ASMは4つのプロセスを意識せよ Gartnerアナリストが提言する実践マニュアル：Cybersecurity Dive

近年注目度が高まっている攻撃対象領域管理（ASM）は、組織の脆弱性管理強化における中核的な要素だ。本稿ではこの実践に向けた4つのポイントを解説する。

[Steve Santos，Cybersecurity Dive]

　編集部注：以下は、調査企業Gartnerでセキュリティ運用とネットワークセキュリティに関するトピックを担当するスティーブ・サントス氏（シニアディレクター・リサーチアナリスト）による寄稿記事である。

　多くの場合、セキュリティリーダーは日々の脅威検出や対応の業務に追われており、現在のツールやプロセスでは攻撃対象領域やセキュリティの状況を十分に把握できないという。今、それが課題になっている。どこに注力すべきか分からなかったり、Webサイトの境界や外部IPアドレス、エンドポイントなどのよく知られた攻撃対象領域にのみ集中してしまったりするのだ。

ASM実践マニュアル　4つのプロセスで進めよう

　このような可視性の欠如を認識した組織は、攻撃対象領域管理（ASM）を実現する方法の確立を目指し、改善に取り組まなければならない。

　ASMは脆弱（ぜいじゃく）性管理や検証、その他のITおよびセキュリティ機能を強化するために組織が活用できるエクスポージャー管理の中核的な要素だ（注1）。企業が保有する資産とそれらの資産に関連するリスクを特定し、可視性という重要な課題に対する答えを提供する。

　ASMの主要な目的には資産の可視性と可用性の向上、セキュリティコントロールに関連するコンプライアンスリスクおよび資産リスクの定量化が含まれている。

　セキュリティリーダーは自社にとって重要な攻撃対象領域の可視化とリスク評価を実施するために、リスクベースのアプローチにのっとって包括的なASMプログラムの導入を目指すべきだ。このアプローチには次のような取り組みが含まれる。

• 範囲設定：　ASMの実装範囲を決定するために、さまざまな攻撃対象領域を理解し、セキュリティの問題だけでなく、ビジネスに焦点を当てた課題に集中すること
• ツールの活用：　攻撃対象領域の範囲に適したツールやサービス、実装方法を適用すること
• プロセス開発：　ASMに関連する適切なプロセスを策定し、実施すること

　さまざまな攻撃対象領域やテクノロジーが関わるため、ツールやプロセスの実装は複雑になる場合がある。ASMを脅威検出や対応に統合するためには、次の4つのプロセスを活用すべきだ。

1．特定

　範囲が明確に定義されていたとしても、組織の攻撃対象領域を管理し、それらをASMツールにマッピングするプロセスに圧倒されるだろう。なぜなら、プロセスを妨げる補助的なデータや矛盾するデータが多く存在するためだ。

　重要なのは適切な資産とデータソースの特定だ。

　セキュリティリーダーにとって重要なのは、攻撃対象領域をより適切に理解するのに役立つ遠隔測定ソースの評価だ。資産ソースには、2つのカテゴリーがある。一つは運用状況に関係なく自分たちが管理および統制しているソースである。もう一つは、自分たちのチームで管理しておらず、他のチームや公開ソースから取り込まなければならないデータだ。

　セキュリティリーダーはASMのプロセスに何を組み込むべきかを評価する前に、資産としての側面を有する全てのITおよびセキュリティ管理項目を一覧化する必要がある。

　全ての組織がさまざまなデータポイントにアクセスできるわけではないため、どのデータソースを取り入れるかを慎重に評価する必要がある。

　外部攻撃対象領域のような一部の攻撃対象領域は、管理されていないデータソースに依存することが多い旨を忘れないでほしい。これはデータの有効性を損なうものではないが、データの使用と理解が複雑化する可能性がある。専門的なASMツールを活用することで、組織は異なるデータの管理と理解に対応しやすくなる。

2．集約

　さまざまなデータソースを集約して関連するコンテキストを得ることは、統合やデータサイエンスの作業に近いものになる。幸いにも、データの統合と集約は、SIEM（Security Information and Event Management）製品やXDR（拡張脅威検知と対処）製品、ITサービス管理、その他の分析ツールなどの多くの主要技術によって対応および実装されている。

　ASMも同様の技術を活用できるため、どのベンダーやどの技術を使用するかが成功の鍵となる。この際、APIを中心とした実装は独自仕様のものよりも優れた性能を発揮する。自社開発の実装ではASMを集約する際におけるさまざまな側面での苦戦が予想される。

　集約フェーズの実装には、以下の手順が必要だ。

• 攻撃対象領域を管理するプラットフォームの決定：　プラットフォームがクラウドにホストされているかどうか、またはオンプレミスかどうかによって統合に影響が生じる。ホスティングの場所により、幾つかのソースで統合に制限が生じる可能性があるためだ
• 固有の資産識別子の確立：　セキュリティリーダーは、ツールに含まれている既存の識別子を使用するか、組織にとってより適切な新しい識別子を定義するかを選択できる
• 資産データのコンテキストの組み込み：　資産のデータソースに固有の識別子を設定した後、セキュリティリーダーは、さまざまなデータソースに関連する資産のコンテキストを集約および整理できるようになる
• 独自の課題に対応するプロセスの確立：　一時的または短期間のみ保有する資産、廃止された資産、誤って検知されたコンテキストをはじめとして、特別な状況にある資産に対応するプロセスを構築する

3．リスク評価

　ASMの導入におけるここまでの段階で、セキュリティリーダーは資産に対する可視性を既に確立している。次のユースケースは、集約された資産のコンテキストを活用して資産に関するリスク評価を実施することである。

　これは2つの評価に分類できる。1つ目のセキュリティコンプライアンスの評価では、セキュリティ管理の実装における不足を特定する。これは「未実装」や「設定ミス」の組み合わせとして現れることがある。

　2つ目の資産リスクの定量化においては、データソース間の関連性に基づいてリスクを数値化する必要がある。

4．機能改善

　ASMデータを活用して資産データに依存するツールの精度を向上させたり、攻撃対象領域に関連するデータを活用して既存のプロセスを改善したりできる。ASMは、エクスポージャー管理やインシデント対応を通じて、セキュリティ運用およびIT運用の機能を強化する。

　適切に機能しているSOCは攻撃対象領域を明確に把握し、十分に理解している。セキュリティの専門家は、攻撃対象領域管理を強化するためのツールや手法を導入する際に、これらのステップを念頭に置くと良いだろう。

（注1）Cybersecurity Trends: Optimize for Resilience and Performance（Gartner）

原文へのリンク