security-alert-triage

アラートのトリアージ

Elastic Security のアラートを1件ずつ分析します。コンテキストを収集し、分類して、ケースを作成し、確認済みにします。このスキルでは、ケースを作成するために case-management スキルが必要です。

前提条件

初回使用前に、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"

クイックスタート

すべてのコマンドはワークスペースのルートから実行します。必ず取得 → 調査 → 記録 → 確認の順に進めます。ツールを直接呼び出してください。最初にスキルファイルを読んだり、ワークスペースを調べたりしないでください。

node skills/security/alert-triage/scripts/fetch-next-alert.js
node skills/security/case-management/scripts/case-manager.js find --tags "agent_id:<id>"
node skills/security/alert-triage/scripts/run-query.js --query-file query.esql --type esql
node skills/security/case-management/scripts/case-manager.js create --title "..." --description "..." --tags "classification:..." "agent_id:<id>" --severity <level> --yes
node skills/security/case-management/scripts/case-manager.js attach-alert --case-id <id> --alert-id <id> --alert-index <index> --rule-id <uuid> --rule-name "<name>" --yes
node skills/security/alert-triage/scripts/acknowledge-alert.js --related --agent <id> --timestamp <ts> --window 60 --yes

よくある複数ステップのワークフロー

タスク	呼び出すツール（順番どおり）
エンドツーエンドのトリアージ	fetch_next_alert → run_query（コンテキスト）→ case_manager create（ケース）→ acknowledge_alert
コンテキストの収集	run_query（プロセスツリー、ネットワーク、関連アラート）
分類後のケース作成	case_manager create → case_manager attach-alert
トリアージ後の確認	acknowledge_alert（一括処理では related モード）

ワークフローを必ず最後まで完了してください。取得 → 調査 → 記録 → 確認の順に進めます。コンテキストを収集しただけで終わらず、確認済みにする前に、調査結果を添えてケースを作成または更新してください。

重要な実行ルール：

• すぐにツールの実行を開始してください。最初に SKILL.md を読んだり、ワークスペースを閲覧したり、ファイルを一覧表示したりしないでください。
• ES|QL クエリでは、クエリを一時的な .esql ファイルに書き込み、--query-file で渡します。edit_file は使わず、echo "..." > query.esql && node ... --query-file query.esql を1回の shell 呼び出しで実行してください。
• コンテキストの収集は絞り込み、対象を絞ったクエリを2～4回（プロセスツリー、ネットワーク、関連アラート）実行してください。10回以上実行しないでください。
• ツールが返した内容だけを報告してください。識別子はそのまま正確にコピーし、ID、タイムスタンプ、ホスト名を言い換えないでください。

重要な原則

• 早まって分類しないでください。 良性／不明／悪意ありのいずれかを判断する前に、コンテキストをすべて収集してください。
• アラートの大半は誤検知です。 たとえ警告的に見えても同様です。「Malicious Behavior」のようなルール名や「critical」という深刻度は、証拠にはなりません。
• 証拠が不十分な場合、「不明」は許容でき、多くの場合に適切な分類です。
• 悪意ありと分類するには、強力な裏付けとなる証拠が必要です。 持続化と C2、認証情報の窃取、ラテラルムーブメントなどが必要であり、疑わしい API 呼び出しだけでは不十分です。
• ツールの出力をそのまま報告してください。 ツールが返した ID、ホスト名、タイムスタンプ、件数を正確にコピーしてください。数値を丸めたり、IDを省略したり、エラーメッセージを言い換えたりしないでください。

ワークフロー

複数のアラートをトリアージする場合は、最初にグループ化し、その後、各グループをトリアージします。

- [ ] Step 0: Group alerts by agent/host and time window
- [ ] Step 1: Check existing cases
- [ ] Step 2: Gather full context (DO NOT SKIP)
- [ ] Step 3: Create or update case (only AFTER context gathered)
- [ ] Step 4: Acknowledge alert and all related alerts
- [ ] Step 5: Fetch next alert group and repeat

ステップ 0：トリアージの前にアラートをグループ化する

ユーザーから複数の未解決アラートについて尋ねられた場合は、重複調査を避けるため、最初にグループ化します。未解決アラートをクエリし、agent.id でグループ化し、さらに時間枠（約5分＝同一インシデントの可能性が高い）でサブグループ化して、各グループを1つの単位としてトリアージします。

概要の確認には ES|QL を使います（PowerShell では、まずファイルに書き込みます）。

FROM .alerts-security.alerts-*
| WHERE kibana.alert.workflow_status == "open" AND @timestamp >= "<start>"
| STATS alert_count=COUNT(*), rules=VALUES(kibana.alert.rule.name) BY agent.id
| SORT alert_count DESC

クエリのテンプレート全体については、references/classification-guide.md を参照してください。

ステップ 1：既存のケースを確認する

新しいケースを作成する前に、このアラートが既存のケースに属していないか確認します。case-management スキルを使用してください。

node skills/security/case-management/scripts/case-manager.js find --tags "agent_id:<agent_id>"
node skills/security/case-management/scripts/case-manager.js cases-for-alert --alert-id <alert_id>

同じエージェント ID、ユーザー、または関連する検出ルールについて、近い時間帯のケースを探します。

注： find --search は Serverless で 500 エラーを返すことがあります。その場合は、代わりに find --tags または list を使用してください。

ステップ 2：コンテキストを収集する

これが最も重要なステップです。省略したり、手を抜いたりしないでください。 分類に関する意見をまとめる前に、すべてのサブステップを完了してください。

時間範囲に関する警告： アラートは数日または数週間前のものである場合があります。NOW() - 1 HOUR のような相対時間は絶対に使用しないでください。アラートの @timestamp を取得し、その時刻を基準に前後 1 時間の範囲でクエリを作成してください。

サブステップ：（2a）同じエージェント／ユーザーに関連するアラート、（2b）環境全体でのルールの発生頻度（高いほど誤検知が発生しやすい）、（2c）エンティティのコンテキスト — プロセスツリー、ネットワーク、レジストリ、ファイル、（2d）挙動の調査 — 永続化、C2、横展開、認証情報へのアクセス。

例 — プロセスツリー（KEEP を使用した ES|QL を使用し、1 万行を超える出力を生成する --full は避けてください）：

FROM logs-endpoint.events.process-*
| WHERE agent.id == "<agent_id>" AND @timestamp >= "<alert_time - 5min>" AND @timestamp <= "<alert_time + 10min>"
  AND process.parent.name IS NOT NULL
  AND process.name NOT IN ("svchost.exe", "conhost.exe", "agentbeat.exe")
| KEEP @timestamp, process.name, process.command_line, process.pid, process.parent.name, process.parent.pid
| SORT @timestamp | LIMIT 80

データの種類	インデックスパターン
アラート	.alerts-security.alerts-*
プロセス	logs-endpoint.events.process-*
ネットワーク	logs-endpoint.events.network-*
ログ	logs-*

クエリテンプレートと分類基準の詳細については、 references/classification-guide.md を参照してください。

ステップ 3：ケースを作成または更新する

コンテキストを収集したら、ケースを作成してアラートを添付します。--rule-id と --rule-name を使用してください（必須です。指定しない場合は 400 エラーになります）：

node skills/security/case-management/scripts/case-manager.js create \
  --title "<concise summary>" \
  --description "<findings, IOCs, attack chain, MITRE techniques>" \
  --tags "classification:<benign|unknown|malicious>" "confidence:<0-100>" "mitre:<technique>" "agent_id:<id>" \
  --severity <low|medium|high|critical>

node skills/security/case-management/scripts/case-manager.js attach-alert \
  --case-id <case_id> --alert-id <alert_id> --alert-index <index> \
  --rule-id <rule_uuid> --rule-name "<rule name>"

# Multiple alerts: attach-alerts --alert-ids <id1> <id2>
# Add notes: add-comment --case-id <id> --comment "Findings..."

ケースの説明： 概要（1～2 文）、攻撃チェーン、IOC（ハッシュ、IP、パス）、MITRE の手法、挙動に関する調査結果、対応状況（修復、リスクにさらされている認証情報）。

ステップ 4：アラートを確認済みにする

関連するアラートをすべてまとめて確認済みにします。まず --dry-run を使用して対象範囲を確認し、その後、オプションを付けずに実行してください：

# By host name — preferred when triaging a host
node skills/security/alert-triage/scripts/acknowledge-alert.js --query --host <hostname> --dry-run
node skills/security/alert-triage/scripts/acknowledge-alert.js --query --host <hostname> --yes

# By agent ID — preferred when agent.id is known
node skills/security/alert-triage/scripts/acknowledge-alert.js --related --agent <id> --timestamp <ts> --window 60 --dry-run
node skills/security/alert-triage/scripts/acknowledge-alert.js --related --agent <id> --timestamp <ts> --window 60 --yes

攻撃チェーンが長い場合は、--window の値を大きくしてください（例：5 分の場合は 300）。ツールの出力に基づき、確認済みにしたアラートの正確な件数を報告してください。エージェントから呼び出される場合は、確認プロンプトを省略するために --yes を渡してください。

ステップ 5：繰り返す

node skills/security/alert-triage/scripts/fetch-next-alert.js

ツールのリファレンス

fetch-next-alert.js

確認されていない Elastic Security アラートのうち、最も古いものを取得します。

node skills/security/alert-triage/scripts/fetch-next-alert.js [--days <n>] [--json] [--full] [--verbose]

run-query.js

Elasticsearch に対して KQL または ES|QL クエリを実行します。

PowerShell に関する警告：ES|QL クエリにはパイプ文字（|）が含まれており、PowerShell はこれをシェルのパイプとして解釈します。ES|QL では必ず --query-file を使用してください：

# Write query to file, then run
node skills/security/alert-triage/scripts/run-query.js --query-file query.esql --type esql

パイプを含まない KQL クエリは、直接渡すことができます：

node skills/security/alert-triage/scripts/run-query.js "agent.id:<id>" --index "logs-*" --days 7

引数	説明
query	KQL クエリ（位置引数）
--query-file, -q	ファイルからクエリを読み込みます（PowerShell で ES|QL を使う場合は必須）
--type, -t	kql または esql（既定値：kql）
--index, -i	インデックスパターン（既定値：logs-*）
--size, -s	最大結果数（既定値：100）
--days, -d	過去 N 日間に制限します
--json	JSON をそのまま出力します
--full	ドキュメントソース全体

acknowledge-alert.js

workflow_status を acknowledged に更新してアラートを確認済みにします。

モード	コマンド
単一	node skills/security/alert-triage/scripts/acknowledge-alert.js <alert_id> --index <index> --yes
関連	node skills/security/alert-triage/scripts/acknowledge-alert.js --related --agent <id> --timestamp <ts> [--window 60] --yes
ホスト	node skills/security/alert-triage/scripts/acknowledge-alert.js --query --host <hostname> [--time-start <ts>] [--time-end <ts>] --yes
クエリ	node skills/security/alert-triage/scripts/acknowledge-alert.js --query --agent <id> [--time-start <ts>] [--time-end <ts>] --yes
ドライラン	どのモードにも --dry-run を追加します（確認は不要です）
確認	すべての書き込みモードで確認を求められます。省略するには --yes を指定します

例

• 「次の未確認アラートを取得してトリアージする」
• 「アラート ID abc-123 を調査する — コンテキストを集めて分類し、悪意がある場合はケースを作成する」
• 「過去 24 時間の重大度が最も高いアラートを 5 件処理する」

ガイドライン

• ツールの出力のみを報告してください。ツールの応答にない ID、ホスト名、IP、詳細を作り出さないでください。
• リクエストに含まれる識別子を保持してください。ツールの呼び出しと応答では、ユーザーが指定した値を正確に使用してください。
• ツールの戻り値を使って、簡潔にアクションを確認してください。
• 事実と推測を区別してください。ツールの出力を超える結論には、自身の評価であることを明記してください。

本番環境での使用

• すべての書き込み操作（acknowledge-alert.js）では確認を求められます。エージェントから呼び出す場合に確認を省略するには、--yes または -y を渡してください。
• データを変更せずに対象範囲をプレビューするには、一括確認の前に --dry-run を使用してください。
• 確認スクリプトは Kibana Detection Engine API を使用しており、セルフマネージドと Serverless の両方のデプロイに対応しています。
• スクリプトを実行する前に、環境変数が意図したクラスターを指していることを確認してください。確認を取り消すことはできません。

環境変数

変数	必須	説明
ELASTICSEARCH_URL	はい	Elasticsearch の URL
ELASTICSEARCH_API_KEY	はい	Elasticsearch の API キー
KIBANA_URL	はい	Kibana の URL（ケース管理用）
KIBANA_API_KEY	はい	Kibana の API キー（ケース管理用）