フォローする すべての検出チームはこの瞬間を知っています。ルールが書かれたりダウンロードされたりして、レビューされ、SIEMのクエリ言語に翻訳され、配置されます。ステータスには有効と表示され、ルール数が増加し、カバレッジレポートは少し緑が増えます。
それはそのルールが書かれた攻撃を検出するかどうかを教えてくれるものではありません。ロジック、データ、または翻訳が現実と静かに食い違っているため、非常によく書かれていても何も見つからないことがあります。そして、全く発報しないルールは、捕まえるべきものが何もないルールと見た目が同じであるため、問題は長い間隠されたままである可能性があります。
この記事では、動作するルールと壊れたルールを区別するもの、ルールが誤る原因、SOC Primeでルールが出荷される前に動作することを証明し、その後も動作し続けるためにできることを説明します。
「動作する」とは実際に何を意味するのか
動作する検出ルールは3つのことを行います。それは、ターゲットとなる行動に対して正しいロジックを表現し、実際にその行動を含むデータ上で動作し、実行するプラットフォームに対して正しく書かれています。これらのうち1つでも失敗すると、ルールは壊れており、たとえ有効化されエラーが発生しなくても意味がありません。
このフレーム作りは役立ちます、なぜならそれぞれの失敗には異なる原因と修正が存在するからです：
- ロジックの問題 自身の中に住んでいます。それは行動の変動を捉えるには狭すぎるか、通常の活動に一致してしまうほど広すぎます。
- データの問題 環境に存在します。ルールが必要とするイベントのログが記録されていない、収集されていない、またはフィールドが欠けている。
- 翻訳の問題 言語間の移動に存在します。ルールがプラットフォームのクエリ構文に変換されたときに意味が変わります。
ほとんどのチームはルールを書くときに最初のものを注意深くチェックします。2番目と3番目のルールが誰にも気づかれずに壊れる傾向があります。
どこで動作するルールが間違うか
行動に合わないロジックです。 ツールのファイル名のみに基づいたルールは、ファイルをリネームするだけで簡単に回避できます。一方、共通のコマンドラインパターンに基づいたルールでフィルタリングがない場合、管理者に一日中一致するかもしれません。どちらのミステイクも配置時には見えません。最初のものは攻撃者がそれを通り過ぎる時に、2番目は警告ノイズとして現れます。
存在しないデータ。 コマンドライン引数に依存するプロセス生成ルールは、コマンドラインのロギングが有効化されていない場合、引数がフィールドとして到着しないため無意味です。同様にログソースがオンボードされていなかったり、エージェントが送信を停止していたりする場合も同様です。このルールは予定通り実行され、何も見つからず、健康に見えます。
異なる場所で異なる意味を持つフィールド。 同じ概念が製品間で異なる名前を持つことがあり、異なるベンダーのデータモデルもまた独立した契約です。Splunk CIMおよびMicrosoft Sentinel ASIMがこの良い例です：あるフィールドは一方に存在して他方には存在しません。文字ごとのポートは、目的地が絶対に満たさないフィールドを参照するルールを生成します。
意味が変わる翻訳。 自動翻訳機は簡単な選択ロジックをうまく処理しますが、コレレーションルールや独自の関数は通常人間のレビューが必要です。プラットフォームはまた、大文字小文字の区別、ワイルドカード、正規表現などの詳細の取り扱いが異なります。ルールは「成功」に翻訳されても、元の動作と異なる場合があります。
良いルールを退場させるプラットフォームの制限。 SIEMは実行できるルールの数を制限しています。チームは通常、新しいもののために有効なルールを無効にし、誰もそれを決定しないまま範囲が縮小します。
なぜそれが重要なのか
これらの問題の一つ一つがルール数とダッシュボードを変更せずに残します。したがって、配備されたルールを数えるカバレッジ数値は保護を過大評価し、そのギャップは通常事件時に表面化し、発報すべきルールが一度も発生できなかったことを誰かが発見します。
他にも二次的なコストがあります：静かなルールは曖昧です。何も発生しない場合、環境が綺麗だからなのか、テレメトリが欠けているのか、ロジックが間違っているのか？その後でそれを解決するには、論理、データ、および翻訳を順番にチェックする必要があります。早期に証拠を集め、それを最新の状態に保つ方がはるかに安価です。
SOC Primeがルールが機能することを証明するのにどのように役立つか
検出検証は実際に一連の質問です：このルールには何が必要か、私の環境がそれを提供しているか、そのルールが私のデータで予想通りに動作するか、もしそうでなければ何を変更すべきか？SOC Primeは各ステップをサポートします。
検出要件を理解する
検証は何らかのテストの前に始まります。SOC Primeは、ルールが狙った行動、テレメトリの要件、MITRE ATT&CKのマッピング、潜在的な偽陽性など、検出コンテンツに関する文脈情報を提供します。これにより、検出エンジニアは検出が彼らの環境に適用されるかどうかを判断するための出発点を得るとともに、テストする前に必要な前提条件を確認することができます。たとえば、コマンドラインのロギングが必要なルールであれば、そうであることを事前に教えてくれるのです。
利用可能なテレメトリを評価する
ルールに何が必要かを知ったら、次の質問はそれを持っているかどうかです。Prime Huntは、利用可能なデータと潜在的な検出範囲の関係を評価するのをチームが支援することができます。データ監査は、利用可能なログデータを分析し、それをMITRE ATT&CKにマッピングして潜在的な可視性のギャップを識別します。これにより、検出範囲の欠如がテレメトリが欠けていることから来ているのか、検出コンテンツが不足していることから来ているのかを判断し、それらは非常に異なる問題であり、それぞれに異なる解決策が必要であることを示します。
組織のデータに対して検出をテストする
Prime Huntは、接続された環境からのデータに対して検出スキャンを実行することもできます。実際のデータに対して検出をテストすることにより、理論的な検証だけでなく、実際の環境でのコンテンツの振る舞いの証拠を得ることができます。スキャン結果は、関連する一致を生成する検出を特定し、さらなる調査や調整が必要なものを強調します。
検出ロジックを調査し改善する
検出の修正が必要な場合、SOC PrimeはPrime CoreおよびPrime Architectを通じて検出エンジニアリング能力を提供します。検出コンテンツは、レビュー、カスタマイズ、翻訳、およびターゲット環境に最適化されることができます。これにより、スキーマ、フィールドマッピング、クエリ言語、および環境固有の要件の違いに対応し、すべての問題のある検出を新しい開発タスクとして扱うことなく対処できます。
実際には、それは次のことを意味します：
- 実行するプラットフォーム用に翻訳します。 プラットフォーム上のすべてのSigmaルールは、すでにすべてのサポートされているSIEM言語とフォーマットに翻訳されているため、スタック用のクエリをすぐに取得して展開することができます。何かカスタムのものや独自のSigmaルールについては、Prime ArchitectのTranslationワークスペースを使用して、SIEM、EDR、XDR、データレイクのネイティブクエリ言語に変換してください。Sigmaはソースであるため、一度の変更で再度翻訳され、各プラットフォームで手動で編集されることはありません。
- テーブル、フィールド、値をスキーマにマッピングします。 カスタムフィールドマッピングを使用して、標準外のテーブル、フィールド、値をデフォルトにマッピングするプロファイルを定義します。プロファイルを一度作成し、その後ルールを展開するたびに適用してください。
- 環境に適合するフィルタを追加します。 フィルタは、特定のユーザー、ホスト、または他のアイテムのセットを含めたり除外したりするために検出ロジックに条件を追加します。既知の無害な活動が良いルールを騒がしくさせることを防ぎますが、ルール自体を書き換えることはありません。
- 展開設定をプリセットとして保存します。 プリセットは、クエリ期間、優先度、ルールステータスなどのパラメータを保存し、展開を一貫して行えるようにします。
- 検証、最適化、微調整を行います。 Translationワークスペースも検出コンテンツを検証し、最適化します。これではレビューの代わりにはなりません：送信先スキーマに対してすべてのフィールドを確認し、特に相関ロジックやプラットフォーム固有の関数については、フラグが立てられたものを注意深く見ます。マッピングやフィルタを超える変更がある場合は、コードを直接編集し、再翻訳してカスタムリポジトリに更新または新しいルールとして保存します。
- AI支援のワークスペースでリサーチと調整を行います。 ルールがターゲットとする行動を調査し、そのロジックに対する変更を実行するために使用します。エンジニアは管理を行い、出荷の前にすべての変更をレビューします。
カバレッジギャップを特定する
検出検証は、何が検出されていないかを答えるべきでもあります。Prime Huntのデータ監査は、利用可能なテレメトリと検出コンテンツの両方に基づいたカバレッジ分析を提供します。これにより、可視性の不足によって引き起こされたギャップと、欠落または不適切な検出ルールによって引き起こされたギャップを区別するのをチームが支援します。その区別は次のエンジニアリングアクションに情報を提供します：より多くのデータを収集する、既存の検出を調整する、または追加の検出コンテンツを特定し開発する。
時間をかけて検証し続ける
検出の効果は、環境や検出コンテンツが進化するにつれて変化します。Prime Huntを用いた定期的な検証により、初期の検証結果に頼るのではなく、現在のデータに対して検出を再評価することができます。これは、ロギング構成、データスキーマ、インフラストラクチャ、または検出コンテンツが頻繁に変化する環境で最も重要です。
仮定よりも証拠を
配備されたルールは主張です。実際のデータでテスト済みのルールは証拠です。違いを見逃しやすいのは、どちらもルールリストで同じように見え、攻撃が到着するまでは静かだからです。
SOC Primeはそのギャップを埋めるのに役立ちます。それは、明確な検出要件と利用可能なテレメトリーの正直な評価から始まり、あなた自身のデータに対して検出をテストし、適合しないものを修正するためのツールを提供します。カバレッジ分析は、残りのギャップがさらなるデータ、新しい調整、または新しいコンテンツを必要としているのかを示し、定期的な検証により、環境が変化するにつれて回答を最新のものに保ちます。まずは最も重要なルールから始め、どれが本当に発報するのかを見つけ出してください。
