PR

問題検知後の体制が重要

 検知するシステムを導入したら,今度は実際に何かが検知できたとして,その後のことを考えておく必要がある。

 防水隔壁としてのファイアウォールを導入したら,第一次の非常時対処は隔壁を閉じること,つまり浸水区画(汚染区画)を隔離することだろう。どういうイベントが起こったら,どう対処するか,緊急対処手順と連絡表は最低限そろえておく必要がある。連絡表を作るとなると,当然連絡ルートが必要になるが,もちろん体制も必要になる。

 ただ,ここで構築する体制は,必ずしもセキュリティの知識豊富な技術者である必要はないだろう。緊急対処の手順というのは,問題発生から対処まで迅速に行うためには極力パターン化しておかなければならないものだ。フローチャートくらいのレベルにまで落としておかないと,誰でもが迅速に対応を行うことはできない。

 逆に言えば,フローチャート程度までに手順を規定できれば,特に知識や技術を備えていなくても対応できるというわけだ。そこまで到達できれば,それほどコストがかからずにインシデントに対応できる態勢が整うということになる。

リスク管理の弱点

 さて,ここまで見てきたインシデント・レスポンスの仕組みは,いわばセキュリティのベースインフラとでも言うべき部分である。インフラによって,さまざまな通信の記録を取り,いざインシデントが起こった場合には防水隔壁を落として,被害を最小限にとどめるという,言ってみればこれだけのことである。このインフラのベースにある考え方は,冒頭に述べたように「エンドユーザーを信用しない」というものだ。

 ほかの「エンドユーザーを信用しない」に関連するセキュリティ管理に,端末管理の仕組みがある。例えば,さまざまなフリーのセキュリティ・ツールをコンポーネントとして利用して,各端末のリスク監査,管理やネットワーク管理,監視を行う仕組みに「OSSIM-Open SourceSecurity Information Management」というシステムがある。

 ほかにも,この種の統合的セキュリティ管理システムはいくつかあるが,機能的には似通っていて,端末監査や管理,ネットワーク・モニターなどの機能を備えている。こうした仕組みは,どちらかといえばリスク管理で,確かにリスクを判別・判定するのには便利だ。

 しかし,リスクの「管理」という側面には弱さがある。「管理」ということになると,常に一定のレベルを保つべく動かなければならないわけだが,例えばパッチの適用だとか,そういう部分はそれこそマイクロソフトのSUSでも援用しないと実現できなかったりする。

 SUSなしで実現できるような機能を持った製品であっても,例えばActiveXを使っていたりとか,まだまだ一長一短あるようだ(ほかならぬWindows UpdateもActiveXを使っているようだが)。パッチ管理はどうにかして負荷を軽減したい課題であるが,なかなか困難だ*

* 筆者のお勧めはいっそのこと,すべてのPC端末にパケット・フィルタリング型ファイアウォールを導入することだ。お仕着せの既製服ミニマム・ポリシーでフィルタし,例えば,そもそも135番ポートを外に向けて公開しなければ,パッチの適用は急がなくてもよい。

園田 道夫 Michio Sonoda

筆者は情報処理推進機構(IPA)の脆弱性分析ラボ研究員,および日本ネットワークセキュリティ協会(JNSA)の研究員を務める。JNSAではハニーポットワーキンググループ,セキュリティスタジアム企画運営ワーキンググループのリーダーとして活動している。MicrosoftのSecurity MVP。現在セキュリティ夜話(http://www.asahi-net.or.jp/~vp5m-snd/sec/),極楽せきゅあ日記(http://d.hatena.ne.jp/sonodam/)にて連続的に読み物掲載中。