はじめに

セキュリティ対策の候補を挙げても、予算と人員には限りがあるため、すべてを同時に実施することはできません。 製品の知名度や担当者の経験だけで実施順序を決めると、守るべき資産を十分に把握しないまま監視製品を導入してしまうなど、対策を運用するための前提を欠くことがあります。

CIS Controls v8.1は、代表的なサイバー攻撃への防御策を18のControlと153のSafeguardに整理したフレームワークです。 この記事では、CIS Controlsを使って現状と目標の差を整理し、事業リスク、実施の前提関係、費用と担当部門の負荷から施策の優先順位を決める方法を紹介します。

CIS Controlsをロードマップに使う利点

CIS Controlsでは、「資産を管理する」「脆弱性管理プロセスを確立する」といった実施内容がSafeguard単位で示されています。 抽象的な目標に終わることを防ぎ、現状評価の確認項目と実行施策を対応づけやすい点が、ロードマップ作成に向いています。

ただし、「CIS Controlsの掲載順に実施すれば、自社の優先順位も決まる」という意味ではありません。 顧客データを大量に扱うクラウドサービスと、閉じたネットワークで設備を運用する工場では、想定する被害と優先すべき対策が異なるからです。 CIS Controlsは施策の共通語彙と確認範囲に使い、最終的な順序は自社の事業リスクに基づいて決めます。

Implementation Groupを起点に対象範囲を定める

CIS Controlsには、組織のリスク特性と実行に使える資源に応じてSafeguardを段階化したImplementation Groupsがあります。 IG1はすべての組織が起点とする基礎的な対策、IG2は機密情報を扱い、セキュリティの管理や運用を担う人員がいる組織向けの対策、IG3は標的型攻撃などによって重大な影響を受ける組織向けの対策を含みます。 IG2はIG1のSafeguardを含み、IG3はIG1とIG2のSafeguardを包含する段階的な構成になっています。

最初の評価ではIG1を共通の基準とし、事業特性に応じてIG2またはIG3のSafeguardを追加します。 たとえば、決済情報や要配慮個人情報を扱う、停止時の社会的影響が大きい、契約で特定の管理策を求められるといった条件があれば、組織全体のIGだけで機械的に対象を区切らず、該当領域の上位Safeguardも評価対象に含めます。

ロードマップを作る6つの手順

1. 事業リスクと守る対象を整理する

評価の前に、主要サービス、重要業務、法令と契約上の義務を確認し、停止、情報漏えい、改ざんが起きた場合の影響を整理します。 その業務を支えるデータ、端末、サーバー、クラウドサービス、アカウント、委託先をたどり、それぞれの所有部門も明確にします。

この作業が不足すると、Safeguardの実施状況は評価できても、どの不足が事業へ大きな損失を与えるか判断できません。 「顧客向けサービスを3日停止させる可能性がある」「管理者アカウントの侵害から全顧客のデータへ到達できる」のように、資産と事業影響をつないで記録します。

2. Safeguardごとに現在地を評価する

対象とするIGを決めたら、各Safeguardを「未着手」「一部実施」「実施済み」「対象外」などの共通尺度で評価します。 製品や規程が存在するだけでは実施済みとせず、対象範囲、責任者、実施頻度、例外の扱い、証跡を確認します。

たとえば資産管理ツールを導入済みでも、クラウド上の一時的なサーバーや私物端末が把握できていなければ、資産管理は一部実施です。 評価結果には根拠となる台帳、設定、記録を紐づけると、担当者が変わった後も同じ基準で見直せます。

3. 目標状態と不足を施策に変える

現在地と目標の差を、実行可能な施策へ変換します。 「Safeguard 6.3が未実施」とだけ記載するのではなく、「管理者権限を持つアカウントを四半期ごとに棚卸しし、不要な権限を5営業日以内に削除する」のように、対象、実施内容、頻度、完了条件を定めます。

一つのSafeguardに、規程の作成、設定変更、運用開始が含まれる場合は施策を分けます。 分割すると担当者と期限を割り当てやすくなり、文書だけ作成して運用が始まっていない状態も区別できます。

4. 優先順位を共通基準で決める

施策の優先順位は、リスク低減効果だけでなく、緊急性、他施策への波及、実行負荷を同じ基準で比較して決めます。 法令違反の解消、契約要件への対応、悪用が確認されている重大な脆弱性への対処など、期限を待てない項目は採点の前に最優先として扱います。

評価項目 確認する内容 高く評価する例
リスク低減効果 発生可能性または被害の大きさをどの程度下げるか 全社の管理者アカウントへ多要素認証を適用する
対象範囲 重要な業務、資産、利用者をどの程度カバーするか 基幹サービスを含む全クラウド環境を資産台帳へ登録する
緊急性 攻撃の状況、監査期限、法令や契約上の期限があるか 外部公開システムの既知の重大な脆弱性を修正する
前提効果 後続の施策を実行可能にするか 脆弱性管理の前提となる資産と所有者を把握する
実行負荷 費用、期間、必要な技能、現場への影響はどの程度か 既存機能の設定変更だけで広い範囲を保護できる

各項目を3段階または5段階で採点すると、部門間で判断理由を共有しやすくなります。 ただし、点数は異なる施策を比較するための補助であり、合計点のわずかな差を客観的な精度とみなすことはできません。 採点結果とともに、対応する事業リスクと判断理由を残します。

5. 依存関係を踏まえて実施順序を決める

優先度が高い施策でも、前提となる仕組みがなければ運用できません。 脆弱性スキャンを始める前に対象資産と所有者を把握し、ログ監視を拡大する前に時刻同期、収集対象、保存期間を決めるなど、施策間の依存関係を確認します。

依存関係を整理したら、直近の四半期は具体的な作業と完了条件まで定め、半年以降は目標と施策群を示します。 遠い時期の作業を細かく固定すると、システム構成や脅威が変わった際に計画の修正量が増えるためです。

6. 責任者と効果指標を設定する

各施策には責任者、協力部門、期限、予算、完了条件を設定します。 「EDRを導入した」「規程を作成した」という完了だけでなく、管理対象端末への適用率、重大な脆弱性を期限内に修正した割合、復元テストの成功率など、対策が機能しているかを確認する指標も設けます。

月次または四半期のレビューでは、作業の進捗と指標の変化を確認します。 新しいサービス、M&A、重大なインシデント、法令や契約の変更があれば事業リスクの整理へ戻り、対象と優先順位を更新します。

12か月のロードマップ例

次の例は、IG1を起点に基礎的な対策を整える場合の構成です。 実際の施策と順序は、現状評価と事業リスクに応じて変更します。

時期 目標 施策の例 確認指標の例
0〜3か月 管理対象と重大な不足を把握する 資産、ソフトウェア、アカウントの棚卸し、現状評価、緊急対応が必要な項目の是正 所有者を特定できた重要資産の割合
4〜6か月 侵害を防ぐ基礎対策を整える 多要素認証、構成管理、脆弱性管理、マルウェア対策、バックアップの見直し 多要素認証の適用率、重大な脆弱性の期限内修正率
7〜9か月 検知と初動の運用を定着させる ログ収集範囲の拡大、アラート対応手順、インシデント連絡体制の整備 ログ収集対象の割合、アラートの初動時間
10〜12か月 対策の有効性を確認して次年度へ反映する 復元テスト、インシデント対応訓練、アクセス権レビュー、次年度の現状評価 復元テストの成功率、訓練で見つかった課題の改善率

優先順位付けで避けたい3つの判断

一つ目は、未実施のSafeguardをすべて同じ優先度で並べることです。 未実施という状態が同じでも、下げられる事業リスクと必要な前提は異なるため、リスク低減効果と依存関係を比較する必要があります。

二つ目は、導入しやすい製品から計画へ載せることです。 短期的には進捗を示しやすくても、対象資産、運用責任、対応手順が定まっていなければ、導入後に検知や是正が続きません。

三つ目は、IGを組織の成熟度を示す点数として扱うことです。 Implementation Groupはリスク特性と利用可能な資源に応じて実施対象を選ぶための分類であり、IG3を選ぶこと自体が目標ではありません。 自社に必要なSafeguardが継続して機能し、想定したリスクを下げている状態を目標にします。

まとめ

CIS Controlsを使ったロードマップは、Safeguardの実施数を増やす予定表ではありません。 事業リスクを起点に対象を選び、現状との差を施策へ変え、リスク低減効果と実行条件から順序を決める計画です。

最初はIG1を共通基準として評価し、事業特性に応じて上位IGのSafeguardを追加します。 四半期ごとに進捗、効果指標、事業の変化を確認して優先順位を更新すれば、限られた予算と人員を説明可能な根拠に基づいて配分できます。

セキュリティロードマップの作成にお困りの場合

自社だけでCIS Controlsの現状評価や施策の優先順位付けを進めることが難しい場合は、弊社のセキュリティチーム代行サービスをご検討ください。 事業リスクの整理からロードマップの作成、各施策の実行と定着まで、外部のセキュリティチームとして継続的に支援します。