一般的にセキュリティ対策とは、セキュリティの脅威が顕在化しないよう未然に防ぐ、予防的なことが中心になります。しかしながら、変化の激しいセキュリティ環境において、さまざまなリスクにあらかじめ対処するのは困難です。よって、セキュリティ上の問題に対して、事後的な対応（インシデントレスポンス）を重視する企業が増えています。
本コラムでは、こうしたインシデントの影響を最小限に抑えるインシデントレスポンスの基本について、計4回にわたり説明します。
インシデントとは
インシデントとは、国際規格（ISO 22300）によると、「中断・阻害、損失、緊急事態又は危機になり得る又はそれらを引き起こし得る状況」と定義されています。わかりやすく言えば、「非常にまずいような状況」でしょうか・・・。
そして、情報セキュリティインシデントとは、「望まない単独若しくは一連の情報セキュリティ事象、又は予期しない単独若しくは一連の情報セキュリティ事象であって、事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの」と、国際規格（ISO/IEC 27000）で定義されています。これは、「非常にまずい情報セキュリティ事象が起こっているような状況」だと言えそうです。
さらに、ここで明確にしておきたいのが、「情報セキュリティ事象」です。国際規格では、「情報セキュリティ方針への違反若しくは管理策の不具合の可能性、又はセキュリティに関係し得る未知の状況を示す、システム、サービス又はネットワークの状態に関連する事象」。かなりわかりづらい定義ですが、情報セキュリティインシデントになる前の「情報セキュリティ上で問題になりそうな状況」のように思えます。
たとえば、不正アクセスかもしれない状況を見つけたら、それは情報セキュリティ事象です。しかし、それで情報漏洩等の被害が起こっているようであれば、それは情報セキュリティインシデントになります。
今なぜ注目されているのか
重大な情報セキュリティインシデントといえば、個人情報の漏洩です。キングオブインシデントといっても過言ではありません。古くは、2014年に起こったベネッセの個人情報流失事件。約2,900万人の顧客情報が漏洩したとされ、新聞やテレビのニュースで大きく取り上げられました。その後も、こうした事件や事故の発生は後を絶ちません。
特に個人情報が漏洩すると、個人情報保護法に関する法律違反につながります。よって、流失した情報の件数規模（多い少ない）を問わず、適切に対処することが求められます。
そうしたインシデントの発生を未然に防ぐのが、一般的に考えられるセキュリティ対策です。個人情報が漏洩しないよう、不正な通信をブロックするファイアウォールを設置したり、データに対して適切なアクセス権を設定したり、いろいろな対策を施すわけです。
しかしながら、サイバー攻撃の手口はますます高度化していきますし、脆弱性といったソフトウェアの欠陥は毎日のように見つかります。いくら対策を強化したところで、万が一のようなインシデントの発生をゼロにすることは不可能に思えます。セキュリティリスクを下げることはできても、リスクをゼロにはできません。
よって、インシデントの発生は完全に防げないことを前提に、もしも起こった際に被害を抑えるためにはどうしたらいいのか・・・そういった事後的な対処を重視する考えが広まっています。それが「インシデントレスポンス」です。
予防的な対策との関係
インシデントレスポンスは、何か起こった際の事後的な取り組みだと説明しました。では、予防的な面がないかといえば、そうではありません。あたり前のことですが、インシデントの発生に対して、どのように対処を進めていくのか、あらかじめルールなどを整備しておく必要があります。そうしないと、誰が何をどのように実施すべきか判断が遅れ、インシデントレスポンスは機能しないはずです。ここでは、そうした社内規程を「インシデント対応ガイドライン」と呼ぶことにします。
では、インシデント対応ガイドラインには、どういった内容を決めておけばいいのでしょう？ 大きく次の2項目（体制とフロー）をあげて説明します。
- インシデント対応体制
体制には、「平時（インシデントが起こる前）」と「有事（インシデントを認識した後）」の2つが必要です。平時は、基本的に情報システム部門を中心としたメンバーで構成する「情報セキュリティ委員会」などが担い、セキュリティ管理の全般体制で対処します。
有事の際には、インシデントが発生した関係部門の担当者と連携を密にし、個別の対応が求められます。よって、インシデント発生時にSIRT（セキュリティインシデントレスポンスチーム：Security Incident Response Team）を立ち上げて対処します。あらかじめ、各部門からSIRTの構成メンバーをアサインしておき、状況に応じて招集するのです。 - インシデント対応フロー
これも平時と有事の2つで、実施すべきプロセスと対応フローが必要です。平時では、各部門から情報セキュリティ事象の連絡を受け付け、初期調査を実施します。その結果から、情報セキュリティインシデントとして対処が必要かどうかを判断します。インシデント発生となれば、SIRTのメンバーを招集して有事の対処を進めます。大きくは、①初動対応、②トリアージ、③原因調査、④暫定・残存対応などのプロセスに分かれます。- 初動対応
被害の拡大を防ぐために、ネットワークを部分的に切り離す等の封じ込め策を行う。 - トリアージ
いくつかのインシデントが同時多発した場合に、対処すべき優先順を決める。 - 原因調査
インシデントの根本的な発生原因を調査する。 - 暫定・残存対応
インシデントを収束するための、対応策を検討・実施する。
- 初動対応
ただし、これらの内容を決めるだけでは、インシデントレスポンスの準備は不十分です。万が一のインシデント発生で、決められたルールどおりに対処が進められるよう、定期的な演習などの訓練が必要です。この演習訓練の実施についても、インシデント対応ガイドラインで明確にしておきます。
事業継続計画との関係
東日本大震災後、大手企業はもちろん、中小企業においても事業継続計画（BCP）を策定している会社が多くなっています。BCPの発動には、大規模地震などの天災や、新型コロナウイルス時のようなパンデミックが想定されています。そして、こうした事業継続が不可能となる緊急事態には、サイバー攻撃などのセキュリティ被害も含まれるはずです。
では、インシデントレスポンスとBCPとの関係は、どのように考えればいいのでしょう？
一般的には、SIRTが対応を進める中で、事業継続に影響が及ぶ状況を判断し、BCPへとエスカレーションしていきます。BCPが発動されると、SIRTは御役御免になるのではなく、BCPと連携しながら対処します。
こうしたことから、BCPとインシデントレスポンスの演習訓練は、合同で実施することも有効です。
次回は
第2回は、すでにインシデントレスポンスの体制やルールを整備している企業で、有効な取り組みが実現できているのか考察します。実は多くの企業で、ちょっと残念なインシデントレスポンスになっていることが少なくないのです。
