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

Slide 1

Slide 1 text

脅威インテリジェンス + 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忍者チャレンジ

Slide 2

Slide 2 text

自己紹介 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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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を実現するために必要な＆アプローチを示します。

Slide 5

Slide 5 text

Part I：理論編 4

Slide 6

Slide 6 text

Copyright © Tomohisa Ishikawa All rights reserved. 1-1：Detection Engineeringとは？ 5 • Detection Engineeringとは？ • “ソフトウェアエンジニアリングの概念を適用し、潜在的な脅威を検知するための検知ルールの設計・構築・テスト・改善・管理を行うアジャイル開発プロセス” • “特定されたDetection Gapを埋めるための体系的アプローチ” < Detection Gapとは？> 参考: TaHiTI Threat Hunting Methodology

Slide 7

Slide 7 text

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の目的

Slide 8

Slide 8 text

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 :「アジャイル」アプローチ • 小さく始めて、継続的に改善する

Slide 9

Slide 9 text

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/

Slide 10

Slide 10 text

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の各フェーズ＞

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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 : トリアージ

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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 パイプラインのサンプルワークフロー＞

Slide 16

Slide 16 text

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 >

Slide 17

Slide 17 text

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を行う。例）「検知ルール」の作成方法次第では、想定外の検知をしてしまう可能性もあり

Slide 18

Slide 18 text

17 < Always-On Purple Team – RSA Conference 2024 >

Slide 19

Slide 19 text

Part II：実務編 18

Slide 20

Slide 20 text

Copyright © Tomohisa Ishikawa All rights reserved. 2：Detection as Code 19 • Detection as Code : 検知ルールをコードとして記述 • Ex) SIGMA – ログイベントを簡単に記述できる一般的な検知シグニチャフォーマット – このフォーマットを利用することで、コンバータを使用して独自のSIEM言語に変換可能検知エンジン SIGMAルールをサポートするセキュリティテレメトリ SIGMAコンバータ特定のSIEMがサポートされているクエリ言語に変換する検知!! SIEMにおける検索 SIGMAルール（YAML）検知!!

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

21 https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_susp_lsass_dump.yml ① 検知ルール名称 ② 検知対象となるログソースこの場合、WindowsのSECURITYログ ③ 検知ルール検知要素 + 条件（Condition）で記載する。

Slide 23

Slide 23 text

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"

Slide 24

Slide 24 text

23 https://github.com/SigmaHQ/sigma/blob/master/r ules/windows/process_creation/proc_creation_win _susp_shadow_copies_deletion.yml

Slide 25

Slide 25 text

24 会場限定で説明します。

Slide 26

Slide 26 text

Part III：応用編 25

Slide 27

Slide 27 text

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>

Slide 28

Slide 28 text

Copyright © Tomohisa Ishikawa All rights reserved. 3：What is the “Successful” Detection Engineering Program? 27 検知能力を改善するための３種類のアプローチ • 延伸（Extension）：同様の攻撃手法やツールに対する検知能力を拡張する • 精緻化（Sophistication）：さらなる検知のために技術的な詳細を深く掘り下げる • 抽象化（Abstractions）：検知ルールを一般化するこの情報インプットとして、脅威インテリジェンスが非常に重要となる。延伸精緻化抽象化 Kerberoasting攻撃に対して、これは mimikazだけでなくRubeusとInvoke- Kerberoast.ps1も検知するツールを拡張します。マルウェア解析を例に挙げれば、初期段階では「静的解析」でハッシュ値や抽出した文字列を検知に利用する。コード解析を行うと、さらなる技術的な詳細が明らかになるため更なる詳細な検知が可能となる。検知を一般化することで、検知範囲を拡大する

Slide 29

Slide 29 text

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の上部へシフトしていくことを意味する。

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Wrap-Up 31

Slide 33

Slide 33 text

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理論

Slide 34

Slide 34 text

33 Thank You!