DevSecOpsにおける検知エンジニアリングとインシデントレスポンス

ログがあることは検知があることを意味しません。アラートがあることは対応があることを意味しません。検知エンジニアリングとは、生のイベントを行動可能なシグナルに変換し、オーナーを置き、MTTD/MTTRを測定可能にするプロセスです。

検知の前にログを語る

非構造化ログはスケールしません。4つの原則：

標準フィールドを持つ構造化JSON：timestamp、service、env、request_id、user_id（ハッシュ化/レダクト済み）、action、result。
サービス、ゲートウェイ、キューを横断する相関ID——W3C Trace Contextを使用。
生のシークレット/PIIをログに出さない。共通SDKでstdoutに出力する前にレダクトする。
機密性の高い操作（管理者操作、キーアクセス、データエクスポート）には独立した監査ログ——スキーマを分け、リテンションを長く（12〜36ヶ月）。

SIEMにストリームすべき重要ログソース

ソース	検知価値
クラウド監査（CloudTrail、Activity Log）	異常なIAM、キー作成、見慣れないリージョン
K8s監査ログ（Metadataレベル）	RBAC変更、Podへのexec、シークレットアクセス
IDプロバイダ（Okta、Azure AD）	ブルートフォース、不可能な移動、MFAバイパス
アプリケーション監査ログ	権限昇格、大量のデータエクスポート
Falco / Tetragon	コンテナのランタイム挙動
WAF、CDN、ゲートウェイ	ブルートフォース、スクレイピング、異常検知

Sigma：detection-as-code

SigmaはSIEM非依存で検知ルールを記述するためのYAML標準フォーマットです（Splunk SPL、ELK Lucene、Sentinel KQLなどに変換可能）。例：

title: K8s exec into production pod
id: 1f0e3aa8-...
status: stable
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    verb: create
    objectRef.subresource: exec
    objectRef.namespace|startswith: prod-
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1609   # container administration command

ルールをgitに保存し、PRでレビューし、CIテスト（陽性/陰性ケース）を持つ。これがdetection-as-codeです。

MITRE ATT&CKへのマッピング

ATT&CKは攻撃者の行動をtactic（目標）とtechnique（手法）に分類します。検知をATT&CKにマッピングするメリット：

どのtacticで検知が不足しているかが分かる（例：Initial Accessは強いがLateral Movement、Exfiltrationは弱いなど）。
脅威インテリジェンスとの照合：自業界を狙うAPTグループが使うtechnique → 該当する検知を優先。
リーダーシップへの明確なカバレッジレポート：「自社スタックに関連するtechniqueの65%をカバー」。

IRランブックとテーブルトップ演習

NIST PICERLサイクル：Preparation → Identification → Containment → Eradication → Recovery → Lessons learned。各ランブックには次が必要です：

重要度マトリクス：SEV1/2/3とSLAレスポンス。
明確なオンコールローテーションとエスカレーションパス。
コミュニケーションテンプレート：ステータスページ、顧客通知、規制当局通知（政令13/2023/NĐ-CP：72時間）。
証拠の保全：ディスク/メモリのスナップショット、ログコピー、監査証跡のエクスポート——削除/復旧の前に実施。
インシデント種別ごとの封じ込めプレイブック：シークレット漏洩、アカウント侵害、ランサムウェア、データ流出。

四半期に1〜2回、各回60〜90分のテーブルトップ演習を、現実的な1シナリオで実施しましょう。測定指標：検知時間（MTTD）、封じ込め時間（MTTC）、復旧時間（MTTR）。

Blamelessなポストモーテム

目的は罰する人を探すことではなく、インシデントを許したシステム条件を見つけることです。テンプレート例：

サマリー（3〜5行）。
タイムライン：誰が、何を、いつ（UTCタイムスタンプで）。
影響：ユーザー、データ、財務。
根本原因：寄与要因（通常は1つではなく複数）。
うまくいったこと：強化のため、良い点も認める。
アクションアイテム：オーナーと現実的な期限を持ち、スプリントバックログに入れる。

Blameless文化はリーダーシップによる保護が必要です——報告者が罰せられるなら、次回から誰も正直に語らなくなります。

バグバウンティとパープルチーム

社内検知の補完：

security.txt + security@メールによる責任ある開示：安価で無料。
HackerOne/Intigriti、または国内プラットフォームでのバグバウンティ：明確なスコープと報酬。
パープルチーム演習：レッドチームが1つのtechniqueを実行し、ブルーチームが検知できるかを測定し、その後一緒にルールをチューニング。点数を競うのではなく、相互に学ぶ。

測定すべきメトリクス

インシデント種別ごとのMTTD。
重要度別の脆弱性MTTRとSLA順守率。
真陽性アラート率（アラート疲労の予防）。
tacticごとのATT&CKカバレッジ。
テーブルトップ実施頻度、ポストモーテムからのアクションアイテム期限内完了率。

結論

検知エンジニアリングとIRは、DevSecOpsとSOCが交差する場所です。ルールをコードとして扱い（Sigma + git + CI）、ランブックをプロダクトとして扱い（レビュー、バージョン管理、MTTR測定）、blameless文化を守りましょう。そうすれば、各インシデントはパニックを引き起こすイベントではなく、システム改善の燃料になります。