Plongez dans l’univers de la détection et des réponses aux incidents cyber

Pour détecter les incidents de sécurité, nous avons défini les événements à identifier, puis nous avons mis en place la collecte de données.

Mais comment faire concrètement pour détecter les incidents à partir de ces données ? C’est ce qu’on va voir dans ce chapitre !

Comprenez le rôle du SIEM

La détection des incidents à partir de données se fait dans un outil dédié : le SIEM.

Dans la pratique, le SIEM est l’un des outils de base du SOC. C’est votre tour de contrôle qui vous permet de :

• surveiller le SI en temps réel, 24 heures sur 24 et 7 jours sur 7 ;

• définir des alertes en recoupant plusieurs événements ;

• créer des tableaux de visualisation ;

• effectuer des recherches complexes dans les données.

Visualiser l’état du SI

Le travail de visualisation du SOC est essentiel, car on ne va pas regarder les logs défiler un par un, cela n’a aucun sens en termes d’analyse.

Au contraire, un bon analyste est quelqu’un qui fait preuve de pédagogie, et qui conçoit de nouvelles manières de représenter simplement les données qui sont pertinentes !

Rechercher des informations

Lorsque vous devrez traiter l’alerte (on y vient plus tard dans le cours), vous utiliserez le SIEM pour comprendre ce qu’il s’est passé, en posant au SIEM des questions très précises. Vous pouvez afficher ces résultats sous forme de listes ou de graphiques, pour visualiser des quantités ou des variations.

En mêlant visualisation et recherche, vous pouvez avoir très rapidement des réponses pertinentes.

Lever des alertes

Pour détecter les événements recherchés, il faut indiquer au SIEM de lever l’alerte à l’aide d’une règle de détection.

Les règles de détection prennent la forme d’une condition :

• si : “ces différentes conditions sont réunies” ;

• alors : “on génère une alerte” ;

• avec : “tel niveau de sévérité”. 

L’alerte est alors transmise à l’outil de traitement des alertes, le SOAR, que nous présenterons dans la partie suivante.

En fonction du niveau de sécurité adopté, l’alerte peut prendre différentes formes : alerte simplement transmise au SOAR, notification, mail envoyé automatiquement, ticket créé automatiquement, etc.

Identifiez ce qui est malveillant

Il y a plusieurs signaux qui nous permettent d’identifier un événement à caractère malveillant :

• l’événement est anormal, par exemple une modification du mot de passe d’un administrateur au milieu de la nuit, ou deux connexions simultanées depuis deux pays différents ;

• l'événement correspond à une technique de la matrice MITRE ATT&CK que vous devez détecter, par exemple l’exécution d’une macro dans un document reçu par courriel. Il peut s’agir d’un courriel légitime, mais si vous voulez détecter cette technique, vous devez définir une règle, quitte à arbitrer dans un second temps du caractère légitime ;

• l'événement correspond à un événement redouté. Par exemple, si plusieurs centaines de fichiers sont modifiés, cela peut être provoqué par l’activité d’un rançongiciel ! Puisque vous avez identifié ce risque comme étant critique pour votre organisation, vous devez définir une règle qui le détecte ;

• l’événement est nécessaire à l’exploitation d’une vulnérabilité connue ;

• l'événement implique des traces connues d’un attaquant, par exemple une adresse IP utilisée pour distribuer des logiciels malveillants.

Ce genre de trace constitue des indicateurs de compromission (ou IoC, pour Indicator of Compromise) : il peut s’agir d’une adresse IP, d’un nom de domaine, ou d’un fichier que l’on a associé à un acteur malveillant.

Enfin, appuyez-vous sur les outils de sécurité présentés dans le chapitre précédent : EDR, NDR, XDR, etc. Ces outils génèrent directement des alertes, que vous pouvez ajouter à celles définies dans le SIEM.

Utilisez les règles YARA pour détecter des fichiers malveillants

Parmi les différentes manières de définir des règles de détection, les règles YARA sont un moyen standardisé de détecter des fichiers malveillants.

Ces règles permettent d’identifier la présence de certains octets ou de certaines chaînes de caractères.

Par exemple, la règle suivante détecte la présence d’une macro dans un document à partir des conditions suivantes :

• si les premiers octets du fichiers sont la séquence d’octets qui indique un document Excel ;

• si l’une des deux séquences d’octets caractéristique d’une macro ou la chaîne de caractères “Excel 4.0 Macros” est présente ;

• si une adresse IP malveillante connue est présente dans le document. 

rule Doc_Excel_with_Macro
{
    meta:
     Description = "Identifie les fichiers Excel contenant une macro"
    strings:
      $xls_marker     = {D0 CF 11 E0 A1 B1 1A E1}
      $macro_bytes_v1 = {85 00 ?? ?? ?? ?? ?? ?? 01 01}
      $macro_bytes_v2 = {85 00 ?? ?? ?? ?? ?? ?? 02 01}
      $macro_string = "Excel 4.0 Macros"
      $malicious_ip = "185.122.204.14"
    condition:
        $xls_marker at 0 and (1 of ($macro_bytes_v*) or $macro_string) and $malicious_ip
}

Utilisez les règles SIGMA pour chercher des indicateurs dans les journaux

Un autre format standardisé de règles de détection est le format des règles SIGMA. Ces règles définissent une condition à chercher dans un type de log donné.

Dans la pratique, une règle SIGMA est un fichier YAML avec une source de données ( logsource  ) et des conditions ( detection  ).

Par exemple, la règle suivante permet d’identifier des exploitations de la vulnérabilité ZeroLogon :

title: 'Possible Zerologon (CVE-2020-1472) exploitation'
id: dd7876d8-0f09-11eb-adc1-0242ac120002
status: experimental
description: Detects Netlogon Elevation of Privilege Vulnerability aka Zerologon (CVE-2020-1472)
references:

- https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472

- https://www.logpoint.com/en/blog/detecting-zerologon-vulnerability-in-logpoint/
author: 'Aleksandr Akhremchik, @aleqs4ndr, ocsd.community'
date: 2020/10/15
tags:
  - attack.t1068
  - attack.privilege_escalation
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4742
    SourceUserName: 'ANONYMOUS LOGON'
      TargetUserName: '%DC-MACHINE-NAME$%' # DC machine account name that ends with '$'
  filter:
    ChangedAttributes|contains:
      - 'Password Last Set:   -'
  condition: selection and not filter
falsepositives:
  - automatic DC computer account password change
  - legitimate DC computer account password change
level: high

La règle indique dans la section logsource  qu’il s’agit de l’analyse de logs Windows, plus précisément des journaux d’événements  security  . Le mot-clé condition  indique qu’elle cherche dans ces journaux les événements d’event ID 4742 avec certains attributs, sauf ceux qui indiquent un changement de l’attribut  Password Last Set   . Vous remarquerez que les concepteurs de la règle ont pris soin d’indiquer :

• où trouver plus d’informations sur la vulnérabilité ;

• quelle est la technique MITRE ATT&CK qui est détectée ici ;

• quels faux positifs cette règle pouvait générer ;

• quel niveau de criticité ils considèrent pour cette vulnérabilité.

Utilisez les ressources à votre disposition

Tout l’intérêt des règles standardisées comme YARA et SIGMA est que vous n’avez pas à réinventer la roue. Beaucoup de ressources sont disponibles sur Internet. C’est particulièrement important lorsqu’une nouvelle vulnérabilité ou une nouvelle technique d’attaque est identifiée.

En résumé

• Le SIEM est l’outil qui permet de voir et d’analyser tous les logs collectés par le SOC.

• Le SIEM permet de recouper plusieurs événements pour lever des alertes selon des règles préalablement configurées. On parle de corrélation.

• Ces règles sont définies par le SOC à partir des informations obtenues auprès d’autres équipes, via ses activités de Cyber Threat Intelligence (CTI) : bulletins d’alertes, IoC, TTP, etc.

• Les formats YARA et SIGMA standardisent l’écriture des règles et facilitent donc leur partage et leur déploiement.

• MITRE CAR est une ressource très pratique pour récupérer des règles de détection déjà élaborées par d’autres SOC.

Vous avez maintenant vos objectifs, vos outils et vos règles de détection. Votre SOC a presque tout pour fonctionner… sauf une organisation ! 

Dans le prochain chapitre, vous allez découvrir comment organiser et outiller votre SOC pour être efficace au quotidien dans la gestion des incidents.