インシデント発見時の対応手順：管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜（4）

本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント（不正アクセス）に関する情報を紹介する。（編集局）

[JPCERT/CC，＠IT]

　第2回と第3回の2回にわたり、インシデントを発見する方法を紹介した。今回はそこで紹介したような方法で何らかのインシデントを発見した、または外部からの通報でインシデントが発生していることに気が付いた場合の一般的な対応手順を紹介する。

（0）冷静に対処する

　まずは落ち着くことが大切である。一般に、インシデントと思わしき事象を発見すると、人は冷静さを失ってしまうものである。しかし冷静さを失ってしまったがために、そもそもインシデントでも何でもなかったものをインシデントと勘違いしたり、また、さほど深刻ではないインシデントの被害や影響範囲を無用に拡大してしまうこともあるのだ。十分に注意してほしい。

（1） 手順の確認

　すでに手順が決められている場合は、その内容を確認する。セキュリティポリシーや作業マニュアルは、参照しやすい場所に用意しておく。

（2） 作業記録の作成

　時刻情報を含めた形で作業内容を記録する。

　この作業記録は、作業時の手順を後日評価する際の資料に用いられるだけでなく、作業中に副次的に障害が発生した場合などには、 作業手順のポリシーなどを見直すための重要な資料となる。

（3） 責任者、担当者への連絡

　発見者がインシデント対応担当でない場合には、事前に定められた連絡手順に従い、組織内のインシデント対応チーム（CSIRT）などの担当者に連絡し、指示を仰ぐ。また、インシデントの内容や程度によっては、組織内のほかの部署とも協力して対応を行わなければならない場合がある。その場合は、事前に定められた各部署の担当者などにも連絡する。

　あらかじめ想定されるインシデントを大まかにリストアップし、それぞれに応じた責任者や担当者を定め、連絡網を整備しておくことをお勧めする。インシデントの種類については、文末のコラムを参考にしてほしい。

（4） 事実の確認

　どのようなインシデントが起こっているのか、冷静に事実関係を確認する。

　外部からの不審なアクセスが、必ずしもすべて悪意によるアクセスとは限らないことに注意してほしい。自らの操作ミスや管理者による作業の可能性もある。あるいはシステム自体のバグなどによる障害の可能性も否定できない。注意深く確認してほしい。

　特に注意しなくてはいけないのは、113/tcp（ident、auth）へのアクセスである。これは、何らかのサーバにアクセスした際に、そのサーバがアクセス元に対して、アクセスしてきたクライアントを実行しているユーザーのユーザー名を取得するために逆にアクセスしてくるものである。

※ ident プロトコルについての詳細は以下の文書を参照してほしい。

RFC 1413“Identification Protocol”（http://www.ietf.org/rfc/rfc1413.txt）

　identのように、自サイトからのアクセスの波及効果として外部からアクセスを受けた場合、その外部からのアクセスを「外部からの（何らかの）攻撃」と誤解してしまうことが多々ある。まずは「不審なアクセス」がそのようなアクセスでないかどうかを確認する。

（5） スナップショットの保存

　システム自体に、ある程度の影響が想定される場合には、後々の調査に備えてインシデント発生時のシステムのスナップショットを保存する。

　保存する項目はインシデントの内容によって異なる。例えば、ログイン状況（who）や履歴（last）、各種サーバのログ（/var/log/*など）、ネットワーク接続の状況（netstat -a）やプロセステーブル（ps）といったシステムの稼働状況に関する記録を保存したり、HDのイメージをそのまま外部記憶装置（テープなど）に保存するといったことが考えられる。

　ただし、システムにおいて何らかの改ざんが行われている場合は、システム上のコマンド自体も改ざんされている可能性が高い。コマンドを用いて上記のような情報を取得する場合には、チェックサムを確認する、または外部メディア（CD-ROMやFDなど）に保存したコマンドを用いるなど、十分に注意したうえで作業を行ってほしい（詳細は「第3回 インシデントを発見する方法（2）」参照）。

（6） ネットワーク接続やシステムの遮断もしくは停止

　DDoS（分散型サービス運用妨害）攻撃用ツール（Agent）を設置されたり、ワームに感染した場合などは、自システムが他サイトの攻撃に（踏み台として）悪用されることになる。このような形で被害が拡大する恐れがある場合には、ネットワークやシステムの全体もしくは一部を遮断または停止する。

　しかし、ただやみくもに遮断／停止すればいいというわけではない。遮断や停止の結果として、システムに甚大な2次被害を与えたり、またほかのシステム（自サイトおよび他サイト）にも影響を与えてしまう可能性がある。遮断や停止については、事前に意思決定プロセスや判断基準を整理しておくとともに、具体的な作業手順についても明確に定めておく必要がある。

（7） 影響範囲の特定

　これからの対応を判断する前提として、どのような種類の影響が、サイト内外のどの範囲にまで、どの程度生じているかを調べる。

　例えば、ほかのシステムとの通信履歴などから、関連するサイトを調べたり、ファイルへのアクセス状況（最終アクセス時刻など）から機密情報の漏えいがなかったかどうかを調べる。特に、持ち出されたり、参照された可能性のあるファイルが、自サイトにとってどれだけ「機密」に当たるものかを確認し、以後の対応を検討する。

　また、踏み台として他サイトへのアクセス（攻撃）に使われた可能性がある場合には、実際に自サイトから外部に対して「いつ」「どのような」アクセスが行われたかを、システムのログやルータなどのネットワーク機器のログなどから整理しておく。

（8） 渉外、関係サイトへの連絡

　インシデントの影響の程度により、サイト内外への事情説明や謝罪などが必要とされることがある。広報や渉外などの担当者と調整し、必要な情報を提供する。

　また、ほかのサイトがインシデントに関係している可能性がある場合（例えば、アクセス元）には、それらのサイトに必要な情報を提供し、協力して解決に取り組めないかどうかを検討する。しかし関係するサイトへの連絡にはリスクも伴うため、注意が必要である。

※ このような「関連サイト」に連絡する際の注意事項や手順については次回に紹介する。

（9） 要因の特定

　インシデントの再発を防ぐための再発防止策について検討するために、インシデントが発生した要因（原因）を特定する。

　例えば、システムの設定に問題がなかったかどうか、また使用しているOSやソフトウェアのセキュリティ上の弱点で対策を講じていなかったものがなかったかどうか、などをベンダや配布元の提供する情報を参照して確認する。またJPCERT/CCや米国CERT/CCなどのCSIRTが提供する情報も参考になるであろう。

※ JPCERT/CCからの情報としては、前の週のセキュリティ関連情報の要約である「JPCERT/CCレポート」、深刻な脆弱性の発見やワームの感染の広まりなどについての緊急告知である「注意喚起」、実際に多くの被害が発生しているインシデントに関するレポートである「緊急報告」の3つの文書がある。いずれもJPCERT/CCのWebサイト（http://www.jpcert.or.jp/）から閲覧できるので、参考にしてほしい。

（10） システムの復旧

　何らかの改ざんやデータの破壊が行われた場合には、バックアップメディアあるいは配布メディアからシステムを復旧する。

　バックアップデータを保存した時点で、すでにシステムが改ざんされていた可能性がある場合には、意図しない設定やプログラムが記録されていると考えられる。バックアップメディアからの復旧に際しては、それらの意図しない情報を書き戻さないように注意する必要がある。

　最悪の場合、バックアップメディアからの復旧をあきらめ、配布メディアによる初期インストールが必要となる場合もある。

（11） 再発防止策の検討

　上記（9）において特定した要因に対して、どのような対策が可能か検討する。

　例えば、使用しているOSやソフトウェアのセキュリティ上の弱点が悪用された（と考えられる）場合には、ベンダや配布元の提供する情報を参照し、問題を修正するために必要なパッチなどの情報を確認する。パッチの適用やソフトウェアの更新などによる対策が困難もしくは不可能な場合には、可能な回避策を調査する。

　また、パスワードデータベースの情報が盗まれた可能性がある場合には、全ユーザーのパスワードを変更しておく必要がある。

（12） 監視体制の強化

　一度、攻撃に成功し、脆弱なサイトとして情報が流されると、引き続き何らかの攻撃を受ける可能性が飛躍的に高まる。インシデントの再発に備え、監視体制を強化する必要がある。

（13） 作業結果の報告

　作業終了後、記録に基づいて、作業内容や作業にかかったコスト（時間、費用など）、また（確認された範囲内での）損失をまとめ、責任者に報告する。

（14） 作業の評価、ポリシー・運用体制・運用手順の見直し

　作業報告に基づいて、セキュリティポリシーに定められた手順に不十分な点がなかったかどうかを確認し、必要に応じてポリシーを見直す。またこれまでの運用体制や運用手順、さらに今回実際に行ったインシデント対応作業に問題がなかったかどうかを確認する。

（15） JPCERT/CCへ報告

　JPCERT/CCへのインシデント報告については、以下のURLで示されるページを参照。

　JPCERT/CCへの連絡方法（http://www.jpcert.or.jp/form/）

---

　今回は、インシデントを発見した後の一般的な対応手順を紹介した。紹介した内容はあくまで一般的なものであり、インシデントの内容やサイトの運用形態によって詳細は異なる。記事の内容を参考にして、自サイトのための対応手順を整理してまとめておくことを強くお勧めする。

　次回は、インシデントに関連したサイト （特にアクセス元） に連絡する際の注意事項を紹介する。

■参考文献
[1] 技術メモ - コンピュータセキュリティインシデントへの対応
http://www.jpcert.or.jp/ed/2002/ed020002.txt

■コラム 〜インシデントの分類（Taxonomy）〜

　インシデントには、システムの改ざんを伴う深刻なものから、弱点探索といったシステム自体には深刻な被害をほとんど与えないものまで、さまざまな種類がある。

　今回は、米国Sandia National Laboratoriesの報告書「A Common Language for Computer Security Incidents」（http://www.cert.org/research/taxonomy_988667.pdf）によるコンピュータセキュリティインシデントの分類、特に「Attack（攻撃）」の分類について簡単に紹介する。

※ JPCERT/CCによるインシデントの分類については、「第1回 インシデントレスポンスとは？」の記事を参照してほしい。

（1） 分類の視点

　Sandiaの報告書では、Attack（攻撃）を以下の5つの視点で分類している。

1 Tool（道具）	どのようなツール（tool、 道具）が使われたのか？
2 Vulnerability（脆弱性）	どのようなセキュリティ上の弱点（脆弱性）が悪用されたのか？
3 Action（行為）	どのような行為が行われたのか？
4 Target（攻撃対象）	何を攻撃の対象とされたのか？
5 Unauthorized Result（攻撃結果）	結果としてどうなったのか？

（2） 分類項目

　上記 5つの視点での各分類項目について紹介する。

1. Tool（道具）
   
   ウイルス、ワーム、rootkit（「第3回 インシデントを発見する方法（2）」を参照）や盗聴用ツールといった、攻撃用の「道具（Tool）」だけでなく、物理的な破壊や盗難、さらに「Social Engineering攻撃」のような「非技術的手法」もToolに含まれる。
   
   
2. Vulnerability（脆弱性）
   
   ハードウェアやソフトウェアの設計上の脆弱性（Design Vulnerability）、実装上の脆弱性（Implementation Vulnerability）、設定上の脆弱性（Configuration Vulnerability）の3つに分類される。
   
   「設定上の脆弱性」としては、パスワードの設定ミスやファイルのアクセス権限の設定ミス、さらに脆弱なサービスの有効化などが含まれる。
   
   
3. Action（行為）
   
   プローブ（Probe）やスキャン（Scan）、攻撃先へ過負荷をかけるアクセス（Flood）、パスワードの盗用などによるユーザーへのなりすまし（Authenticate）、代替手段による認証の手続きなどの回避（Bypass）、IPアドレスやドメインネーム情報の偽造や電子メールアドレスの詐称などのネットワークを介したなりすまし（Spoof）、データの読み出し（Read）、複製（Copy）、窃盗（Steal）、改ざん（Modify）、削除（Delete）の11種類に分類される。
   
   ここで、プローブ（Probe）とスキャン（Scan）は、それぞれ次のように定義され、区別される。
   
   
   • プローブ（Probe）
     ターゲットの特徴（サーバプログラムのバージョン情報など）を知る目的でのアクセス。
     
     
   • スキャン（Scan）
     ある特定の特徴（脆弱なサーバプログラムを使っているか否かなど）を、一連のターゲットの中のどのターゲットが持っているかを確認するための、連続したアクセス。
     
     また、AuthenticateとSpoofは「なりすまし」としては同じであるが、次のように区別される。
     
     
   • なりすまし（Authenticate）
     何らかの方法で手に入れた他人のパスワードなどを使って「正規のユーザ」と偽るといった「認証（Authenticate）」の手続きを経る行為である。
     
     
   • なりすまし（Spoof）
     認証の手続きとは無関係に単なる「虚偽の情報」を示す行為である。
     
     
   • 回避（Bypass）
     何らかのセキュリティ上の弱点を悪用するなどして、本来行わなければならない認証の手続きを回避（Bypass）して、ユーザーや管理者の権限を取得するといった行為である。
     
     データの読み出し（Read）、複製（Copy）、窃盗（Steal）、改ざん（Modify）、削除（Delete）は次のように区別される。
     
     
   • 読み出し（Read）
     対象となるデータを「読む」こと。複製（Copy）や窃盗（Steal）の必要はない。
     
     
   • 複製（Copy）
     対象となるデータのオリジナルをそのまま残しておき、複製を作成すること。データの内容を「読む」必要はない。
     
     
   • 窃盗（Steal）
     対象となるデータへの、本来の所有者によるアクセスや使用を不可能にする。例えば、データを「複製」した後に「削除」する、またはデータの収められたメディア（FDなど）を盗み出すといった行為。
     
     
   • 改ざん（Modify）
     データの内容や特徴（属性など）を変更する。
     
     
   • 削除（Delete）
     データを削除する。もしくは修復不可能な状態にする。
4. Target（攻撃対象）
   
   ユーザーアカウント（Account）、プロセス（Process）、データ（Data）、コンピュータ（Computer）、ネットワーク（Network）、コンピュータやネットワークを構成する個々のパーツ（Component）、ネットワーク間のネットワーク（Internetwork）の7つに分類される。
   
   
5. Unauthorized Result（攻撃結果）
   
   権限のないアクセスの増加（Increased Access）、情報の漏えい（Disclosure of Information）、データの改ざん（Corruption of Information）、サービス運用妨害（Denial of Service）、資源の無断使用（Theft of Resources）の5つに分類される。

（3） そのほかの分類

　Sandiaの報告書におけるインシデントの分類には、上記で紹介した「攻撃」という視点での分類のほかに、Attackers（攻撃者）やObjectives（攻撃の目的）という分類がある。詳細は、Sandiaの報告書を参照してほしい。

Profile

JPCERT/CC

JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center（コンピュータ緊急対応センター）の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに日本で最初に加盟したCSIRT。