![[レポート]大規模な検知エンジニアリング：高精度のセキュリティ運用の構築（Datadog提供）に参加しました。#SEC327 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/4pUQzSdez78aERI3ud3HNg/fe4c41ee45eccea110362c7c14f1edec/reinvent2025_devio_report_w1200h630.png?w=3840&fm=webp)
[レポート]大規模な検知エンジニアリング：高精度のセキュリティ運用の構築（Datadog提供）に参加しました。#SEC327 #AWSreInvent
はじめに
こんにちは。AWS re:Invent2025 に参加しているオペレーション部shiinaです。
現地より Datadog スポンサーセッション「大規模な検知エンジニアリング：高精度のセキュリティ運用の構築 #SEC327」のレポートをお伝えします。
セッション概要
タイトル
大規模な検知エンジニアリング：高精度のセキュリティ運用の構築（Datadog提供）#SEC327
詳細
セキュリティチームは、AWS のサービス、サードパーティ製ツール、ハイブリッドインフラストラクチャ全体にわたるテレメトリデータの急増に直面しています。
課題は脅威の検出だけではありません。SOC チームに負担をかけることなく、毎日何百万ものイベントの中から真のインシデントを見つけ出すことも重要です。
Riot Games と Datadog の専門家と共に、効果的な大規模検出システムを構築するための実証済みの原則を探ります。
Riot Games のような企業での実際の導入事例を参考に、AWS ネイティブサービスと Datadog のセキュリティプラットフォームを併用して、実際に機能する高精度な検出ルールを作成する方法を紹介します。
このプレゼンテーションは、AWS パートナーである Datadog がお届けします。
スピーカー
- Andrew Krug,Head of Security Advocacy & Research, Datadog
- Nathan Pitchaikani,Senior Security Engineer, Riot Games
レベル
300
Agenda
本セッションでは次の2つがテーマでした。
- 検知ルールを「コード」として扱うことで、 ソフトウェア開発と同じレベルの品質管理をする
- ログの取り方・流し方・絞り方をきちんと設計して、無駄なコストと誤検知を減らす
下記 URL より本セッションのスライドやリンク集を確認できます。
検知エンジニアリングはアラートを書く仕事ではない
「悪いことが起きたときに、文脈付きで、アクション可能な形で気づけるようにするためのエンジニアリング」
AWS だけでも CloudTrail、VPC Flow Logs、各種アプリログ など、ログはほぼ無限です。
どのログをどのような形式でどのように見るかが重要となってきます。
検知ロジックを設計して運用する“プロダクト開発”に近いイメージです。
手作業で検知する設定を行っている運用がなぜ辛くなるのか
多くの組織では以下の運用が残っています。
- SIEM やコンソール上で直接アラート条件をポチポチ
- 誰がいつ変えたか分からない
- 本番で試し打ちして壊れてから気づく
これをやっていると次のような状態となります。
- 変更履歴が追えない（不具合の原因が分からない）
- チームでレビューできない（属人化）
- ルールが増えるほどカオス化
Detection as Code：検知を普通のコードとして扱う
そこで出てくるのが Detection as Code の検知（監視）ルールのコード管理です。
コード化することで以下が行えます。
- ルール・クエリ・設定をGit 管理する
- PR ベースでレビューする
- CI/CDパイプラインによるデプロイ
- 変更はすべて履歴・差分で追える
Datadog Cloud SIEM によるデモが紹介されました。
（参考）Datadog ドキュメント
精度
ルール設計では、リコール（再現率）と適合率（精度）のトレードオフを避けて通れません。
- リコール寄り
- とりあえず怪しければ鳴らす
- 取りこぼしは少ないが、誤検知が多い
- 適合率寄り
- かなり怪しいものだけ鳴らす
- 誤検知は少ないが、取りこぼしが増える
運用が耐えられる範囲でチューニングし続けることになるため、テスト自動化ができると楽になります。
ログは全部取るか、全部捨てるかではなく、段階的に絞る
ログパイプラインの話が出ました。
ポイントは次の通りです。
- 入口でできるだけ絞る
- 明らかに不要なイベントはそもそも送らない
- 共通フォーマットに正規化
- 後でルールを書きやすくするためのフィールド統一
- めったに使わないフィールドは削る
- 例：CloudTrail のフィールド、Windows ログのノイズフィールド
- 環境ごと・用途ごとにルーティング
- 「検知用」「保存だけ」「アーカイブ」など使い分け
Datadog において検知で必要なログはホットストレージにインデックスする。
それ以外はアーカイブに置いておき、必要なときだけリハイドレートすることが挙げられていました。
（参考）Datadog ドキュメント
行動検知・AI は前処理と設計が9割
行動ベースの検知は強力な一方で、ノイズも大量に出るため、1日あたりのシグナルが多く、人間だけではさばけません。
そこで出てくるのが、AIによるマッピング、優先度付け、一次調査の自動化です。
ここで Datadog Bits AI SRE が紹介されました。
（参考）Datadog ドキュメント
異なるログも同じルールで検知できるようにする試み
最後に紹介されていたのが OCSI (Open Cybersecurity Schema Initiative)です。
多種多様なログフォーマットを共通スキーマにマッピングして、統一されたフィールドで扱えるようにすることでした。
Datadog や AWS による推進によって Vector や Datadog Observability Pipelines などで実装例が出始めているとお話がありました。
（参考）Datadog ドキュメント
最後に
本セッションでは Detection as Code やログパイプライン、OCSI、Bits AI が紹介されました。
これらは既存の開発・運用プラクティスをセキュリティに拡張するための実装手段として位置付けられるといった内容でした。
Datadog をすでにお使いの環境であれば、まずは Cloud SIEM のルールを Git 管理して CI に乗せる、ログインデックスとアーカイブの設計を見直すといったところから始められそうです。
本記事が参考になれば幸いです。
#SEC327
#AWSreInvent
