―ひとり情シスでも始められる、対応手順の標準化 ―
アラート対応を、担当者任せにしないために
セキュリティアラートが届くたびに、調査方法を考え、関係者へ連絡し、結果を記録する。ひとり情シスでは、その間も日常業務が続きます。SOARの第一歩は、担当者によって対応方法が変わらないように、手順と進捗を共有し、毎回ゼロから始めないことです。
第1弾ではUEBAで異常に気づき、第2弾ではAI Assistantでログ調査を支援しました。第3弾では、その後の「誰が、何を確認し、どう記録するか」を揃える仕組みを紹介します。
SOARは、アラート後の調査・判断・連絡・記録を整理し、必要に応じて自動化する考え方です。まず手順を標準化するだけでも、対応漏れや引き継ぎの負担を減らすことにつながります。
例としてWindowsのログオン失敗（イベントID 4625）を使い、Energy Logserver（以下ELS）のアラートルール、Playbook（対応手順）、インシデント（調査・対応が必要な事象）の管理を紹介します。
検知した後の対応を、どう効率化するか？
異常を検知しても、調査や連絡、対応状況の管理は残ります。SOARでは、その流れを事前に整理しておきます。
ELSでは、アラートからインシデントを自動生成し、事前に作成したPlaybookをルールに関連付けられます。手順と対応状況を一か所で確認しやすくすることが狙いです。
実例：深夜のログオン失敗に、どう対応する？
例えばログオン失敗のアラートを受けたら、対象アカウントや関連ログを確認し、連絡の要否を判断します。
※今回の検証ではイベントID 4625の単発検知を使用しており、深夜や連続失敗を検知条件としていません。
従来の対応：翌朝、担当者が一から調査することも
夜間対応体制がなければ、翌朝に担当者がログを調べ、連絡・記録する場合もあります。手順が決まっていないと、確認範囲や記録方法にばらつきが出ます。重大な侵害が疑われる場合は、別途緊急対応が必要です。
SOARで、アラート対応はどう変わる？
表1で従来の対応と比較します。
表1 従来のアラート対応とELSのSOAR関連機能を活用した対応の比較
| 対応業務 | 従来の対応 | ELSのSOAR関連機能を活用した対応 |
| 事前準備 | 担当者ごとに対応手順や確認項目が異なり、判断が属人化しやすい | Playbookに初動手順を事前登録し、必要に応じてワークフローを設計。確認項目を共通化し、担当者が迷わず初動調査を進めやすくする |
| アラート発生後 | アラートを確認し、管理表への記録や案件の起票を手作業で行う | アラートを起点にインシデントを自動生成。記録を始めるための手作業を減らす |
| 初動対応 | 調査のたびに手順書を探したり、詳しい担当者に確認したりする | 事前に整理したPlaybookを初動調査の共通手順として活用。確認項目の洗い出しや担当者間のばらつきを減らす |
| 対応状況の管理 | メールやExcelを見比べ、どの案件が対応中かを確認する | インシデントを一覧で管理し、対応状況を把握しやすくする |
| 引き継ぎ | 対応経緯や次に確認することを、その都度口頭やメールで伝える | 共通の確認手順とインシデントの管理情報をもとに、引き継ぎの負担を軽くする |
| 繰り返し作業 | 通知や情報収集などを、担当者が案件ごとに繰り返す | 定型的な処理はワークフロー化の対象として整理し、人が判断すべき作業に時間を使える運用を目指す |
※上記は運用イメージです。対応時間の短縮率を実測したものではありません。
検証では、ログオン失敗のアラートルールに事前作成したPlaybookを関連付け、インシデントの自動生成とステータスの手動変更を確認しました。
※調査・通知・端末隔離の自動実行は今回の検証対象に含めていません。
Energy Logserverでできること
実機画面で、検知の起点、共通の確認手順、対応状況の管理を順に見ていきます。
アラートルール：対応の出発点を揃える
Windowsのログオン失敗（イベントID 4625）をWazuh経由でELSに取り込み、検証用ルールからインシデントが生成されることを確認しました。
Playbook：初動対応の手順を揃える
Playbook（プレイブック）は、「何を確認し、誰が判断し、どう記録するか」をまとめた対応手順です。ワークフローは、確認・連絡・記録などをどの順番で進めるかを決めた流れです。
Playbookは、担当者が共通の手順に沿って初動対応を進めるために活用できます。
※今回の検証ではPlaybookを初動対応のチェックリストとして使用しています。ログ検索や判断の自動化は検証対象外です。
検証では「SOC_Initial_Response_Test」に確認・調査・優先度判断・連絡・記録の項目を事前登録し（図1）、アラートルールに関連付けました（図3）。
実運用では、対象アカウントや送信元、前後のログを確認し、必要に応じて連絡・記録する手順が考えられます。
※上記は運用例であり、図1に登録した項目と完全に一致するものではありません。
インシデント管理：対応漏れや引き継ぎを減らす
ELSではインシデントの状態を一覧で確認できます。検証では自動生成された案件を手動で「ongoing（対応中）」に変更しました（図2）。対応中の案件を見失いにくくする仕組みです。
自動化を広げるには：定型作業から段階的に
最初から自動対処を目指す必要はありません。まずはインシデントの自動生成と手順・状況の共有から始め、通知や情報収集などの定型作業を段階的に自動化することを検討します。
※自動化できる範囲はELSの機能・構成によって異なります。
ひとり情シスなら、どこから始めればよい？
まず、よく発生するアラートを一つ選び、確認項目・判断者・記録先をPlaybookにまとめます。次に対応状況の管理方法を決め、必要に応じてワークフローや自動化を検討します。段階的な進め方を表2にまとめます。
表2 ひとり情シスがSOARを段階的に活用するためのステップ
| 段階 | 取り組むこと | 期待できる変化 |
| STEP 1 | よく出るアラートを一つ選び、Playbookで初動手順を定義。インシデントの記録・管理方法を整え、必要に応じてワークフローを設計する | 発生時に対応の流れを一から考えずに済み、判断や引き継ぎの負担を減らせる |
| STEP 2 | アラートの緊急度・夜間連絡先・対応状態の記録方法を統一 | 対応漏れ・引き継ぎ漏れを減らす |
| STEP 3 | 通知・チケット作成・情報取得など、影響の小さい処理の連携を検討 | 繰り返し作業を減らす |
| STEP 4 | 停止・隔離などの対処に承認手順と復旧方法を設ける | 人の判断を残しつつ対応を迅速化 |
自動化は「頻度が高い」「判断条件が明確」「誤動作の影響が小さい」作業から検討すると進めやすくなります。
運用前に決めておきたいこと
アラートを増やしすぎない
すべてのログオン失敗を同じ優先度で通知すると、重要なものが埋もれます。管理者アカウントか、短時間に集中しているかなど、運用に合う条件を決め、見逃しにも注意して見直します。
「誰が判断するか」を決める
夜間・休日の連絡先、判断者、不在時の引き継ぎ先を事前に決めます。対応体制がない場合は、監視対象や外部委託の必要性も検討します。
対処だけでなく復旧方法も用意する
停止や隔離を自動化する場合は、承認方法だけでなく誤判定時の復旧手順も用意します。
まとめ：SOARの第一歩は「人が迷わない運用」
第1弾のUEBAで「気づく」、第2弾のAI Assistantで「調べる」、第3弾のSOARで「対応を進め、記録する」。共通の手順と案件管理によって、アラート対応を毎回ゼロから始めない運用を目指します。
今回の実機検証では、対応手順の登録・関連付けとインシデント管理の流れを確認しました。
次回予告
第4弾では、UEBAによる検知、AIによる調査支援、SOARによる対応管理が、ひとり情シスの一日の業務でどうつながるかを紹介します。
Energy Logserver 製品紹介ページ
ELSの特長や機能については、以下の製品紹介ページをご参照ください。
ご不明な点がありましたら、お気軽にお問い合わせください。
参考資料
ELS 8.1.0 リリースノート
※各機能の対応範囲・設定要件は導入バージョンの該当章で確認してください。
