SIEM拡張：全面刷新なしにSIEMの経済性を立て直す方法
ほとんどのセキュリティチームは、今年SIEMを入れ替えることはできません。契約は18か月残っており、コンプライアンス監査人は四半期報告がどのシステムから出ているかを正確に把握しています。検知コンテンツには何年ものチューニングが積み重なっており、ゼロから作り直したいと考える人はいません。その一方で、クラウド、SaaS、アイデンティティのログ量が当初の予算の想定を上回る勢いで増え、取り込みの請求額は四半期ごとに膨らんでいきます。そうした状況に置かれたチームが最終的に検討することになるのが、SIEM拡張です。
考え方は単純です。プラットフォームを引き剥がすのではなく、その周囲に機能を足し、特定のワークロードをそこから移します。SIEMが本当に得意とすることには引き続き任せ、コストと検知の問題は別の場所で解決するという発想です。
SIEM拡張とは実際に何を指すのか
SIEM拡張とは、既存のSIEMを置き換えるのではなく、その周囲に追加の処理、相関分析、トリアージの機能を重ねる進め方です。プラットフォームは、コンプライアンスの証跡と長期保持のための記録システムとしてそのまま残ります。大量のテレメトリの正規化、ドメインを横断する相関分析、一次のアラートトリアージといった、SIEMが不得手な作業は第二の層が引き受けます。
これはSIEMの置き換えプロジェクトとは異なります。置き換えでは、プラットフォームを完全に廃止し、その検知コンテンツ、連携、保持義務を新しい基盤へ移行することが目的になります。拡張はあえて野心を抑えたやり方です。取り除かないと決めた制約の周りを最適化していくことになります。
この区別が重要なのは、二つの道筋でリスクの性質が異なるからです。置き換えは、移行のあいだ検知カバレッジと監査の連続性を危険にさらします。拡張はそのどちらも保ったままであり、足した層が期待に届かなければ、たいていは元に戻せます。
置き換えではなく拡張が選ばれる理由
最も多い動機はコストです。SIEMの価格は一般にデータ量か秒あたりのイベント数に連動しており、多くの環境で最も急速に増えているログソースは、シグナル密度が最も低いものです。クラウドのコントロールプレーンのログ、SaaSの監査証跡、エンドポイントのテレメトリはいずれも膨大な量を生み出しますが、その大半のイベントは検知に寄与することがありません。
二つ目の動機は契約のタイミングです。更新サイクルが、プラットフォームは機能していないとチームが判断した時点と重なることはめったにありません。そのため、問題を認識してから手を打てるようになるまでに、一年以上の空白が生じることも珍しくありません。拡張は、ただ待つのではなく、その空白を生産的に埋めます。
三つ目の動機は検知の質であり、チームが過小評価しがちなのがこれです。ルールベースの相関分析は、文脈の中でしか不審にならない振る舞いを苦手とします。SIEMの出力の多くが、アナリストが判断を下す前に手作業での補強を必要とする確度の低いアラートとして届くのは、そのためです。
SIEMの支出が集中しやすいところ：
- クラウドのコントロールプレーンやSaaSの監査ログのような、大量かつ低シグナルなソースの取り込みとインデックス化
- 実際の調査の実態が求める以上に長く保持されているホットティアのデータ
- プラットフォームが自力で解決できなかったアラートを、アナリストが手作業で補強するために費やす時間
- ログ形式やAPIが変わるたびに壊れるルールを保守するディテクションエンジニアリングの工数
コンピュータセキュリティログ管理に関するNISTのガイドは、ログ管理とセキュリティ分析が、それぞれ異なる要件を持つ別個の機能であると指摘しています。多くのSIEM導入はこの二つを一つのシステムに押し込め、ストレージ層の仕事に分析層の価格を払っています。
何を移し、何を残すかを決める
どのログソースも移せばよいというものではなく、誤ったものを移せば、削減額を上回るコンプライアンス上の問題を招きます。現実的な手順は次のとおりです。
- ソースを量と検知への寄与度で棚卸しし、過去一年間に各ソースが実際にどれだけのアラートと確定インシデントを生んだかを測ります。
- 量が多く、検知への寄与がほぼゼロのソースを特定します。これが移行の候補であり、多くの環境ではクラウドとSaaSのテレメトリがそれにあたります。
- 候補ごとに保持義務を確認します。コンプライアンスのフレームワーク、規制要件、契約上の約束に名指しされているものは、SIEMのホットティアである必要はないにせよ、到達可能な状態に保ちます。
- 移行候補は、調査と脅威ハンティングのためにクエリ可能な状態を保てる低コストの層へ振り向け、アラートと補強済みのイベントだけをSIEMに戻します。
- SIEMはレポートと証跡の層として残します。これにより、SIEMのコンプライアンスワークフローと監査証跡は、これまでと変わらず機能し続けます。
この手順の結果として、取り込み量の大きな割合が外に出る一方で、SIEMはレポートにおける役割を保ちます。多くのチームはこの一手だけでログ保存コストの目に見える削減を経験しており、Exaforceのお客様からは、どのデータをどこに置くかを再構成した結果、ログ保存コストが約90%削減されたという報告もあります。
ログ管理とSIEMは目的が異なるという点は押さえておく必要があります。その境界を理解していることが、移行の判断を監査人に対して説明できるものにします。
検知の質という、もう半分の問題
コスト削減だけでは、確度の低いアラートに溺れているSOCは救えません。SIEM拡張がデータを移すだけに終われば、同じ運用上の問題が安くなっただけ、という結果になります。
より厄介なのは、SIEMの脅威検知が、既知のパターンに対してあらかじめ書かれた相関ルールに依存している点です。MITRE ATT&CKのようなフレームワークが記述する攻撃者の振る舞いは、正規の認証情報や許可されたツールを使うことが多く、個々のイベントは正常に見え、不審なのは順序だけということになります。ルールでその一部は捉えられますが、データソースが増えるたびにチューニングの負担は膨らみます。
SIEM拡張が本領を発揮するのはここです。アイデンティティ、クラウド、SaaS、エンドポイントのデータを同時に横断する相関分析は、単一ドメインのルールでは解けないアラートを解決できます。また、一次トリアージの自動化により、定型的な案件は人に届く前に完結します。Exaforceを含め、この用途に作られたプラットフォームはルールだけに頼らず複数種類のモデルを適用します。静的なルールであれば見落とすか、無差別に検出してしまうようなイベントに対して、一貫した判断を下せるのはそのためです。
運用上の効果はアナリストの時間に表れます。Verizonのデータ漏洩・侵害調査報告書（DBIR）は、侵害の大きな割合に人的要因が関わっていることを一貫して示しています。そうした事案を捉えるのに最も適した位置にいるのは、アナリストがキューのノイズ処理に日々を費やしていないチームです。誤検知の量を減らすことは、チームが何に目を向けられるかを変えます。
拡張が効いているかをどう見極めるか
何かを変える前にベースラインを取っておきます。SIEM拡張に賛成するにせよ反対するにせよ、次の予算サイクルではその議論が数字でなされるからです。
月ごとの取り込み量とコスト、アナリストに届くアラート量、人手を介さずに完了したアラートの割合、そして調査までの平均時間を追跡します。最初の二つは下がるはずです。三つ目は上がるはずです。四つ目は、足した層が本当に仕事を解決しているのか、単に場所を移しただけなのかを教えてくれる指標であり、より広いSOCの指標とKPIと併せて見ておく価値があります。
検知カバレッジは対照として見ておきます。データを移したことで確定インシデントの検出数が減ったのであれば、移しすぎであり、いくつかのソースを戻す必要があります。量が減ったのだから問題ないと決めつけず、90日の時点で意識的にこの確認を行ってください。
SIEMのレポートについて一点注意があります。データの置き場所を変えれば、定期レポートや監査クエリに下流で影響が出ます。変更後の最初の監査サイクルの最中ではなく、その前に、コンプライアンスレポートが従来と同じ出力を生むことを検証してください。
ここから何が見えてくるか
SIEM拡張は、全面的な置き換えにともなう移行リスクを引き受けることなく、自分たちで制御できる時間軸でコストと検知の質に手を打つ方法です。これが成り立つのは、SIEMが本当に得意とする二つのこと、すなわち証跡の保持とコンプライアンスレポートが、高コストで不完全にこなしている部分と切り分けられるからです。
多くのチームにとって率直な見立ては、SIEM拡張は時間を買い、支出を抑える一方で、長期的なプラットフォームの問いは開いたままになる、というものです。結局はSIEMを置き換えるチームもありますが、その判断に至る頃には、自分たちに本当に必要なものについてはるかに良いデータを持っています。拡張したアーキテクチャが十分に安定し、置き換えが急ぎではなくなるチームもあります。
取り込みコストがセキュリティ予算より速く増えており、アナリストが調査よりもアラートの補強に時間を費やしているのであれば、次の更新交渉が始まる前に、拡張の層が何を変えるのかを評価する頃合いかもしれません。