AIがチームによる修正よりも速く脆弱性を発見できるようになると何が変わるのか。そしてそれに対処するための4段階の計画をご紹介します。
最先端のAIモデルは今や、人間には到底かなわない規模とスピードで脆弱性を発見できるようになっており、現時点での最高水準を示しているのがMythosです。その対象には、CVEが割り当てられていない欠陥や、何十年もレビューされ続けてきたコード内の欠陥も含まれます。現時点では最強のモデルへのアクセスは制限されていますが、この能力は徐々に広がりつつあり、攻撃者もこれを手にすることになります。
ここで実務上の問題となるのは、脆弱性の発見が高速かつ低コストになった一方で、トリアージ、修正、そして悪用された場合の封じ込めについては、そうなっていないという点です。もともとバックログを抱えて対応が遅れていたプログラムであれば、状況はさらに悪化します。そこで本稿では、実際に何が変わるのか、そしてその変化に対応できる体制をどう構築すればよいのかを見ていきます。
ルールを変える4つの変化
1. 既存の制度では処理しきれないほどの脆弱性が生まれています。CVEの発行はAIによる発見のペースに追いついておらず、実際には存在する不具合の一部にはCVEが永久に付与されないケースも出てきます。CVEの有無にかかわらず、それが実際のビジネスリスクを意味するのであれば、対応する責任はセキュリティチームにあります。
2. 攻撃者にとって、悪用がより速く、より安価になっています。脆弱性が知られてから実際に悪用されるまでの時間は、劇的に短縮されました。MandiantのM-Trendsレポート最新版では、平均悪用時間がマイナス7日と推定されています。つまり、パッチが公開される前から悪用が始まるということです。これに合わせて、対応・修正のスピードを上げる必要があります。
3. リスク受容の正当化が難しくなっています。AIによって防御側の対応が速く安価になるという業界の一般的な見方があるため、脆弱性を放置することは、もはやリソース不足の問題ではなく、意図的な選択と見なされるようになりつつあります。攻撃者がAIを使いこなす以上、取締役会や監査人も、セキュリティチームがAIを活用してより速く、より低コストで対応することを期待するでしょう。
4. 攻撃対象領域全体の露出がより大きくなっています。ソフトウェア、設定、ID関連の弱点は、いずれも機械的なスピードで発見・調査され得ます。本稿ではソフトウェアの脆弱性に焦点を当てていますが、ここで示す原則は他の一般的な攻撃経路にも応用できます。
明るい材料もあります。特定のコードベースに関して言えば、これは際限のない洪水ではなく、あくまで一時的な急増にとどまるということです。コードの量には限りがあり、AIが発見する不具合の大半は、既知の脆弱性クラスであり、既知の修正方法が存在します。厄介なのは脆弱性そのものが特殊だからではなく、その「量」の多さなのです。
新しい状況に対応するプログラムの作り方:4段階の計画
このギャップを埋めるのがセキュリティチームの仕事です。攻撃者を助けているのと同種のAIツールは、防御側も利用できます。トリアージに、修正の振り分けに、そして対応に、これを活用しましょう。
以下に示す計画は、その実現を後押しするものです。計画の各段階は、それぞれ一つ前の段階だけでは不十分だからこそ存在しています。発見した脆弱性はトリアージできる数を上回り、トリアージした脆弱性は修正できる数を上回り、そしてすべてを修正しきることはできません。
1. スキャンして発見する
この最初のステップの目標は、発見されたものがすべて一元的に管理できる場所に集約されることです。CVEの発見自体は比較的単純な部分です。1つの非常に網羅的なベンダーを使うにせよ、複数のソースを組み合わせるにせよ、重要な資産すべてが確実にカバーされているようにしてください。
新たに求められる作業は、CVE以外の発見への対応です。スキャンでは、AIが発見した欠陥を含め、CVEカタログの枠を超えた脆弱性データを取り込み、それを他のすべてと同じトリアージ・修正プロセスに乗せる必要があります。CVEしか管理できないツールでは、この新しいクラスの発見事項を見逃してしまいます。幸いなことに、修正・対応のパターン自体は変わりません。CVE以外の脆弱性も、結局はライブラリ、バイナリ、イメージといった、私たちが修正方法を熟知している対象に結びついているからです。
2. 優先順位を付ける
AI以前から、すべての脆弱性を修正できるのは最も成熟したセキュリティ・エンジニアリング組織に限られていました。今では、適切なトリアージがさらに重要になっています。最終的にはすべてを修正すべきSLA上の理由があるかもしれませんが、セキュリティの観点からは、どの脆弱性が実際にビジネスリスクを高めるのかを把握する必要があります。本当に重要なシグナルは3つあり、最初の2つは実環境でのみ測定可能です。
- 使用中かどうか。脆弱なパッケージが実際にメモリに読み込まれ稼働しているのか、それとも単にどこかにインストールされているだけなのか。
- 悪用可能性。ネットワーク経由のアクセスや露出など、何らかの手段で到達可能かどうか。
- 影響度。この資産が侵害された場合、実際にビジネス上の悪影響があるかどうか。
組織運営上のポイントは2つあります。
- この分析によって絞り込まれた短いリストにチームの力を集中させること。
- トリアージを支援するツールを信頼すること。優先度を下げるという判断は能動的な決定であり、チームがそのフィルターを信頼して初めて機能します。
4. 脆弱性が悪用される事態に備える
すべてを修正することはできません。それはリソースの制約による場合もあれば、修正パッチが存在しない場合や、修正によって大量の依存関係が壊れてしまう場合もあります。露出したまま残るすべてのものについて、最後の砦となるのがランタイムです。
幸いなことに、侵入経路がどれほど目新しいものであっても、悪用後の挙動は似通っています。権限昇格、偵察、鍵の窃取といった具合です。攻撃者を捕捉するために、その悪用手法自体を認識する必要はありません。悪用からビジネスへの実害が生じるまでの間こそ、組織を実質的に守れる時間帯なのです。
実践的には次のような取り組みが求められます。
- 侵害の兆候をワークロード上で監視する。データの持ち出し、不審な偵察行動、マルウェアの活動などです。
- どれだけ速く検知できるか、そしてより重要なこととして、どれだけ速く対応できるかを測定し、ボトルネックを見つけます。データ処理が追いついていない、人の目視が追いついていない、あるいは確認すべき対象が多すぎる、といった具合です。これらのボトルネックはいずれも、ツールやプロセスの改善で解決できます。発見件数が多すぎる場合や時間外のカバーが手薄な場合はAIエージェントを活用し、データ・エンリッチメントのパイプラインが遅すぎる場合は対応をデータソースに近づけましょう。
- 実効性のある封じ込めのプレイブックを構築する。何を自律的に実行できるか、何に人の判断が必要かを事前に決めておきます。エスカレーションの経路も定義しておきましょう。
- ビジネス通知プロセスを事前に整備する。チームが破壊的な対応を取る必要が生じてから決めるのではなく、インシデント発生前に用意しておきます。
- 対応の量や求められるスキルがチームの手に余る場合は、外部サービスプロバイダーやエージェント型SOCツールで補強しましょう。
結論
ここで述べてきたことは、決して目新しいものではありません。カバレッジ、トリアージ、量産型の修正パイプライン、そしてすり抜けてきたものへの実効的な計画です。変わったのは、AIによって双方の賭け金が引き上げられたという点です。攻撃者はより多くのものを、より速く発見できるようになりましたが、防御側にも同じツールが用意されており、それを効果的に活用する術を身につける必要があります。発見のスケールが拡大した以上、対応もそれに見合ったものにしなければなりません。
翻訳元: https://webflow.sysdig.com/blog/vulnerability-response-in-the-ai-discovery-era
