この記事のポイント
- インシデント公表のタイミングや内容はケースバイケースだが、その時点で真実だとわかっていることは迅速に情報公開していくことが重要
- リリースや報告書には、原因・事象、影響範囲、対応内容、痕跡情報などを具体的に記載することが望ましい
- 「インシデントを招いた原因は、特定の人ではなく企業・組織である」という認識の下で対応することが大切
インシデント発覚時には被害の全貌がわからない
一般に、深刻なサイバーインシデントが起きた際には、それを速やかに公表することが望ましいとされています。実際にランサムウェア被害が発覚した際に、企業はその事実をどのように公表しているのでしょうか。
北條氏：
第1回・第2回でもお話ししたとおり、ネットワークへ侵入した攻撃者は、データを窃取した後にランサムウェアを仕掛けるのですが、データが暗号化されてインシデントが発覚した時点では、攻撃者でない限り窃取されたデータの具体的な内容はわかりません。そのため、企業が速やかにインシデントを公表しようとしても、攻撃を受けたという事実のみしか伝えられず、結果として曖昧な形での公表になってしまっているケースが多いのが現状です。
辻氏：
暴露型（二重脅迫型）ランサムウェアの攻撃者グループが情報を暴露する場の1つとして用いる「リークサイト」では、いきなり情報がすべて公開される場合もあれば、「○日以内に交渉がなかった場合にはすべて公表します」といった具合に、企業名や交渉状況などの情報が段階的に公開される場合もあります。
いずれの場合も、リーク情報が出たということは、それ以前にその企業はランサムウェア攻撃を受けたことに気づいているはずです。個社名がリークサイトに公開されているにもかかわらず何のニュースリリースも出していないとなると、周囲から「もし情報がすべて公開されなかったら黙ったままでいるつもりなのか？」といった疑念を抱かれてしまいます。被害を過小評価し、事を荒立てたくないという気持ちもわかるのですが、企業の対応としては、やはり速やかな公表を第一に検討すべきでしょう。
北條氏：
ただ、実際に何のデータが被害を受けたのか把握できていない状況で公表しても、取引先や顧客等を混乱させてしまったり、さまざまな憶測を呼んでしまったりする可能性もあります。心配した取引先等から連絡を受けても、「公表している以上のことは何もわかりません」との回答によってどれぐらい納得してくれるでしょうか。上場企業の場合は株価にも影響が及び得ることを考えると、インシデントが発覚し、ほとんど何もわかっていない段階ですぐに公表すべきだとは一概には言えないのが難しいところです。
いざ公表するとなった際には、自社の被害状況等をどのように分析し、その事実をどのように伝えればいいのでしょうか。
北條氏：
公表のタイミングと同様に難しい問題です。被害組織が公表するより先にリークサイトに盗んだデータを公開されてしまった場合は、速やかにランサムウェアの被害にあっている事実を公表することが望ましいのですが、この時点でも、どのようなデータが盗まれたのかを把握できていないことがほとんどでしょう。そもそもリークサイトに公開されたデータが、盗まれたうちの一部なのか全部なのかということすらわかりません。たとえば、40GBのデータがリークサイトに公開されたとして、40GB分のデータだけが盗まれたと判断するのは早計です。実は盗まれたのが2TBあるうちの40GBだけが公開されたのかもしれませんからね。
辻氏：
攻撃者がデータを圧縮して盗んでいくケースもあります。EDR（Endpoint Detection and Response）などのログを追えばある程度のことはわかりますが、判断が非常に難しい部分でもあります。
サイバーインシデントの現実的な公表の仕方として、「最大何件」という表現がよく使われていますね。
北條氏：
「実際に漏えいした件数」と「（侵害が及んだPCやサーバーに保管されていたデータを含め）漏えいした可能性のある件数」とで書き分けをしているケースもありますね。企業によっては漏えいしたデータの件数、すなわち、リークサイトに公開されて確認できた件数だけしか公表せず、漏えいした可能性のあるデータについては何も触れていないところもあります。
公表の第一報において、どういった情報がどのくらい盗まれたのかという正確な情報を伝えられないことにより、事態がより複雑化してしまう例も少なくありません。
たとえば、窃取された情報の件数を少なく公表して後からより大きな被害規模であったことがわかると、企業の評判や印象に悪影響を及ぼすおそれがあります。一方で、件数を公表した後にそれより小さな被害規模だったことがわかって公表したとして、メディアで大々的に取り上げられるのは件数の多かった最初の公表のほうなので、世間の人々が抱いたイメージを払拭することは困難です。また、件数だけではなく、どのような情報が盗まれたのかという項目に関しても、後から増えていくというのは、調査やデータの把握ができていないとして印象が悪くなってしまいます。
こうした対応の難しさがあるがゆえに、結果としてインシデント発覚時点では攻撃を受けたということしか公表できないケースが多いのだろうと思います。
受け手を意識し、事実を積極的に公表する
第一報のタイミングや被害件数の伝え方のほかに、インシデント公表時に押さえておくべきポイントがあれば教えてください。
辻氏：
不幸にもセキュリティ事故にあってしまったものの、その後の対応が素晴らしかった企業を表彰する「情報セキュリティ事故対応アワード」というイベントがあり、私は2016年から毎年審査委員を務めているのですが、そこでは事故発覚から第一報までの期間と続報の頻度を審査基準の1つとしています。つまり、インシデントの認知後なるべく早く第一報を出し、さらに状況に応じて続報を出すのが望ましい、ということになります。
とはいえ、利害関係者が多い場合には対応方針について全体で意思を統一してから公表したほうがよいケースもあります。たとえば、日本のプロバスケットボールリーグを統括するB.LEAGUEが2017年にサイバー攻撃を受け、クレジットカード情報を含む個人情報が流出してしまった事案では、それを知った顧客やファンの人達が、B.LEAGUEのチケットサイトやファンクラブ受付サイトではなく、バスケットボールのチームに問い合わせをする可能性が考えられました。そこで、どこに問い合わせが来ても統制のとれた対応できるよう、想定問答集を用意するなどの調整を経てから公表に踏み切り、結果的にそれがスムーズな事後対応につながりました。顧客やファンだけでなく、チームやカード会社など、多くのステークホルダーが関わるインシデントの公表・対応の好事例の1つといえるでしょう。
北條氏：
危機管理の鉄則は、迅速に真実を語ること。憶測が流れてしまうとマイナスなので、現時点でわかっていることを明らかにしていくのが重要なポイントです。正確に把握できているものが真実であるのならば、積極的に公表していくのがよいと思います。
ただ、続報を複数回に分けて公開していく方法は、やり方を間違えると顧客にとってマイナスのイメージを与える可能性もあるため注意が必要です。時間が経過するにつれて情報がどんどん増えていくとなると、顧客としてはずっとリリース情報を追い続けなければなりません。一般的には、第一報（初期報告）、第二報（中間報告）、第三報（最終報告）がわかりやすくて丁寧だと思いますが、業種や規模によるところも大きいので、続報の出し方についてはよく検討されたほうがよいでしょう。
辻氏：
また、個人的には、同じような被害にあった人たちに役立つ、あるいは同じ被害にあってしまう人を減らすような、社会貢献に資する情報が公表内容に含まれているかどうかも重視しています。具体的には、攻撃者のIPアドレスやマルウェアのシグネチャといったIoC（Indicator of Compromise）と呼ばれる痕跡情報、脆弱性情報などです。
さらに言えば、リリースや報告書には、インシデントの原因・事象、影響範囲、対応内容も具体的に記載していただきたいです。原因が不明瞭なのに「社内教育を徹底します」といった再発防止策が書かれていても、妥当性があるのかどうかわからないですよね。
北條氏：
同感です。特に痕跡情報や脆弱性情報は、他社の参考になる情報なので、積極的に開示されるようになると良いですね。
一部には企業が公表した貴重な情報を、その企業を糾弾するための材料として用いる向きもあるようで、非常に残念に思います。これでは公表する側のモチベーション低下を招きかねません。
インシデントを公表することによって被害にあった企業が過剰に責められてしまうカルチャーは変えていく必要があると考えています。これは法律の問題ではなく、文化の問題です。公表することのメリットを、私たちとしてももっと社会に伝えていかなければなりません。
こういう公表はすべきではないという悪例はありますか？
辻氏：
良くないケースの一例としては、検索避けのために公表文を画像データで掲載することがあげられます。これは単に自分たちは公表しているとアピールしているだけで、誰のためにもなっていませんよね。HTMLとPDFの両方で公表することが理想です。
また、更新の履歴を残さずに上書きされていくケースや、一定期間後に公表文が消えているケースも見かけますが、こうしたやり方は避けるべきです。これでは経緯を追うことができないからです。一方で、長期間トップページの上部に最終報を掲載している会社は誠実だなという印象を持ちます。
海外企業の好事例に学ぶ多角的な情報発信
これは良いと感じたインシデント公表の事例があれば教えてください。
辻氏：
印象に残っている海外事例はいくつかあるのですが、特にご紹介したいのは、ノルウェーのオスロに本社を置くボリュー社（Volue）の対応です。インフラ企業などに対してエネルギー需給予測管理ソフトウェアを提供するボリュー社は、2021年5月にランサムウェア攻撃の被害にあいました。
この事例で注目すべきは、ボリュー社が非常に透明性の高い公表をしていた点です。同社はまず、ランサムウェア被害が発生した日にすぐさまその事実を公表。事件についてのアップデートを報告する専用ページを設け、その後もそこに続報を出し続け、13日間に19回もの情報公開を行いました。
並行して、SNSをはじめ組織外のチャネルを活用した情報発信も展開。これは自社のWebサイトがDDoS攻撃を受けていたり、マルウェアを仕込まれていたりすることによって公表できないケースがあることを想定し、多くの人の憶測だけで情報が広がらないように、自分たちがしっかりと一次情報を伝えようとする姿勢が見られます。事件発生2日後からは毎朝9時にZoomを利用したWebキャストで各セクションの責任者から日次の報告がなされていました。
また、ボリュー社が顧客に向けて出したガイダンスでは、感染したランサムウェアの名前やそれらに関する公的機関のドキュメントなどにも言及していました。さらに驚いたのは、CEOやCFOといった会社のトップが自身の署名や連絡先とともに対応方針などを含めたメッセージを発信していたことです。
北條氏：
会社をあげて対応しているという強い姿勢がうかがえますね。
辻氏：
これに加えて、希望者に対しては、インシデントの詳細や解決のために行ったアクション、再発防止策などを記したポストモーテム（Postmortem）レポートが配布されました。私もこのレポートを入手するための問い合わせをしましたが、その日のうちに「オープンなコミュニケーションや透明性を私たちは信じています。インフラに対するサービスを提供する我々のような会社にとっては、これが重大なセキュリティインシデントを解決するための唯一の方法です」といったメッセージとともにレポートが送られてきました。
すべての企業がこのレベルの対応をする必要はないかもしれませんが、社会的な責任があると自負している会社が実際にこれだけの対応をした例があるということはお伝えしておきたいです。
社内で犯人探しをするのは悪手
インシデント公表において、経営層が意識すべき点はありますか？
北條氏：
インシデント公表には、ステークホルダーへの注意喚起の意味合いもあります。つまり、窃取された情報の中に顧客や取引先などの関係者の情報が含まれている場合には、そこに被害が及ぶ可能性があることを周知しているわけです。仮に、その盗まれた情報が原因となって当該関係者が別の攻撃を受けたために、当該関係者から訴えられてしまった場合、企業として被害範囲も含めたインシデントを公表していたという事実は、「自社としてはきちんと注意喚起をしていた」と主張するための根拠の1つになり得ます。
辻氏：
インシデント対応において、経営層が「インシデントを招いた原因は、特定の人ではなく組織である」という姿勢を示すことも重要だと思います。悪意のある第三者によるサイバー攻撃は、組織に対する攻撃であって、特定の人物に対する攻撃ではないため、社内で犯人探しをしても意味はありません。
過去に所属企業においてインシデントが発生した際、私が社内外対応の調整役を務めたのですが、何よりもまず、日頃からセキュリティに携わる特定の人物だけが責められない状況・雰囲気を作るところから社内対応を始めました。これにより、調査を進める中でその人から、追加で流出した可能性のある情報についての報告が上がってくるなど、結果として良い方向に進んだというたしかな手応えを感じました。もし経営層や周りから責められていたら、当人はこうした情報は隠そうとしてしまっていたかもしれませんからね。
北條氏：
辻さんの言うように、社内で犯人探しをするのは、責められた本人はもちろん、それを見ている周囲の人たちも「次に自分もそういう目にあうかもしれない」と感じて、本来であれば共有すべき情報を隠蔽・改ざんしたり、嘘をついたりしがちなので、逆効果です。
経営者から「インシデントの原因をつくった人物を処分したいが、どうしたらいいか」という相談を受けたとしても、「誰かを処分したところで、被害が減るわけではありません。インシデント対応等に際し、経営層がうまくコミュニケーションをとるには、誰か1人を責めるのではなく、組織として対応がしやすくなるよう保護をより厚くしたほうがよい」とアドバイスするようにしています。
全3回にわたり、ありがとうございました。
（取材・文：周藤 瞳美 、写真：岩田 伸久）
最新情報をフォローする
