過去のコラムでは,不正侵入をはじめとするセキュリティ・インシデント*の証拠を保存する手順やツールを紹介した。今回はその続編として,セキュリティ・インシデントの調査方法について解説したい。ログの解析などはもちろん重要だが,管理者などからの聞き取り調査も重要だ。いわば“からめ手”ともいえる,人物相手の調査が有効である場合も少なくない。

* セキュリティ・インシデントとは,コンピュータ・セキュリティに関係する人為的事象(incident)のことで,意図的および偶発的に発生する。具体的には,不正侵入に限らず,弱点探索 (ポート・スキャン)や リソースの不正使用,サービス妨害(DoS:Denial of Service)などが含まれる。

調査はインシデント対応の一部

 セキュリティ・インシデント対応は,多くの場合以下に示す 1 から 5 までの手順で行われる。今回紹介する「調査(セキュリティ・インシデント調査)」は,インシデント対応の一部に過ぎない。

  1. セキュリティ・インシデントの検出
  2. 証拠の保存
  3. 調査
  4. 対応策の検討
  5. 対応策の実施

 もちろん,以上を速やかに実施するためには,事前の準備が不可欠だ。そこで,

  1. セキュリティ・インシデント発生前の準備

も,インシデント対応の一部と考えたい。

インシデントを断定する前に十分な調査を

 セキュリティ・インシデント調査は,「どのようなインシデントが発生した可能性が高いのか」を明らかにすることが目的である。調査を行うことで,次の段階である「対応策の検討」,つまり「採るべき最善の対応策は何か」を決めることができる。

 ここで注意したいのは,十分な調査時間がないうちには,調査者は発生したインシデントを断定するべきではないということだ。あるインシデントが発生した可能性が高いと思っても,それは「可能性」として伝えるべきで,事実として報告してはならない。さもないと,その後の調査や対応策をミスリードすることになりかねない。可能性があるインシデントはすべてリストアップし,そのすべてについての対応策を考えておく必要がある。

 もちろん,調査が進むにつれて,実際に発生したと思われるインシデントの候補は絞られていくだろう。しかし,調査が十分ではない段階では,調査者の主観で選択肢を狭めてしまうのは危険である。

まずは通報者からの聞き取りを

 次に,実際の調査手順について考えてみたい。ここでは,インシデントを発見して通報したユーザーと,調査に当たるユーザー(管理者)が別である場合を想定する。前者を「通報者」,後者を調査者として話を進める。

 調査者の役目は文字通りインシデントの調査である。調査のためには,以前のコラムで書いたように,インシデントが発生したと思われるコンピュータのハードディスク内容を保存し,解析する必要がある。しかし,それだけでは不十分である。やるべきことを,順を追って説明していこう。

 まずは,インシデントを発見した通報者から様々な情報を聞き出す必要がある。インシデントの発生状況はもちろんのこと,通報者の氏名や連絡先も聞いておく必要がある。後々連絡を取る必要が生じるからだ。

 少なくとも,以下の項目については聞いておきたい。

  • 通報者氏名
  • 通報時刻
  • 通報者の連絡先(メール・アドレスや電話番号など)
  • インシデントの疑いがある現象の特徴
  • インシデントの疑いがある現象の発生時刻
  • インシデントの疑いがある現象の検出手段
  • 現時点で想定できる被害範囲

インシデントの痕跡を探せ

 当然,インシデントが検出されたコンピュータ(システム)の情報収集も不可欠である。

  • コンピュータの現在の状態
  • コンピュータが接続されているネットワークの状況
  • コンピュータが他のユーザー(システム)に対して施しているアクセス・コントロール
  • インストールされている OS やソフトウエアの種類
  • コンピュータの重要度(ネットワーク運用や業務に寄与している度合い)
  • ログの有無
  • コンピュータの管理者および主なユーザーの氏名と連絡先

 以上のような周辺情報を押さえた上で,適切な方法とツールで保存した,対象コンピュータのハードディスク内容などを詳細に調査する。通報されたインシデントやコンピュータの種類などによって,調べるべき内容は変わってくるが,以下の項目は不可欠だろう。

  • 不自然なコンピュータ(ホスト)からの接続の有無
  • (上記接続がある場合)その接続元IPアドレス
  • 不正なプログラムの有無
  • DoS攻撃の有無
  • 破壊行為の有無
  • アクセス・コントロール・リストの変更の有無
  • その他不自然な動作の有無

ネットワーク構成図からも有用な情報が

 インシデントが報告されたコンピュータだけではなく,ネットワーク構成に基づいた調査も必要だ。組織に正確なネットワーク構成図が存在する場合には,それだけである程度のことを推測できる。

 例えば,インシデントが報告されたコンピュータがインターネットに接続していない場合,内部犯罪の可能性が高いと推測できる。その場合には,特定の部署にはインシデントについて調査していることを隠す必要があるかもしれない。

 インシデントが報告されたコンピュータが,インターネットに接続しているネットワークに存在する場合,そのコンピュータはもちろんのこと,同じネットワークの別コンピュータも踏み台として悪用されている可能性がある。

 また,インシデントが報告されたコンピュータが最初に攻撃されたとは限らない。組織内の別のコンピュータがまず攻撃(侵入)されて,その後に攻撃された可能性もある。最初に影響が及んだコンピュータを特定するためにも,ネットワーク構成図は有用である。構成図には,外部への接続性(インターネット,他の組織への専用線,ダイアルアップ接続など)が記されているはずだからだ。外部に直接接続しているコンピュータ(システム)が最初に攻撃された可能性は高い。

 ネットワーク構成図には,ルーターやファイアウオール,NIDS(ネットワーク型侵入検知システム)といったネットワーク機器も記載されているはずだ。構成図からは,インシデントが報告されたコンピュータと,ネットワーク機器との相対的な位置関係をつかめるだろう。位置関係が分かれば,どの機器のログが助けとなるかが分かる。その機器のログを合わせて解析することで,より詳細な情報を得られる。

 なお,ネットワーク構成図に基づいて調査する際には,物理的な接続だけではなく,コンピュータや機器それぞれが施しているアクセス・コントロールも考慮しなくてはならない。

 例えば,インシデントが報告されたコンピュータが,パートナ企業との専用線とインターネットの両方に接続されているとしよう。ただし,インターネットとコンピュータの間にはネットワーク機器(ルーターやファイアウオールなど)が設置されていて,インターネット側からはアクセスできないように設定されているとする。

 この場合には,おそらく組織内(ローカル・ネットワーク)あるいはパートナ企業のネットワークのいずれかから攻撃されたと推測できる。たとえ接続されているとしても,インターネット側からの攻撃を考慮する必要はない(もちろん,アクセス・コントロールが適切に設定されていることを確認する必要はある)。

管理者などへの聞き取り調査も不可欠

 上記のような手順で,コンピュータやネットワークの調査を進めれば,すぐに状況についての理解をある程度得られるだろう。おのずと必要な対応策も決まってくる。しかし,対応策を決定する前に,さらなる調査が必要だ。対象となるコンピュータの管理者およびユーザーからの聞き取り調査である。

 ただし,ここまでの調査で,管理者やユーザーが“容疑者”の可能性があると判断した場合には,十分注意しなくてはならない。管理者やユーザーの“証言”をうのみにすると,調査がかく乱される恐れがある。煙に巻かれることがないように,相手と議論することなく,こちら側から一方的に質問のみを行うなどの工夫が必要だ。

 管理者が容疑者でない場合には,聞き取り調査はとても重要である。インシデントの通報者とは異なり,そのコンピュータに精通している管理者ならば,発生している現象が本当にセキュリティ・インシデントなのかどうかを判断できる“はず”だからだ。特に,通報者がインシデントと判断した根拠が,ファイアウオールのログやIDS(侵入検知システム)のアラートであった場合には,実際にはインシデントでない場合も多いので,管理者への聞き取り調査は有効だ。

 管理者への質問としては,以下が考えられる。

  • 通常の運用状態と異なる点が見られるかどうか
  • 管理者以外にroot 権限で対象コンピュータにアクセスできるユーザーがいるかどうか
  • 対象コンピュータではどのようにログを採取しているか
  • 対象コンピュータではどのようなセキュリティ対策を施しているのか

 管理者への聞き取り調査が終わったら,管理者を“管理”する人物(管理者の所属長などが該当するだろう)にも聞き取り調査したい。管理者が疑わしい場合はもちろん,そうでない場合にも実施したい。この種の人物は,管理者や調査者が知らない情報を持っている場合がある。

 例えば,最近組織を離れた人物や,不平不満をこぼしている人物などを知っている場合がある。彼らがただちに容疑者になるわけではないが,調査を進める上では有用な情報だ。ハードディスクの中身の解析も重要だが,こういった情報を入手することも重要であると覚えておいてほしい。


坂井順行(SAKAI Yoriyuki)
株式会社ラック 不正アクセス対策事業本部
sakai@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。