このページのトピック
ポリシーで使用する セキュリティログ監視 ルールを定義する
OSSEC セキュリティログ監視 エンジンはエージェントに統合されており、コンピュータで実行されているオペレーティングシステムとアプリケーションによって生成されたログとイベントを Workload Security で監視する機能を提供します。Workload Security には、コンピュータまたはポリシーに割り当てることができるOSSEC セキュリティログ監視 ルールの標準セットが付属しています。要件に合う既存ルールが存在しない場合は、カスタムルールを作成することもできます。
トレンドマイクロが発行したセキュリティログ監視ルールは編集できません (ただし、複製して編集することはできます)。
1台以上のコンピュータに割り当てられたセキュリティログ監視ルール、またはポリシーの一部であるセキュリティログ監視ルールは削除できません。
セキュリティログ監視 ルールを作成するには、次の基本手順を実行します。
- 新しい セキュリティログ監視 ルールを作成します。
- デコーダ
- サブルール
- 実際の使用例
- セキュリティログ監視 ルールの重大度レベルと推奨される使用
- strftime() 変換指定子
- セキュリティログ監視 ルールを調べる
セキュリティログ監視 モジュールの概要については、 ログの分析を参照してください。
新しい セキュリティログ監視 ルールを作成します
- Workload Security コンソールで、[ Policies]→[Common Objects]→[Rules]→[ セキュリティログ監視 Rules]の順に選択します。
- [ 新規]→[新規 セキュリティログ監視 ルール]の順にクリックします。
- [一般] タブで、ルールの名前と説明を入力します (説明は省略できます)。
-
[コンテンツ] タブで、ルールを定義します。ルールを定義する一番簡単な方法は、[基本ルール] を選択し、表示されるオプションを使用してルールを定義する方法です。さらにカスタマイズが必要な場合は、[カスタム (XML)] を選択し、定義しているルールをXMLビューに切り替えることができます。
[カスタム (XML)] ビューで行った変更は、 [基本ルール] ビューに切り替えると失われます。
XMLベースの言語を使用して独自の セキュリティログ監視 ルールを作成する場合は、 OSSEC のドキュメントを参照するか、サポートプロバイダにお問い合わせください。
ベーシックルールテンプレートでは、次のオプションを使用できます。
- ルールID:ルールIDはルールの一意の識別子です。OSSECでは、ユーザ指定のルール用に100000~109999を定義しますWorkload Security は、このフィールドに新しい一意のルールIDをあらかじめ入力します。
- レベル:ルールにレベルを割り当てます。ゼロ (0) は、ルールによってイベントが記録されないことを示しますが、このルールを監視する他のルールが発生する可能性があります
- グループ:1つ以上のカンマ区切りのグループにルールを割り当てます。これが便利なのは、ある1つのルールの発生時に発生する複数のルール、または特定のグループに属するルールを作成した後に依存関係が使用されるときです。
- ルール説明:ルールの説明。
-
Pattern Matching: ルールがログ内で検索するパターンです。ルールは一致時にトリガーされます。パターンマッチングでは、正規表現またはより単純な文字列パターンがサポートされます。文字列パターンパターンタイプは正規表現よりも高速ですが、次の3つの特別な操作のみをサポートします。
- ^ (脱字記号): テキストの先頭を指定します。
- $ (ドル記号): テキストの終わりを示します。
- | (パイプ): 複数のパターン間のORを作成します。セキュリティログ監視モジュールで使用される正規表現の構文については、https://www.ossec.net/docs/syntax/regex.htmlを参照してください。
-
依存関係: 別のルールに依存関係を設定すると、この領域で指定されたルールもトリガされた場合にのみルールでイベントがログに記録されます。
- 頻度:ルールが実行されるまでの特定の期間内にルールが一致しなければならない回数。
- Time Frame: イベントをログに記録するためにルールが特定の回数 (頻度) トリガーする必要がある期間 (秒)。
ザ[コンテンツ]タブのみが表示されますセキュリティログ監視自分で作成したルールセキュリティログ監視 ルールには、 セキュリティログ監視 ルールの設定オプションがある場合はその代わりに[設定]タブがあります。
- [ファイル]タブで、ルールで監視するファイルの絶対パスを入力し、ファイルの種類を指定します。パスとファイル名はグロブ文字をサポートしていないことに注意してください。
-
[オプション]タブの[アラート] で、このルールが Workload Securityでアラートをトリガするかどうかを選択します。 [アラートの最小重大度] では、ベーシックルールまたはカスタム (XML) テンプレートを使用して作成されたルールに対してアラートをトリガーする最小の重大度を設定します。
ベーシックルールテンプレートでは、一度に1つのルールが作成されます。 1つのテンプレートに複数のルールを記述するには、カスタム (XML) テンプレートを使用できます。カスタム (XML) テンプレート内にレベルの異なる複数のルールを作成する場合、 アラートの最小重大度 設定を使用して、そのテンプレート内のすべてのルールに対してアラートをトリガする最小重大度を選択できます。
-
[ に割り当てられました]タブには、この セキュリティログ監視 ルールを使用しているポリシーとコンピュータが表示されます。新しいルールは作成中であるため、まだ割り当てられていません。
- [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 構成 設定で構成できます。
サブルール
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>
タグを使用して、親グループ内に追加のサブグループを定義できます。このサブグループは、次の表に示す任意のグループを参照できます。
グループの種類 | グループ名 | 説明 |
攻撃の予兆 | connection_attempt web_scan 偵察 |
接続試行 Web検索 一般的な検索 |
認証制御 | authentication_success authentication_failed invalid_login login_denied authentication_failures adduser account_changed |
成功 失敗 無効です ログイン拒否 複数の失敗 ユーザアカウントが追加されました ユーザアカウントが変更または削除されました |
攻撃/悪用 | automatic_attack exploit_attempt invalid_access スパムメール multiple_spam sql_injection 攻撃 ウイルス |
ワーム(標的にされない攻撃) 攻撃コード パターン アクセスが無効です スパムメール解析依頼 複数のスパムメッセージ SQLインジェクション 一般的な攻撃 ウイルス検出数 |
アクセス管理 | access_denied access_allowed 不明なリソース firewall_drop multiple_drops client_misconfig client_error |
アクセス拒否 アクセス許可 存在しないリソースへのアクセス ファイアウォール drop 複数のファイアウォールドロップ クライアントの設定ミス クライアントエラー |
ネットワーク制御 | new_host ip_spoof |
新しいコンピュータが検出されました ARPスプーフィングの可能性 |
システム監視 | service_start system_error system_shutdown logs_cleared invalid_request プロミス policy_changed config_changed low_diskspace time_changed |
サービスの開始 システムエラー シャットダウン ログがクリアされました リクエストが無効です インタフェースがプロミスキャスモードに切り替えられました ポリシーの変更 設定の変更 ディスク空き容量が少ない 時間の変更 |
イベントの自動タグ設定が有効になっている場合、イベントにはグループ名のラベルが付けられます。トレンドマイクロが提供するセキュリティログ監視ルールでは、グループをより使いやすいバージョンに変更する変換テーブルを使用します。たとえば、 login_denied
は「ログインが拒否されました」と表示されます。カスタムルールは、ルールに表示されるグループ名別に表示されます。
Description
<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
<match></match>
タグを使用して、「password failed」文字列を検索します。
<rule id="100124" level="5">
<decoded_as>sshd</decoded_as>
<match>^Failed password</match>
<description>Failed SSHD password attempt</description>
</rule>
文字列の先頭を示す正規表現のキャレット (「^」) に注意してください。ログの先頭に「Failed password」は表示されませんが、セキュリティログ監視デコーダによってログがセクションに分割されます。詳細については、 Decoders を参照してください。これらのセクションの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」 |
条件文
ルールの評価では、trueと評価される他のルールを条件とすることができます。 <if_sid></if_sid>
タグは、 セキュリティログ監視 エンジンに対して、タグで特定されたルールがtrueと評価された場合にのみ、このサブルールを評価するように指示します。次の例では、100123、100124、および100125の3つのルールを示します。ルール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アドレスの前に「!」を使用すると、指定した以外の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) のいずれかを指定する追加のルールオプション。 |
複合ルール
アトミックルールは、単一のログエントリを調べます。複数のエントリを関連付けるには、複合ルールを使用する必要があります。複合ルールは、現在のログと受信済みのログを一致させる必要があります。複合ルールには2つの追加オプションが必要です frequency
オプションは、ルールがアラートを生成する前にイベントまたはパターンが何回発生する必要があるかを指定します timeframe
オプションは、セキュリティログ監視エンジンに過去のログを検索する期間を秒単位で指定します。すべての複合ルールの構造は次のとおりです。
<rule id="100130" level="10" frequency="x" timeframe="y">
</rule>
たとえば、10分以内に5回のパスワードエラーが発生した場合に重大度の高いアラートを作成する複合ルールを作成できます。 <if_matched_sid></if_matched_sid>
タグを使用すると、新しいルールでアラートを作成するために、必要な頻度と期間内にどのルールを表示する必要があるかを指定できます。次の例では、イベントの5つのインスタンスが検出されたときにトリガーするように frequency
属性が設定され、時間枠を600秒に指定するように timeframe
属性が設定されています。
<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
- カテゴリ: なし
- イベント:
<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)
この構造は、ルールを作成するための適切な基盤となります。次に、Workload Securityで新しいセキュリティログ監視ルールを作成します。
新しいCMSセキュリティログ監視ルールを作成するには:
- Workload Security コンソールで、[ Policies]→[Common Objects]→[Rules]→[ セキュリティログ監視 Rules ]の順に選択し、[ New ]をクリックして、[ New セキュリティログ監視 Rule Properties ]画面を表示します。
- 新しいルールの名前と説明を入力し、[ Content ] タブを選択します。
- 基本ルールテンプレートから開始するには、[ Basic Rule] を選択します。
- [ ルールID ] フィールドには、100,000以上の未使用のID番号が自動的に入力されます。このIDはカスタムルール用に予約されています。
- Level を Low (0)に設定します。
- ルールに適切なグループ名を付けます。この場合、cms.
-
短いルールの説明を入力します。
-
[ Custom (XML) ] オプションを選択します。基本ルールで選択したオプションがXMLに変換されます。
-
[ Files ] タブを選択し、[ Add File ] をクリックして、ルールを適用するアプリケーションログファイルとログの種類を追加します。この場合、ファイルの種類は「アプリケーション」および「イベントログ」です。
イベントログは、ログファイルの場所とファイル名を指定する必要がないため、Workload Securityで一意のファイルタイプです。代わりに、Windowsイベントビューアに表示されるログ名を入力するだけで十分です。イベントログファイルの種類の他のログ名には、[セキュリティ]、[システム]、[Internet Explorer]、またはWindowsイベントビューアに表示されるその他のセクションがあります。その他のファイルタイプでは、ログファイルの場所とファイル名が必要です。 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} を使用 {#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 | 曜日の正式名 (例: Thursday) |
%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 | 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) |
%% | %記号 (例: %) |
詳細については、以下を参照してください。
- https://www.php.net/manual/en/function.strftime.php
- http://www.cplusplus.com/reference/ctime/strftime/
セキュリティログ監視 ルールを調べる
セキュリティログ監視 ルールは、 Workload Security コンソールの 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
- 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ルールの [オプション] タブを見てみると、重要度が「中(4)」のサブルールが一致した場合、Workload Securityがアラートを発令するとします。この例はこれに該当するため、このルールによってイベント[が記録される際に]アラートが選択されている場合、アラートが発令されます。
サブルールの複製
一部のセキュリティログ監視ルールに重複するサブルールがあります。例を表示するには、Microsoft Windowsのイベントルールを開き、[ 設定 ] タブを選択します。サブルール18125 (リモートアクセスログインの失敗) は、サブルール18102および18103の下に表示されます。いずれの場合も、サブルール18125には重大度の値はなく、[以下を参照] のみが表示されます。
重複して表示されるのではなく、ルール18125は、[設定] 画面の下部に1回だけ表示されています。