アラート：詳細EPLルールのサンプル

[#1]

  

ESAの詳細EPLルールの例は次のとおりです。次に示す例には、同じユースケースを実現可能な複数の方法があります。

例1： 

ユーザー アカウントを作成し、300秒以内に同じユーザー アカウントを削除します。ユーザー情報はuser_srcメタに格納されます。

EPL 1：

                     

ルール名	CreateuseraccountFollowedbyDeletionof Useraccount1
ルールの説明	ユーザー アカウントを作成してから300秒以内に同じユーザー アカウントを削除するアクションのパターンを検知します。
ルールのコード	SELECT * FROM Event(ec_subject='User'                     AND ec_outcome='Success'                     AND user_src is NOT NULL                     AND ec_activity IN ('Create', 'Delete')                    ).win:time(300 seconds) match_recognize (partition by user_src ​                 measures C as c, D as d                  pattern (C D)                  define                  C as C.ec_activity='Create' ,                  D as D.ec_activity='Delete');
注	指定の時間内にパターンに必要なイベントをフィルタします。必要なイベントのみがmatch recognize関数に渡されるフィルタ条件にする必要があります。この例では、ユーザー アカウントの作成と削除です。コード：Event(ec_subject='User' AND ec_outcome='Success' AND user_src is NOT NULL AND ec_activity IN ('Create', 'Delete') Partition byによってバケットが作成されます。この場合、esperによって、user_srcの値ごとにバケットが作成されます。そのため、user_srcの値は両方のイベントで共通になります。 必要なパターンを定義します。現在は、作成の後に削除を実行するように設定されています。複数回の作成の後に削除を実行するよう設定できます（C+ D）。パターンは正規表現に非常に似ています。 最も効率的なユースケースです。

EPL 2：

                     

ルール名	CreateuseraccountFollowedbyDeletionof Useraccount2
ルールの説明	ユーザー アカウントを作成してから300秒以内に同じユーザー アカウントを削除するアクションのパターンを検知します。
ルールのコード	SELECT * from pattern[every (a= Event(ec_subject='User' AND ec_outcome='Success' AND user_dst is NOT NULL AND ec_activity IN ('Create'))  -> ( Event(ec_subject='User' AND ec_outcome='Success' AND user_dst is NOT NULL AND ec_activity IN ('Create') AND user_src=a.user_src) ) )where timer:within(300 Sec) ];
注	同じユーザーの作成が2回、削除が1回、その順序で実行されるとします。その後、前掲のパターンによって2つのアラートが発行されます。 ユーザーが作成されるごとに、スレッドが作成されます。 スレッドを制御する方法はありません。時間の設定と、できれば短い間隔があることが重要です。

例2： 

ユーザーが作成された後に、同じユーザーがログインし、最終的にそのユーザーが削除されるというパターンを検出します。Windowsログの場合、ユーザー情報は、イベントに応じて、user_dstまたはuser_srcに格納されます。

user_src(create) = user_dst(Login) = user_src(Delete)

EPL 3：

                     

ルール名	CreateUserLoginandDeleteUser
ルールの説明	ユーザーがユーザー アカウントを作成し、そのユーザーでログインした後、ユーザー アカウントを削除するアクションのパターンを検知します。
ルールのコード	SELECT * FROM Event(ec_subject='User'                     and ec_activity in ('Create','Logon','Delete')                     and ec_theme in ('UserGroup', 'Authentication')                     and ec_outcome='Success'                    ).win:time(300 seconds) match_recognize (measures C as c, L as l, D as d                  pattern (C L D)                  define                  C as C.ec_activity = 'Create',                  L as L.ec_activity = 'Logon' AND L.user_dst = C.user_src,                  D as D.ec_activity = 'Delete' AND D.user_src=C.user_src                 );
注	user_src/user_dstはすべてのイベントで共通ではないため、partitionは使用できません。一度に1つのシングル バケットが1つのパターンを実行することになります。たとえば、ユーザー1および2について、イベントのストリームがC1C2L1D1、 C1L1C2D1の場合、C1スレッドがC2によってリセットされるため、アラートは発行されません。C1L1D1が順序どおりで、同じユーザーまたは異なるユーザーのその他のイベントが間に入らない場合にのみ、アラートが発行されます。  別の方法としては、Named Windowを使用し、user_dstとuser_srcを単一の列にマージしてから、match recognizeを実行します （EPL 3）。  パターンも使用できます。予想よりも多くのアラートが発行される可能性があります （EPL 4）。

EPL 4：NamedWindowsとmatch recognizeの使用

                  

ルール名	CreateUserLoginandDeleteUser
ルールの説明	ユーザーがユーザー アカウントを作成し、そのユーザーでログインした後、ユーザー アカウントを削除するアクションのパターンを検知します。
ルールのコード	@Name('NormalizedWindow') create window FilteredEvents.win:time(300 sec) (user String, ecactivity string, sessionid Long); @Name('UsersrcEvents') Insert into FilteredEvents select user_src as user, ec_activity as ecactivity, sessionid from Event( ec_subject='User' and ec_activity in ('Create','Delete') and ec_theme in ('UserGroup', 'Authentication') and ec_outcome='Success' and user_src is not null ); @Name('UsrdstEvents') Insert into FilteredEvents select user_dst as user, ec_activity  as ecactivity, sessionid from Event( ec_subject='User' and ec_activity in (Logon’) and ec_theme in ('UserGroup', 'Authentication') and ec_outcome='Success' and user_dst is not null ); @Name('Pattern') @RSAAlert(oneInSeconds=0, identifiers={"user"}) select * from FilteredEvents ​         match_recognize (          partition by user          measures C as c, L as l, D as d          pattern (C L+D)          define C as C.ecactivity= ‘Create’,                 L as L.ecactivity= ‘Logon’,                 D as D.ecactivity=’Delete’                  );

EPL #5: Using Every @RSAAlert(oneInSeconds=0, identifiers={"user_src"})

SELECT a.time as time,a.ip_src as ip_src,a.user_dst as user_dst,a.ip_dst as ip_dst,a.alias_host as alias_host from pattern[every (a=Event (ec_subject='User' and ​ec_activity='Create' and ec_theme='UserGroup' and ec_outcome='Success') ->  (Event(ec_subject='User' and ec_activity='Logon' and ec_theme='Authentication' and user_src=a.user_dst) -> b=Event(ec_subject='User' and ec_activity='Delete' and ec_theme='UserGroup' and user_dst=a.user_dst))) where timer:within(300 sec)];

               

ルール名	CreateUserLoginandDeleteUser
ルールの説明	ユーザーがユーザー アカウントを作成し、そのユーザーでログインした後、ユーザー アカウントを削除するアクションのパターンを検知します。

例3：

同じソースIPからの過剰な回数のログイン失敗 

EPL 6：@RSAAlert(oneInSeconds=0, identifiers={"ip_src"})

                      

ルール名	ExcessLoginFailure
ルールの説明	同一のユーザーが、一定時間内に複数回、同じソースIPからログインを試行して失敗したパターンを検知します。
ルールのコード	SELECT * FROM          Event(          ip_src IS NOT NULL AND ec_activity=’Logon’ AND ec_outcome = ‘Failure’ ).std:groupwin(ip_src).win:time_length_batch(300 sec, 10) GROUP BY ip_src HAVING COUNT(*) = 10;
注	ip_srcにつきウィンドウを作成します。 time_length_batchを使用します：イベントはバッチで確認します（タンブリング ウィンドウ）。各イベントは単一のウィンドウの一部となります。一定時間が経過するか、一定カウントに達すると、ウィンドウによってイベントがリリースされます。 タンブリング ウィンドウの問題の1つは、バッチの終盤で発生するイベントはアラート発行につながらない可能性があるということです。 後述のt=301の一連のイベントでは、300秒以内にログイン失敗が10回発生したものの、イベントのバッチはt=300でドロップされたため、アラートは発行されません。                                                                           時間（t） 特定のユーザーのログイン失敗 アラート 時間バッチ 0 0 0 1 295 6 0 1 299 3 0 1 301 1 0 2 420 6 0 2 550 3 0 2 600 0 0 3 720 6 0 3 850 3 0 3 900 1 1 3（終了）、4（開始） 前述の問題は、win:time_length_batchウィンドウの代わりに、win:timeウィンドウ（EPL 7）を使用することで解決できます。 外側のgroup byは、一定時間が経過したときにイベントを制御するためのものです。60秒の終わりに9つのイベントがあるとすると、esperエンジンはそれらの9つのイベントをリスナーにプッシュします。カウントは10に等しくないため、Group byとcountによってそれが制限されます。 時間とカウントは必要に応じて変更できます。

EPL 7：@RSAAlert(oneInSeconds=0, identifiers={"ip_src"})

                     

ルール名	ExcessLoginFailure
ルールの説明	同一のユーザーが、一定時間内に複数回、同じソースIPからログインを試行して失敗したパターンを検知します。
ルールのコード	SELECT * FROM                   Event(            ip_src IS NOT NULL AND ec_activity=’Logon’ AND ec_outcome = ‘Failure’    ).std:groupwin(ip_src).win:time (300 sec) GROUP BY ip_src HAVING COUNT(*) = 10
注	これはスライディング ウィンドウであるため、一連のイベントに対してアラートが発行された後、一定時間が経過するまで、それらのイベントが別のアラートに使用されることがあります。 10のイベントがアラートの発生に関わっている場合、最後のイベントのみが表示されます。 <または>を使用した場合は、複数のアラートが表示されることがあります。それに応じて、アラート抑制を使用する必要があります。

例4：

同じソースから同じ宛先への複数の異なるユーザー、または、複数の異なるソースから同じ宛先への単一のユーザーによる複数回のログイン失敗

EPL 8：groupwin、time_length_batch、uniqueの使用

                     

ルール名	MultiplefailedLogins
ルールの説明	次の場合に複数回ログインが失敗したパターンを検知します。 - 同じソースから同じ宛先への複数のユーザー - 複数のソースから同じ宛先への単一のユーザー
ルールのコード	SELECT * FROM  ​  Event( ec_activity='Logon' AND ec_outcome='Failure'  AND  ip_src IS NOT NULL   AND  ip_dst IS NOT NULL AND  user_dst IS NOT NULL ).std:groupwin(ip_src,ip_dst).win:time_length_batch(300 seconds, 5}).std:unique(user_dst) group by ip_src,ip_dst having count(*) = 5;
注	ip.dstとip.srcはすべてのイベントで共通です。 user_dstはすべてのイベントに対して一意です。 5人の異なるユーザーが同じip.srcとip.dstの組み合わせでログインしようとすると、アラートが発行されます。

例5：

指定の時間内にデバイスからのログ トラフィックがない

EPL 9：groupwin、time_length_batch、uniqueの使用

                     

ルール名	NoLogTraffic
ルールの説明	指定の時間内にデバイスからのログ トラフィックが確認されないパターンを検知します。
ルールのコード	SELECT * FROM pattern [every a = Event(device_ip IN ('10.0.0.0','10.0.0.1') AND medium = 32) -> (timer:interval (3600 seconds) AND NOT Event(device_ip = a.device_ip AND device_type = a.device_type AND medium = 32))];
注	ルールではトラフィックが突然失われた状況のみが検出されます。最初からトラフィックがない場合は、アラートが発行されません。ルールでアラートを発行するには、1つ以上のイベントが必要です。 入力としてのデバイスのIPアドレスまたはデバイスのホスト名のリスト。これらのシステムのみがトラッキングされます。 時間の入力が必要です。イベント間の時間間隔が入力した時間を超えると、アラートが発行されます。

例6：

複数回のログイン失敗の後に、同じユーザーによるロックアウト イベントが発生していない

EPL 10：groupwin、time_length_batch、uniqueの使用

                     

ルール名	FailedloginswoLockout
ルールの説明	複数回のログイン失敗の後に、同じユーザーによるロックアウト イベントが発生していないパターンを検知します。
ルールのコード	SELECT * FROM pattern [every-distinct(a.user_dst, a.device_ip, 1 msec) (a= Event(ec_activity='Logon' and ec_outcome='Failure' and user_dst IS NOT NULL) -> [2]( Event( device_ip =a.device_ip and ec_activity='Logon' and ec_outcome='Failure' and user_dst=a.user_dst) AND NOT Event( ( ec_activity='Logon' and ec_outcome='Success' and device_ip = a.device_ip and user_dst=a.user_dst) or (ec_activity='Lockout' and device_ip = a.device_ip and user_dst=a.user_dst)))) where timer:within(60 seconds) -> (timer:interval(30 seconds) and not Event(device_ip=a.device_ip and user_dst=a.user_dst and ec_activity='Lockout')) ];
注	前述のクエリーは、同じユーザーがログインに2回失敗した後に、ロックアウト イベントがないことを検出します。 複数回のログイン失敗は時間が記録され、特定の時間内に発生することが想定されています。また、実際、ロックアウト イベントは、最後のログイン失敗が発生してから短時間で発生することが想定されています。これは、ユーザーあたりのログイン失敗回数の閾値が、通常はドメインで設定されているためです。 この例のクエリーでは、every distinctにより、ユーザーとデバイスの組み合わせの新しいスレッドは1ミリ秒間抑制されます。 3回のログイン失敗の許容時間は、最初の失敗した試行から60秒です。ロックアウト イベントが発生するまでの待機時間は30秒です。

注：
1. メタ キー内の「.」は「_」に置き換える必要があります。
2. すべてのパターンは期限を定める必要があります。
3. ステートメントの前に適切なタグを使用します。
     a) @RSAPersist:
     b) @RSAAlert:

詳細については、次の資料を参照してください。

• EPLのドキュメントについては、http://www.espertech.com/esper/documentation.phpを参照してください。 
• EPLオンライン ツールについては、http://esper-epl-tryout.appspot.com/epltryout/mainform.htmlを参照してください。

Previous Topic:ESAアノテーション

Next Topic:追加の手順

You are here

Table of Contents > ルール ライブラリへのルールの追加 > 詳細EPLルールの追加 > 詳細EPLルールのサンプル