脅威インテリジェンス＋SIGMAから始めるDetection Engineering

「2025年 TMCIT × 大和セキュリティ DFIR忍者チャレンジ」で実施させていただいた講演資料です。

Transcript

1. 脅威インテリジェンス + SIGMAから始める Detection Engineering 2025.02.23 Tomohisa Ishikawa, Ph.D., CISSP, CSSLP, CCSP, CISA, CISM, PMP scientia.admin@gmail.com @scientia_sec 2025年 TMCIT × 大和セキュリティ DFIR忍者チャレンジ
2. 自己紹介 1 所属: 東京海上ホールディングス株式会社 IT企画部 リスク管理グループ Lead Cyber Security Architect 専門： グローバルセキュリティ戦略・不正アクセス技術・インシデント対応・ セキュリティ運用・グローバルセキュリティ戦略 etc. 資格： 博士（工学）, CISSP, CSSLP, CCSP, CISA, CISM, CDPSE, PMP etc. 経歴： 2009.04 – 2019.03：某セキュリティ企業 侵入テスト・インシデント対応・脆弱性管理・セキュア開発・セキュリティ教育 etc. 2019.04 – 現在 ：東京海上ホールディングス株式会社 グローバルセキュリティ戦略・セキュリティアーキテクチャの検討/推進・ 国内外グループ企業のセキュリティ支援・CSIRT運用・脅威インテリジェンス分析 etc. 対外活動： （抜粋） 講演・講師： • FIRSTCON23 Speaker（2023） • セキュリティ・キャンプ 全国大会 講師（2023～） • Global Security Camp Instructor（2024～） • JSAC2025 Workshop Speaker (2025) 委員会活動： • IPA 情報処理技術者試験委員・情報処理安全確保支援士試験委員（2018～） • IPA 「10大脅威執筆者会」メンバー（2010～2014, 2019～） • 総務省サイバーセキュリティエキスパート（2024～） 執筆・翻訳・監訳： • 複数の本を執筆・翻訳・監訳しています。 調査・研究： • CSS（情報処理学会）、SCIS（電子情報通信学会）で研究発表をしています。 石川 朝久 Tomohisa Ishikawa
4. Copyright © Tomohisa Ishikawa All rights reserved. 本日お伝えしたいこと 3 テーマ：Detection Engineering • Detection Engineeringの理論的概念を説明とするとともに、脅威インテリジェンスがどのよう に関連するか、またSIGMAを取り上げつつDetection as Codeがどのような役割を持つか 説明していきます。 アジェンダ： • Part I ：理論編（What is Detection Engineering?） – Detection Engineeringの定義や特徴、Detection Engineeringプロセス、関連する概念を説明します。 – その上で、脅威インテリジェンスがどのように役立つのかその内容を説明します。 • Part II ：実務編（ What is “Detection as Code”?） – SIGMAを例に取り上げながら、どのようにSIMGAを記述するか、その利活用方法について説明します。 • Part III ：応用編（What is “Good” Detection Engineering?） – 良いDetection Engineeringを実現するために必要な＆アプローチを示します。
5. Part I：理論編 4
6. Copyright © Tomohisa Ishikawa All rights reserved. 1-1：Detection Engineeringとは？ 5 • Detection Engineeringとは？ • “ソフトウェアエンジニアリングの概念を適用し、潜在的な脅威を検知するための検知ルールの 設計・構築・テスト・改善・管理を行うアジャイル開発プロセス” • “特定されたDetection Gapを埋めるための体系的アプローチ” < Detection Gapとは？> 参考: TaHiTI Threat Hunting Methodology
7. Copyright © Tomohisa Ishikawa All rights reserved. • Detection Gapを特定する施策として、以下の３種類がある。 – Cyber Threat Intel ：最新の攻撃手法を特定する手法 – Red/Purple Teaming ：既知の攻撃手法における予防・検知能力を特定する手法 – Threat Hunting ：既存のセキュリティセンサーで検知できない未知の脅威を特定する手法 • Detection Engineeringは、特定されたDetection Gapを埋めるための体系的アプローチ 1-1：Detection Engineeringとは？ 6 参考: TaHiTI Threat Hunting Methodology Threat Huntingの目的 Red/Purple Teamingの目的 Cyber Threat Intelの目的
8. Copyright © Tomohisa Ishikawa All rights reserved. 1-1：Detection Engineeringとは？ 7 • “Detection Engineering”の特徴 – #1 : Detection as Code • 検知ルールをコードして、利用・管理する (YARA, SIGMA etc.) → 詳しくは、「Part II：実務編」で解説します。 – #2 : ソフトウェア工学の応用 • 「ソフトウェアの開発、運用、保守に体系的かつ規律ある、定量化可能なアプローチを適用する」 （Software Engineering Definition by IEEE） • Detection Engineeringの評価と管理にメトリクスを使用する → 詳しくは、「Part III：応用編」で解説します。 – #3 :「アジャイル」アプローチ • 小さく始めて、継続的に改善する
9. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 8 DR-DLC：Detection & Response Development Life Cycle – Forrester社Principal AnalystであるAllie Mellenによる提案されたモデル https://www.forrester.com/blogs/announcing-the-detection-and-response-development-lifecycle-dr-dlc-for-detection-engineering/
10. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 9 DR-DLC：Detection & Response Development Life Cycle Monitor Run Deliver Release Test Build Define Discover フェーズ 概要 Discover 作成・改善すべき検知ルールの特定する。 Define 検知ルールの要件定義を行う。 Build 要件定義に従い、検知ルールを作成する。 Test 検知ルールが想定どおり検知を実現できるか、テストを行う。 Release 作成した検知ルールをレビュー・承認する。 Deliver 必要な文書化を行い、管理・再利用に向けて適切なリポジトリへ格納する。 Run 検知ルールを本番環境へ展開し、実行する。 Monitor KPIや継続的検証に基づいて、検知の精度・品質を管理する。 ＜DR-DLCの各フェーズ＞
11. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 10 Phase 1 – Discover • 作成・改善すべき検知ルールの特定する。大きく４種類のリクエストパスが存在する Request from… リクエスト概要 CTIアナリスト • 脅威インテリジェンスをもとに、新しい脅威へ対抗する SOCアナリスト • サイバー攻撃の最前線にいるSOCアナリストが持つ知見を反映させる • Purple Teamingおよびthreat huntingの結果に基づいて、改善を行う。 セキュリティポリシー • ビジネスおよびセキュリティポリシーにより、環境を保護するための追加の管理が必要 • 例）特定のサービスの禁止 “Monitor”フェーズ • “Monitor”フェーズは、検知ルールの品質を評価するフェーズである。 • その評価に基づいて、更なる検知すべきルールを特定する。 ＜４種類のリクエストパス＞ Monitor Run Deliver Release Test Build Define Discover
12. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 11 Phase 2 – Define • “Discover”フェーズに基づき、検知ルールの要件定義を行う。 • ２種類の活動が必要となる。 Monitor Run Deliver Release Test Build Define Discover 項目 詳細 Requester 検知ルール作成を依頼する担当者 Evidence 検知ルール作成の根拠となるCTIあるいはログデータ Scope 検知ルールの適用範囲を定義（範囲、適用期間 etc.） Contents 検知ルールの技術的詳細を定義 Utility / Urgency 当該検知ルールを作成する必要がある理由 Exception （誤検知防止のための）検知ルールの例外を記載 観点 詳細 深刻度 ルールがない場合、この要件は 重大な影響をもたらしますか？ 整合性 検知要件は、各脅威グループの 攻撃対象、意図、能力と、組織の プロファイルを一致するか？ カバレッジ 当該要件は、Detection Gapに 基づき、組織の検知カバレッジを 向上できるか？ Step 1 : 要件定義 Step 2 : トリアージ
13. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 12 Phase 3 – Build • “Define”フェーズに基づき、 要件定義を満たす検知ルールを作成する。 • 3-1 : 設計 – (A) 調査 • どんなログソースが必要か？ • どのような検知ロジックが必要か？ • 検知ロジックにどのような条件が必要か？ – (B) 技術仕様の記述 – (C) テストの検証基準の作成 • 3-2 : 開発 – 設計プロセスに基づき、検知ルールを記述する。 • SIGMA • YARA Monitor Run Deliver Release Test Build Define Discover
14. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 13 Phase 4 – Test • “Build”フェーズで作成された検知コードが、期待通りに機能しているかどうかをテストする • “Test”フェーズの目的 – 検知コードが要件定義に沿って適切に実装され、期待される動作と結果を返すことを確認する • ２種類のテストデータを作成する – Known Bad ：偽陰性（false negative）がないことを確認 – Known Good ：偽陽性（false positive）がないことを確認 Monitor Run Deliver Release Test Build Define Discover
15. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 14 Phase 5 – Release • 作成した検知ルールをレビュー・承認する。 Phase 6 – Deliver • 必要な文書化を行い、管理・再利用に向けて適切なリポジトリへ格納する。 Detection Engineeringのベストプラクティスでは、CI/CDパイプラインの使用が推奨されている Monitor Run Deliver Release Test Build Define Discover GitHub Actions Detection Engineer GitHub Amazon OpenSearch (SIEM) 検知コードを コミット コミットされたコードを テスト・変換する SIEMにクエリを送信する ためAPIを実行 ＜ CI/CD パイプラインのサンプルワークフロー＞
16. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 15 Phase 7 – Run • 本番環境で検知ルールを実行する。 • 「Deployment Tag」を使用して検知ルールの信頼性を示し、SOCアナリストの関与を管理する。 Monitor Run Deliver Release Test Build Define Discover タグの種類 詳細 Experimental 本番環境で広範なテストが行われていない検知ルール。適用範囲を限定し、アラートの 確認はルール作成者に限定し、他のSOCアナリストは除外することが望ましい。 Testing “Experimental”より信頼性が高い検知ルールで、より幅広い用途で利用可能。SOCのアナリ スト全員が、優先度「低」で確認・レビューを行うことが望ましい。 Stable 信頼性が高い検知ルールであり、本番環境全体に展開可能。SOCアナリストは、通常の検知 ルールとして、確認・レビューする。展開後に誤検知や改善が必要な場合は、検知エンジニ アに相談する必要がある。 < Deployment Tag >
17. Copyright © Tomohisa Ishikawa All rights reserved. 1-2：Detection Engineering Process 16 Phase 8 – Monitor • KPIなどに基づき、検知精度と品質を管理する。 • 「Practical Threat Detection Engineering」で提案された3M+Cフレームワークの活用が有益！ Monitor Run Deliver Release Test Build Define Discover < 3M+C Framework> Metrics • 統計的なKPIから「検知ルール」のパフォーマンスを評価する。 例）クローズまで時間がかかる検知ルール → 検知精度が低い可能性あり Monitoring • 検知ルールから生成された個々の「アラート」を継続的に分析する。 例）実際のアラートを分析することで、誤検知や検知の課題を発見する Maintenance • 脅威インテリジェンスなどに基づく「検知ルール」の更新する。 例）外部レポートの活用 Continuous Validation • Detection Gapを特定するために、継続的にPurple Teamingを行う。 例）「検知ルール」の作成方法次第では、想定外の検知をしてしまう可能性もあり
18. 17 < Always-On Purple Team – RSA Conference 2024 >
19. Part II：実務編 18
20. Copyright © Tomohisa Ishikawa All rights reserved. 2：Detection as Code 19 • Detection as Code : 検知ルールをコードとして記述 • Ex) SIGMA – ログイベントを簡単に記述できる一般的な検知シグニチャフォーマット – このフォーマットを利用することで、コンバータを使用して独自のSIEM言語に変換可能 検知エンジン SIGMAルールをサポートする セキュリティテレメトリ SIGMAコンバータ 特定のSIEMがサポートされている クエリ言語に変換する 検知!! SIEMにおける検索 SIGMAルール （YAML） 検知!!
21. Copyright © Tomohisa Ishikawa All rights reserved. 2：Detection as Code 20 • Detection as Code : 検知ルールをコードとして記述 • 例) SIGMA – コンバータ • 参考) uncoder.io • 参考) sigconverter.io • 参考) コマンドライン (https://github.com/SigmaHQ/sigma-cli) – SIGMAルールのストレージ • 参考）https://github.com/SigmaHQ/sigma
22. 21 https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_susp_lsass_dump.yml ① 検知ルール名称 ② 検知対象となるログソース この場合、WindowsのSECURITYログ ③ 検知ルール 検知要素 + 条件（Condition）で記載する。
23. Copyright © Tomohisa Ishikawa All rights reserved. 2：Detection as Code 22 • Elastic Lucene • Carbon Black • Kusto Query Language (Microsoft) • Splunk EventID:4656 AND ProcessName:*¥¥lsass.exe AND AccessMask:0x705 AND ObjectType:SAM_DOMAIN EventID: 4656 ProcessName:¥lsass.exe AccessMask:0x705 ObjectType:SAM_DOMAIN EventID == 4656 and ProcessName endswith "¥¥lsass.exe" and AccessMask =~ "0x705" and ObjectType =~ "SAM_DOMAIN" EventID=4656 ProcessName="*¥¥lsass.exe" AccessMask="0x705" ObjectType="SAM_DOMAIN"
24. 23 https://github.com/SigmaHQ/sigma/blob/master/r ules/windows/process_creation/proc_creation_win _susp_shadow_copies_deletion.yml
25. 24 会場限定で説明します。
26. Part III：応用編 25
27. Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 26 「良い」Detection Engineering Programとは？ – ３種類のKPIを利用して、Detection Engineering Programの有効性を評価する P メトリクス 観点 概要 MTTD + MTTR 時間 時間軸（Time Based Security）の観点から評価する Precision & Recall 検知効率 検知効率の観点から、「偽陽性」と「偽陰性」の割合を 評価する Detection Coverage カバレッジ 検知能力のカバレッジの観点から、十分な網羅性が十分 か評価する < Detection Engineering Programを評価する３種類のKPI>
28. Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 27 検知能力を改善するための３種類のアプローチ • 延伸（Extension） ：同様の攻撃手法やツールに対する検知能力を拡張する • 精緻化（Sophistication） ：さらなる検知のために技術的な詳細を深く掘り下げる • 抽象化（Abstractions） ：検知ルールを一般化する この情報インプットとして、脅威インテリジェンスが非常に重要となる。 延伸 精緻化 抽象化 Kerberoasting攻撃に対して、これは mimikazだけでなくRubeusとInvoke- Kerberoast.ps1も検知するツールを拡 張します。 マルウェア解析を例に挙げれば、初期 段階では「静的解析」でハッシュ値や 抽出した文字列を検知に利用する。 コード解析を行うと、さらなる技術的 な詳細が明らかになるため更なる詳細 な検知が可能となる。 検知を一般化することで、検知範囲を 拡大する
29. Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 28 • Pyramid of Pain（痛みのピラミッド） – 2013 年に、セキュリティ専門家であるDavid J. Biancoが発表した概念（Bianco氏のブログ） – ６種類のIOCを分類し、ピラミッドの上にいけばいくほど攻撃者に与える影響（=痛み）が大きいことを 示す図である。 – 抽象化（Abstraction）とは、検知ルールをPyramid of Painの上部へシフトしていくことを意味する。
30. Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 29 Summit The Pyramid（=STP理論） • 検知の堅牢性（Robustness）を向上させるため、MITREが提案した評価手法 – 正確性（Accuracy） ：高い検知精度と高い再現率を持つこと（=低い偽陽性・偽陰性を持つこと） – 耐性（Resistance） ：時間の経過に対する攻撃者の回避能力に対する耐性があること • https://ctid.mitre.org/projects/summiting-the-pyramid/ • https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/ • Summiting the Pyramid of Pain（Shmoocon 2024）：https://www.youtube.com/watch?v=B86QP361t8E
31. Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 30 Summit The Pyramid（=STP理論） • MITREの課題： – 攻撃グループは既知の攻撃手法を多数再利用し、また各テクニックに対するSIGMAやCARは準備されて いる一方、実際の検知に成功していない現実がある。 – 参考： • SIGMA Repository ：https://github.com/SigmaHQ/sigma/ • CAR（Cyber Analytics Repository） ：https://car.mitre.org/analytics/by_technique • AttackRuleMap ：https://attackrulemap.com/ – 多くの検知ルールにおいて、Pyramid of Painの低いレイヤの実装が大半であり、攻撃手法そのものを 検知できるロジックではないことが挙げられる。 – そのため、SIGMAを中心に改善するフレームワークとして、STP理論を提唱している。 • 詳しくは、JSAC2025で公開したWorkshop資料をご覧ください。 – https://jsac.jpcert.or.jp/archive/2025/pdf/JSAC2025_ws1_ishikawa_daitoku_tomiyama_jp.pdf
32. Wrap-Up 31
33. Copyright © Tomohisa Ishikawa All rights reserved. Wrap-Up 32 • Part I ：理論編（What is Detection Engineering?） – 定義：“特定されたDetection Gapを埋めるための体系的アプローチ” – Detection Engineeringの３種類の特徴 – プロセスモデル（Detection & Response Development Life Cycle） • Part II ：実務編（ What is “Detection as Code”?） – Detection as Codeの事例として、SIGMAの概要を紹介しました。 • Part III ：応用編（What is “Good” Detection Engineering） – Detection Engineering Programの有効性を評価する３種類の指標 – 検知能力を改善するための３種類のアプローチ – Summit The Pyramid理論
34. 33 Thank You!