OSSECセキュリティログ監視エンジンはエージェントに統合されており、 Server & Workload Protection では、コンピュータで実行されているOSやアプリケーションによって生成されたログやイベントを検査できます。 Server & Workload Protection には、コンピュータまたはポリシーに割り当てることができるOSSECセキュリティログ監視インスペクションルールの標準セットが付属しています。要件を満たす既存のルールがない場合は、カスタムルールを作成することもできます。
トレンドマイクロが発行するセキュリティログ監視ルールは編集できませんが、コピーしたものを編集することはできます。
注意1台以上のコンピュータに割り当てられたセキュリティログ監視ルール、またはポリシーの一部であるセキュリティログ監視ルールは削除できません。
|
セキュリティログインスペクションルールを作成するには、次の基本的な手順を実行します。
- 新しいセキュリティログインスペクションルールの作成
- デコーダ
- サブルール
- 実際の例
- セキュリティログインスペクションルールの重要度と推奨される使用方法
- strftime() 変換指定子
- セキュリティログインスペクションルールの調査
セキュリティログ監視モジュールの概要については、を参照してください。ログの分析。
新しいセキュリティログ監視ルールを作成する
-
Server & Workload Protection コンソールで、次の場所に移動します。 。
-
クリック。
-
[一般] タブで、ルールの名前とオプションの説明を入力します。
-
[内容] タブでは、ルールを定義します。ルールを定義する最も簡単な方法は、 [基本ルール] を選択し、表示されるオプションを使用してルールを定義することです。さらにカスタマイズが必要な場合は、 [カスタム (XML)] を選択して、定義するルールのXMLビューに切り替えることができます。
注意
[基本ルール] ビューに戻すと、[カスタム (XML)] ビューで加えた変更はすべて失われます。XMLベースの言語を使用して独自のセキュリティログインスペクションルールを作成する方法について詳しくは、 OSSECを参照するか、サポートプロバイダにお問い合わせください。
基本ルールテンプレートでは以下のオプションを使用できます。
-
[ルールID]: ルールIDは、ルールの一意の識別子です。 OSSECでは、100000~109999をユーザ定義ルールの領域として定義しています。 Server & Workload Protection によって、新しい一意のルールIDがフィールドに事前入力されます。
-
[レベル]: ルールにレベルを割り当てます。ゼロ (0) は、ルールがイベントをログに記録しないことを意味します。ただし、このルールを監視する他のルールは実行される可能性があります。
-
[グループ]: 1つ以上のカンマ区切りのグループにルールを割り当てます。これは、ルールまたは特定のグループに属するルールの実行時に起動するルールを作成できるため、依存関係を使用する場合に便利です。
-
[ルールの説明]: ルールの説明。
-
[特征码匹配]: ルールがログ内で検索するパターンです。ルールは一致時にトリガーされます。パターンマッチングでは、正規表現またはより単純な文字列パターンがサポートされます。 「文字列パターン」パターンタイプは正規表現よりも高速ですが、次の3つの特別な操作のみをサポートします。
- [^ (キャレット)]: テキストの開始を指定します。
- [$ (ドル記号)]: テキストの終了を指定します。
- [| (パイプ)]: 複数のパターン間の「OR」を作成する場合は、セキュリティログ監視モジュールで使用される正規表現の構文については、「https://www.ossec.net/docs/syntax/regex.html 。
-
[依存パッケージ]: 別のルールに依存関係を設定すると、この領域で指定されたルールもトリガされた場合にのみルールでイベントがログに記録されます。
-
[頻度]: ルールがトリガーされるまでに、特定の期間内にルールが一致する必要がある回数。
-
[期間]: イベントをログに記録するためにルールが特定の回数 (上記の頻度) をトリガーする必要がある期間 (秒)。
注意 [内容] タブは、自分で作成したセキュリティログインスペクションルールに対してのみ表示されます。トレンドマイクロが発行するセキュリティログ監視インスペクションルールには、セキュリティログ監視ルールの設定オプション
(存在する場合) が表示される [構成] タブがあります。
|
-
[ファイル] タブで、ルールで監視するファイルの絶対パスを入力し、ファイルの種類を指定します。
-
[オプション] タブの [アラート] セクションで、このルールで Server & Workload Protectionのアラートをトリガーするかどうかを選択します。 [アラートの最小重大度] では、ベーシックルールまたはカスタム (XML) テンプレートを使用して作成されたルールに対してアラートをトリガーする最小の重大度を設定します。
注意
ベーシックルールテンプレートでは、一度に1つのルールが作成されます。 1つのテンプレートに複数のルールを記述するには、カスタム (XML) テンプレートを使用できます。カスタム (XML) テンプレート内でレベルの異なる複数のルールを作成する場合は、 [最小のアラート重要度] 設定を使用して、そのテンプレート内のすべてのルールに対してアラートをトリガする最小重大度を選択できます。 -
[割り当て対象] タブには、このセキュリティログインスペクションルールを使用しているポリシーとコンピュータが一覧表示されます。新しいルールを作成しているため、まだ割り当てられていません。
-
[OK]をクリックします。ルールをポリシーとコンピュータに割り当てる準備ができました。
デコーダ
セキュリティログ監視インスペクションルールは、変更を監視するファイルのリストと、ルールを実行するために満たす必要のある一連の条件で構成されます。セキュリティログ監視エンジンが監視対象のログファイルに変更を検出すると、その変更がデコーダによって解析されます。デコーダは、未加工のログエントリを次のフィールドに解析します。
- [ログログ]: イベントのメッセージセクション
- [full_log]: イベント全体
- [場所]: ログの取得元
- [ホスト名]: イベントソースのホスト名
- [program_name]: イベントのsyslogヘッダからのプログラム名
- [srcip]: イベント内の送信元IPアドレス
- [dstip]: イベント内の宛先IPアドレス
- [srcport]: イベント内の送信元ポート番号
- [dstport]: イベント内の送信先ポート番号
- [protocol]: イベント内のプロトコル
- [] を選択した場合は、感染したコンテンツを置換するテキストおよびファイル名を入力してください]: イベント内で実行された処理
- [srcuser]: イベント内の発信元ユーザ
- [dstuser]: イベント内の送信先ユーザ
- [ID]: イベントのIDとしてデコードされた任意のID
- [ステータス:]: イベント内のデコードされたステータス
- [コマンド]: イベント内で呼び出されているコマンド
- [url]: イベント内のURL
- [データ]: イベントから抽出された追加データ
- [システム名]: イベント内のシステム名
ルールは、このデコードされたデータを確認して、ルールで定義された条件に一致する情報を検索します。
一致する項目の重要度レベルが十分に高い場合は、次のいずれかの処理を実行できます。
- アラートを発生させることができます。 (セキュリティログ監視ルールの [プロパティ] 画面の [オプション] タブで設定できます。)
- イベントをsyslogに書き込むことができます。 ( [SIEM] 領域で設定可能 タブをクリックします。)
- イベントを Server & Workload Protectionに送信できます。 (セキュリティログ監視のSyslog設定での設定 タブをクリックします。)
サブルール
1つのセキュリティログ監視インスペクションルールに複数のサブルールを含めることができます。これらのサブルールには、アトミックまたはコンポジットの2種類があります。アトミックルールは単一のイベントを評価し、複合ルールは複数のイベントを調べ、イベントの頻度、繰り返し、および相関を評価できます。
グループ
各ルール、またはルールのグループは、
<group></group>
エレメント。属性名には、このグループに含めるルールが含まれている必要があります。次の例では、グループに syslog ルールと sshd ルールが含まれていることを示しています。<group name="syslog,sshd,"> </group>
注意グループ名の末尾のカンマに注目してください。を使用する場合は、末尾のカンマが必要です。
<if_group></if_group> タグを使用して、このサブルールに条件付きで別のサブルールを追加します。 |
注意一連のセキュリティログインスペクションルールがエージェントに送信されると、エージェントのセキュリティログ監視エンジンは割り当てられた各ルールからXMLデータを取得し、実質的に1つの長いセキュリティログインスペクションルールにまとめます。一部のグループ定義は、トレンドマイクロが作成したすべてのセキュリティログインスペクションルールに共通です。このため、トレンドマイクロでは「初期設定ルール設定」と呼ばれるルールを用意しています。このルールでは、これらのグループを定義し、他のトレンドマイクロルールとともに常に割り当てられます。
(割り当てるルールを選択し、[初期設定のルール設定] ルールを選択していない場合は、インスペクションルールが自動的に割り当てられることを通知するメッセージが表示されます。)トレンドマイクロが作成したルールを割り当てずにコンピュータを使用する場合は、「初期設定のルール設定」ルールの内容を新しいルールにコピーするか、「初期設定のルール設定」**ルールを選択してコンピュータに割り当てる必要があります。
|
ルール、ID、およびレベル
グループには、必要な数のルールを含めることができます。ルールは次を使用して定義されます。
<rule></rule>
要素であり、少なくとも 2 つの属性、 [ID] と [レベル]が必要です。 [ID] はそのシグネチャの一意の識別子で、 [レベル] はアラートの重大度です。次の例では、それぞれ異なるルール 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 explore_attempt invalid_access スパムメール multiple_spam sql_injection攻撃
ウイルス
|
ワーム (非標的型攻撃) エクスプロイトパターン 無効なアクセススパム複数のスパムメッセージ SQLインジェクション 一般的な攻撃 ウイルス検出
|
アクセス制御
|
access_denied access_allowed unknown_resourcefirewall_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-初期設定のLog Decoder] を選択します。 [構成] タブに移動し、 [デコーダの表示]をクリックします。
|
一致する
ログ内の特定の文字列を検索するには、
<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>
タグを使用して「パスワードに失敗しました」という文字列を検索します。<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+)
|
\*
|
上記のいずれかに一致 (例: \\w\*、\\d\*)
|
^
|
文字列の先頭 (^任意の文字列)
|
$
|
文字列の末尾 (任意の文字列$)
|
|
|
複数の文字列間の「OR」
|
条件文
ルールの評価は、他のルールが true と評価されたことを条件とすることができます。の
<if_sid></if_sid>
タグは、タグで識別されたルールが true と評価された場合にのみ、このサブルールを評価するようにログ検査エンジンに指示します。次の例は、100123、100124、および
100125 の 3 つのルールを示しています。ルール 100124 および 100125 は、<if_sid></if_sid>
鬼ごっこ:<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
|
パターン
|
イベント (ログ) に対して照合される任意の文字列。
|
正規表現
|
正規表現
|
イベント (ログ) に対して照合される任意の正規表現。
|
decoded_as
|
文字列
|
事前一致する任意の文字列。
|
srcip
|
送信元のIPアドレス
|
送信元IPアドレスとしてデコードされる任意のIPアドレス。 「!」を使用します。 IPアドレスを無効にします。
|
dstip
|
送信先のIPアドレス
|
宛先IPアドレスとしてデコードされる任意のIPアドレス。 「!」を使用します。 IPアドレスを無効にします。
|
srcport
|
送信元のポート番号
|
任意の送信元のポート (形式の一致)。
|
dstport
|
送信先のポート番号
|
任意の送信先のポート (形式の一致)。
|
ユーザ
|
ユーザ名
|
ユーザ名としてデコードされる任意のユーザ名。
|
program_name
|
プログラム名
|
Syslogプロセス名からデコードされる任意のプログラム名。
|
ホスト名
|
システムのホスト名
|
Syslogのホスト名としてデコードされる任意のホスト名。
|
時刻
|
hh:mm~hh:mmまたはhh:mm am~hh:mm pmの形式の時間範囲
|
トリガするルールに対してイベントが発生する必要のある時刻の範囲。
|
weekday
|
曜日 (日曜、月曜、火曜など)
|
トリガするルールに対してイベントが発生する必要のある曜日。
|
ID
|
ID
|
イベントからデコードされる任意のID。
|
url
|
URL
|
イベントからデコードされる任意のURL。
|
使用
<if_sid>100125</if_sid>
タグを使用して、このルールを 100125 ルールに依存させます。このルールは、ログイン成功ルールにすでに一致した 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>
ログエントリのサイズに関する制限
次の例では、前の例に [最大サイズ] 属性を追加します。この属性は、最大文字数未満のルールのみを評価するようにセキュリティログ監視エンジンに指示します。
<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) 番号。
|
オプション
|
alert_by_email no_email_alert no_log
|
アラートの処理としてメール生成 (alert_by_email)、メール生成なし (no_email_alert)、またはログへの記録なし (no_log) のいずれかを指定する追加のルールオプション。
|
コンポジットルール
アトミックルールは、単一のログエントリを調べます。複数のエントリを関連付けるには、複合ルールを使用する必要があります。複合ルールは、現在のログと受信済みのログを一致させる必要があります。複合ルールには2つの追加オプションが必要です
[頻度] オプションは、ルールがアラートを生成する前にイベントまたはパターンが何回発生する必要があるかを指定します [期間] オプションは、セキュリティログ監視エンジンに過去のログを検索する期間を秒単位で指定します。すべての複合ルールの構造は次のとおりです。
<rule id="100130" level="10" frequency="x" timeframe="y"> </rule>
たとえば、10 分以内にパスワードが 5 回失敗した場合に、より重大度の高いアラートを作成する複合ルールを作成できます。の使用
<if_matched_sid></if_matched_sid>
タグを使用すると、新しいルールがアラートを作成するために、希望の頻度と時間枠内でどのルールを確認する必要があるかを指定できます。次の例では、 [頻度] 属性はイベントの 5 つのインスタンスが表示されたときにトリガーされるように設定され、 [期間] 属性は時間枠を 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>
実際の使用例
Server & Workload Protection には、数多くの一般的なアプリケーション向けのセキュリティログインスペクションルールの初期設定が多数含まれています。セキュリティアップデートを通じて、新しいルールが定期的に追加されます。セキュリティログインスペクションルールでサポートされるアプリケーションのリストは増え続けていますが、サポートされていないアプリケーションやカスタムアプリケーション用にカスタムルールを作成する必要がある場合があります。
ここでは、Microsoft SQL Serverデータベースをデータリポジトリとして使用するMicrosoft Windows Server IISおよび.Netプラットフォームでホストされる、カスタムCMS
(コンテンツ管理システム) の作成について説明します。
最初に、次に示すアプリケーションログの属性を特定します。
- アプリケーションログを記録する場所
- ログファイルのデコードに使用できるセキュリティログ監視デコーダ
- ログファイルメッセージの一般的な形式
ここで示すカスタムCMSの例では、次のようになります。
-
Windowsイベントビューア
-
Windowsイベントログ (eventlog)
-
Windowsイベントログ形式 (次のコア属性を使用)
- 出典: CMS
- カテゴリ: なし
- イベント:
<Application Event ID>
次に、アプリケーションの機能別にログイベントのカテゴリを識別し、それらのカテゴリをカスケードグループの階層に整理して検査します。検査対象のすべてのグループがイベントを発生させる必要はありません。
match は条件文として使用できます。グループごとに、ルールで一致条件として使用できるログ形式属性を特定します。これは、すべてのアプリケーションログを調べて、ログイベントのパターンと論理グループを調べることによっても実行できます。
たとえば、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)
この構造は、ルールを作成するための適切な基盤となります。 Server & Workload Protectionで新しいセキュリティログ監視インスペクションルールを作成します。
[新しいCMSセキュリティログ監視ルールを作成するには]:
-
Server & Workload Protection コンソールで、 をクリックします。新規を表示します。新しいセキュリティログ監視ルールのプロパティウィンドウ。
-
新しいルールの名前と説明を入力し、 Content タブをクリックします。
-
新しいカスタムルールを作成する最も簡単な方法は、基本ルールテンプレートから始めることです。 Basic Rule ラジオボタンを選択します。
-
Rule ID フィールドには、100,000以上の未使用のID番号が自動的に入力されます。このIDはカスタムルール用に予約されています。
-
Level 設定を Low (0)に設定します。
-
ルールに適切なグループ名を付けます。この場合は「cms」です。
-
ルールの簡単な説明を入力します。
-
ここで、 Custom (XML) オプションを選択します。 「基本」ルールで選択したオプションがXMLに変換されます。
-
Files タブをクリックし、 Add File ボタンをクリックして、ルールを適用するアプリケーションログファイルとログの種類を追加します。この場合、ファイルの種類は「アプリケーション」、「eventlog」です。
注意
Eventlog は、ログファイルの場所とファイル名を指定する必要がないため、 Server & Workload Protection で一意のファイルの種類です。代わりに、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以上にする必要があります。情報ルールの重大度は低くなります。
-
最後に、新しく作成したルールを開き、 Configuration タブをクリックして、カスタムルールのXMLをルールフィールドにコピーします。 Apply または OK をクリックして変更を保存します。
ルールがポリシーまたはコンピュータに割り当てられると、セキュリティログ監視エンジンは指定されたログファイルの検査をすぐに開始します。
The complete Custom CMS Log Inspection Rule:
<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サイトを参照してください。
セキュリティログ監視ルールの確認
セキュリティログ監視インスペクションルールは、次の場所にある Server & Workload Protection コンソールにあります。 。
セキュリティログインスペクションルールの構造とイベント照合プロセス
次のスクリーンショットは、「Microsoft Exchange」セキュリティログインスペクションルールの [プロパティ] 画面にある Configuration タブの内容を示しています。
次に、ルールの構造を示します。
- 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)
- 頻度 - 12
- Time Frame (1 to 86400) - 120
- 無視 - 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)」のセキュリティログ監視イベントが記録されます。
(「無視」属性は、サブルール3851に、サブルール3801に一致する個々のイベントを120秒間無視するように指示します。これは、「ノイズ」を減らすのに役立ちます。)
サブルール3851のパラメータが一致した場合、重大度が「高(9)」のセキュリティログ監視イベントが記録されます。
Microsoft Exchangeルールの[オプション]タブを見ると、重大度が「中(4)」のサブルールが一致した場合、 Server & Workload Protection によってアラートが生成されることがわかります。この例では、アラートが発生します ([このルールがイベントをログに記録したときにアラートを送信する] が選択されている場合)。
重複しているサブルール
一部のセキュリティログインスペクションルールに重複するサブルールがあります。例を表示するには、[Microsoft Windowsイベント] ルールを開き、 Configuration タブをクリックします。サブルール18125 (リモートアクセスログインの失敗) は、サブルール18102および18103の下に表示されます。いずれの場合も、サブルール18125には重大度の値はなく、「以下を参照」のみが表示されます。
ルール18125は、2回表示されるのではなく、1回だけ Configuration ページの下部に表示されます。