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

公開 2024年06月11日 10時02分

[ITmedia]

印刷する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サイバー攻撃の被害に関する情報とその分類（NRIセキュアテクノロジーズのブログから引用）

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

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

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

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

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

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

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

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

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

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

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

次ページへ「うちの情報が漏れました」正しく伝える準備の方法は