AIネイティブなセキュリティプログラムを構築するなら、まず「成果」から始めるべき

AIのロードマップから着手する必要はありません。少人数のチームが手を回せていないセキュリティ業務を一つ選び、そこにAIを適用して、本当に改善するかどうかを確かめることが出発点です。

前回の記事では、セキュリティ運用における品質・一貫性・コスト効率という長年のトレードオフ、「SOCトライアングル」について解説しました。

AIは、この制約を緩和し始めています。人員を比例して増やさなくても、特定の種類の業務をより深く、より一貫して実施できるようになってきたためです。

そこで、セキュリティ責任者から次に必ず聞かれる質問があります。「どこから始めればよいのか」というものです。

リソースに制約のあるチームにとって、この問いは重要です。多くのチームは、優れたセキュリティとはどのようなものかをすでに理解しています。難しいのは、限られた人材、スキル、予算、技術、時間の中で、それを安定して実現することです。

ここにこそ、AIが少人数のセキュリティチームに新たな機会をもたらします。AIは、重要なセキュリティ業務をより速く、より一貫して実施し、希少な専門人材への依存を減らす助けとなります。

まずビジネスが最も必要とするセキュリティ上の成果を見定め、そのうえで、限られたリソースのためにチームが安定して実行できていない業務を洗い出しましょう。

ビジネスが失うわけにいかない成果から始める

AIの適用先を選ぶ前に、組織が顧客へのサービス提供を続けるために依存している、システム、ID、データ、業務プロセスの最小限の集合を特定します。

これはあらゆるセキュリティチームにとって有益な取り組みであり、とりわけ少人数のチームには欠かせません。ビジネスの観点から境界が定まるため、どこに最も注意を払うべきかを判断できるようになります。この境界が明確になれば、セキュリティ上の問いは格段に具体的になります。

それらのシステムにアクセスできるIDはどれか。攻撃を受けている可能性を知らせる検知はどれか。インシデントを調査するにはどのような証拠が必要か。どれだけ迅速に封じ込める必要があるか。重要な業務プロセスを止めかねない露出はどれか。

この作業は、AIの計画を技術カテゴリごとに組み立てがちな傾向を断ち切る助けにもなります。エンドポイント、ID、クラウド、SIEM、脆弱性管理はいずれも、許容可能なリスクの範囲内で事業を継続させるという、同じ大きな目的に貢献しています。

成果の実現を妨げる制約を洗い出す

重要な成果が明確になったら、セキュリティプログラムがそれを安定して実現しにくい理由を検討します。

セキュリティチームと仕事をする中で、同じ制約が繰り返し現れるのを目にします。人員の制約は、調査が追いつかないペースでアラートが積み上がるときに表れます。スキルの制約は、脅威インテリジェンスはあるものの、それを運用に落とし込む専門知識や余力が誰にもないときに顕在化します。お金の制約は、セキュリティデータのコストが上がり続けているのに、可視性がそれに見合って向上しないときに生じます。

時間もまた、独自の失敗パターンを生みます。環境や攻撃者の手法が変化するにつれて、検知ルールは古くなっていきます。技術面の制約により、アナリストは、もともと連携を想定して設計されていないシステム間を手作業で行き来せざるを得ません。組織内の協力も重要です。セキュリティチームは、他のあらゆる事業上の優先事項と、注目やリソースを奪い合っているからです。

これらの問題は、必ずしもセキュリティに関する知識が不足していることを意味しません。プログラムが「やるべきだとわかっていること」と「毎回確実に実行できること」との間にギャップがあることを示しています。

このギャップを埋めるところで、AIが役に立ちます。

継続的に行うべき業務を見つける

適切な出発点を見つける実践的な方法は、継続的に実施したときに最も価値を生むにもかかわらず、現状では定期的に、場当たり的に、あるいはインシデント発生後にしか行われていないセキュリティ活動を探すことです。

セキュリティ態勢管理はその一例です。アプリケーション、ID、クラウドリソース、設定が変わるたびに、露出も変わります。AIを活用した分析なら、ビジネスが依存するシステムを踏まえて、どの露出が最も重要かを継続的に再評価できます。

検知エンジニアリングも同じパターンです。18カ月前には有用なシグナルを出していたルールが、今ではほとんど無害なアクティビティばかりを検知しているかもしれません。ルールの作成時には存在しなかった新たな攻撃手法によって、カバレッジに穴が生じている可能性もあります。検知の精度とカバレッジを継続的に評価すれば、環境ごとに専任の検知エンジニアを置かなくても、改善を日々の運用に組み込めます。

脅威インテリジェンスの有効期間はさらに短くなります。質の高い情報源を購読していても、情報が陳腐化する前に新しいレポートをハンティングへ落とし込むのに苦労するチームは少なくありません。AIは、新しいインテリジェンスの解釈、特定の環境に関係する手法の見極め、対応するハンティングの迅速な実行を支援できます。

アラート調査は、最もわかりやすい例かもしれません。人間のアナリストは通常、エンドポイント、ID、ネットワーク、メール、クラウドのコンテキストを集め、証拠を突き合わせて結論を導き、結果を文書化しなければなりません。少人数のチームが、この作業を数十件、数百件のアラートに対して繰り返すのは持続不可能です。AIは証拠収集と相関分析の大部分を担えるため、アナリストには、調査が完了した状態か、あるいは明確に文書化されたエスカレーション先が手渡されます。

データアーキテクチャの側面もあります。多くの組織は、大量のセキュリティデータを一元的に集約しています。検索可能にする最も簡単な方法が、これまではそれだったからです。フェデレーテッド検索を使えば、エンドポイント、クラウド、IDなどのシステムに、データが存在する場所のまま問い合わせることができます。リソースに制約のある組織では、調査に必要な可視性を維持しつつ、不要なデータ取り込みや保存のコストを抑えられます。

どの機能も、根底にある同じ問題に対処します。重要なセキュリティ業務が、担当者がすべての手順を手作業でこなす時間を確保できるかどうかに左右されなくなり、安定して実行できるようになるのです。

意味のある出発点を選ぶ

次のステップに、全面的な変革は必要ありません。

ビジネスにとって重要な運用上の成果を一つ選び、チームがそれを安定して実現できずにいる制約を特定します。

ユーザーから報告されるフィッシングがアナリストの時間の大部分を占めているなら、アラート調査から始めます。新しいインテリジェンスがチームの対応能力を上回るペースで届き続けているなら、脅威ハンティングから着手します。検知がほとんど見直されないためにアラートの質が低下しているなら、検知の最適化に注力します。可視性のコストが、保存しているデータの価値よりも速く膨らんでいるなら、アーキテクチャ自体をどう変えられるかを検討します。

重要なのは、AIのユースケースを具体的な運用上の課題に結びつけることです。

このやり方なら、導入のガバナンスも利かせやすくなります。AIに許可する作業の範囲、人間の承認が必要な場面、可視化すべき証拠、そして適用範囲を広げる前に何をもって成功とするかを、チームがあらかじめ定義できるからです。

プログラムが実際に改善したかを測定する

AIプログラムは、活動量を数えるだけの取り組みになりがちです。処理したアラート数、生成したクエリ数、作成した要約数などを追跡する形です。

これらの数字が示すのは利用状況にすぎません。セキュリティプログラムが良くなっているかどうかは、CISOにはわかりません。

測定は、成果に立ち返って行うべきです。

アラート調査であれば、調査の質、完了までの時間、エスカレーションの質、アナリストの工数を見ます。検知エンジニアリングなら、誤検知率とカバレッジの推移を測定します。脅威インテリジェンスでは、新しいレポートが、環境に固有の発見事項、あるいは露出がないことの確認になるまでの速さを測ります。態勢管理については、重要な事業運営にとって最も重要な露出を、チームが特定し、対処できているかどうかを確認します。

SOCトライアングルも、有効な確認の物差しになります。品質、一貫性、コスト効率は、そろって向上しているでしょうか。アナリストは、判断力と専門知識を要する業務により多くの時間を割けているでしょうか。組織は、重大なリスクをより速く特定し、対応できているでしょうか。

業務が滞っている場所から始める

リソースに制約のあるチームにとって、AI導入の最初のユースケースは、多くの場合、すぐ目の前に隠れています。

チームが「やるべきだ」とわかっていながら、安定して実行できていないセキュリティ業務を探してください。アラートが調査待ちのまま長く放置されているかもしれません。脅威インテリジェンスが届くペースが速すぎて、誰もハンティングに落とし込めないのかもしれません。チューニングする時間を誰も取れず、検知ルールが手つかずのままになっていることもあるでしょう。継続的な評価が現実的ではなかったために、重要な露出を定期的にしか確認できていないチームもあります。

こうした実行上のギャップを一つ選び、改善すべき成果を定義します。ガードレールを設け、結果を測定し、そこから範囲を広げていきます。

ここでは、リソースの制約がかえって規律を生みます。少人数のチームには、明確な運用上の目的がないままAIを試す余裕はありません。あらゆるユースケースは、セキュリティプログラムが事業を守るやり方をどう改善するかによって、存在意義を示さなければなりません。

AIネイティブなセキュリティプログラムは、技術のロードマップから始まるものではありません。今よりも優れた形で、より速く、より一貫して実施すべき重要なセキュリティ業務を一つ選ぶことから始まります。まずは、そこから着手してください。

翻訳元: https://www.csoonline.com/article/4232574/when-building-an-ai-native-security-program-start-with-outcomes.html

本記事は csoonline.com の記事を翻訳・要約したものです。