この記事のポイント：本記事では Datadog Cloud SIEM（Security Monitoring）を使い、
「不審なアクティビティの検知 → Signal 生成 → Playbook による初動整理」
までを、SSH の invalid user 検知を例に解説します。
Security Monitoring / Cloud SIEM を初めて触る方や、
「まずは最短で検知を形にしたい」チーム向けの実践記事です。

はじめに

Datadog Cloud SIEM（Security Monitoring）は、インフラ・アプリケーション・クラウドサービスのログを横断的に分析し、
不審なアクティビティをリアルタイムに検知できる機能です。
既存の Datadog Agent / Logs 基盤をそのまま活用できるため、
新たに専用の SIEM 製品を導入せずにセキュリティ検知を始められる点が特徴です。

一方で、実際の現場では次のような悩みをよく耳にします。

  • Security Monitoring を有効化したが、どの Detection Rule を作ればよいか分からない
  • 検知は出るものの、ログと紐づかず状況が把握しづらい
  • Signal が出た後の初動対応がチーム内で整理されていない

本記事では、これらを避けるために
「最小構成・実運用前提」で Detection Rule を作成し、
実際に Signal が発生するところまでを確認します。

前提・動作環境

  • Datadog アカウント（US / EU いずれも可）
  • Logs が有効化され、ホストログが Datadog に到達している
  • Datadog Agent による syslog / sshd ログ収集が設定済み
  • Cloud SIEM（Security Monitoring）が有効

ポイント：
Cloud SIEM は Logs データが前提です。
まずは sshd のログが Datadog 上で検索できることを確認してから進めましょう。

SSH invalid user を検知する Detection Rule の作成

Step 1｜Detection Rule の作成

今回は「SSH への invalid user による認証試行」を検知対象とします。
Cloud SIEM の Detection Rules から新規ルールを作成します。


Detection Rules 画面の New Rule ボタン（新規ルール作成）
図1：Detection Rules から New Rule を選択してルール作成を開始（画像クリックで拡大）

ログ検索条件は、実際に出力されるログ文言に合わせて以下のように設定しました。

service:sshd AND "Invalid user"

SSH の失敗ログは環境やディストリビューションによって文言が微妙に異なります。
今回の環境では Failed password ではなく、実ログに含まれていた "Invalid user" が確実だったため、
まずは「確実にヒットする条件」に寄せてクエリを固めています。

集計条件は以下としました。

  • 評価ウィンドウ：15分
  • カウント条件：3回以上
  • Detection Method：Threshold

Detection Rule の検索クエリと集計条件（Threshold）の設定例
図2：検索クエリと集計条件の設定例（まずはプレビューでログがヒットする条件を固める）

まずは検証目的のため、Severity は INFO に設定しています。
（本番運用では、閾値や除外条件が固まった後に Medium / High などへ調整するのがおすすめです）

Step 2｜Rule Conditions / Parameters の設定

Rule Conditions では次の条件を設定します。


Rule Conditions と Other Parameters（再トリガー抑制など）の設定例
図3：Rule Conditions / Other Parameters の設定例（短時間の連続試行をまとめて扱う）
  • Triggers when query a >= 3（15分内に3回以上）
  • Rule multi-triggering behavior：1時間以内の再トリガーはまとめる
  • 最大継続時間：24時間

この設定により、短時間に繰り返される認証試行を 1つの Signal として扱いやすくなります。
特に検証初期は、同じ事象で Signal が大量発生しやすいため、まずは「まとめる」方向のパラメータに寄せておくと運用が安定します。

また、group by に network.client.ip が出ないケースがあります。今回のように抽出されていない場合は、まずは host 単位で Signal を出す設計でも問題ありません。
（将来的に IP 単位で追えるようにしたい場合は、ログパイプラインで IP を属性化し、network.client.ip 等へマッピングする方針が現実的です）

Playbook（What happened / Check）の記載

Detection Rule には Playbook を記載できます。
Signal 発生時に「何が起きたか」「まず何を確認すべきか」を明文化しておくことで、
担当者による判断ブレを防げます。

今回の Playbook は以下のようにしました。


Playbook（What happened / Check / Note）を Detection Rule に記載する画面
図4：Playbook の記載例（What happened / Check を先に決めておくと初動対応が安定）
What happened
SSH に対する invalid user による認証失敗を検知

Check
・該当ホストの sshd ログを確認
・同一 IP からの連続試行がないか確認

Note
This rule is for test / validation purpose.

検証段階であることを明示するため、
テスト用途である旨を Note に明記しています。


Detection Rule の設定保存後に一覧へ戻る画面
図5：設定を保存してルール作成完了（保存後は Detection Rules 一覧に表示される）

Signal の生成と確認

実際に SSH で存在しないユーザー名を指定して接続を試行すると、
設定した Detection Rule により Signal が生成されました。


Signals 一覧に検知結果（Signal）が表示される画面
図6：Signals 一覧で検知結果を確認（Rule 名、Severity、対象ホストなどがまとまって見える）

Signals 画面では以下の情報を確認できます。

  • どの Detection Rule がトリガーされたか
  • 何件のログが条件に一致したか
  • 対象ホスト
  • Log Activity（時系列）

Signal 詳細画面では、Playbook に記載した What happened / Check がそのまま表示され、
初動対応のガイドとして機能します。


Signal 詳細画面で What happened / Check が表示される例
図7：Signal 詳細画面（検知条件、ログ件数、時系列、Playbook が1画面で追える）

つまずきポイントと対処

  • 検知されない
    実ログの文言と検索条件が一致しているかを確認します。
    特に SSH 失敗系は Failed password / Invalid user / authentication failure など揺れが出やすいため、
    まずは Logs Explorer の検索で「確実にヒットする文字列」から固めるのがおすすめです。
  • group by に IP が出ない
    network.client.ip が自動抽出されていない場合があります。まずは host 単位の Signal で運用開始して問題ありません。
    IP 単位で追跡したい場合は、ログパイプラインで IP を属性化して network.client.ip 等へマッピングする方針を検討します。
  • 通知が多すぎる
    検証段階では Severity を INFO にし、再トリガー抑制（multi-triggering behavior）も「まとめる」方向に寄せます。
    本番運用前に、除外条件（特定の運用元 IP / 監視エージェントなど）や閾値を詰めるのがおすすめです。

まとめ

Datadog Cloud SIEM（Security Monitoring）を使えば、既存のログ基盤を活かした
リアルタイムなセキュリティ検知を比較的シンプルに構築できます。

まずは今回のように
1つのユースケース（SSH invalid user）に絞って「検知 → Signal → Playbook」
までを通しで作り、そこから段階的にルールを増やしていくのが実践的です。

参考リンク

最後までお読みいただきありがとうございました。
この記事が Datadog を使ったセキュリティ運用の第一歩になれば幸いです。