セキュリティ事故に備えるシーサート構築術

セキュリティの事故対応に求める要素インシデントと戦うCSIRT

セキュリティの事故(インシデント)を未然に防ぐことが難しくなった今、インシデント発生による影響を最小化する取り組みへの重要性が高まっている。今回は「事後対応」の中身ついて解説しよう。

» 2009年03月09日 08時25分 公開
[ITmedia]

本記事の関連コンテンツは、オンライン・ムックPlus「セキュリティ事故に備えるシーサート構築術」でご覧になれます。


  「インシデント対応」とは、文字通り「インシデントに対応すること」という意味であるが、そこにはさまざまな意味と要素がある。まずは、インシデント対応に関連した用語の説明しよう。

 一般的にインシデント対応とは、「インシデントレスポンス」(Incident Response)という言葉の部分的な和訳が充てられている。しかし、インシデントレスポンスが指す内容が厳密に定義されているわけではない。JPCERTコーディネーションセンター(JPCERT/CC)が公開している「CSIRT ガイド」(PDFファイル)では、インシデントに対して行う業務の呼称として「インシデントマネジメント」「インシデントハンドリング」「インシデントレスポンス」の3つを挙げている。

インシデントマネジメント、ハンドリング、レスポンスの関係(JPCERTコーディネーションセンター「CSIRT ガイド」より引用)

 これによれば、インシデント発生前のパッチ適用や普及啓発といった防御策、すなわち「事前」の対応を含めたインシデントに対して行う一連の業務をまとめて「インシデントマネジメント」と呼ぶ。また、インシデント発生後に行う業務を「インシデントハンドリング」、さらに実際のインシデントに対応して行う業務を「インシデントレスポンス」と呼んでいる。

 本連載ではCSIRT ガイドが定義する「インシデントハンドリング」、すなわちインシデント発生後に行う事後対応をインシデント対応とし、その中身について紹介する。

業務フローと構成要素

 JPCERT/CCが公開する「インシデントハンドリングマニュアル」(PDFファイル)によれば、インシデント対応は大きく分けて以下の4つの要素から構成される。

  1. 検知/連絡の受け付け
  2. トリアージ
  3. インシデントレスポンス(以降、レスポンス)
  4. 報告/情報公開

1.検知/連絡の受け付け

 インシデント対応での重要な点は、インシデントの発生をいかにして迅速に検知し、対応を始められるかどうかになる。

 インシデントの発生を検知するには日常的な監視活動が重要ではあるものの、必ずしも人手を介する必要性はない。システムの構成によっては異常検知システムなどを活用した自動化ができる場合がある。どのような方法であれ、まずは何をもって「異常」と見なすのかを明確にし、「誤検知」を減らす工夫をしておくことが重要だ。

 しかし、例えば情報漏えいなどにおいて外部からの通報で発覚する場合では、自主的に検知ができないケースが珍しくない。そのような場合に備えて、インシデントに関する問い合わせを外部から受け付けるための窓口(メールアドレス、電話番号、FAX番号など)をWebサイトなどで公開しておくことが重要である。

 いずれの場合でも、インシデントが発生する可能性に対して関係者が速やかにアクションを起こせるように情報の転送などの連絡手順を明確にしておくべきである。その手順が正常に機能することを確認するために、随時「予行演習」などを実施することも推奨される。

2.トリアージ

 「トリアージ」とは、本来は災害医療において効果的な救命活動を行うために、多数の傷病者を重症度と緊急度によって分別し、治療の優先度を決めることを指す。そこから転じて、セキュリティのインシデント対応においても、発生したインシデントを深刻度と緊急度によって分別して優先順位を決めることを「トリアージ」と呼ぶようになった。

 この作業では単純に優先順位を決めるだけにとどまらない。まず優先順位を付けるため一次分析を行う必要がある。その際に、対象としているインシデントが本当に自社で対応すべきインシデントなのかどうかを確認しなければならない。事前に対応すべきインシデントだと決定するための基準を定めておく必要がある。

 「対応すべきではない」と判断したインシデントについても、社外の当事者に対応を促す必要がある場合には、関係者への対応依頼を行うべきである。外部からの通報によって認知したインシデントであれば、通報者へ対応しない理由を自社のセキュリティポリシーの範囲内において説明することが求められる。

3.レスポンス

 実際のインシデントへの対応作業には、以下の4つの要素がある。

分析

 トリアージの段階で一次分析を行うが、再度自社で対応すべきインシデントであるかどうかを確認するとともに、インシデントの内容を詳細に分析する。

対応計画の策定

 社内の関連部署と連携し、対応計画を策定する。例えば、外注先での対応が必要な場合など自社だけで対応が十分にできない場合や、対応に際して自社サービス(業務)の停止が伴う場合などは、経営層との密接な連携が必要である。

関係者との連携

 対応計画を策定する際には、必要に応じて外部の専門機関や専門業者、対象インシデントに関係している可能性がある機関に対して、対応支援を要請したり、必要な情報を交換したりする。

再発防止策の検討

 インシデントの発生原因を究明し、再発防止策を検討、策定する。

 レスポンスでは、このような対応計画に従って復旧作業を行い、再発防止策を実施する。その上で、実施した内容が適切かつ十分であったかどうかを確認して、問題がある場合は、再度上記の手順を繰り返すことになる。

4.報告/情報公開

 インシデント対応計画の策定や実施と並行して、必要に応じて報道機関や顧客などに周知するためのプレスリリースや監督省庁への報告を行う。


 今回紹介したように、セキュリティのインシデント対応においては、既存の情報システム部などIT関連部署だけで完結することはない。IT関連部署だけで処理できるケースもあるが、例えば社内から顧客情報が漏えいしたといった深刻なインシデントが発生した場合には、経営層や広報部門、顧客対応という点で営業部門やカスタマサービス部門との連携も必須になる。監督官庁や株主への報告が求められる場合には、総務部門との連携も必要だろう。

 このような対応が求められるようなインシデントが発生する可能性を考慮するなら、全社的な対応体制を事前に用意しておくことが必要だ。このような対応を可能にする枠組みとなるのが、「シーサート」(CSIRT=Computer Emergency Response Team)である。

 シーサートの詳細は次回解説するが、シーサートとは1つの社内部署ではないという点をご理解いただきたい。シーサートの語源は「Team」であることから、何らか専門部署という認識がされがちだが、必ずしも「部署」という組織形態にとらわれる必要はない(もちろん部署という形態でもいい)。

 今、企業の情報セキュリティに求められているのは、シーサートという機能を設けることにある。シーサートには国際規格のような厳密な定義は存在しない。シーサートとは、あくまでセキュリティのインシデントに対応するために必要な機能を提供する枠組みと考え方である。次回は、シーサートという枠組みによってインシデント対応を実施していく上での注意事項を紹介する。

過去のセキュリティニュース一覧はこちら

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ