インシデントレスポンスとは？：管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜（1）
本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント（不正アクセス）に関する情報を紹介する。（編集局）
近年のインターネットの普及、特に「ブロードバンド」と呼ばれる高速通信網の一般家庭への普及には目を見張るものがある。
しかし、それに伴い、「コンピュータセキュリティ・インシデント」 の発生件数も増大の一途をたどっている。特に昨年のCodeRedやNimdaといったワームによる被害は広範囲にわたり、これまで「セキュリティ」といったものをほとんど意識することのなかった一般のユーザーにも「セキュリティ」の重要性が認知されだしたことは記憶に新しいところだろう。
そのような中で、
インシデントレスポンス（Incident Response）
||
コンピュータセキュリティ・インシデントに対応すること
の重要性も認知されつつある。
しかしながら「インシデントレスポンス」として一体何を、どのようになすべきなのか？ といった根本的な部分での理解はまだまだ十分に広まっていない状態であると思われる。
そこで今回から数回にわたり、「インシデントレスポンス」をテーマに、具体的な例を挙げながら管理者である読者に向けた解説をしていく。
今回は「インシデントレスポンス」の概要を簡単に説明する。
「コンピュータセキュリティ・インシデント」とは？
「コンピュータセキュリティ・インシデント」とは、具体的にどのような事象を指すのだろうか？ 「Computer Security Incident」を直訳すれば、「コンピュータセキュリティに関連した事件、出来事」といった意味になるが、JPCERT/CCのFAQでは、
コンピュータセキュリティに関係する人為的事象で、意図的および偶発的なもの（その疑いがある場合）を含む。
例えば、リソースの不正使用、サービス妨害行為、データの破壊、意図しない情報の開示や、さらにそれらに至るための行為（事象）などがある。
と説明している。
このような事象を表す用語として、一般的には「不正アクセス」という言葉が使われている。しかし「不正アクセス」には、スキャンやプローブ（探針）といった弱点探索は含まれないことが「不正アクセス禁止法」によって定義されている。
また「不正」という言葉は、「悪意のある」や「正常でない」といったさまざまな意味を含んで使われることがある。そこで本連載では、あいまいな意味で使われることのある「不正アクセス」ではなく、「コンピュータセキュリティ・インシデント」（以下インシデント）という用語を用いる。この用語はRFC（Request For Comments）の文書に用いられるなど、世界的に広く使われている用語だ。
インシデントの種類
インシデントにはさまざまな種類がある。それらのインシデントをJPCERT/CCでは以下の6つのタイプに分類している。
- プローブ、スキャン、そのほか不審なアクセス（scan）
- 弱点探索（サーバプログラムのバージョンのチェックなど）
- 侵入行為の試み（未遂に終わったもの）
- ワームの感染の試み（未遂に終わったもの）
- サーバプログラムの不正中継（abuse）
- メールサーバやプロキシサーバなどの、管理者が意図しない第三者による使用
- 送信ヘッダを詐称した電子メールの配送（forged）
- From: 欄などの詐称
- システムへの侵入（intrusion）
- システムへの侵入、改ざん（rootkitなどの専用ツールによるものも含む）
- DDoS攻撃用プログラムの設置（踏み台）
- ワームの感染
- サービス運用妨害につながる攻撃（DoS）
- ネットワークの輻輳（混雑）による妨害
- サーバプログラムの停止
- サーバOSの停止や再起動
- そのほか
- SPAMメールの受信
- コンピュータウイルスの感染
守るだけが「セキュリティ」ではない
一般に「セキュリティ」について語られる場合は、事前の「防御」に主眼が置かれている。一方、「インシデントレスポンス」には、「事前の対応」という意味での「防御」も含まれるが、それ以上に「事後の対応」が重要な位置を占めている。
例えば、発生したインシデントの原因の追究や分析、被害を受けたシステムの復旧、再発の防止などが含まれる。
しかしここで1つの疑問を投げ掛ける人もいるだろう。
防御を完璧にしていれば、事後のことなど考える必要はないのでは？
近年のセキュリティ技術の進歩、そしてその普及の度合いは、インターネットの普及同様に目覚しいものがあることは事実だ。例えば、ウイルス検知ソフトやIDS（Intrusion Detection System：侵入検知システム）の導入は（まだまだ十分とはいえないものの）数年前とは比較にならないほど浸透してきている。また、重要なデータを暗号化して保存したり、通信路を暗号化するなどの方法はすでに広く一般に使われている。
しかし本当にそれで十分なのだろうか？
現在、一般に用いられているソフトウェアの多くはとても複雑に作られている。従って、開発者ですら気が付かないようなセキュリティ上の弱点（脆弱性）が何かのきっかけで新たに見つかる可能性もあるのだ。つまり、使用しているソフトウェアのセキュリティ関連情報を注意深く収集して既知の脆弱性に対する防御策を「完璧」に講じていても、公になっていない未知の脆弱性を使ったインシデントが「絶対に発生しない」とはいえない。
大事なポイントは、
各サイトのセキュリティポリシーに応じた適切なセキュリティ技術や製品を導入して、それらを適切に運用するとともに、近い将来発生し得るインシデントに備えて、事前に対応手順を明確にし、その手順に従った運用を行う
ということだ。
例えば、「事後の対応」として「事前に」検討および確認すべき項目には、以下のようなものがある。
なお、これらの項目はあくまで一例なので、各企業のサイトのポリシーなどに合わせて適宜読み替えてほしい。
- 準備
- 緊急時の連絡体制および連絡手順
- データのバックアップ手順
- 頻度
- バックアップするデータの内容
- システムの二重化
- ログの取得内容の整理および取得方法
- インシデントの発見
- ログのチェック手順
- チェックするログファイル
- ログの読み方
- データの改ざんや破壊が行われていないかの確認手順
- 署名による比較
- 汚染されていないことが確実に保証されている同じシステムとの比較
- ログのチェック手順
- インシデントからの復旧
- 復旧作業の責任者
- 個々の作業において「判断」を下すのはだれか？
- 作業記録の作成手順（記録すべき項目など）
- インシデント発見のきっかけ
- インシデントの原因
- 具体的な作業内容
- パッチの適用などの再発防止策の内容
- 復旧作業の手順
- 事実の再確認
- スナップショットの保存
- ネットワークの遮断もしくはシステムの停止
- バックアップ機などによる運用の切り替え
- 影響範囲の特定
- 必要に応じて、復旧に掛かる時間などのコストの見積もり
- 必要に応じて、復旧見込み時刻のアナウンス
- 必要に応じて、インシデントに関係するサイトへの協力依頼
- インシデントの原因の特定
- バックアップメディアからのデータの復旧
- パッチの適用などの再発防止策の検討および実施
- 復旧作業の責任者
- 復旧後の対応
- インシデントに関係していると思われるサイトへの連絡手順
- JPCERT/CCなどの公的機関への報告（届け出）手順
- 運用ポリシーや手順の見直し
これらの手順やポリシーを明確化することにより、インシデントによる被害を受けても、より短い時間でシステムを復旧することが可能となる。また、同様のインシデントの再発を防ぐことにもつながるのだ。
今回は「インシデントレスポンス」のうち、特に「事後の対応」のために「事前に」検討すべき項目を紹介した。次回はこれらのうち、「インシデントを発見する方法」について具体的に解説していく。
▼コラム▼〜CSIRTとは？ 〜
JPCERT/CCは日本の代表的なCSIRTだが、それではCSIRTとはどういった組織なのだろうか？ ここでは、世界最初のCSIRTである米国CERT/CCによるCSIRTについてのFAQを基に簡単に解説する。
Computer Security Incident Response Team（CSIRT）Frequently Asked Questions（FAQ）
- CSIRTとは？
CSIRTとは、Computer Security Incident Response Teamの略であり、「コンピュータセキュリティ・インシデント」に対応する活動を行う組織体の一般名称だ。
しばしばCERT（Computer Emergency Reponse Team）と呼ばれることもあるが、CERTという単語は米国CERT/CCの登録商標であり、その使用にはいくつかの制限がある。なおJPCERT/CCは、CERT/CCの日本支部ではないので注意してほしい。またCERT/CCは支部を設置していない。詳細はCERT/CCについてのFAQを参照してほしい。
The CERT Coordination Center FAQ - 対応内容
CSIRTが行う「対応」内容は、各CSIRTによって大きく異なる。インシデントが発生したサイトに出向いて、インシデントの原因の調査、分析、復旧作業まで行うCSIRTもあれば、復旧のための一般的なアドバイスのみを行うCSIRTもある。
またインシデントに関係したサイト（不審なアクセスのアクセス元など）への連絡を仲介するのもCSIRTが行うインシデント対応として重要な業務の1つ。 - サービス対象
CSIRTは、constituencyと呼ばれる「顧客」のサイトに関連したインシデントに対応する。constituency はCSIRTごとに定義されており、そのCSIRTの親組織であることもあれば、国や地域であったり、インシデント対応業務をサービスとして「購入」した客や会員であることもある。 - 分類
上記のような対応内容やconstituencyなどによって、CSIRTは大きく6種類に分類される。
- Internal CSIRTs
親組織をconstituencyとするCSIRT。銀行やベンダ、大学や研究機関などインターネットを利用しているさまざまな組織の中にCSIRTが存在する。特に欧米では多くの企業や大学が内部にCSIRTを構築し、自組織やその顧客に関連したインシデントに対応している。 - National CSIRTs
国や地域（の人や組織）をconstituencyとするCSIRT。JPCERT/CCはこのタイプのCSIRTの代表例とされている。また、ほかにも韓国のCERTCC-KRやシンガポールのSingCERTなど、多くの国や地域にその地域を代表するCSIRTが存在する。 - Coordination Centers
世界中のさまざまなCSIRTとのインシデント対応の連携を主たる業務としているCSIRT。米国CERT/CCがこのタイプの代表例だが、JPCERT/CCもこのような業務を行っている。 - Analysis Centers
インシデントに関するさまざまな情報を収集し、傾向や対策を研究、必要に応じて警告を発するなどの活動を行っているCSIRT。 - Vendor Teams
ソフトウェアやハードウェアのベンダ内で、自社製品の脆弱性情報の収集、分析、対策法の開発および情報発信などを行うCSIRT。社内のCSIRT（InternalCSIRT）を兼ねていることもある。 - Incident Response Providers
有償のサービスとしてインシデント対応を行うCSIRT。いわゆるセキュリティベンダがこのタイプの代表例。
- Internal CSIRTs
CSIRTの活動、特にJPCERT/CCが具体的にどのようにインシデント対応業務を行っているかについては次回以降のコラムで紹介する。
Profile
JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center（コンピュータ緊急対応センター）の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティ・インシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに加盟している日本唯一のCSIRTである。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。