ランサムウェア対応で AI Agent が最初に自動化すべきこと
ランサムウェア対応では誤操作が証拠を壊し、被害範囲を広げます。AI Agentは調整と証拠収集から始め、対応の権限は段階的に広げていきます。
ランサムウェア対応で AI Agent が最初に自動化すべきこと
ランサムウェア対応では速度が重要ですが、誤操作は証拠を壊し停止範囲を広げます。まず調整と証拠収集から始め、制御された対応へ進みます。
最初に全体像を作る
影響資産、ID 活動、タイムライン、指標、バックアップ状態をレビュー可能な画面にまとめます。
範囲を限定した操作を調整する
隔離候補、チケット更新、関係者向け要約、証拠チェックリストを準備し、破壊的操作は承認制にします。
封じ込め後に学ぶ
タイムラインと control gap をまとめ、確認済みの finding を検知と playbook 改善へ反映します。
手順の順序は「誤操作のコスト」で決める
CISA の #StopRansomware Guide は、封じ込めで何を天秤にかけるかの例を示しています。影響を受けたシステムを直ちに隔離し、複数のサブネットが影響を受けているとみられる場合はスイッチ単位でネットワークを切り離し、電源断はネットワークから切り離せない場合に限ります。電源を落とすと揮発性メモリ上の証拠が失われるためです。
ランサムウェアでは、誤操作の代償が停止と証拠の喪失の二重になり、判断を待つ間も時間は進みます。そこで手順ごとに区分を決めます。読み取り専用の手順と証拠の複製はアラートが届いた時点で実行し、元に戻せる変更はあらかじめ指名した承認者を待ち、本番環境に影響して元に戻せない手順や、法務・事業上の責任を伴う手順は人が担当します。この並びは推奨パターンであり、CISA の順序（隔離から始まる）そのものではありません。
元に戻せる度合いで並べた手順書
表の行番号はリスクによる区分であり、実行順の待ち行列ではありません。暗号化のアラートが上がったら、端末を確認できた時点で行 6 の承認依頼をすぐに出し、行 1〜5 の結果は承認材料として並行して追加します。
| 手順 | 元に戻せるか | ゲート設定（推奨） | 先に保全する証拠 |
|---|
| 1. 範囲の把握：端末、アカウント、アラートの背後にある検知 | 読み取りのみ | Autonomous | 元のアラート、event ID、時刻 |
| 2. 復旧手段の確認：バックアップ、シャドウコピー、vssadmin・wbadmin・bcdedit の不審な使用 | 読み取りのみ | Autonomous | バックアップジョブ履歴と、最初に見た時点のカタログ |
| 3. 侵入経路の調査：新規作成または権限が昇格したアカウント、不審な VPN ログイン、リモート管理ツール | 読み取りのみ | Autonomous | 認証ログと VPN ログ（発生元とは別に複製） |
| 4. データ流出の調査：異常な送信量、Rclone、Web ストレージ宛ての通信 | 読み取りのみ | Autonomous | ファイアウォールとプロキシのログ（上書きされる前にエクスポート） |
| 5. 証拠を保護された保管先へ複製し、ケースを起票し、インシデント対応責任者へ通知 | 複製は可。送信済みの通知は戻せない | Autonomous | インシデント記録（クエリ、結果、実行者） |
| 6. 影響が確認された端末を、使用中の EDR の connector で隔離 | 可（解除）。止まった時間は戻らない | Approval | 先にエクスポートした EDR の検知、プロセスツリー、通信。対応していればメモリ取得 |
| 7. 確認済みの C2・流出先をファイアウォールでブロック | 可。使用中のサービスを止める恐れ | Approval | ファイアウォールログのエクスポート、出典つきの指標 |
| 8. 攻撃者のアカウントを無効化し、セッションを破棄し、リモートアクセスを閉じる | 再有効化は可。破棄したセッションは戻らない | Approval | サインインログ、セッション、所属グループ |
| 9. ホストのシャットダウン・電源断 | 不可（メモリが失われる） | Blocked | 代表ホストのメモリ取得 |
| 10. オフラインバックアップからの復旧・再構築 | 上書き後は戻しにくい | Blocked | 最初の侵害の兆候とバックアップ日時の突き合わせ、ドロッパー型マルウェアの確認 |
| 11. 身代金の判断 | 不可 | Blocked | 受け取ったままの脅迫文、法執行機関からの情報（復号ツールの有無を含む） |
| 12. 顧客・規制当局・保険会社・報道への外部連絡 | 不可 | Blocked | 承認済みの事実一覧（判明分と未判明分） |
Approval の行の前に、agent は材料をそろえます。資産台帳と照合した対象、変更内容、保全済みの証拠、解除手順です。
推奨パターン（Human-in-the-Loop SOC の承認マトリクスに沿った運用）：行 6〜8 で承認者が 1 名で足りるのは、影響の小さい本番以外の端末 1 台、または一般ユーザーのアカウント 1 つに限ります。それより広い場合は、異なる役割の 2 名の承認を取ります。本番環境や重要資産、特権・役員・サービスアカウント、共用基盤（行 7 のファイアウォールでのブロックを含む）、複数の対象が該当します。承認者ごとに待機中の代行者と電話での呼び出し手段を用意し、手順の省略は、インシデントの前にリスクオーナーが記録した判断に限ります。行 6〜8 はまとめて依頼します。CISA の足並みをそろえた隔離に沿った考え方ですが、行 7・8 が整わないからといって行 6 を止めてはいけません。
zcr が文書で示す範囲と、お客様側の設定
文書に記載された機能：zcrSOAR は playbook の各ステップを Autonomous、Approval、Blocked のいずれかに設定でき、承認依頼を重大度・資産・拠点で振り分けます。connector 経由でエンドポイントを隔離・解除できます（文書の例は SentinelOne）。標準の playbook は phishing、malware、brute-force、C2 isolation で、未承認の playbook は、組織が本番実行を認めるまで Draft、Test、Dry-run、Simulation Mode にとどまります。zcrSIEM はランサムウェアを含む検知ルールを標準で備えますが、SOAR は含みません。
推奨パターン：この手順書はカスタム playbook として作成するか、malware または C2 isolation の playbook を調整し、まず Dry-run で確認します。行 9〜12 は Blocked にして、人が作業します。
お客様側の設定：バックアップ基盤との連携（行 2。connector がなければ独自の連携）、メモリ取得ツール、証拠の保管先、EDR・Active Directory・ID プロバイダー・ファイアウォールの操作（行 6〜8。各 connector にできることは事前に確認）、承認者の指名、別経路（アウトオブバンド）の連絡手段です。
自動化した対応が破綻する場面と、引き継ぐ担当者
攻撃者に気づかれない CISA は、足並みをそろえた隔離と、電話などの別経路での連絡を勧めています。検知に気づいた攻撃者が、先に横展開したりランサムウェアを広く展開したりする恐れがあるためです。メールや Teams で送る承認依頼は、そのアカウントが侵害済みなら読まれるかもしれません。zcrSOAR の文書に、別経路として説明されている通知チャネルはありません。そのため、電話か、お客様側で接続する呼び出しサービスを使います（お客様側の設定）。
攻撃者の文字列はデータとして扱う 脅迫文、ファイル名、ログのフィールドは攻撃者が書けます。細工された名前や文面は、命令として読むモデルを誘導し得ます。対象は構造化フィールドから取り、資産台帳と照合したものに限ります（推奨パターン）。
復旧を急がない CISA は、ランサムウェアが過去の未解決の侵害の兆候である可能性を指摘し、バックアップから再構築する前にドロッパー型マルウェアを見つけるよう求めています。
次のいずれかを見つけたら、agent は作業を止め、ケースをインシデント対応責任者へ渡します。
- 範囲内の端末が報告を止めた（データの空白として扱う）
- 対象にドメインコントローラー、ID プロバイダー、ハイパーバイザー、バックアップサーバー、範囲外の端末が含まれる
- 復旧手段の確認で、カタログの削除やバックアップジョブの停止が見つかる
- 依頼から承認までの間に対象の数が増える
- データ流出が見つかる（通知義務が発生し得るため）
- 隔離の実行が失敗またはタイムアウトする、または承認依頼が決めておいた待ち時間を過ぎても未回答である（無回答は承認とみなさない）
よくある質問
agent が頼る仕組みが止まったり暗号化されたりしたら？
行 6〜8 の手動版を用意し、EDR、ディレクトリ、ファイアウォールの各コンソールから、複数のサブネットが影響を受けた場合はスイッチ単位の切り離しで実行できるようにします。同じ指名済みの承認者と演習しておきます（推奨パターン）。
ファイルが暗号化されている最中に、agent が端末を隔離してよいですか？
Approval から始めるのが推奨パターンです。影響の小さい限られた端末群を無人で隔離するかどうかは、リスクオーナーが決める事項で、AI 支援 SOC と Autonomous SOCの基準を満たした場合に限ります。基準とは、可逆で、見直し期間を通じて承認付きで運用し、後から取り消した承認がなく、元に戻す手順を試験していることです。Dry-run の結果だけでは基準を満たしません。CISA が直ちに隔離するよう求めているため、承認を外すのではなく、承認の手順を速くします。
zcrSIEM や zcrMDR にこの対応を任せられますか？
zcrSIEM は検知と調査を担い、自動 playbook、承認、封じ込めは zcrSOAR の役割です。zcrMDR は承認済みのチャネルパートナーを通じて提供されるマネージドサービスで、対応操作と対応時間帯はサービスレベルと契約で定まります。
出典
続き: Autonomous SOC の限界、Human-in-the-Loop SOC、Ransomware感染端末の自動隔離 ― ただし人の承認を挟む、AI SOC Agent ガイド
zcrMDR を見る · 料金を見る · zcr に相談
自社の環境についてのご相談は、こちらへどうぞ。
