本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。
ポリシーで使用する セキュリティログ監視 ルールを定義する
OSSEC セキュリティログ監視 エンジンはDeep Security Agentに統合されており、Deep Securityは、コンピュータ上で実行されているオペレーティングシステムおよびアプリケーションによって生成されたログおよびイベントを検査できます。Deep Security Managerには、コンピュータまたはポリシーに割り当てることができるOSSEC セキュリティログ監視 ルールの標準セットが付属しています。要件に合う既存ルールが存在しない場合は、カスタムルールを作成することもできます。
トレンドマイクロが発行したセキュリティログ監視ルールを変更することはできませんが、それらを複製してから変更することはできます。
1台以上のコンピュータに割り当てられているか、ポリシーの一部であるセキュリティログ監視ルールは削除できません。
セキュリティログ監視 ルールを作成するには、次の基本手順を実行します。
- 新しい セキュリティログ監視 ルールを作成します。
- デコーダ
- サブルール
- 例
- セキュリティログ監視 ルールの重大度レベルと推奨される使用
- strftime () 変換指定子
- セキュリティログ監視 ルールを調べる
セキュリティログ監視 モジュールの概要については、 セキュリティログ監視を参照してください。
新しい セキュリティログ監視 ルールを作成します。
- Deep Security Managerで、[ポリシー]→[共通オブジェクト]→[ルール]→[セキュリティログ監視ルール] に進みます。
- [新規]→[新しいセキュリティログ監視ルール] をクリックします。
- [一般] タブで、ルールの名前と説明を入力します (説明は省略できます)。
-
[コンテンツ] タブで、ルールを定義します。ルールを定義する一番簡単な方法は、[基本ルール] を選択し、表示されるオプションを使用してルールを定義する方法です。さらにカスタマイズが必要な場合は、[カスタム (XML)] を選択し、定義しているルールをXMLビューに切り替えることができます。
カスタム (XML)ビューで行った変更は、基本ルールビューに戻すと失われます。
XMLベースの言語を使用して独自の セキュリティログ監視 ルールを作成する場合は、 OSSEC のドキュメントを参照するか、サポートプロバイダにお問い合わせください。
基本ルールテンプレートでは以下のオプションを使用できます。
- ルールID: ルールIDはルールの一意の識別子です。OSSECは100000 - 109999をユーザ定義ルールのスペースとして定義しています。Deep Security Managerは新しい一意のルールIDでフィールドを事前に入力します。
- レベル: ルールにレベルを割り当てます。ゼロ (0) は、ルールによってイベントが記録されないことを示しますが、このルールを監視する他のルールが発生する可能性があります
- グループ: 1つ以上のカンマ区切りのグループにルールを割り当てます。これが便利なのは、ある1つのルールの発生時に発生する複数のルール、または特定のグループに属するルールを作成した後に依存関係が使用されるときです。
- ルールの説明: ルールの説明。
-
パターンマッチング: これはルールがログ内で探すパターンです。ルールは一致時にトリガーされます。パターンマッチングは正規表現またはより単純な文字列パターンをサポートします。文字列パターンのパターンタイプは正規表現よりも高速ですが、3つの特殊操作のみをサポートします。
- ^ (カレット): テキストの先頭を指定します。
- $ (ドル記号): テキストの末尾を指定します。
- | (パイプ): 複数のパターン間に「OR」を作成します。
セキュリティログ監視モジュールで使用される正規表現の構文については、https://www.ossec.net/docs/syntax/regex.htmlを参照してください。
- 依存関係: 別のルールに依存関係を設定すると、この領域で指定されたルールがトリガーされた場合にのみ、イベントが記録されます。
- [頻度] は、ルールがトリガされるまでの特定の期間内にルールを照合する必要のある回数です。
-
[期間] は、イベントを記録するためにルールを特定の回数 (上記の頻度) トリガするまでの期間 (秒数) です。
コンテンツタブは、ユーザー自身が作成したセキュリティログ監視ルールにのみ表示されます。トレンドマイクロによって発行されたセキュリティログ監視ルールには、代わりに構成タブが表示され、セキュリティログ監視ルールの構成オプションが表示されます (存在する場合)。
- ファイルタブで、ルールでモニタしたいファイルのフルパスを入力し、ファイルの種類を指定してください。
グロブ文字はファイル名で使用する場合のみサポートされており、パスのマッチングにはサポートされていません。例えば、
/home/user1/testlog*.txtは有効ですが、/home/*/testlog1.txtは無効です。 - [オプション] タブの [アラート] セクションで、このルールでアラートをトリガするかどうかを選択します。
最小のアラート重要度 は、基本ルールまたはカスタム（XML）テンプレートを使用してルールに対してアラートをトリガする最小の重大度レベルを設定します。
基本ルールテンプレートは、一度に1つのルールを作成します。1つのテンプレートに複数のルールを書き込むには、カスタム（XML）テンプレートを使用できます。カスタム（XML）テンプレート内でレベルが異なる複数のルールを作成する場合は、[ 最小のアラート重要度 ]設定を使用して、そのテンプレート内のすべてのルールに対するアラートをトリガする最小の重要度を選択できます。
- [ 割り当て対象 に割り当てられました]タブには、この セキュリティログ監視 ルールを使用しているポリシーとコンピュータが表示されます。新しいルールは作成中であるため、まだ割り当てられていません。
- [OK] をクリックします。このルールをポリシーとコンピュータに割り当てる準備ができました。
デコーダ
A セキュリティログ監視 ルールは、変更を監視するファイルのリストと、ルールがトリガする条件のセットで構成されます。 セキュリティログ監視 エンジンが監視対象ログファイルの変更を検出すると、その変更はデコーダによって解析されます。デコーダは、rawログエントリを解析して次のフィールドを生成します。
- log: イベントのメッセージセクション
- full_log: イベント全体
- location: ログの生成元
- hostname: イベント発生元のホスト名
- program_name: イベントのSyslogヘッダで使用されるプログラム名
- srcip: イベント内の送信元のIPアドレス
- dstip: イベント内の送信先のIPアドレス
- srcport: イベント内の送信元のポート番号
- dstport: イベント内の送信先のポート番号
- protocol: イベント内のプロトコル
- action: イベント内で実行された処理
- srcuser: イベント内の送信元のユーザ
- dstuser: イベント内の送信先のユーザ
- id: イベントからのIDとしてデコードされたID
- status: イベント内のデコードされたステータス
- command: イベント内で呼び出されるコマンド
- url: イベント内のURL
- data: イベントから抽出される追加データ
- systemname: イベント内のシステム名
ルールは、このデコードされたデータを確認して、ルールで定義された条件に一致する情報を検索します。
一致する項目の重要度レベルが十分に高い場合は、次のいずれかの処理を実行できます。
- アラートを発生させることができます。セキュリティログ監視ルールのプロパティウィンドウのオプションタブで設定可能です。
- イベントは syslog に書き込むことができます。管理 > システム設定 > イベント転送 タブの SIEM エリアで設定可能です。
- イベントはDeep Security Managerに送信できます。ポリシーまたはコンピュータエディタ > 設定 > イベント転送タブのセキュリティログ監視Syslog設定で設定可能です。
サブルール
1つの セキュリティログ監視 ルールに複数のサブルールを含めることができます。これらのサブルールには、アトミックとコンポジットという2つの種類があります。アトミックルールは1つのイベントを評価し、コンポジットルールは複数のイベントを確認して、頻度、繰り返し、およびイベント間の相関関係を評価できます。
グループ
各ルールまたはルールのグループは、<group></group>要素内で定義する必要があります。属性名には、このグループに含めたいルールを含める必要があります。次の例では、グループにsyslogとSSHDのルールが含まれていることを示しています。
<group name="syslog,sshd,"> </group>
グループ名の末尾のコンマに注意してください。<if_group></if_group>タグを使用してこのサブルールに別のサブルールを条件付きで追加する場合、末尾のコンマが必要です。
セキュリティログ監視ルールのセットがエージェントに送信されると、エージェント上のセキュリティログ監視エンジンは、各割り当てられたルールからXMLデータを取得し、それを1つの長いセキュリティログ監視ルールに組み立てます。トレンドマイクロによって作成されたすべてのセキュリティログ監視ルールには共通のグループ定義があります。このため、トレンドマイクロはこれらのグループを定義するDefault Rules Configurationというルールを含めており、他のトレンドマイクロのルールと一緒に常に割り当てられます。ルールを割り当てる際にDefault Rules Configurationルールを選択しない場合、そのルールが自動的に割り当てられることを通知するメッセージが表示されます。独自のセキュリティログ監視ルールを作成し、トレンドマイクロ作成のルールを割り当てずにコンピュータに割り当てる場合は、Default Rules Configurationルールの内容を新しいルールにコピーするか、またはDefault Rules Configurationルールをコンピュータに割り当てるために選択する必要があります。
ルール、ID、およびレベル
グループには必要なだけのルールを含めることができます。ルールは<rule></rule>要素を使用して定義され、少なくとも2つの属性、idとlevelを持たなければなりません。idはそのシグネチャの一意の識別子であり、levelはアラートの重大度です。次の例では、異なるルールIDとレベルを持つ2つのルールが作成されています。
<group name="syslog,sshd,"> <rule id="100120" level="5"> </rule> <rule id="100121" level="6"> </rule> </group>
カスタムルールには、100,000以上のID値を指定する必要があります。
親グループ内に<group></group>タグを使用して追加のサブグループを定義できます。このサブグループは、以下の表に記載されているグループのいずれかを参照することができます。
| グループの種類 | グループ名 | 説明 |
| 攻撃の予兆 | connection_attempt web_scan recon |
接続の試行 Web検索 一般的な検索 |
| 認証制御 | authentication_success authentication_failed invalid_login login_denied authentication_failures adduser account_changed |
成功 失敗 無効 ログイン拒否 複数の失敗 ユーザアカウントの追加 ユーザアカウントの変更または削除 |
| 攻撃/悪用 | automatic_attack exploit_attempt invalid_access spam multiple_spam sql_injection attack virus |
ワーム (対象を指定しない攻撃) 攻撃コードのパターン 無効なアクセス スパム 複数のスパムメッセージ SQLインジェクション 一般的な攻撃 ウイルスの検出 |
| アクセス管理 | access_denied access_allowed unknown_resource firewall_drop multiple_drops client_misconfig client_error |
アクセス拒否 アクセス許可 存在しないリソースへのアクセス ファイアウォールによるドロップ 複数のファイアウォールによるドロップ クライアントの誤った設定 クライアントエラー |
| ネットワーク制御 | new_host ip_spoof |
新しいコンピュータの検出 ARPスプーフィングの疑い |
| システム監視 | service_start system_error system_shutdown logs_cleared invalid_request promisc policy_changed config_changed low_diskspace time_changed |
サービスの開始 システムエラー シャットダウン ログのクリア 無効な要求 インタフェースのプロミスキャスモードへの切り替え ポリシーの変更 設定の変更 ディスク容量が少ない 時刻の変更 |
イベントの自動タグ付けが有効になっている場合、イベントはグループ名でラベル付けされます。トレンドマイクロが提供するセキュリティログ監視ルールは、グループをよりユーザーフレンドリーなバージョンに変更する変換テーブルを使用します。例えば、login_deniedはLogin Deniedとして表示されます。カスタムルールは、ルールに表示されるグループ名で一覧表示されます。
説明
<description></description>タグを含めます。ルールがトリガーされた場合、説明テキストがイベントに表示されます。
<group name="syslog,sshd,"> <rule id="100120" level="5"> <group>authentication_success</group> <description>SSHD testing authentication success</description> </rule> <rule id="100121" level="6"> <description>SSHD rule testing 2</description> </rule> </group>
デコード形式
<decoded_as></decoded_as>タグは、指定されたデコーダーがログをデコードした場合にのみルールを適用するようにセキュリティログ監視エンジンに指示します。
<rule id="100123" level="5"> <decoded_as>sshd</decoded_as> <description>Logging every decoded sshd message</description> </rule>
使用可能なデコーダを表示するには、[セキュリティログ監視ルール] 画面で [デコーダ] をクリックします。[1002791-Default Log Decoders] を右クリックして、[プロパティ] を選択します。[設定] タブに進み、[デコーダの表示] をクリックします。
一致項目
ログ内で特定の文字列を探すには、<match></match>を使用します。こちらはLinuxのsshd失敗パスワードログです。
Jan 1 12:34:56 linux_server sshd[1231]: Failed password for invalid user jsmith from 192.168.1.123 port 1799 ssh2
「Failed password」という文字列を検索するには、<match></match> タグを使用します。
<rule id="100124" level="5"> <decoded_as>sshd</decoded_as> <match>^Failed password</match> <description>Failed SSHD password attempt</description> </rule>
正規表現のキャレット ( ^ ) は文字列の先頭を示しています。「Failed password」はログの先頭には表示されませんが、セキュリティログ監視デコーダーはログをセクションに分割します。参照 デコーダ 詳細情報については、「log」はログのメッセージ部分であり、「full_log」はログ全体であるセクションの1つです。
次の表は、サポートされている正規表現の構文一覧です。
| 正規表現の構文 | 説明 |
| \w | A～Z、a～z、0～9の英数字1文字 |
| \d | 0～9の数字1文字 |
| \s | 単一のスペース (空白文字) |
| \t | 単一のタブ |
| \p | ()*+,-.:;<=>?[] |
| \W | \w以外 |
| \D | \d以外 |
| \S | \s以外 |
| \. | 任意の文字 |
| + | 上記のいずれかの1つ以上に一致 (たとえば、\w+、\d+) |
| * | 上記のいずれかの0個以上に一致 (たとえば、\w*、\d*) |
| ^ | 文字列の先頭 (^<任意の文字列>) |
| $ | 文字列の末尾 (<任意の文字列>$) |
| | | 複数の文字列間の「OR」 |
条件文
ルールの評価は、他のルールが真と評価された場合に条件付きで行うことができます。<if_sid></if_sid>タグは、タグで識別されたルールが真と評価された場合にのみ、このサブルールを評価するようにセキュリティログ監視エンジンに指示します。次の例では、3つのルールを示しています: 100123、100124、および100125。ルール100124と100125は、<if_sid></if_sid>タグを使用して100123ルールの子として変更されています。
<group name="syslog,sshd,"> <rule id="100123" level="2"> <decoded_as>sshd</decoded_as> <description>すべてのデコードされたsshdメッセージを記録</description> </rule> <rule id="100124" level="7"> <if_sid>100123</if_sid> <match>^Failed password</match> <group>authentication_failure</group> <description>SSHDパスワード試行失敗</description> </rule> <rule id="100125" level="3"> <if_sid>100123</if_sid> <match>^Accepted password</match> <group>authentication_success</group> <description>SSHDパスワード試行成功</description> </rule> </group>
評価の階層
<if_sid></if_sid>タグは本質的に階層的なルールセットを作成します。つまり、ルールに<if_sid></if_sid>タグを含めることで、そのルールは<if_sid></if_sid>タグで参照されるルールの子ルールとなります。ログにルールを適用する前に、セキュリティログ監視エンジンは<if_sid></if_sid>タグを評価し、親ルールと子ルールの階層を構築します。
階層的な親子構造を使用することで、ルールの効率を向上させることができます。親ルールが真と評価されない場合、セキュリティログ監視エンジンはその親の子ルールを無視します。
<if_sid></if_sid>タグは、まったく異なるセキュリティログ監視ルール内のサブルールを参照するために使用できますが、後でルールを確認するのが非常に難しくなるため、これを避けるべきです。
次の表は、使用可能なアトミックルールの条件指定のオプションを一覧表示しています。
| タグ | 説明 | 備考 |
| match | パターン | イベント (ログ) に対して照合される任意の文字列。 |
| regex | 正規表現 | イベント (ログ) に対して一致する正規表現。 |
| decoded_as | 文字列 | 事前一致する任意の文字列。 |
| srcip | 送信元のIPアドレス | ソースIPアドレスとしてデコードされたIPアドレス。IPアドレスを否定するには!を使用します。 |
| dstip | 送信先のIPアドレス | 宛先IPアドレスとしてデコードされたIPアドレス。IPアドレスを否定するには!を使用します。 |
| srcport | 送信元のポート番号 | 任意の送信元のポート (形式の一致)。 |
| dstport | 送信先のポート番号 | 任意の送信先のポート (形式の一致)。 |
| user | ユーザ名 | ユーザ名としてデコードされる任意のユーザ名。 |
| program_name | プログラム名 | Syslogプロセス名からデコードされる任意のプログラム名。 |
| hostname | システムのホスト名 | Syslogのホスト名としてデコードされる任意のホスト名。 |
| time | 次の形式の時刻の範囲 hh:mm - hh:mmまたは hh:mm am - hh:mm pm | トリガするルールに対してイベントが発生する必要のある時刻の範囲。 |
| weekday | 平日 (日曜日、月曜日、火曜日など) | トリガするルールに対してイベントが発生する必要のある曜日。 |
| id | ID | イベントからデコードされる任意のID。 |
| url | URL | イベントからデコードされる任意のURL。 |
このルールを100125ルールに依存させるには、<if_sid>100125</if_sid>タグを使用します。このルールは、すでに成功したログインルールに一致したSSHDメッセージに対してのみチェックされます。
<rule id="100127" level="10"> <if_sid>100125</if_sid> <time>6 pm - 8:30 am</time> <description>Login outside business hours.</description> <group>policy_violation</group> </rule>
ログエントリのサイズに関する制限
次の例では、前の例にmaxsize属性を追加し、セキュリティログ監視エンジンに対して、最大サイズの文字数未満のルールのみを評価するように指示します。
<rule id="100127" level="10" maxsize="2000"> <if_sid>100125</if_sid> <time>6 pm - 8:30 am</time> <description>Login outside business hours.</description> <group>policy_violation</group> </rule>
次の表は、使用可能なアトミックルールのツリーベースのオプションを一覧表示しています。
| タグ | 説明 | 備考 |
| if_sid | ルールID | 指定された署名IDに一致するルールの子ルールとしてこのルールを追加します。 |
| if_group | グループID | 指定されたグループに一致するルールの子ルールとしてこのルールを追加します。 |
| if_level | ルールレベル | 指定された重要度レベルに一致するルールの子ルールとしてこのルールを追加します。 |
| 説明 | 文字列 | ルールの説明。 |
| info | 文字列 | ルールの追加情報。 |
| cve | CVE番号 | ルールに関連付ける任意のCommon Vulnerabilities and Exposures (CVE) 番号。 |
| options | alert_by_email no_email_alert no_log | アラートの処理としてメール生成 (alert_by_email)、メール生成なし (no_email_alert)、またはログへの記録なし (no_log) のいずれかを指定する追加のルールオプション。 |
コンポジットルール
単一のログエントリを検査するのがアトミックルールです。複数のエントリを関連付けるには、コンポジットルールを使用する必要があります。コンポジットルールは、現在のログを既に受信したものと一致させることを目的としています。コンポジットルールには2つの追加オプションが必要です: frequencyオプションは、ルールがアラートを生成する前にイベントまたはパターンが何回発生する必要があるかを指定し、timeframeオプションは、セキュリティログ監視エンジンが過去のログを何秒前まで遡って検索するかを指示します。すべてのコンポジットルールは次の構造を持っています:
<rule id="100130" level="10" frequency="x" timeframe="y"> </rule>
例えば、10分間に5回のパスワード失敗があった場合に高い重大度のアラートを作成する複合ルールを作成することができます。<if_matched_sid></if_matched_sid>タグを使用して、新しいルールがアラートを作成するために必要な頻度と時間枠内でどのルールを確認する必要があるかを示すことができます。次の例では、frequency属性はイベントが5回発生したときにトリガーされるように設定され、timeframe属性は時間枠を600秒として指定するように設定されています。
<if_matched_sid></if_matched_sid>タグは、複合ルールが監視する他のルールを定義するために使用されます。
<rule id="100130" level="10" frequency="5" timeframe="600"> <if_matched_sid>100124</if_matched_sid> <description>5 Failed passwords within 10 minutes</description> </rule>
より詳細なコンポジットルールを作成するのに使用できるタグが他にもいくつかあります。このようなルールを使用すると、次の表に示すように、イベントの特定の部分が同じになるように指定できます。これにより、コンポジットルールを調整して誤判定を減らすことができます。
| タグ | 説明 |
| same_source_ip | 送信元のIPアドレスが同じになるように指定します。 |
| same_dest_ip | 送信先のIPアドレスが同じになるように指定します。 |
| same_dst_port | 送信先のポートが同じになるように指定します。 |
| same_location | 場所 (ホスト名またはAgent名) が同じになるように指定します。 |
| same_user | デコードされるユーザ名が同じになるように指定します。 |
| same_id | デコードされるIDが同じになるように指定します。 |
複合ルールが特定のルールIDではなく、すべての認証失敗に対してアラートを出すようにしたい場合、<if_matched_sid></if_matched_sid>タグを<if_matched_ group></if_matched_ group>タグに置き換えることができます。これにより、authentication_ failureのようなカテゴリを指定して、インフラ全体で認証失敗を検索することができます。
<rule id="100130" level="10" frequency="5" timeframe="600"> <if_matched_group>authentication_failure</if_matched_group> <same_source_ip /> <description>5 Failed passwords within 10 minutes</description> </rule>
<if_matched_sid></if_matched_sid>タグと<if_matched_group></if_matched_ group>タグに加えて、<if_matched_regex></if_matched_regex>タグを使用して、受信したログを検索するための正規表現を指定することもできます。
<rule id="100130" level="10" frequency="5" timeframe="600"> <if_matched_regex>^Failed password</if_matched_regex> <same_source_ip /> <description>10分以内に5回のパスワード失敗</description> </rule>
例
Deep Securityには、数多くの一般的なアプリケーションおよび一般的なアプリケーションの セキュリティログ監視 初期設定ルールが多数含まれています。新しいルールは、セキュリティアップデートを使用して定期的に追加できます。 セキュリティログ監視 ルールでサポートされるアプリケーションのリストが増加しているにもかかわらず、サポートされていないアプリケーションまたはカスタムアプリケーションのカスタムルールを作成する必要が生じる場合があります。
次の例では、Microsoft Windowsサーバー上でIISと.Netプラットフォームを使用してホストされるカスタムCMS (コンテンツ管理システム) を作成し、データリポジトリとしてMicrosoft SQLサーバーデータベースを使用します。
最初に、次に示すアプリケーションログの属性を特定します。
- アプリケーションログを記録する場所
- どの セキュリティログ監視 デコーダを使用してログファイルを復号できますか？
- ログファイルメッセージの一般的な形式
CMSの例について、回答は以下の通りです。
- Windowsイベントビューア
- Windowsイベントログ (eventlog)
- Windowsイベントログ形式 (次のコア属性を使用)
- ソース: CMS
- カテゴリ: なし
- イベント:<Application Event ID>
次に、アプリケーションの機能別にログイベントのカテゴリを特定し、そのカテゴリを監視用のカスケードグループの階層に分類します。監視対象のすべてのグループでイベントを発生させる必要はなく、一致する項目を条件文として使用できます。各グループについて、ルールで照合条件として使用できるログ形式の属性を特定します。これは、すべてのアプリケーションログの、ログイベントのパターンおよび論理分類を調べて実行することもできます。
例えば、CMSアプリケーションは以下の機能をサポートしており、それに対してセキュリティログ監視ルールが作成されています。
- CMSアプリケーションログ (ソース: CMS)
- 認証 (イベント: 100～119)
- ユーザログインの成功 (イベント: 100)
- ユーザログインの失敗 (イベント: 101)
- 管理者ログインの成功 (イベント: 105)
- 管理者ログインの失敗 (イベント: 106)
- 一般エラー (種類: エラー)
- データベースエラー (イベント: 200～205)
- ランタイムエラー (イベント: 206～249)
- アプリケーション監査 (種類: 情報)
- コンテンツ
- 新しいコンテンツの追加 (イベント: 450～459)
- 既存のコンテンツの変更 (イベント: 460～469)
- 既存のコンテンツの削除 (イベント: 470～479)
- 管理
- User
- 新しいユーザの作成 (イベント: 445～446)
- 既存のユーザの削除 (イベント: 447～449)
- User
- コンテンツ
- 認証 (イベント: 100～119)
この構造は、ルール作成のための良い基盤を提供します。これで、Deep Security Managerで新しいセキュリティログ監視ルールを作成できます。
新しいCMSセキュリティログ監視ルールを作成するには
- Deep Security Managerで、ポリシー > 共通オブジェクト > ルール > セキュリティログ監視ルールに移動し、新規をクリックして新規セキュリティログ監視ルールのプロパティウィンドウを表示します。
- 新しいルールに名前と説明を付けて、コンテンツタブを選択してください。
- 基本ルールを選択します。新しいカスタムルールを作成する最も簡単な方法は、基本ルールテンプレートから始めることです。
- ルールIDフィールドには、カスタムルール用に予約された100,000以上の未使用ID番号が自動的に入力されます。
- [レベル] を [低 (0)] に設定します。
- ルールに適切なグループ名を指定します。ここでは「cms」とします。
- ルールの簡単な説明を入力します。
- カスタム (XML)を選択します。基本ルールで選択したオプションがXMLに変換されます。
- ファイルタブを選択し、ファイルを追加をクリックして、ルールを適用するアプリケーションログファイルとログタイプを追加します。この場合、ファイルタイプとしてアプリケーションとeventlogを選択します。
EventlogはDeep Securityにおけるユニークなファイルタイプです。なぜなら、ログファイルの場所やファイル名を指定する必要がないからです。代わりに、Windowsイベントビューアに表示されるログ名を入力するだけで十分です。Eventlogファイルタイプの他のログ名には、Security、System、Internet Explorer、またはWindowsイベントビューアにリストされている他のセクションが含まれることがあります。他のファイルタイプでは、ログファイルの場所とファイル名が必要です。C/C++のstrftime () 変換指定子は、ファイル名の一致に利用可能です。より便利なもののリストについては、表を参照してください。
- [OK] をクリックして基本ルールを保存します。
- 基本ルールCustom (XML) を作成したら、以前に特定されたロググループに基づいてグループに新しいルールを追加し始めることができます。基本ルールの基準を初期ルールに設定する必要があります。次の例では、CMS基本ルールが
CMSのSource属性を持つWindowsイベントログを特定しています。<group name="cms"> <rule id="100000" level="0"> <category>windows</category> <extra_data>^CMS</extra_data> <description>Windows events from source 'CMS' group messages.</description> </rule>
- 識別されたロググループから後続のルールを構築して進めます。次の例では、認証とログインの成功および失敗をイベントIDで識別し、ログに記録します。
<rule id="100001" level="0"> <if_sid>100000</if_sid> <id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id> <group>authentication</group> <description>CMS認証イベント。</description> </rule> <rule id="100002" level="0"> <if_group>authentication</if_group> <id>100</id> <description>CMSユーザーログイン成功イベント。</description> </rule> <rule id="100003" level="4"> <if_group>authentication</if_group> <id>101</id> <group>authentication_failure</group> <description>CMSユーザーログイン失敗イベント。</description> </rule> <rule id="100004" level="0"> <if_group>authentication</if_group> <id>105</id> <description>CMS管理者ログイン成功イベント。</description> </rule> <rule id="100005" level="4"> <if_group>authentication</if_group> <id>106</id> <group>authentication_failure</group> <description>CMS管理者ログイン失敗イベント。</description> </rule>
- 確立されたルールを使用して、任意の複合または相関ルールを追加します。次の例は、10秒間に5回のログイン失敗が発生した場合に適用される高重大度の複合ルールを示しています。
<rule id="100006" level="10" frequency="5" timeframe="10"> <if_matched_group>authentication_failure</if_matched_group> <description>CMS繰り返し認証ログイン失敗イベント。</description> </rule>
- すべてのルールの重要度レベルが適切かどうかを確認します。たとえば、エラーログの重要度はレベル5以上でなければなりません。情報ルールの重要度は低くなります。
- 新しく作成したルールを開き、Configurationタブを選択し、カスタムルールのXMLをルールフィールドにコピーします。適用またはOKをクリックして変更を保存します。
ルールがポリシーまたはコンピュータに割り当てられると、 セキュリティログ監視 エンジンは、指定されたログファイルの検査をただちに開始します。
完成したカスタムCMSセキュリティログ監視ルール:
<group name="cms">
<rule id="100000" level="0"> <category>windows</category> <extra_data>^CMS</extra_data> <description>Windows events from source 'CMS' group messages.</description> </rule>
<rule id="100001" level="0"> <if_sid>100000</if_sid> <id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id> <group>authentication</group> <description>CMS Authentication event.</description> </rule> <rule id="100002" level="0"> <if_group>authentication</if_group> <id>100</id> <description>CMS User Login success event.</description> </rule> <rule id="100003" level="4"> <if_group>authentication</if_group> <id>101</id> <group>authentication_failure</group> <description>CMS User Login failure event.</description> </rule> <rule id="100004" level="0"> <if_group>authentication</if_group> <id>105</id> <description>CMS Administrator Login success event.</description> </rule> <rule id="100005" level="4"> <if_group>authentication</if_group> <id>106</id> <group>authentication_failure</group> <description>CMS Administrator Login failure event.</description> </rule> <rule id="100006" level="10" frequency="5" timeframe="10"> <if_matched_group>authentication_failure</if_matched_group> <description>CMS Repeated Authentication Login failure event.</description> </rule> <rule id="100007" level="5"> <if_sid>100000</if_sid> <status>^ERROR</status> <description>CMS General error event.</description> <group>cms_error</group> </rule> <rule id="100008" level="10"> <if_group>cms_error</if_group> <id>^200|^201|^202|^203|^204|^205</id> <description>CMS Database error event.</description> </rule> <rule id="100009" level="10"> <if_group>cms_error</if_group> <id>^206|^207|^208|^209|^230|^231|^232|^233|^234|^235|^236|^237|^238| ^239^|240|^241|^242|^243|^244|^245|^246|^247|^248|^249</id> <description>CMS Runtime error event.</description> </rule> <rule id="100010" level="0"> <if_sid>100000</if_sid> <status>^INFORMATION</status> <description>CMS General informational event.</description> <group>cms_information</group> </rule> <rule id="100011" level="5"> <if_group>cms_information</if_group> <id>^450|^451|^452|^453|^454|^455|^456|^457|^458|^459</id> <description>CMS New Content added event.</description> </rule> <rule id="100012" level="5"> <if_group>cms_information</if_group> <id>^460|^461|^462|^463|^464|^465|^466|^467|^468|^469</id> <description>CMS Existing Content modified event.</description> </rule> <rule id="100013" level="5"> <if_group>cms_information</if_group> <id>^470|^471|^472|^473|^474|^475|^476|^477|^478|^479</id> <description>CMS Existing Content deleted event.</description> </rule> <rule id="100014" level="5"> <if_group>cms_information</if_group> <id>^445|^446</id> <description>CMS User created event.</description> </rule> <rule id="100015" level="5"> <if_group>cms_information</if_group> <id>^447|449</id> <description>CMS User deleted event.</description> </rule> </group>
セキュリティログ監視 ルールの重大度レベルと推奨される使用
| レベル | 説明 | 備考 |
| レベル0 | 無視され、処理は行われない | 主に誤判定を回避するために使用されます。これらのルールは、他のすべてのルールより先に検索され、セキュリティとは無関係のイベントが含まれます。 |
| レベル1 | 事前定義された使用法はなし | |
| レベル2 | システムの優先度の低い通知 | セキュリティとは無関係のシステム通知またはステータスメッセージ。 |
| レベル3 | 成功した/承認されたイベント | 成功したログイン試行、ファイアウォール許可イベントなど。 |
| レベル4 | システムの優先度の低いエラー | 不正な設定または未使用のデバイス/アプリケーションに関連するエラー。セキュリティとは無関係であり、通常は初期設定のインストールまたはソフトウェアのテストが原因で発生します。 |
| レベル5 | ユーザによって生成されたエラー | パスワードの見落とし、アクションの拒否など。これらのメッセージは通常、セキュリティに関連しません。 |
| レベル6 | 関連性の低い攻撃 | システムに脅威を及ぼさないワームまたはウイルスを示します (Linuxサーバを攻撃するWindowsワームなど)。また、頻繁にトリガされるIDSイベントおよび一般的なエラーイベントも含まれます。 |
| レベル7 | 事前定義された使用法はなし | |
| レベル8 | 事前定義された使用法はなし | |
| レベル9 | 無効なソースからのエラー | 不明なユーザとしてのログインの試行または無効なソースからのログインの試行が含まれます。特にこのメッセージが繰り返される場合は、セキュリティとの関連性がある可能性があります。また、adminまたはrootアカウントに関するエラーも含まれます。 |
| レベル10 | ユーザによって生成された複数のエラー | 複数の不正なパスワードや複数のログイン失敗などを含めてください。それらは攻撃を示している可能性もありますし、単にユーザが資格情報を忘れた可能性もあります。 |
| レベル11 | 事前定義された使用法はなし | |
| レベル12 | 重要度の高いイベント | システムやカーネルなどからのエラーまたは警告メッセージを含めます。これらは特定のアプリケーションに対する攻撃を示している可能性があります。 |
| レベル13 | 通常と異なるエラー (重要度: 高) | バッファオーバーフローの試行などの一般的な攻撃パターン、通常のSyslogメッセージ長の超過、または通常のURL文字列長の超過。 |
| レベル14 | 重要度の高いセキュリティイベント | 通常、複数の攻撃ルールと攻撃の兆候が組み合わさったもの。 |
| レベル15 | 攻撃の成功 | 誤判定の可能性はほとんどありません。すぐに対処が必要です。 |
strftime () 変換指定子
| 指定子 | 説明 |
| %a | 省略された曜日名 (例: 木) |
| %A | 曜日の完全な名前 (例: 木曜日) |
| %b | 省略された月名 (例: Aug) |
| %B | 月の完全な名前 (例: 8月) |
| %c | 日付と時刻の表記 (例: Thu Sep 22 12:23:45 2007) |
| %d | 月の日 (01 - 31) (例: 20) |
| %H | 24時間形式の時刻 (00 - 23) (例: 13) |
| %I | 12時間形式の時 (01 - 12)(例: 02) |
| %j | 年の日数 (001 - 366) (例: 235) |
| %m | 月を10進数で表したもの (01 - 12)(例: 02) |
| %M | 分 (00 - 59) (例えば、12) |
| %p | 午前または午後の指定 (例: AM) |
| %S | 秒 (00 - 61) (例: 55) |
| %U | 最初の日曜日を週の初日とする週番号 (00 - 53) (例: 52) |
| %w | 日曜日を0とする10進数の曜日 (0 - 6) (例: 2) |
| %W | 最初の月曜日を週の初日とする週番号 (00 - 53) (例: 21) |
| %x | 日付表記 (例: 02/24/79) |
| %X | 時間表記 (例: 04:12:51) |
| %y | 年、西暦の下2桁 (00 - 99)(例: 76) |
| %Y | 年 (例: 2008) |
| %Z | タイムゾーン名または略語 (例: EST) |
| %% | % 記号 (例えば、%) |
詳細については、以下を参照してください。
セキュリティログ監視 ルールを調べる
セキュリティログ監視ルールは、Deep Security Managerのポリシー > 共通オブジェクト > ルール > セキュリティログ監視ルールにあります。
セキュリティログ監視 のルール構造とイベント照合プロセス
次の図は、Microsoft Exchangeセキュリティログ監視ルールのプロパティウィンドウの構成タブの内容を示しています。
以下はルール構造です:
- 3800 - Grouping of Exchange Rules - Default - ignore
- 3801 - Email rcpt is not valid (invalid account) - Default - Medium (5)
- 3851 - Multiple email attempts to an invalid account - Default - High (10)
- Frequency (1 to 128) - 10
- Time Frame (1 to 86400) - 120
- Time to ignore this rule after triggering it once - to avoid excessive logs (1 to 86400) - 120
- 3851 - Multiple email attempts to an invalid account - Default - High (10)
- 3802 - Email 500 error code - Default - Medium (4)
- 3852 - Email 500 error code (spam) - Default - High (9)
- Frequency (1 to 128) - 12
- Time Frame (1 to 86400) - 120
- Time to ignore this rule after triggering it once - to avoid excessive logs (1 to 86400) - 240
- 3852 - Email 500 error code (spam) - Default - High (9)
- 3801 - Email rcpt is not valid (invalid account) - Default - Medium (5)
セキュリティログ監視エンジンはログイベントをこの構造に適用し、一致があるかどうかを確認します。例えば、Exchangeイベントが発生し、このイベントが無効なアカウントへのメール受信である場合、イベントは行3800と一致します (これはExchangeイベントであるためです)。その後、イベントは行3800のサブルール3801および3802に適用されます。
これ以上の一致がない場合、この一致のカスケードは3800で停止します。3800は無視の重大度レベルであるため、セキュリティログ監視イベントは記録されません。
しかし、無効なアカウントへのメール受信は3800のサブルールの1つ、サブルール3801に一致します。サブルール3801の重大度レベルは中 (4) です。ここで一致が停止した場合、重大度レベルが中 (4) のセキュリティログ監視イベントが記録されます。
しかし、イベントに適用される別のサブルールがあります: サブルール3851です。サブルール3851は、3つの属性を持ち、同じイベントが過去120秒以内に10回発生した場合に一致します。その場合、セキュリティログ監視イベントが重大度高 (9) で記録されます。無視属性は、次の120秒間、サブルール3801に一致する個々のイベントを無視するようにサブルール3851に指示します。これはノイズを減らすのに役立ちます。
サブルール3851のパラメータが一致したと仮定すると、セキュリティログ監視イベントが重大度高 (9) で記録されました。
Microsoft Exchangeルールのオプションタブを確認すると、Deep Security Managerは重大度レベルが中 (4) のサブルールが一致した場合にアラートを発することがわかります。この例ではその通りなので、アラートが発せられます (このルールがイベントを記録したときにアラートを出すが選択されている場合)。
重複するサブルール
一部のセキュリティログ監視ルールには重複するサブルールがあります。例を見るには、Microsoft Windows Eventsルールを開き、設定タブを選択してください。サブルール18125 (リモートアクセスログイン失敗) がサブルール18102と18103の下に表示されることに注意してください。また、どちらの場合もサブルール18125には重大度の値がなく、「以下を参照」とだけ表示されることに注意してください。
重複して表示されるのではなく、ルール18125は、[設定] 画面の下部に1回だけ表示されています。
