OSSEC セキュリティログ監視 エンジンはエージェントに統合されており、コンピュータで実行されているオペレーティングシステムとアプリケーションによって生成されたログとイベントを
Workload Security で監視する機能を提供します。Workload Security には、コンピュータまたはポリシーに割り当てることができるOSSEC
セキュリティログ監視 ルールの標準セットが付属しています。要件に合う既存ルールが存在しない場合は、カスタムルールを作成することもできます。
トレンドマイクロが発行したセキュリティログ監視ルールは編集できません (ただし、複製して編集することはできます)。
1台以上のコンピュータに割り当てられたセキュリティログ監視ルール、またはポリシーの一部であるセキュリティログ監視ルールは削除できません。
セキュリティログ監視 ルールを作成するには、次の基本手順を実行します。
- 新しいセキュリティログ監視ルールを作成
- デコーダー
- サブルール
- 実際の例
- セキュリティログ監視ルールの重大度レベルとその推奨使用法
- strftime () 変換指定子
- セキュリティログ監視ルールを調べる
セキュリティログ監視モジュールの概要については、ログの分析を参照してください。
新しい セキュリティログ監視 ルールを作成します
-
Workload Securityコンソールで、に移動します。
-
をクリックします。
-
[一般]タブで、ルールの名前と任意の説明を入力してください。
-
[コンテンツ]タブはルールを定義する場所です。ルールを定義する最も簡単な方法は、[Basic Rule]を選択し、提供されているオプションを使用してルールを定義することです。さらにカスタマイズが必要な場合は、[Custom (XML)]を選択して、定義しているルールのXMLビューに切り替えることができます。カスタム (XML) ビューで行った変更は、[Basic Rule] ビューに戻すと失われます。
XMLベースの言語を使用して独自のログ検査ルールを書くためのさらなる支援については、OSSECのドキュメントを参照するか、サポートプロバイダーにお問い合わせください。
ベーシックルールテンプレートでは、次のオプションを使用できます。
-
ルールID: ルールIDはルールの一意の識別子です。OSSECは100000 - 109999をユーザ定義ルールの領域として定義しています。Workload Securityは新しい一意のルールIDでフィールドを事前入力します。
-
レベル: ルールにレベルを割り当てます。ゼロ (0) は、ルールがイベントを記録しないことを意味しますが、このルールを監視する他のルールが発動する可能性があります。
-
グループ: ルールを1つ以上のカンマ区切りのグループに割り当てます。これは、依存関係が使用される場合に便利です。ルールの発動に基づいて発動するルールや、特定のグループに属するルールを作成することができます。
-
Rule Description: ルールの説明。
-
Pattern Matching: これはルールがログ内で探すパターンです。ルールは一致した場合にトリガーされます。パターンマッチングは正規表現またはより簡単な文字列パターンをサポートします。文字列パターンのパターンタイプは正規表現よりも高速ですが、3つの特別な操作のみをサポートします。
- ^ (caret): テキストの開始を指定します。
- $ (dollar sign): テキストの終了を指定します。
- | (pipe): 複数のパターン間で OR を作成するため。ログ検査モジュールで使用される正規表現の構文については、https://www.ossec.net/docs/syntax/regex.html を参照してください。
-
Dependency: 別のルールに依存関係を設定すると、この領域で指定されたルールがトリガーされた場合にのみ、イベントがログに記録されます。
-
頻度: ルールが発動される前に特定の時間枠内でルールが一致する必要がある回数。
-
Time Frame: ルールがイベントを記録するために一定回数 (頻度) トリガーされる必要がある秒単位の期間。
[コンテンツ]タブは、ユーザー自身が作成したログインスペクションルールにのみ表示されます。トレンドマイクロによって発行されたログインスペクションルールには代わりに[設定]タブが表示され、ログインスペクションルールの設定オプション (ある場合) が表示されます。
-
[ファイル]タブで、ルールがモニタするファイルのフルパスを入力し、ファイルの種類を指定してください。グロブ文字はファイル名で使用する場合のみサポートされており、パスの一致にはサポートされていません。例えば、
/home/user1/testlog*.txt
は有効ですが、/home/*/testlog1.txt
は無効です。 -
[オプション] タブの [警告] セクションで、このルールが Workload Security でアラートをトリガーするかどうかを選択します。アラートの最小重大度は、基本ルールまたはカスタム (XML) テンプレートを使用して作成されたルールのアラートをトリガーする最小重大度レベルを設定します。基本ルールテンプレートは、一度に1つのルールを作成します。1つのテンプレートで複数のルールを作成するには、カスタム (XML) テンプレートを使用できます。カスタム (XML) テンプレート内で異なるレベルの複数のルールを作成する場合、[Alert Minimum Severity] 設定を使用して、そのテンプレート内のすべてのルールに対してアラートをトリガーする最小の重大度を選択できます。
-
[割り当て対象]タブには、このログインスペクションルールを使用しているポリシーとコンピュータが一覧表示されます。新しいルールを作成しているため、まだ割り当てられていません。
-
[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]エリアで設定可能です。
- イベントはWorkload Securityに送信できます。 タブの[セキュリティログ監視 Syslog Configuration]設定で構成可能です。
サブルール
1つの セキュリティログ監視 ルールに複数のサブルールを含めることができます。これらのサブルールには、アトミックとコンポジットという2つの種類があります。アトミックルールは1つのイベントを評価し、コンポジットルールは複数のイベントを確認して、頻度、繰り返し、およびイベント間の相関関係を評価できます。
グループ
各ルール、またはルールのグループは、
<group></group>
要素内で定義する必要があります。属性名には、このグループに含めたいルールを含める必要があります。次の例では、グループにsyslogとsshdのルールが含まれていることを示しています。<group name="syslog,sshd,"> </group>
グループ名の末尾のカンマに注意してください。末尾のカンマは、
<if_group></if_group>
タグを使用して、このルールに別のサブルールを条件付きで追加する場合に必要です。一連のセキュリティログ監視ルールがエージェントに送信されると、エージェントのセキュリティログ監視エンジンは割り当てられた各ルールからXMLデータを取得し、実質的に1つの長いセキュリティログ監視ルールにまとめます。一部のグループ定義は、トレンドマイクロが作成したすべてのセキュリティログ監視ルールに共通です。このため、トレンドマイクロでは初期設定ルール設定と呼ばれるルールを用意しています。このルールでは、これらのグループを定義し、他のトレンドマイクロルールとともに常に割り当てられます。割り当てるルールを選択し、[初期設定のルール設定]
ルールも選択していない場合は、ルールが自動的に割り当てられることを通知するメッセージが表示されます。 独自のセキュリティログ監視ルールを作成し、トレンドマイクロが作成したルールを割り当てずにコンピュータに割り当てる場合は、[初期設定のルールの設定]
ルールの内容を新しいルールにコピーするか、[初期設定のルールの設定] ルールを選択して割り当てる必要があります。
ルール、ID、およびレベル
グループには必要なだけのルールを含めることができます。ルールは
<rule></rule>
要素を使用して定義され、少なくとも2つの属性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>
タグを使用して、親グループ内に追加のサブグループを定義できます。このサブグループは、以下の表に記載されているグループのいずれかを参照できます。
グループの種類
|
グループ
|
説明
|
攻撃の予兆
|
接続試行
web_scan 再確認
|
接続試行
ウェブ検索
一般検索
|
認証制御
|
認証成功
認証に失敗しました
無効なログイン ログイン拒否
認証失敗
adduser アカウントが変更されました
|
Success
Failure
無効なログイン
拒否されました
複数の失敗
ユーザアカウントが追加されました
ユーザアカウントが変更または削除されました
|
攻撃/悪用
|
自動攻撃
エクスプロイト試行
無効アクセススパム
multiple_spam sql_injection
攻撃
ウイルス
|
ワーム (非標的型攻撃)
エクスプロイトパターン
無効なアクセス
スパム
複数のスパムメッセージ
SQLインジェクション
一般的な攻撃
ウイルスが検出されました
|
アクセス管理
|
access_denied access_allowed unknown_resource firewall_drop multiple_drops client_misconfig
client_error
|
アクセス拒否
アクセスが許可されています
存在しないリソースへのアクセス
ファイアウォールドロップ
複数のファイアウォールドロップ
クライアントの誤設定
クライアントエラー
|
ネットワーク制御
|
new_host
IPスプーフィング
|
新しいコンピュータが検出されました
ARPスプーフィングの可能性
|
システム監視
|
サービス開始
システムエラー システムシャットダウン
ログがクリアされました
無効なリクエスト
プロミスク
ポリシーが変更されました
設定が変更されました
ディスク容量不足
時間変更
|
サービス開始
システムエラー
シャットダウン
ログがクリアされました
無効なリクエスト
インターフェースがプロミスキャスモードに切り替わりました
ポリシーが変更されました
設定が変更されました
ディスク容量が低い
時間が変更されました
|
イベントの自動タグ付けが有効になっている場合、イベントにはグループ名がラベル付けされます。トレンドマイクロが提供するセキュリティログ監視ルールは、グループをよりユーザーフレンドリーなバージョンに変更する変換テーブルを使用します。例えば、
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>
利用可能なデコーダーを表示するには、[セキュリティログ監視ルール]ページに移動し、[Decoders.]をクリックします。[1002791-Default Log Decoders]を右クリックして[プロパティ]を選択します。[設定]タブに移動し、[View 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つは
log
であり、ログ全体であるfull_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」
|
条件文
ルールの評価は、他のルールが真と評価された場合に条件付きで行うことができます。
<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>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アドレスを否定するには
! を使用します。 |
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
属性を前の例に追加しています。この属性では、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) のいずれかを指定する追加のルールオプション。
|
複合ルール
Atomicルールは単一のログエントリを調査します。複数のエントリを関連付けるには、複合ルールを使用する必要があります。複合ルールは、現在のログと既に受信したログを一致させることを目的としています。複合ルールには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>5 Failed passwords within 10 minutes</description> </rule>
実際の使用例
Workload Security には、数多くの一般的なアプリケーションおよび一般的なアプリケーション向けの多くの初期設定の セキュリティログ監視 ルールが含まれています。新しいルールは、セキュリティアップデートを使用して定期的に追加できます。
セキュリティログ監視 ルールでサポートされるアプリケーションのリストが増加しているにもかかわらず、サポートされていないアプリケーションまたはカスタムアプリケーションのカスタムルールを作成する必要が生じる場合があります。
ここでは、Microsoft SQL Serverデータベースをデータリポジトリとして使用するMicrosoft Windows Server IISおよび.Netプラットフォームでホストされる、カスタムCMS
(コンテンツ管理システム) の作成について説明します。
最初に、次に示すアプリケーションログの属性を特定します。
- アプリケーションログを記録する場所
- どの セキュリティログ監視 デコーダを使用してログファイルを復号できますか?
- ログファイルメッセージの一般的な形式
ここで示すカスタムCMSの例では、次のようになります。
-
Windowsイベントビューア
-
Windowsイベントログ (eventlog)
-
Windowsイベントログ形式 (次のコア属性を使用)
- ソース: CMS
- カテゴリ: なし
- イベント:
<アプリケーションイベントID>
次に、アプリケーションの機能別にログイベントのカテゴリを特定し、そのカテゴリを監視用のカスケードグループの階層に分類します。監視対象のすべてのグループでイベントを発生させる必要はなく、一致する項目を条件文として使用できます。各グループについて、ルールで照合条件として使用できるログ形式の属性を特定します。これは、すべてのアプリケーションログの、ログイベントのパターンおよび論理分類を調べて実行することもできます。
たとえば、CMSアプリケーションでは、次の機能をサポートしています. セキュリティログ監視 のルールは次のとおりです。
- CMSアプリケーションログ (ソース: CMS)
- 認証 (イベント: 100~119)
- ユーザログインの成功 (イベント: 100)
- ユーザログインの失敗 (イベント: 101)
- 管理者ログインの成功 (イベント: 105)
- 管理者ログインの失敗 (イベント: 106)
- 一般エラー (種類: エラー)
- データベースエラー (イベント: 200~205)
- ランタイムエラー (イベント: 206~249)
- アプリケーション監査 (種類: 情報)
- コンテンツ
- 新しいコンテンツの追加 (イベント: 450~459)
- 既存のコンテンツの変更 (イベント: 460~469)
- 既存のコンテンツの削除 (イベント: 470~479)
- 管理
- ユーザ
- 新しいユーザの作成 (イベント: 445~446)
- 既存のユーザの削除 (イベント: 447~449)
- ユーザ
- コンテンツ
- 認証 (イベント: 100~119)
この構造は、ルールを作成するための適切な基盤となります。次に、Workload Securityで新しいセキュリティログ監視ルールを作成します。
新しいCMSログインスペクションルールを作成するには:
-
Workload Securityコンソールで、に移動し、[新規]をクリックして[New セキュリティログ監視ルール Properties]ウィンドウを表示します。
-
新しいルールに名前と説明を付けてから、[コンテンツ] タブを選択してください。
-
基本ルールテンプレートを開始するには、[Basic Rule]を選択してください。
-
[ルールID]フィールドには、カスタムルール用に予約された100,000以上の未使用ID番号が自動的に入力されます。
-
[レベル]を[Low (0)]に設定します。
-
ルールに適切なグループ名を付けます。この場合、cms.
-
短いルールの説明を入力します。
-
[Custom (XML)]オプションを選択します。基本ルールで選択したオプションはXMLに変換されます。
-
[ファイル] タブを選択し、[ファイルを追加] をクリックして、ルールを適用するアプリケーションログファイルとログタイプを追加します。この場合、ファイルの種類としてApplicationとeventlogです。EventlogはWorkload Securityにおいてユニークなファイルタイプです。なぜなら、ログファイルの場所やファイル名を指定する必要がないからです。代わりに、Windows Event Viewerに表示されるログ名をそのまま入力するだけで十分です。Eventlogファイルタイプの他のログ名には、Security、System、Internet Explorer、またはWindows Event Viewerにリストされている他のセクションが含まれる場合があります。他のファイルタイプでは、ログファイルの場所とファイル名を指定する必要があります。ファイル名に一致させるために、C/C++
strftime ()
変換指定子が利用可能です。以下の表に、より有用なもののリストを示します。 -
[OK]をクリックして基本ルールを保存します。
-
作成したカスタム (XML) の基本ルールを使用して、以前に特定したロググループに基づいて、新しいルールをグループに追加します。基本ルールの条件を初期ルールに設定します。次の例では、CMSの基本ルールによって、[ソース] 属性がCMSの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 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>
-
確立されたルールを使用して、複合ルールまたは相関ルールを追加します。次の例は、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>
-
すべてのルールの重要度レベルが適切かどうかを確認します。たとえば、エラーログの重要度はレベル5以上でなければなりません。情報ルールの重要度は低くなります。
-
最後に、新しく作成したルールを開き、[設定]タブを選択して、カスタムルール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>
セキュリティログ監視ルールの重要度レベル {#log-Inspection-rule-severity-levels-and-their-recommended-use} を使用
レベル
|
説明
|
メモ
|
レベル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
|
曜日の完全な名前 (例: 木曜日)
|
%b
|
省略された月名 (例: Aug)
|
%B
|
月の完全な名前 (例: August)
|
%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またはPMの指定 (例: 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)
|
%%
|
% 記号 (例えば、%)
|
詳細については、以下を参照してください。
セキュリティログ監視 ルールを調べる
セキュリティログ監視ルールは、Workload Securityコンソールの
にあります。セキュリティログ監視 のルール構造とイベント照合プロセス
次の図は、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)のセキュリティログ監視イベントが記録されます。
ただし、イベントに適用されるサブルールがもう1つあります。サブルール3851です。サブルール3851とその3つの属性は、同じイベントが過去120秒間に10回発生した場合に一致します。その場合、重大度が高(9)のセキュリティログ監視イベントが記録されます。
Ignore属性は、サブルール3851に、サブルール3801に一致する個々のイベントを120秒間無視するように指示します。これは、ノイズの低減に役立ちます。
サブルール3851のパラメータが一致した場合、重大度が高(9)のセキュリティログ監視イベントが記録されます。
Microsoft Exchangeルールの[オプション]タブを確認すると、Workload Securityは重大度レベルが中 (4) のサブルールが一致した場合にアラートを発することが合理的に考えられます。この例では、[このルールによってイベントが記録された場合にアラート]が選択されている場合にアラートが発せられます。
サブルールの複製
一部のログインスペクションルールには重複するサブルールがあります。例を見るには、Microsoft Windows Eventsルールを開き、[設定]タブを選択してください。サブルール18102と18103の下にサブルール18125 (リモートアクセスログイン失敗) が表示されることに注意してください。また、どちらの場合もサブルール18125には重大度の値がなく、See
Belowとだけ表示されることにも注意してください。
ルール18125は2回ではなく、[設定]ページの下部に1回だけ表示されます。
