Warnmeldungen: Beispiele für erweiterte EPL-Regeln

Document created by RSA Information Design and Development on Feb 7, 2017
Version 1Show Document
  • View in full screen mode
  

Im Folgenden sehen Sie die Beispiele für erweiterte ESA-Regeln. Jedes Beispiel bietet mehrere Möglichkeiten zur Implementierung des gleichen Anwendungsbeispiels.

Beispiel Nr. 1: 

Erstellen Sie ein Benutzerkonto und löschen Sie eben dieses Benutzerkonto in 300 Sekunden. Benutzerinformationen werden in der Metadatei user_src gespeichert.

EPL Nr. 1:

                     
RegelnameCreateuseraccountFollowedbyDeletionof Useraccount1
RegelbeschreibungErstellen Sie ein Benutzerkonto, gefolgt von einer Aktion, um eben dieses Benutzerkonto in 300 Sekunden zu löschen.
Regelcode

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');

Hinweis
  • Filtern Sie Ereignisse, die für Muster im vorgegebenen Zeitraum erforderlich sind. Aufgrund der Filterbedingungen sollten nur erforderliche Ereignisse an die Funktion match_recognize übergeben werden. In diesem Fall handelt es sich um Erstellen und Löschen von Benutzerkontoereignissen, d. h. Event(ec_subject='User' AND ec_outcome='Success' AND user_src is NOT NULL AND ec_activity IN ('Create', 'Delete').
  • Partitionieren Sie durch das Erstellen von Buckets. In diesem Fall werden von Esper Buckets pro Wert von user_src erstellt. Und daher weisen beide Ereignisse den gleichen Wert von user_src auf.
  • Definieren Sie das gewünschte Muster. Gegenwärtig ist es auf Erstellen gefolgt von Löschen eingestellt. Sie können mehrfach Erstellen gefolgt von Löschen (C+ D) einstellen. Ein Muster ist einem regulären Ausdruck sehr ähnlich.
  • Dies ist das effizienteste Anwendungsbeispiel.

EPL Nr. 2:

                     
Name der RegelCreateuseraccountFollowedbyDeletionof Useraccount2
RegelbeschreibungErstellen Sie ein Benutzerkonto, gefolgt von einer Aktion, um eben dieses Benutzerkonto in 300 Sekunden zu löschen.
Regelcode

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) ]; 
Hinweis
  • Angenommen, der Benutzer wird zweimal erstellt und einmal gelöscht in dieser Reihenfolge. Dann gibt das oben genannte Muster 2 Warnmeldungen aus.
  • Für jede Benutzererstellung wird ein Thread erstellt.
  • Es gibt keine Möglichkeit, um Threads zu steuern. Es ist wichtig, zeitliche Begrenzungen und vorzugsweise kurze Intervalle anzugeben.

Beispiel Nr. 2: 

Entdecken eines Musters, in dem ein Benutzer ein Benutzerkonto erstellt, gefolgt von der Anmeldung dieses Benutzers und der anschließenden Löschung des Benutzerkontos. Im Fall von Windows-Protokollen werden Benutzerinformationen je nach Ereignis entweder in user_dst oder user_src gespeichert.

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

EPL Nr. 3:

                     
Name der RegelCreateUserLoginandDeleteUser
RegelbeschreibungEntdecken Sie ein Muster, in dem ein Benutzer ein Benutzerkonto erstellt, gefolgt von der Anmeldung dieses Benutzers, gefolgt vom Löschen des Benutzerkontos. 
Regelcode       

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

Hinweis
  • Da user_src/user_dst nicht allen Ereignissen gemeinsam ist, kann keine Partition verwendet werden. 1 einzelner Bucket führt jeweils 1 Muster aus. Beispiel: Wenn der Ereignisstream für Benutzer 1 und 2 C1C2L1D1, C1L1C2D1 lautet, wird keine Warnmeldung ausgegeben, da der Thread C1 von C2 zurückgesetzt wurde. Eine Warnmeldung wird nur ausgegeben, wenn C1L1D1 in dieser Reihenfolge erfolgen und kein anderes Ereignis weder von selben Benutzer noch einem anderen Benutzer dazwischen auftritt. 
  • Eine weitere Lösung wäre die Verwendung eines benannten Fensters, das Zusammenführen von user_dst und user_src in einer einzelne Spalte und die anschließende Ausführung von match_recognize. (EPL Nr. 3). 
  • Muster können ebenfalls verwendet werden. Möglicherweise erhalten Sie mehr Warnmeldungen als erwartet. (EPL Nr. 4).

EPL Nr. 4: Verwenden von NamedWindows und match_recognize

                  
Name der RegelCreateUserLoginandDeleteUser
RegelbeschreibungEntdecken Sie ein Muster, in dem ein Benutzer ein Benutzerkonto erstellt, gefolgt von der Anmeldung dieses Benutzers, gefolgt vom Löschen des Benutzerkontos. 
Regelcode

@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 Nr. 5: Verwenden von 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)];

               
Name der RegelCreateUserLoginandDeleteUser
RegelbeschreibungEntdecken Sie ein Muster, in dem ein Benutzer ein Benutzerkonto erstellt, gefolgt von der Anmeldung dieses Benutzers, gefolgt vom Löschen des Benutzerkontos. 

Beispiel Nr. 3:

Übermäßige Anmeldungsfehler von derselben Quell-IP 

EPL Nr. 6: @RSAAlert(oneInSeconds=0, identifiers={ip_src})

                      
Name der RegelExcessLoginFailure
RegelbeschreibungDerselbe Benutzer versuchte, sich von derselben Quell-IP anzumelden, und die Anmeldung ist fehlgeschlagen 
Regelcode

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;
    

Hinweis
  • Erstellt Fenster gemäß ip_src
  • Verwendet time_length_batch: Prüft Ereignisse in Batches (Rollierendes Fenster). Jedes Ereignis ist nur Teil eines Fensters. Das Fenster gibt Ereignisse frei, wenn entweder die Zeit abgelaufen oder die Anzahl erreicht ist.
  • Eines der Probleme mit rollierenden Fenstern ist, dass Ereignisse, die gegen Batch-Ende auftreten, möglicherweise keine Warnmeldung auslösen.

Obgleich in der folgenden Reihenfolge der Ereignisse bis t=301 10 Anmeldungsfehler für dieselbe Anmeldung in den letzten 300 Sekunden auftraten, wird keine Warnmeldung ausgegeben, da der Ereignis-Batch bei t=300 verworfen wurde.

                                                                         
Zeit tAnmeldungsfehler für bestimmte BenutzerWarnmeldungenZeit-Batch
0001
295601
299301
301102
420602
550302
600003
720603
850303
900113 endet und 4 beginnt
  • Das oben genannte Problem kann mithilfe von win:time-Fenstern (EPL Nr. 7) anstelle von win:time_length_batch-Fenstern gelöst werden.

  • Mit dem äußeren Group by werden Ereignisse nach Ablauf der Zeit gesteuert. Angenommen, es liegen 9 Ereignisse nach 60 Sekunden vor, dann werden diese 9 Ereignisse von der Esper-Engine an den Listener übertragen. Group by und Count führen zu einer Einschränkung, da die Anzahl ungleich 10 ist.

  • Zeit und Anzahl können nach Bedarf geändert werden.

EPL Nr. 7: @RSAAlert(oneInSeconds=0, identifiers={"ip_src"})

                     
Name der RegelExcessLoginFailure
RegelbeschreibungDerselbe Benutzer versuchte, sich von derselben Quell-IP anzumelden, und die Anmeldung ist fehlgeschlagen 
Regelcode

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

Hinweis
  • Hierbei handelt es sich um ein Schiebefenster, d. h. nachdem eine Warnmeldung für eine Reihe von Ereignisse ausgegeben wurde, können sie für eine weitere Warnmeldung verwendet werden, bis die Zeit abgelaufen ist.
  • Wenn 10 Ereignisse an der Auslösung einer Warnmeldung beteiligt waren, wird nur der letzte Ereignisse angezeigt.
  • Wenn < oder > verwendet wird, werden möglicherweise mehrere Warnmeldungen angezeigt. Sie sollten die Warnmeldungsunterdrückung entsprechend einsetzen.

Beispiel Nr. 4:

Mehrere fehlgeschlagene Anmeldungen von verschiedenen Benutzern von derselben Quelle an dasselbe Ziel, ein einzelner Benutzer von mehreren verschiedenen Quellen an dasselbe Ziel.

EPL Nr. 8: Verwenden von groupwin , time_length_batch und unique

                     
Name der RegelMultiplefailedLogins
RegelbeschreibungEs liegen mehrere fehlgeschlagene Anmeldungen für die folgenden Fälle vor:
- von mehreren Benutzern von derselben Quelle an dasselbe Ziel.
- von einem einzelnen Benutzer von mehreren Quellen an dasselbe Ziel. 
Regelcode

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;

Hinweis
  • ip.dst und ip.src sind allen Ereignissen gemeinsam.
  • user_dst ist für alle Ereignisse eindeutig.
  • Eine Warnmeldung wird abgegeben, wenn mindestens 5 verschiedene Benutzer eine Anmeldung von derselben ip.src- und ip.dst-Kombination versuchen.

Beispiel Nr. 5:

Kein Protokollverkehr von einem Gerät in einem vorgegebenen Zeitraum.

EPL Nr. 9: Verwenden von groupwin, time_length und unique

                     
Name der RegelNoLogTraffic
RegelbeschreibungEs wird kein Protokollverkehr von einem Gerät in einem vorgegebenen Zeitraum festgestellt.
Regelcode

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))];

Hinweis
  • Von der Regel wird nur ein plötzlicher Verkehrsrückgang erkannt. Es wird keine Warnmeldung ausgegeben, wenn es überhaupt keinen Datenverkehr gibt. Es ist mindestens ein Ereignis erforderlich, damit aufgrund der Regel eine Warnmeldung ausgegeben wird.
  • Liste der Geräte-IP-Adresse oder Gerätehostnamen als Eingabe. Nur diese Systeme werden nachverfolgt.
  • Eine Zeiteingabe ist erforderlich. Eine Warnmeldung wird ausgegeben, wenn das Zeitintervall zwischen Ereignissen die Eingabezeit überschreitet.

Beispiel Nr. 6:

Mehrere fehlgeschlagene Anmeldungen vom selben Benutzer, auf die KEIN Sperrungsereignis folgt.

EPL Nr. 10: Verwenden von groupwin , time_length_batch und unique

                     
Name der RegelFailedloginswoLockout
RegelbeschreibungEs gibt mehrere fehlgeschlagene Anmeldungen vom selben Benutzer, auf die KEIN Sperrungsereignis folgt.
Regelcode

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'))
];

Hinweis
  • Mit der oben genannten Abfrage wird das Fehlen eines Sperrungsereignisses nach 2 fehlgeschlagenen Anmeldungen vom selben Benutzer erkannt.
  • Der Zeitpunkt des Auftretens der fehlgeschlagenen Anmeldungen wird aufgezeichnet, und es wird davon ausgegangen, dass sie in einem bestimmten Zeitraum auftreten. Außerdem wird in der Praxis davon ausgegangen, dass das Sperrungsereignis kurze Zeit nach der letzten fehlgeschlagenen Anmeldung auftritt, da der Schwellenwert für fehlgeschlagene Anmeldungen pro Benutzer in einer vorgegebenen Domain festgelegt wird.
  • In der aktuellen Abfrage wird durch every-distinct ein neuer Thread mit einer Kombination aus Benutzer und Gerät für 1 Millisekunde unterdrückt.
  • Die für 3 fehlgeschlagene Anmeldungen zulässige Zeit nach dem ersten fehlgeschlagenen Versuch beträgt 60 Sekunden. Die Wartezeit für das Auftreten des Sperrungsereignisses beträgt 30 Sekunden.

Hinweis:
1. “.” in Metaschlüsseln muss durch ("_") ersetzt werden.
2. Alle Muster sollten zeitgebunden sein.
3. Verwenden von entsprechenden Tags vor den Aussagen
     a) @RSAPersist:
     b) @RSAAlert:

Weitere Informationen finden Sie im:

Previous Topic:ESA-Anmerkungen
You are here
Table of Contents > Hinzufügen von Regeln zur Regelbibliothek > Hinzufügen einer erweiterten EPL-Regel > Beispiele für erweiterte EPL-Regeln

Attachments

    Outcomes