SOCアクション設計
文書番号：2605.00009
この記事の位置づけ
この記事では、SOCがアラートを受けた後に、何を確認し、どの条件で隔離や復旧へ進めるかを扱うのだ。
ログ収集は SIEMログ設計とSOC運用の入口、検知条件は SIEM検知ルールと相関分析の設計 を参照する必要があるのだ。
SOCアクションは検知ルールと一体で設計する
アラートは、確認とアクションへつながって初めて意味があるのだ。
| 検知 | 確認 | アクション候補 |
|---|---|---|
| パスワードスプレー | 成功ログイン有無、対象ユーザー、送信元評価 | 送信元ブロック、セッション失効、本人確認 |
| MFA疲労攻撃 | 拒否後成功、端末、位置情報 | セッション失効、MFA再登録、ID一時停止 |
| 不審プロセス実行 | 端末、親子プロセス、ハッシュ、通信先 | 端末隔離、プロセス停止、検体保全 |
| クラウド権限変更 | 実行者、対象権限、直前ログイン | 権限ロールバック、鍵無効化、監査ログ保全 |
| 大量ダウンロード | 対象データ、利用者、業務妥当性 | 共有停止、アカウント制限、DLP確認 |
検知だけを先に作ると、SOCが毎回個別判断することになるのだ。検知ルールごとに初動、エスカレーション、封じ込め候補、証跡保全を紐付けるのだ。
初動確認
初動では、インシデント確定を急ぎすぎず、判断に必要な事実を短時間で揃えるのだ。
| 確認対象 | 見ること |
|---|---|
| 主体 | 対象ユーザー、特権ID、サービスアカウント、端末 |
| 送信元 | IP、国地域、ASN、VPN、既知拠点 |
| 対象 | システム、データ、権限、ファイル、API |
| 時系列 | 直前のログイン、MFA、権限変更、操作 |
| 業務文脈 | 作業予定、変更申請、保守、診断、例外承認 |
この段階で重要なのは、ログを追加で失わないことなのだ。必要に応じて対象ログの保全、チケット起票、関係者への確認を並行するのだ。
隔離判断
隔離は強いアクションなのだ。対象を止めることで被害拡大を防げますが、業務影響も発生するのだ。
| 隔離対象 | 候補アクション | 判断材料 |
|---|---|---|
| 端末 | EDR隔離、ネットワーク遮断 | 不審プロセス、C2通信、横展開兆候 |
| ID | セッション失効、ID一時停止、パスワードリセット | 不審ログイン、MFA突破、権限変更 |
| 通信 | IPブロック、URLブロック、DNSブロック | 送信元評価、通信先、影響範囲 |
| クラウド権限 | キー無効化、ロールバック、ポリシー削除 | 権限変更、API実行、監査ログ |
| 共有 | 外部共有停止、公開リンク停止 | 大量DL、外部公開、機密データ |
隔離条件は事前に決めるのだ。たとえば「特権IDの不審ログイン後に監査ログ無効化があれば即時封じ込め候補」のように、重大度とアクションを結び付けるのだ。
復旧確認
復旧では、単にサービスを戻すだけでは不十分なのだ。安全な状態へ戻ったことを説明できる必要があるのだ。
| 復旧対象 | 確認すること |
|---|---|
| 端末 | EDR検知解消、再スキャン、隔離解除条件 |
| ID | セッション失効、MFA再登録、権限見直し |
| クラウド | 不正キー削除、権限ロールバック、監査ログ有効化 |
| Web | 脆弱性修正、WAF暫定ルール、再診断 |
| SaaS | 共有停止、外部連携削除、管理者棚卸し |
復旧判断は、運用担当だけで閉じず、必要に応じてシステムオーナー、セキュリティ部門、法務、広報、監査と接続するのだ。
証跡保全
事後調査や説明責任に必要な証跡は、対応中に失われやすいのだ。
最低限、次を保全対象にするのだ。
| 証跡 | 例 |
|---|---|
| 検知ログ | アラート、相関条件、元イベント |
| 認証ログ | ログイン、MFA、セッション、送信元 |
| 端末ログ | プロセス、ファイル、通信、EDRイベント |
| クラウド監査ログ | API実行、権限変更、鍵作成、ログ設定 |
| 操作履歴 | チケット、承認、隔離、復旧、連絡履歴 |
| 外部連絡 | ベンダー照会、監督当局、顧客通知判断 |
証跡保全は、調査のためだけではないのだ。後から「なぜその判断をしたか」を説明するためにも必要なのだ。
SOC運用で見る指標
SOCの成熟度はログ量では測れないのだ。見るべき指標は、検知、判断、対応、復旧に関するものなのだ。
| 指標 | 意味 |
|---|---|
| MTTD | 検知までの時間 |
| MTTA | アラート確認開始までの時間 |
| MTTR | 復旧までの時間 |
| 誤検知率 | アラートのうち不要だった割合 |
| 見逃し率 | 後から判明した未検知インシデント |
| 証跡充足率 | 調査に必要なログが揃っていた割合 |
| 対応完了率 | アラートが放置されていないか |
特に、MTTDと証跡充足率は一緒に見るのだ。早く検知しても調査ログがなければ対応が止まり、ログが揃っていても検知が遅ければ被害が広がるのだ。
まとめ
SOCアクション設計では、検知後に誰が何を確認し、どの条件で隔離、復旧、証跡保全へ進むかを決めるのだ。
アラートを増やすことではなく、「何が起きた、だから何をする」へ変換することがSOC運用の中心なのだ。
実行前に決める権限と解除条件
上の対応表は著者のプレイブック設計案なのだ。検知しただけで各操作を自動実行する規則ではないのだ。隔離・失効・削除には、次の情報を対応単位で持たせるのだ。
| 記録項目 | 内容 |
|---|---|
| 実行権限 | 承認者、緊急権限、自動実行してよい条件 |
| 影響と保全 | 停止する業務、先に残す証拠、保全の担当 |
| 解除条件 | 侵害経路の対処、再発確認、解除承認者 |
| 結果と復旧 | 期待した状態、実際の結果、失敗時の戻し方 |
リスク管理とインシデント対応の関係はNIST SP 800-61 Rev.3を参照するのだ。個々の隔離条件・承認条件は対象組織が定めるものであり、以下の資料が本記事の表をそのまま指定しているわけではないのだ。