Deep Security 11のサポートは終了しています。バージョンセレクタ（上記）を使用して、より新しいバージョンのヘルプセンターを表示します。

本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。リンク切れなどお気づきの点がございましたら、トレンドマイクロサポート窓口までご連絡ください。

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

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

トレンドマイクロが発行するセキュリティログ監視ルールは編集できませんが、コピーしたものを編集することはできます。

1台以上のコンピュータに割り当てられたセキュリティログ監視ルール、またはポリシーの一部であるセキュリティログ監視ルールは削除できません。

セキュリティログ監視 ルールを作成するには、次の基本手順を実行します。

セキュリティログ監視 モジュールの概要については、 セキュリティログ監視によるログの分析を参照してください。

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

  1. Deep Security Managerで、[ポリシー]→[共通オブジェクト]→[ルール]→[セキュリティログ監視ルール] に進みます。
  2. [新規]→[新しいセキュリティログ監視ルール] をクリックします。
  3. [一般] タブで、ルールの名前と説明を入力します (説明は省略できます)。

  4. [コンテンツ] タブで、ルールを定義します。ルールを定義する一番簡単な方法は、[基本ルール] を選択し、表示されるオプションを使用してルールを定義する方法です。さらにカスタマイズが必要な場合は、[カスタム (XML)] を選択し、定義しているルールをXMLビューに切り替えることができます。

    [基本ルール] ビューに戻すと、[カスタム (XML)] ビューで加えた変更はすべて失われます。

    XMLベースの言語を使用した独自のセキュリティログ監視ルールの作成の詳細については、OSSECのドキュメントを参照するか、サポート担当者に問い合わせてください。

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

  • ルールID: ルールIDは、ルールの一意の識別子です。OSSECでは、ユーザ指定のルール用に100000～109999を定義しますこのフィールドには、新しい一意のルールIDがDeep Security Managerによって事前に入力されています。
  • レベル: ルールにレベルを割り当てます。ゼロ (0) は、ルールによってイベントが記録されないことを示しますが、このルールを監視する他のルールが発生する可能性があります
  • グループ: 1つ以上のカンマ区切りのグループにルールを割り当てます。これが便利なのは、ある1つのルールの発生時に発生する複数のルール、または特定のグループに属するルールを作成した後に依存関係が使用されるときです。
  • ルールの説明: ルールの説明。

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

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

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

  • 依存関係: 別のルールへの依存関係を設定すると、現在のルールでは、このエリアに指定したルールがトリガされた場合にもイベントが記録されます。
  • [頻度] は、ルールがトリガされるまでの特定の期間内にルールを照合する必要のある回数です。
  • [期間] は、イベントを記録するためにルールを特定の回数 (上記の頻度) トリガするまでの期間 (秒数) です。
[ Content ]タブは、自分で作成した[ログ検査]ルールに対してのみ表示されます。トレンドマイクロが発行するログ検査ルールでは、[ Configuration ]タブが表示され、[ログ検査ルール]の設定オプションが表示されます（).が設定されている場合）。
  1. [ファイル] タブで、ルールによって監視するファイルのフルパスを入力し、そのファイルの種類を指定します。
  2. [オプション] タブの [アラート] セクションで、このルールでアラートをトリガするかどうかを選択します。

    最小のアラート重要度 は、基本ルールまたはカスタム（XML）テンプレートを使用してルールに対してアラートをトリガする最小の重大度レベルを設定します。

    基本ルールテンプレートは、一度に1つのルールを作成します。1つのテンプレートに複数のルールを書き込むには、カスタム（XML）テンプレートを使用できます。カスタム（XML）テンプレート内でレベルが異なる複数のルールを作成する場合は、[ 最小のアラート重要度 ]設定を使用して、そのテンプレート内のすべてのルールに対するアラートをトリガする最小の重要度を選択できます。
  3. [ 割り当て対象 に割り当てられました]タブには、この セキュリティログ監視 ルールを使用しているポリシーとコンピュータが表示されます。新しいルールは作成中であるため、まだ割り当てられていません。
  4. [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データを取得し、基本的に単一の長い セキュリティログ監視 ルールになるように組み込みます。グループ定義の中には、トレンドマイクロが作成したすべての セキュリティログ監視 ルールに共通のものがあります。そのため、トレンドマイクロには「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」は「ログイン拒否」と表示されます。カスタムルールのリストには、ルール内に表示されるグループ名が表示されます。

説明

<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つのオプションが必要です. 頻度 オプションは、イベントまたはパターンがアラートを生成するまでに何回発生する必要があるかを指定します。また、 の時間枠の オプションは、 セキュリティログ監視 エンジンにどれくらいの時間（秒）遅れて通知します。以前のログを検索する必要があります。すべてのコンポジットルールの構造は次のようになります。

<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)

これは、ルール作成に役立つ基本的な構造です。次に、 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サイトを参照してください。

https://www.php.net/manual/en/function.strftime.php
www.cplusplus.com/reference/clibrary/ctime/strftime.html

セキュリティログ監視ルールの確認

セキュリティログ監視 ルールはDeep Security Managerの Policies> Common Objects> Rules> セキュリティログ監視 Rulesにあります。

セキュリティログ監視 のルール構造とイベント照合プロセス

この画面ショットは、「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
    • 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

セキュリティログ監視 エンジンは、ログイベントをこの構造に適用し、一致が発生したかどうかを確認します。たとえば、Exchangeイベントが発生し、そのイベントが無効なアカウントに対するメールの受信である場合、このイベントは3800の行と一致します (3800の行がExchangeイベントであるため)。また、同じイベントが、3800の行のサブルールである3801の行と3802の行にも適用されます。

これ以上の一致がない場合、この一致の「連鎖」は3800の行で停止します。3800の重大度は「Ignore", 」なので、 セキュリティログ監視 イベントは記録されません。

ただし、無効なアカウントに対するメールの受信は、3800の行のサブルールの1つ、サブルール3801に一致しています。サブルール3801の重要度は「Medium (4)」です。ここで一致が停止した場合、重大度レベルが[中（4)" ）の セキュリティログ監視 イベントが記録されます。

しかし、このイベントに該当するルールは他にもあります。サブルール3851です。同じイベントが過去120秒以内に10回発生した場合、サブルール3851とその3つの属性が一致するでしょう。その場合は、重大度が「高」（9)" ）の セキュリティログ監視 イベントが記録されます。(「無視」属性は、サブルール3851に、サブルール3801と一致する個々のイベントを今後120秒間無視するように指示しています。これは、「ノイズ」の低減に役立ちます)。

サブルール3851のパラメータが一致したと仮定すると、重大度が「高」（9)" ）の セキュリティログ監視 イベントが記録されます。

Mail Server - Microsoft Exchangeルールの [オプション] タブを調べてみると、重要度が「中 (4)」のサブルールが一致していれば、Deep Security Managerによってアラートが発令されることがわかります。この例はこれに該当するため、アラートが発令されます ([このルールによってイベントが記録された場合にアラート] が選択されている場合)。

重複しているサブルール

一部の セキュリティログ監視 ルールに重複するサブルールがあります。例を見るには、[Microsoft Windows Events] ルールを開き、[設定] タブをクリックします。サブルール18125 (Remote access login failure) が、サブルール18102と18103の下に表示されています。また、どちらの場合も、サブルール18125には重要度の値が示されておらず、単に [See Below] と表示されています。

重複して表示されるのではなく、ルール18125は、[設定] 画面の下部に1回だけ表示されています。

お問い合わせ
お問い合わせ
サポート情報
サポート情報
セキュリティ情報
セキュリティ情報