triaging-security-alerts

セキュリティアラートのトリアージ

トリアージはセキュリティ業務で最も量が多い仕事ですが、最も語られることの少ない仕事でもあります。その成果は、後から説明できる判定です。多くの場合、侵害の前に出ていたアラートをなぜクローズしたのかと尋ねる人に対して説明することになります。

難しい理由は3つあります。アラートの圧倒的多数はインシデントではないため、毎回、事前確率は不利に働きます。2種類の誤りのコストには大きな非対称性があります。誤ってエスカレーションしたアラートは何時間もの無駄につながり、誤ってクローズしたアラートは侵害につながります。そして、キューには次々とアラートが届くため、1件のアラートに際限なく時間をかけることは、次のアラートにかける時間を奪うことになります。

使用する場面

• SIEM、EDR、またはクラウドセキュリティツールからのアラートキューに対応するとき
• アラートをインシデントとして扱うべきか判断するとき
• 滞留しているアラート、または繰り返し発生する特定のアラートを再検討するとき
• 別のアナリストの判定をレビューするとき
• ノイズの多い検知を調整するか、削除するか判断するとき

使用しない場面

• アラートがすでに悪意のあるものと確認されている場合 — トリアージを終了し、 responding-to-incidents を使用してください。トリアージは対応の開始時点で終わります
• 起点となるアラートがなく、侵害を探している場合 — hunting-threats を使用してください。ハンティングは仮説主導ですが、トリアージはキュー主導です
• ルールを書き換える場合 — engineering-detections または writing-sigma-rules を使用してください。 キューへの対応中にその場で調整するのではなく、トリアージで得た知見をそちらに引き継いでください
• アラートが示したサンプルを分析する場合 — analyzing-malware を使用してください
• 侵害された特定のホストを詳しく調査する場合 — investigating-windows-endpoints または該当するクラウド調査スキルを使用してください

判定は2種類ではなく3種類

よくある失敗は、真か偽かの二分法で考えることです。判定は3種類あり、最後の2つを混同すると検知プログラムが損なわれます。

判定	意味	適切な対応
真陽性	検知は正しく作動し、活動は悪意のあるものだった	インシデント対応にエスカレーションする
良性の真陽性	検知は正しく作動し、活動は許可されたものだった	クローズし、許可された背景を記録する。ルールを調整して取り除いてはいけません
偽陽性	検知ロジックが誤っており、主張する対象に合致していなかった	クローズし、ロジック上の欠陥として検知エンジニアリングに報告する

メモリテストのために管理者が正当に LSASS をダンプした場合、これは良性の真陽性です。ルールは完全に正しく機能しています。これを偽陽性として記録すると、設計どおりに機能しているルールを弱めることになりかねません。1年も経てば、検知プログラムはそうしてひっそりと機能しなくなります。

事前確率は証拠以上に判断を左右する

トリアージでの誤りの大半は、証拠の読み違いではありません。事前確率の見誤りです。

正確性が99％の検知が、実際に侵害されているホストが1台ある環境で10,000台のホストを対象に作動するとします。この場合、およそ100件の誤アラートと1件の真のアラートが発生します。アラートが陽性でも、実際の侵害である可能性は約1％です。正確性が99％であっても変わりません。だからこそ、「ツールがフラグを立てた」というだけではほとんど意味がありません。また、ツールの重大度だけでエスカレーションするアナリストは、ほぼ毎回間違えることになります。

実務上の影響は次のとおりです。

• 重大度はルールの特性であり、アラートの特性ではありません。 検知を作成した人が、あなたの環境が存在する前に設定したものです。
• このシグナルを生み出す別の要因がないか考えてください。 日常的な管理作業、バックアップソフトウェア、または脆弱性スキャナーで説明できるなら、反証が得られるまでは侵害よりもその説明のほうがはるかに可能性が高いでしょう。
• 確証の数は確信の強さに勝ります。 独立した弱いシグナルが2つ同じ方向を示す場合、事後確率は強いシグナルが1つある場合よりも大きく上昇します。それぞれの良性の説明が同時に成り立つことはめったにないためです。
• まれなことはまれです。しかし、まれだからといって無害とは限りません。 目的は事前確率を明示し、証拠によって実際に覆す必要がある状態にすることです。すべてのアラートを理由をつけて退けることではありません。

最も安価に判別できる項目から順に調査する

良性と悪意のある活動を最も低コストで切り分けられる質問から調べます。決まった拡充チェックリストを実行しないでください。

1. この資産は何で、誰が使っていますか？ ドメインコントローラーと開発者のノート PC では、同じ活動でも事前確率は異なります。
2. このホストまたはユーザーにとって、これは通常のことですか？ まず頻度と履歴を確認します。8 か月間毎日実行されていたアクションは、イベントではなくベースラインです。
3. 承認されていましたか？ 変更チケット、メンテナンス時間、デプロイパイプラインを確認します。良性の真陽性の大半はここで解決します。
4. 親プロセスと実行チェーンは何ですか？ アーティファクト自体よりも、由来のほうがはるかに有効な判別材料になります。powershell.exe だけでは意味がありませんが、winword.exe によって起動されたのであれば話は別です。
5. 最後に、外部のレピュテーションを確認します。 ハッシュと IOC の照会は、最初ではなく、最後に行う低コストの手順です。レピュテーションが良好でも標的型活動がない証拠にはなりません。また、レピュテーションが悪くても、上記のローカルコンテキストを確認する必要があります。

いずれかの手順で結論が出たら、そこで調査を止めてください。すべてのアラートで毎回すべての手順を実行していると、キューに圧倒されます。

調査時間の上限設定とエスカレーション

調査を始める前に上限を設定します。通常のアラートなら、一般的には 15 分です。上限に達したら、必ず判断を下さなければなりません。その判断は「調査を続ける」ではありません。

• クローズに十分な根拠がある → 根拠を記録してクローズします。
• エスカレーションに十分な根拠がある → エスカレーションします。
• どちらにも不十分 → それでもエスカレーションします。 時間をかけて調査しても解決しないアラート自体がシグナルです。曖昧だからといってキューに残し続けるのではなく、自分では用意できない追加リソースを投入する理由になります。

次のいずれかに該当する場合は、トリアージを完了する前に直ちにエスカレーションしてください。最重要資産で実行が確認された場合、ドメインコントローラーまたは ID プロバイダーで認証情報へのアクセスが確認された場合、ラテラルムーブメントの証拠がある場合、セキュリティツールが無効化されている場合、バックアップインフラストラクチャに関わるものがある場合です。これらについて、時間をかけて判断を誤るコストは大きすぎます。

クローズするアラートには証拠が必要です

確認したこと、見つかったこと、判断を変える条件を記録します。理由の記載がない処理結果はレビューできません。また、侵害に先立って発生したアラートは必ずレビューされます。

危険な表現は、正直に言えば「侵害を示すテレメトリが収集されていない」とすべきところで、「侵害の証拠は見つからなかった」とすることです。前者は問題を打ち切りますが、後者は可視性のギャップに関する発見であり、engineering-detections に報告すべきものです。

すべての処理結果は、検知エンジニアリングにも情報を還元します。誤検知はロジックの欠陥であり、良性の真陽性が繰り返される場合は、承認済みコンテキストのフィルターが不足しています。また、何か月もノイズしか生成しないルールは、耐え続けるのではなく、効果を測定して削除すべきです。

却下すべき合理化

• 「ツールが重大と判定したのだから、深刻なはずです。」 重大度は、一般的な環境を前提にルールの作成者が設定したものです。実際の基準となる発生率は、あなたの環境固有のものです。
• 「以前に何百回も発生しましたが、いつも何もありませんでした。」 これまで無害だったことは証拠にはなりますが、証明にはなりません。ルールが無視されていると知っている攻撃者は、まさにその手口を使います。今回の事象固有の詳細を確認してください。
• 「ユーザー本人だと言っていました。」 そのアカウントが使われたことは確認できますが、他の誰かがそのアカウントを使っていないことまでは確認できません。侵害されたユーザーも電話に出ます。テレメトリーと照合してください。
• 「自然に止まったので、解決したのです。」 活動が止まるのは、オペレーターが作業を終えた、別の対象に移った、あるいは静かになった場合にも同様に起こります。セキュリティの問題が自然に解決することはありません。
• 「何も見つからなかったので、誤検知です。」 確認していない、または収集されていないテレメトリーに証拠がないことは、誤検知を意味しません。どちらを指しているのか明確にしてください。
• 「既知の誤検知です。」 それなら、調整するかフィルタリングすべきです。それでも発生し続けるなら、調整が不足しているか、実際には無害な真陽性が誤って分類されているかのどちらかです。どちらも対応が必要であり、単なる判定では済みません。
• 「確信が持てるまで調査を続けます。」 確信は得られるものではなく、キューには次の事象が届き続けます。時間を区切り、曖昧さが残る場合はエスカレーションしてください。
• 「無害な事象をエスカレーションすると、不注意に見えます。」 曖昧な事象をエスカレーションするのは、システムが正しく機能している証拠です。曖昧さを黙って解消したことこそ、インシデント後のレビューで問題になります。

外部ソースの確認

公開されているアドバイザリー、仕様書、ベンダーレポートをMarkdownとして取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの定型部分が取り除かれ、文章主体のページではトークン数を約78％削減できます。また、要約ではなく全文が返されるため、grepで検索でき、検索結果に何もない場合も信頼できます。

この方法に適さないケースが3つあります。JSONやAPIの応答は、生データのまま取得してください。可読性の抽出処理で構造化データが崩れるためです。認証が必要なページやJavaScriptで描画されるページは、直接取得してください。匿名で取得されるためです。また、攻撃者のインフラ（フィッシングリンク、C2、マルウェアのホスティング先）、クライアント所有のホスト、エンゲージメントURLを経由させてはいけません。リクエストはあなたのマシンから第三者へ送信され、稼働中の攻撃者インフラの場合は、オペレーターに気付かれるおそれもあります。

サイトによっては抽出ツールをブロックし、ページではなくエラーの内容を返すことがあります。たとえば、freedesktop.orgからは{"error":"Failed to fetch: 418 I'm a teapot"}が返されることがあります。これは取得が拒否されたのであって、対象が存在しないとソースが示しているのではありません。そこから結論を導く前に、URLを直接再取得してください。

参考資料

• responding-to-incidents — 真陽性の次の対応先
• engineering-detections — 誤検知と調整漏れの報告先
• hunting-threats — キュー主導のトリアージに対する、仮説主導のアプローチ
• investigating-windows-endpoints — トリアージでエスカレーションされた後の、詳細なホスト分析