長年にわたり、組織のセキュリティ態勢を説明する最も簡単な方法の一つは、脆弱性の数を数えることだった。
セキュリティチームは、スキャン中に2,000件の脆弱性を発見した、重大な検出結果を40％削減した、あるいは特定の期間内に高深刻度の問題の95％にパッチを適用した、と報告するかもしれない。
こうした数字は有用だ。しかし、経営幹部やセキュリティリーダーが実際に知りたい問いに、常に答えられるとは限らない。
現在、組織はどの程度さらされているのか。
ある企業は何千もの脆弱性を抱えていても、外部へのエクスポージャーは比較的限定されている可能性がある。一方、別の組織には高深刻度の検出結果が数十件しかなくても、そのうち1件がインターネットに公開されたシステムに影響し、特権IDに関係し、機密データへの直接的な経路を提供しているかもしれない。
この違いを背景に、継続的エクスポージャー管理（CEM）への関心が高まっている。
CEMは、セキュリティへの露出を定期的な評価の際に測定するものとして扱うのではなく、より継続的な視点で捉える。資産、脆弱性、ID、設定、攻撃経路、ビジネスコンテキストを調べ、どの弱点が現実のリスクとして最も大きいのかをセキュリティチームが把握できるようにする。
目的は、すべてのセキュリティ上の検出結果をなくすことではない。攻撃者が現実に悪用できる機会を継続的に減らすことが目的だ。
脆弱性管理とエクスポージャー管理は同じではない。
脆弱性管理は、サイバーセキュリティの重要な一部であり続けている。
セキュリティチームは、脆弱性を発見し、深刻度を評価し、修正の優先順位を付け、修正が適用されたことを確認する必要がある。
問題は、脆弱性の深刻度だけでは全体像が分からないことだ。
深刻度スコアが同じ2つの脆弱性を考えてみよう。
- 脆弱性Aは、機密情報がなく接続性も限定された、隔離された内部テストサーバーに存在する。
- 脆弱性Bは、顧客データベースに接続された、インターネットに公開された本番アプリケーションに存在する。
CVSSの観点では、どちらも対応に値するかもしれない。しかし、ビジネスリスクの観点では、両者は大きく異なる。
エクスポージャー管理は、このコンテキストを加味する。
単に次のように問うのではなく、
「この脆弱性はどの程度深刻か？」
セキュリティチームは、次のように問える。
「攻撃者は現実に、この弱点を利用して重要なものに到達できるのか？」
この視点の転換は、継続的エクスポージャー管理へ移行する最大のメリットの一つだ。
セキュリティチームは何を測定すべきか？
組織のエクスポージャーを説明できる単一の指標は存在しない。
有効なCEMプログラムでは、複数のシグナルを組み合わせ、セキュリティチームが実際に行動に移せる情報へと変換する必要がある。
追跡する価値のある測定項目をいくつか紹介する。
1. インターネットに公開されたエクスポージャー。
最初の問いは、比較的シンプルなものにすべきだ。
攻撃者はインターネットから何に到達できるのか？
組織は、自分たちが認識している以上に多くの資産を外部に公開していることが多い。
これには次のようなものが含まれる。
- Webアプリケーション。
- API
- リモートアクセスサービス
- クラウドワークロード
- 開発環境
- 放置されたサブドメイン
- ストレージサービス
- サードパーティがホスティングするシステム
公開を意図していなかった資産も、誤って公開されれば深刻なセキュリティ問題になり得る。
そのためセキュリティチームは、インターネットに公開された資産の正確なインベントリを維持し、公開が意図したものかどうかを定期的に確認すべきだ。
2. 価値の高い資産に存在する重大な脆弱性。
すべての脆弱性に同じ緊急度で対応する必要があるわけではない。
価値の低いシステムに存在する重大な脆弱性は、ID基盤やビジネスクリティカルなアプリケーションに影響する中程度の深刻度の問題ほど懸念すべきものではない可能性がある。
ここで重要になるのが、資産の重要度だ。
セキュリティチームが把握すべきこと：
- 機密データを含むシステムはどれか。
- 重要なビジネスプロセスを支えるアプリケーションはどれか。
- 特権アクセスを提供するシステムはどれか。
- 外部に公開されている資産はどれか。
- 他の価値の高い環境に接続しているシステムはどれか。
脆弱性情報と資産の重要度を組み合わせることで、はるかに有用な優先順位付けが可能になる。
3. 悪用可能性。
攻撃者がすでに悪用している脆弱性や、信頼性の高い悪用手段が公開されている脆弱性は、より大きな懸念となる。
そのためセキュリティチームは、深刻度スコアだけでなく、より幅広く監視すべきだ。
次の点を考慮する必要がある。
- 悪用が観測されているかどうか
- 公開されたエクスプロイトコードが存在するかどうか
- 影響を受けるテクノロジーが広く導入されているかどうか
- 技術的に悪用が現実的かどうか
- 代替的なセキュリティ対策が利用できるかどうか
これにより組織は、限られた修正リソースを、最大の効果が見込める場所に集中させられる。
4. IDのエクスポージャー。
現代の企業環境は、マシンだけを見ていても保護できない。
IDは攻撃対象領域の主要な部分になっている。
セキュリティチームは次の項目を調べるべきだ。
- 特権アカウント
- 休眠アカウント
- サービスアカウント
- 過剰な権限
- 窃取された認証情報
- 脆弱な認証制御
- サードパーティのID
- クラウドID
- マシンおよびワークロードのID
- 脆弱なサーバーは一つの問題だ。
脆弱なサーバーに侵害された特権IDが組み合わさると、リスクはまったく異なるレベルに達する可能性がある。
このためエクスポージャー管理では、脆弱性データとID情報を結び付ける必要性が高まっている。
5. 攻撃経路。
エクスポージャー管理で最も有用な概念の一つが、攻撃経路だ。
攻撃経路のアプローチでは、セキュリティ上の弱点を個別に調べるのではなく、複数の弱点がどのように組み合わさる可能性があるかを見る。
例えば、次のような経路だ。
インターネットに公開されたアプリケーション → 脆弱なコンポーネント → 侵害されたサービスアカウント → 過剰な権限 → 機密データベース
個々の問題は、それぞれ異なるセキュリティチームが追跡している可能性がある。
脆弱性はアプリケーションチームが、サービスアカウントはIDチームが、データベースはクラウドチームが担当しているかもしれない。
しかし攻撃者は、各コンポーネントをどのチームが担当しているかなど気にしない。関心があるのは、経路全体が価値のある場所に通じるかどうかだ。
こうした関係を理解することで、現実的な攻撃シナリオに基づいて修正の優先順位を付けられるようになる。
6. クラウドのエクスポージャー。
クラウド環境では、エクスポージャー管理はより複雑になる。
リソースは迅速に作成でき、頻繁に変更され、複数のサービスに接続される可能性がある。
単一のクラウドワークロードに、次のような要素が関係することがある。
- コンピューティングリソース
- ストレージ
- IAM権限
- API
- セキュリティグループ
- コンテナ
- SaaS統合
- シークレット
- サードパーティサービス
先月は安全だった設定が、新たな接続や権限変更の後にリスクのあるものになる可能性がある。
このため、クラウドを定期的に評価するだけでは、十分な可視性を得られない場合がある。
組織には、クラウドのエクスポージャーに生じた意味のある変化を継続的に特定するプロセスが必要だ。
7. 外部攻撃対象領域の変化
攻撃対象領域は固定されたものではない。
企業は新しいアプリケーションを立ち上げ、事業を買収し、インフラを廃止し、クラウドプロバイダーを変更し、新たなSaaSプラットフォームを導入する。
こうした変化によって、誰も意図的にセキュリティ上の弱点を作っていなくても、セキュリティ上のエクスポージャーが生じる可能性がある。
例えば、マーケティングチームが、これまで使われていなかったサブドメインを利用して新しいアプリケーションを立ち上げることがある。
セキュリティチームは、そのシステムの存在をすぐには把握できないかもしれない。
外部攻撃対象領域管理（EASM）は、こうした資産の発見を支援し、エクスポージャー管理における可視性を高める別の情報源となり得る。
8. 修正までの時間
平均修正時間は今でも有用だが、慎重に解釈すべきだ。
企業が平均修正時間を15日と報告することがある。
しかし、その数字に数千件の低リスク脆弱性が含まれている一方で、インターネットに公開されたシステムに影響する、悪用可能性の非常に高い一握りの脆弱性が未対応のままだと分かれば、印象は変わる。
セキュリティチームは、リスクカテゴリー別に修正時間を追跡することを検討すべきだ。
例えば、次のような分類だ。
- 重大なインターネット公開エクスポージャー
- 高リスクのIDエクスポージャー
- 悪用された脆弱性
- 重大なクラウドの設定ミス
- 高リスクの攻撃経路
これにより、セキュリティ上のエクスポージャーが実際に改善しているかどうかを、はるかに明確に把握できる。
9. 未解決のまま残るエクスポージャー
もう一つ有用な指標は、未解決のまま残っている重大なエクスポージャーの量だ。
次のように報告するのではなく、
「5,000件の脆弱性を修正した」
セキュリティ責任者は、次のように問える。
「影響の大きいエクスポージャー経路は、あといくつ残っているのか？」
こちらの方が、経営幹部にとってはるかに意味のある問いだ。
目指すべきは、意味のあるエクスポージャーの数と深刻度が時間とともに減少することだ。
10. ビジネスコンテキスト
セキュリティ指標は、技術的なエクスポージャーとビジネスへの影響を結び付けたときに、最も有用になる。
例えば経営幹部は、アプリケーションに17件の脆弱性があることを必ずしも知る必要はない。
理解すべきなのは、次の点だ。
- どのビジネスプロセスが影響を受けるのか。
- どのデータが露出する可能性があるのか。
- そのシステムを経由して、別の重要な環境にアクセスできる可能性はあるのか。
- 現在、悪用は可能なのか。
- 推奨される対応は何か。
- どれほど迅速に対処する必要があるのか。
ここでセキュリティチームは、技術的な調査結果をビジネス上の意思決定へと変換できる。
実践的なCEMダッシュボード
有用なエクスポージャー管理ダッシュボードに、数百もの指標は必要ない。
セキュリティ責任者は、まず少数の指標から始めることができる。
エクスポージャー
- インターネットに公開された重大な資産の数
- 未知の外部資産の数
- 高リスクの攻撃経路の数
脆弱性
- 悪用可能な重大な脆弱性
- ビジネスクリティカルな資産に存在する重大な脆弱性
- 高リスクの調査結果の平均修正時間
ID
- 特権ID
- 過剰な権限
- 休眠状態の特権アカウント
- 高リスクの侵害された認証情報
クラウド
- 重大なクラウドの設定ミス
- 公開された機密リソース
- 高リスクのID権限
対応
- 解消した高リスクのエクスポージャー
- 再発した高リスクのエクスポージャー
- 重大なエクスポージャーを封じ込めるまでの平均時間
- 修正後に重大な調査結果を検証した割合
正確な指標は組織によって異なる。
重要なのは、ダッシュボードが一つの問いへの答えを導き出せることだ。
「実際のエクスポージャーは増えているのか、減っているのか？」
継続的であることの重要性
「継続的」という言葉は重要だ。
四半期ごとの脆弱性評価は、一時点のスナップショットを提供する。
しかし、企業環境は日々変化する。例えば、次のような変化がある。
- 新しいクラウドリソースがデプロイされる。
- 新しいAPIが公開される。
- ソフトウェアのアップデートによって脆弱性が持ち込まれる。
- 特権アカウントが作成される。
- サードパーティとの統合が接続される。
- それまで無害だったシステムが、より大きな攻撃経路の一部になる。
つまりセキュリティチームは、エクスポージャーを固定された評価結果ではなく、常に変化する対象として扱うべきだ。
継続的であることは、必ずしもすべてのセキュリティ制御を毎秒実行しなければならないという意味ではない。
組織が、意味のある変化を定期的に発見し、その変化が忘れられたエクスポージャーになる前にリスクを再評価するプロセスを持つという意味だ。
継続的エクスポージャー管理におけるVAPTの位置付け
継続的エクスポージャー管理は、ペネトレーションテストに取って代わるものではない。
両者は異なる目的を果たす。
- 自動化されたエクスポージャー管理は、資産、脆弱性、設定、ID、潜在的な攻撃経路の特定を支援できる。
- 脆弱性スキャンは、既知の技術的な弱点を特定できる。
続いて、脆弱性評価およびペネトレーションテスト（VAPT）によって、より深い検証を行える。
ペネトレーションテストは、弱点が実際に悪用可能かどうか、また攻撃者がアクセスを得た後に何を達成できる可能性があるかを判断するのに役立つ。
したがって、実践的なセキュリティプログラムでは、次の要素を組み合わせられる。
継続的な発見 → リスクの優先順位付け → VAPT → 修正 → 検証 → 継続的な監視
これにより、年1回のペネトレーションテストだけに頼るよりも、強固なフィードバックループを構築できる。
エクスポージャー管理プログラム構築時によくある間違い
間違い1：すべての検出結果を同じように扱う
すべての脆弱性に同じ対応が必要なわけではない。
リスクのコンテキストが重要だ。
間違い2：CVSSだけに注目する
深刻度スコアは有用だが、優先順位付けの唯一の要素にすべきではない。
悪用可能性、エクスポージャー、資産価値、IDのコンテキストも重要だ。
間違い3：未知の資産を無視する
存在を把握していない資産を保護することはできない。
外部資産の発見は、プログラムの一部にすべきだ。
間違い4：インフラだけを見る
現代のエクスポージャーには、ID、クラウドサービス、API、アプリケーション、サードパーティとの接続が含まれる。
間違い5：リスクの低減ではなく活動量を測定する
実施したスキャンの回数や修正した脆弱性の数は、セキュリティが向上したことと同じではない。
より重要な問いは、意味のあるエクスポージャーが減少しているかどうかだ。
セキュリティチームが始めるべきこと
エクスポージャー管理プログラムを全面的に導入する準備が整っていない組織でも、実践的な取り組みをいくつか始めることはできる。
ステップ1：正確な資産インベントリを構築する
内部と外部に何が存在するのかを把握する。
ステップ2：重要な資産を特定する
ビジネス上の重要性とデータの機密性に基づいてシステムを分類する。
ステップ3：IDの関係をマッピングする
特権ユーザー、サービスアカウント、ワークロードIDを把握する。
ステップ4：インターネットに公開されたエクスポージャーを優先する
攻撃者が直接到達できるシステムから始める。
ステップ5：脆弱性データと資産データを結び付ける
独立した脆弱性リストだけに頼るのをやめる。
ステップ6：意味のある攻撃経路を特定する
価値の高い資産につながる可能性のある弱点の組み合わせを探す。
ステップ7：重要な検出結果を検証する
ペネトレーションテストとセキュリティ評価を用いて、高リスクの検出結果が実際に悪用可能かどうかを判断する。
ステップ8：改善度を測定する
意味のあるエクスポージャーが時間とともに減少しているかを追跡する。
目標は脆弱性ゼロではない
これは、最も重要な意識の変化かもしれない。
大規模な企業で脆弱性をゼロにすることは、まず難しい。
新たな脆弱性は発見され続ける。新しいアプリケーションがデプロイされる。クラウドの設定は変化する。新たなIDが作成される。
したがって、検出結果をゼロにしようとすることは、非現実的な目標になり得る。
より良い目標は、エクスポージャーを制御することだ。
セキュリティチームは次を把握すべきだ：
- 何にさらされているのか
- どのエクスポージャーが最も重要なのか
- どの攻撃経路が現実的なのか
- どの弱点に直ちに対応する必要があるのか
- どのリスクを受容しているのか
- 全体的なエクスポージャーが改善しているか
これにより、セキュリティ責任者は脆弱性の数をはるかに上回る価値を得られる。
組織への侵入がどれほど難しいのかを把握できるのだ。
最後に
継続的エクスポージャー管理は、脆弱性とサイバーリスクに対する組織の考え方の転換を示すものだ。
脆弱性がいくつ存在するのかだけを問うのではなく、セキュリティチームは、脆弱性が資産、ID、クラウド環境、攻撃経路とどのように相互作用するのかに注目できる。
最も効果的なプログラムが、必ずしも最大数の検出結果を生み出すとは限らない。
生み出すのは、より良い意思決定だ。
セキュリティチームは、重要なエクスポージャーを特定し、それが重要である理由を説明し、ビジネスリスクに応じて優先順位を付け、修正によって組織の攻撃対象領域が実際に縮小したことを検証できなければならない。
企業環境がより分散化し、動的になるにつれて、エクスポージャーを継続的に把握し、低減する能力はますます重要になる。
目的は、別のセキュリティダッシュボードを作ることではない。
より難しい問いに答えられるセキュリティプログラムを構築することだ。
もし今日、攻撃者が私たちを標的にしたら、環境への最も現実的な侵入経路はどこにあり、それに対して何をしているのか？