ノイズを 90% 削る — エージェント駆動のセキュリティオペレーション
これまで関わったセキュリティオペレーションチームには例外なく同じボトルネックがあり、それは検知の カバレッジではありません。キューが 1 日に生む指摘の数が、チームが意見を形成できる数を超えている ことです。結果としてトリアージは、タイトル欄のパターンマッチングへ劣化していきます。
既定の対応は 2 つあります。アナリストをもう 1 人雇うか、量が人員に収まるまで検知をチューニングするか。
前者は高コストで一時的です。後者はもっと注意に値します。それが実際に何をしている行為かというと、 可視性を人員数から決めるという決定です。誰もそう書き残しません。抑制ルール 1 件ずつ、変更チケット の中で起きます。そして止めた検知こそが、後で問われる検知になります。
ある案件では、Amazon GuardDuty とお客様のサードパーティ監視 SaaS にエージェントを接続することで、 L1 の指摘トリアージと優先度付けを完全に取り除きました。
この数字はこの記事の簡単な部分です。議論に値するのはその下の設計で、同じアーキテクチャの素朴版は 本当に危険だからです。
L1 は人員問題に見える。だから直らない
人員問題には既知の対処法があり、既知の対処法に手を伸ばすと前進した感覚が得られます。そこが罠です。
指摘が対処可能かどうかを決めるのは、ほぼ指摘そのものではありません。別の場所にある文脈です。この リソースが何なのか、誰が所有しているのか、本番かどうか、そのワークロードにとって当該挙動が正常かどうか、 同じ 1 時間内の他の 3 件と相関しているか、変更作業ウィンドウが開いているか。
L1 アナリストはシフトの大半を、複数のコンソールを横断してその文脈を手で運ぶことに使い、そのあとで、 文脈がすでにほぼ決めてしまっている判断を下します。
そう見えた瞬間に、自動化すべき対象が変わります。自動化するのはアナリストの意見ではありません。輸送です。
「何について誤ってよいか」で分ける 3 層
機能した設計は、多くのチームが一体で出荷する 3 つを分離しています。分離の軸は能力ではありません。 許される誤りです。
エージェントは補強と相関を行う。 文脈を集め、所有者やタグを引き、関連する指摘を探し、リソース自身の 語彙で何が起きたかを記述します。これは調査であり、調査は誤りに耐えます。エージェントの要約が 90% 正しければ、それを読むアナリストは 30 分前進した状態から始められます。ここで非決定性が許容できる理由は 一つだけです。何も決定していないから。
対処判断は決定論的なルールが所有する。 抑制・エスカレーション・ルーティングは、補強済みレコードに 対して評価されるルールが決めます。モデルではありません。ここが荷重を支える判断なので、再現可能で、 レビュー可能で、「なぜこの指摘は閉じられたのか」と問う人に説明できる必要があります。「なぜ抑制された のか」にルールを指して答えられないなら、それは指摘を丁寧に失うシステムです。
人間はエスカレーションとルールセットを所有する。 チームの仕事は 1 段上がります。意味のある 10% と、 残りの 90% を生んだルールの所有権です。
この後半こそ皆が飛ばす部分で、あれば良いという話ではありません。安全機構の全体です。これがなければ、 自社のロゴが付いた無人の分類器を運用していることになります。
90% の正確な意味
言葉に慎重なのは、この主張が誇張しやすく、実際に誇張されているのを聞いたことがあるからです。
指摘の 90% が誤検知だったという意味ではありません。検知の 90% を削除したという意味でもありません。
指摘の 90% が、対処判断に人を必要としなくなったという意味です。補強と決定論的ルールがそこに到達 するからです。それらの指摘は依然として存在し、記録され、クエリできます。変わったのは、注意力を消費 しなくなったことだけです。
この区別が、自動化プログラムと「時限式の障害」を分けるすべてです。6 か月後、誰かが特定の指摘について なぜ自動クローズされたのかを訊きます。答えを再構成できないなら、ノイズを削減したのではなく隠したの です。そしてそれが分かるのは、最悪の日です。
名前を付けておくべき失敗パターン
何を支払うのか
ルールセットには所有者が必要で、その所有者はシニアです。工数をシフト表からバックログへ移したことに なります。置き場所としては良くなりましたが、無料ではありません。しかも今後は、キャパシティを計画する 人の目に見える形で存在します。
新しい依存関係も引き受けます。補強レイヤーが劣化すると、決定論的ルールはより薄いレコードに対して評価 されます。完全なレコードでは正しかったルールが、部分レコードでは誤ります。この失敗は計測していなければ 静かです。フェイルクローズにしてください — 不完全なレコードは解決ではなくエスカレーションへ回す。つまり 最も余力のない日に、あなたの 10% は増えます。
そして、これは一定の流量を超えなければ元が取れません。1 日数百件を下回るなら、ルールセットの維持費が 置き換えるトリアージを上回り、表計算と有能なアナリスト 1 名が勝ちます。私は表計算を勧めたことがあります。
機能しているかの見分け方
兆候は 2 つあり、どちらもノイズの数値ではありません。
1 つ目は、エスカレーションキューが難しくなることです。アナリストに届く 10% に自明な作業が残って いるなら、ルールは仕事をしておらず、数値がこちらを甘やかしています。
2 つ目は、ルール変更がエンジニアではなくアナリストから出てくることです。それが内側から見た所有権の姿で、 この設計が最初の 1 年を生き延びる唯一の形です。
この領域で作り続けている理由
この仕事が、私がメンテナンスしているオープンソースの形を決めています。
Secrust が存在するのは、本当のシグナルが相関 — 同一プリンシパルに対する多数の失敗のあとの 成功 — に宿り、そこでは個々のイベントが疑わしくないからです。Watari が存在するのは、意味の ある 10% に絞り込んだあと、その周辺のケース管理がスタックの高コスト部分であってはならないからです。
どちらも OCSF を土台にしています。理由は上記の補強レイヤーが成立する理由と同じで、単一スキーマが自動的な 文脈組み立てを扱いやすくするからです。ソースごとの独自パーサーは、この種のプログラムが死ぬ経路です。 難しい技術課題によってではなく、チームより速く成長する統合面によって。