インシデント発生を前提とした事前対応策−長期休暇中のインシデント発生時のケース別対応案【前編】

　夏休みなどの休暇中にWeb改ざんや情報漏えいなどのインシデントが発生すると、ウイークデイと異なり、初動対応が遅れ被害が拡大する場合があります。
　また、IPAやJPCERT/CCなどのセキュリティ専門機関は、長期休暇に関わるセキュリティ対策のポイントを毎年公開していますが、そうした予防策を超えた攻撃が増えている現状があります。
　そこで今回は、予防策は当然のこととして実施している企業の管理者に向けて、いざ休暇中にインシデントが起こってしまった場合どうするか、その事前対応策と、インシデント発生後の具体的行動について、株式会社ラックの岩井博樹氏に寄稿いただきました。対応策は、企業により異なるIT運用実態と、ウイルスやDDoS等の攻撃類型別のケースごとに解説されています。

株式会社ラック
http://www.lac.co.jp/

─

●緊急電話の傾向が変わった

　長期休暇も終盤にさしかかり、家族や恋人との団らんを満喫…という時に、必ずといってよいほど筆者にかかってくるのが緊急電話だ。「サイバー119チーム」の日常的平和が壊される瞬間だ。お盆明け、正月明けのインシデントは、もはや風物詩のようだ。

　しかし、今年2009年になってからというもの、長期休暇「中」ではなく休暇「後」に緊急電話が鳴ることが多くなった。その理由は、2009年上期のセキュリティキーワードに隠されている。

　2009年上期のキーワードは、筆者的には「ウイルス / ワーム」だ。具体的にはConfickerワームとJSRedir-R（通称、GENOウイルス）系だ。前者はSMB経由やUSBフラッシュメモリ等を経由し感染するワーム、後者はWebサイト運用者のFTPアカウントを盗用し、Webコンテンツを改ざんする。いずれも「既知の技術」を悪用した手口であるにもかかわらず、多くの企業に被害を与えた。

　ではなぜ、大感染したのか。その理由は明白であり、セキュリティ担当者が唯一セキュリティ・パッチを当てることのできない「ヒト」を経由することでウイルスが企業内に持ち込まれていることが一因として挙げられる。

　今後もこのタイプのインシデントは増大が予測され、もはやシステム的予防策だけでは手がつけられない。今後のセキュリティ対策のキーワードは、「インシデントに備えた予防対策」と、それでも発生してしまうインシデントへの「インシデント発生を前提とした対応策」の双方を実践することが重要となるだろう。そこで、本稿では、お盆休み前に講じておきたいインシデント発生「後」のための対策について述べようと思う。

●お約束の長期休暇前の予防対策はさっさと

　お盆休み前といえば、お約束の「夏休み前のセキュリティ対策」だ。なぜ、このような対策が必要かといえば、夏休み中に、業務用端末へのウイルス感染やサーバへの不正侵入、情報漏えいなど、セキュリティ事故が発生する可能性があるためだ。この事前対策が盛んに言われるようになったのは、2003年のBlasterワームの頃からだと記憶している。あれから6年の歳月が経ち、「連休前のセキュリティ対策」はセキュリティ担当者にとってはもはや常識となった。（研究機関や外部出入りの多い組織にとっては、まだまだ大変な業務であると思われるが…）

　ところが、今年のセキュリティ事情はひと味違う。そのきっかけとなったのが、JSRedir-R（通称、GENOウイルス）やConfickerの大感染騒ぎだ。JSRedir-R騒ぎは5月のゴールデンウィーク後にピークを迎えたが、その多くがゴールデンウィーク中の感染だったことは記憶に新しい。これらの共通点は、発症当初は感染経路が分からなかったことだ。要は、従来の予防策だけでは防ぎきれなくなったということだ。

●インシデント発生後に向けての対策

　「インシデント前提の対応策」といっても、何をしたらいいのか。ポイントは3つある。

【インシデント前提の対応策ポイント】
(1)インシデントに気付けるようにする
(2)インシデントの原因が特定できるようにする
(3)助けを呼ぶことができるようにする

●インシデント発生に気付く体制

　まず、(1)「インシデントに気付けるようにする」であるが、「インシデント発生後」というからには、インシデントが発生したことを知らせるトリガーが必要だ。具体的には、ファイアウォールやIDS/IPS、ネットワークトラフィックの急激な上昇、Proxyのログ、各PCにインストールされてる監視用ソフトウェアのアラートなどだ。そして忘れてはならないのが、第三者による通報だ（耳を塞ぐべからず！）。一般に、これらによりインシデントの発生に気付くことができる。

　これらはインシデント発生を示す「点」となる。この「点」から、

・被害範囲の特定
・被害拡大の防止
・被害原因の究明

等を実施することで、インシデントの被害を最小限に食い止めることができ、復旧・回復、その後の対策が実現可能となる。そのためには、また別の「点」を見つけ出さなければならず、インシデント対応技術に加え、コンピュータフォレンジック技術、マルウェア解析技術等が必要となる（気が遠くなるが…）。

　最悪のケースを想定し、どのような対策をしておけば最低限のインシデント対応が可能であるのか整理しておくことは、今後の組織防衛の観点から非常に重要だ。

●ログ取得の注意点

　(2)「インシデントの原因が特定できるようにする」は当然のことと思われるかもしれないが、意外にできていない企業が多い。「PCの操作ログを取得しているので当社はOK♪」などと思っていると痛い目にあう。PCの操作ログの取得範囲、ツールの仕様を良く確認しよう。思っているほど万能ではないはずだ。

　仮にPCの操作ログからインシデントの断片を発見した場合に、次になんのログがあれば原因の究明まで辿りつくかイメージしておくと良い。使う、使わないは別として次のログは取得しておくと効果的だ。

・ネットワーク・トラフィックのフルキャプチャ（フィルタルールは各組織毎に調整が必要）
・Windows監査ログのフル取得（出来ない場合は、オブジェクト・アクセス関連、ログオン・オフ関連）
・入室管理のログ（これは当たり前！）

　休暇中なので、ログもさほど多くはならない筈なのでお試しあれ。なお、ネットワーク・トラフィックをキャプチャしておくことは、万一の際は調査の際に重要な材料となることが多い。特に、ウイルスやボット、情報漏えい等のインシデントでは効果的だ。

●受付窓口設置

　(3)「助けを呼ぶことができるようにする」は最重要かもしれない。マネジメント面、技術面、その他諸々で不足している要素があるならば、すぐに助けを呼ぶ準備はしておくべき。

　証拠保全、調査、報告（経営層、関係省庁、その他）いずれにせよ、まず「インシデント受付窓口」はさっさと設けてしまおう。これは社内・外それぞれに対してだ。多くの企業ホームページに記載されている問い合わせ窓口は、営業や広報関連の御担当者が対応しているはずだ。これではインシデント対応までに時間がかかってしまうから、セキュリティ関連専用の窓口を設けておこう。CSIRTのある組織は、彼らのメーリングリストが良い。ちなみに筆者の勤めるラックではJSOC-IRTが（こっそり）受け付けている。

JSOCチーム情報
http://www.nca.gr.jp/member/jsoc.html

【執筆：株式会社ラックサイバーリスク総合研究所コンピュータセキュリティ研究所所長岩井博樹】