0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ASKULのランサムウェアインシデントレポートをAIと分解して分かった“良い報告書”の構成

0
Posted at

0. 調べようと思ったきっかけ

  • ASKUL のランサムウェアインシデント対応レポートが非常にわかりやすかった
  • 文書の構造や、どのポイントを押さえて書かれているのか気になった

参照:https://pdf.irpocket.com/C0032/PDLX/O3bg/N4O3.pdf

1. この記事を公開しようと思った理由

今回の内容は生成AIによる出力が中心なので、当初は公開するほどではないかなと思っていました。
しかし、最終形にたどり着くまでに約30分ほど試行錯誤したため、その時間を誰かが節約できるなら公開する価値はあると判断しました。

2. 生成AIの出力内容

それでは、生成AIによる出力内容(一部人による微修正)を紹介します。

全体俯瞰:セクション間のつながり

各セクションは独立しているようで、論理的につながっています:

セクション1(謝罪) → セクション2(事実) → セクション3(被害)
     ↓
「何が起きたか」が分かったところで...
     ↓
セクション4(原因):「なぜ起きたか」を説明
     ↓
「原因が分かったから対策できる」という流れで...
     ↓
セクション5(復旧) → セクション6(再発防止) → セクション7(ガバナンス)
     ↓
「対策を実行する」と約束したので...
     ↓
セクション8(情報公開):「継続的に報告します」と約束
     ↓
「専門用語が分からない人のために」
     ↓
セクション9(用語集)
     ↓
「今までもちゃんと報告してきた証拠」
     ↓
セクション10(発表履歴)

このように、各セクションが「Why(なぜ) → What(何を) → How(どう)」の論理展開でつながっています。

1. 冒頭文と代表者メッセージ

📌 このセクションの役割

「会社のトップが、事態をどう受け止めているか」を示す最重要セクション

💡 分かりやすく言うと

  • 「何が起きたのか」の第一報
  • 社長が「本当に申し訳ありません」と頭を下げる場面
  • 「うちの会社は真剣に受け止めています」という姿勢の表明

👥 読み手が知りたいこと

  • 「どれくらい深刻な事態なのか?」
  • 「会社は本気で反省しているのか?」
  • 「今後ちゃんと対応してくれるのか?」

📝 具体的には何を書くか

  • インシデント発生日と簡潔な事象説明
  • 影響を受けた人たち(顧客・取引先など)への謝罪
  • 社長自身の言葉による決意表明
  • この報告書が「隠さず全部説明する」ためのものだという宣言
  • 他の会社にも役立ててほしいという社会貢献の姿勢

⚠️ なぜこれが最初に必要か

危機対応の鉄則は「トップが前に出る」こと。社長の顔が見えない報告書は、「逃げている」と受け取られ、信頼を失います。


2. インシデントの全容

📌 このセクションの役割

「いつ、何が起きて、どう対処したか」を時系列で整理する事実記録

💡 分かりやすく言うと

  • サイバー攻撃の「事件の経過報告」
  • 「10月19日の朝に異常を発見して、すぐにネットワークを切断しました」というような、時間順の説明
  • 警察に届けた犯罪被害の「被害届」のようなもの

👥 読み手が知りたいこと

  • 「いつ攻撃されたのか?」
  • 「会社はすぐに対応したのか?」
  • 「今はどうなっているのか?」(復旧状況)

📝 具体的には何を書くか

  • 発生時: 攻撃を検知した日時と最初の対応
  • 初動対応: ネットワークの緊急遮断、パスワードの一斉変更など
  • 調査開始: 外部の専門家(フォレンジック調査会社など)への依頼
  • 追加被害: その後に発覚した不正アクセスや情報流出
  • 復旧開始: サービス再開に向けた段階的な取り組み
  • 現在: 本報告書発表時点での状況

⚠️ なぜこれが必要か

時系列を明確にすることで、「会社が迅速に対応したこと」「隠蔽していないこと」を証明します。また、後から「なぜもっと早く対応しなかったのか」という批判に対する証拠にもなります。


3. 被害の範囲と影響

📌 このセクションの役割

「誰に、どんな被害が出たか」を定量的に示す影響報告

💡 分かりやすく言うと

  • 「どんな被害が出たのか」の全体像
  • 情報漏洩なら「何人分の個人情報が流出したか」
  • サービス停止なら「どのくらい売上が減ったか」
  • 被害を「数字」で示すことで、深刻度を明確にする

👥 読み手が知りたいこと

  • 顧客: 「自分の個人情報は漏れたのか?」
  • 取引先: 「取引情報は大丈夫か?」
  • 株主: 「会社の業績にどれくらい影響するのか?」
  • 社員: 「自分の人事情報は守られているか?」

📝 具体的には何を書くか

3-1. 情報流出の詳細

  • 流出した個人情報の件数(「顧客59万件、取引先1.5万件」など)
  • カテゴリ別の内訳(氏名、住所、電話番号など)
  • 流出していない情報の明記(「クレジットカード情報は保有していないので流出なし」など)
  • 該当者への個別通知の実施状況

3-2. システムへの影響

  • 暗号化されたシステムの範囲(「物流システム全停止」など)
  • 侵害されなかったシステム(「ECサイトは無事」など)
  • サービス停止の期間と範囲
  • 図解やイラストで視覚的に説明

3-3. 業績への影響

  • サービス停止による売上機会損失(「約〇〇億円」など)
  • システム復旧費用(専門家への委託費用など)
  • セキュリティ強化の投資額
  • 株価への影響(上場企業の場合)

⚠️ なぜこれが必要か

被害の全体像を数字で示すことで、「隠していない」という透明性を示します。また、該当者への通知を実施していることを明記することで、「被害者への配慮がある」ことを示します。


4. 攻撃手法と原因分析

📌 このセクションの役割

「どうやって攻撃されたか」と「なぜ防げなかったか」を一体的に説明する原因究明

💡 分かりやすく言うと

  • 泥棒が「どうやって家に侵入したか」(攻撃手法)
  • そして「なぜ鍵が破られたのか」(原因分析)を説明
  • 攻撃の手口を知ることで、「次は同じ手は通用しない」対策につながる

👥 読み手が知りたいこと

  • 「なぜこんなことが起きたのか?」
  • 「会社のセキュリティはザルだったのか?」
  • 「本当のところ、何が問題だったのか?」

📝 具体的には何を書くか

4-1. 攻撃の手法

  • 初期侵入: 攻撃者がどうやって最初にシステムに入り込んだか
    • 例:「業務委託先のパスワードが盗まれて不正ログインされた」
  • 侵入拡大: 中に入った後、どうやって権限を奪ったか
    • 例:「セキュリティソフトを無効化して、複数のサーバに侵入」
  • 攻撃実行: 最終的にどんな攻撃をしたか
    • 例:「ランサムウェアを展開してデータを暗号化、バックアップも削除」
  • 攻撃タイムライン: 図解で「いつ、何が起きたか」を視覚化

4-2. 根本原因分析(なぜ防げなかったか)

  • 不正アクセスを許した原因
    • 例:「業務委託先のアカウントに二段階認証を設定していなかった」
    • 例:「管理者権限が適切に管理されていなかった」
  • 侵入を早期発見できなかった原因
    • 例:「24時間監視体制がなかった」
    • 例:「セキュリティソフトが一部のサーバに導入されていなかった」
  • 復旧が長期化した原因
    • 例:「バックアップが同じ場所にあり、一緒に暗号化された」
    • 例:「ランサムウェア攻撃を想定した復旧計画がなかった」

⚠️ なぜこれが必要か

「どう攻撃されたか」だけでなく「なぜ防げなかったか」を正直に認めることで、「自社の課題を理解している」ことを示します。原因を認めない企業は、再発防止策も信用されません。


5. システムの復旧と安全性確保

📌 このセクションの役割

「もう安全です」を証明する復旧報告

💡 分かりやすく言うと

  • 「壊れた家を修理して、新しい鍵に交換しました」という報告
  • 「攻撃者は完全に追い出しました」という安全宣言
  • 外部の専門家のお墨付きをもらって、「本当に安全」を証明

👥 読み手が知りたいこと

  • 「もう安全なのか?」
  • 「また攻撃されないのか?」
  • 「サービスを使っても大丈夫なのか?」

📝 具体的には何を書くか

  • 徹底的なクリーン化: 感染した可能性のある機器を全てチェックし、怪しいものは廃棄またはゼロから再構築
  • 新環境での再構築: 部分的な修理ではなく、安全が確認された新しい環境を一から構築
  • 外部専門家による検証: 自社だけでなく、第三者の専門家に安全性を確認してもらった
  • 残存脅威なしの確認: 「攻撃者の痕跡は完全に消えた」ことを明記

⚠️ なぜこれが必要か

顧客や取引先は「もう安全なのか」を最も知りたがっています。「安全です」と言うだけでなく、「第三者の専門家がチェックして安全を確認した」という客観的証拠を示すことで、信頼が回復します。


6. 再発防止策と強化ロードマップ

📌 このセクションの役割

「今後どうするか」を短期・中期・長期で具体的に示す行動計画

💡 分かりやすく言うと

  • 「同じ失敗を繰り返さない」ための具体的な対策リスト
  • 「すぐやること」「数か月かけてやること」「継続的にやること」に分けて説明
  • 単なる「頑張ります」ではなく、「いつまでに、何を、どうやるか」を明確に

👥 読み手が知りたいこと

  • 「本当に再発しないのか?」
  • 「具体的に何をするのか?」
  • 「いつまでに対策が完了するのか?」

📝 具体的には何を書くか

6-1. 短期対策(発生~1か月):緊急対応

  • 全てのリモートアクセスに二段階認証を導入
  • 管理者権限を厳格に管理(誰がどの権限を持つか明確化)
  • セキュリティソフト(EDR)を全てのサーバに導入
  • 24時間365日の監視体制を構築
  • 社員とパートナー企業への緊急セキュリティ教育

例え: 泥棒に入られた直後に、すぐ鍵を交換して防犯カメラを設置するイメージ

6-2. 中期対策(~6か月):仕組みの強化

  • クラウドサービスの監視システムを高度化
  • セキュリティ監視センター(SOC)の運用高度化
  • ランサムウェア対策専用のバックアップシステム構築
  • 全社員向けセキュリティ研修プログラムの実施
  • 定期的な模擬攻撃訓練の実施

例え: 鍵を二重ロックにして、警備会社との契約を結ぶイメージ

6-3. 長期対策(6か月~):継続的改善

  • 国際基準(NIST等)に基づく定期的なセキュリティ評価
  • 事業継続計画(BCP)の見直しと訓練
  • 外部専門機関による年次セキュリティ診断
  • 最新の脅威に対応した継続的な対策アップデート

例え: 定期的に防犯診断を受けて、常に最新の防犯設備に更新し続けるイメージ

⚠️ なぜこれが必要か

「再発防止します」という言葉だけでは信用されません。「いつまでに、何を、どうやるか」を具体的に示すことで、「本気で取り組んでいる」ことが伝わります。また、3段階に分けることで、「今すぐできること」と「時間をかけて取り組むこと」を区別し、現実的な計画であることを示します。


7. ガバナンス体制の再構築

📌 このセクションの役割

「経営レベルでセキュリティを管理する」体制づくりの宣言

💡 分かりやすく言うと

  • セキュリティを「IT部門だけの問題」ではなく「経営の最重要課題」に格上げ
  • 社長直轄のセキュリティ責任者(CISO)を置く
  • 取締役会で毎月セキュリティ状況を報告する仕組み
  • 「セキュリティは会社全体の問題」という意識改革

👥 読み手が知りたいこと

  • 「経営陣は真剣に取り組んでいるのか?」
  • 「IT部門に丸投げしていないか?」
  • 「セキュリティにお金をケチっていないか?」

📝 具体的には何を書くか

  • CISO(最高情報セキュリティ責任者)の設置: セキュリティ専門の役員を置く
  • 取締役会への定期報告: 毎月の取締役会でセキュリティ状況を報告
  • 各部門の責任者明確化: 営業、製造、経理など、全部門にセキュリティ担当を配置
  • セキュリティ予算の確保: セキュリティ投資を経営判断として優先順位付け
  • リスク管理委員会の設置: セキュリティリスクを経営リスクとして管理

⚠️ なぜこれが必要か

技術的な対策だけでは不十分です。「経営層がセキュリティを経営課題として認識している」ことを示すことで、「会社の体質が変わった」ことを証明します。これは投資家や取引先が最も重視するポイントです。


8. 情報公開方針とステークホルダー対応

📌 このセクションの役割

「透明性」と「継続的なコミュニケーション」のコミットメント

💡 分かりやすく言うと

  • 「隠さず、嘘つかず、逃げない」という姿勢の表明
  • 「身代金は払いません」という犯罪者に屈しない宣言
  • 「困ったことがあったら相談してください」という窓口の案内
  • 「他社にも情報共有して、社会全体で防ぎます」という貢献の約束

👥 読み手が知りたいこと

  • 「会社は隠していないか?」
  • 「身代金を払って犯罪を助長していないか?」
  • 「何かあったら相談できるのか?」
  • 「今後も情報を教えてくれるのか?」

📝 具体的には何を書くか

8-1. 身代金不払いの方針

  • 攻撃者とは一切接触・交渉していない
  • 身代金は1円も払っていない
  • 犯罪行為を助長しないという社会的責任

8-2. 情報開示の原則

  • 事実に基づく透明性の高い情報発信
  • 新しい事実が判明したら速やかに開示
  • ただし、二次被害防止のため一部詳細は非公開にする理由を説明

8-3. 外部連携

  • 警察への被害届提出
  • 個人情報保護委員会への報告
  • セキュリティ専門機関(JPCERT/CC等)への情報提供で社会貢献
  • 取引先への適切な情報共有

8-4. お問い合わせ窓口

  • 情報流出専用の電話・メール窓口
  • 受付時間と連絡先の明記
  • 投資家向け(IR)、報道機関向けの窓口も別途用意

⚠️ なぜこれが必要か

危機対応で最も重要なのは「透明性」です。隠したり嘘をついたりすると、後で発覚した時に信頼が完全に失われます。また、「身代金を払わない」と明言することで、「犯罪者に屈しない」という社会的責任を果たします。


9. 用語集と技術解説

📌 このセクションの役割

専門用語を素人にも分かるように説明する用語辞典

💡 分かりやすく言うと

  • 報告書に出てくる難しい言葉(ランサムウェア、EDR、MFAなど)を簡単に説明
  • 図解やイラストで攻撃の仕組みを視覚的に説明
  • 「IT用語が分からない」という読み手への配慮

👥 読み手が知りたいこと

  • 「ランサムウェアって何?」
  • 「EDRって何の略?」
  • 「MFAって何をするもの?」

📝 具体的には何を書くか

  • ランサムウェア: データを暗号化して身代金を要求する犯罪プログラム
  • EDR: パソコンやサーバを監視して、怪しい動きを検知するセキュリティソフト
  • MFA(多要素認証): パスワードだけでなく、スマホの確認コードなど複数の方法で本人確認すること
  • SOC: 24時間365日でセキュリティを監視する専門チーム
  • フォレンジック: デジタル機器を詳しく調査して、証拠を集める技術
  • BCP: 災害や事故が起きても事業を継続するための計画
  • NIST: アメリカの政府機関が作った、世界的に使われているセキュリティの基準
  • 攻撃の流れ: 図解で「侵入→偵察→拡大→攻撃→窃取→公開」を視覚化

⚠️ なぜこれが必要か

報告書は技術者だけでなく、一般の顧客や株主も読みます。専門用語だらけで理解できない報告書は、「わざと難しくして誤魔化している」と受け取られます。用語集を付けることで、「誰にでも理解してもらおうとしている」誠意が伝わります。


10. これまでの発表履歴

📌 このセクションの役割

継続的な情報開示の証跡記録

💡 分かりやすく言うと

  • 「いつ、何を発表したか」の一覧表
  • 「第1報、第2報...」と継続的に情報を出してきた証拠
  • 「隠さず、小出しにせず、タイムリーに開示してきた」ことの証明

👥 読み手が知りたいこと

  • 「いつから問題を公表していたのか?」
  • 「情報を小出しにしていないか?」
  • 「継続的に状況を報告しているか?」

📝 具体的には何を書くか

  • 第1報:インシデント発生の第一報(日付・タイトル)
  • 第2報:調査状況の中間報告
  • 第3報:サービス復旧の進捗報告
  • 第4報:情報流出の確認報告
  • ...(以降、発表した全ての報告書を時系列で列挙)
  • 各報告の主な内容サマリー

⚠️ なぜこれが必要か

「今まで何も言っていなかったのに、突然詳細な報告書を出す」と、「隠していた」と疑われます。継続的に情報を開示してきた履歴を示すことで、「透明性を保ってきた」ことを証明します。


📊 全10セクションの構成ロジック

【全体の流れ】読み手の疑問に順序立てて答える構成

❓「何が起きたの?」
   → 1. 冒頭文と代表者メッセージ(概要と謝罪)
   → 2. インシデントの全容(時系列の事実)

❓「どんな被害が出たの?」
   → 3. 被害の範囲と影響(定量的な影響報告)

❓「なぜこんなことが起きたの?」
   → 4. 攻撃手法と原因分析(手口と原因)

❓「もう安全なの?」
   → 5. システムの復旧と安全性確保(安全宣言)

❓「今後どうするの?」
   → 6. 再発防止策と強化ロードマップ(具体的対策)
   → 7. ガバナンス体制の再構築(経営の本気度)

❓「会社は信用できるの?」
   → 8. 情報公開方針とステークホルダー対応(透明性の約束)

❓「難しい言葉が分からない」
   → 9. 用語集と技術解説(専門用語の説明)

❓「今までちゃんと報告してきたの?」
   → 10. これまでの発表履歴(継続的開示の証拠)

💡 各セクションに共通する「書き方の原則」

1. 素人目線を忘れない

  • 専門用語は使わない(使う場合は必ず説明)
  • 「つまりどういうこと?」を常に考える
  • IT知識ゼロの人が読んでも分かる表現

2. 数字で具体的に

  • 「多くの」ではなく「59万件」
  • 「早期に」ではなく「24時間以内に」
  • 「適切に」ではなく「全24時間監視」

3. 図解・表を活用

  • 文章だけでは分かりにくい部分は図で説明
  • 時系列は表形式で整理
  • システム構成図や攻撃フロー図を挿入

4. 言い訳しない

  • 原因は素直に認める
  • 「想定外」「やむを得ず」などの言い訳は避ける
  • 「不十分だった」と認めた上で、「今後はこうする」を示す

5. 前向きに締める

  • 問題点だけでなく、対策も必ず示す
  • 「二度と起こさない」という決意を明確に
  • 「社会全体の安全に貢献したい」という姿勢
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?