「セキュリティ事故は、起きるかどうかではなく、いつ起きるか」だが・・・

～セキュリティの事故分析とリスク分析を考える～ 

セキュリティ・エグゼクティブ・ディレクター　中島浩光

タイトル中の「事故は、起きるかどうかではなく、いつ起きるか」は原発の事故に関するある人の発言なのですが、情報セキュリティ事故も確かにそうなんですよね。その証拠に、世間ではあいも変わらずセキュリティ事故が起きているわけです。

＜セキュリティ事故とセキュリティリスク＞

さて、情報セキュリティ事故が発生した場合、事故対応はしなくてはいけないわけですが、ちゃんとした組織であれば、発生したセキュリティ事故に対する原因究明もする必要があります。何が起こったのか？どんな攻撃だったのか？起きた原因はなんであるのか？といったことを解明していくわけですが、セキュリティ事故の分析を行う時に気を付けた方がいいな、と思っていることがあります。

それは、

「セキュリティ事故はセキュリティリスク分析の観点から分析・報告を行うべき」

ということです。

何を言っているんだ？と思われるかもしれませんが、セキュリティ事故の分析・報告においてセキュリティリスク分析（情報セキュリティリスク分析）の観点から行うことは非常に有効だと考えるのです。

＜セキュリティリスク分析では何をしているか？＞

では、セキュリティリスク分析の観点って何か？を説明するにあたっては、「情報セキュリティリスク」の構造を考える必要がありますが、よく

情報セキュリティリスク　＝　情報資産　×　脆弱性　×　脅威

という、式が使われます。

情報セキュリティリスク分析の方法の一つとして、この式に従って、情報資産、脆弱性、脅威をそれぞれ洗い出し、セキュリティリスクを洗い出す方法があります。

このやり方を行う場合、情報資産、脆弱性、脅威のそれぞれを可能な限り網羅的に行う必要があり、洗い出しの粒度を細かくしてしまうとそれぞれを洗い出すのが際限なくなるため、洗い出しの粒度を大きくすることを推奨します。

で、セキュリティリスク分析ではこうしてセキュリティリスクを洗い出して、いろいろと評価して、セキュリティリスクに対するセキュリティ対策を行っていくわけです。

＜セキュリティリスクとセキュリティ事故の関係＞

さて、情報セキュリティリスク分析をしてセキュリティ対策を実施するわけです。でも、残念ながらセキュリティ事故が起こったりします。セキュリティ事故が起こったら、事故対応して、原因分析をして、セキュリティ事故の報告をするわけです。

ただ、個人的には「セキュリティリスク分析からセキュリティ対策」の一連の活動と、「セキュリティ事故から事故対応」の一連の活動が、別々というかもっと連携しないといけないのかな？とちょっと感じています。

そこで、考えなくてはいけないのは、「セキュリティ事故というのはセキュリティリスクが顕在化したもの」であるという事だと思うのです。そう考えるとセキュリティ事故についても、

情報セキュリティ事故　＝　情報資産　×　脆弱性　×　脅威

が、成り立つわけなのです。

実際のセキュリティ事故の原因究明をする場合には、何が原因で、どういう経緯でどう攻撃をされて、どんな被害があったのか？という感じで進んでいくわけなのですが、「ソフトウェアの脆弱性を攻撃された」とかいう以外では、「脆弱性」や「脅威」という単語は出てこず、原因を分析・記述しているものが多いと感じます。

もし、セキュリティリスク分析を式に従って行うのであれば、事故分析もこの式に従って行うことが可能であり、発生したセキュリティ事故における「情報資産」は何だったのか？「脅威」は何だったのか？「脆弱性」は何だったのか？と分析して記述していけばよいと思うのです。

＜フィードバック＞

こうして、セキュリティ事故の分析・報告において「情報資産」、「脆弱性」、「脅威」というセキュリティリスク分析と同じ言葉を使うと、事故報告の内容をセキュリティリスク分析やセキュリティリスク対応へのフィードバックが容易になるはずなのです。

つまり、セキュリティ事故の原因となった「脆弱性」がセキュリティリスク分析・対応できちんと検討・対応されていたのか？とか、リスク分析で検討されていたが、対応がまずかったのか？等が分かりやすくなるはずなのです。

こうすることで、発生したセキュリティ事故からのセキュリティリスク分析の見直し、対策の見直し・改善が分かりやすくなると思うのです。

さて、同じ単語を使う、というだけの話なのですが、結構重要だと思うんですよね。