コメントはまだありません~セキュリティの事故分析とリスク分析を考える~セキュリティ・エグゼクティブ・ディレクター中島浩光タイトル中の「事故は、起きるかどうかではなく、いつ起きるか」は原発の事故に関するある人の発言なのですが、情報セキュリティ事故も確かにそうなんですよね。その証拠に、世間ではあいも変わらずセキュリティ事故が起きているわけです。セキュリティ事故とセキュリティリスクさて、情報セキュリティ事故が発生した場合、事故対応はしなくてはいけないわけですが、ちゃんとした組織であれば、発生したセキュリティ事故に対する原因究明もする必要があります。何が起こったのか?どんな攻撃だったのか?起きた原因はなんであるのか?といったことを解明していくわけですが、セキュリティ事故の分析を行う時に気を付けた方がいいな、と思っていることがあります。「セキュリティ事故はセキュリティリスク分析の観点から分析・報告を行うべき」ということです。何を言っているんだ?と思われるかもしれませんが、セキュリティ事故の分析・報告においてセキュリティリスク分析(情報セキュリティリスク分析)の観点から行うことは非常に有効だと考えるのです。いう、式が使われます。それぞれ洗い出し、セキュリティリスクを洗い出す方法があります。それぞれを可能な限り網羅的に行う必要があり、洗い出しの粒度を細かくしてしまうとそれぞれを洗い出すのが際限なくなるため、洗い出しの粒度を大きくすることを推奨します。セキュリティリスク分析ではこうしてセキュリティリスクを洗い出して、いろいろと評価して、セキュリティリスクに対するセキュリティ対策を行っていくわけです。セキュリティリスクとセキュリティ事故の関係さて、情報セキュリティリスク分析をしてセキュリティ対策を実施するわけです。残念ながらセキュリティ事故が起こったりします。セキュリティ事故が起こったら、事故対応して、原因分析をして、セキュリティ事故の報告をするわけです。個人的には「セキュリティリスク分析からセキュリティ対策」の一連の活動と、「セキュリティ事故から事故対応」の一連の活動が、別々というかもっと連携しないといけないのかな?とちょっと感じています。そこで、考えなくてはいけないのは、「セキュリティ事故というのはセキュリティリスクが顕在化したもの」であるという事だと思うのです。成り立つわけなのです。実際のセキュリティ事故の原因究明をする場合には、何が原因で、どういう経緯でどう攻撃をされて、どんな被害があったのか?という感じで進んでいくわけなのですが、「ソフトウェアの脆弱性を攻撃された」とかいう以外では、「脆弱性」や「脅威」という単語は出てこず、原因を分析・記述しているものが多いと感じます。セキュリティリスク分析を式に従って行うのであれば、事故分析もこの式に従って行うことが可能であり、発生したセキュリティ事故における「情報資産」は何だったのか?「脅威」は何だったのか?「脆弱性」は何だったのか?と分析して記述していけばよいと思うのです。いうセキュリティリスク分析と同じ言葉を使うと、事故報告の内容をセキュリティリスク分析やセキュリティリスク対応へのフィードバックが容易になるはずなのです。セキュリティ事故の原因となった「脆弱性」がセキュリティリスク分析・対応できちんと検討・対応されていたのか?とか、リスク分析で検討されていたが、対応がまずかったのか?等が分かりやすくなるはずなのです。することで、発生したセキュリティ事故からのセキュリティリスク分析の見直し、対策の見直し・改善が分かりやすくなると思うのです。同じ単語を使う、というだけの話なのですが、結構重要だと思うんですよね。2017-08-01カテゴリーイベント・セミナーお知らせコラム活動レポートAbout企業におけるセキュリティ管理者の必要性、意義、そして、最新のIT環境におけるセキュリティ、コンプライアンスを考え議論し、情報発信することを目的とする。ついてお問い合わせサイトマップ。