Cisco Security MARS Local Controller および Global Controller ユーザ ガイド リリース 6.x
Security Threat Mitigation(STM)タスク フロー概要
Security Threat Mitigation(STM)タスク フロー概要
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 12MB) | フィードバック

目次

Security Threat Mitigation(STM)タスク フロー概要

ポリシー目標

セキュリティ ポリシー目標

モニタリング ポリシー目標

軽減ポリシー目標

復旧ポリシー目標

シスコ セキュリティ ホイール

プロビジョニング フェーズのチェックリスト

モニタリング フェーズのチェックリスト

モニタリング、通知、軽減、復旧、および監査に関する方針

アプライアンス側の調整に関する注意事項

デバイス インベントリ ワークシート

ユーザ ロール ワークシート

Security Threat Mitigation(STM)タスク フロー概要

Cisco Security Monitoring, Analysis, and Response System(MARS)使用に関する理論的な手法には、意識している目標およびそれを実現するためのポリシーをしっかりと把握することが必要です。この章は、まずセキュリティ、モニタリング、軽減および復旧に関する基本的な「ポリシー目標」のリストを示します。さらに 1 つに統合された手法の一部として、それぞれがどのように見なされるかを説明します。このような明快なポリシーは総合的な基盤として機能し、また、特定の手法の適用を可能にします。

この章では、MARS を Security Threat Mitigation(STM; セキュリティ脅威軽減)システムとしてネットワークに配置する場合に従う必要がある 2 つのプロジェクト フェーズおよびタスク フローについて説明します。これらの機能は、次のとおりです。

プロビジョニング(「プロビジョニング フェーズのチェックリスト」を参照)。

モニタリング(を参照)。

最後に、この章は「アプライアンス側の調整に関する注意事項」の説明で終わり、ユーザが使用できる次の 2 つのワークシートを示しています。

「デバイス インベントリ ワークシート」

「ユーザ ロール ワークシート」

ポリシー目標

ここでは、次の内容について説明します。

「セキュリティ ポリシー目標」

「モニタリング ポリシー目標」

「軽減ポリシー目標」

「復旧ポリシー目標」

「シスコ セキュリティ ホイール」

セキュリティ ポリシー目標

セキュリティ ポリシーでは、次の事項を決定する必要があります。

ユーザが属する組織のセキュリティ目標

保護するリソース

最新のマップおよびインベントリを含むネットワーク インフラストラクチャ

より多くの保護を必要とする重要なリソース(研究開発、財務、人事など)

モニタリング ポリシー目標

モニタリング ポリシーでは、次の事項を決定する必要があります。

ユーザ、送信元、宛先、サービス、稼動時間を含む、ネットワーク上の管理トラフィック フローの予測量

ユーザ、送信元、宛先、サービス、稼動時間を含む、セキュリティ プローブおよび脆弱性テストのためのネットワーク トラフィックの予測量

「ネットワーク プロキシミティ」から重要なリソースに監査データを配信できるネットワーク インフラストラクチャ

ネットワーク インフラストラクチャ内のデバイスおよびホストで使用可能なさまざまなイベント ロギング レベル

調査に使用するデバイスおよび技術

軽減ポリシー目標

軽減ポリシーでは、次の事項を決定する必要があります。

重要なリソースに対するネットワーク上のチョーク ポイント

レイヤ 2 およびレイヤ 3 デバイスで軽減された攻撃を記述するためのプロセスの定義

ホストおよびアプリケーション レイヤで軽減された攻撃を記述するためのプロセスの定義

ネットワーク運用、セキュリティ運用、ホスト所有者、および共有ホストのアプリケーション所有者など、企業の所有権に関する問題の解決

セキュリティ対策チームおよび復旧チームに通知するためのポリシー

IOS Intrusion Prevention System(IPS; 侵入防御システム)Dynamic Attack Mitigation(DAM; 動的な攻撃軽減)など、ベンダー検出ツールのプライオリティ付けのプロセス

検出された攻撃のブロック方法(一時的あるいは永久的にブロックするのか、MARS で生成された規則を使用するのか、セキュリティ運用チームが定義したカスタム規則を使用するのか、など)

復旧ポリシー目標

復旧ポリシーでは、次の事項を決定する必要があります。

ネットワーク内のノード タイプごとの、検出されたにもかかわらず軽減されていない攻撃への対応方法

ホストおよびアプリケーションを適切に復旧するためのツール ベンダー更新ポリシー

復旧オプションを使用できない、感染したレガシー ホストを隔離するためのポリシーおよび手順。これらの手順には、バックアップからの復元またはネットワークの隔離が含まれることがあります。

シスコ セキュリティ ホイール

ポリシーおよびポリシーで構成されるオブジェクトはシスコ セキュリティ ホイールのハブになります(図 2-1)。

図 2-1 シスコ セキュリティ ホイール

 

ネットワーク セキュリティを表すシスコ セキュリティ ホイールのスポークは、次の 4 つのステップで構成される連続したプロセスです。

1. システムを保護します。

2. ネットワーク内でセキュリティ ポリシーに対する違反や攻撃をモニタし、対応します。

3. セキュリティ セーフガードの有効性をテストします。

4. 企業セキュリティを管理し、改善します。

4 つのすべてのステップは連続して行う必要があります。企業のセキュリティ ポリシーを作成および更新する場合は、各ステップを考慮する必要があります。

プロビジョニング フェーズのチェックリスト

プロビジョニングでは、ハードウェア、ソフトウェア、およびネットワークの計画、セットアップ、および設定を行います。これにより、MARS アプライアンスのデータおよびネットワーク リソースに実際にアクセスできるようになります。このフェーズは、インストールが正常に完了した後に実行します。インストール手順については、『 Cisco Security MARS Initial Configuration and Upgrade Guide 』を参照してください。

次のチェックリストに、意思決定プロセスを理解するために必要なタスク、および MARS を最も効率的な方法でプロビジョニングするのに必要な基本フローを示します。各ステップには複数のサブステップが含まれることがあります。これらのステップとサブステップは順番どおりに実行する必要があります。チェックリストには、各タスクを実行するための具体的手順の参照先も示されています。


ステップ 1 インベントリおよびレビュー可能なレポート デバイス、軽減デバイス、およびサポート デバイス

レポート デバイス :ユーザとネットワークのアクティビティ、およびデバイスのステータスと設定に関するログを提供します。

軽減デバイス :検出された攻撃に対処する際に使用することができます。また、レポート デバイスとしても機能します。

サポート デバイス :レポート デバイス、軽減デバイス、または MARS アプライアンスにネットワーク サービスを提供します。

ネットワーク上のどのデバイスをモニタするかについては、複数の要因が関係します。たとえば、デバイスの配置、同じネットワーク セグメント上のその他のデバイスと比較した場合のレポート機能、および MARS アプライアンスで実現する必要のある動作レベルなどです。

どのデバイスをレポート デバイスおよび軽減デバイスにするかを検討する場合は、これらのデバイスから MARS に提供されるデータを把握する必要があります。有効なすべてのデバイスを追加しただけでは、最適なモニタリングおよび軽減方針とはいえません。慎重に検討してデバイスを選択することにより、MARS のワークロードを削減して、検出時間および軽減時間を短縮し、フォールス ポジティブ検出を改善することができます。

MARS が処理するのはモニタ対象デバイスだけであるため、モニタするデバイスは慎重に決定する必要があります。次に、デバイスを決定する場合の考慮事項の例を数個だけ示します。

特定のネットワーク セグメントのレポート デバイスで使用可能なログおよびデータ タイプを考慮して、ネットワークのアクティビティの全体像が最もよくわかるログを選択します。

ネットワーク内の各セグメントの本来のチョークポイントにある軽減デバイスを特定します。これらの軽減デバイスを MARS の処理対象にすると、攻撃を止める可能性が高まります。MARS は攻撃を識別すると、ネットワーク トポロジを調べて、最適なチョークポイントを特定します。ただし、MARS が調査するのは、モニタ対象デバイスだけです。

サポート デバイスは STM システムの運用に重要な役割を果たすことがあります。したがって、ネットワーク上のサポート デバイスのインベントリを作成し、検討する必要があります。対象となるデバイスは、電子メール サーバ、Authentication, Authorization, and Accounting(AAA; 認証、許可、アカウンティング)サーバ、Domain Name System(DNS; ドメイン ネーム システム)サーバ、Syslog サーバなど、想定される STM システムで特定の役割を果たすデバイスです。

手順完了時の結果:モニタするデバイス リストが完成します。各デバイスの詳細には、デバイス名、レポート IP アドレス、管理 IP アドレス、管理プロトコル、管理アカウント情報、およびイネーブルにするロギング機能、レベル、プロトコルが含まれます。

詳細については、次の項を参照してください。

1. 「モニタ対象デバイスの選択」

2. 「動作レベル」

3. Cisco Security MARS Initial Configuration and Upgrade Guide 6.X 』の「Deployment Planning Guidelines」

4. 「デバイス インベントリ ワークシート」

ステップ 2 必要なすべてのトラフィック フローを特定し、イネーブルにします。

対象デバイスを決定したら、管理、報告、および通知に使用するネットワーク サービスが、目的のトラフィック フローに対して許可されていることを確認する必要があります。ステップ 1 で作成した詳細な 「デバイス インベントリ ワークシート」 を参照して、MARS アプライアンスと各サポート デバイス、レポート デバイス、軽減デバイスとの間の管理、ロギング、および通知トラフィックが中間ゲートウェイで許可されていることを確認します。

さらに、DNS、電子メール、AAA、および Network Time Protocol(NTP; ネットワーク タイム プロトコル)サーバなどのサポート デバイスのネットワーク サービスが、ネットワーク上の MARS アプライアンス、サポート デバイス、レポート デバイス、および軽減デバイスを通過できるように許可する必要があります。

MARS は受信イベントだけにデバイス タイムを適用します。報告された時刻が MARS アプライアンスの時刻から 3600 秒以内の範囲である限り、Intrusion Detection System(IDS;侵入検知システム)/Intrusion Prevention System(IPS; 侵入防御システム)デバイスなどのデバイスや Windows からプルされたすべてのイベントに対して、MARS は報告された時刻を使用します。


ヒント MARS アプライアンスを含むすべてのデバイスは、同じ時刻に同期させることを推奨します。MARS アプライアンスは Hypertext Transfer Protocol Security(HTTPS)サーバであるため、ここで使用される証明書では、時刻、日付、および時間帯が適切に設定されている必要があります。これらが適切に設定されていないと、セッションおよびインシデントのタイム スタンプが不正確になり、Web インターフェイスにアクセスする際に「タイムアウト」エラーが発生することがあります。


トラブルシューティングしなければならない事態を制限するには、送信元ネットワーク セグメントから宛先セグメントへの各トラフィック フローをテストする必要があります。できれば、プロトコルごとに、デバイス間のすべてのフローをテストして、さまざまなゲートウェイ Acess Control List(ACL; アクセス制御リスト)の「最適な一致」と「最初の一致」のセマンティックによって、目的のトラフィック フローが妨げられないことを確認します。ネットワーク上のすべてのセキュリティ デバイスの場合と同じように、イネーブル化されたトラフィック フローの対象を、目的のプロトコル、ポート、および送信元/宛先ペアに限定する必要があります。

手順完了時の結果:すべての中間ゲートウェイで、デバイスと MARS アプライアンス間のログ、管理、および通知トラフィックが許可されていることが確認されます。

詳細については、次の項を参照してください。

1. Top Issues for the Cisco Security Monitoring, Analysis, and Response System 』の「 Event Timestamps and Processing

2. Cisco Security MARS Initial Configuration and Upgrade Guide 6.X 』の「Deployment Planning Guidelines」

3. Cisco Security MARS Initial Configuration and Upgrade Guide 6.X 』の「Supporting Devices」

4. Cisco Security MARS Initial Configuration and Upgrade Guide 6.X 』の「Required Traffic Flows」

5. Cisco Security MARS Initial Configuration and Upgrade Guide, 6.X 』の「Specify the Time Settings」

6. 「デバイス インベントリ ワークシート」

ステップ 3 レポート デバイス、軽減デバイス、およびサポート デバイスをブートストラップします。

「デバイス インベントリ ワークシート」デバイス インベントリ ワークシート で決定したデバイスごとにブートストラップを行って、MARS との間に必要な通信が発生するように設定します。デバイスのブートストラップでは、STM システム内の役割によって決定する値を、デバイスの設定値にします。デバイス タイプおよび役割に応じて、次のブートストラップ タスクを実行します。

MARS アプライアンスが軽減およびアクセスのために実行するデバイス管理をイネーブルにする。

MARS アプライアンスのために正しいログを収集するエージェントをインストールする。

正しいロギング レベルおよびロギング サービスをイネーブルにする。

MARS アプライアンスにログを転送するか、これらのログを必要に応じて受信またはプルするアプライアンスを決定する。

デバイス設定の検出をイネーブルにする。

デバイスが MARS アプライアンスから通知を受信できるように設定する。

STM システムで想定された役割を割り当てるための設定は、デバイスごとに異なります。デバイスについて検討する場合は、STM システム内で想定される役割と、上記タスクの設定を直接、相関付けます。さらに、MARS によって課せられる制限を把握します。たとえば、特定のデバイス タイプを検出する場合、サポート対象プロトコルに制限があることがあります。

手順完了時の結果:レポート デバイスおよび軽減デバイスで、正しいロギング レベルがイネーブルになります。MARS アプライアンスはこれらのデバイスから必要なすべてのログを受信またはプルすることができます。また、設定値を取得したり、サポート対象の軽減デバイスに ACLS をプッシュすることができます。検出済み攻撃の通知が必要なデバイスは、MARS アプライアンスからこのような通知を受信するように設定できます。MARS アプライアンスは、受信したイベントを取得して格納しますが、これらを検査するには、レポート デバイスおよび軽減デバイスを Web インターフェイスで定義して、アクティブにする必要があります。


ヒント Web インターフェイスにデバイスを追加してアクティブにする前に、デバイスから MARS にパブリッシュされたイベントを問い合せるには、デバイスの報告 IP アドレスを一致基準として使用します。この方法は、デバイスが適切にブートストラップされていることを確認する場合に便利です。


詳細については、次の項を参照してください。

1. 「デバイス インベントリ ワークシート」

2. 「Supported Reporting and Mitigation Devices」

3. Device Configuration Guide for Cisco Security MARS, Release 6.x 』の「 Configuring Reporting and Mitigation Devices in MARS 」章の「Bootstrap Summary Table」

4. レポート デバイスおよび軽減デバイスのログ設定に関するユーザ ガイドの項

ステップ 4 MARS にデバイスを定義します。

レポート デバイスおよび軽減デバイスを決定したうえでブートストラップして、必要なトラフィック フローをイネーブルにしたら、これらのデバイスを MARS に定義する必要があります。MARS は、この情報を使用してデバイスと通信します。定義するためには、Web インターフェイスに各デバイスを追加するか、comma separated value(CSV; カンマ区切り値)ファイルをインポートします。CSV ファイルは、基本的なデバイス タイプに必要な設定を定義し、より複雑なデバイスを定義するための起点となります。また、トポロジ検出を使用して、レポート デバイスおよび軽減デバイスを自動的に検出してから、前の手順に戻って、詳細を追加指定することができます。

ほとんどのデバイス タイプに対し、デバイス検出に使用するアクセス プロトコルを決定する必要があります。選択したプロトコルによって、検出できるデータ タイプ、および軽減の実行の可否が決まります。これらのオプションを理解すると、企業のポリシーに適合する一貫した方法を見つけることができます。

デバイスの追加方法は、ネットワーク上のデバイス数と、追加するデバイスの CSV デバイス キーワードの有無によって異なります。また、エージェント、モジュール、またはセンサを使用するデバイス タイプを定義する場合は、ベースとなるホストまたはデバイスを定義してから、モジュール、センサー、およびエージェントをベース デバイスに追加するなど、複数のステップが必要です。たとえば、Cisco ASA デバイスに IPS モジュールを追加する場合は、Cisco ASA デバイスを定義してから、このデバイスのコンポーネントとして IPS モジュールを定義する必要があります。また、専用アプライアンスでない多くのアプリケーションでは、アプリケーションが稼動するホスト(汎用、Windows、UNIX、または Linux)を定義してから、アプリケーションとホストを関連付ける必要があります。

デバイスを追加したら、Web インターフェイスの各ページにある [Activate] ボタンをクリックして、追加したデバイスをアクティブにする必要があります。

MARS 内に誤って追加された、または、アクティブでないデバイスをすべて表示するには、次の 2 つのクエリーのいずれかを定義します。

[Devices] フィールドで「Unknown Reporting Device」を選択します。このクエリーは、MARS で定義されたレポート IP に一致しないイベントをレポートするデバイスのイベントだけを返します。MARS がイベントを受信したとき、まず、受信したイベントの IP が [Reporting and Monitor Devices] ページで特定されたレポート IP に一致するかどうかを判定します。MARS は一致を検出したときだけ、イベントの解析を試みます。したがって、レポート デバイスのレポート IP が誤って定義されている場合は、そのデバイスからのイベントは解析されません。実質的に、このクエリーは解析されないイベントを特定します。

[Events] フィールドで「Unknown Device Event Type」を選択します。このクエリーは、なんらかの理由で(たとえば、MARS シグニチャリストがデバイス イベント リストに追随していないなど)、MARS に解析されない既知のデバイスからのイベントを返し、さらに、未知のデバイスからレポートされたイベントを返します。

これらのクエリーは、デバイスの追加後、特に CSV シードファイルや Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)検出を使用した場合に、推奨される優れた方法です。どちらのクエリーでも、特定のレポート IP アドレスを探している場合は、[Keyword] フィールドにアドレスを入力して、その IP アドレスを含むものに結果にフィルタします。

手順完了時の結果:すべてのレポート デバイスおよび軽減デバイスが、MARS 内に定義され、アクティブになります。デバイスが MARS 内でブートストラップおよび定義されると、MARS はデバイスから受信したログの検査を開始します。MARS はデバイスが追加されるまで、受信したイベントの取得および格納だけを行い、検査は実行しません。

詳細については、次の項を参照してください。

1. 「デバイス インベントリ ワークシート」

2. 「アクセス タイプの選択」

3. Device Configuration Guide for Cisco Security MARS, Release 6.x 』の「 Configuring Reporting and Mitigation Devices in MARS

4. 「Supported Reporting and Mitigation Devices」 (CSV Keyword カラム)

5. 「レポート デバイスおよび軽減デバイスとの接続の確認」

6. 「レポート デバイスおよび軽減デバイスのアクティブ化」

ステップ 5 MARS のグローバル データ収集の設定値およびスケジュールを設定します。

デバイスを追加したら、次に示す MARS の豊富なデータ収集機能をイネーブルにできます。

動的な脆弱性スキャニング。 MARS は攻撃を検出したときに、ネットワークをプローブして、攻撃の成功の可能性および重大度を判定することができます。検出された攻撃に応じてデータ収集を実行するには、この機能をイネーブルにして、分析するネットワークを指定する必要があります。

NetFlow データ収集。 NetFlow データを使用すると、MARS はネットワーク内の一般的なデータ フローをプロファイリングして異常を識別し、ワームの急増を含む Day Zero 攻撃を検出することができます。MARS アプライアンスが統計的プロファイリングを完了するには、4 日間 ~ 2 週間かかります。プロファイルが作成されると、MARS は異常なトラフィック フローの検出を開始し、これらのフローに応じたインシデントを作成します。NetFlow データ収集を設定するには、NetFlow トラフィックを生成できるデバイスを設定し、共有コミュニティ ストリングを待ち受けるように MARS を設定する必要があります。

レイヤ 3 トポロジ検出。 レイヤ 3 ネットワーク デバイス(IP レイヤで動作するデバイス)を検出する、プロセス中心の処理。このレイヤ 3 データは、攻撃パス ベクトルを判別し、トポロジ グラフを読み込む場合に使用します。この情報の更新スケジュールは定義することができます。

レイヤ 2 デバイス検出。 この機能を使用すると、MARS は攻撃パス ベクトルを判別したり、Media Access Control(MAC; メディア アクセス制御)アドレスによって攻撃元ホストおよびターゲットを識別したりすることにより、IP アドレスのスプーフィング攻撃による混乱を回避できます。この機能は通常、スイッチを追加したり、軽減機能をイネーブルにしたりするときに設定します。

MARS が定期的にデータをプルするデバイスには、複数のタイプがあります。これらのデバイスに対し、イベント ログを取得して処理するためのインターバルを定義できます。これらの更新機能は、次のとおりです。

Windows イベント ログ MARS が Windows ホストおよびサーバから監査追跡レコードをプルする頻度を設定できます。この設定はこのようなすべてのホストでグローバルです。デフォルト値は 5 分です。

Oracle イベント ログ。 MARS が Oracle データベース サーバから監査追跡レコードをプルする頻度を設定できます。この設定はこのようなすべてのサーバでグローバルです。デフォルト値は 5 分です。

モニタ対象デバイスの更新スケジューラ。 MARS が Qualys QualysGuard、Foundstone Foundscan、eEye REM などの特定のレポート デバイスからデータをプルする頻度を設定できます。スケジュールは IP アドレス単位で設定します。

設定を定義したら、Web インターフェイスの各ページにある [Activate] ボタンをクリックして、定義をアクティブにする必要があります。

手順完了時の結果:レポート デバイス、軽減デバイス、およびサポート デバイスからプルされたキャッシュ済みデータの更新スケジュールが MARS 内に定義され、アクティブになります。これらの設定を定義すると、MARS はネットワークをプローブしたり、レポート デバイス、軽減デバイス、およびサポート デバイスからアップデートをプルしたりすることができます。

詳細については、次の項を参照してください。

1. 「データ イネーブル化機能」

2. Device Configuration Guide for Cisco Security MARS, Release 6.x 』の「 Windows Event Log Pulling Time Interval 」セクション

3. 「レイヤ 2 検出および軽減」

4. Device Configuration Guide for Cisco Security MARS, Release 6.x 』の「 Configure Interval for Pulling Oracle Event Logs

5. 「動的な脆弱性スキャニング用ネットワーク」

6. 「NetFlow 異常検出の概要」

7. 「ネットワークの検出:レイヤ 3 トポロジ検出」

8. 「トポロジ更新のスケジュール」

ステップ 6 サポート デバイスおよびネットワーク資産に関する脆弱性評価情報を読み込みます。

脆弱性評価情報の対象は、ネットワークの特定のホストです。ホストがレポート デバイスであるか、軽減デバイスであるか、またはネットワーク上の重要な資産であるかに関係なく、すべてのホストについて詳細な情報を取得できます。

この情報には、ホストで稼動するオペレーティング システム、パッチ レベル、およびネットワーク サービスが含まれます。

ホストを定義したら、Web インターフェイスの各ページにある Activate をクリックして、ホストをアクティブにする必要があります。

手順完了時の結果:MARS はネットワーク上のホスト、および稼動しているサービスについての詳細情報を取得します。

詳細については、次の項を参照してください。

1. 「ホストとデバイスの ID および詳細に関する方針」

2. 「デバイス インベントリ ワークシート」

3. 「IP 管理」

4. 「サービス管理」

ステップ 7 イベント生成および処理をモニタおよび調整します。

モニタリング アプリケーションの場合と同様に、技術上の精度およびパフォーマンスを高めるには、ログ生成およびイベント処理を調整することが重要です。MARS でどのイベントを処理するかを調整する方法は、次の 2 つです。

デバイス側の調整 :この方法では、デバイス レベルでイベント生成を制限します。MARS は、セキュリティまたはデバイス ステータスに関連しないイベントは受信しません。この方法では、ネットワークの複数のデバイスから報告された疑わしい重複データの除去と、トラフィック サマリー Syslog など、MARS 内でレポートやクエリーによって複製される可能性のあるイベントの除去も行われます。

アプライアンス側の調整 :この方法では、MARS アプライアンスで受信したイベントのうち、通常のネットワーク アクティビティまたは計画済みのネットワーク アクティビティを表すものを特定します。MARS がこのようなイベントを疑わしいセキュリティ インシデントとして処理しないようにするために、廃棄規則を定義します。このような廃棄規則を定義する場合は、できるだけ細かく定義する必要があります。たとえば、予測期間内に特定の IP アドレスで発生すると想定される ping スイープの送信元を特定します。この場合は、ネットワークおよび管理方法に関する情報を明示的に指定する必要があるため、スプーフィングはより困難になります。7 つの条件、送信元、宛先、サービス タイプ、イベント タイプ、時間範囲、レポート デバイス、およびイベントの重大度を組み合わせて、規則をさらに限定できます。イベント全体を廃棄するのか、またはイベントを廃棄してデータベースに記録して、クエリーやレポートに使用できるようにするのかを選択する必要があります。


) 廃棄規則は MARS のイベントデータ格納を防止できません。単に、アプライアンスのイベント処理を防止するだけです。廃棄規則に影響されるイベントは、アプライアンスに格納されているためクエリーのように見えます。単にインスペクション規則の処理をしないだけで、イベントの格納は続いています。したがって、アプライアンスの格納が問題であれば、デバイス側の調整を使用することを推奨します。



) MARS のリリース 4.2.3 およびそれよりも前のリリースの場合、NetFlow ベースのイベントの廃棄規則を定義できません。これらのリリースでは、NetFlow イベントの調整は、レポート デバイスで行う必要があります。


調整は、攻撃の識別能力、真に疑わしいアクティビティに関するレポートの品質、および STM ソリューションの全体的なパフォーマンスや精度を改善するために継続的に行うタスクです。調整タスクではトラフィックを詳細に調査します。調査を行ったり精度を上げたりするには、アプライアンスに着信するイベントをデバイス単位で評価します。


ヒント ラボ ネットワーク環境では、MARS アプライアンスを使用して、生成されたイベントおよび調整オプションをデバイス タイプごとに調査します。制御された環境では、要件を文書化しておくことにより、デバイス側の重要な調整基準をモニタリング デバイス タイプごとに確立して、運用ネットワークの調整作業を大幅に削減できます。


手順完了時の結果:STM システムにとって価値のあるイベントだけが、MARS アプライアンスによって処理されるようになります。

詳細については、次の項を参照してください。

1. 「アプライアンス側の調整に関する注意事項」

2. User Guide for Cisco Security Manager 3.2.1 』の「 Managing Firewall Devices 」の「 Configuring Logging Policies on Firewall Devices


 

モニタリング フェーズのチェックリスト

プロビジョニング フェーズを完了したら、セキュリティに関するより広範な目標および要件を実現できるように MARS を設定する必要があります。モニタリング フェーズの主な目標は、モニタリング、軽減機能、および復旧ポリシーを効率的に実現することです。このフェーズでは、この目標の達成に必要な戦略、規則、レポート、およびその他の設定を定義します。


) 検出された攻撃に対応する準備をするため、トラフィック フローのモニタリングを開始する前に、企業のセキュリティ ポリシーに厳密に適合するように、MARS を設定しておく必要があります。


次のチェックリストに、意思決定プロセスを理解するために必要なタスク、および MARS を最も効率的に運用するために必要な基本フローを示します。各ステップには複数のサブステップが含まれることがあります。これらのステップとサブステップは順番どおりに実行する必要があります。チェックリストには、各タスクを実行するための具体的手順の参照先も示されています。


ステップ 1 モニタリング、通知、軽減機能、復旧、および監査に関する方針を決定します。

これらの方針で重要となるのは、目的のトラフィック フローや生成されたイベントでなく、MARS アプライアンスがこのデータを処理した後に何を実行するかです。MARS によるネットワークの保護方法、および進行中の攻撃を停止して感染したホストを復旧させる方法を、モニタリングおよび鑑識分析の短期および長期の要件を考慮して決定する場合は、これらの方針が重要となります。これらの方針には、MARS へのユーザ介入の予測だけでなく、レポート デバイスに関する予測も含まれます。基本的には、予想される役割、タスク、およびデータ要件がこれらの方針によって決定するため、イベント、規則、クエリー、およびレポートを、特定のタスクに必要なデータを提供する役割に対応付けることができます。

すべてのセキュリティ システムの場合と同様に、ジョブの実行に最低限必要な権限をユーザに割り当てることを推奨します。管理レベルの権限は、MARS アプライアンスの管理者だけに限る必要があります。

手順完了時の結果:検出された攻撃およびデバイス問題に効果的に対応するために必要なユーザおよびロールが決定されます。通知に応答するための明確なガイダンスが定義され、このような通知の情報に関する要件、および予測される使用方法と配信方式が決定されます。

詳細については、次の項を参照してください。

1. 「モニタリング、通知、軽減、復旧、および監査に関する方針」

2. 「ケース管理」

3. 「ユーザ管理」

4. 「Local Controller 上のグローバル ユーザ ロールの昇格」

5. 「ユーザ ロール ワークシート」

ステップ 2 通知サービスを定義します。

このタスクでは、軽減および復旧担当者に通知し、必要なその他のアクションを実行するように、MARS の通知サービスを準備します。MARS では、通知サービスは次の 3 つのブロックで構成されます。

ユーザ アカウント :レポートまたは通知を受け取るユーザ、またはモニタリングや軽減措置のために Web インターフェイスにアクセスするユーザ。ユーザは、電子メール、ページャ メッセージ、または Short Message Service(SMS)メッセージの形式で通知を受けることができます。ユーザは、Admin、Security Analyst、Operator、Notification Only の 4 つのロールのいずれかに割り当てられ、これによって Web インターフェイスのアクセス権限が決定します。

デバイス :通知を SNMP メッセージ、Syslog メッセージ、または(IOS IPS デバイスの場合は)DAM メッセージ(遮断と同等)の形式で受信するデバイス。デバイス定義の詳細については、「プロビジョニング フェーズのチェックリスト」を参照してください。

アクション :インスペクション規則内で定義される通知アクション。通知対象がユーザかデバイスかに応じて、スタッフにガイダンスを表示したり、デバイスに攻撃を記録またはブロックしたりするように指示できます。

MARS では、通知を受信すると想定されるユーザまたはデバイスをシステムで識別する必要があります。したがって、最初に、特定のイベント設定に基づいて通知する必要があるユーザまたはグループに対応付けるユーザ アカウントを定義します(「ユーザ ロール ワークシート」を参照)。また、通知される必要があるデバイス、または何らかのアクションを実行する必要があるデバイスを指定する必要があります(「デバイス インベントリ ワークシート」を参照)。

次に、通知サービス設定(アクション)として、電子メール、ページ、SMS、SNMP、Syslog、動的な攻撃軽減から、1 つ以上選択します。これらの設定にはそれぞれ、各通知タイプごとに定義可能な連絡先情報およびメッセージが含まれます。

これらの設定を定義する独立したインターフェイスはありません。通知サービス設定を定義するには、既存のインスペクション規則を編集し、新しいアクション定義を追加する必要があります。これらの設定を定義すると、すべてのインスペクション規則で使用できるようになります。

手順完了時の結果:必要なすべてのユーザが MARS で識別され、正しいユーザに通知されるように規則およびレポートをカスタマイズできるようになります。

詳細については、次の項を参照してください。

1. 「ユーザ管理」

2. 「カスタム ユーザ グループでのユーザの追加と削除」

3. 「IP 管理」

4. Device Configuration Guide for Cisco Security MARS, Release 6.x 』の「 Configuring Reporting and Mitigation Devices in MARS 」にある「Adding Reporting and Mitigation Devices」

5. 「サードパーティ製 Syslog および SNMP サーバへのアラート データの転送」

6. 「MARS MIB のフォーマット」

7. 「インスペクション規則」

8. 「システムおよびユーザ インスペクション規則の処理」

9. 「アラートの設定」

10. 「アラートとインシデントの通知」

ステップ 3 カスタム インスペクション規則を定義し、システム インスペクション規則を調整します。

インスペクション規則によって、異種デバイスからのイベントを、攻撃またはその他のネットワーク セッションのエンドツーエンド アクティビティが反映された重要なセッションに関連付けます。MARS は攻撃をエンドツーエンドで識別するため、ネットワークの軽減ポイントを確実に判別することができます。ただし、異なる目標を実現するためにインスペクション規則を定義することもできます。攻撃の識別は実現可能な目標の 1 つにすぎません。その他の目標の例としては、重要な資産の使用の特定、ネットワーク ヘルスの評価、使用率分析に基づくネットワーク設定の調整などがあります。

MARS には 100 を超えるインスペクション規則が組み込まれていますが、ユーザが属する企業のポリシーにとって重要なセッションを識別できないことがあります。たとえば、カスタム アプリケーションまたはサポート対象外アプリケーションの使用をモニタする場合は、選択された送信元と宛先間のトラフィックを、既知のプロトコルとポートのペアを使用してモニタするインスペクション規則を新規に定義できます。または、該当するアプリケーションによって生成されたイベントを独自に処理するカスタム ログ パーサーを定義して、追跡するイベント内のデータを調べることもできます。既知のプロトコルとポートのペアをモニタすると、セッション数などのサマリー データを取得することができます。一方カスタム ログ パーサーは、リソース利用率や失敗したログインなどのトラフィックの特徴を詳細に検査することができます。カスタム パーサーを定義するには、アプライアンスで使用されるメッセージ フォーマットを調べ、クリア テキスト形式で MARS にパブリッシュする必要があります。

作成した規則を意味のあるグループに編成すると、目的を明確にしたり、システムの学習能力を改善したりすることができます。具体的な目標について検討する場合は、規則グループ(および対応するレポート グループ)を定義して、上述の ステップ 1 で決定した方針を調整する必要があります。規則は複数のグループに属することができるため、同じ問題を解決するための同じ規則を何回も作成する必要はありません。グループ化の目的は、単に作業をまとめて、1 度に 1 つの方針を処理できるようにすることです。

手順完了時の結果:企業ポリシーに適合する適切な通知を送信するように、カスタム インスペクション規則がすべて作成され、既存のインスペクション規則が設定されます。カスタム ログ パーサーおよびインスペクション規則がすべて定義され、ユーザ ネットワーク内で発生したトラフィック フローまたはサポート対象外のアプリケーションやプロトコルを監査できるようになります。

詳細については、次の項を参照してください。

1. 「規則およびレポート グループ」

2. 「イベント管理」

3. 「IP 管理」

4. 「サービス管理」

5. 「ユーザ管理」

6. 「インスペクション規則」

7. 「システムおよびユーザ インスペクション規則の処理」

8. 「アラートの設定」

9. 「アラートとインシデントの通知」

ステップ 4 カスタム クエリーおよびレポートを定義します。

クエリーおよびレポートは鑑識分析を行うためのツールです。このツールを使用すると、履歴データを分析し、MARS のリアルタイム モニタリング機能では知り得ない長期的な傾向を特定することができます。本来、クエリーはレポート テンプレートの定義に従ってデータをオンデマンドで詳細に検査するために実行します。それに対してレポートは、定期的に実行されるようにスケジュールするものであり、継続的に検査する期間および頻度を定義できます。クエリーを使用すると、検索基準をフィルタリングして、レポート テンプレートに基づいて検索範囲を狭めたり、広げることができます。MARS には定義済みレポート テンプレートが多数用意されているため、ポリシーの実現にとって重要なインシデントおよびイベントに重点を置いた新しいレポート テンプレートを定義できます。この機能は、特に適合レポート要件に従う場合に役立ちます。レポートを定義し、生成スケジュールを立てて、結果を監査レコードの一部として格納できるためです。

アクセス全体と同様、レポートおよびクエリーの実行または表示機能は、ユーザ ロールに基づいて制限することができます。このようなセーフガード機能により、システムの他のユーザがレポートのスケジュールを誤って変更するような事態を回避できます。また、ユーザにレポートが通知されるようにレポート テンプレートを設定することもできます。通常、レポートの通知には電子メールがよく使用されますが、すべての通知方法がサポートされています。

手順完了時の結果:鑑識分析および監査の目標を実現するために必要なレポート テンプレートが定義され、最小権限ポリシーに従ってユーザ ロールに割り当てられます。レポートのアクセスまたは分配と、スタッフ間の問い合せに役立つレポート グループが定義されます。

詳細については、次の項を参照してください。

1. 「クエリーおよびレポート」

2. 「[Select Query Criteria]」

3. 「バッチ クエリー操作」

4. 「[Reports]」

5. 「レポートの作成」

ステップ 5 ネットワークおよびセキュリティ アクティビティをモニタします。

このタスクには、ネットワーク内で攻撃または問題点をモニタして、対応する作業が含まれます。MARS へのユーザの介入方法は、ユーザ ロールおよび組織の運用ガイドラインによって異なります。ユーザが Web インターフェイスを使用してほぼリアルタイムでトラフィックをモニタする場合は、疑わしい動作や異常な動作への対処時期や対処方法だけでなく、表示された相関データに関する詳しい知識が必要です。

MARS にはネットワークとセキュリティ アクティビティに対する 2 つのインターフェイスがあります。1 つは [Summary] タブで、もう 1 つは [Query/Reports] タブです。各インターフェイスには、ネットワークの現状の把握に役立つさまざまなビューおよびツールが用意されています。

[Summary] タブにはイベントがほぼリアルタイムで表示され、[Query/Reports] タブには主に過去の鑑識分析が表示されます(このチェックリストの次のタスクを参照)。[Summary] タブにはネットワーク アクティビティの主な状況として、ホット スポット図、最新イベント、インシデント チャート、およびトポロジ図が表示されるため、最新のアクティビティを確認できます。

さらに調査や軽減が必要なインシデントを指定する際には、インシデントを調査してフォールス ポジティブであるかどうかを判断したり、MARS を使用して攻撃をブロックしたりすることができます。レイヤ 2 で動作するチョーク ポイント(プライマリ スイッチ)が存在する場合、MARS は適切なデバイスを特定して、推奨される CLI 変更を行い、これらの変更をユーザがデバイスにプッシュできるようにします。チョーク ポイントがレイヤ 3 デバイスの場合、MARS は、特定されたチョーク ポイントとの管理セッションにコピー アンド ペーストできる CLI 変更を推奨します。

このような方法により、ユーザはネットワーク内の疑わしい動作をモニタし、検出内容に対応することができます。

手順完了時の結果:ネットワーク上の攻撃をモニタ、表示、および軽減するために必要なビューおよびツールについて理解しました。

詳細については、次の項を参照してください。

1. 「ネットワークの概要」

2. 「インシデントの調査および軽減機能」

3. 「フォールス ポジティブの確認」

4. 「規則およびレポート グループ」

5. 「イベント グループの使用」

6. 「ケース管理」

7. 「[False Positive] ページ」

8. 「未処理メッセージの取得」

ステップ 6 システムおよびネットワーク ヘルスをモニタします。

STM システムは MARS アプライアンスだけを示すのではなく、すべてのレポート デバイスや軽減デバイス、およびすべての MARS アプライアンスが含まれます。システムのヘルスを評価する場合は、これらのデバイスのヘルスをそれぞれモニタする必要があります。異常な動作に関する通知を生成するインスペクション規則を使用したり、システム ヘルスに関するクエリーおよびレポートを生成したり、MARS のシステム ログを手動で表示したりすることにより、システム ヘルスをモニタします。

MARS では、CPU、帯域幅、メモリなど一般的なリソースの使用に関するレポートを作成できます。システム ヘルスのモニタリングを簡素化するために、レポート グループを定義して、これらのレポートを意味のあるグループにまとめることができます。特定のユーザ ロールに限って、レポートおよびクエリーを表示できるようにすることも可能です。

レポートはスケジュール可能であるため、レポートが更新されるたびに該当するユーザに知らせることができます。


ヒント レポート デバイスのリソース使用率を表示できない場合は、[Admin] > [System Configuration] > [Security and Monitored Devices] でデバイスを定義する際に、[Monitor Resource Usage] オプションがイネーブルになっていることを確認してください。このデータを提供するように設定できるデバイスのリストについては、「リソース使用率データの設定」を参照してください。


MARS にはアプライアンス自体のステータスに関する詳細ログや、アプライアンスのヘルスに関するステータスを表示するコマンドライン ユーティリティがいくつか組み込まれています。

手順完了時の結果:システムおよびネットワーク ヘルスのモニタを行うために MARS に用意されているツールおよびレポートについて理解しました。

詳細については、次の項を参照してください。

1. 「規則およびレポート グループ」

2. 「規則およびレポート グループの概要」

3. 「リソース使用率データの設定」

4. Cisco Security MARS Command Reference, 6.X 』の pnstatus コマンド

5. Cisco Security MARS Command Reference, 6.X 』の pnlog コマンド

6. 「実行時ロギング レベルの設定」

7. 「MARS バックエンド ログ ファイルの表示」

8. 「監査証跡の表示」

9. 「未処理メッセージの取得」

ステップ 7 MARS の処理を調整します。

モニタリング アプリケーションに関する継続的な作業である調整には、イベント処理の感度および精度を調整する作業が含まれます。MARS では、次のようなさまざまな方法で変更を行うことができます。

廃棄規則を使用して、MARS によるイベント処理をイネーブルまたはディセーブルにします。


) MARS のリリース 4.2.3 およびそれよりも前のリリースの場合、NetFlow ベースのイベントの廃棄規則を定義できません。これらのリリースでは、NetFlow イベントの調整は、レポート デバイスで行う必要があります。


デバイスでイベント生成をオンまたはオフにします。

選択したインシデントをフォールス ポジティブとして識別します。

特定のネットワーク、ホスト、サービス、レポート デバイス、またはトラフィック フローを追加または除外することにより、インスペクション規則を調整します。

IPS や IDS などのデバイス タイプ別にトラフィックのインスペクションを調整し、イベント生成に使用される規則セットを改良します。

レポート デバイスを追加または削除することにより、報告イベント セットの変更や、フォールス ポジティブ、OS フィンガープリント、脆弱性評価などの MARS の自己調整機能を改善するために使用できる補助データの提供が行われます。

資産、サービス、および脆弱性評価情報を記述して、ネットワーク上で予測される動作を示します。ネットワークの詳細な情報が MARS に集まるにつれて、着信イベントに対する MARS の評価精度も高まります。

手順完了時の結果:MARS アプライアンスによって処理されるイベントの範囲が、STM システムに最も価値のあるイベントに限定されるか、またはこのようなイベントを含むように拡張されます。

詳細については、次の項を参照してください。

1. 「アプライアンス側の調整に関する注意事項」

2. 「廃棄規則の作業」

3. 「フォールス ポジティブの確認」

4. 「モニタ対象デバイスの選択」


 

モニタリング、通知、軽減、復旧、および監査に関する方針

STM で企業のセキュリティ ポリシーをサポートするには、複数の方針を緊密に調整する必要があります。

モニタリングでは、ネットワーク アクティビティおよびデバイスのステータスを調査して、異常なアクティビティまたは動作を識別します。

通知では、検出された異常に対応する担当者に警告し、対処に必要な情報を提供します。

軽減では、疑わしいアクティビティに対応して、ネットワークへの拡散を防止します。

復旧では、正常な対処を行って、ネットワークの感染ホストを浄化します。

監査では、その他のタスク中に発生したアクティビティを記録して、報告します。監査の目的は、適合性の監査や傾向分析をサポートするためのアクティビティおよび対処法をアカウントに提供することです。

最初に決定しなければならないのは、選択されたチョーク ポイントでの軽減に対する責任を持つ担当者です。通常、企業内では、各部門にわたるコア ネットワーク インフラストラクチャ デバイスから専用のセキュリティ デバイスを分離しています。たとえば、2 つの独立したチーム(セキュリティ運用チームとネットワーク運用チーム)は、共有デバイス上で、異なるネットワーク コンポーネントまたはポリシーに責任を持ちます。ネットワークで MARS を展開する前に、企業ポリシーに従って、軽減方針の責任者を明確に定義する必要があります。

軽減方針には、2 つの選択肢があります。

MARS を利用して、チョーク ポイントを判別し、推奨された CLI 変更を受け入れます。これによって、検出された攻撃をブロックすることができます。

MARS の推奨事項を評価できる担当者に通知し、インシデントの詳細を送信します。ただし、検出された攻撃を停止させる場所および方法についての最終判断は、その担当者が行います。

どちらの方法を選択しても、攻撃のブロック期間、正常化のために必要な内部攻撃調査の方法、必要な隔離期間後にポリシーを更新する担当者、および監査に適合するために、このようなイベント レコードを保持する方法(MARS のケース管理機能がチケット統合システムと連携しているかどうかなど)について、ガイドラインを作成する必要があります。

次に、実行しなければならないモニタリング タイプを明確にする必要があります。つまり、システム モニタリングとセキュリティ モニタリングを区別します。 システム モニタリング では、MARS アプライアンスのステータスだけでなく、MARS によって管理されるレポート デバイスおよび軽減デバイスのヘルスやステータスもモニタします。 セキュリティ モニタリング では、ネットワークおよびセキュリティに関するアクティビティを重点的にモニタします。

どちらのタイプのモニタリングを行う場合でも、定義済みおよびカスタムのクエリーやレポートの中で必要なもの、これらによって取得されるデータを評価して対応するプロセス、および MARS のケース管理機能を使用して応答を管理し、変更を追跡するためのガイドラインを決定する必要があります。

最終フェーズでは、特定のインシデントが検出された場合に通知するユーザを決定します。たとえば、デバイス ステータスに関するインシデントを通知するユーザと、セキュリティに関するインシデントを通知するユーザなどです。軽減および復旧の担当者とモニタリング(必要な場合は部門にまたがるモニタリング)を実行する担当者、および通知の生成方法と形式を決定します。この作業では、SMS、ページャ アラート、電子メールなどから方法を選択し、インシデント、クエリー、またはレポートのどれに基づいて通知を生成するかを決定します。

アプライアンス側の調整に関する注意事項

MARS アプライアンスを調整する場合、レポート バイスから着信したトラフィックの検査は重要でありません。アプライアンス側で調整する場合は、主に次の 2 つの方法を使用します。

廃棄規則 :レポート デバイスから受信した特定の基準と一致するすべてのイベントを廃棄します。この方法は高速で、最も調整が少なくてすみます。廃棄規則を定義するときに、イベント ログを維持するのか、または単に廃棄するのかを指定することもできます。廃棄規則の利点は、イベントがインスペクション規則で処理されないため、発生する可能性のあるワークロードが削減されて、アプライアンスの処理が高速になることです。


) MARS のリリース 4.2.3 およびそれよりも前のリリースの場合、NetFlow ベースのイベントの廃棄規則を定義できません。これらのリリースでは、NetFlow イベントの調整は、レポート デバイスで行う必要があります。


インスペクションからのデバイスの削除 :インスペクション規則からデバイスを削除します。この方法は、特定のタイプのアラームをトリガーするイベントだけが対象になります。レポート デバイスから受信した特定の基準と一致するイベントがまったく破棄されないのがこの方法の利点です。つまり、この方法で重要になるのは、起動したすべてのインシデントを削除するのではなく、イベントに基づいて、特定のフォールス ポジティブを削減することです。また、クエリーおよびレポートを使用してイベントを確認できるように、イベントが記録されます。

どちらの方法を使用する場合も、規則を追加または変更したときには、[Activate] ボタンをクリックして変更を有効にする必要があります。

デバイス インベントリ ワークシート

デバイス インベントリ ワークシートを使用すると、ネットワーク上のデバイスに関して必要な情報を収集できます。収集する情報は次のとおりです。

デバイス名 :デバイスの既知の名前。通常は、デバイスの DNS 名になります。MARS のトポロジ グラフ、レポート、およびイベントに、この名前が使用されます。

レポート IP アドレス :MARS に対してイベントを送信するネットワーク インターフェイスに割り当てられた IP アドレス。MARS はこのアドレスを使用してデバイス名に対応付けて、デバイスから送信されたメッセージおよびイベントを一意に識別します。

管理 IP アドレス :MARS の接続先ネットワーク インターフェイスに割り当てられた IP アドレス。このアドレスを使用して MARS はデバイスに接続し、その設定情報を取得します。

ユーザ名/パスワード :管理 IP アドレスに接続し、ネットワークでのロールに基づいて情報を読み書きするための許可が正しく設定されているアカウント。レポート デバイスの場合、このアカウントには MARS が既存設定を読み取るのに十分な権限が設定されている必要があります。軽減デバイス、特にレイヤ 2 スイッチの場合、検出された攻撃をブロックするために、MARS はこのアカウントを使用して、実際の CLI 変更をデバイスにパブリッシュします。

システム/セグメント内の役割 :デバイスの役割(レポート デバイスまたは軽減デバイス)。DNS や電子メール サーバなどのサポート デバイスの場合もあります。さらに、ネットワーク セグメントに対して想定されるこのデバイスの重要性、特に同じセグメント上の別のデバイスに対する重要性を考慮する必要があります。このセグメントレベルの役割を明確にするには、モニタリング方針全体を表すような用語(プライマリ送信元、代替オプション、攻撃 ID、フォールス ポジティブ評価、セッション データ、エンドポイント/MAC アドレス ID)を使用します。デバイスがネットワーク セグメント レベルで実行できる、または実行すべき役割を把握すると、調整可能な必須ログ設定にプライオリティを付けることができます。

必須プロトコル :このデバイスが処理に使用するプロトコル。重要なのは、管理プロトコル、通知プロトコル、および監査イベントのパブリッシュに使用されるプロトコルです。

ログ設定/SNMP RO コミュニティ ストリング :このデバイスが MARS システム内で果たす役割に必要な、イベントおよびログ生成に関する特定の設定。および、このデバイスの SNMP RO コミュニティ ストリング。

調整の可否 :ログ生成をデバイス側で調整できるかどうか。

通知 :このデバイスが MARS から通知を受信できるかどうか。

通知フォーマット :このデバイスに送信される通知のフォーマット。

 

表 2-1

デバイス名
レポート IP アドレス
管理 IP アドレス/
アカウント
ユーザ名/
パスワード
システム/セグメント内の役割
 
必須プロトコル
ログ設定/SNMP RO コミュニティ ストリング
調整の可否
(可/不可)
通知
(可/不可)
通知フォーマット

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ユーザ ロール ワークシート

ユーザ ロール ワークシートを使用すると、ネットワークの管理者に関して必要な情報を収集できます。収集する情報は次のとおりです。

ユーザ名 :ユーザの名前

ユーザ ロール :このユーザが企業のセキュリティ ポリシーに関して果たす役割

MARS アカウント :MARS のユーザ アカウント、およびロール(Admin、Security Analyst、Operator、または Notification Only)。このロールにより、Web インターフェイスでのアクセス権限が決定します。アカウンタビリティおよびセキュリティのために、通常はユーザごとに一意のアカウントを設定します。ただし、グループベースのアカウントも定義できます。

通知設定 :インシデント規則が起動された場合に、このユーザと通信するために必要な情報。ユーザの場合は、電子メール、ページャ メッセージ、または SMS メッセージです。対応チームの場合は、グループ エイリアスを使用できます。インスペクション規則が起動したり、スケジュールされたレポートが生成されると、ユーザに通知が送信されます。

デバイスの所有権 :ユーザが責任を負うネットワーク上のレポート デバイスおよび軽減デバイス。このリストは、ユーザが軽減チームまたは復旧チームに属している場合には特に重要です。

インスペクション規則 :このユーザ ロールを果たすのに必要なインスペクション規則。これらの規則を定義したり、規則の起動時にユーザに通知するように設定する必要があります。

レポート/クエリー :このユーザ ロールを果たすのに必要なレポートおよびクエリー。ユーザがこれらのレポートおよびクエリーにアクセスできるようにする必要があります。また、スケジュールされたレポートが生成された場合にユーザに通知することもできます。

 

表 2-2 ユーザ ロール ワークシート

ユーザ名
ユーザ ロール
MARS
アカウント/ロール
通知設定
デバイスの所有権
インスペクション規則
レポート/クエリー