.jpeg){kind=logo}
最近、私はサイバーセキュリティのリーダーたちと、「セキュリティ・イベント・ホライズン」という私が提唱している概念について、多くの議論を交わしています。その基本的な考え方は、セキュリティ分野における「多層防御」という概念は、本来の意味とは異なるものであるということです。セキュリティ技術は、対象となる攻撃ツールや行動の範囲において 重複することがほとんどなく、通常、攻撃者が侵害を試みてから実際に成功するまでの間には、たった一つのセキュリティ対策／技術しか介在していないのです。 予防は依然として重要ですが、攻撃のライフサイクルには、予防志向の考え方がもはや有効なモデルではなくなり、検知、コンテキスト、そして対応が最も重要になる時点が存在します。
セキュリティ運用に長く携わってきた人にとっては当たり前のことのように聞こえるかもしれませんが、セキュリティ業界の多くでは依然として、適切な予防策を講じれば侵害は例外的な事態に過ぎないとでも言うかのようにこの問題について語られているため、この点を明確にしておく価値はあると思います。実際の環境では、そうはいかないのです。
なぜ「多層防御」という表現は不適切なのでしょうか？
現代の企業は、その規模があまりにも大きく、分散化が進み、かつ変化が激しいため、そのような前提は成り立ちません。企業は、クラウドインフラストラクチャ、SaaSアプリケーション、エンドポイント端末群、ID管理システム、API、サードパーティ製サービス、レガシーアプリケーション、そしてビジネスに不可欠なシステムなど、膨大な資産を運用していますが、これらに対して現実的な時間枠内でパッチを適用することは困難、あるいは不可能です。 管理が行き届いた組織であっても、未把握の資産、外部に公開されたサービス、設定のドリフト、権限が過剰なID、そして修正プログラムが利用可能になった時点でパッチを適用できないシステムが存在する。
もちろん、予防策は依然として必要です。パッチ適用、システムの強化、ネットワークのセグメンテーション、ID管理、セキュアな設定、メールセキュリティ、エンドポイント保護、脆弱性管理といった対策は、いずれも攻撃者が攻撃の機会を得る余地を減らします。しかし、問題は、予防策だけでは完全な運用モデルとは言えない点にあります。企業規模では、予防策の一定割合は失敗に終わるものであり、セキュリティアーキテクチャは、その前提を踏まえて設計されなければなりません。
AIはこの問題をさらに深刻化させる。攻撃者は、脆弱性の発見、エクスプロイトの亜種の作成、偵察活動の自動化、説得力のあるソーシャルエンジニアリングの手法の生成、そして防御側の対応に応じて活動を適応させるための、より優れたツールを手にすることになるだろう。防御側もAIを活用するだろうが、時間的な非対称性が重要な問題となる。大規模な企業全体において、すべての悪用可能な経路が排除されたことを証明するよりも、1つの悪用可能な経路を見つけるほうがはるかに容易だからだ。
関連記事： 2つのジェネレーティブAIの波が去った後、企業の次なる展開は？
なぜ「セキュリティ・イベント・ホライズン」なのか
だからこそ、私は「セキュリティ・イベント・ホライズン」という概念を考案し、これについて議論することが重要だと考えているのです。
このモデルでは、原因に基づく検知と結果に基づく検知が区別されています。原因に基づく検知は、攻撃を引き起こす、あるいは可能にする要因、すなわち脆弱性、エクスプロイト、悪意のあるファイル、コマンド、インフラストラクチャの指標、phishing 、あるいは既知の手法などに焦点を当てています。ここには、多くの予防および遮断ロジックが当然ながら組み込まれています。
効果ベースの検知は、初期攻撃が成功した後の展開に焦点を当てています。攻撃者が環境内に侵入すると、そこで実行すべき一連の作業があります。具体的には、認証、情報収集、移動、権限昇格、潜伏、通信、データの準備を行い、最終的には目的を達成するための行動を起こします。こうした行動は、環境内に何らかの影響をもたらします。防御側の役割は、そうした影響を検知し、その文脈を理解した上で、攻撃者が実際に被害をもたらす前に適切な対応を行うことです。
MITRE ATT&CK は、この移行を説明する上で有用な手法です。攻撃の初期段階は、予防を目的とした対策と自然に一致する傾向があります。攻撃が「発見」、「認証情報の取得」、「横方向の移動」、「コマンド＆コントロール」、「情報の収集」、「情報の持ち出し」へと進行するにつれて、環境からは行動の証拠が生じ始めます。その時点で問題となるのは、個々のオブジェクトが悪意のあるものであるかどうかというよりも、一連の活動に整合性があるかどうかという点になります。
攻撃者は、正当な認証情報、正当なプロトコル、正当な管理ツール、そして正当なクラウドサービスをますます多用するようになっています。 彼らの行動の多くは、単独で見れば悪意のあるものには見えません。ログインは有効かもしれません。PowerShellコマンドは許可されているかもしれません。2つのシステム間の接続は承認されたプロトコルを使用しているかもしれません。クラウドAPIの呼び出しは構文的には正常かもしれません。重要なのは、その動作が、そのユーザー、ホスト、ワークロード、またはアプリケーションの通常の動作と一致しているかどうか、そしてより広範な攻撃パターンに当てはまるかどうかです。
検知とは、単にアラートを収集するだけでは不十分です。アナリストが優先順位付けを行うためのシグナルを単に増やすだけでは、本来目指すべき成果にはつながりません。侵害後の環境において真に必要なのは、攻撃の進行状況を把握できる体制を整えることです。これには、いくつかの実務上の意味合いがあります。
サイバー攻撃の進行過程を理解する
まず、予防とはリスクの排除ではなく、リスクの低減として捉える必要があります。予防は攻撃者の機会を減らすものであり、継続的に改善すべきですが、アーキテクチャの他の部分がそれに依存するという前提であってはなりません。
第二に、検知機能は、防御が失敗した後に観測可能な攻撃の要素を中心に設計されなければなりません。ネットワーク活動、IDの挙動、クラウドのコントロールプレーン活動、SaaSの利用状況、エンドポイントのテレメトリ、データの移動は、いずれも攻撃者の行動を異なる角度から捉える手がかりとなります。現代のセキュリティアーキテクチャにおいて、これらはいずれも単独では不十分です。
第三に、コンテキストは不可欠であり、テレメトリと同様に重要です。イベントを検知することと、それを理解することは別物です。防御担当者は、対象資産が何であるか、そのIDの所有者は誰か、通常の動作はどのようなものか、システムが外部に公開されているかどうか、どのような権限が関与しているか、そしてその活動が環境内の他のイベントとどのように関連しているかを把握する必要があります。
最後に、対応策は攻撃の段階と密接に関連していなければなりません。初期段階の不確かな兆候に対する適切な対応は、横方向の移動やデータ転送が確認された場合の対応とは異なります。セキュリティ運用チームは、単に何かが発生したということを把握するだけでなく、攻撃ライフサイクルのどの段階にあるのか、そして理想を言えば、攻撃者が次に何をしようとしているのかを見極める必要があります。
これが「セキュリティ・イベント・ホライズン・フレームワーク」の要点です。これは、さまざまな技術がどの領域で機能し、どのようなシグナルを生成するか、そして攻撃が「侵害の試み」から「実際の侵入」へと移行するにつれて、その価値がどこで変化するかを分析するための手法です。
予防は、常にセキュリティアーキテクチャの中核をなす要素であり続けるでしょう。しかし、AIによって脆弱性の発見や悪用が加速し、企業全体で導入されているすべてのソフトウェアやハードウェアコンポーネントにパッチを適用することが現実的ではない現代においては、セキュリティプログラムは、予防策が失敗した後に何が起こるかを明確に定義し、その事態に備えた設計を行う必要があります。
そこで、検知と対応がその役割を担わなければならない。それは、後付けの対策や、ばらばらのアラートの寄せ集めとしてではなく、環境全体にわたる攻撃者の行動を理解するためのモデルとしてである。
セキュリティ担当者や管理職にとっての実務上の課題は、極めて明快です。攻撃者が本来なら阻止されるはずの防御策を突破した場合、その行動を把握し、攻撃がどこまで進行しているかを理解し、その活動がビジネスに重大な影響を及ぼす事態となる前に、適切に対応できるでしょうか。
Vectra AIは、他社にはない独自のデータセットと技術を活用した検知・対応機能を提供することで、ハイブリッドかつソフトウェア定義型のエンタープライズ環境を保護するために必要なシグナルと継続的な対応能力を実現するよう、独自の設計が施されています。「イベント・ホライズン」を超えた機能を提供するセキュリティアーキテクチャを真剣に検討されているなら、ぜひご検討ください。
「Security Event Horizon」におけるマーティ・ロッシュのその他の記事については、 『Hunt Club 』をお聴きください。