「当社の情報が漏えいしました」──世間へどう発表すべき? タイミングは? セキュリティ専門家に根掘り葉掘り聞いてみた

0

2024年06月12日 10:21  ITmedia NEWS

  • チェックする
  • つぶやく
  • 日記を書く

ITmedia NEWS

写真

 「この会社、情報漏えいしたのに、説明が全然なってないな」──情報セキュリティインシデントが日常化した昨今。企業や自治体などによる“情報漏えいのお詫びとお知らせ”を見て、こう感じたことはないだろうか。そしてもし、自分の勤め先でインシデントがあったとき、同じ目で見られない自信はあるだろうか。


【その他の画像】


 SNSが発達し、インシデントの発表がレピュテーションリスクにつながり得るこの時代。“世間への伝え方”は、企業・組織のイメージや株価、そして信頼を保つために、無視できない要素になりつつある。もちろん、事態を未然に防ぐのも大事だが、可能性をゼロにはできない。


 もし「自社でインシデントが起きました」「サイバー攻撃を受け情報が漏えいしました」という事態に陥ったとき、世間にどう伝えるのが適切か。NRIセキュアテクノロジーズでインシデント発生時の情報開示に関するコンサルティングを手掛ける山口雅史さん(コンサルティング事業統括本部長)、木村匠さん(シニアセキュリティコンサルタント)、そして情報を広げる当事者として記者(吉川)の三者で議論した。


●被害の発表、適切な考え方は まず前提を整理


 まず、山口さんと木村さんに聞いた、情報公開に関する基本的な考え方を整理しておく。


 インシデントに関する情報公開は、対象や目的に応じて大きく2種類に分けられるという。一つはインシデント対応に必要な情報を集めたり、他の組織に同じ被害が及ぶことを避けたりするために、専門組織やセキュリティ系コミュニティー間でなされるクローズドな「情報共有」。もう一つが、法的な要求を満たしたり、ユーザーや社会への説明責任を果たしたりするための「被害公表」だ。今回は主に後者を扱う。


 2人によれば、被害公表の基準は、インシデントの規模や種類によって7レベルに分けられ、段階に応じた対応が必要になるという。各レベルの対応は以下の画像の通り。なお、これらはあくまで一般に公表する際の考え方で、個人情報保護委員会への報告などとはまた別だ。


 ただし場合によっては、レベルを問わず速やかな公表が必要なケースもあると山口さん。例えばサービスのユーザーがWebサイトにアクセスすることで、マルウェアに感染したり、フィッシング詐欺の被害に遭う可能性があったりするなど、当座のリスクがある場合は、被害を未然に防ぐためにも早急な公表が必要という。


 この他、自社の受けた被害が、同業他社などでも発生し得る場合などは、専門機関と協力の上、原因が分かった段階で注意喚起を兼ねて公表するケースも考えられる。例えば既知の脆弱性を狙った攻撃があった場合に、詳細に先んじてその旨を注意喚起するケースなどがそれに当たる。


 とはいえ、早急に初報を出すケースでは、その後情報の更新がないと世間の不信感につながる場合もあると木村さん。そのため海外では株主やユーザーなどからの納得を得るため、タイムライン形式で情報を更新するケースもあるという。


 以上の前提を踏まえ、あるべき情報公開の形を三者で議論。記者からは、報道記者の立場に加え、自身の情報が漏れているかもしれない当事者としての視点からも意見をぶつけた。


●三者で話す「情報公開の正しいタイミングは?」


吉川:まずは、情報公開の正しいタイミングについて議論させてください。ITmedia NEWSでもインシデントはよく取り上げますが、インシデントの発生から発表までに時間がたっていると「どうしてこんなに遅れるんだ」というコメントが出始める印象があります。


山口さん:最近は事象が発生して1カ月たつと「1カ月間どうしていたんだ」といわれるので、やはりタイミングをなるべく早く、かつ確かに情報を開示するのが求められるようになっていると思います。


 ただ、これは事実が明確であった場合です。過去、ある企業があいまいな状況で「インシデントが起きました。個人情報が盗まれたと思われます」と公表したケースがあったんですが、結果としてSNSでの(事実に基づかない)風評被害につながり、株価が下落する事態が発生しました。


 ですので、早さと合わせて情報の正確さも必要になります。ただ、初動のときは分からない情報もあります。その場合は、被害をより大きく見積もっておいた方が、きっちりしたリスクマネジメントと捉えられることにつながると思います。


吉川:印象だけの話をすれば「第2報で漏えい件数が増えた!」みたいなケースは、悪いイメージですよね。なるべく早い発表が必要な点についても同意します。たまに事象の発生から半年とか1年とかたってからの発表もありますが「都合が悪いから隠していたんだろ」といった声がすごく多くなる印象です。


 同様に賛否があるのは……金曜夜や夕方の発表ですね。どうしてもビジネス系の話題は休みを越せず、週明けには“鎮火”する傾向が多い印象なので「話題にならないよう、狙ったのでは?」という意見も散見されます。もちろん、金曜日に発覚してその日に発表する、というケースもあるとは思うんですが……この辺り、クライアントとコミュニケーションすることはあるのでしょうか。


山口さん:われわれは「こういう情報を分析して、整理すべき」という部分の専門家で、いつ発表すべき、というところまでアドバイスはしないんです。そこから先は広報戦略ですよね。そもそも公表するか否かは、広報や法務、そして経営判断によるところが大きいので。


吉川:なるほど。情報が漏えいした本人への報告は別として、例えば経営者が情報公開を拒否してしまうと、伏せられてしまう可能性はあると。


山口さん:規模が大きい場合は、第三者委員会が設置され、そこから対外的なレポートが出されたり、公表を促すケースもありますけどね。


木村さん:そういった判断が発生する根本原因というのは、被害を公表すること自体が、社会的な制裁につながるという意識が強いからだと思うんですよね。本来、被害を受けた組織が、二次被害を防ぐために公表すること自体はポジティブな効果を持つはずです。


 しかし、現状はどうしてもSNSで広がって「やらかした」といったような声につながってしまうので、ネガティブに捉えられてしまう。みんなでセキュリティを高めるために専門知を持ち寄ろう、という意識があれば、発表しない・話題にならないタイミングで発表する判断にはならないと思います。


吉川:いち記者としてはセキュリティ関心層の方に参考にしてもらいたい意識で情報を発信しているつもりですが、媒体によっては“公開処刑”的なニュアンスもありますよね。この辺りはメディアももちろんですが、情報の受け手側も意識を改める必要があるのかもしれません。


●どこまで詳しく伝えるべきか?


吉川:では、発表の中身、情報の”粒度”についてはどうでしょうか。記者としては被害のあった日時、対象となる組織、手口や原因、漏えい件数、再発防止策や当局への報告状況などが最低でも知りたいな、と思う情報ですが。


山口さん:話にあった被害の日時や対象の組織、その規模・内容まで説明することもありますし、さらにどんなシステムが攻撃を受けたか、どんな攻撃手法だったかまで書く場合もあります。どんな脆弱性を狙った攻撃だったか、どんなマルウェアだったかまで発信する場合は、同様の被害が広がる可能性を踏まえたものであることが多いです。


 ただ先ほども話した通り、われわれはこういう情報をまとめて世の中に公表する、というよりは「こういう情報を整理して、公表する情報として扱ってください」とアドバイスしています。実際にそこから先、どこまで情報を開示するかは、やはり広報的な判断になります。あえて全部開示する場合もあれば、若干オブラートに包む場合もありますね。


吉川:記者としてはなるべく詳細に開示してもらいたいところではあります。例えば「クラウドサービスの設定ミスにより」という原因説明はよく見受けられますが、これだけだとSaaS型のクラウドストレージで起きたトラブルなのか、それともAWSやAzureなどIaaS・PaaSのトラブルなのか、見分けがつきません。


 しかし、この二つでは注意喚起すべき対象が異なると思います。可能であれば切り分けるべき内容と思うのですが、こういった情報の粒度はどう判断するものなのでしょう。


木村さん:広報戦略の観点もあると思うのですが、開示によって二次被害を起こしてしまう可能性がある情報は、表に出すべきではありません。


 例えば脆弱性に関連する情報の場合、既知の脆弱性かつすでに対策が世に出ているものであれば、(プレスリリースなどで大々的に知らせるかは別として)世に知らせることで対応を促せるものと思います。


 ただ、いわゆるゼロデイ脆弱性のような、まだ対策の仕方が分かっていないケースは、やめた方がいいと思いますし、専門機関もそうアドバイスするでしょう。脆弱性の原因となる(サービスや機器を提供する)ベンダーと調整した上で、対策が出た後に情報を出そう、という流れになるのではないかと思います。


山口さん:過去には、もともとは攻撃の難易度が高かったものの、公表されることで容易になってしまったケースもありましたね。われわれも、攻撃手法や脆弱性の情報について公表しすぎると、かえって攻撃の標的にされ得るということは(クライアントなどに)伝えています。


木村さん:そういった情報は「ISAC」といった各業界にあるセキュリティの調査組織や政府機関など、一般には公表しない形で集約する場に共有した方がいいと思います。一方、一般向けにはこれらの取り組みを進めている旨を発表すると、ネガティブには捉えられないのかなと。逆に言えば「詳しいことは言えません」とするときの理由付けにもなってしまうのですが。


吉川:確かに、自分にとっても「それを言われるとこれ以上は聞きにくい」ワードですね……その辺りは各企業に誠実さを求めるしかないですし、報じるに当たってこちらも誠実でありたいです。


山口さん:あとは、個人の特定に関する話もありますね。個人の責任所在が特定可能になってしまうと、企業としては働く人を守る義務が果たせなくなってしまいます。内部不正は例外ですが。同様に、被害を受けた人の特定もできないような知らせ方が必要です。


吉川:設定ミスなど人為的なミスの場合も、個人ではなく「そうなってしまう仕組みが悪い」が結論になるといった具合でしょうか。


●「うちの情報が漏れました」正しく伝えるのに必要な備えは


吉川:では、ここまで話したような備えをどのようにするか、という点についてはいかがでしょう。自分の立場で言うのもなんですが、何かあった際「対外的な発表に向けた動きはどうする」「記者対応はどうする」という訓練までしている企業は、そこまで多くないんじゃないかと思うんですよね。どのように備えるのが正解なのでしょうか。


山口さん:実際にインシデントが起きたとき、企業としてどのように動くべきかを確認するサイバーセキュリティ演習のようなものがあります。(インシデント対応の)現場のみでやるケースもありますが、経営層、広報、法務、人事、総務なども集まって被害の状況を整理し、セキュリティ担当者以外も含めてどう対応すべきか検討する形の演習も多くなってきています。


吉川:いわゆる「サイバーレジリエンス」(サイバー攻撃を受ける前提で、被害を最小限にとどめて早期にシステムを復旧させるための考え方)ですね。自分も同様のケースを取材したことがあります。やはりその重要性も高まっていると。


山口さん:経団連や関係省庁の動きからしても、経営層がサイバーセキュリティを認知して対応すべき、という理解が世間的にも広がってきています。また10年前と比べると、株主や記者もサイバー攻撃に敏感になっています。


 例えばインシデントがあったとき、社内情報がマスコミを通して漏れてしまうと、結果として企業は説明責任を果たしにくくなる。インシデントが発生した際にはこういう対応をしました、と(企業自ら)説明責任を果たせるかどうかも、訓練の有無で変わると思います。


吉川:セキュリティインシデントに限りませんが、他社媒体でもトラブルの後に「実は○○社が原因だった!」と示唆する報道をよく見かけますね。確かに、最悪のケースの一つかもしれません。


●会見? Web? 正しい発表の場は


吉川:次に、インシデントを発表する“場”についての考え方をお聞かせください。先ほど全7レベルの対応を見せていただきました。ただ、自分としては特にレベル4〜6は大きな違いがない印象です。SNS時代ですし、Web上の発表は誰かに見つけられるので「発表をしない」「Web上で発表する」「会見をする」以上の差を見いだせないなと。この辺りはどう切り分けられるのでしょうか。


山口さん:公表の必要がない事態は別として、あまり大ごとにしたくないが、公表しないことによるレピュテーションリスクも抱える企業が、レベル4〜5で済ますことはあるかなと。


吉川:確かに、記者向けに情報が送られないパターンでは、気付くのが遅れることはありますね。結局はSNSなど記者自身の情報網で気付きはしますが。では、会見をするしないの判断はどうなるのでしょうか。


 あくまで個人的な感覚ですが、数十万〜数百万件規模の漏えいや、億単位の金銭的被害があると「会見はいつだ」という声が見られる気がします。人命や税金がかかわる医療・教育・自治体などは例外ですが。


山口さん:過去にレベル7、記者会見の内容について対応したことがあります。恐らくではあるのですが、(当時の会見は)企業のブランドを守るため、社長自ら事後対応について強くメッセージングするものでした。報道向けのレベル6、会見をするレベル7になってくると、そういった広報戦略も絡んでくるのではないか思います。


吉川:説明責任を求められる場合は、会見をすべきという考え方ですね。ちなみに、記者会見がある際は、どのようなアドバイスをするのでしょうか。


山口さん:セキュリティの観点でいえば「不確かな情報を言ってはいけない」と伝えています。確実な情報は説明すべきですが、例えば攻撃手法や脆弱性についての不確かな情報は「自分も攻撃されるのでは」「自分も対象になるのでは」と不安を増長させ、SNSでの(ネガティブな)反応も増大します。


 それ以外は、なぜ事態が起きたのかやその裏付け、誰が対応したのかといった企業としての取り組みの話をすべきと伝えています。


吉川:なるほど。SNSやニュースポータルでは「会見には社長が出ろ」「いや技術が分かっている人間が出ろ」と正反対な意見が飛び交うのも見られますが、誰がどんな内容を話すべき、という点はどうでしょうか。


山口さん:ある通信系の社長さんは知識豊富で、記者からの技術的な質問にも回答できており、企業のトップとしてあるべき姿と思います。ただ、全員が全員同じ対応を取るのは難しい。


木村さん:重要なのは場の役割だと思うんですよね。記者会見は、企業の責任ある立場の人が顔を見せて、今後誠意ある対応をします、というのを社会に対して約束する場だと思います。もちろん詳しい人が説明することも重要ですが、それ自体は会見の場ではなく、書面でも対応できますし。


吉川:確かに、いわゆる“謝罪”は会見で、詳細は後日資料や書面で、というケースも見受けられます。あるいは謝罪と詳細の説明を、経営層と現場で手分けしているケースもありますね。あとは謝罪の場と、詳細説明の場を別々に設ける場合もあるでしょうか。


 以前取材したことがあるのですが、経営者の中には会見のトレーニングをしている方もいるそうです。一方で、現場の技術職の方がそういった訓練をしているとは限らないですし、情報を受け取る・発信する側としても切り分けが必要なのかもしれません。ただ、いち労働者としては、なるべく単一の場で行ってもらう方が楽ではあります。


●被害発表=制裁にしない


吉川:逆にお二人からこれを発信しておきたい、と思うことはありますか。


木村さん:セキュリティに限らない、クライシスコミュニケーションの話なのですが、何かあった際の発表の仕方って、企業としての責任が問われるし、それが露呈する場だと思うんです。場合によっては印象が上向くこともあれば、下がることもある。


 これを踏まえて思うのは、先ほど話した通り、被害の公表が社会的な制裁・処罰になってはいけないなと。記者会見を開いて頭を下げる映像はインパクトがあるので「またやってるな」と思ってしまうかもしれないんですが。


吉川:自分はITmedia NEWS以外にもいくつかのメディアで書き手をした経験があるのですが、セキュリティに限らず具体的な原因、経緯より「誰々・どこどこが謝罪した」という話題の方が注目を集めやすい傾向は確かにあると思います。


木村さん:特に文字のメディアであれば対策情報などたくさんの情報を伝えられると思いますし、そこまで踏み込んで説明できるといいと思います。とはいえ、記者だけでは難しいのが実態とは思いますので、当事者の企業が専門家と一緒に、どうすれば社会のためになる情報を発信できるのか、考えて伝えられればいいのかなと。


山口さん:内部不正はまた別ですが、誰が悪いかと言えばハッカー(攻撃者)なんですよね。ひと昔前は、ちゃんと防御・対応できていなかった企業が悪いという風潮があったのですが、今はある程度攻撃者が悪い、という意識が醸成されつつあるとは思います。もちろん、企業も説明責任を果たすための対応をきちんとしていなかった場合には、その責務を負わなくてはいけないと思うのですが。


木村さん:あとは、被害者救済につながる情報はあってしかるべきかなと。昨年「データセキュリティ法の迷走」という洋書を翻訳したのですが、米小売大手Targetの漏えい事例を巡り「大々的にセンセーショナルに報じられ、株価は下がって、人も辞めていき、当局からの賠償金もあったが、それって被害者の救済につながったのだろうか」という問題意識が書かれていました。同様の考えは社会的にも重視すべきではないかと。


吉川:被害者救済の点はその通りですね。また「インシデントの発表がありました。それに対する制裁や社会的な反応がありました。で、社会はその反省を生かして前進したのでしょうか?」という点は、情報の発信者・受信者を問わず考えるべきポイントなのかもしれません。


    ランキングIT・インターネット

    前日のランキングへ

    ニュース設定