SEの香取です。
「このセキュリティ・アプライアンス（サービス）を検証してください」
あまり無いことかも知れませんが、もしそうなった場合に参照出来る資料が意外に少なかったりします。私自身は比較的よく検証作業をしますので「普段の作業内容をブログ記事にしておくと、誰かの役に立つかも知れない」と思い、この記事を書くことにしました。

検証作業の流れ

大体この図の様な流れになると思います。
まずはとにかく目的・・・利用目的ですね。「何のために、何を用いる」を知る必要があります。

• Webアプリケーションの改修に時間を要すため、WAFを用いて当面の対策をする。
• 既にサポートが終了してしまったミドルウェアの脆弱性対策のために、IPSを用いる。
• メール添付ファイルのマルウェア対策のために、Sandbox を用いる。

こんな感じです。
利用目的を知り、次は「一次検証」です。
この記事は一次検証にフォーカスします。結果レビュー以降は、どうしても個別対応になります。まずは一次検証をしっかり行い、その結果により後のことを決めて行くのが良いと思います。

一次検証

それでは、今回は架空のIPS装置「Coelacanthus-IPS」を検証してみましょう。なぜ、シーラカンスかというと・・・フィーリングです！（すみません）

Coelacanthus-IPS

【ご注意】実際には存在しない、架空のIPS装置です。

レポートの目次書き

大規模、複数のメンバーで行う際は「検証計画」をビシッと作り、プロジェクトとして実施したいところです。しかし、一人で作業をするときは省力化を図るため、検証後に作るレポートの目次書きをそのまま計画として利用します。

1. 検証環境
2. パフォーマンス計測
3. プラットフォームの脆弱性診断
4. Webアプリケーションの脆弱性診断
5. 考察

今回は、「1.検証環境」の構成と概要に留めます。
実際の環境構築方法、それから各計測・診断などを書くと結構なボリュームになりそうなので、記事を分けるつもりです。最終的にサンプルのレポートを完成させることが出来ると良いと思っています。

1. 検証環境

アプライアンスの検証をするときに、グローバルIPアドレスを使用することが多いです。
完全に閉じた環境で検証を行う方が安全かつ精度の高い数値・結果を得られるとは思います。しかし、現場のSEとしては実際の利用状態に近い形での検証を行いたく、この様にしています。
また、最近のアプライアンスは「クラウド連携」など、インターネットに接続されていないと不都合が生じる製品もあるため、その対策の意味もあります。

グローバルIPアドレス（a.b.c.0 /29）

管理用IPアドレス（192.168.0.0 /24）

Victim

複数の Victim があると都合が良いのですが、丁度良いサーバが確保出来なかったり、ラック内のスペースを占有したく無いこともあります。そのため、KVM を利用して複数の Victim を構築します。実際の構築方法は別の記事（次回以降）で紹介します。

図では3つの VM を使っていますが、大抵は 1VM で済ませています。ホスト側にも Web 環境を構築して、VM では BadStore を起動する事が多いです。
それから、注意点としては『ファイヤウォール設定をしっかり行っておくこと』があります。脆弱性のある環境にグローバルIPアドレスを設定するので、気をつけないと攻撃の踏み台にされる等、知らない内に加害者になってしまう可能性があります。
個人的に、ホスト側の IPTables でフィルタ設定をすることが多いです。INPUT DROP の設定をして、ローカルと a.b.c.0 /29 からのアクセスを受け付ける様にしています。

2. パフォーマンス計測

IPS あり／なし（直結）の状態での計測値を比較します。

セキュリティ・アプライアンスをネットワークに設置すると、多かれ少なかれパフォーマンスは低下します。IPSは、ディープ・パケット・インスペクション により、通信内容を取得し、シグネチャとのマッチングを行って攻撃を検知し、防御をします。
こういう複雑な処理をしながら、大量のトラフィックをさばくとしたら・・・ボトルネックになってしまう可能性がありますね。
パフォーマンスは、どの程度低下するのでしょう？ 大切なのは、きちんと数値で把握することです。そのための計測を行います。
良く利用しているツールは、Apache JMeter です。

3. プラットフォームの脆弱性診断

OS / ミドルウェアの脆弱性診断です。
通常はセキュリティ・アップデートにより対策を行います。しかし、もう更新されない “終了したプラットフォーム” を使い続ける必要があったり、修正前に攻撃されてしまう「ゼロデイ攻撃」を防ぐ目的で IPS を利用する場合があります。 また、セキュリティ・アップデートを頻繁に適用出来ない環境で「IPS が頼り」ということもあります。
この様に IPS 等のセキュリティ・アプライアンスを導入する目的は様々ですが、やはり期待されるのは防御性能です。よって、IPS あり／なし（直結）の状態で脆弱性診断を行います。この結果を比較することで防御性能が分かるはずです。

脆弱性診断をする際に重要なのは「脆弱性のある Victim を使うこと」です。yum update 等を行って、最新状態にしたプラットフォームでは「IPSなし（直結）」でも脆弱性が確認されず、比較が出来ません。
そこで、脆弱性のある OS やミドルウェアを含むイメージを利用します。具体的には BadStore です。Victim 環境の構築に少しコツが要るので、これも後の記事で解説します。
プラットフォームの脆弱性診断には、OpenVAS を使うことが多いです。

4. Webアプリケーションの脆弱性診断

本来は WAF（Web Application Firewall）の範囲ですが、最近の IPS は Injection など、一部 Web アプリケーションの脆弱性を突く攻撃の防御が可能な製品もあります。
問題なのは、同じ製品でも人によって認識が異なっていることです。「IPS で WAF の代わりになる」という人もいれば、「オマケ機能なので過度の期待をしてはいけない」という人もいます。また、IPS でも製品によって特性は異なります。
正確なところは診断をしてみない限り分からないのです。
そのための脆弱性診断です。
Webアプリケーションの脆弱性診断には、OWASP ZAP を使っています。

おわりに

次回以降で環境構築や実際の検証作業を行っていきます。
セキュリティ・アプライアンスやサービスの検証を行う方にとって、少しでも役立つ資料となりますと幸いです。
よろしくお願いいたします。