3 回連載の最終回では、情報セキュリティ インシデントが発生した際に企業・組織がどのように公表するべきかを考えます。
みんなが知っているのに「秘境」？
図1（秘境の例１）沖縄県波照間島のニシ浜
現在、日本を含め世界中には様々な「秘境」が存在します。以前は文字通り知る人ぞ知る場所だったにもかかわらず、手軽に行ける「秘境」はだいぶ増えているように思います。これは車、鉄道や飛行機など交通機関の発達も一因ですが、インターネットやテレビを始めとするメディアによる周知の効果が大きいのではないでしょうか。
刑事事件や政治に関する話題においてもメディアの役割は大きく、取り上げられ方によっては「炎上」してしまうリスクは高まっているようです。企業・組織にとってどのようにメディアを始めとして外部に発信していくかは、非常に重要な課題と言えます。
日本の組織の対応
図2（秘境の例２）青森県不老ふ死温泉
日本においては、情報セキュリティインシデント（以下、単に「インシデント」と呼びます。）が発生した際の組織の対応は現状では千差万別です。被害が明らかになった場合であっても組織の信用低下を恐れ公表しない組織も多い一方、（稀ではありますが、）具体的な被害がないのにもかかわらず外部から「隠蔽している」と指摘されることを恐れ、インシデント発生を一刻も早く公表し、マスコミからの問い合わせ全てに「誠実に」答える組織もあります。
筆者の過去の経験では、普段インシデントがあまり発生せず、比較的ユーザ数の少ない組織の方が、こうした危機管理体制が不慣れかつ不適切な事例が多いように見受けられます。
第 2 回でも取り上げたとおり、インシデントの原因究明には多くの時間、費用や労力を費やすことも多く、再発防止策を講じることはそれなりに時間を要します。そのため、インシデント発生と併せて再発防止策も公表した場合には、「発生をなぜ隠していたのか」と指摘されることも多いのです。
なぜ公表する必要があるのか
インシデントの発生した際には、公表が必要なケースと公表する必要性が低いケースの双方があります。例えば一社員や職員が不審メールを開封した程度のインシデントであれば、直ちに公表が必要ではないでしょう。これは、政府機関、地方公共団体や公的機関でも同様であり、単に「情報公開の必要性」「知る権利」を盾に外部から問われた場合であっても、把握している情報を全て明らかにするのではなく、的確な情報を適時に発信することが必要です。
そもそも、インシデント発生を公表するのは何のためでしょうか。インシデントを公表する意義は次の2点に集約できます。
(1) 説明責任を果たす
個人情報や重要情報を扱う組織として、インシデントが発生し、これらの情報の安全が脅かされる恐れがある場合、または組織の業務継続に影響を与える（あるいは与える可能性のある）場合には、組織は過去の事実経過や今後の見通しについて社会的な説明責任を果たす必要があります。公表を伴うインシデントの多くはこれに該当すると考えられます。
(2) 影響を受ける（可能性のある）人に対する周知
インシデントの発生により、国民や顧客・取引先等に影響がある場合、特にWebの改ざん事案など、影響を受ける人の特定が困難な場合は、組織は公表により注意事項等を広く周知する必要があります。
これらを踏まえると、一個人が不審メールを開封してしまった事案や、個人情報や重要情報を扱っていないシステムにおける軽微なインシデントは、それ自体を公表する必要性は薄いと考えられます。このような理由から特にサイバーセキュリティに関しては非公表と「隠蔽」は厳に区別すべきと考えます。
「攻撃者に資することになることからお答えを差し控えたい」
これは筆者のこれまでのインシデントハンドリングの経験において、一番使いどころが難しいと思われるフレーズです。インシデントを公表するに当たり、記者の問い合わせに把握したことを全て発信している組織もいくつかありましたが、例えばネットワークの構成や使用ソフトウエア、インシデントの対応において問題の所在が周知になると、新たな攻撃のターゲットとなる恐れがあります。それらの詳細を公表しなくても前項の (1) と (2) の目的は達成できます。インシデントの規模が大きければ大きいほど、原因究明や再発防止策に時間を要することから、不用意に新たな攻撃を誘発する恐れのある発信は控えるべきです。
魔法の言葉？「現時点では」「確認されていない」
インシデントが発生した際の公表文でよく見かけるのが、「現時点では情報流出は確認されていない」「現在のところ被害は確認されていない」といった文言です。このようなプレスリリース文を元に、「情報流出/被害がない」と報道されている例が見受けられますが、これは明らかに誤報です。なぜならこれらの文言は、あくまで現時点まででわかっている事実経過や調査結果では確認されていない（が、将来的に調査が進んだ結果、情報流出や被害が確認される可能性は否定しない）という意味だからです。
一方、一旦インシデントを公表し、調査が進んでから、「実は被害があった」「情報漏えいが発覚した」例は、筆者の知りうる限りありません。これは、決して攻撃を受けた組織の調査が甘かったというわけではなく、攻撃者側も、有能であればあるほど攻撃の痕跡を消すのが巧妙であるため、例えば「端末から情報を抜き取るため、ファイルを圧縮しようとした痕跡があった」「通信はしていたが送信した内容が消されており不明」など、被害や情報漏えいの痕跡は見られるものの、決定的な証拠がほとんどの場合つかめないためです。
まず、インシデント発生について公表
以上を踏まえて、こうしたインシデントが発生した際には、経営層・責任者はどのように公表していくのが良いのでしょうか。
個人情報や重要情報を扱っているシステムでインシデントが確認されたり、または業務への影響が出た（または今後、影響が出ると見込まれる）場合、まずはその時点で把握されている事実経過と（原因究明を行っているのであれば）調査中である旨を速やかに公表すると良いでしょう。その後、ある程度、調査や対策に目処がついた時点でその後の対応について追加で公表するのです。こうした 2 段階を経ることで、関係者への説明責任を速やかに果たすと共に、組織がじっくりと原因調査と再発防止策を講じることができる時間を確保できます。
まとめ
以上をまとめると以下のようになります。
- 組織は、インシデントが発生した場合には、社会的説明責任を果たすか、または広く注意喚起する必要がある際には公表すべき
- 公表するとはいえ、把握していることを全て明らかにするのは駄目、中身を精査すべき
- 公表が必要な案件が発生した場合、可能な限り早めに発生の公表をするとよい
- 発生の公表した後は、調査や対策に一定の区切りがついた段階で、その後の経過について公表が必要
おわりに
今回までの 3 回シリーズでインシデントの特徴を分析し、発生した時にどのように対応すれば良いかを考えてみました。
情報セキュインシデントは、今やどの組織においても他山の石ではなく、いつ発生してもおかしくありません。システム管理者だけではなく、経営層や管理職も仮に自身の組織にインシデントが発生した場合にどのように対応するか、考えていただければと思います。
Authors