Ransomware感染端末の自動隔離 ― ただし人の承認を挟む
ランサムウェア感染端末の自動隔離には、誤操作を防ぐ承認境界が必要です。zcrSOARの実画面をもとに、承認ゲートの設計方法を解説していきます。
Ransomware感染端末の自動隔離 ― ただし人の承認を挟む
深夜2時半、アラートが上がります。経理部門の1台が異常な速度でファイルを上書きしており、シャドウコピーは消え、これまで一度も通信したことのないIPアドレスへの接続が発生しています。1分経つごとに暗号化されるファイルが増えていきます。
問われているのは一つだけです。この端末を、誰の判断も待たずにシステムが自動でネットワークから切り離してよいのか。
どちらの言い分にも理がある
「迷わず切れ、確認は要らない」という立場は間違っていません。今のランサムウェアは端末1台を数分で暗号化しきります。深夜3時に権限を持つ人が起きてボタンを押すのを待つのは、攻撃者に時間を献上しているのと同じです。しかもその端末が共有ファイルサーバーにアクセスできるなら、失われるのは1台分では済みません。
一方で、ためらう側にも理由があります。しかもそれは、自分が経験するまであまり語られない類の理由です。
端末の隔離は「試してみて違ったら戻す」で済む操作ではありません。切ってしまった端末が月次決算を回している端末だったら。工場チームが制御システムに入るために使っている踏み台サーバーだったら。そこで発生するダウンタイムは、攻撃者ではなく自分たちが作り出したものです。そして翌朝、事業部門から「誰の許可でやったのか」という問い合わせが来ます。
日本でもタイでも、この問題を必要以上に難しくしているのは資産情報の不備です。EDRコンソール上のホスト名と、情シスが普段呼んでいる名前が一致していない。だからいざという時、アラートに出ているそのホスト名が誰の端末で今何をしているのか、誰も断言できません。
実務で機能する線引きは「戻せるか、戻しにくいか」
「自動化か手動か」で議論する代わりに、問いを変えてみてください。この操作を誤って実行した場合、どれくらい簡単に元へ戻せるのか。
戻せる操作は、最後まで自動で走らせる。 プロセスツリーの取得、手持ちのIOCリストとのハッシュ照合、直近の通信相手の洗い出し、関連ログのケースへの集約、深刻度のタグ付け、チームへの通知。これらはすべて「読む」と「集める」の作業です。間違えてもマシンリソースを無駄にするだけで、誰も困りません。そして人間がやるとマシンの何倍も時間がかかる種類の作業でもあります。
戻しにくい操作には、人を挟む。 ネットワークからの切り離し、ADアカウントの無効化、境界でのIPブロック、実行中プロセスの強制終了。この4つは実在の人と実在の業務に影響し、気が変わったからといってきれいに復旧するとは限りません。
これをグラフとしてどう組むか ― 自動で走るActionノードと、実行を止めるApprovalノードの関係 ― はSOARにおけるagentic automationで扱っているので、ここでは繰り返しません。この記事で見たいのは、承認依頼が上がった 後 に何が起きるかです。
言い換えれば、自動化は扉の手前まで一気に走らせ、あとは押すだけの状態を整えてから止まる、という設計です。到着した担当者はゼロから調査を始める必要がなく、システムが用意したものを読んで判断するだけで済みます。そしてその扉は、誰が申請したのか、どの権限が必要な依頼なのか、どれだけ待たされているのかが記録される本物である必要があります。zcrSOARがそれを口約束ではなく画面上の仕組みとして持っているのは、この部分です。
2つの設計を分けるのは「人が判断に使う時間」であって、「自動実行されるアクションの数」ではありません。アナリストがケースを開いてから、何かを押す決心がつくまでにさらに20分の調査が必要なら、その自動化は止まるのが遅すぎたのではなく、早すぎたということです。
承認ゲートが実際に人の手元に現れたときの姿
zcrSOARのApprovals & tasks画面は、人の判断を待っているものを、Case approvals、Playbook steps、Revisions、Response actions、Human tasksというタブに分けて集約します。Case approvalsタブでは、承認待ちのケース単位の依頼が1件ずつカードとして並びます。デモはサンプルデータで動いているため、画面上の値はこの記事では引用しません。大事なのは、カード1枚に何が載っているかです。1枚をじっくり読んでみます。
- ケース名とケースID、そしてどの状態への遷移を求める依頼かを示すTRANSITIONラベル。たとえばCONTAINED → CLOSED
- 依頼の理由を書いた1行。たとえば、封じ込めが確認できたのでクローズを申請する、という内容
- 申請者（
requested by）、滞留時間（waiting）、SLAの時間、そして依頼に必要な権限（REQUIRED: OPERATORまたはREQUIRED: ADMIN）
- 同じカード上でRejectがApproveの隣に並んでいます。つまり「承認しない」が通常の選択肢として置かれており、わざわざ探しに行く必要がありません
- 一覧の上の1行で、キューを開いている人がこのキューの承認を決裁できるかどうかが示されます
種類の異なるケースが、必要な権限も異なるまま同じ一つのキューに並びます。つまりこのゲートはランサムウェア専用のものではありません。ただし、どの種類のケースにどの権限を割り当てるのかをどこで設定するのかは、この画面には出てきません。
カード1枚に載っているこの4点は、監査で聞かれたときにセキュリティチームが答えられないことが多い項目そのものです。
- 誰が申請したか ―
requested by が申請者を示しており、「システムがやりました」ではない
- その依頼にどの権限が要るか ―
REQUIRED: OPERATOR や REQUIRED: ADMIN は依頼そのものに記録されている。一方、いま画面を見ている人がどれを押せるかは一覧の上の別の1行が示す。つまりカードは「必要な権限」を記録し、閲覧者に何ができるかはシステム側が突き合わせて判断している
- どれだけ滞留しているか ―
waiting が画面上に出ており、ログを掘る必要がない
- 残り時間が分かる ― SLAの数字は、SLA超過までの残り時間であり、経過時間ではない。依頼が滞留するほど、この数字は小さくなる
3と4こそ、多くの承認プロセスが静かに破綻する箇所です。ゲートが無いからではなく、ゲートが「仕事が溜まっているのに溜まっていることに誰も気づかない場所」になるからです。誰かの受信箱で承認依頼が3日間放置され、誰も催促していない光景に心当たりのある方も多いはずです。
この画面がまだ語っていないことを正直に書いておきます
タブの見出しのすぐ下には "Case-level state-transition approvals — distinct from playbook-step approvals." と明記されています。つまりこれはケースの状態遷移に対する承認であり、たとえば封じ込めが確認済みになった後のクローズ申請がそれにあたります。隔離を実行する瞬間の「isolateしてよいか」という承認ではありません。
アクションそのもののゲートは別種の承認で、専用のタブがあります。Playbook stepsタブは、それを止まっている自動化に対する人の判断ゲートとして表示します。承認すれば止まっていた実行が再開し、却下すれば実行は終了し、画面は証拠を確認してから判断するよう促しています。この記事はそのタブには踏み込まないため、その依頼がどう振り分けられ、誰が決裁できるのかについては、ここで書けることはこれ以上ありません。
もう一つ、この画面からは分からないことがあります。SLAを使い切った後どうなるのか ― 次の担当者へエスカレーションするのか、そのまま滞留するのか、自動承認されるのか。この画面では確認できません。実運用に載せるなら事前に確認すべき点です。この挙動の違いこそが、安全なゲートと、単に全体を遅くするだけのゲートを分けるからです。
自社に当てはまるかを判断するサイン
- 隔離を実行できるEDRはあるが、誤って別の端末を切る事故が怖くて自動モードを有効にできない
- 権限を持つ担当者が起きるのを待ったせいで、封じ込めの判断が遅れた事案がある
- 直近の隔離を誰が何時に承認したのか答えられない
- 承認依頼がチャットのグループやメールにあり、本人性と時刻が記録される仕組みの中にない
- 「絶対に切ってはいけない」端末群があるが、その取り決めが人の頭の中にしかない
2つ以上当てはまるなら、課題は自動化の不足ではありません。判断そのものに定位置が無いということです。
3つのアプローチを率直に比較する
| アプローチ | 向いている組織 | 支払う代償 |
|---|
| 完全自動 | 資産情報が正確で、切ってよい端末が明確に分かっている組織 | 誤隔離が1回起きるだけで、事業側から自動封じ込めの全面停止を指示されうる |
| ゲートまで自動、最後は人が押す | チームは小さいが止められない重要システムを抱える、大多数の組織 | 人が判断に使う時間はそのままかかる。受け手が実在している必要がある |
| 完全手動 | これから着手する段階で、まだ何も連携していない組織 | 最も遅く、誰がいつ何をしたかの証跡が残らないことが多い |
どれが正解かは組織によって変わります。ただ、判断を誤ったときの被害が最も小さい出発点は中間案であることが多いはずです。この運用を作るだけの規模かどうかは、zcrSOARのプランと併せて考えてみてください。
関連記事
承認キューにケースが溜まる前に、まず検知できていなければ話が始まりません。何を拾うべきかはSIEMによるランサムウェア検知をご覧ください。1つのケースが細かなイベントからどう組み上がるのかはMITRE ATT&CKに沿ったattack flowの読み方で扱っています。SOARとSIEMの境界がまだ曖昧な方は、SOARとは何かから始めるのがおすすめです。
お問い合わせ
自社の封じ込めワークフローで、どこを自動にしてどこに人を挟むべきか。お気軽にご相談ください。無料でご相談いただけます。
出典
- Splunk SURGe — Gone in 52 Seconds…and 42 Minutes: A Comparative Analysis of Ransomware Encryption Speed — 実在するransomware10種を実測。最速のLockBitは約10万ファイルを4分9秒で暗号化しており、本記事の「数分で暗号化できる」という記述を裏付ける
- MITRE ATT&CK — T1490 Inhibit System Recovery — 冒頭で触れているshadow copy削除に対応するTechnique