Alertes : Exemple de règles EPL avancées

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

Voici des exemples de règles ESA avancées. Pour chaque démonstration, il existe plusieurs façons d'implémenter le même exemple d'utilisation.

Exemple n° 1 : 

Créez un compte utilisateur, puis supprimezle en 300 secondes. Les informations utilisateur sont stockées dans la métavaleur user_src.

EPL n° 1 :

                     
Nom de la règleCreateuseraccountFollowedbyDeletionof Useraccount1
Description de la règleCréez un compte utilisateur, puis effectuez une action permettant de supprimer le même compte utilisateur en 300 secondes.
Code de règle

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

Remarque
  • Filtre les événements nécessaires au modèle dans la période donnée. Les conditions de filtrage doivent être définies de telle sorte que seuls les événements requis sont transmis à la fonction de détection de correspondance. Dans ce cas, il s'agit d'événements de création et de suppression de comptes utilisateur. Exemple : Event(ec_subject='User' AND ec_outcome='Success' AND user_src is NOT NULL AND ec_activity IN ('Create', 'Delete')
  • Partition by crée des buckets. Dans le cas présent, Esper crée des buckets selon la valeur de user_src. Par conséquent, la valeur de user_src est commune aux deux événements.
  • Définissez le modèle souhaité. Actuellement, il correspond à Create suivi de Delete. Vous pouvez effectuer plusieurs créations suivies de suppressions (C+ D). Le modèle est très similaire à une expression régulière.
  • Exemple d'utilisation le plus efficace.

EPL n° 2 :

                     
Nom de la règleCreateuseraccountFollowedbyDeletionof Useraccount2
Description de la règleCréez un compte utilisateur, puis effectuez une action permettant de supprimer le même compte utilisateur en 300 secondes.
Code de règle

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) ]; 
Remarque
  • Admettons qu'un même utilisateur soit créé deux fois, et qu'il soit supprimé une fois dans cet ordre. Dans ce cas, le modèle cidessus déclenche 2 alertes.
  • Un thread est créé pour chaque création d'utilisateur.
  • Il n'existe aucun moyen de contrôler les threads. Il est important d'avoir des limites temporelles et, si possible, de petits intervalles.

Exemple n° 2 : 

Détectez un modèle comportant la création d'un utilisateur, sa connexion, puis sa suppression au final. Dans le cas de logs de fenêtres, les informations utilisateur sont stockées dans user_dst ou user_src en fonction de l'événement.

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

EPL n° 3 :

                     
Nom de la règleCreateUserLoginandDeleteUser
Description de la règleDétectez un schéma dans lequel un utilisateur crée un compte utilisateur suivi de la connexion par le même utilisateur, suivi de la suppression du compte utilisateur. 
Code de règle       

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

Remarque
  • Dans la mesure où user_src/user_dst n'est pas commun à tous les événements, nous ne pouvons pas utiliser le partitionnement. 1 seul bucket exécute 1 modèle à la fois. Par exemple, pour l'utilisateur 1 et 2, si le flux d'événements est C1C2L1D1, C1L1C2D1, aucune alerte n'est émise, car le thread C1 est réinitialisé par C2. Une alerte est émise uniquement si le flux C1L1D1 est dans l'ordre, et si aucun autre événement du même utilisateur ou d'un autre utilisateur n'a lieu dans l'intervalle. 
  • Il existe une autre solution : utiliser une fenêtre nommée, fusionner user_dst et user_src en une seule colonne, puis exécuter la détection de correspondance. (EPL n° 3). 
  • Le modèle peut également être utilisé. Vous risquez d'obtenir plus d'alertes que prévu. (EPL ° 4).

EPL n° 4 : Utilisation de fenêtres nommées et de la détection de correspondance

                  
Nom de la règleCreateUserLoginandDeleteUser
Description de la règleDétectez un schéma dans lequel un utilisateur crée un compte utilisateur suivi de la connexion par le même utilisateur, suivi de la suppression du compte utilisateur. 
Code de règle

@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 n°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)];

               
Nom de la règleCreateUserLoginandDeleteUser
Description de la règleDétectez un schéma dans lequel un utilisateur crée un compte utilisateur suivi de la connexion par le même utilisateur, suivi de la suppression du compte utilisateur. 

Exemple n° 3 :

Nombre excessif d'échecs de connexion à partir de la même adresse IP source 

EPL n°6: @RSAAlert(oneInSeconds=0, identifiers={"ip_src"})

                      
Nom de la règleExcessLoginFailure
Description de la règleLe même utilisateur a essayé de se connecter à partir de la même IP source et a rencontré des échecs de connexion 
Code de règle

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;
    

Remarque
  • Crée la fenêtre selon ip_src
  • Utilise time_length_batch : Examine les événements par lots (fenêtre bascule). Chaque événement fait partie d'une seule fenêtre. La fenêtre libère les événements lorsque le délai est écoulé ou que le nombre est atteint.
  • Les fenêtres bascule posent un problème : les événements qui se produisent vers la fin du lot risquent de ne pas aboutir à une alerte.

Dans la séquence d'événements cidessous, à t=301, bien qu'il y ait eu 10 échecs de la connexion au cours des 300 dernières secondes pour la même connexion, aucune alerte ne se déclenche, car le lot d'événements a été interrompu à t=300

                                                                         
Temps tÉchecs de la connexion pour des utilisateurs spécifiquesAlerteLot temporel
0001
295601
299301
301102
420602
550302
600003
720603
850303
900113 se termine et 4 commence
  • Vous pouvez résoudre le problème cidessus en utilisant des fenêtres win:time (EPL n° 7) au lieu des fenêtres win:time_length_batch.

  • Le regroupement externe contrôle les événements au fil du temps. Admettons que vous ayez 9 événements à la fin de 60 secondes, le moteur Esper va transmettre ces 9 événements au Listener. Les clauses de regroupement et de nombre vont limiter cette situation, car le nombre n'est pas égal à 10.

  • Vous pouvez modifier les valeurs de temps et de nombre comme vous le souhaitez.

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

                     
Nom de la règleExcessLoginFailure
Description de la règleLe même utilisateur a essayé de se connecter à partir de la même IP source et a rencontré des échecs de connexion 
Code de règle

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

Remarque
  • Il s'agit d'une fenêtre glissante. Par conséquent, une fois qu'une alerte est déclenchée pour un ensemble d'événements, ceuxci peuvent être utilisés pour une autre alerte jusqu'à ce que le délai soit dépassé.
  • Si 10 événements sont impliqués dans le déclenchement d'une alerte, seul le dernier événement apparaît
  • Si vous utilisez < ou >, il est possible que plusieurs alertes soient visibles. Vous devez utiliser la suppression d'alerte en conséquence.

Exemple n° 4 :

Plusieurs échecs de connexion de plusieurs utilisateurs différents, de la même source vers la même destination. Plusieurs échecs de connexion d'un seul utilisateur, de plusieurs sources différentes vers la même destination.

EPL n° 8 : utilisation de groupwin, time_length_batch et unique

                     
Nom de la règleMultiplefailedLogins
Description de la règleIl existe plusieurs échecs de connexion pour les cas suivants :
de plusieurs utilisateurs, de la même source vers la même destination ;
d'un seul utilisateur, de plusieurs sources vers la même destination. 
Code de règle

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;

Remarque
  • ip.dst et ip.src sont communs à tous les événements.
  • user_dst est unique pour tous les événements.
  • L'alerte se déclenche lorsqu'au moins 5 utilisateurs différents essaient de se connecter à partir de la même combinaison ip.src et ip.dst.

Exemple n° 5 :

Aucun trafic de log en provenance d'un périphérique dans une période donnée.

EPL n° 9 : utilisation de groupwin, time_length_batch et unique

                     
Nom de la règleNoLogTraffic
Description de la règleAucun trafic de log constaté en provenance d'un périphérique dans une période donnée.
Code de règle

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

Remarque
  • La règle détecte uniquement une chute soudaine de trafic. Elle ne déclenche pas d'alerte si le trafic est inexistant. Vous avez besoin d'au moins 1 événement pour que la règle envoie l'alerte.
  • Liste des adresses IP ou des noms d'hôtes de périphériques en entrée. Seuls ces systèmes peuvent être analysés.
  • L'entrée du délai est obligatoire. L'alerte est déclenchée lorsque l'intervalle de temps entre les événements dépasse la durée d'entrée.

Exemple n° 6 :

Plusieurs échecs de connexion NON suivis d'un événement de verrouillage par le même utilisateur.

EPL n° 10 : utilisation de groupwin, time_length_batch et unique

                     
Nom de la règleFailedloginswoLockout
Description de la règlePlusieurs échecs de connexion du même utilisateur ne sont pas suivis de l'événement de verrouillage (Lockout).
Code de règle

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

Remarque
  • La requête ci-dessus détecte l'absence d'un événement de verrouillage après l'occurrence de 2 échecs de connexion pour le même utilisateur.
  • Les nombreux échecs de connexion sont recensés et supposés se produire dans un laps de temps donné. De plus, dans la pratique, on support que l'événement de verrouillage se produit dans un court délai après l'occurrence du dernier événement d'échec de connexion, car la valeur de seuil des échecs de connexion par utilisateur est définie dans un domaine donné.
  • Dans la requête actuelle, chaque élément distinct supprime un nouveau fil pour l'association de l'utilisateur et du périphérique pendant 1 milliseconde.
  • Le délai alloué pour 3 échecs de connexion est de 60 secondes, à partir du 1er échec. Le temps d'attente de l'événement de verrouillage est de 30 secondes

Remarque :
1. “.” dans les clés méta doit être remplacé par (”_”).
2. Tous les modèles doivent avoir une limite temporelle.
3. Les balises appropriées doivent être utilisées devant les instructions
     a) @RSAPersist:
     b) @RSAAlert :

Pour obtenir des informations supplémentaires, consultez :

Previous Topic:Annotations ESA
You are here
Table of Contents > Ajouter des règles à la Bibliothèque de règles > Ajouter une règle EPL avancée > Exemple de règles EPL avancées

Attachments

    Outcomes