• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

今週のSecurity Check

迅速なセキュリティ・インシデント対応のために

坂井順行 2002/07/22 ITpro

 自社システムのセキュリティが万全だと思っていても,クラッキングやウイルス,情報漏えいといったセキュリティ・インシデントの発生確率をゼロにはできない。もしインシデントが発生した場合には,まずは今後の対応計画を立案する必要がある。インシデントが進行している状態に身を置いていると,とりあえず目先の調査や評価にとらわれがちだが,きちんと計画を立ててからとりかかったほうが,結果的には迅速かつ効率的な対応が可能になる。

 具体的には,システム運用の回復,広報活動,攻撃者の特定などについての計画を立てる。計画を実施するには経営陣の許可が必要だろう。それについても,事前に許可を取りやすい体制を作っておく必要がある。

システム運用の回復

 インシデントの発生を検知したら,その原因および影響を受けるシステムを一時的に停止するなどして,インシデントの影響拡大を阻止することが第一だ。その後の対応として,システムを通常どおりに復旧する必要がある。そこで,まずはシステムの回復に向けた計画立案が求められる。

 回復の手順は,インシデントの種類によって大きく変わってくる。例えば,DoS(サービス妨害)攻撃などの場合には,同じ手口の攻撃を防御できるように,機器の増設やルーターの再設定などを行うことで,システム運用を回復できる。

 しかし,Webサーバー・ソフトのセキュリティ・ホールなどが原因でページの改ざんなどを許した場合には,そのセキュリティ・ホールを解消しない限り,たとえ運用を再開したとしても,ぜい弱性をふくんだままであり,再びインシデントが発生する確率は高い。つまり,見かけ上運用を回復させても意味はないということである。

 そこで,システム運用の回復の計画を立てる際には,インシデントの原因や内容を明らかにしなくてはいけない。それによって,回復手順は変わってくる。例えば,想定される以下のインシデントそれぞれで最適な回復手順は変わってくるだろう。

  • DoS
  • 組織外のユーザーによる,組織内のコンピュータ資源の不正利用
    (例えば電子メールの第三者中継,プロキシの目的外利用)
  • 組織内のユーザーによる,組織内のコンピュータ資源の不正利用
    (例えば職責以外の資源への不正アクセス,業務外目的でのコンピュータ資源の利用)
  • 情報の盗難
  • データの破壊
 インシデント発生時に,速やかに回復手順を立案できるように,平常時から,考えられるインシデントをリストアップし,その回復手順をまとめておくことが不可欠である。そうすれば,インシデント発生時に一から立案する必要がなく,用意した回復手順を“マイナー・チェンジ”するだけで対応できるだろう。

広報活動

 企業の場合は,セキュリティ・インシデントへの対策として広報活動も重視しなくてはならない。特に,インシデントが公のものとなっている場合や,顧客などにも影響を与えている場合にはなおさらである。

 具体的な方法としては,自社のサイトなどで告知するだけではなく,マスコミなどの媒体を通じて発表するという方法も考えられる。組織に広報部門が存在する場合には,その部門も当然広報活動の任を負うことになる。そのため,広報部門も“コンピュータ・インシデント対応チーム”の一員に加えておくべきだ。

 さらに,想定されるインシデントに対する広報活動の素案を用意しておくべきである。もちろん,その素案をそのまま使用することはできないだろうが,広報活動の計画立案に費やす時間を大幅に削減できる。

攻撃者の特定

 インシデントが発生したら,「システム運用の回復」と「広報活動」は急務である。それに対して「攻撃者の特定」には時間をかける必要がある。そのため,その計画立案を後回しにする場合もある。

 攻撃者が内部のユーザーである場合には,その組織内で調査できる。しかし,外部からもたらされたインシデントの場合には,攻撃者の特定は困難だ。というのも,現在国内にはセキュリティ・インシデントの攻撃元を調査するための第三者機関は存在しない。自分たちで調査を進めるしかない。

 また,他サイトの管理者などの力を借りたとしても,最後に攻撃者が経由したサイトを突き止めるのが精一杯で,攻撃者の身元を特定するには至らない。加えて,そのサイトを突き止めるだけでも,かなりの時間と資源を必要とするだろう。

最後の障害

 インシデント発生後,システム回復や広報活動(場合によっては,攻撃者の特定についても)の手順を首尾よく立案したとする。次に行うべきは,当然その実施である。しかしその前にやらなければいけないのが,経営陣から実施許可を得ることである。通常,組織(企業)における最終意思決定権者は,コンピュータ・インシデント対応チームではなく経営陣だからである。

 とはいうものの,インシデント発生後に,経営陣にその内容や対応の必要性を説明していたのでは,いたずらに時間を浪費してしまうだけだ。そのため平常時に,事前に“根回し”をしておくことが不可欠だろう。この場合も,インシデントごとに予想される手順をリストアップしておき説明しておけば,経営陣の理解を得やすい。

 以上のように,インシデントが発生したら,まず対応手順の計画を立てる必要があるが,その計画を立てやすいように,いわば“計画の計画”を立てておくことが不可欠なのだ。


坂井順行(SAKAI Yoriyuki)
株式会社ラック システムインテグレーション事業本部
sakai@lac.co.jp


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

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

設計/開発

サーバー/ストレージ

ネットワーク/通信サービス

セキュリティ

もっと見る