 |
||
|
［目次］ [第1章] [第2章] [第3章] [第4章] |
  |
| 第4章 Cisco Secure IDSでのセキュリティ監視 |
第1項 Cisco Secure IDSの設置・設定
第3章までは、IDS全般に関する設置場所などについて説明してきました。本章では、Cisco Secure IDS Version3.1を利用して、導入からポリシーの設計、適用方法まで説明していきます。
Cisco Secure IDSは下記3つの構成により、セキュリティ監視を実現します。
●Cisco IDS Sensor
ネットワーク上のパケットを監視し、監視ポリシーに従い不正なパケットを検知し、通知などを行います。
●Cisco IDS Device Manager
Webブラウザを利用して、Sensorの監視ポリシーなどの管理を行います。
●Cisco IDS Event Viewer
Javaベースのアプリケーションです。Sensorで検知したログをGUIにて表示します。
1.1 設置場所
この章では、具体的な設置場所を考え、その環境に適した設定というものを考えてみます。以下のような基本的なネットワーク構成を想定して説明していきます。
 |
| 図4-1. ネットワーク構成図 |
図4-1に記載されている通り、DMZセグメント上を流れるパケットを監視します。Sensorが導入されるホストでDMZセグメントに接続されているインターフェイスにはIPアドレスを割り当てず、ステルス監視とします。DMZ セグメントに接続されているインターフェイス上では、パケットのキャプチャのみ可能であれば良く、通信を行える必要はありません。よって、IPアドレスを割り当てる必要はないのです。
Cisco Secure IDSを導入するにあたり、事前に決定しておかなければならない項目があります。まずは、それを決定し導入作業をスムーズに行いましょう。全ての項目について、Sensor，IEV共に必要な情報です。
| 表4-1．決定項目 |
|
1.2 Cisco IDS Sensorの導入
Cisco Systems社より、IDS専用機として、IDS-4230シリーズ、IDS-4210が用意されています。
まずは、この専用機へIDS Sensorのインストールを行います。表4-2がインストール手順です。
| 表4－2. Cisco Secure IDS Sensorインストール手順 |
|
1.3 Cisco IDM(IDS Device Manager)を利用しての設定
Cisco IDMはSensorのネットワークに関する諸設定や、監視ポリシーの設定、ログの管理までを行う統合的な管理モジュールです。Webインターフェイスを持っているので、Webブラウザを利用して各種設定作業を行うことになります。
Cisco IDMへのアクセスには、通常のhttp(80/TCP)だけでなく、https(443/TCP)を利用することも出来ます。
また、利用するポート番号は、任意で設定可能です。
●Web Browsers
・Netscape (version 4.5 or newer)
・Internet Explorer(version 5.01 ServicePack1 or newer)
●Operating System
・WindowsNT 4.0 ServicePack 6
・Windows2000 Professional or Server
・Solaris SPARC version 2.7
・Solaris SPARC version 2.8
●Security communications
・SSL
IDMにはブラウザを利用してアクセスします。アドレスを以下のように入力します。更に、認証画面では、以下の情報の入力を求められます。
|
※注意
Cisco IDMに接続するとユーザ名、パスワードの入力を求められます。上記の情報は初期設定の値です。パスワードは初期設定から直ぐに変更しましょう。
 |
| 図4-2. ログイン画面 |
ログインに成功すると、図4-2が表示されます。ここからリンクを辿り各種設定変更などを行うのです。
1.4 パスワードの変更
ログインに成功後、最初にパスワードをデフォルト値から変更することを推奨します。パスワードのデフォルト値は公開されているため、第三者によりアカウントのなりすましを招く恐れがあります。Cisco IDMへのログインを許してしまうと、監視ポリシーの変更やログを削除されてしまうなど、セキュリティ監視に障害が発生する可能性があります。
IDSを利用して、ネットワークのセキュリティ監視を行うのであれば、設置するIDS自身のセキュリティレベルにも注意を払わなければなりません。
 |
| 図4-3. パスワード変更画面 |
1) Cisco IDMのメインウィンドウから、Device > Sensor Setup > Passwordを選択します。図4－3のパスワード変更画面が表示されます。
2) Current Passwordフィールドに現在設定パスワードを入力します。
3) New Passwordフィールドに新しいパスワードを入力します。
4) Password Againフィールドに確認のため、再度新しいパスワードを入力します。
※注意
パスワードに設定する文字列の長さには注意が必要です。英数字や記号をパスワードの文字列に含ませ複雑なものにするのは当然ですが、Cisco IDMでは、1文字以上、8文字以下という制限があります。9文字以上のパスワードを設定しても9文字目以降は切り捨てられます。仮にパスワードをciscosensorとしてもciscosenterと同じであると認識されてしまいます。
1.5 ネットワークの設定
ブラウザ経由でログイン後、現在のネットワークに関する設定Cisco IDMを利用して変更することが出来ます。
 |
| 図4-4. ネットワーク設定画面 |
1) Device > Sensor Setup > Networkと順に選択します。図4-4のネットワークに関する設定画面が表示されます。
2) 必要な項目の設定を行います。
3) 設定完了後、OKボタンをクリックします。
Cisco IDMを利用してネットワークに関する設定は可能ですが、Sensorが導入されているホストにログインし、sysconfig-sensorコマンドを実行することで変更することも可能です。ネットワークに関する設定を変更する際は、Consoleログインが可能な環境を用意することを推奨いたします。ネットワーク経由での環境のみである場合、万が一、操作ミスにより設定を誤ってしまうとネットワーク経由でのログインが不可能になります。
1.6 リモートホストの追加
IDS Event Viewerへアラームを通知するには、Sensor側での設定が必要になります。IDS Event Viewerに関する情報をSensorへ登録します。
まずは、リモートホストの情報を追加します。
 |
| 図4-5. Remote Hosts Panel |
1) Configuration > Communication > Remote Hostsの順に選択します。図4-5がリモートを追加する画面です。
2) AddボタンをクリックしCisco IDS Event Viewerを導入済み(予定)のホストに関する情報を登録します。図4-6が登録画面です。
 |
| 図4－6. Remote Hosts Adding Panel |
3) 必要な情報を登録します。
4) 登録完了後、OKボタンをクリックします。
※登録を解除する場合は、解除するホストを選択し、Deleteボタンをクリックします。
1.7 イベントの通知
Cisco IEVを利用してリアルタイムでアラームを表示させるためには、Cisco IEVが導入されているホストにログを転送するように設定しなければなりません。
 |
| 図4－7. Event Destination登録画面 |
1) Cisco IDMのメインパネルからCommunications > Remote Hosts > Event Destinationの順に選択します。図4-7はログに関する保存方法などを設定する画面です。ここで、Cisco IEVにログを転送するように設定します。
2) id は自動的に割り当てられます。そのままの値にします。
3) HostにはCisco IEVを選択します。
4) 指定したレベル以上のログを通知するようになります。ここではinformationを指定することを推奨します。
5) Serviceにはsmidを指定します。
6) TypeにはAlarms、Errors、CmdLogs、IpLogsを指定します。
7) 設定完了後、OKボタンをクリックします。
※注意
ここでの設定内容はログをCisco IEVに転送し、Cisco IEVを利用してアラームの内容を確認することを前提とした設定内容となっています。
また、ログはSensor側にも保存しておいたほうが良いでしょう。HostにSensorを選択し、Serviceにloggeredを選択することで、保存することが出来ます。
1.8 Cisco IEV(IDS Event Viewer)の導入
Cisco IEVはSensorを利用することで検知したアラームをリアルタイムで表示することが出来ます。また、Sensor側に保存されているログファイルの内容を表示することも出来ます。
Cisco IEVは以下のアプリケーションを利用しています。
●Java2 Runtime Environment Version 3.0
●CSIDS DataFeed Software Development Version 1.3.0
●MySQL server Version 3.23
1.8.1 インストールモジュールの入手
インストールモジュールを入手します。これはSensorからダウンロードすることができです。Cisco IDMメインパネルから、Monitoring > IDS Event Viewerの順で選択します。
 |
| 図4-8．IEVダウンロード画面 |
図4-8はCisco IEVに関する画面です。まずは、ReadMeを確認しましょう。その後、Cisco IEVの導入を予定しているホストの適当なフォルダにダウンロードします。
1.8.2 Cisco IEVのインストール
 |
| 図4-9. インストールの準備 |
Sensorからダウンロードしたセットアッププログラムiev-win-3.1.exeをダブルクリックし、インストールを開始します。最初にWelcome画面が表示されます。Nextボタンをクリックして、次へ進みます。
 |
| 図4-10. インストールフォルダの指定 |
次にインストール先を選択します。プログラムのインストール先を指定するのであればBrowseボタンをクリックし、インストール先を指定します。インストール先が決定したのであれば、Nextボタンをクリックして、次へ進みます。
 |
| 図4-11. プログラムメニューへの登録 |
プログラムメニューへ登録名前を指定します。指定が完了したら、Nextボタンをクリックし、次へ進みます。
 |
| 図4-12. インストールの開始 |
Nextボタンをクリックするとインストールが開始されます。
 |
| 図4-13. インストール画面 |
インストール中の画面です。インストールが完了したら、Nextボタンをクリックします。
 |
| 図4-14. 設定画面 |
Cisco IEVに関する必要項目を入力します。入力完了後、Nextボタンをクリックしてつぎへ進みます。ここで入力した情報は、後にSensor側に登録する必要があるため、メモを取るなどしましょう。
 |
| 図4-15. 完了画面 |
これで、インストール作業は完了です。Finishボタンをクリックします。
 |
| 図4-16. 再起動要求画面 |
インストールが完了すると、OSの再起動を要求されます。起動しているアプリケーションを停止しOKボタンをクリックして再起動します。
1.8.3 Sensorの登録
Cisco IEVインストール後、Sensorの登録を行います。Cisco IEVを起動後、File > New > Deviceを選択します。
 |
| 図4-17. Sensor登録画面 |
図4-17はSensorの登録画面です。Sensorに関する情報を入力します。入力完了後、OKボタンをクリックします。
1.8.4 Sensorとの導通確認
Cisco IEVでの設定が完了後、Sensorとの導通確認をします。Cisco IEVの画面上でSensorを選択しDevice Statusをクリックします。
 |
| 図4-18. 接続状態 |
ここで、通信が上手くいかずエラーが返されるようであれば、snoopコマンドを利用してパケットをキャプチャするといいでしょう。登録されているSensorのIPアドレスや、設定されているポート番号に誤りがないか確認します。
1.9 ステルスモードの設定
ネットワーク上のパケットを監視するインターフェイスを指定することが出来ます。この実際にネットワークを監視するインターフェイスにはIPアドレスを割り当てず、0.0.0.0とします。
監視用インターフェイスのIPアドレスの変更は、OSの設定変更になります。そこで、Sensorが導入されているマシンにログインし、監視用インターフェイスのIPアドレスを変更します。
| 表4-3. IDS－4230シリーズの場合 |
|
IPアドレスの変更が完了したら、次にネットワークの監視を行うインターフェイスを指定します。
 |
| 図4－19. Sensing Interface |
1) Configuration > Sensing Engine > Sensing Interfaceの順で選択します。図4-19で監視用のインターフェイスを指定することが可能です。
2) Customを選択し、インターフェイス名を入力します。
3) Traffic Flow SeverityはHigh(default)を選択します。
4) Traffic Flow Timeoutは90(default)を指定します。
5) Link Status Alarm LevelはHigh(default)を選択します。
6) Storage Timeout Secondsは100(default)を指定します。
7) 各設定項目の指定の完了後、OKボタンをクリックします。
第2項 ポリシー設計
導入作業が完了し、SensorとIDM間の通信が確立されたことを確認出来たのであれば、次に環境に合わせた監視ポリシーを作成しなければなりません。この項では、Cisco Secure IDSでの監視ポリシーを設定について説明していきます。
2.1 ポリシー設計の前に
Cisco IDSでは、約400個ものシグネチャが標準で用意されています。これらのシグネチャ全てを監視対象とすればいいのでしょうか？その他にもカスタマイズしたシグネチャの作成も可能です。
確かに間違いではありません。しかしながら、全ての項目を監視対象とすれば良いというものでもありません。
また、セキュリティ監視を目的によっても変わってくるものです。どのような脅威を想定し、セキュリティ監視を行うのか、どのホストを監視対象ホストとするのか予めセキュリティポリシーにて定義するべきでしょう。
本章の冒頭にもあります通り、DMZセグメントに設置することを想定しています。このポリシー設計についてもDMZセグメントに設置することを前提として考えられています。
監視ポリシーを考えるのであれば、設置する環境を正確に把握しなければなりません。再度ネットワーク構成図を確認することで、監視対象となるホストに関する情報の洗い出しを行いましょう。以下3つのホストが監視対象となります。
●Webサーバ
●DNSサーバ
●メールサーバ
更に各ホストにおいて、提供されているサービス、使用しいているアプリケーション名、バージョンまで把握しましょう。
また、通常DMZセグメントの境界にはFirewallが導入されています。このACLを正確に把握することも、監視ポリシーを作成するにあたって非常に重要な情報になります。
各ホスト上で提供されているサービスが、必ずしも他のセグメントからアクセスが許されているわけではありません。これはセキュリティポリシーに沿った形となっているでしょう。Cisco Secure IDSでは、攻撃と思われるパケットを検知するだけでなく、特定のサービスに関してのコネクションを監視することが出来るのです。
2.2 既知の攻撃に対する監視
Cisco Secure IDSでは、既知の攻撃方法をもとに約400個ものシグネチャが用意されていることは既に紹介した通りです。Cisco Secure IDSでは、これら既知の攻撃に関するシグネチャをSignature Groupsとし攻撃手法などにより分類されています。まずは、このSigunature Groupsで用意されているシグネチャを利用しての設定を考えてみたいと思います。
2.2.1 HTTPに関するポート番号の決定
STATE.HTTPシグネチャを設定し、不正なアクセスを監視するためには、HTTPサービスを提供しているポートを指定しなければなりません。通常であれば、80番ポートを利用していますが、PROXYサーバなどを導入しているのであれば、8080番ポートにHTTPサービスを提供していることが考えられます。また、アプリケーションの設定にWebブラウザを利用するものがあれば、その設定のために利用するポート番号も併せて指定します。
Cisco IDMのメインパネルからConfiguration > Sensing Engine > Service Portsの順で選択します。
 |
| 図4-20. Service Port |
図4-20はポートを指定する画面です。HTTP.STATE engineで使用したいポート番号を指定します。
2.2.2 Signature Groups
Cisco Secure IDSでは、監視ポリシーはCisco IDMによって管理されています。監視ポリシーの設定もCisco IDMを利用して行います。
Cisco IDMのメインパネルからConfiguration > Sensing Engine > Signature Groupsの順で選択します。
 |
| 図4-21. Signature Groups |
図4-21がSignature Groupsの設定画面です。既知の攻撃手法を利用しての攻撃を検知するために、シグネチャが大きな項目ごとに分かれています。これらシグネチャの中で、監視対象とマッチすることがあれば、アラームを通知するのです。
この項の冒頭で記した通り、全てのシグネチャを監視対象としても間違いでありませんが、環境によっては好ましいものではありません。
Cisco SensorをDMZ上に設置することを想定しています。監視対象となるシグネチャが多ければ多いほど、Sensorへの負担が増加します。つまり、全てのシグネチャを監視対象とすると必然的にSensorが導入されているホストの負荷を増加させることに繋がるのです。
また、監視対象とされるシグネチャの数が多ければ、ネットワーク型IDSにとってはつきものと言える、多くの誤検知を招く恐れが高まり、IDSの管理自体に影響を与える結果を招きかねないのです。
確かに、環境によっては、ほぼ全てのシグネチャを監視対象としなければならないこともあります。これは、運用上の仕方がないものであれば仕方がないでしょう。しかしながら、何ら考慮せずに全てのシグネチャを監視対象とするのであれば事情は違ってきます。運用面のことも考慮し、監視ポリシーを設計しなければならないのです。
IDSの監視ポリシーを作成する上での考え方として、負の考えかというものがあります。このように既に用意されているシグネチャに関しては、基本的に全て監視対象として、そこから環境に合わせて、不必要なものに関しては監視対象外としていくのです。
監視対象となるシグネチャを一つ、一つ積み上げていくのではなく、削除していくのです。この考え方をもとに具体的に考えてみましょう。
ファイアウォールが導入されているのであれば、セキュリティポリシーに沿った形でアクセス制限が設定されていることでしょう。このアクセス制限によりDMZ上の特定のホスト、サービスに対してアクセスが許可されていないのであれば、当然、DMZセグメント上にこれに関するパケットが流れることはありません。つまり、その特定のサービスに関するシグネチャについては、監視対象としても検知することはないのです。
そこで、これらいくら監視対象としても検知することがないシグネチャについては監視対象外とすることが出来るのです。
ポイント(1)
監視対象としても検知することが出来ないものについては監視対象外とする。
これはファイアウォールの設定に間違いがないことを前提としています。しかしながら、必ずしもファイアウォールの設定に間違いがないとは言い切れません。そこで、ファイアウォールの設定に対しても監査を行うことで、この問題を回避することが出来ます。詳細については、後ほど記したいと思います。
想定されているDMZセグメントにはWebサーバが設置されています。これは、ファイアウォールの設定でもインターネット上の全てのホストからのアクセスが許されていることが多いでしょう。そこで、HTTPサービスについての設定を考えてみます。
図4－21を見ると分かる通りSignature Groupsは、サービス単位など大きな項目ごとに分かれています。これは、攻撃手法の違いとも考えることが出来ます。HTTPサービスに関するシグネチャはWWW Signaturesです。更にWWW Signaturesは細かい攻撃手法ごとのシグネチャが用意されています。既知の攻撃手法についてのシグネチャを確認してみましょう。
HTTPサービスに関するシグネチャを確認するにはメインパネルからConfiguration > Sensing Engine > Signature Configuration > Signature Group > WWW Signatureの順で選択します。
 |
| 図4-22. WWW Signatures |
図4-22が、HTTPサービスに関するシグネチャです。
まずは設定方法を紹介し、どのシグネチャを監視対象とすればいいか考えてみたいと思います。
●監視対象にする場合
1) 監視対象するシグネチのチェックボックスにチェックを入れます。
2) Enableボタンをクリックします。
3) 画面最上部にあるApply Changesをクリックします。
※Select Allをクリックすると全てのシグネチャに対し、一度にチェックを入れることが可能です。
●監視対象外にする場合
1) 監視対象するシグネチのチェックボックスにチェックを入れます。
2) Disableボタンをクリックします。
3) 画面最上部にあるApply Changesをクリックします。
これら数多くのシグネチャの中で、何を監視対象とし、何を監視対象外とするかの判断が必要になります。一つの判断基準として、OSやアプリケーションによって判断することが挙げられます。
HTTPサービスに関する攻撃手法というものは、全てのOSやアプリケーションに対して有効というわけではありません。使用しているOS、アプリケーションによってその脆弱性は変わってきますから、当然攻撃手法も変わってきます。Signature Groupsに用意されているシグネチャは攻撃手法によって細かく区別されています。
攻撃者の多くは、ターゲットとするホストを決定するために事前調査というものを行います。これは、使用しているOSやアプリケーションからそのバージョンまで調べます。もし、脆弱性を持つ、OSやアプリケーションを利用しているのであれば、その脆弱性をつく攻撃手法を用います。
つまり、使用していないアプリケーションの攻撃手法を利用され、攻撃を受けることはワームなどを除いて考えにくいため、監視対象外とすることが出来るのです。
なかには、サーバ側の設定で、偽った情報を応答するように設定しているかもしれません。よって、その偽った情報に関する攻撃を受けることはあるかもしれません。しかしながら、実際に使用しているアプリケーションに対する攻撃手法とは異なるため、攻撃が成立することは考えにくいものです。この観点から考えてみても監視対象外とすることが出来るのです。
ポイント(2)
監視対象では、関係のないOSやアプリケーションについては監視対象外とする。
2.2.3 NSDB(Network Security Database)
Signature Groupsパネルではシグネチャ名が表示されています。しかしながら、それがどのような攻撃を意味しているのかは、攻撃手法を知らなければ判断するのは難しいでしょう。そこでCisco Secure IDSでは、各シグネチャの詳細な情報はNetwork Security Databaseとして用意されています。ここから各シグネチャに関する情報を集めることが出来ます。
目的のシグネチャに関する詳細を確認るにはIDをクリックします。すると、図4-23が表示されます。更にRelated Vulnerabilitiesをクリックすることでより詳細な情報(4-24)を確認することが可能です。
 |
| 図4-23. NSDB Exploit Signature |
 |
| 図4-24. NSDB Vulnerablity |
2.2.4 Severityの変更
IDSにおけるポリシー設計は単に監視対象とするのか、それとも監視対象外とするのかを判断するだけでなく、更に考えなければならないこともあります。
IDSを利用することでネットワーク上に不正と思われるパケットを検知したのであれば、それを管理者に対してなんらかの形で通知しなければ意味の無いものとなってしまいます。
検知したアラームの内容によって、その重要度は変わってきます。Signature Groupsに存在するシグネチャは、全て重要度の変更が可能です。Cisco Secure IDSでは標準で用意されているシグネチャの重要度は、項目によって既に設定がされています。しかしながら、これは全ての環境に合わせた形で設定されているものではありません。そこで、監視対象とするシグネチャについて重要度を変更します。
各シグネチャのチェックボックスの右隣にあるEdit Iconをクリックすると、各シグネチャに対する編集画面(図4-25)が表示されます。
 |
| 図4-25. Editing |
重要度を変更するためには、プルダウンメニューから選択します。Cisco Secure IDS
では以下の5つのレベルが用意されています。
●None
●Information
●Low
●Medium
●High
重要度を指定する場合、どのようなアラームをHighとし、またInformationとするのか、事前に方針をセキュリティポリシーに沿った形で決定するといいでしょう。アラームのないようによってその重要度というものは当然違ってくるものです。攻撃のための事前調査であるポートスキャンを受けた時と、直接DoS攻撃などを受けた時の対応は当然変わってきます。そのため、アラームの内容によって重要度を区別することは、運用面から考えても非情に大切なことなのです。
アラームに関する重要度を決定する考え方の例を以下に示します。表4-4の内容はあくまでも例ですので、きちんとセキュリティポリシーに沿った形で定義する必要があります。
| 表4-4. 重要度の決定方針参考例 |
|
監視対象となるシグネチャに関して、重要度の変更が完了したら、OKをクリックします。
更に、Signature Groupsに用意されているシグネチャの選択が完了したら、それを有効にするためにメインメニューの上部にあるApply Changesをクリックし、Sensorに反映させます。
2.3 TCP Connection Signatures
TCP Connection Signaturesでは、TCPのコネクションを監視することが可能です。デフォルトで用意されているシグネチャの他に、新たに作成して追加することも可能です。
本章での説明では、DMZセグメントに設置されていると想定しています。通常、DMZセグメントと他のセグメントとの境界には、ファイアウォールが設置されています。つまり、発生すると予想可能な通信を限定することが出来るのです。そこで、発生すると予想される通信については無視し、ファイアウォールでブロックされるように設定されている通信については監視するように設定するのです。万が一、アラームが通知されるようなことがあれば、ファイアウォールの適切に設定されていないことが考えられます。
このように設定することで、ファイアウォールに設定されているルールについても監査することが可能になるのです。
また、ファイアウォールのアクセス制限により通信が確立されることがないため、攻撃が成功する可能性はないとないと判断したサービスがあるかと思います。ファイアウォールを通過してしまい、攻撃を受けるようなことが発生しても、通信の発生自体が問題であると判断することが出来ます。
その結果、Signature Groupsでは監視対象外としているサービスに関する攻撃を受けたとしても、細かな手法まで特定することは難しいですが、この設定により対応する事は出来るのです。
 |
| 図4-26. TCP Connection Signatures |
1) Communication > Sensing Engine > TCP Connectionの順に選択します。図4-26はTCP Connection Signatuereに関する設定画面です。
2) 監視対象とするシグネチャのチェックボックスをチェックし、Enableボタンをクリックします。無効にする場合は、Disableボタンをクリックします。
3) 画面最上部のApply Changeをクリックします
TCP Connection Signaturesは、この設定だけでは、検知することが出来ません。Signature GroupsのTCP Header Signaturesに存在するTCP Conn Reqを有効にします。実際のアラームの内容としては、TCP Conn Reqを検知したことが報告されます。
また、TCP Connection Signaturesは、カスタマイズが可能です。重要度についても、環境に合わせて変更します。
更にTCP Connection Signaturesでは、新たにシグネチャを追加することが可能です。
 |
| 図4-27. TCP Connection Signatures Adding |
1) Addボタンをクリックします。図4-27は追加画面です。
2) IdフィールドにシグネチャのIDを指定します。
3) Servetiyフィールドに重要度を指定します。
4) Actionフィールドにアラームを検知した時に行う、アクションを指定します。
5) Commentフィールドにシグネチャに関するコメントを指定します。
6) 必要な項目の入力が完了後、OKボタンをクリックします。
Ｉdには、ポート番号を指定します。指定したポートに対するコネクション要求があるとアラームを通知します。これで、TCP Connection Signaturesで用意されていないポートに対するコネクション要求の検知も可能になります。
※UDPのコネクションについても、UDP Connection Signaturesから設定可能です。
2.4 Filtered Signatures
運用上、無視しても構わないアラームというものが存在します。つまり、誤報と考えられるアラームも存在するということです。誤報というものは通常、運用に入ってから悩まされるものであり、監視ポリシーのチューニング作業の中で減らしていくものです。しかしながら、運用に入る前から、予め誤報となる可能性があるものもあります。それらについては、このFiltered Signaturesを利用して事前に検知しないように対策を施しておくと良いでしょう。
シグネチャ、送信元IPアドレス、送信先IPアドレスを組み合わせることにより特定のイベントに関してフィルタをかけることが出来ます。運用管理で利用しているホストから、各サーバに対するアクセスについて無視するのであれば、Filtered Signaturesにて設定することで無視することが出来るようになります。
リモート管理で内部ネットワークからSSHを利用してメンテナンス作業を行っていたとします。このため、ファイアウォールのルールでは特定のホストからのSSHの接続を許可していたとします。
このような場合、インターネット上、全てのホストからの接続を許していいる訳ではありませんので、SSHのコネクションについては監視対象とすべきです。しかしながら、特定の許可されたホストからであれば不正なアクセスとはいえないので、監視対象外とすべきでしょう。
このように、信頼出来るのであるから無視するために設定するのがFiltered Signaturesなのです。具体的に設定してみましょう。
 |
| 図4-28. Filtered Signatures |
1) Cisco IDMのメインパネルからConfiguration > Sensing Engine > Filtered Signaturesの順で選択します。図4-28はフィルタに関する設定を行う画面です。
2) Include/Excludeを選択します。
3) Sigunatureフィールドにシグネチャを指定します。
4) Sub-Signatureフィールドにサブシグネチャを指定します。
5) Source IPフィールドに送信元のIPアドレスを指定します。
6) Destination IPフィールドに送信先IPアドレスを指定します。
7) 必要な設定項目の入力完了後、OKボタンをクリックします。
8) 設定を反映させるために、Apply Changesをクリックします。
第2節 導入後
第1項 ログ管理
1.1 ログ管理の概要
一般的に，ネットワーク型IDS（Network Intrusion Detection System）は，非常に多くのログ（log）を出力します。既に紹介しましたCisco Secure IDSに含まれる諸機能の多くは，ログを入力として受け取り，それを表示することで機能します。ネットワーク型IDSのこのような機能は，アプリケーションというカテゴリの中でも，非常に特徴的と言うことができるでしょう。通常のサービス提供を行うアプリケーションでは，セキュリティの観点からは好ましいことではありませんが，ログの出力について，積極的に抑止する方針に添って設定を行うことが可能であるためです。
また，ネットワーク型IDSは，シグネチャの検知基準に合致したパケットを，そのままログとして保存します。そして，シグネチャの検知基準に合致したパケットが，監視対象のネットワーク上に出現したという事実を，IDS実装に応じた固有の形式でログに保存します。
Cisco Secure IDSは，このようにしてロギングされた情報を参照するための機能と管理するための機能を多数実装しています。
このようなログは，その運用と管理要件に応じて適切に管理されている必要があります。このような課題に対して，Cisco Secure IDSでは，イベントについてログに保存するレベルとタイプを指定する機能や一定の間隔でログをFTPサーバへ転送する機能する機能を兼ね備えることで，ログの運用と管理について，ネットワーク型IDSの利用者をサポートします。
ここでは，ログ管理の概要として，ログ管理に含まれる詳細項目を挙げておきます。
●ログ管理の詳細項目
1) ログの参照
2) ログの保存
3) ログの解析
続く解説では，ログの参照，ログの保存，ログの解析のそれぞれについて，個別に解説します。
1.2 ログの参照
Cisco Secure IDSにおけるIDM（IDS Device Manager）では，ログを参照するための機能として，参照する時点で保存中のイベントログを参照する機能，および，Sensorに保存されている過去のイベントログを参照する機能などが実装されています。
また，Cisco Secure IDSにおいてリアルタイムでログを参照するためには，スタンドアロンで動作するIEV（IDS Event Viewer）アプリケーションを利用します。
●Cisco Secure IDSが実装しているログ参照機能
1) 参照する時点で，Sensorが保存中のログを参照する機能
Monitoring > Logs > Currentの順に選択します。
 |
| 図4-30. Currentログファイル |
2) Sensorに保存されている過去のログを参照する機能
Monitoring > Logs > Archivedの順に選択します。
 |
| 図4-31. Archivedログファイル |
3) IEVの起動
Programs > Cisco Systems > Cisco IDS Event Viewer > Cisco IDS Event Viewerの順で選択します。
1.3 ログの保存
これまでにそれを参照する方法について解説してきたログについて，残された運用上の課題は，その保存期間の設定と保存方法の確定，そして，ログの複製の管理です。一定期間ログを保存するためには，全てのログを保管するための記憶装置とその機構を必要とします。このような課題に対してCiscoは，SN5420ストレージルータに代表されるソリューションによってもまた，ネットワーク型IDSの利用者をサポートしています。
●ログの保存における課題
1) 保存期間の設定
2) 保存方法の確定
3) 複製の管理
ログの保存期間については，その組織毎にセキュリティポリシーが相違するということも考えられます。また，コンピュータシステムセキュリティに関する諸規定などに準拠して，そのセキュリティポリシーを決定することもできます。
保存方法については，多くの方法が考えられます。改ざんの脅威を回避するために，上書きができない記憶媒体（CD-RやPDFファイル形式）などに最終的に記録することも考えられます。また，ファイルサーバ（ログ収集サーバ）を準備して，そのハードディスク上に記録しておくことも考えられます。
どのような方法を選択する場合でも，その方法毎に想定される脅威を認識している必要があります。例えば，ここで挙げた記憶媒体を利用する場合には，盗難や紛失，あるいは，破壊などが脅威となるでしょう。また，ファイルサーバを用いる場合には，そのサーバに対して比較的高いセキュリティレベルを設定した上で，必要なセキュリティポリシーを実装する必要があります。
Cisco Secure IDSにおけるIDM（IDS Device Manager）では，ログの運用管理のために使用する機能として，ログに保存するトラフィックを指定する機能，イベントについてログに保存するレベルとタイプを指定する機能，一定の間隔でログをFTPサーバへ転送する機能などを実装しています。
●Cisco Secure IDSが実装しているログ管理機能
1) ログに保存するトラフィックを指定する機能
Configuration > Sensing Engine > Level Of Traffic Loggingの順に選択します。
2) イベントについてログに保存するレベルとタイプを指定する機能
Configuration > Logging > Event Loggingの順に選択します。
3) 一定の間隔でログをFTPサーバへ転送する機能
Configuration > Logging > Exporting Event Logsの順に選択します。
1.4 ログの解析
ログの解析は，ネットワーク型IDSの利用者にとって，非常に多くのリソースを必要とする業務です。一般にIDSによって出力されたログに対する解析は，IEVへの通知を行っているアラームとは別に，ログとしてのみ保存されている情報を参照します。ここで参照するログには，設定されている監視ポリシーに応じて，様々な情報が記録されています。
解析のために参照したログからは，監視対象のネットワークに対して攻撃者が行った調査行為の記録，つまり，ポートスキャン（Port Scan）やシステムやサービスに対するプルーブ（Probe）の事実が記録されているかもしれません。または，監視対象のネットワークに対する，実際には影響のなかった場合を含む，フラッド系の攻撃や，侵入の試み，あるいは，プログラムの異常動作を誘発するコードの送信に分類が可能な事象の記録が残されているかもしれません。
そして，監視対象のネットワークに対して，実際に成功してしまった攻撃や侵入の事実を記録していることもあります。このような場合には，攻撃，および，侵入による影響を回避するために，そのターゲットとなったシステムに対して，事後的な対応を行う必要があります。
ログの解析において重要であるのは，不正アクセスの事象として分類可能な事実がそこから読み取られないことを確認するのではなく，時には些細な，不正アクセスの事象に関連する記録を探し出そうとする態度です。そのような態度でログ解析に臨まない限り，ログ解析の実施は，つまらないルーティンワークとなってしまいます。
ログの解析において，その目的となることは，監視対象のネットワークにおけるセキュリティの観点からの具体的な脅威の認識と，セキュリティアーキテクチャにおける構成上の問題点を抽出することです。
●ログ解析の目的
1) 監視対象のネットワークにおけるセキュリティの観点からの具体的な脅威の認識
2) セキュリティアーキテクチャにおける構成上の問題点の抽出
脅威を認識するためにネットワーク型IDSを利用する場合には，個々のシグネチャを潜在的な脅威の一覧と考えることができます。そして，シグネチャに応じてロギングされた事実は，少なくとも，実際にその脅威が実現されようとした可能性を示しています。
ポリシーにおける各シグネチャの設定状況によっては，実際に監視対象のネットワークに接続されているネットワークデバイスにとって脅威とはならない事実についても記録されています。ログ解析の結果として，そのような判断が可能である場合には，既存のポリシーから該当するシグネチャによる検知を行わないようにすることについて検討することになるでしょう。
そうではなくて，監視対象のネットワークデバイスに影響しうるシグネチャによる検知が行われていた場合には，そのネットワークデバイスに対して，所定の対応を行う必要があります。この場合の詳細については，緊急対応についての解説で述べます。
また，このようなセキュリティの観点からの攻撃や侵入の脅威についての問題点を抽出する用途とは別に，セキュリティアーキテクチャの構成上の問題点を抽出することを目的としてログ解析を行うことができます。
セキュリティアーキテクチャにおける問題点を抽出するためのログの解析において，その判断の基準となるものとしては，最初にセキュリティポリシーが挙げられるでしょう。例えば，ファイアウォールで保護されている非武装地帯（DMZ：De-Militarized Zone）が監視対象であるとき，ファイアウォールで実装されているべきセキュリティポリシーによって遮断されているはずの通信が検知されている場合には，それはファイアウォールによる保護が機能していないことを示しています。このような事実に対しては，その原因の調査を行う必要があります。
また，監視対象のネットワークから，それ以外のネットワークに対して，想定していない通信が発生している場合についても同様です。非武装地帯を例とした場合，通常，非武装地帯は，最もセキュリティレベルの低いネットワークであり，そのネットワークから他のネットワークへの通信は，必要最低限に抑制されているはずです。そして，その非武装地帯への通信についても，必要最低限の通信だけが認可されているはずです。
このようなセキュリティポリシーを前提に，ネットワーク型IDSによって検知された結果のログを解析することで，ファイアウォールのアクセス制御についての構成変更を検討することができます。このようなセキュリティポリシーの実装に関する問題点の抽出は，ルータやスイッチなどのセキュリティポリシー（アクセス制御リスト）の実装が可能なネットワークデバイスについても同様に考えることができます。
1.5 まとめ
この項では，主にログの管理について解説してきました。ここで改めて，これまでに解説してきましたログ管理についてまとめておきます。
はじめに，Cisco Secure IDSにおいてログを参照する下記の3機能について触れました。
●Cisco Secure IDSが実装しているログ参照機能
1) 参照する時点で，Sensorが保存中のログを参照する機能
2) Sensorに保存されている過去のログを参照する機能
3) IEV（IDS Event Viewer）
次に，ログの保存について解説しました。そこでは，ログの保存に関する検討項目として，下記の3点を挙げました。また，ログの保存に関する機能として，下記の3機能に触れました。
●ログの保存における課題
1) 保存期間の設定
2) 保存方法の確定
3) 複製の管理
●Cisco Secure IDSが実装しているログ管理機能
1) ログに保存するトラフィックを指定する機能
2) イベントについてログを保存するレベルとタイプを指定する機能
3) 一定の間隔でログをFTPサーバへ転送する機能
最後に，ログの解析について解説しました。ログの解析が，下記の2点を主要な目的とする業務であり，また，その結果に対応する必要が発生する項目について，若干の検討も行いました。
●ログ解析の目的
1) 監視対象のネットワークにおけるセキュリティの観点からの具体的な脅威の認識
2) セキュリティアーキテクチャにおける構成上の問題点の抽出
第2項 ポリシーチューニング
2.1 ポリシーチューニングの概要
ポリシーチューニングは，IDSの運用では必然的な要件です。ポリシーチューニングは，適切にそれが実施されている監視ポリシーである場合には，監視対象のネットワークのセキュリティレベルを如実に示す指標を作成する結果になります。また，ポリシーチューニングは，IDSの利用者に対して，プロシージャレベルのセキュリティポリシーをネットワークデバイスに実装する契機を提供します。さらに，ポリシーチューニングを実施することで，監視対象のネットワークで集中的に監視するべきセキュリティリスクを限定することができます。このことは，セキュリティ監視だけがその職責ではない管理者に，セキュリティに関する事柄について意識すべき事柄を減少させ，同じように重要な他の業務へのリソースを提供します。
●ポリシーチューニングを行う必然性
1) 監視ポリシーをネットワークのセキュリティレベルの指標としての位置付けること
2) プロシージャレベルのセキュリティポリシーの実装
3) 監視対象ネットワークにおいて懸念すべきセキュリティリスクの削減
既に別の節で述べたように，ネットワーク型IDSの導入目的は，監視対象のネットワークで発生したセキュリティリスクと認識すべき事実の記録，および，最大限早急に，監視対象のネットワークで発生した攻撃や侵入を試みるアクティビティをネットワーク管理者に通知することです。
●ネットワーク型IDSの導入目的
1) セキュリティリスクと認識すべき事実の記録
2) 監視対象のネットワークで発生した攻撃や侵入を試みるアクティビティの検知
はじめに例として，Cisco Secure IDSに実装されている全てのシグネチャを監視対象のネットワークで検知するポリシーに対して，ポリシーチューニングを行う場合を検討してみましょう。
全てのシグネチャについて検知を試みるポリシーでは，非常に多くのアラームが，IEV宛てに発生することが容易に推察されます。このような状況下では，Cisco Secure IDSの利用者は，その非常に多くのアラームの中から，真に危険なアラームを選別すること自体が難しいでしょう。さらに，ログ解析を行うに際しても，非常に多くのデータがその対象となることで，対応する多くのリソースを充当することを解析担当者に強いることになります。
そして，このような状況下では，Cisco Secure IDSを導入する当初の目的を果たせない可能性が増すことが容易に予測されます。重要なアラームの選定やログからの抽出に多くの時間を要するということは，不正アクセス事象のシステム管理者による認知が遅れてしまうことを，そのまま示します。
そこで，事項で解説するポリシーチューニングという手続きが，運用上必要な要件となります。
2.2 ポリシーチューニングの運用手続き
ポリシーチューニングの概要については既に解説しました。その内容を踏まえて，ここではポリシーチューニングの運用手続きについて解説します。これから解説する内容は，ポリシーチューニングを実施する契機として理解することもできます。
ポリシーチューニングによって実施されるポリシーに対する変更は，監視対象のネットワークにおけるセキュリティリスクを低減する対策と平行して実施します。
また，ポリシーチューニングにおいて具体的に実施される項目は，ポリシーに含まれる過剰なシグネチャ（検知基準）の削減とシグネチャの検知精度の調整です。さらに，ネットワークに求められる動作要件が追加⁄削除された場合には，それをポリシーに反映するために，ポリシーチューニングを実施する必要が発生します。
●ポリシーチューニングにおける実施項目
1) 過剰なシグネチャの削減
2) シグネチャの検知精度の調整
3) ネットワーク環境の変化への対応
監視対象のネットワークには，各種のコンピューティング機器のネットワークインターフェースが接続されています。そこで，個々のシグネチャについて，そのシグネチャをポリシーから除外する（そのシグネチャによる検知を行わないことにする）ためには，そのシグネチャによって検知される脆弱性に対する対策が，それらのコンピューティング機器の全て対して実施されていなければなりません。さらに，このような対策は，監視対象を経由する通信を行うことが計画されているデバイスについても同様です。
このことを言い換えると，ネットワーク型IDSのポリシーからシグネチャを除外するためには，それらのネットワークデバイスの全てについて，これから除外しようとしているシグネチャによって検知される脆弱性の対策が実施されている事実が必要であることになります。
さらに，それらのネットワークデバイスに対して，実際的な対策を行う判断のためには，そのシグネチャによって検知できる攻撃が実現した場合のセキュリティリスクについて，事前に認識している必要もあるでしょう。
●ポリシーチューニングの要件（１）
1) 特定のシグネチャによって検知しうる脆弱性への対策の事実
また，このような個別の脆弱性への対策を実施するためには，その前提として，ネットワーク型IDSを導入するよりも以前に，監視対象のネットワークに接続されているデバイスとそのインタフェースの一覧が作成されている必要があります。さらに，それらの個々のデバイス上で提供されているアプリケーションサービスの一覧もポリシーチューニングに際して認識されていることが望ましいといえます。
なお，脆弱性とそれに対応する攻撃手法は，特定のオペレーティングシステムに固有の脆弱性である場合や，さらには，オペレーティングシステムの実装が稼動するハードウェアアーキテクチャに依存する場合があります。したがって，この一覧では，ホスト名に加えて，その実装が特定⁄併記されている必要があることになります。
さらに，特定のプロトコルに存在する脆弱性に加えて，プロトコルの特定の実装に脆弱性が発見される場合もあることから，サービスについても同様に，その実装が特定されている必要があります。
●ポリシーチューニングの要件（２）
2) 監視対象ネットワークに接続されているコンピューティング機器とその実装の一覧
●ポリシーチューニングの要件（３）
3) 監視対象ネットワークで提供されているネットワークサービスとその実装の一覧
また，監視対象のネットワークに接続されているコンピューティング機器は，ネットワークサービスのサーバ用途で運用⁄利用されているばかりとは限りません。サーバ用途のデバイスに加えて，クライアント端末が同時に接続されることが想定されるネットワーク環境では，それらのクライアントに対して利用が許可されているネットワークサービスの一覧も必要になります。
●ポリシーチューニングの要件（４）
4) 監視対象ネットワークでクライアントに利用が許可されているネットワークサービスの一覧
個別のシグネチャによっては，その検知精度を調整する必要がある場合があります。このような対応を行う必要があるシグネチャに該当するのは，例えば，Cisco Secure IDSでは，FLOOD.TCPSYNに分類されるHalf-open Synのようなシグネチャです。このシグネチャは，攻撃者による特定のポートに対するSynパケットの送信を検知します。導入直後の「あ」における「い」の値は「う」と設定されているため，ネットワークの利用状況によっては，検知結果が過剰になってしまう場合があります。したがって，Cisco Secure IDSの利用者が検知基準としてふさわしいと考える値に「い」を変更します。
さらにここでは，ポリシーチューニングによって，監視対象ネットワーク上に発生する攻撃パケットによるトラフィックが削減されるわけではないことに注意します。削減されるのは，SensorとIEV間のアラームの通信です。
●ポリシーチューニングの要件（５）
5) シグネチャの検知基準に応じた，検知精度の調整
最後に，監視対象のネットワークは，動作要件や利用者のニーズに応じてその様相を変化させる必要があります。これは，ネットワーク環境の要件の追加に応じることに加えて，要件の削除に対しても同様に考えることができます。したがって，Cisco Secure IDSの管理者は，このようなネットワーク環境の変化も，ポリシーチューニングを必然化する契機のひとつとして認識することになります。
●ポリシーチューニングの要件（６）
6) 新しいデバイスやサービスの監視対象のネットワークへの追加への対応
●ポリシーチューニングの要件（７）
7) 既存のデバイスやサービスの監視対象のネットワークからの削除への対応
最後に，シグネチャの追加について触れておきます。監視対象のネットワーク環境は常に，新たに発見される脆弱性によるセキュリティレベルの低下のリスクを負っています。このような環境要因の変化に対応するために，Cisco Secure IDSにおいては，新規に発見された脆弱性を検知するためのシグネチャの追加定義がサポートされています。Ciscoは，これらのシグネチャの更新情報を，「」でネットワーク型IDSの利用者に通知することで，新たに発見された脆弱性を利用した攻撃や侵入の試みを検知⁄記録して，利用者が早急に認識するためのソリューションをサポートします。さらに，Cisco Secure IDSでは，自動的に更新シグネチャを取得する機能を実装することで，その利用者をサポートします。自動的にCisco Secure IDSが取得したシグネチャについても，同様にポリシーチューニングを実施することになります。
●ポリシーチューニングの要件（８）
8) シグネチャの追加と更新
ここでは，ポリシーチューニングの要件と契機についてまとめておきます。
●ポリシーチューニングの要件
1) 特定のシグネチャによって検知しうる脆弱性への対策の事実
2) 監視対象ネットワークに接続されているコンピューティング機器とその実装の一覧
3) 監視対象ネットワークで提供されているネットワークサービスとその実装の一覧
4) 監視対象ネットワークでクライアントに利用が許可されているネットワークサービスの一覧
5) シグネチャの検知基準に応じた，検知精度の調整
6) 新しいデバイスやサービスの監視対象のネットワークへの追加への対応
7) 既存のデバイスやサービスの監視対象のネットワークからの削除への対応
8) シグネチャの追加と更新
2.3 Cisco Secure IDSにおけるポリシーチューニング
ここでは，Cisco Secure IDSのIDMにおける，ポリシーチューニングの実施についての解説を行います。
そこでまず，多数のシグネチャを概観するために，下記のようにシグネチャを分類します。
2.3.1 シグネチャの分類
1) Signature Groupsにグループ化されているシグネチャ
2) TCP Connection Groupsにグループ化されているシグネチャ
3) UDP Connection Groupsにグループ化されているシグネチャ
4) String Signature
5) Custom Signature
以降では，それぞれのシグネチャのチューニング方法について，解説します。その後で，シグネチャの自動更新機能について解説します。
2.3.2 シグネチャの編集(Signature Groups)
●Signature Groupsにグループ化されているシグネチャ
1) Configuration > Sensing Engine > Signature Groupsを選択します。
※ここでは，個々のシグネチャについて有効⁄無効にする方法を解説します。
2) 有効⁄無効にするシグネチャが含まれているSignature Groupを選択します。
3) 表示されたシグネチャの中から，有効⁄無効にするシグネチャのチェックボックスをクリックします。
4) 有効にする場合は画面下のEnableボタンを，無効にする場合は画面下のDisableボタンをクリックします。
5) 画面最上部のApply Changesクリックします。
2.3.3 シグネチャの編集(TCP Connection Groups)
●TCP Connection Groupsにグループ化されているシグネチャ
1) Configuration > Sensing Engine > TCP Connection Signaturesを選択します。
2) 表示されたシグネチャの中から，有効⁄無効にするシグネチャのチェックボックスをクリックします。
3) 有効にする場合は画面下のEnableボタンを，無効にする場合は画面下のDisableボタンをクリックします。
4) 画面最上部のApply Changesをクリックします。
※なお，画面下部のAddをクリックすることで，TCPの通信を検知するシグネチャを追加します。
2.3.4 シグネチャの編集(UDP Connection Groups)
●UDP Connection Groupsにグループ化されているシグネチャ
1) Configuration > Sensing Engine > UDP Connection Signaturesを選択します。
2) 表示されたシグネチャの中から，有効⁄無効にするシグネチャのチェックボックスをクリックします。
3) 有効にする場合は画面下のEnableボタンを，無効にする場合は画面下のDisableボタンをクリックします。
4) 画面最上部のApply Changesをクリックします。
※なお，画面下部のAddをクリックすることで，UDPの通信を検知するシグネチャを追加します。
2.3.5 シグネチャの編集(String Signature)
●String Signature
1) Configuration > Sensing Engine > String Signaturesを選択します。
2) 表示されたシグネチャの中から，有効⁄無効にするシグネチャのチェックボックスをクリックします。
3) 有効にする場合は画面下のEnableボタンを，無効にする場合は画面Disableボタンをクリックします。
4) 画面最上部のApply Changesをクリックします。
※なお，画面下部の「add」をクリックすることで，正規表現の文字列によって検知を行うシグネチャを追加します。
2.3.6 シグネチャの編集(Custom Signature)
●Custom Signature
1) Configuration > Sensing Engine > Custom Signaturesを選択します。
2) 表示されたシグネチャの中から，編集を行うシグネチャの編集アイコンをクリックします。
3) 表示された画面上で，各シグネチャパラメタの編集を行います。
4) 編集を終えたら，画面下部のOKをクリックします。
5) 画面最上部の「Apply Changes」をクリックします。
※なお，画面下部の「add」をクリックすることで，クリックする時に表示されている「Signature Engine」から，ユーザ独自のシグネチャを追加します。
ここでは，Cisco Secure IDSに実装されている，Ciscoから提供される新規のシグネチャとサービスパックアップデートを更新する機能について解説します。
2.3.7 シグネチャの自動更新機能
1) Administration > Updateを選択します。
2) 各項目を設定します。
3) 設定を終了したら，OKをクリックします。
※任意に更新を行いたい場合には，「Update Now」をクリックします。
以下のURLは、Cisco Secure IDSのsignature updateに役立つメール配信サービスです。ここの登録より、siggnatureの更新情報や、緊急時のカスタムシグネチャの作成方法に関する情報を入手できます。
http://www.cisco.com/warp/public/779/largeent/it/ids_news/subscribe.shtml
2.4 ポリシーチューニングのゴール
ポリシーチューニングのゴールは，必要最低限のアラートを「管理コンソール」に出力する監視ポリシーとすることです。ポリシーチューニングの手続きについては，別の節で解説しましたけれども，監視対象のネットワークに実施されている実際的な対策に反比例して，ポリシーに含めるべき監視を行うべきシグネチャの量は減っていきます。
また，ポリシーチューニングは，実際にIEVを参照するネットワーク型IDSの利用者，および，管理者が，大量の通知によって惑わされてしまうことや，重要な検知の事実を見落としてしまう脅威からの回避策にもなります。
●ポリシーチューニングのゴール
1) 管理コンソールに通知されるアラートの量が少ないこと
2) 大量の通知によって惑わされないこと
3) 重要な検知の事実を見落とさないこと
2.5 まとめ
ここでは改めて，この節で解説したポリシーチューニングに関する事柄について，まとめておきます。
はじめに，ポリシーチューニングの概要について解説しました。そこでは，ネットワーク型IDSを運用する場合に，ポリシーチューニングを行うことの必然性について，下記のようにまとめました。
●ポリシーチューニングを行う必然性
1) 監視ポリシーをネットワークのセキュリティレベルの指標としての位置付けること
2) プロシージャレベルのセキュリティポリシーの実装
3) 監視対象ネットワークにおいて懸念すべきセキュリティリスクの削減
次に，ポリシーチューニングにおける運用手続きについて解説しました。ここで重要な事項として，監視対象のネットワークに接続されているネットワークデバイスにおけるセキュリティリスクへの対策の実施と並行して，それが実施されることを指摘しました。また，ポリシーチューニングの要件として，下記の8点を挙げました。
●ポリシーチューニングの要件
1) 特定のシグネチャによって検知しうる脆弱性への対策の事実
2) 監視対象ネットワークに接続されているコンピューティング機器とその実装の一覧
3) 監視対象ネットワークで提供されているネットワークサービスとその実装の一覧
4) 監視対象ネットワークでクライアントに利用が許可されているネットワークサービスの一覧
5) シグネチャの検知基準に応じた，検知精度の調整
6) 新しいデバイスやサービスの監視対象のネットワークへの追加への対応
7) 既存のデバイスやサービスの監視対象のネットワークからの削除への対応
8) シグネチャの追加と更新
そして，Cisco Secure IDSにおけるポリシーチューニングの操作方法について解説しました。ここで紹介したチューニング対象のシグネチャは，下記の一覧です。
●シグネチャの分類
1) Signature Groupsにグループ化されているシグネチャ
2) TCP Connection Groupsにグループ化されているシグネチャ
3) UDP Connection Groupsにグループ化されているシグネチャ
4) String Signature
5) Custom Signature
最後に，ポリシーチューニングのゴールについて解説しました。ポリシーチューニングのゴールは，下記の3点がその内容になります。
●ポリシーチューニングのゴール
1) 管理コンソールに通知されるアラートの量が少ないこと
2) 大量の通知によって惑わされないこと
3) 重要な検知の事実を見落とさないこと
第3項 攻撃検知後の対応
3.1 Cisco Secure IDSによって検知される事象
シグネチャは，Cisco Secure IDSにおけるIDM（IDS Device Manager）画面上では，TOC（Table Of Contents）の項目として確認することができます。
また，TOC（Table Of Contents）の項目からは，シグネチャを下記のように分類することができます。
●シグネチャの分類
1) Signature Groupsメニューに登録されている，サービスアプリケーション固有のシグネチャ
2) TCP Connection Signatureメニューに登録されている，TCPサービスへの接続要求
3) UDP Connection Signatureメニューに登録されている，UDPサービスへの接続要求
4) 文字列定義によるユーザ定義のシグネチャ
5) パラメタ変更によるユーザ定義のシグネチャ
Signature Groupsに分類されているシグネチャは，アプリケーション固有の脆弱性を利用した攻撃，あるいは，侵入の試みを検出するためのシグネチャです。また，ユーザによって定義されたシグネチャは，Signature Groupsの中のCustomer Signatureに登録されます。
TCP Connection Signatureに分類されているシグネチャは，TCPを利用したアプリケーションに対する，接続要求を検知するシグネチャです。検知される事象としては，攻撃者による量的に過剰なサービス要求である場合やプルーブ（Probe）の試みである場合が想定されます。
UDP Connection Signatureに分類されているシグネチャは，UDPを利用したアプリケーションに対する接続要求を検知するシグネチャです。検知される事象として想定されるものは，TCP Connection Signatureに分類されているものと同様です。
文字列定義によるユーザ定義のシグネチャは，送信されたパケットに含まれているアプリケーションレベルの処理の対象となる文字列を，Cisco Secure IDSの利用者によって独自に作成されたシグネチャによって事象を検知します。
最後に，パラメタ変更によるユーザ定義のシグネチャは，特定の各種のパラメタが指定可能なSignature Engineに分類されているシグネチャを，Cisco Secure IDSの利用者が独自に編集することで作成されたシグネチャによって事象を検知します。
3.2 適切な判断のために
これまでの解説によれば，Cisco Secure IDSは，監視対象ネットワーク上で検知するよう設定されているシグネチャに応じて，様々な事象を検知します。これらの事象の中から，真に危険度の高いアラートを抽出して危険性についての判断を行うためには，監視対象のネットワークに関する恒常的であり，かつ，十分な事前の認識と，攻撃手法に関する理解，そして，シグネチャの検知精度に関する認識を前提とした，総合的な検討が必要になります。
●事象の理解に必要な前提知識
1) 監視対象のネットワークに関する十分な認識
2) 攻撃手法に関する理解
3) シグネチャの検知精度に関する認識
攻撃手法に関する理解については，ネットワーク型IDSが管理者に課せられる理解を代替してくれていると考えることもできます。しかしながら，ネットワーク型IDSによる検知に対する判断と，その判断に応じた対処のための運用手続きを想定した場合には，それでは不十分であるといわざるをえません。
確かにネットワーク型IDSは，特定の攻撃手法の特徴を検知した後，それをデータベースに保存すること，および，アラートとして「管理コンソール」に通知するよう機能します。しかし，そのアラート（あるいは，ログ）を参照して，事象に対する判断を行うのは，監視対象ネットワークの管理者であり，ネットワーク型IDSではありません。
3.3 緊急対応
緊急対応の必要性は，IEVへのアラームの通知をその契機とします。ログ解析をその契機とする場合と比較すると，緊急性という観点からは，それは「緊急対応」ではなく，「事後的な対応」という位置付けになります。
緊急対応を行う必然性があるのは，セキュリティリスクが実現した場合，そして，監視アーキテクチャに障害が発生した場合です。
●緊急対応を行う場合
1) セキュリティリスクが実現した場合
2) 監視アーキテクチャに障害が発生した場合
セキュリティリスクが実現した場合とは，最適化を指向したチューニングがなされた監視ポリシーの場合には，IEVにアラームが出力された瞬間，と認識することになります。適切にチューニングされた監視ポリシーによって出力されるアラームは，実質的な対策が行われていないセキュリティリスクであり，また，そうであるからこそ検知するように設定されているシグネチャによるアラームであるからです。
諸事情あって，最適化が実現されていない監視ポリシーの場合には，アラームの出力に応じて緊急対応の実施について決断するために，アラームの内容に関する検討が必要になります。このときに検討されるのは，シグネチャによって報告された攻撃手法，シグネチャの検知精度，実際に送受信されたデータとなります。そして，その検討の結果として，緊急対応を行うことになります。
セキュリティリスクが発生した場合に実施される緊急対応は，所定の手続きによることが重要です。つまり，事前に想定されるセキュリティリスクと，実際に緊急対応として行うオペレーションについては，運用手続きとして，関係者間で合意されている必要があります。
ここで，緊急対応として行われる運用手続きにおけるオペレーションとしては，まず通報が挙げられます。通報は，発生して，検知された事象に対する判断に基づいて実施されるシステム管理者による手続きであり，IEVへの通知それ自体ではありません。
その通報に応じて実施される手続きは，攻撃のターゲットとなったネットワークデバイスに対する専門家，あるいは，担当者による調査である場合や，ケーブルの切断である場合もあります。後者の事例としては，監視対象のネットワークデバイスが，対策を実施していないセキュリティホールを利用して伝染する機能をもったウィルスが感染してしまった場合があります。これは，管理外のネットワークデバイスへの更なる感染を防ぐために必要な対応です。
さらに，攻撃や侵入の被害にあったデバイスやその事実を記録しているログを保全することが重要です。保全については，法律的な手続きのそれと同じように実施する必要があることに注意します。被害にあったデバイスは，保全されることで被害の証拠を残し，また，必要な対策を検討する場合の資料として利用することができることになります。
他方，監視アーキテクチャに障害が発生した場合とは，ネットワーク型IDSに何らかの障害が発生して監視の継続が不可能になった場合や，IEVに障害が発生してアラームの通知を受けられなくなった場合などがあります。
これらの潜在的な障害の可能性に対しては，Cisco Secure IDS自体の複製（冗長化）やIEVの複製（冗長化），つまり，監視アーキテクチャを構成する各デバイスのバックアッププランによって事前に対策をとっておくべきです。
さらにまた，Cisco Secure IDSの冗長化については，同様の障害が冗長化されないように，ハードウェアの相違までを踏まえて，ネットワーク型IDSとして相違する実装を併用することも検討項目となります。あるいは，特定のネットワーク型IDSの構成部品に障害が発生したような場合については，所定の復旧までの期間については監視をあきらめる，のようなセキュリティポリシーを規定しておくことも重要です。
3.4 まとめ
ここで，これまでに解説してきた攻撃検知後の対応についてまとめておきます。
はじめに，Cisco Secure IDSによって検知される事象について，解説しました。ここでは様々な事象を，TOCで参照が可能な下記5点のように分類しました。
●シグネチャの分類
1) Signature Groupsメニューに登録されている，サービス固有のシグネチャ
2) TCP Connection Signatureメニューに登録されている，TCPサービスへの接続要求
3) UDP Connection Signatureメニューに登録されている，UDPサービスへの接続要求
4) 文字列定義によるユーザ定義のシグネチャ
5) パラメタ変更によるユーザ定義のシグネチャ
次に，検知する事象に関する一般的な解説を踏まえて，ネットワーク型IDSの利用者が，検知された事実の報告に対して適切な判断を行うための前提を提示しました。そこでは，適切な理解に基づく判断を行うために必要な認識として，下記の3点を挙げました。
●事象の理解に必要な前提知識
1) 監視対象のネットワークに関する十分な認識
2) 攻撃手法に関する理解
3) シグネチャの検知精度に関する認識
最後に，緊急対応の必要性について解説しました。緊急対応を行う必要があるのは，下記の2点の場合です。
●緊急対応を行う場合
1) セキュリティリスクが実現した場合
2) 監視アーキテクチャに障害が発生した場合
