security-detection-rule-management

検知ルールの管理

新たな脅威やカバレッジの不足に対応するために新しい検知ルールを作成し、既存のルールを調整して誤検知を減らします。 すべての操作では、rule-manager.js を介して Kibana Detection Engine API を使用します。

実行ルール

• ツールの実行をただちに開始してください。先に SKILL.md を読んだり、ワークスペースを調べたり、ファイルを一覧表示したりしないでください。
• ツールの出力を忠実に報告してください。ルール ID、名前、アラート数、例外 ID、エラーメッセージは、API から返されたとおりに正確にコピーしてください。ルール UUID を省略したり、ルール名を創作したり、アラート数を丸めたりしないでください。
• ツールがエラー（ルールが見つからない、API エラー）を返した場合は、正確なエラーを報告してください。別の方法を推測しないでください。

前提条件

初回使用前に、skills/security ディレクトリから依存関係をインストールしてください。

cd skills/security && npm install

必要な環境変数を設定してください（またはワークスペースのルートにある .env ファイルに追加してください）。

export ELASTICSEARCH_URL="https://your-cluster.es.cloud.example.com:443"
export ELASTICSEARCH_API_KEY="your-api-key"
export KIBANA_URL="https://your-cluster.kb.cloud.example.com:443"
export KIBANA_API_KEY="your-kibana-api-key"

一般的な複数ステップのワークフロー

タスク	呼び出すツール（順番どおり）
ノイズの多い SIEM ルールを調整する	rule_manager find/noisy-rules → run_query（誤検知を調査）→ rule_manager patch または add-exception
エンドポイント動作ルールに例外を追加する	fetch_endpoint_rule（GitHub からルール定義を取得）→ add_endpoint_exception（rule.id を対象に設定）
新しい検知ルールを作成する	run_query（データに対してクエリをテスト）→ rule_manager create
ルールのアラート量を調査する	rule_manager get → run_query（アラートインデックスをクエリ）

エンドポイント動作ルールでは、例外を追加する前に必ずルール定義を取得し、クエリのロジックと既存の除外条件を確認してください。SIEM ルールでは、調整する前に必ず run_query でアラートのパターンを調査してください。

重要： エンドポイント動作ルールでは、ルール定義を取得する際に必ず fetch_endpoint_rule（shell やスクリプトの直接呼び出しではなく）を使用し、その後 add_endpoint_exception で例外を追加してください。これらは専用ツールです。基盤となるスクリプトを手動で呼び出さないでください。

ワークフロー：誤検知を減らすためにルールを調整する

ステップ 1～2：ノイズの多いルールを特定し、誤検知を分析する

noisy-rules または find でノイズの多いルールを見つけ、ルール定義を取得してアラートを調査します。

node skills/security/detection-rule-management/scripts/rule-manager.js noisy-rules --days 7 --top 20
node skills/security/detection-rule-management/scripts/rule-manager.js find --filter "alert.attributes.name:*Suspicious*" --brief
node skills/security/detection-rule-management/scripts/rule-manager.js get --id <rule_uuid>
node skills/security/alert-triage/scripts/run-query.js "kibana.alert.rule.name:\"<rule_name>\"" --index ".alerts-security.alerts-*" --days 7 --full

パターンを確認します。同じプロセス／ユーザー／ホストなら例外の候補、広範なパターンならクエリを絞り込み、正当なソフトウェアなら例外を追加し、範囲が広すぎるなら書き換えるかしきい値を調整します。

ステップ 3：調整方法を選択する

推奨順：

1. 例外を追加する — 既知の正当なプロセス、ユーザー、ホストに対して最適です。ルールのクエリは変更しません。ルール自体は概ね正しいものの、既知の正当なアクティビティで検知が発生する場合に使用します。

2. クエリを絞り込む — 誤検知のパターンを除外するよう、ルールのクエリをパッチします。クエリの範囲が広すぎることが誤検知の原因である場合に最適です。

3. しきい値／アラート抑制を調整する — しきい値ルールでは、しきい値を引き上げます。どのルールタイプでも、アラート抑制を有効にして同じエンティティに対する重複アラートを減らします。

4. リスクスコア／重要度を下げる — 価値の低いアラートを多数生成するものの、一定の検知価値がある場合は、ルールの優先度を下げます。

5. ルールを無効にする — 最終手段です。ルールに価値がない場合、または別のルールと完全に重複する場合に限ります。

ステップ 4～5：調整を適用し、検証して、記録する

例外を追加する（単一／複数条件、matches によるワイルドカード）：

node skills/security/detection-rule-management/scripts/rule-manager.js add-exception \
  --rule-uuid <rule_uuid> \
  --entries "process.executable:is:C:\\Program Files\\SCCM\\CcmExec.exe" "process.parent.name:is:CcmExec.exe" \
  --name "Exclude SCCM" --comment "FP: SCCM deployment" --tags "tuning:fp" "source:soc" --yes

クエリ、しきい値、重大度を修正する、または無効にする：

node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --query "process.name:powershell.exe AND NOT process.parent.name:CcmExec.exe" --yes
node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --max-signals 50 --yes
node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --severity low --risk-score 21 --yes
node skills/security/detection-rule-management/scripts/rule-manager.js disable --id <rule_uuid> --yes

書き込み操作（patch、enable、disable、delete、add-exception、bulk-action）では、デフォルトで確認を求めます。 確認を省略するには --yes を渡します（エージェントから呼び出す場合は必須です）。

rule-manager.js get --id <rule_uuid> で検証します。case-management スキルを使ってトリアージケースを更新します。

---

ワークフロー：新しい検知ルールの作成

ステップ 1～2：脅威、データソース、フィールドを定義する

MITRE ATT&CK の手法、必要なデータソース（Endpoint、Network、Cloud）、悪意のある動作と正当な動作を指定します。 一般的なインデックス：logs-endpoint.events.process-*、logs-endpoint.events.network-*、 .alerts-security.alerts-*、logs-windows.*、logs-aws.*。主なフィールド：process.name、process.command_line、 process.parent.name、destination.ip、winlog.event_id、event.action。run-query.js でデータを検証します：

node skills/security/alert-triage/scripts/run-query.js "process.name:certutil.exe" --index "logs-endpoint.events.process-*" --days 30 --size 5

ステップ 3：クエリを作成してテストする

ルールタイプ：query（KQL フィールドマッチング）、eql（イベントシーケンス）、esql（集計）、threshold（ボリュームベース）、 threat_match（IOC 相関）、new_terms（初回検出）。作成前に Elasticsearch に対してテストします：

node skills/security/alert-triage/scripts/run-query.js "process.name:certutil.exe AND process.command_line:(*urlcache* OR *decode*)" \
  --index "logs-endpoint.events.process-*" --days 30

EQL では、シェルのエスケープ処理の問題を避けるために --query-file を使用します。

ルールを作成または修正する前に、クエリの構文を検証してください。 validate-query コマンドは、エスケープされたバックスラッシュ、 対応しない括弧、閉じていない引用符、重複したブール演算子など、よくあるエラーをローカルで検出します：

node skills/security/detection-rule-management/scripts/rule-manager.js validate-query \
  --query "process.name:taskkill.exe AND process.command_line:(*chrome.exe* OR *msedge.exe*)" --language kuery

create コマンドと patch コマンドも自動的に検証を実行し、無効なクエリを拒否します。チェックに引っかかってもクエリが正しいと確信できる場合に限り、 --skip-validation を渡してください。

よくある KQL 構文の間違い：

• エスケープされたスラッシュ — KQL のワイルドカードでは通常のテキストを使います。*\/IM chrome.exe* ではなく、*/IM chrome.exe* と記述します。
• 対応しない括弧 — すべての ( に対応する ) が必要です。
• 閉じていない引用符 — すべての " に対応する引用符が必要です。
• 重複した演算子 — AND AND や OR OR は常にエラーです。

ステップ 4：ルールを作成する

node skills/security/detection-rule-management/scripts/rule-manager.js create \
  --name "Certutil URL Download or Decode" \
  --description "Detects certutil.exe used to download files or decode Base64 payloads, a common LOLBin technique." \
  --type query \
  --query "process.name:certutil.exe AND process.command_line:(*urlcache* OR *decode*)" \
  --index "logs-endpoint.events.process-*" \
  --severity medium --risk-score 47 \
  --tags "OS:Windows" "Tactic:Defense Evasion" "Tactic:Command and Control" \
  --false-positives "IT administrators using certutil for legitimate certificate operations" \
  --references "https://attack.mitre.org/techniques/T1140/" \
  --interval 5m --disabled

複雑なルール（EQL シーケンス、MITRE マッピング、アラート抑制）には、create --from-file rule_definition.json と --threat-file を使用します。スキーマについては references/detection-api-reference.md を参照してください。

ステップ 5：監視して反復する

noisy-rules --days 3 --top 10 でアラート量を監視し、必要に応じて誤検知を調整します。

---

ワークフロー：Endpoint 動作ルールの調整

特定のルールを対象とする Endpoint 例外を追加して、Elastic Endpoint 動作ルールを調整します。Endpoint 例外は、 個々の SIEM ルールの下ではなく、Security → Exceptions → Endpoint Security Exception List にあります。

主な原則： 必ず最初に protections-artifacts からルール定義を取得してください。必ず例外の対象をルールに絞ってください（rule.id または rule.name）。 プロセス名より完全なパスを使用してください。例外を追加する前に、必須のエンティティ照合（ステップ 4b）を実行してください。 影響をシミュレーションし（ステップ 5b）、ノイズを 60% 以上削減することを目指してください。

スクリプト： fetch-endpoint-rule-from-github.js（ID を指定してルール TOML を取得）、add-endpoint-exception.js（Endpoint Exception List に追加。rule.id／rule.name が必須）、check-exclusion-best-practices.js。

手順をすべて記載したワークフロー（ステップ 1～6）、クエリ、シミュレーションテンプレートについては、 references/endpoint-behavior-tuning-workflow.md を参照してください。除外のベスト プラクティスについては、 references/endpoint-rule-exclusion-best-practices.md を参照してください。

---

ツールのリファレンス

rule-manager.js

すべてのコマンドはワークスペースのルートから実行します。特記がない限り、すべての出力は JSON です。

コマンド	説明
find	オプションの KQL フィルターを使ってルールを検索／一覧表示します
get	--id または --rule-id でルールを取得します
create	ルールを作成します（インラインフラグまたは --from-file）
patch	ルールの特定のフィールドを更新します
enable	ルールを有効にします
disable	ルールを無効にします
delete	ルールを削除します
export	ルールを NDJSON としてエクスポートします
bulk-action	ルールを一括で有効化／無効化／削除／複製／編集します
add-exception	ルールに例外項目を追加します
list-exceptions	例外リストの項目を一覧表示します
create-shared-list	共有例外リストを作成します
noisy-rules	アラート量が最も多いルールを見つけます
validate-query	作成／更新の前にクエリ構文を確認します

エンドポイントの動作の調整： fetch-endpoint-rule-from-github.js（ID でルール TOML を取得）、add-endpoint-exception.js （エンドポイント例外リストに追加。rule.id/rule.name が必要）、check-exclusion-best-practices.js。

例外エントリの形式

エントリは field:operator:value の形式で渡します。演算子：is、is_not、is_one_of、is_not_one_of、exists、 does_not_exist、matches、does_not_match。例：process.name:is:svchost.exe、 file.path:matches:C:\\Program Files\\*。

追加リソース

• API スキーマの詳細については、references/detection-api-reference.md を参照してください
• エンドポイントの動作の調整については、references/endpoint-exceptions-guide.md、 references/endpoint-rule-exclusion-best-practices.md を参照してください
• 調整中のアラート調査には、alert-triage スキルを使用してください
• ケース内で調整作業を記録するには、case-management スキルを使用してください

例

• 「過去 7 日間で最もアラートの多い検知ルールを見つけて、そのうち 1 つの調整を手伝ってください」
• 「疑わしい PowerShell ルールに例外を追加し、SCCM を除外してください」
• 「certutil による URL のダウンロードまたはデコードを検知する新しいルールを作成してください」

ガイドライン

• ツールの出力のみを報告してください。 結果を要約する場合は、ツールが返した内容のみを引用または言い換えてください。 ID、ホスト名、IP、スコア、プロセスツリー、その他ツールの応答に含まれない詳細を作り出さないでください。
• リクエストに含まれる識別子を保持してください。 ユーザーが特定のホスト名、エージェント ID、ケース ID、その他の値を指定した場合、 ツール呼び出しと応答ではその値を正確に使用してください。別の識別子に置き換えないでください。
• 操作の完了を簡潔に確認してください。 ツールの実行後、ツールの戻り値を使って実施内容を確認してください。ツールの応答に含まれない内部 ID、メタデータ、 ステータスの詳細を捏造しないでください。
• 事実と推論を区別してください。 ツールの戻り値を超える結論を導く場合（例：観測された挙動に基づいて MITRE の手法を提案する場合）は、 ツールの出力としてではなく、自分の評価であることを明確に示してください。
• ただちにツールの実行を開始してください。 実行前に SKILL.md を読んだり、ディレクトリを調べたり、ファイルを一覧表示したりしないでください。
• ツールの出力をそのまま報告してください。 ルール ID、名前、アラート数、エラーメッセージは、返されたとおりに正確にコピーしてください。 UUID を省略したり、数値を丸めたりしないでください。

本番環境での使用

• すべての書き込み操作（create、patch、enable、disable、delete、add-exception、bulk-action、 add-endpoint-exception）では、確認を求められます。エージェントから呼び出す場合は、--yes または -y を渡すと確認をスキップできます。
• エンドポイント例外は検知を全体的に抑制します。 エントリーで rule.id または rule.name を使い、例外の対象を常に特定のルールに限定してください。対象を指定しない広範な例外は、検知範囲を気付かれないまま縮小するおそれがあります。
• スクリプトを実行する前に、環境変数が意図したクラスターを指していることを確認してください。
• 一括変更を実行する前に、bulk-action で --dry-run を使って影響をプレビューしてください。

環境変数

変数	必須	説明
ELASTICSEARCH_URL	はい	Elasticsearch の URL（ノイズの多いルールの集計用）
ELASTICSEARCH_API_KEY	はい	Elasticsearch の API キー
KIBANA_URL	はい	Kibana の URL（ルール API 用）
KIBANA_API_KEY	はい	Kibana の API キー