インシデント発生時 どうなるか?どうするか?①

情報セキュリティインシデントは、思いがけず起こってしまうものです。

起こらない、起こさないに越したことはありませんが、すべてが自組織でコントロルできるものではありません。

外部からの攻撃など、コントロールできない要素が多分にあります。

そしてインシデントは、得てして予想外のときに起きるものです。

ここでは、実際にインシデントが発生した場合にどのようなことが起こり得るか、またその場合、あなたが経営者である時にどのような対応が必要になるかを架空のケースで見ていきましょう。

「会社の顧客データがネットにさらされている」

あなたは、ある中堅IT企業の社長だとします。

会社は、一般ユーザー向けのソフトウエアのネット経由販売。

ある日曜日、取引先の役員とのゴルフ中に、1本の電話がかかってきます。

電話の相手は会社の総務部長で、内容は「会社の顧客データがネットにさらされている」というもの。

総務部長は大変慌てている様子で、「会社のCIOと連絡がつかなかったため、あなたに連絡を入れた」と言っています。

インシデント発生です。

まずすべきことは、通報元・顧客からのネットにさらされているという情報を確認することです。

それは本当にあなたの会社のものなのでしょうか。

特定される根拠があるのかどうか確認しなければなりません。

もしも通報が匿名で、「漏えい先のURLを送りたいので、総務部長のメールアドレスを連絡してほしい」などと言われた場合、通報元自体を疑うべきでしょう。

情報漏えいを編って、調査行為を仕掛けてきている可能性も疑われます。

巧妙な攻撃者なら総務部長が慌ててクリックするよう仕向けてメールにURLを仕込み、侵入経路を作ることもできるでしょう。

通報が警察やJPCERT/CC(JPCERTコディネーションセンター)のような公的機関からであれば間違いないとは考えられますが、再確認のために連絡先を確認しておく必要があるでしょう。

公的機関からの通報の場合、それなりの確証をもって通報されます。

例えば、「漏えいしたデータからあなたの会社が特定される情報が発見され、あなたの会社が使っているIPアドレス、あるいはURLが確認されている」といったことです。

このような外部からの通報を受けるセクションが情報セキュリティインシデント発生時の初動対応に慣れていないことがあります。

通報する側は、この種の対応を行なう責任者が誰で、どこに連絡すればよいかはわかっていません。

そのため通報者は、会社の代表電話にかけ、受けた方もまずは総務部長に回すという結果になるのです。

ここで、総務部長がこの種のインシデントヘの対応能力があるかどうかもあなたは判断する必要があります。

もし、慣れていないと判断すれば、適切な指示を出せるCIOあるいは情報セキュリティインシデントの対応責任者に連絡を取らせて、初動対応の指示を仰ぐようにすべきです。

適当な人間を指名できないのなら、あなたはすぐに出社すべきでしょう。

漏えい情報の確認、二次被害対処

通報元が信頼でき、漏えい情報の特定が可能と判断された場合について考えてみましょう。

次のアクションは一刻も早く漏えい情報の内容を確認し、二次被害の特定と防止への対処を行なうことです。

インシデントが発生した場合、この段階でまず最大限に優先されるのは被害の拡大防止であることを十分理解すべきです。

以下の対応を同時進行で行なわなければなりません。

  1. 漏えいした情報によって、顧客や取引先などにどのような被害が発生するかを想定し、それに対する対処を策定する
  2. 漏えい経路を特定してさらなる漏えい、あるいは他に漏えいが起こっていないかを特定する

①については漏えい情報の中身に基づいた判断が必要です。

社内の責任者を招集し、内容を確認するとともに、情報セキュリティの專門家による二次被害の想定を判断。

漏えいが外部に公開されているWebサーバーからのものと疑われる場合には、すぐにネットワークから遮断。

警察には被害届を提出する法務対応の準備も必要です。

②については、さらに複雑な対応が必要でしょう。

漏えいが、外部からの攻撃・内部犯行・過失のいずれかという切り分けが必要です。

初期段階で、CSIRT(Computer Security Incident Response Team :シーサート)組織が自社内にあるならここが中心になって、対応を行ないますが、CSIRTだけでは動けません。

切り分けには、ルターやIDS/IPS (Intrusion Detection System /Intrusion Prevention System :侵入検出/遮断システム)あるいはデータベース、ファイルサバーなどのIT機器のログの収集と分析が必要になります。

これらの作業に対応可能な情報システム部のメンバーもアサインする必要がありますログの分析といっても、むやみに行なうと極めて非効率になります。

漏えいが起こった日時を推定して疑わしいところから解析する必要があります。

公的機関からの通報であれば、漏えいしたと推定される日時や、サイバー攻撃によるものか内部犯行の恐れが強いのか、ある程度は推定されているはずです。

これらの情報を開示してもらい、迅速な解明ができるよう対処すべきです。

標的型攻撃によるものであれば、C&C(Command & Control)サーバーとの通信を特定している可能性もあります。

初動対応では、適格なメンバーを招集し、対応チームを構成し、メンバー間で情報を共有、また、情報を分析しながら的確に指示を出していく司令塔が必要です。

責任と権限をもった経営層、あるいはその直属の組織の役割になります。

責任と権限をもつ前提として、司令塔としての役割を遂行可能な能力を有しているかを見極めておくことが重要です。

まとめ

実際にインシデントが発生した場合にどのようなことが起こり得るか、またその場合、どのような対応が必要になるかを架空のケースでの

  • インシデント発生時の、通報元の情報確認
  • 漏えい情報の内容を確認し、二次被害の特定と防止への対処

といったインシデント発生時の初動について見てきました。

リスク対策とはインシデントの発生を防ぐだけでなく、万が一発生した場合に備えた事前対策も必要になります。

インシデント発生時 どうなるか?どうするか?②」で、ここで説明したインシデント発生時の初動以後の対応について見ていきます。

【関連記事】インシデント発生時 どうなるか?どうするか?②

シェアする

  • このエントリーをはてなブックマークに追加

フォローする