ここからは，検証の結果を具体的に見ていく。前回の検証結果から変わった部分と，変わらなかった部分を見ながら，検証結果を考察していく。

　まず変わらなかったのは，防御チームの気づきである。前回のヤシマ作戦で最もショックを受けたのは，疑似攻撃を受けていることに防御チームが全く気づけなかったことだった。残念ながら今回も，疑似攻撃を実施している期間中，防御チームのシステム運用者はそのことに気づけなかった。

　実際には何も感知できなかったわけではなく，防御チームのシステム運用者は，特定のWebページへのアクセスがいつもと違うことや，存在しないURLへのアクセスの痕跡などを捕捉していたそうだ。だが，それが疑似的とはいえ攻撃だとは判断せず，追跡するなどの処置は取らなかった。

　前回から変わったのは，見つかった脆弱性の項目である。各データセンターのシステムで見つかった脆弱性の項目は図3の通りである。青い部分が前回脆弱性と指摘されたが今回は問題にならなかった項目，赤い部分が前回の脆弱性が残った項目または新たに脆弱性として見つかった項目である。

図3●脆弱性の検証項目と結果
図3●脆弱性の検証項目と結果
[画像のクリックで拡大表示]

　ソフィア総合研究所では，脆弱性項目数が前回に比べて4割も減少した。新たに発見された脆弱性も無かった。ただ，すべてがIDS/IPSアプライアンスの効果ではない。前回指摘されたPHPの脆弱性やOpenSSLのメモリー・バグなどの脆弱性への対策は，サーバーの設定変更によるものだ。

　一方，ライブドアとさくらインターネットでは，一部の脆弱性をつぶすことができたものの，ヤシマ作戦では見つからなかった脆弱性が新たにいくつか発見された。これは前回診断したサーバーと，今回対象としたサーバーが違うからだろう。

チューニング期間の長短で差が出た

　このように程度の差こそあれ，いずれのデータセンターでも脆弱性は残っている。では，IDS/IPSアプライアンスは大して役に立たないかというと，そんなことはない。疑似攻撃の期間中，アプライアンスは攻撃と疑われる多くのアクセスを検知し，その一部をブロックしていた。図4は，ある1日（24時間）に検知したりブロックしたりしたセキュリティ・イベントだ。件数の多いものから順番に並べている。

図4●アプライアンスがブロックまたは検知したセキュリティ・イベントのランキング
図4●アプライアンスがブロックまたは検知したセキュリティ・イベントのランキング
[画像のクリックで拡大表示]

　アプライアンスが検知したりブロックしたりしたセキュリティ・イベントは，攻撃チームによるものだけではない。本番環境を用いているので，（疑似攻撃ではない）実際の不正アクセスもカウントされている。従って，レポートされた検知数やブロック数の多寡がそれぞれのアプライアンスの性能を示しているわけではない。

　そうした点を踏まえた上で，アプライアンスによる違いに注目してみる。ソフィア総合研究所が設置した「IPS5500-1000E」（米Top Layer Networks製）が，検知件数，ブロック件数とも最も多い。特に，ポート・スキャンのブロック数はケタ違いに多い。その理由は，ほかの2社に比べてソフィア総合研究所がアプライアンスを早期に設置したからだと考えられる（ほかの2社は，ソリューション・チームからの提案や，その検討に時間を費やしていた）。設置後のチューニングに時間をかけることができたので，オデッサ作戦を開始する前に，検知やブロックのしきい値調整を十分に行えた。

　図4に示した結果を見る限り，「IntruShield1400」（米McAfee製）と「TippingPoint 1200E」（米TipppingPoint製）の捕捉したイベント数は，IPS5500-1000Eのそれに比べると少ない。だからといって，これら2 製品のイベント捕捉能力が低いとは言い切れない。なぜなら，ライブドアとさくらインターネットがそれぞれ機器を設置する時期が当初の予定より大幅に遅れ，チューニングや運用テストに十分な時間を割けなかった。それが，検知件数やブロック件数の差につながったと考えられるからだ。

　つまり，IDS/IPSアプライアンスのセキュリティ・イベントの検知性能やブロック性能は，機器設定のカスタマイズ次第で大きく変わるということだ。 IDS/IPSアプライアンスを導入する際は，テスト稼働させて情報収集し，セキュリティ・イベントを検知するためのしきい値や，ブロックするためのしきい値を設定する。今回は，前回のヤシマ作戦の結果を用いてしきい値を設定した。