アスクルへの攻撃で犯行声明が出た点は、攻撃が技術問題に留まらず「交渉・心理戦」へ拡張していることを示します。暗号化で止めるだけでなく、窃取データの公開を材料に支払いを迫る二重恐喝が前提になりつつあります。情シスは復旧可否だけで安心せず、「漏えいを梃子にされる」局面を想定した対応計画を持つ必要があります。
また声明は、取引先や顧客の不安を増幅させ、広報・法務・経営判断を揺さぶる目的もあります。攻撃者にとっては“成功の宣伝”にもなり、次の標的への圧力として機能します。よって、初動から対外説明までを一体のインシデントとして扱うことが重要です。
受発注、在庫、配送、決済、会員基盤を持つ企業は、停止の影響が即時に顕在化し「止める価値が高い」標的になります。加えて、取引履歴や請求・配送情報などの集積は窃取データの価値を高めます。バックアップがあっても、公開脅迫により交渉を強制され得る点が厄介です。
さらに決済、倉庫、配送、コールセンター、SaaSなど外部連携が多く、サプライチェーン全体で攻撃面が広がります。自社の堅牢化だけでは不十分で、委託先アカウントやリモート保守経路、API権限まで含めた棚卸しが必須です。契約上の通知義務やログ提供、脆弱性対応SLAも具体化しておくべきです。
最初に避けたいのは、現場判断で停止やログ削除を行い、証拠と復旧の両方を損なうことです。優先順位は封じ込め、証拠保全、指揮系統の確立の順で整えると実務上ブレにくくなります。止められない系統は、セグメント分離やアクセス制御の強化で被害拡大を抑えます。
同時に「いつ侵入されたか」「何が持ち出されたか」「影響範囲はどこまでか」をフォレンジックで詰め、説明責任に耐えるタイムラインを作ります。攻撃者との接触可否、公開情報の範囲、顧客対応方針は会社として統一が必要です。ITだけで完結せず、法務・広報・経営を含む意思決定体制を平時から用意します。
再発防止は「侵入をゼロにする」より「侵入されても致命傷にしない」設計が現実的です。MFAの徹底、特権IDの日常利用禁止、PAMやジャストインタイム権限で横展開を抑えます。EDR/XDRは導入だけでなく、ログの保持期間・粒度、改ざん耐性（WORM等）を含めた運用設計が要点です。
バックアップは隔離（オフライン/イミュータブル）とアカウント分離、復旧訓練までセットで成立します。RTO/RPOを事業部と合意し、復旧優先順位を明確にしておくことが交渉圧力への耐性になります。声明が出た時点で攻撃は終わっていない前提で、技術・法務・広報を束ねた総合対応力を高めることが、情シスの重要課題です。
