Management Center for Cisco Security Agents 6.0.2 ユーザ ガイド
規則モジュールの設定
規則モジュールの設定
発行日;2012/01/15 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

規則モジュールの設定

概要

規則モジュールおよび規則について

規則モジュールの管理

規則モジュールの設定

規則モジュールへの規則の追加

規則表示のフィルタリング

モジュール間での規則のコピー

設定の比較

規則モジュールのマージまたはコピー

変更履歴の表示

規則の説明

整合性検査

ポリシーへの規則モジュールの関連付け

規則プログラムの生成

規則ページの共通設定項目

規則:アクション オプションと優先順位

規則:アクション定義

強制アクション

検出アクション

規則:優先順位の操作

Monitor アクション

Notify User アクション

Set アクションの使用方法

アトリビュート:Current Application Virus Classification

アトリビュート:Custom-made state condition

アトリビュート:Data Payload trust status

アトリビュート:Data scan on CLOSE

アトリビュート:Data scan on OPEN

アトリビュート:detected access

etected boot

:detected rootkit trust status

アトリビュート:Digital signature check

アトリビュート:File deletion

アトリビュート:file trust status

t address trust status

rity level

アトリビュート:Stack

アトリビュート:Sensitive Data Scan

アトリビュート:Timer to restore Security

アトリビュート:Virus scan

アトリビュート:Virus scan on CLOSE

アトリビュート:Virus scan on OPEN

ユーザに対するクエリー

応答のキャッシング

クエリー規則の優先順位情報

Rule Overrides

監査モードの使用方法

グループの監査モード

規則モジュールの監査モード

ポリシーの監査モード

監査モードのホストの識別

ラーニング モードの使用方法

ラーニング モードに関するその他の注

Sample - Cisco Security Agent Bypass 規則モジュール

規則モジュールの設定

概要

規則モジュールは 1 つまたは複数の規則で構成されます。規則モジュールは、単独または複数で 1 つのポリシーに関連付けられます。この規則のモジュールは、一般に特定の「モジュール化」の目的で設定されます。つまり、複数の規則をあるポリシーから別のポリシーにまとめて移動したり、いくつかのポリシーの一部にできます。

ポリシーとは異なり、一般に規則モジュールは OS に固有なものです。このように、非常に多くの規則モジュールをそれよりも少ない数のポリシーに合わせて調整し、基本的な製品設定ビューを簡素化することができます。たとえば、すべての Apache サーバ用に 1 つのポリシーを設定できますが、そのポリシーは数百の規則を含むいくつかの OS 固有規則モジュールで構成されます。管理者は、このように一般サーバ グループに関連付けて展開できる Apache ポリシーだけを対象にすることができます。

この章で取り上げる事項は次のとおりです。

「規則モジュールおよび規則について」

「規則モジュールの管理」

「規則モジュールの設定」

「規則モジュールへの規則の追加」

「規則表示のフィルタリング」

「モジュール間での規則のコピー」

「設定の比較」

「規則モジュールのマージまたはコピー」

「変更履歴の表示」

「規則の説明」

「整合性検査」

「ポリシーへの規則モジュールの関連付け」

「規則プログラムの生成」

「規則ページの共通設定項目」

「規則:アクション定義」

「規則:優先順位の操作」

「Monitor アクション」

「Notify User アクション」

「Set アクションの使用方法」

「ユーザに対するクエリー」

「応答のキャッシング」

「Rule Overrides」

「監査モードの使用方法」

「ラーニング モードの使用方法」

「Sample - Cisco Security Agent Bypass 規則モジュール」

規則モジュールおよび規則について

規則とは、セキュリティ ポリシーの基本要素です。CSA MC では、複数の規則タイプが作成できます。各規則タイプには、特定の構文を使用して、情報をさまざまに組み合わせて入力する必要があります。ほとんどのポリシーおよび規則モジュールは、セキュリティを実施し、動作を検出する規則の組み合わせを使用します。実施および検出のアクションは階層的で、特定の手順の規則に従います (手順については、「規則:アクション オプションと優先順位」を参照してください)。

強制アクションの例としては、リソースにアクセスしようとして CSA が許可したとき、拒否したとき、またはプロセスを終了したとき、があります。検出アクションの例としては、CSA がユーザに通知するとき、アプリケーションの動作を監視するとき、リソースにタグ付けするとき、があります。CSA がシステムを保護する方法として、セキュリティを強制する規則と、動作を検出する規則を組み合わせる方法があります。たとえば、アプリケーションの動作に基づいてプロセスをアプリケーション クラスに追加するよう、検出規則に記述することができます。次に、アプリケーション クラスのすべてのメンバーが特定のリソースにアクセスすることを拒否するよう、強制規則に記述することができます。

規則表示リストで、強制規則はリストの上部に、検出規則は下部に表示されます。図 5-2 規則モジュールの規則リストは、規則表示リスト、および 3 つの強制規則と 1 つの検出規則を示しています。

CSA MC に付属の他のタイプの強制規則は、イベント相関および学習機能を備えており、ポート スキャン検出、SYN フラッド保護、予想可能な TCP シーケンス番号の防止、および形式誤りの IP パケットのブロックをグループごとにイネーブルにできます (これらの機能は、[Network shield rule] ページにあります)。これは特にネットワーク サーバで役立ちます (詳細については、 第 7 章「グローバル設定の使用」 を参照してください)。

規則タイプの中には、すべてのオペレーティング システムで共通なものもありますが、特定のオペレーティング システムだけで使用できるものもあります。規則タイプには、Windows と UNIX の両方のオペレーティング システムで使用できるもの、Windows だけで使用できるもの、および UNIX だけで使用できるものがあります。UNIX オペレーティング システムという場合には、Solaris と Linux の両方のオペレーティング システムが含まれています。

規則モジュールの管理

ここでは、規則モジュールの設定および管理に関係するタスクについて説明します。

規則モジュールの設定

規則モジュールは 1 つまたは複数の規則で構成されます。規則モジュールは、単独または複数で 1 つのポリシーに関連付けられます。複数のポリシーを 1 つのグループに割り当てることができます。1 つのホストが複数のグループに属し、所属先のすべてのグループのポリシーを継承することも可能です。1 つのホストに複数のポリシーを関連付けると、それぞれのポリシーの規則モジュールがマージされ、あたかも 1 つのポリシー内ですべて定義されているかのように機能します。特に、ポリシー内の規則の順位は 1 つのモジュール内の場合と同じになります。

ポリシー レベルは、ホスト グループがそのセキュリティ ポリシーを構成する規則を知るための共通基盤となるものです。


「規則:アクション オプションと優先順位」をよく読んで、ポリシーを展開した後、規則の優先順位がどのように機能するかを理解しておいてください。また、変数の設定についての章(第 8 章「変数と状態条件の設定」)も参照して、規則テキスト フィールドが必要とする情報を理解しておいてください。



注意 CSA MC の出荷時に事前設定のポリシーおよび規則モジュールの整合性を維持するため、これらのポリシーを変更しないでください。事前設定のポリシーを使用する場合でも、自サイトの事情で少し編集が必要なときは、新しいポリシーを作成し(既存のポリシーをクローニング)、グループに追加する必要があります。

規則モジュールを設定するには、次の操作を行います。


ステップ 1 設定特権のあるユーザとして CSA MC にログインし、拡張モードに切り替えます。

ステップ 2 [Configuration] メニューをマウスでポイントし、表示されるドロップダウン メニューから [Rule Modules] を選択します。規則モジュールのリスト ページに、既存の規則モジュールの一覧が表示されます。CSA MC はいくつかの事前設定のモジュールとともに出荷されます。

ステップ 3 新しい規則モジュールを作成するには、[New] ボタンをクリックします。

ステップ 4 オペレーティング システムの管理プリファレンスを設定していない場合は、表示されるポップアップ ボックスから、Windows または UNIX 規則モジュールのいずれかを選択します。


) 一般的に、UNIX は Solaris と Linux の両方のオペレーティング システムを指します。


ステップ 5 規則モジュール設定ビューの [Name] に、モジュールの一意の名前を入力します。名前は大文字と小文字を区別します。最初の文字には英文字を使用し、長さは 64 文字以下で、ハイフンとアンダースコア(_)が使用できます。名前に空白を含めることもできます。モジュールをポリシーに関連付けたときにポリシー リストボックスですぐ認識できるような、わかりやすい名前を付けます。

ステップ 6 [Description] に、モジュールの説明を入力します。この説明は、規則モジュール リスト ビューに表示されます。[+Detailed] フィールドを拡張すると長い説明を入力できます。

ステップ 7 [OS] フィールドでは、 オプションで、Windows または UNIX の分類内で特定のオペレーティング システムに対して、このモジュールをターゲットとして選択できます。


) • 32 ビット Vista、Windows 7、または Windows 2008 オペレーティング システム専用の規則モジュールを作成する場合は、OS のドロップダウン メニューで [Vista/Win7/W2k8 x86] を選択します。

64 ビット Vista、Windows 7、または Windows 2008 オペレーティング システム専用の規則モジュールを作成する場合は、OS のドロップダウン メニューで [Win7/W2K8 x64] を選択します。


 

ステップ 8 オプションで、この規則モジュールを [Rule overrides] から使用できる [Audit mode] に置くことができます。この方法で、同じホストに割り当てられた他のモジュールからの規則をライブ モードで実行している間、監査モードで実行中の監査モード モジュール内に規則を設定することができます。これは、新しい規則モジュールをテストする場合、または当該のホストに対するすべての保護を解除することなく既存のモジュールを変更する場合に役立ちます。グループ レベルで監査モードを適用することもできます。詳細については、「監査モードの使用方法」を参照してください。

ステップ 9 オプションで、この規則モジュールを [Rule overrides] から使用できる [Learn mode] に置くことができます。この方法で、エージェント上でポリシー規則をローカライズして、エージェントを最初にインストールしたときに表示される可能性のあるクエリー ポップアップの発生を抑えることができます。ラーニング モードは、展開されたクエリー ユーザ規則と連動して特定の方法で動作します。詳細については、「ラーニング モードの使用方法」を参照してください。

ステップ 10 オプションで、設定された [State Conditions] を規則モジュールに適用することもできます。規則に状態条件を指定するには、[System state] または [User state] の横の [change] リンクをクリックします。「状態条件」を参照してください。

ステップ 11 [Save] ボタンをクリックします。

ステップ 12 ここで規則をモジュールに追加します。[Rules] エリアの [Add] ボタンをクリックし、モジュールに追加する規則の種類を選択します。

選択した規則の作成については、 第 6 章「利用可能な規則タイプ」 の規則タイプの説明を参照してください。


) エージェントが最初にインストールされた後、設定できない自動の正規化ラーニング期間があり、72 時間実行されます。このラーニングは、実行しているアプリケーションと異常システム コールの両方が対象です。[Reset Cisco Security Agent] の [Learned Information] チェックボックスを使用すると、最初の学習内容をすべて消去して、72 時間の自動ラーニング期間を再び開始できます。


規則モジュールへの規則の追加


ステップ 1 設定特権のあるユーザとして CSA MC にログインし、拡張モードに切り替えます。

ステップ 2 メニューバーの [Configuration] をマウスでポイントし、メニューの [Rule Modules] を選択します。規則モジュールのリスト ページに、既存の規則モジュールのリストが表示されます。CSA MC はいくつかの事前設定のモジュールとともに出荷されます。

ステップ 3 規則を追加する規則モジュールのリンクをクリックします。

ステップ 4 規則モジュールの [Rules] エリアを展開し、[Add] をクリックします。ドロップダウン メニューに、規則タイプのリストが表示されます。

ステップ 5 規則モジュールに追加する規則の種類を選択します。指定した規則タイプの設定ページが開きます。

ステップ 6 第 6 章「利用可能な規則タイプ」 の手順に従って規則を設定し、[Save] をクリックします。

図 5-1 規則モジュール、規則の変更

規則モジュール設定ビューで [Enable] と [Disable] のボタンを使用すると、特定の規則の設定ビューに移動しなくても、モジュール内の規則をイネーブルまたはディセーブルにできます。イネーブルまたはディセーブルにする規則のチェックボックスをオンにし、対応するボタンをクリックします図 5-2を参照してください。

[Rules] セクションの [ID] カラムには、対象の規則に割り当てられた規則 ID 番号が表示されます。この番号は、新しい規則が作成されるごとにインクリメントします。これは、規則の識別子としてのみ使用されます。この ID は Event Log メッセージに表示され、これを使用して特定の規則が参照できます。

[Rules] セクションの [Events] カラム(図 5-2 を参照)には、過去 24 時間に規則が生成したイベントの番号が表示されます。この番号をクリックすると、イベント自体のリストに移動します。

図 5-2 規則モジュールの規則リスト

規則表示のフィルタリング

[Groups] 設定ページ、ポリシー設定ページ、および規則モジュール設定ページには、それぞれグループに関連付けられた規則、またはモジュールに含まれる規則のいずれかのテーブルが表示されます。これらのどのページでも、テーブルの上部に [View All rules] 項目があります。ここで [All] リンクをクリックすると、選択した規則タイプによって、この規則のビューをフィルタリングできます。All をクリックすると、ポップアップが表示され、1 つまたは複数のモジュール内に存在する規則タイプがリストされます。ポップアップから規則タイプを選択すると、選択した規則タイプのみがテーブルに表示されます。[show enabled rules only] チェックボックスをオンにし、表示する規則タイプを選択して、イネーブルになった規則のみを表示することもできます。


) 規則の表示をフィルタリングしても、他の規則がモジュールから削除されるわけではありません。変更されるのは、モジュールの表示のみです。同じポップアップ メニューから [All] を選択すると、要約ビュー全体が再び表示されます。


このフィルタリング機能は、規則のリストが大きくなり、特定の規則タイプのみに絞って表示する必要がある場合に役立ちます。

ユーザ状態またはシステム状態を規則モジュールに適用する場合は、それらの設定に基づいて表示をフィルタリングすることもできます。これは、特定の状態がアクティブである場合にどの規則が適用されるかを表示するのに役立ちます。

モジュール間での規則のコピー

[Copy] ボタンと [Rule Module] ページの下部にあるプルダウン リストを使用して、選択した規則を、指定した別の規則モジュールにコピーできます。モジュール間の規則のコピーは、設定のクローニングと同様です (この項で説明する [Copy] ボタンを使用して、ポリシー内で規則をクローニングすることもできます)。

選択した規則をモジュール間でコピーするには、次の手順を実行します。


ステップ 1 設定特権のあるユーザとして CSA MC にログインし、拡張モードに切り替えます。

ステップ 2 CSA MC のメニューバーの [Configuration] をマウスでポイントし、[Rule Modules] を選択します。規則モジュールのリスト ページに、既存の規則モジュールの一覧が表示されます。CSA MC はいくつかの事前設定のモジュールとともに出荷されます。

ステップ 3 規則のコピー元の規則モジュールのリンクをクリックします。

ステップ 4 [Rule Module] ページ(図 5-2 を参照)で、別のモジュールにコピーする 1 つまたは複数の規則のチェックボックスをオンにします。

ステップ 5 [Copy] ボタンの横のプルダウン メニューでは、[to] がデフォルトのオプションになっています (モジュール間で個々の規則をコピーする場合は、このオプションは変更しないでください)。[rule module] プルダウン リストで、選択した 1 つ以上の規則のコピー先として、モジュール名を選択します。

ステップ 6 [Copy] ボタンをクリックします。

チェックをオンにしたすべての規則が、選択したモジュールにコピーされます。

モジュール間で規則をクローニングするには、上のステップ 1 ~ 4 を繰り返します。次に、規則モジュール プルダウン リストで他のモジュールを選択するのではなく、同じプルダウンリストで現在のモジュールを選択します。[Copy] ボタンをクリックすると、選択した規則が、同じモジュール内でクローニングされます。

[Copy] ボタンの横のプルダウン メニューで [from] を選択すると、(規則モジュール プルダウン リストで)選択したモジュールのすべての規則をコピーできます。

設定の比較

この比較ツールの目的は、設定をインポートした後、または CSA MC をアップグレードした後にユーザを支援することです。これらのプロセスによって、重複した、非常によく似た設定項目ができることがあります。設定を比較してマージすることで、重複した項目を簡単に集約することができます。この比較ユーティリティは、グループ、規則モジュール、ポリシー、アプリケーション クラス、および変数で使用できます。

CSA MC のすべてのユーザは、拡張モードで CSA MC を表示するときに規則モジュールを比較できますが、比較したモジュール内で規則をコピー、マージ、または削除できるのは設定権限を持つユーザだけです。

2 つの項目を比較する場合(3 つ以上の設定は同時に比較できません)、CSA MC では 2 つの設定が左右に並べて表示され、異なる部分が赤で強調されます(図 5-3 を参照)。設定権限を持っているユーザが設定の差異を評価したら、いくつかの規則をマージして、それらの規則を別の規則モジュールへコピーするか、または新しいモジュールへコピーするかを選択できます。また、これらのユーザはグループおよびポリシーのアタッチやデタッチをすることも可能です。アプリケーション クラスや変数も比較できますが、比較ページからコピーやマージができるのは規則のみです。

機能に関する注:

規則モジュールを比較すると、それらのモジュール内の類似の規則が左右に並べて表示され、異なる部分が赤で強調表示されます。差異がない場合、規則の説明テキストが黒で表示されます。

規則モジュールを比較する場合、ページの上部にリンクがあります。ここで [show all rules] または [show only similar rules with detailed differences] を使用できます。[show only similar rules with detailed differences] を選択すると、モジュールの差異、およびそれらのモジュール内の規則の差異のみが表示されます。

一方のモジュールにある規則に対応する規則が、もう一方のモジュールに存在しない場合は、比較の表示で、その規則の横に何も表示されません。

説明、アプリケーション クラス、他の設定項目がすべて同じである場合は、異なるロギング オプションが選択されていたり、許可/拒否アクションが違っていても、左右に表示されません。ロギングや許可/拒否アクションが異なると、ポリシー内の規則の優先順位が異なります。各規則で優先順位が同じでなくても、左右に並べて表示されません。

2 つの規則モジュールを比較するには、次の手順に従います。


ステップ 1 設定特権のあるユーザとして CSA MC にログインし、拡張モードに切り替えます。

ステップ 2 CSA MC のメニューの [Configuration] をマウスでポイントし、[Rule Modules] を選択します。

ステップ 3 [Rule Module] リスト ページで、比較する 2 つの規則モジュールを選択して [Compare] を選択します。

図 5-3 規則モジュールの比較

規則モジュールのマージまたはコピー

あるモジュールから他のモジュールへ規則をマージまたはコピーするには、最初に 2 つの規則モジュールを比較します。規則モジュールを比較して差異を評価したら、モジュール間で規則をコピーすることができます。


ステップ 1 2 つの規則モジュールを比較します。

ステップ 2 他の規則モジュールにマージする規則モジュールから規則を選択し、[Copy] をクリックします。[Copy Policy Rules] ポップアップ ボックスには、次のオプションが表示されます。

比較している一方の規則モジュールで選択した規則を、比較している他方の規則モジュールにコピーする。

選択した規則を、選択した別の規則モジュール(現在比較している規則モジュールではない)にコピーする。

選択した規則を、ここで利用可能なフィールドに名前を入力して作成した新しい規則モジュールにコピーする。

ステップ 3 [Copy Policy Rules] ポップアップで、実行するコピー タスクを選択して [OK] をクリックします。

図 5-4 [Copy Rule Module] ポップアップ ボックス

変更履歴の表示

各規則のページの上部に、[View change history] リンクがあります。このリンクをクリックすると、この規則に対して行われたすべての変更内容が一覧表示されているページが表示されます。この [View change history] リンクは、アプリケーション クラス、変数、規則モジュール、およびポリシーにも使用できます。

規則の説明

CSA MC では、対象のポリシーの説明によって、段落形式の各規則とそのポリシー内での役割が説明されます。[Groups]、[Host]、[Rule Modules]、または [Policy] ページで、[Explain rules] リンクをクリックすると、この説明が表示されます。図 5-5を参照してください。

図 5-5 [Rule Module Explanation] ページ

整合性検査

メインの規則モジュール ページでは、規則の一部である変数に対する OS 整合性検査が行われます。たとえば、Linux アプリケーション クラスが、Linux または All UNIX をターゲット OS とする UNIX モジュールに接続されていることを確認します。規則モジュールのターゲット OS が Solaris である場合、アプリケーション クラスに Linux のマークが付けられていると、整合性検査は失敗します。

この整合性検査では、指定した OS タイプのモジュールが同様の OS ポリシーに接続されていることも確認されます。項目のクローンを作成したり複数のポリシー編集を作成したりできるよう整合性検査に合格しなかったモジュールを保存することはできますが、矛盾した項目の付加や展開はできません。

ポリシーへの規則モジュールの関連付け


) この手順は、第 4 章「ポリシーの構築」に示す手順と同じです。便宜のため、ここにも手順を示します。


規則モジュールを設定するときには、アクセス制御規則やタギングおよびモニタリング規則を共通の名前の下に組み合わせます。この操作により、その規則モジュール名がポリシーに関連付けられます。このポリシーは、モジュールを構成する規則を使用して、ホストで許可または拒否されるアクションを制御します。「規則モジュールの設定」を参照してください。

CSA MC には、[Rule Module] 設定ページの [Modify policy associations] リンクを使用して規則モジュールをポリシーに関連付けるオプションと、Policy リスト ビュー ページの [Modify rule module associations] リンクを使用してポリシーを規則モジュールに関連付けるオプションがあります。

規則モジュール設定ページの [Modify policy associations] リンクを使用して 1 つまたは複数の規則モジュールを既存のポリシーに関連付けるには、次の手順を実行します。


ステップ 1 設定特権のあるユーザとして CSA MC にログインし、拡張モードに切り替えます。

ステップ 2 メニューバーの [Configuration] > [Rule Modules] をマウスでポイントします。規則モジュールのリスト ページに、既存の規則モジュールの一覧が表示されます。CSA MC はいくつかの事前設定のモジュールとともに出荷されます。

ステップ 3 ポリシーに関連付ける規則モジュールのリンクをクリックします。該当する規則モジュールの編集ビューが表示されます。

ステップ 4 編集ビューで [Tasks] メニューを展開し、[Modify policy associations] リンクをクリックします。この操作を行うと、スワップ ボックスがあるページが表示されます。図 5-6を参照してください。左のボックスには、規則モジュールを関連付けないポリシーが表示されます。右のボックスには、規則モジュールを関連付けるポリシーが表示されます。

ステップ 5 この規則モジュールを既存のポリシーに追加するには、左のボックスで規則モジュールを選択し、[Add] ボタンをクリックします。選択した規則モジュールが右のボックスに移動し、ポリシーに関連付けられています。


) 異なるアーキテクチャの規則モジュールを同じポリシーに付加することができます。このようにして、すべてのプラットフォームでサポートされるソフトウェアの、サポートされる全アーキテクチャで、タスク固有の完全独立した包括的なポリシーを設定できます。たとえば、Apache は、Windows、Linux、および Solaris プラットフォームをサポートする Web サーバ ソフトウェア製品です。Apache 用の 3 つの OS 固有の規則モジュールを 1 つのポリシーに関連付けることができます。その場合、管理する必要があるのは、1 つの Apache ポリシーだけです。



注意 規則モジュールをホストに展開するには、規則モジュールを関連付けるポリシーを忘れずにグループに付加する必要があります。

図 5-6 規則モジュールの関連付け

規則プログラムの生成


注意 既存の CSA MC 設定を変更すると、変更内容はデータベースに保存されますが、まだネットワーク経由で各エージェントへは配布されません。CSA MC の下部のフレームにある [Generate rules] リンクをクリックして、まず新しい設定と編集済みの設定をすべて表示した後、それらをエージェントに配布する必要があります (保留中の変更内容がある場合は、[Generate rules] リンクの下線が点滅します)。

[Generate rule programs] ビューには、配布されないデータベース項目すべてのステータスに加え、設定変更を行った管理者の名前が表示されます。編集済みの各設定項目の横に、[Details] リンクが表示されます。リンクをクリックすると、その設定に対して行われた変更内容が表示されます。

これらの変更内容を確認したら、戻って設定を変更または削除するか、あるいは [Generate] ボタン(下部のフレーム内)をクリックしてすべてのアップデートを配布できます。


) 規則プログラムを生成してエージェントに配布する前に、[Reports] ドロップダウン リストから [Audit Trail] ビューにアクセスすると、変更時刻や変更を行った管理者など、すべてのデータベース変更を表示できます。詳細については、「監査追跡の使用方法」を参照してください。


図 5-7 設定の生成

規則ページの共通設定項目

ここでは、ほとんどの規則タイプ ページにある共通のフィールドについて説明します。これには、規則の優先順位を決定するアクション オプションならびにクエリー規則の仕組みの説明も含まれます。固有の規則タイプ自体は、次の章で説明します。

規則:アクション オプションと優先順位

特定の規則タイプを設定する場合は、その規則のアクション(許可や拒否など)を選択します。規則モジュールをポリシーに追加すると、CSA MC は、アクションに応じて複数のモジュールから個々の規則を各ポリシー内で次のように順位付けます。

優先順位 1

Priority Terminate Process(優先順位終了プロセス)

優先順位 2

Priority Deny(優先順位拒否)

優先順位 3

Priority Allow(優先順位許可)

優先順位 4

Query User (Default Terminate)(クエリー ユーザ(デフォルトは終了))

優先順位 5

Query User (Default Deny)(クエリー ユーザ(デフォルトは拒否))

優先順位 6

Query User (Default Allow)(クエリー ユーザ(デフォルトは許可))

優先順位 7

Terminate Process(終了プロセス)

優先順位 8

Deny(拒否)

優先順位 9

Default Action (Allow)(デフォルト アクション(許可))

優先順位/適用なし

Monitor(モニタ)

優先順位/適用なし

Notify User(ユーザ通知)

優先順位/適用なし

Set(設定)

優先順位/適用なし

Add process to application class(プロセスをアプリケーション クラスに追加)

優先順位/適用なし

Remove process from application class(アプリケーション クラスからのプロセスの削除)

項目の横にある優先順位リストは、CSA が規則を処理する順序を示します。別の上位の優先順位規則がシステム アクションによって実行されていない限り、1 の強制規則(Priority Terminate Process)が最初にチェックされ、優先順位 8 の強制規則(Deny)が最後にチェックされます。同じリソースのトリガーを最初に規制する、優先順位の強制規則がある場合でも、モニタ規則などの検出規則は常にチェックされます。


) エージェントのデフォルトのアクションは、該当する規則がない場合に操作を許可(前の表の優先順位 9)することです。Cisco Security Agent リソースを変更しようとすると、例外が発生します。エージェントの自己保護のため、デフォルトでは、このような要求は拒否されます。


規則:アクション定義

アクセス制御規則を設定する場合は、その規則のアクションを選択する必要があります。次に、選択できるすべてのアクション タイプについて説明します。すべての規則にすべてのアクション タイプを使用できるわけではありません。

強制アクション

Priority Terminate Process :このアクション タイプを選択すると、他のすべての許可、終了、拒否、およびクエリー規則に優先する終了規則が作成されます。このアクションは、当該のリソースへのアプリケーション アクセスを拒否し、アプリケーション プロセスの終了も試行します。他の状況が同じであれば、高順位でない終了と許可規則が同じポリシー内で競合する場合は、許可が優先します。すべてのプロセスを安全に終了できないことに注意してください(たとえば、winlogon)。プロセスの終了が安全でない場合、アクションは拒否されますが、終了しません。

Priority Deny :このアクション タイプを選択すると、他のすべての許可、拒否、およびクエリー規則に優先する拒否規則が作成されます。たとえば、この高優先順位拒否と競合する許可規則を設定しても、高優先順位拒否が常に優先します。他の状況が同じであれば、高順位でない拒否と許可規則が同じポリシー内で競合する場合は、許可が優先します。

Priority Allow :このアクション タイプを選択すると、指定したアクションの実行を許可する規則が作成されます。どの規則でもデフォルトのアクションは「許可」なので、一般に、許可規則を設定するのは、ポリシー内で既存の拒否規則の例外を作成する場合のみです。

Query User (Default Terminate) :このアクション タイプを使用すると、指定したアクションの発生時に、ユーザにプロンプトが表示されます。ユーザは 5 分以内に、Yes、No、または Terminate で応答する必要があります。ユーザが他の応答をしない限り、デフォルトは拒否で、プロセスは終了します。詳細については、「Query User」を参照してください (Solaris 規則の場合、Query user オプションは利用できません)。

Query User (Default Deny) :このアクション タイプを使用すると、指定したアクションの発生時に、ユーザにプロンプトが表示されます。ユーザは 5 分以内に、Yes、No、または Terminate で応答する必要があります。ユーザが他の応答をしない限り、デフォルトは拒否です。詳細については、「Query User」を参照してください (Solaris 規則の場合、Query user オプションは利用できません)。

Query User (Default Allow) :このアクション タイプを使用すると、指定したアクションの発生時に、ユーザにプロンプトが表示されます。ユーザは 5 分以内に、Yes、No、または Terminate で応答する必要があります。ユーザが他の応答をしなければ、デフォルトで許可に設定されます。詳細については、「Query User」を参照してください (Solaris 規則の場合、Query user オプションは利用できません)。

Text used to query user :クエリー ユーザ規則を設定する場合は、クエリー設定も必要です。クエリー設定フィールドに入力するテキストは、システムで何が起こっているかをクライアントに説明するために、クエリー ユーザ ポップアップ ボックスに表示されるテキストになります。

Terminate Process :このアクションは、当該のリソースへのアプリケーション アクセスを拒否し、アプリケーション プロセスの終了も試行します。すべてのプロセスを安全に終了できないことに注意してください(たとえば、winlogon)。プロセスの終了が安全でない場合、アクションは拒否されますが、プロセスは終了しません。

Deny :このアクション タイプを選択すると、指定したアクションのシステム上での実行を停止する規則が作成されます (この規則で [Deny] を選択すると、ユーザが対象のアプリケーションを実行しようとしたときに、アプリケーションの実行が禁止されていることを説明するポップアップ ボックスが表示されます)。

検出アクション

同じリソースのトリガーを最初に規制する、優先順位の強制規則がある場合でも、検出規則は常にチェックされます。


) ダイナミック アプリケーション クラスの分類がプロセスに適用される前に、すべての規則が評価されます。その結果、アプリケーション クラス メンバシップが常に、1 つの要求で評価されるすべての規則に適用されます。


Monitor :ほとんどの規則タイプに「モニタ」アクションがあります。モニタ規則を作成することで、特定のリソースに関する許可規則または拒否規則を明示的に作成しなくても、そのリソース アクセスに対するイベントを作り出すことができます。また、リソースのアベイラビリティ(許可や拒否など)を指示している他の同様の規則がある場合に、モニタ規則を作成することもできます。たとえば、リソースのモニタ規則を作成でき、そのモニタ規則がトリガーされると、当該のリソースに関する後続の規則も同様にトリガーされます。その結果、リソース アクセス アクションが許可か拒否かにかかわらず、リソースについて一般アラートを設定できます。また、特定の強制アクション タイプの発生時にのみトリガーされるように、モニタ規則を設定できます。このように設定すると、モニタの対象は、たとえば「ファイル リソース上の拒否アクション」だけになります。詳細については、「Monitor アクション」を参照してください。

Set :規則で「Set」アクションを使用すると、システムで規則に設定された条件が発生したときに、特定の設定アクションが実行されます。「Set アクションの使用方法」を参照してください。

Notify User:選択すると、アクションが対象の規則をトリガーしたときにユーザに通知できます。ユーザはこの通知を確認し、対象のアクションの理由を入力します。[Notification Settings] 設定ウィンドウで、[OK] ボタンを選択するか、または [Yes] および [No] オプション ボタンの組み合わせを選択して、通知ポップアップ ウィンドウを追加します。

詳細については、「Log」および「通知設定」を参照してください。

Add process to application class :ダイナミック アプリケーション クラスを定義する場合に使用します。ダイナミック アプリケーション クラスは、特定のアプリケーションの実行可能ファイル名ではなくアプリケーションの動作に基づいて構築されます。リソースへのアクセスを指示するアクションがこの規則(つまり allow、deny、terminate)の任意のパラメータと一致すると、プロセスがダイナミック クラスに追加されます。詳細については、「規則の結果としてのクラス構築」を参照してください。

Remove process from application class :このアクション タイプは、ダイナミック アプリケーション タグをプロセスから削除する場合に選択します。リソースへのアクセスを指示するアクションがこの規則(つまり allow、deny、terminate)の任意のパラメータと一致すると、プロセスがダイナミック クラスから削除されます。詳細については、「規則の結果としてのクラス構築」を参照してください。


) システム上で実行されている場合、ダイナミックな分類はアプリケーション クラスの一部になります。プロセスの実行が中止すると CSA MC のアプリケーションの分類も終了します。プロセスが再開したとき、それが同じアプリケーション クラスに入るかどうかはプロセスの動作とアプリケーション クラスの定義によります。したがって、すべてのダイナミック アプリケーション クラスはエフェメラルであり、システムで常に再評価され分類されます。


設定するすべての規則で、その規則のデフォルト アクションは許可です。規則モジュールは、特定のアクションを拒否する規則を作成するまで、すべてのシステム アクションを許可します。このロジックによると、モジュール内に、またはモニタリングの目的で作成した拒否規則への例外を作成する場合以外、許可規則を作成することはあまりありません(「Monitor アクション」を参照)。許可規則を独立に作成したとしても、デフォルト アクションが「許可」なので、作成した許可規則は基本的に何の効果もありません。

モジュール内で規則を設定する場合、モデルとして好ましいのは、優先順位レベルを考慮して、優先順位の低いものから高いものへとボトムアップで作業を進める手法です。規則にパラメータが 1 つも追加されていなければ、デフォルトで、すべてのシステム アクションが許可されています。まず拒否規則を作成し、その特定の拒否に対して例外を作成する場合は、許可規則を作成します。次に、クエリー規則を使用して、ユーザがアクションの許可または拒否を決定できるアクセス制御を行うことを検討します。最後に、必要な高優先順位規則を作成します。

規則:優先順位の操作

CSA MC は、選択した「アクション」タイプを使用してポリシー内の規則の順位を決定する以外に、選択したロギング タイプを使用して、類似の規則について、ポリシー内での下位順位付けをします。ポリシー内の複数の規則でアクション タイプが同じであれば、ロギングが無効ロギングに優先します。したがって、たとえば許可という 1 つの優先順位の規則の中で、Log 規則が No Log 規則に優先します。

ほとんどのポリシーでは、この規則の順位および下位順位の自動決定に従って、ポリシーを組み合わせて展開します。しかし、CSA MC の順位付け方式が原因で、ポリシーが好ましくない動作をすることがあります。このため、ほとんどの規則タイプでは、チェックボックスを用意して、類似の規則タイプをポリシー内の下位順位にどのように順位付けるかを操作できるようになっています。このチェックボックスは、[Take precedence over other <similar action> rules] という名前で、規則設定ページにあります。この優先順位チェックボックスがオンになっている規則は、このチェックボックスがオフになっている類似の規則よりも先に評価されます。

同じポリシー内の 2 つの規則が、自動規則順位付けが原因で、予想とは異なる動作を行う例を次に示します。同じポリシー内に、次のような 2 つのネットワーク アクセス制御が存在するとします。

Log、Deny、All applications、acting as a server、
for TCP/1-65000

No Log、Deny、All applications、acting as a server、
for TCP/1900

TCP/1900 の接続に関する規則は拒否され、その規則にロギングを選択していないにもかかわらずロギングが行われます。これは、TCP/1-65000 の接続に関する規則がポリシー内で最初に評価され、TCP/1900 に関する規則にロギングを選択していなくても、その接続がイベント ログに送られるからです。

この例では、TCP/1900 の規則で [Take precedence over other <action> rules] チェックボックスをオンにすると、この規則の優先順位をポリシー内の他の拒否規則よりも高く設定できるとともに、アクションを拒否し、ポリシー内に他の規則があっても継続的通知を行わない場合に、そのアクションに対するログを抑制できます。


注意 [Take precedence over other <action> rules] チェックボックスは、頻繁には必要としない規則順位付けツールです。ほとんどの場合は、CSA MC による規則の自動順位付けで問題ありません。しかし、このチェックボックスを使用して規則の順位を操作した場合は、次の規則順位方式に従う必要があります。1 つのグループ内では、規則は次の基準でソートされます。
* アクション タイプ
* 優先順位チェックボックスのオン/オフ
* ログ チェックボックスのオン/オフ


) 1 つのポリシーに対して、同じアクション タイプ、同じロギング タイプ、および同じ「take precedence」タイプの規則が複数存在する場合、それらを区別して順位を決定する基準がないので、これらの規則がポリシー内でどのように順位付けられるかは予測できません。



) 監査モードおよびラーニング モードは、規則の優先順位には影響しません。たとえば、まったく同じ 2 つの規則があって、一方が監査モード、もう一方が別のモードという点だけが異なる場合、CSA MC がリストで規則に付ける順序によって、どちらの規則が先にトリガーされるかが指定されます。その順序は、管理者によって先に作成された規則が先にトリガーされるというように単純に決定されます。


Monitor アクション

ほとんどの規則タイプに「モニタ」アクションがあります。モニタ規則を作成することで、特定のリソースに関する許可規則または拒否規則を明示的に作成しなくても、そのリソース アクセスに対するイベントを作り出すことができます。また、リソースのアベイラビリティ(許可や拒否など)を指示している他の同様の規則がある場合に、モニタ規則を作成することもできます。たとえば、リソースのモニタ規則を作成でき、そのモニタ規則がトリガーされると、当該のリソースに関する後続の規則も同様にトリガーされます。その結果、リソース アクセス アクションが許可か拒否かにかかわらず、リソースについて一般アラートを設定できます。

また、特定の強制アクション タイプの発生時にのみトリガーされるように、モニタ規則を設定できます。このように設定すると、モニタの対象は、たとえば「ファイル リソース上の拒否アクション」だけになります。

Notify User アクション

さまざまな規則タイプを設定すると、アクションが規則をトリガーしたときにユーザに通知できます。このとき、ユーザは通知を確認する必要があります。また、通知ポップアップの中でアクションの理由を入力するようユーザに要求することもできます。[Notification Settings] 設定ウィンドウ(「通知設定」を参照)で [OK] ボタンを選択するか、または [Yes] と [No] のオプション ボタンの組み合わせを選択して、通知のポップアップ ウィンドウを追加します。

規則のアクション タイプとして [Notify User] を選択すると、[Notification Settings] プルダウン メニューが表示されます。規則の一部として、事前設定された [Notification Setting] のいずれかを選択する必要があります。[Notification Settings] 設定ページから [Notification Setting] を設定します。これは、[Configuration] > [Variables] メニューからアクセスできます。ここで、通知のテキストとボタンを設定します。これらのものは、エンド ユーザに表示されるポップアップの通知ボックスに示されます。また、ポップアップ ウィンドウに表示されるフリーフォーム テキストのジャスティフィケーションを設定することもできます。設定の詳細については、「通知設定」を参照してください。

さまざまなボタンおよび理由説明の編集フィールドがある通知ポップアップをユーザに表示することには、次の目的があります。

エンド ユーザに対して、企業のポリシーに反するアクションを実行しようとしていることを警告します。そのアクションを禁止するのではなく、単にユーザに通知し、アクションの理由説明を自由形式のテキストでポップアップに入力するよう要求します。このテキストは、MC イベント ログに表示されます。この場合は、通知の確認としてポップアップに [Yes] ボタンを表示します。

別の例として、ルートキットが原因でシステムが隔離されている場合に、ユーザに通知することがあります。この場合は、[OK] ボタンがある単純な通知ポップアップを表示し、隔離状態を示して、IT 部門に連絡するようユーザに求めます。

Set アクションの使用方法

Set(設定)とは、システムで規則に設定された条件がトリガーされるときに、1 回限りの特定の設定項目を実行する単一の設定アクションです。たとえば、「Set」が設定された規則がトリガーされると、セキュリティ レベルを低に設定するなど、特定のアクションが実行されます。これは、プロセスの追加および削除のタギングとは異なります。プロセスの追加および削除のタギングでは、プロセスの寿命の間、またはタグが削除されるまでは、タグがそのプロセスになります。Set では 1 回限りのアクションが実行されます。


) Set は、1 つの点でプロセスの追加および削除のタギングと似ています。Set をユーザ クエリー応答に基づいて実行するように設定できます。ただし、Set に対する有効なクエリー応答は「許可」だけです。接続が拒否された場合、マークを付ける対象がなかったことになります。



) 結果として Set アクションがグローバル システム状態を設定する場合もあります(Set Host Address as Untrusted)。また、Set アクションの出力がイベントを生成するだけの場合もあります(Set Rule Module protection)。


規則のアクション タイプとして [Set] を選択すると、[Attribute] プルダウン メニューと [Value] プルダウン メニューが表示されます。設定できるすべてのアトリビュートには対応する値があり、この値も設定する必要があります。規則には設定できるアトリビュートと値のペアがいくつかあります。


) すべての規則タイプにすべてのアトリビュートを使用できるわけではありません。たとえば、[Differentiated Service] オプションはネットワーク アクセス制御規則だけで使用できます。対象の規則タイプに適用可能なセット アトリビュートは、その規則に対して選択できるタイプだけになります。


この項の以降では、使用可能なアトリビュートと値のペアについて説明します。

アトリビュート:Current Application Virus Classification

set current application Virus Classification アトリビュートは、固定の動作ベースのアンチウイルス タグをアプリケーションに割り当てます。

current application Virus Classification アトリビュートを指定してから、次のいずれかの値を選択します。

Include no static tag

Include the Tag <Virus:Behavior.Excessive Policy Violation>

Include the Tag <Virus:Behavior.Malicious Activity>

Include the Tag <Virus:Behavior.Dangerous Activity>

Include the Tag <Virus:Behavior.Suspicious Activity>

Include the Tag <Virus:Behavior.Potential Unwanted Application>

アプリケーションが別なアプリケーションと対話して、特定の動作を試みた場合、さまざまな規則によって、動作ベースのアンチウイルス タグがそのアプリケーションに割り当てられることがあります。動作ベースのアンチウイルス タグは「スタティック」です。このタグは、アプリケーションに割り当てることができ、管理者はこのタグを設定できますが、その名前は変更できません。

同じタグ付け要件の 2 つの規則があり、一方の規則が「非スタティック タグ」を適用し、他方の規則が動作ベースのスタティック タグの 1 つを適用する場合、「非スタティック タグ」分類の規則が優先され、アプリケーションはスタティック タグを受け取りません。

これらのタグの使用方法、および動作ベースのアンチウイルスの動作については、「アンチウイルスの基礎」を参照してください。

アトリビュート:Custom-made state condition

この設定 アクションにより、カスタム システムの状態を企業の個々のニーズに合わせて定義することが可能になります。[Custom-made state condition] セット アトリビュートを指定したら、[Custom 1] から [Custom 10] のいずれかの値を選択します。

custom-made state conditions は、さまざまな規則タイプを使用して作成できます。このセット アトリビュートにより管理者は、さまざまな条件を使用してカスタム条件を定義できます。

カスタム条件のメリットは、ホストを High、Medium、または Low セキュリティ レベルのシステム状態にすることなく、リソースを保護することです。ユーザが自身のエージェントのセキュリティ レベルを変更しても、カスタム システム状態に基づいてセキュリティを強制している規則には何も影響しません。

ホストは、同時に複数のカスタム状態にはなれません。異なる規則で、異なるカスタム状態を定義しており、それらの規則がホストに対してトリガーされると、ホストは、最後にトリガーされたカスタム状態に移行します。ホストは、エージェントでシステム状態がリセットされるまで、そのカスタム状態のまま保持されます。CSA MC からエージェントをリセットする手順については、「Cisco Security Agent のリセット」を参照してください。[Host Details] ページの [Detailed status and diagnostics] リンクには、ホストのシステム状態が示されます。詳細は、「ホストのステータス」を参照してください。

カスタム状態を作成したら、そのカスタム状態を参照するシステム状態セットを作成する必要があります。また、スキャン データ タグやスタティック データ タグなどの追加の要素を含めるよう、システム状態セットを設定することもできます。リソースを保護するには、新しいシステム状態セットを指定する保護規則を作成する必要があります。

カスタム状態は、次の規則タイプによって定義できます。

エージェント サービス制御規則

アプリケーション制御規則

クリップボード アクセス制御

COM コンポーネント アクセス制御

接続率上限

データ アクセス制御

ファイル アクセス制御

ファイル バージョン制御

カーネル保護

ネットワーク アクセス制御

ネットワーク インターフェイス制御

ネットワーク シールド

プリンタ アクセス制御

レジストリ アクセス制御

ルートキット/カーネル保護

スキャン イベント ログ

システム API 制御

アトリビュート:Data Payload trust status

値:Data Payload trust status アトリビュートを指定してから、次のいずれかの値を選択します。

unchanged for any protocol

unchanged if MSRPC

unchanged if LPC

untrusted if MSRPC (locally and globally)

untrusted if MSRPC (locally)

untrusted if LPC (locally and globally)

untrusted if LPC (locally)

untrusted for any protocol (locally and globally)

untrusted for any protocol (local)

Data Payload trust status を Untrusted に設定する規則を使用して、特定のタイプのアクションが規則によって検出された場合に、システムでシグニチャを作成するよう設定します。この検出が発生すると、エージェントによってペイロードが取得され、シグニチャの生成が試行されます。グローバル設定が含まれている規則によってシグニチャが生成された場合は、グローバルに配布するために、エージェントが MC へシグニチャを送信します。グローバル シグニチャに基づいて制限を強制する規則を持つエージェントは、新しく作成されたシグニチャを受け取り、特定の攻撃に対して保護されます。

ローカルとグローバルについて

データ ペイロードが変更されていない、または信頼できないとしてローカルで分類されると、生成されたシグニチャは一時的に(1 時間)、ローカル マシンの @signatures または @highrisk_signature リストに追加されます。また、変更されていない、あるいは信頼できないグローバル アトリビュートが使用された場合は、生成されたシグニチャをグローバル イベントの相関の候補にするためにイベントが CSA MC へ送信されます。そのシグニチャの相関が中央でとられる場合、設定されたイベント相関しきい値に達すると、このシグニチャは類似したすべてのホストのグローバル シグニチャ リストに追加されます。

アトリビュート:Data scan on CLOSE

Data scan on CLOSE アトリビュートを指定してから、次のいずれかの値を選択します。

being required for this file

NOT being required for this file

Data scan on CLOSE アトリビュートは、ファイル アクセス制御(FACL)規則で使用できます。

ある FACL で data scan on CLOSE が必要な場合、CSA はファイルを閉じるときに、ファイルの内容とスキャン データ タグのパターンを比較します (これらのタグ、およびタグの定義は [Configuration] メニューで [Global Settings] > [Scanning Data Tags] に移動して検索できます)。ファイルの内容が、スキャン データ タグのパターンと一致する場合、ファイルにタグが付けられます。1 つのファイルに複数のスキャン データ タグを付けられます (これらのタイプのタグの詳細については、「スキャン データ タグとスタティック データ タグ」を参照してください)。

FACL でデータ スキャンが必要ない場合、データ スキャンは発生しません。


) あるファイルに、スキャンが必要と不要の両方のマークが付けられている場合、スキャンは実行されません。


アトリビュート:Data scan on OPEN

Data scan on OPEN アトリビュートを指定してから、次のいずれかの値を選択します。

being required for this file

NOT being required for this file

Data scan on OPEN アトリビュートは、ファイル アクセス制御(FACL)規則で使用できます。

ある FACL で data scan on OPEN が必要な場合、CSA はファイルを開くときに、ファイルの内容とスキャン データ タグで定義されているパターンを比較します (これらのタグ、およびタグの定義は [Configuration] メニューで [Global Settings] > [Scanning Data Tags] に移動して検索できます)。ファイルの内容が、スキャン データ タグのパターンと一致する場合、ファイルにタグが付けられます。1 つのファイルに複数のスキャン データ タグを付けられます (これらのタイプのタグの詳細については、「スキャン データ タグとスタティック データ タグ」を参照してください)。

FACL でデータ スキャンが必要ない場合、データ スキャンは発生しません。


) あるファイルに、スキャンが必要と不要の両方のマークが付けられている場合、スキャンは実行されません。


アトリビュート:detected access

:Protected、Unprotected

これは、アプリケーション、サービス、または Unprotected のマークが付けられたその他のシステム コンポーネントが、対応する Protected 規則を持っておらず、エージェントによって保護されていない場合に、(イベント ログによる)通知と、オプションで(システム状態による)アクションの実行を行うためのアトリビュートです。

これを保護監査ツールとして使用するには、保護しているリソースに対して「Set-detected access-Protected」が設定された規則をポリシーに含めます。この規則によって、リソースがエージェントの保護対象としてマーク付けされます。

続いて、特定のリソースがシステムで保護されていることを確認する場合、対象のリソースに対して「Set-detected access-Unprotected」規則を設定し、その規則を、たとえば <All OS type> グループに関連付けられたポリシーに含めます。このように、システムで保護の必要なリソースがアクセスされ、そのリソースに対応する「Set-detected access-Protected」規則がなく、「Set-detected access-Unprotected」規則が存在する場合、リソースが保護されないことを通知するメッセージがイベント ログに送信されます。

たとえば、この機能を使用すると、Web サーバを実行するホストが適切に保護されていることを確認できます。この確認を行うには、任意のアプリケーションが TCP/80 用サーバとして動作するときに「Set-detected access-Unprotected」を示す All Windows グループに設定規則を作成します。また、Microsoft IIS が TCP/80 への接続を受け取るときに「Set-detected access-Protected」に指定された Microsoft IIS Web Server モジュールに別の規則を追加します (Apache の場合も同様の規則を対応するモジュールに追加します)。両方のポリシーが関連付けられた IIS Web Server を実行するホストは保護条件を満たしますが、イベントはログに記録されません。保護要件(Unprotected)を指定するポリシーが設定されたホストに、対応する保護が提供されない場合(Protected)、ポリシーのミスマッチが発生し、その結果、イベントが生成されます。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。

アトリビュート :detected boot

:Insecure、Secure

これは、前のシステム ブートが標準外の方法で実行された場合を検出するためのアトリビュートです。たとえば、システムをハード ドライブではなく周辺装置(CD ROM)からブートした場合です。このタイプのブートは標準外と見なすことができ、場合によっては疑わしい可能性があります (これはトロイの木馬をシステムに取り込む 1 つの方法です)。このタイプの周辺装置によるセキュアでないブートの検出は、対応するシステムの特定タイプの互換 BIOS と連動します。互換 BIOS は標準外のブートを検出して、次回の標準のブート時にカーネル保護規則(「カーネル保護」を参照)が適切に設定されていれば、メッセージが MC に送信され、MC はこのセキュアでないブートの検出をログに記録します。次に、これによってシステム状態(設定済みの場合)がトリガーされます。セーフ モードによるブートも、このセキュアでないブートのカテゴリに入ります。互換 BIOS は、セーフ モード ブートの検出には必要ありません。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。

アトリビュート :detected rootkit trust status

detected rootkit trust status アトリビュートを指定してから、次のいずれかの値を選択します。

Unchanged

Untrusted

このセット アトリビュートは、ネットワーク アクセス制御、カーネル保護、システム API 制御、バッファ オーバーフロー、およびルートキット/カーネル保護の各規則で使用できます。

ルートキットは、モジュールが起動後にロードする場合、またはモジュールがカーネル機能の修正を試みる場合に検出される可能性があります。

このセット アトリビュートで NACL を使用すると、次のいずれかの状況のルートキットを検出できます。

アプリケーションが、既知のトロイの木馬またはルートキット ポートを待ち受けているのではないかと疑われる場合。

一連の他のアクションに関連付けられたネットワーク アクションが、ルートキットを示している場合。たとえば、アプリケーションがキーボードを「フック」してから、Security Account Manager の読み取り開始し、ネットワークにアクセスしようとした場合は、ルートキットを示していることがあります。

CSA が悪意のある動作を検出し、規則がオブジェクトに「untrusted」のタグを付けた場合、ルートキットは「untrusted」として指定されます。ルートキットなどの実行ファイルの動作を認識しており、それが良性な場合は、Set を使用して、検出されたルートキットの信頼ステータスを「unchanged」にできます。ルートキットの信頼ステータス「unchanged」は、ルートキットの信頼ステータス「untrusted」よりも優先されます。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。

アトリビュート :Differentiated Service(Trusted QoS

:priority Best Effort (0,0)、priority Scavenger (8, CS1)、application specified、IP routing (48, CS6)、Voice (46, EF)、Interactive Video (34, AF41)、Streaming Video (32, CS4)、Mission Critical Data (26, AF31)、Call Signaling (24, CS3)、Transactional Data (18, AF21)、Network Management (16, CS2)、Bulk Data (10, AF11)、Best Effort (0,0)、Scavenger (8, CS1)

特定のトラフィック フローに Differentiated Service を指定するには、IP パケット内で認識可能な値である QoS マーキングを設定します。この操作により、ルータおよびスイッチが QoS マークの付いたトラフィックを識別してアクションを実行できるため、よりきめ細かくトラフィックの転送を制御できるようになります。

使用可能なマーキングでは、Differentiated Services Code Point(DSCP)設定および Per Hop Behavior(PHB)設定を提供します。DSCP 値は IP ヘッダーのサービス フィールドと一致します。PHB 値は、ルータおよびスイッチがホップバイホップ ベースでトラフィックを処理する方法と一致します。これらの値は、各値オプション横のカッコ内に、(DSCP,PHB) の順で表示されます。


) ネットワーク アクセス制御規則を使用して、IPv6 のネットワーク トラフィックに [Differentiated Services (Trusted QoS)] タグのマークを付けることはできません。



) ここでは提供される値マーキングをすべて説明しませんが、デフォルトでアプリケーションは Best Effort 値が指定されて転送されることに注意してください。提供される Scavenger 値は Best Effort よりも低くなります。特定タイプのトラフィック フローを大幅にダウングレードするには Scavenger マーキングを使用します。priority Best Effort 値および priority Scavenger 値を指定すると、複数のマーキング タイプが使用されている可能性のある複数の規則に優先順位を設定できます。


CSA ディファレンシエーテッド サービス機能に関する重要な詳細事項

QoS マーキングを設定するエージェントに規則がない場合、すべてのシステムの一般的なデフォルトとして、トラフィック フローは「application specified」としてマークが付けられます。QoS マーキングを設定するエージェントに規則がある場合、エージェントはそれに応じて DSCP マーキングを選択および設定します。エージェント上で Differentiated Service 規則が競合する場合(つまり、トラフィック フローに適用可能な Differentiated Service 設定規則が複数ある場合)、エージェントは順位の最も高いマーキングを選択して設定します (マーキングの優先順位は、使用可能なプルダウン リストの上から下の順になります)。

エージェントは、送信するパケットにマークを付けているだけです。エージェントは、受け取るパケットにはマークを付けることができません。これらのパケットにマークを適切に付けるのは、リモート ホストの役割です。

セキュリティ スライドバーを使用してエージェントをディセーブル、停止、またはオフにすると、既存セッションの QoS はエージェントによって設定されなくなります。エージェントは既存フローのマーキングを停止します。その後で既存フローは「application specified」に戻されます。エージェントが再びイネーブルになると、許可フローはエージェントによって設定された以前のマーキングを再開します。エージェントのディセーブル中に新しいセッションが作成された場合、新しいフローはエージェントが復帰するタイミングを妨げません。そのフローには、application specified のマークが付いた一般的なシステム デフォルトの許可が自動設定され、接続されている間はそのマーキングが保持されます。

許可は、接続の開始時にだけ行うことに注意してください。

ディファレンシエーテッド サービスの一般情報については、RFC 2475 を参照してください。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。たとえば、ネットワークが攻撃を受けた場合(つまり「virus detected」)、すべてのトラフィック フローをダウングレードする規則をトリガーするようにシステム状態を設定できます。

アトリビュート:Digital signature check

Digital signature check を指定した後で、次のいずれかの値を選択します。

being required for this file

NOT being required for this file

Digital signature check アトリビュートは、ファイル アクセス制御(FACL)規則で使用できます。

ある FACL でデジタル署名のチェックが必要な場合、CSA はファイルからデジタル署名を抽出し、それを確認します。この設定アクションは、このリリースで配布される Base - Digital Signatures for Downloaded Executables 規則モジュールの 1 つの FACL で使用されます。この実装では、信頼されていない実行可能ファイルのデジタル署名チェックが必要です。

FACL でデジタル署名のチェックが必要ない場合、デジタル署名チェックは実行されません。


) あるファイルで、デジタル署名チェックが必要と不要の両方のマークが付けられている場合、デジタル署名チェックは実行されません。


アトリビュート:Discovery of other CSA nodes

:Disabled、Enabled

このセット アトリビュートを使用できる規則タイプは、バッファ オーバーフロー、接続率上限、データ アクセス制御、ネットワーク アクセス制御、ネットワーク シールド、およびシステム API です。このアトリビュートは、ホスト IP アドレスにアクティブな Cisco Security Agent が関連付けられているかどうかを判別するためのものです。関連付けられている場合は、アクティブなエージェント システムのリストが保持されます。また、このリストをクッキー(@csanode)を介して規則で使用すると、アクティブなエージェントの存在に基づいて、通信とリソースのアベイラビリティを制限または許可することができます。たとえば、システムでエージェントが検出された場合に、当該のシステムが「n」システムと通信できるようにします。この設定規則タイプを使用すると、CSA ノード検出を接続ごとにイネーブルまたはディセーブルにすることができます。

アトリビュート:file Data Classification

値:Static data tags

このセット アトリビュートは、ファイル アクセス制御(FACL)保護規則で使用できます。このアトリビュートを使用すると、ファイルの内容をスキャンせずに、ファイルにスタティック データ タグを付けられます。

file Data Classification アトリビュートを指定し、値リストからスタティック データ タグを選択します。CSA のこのリリースではスタティック データ タグが配布されており、設定および使用できます。これらのタイプのタグの詳細については、「スキャン データ タグとスタティック データ タグ」を参照してください。

スタティック データ タグの名前は変更できず、新しいスタティック データ タグを作成することもできません。スタティック データ タグは、ファイルへのアクセスを試みるアプリケーションのグループに基づいて、ファイルに割り当てられます。企業のニーズに基づいて、スタティック データ タグのパラメータを定義してください。このタギング方法は、専用アプリケーションがある場合などに役立つことがあります。たとえば、専用アプリケーションを読み込むファイルが <HIPAA Controlled> ファイルと見なされることが、事前にわかっている場合などです。

アトリビュート:File deletion

File deletion アトリビュートを指定してから、次のいずれかの値を選択します。

being required for this file

NOT being required for this file

File deletion アトリビュートは、スキャン イベント ログ規則で使用できます。

このアトリビュートでは、セキュリティ エージェントによる削除用のスキャン データ タグ、スタティック データ タグ、またはウイルス スキャン タグのマークをファイルに付けられます。

あるファイルで、削除が必要と不要の両方のマークが付けられている場合、削除は実行されません。

アトリビュート:file trust status

file trust status アトリビュートを指定してから、次のいずれかの値を選択します。

Unchanged

Trusted

Untrusted (until CSA AV Scan)

Untrusted

Untrusted (temporary)

この値リストは階層的になっています。同じアクションに適用される 2 つの類似した規則があり、1 つの規則はファイルに Trusted とタグ付けし、もう 1 つ規則は同じファイルに Untrusted (until CSA AV Scan) とタグ付けした場合は、Trusted タグに適用される規則が最初にトリガーされ、そのタグが適用されます。Untrusted (until CSA AV Scan) に適用される第 2 の規則はトリガーされません。

このセット アトリビュートは、ファイル アクセス制御(FACL)保護規則で使用できます。

Unchanged

このファイル信頼ステータスを使用すると、既存のファイル信頼ステータスが変更されず、そのままになります。これにより、たとえばバックアップ ツールなどのネットワーク アプリケーションがファイルを開いたために、ファイルの信頼レベルが変更されることを防止できます。

Trusted

ファイルが「Trusted」に指定されると、そのファイルは、ホストでローカルに保持されている Untrusted ファイルのデータベースから削除されます。ファイルには Trusted タグが付けられず、Untrusted タグが外されます。

file trust status アトリビュートを使用して Trusted に変更できるのは、Untrusted として動的にタグ付けされたファイルだけです。Untrusted としてポリシーで静的に定義されているファイルは、Trusted として指定できません。

Untrusted (until CSA AV scan)

「Untrusted (until CSA AV scan)」は、「Untrusted」の分類の一種です。規則がトリガーされると、ファイルはシステムに保持されている間は Untrusted として扱われます。ファイルが 90 日以上システム上に保持され、CSA AV がファイルをスキャンして、そのファイルがウイルスに感染していないと判断した場合、ファイルから Untrusted (until CSA AV scan) タグが外され、Trusted として扱われるようになります。

Untrusted (until CSA AV scan) タグは、通常の Untrusted タグよりも優先されます。

Untrusted

「Untrusted」file trust status アトリビュートを使用して、ファイルに Untrusted タグを永続的に付けます。

規則のトリガーによって、ファイルが Untrusted と動的にタグ付けされると、ホストでローカルに保持されている Untrusted ファイルのデータベースに、そのファイル名が追加されます。

Untrusted とマークされ、実行しようとしたアプリケーションは、ローカル エージェントの [Untrusted Applications] ウィンドウに表示されます。これらのアプリケーションは、組み込みアプリケーションクラス <*Processes Executing Untrusted Content>(「組み込みのアプリケーション クラス」を参照)にも自動的に追加されます。追加された組み込みアプリケーション クラスは、規則の中で使用できます。

Untrusted (temporary)

「Untrusted (temporary)」は「Untrusted」の分類の一種です。ダウンロードしたネットワーク アプリケーションのファイル拡張子が認識されないものである場合は、そのアプリケーションは 60 秒間 Untrusted として扱われます。60 秒以内にそのネットワーク アプリケーションを実行すると、Untrusted タグが付けられます。そのファイルを実行しなかった場合、ファイルは Untrusted (temporary) タグが外され、Trusted として扱われます。

他のすべてのセットの file trust status アトリビュートは、Untrusted (temporary) タグよりも優先されます。

アトリビュート :Host address trust status

Host address trust status アトリビュートを指定してから、次のいずれかの値を選択します。

Unchanged

Untrusted (locally)

Untrusted (locally and globally)

この値リストは階層的になっています。同じアクションに適用される 2 つの類似した規則があり、1 つの規則はファイルに Unchanged とタグ付けし、もう 1 つ規則は同じファイルに Untrusted (locally) とタグ付けした場合は、Unchanged タグに適用される規則が最初にトリガーされ、そのタグが適用されます。Untrusted (locally) に適用される第 2 の規則はトリガーされません。

この Host address アトリビュートは、ホストの IP アドレスがセキュリティ ポリシーに違反するか、または悪意ある動作を示す場合に、信頼できないものとしてマークを付けるためのアトリビュートです。untrusted host (locally) として分類されると、ホストは一時的に(1 時間)ローカル マシンの @dynamic リストに追加されます。また、信頼できないグローバル アトリビュートが使用されると、そのホスト アドレスをグローバル イベント相関の候補にするためにイベントが CSA MC に送信されます。このアドレスの相関が中央でとられる場合、(設定されたイベント相関しきい値に到達すると)アドレスは永続的にすべてのホストのグローバル隔離リストに追加されます。


ヒント 継続的に外部ホストがアクセスする外部 Web サーバに、ローカルの untrusted 値を使用できます。その結果、悪意があると思われるホストは内部ネットワーク全体でグローバルに隔離されませんが、Web サーバとの通信が一時的に阻止されます。


あるホスト アドレスが、ローカルまたはグローバルに Untrusted とタグ付けされないようにする場合には、特定の環境下で、その環境に対してアトリビュートを「Unchanged」に設定するような規則を作成し、その規則を他の類似規則よりも優先します。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。

アトリビュート :Security level

:High、Medium、Low

Security Level アトリビュートを設定すると、システムの現在の実行状態に基づいてエージェントのセキュリティ レベルをプログラムで変更できます。たとえば、エージェントのセキュリティ レベルが低のときにシステムでウイルスが検出された場合、このプロセスは状態が高に設定されたときに自動的に適用されるシステム状態のポリシーをトリガーできます。高に設定すると、ウイルスに感染したシステムによる発信ネットワーク接続を拒否する規則を実行する場合があります。

このタイプの対応する設定規則がトリガーされると適用される、システム状態を設定できます。「System State Sets」を参照してください。

アトリビュート:Stack

値:recovery

Set Stack Recovery アクションを使用する場合は、処理できない例外が発生したときに、システムでスタックを安全な場所へ復元して戻すように設定します。スタックの復元は、不可欠なサービスだけを対象にしています。不可欠でないサービスは、失敗してもかまわないことがあります。

アトリビュート:Sensitive Data Scan

値:being required for this file、NOT being required for this file

ファイルには、機密データのスキャンが必要または不要とマークされることがあります。

アトリビュート:Timer to restore Security

Timer to restore security アトリビュートを指定してから、時間の値を選択するか、またはセキュリティのリストアは NOT being required であることを指定します。

時間の値は、CSA のセキュリティが「オフ」に設定されてから、または「net stop csagent」が実行されてから、どのくらいの時間で CSA のセキュリティが自動的に戻るか、を示しています。

Timer to restore security アトリビュートは、エージェント サービス制御規則で使用できます。

あるホストが、セキュリティの復元に対して異なる時間の値を持つ複数のエージェント サービス制御規則によって影響され、これらの値の 1 つが NOT being required の場合は、NOT being required であるセキュリティの復元が他のすべての時間設定よりも優先されます。この場合、CSA は自動的に再起動されません。

さまざまなエージェント サービス制御規則で指定されている、複数の必要な時間設定があり、セキュリティの復元が NOT being required であると指定している規則がない場合は、セキュリティを再開するのに必要な最も短時間の設定が他の設定よりも優先されます。


) このセット アトリビュートは Solaris エージェントで使用できません。


アトリビュート:Virus scan

Virus scan アトリビュートを指定してから、次のいずれかの値を選択します。

being required for new application

NOT being required for new application

このセット アトリビュートはアプリケーション制御規則で使用できます。

ウイルスのスキャンが必要な場合、このセット アトリビュートを使用しているアプリケーション制御規則では、アプリケーション クラスのアプリケーションが他のアプリケーション クラスのアプリケーションを実行しようとしたときに、CSA が(Clam AntiVirus を使用して)ウイルス スキャンを実行します。

ウイルス スキャンが必要ない場合、ウイルス スキャンは実行されません。あるファイルが、ウイルス スキャンを必要としない規則、およびウイルス スキャンを必要とする規則によって影響される場合、ウイルス スキャンは実行されません。

CSA が、このセット アトリビュートを持つホストでアプリケーション制御規則を検出すると、エージェントのインターフェイスで、ユーザが [AntiVirus] ウィンドウを使用できるようになります。エージェント インターフェイスの [AntiVirus] 画面の説明については、「アンチウイルスによる保護」を参照してください。

アトリビュート:Virus scan on CLOSE

Virus scan on CLOSE アトリビュートを指定してから、次のいずれかの値を選択します。

being required for this file

NOT being required for this file

Virus scan on CLOSE アトリビュートは、ファイル アクセス制御(FACL)規則で使用できます。

ウイルスのスキャンが必要な場合、このセット アトリビュートを使用している FACL では、アプリケーションがファイルに書き込みしようとしたとき、またはアプリケーションがディレクトリを作成、名前変更、削除しようとしたときに、CSA が(Clam AntiVirus を使用して)ウイルス スキャンを実行します。ユーザがファイルを閉じるときにウイルス スキャンが実行されます。ファイルがウイルスに感染した場合、そのファイルが修正されるとすぐに感染が検出されます。

ウイルス スキャンが必要ない場合、スキャンは実行されません。あるファイルが、ウイルス スキャンを必要としない規則、およびウイルス スキャンを必要とする規則によって影響される場合、ウイルス スキャンは実行されません。


) CSA が、このセット アトリビュートを持つホストで FACL を検出すると、エージェントのインターフェイスで、ユーザが [AntiVirus] ウィンドウを使用できるようになります。エージェント インターフェイスの [AntiVirus] 画面の説明については、「アンチウイルスによる保護」を参照してください。


アトリビュート:Virus scan on OPEN

Virus scan on OPEN アトリビュートを指定してから、次の値のいずれかを選択します。

being required for this file

NOT being required for this file

Virus scan on OPEN アトリビュートは、ファイル アクセス制御(FACL)規則で使用できます。

ウイルスのスキャンが必要な場合、このセット アトリビュートを使用している FACL では、アプリケーション クラスのアプリケーションがファイルに読み込みまたは書き込みしようとしたとき、あるいいはアプリケーション クラスのアプリケーションがディレクトリを作成、名前変更、削除しようとしたときに、CSA が(Clam AntiVirus を使用して)ウイルス スキャンを実行します。ファイルを開くときにウイルス スキャンが実行されます。

ウイルス スキャンが必要ない場合、スキャンは実行されません。あるファイルが、ウイルス スキャンを必要としない規則、およびウイルス スキャンを必要とする規則によって影響される場合、ウイルス スキャンは実行されません。


) CSA が、このセット アトリビュートを持つホストで FACL を検出すると、エージェントのインターフェイスで、ユーザが [AntiVirus] ウィンドウを使用できるようになります。エージェント インターフェイスの [AntiVirus] 画面の説明については、「アンチウイルスによる保護」を参照してください。


ユーザに対するクエリー

アクセス制御規則を作成する場合、単に特定のアクションを許可または拒否するだけでなく、アクションがその規則をトリガーしたとき、ユーザに対してクエリーが実行されるように選択できます。この操作を行うと、ユーザがその時点で、アクションを許可するか、拒否するか、またはプロセスを終了するかを決定できるようになります。ユーザに対してクエリーが実行されるように選択する場合は、ユーザに表示する説明テキストも作成し、5 分以内にクエリーに対する応答がない場合のデフォルトとして、アクションを許可するか、拒否するか、または終了するかを指定します。ユーザがシステムにログインしていない場合は、デフォルトのアクションがすぐに実行されます。

クエリー設定は、ポップアップ クエリー ボックスにどのオプション ボタンを表示するか、どのアクションをデフォルトにするか、ユーザが提供した回答を記憶するか、および、表示するクエリー テキストを何にするかを決定できる変数設定です。

クエリー設定の場合、クエリーへの応答はリソースではなく質問と関連しています。たとえば、ファイル アクセス制御規則が応答に対してユーザを照会し、同じクエリーがネットワーク アクセス制御規則にも設定されている場合、ネットワーク アクセス制御規則の起動時にユーザは再び照会されません。前のファイル アクセス制御規則からのクエリー応答が自動的に採用されます。

詳細については、「クエリー設定」を参照してください。


注意 Solaris 規則では、MC 上でクエリー ユーザ アクションを選択できますが、クエリー ポップアップは Solaris エージェント ホスト システムに表示されません。代わりに、Solaris システムでクエリー ユーザ規則を設定していて、その規則がトリガーされると、デフォルトのアクションがシステムですぐに実行されます。
Windows エージェントおよび Linux エージェントでは、管理者がエージェント設定(ユーザ クエリーを含む)を設定できます。グループのエージェント UI が非表示である場合、クエリー ユーザ ポップアップ ボックスは表示されません。割り当てられたポリシーに含まれるすべてのクエリー ユーザ規則とヒューリスティックに対して、すぐにデフォルトのアクションが実行されます。

クエリー ユーザ規則がトリガーされるシステムに対してアクションを試みると、リソースのあるシステム上にポップアップ ボックスが表示されます。

図 5-8 ユーザへのクエリー ポップアップ ボックス

[Query Settings] ページから [Configuration] > [Variables] メニューを選択して、エンド ユーザに表示されるポップアップ ボックスに現れるクエリー テキストとクエリー オプション ボタンを設定します。クエリー ポップアップ ボックスで、ユーザは試みられるアクションについての情報を読み、次のいずれかを選択してクリックします。

[Yes]:当該のリソースへのアプリケーション アクセスを許可します。

[No]:当該のリソースへのアプリケーション アクセスを拒否します。

[No, Terminate this application]:当該のリソースへのアプリケーション アクセスを拒否し、アプリケーション プロセスの終了も試行します。該当アプリケーションの名前が終了オプションとともに表示されます (winlogon など、一部のプロセスは安全に終了できません)。

[Default Action]:クエリー ポップアップに表示されるオプション ボタンの 1 つをデフォルト アクションとして選択します。ユーザが 5 分以内にクエリーに応答しない場合、またはユーザがシステムにログインしていない場合は、デフォルトのアクションがすぐに実行されます。

[Logged query responses]:クエリー ポップアップでユーザが使用できるクエリー アクション(Allow、Deny、Terminate)を決定するほかに、ユーザによって特定のクエリー アクションが選択された場合だけ、クエリー応答をログに記録するように設定できます。[Logged query responses] セクションのマルチセレクト ボックスを使用して、ログ メッセージを作成する 1 つまたは複数の応答タイプを選択できます。たとえば、クエリーですべてのクエリー アクションが使用できる場合、Terminate 応答の場合だけログ メッセージが作成されるように設定できます (デフォルトではすべてのクエリー応答がログに記録されます)。

[Don't ask me again]:ユーザのクエリー応答を記憶するため、クエリー ボックスに表示されるボタンに加えて、[Don't ask me again] チェックボックスを表示することもできます。ユーザがクエリーに応答する際にそのチェックボックスをオンにすると、同じクエリーがトリガーされたときに、記憶された応答が自動的に表示され、ユーザは再び質問されることはありません。

[Query challenge]:セキュリティを強化するため、クエリー ポップアップ ボックスでクエリー チャレンジを発行できます。ユーザがデフォルトの回答を選択せず、選択された回答がデフォルトよりも弱い場合、チャレンジが表示されます。ここで、システムの前に座っているユーザが、応答を試みている悪意のあるリモート ユーザまたはプログラムではなく、クエリーに回答していることが確認されます。チャレンジに成功するには、ユーザはグラフィックで表示された情報をポップアップ ボックスに入力します (「クエリー設定」を参照)。

規則のクエリーを設定すると、[Query Setting] ページの [Text used to query user] フィールドに入力したテキストが、システムの状況をユーザに説明するクエリー ユーザ ポップアップ ボックスに表示されます。したがって、この情報では、ポップアップをトリガーしたシステム アクションをわかりやすく説明することが大切です。


注意 ファイル アクセス制御規則では、クエリー ユーザ ポップアップ ボックスが、対象の 1 つまたは複数のファイルが存在するシステムに表示されます。リモートにアクセスが制限されているファイルにユーザがアクセスを試みると、ポップアップ ボックスは、ユーザのマシンではなく、ファイルがあるリモート マシンに表示されます。この場合、無人システムに保存されたファイルに対して、「クエリー ユーザ」ファイル アクセス制限を設定しないでください。

[Requesting User Justification]:ユーザに問い合わせるだけでなく、ポップアップ ウィンドウの編集フィールドに確認文を入力するように要求できます。この自由形式の確認テキストは、エンド ユーザが入力し、MC のイベント ログ メッセージに表示されます。ユーザはこのフィールドを使用して、リソースがアクセスされた理由、またはアクションが実行された理由を説明できます。

応答のキャッシング

ユーザに対するクエリーで、エージェントは応答を永続的または一時的に記憶できます。この処理によって、同じ規則が再度トリガーされると、永続的または一時的に、以前のユーザの応答に基づいて許可、拒否、または終了が選択され、ポップアップ クエリー ボックスは表示されなくなります。

たとえば、アプリケーションがネットワーク上で通信できるかどうかについてのクエリーで、ユーザが [Yes] オプション ボタンを選択して [Don't ask again] チェックボックスをオンにした場合、[Yes] の応答は永続的に記憶され、その応答がエージェント UI クエリー応答ウィンドウの編集フィールドに表示されます。一方、setup.exe がシステム上でソフトウェアをインストールできるかどうかについてのクエリーで、ユーザが [Yes] オプション ボタンを選択したときに、[Don't ask again] チェックボックスがないか、あってもユーザがそれをオンにしなかった場合、この応答は一時的に記憶され、エージェント UI クエリー応答ウィンドウには表示されません。

ユーザの応答が一時的(約 1 時間)にキャッシュされただけの場合、ユーザはこのウィンドウで [Clear] ボタンをクリックして、一時的にキャッシュされた応答をすべて削除することができます。編集フィールドにリストされた永続的な応答をクリアするには、編集フィールドで応答を選択して [Delete] キーを押す必要があります。

クエリー キャッシングに関する注

永続的な応答は、再起動後も記憶されたままになります。

一時的にキャッシュされた応答は、再起動後に失われます。

クエリー応答が一時的に 1 時間キャッシュされるとき、その 1 時間の間にキャッシュされた応答が後続の規則の要求で使用されると、ウィンドウは 1 時間延長されます。

クエリー応答は、応答したユーザに関係付けられます。マルチユーザ マシンでは、複数のユーザが同じ質問をされる場合があります。

クエリー規則の優先順位情報

評価を必要とする類似のクエリー規則が複数ある場合に CSA MC が規則の優先順位をどのように管理するかに注意してください。

基本の優先順位:アクション =Allow、Deny Terminate/no challenge/no don't ask again/no logging。

オンになるクエリー オプションの関連優先順位は次のとおりです(上から下)。

Challenge/Don't ask again/Logging

Challenge/Don't ask again

Challenge/Log

Don't ask again/Log

Don't ask again

Log

Rule Overrides

監査モードおよびラーニング モードは、CSA のパイロットまたは CSA の最初の展開のときに役に立つツールです。

監査モードの使用方法

監査モードは、新しいホストのインストール後や、ホストの設定の変更後に、実際のホストのオペレーションに影響を与えずにその結果を確認する必要がある場合に便利です。監査モードで動作しているときは、関連付けられた規則が拒否を指示する場合でも、エージェントはアクションや操作を一切拒否しません。エージェントはその代わりにアクションを許可し、拒否またはクエリー規則がトリガーされたときに、イベントをロギングし(その規則でロギングがイネーブルの場合)、ロギングがイネーブルの許可規則がトリガーされたときも、イベントをロギングします。したがって、ポリシーを有効にする前に、ホストにポリシーまたは規則モジュールを展開することによる影響を認識できます。ログを検査してポリシーまたは規則モジュールがグループに対して意図したとおりに機能することがわかれば、監査モードの指定を解除できます。

グループ監査モードを使用するときには([Rule Overrides] エリアから使用可能)、詳細ロギング(Verbose logging)モードをイネーブルにすることもできます。エージェントは通常、同じログ メッセージが複数届いたときに一部を非表示にしますが、詳細ロギング モードでは、ログ メッセージが一切、非表示にされません。

監査モードで動作しているエージェントがイベントを CSA MC に送信すると、イベント ログ メッセージの前に、「Audit」という語が表示されます。これには、いくつかの例外があります。たとえば、ポート スキャンや形式誤りのパケットなどの検出イベントに関するイベント ログ メッセージの前には、「Audit」という語が表示されません。イベント ログ内の(予防ではなく)イベント検出メッセージは、監査モードのオン/オフと関係なく同じメッセージが表示されます。

グループの監査モード

グループ レベルで監査モードをイネーブルにする場合は、監査モード グループ内のすべての規則が監査モードになります。

ホストが所属するグループで監査モードが選択されている場合、(同じホストが、監査モードが選択されていない別のグループに同時に所属していても)監査グループにポリシーが適用されるだけではなく、そのホストに関連付けられたすべてのポリシーが監査モードになります。したがって、監査モードは特定のポリシーに適用されるのではなく、ホスト全体に適用されます。

グループが監査モードであるかどうかは、次のいずれかの方法で判断できます。

グループ リスト ページで、グループを示している行のグループのアトリビュートに [A] と表示されています。グループ リスト ページを表示するには、CSA MC のメニューバーで [Systems] > [Groups] に移動します。

グループの詳細ページを表示すると、[Rule Overrides] エリアの [Audit mode] チェックボックスがオンになっています。グループの詳細ページを表示するには、グループ リスト ページでグループをクリックします。

[Host Security] ページで、対象のグループを示す行で [Audit Mode] チェックボックスがオンになっています。[Host Security] ページを表示するには、CSA MC のメニューバーで [Configuration] > [Host Security] に移動します。


) [Hosts Managing Tasks] ページを使用して、「期間指定された」監査モードを設定できます。基本的には、ホストを指定された間隔で選択済みグループに移動したり、グループから移動したりするタスクを設定できます。このようにして、30 日間のパイロット期間の経過後に、新しいホストをすべて監査モード グループからライブ モードのグループに移動できます。構成情報については、「ホストの管理タスク」を参照してください。


規則モジュールの監査モード

規則モジュール レベルで監査モードを使用することもできます。ポリシーに割り当てられている規則モジュールが監査モードの場合、その規則モジュールに関連付けられている規則だけが監査モードで実行されます。同じポリシー内の他の規則モジュールの規則は、設定されていたモードでそのまま実行されます。これは、新しい規則モジュールをテストする場合、または当該のホストに対するすべての保護を解除することなく既存のモジュールを変更する場合に役立ちます。

ある規則モジュールが監査モードになっており、複数のポリシーで使用されている場合、その規則モジュールは、割り当てられているすべてのポリシーで監査モードになります。


注意 展開済みの「ライブ」の規則モジュールを監査モードにすると、それまで規則モジュールが提供していたすべてのセキュリティ機能がオフになります。監査モードを使用して規則モジュールの動作を分析する場合は、このことに十分注意してください。

規則モジュールが監査モードであるかどうかは、次のいずれかの場所を調べると判断できます。

規則モジュールのリスト ページで、規則モジュールを示している行の [Attributes] カラムに [A] と表示されています。規則モジュールのリスト ページを表示するには、CSA MC のメニューバーで [Configuration] > [Rule Modules] に移動します。

ポリシーの詳細ページで、規則モジュールを示している行の [Attributes] カラムに [A] と表示されています。ポリシーの詳細リスト ページを表示するには、CSA MC のメニューバーで [Configuration] > [Policies] に移動し、ポリシーの名前をクリックします。

グループの詳細ページで、組み合わされたポリシー規則を展開します。規則が行単位で表示され、その規則の規則モジュールが参照されます。規則モジュールが監査モードの場合は、規則モジュールの名前の横に [A] と表示されています。グループの詳細ページを表示するには、CSA MC のメニューバーで [Systems] > [Groups] に移動し、グループの名前をクリックします。

ポリシーの監査モード

ポリシーをテスト モードにできるのは、グループのコンテキスト内だけです。そのため、あるポリシーが複数のグループに属している場合、そのポリシーは、あるグループでは監査モードにして、他のグループではライブ モードにすることが可能です。ポリシーを監査モードで使用するグループでは、そのポリシー内のすべての規則が監査モードになります。

あるホストで 2 つの同じ規則を使用し、1 つが監査モードでもう 1 つがライブ モードの場合、両方の規則がトリガーされます。監査モードの規則は何も影響がありません。ライブ モードの規則は、どのようなアクションであっても、指定されているアクションを強制的に実行します。

ポリシーが監査モードであるかどうかは、次のいずれかの場所を調べると判断できます。

グループの詳細ページで、ポリシーが示されている行で [Audit Mode] チェックボックスがオンになっています。グループの詳細ページを表示するには、CSA MC のメニューバーで [Systems] > [Groups] に移動し、グループの名前をクリックします。

[Host Security] ページでグループの名前をクリックし、そのグループが使用しているポリシーを表示します。そのグループに対してポリシーが監査モードになっている場合は、[Audit Mode] チェックボックスがオンになっています。[Host Security] ページを表示するには、CSA MC のメニューバーで [Configuration] > [Host Security] に移動します。

監査モードのホストの識別

ホストが属すすべてのグループが監査モードの場合、そのホストは監査モードであると見なされます。規則モジュール、またはユーザが属すグループのポリシーが監査モードの場合、ホスト上の個々の規則は監査モードになっている可能性があります。ホスト自体を監査モードに設定することはできません。

ホストが規則を監査している範囲、または規則を強制する範囲を確認するには、次の場所を調べます。

ホストの詳細ページで、[Status] エリアで [Host Settings] をクリックします。監査モードが「オン」とマークされている場合は、そのホストが属す少なくとも 1 つのグループが監査モードになっています。ホストの詳細ページを表示するには、CSA MC のメニューバーで [Systems] > [Hosts] に移動し、対象ホストの名前をクリックします。

ホストの詳細ページで、[Group Membership and Policy Inheritance] テーブルを調べます。監査モードになっているグループまたはポリシーのアトリビュート カラムに [A] と表示されています。グループ名を展開し、グループに関連付けられている規則モジュールを調べます。監査モードになっている規則モジュールのアトリビュート カラムに [A] と表示されています。

ラーニング モードの使用方法

ラーニング モードの目的は、個々のシステムでポリシーをローカライズして、システムにエージェントを最初にインストールしたときにポップアップ クエリーが表示されて混乱が発生しないようにすることにあります。このクエリーは、未知のシステム アクションが通常か異常かをエンド ユーザが判別できるように、クエリー規則が展開された結果として発生します。エージェントは、最初に展開されるとき、システム アクションを初めて確認しているため、こうしたポップアップ クエリーが多数発生する可能性があります。しかし、アクションに対してクエリーが頻発する初期の現象は(ほとんどの場合)無害と考えられるため、ユーザは、表示されるクエリーの大部分に Yes で応答するように教育される可能性があります。

有用なクエリー規則を展開から削除しないでこの問題を解決するために、エージェントが最初にインストールされた後、設定できない自動の正規化ラーニング期間があり、72 時間実行されます。このラーニングは、実行しているアプリケーションと異常システム コールの両方が対象です。その後、ラーニング モードを一時的な期間だけイネーブルにできます。ラーニング モードによって、エージェントはクエリー ポップアップを表示しないように指定され、代わりにクエリー規則がトリガーされると即時の 許可 クエリー応答を採用して、その 許可 応答を永続的に保存するように指定されます。

ラーニング モードを使用する場合は、ラーニングに適したクエリーの特定オプションをイネーブルにする必要があります。ラーニング モードは [Group] ページまたは [Rule module] ページでイネーブルにし、クエリーは [Configuration] > [Variables] > [Query Settings] メニューで定義します。[Query Settings] ページには事前設定のクエリーがいくつかリストされています。ラーニング モードを機能させるには、次の操作を行う必要があります。

[Group] ページまたは特定の [Rule module] ページで、[Rule overrides] セクションの [Learn mode] をイネーブルにします。

監査モードと同様に、ラーニング モードは、ホストで実行されているすべてのポリシー内の持続性クエリーすべてを対象に(グループ ラーニング モード)イネーブルにするか、または特定の規則モジュールにある特定の持続性クエリーを対象に(規則モジュール ラーニング モード)イネーブルにすることができます。

ラーニングのために展開するクエリーの [Query Setting] 設定ページ(「クエリー設定」を参照)にアクセスします。クエリーは、次の場合にラーニングに適しています。

[Enable "Don't ask again" option] が選択されている場合

Allowed query actions の 1 つとして [Allow] が選択されている場合

クエリー応答が採用され、ラーニング モードをオフにすると、大部分のクエリーは表示されなくなり、エージェントが提供するシステム セキュリティは個々のシステムに対して正規化されます。この時点で、ユーザには異常または不審なシステム動作に対するクエリー ポップアップだけが表示されます。

ラーニング モードに関するその他の注

ラーニング モードがイネーブルな時間枠では、適格なクエリーはすべて自動および持続性のある Yes で応答されます (ラーニング モードを手動で有効にした場合は、適切な時間が経過した後で、必ずラーニング モードをオフにしてください)。

[Hosts Managing Tasks] ページを使用して、「期間指定された」ラーニング モードを設定できます。基本的には、ホストを指定された間隔で選択済みグループに移動したり、グループから移動したりするタスクを設定できます。このようにして、設定時間の経過後に、新しいホストをすべてラーニング モード グループから移動できます。構成情報については、「ホストの管理タスク」を参照してください。

クエリーがトリガーされ学習されると、イベントが MC イベント ログに記録されます。このイベントは多くのイベントと同様の形式ですが、クエリー応答が採用されたこと、および対象クエリーのラーニング モードがオンになったことが示されます。

学習した許可応答は、発生時にエージェントの [User Query Responses] ウィンドウに表示されます。

クエリー規則の監査モードとラーニング モードの両方がイネーブルの場合、ラーニングは実行されません。

ラーニング モードの場合に、エージェントはローカル マシンで実行されている各種アプリケーションを学習します。また、一般にマシンによって示される、通常とは異なるシステム コールがあれば学習します。結果として、ラーニング モード期間中にシステムで実行されると見なされているアプリケーションはトリガーされず、ラーニング期間後の最初の実行時に「初回実行」アプリケーションとして分類されません。ラーニング中に確認された通常とは異なるシステム コールは、システム API 規則の異常システム コール検出をトリガーしません。

エージェントに対して「Reset Cisco Security Agent」機能を使用すると、学習したすべての情報が削除され、エージェントは 72 時間のラーニング期間をもう一度開始します。

Sample - Cisco Security Agent Bypass 規則モジュール

十分に把握し、信頼しているアプリケーションの無害な動作を、CSA がブロックし、Event Management Wizard を使用してアプリケーションを十分にイネーブルにできない場合は、すべての CSA の保護および制御からアプリケーションを免除するよう、Sample - Cisco Security Agent Bypass 規則モジュールを設定します。

この規則モジュールの使用方法については、 付録 B「CSA Bypass 機能」 を参照してください。


警告 CSA Bypass 機能を使用するのは、最後の手段としてください。この機能を使用する前に、Event Management Wizard を使用してアプリケーションを有効にしてみてください。詳細については、「Event Management Wizard について」を参照してください。

CSA の保護および制御から免除することを選択するアプリケーションが侵害された場合は、CSA の実行中でも、ホスト システムは攻撃に対して脆弱になります。