ポリシーで使用するセキュリティログ監視ルールの定義

OSSECのセキュリティログ監視エンジンがDeep Securityに統合されています。このエンジンにより、コンピュータで実行されているOSおよびアプリケーションで生成されたログとイベントをDeep Securityで検査できるようになりました。Deep Security Managerには、コンピュータまたはポリシーに割り当てることができる、標準のOSSECのセキュリティログ監視ルールセットが付属しています。要件に合う既存ルールが存在しない場合は、カスタムルールを作成することもできます。

トレンドマイクロが発行するセキュリティログ監視ルールは編集できませんが、コピーしたものを編集することはできます。
1台以上のコンピュータに割り当てられたセキュリティログ監視ルール、またはポリシーの一部であるセキュリティログ監視ルールは削除できません。

このトピックの内容:

新しいセキュリティログ監視ルールを作成する

  1. Deep Security Managerで、[ポリシー][共通オブジェクト][ルール][セキュリティログ監視ルール] に進みます。
  2. [新規][新しいセキュリティログ監視ルール] をクリックします。
  3. [一般] タブで、ルールの名前と説明を入力します (説明は省略できます)。
  4. [コンテンツ] タブで、ルールを定義します。ルールを定義する一番簡単な方法は、[基本ルール] を選択し、表示されるオプションを使用してルールを定義する方法です。さらにカスタマイズが必要な場合は、[カスタム (XML)] を選択し、定義しているルールをXMLビューに切り替えることができます。[基本ルール] ビューに戻すと、[カスタム (XML)] ビューで加えた変更はすべて失われます。

    基本ルールテンプレートでは以下のオプションを使用できます。

    ルールID: ルールIDは、ルールの一意の識別子です。OSSECでは、ユーザ指定のルール用に100000~109999を定義します (このフィールドには、新しい一意のルールIDがDeep Security Managerによって事前に入力されています)。

    レベル: ルールにレベルを割り当てます。ゼロ (0) は、ルールによってイベントが記録されないことを示しますが、このルールを監視する他のルールが発生する可能性があります (下記に示す依存関係のセクションを参照)。

    グループ: (オプション) 1つ以上のカンマ区切りのグループにルールを割り当てます。これが便利なのは、ある1つのルールの発生時に発生する複数のルール、または特定のグループに属するルールを作成した後に依存関係が使用されるときです。

    ルールの説明: (オプション) ルールの説明。

    パターン照合: これは、ルールがログ内を検索するパターンです。一致するものが検出されるとルールがトリガされます。パターン照合では、正規表現またはより簡単な文字列パターンをサポートします。「文字列パターン」というパターンの種類は正規表現よりも処理が高速ですが、サポートされるのは次に示す3つの特殊な処理のみです。

    • ^ (カレット): テキストの先頭を指定します。
    • $ (ドル記号): テキストの末尾を指定します。
    • | (パイプ): 複数のパターン間に「OR」を作成します。

    セキュリティログ監視モジュールで使用される正規表現の構文については、http://www.ossec.net/doc/syntax/regex.htmlを参照してください。

    依存関係: 別のルールへの依存関係を設定すると、現在のルールでは、このエリアに指定したルールがトリガされた場合にもイベントが記録されます。

    [頻度] は、ルールがトリガされるまでの特定の期間内にルールを照合する必要のある回数です。

    [期間] は、イベントを記録するためにルールを特定の回数 (上記の頻度) トリガするまでの期間 (秒数) です。

  5. [コンテンツ] タブが表示されるのは、ユーザ自身が作成するセキュリティログ監視ルールについてのみです。トレンドマイクロが発行するセキュリティログ監視ルールの場合は、代わりに [設定] タブが表示されます。このタブには、セキュリティログ監視ルールの設定オプションが表示されます。
  6. [ファイル] タブで、ルールによって監視するファイルのフルパスを入力し、そのファイルの種類を指定します。
  7. [オプション] タブの [アラート] セクションで、このルールでアラートをトリガするかどうかを選択します。

    [最小のアラート重要度] 設定は、「基本」テンプレートを使用して作成できないルール内に「複数のルール」を作成済みの場合にのみ使用されます。ただし、「基本」テンプレートを使用してルールを作成した後で、ルールのXMLを編集し、重要度の異なるルールをそのXMLに追加する場合は、[最小のアラート重要度] 設定を使用して、アラートをトリガする複数のルールから最低限の重要度を設定できます。

  8. [割り当て対象] タブには、このセキュリティログ監視ルールを使用するポリシーとコンピュータが一覧表示されています。新しいルールは作成中であるため、まだ割り当てられていません。
  9. [OK] をクリックします。このルールをポリシーとコンピュータに割り当てる準備ができました。

デコーダ

セキュリティログ監視ルールは、変更を監視するファイルのリストおよびトリガするルール用の条件のセットで構成されています。セキュリティログ監視エンジンが監視対象のログファイルで変更を検出すると、その変更はデコーダによって解析されます。デコーダは、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への送信 (ポリシーエディタまたはコンピュータエディタの [設定]→[SIEM] タブの [セキュリティログ監視イベントの転送 (Agent/Applianceから)] エリアで設定できます)

サブルール

1つのセキュリティログ監視ルールには複数のサブルールを含めることができます。これらのサブルールには、アトミックとコンポジットという2つの種類があります。アトミックルールは1つのイベントを評価し、コンポジットルールは複数のイベントを確認して、頻度、繰り返し、およびイベント間の相関関係を評価できます。

グループ

各ルールまたはルールのグループは、<group></group> エレメント内に定義する必要があります。属性名には、このグループに追加するルールを含めてください。次の例では、Syslogとsshdのルールをグループに含めています。

<group name="syslog,sshd,">
</group>
グループ名の末尾にカンマが付いていることに注意してください。末尾のカンマは、<if_group></if_group> タグを使用して、このルールに別のサブルールを条件付きで追加する場合に必要です。
セキュリティログ監視ルールのセットがAgentに送信されると、そのAgent上のセキュリティログ監視エンジンは割り当てられた各ルールからXMLデータを取得し、基本的に1つの長いセキュリティログ監視ルールにアセンブルします。一部のグループ定義は、トレンドマイクロによるすべてのセキュリティログ監視ルールで共通です。そのため、トレンドマイクロには「Default Rules Configuration」と呼ばれるルールがあります。このルールはこれらのグループを定義し、常に他のトレンドマイクロのルールとともに割り当てられます(割り当てるルールに「Default Rules Configuration」ルールを選択しない場合は、「Default Rules Configuration」ルールが自動的に割り当てられることを知らせる通知が表示されます)。独自のセキュリティログ監視ルールを作成し、トレンドマイクロのルールが1つも割り当てられていないコンピュータに割り当てる場合は、作成したルールに「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」は「ログイン拒否」と表示されます。カスタムルールのリストには、ルール内に表示されるグループ名が表示されます。

説明

<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」がログの先頭にない場合でも、セキュリティログ監視デコーダはログを複数のセクションに分割します(上記の「デコーダ」を参照)。これらのセクションの1つは、ログ全体を示す「full_log」ではなく、ログのメッセージ部分を示す「log」です。

次の表は、サポートされている正規表現の構文一覧です。

正規表現の構文 説明
\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」

条件文

ルールの評価では、trueと評価される他のルールを条件とすることができます。<if_sid></if_sid> タグでは、タグで識別されたルールがtrueと評価された場合にのみこのサブルールを評価するようにセキュリティログ監視エンジンを設定します。次の例では、100123、100124、および100125の3つのルールを示します。<if_sid></if_sid> タグを使用して、ルール100124と100125がルール100123の子になるように変更されています。

<group name="syslog,sshd,">
	<rule id="100123" level="2">
		<decoded_as>sshd</decoded_as>
		<description>Logging every decoded sshd message</description>
	</rule>
	<rule id="100124" level="7">
		<if_sid>100123</if_sid>
		<match>^Failed password</match>
		<group>authentication_failure</group>
		<description>Failed SSHD password attempt</description>
	</rule>
	<rule id="100125" level="3">
		<if_sid>100123</if_sid>
		<match>^Accepted password</match>
		<group>authentication_success</group>
		<description>Successful SSHD password attempt</description>
	</rule>
</group>

評価の階層

<if_sid></if_sid> タグでは、基本的に階層型のルールセットを作成します。つまり、<if_sid></if_sid> タグをルールに含めることにより、そのルールは <if_sid></if_sid> タグで参照されるルールの子になります。ログにルールを適用する前に、セキュリティログ監視エンジンは <if_sid></if_sid> タグを評価して親ルールと子ルールの階層を作成します。

階層型の親子構造を使用すると、ルールの効率を向上させることができます。親ルールがtrueと評価されない場合、セキュリティログ監視エンジンはその親の子を無視します。
<if_sid></if_sid> タグを使用することで、まったく別のセキュリティログ監視ルール内のサブルールを参照することもできますが、後からルールを確認するのが非常に難しくなるため、このような指定方法はお勧めしません。

次の表は、使用可能なアトミックルールの条件指定のオプションを一覧表示しています。

タグ 説明 備考
match パターン イベント (ログ) に対して照合される任意の文字列。
regex 正規表現 イベント (ログ) に対して照合される任意の正規表現。
decoded_as 文字列 事前一致する任意の文字列。
srcip 送信元のIPアドレス 送信元のIPアドレスとしてデコードされる任意のIPアドレス。IPアドレスの前に「!」を使用すると、指定した以外のIPアドレスを意味します。
dstip 送信先のIPアドレス 送信先の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属性を前の例に追加しています。この属性では、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 ルールレベル 指定された重要度レベルに一致するルールの子ルールとしてこのルールを追加します。
description 文字列 ルールの説明。
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) のいずれかを指定する追加のルールオプション。

コンポジットルール

アトミックルールは、1つのログエントリを確認します。複数のエントリを関連付けるには、コンポジットルールを使用する必要があります。コンポジットルールは、現在のログを受信済みのログと照合します。コンポジットルールには、2つの追加オプションが必要です。frequencyオプションでは、ルールによってアラートが生成されるまでのイベント/パターンの発生回数を指定します。timeframeオプションでは、セキュリティログ監視エンジンがどのくらい前までさかのぼってログを検索する必要があるか (秒単位) をエンジンに通知します。すべてのコンポジットルールの構造は次のようになります。

<rule id="100130" level="10" frequency="x" timeframe="y">
</rule> 

たとえば、10分以内にパスワードを5回間違えたら重要度の高いアラートを作成するコンポジットルールを作成できます。<if_matched_sid></if_matched_sid> タグを使用すると、アラートを作成する新しいルールに対して、目的の頻度および期間内にトリガする必要のあるルールを指定できます。次の例では、イベントの5つのインスタンスが発生したらトリガするようにfrequency属性が設定されています。また、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>5 Failed passwords within 10 minutes</description>
</rule>

実際の使用例

Deep Securityには、数十種類の一般的なアプリケーションに対応した、多数の初期設定のセキュリティログ監視ルールが含まれています。新しいルールは、セキュリティアップデートを使用して定期的に追加できます。セキュリティログ監視ルールでサポートされるアプリケーションが増えても、サポート対象外のアプリケーションやカスタムアプリケーション用のカスタムルールを作成することが必要な場合があります。

ここでは、Microsoft SQLデータベースをデータリポジトリとして使用するMicrosoft Windows Server IIS .Netプラットフォームでホストされる、カスタムCMS (コンテンツ管理システム) の作成について説明します。

最初に、次に示すアプリケーションログの属性を特定します。

  1. アプリケーションログを記録する場所
  2. ログファイルのデコードに使用できるセキュリティログ監視デコーダ
  3. ログファイルメッセージの一般的な形式

ここで示すカスタムCMSの例では、次のようになります。

  1. Windowsイベントビューア
  2. Windowsイベントログ (eventlog)
  3. Windowsイベントログ形式 (次のコア属性を使用)
    • ソース: CMS
    • カテゴリ: なし
    • イベント: <アプリケーションイベント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)

これは、ルール作成に役立つ基本的な構造です。次に、Deep Security Managerで新しいセキュリティログ監視ルールを作成します。

新しいCMSセキュリティログ監視ルールを作成するには

  1. Deep Security Managerで、[ポリシー]→[共通オブジェクト]→[ルール]→[セキュリティログ監視ルール] に進み、[新規] をクリックし、[新しいセキュリティログ監視ルールのプロパティ] 画面を表示します。
  2. 新しいルールの名前と説明を指定し、[コンテンツ] タブをクリックします。
  3. 新しいカスタムルールを作成する最も簡単な方法は、基本ルールテンプレートを使用することです。[基本ルール] オプションを選択します。
  4. [ルールID] フィールドには、未使用のID番号 (100,000以上) が自動的に入力されます。これは、カスタムルール用に予約されたIDです。
  5. [レベル][低 (0)] に設定します。
  6. ルールに適切なグループ名を指定します。ここでは「cms」とします。
  7. ルールの簡単な説明を入力します。

  8. 次に、[カスタム (XML)] オプションを選択します。「基本」ルール用に選択したオプションがXMLに変換されます。

  9. [ファイル] タブをクリックし、[ファイルの追加] ボタンをクリックして、ルールを適用するアプリケーションログファイルおよびログの種類を追加します。ここでは、「Application」、およびファイルの種類として「eventlog」を選択します。

    eventlogは、Deep Security固有のファイルの種類です。この場合、ログファイルの場所と名前を指定する必要はありません。その代わりに、Windowsイベントビューアに表示されるログの名前を入力してください。ファイルの種類がeventlogの場合の他のログの名前は、「Security」、「System」、「Internet Explorer」、またはWindowsイベントビューアに表示されるその他のセクションになる可能性があります。その他のファイルの種類の場合は、ログファイルの場所と名前が必要です(ファイル名の照合にはC/C++ strftime() 変換指定子を使用できます。その他の役立つ変換指定子については、以降の表を参照してください)。
  10. [OK] をクリックして基本ルールを保存します。
  11. 作成された基本ルールのカスタム (XML) を使用すると、以前に特定されたログのグループに基づいて、グループへの新しいルールの追加を開始することができます。基本ルールの条件は初期ルールに設定します。次の例では、ソース属性が「CMS」のWindowsイベントログが、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>
    
  12. 次に、特定されたロググループから後続のルールを作成します。次の例では、認証とログインの成功および失敗を特定し、イベント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 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>
  13. 次に、設定済みのルールを使用して、任意のコンポジットルールまたは相関ルールを追加します。次の例は、重要度の高いコンポジットルールを示しています。このルールは、ログインの失敗が10秒間に5回繰り返されたインスタンスに適用されます。
    <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>
  14. すべてのルールの重要度レベルが適切かどうかを確認します。たとえば、エラーログの重要度はレベル5以上でなければなりません。情報ルールの重要度は低くなります。
  15. 最後に、新しく作成されたルールを開き、[設定] タブをクリックして、カスタムルールの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 曜日の省略名 (例: Thu)
%A 曜日の正式名 (例: Thursday)
%b 月の省略名 (例: Aug)
%B 月の正式名 (例: August)
%c 日時形式 (例: Thu Sep 22 12:23:45 2007)
%d 月初から数えた日 (01~31) (例: 20)
%H 24時間形式の時刻 (00~23) (例: 13)
%I 12時間形式の時刻 (00~12) (例: 02)
%j 年初から数えた日 (001~366) (例: 235)
%m 10進表記の月 (01~12) (例: 02)
%M 分 (00~59) (例: 12)
%p AMまたはPMの指定 (例: AM)
%S 秒 (00~61) (例: 55)
%U 1週目の最初の日を最初の日曜とした場合の週番号 (00~53) (例: 52)
%w 日曜を0とした場合の10進表記の曜日 (0~6) (例: 2)
%W 1週目の最初の日を最初の月曜とした場合の週番号 (00~53) (例: 21)
%x 日付形式 (例: 02/24/79)
%X 時刻形式 (例: 04:12:51)
%y 年の末尾2桁 (00~99) (例: 76)
%Y 年 (例: 2008)
%Z タイムゾーン名または省略形 (例: EST)
%% %記号 (例: %)

詳細については、次のWebサイトを参照してください。

www.php.net/strftime
www.cplusplus.com/reference/clibrary/ctime/strftime.html