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

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

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

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

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

• 新しい セキュリティログ監視 ルールを作成します。
• デコーダ
• サブルール
• 実際の使用例
• セキュリティログ監視 ルールの重大度レベルと推奨される使用
• strftime() 変換指定子
• セキュリティログ監視 ルールを調べる

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

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

1. Workload Security コンソールで、[ Policies]→[Common Objects]→[Rules]→[ セキュリティログ監視 Rules]の順に選択します。
2. [ 新規]→[新規 セキュリティログ監視 ルール]の順にクリックします。
3. [一般] タブで、ルールの名前と説明を入力します (説明は省略できます)。

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

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

   XMLベースの言語を使用して独自の セキュリティログ監視 ルールを作成する場合は、 OSSEC のドキュメントを参照するか、サポートプロバイダにお問い合わせください。

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

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

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

  • ^ (カレット): テキストの先頭を指定します。
  • $ (ドル記号): テキストの末尾を指定します。
  • | (pipe）：複数のパターン間に「OR」を作成する セキュリティログ監視 モジュールで使用される正規表現の構文については、https://www.ossec.net/docs/syntax/regex.htmlを参照してください。

• 依存関係：別のルールへの依存関係を設定すると、このエリアで指定されたルールも実行された場合にのみイベントがログに記録されます。

• 頻度：ルールが実行されるまでの特定の期間内にルールが一致しなければならない回数。
• 時間枠：イベントをログに記録するルールが一定の回数（頻度、上記）で実行されるまでの時間（秒）です。

ザコンテンツタブのみが表示されますセキュリティログ監視自分で作成したルールセキュリティログ監視 ルールには、 セキュリティログ監視 ルールの設定オプションがある場合はその代わりに[ 設定] タブがあります。

1. [ファイル] タブで、ルールによって監視するファイルのフルパスを入力し、そのファイルの種類を指定します。

2. [ オプション] タブの[ アラート ]で、このルールが Workload Securityでアラートをトリガするかどうかを選択します。
   [アラート最小重要度]では、基本ルールまたはカスタム（XML）テンプレートを使用してルールに対してアラートをトリガする最小の重大度レベルを設定します。

   基本ルールテンプレートは、一度に1つのルールを作成します。1つのテンプレートに複数のルールを書き込むには、カスタム（XML）テンプレートを使用できます。カスタム（XML）テンプレート内でレベルが異なる複数のルールを作成する場合は、[ Alert Minimum Severity ]設定を使用して、そのテンプレート内のすべてのルールに対するアラートをトリガする最小の重要度を選択できます。

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

4. [OK] をクリックします。このルールをポリシーとコンピュータに割り当てる準備ができました。

デコーダ

セキュリティログ監視 ルールは、変更を監視するファイルのリストと、ルールがトリガするために満たす条件のセットで構成されます。 セキュリティログ監視 エンジンが監視対象ログファイルの変更を検出すると、その変更はデコーダによって解析されます。デコーダは、rawログエントリを解析して次のフィールドを生成します。

• ログ：イベントのメッセージセクション
• full_log：イベント全体
• の場所：ログはどこから来たのですか
• ホスト名：イベントソースのホスト名
• program_name：イベントのsyslogヘッダからのプログラム名
• srcip：イベント内の送信元IPアドレス
• dstip：イベント内の送信先IPアドレス
• srcport：イベント内の送信元ポート番号
• dstport：イベント内の宛先ポート番号
• プロトコル：イベント内のプロトコル
• action：イベント内で実行されたアクション
• srcuser：イベント内の元のユーザ
• dstuser：イベント内の送信先ユーザ
• id：イベントからIDとしてデコードされたID
• ステータス：イベント内のデコードされたステータス
• コマンド：イベント内でコマンドが呼び出されています
• url：イベント内のURL
• データ：イベントから抽出された追加データ
• systemname：イベント内のシステム名

ルールは、このデコードされたデータを確認して、ルールで定義された条件に一致する情報を検索します。

一致する項目の重要度レベルが十分に高い場合は、次のいずれかの処理を実行できます。

• アラートの発令(セキュリティログ監視ルールの [プロパティ] 画面の [オプション] タブで設定できます)
• イベントのSyslogへの書き込み([管理]→[システム設定]→[イベントの転送] タブの [SIEM] エリアで設定できます)
• このイベントは、 Workload Securityに送信できます。(ポリシーエディタまたはコンピュータエディタの [設定]→[イベントの転送] タブの [セキュリティログ監視の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> 要素を使用して定義され、 id と レベルの少なくとも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> タグを使用して、親グループ内に追加のサブグループを定義できます。このサブグループは、次の表に示す任意のグループを参照できます。

イベントの自動タグ付けが有効な場合は、イベントにグループ名のラベルが付けられます。セキュリティログ監視 ルールでは、グループをユーザフレンドリなバージョンに変更する変換テーブルを使用します。そのため、たとえば、「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>

文字列の先頭を示す正規表現のカレット (^) に注意してください。「失敗したパスワード」はログの先頭に表示されませんが、 セキュリティログ監視 デコーダではログがセクションに分割されます。詳細については、「デコーダ」を参照してください。これらのセクションの1つは、ログ全体を示す「full_log」ではなく、ログのメッセージ部分を示す「log」です。

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

条件文

ルールの評価では、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> タグは、完全に異なる セキュリティログ監視 ルール内のサブルールを参照するために使用できますが、後でルールを確認することが非常に困難になるため、この処理は避けてください。

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

このルールを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>

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

コンポジットルール

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

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

より詳細なコンポジットルールを作成するのに使用できるタグが他にもいくつかあります。このようなルールを使用すると、次の表に示すように、イベントの特定の部分が同じになるように指定できます。これにより、コンポジットルールを調整して誤判定を減らすことができます。

特定のルール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 (コンテンツ管理システム) の作成について説明します。

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

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

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

1. Windowsイベントビューア
2. Windowsイベントログ (eventlog)

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

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

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

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

7. 短いルールの説明を入力します。

   

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

   

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

   

   Eventlog は、ログファイルの場所とファイル名を指定する必要がないため、 Workload 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>  

セキュリティログ監視 ルールの重大度レベルと推奨される使用

strftime() 変換指定子

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

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
  • 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の重大度レベルは「無視」なので、 セキュリティログ監視 イベントは記録されません。

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

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

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

Microsoft Exchangeルールの[オプション]タブを確認すると、重大度レベルが「中（4）」のサブルールが一致した場合に、 Workload Security がアラートを発行します。この例はこれに該当するため、アラートが発令されます ([このルールによってイベントが記録された場合にアラート] が選択されている場合)。

重複しているサブルール

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

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