SIEM & SOAR

Security Information Event Manager

What is a SIEM & SOAR ?

Un SIEM est un outil généralement utilisé par des équipes de sécurité dédiées afin d'avoir une gestion unifié de la détection dans leur organisations.

Il est possible de remonter toutes formes d'évènements et ce, dans des environnement différents : full cloud, hybrid ou on-prem.

Architecture

Les outils SIEM collectent, agrègent et analysent en temps réel d’importants volumes de données issues des applications, appareils, serveurs et utilisateurs d’une organisation afin de permettre aux équipes chargées de la sécurité de détecter et de bloquer les attaques

Les outils SOAR eux, s'utilisent dans la continuité de l'exploitation du SIEM. Ils permettent d'effectuer des actions automatisées selon des playbooks qui ont été déterminés. Ces playbooks peuvent être configurés de sorte à déclencher des actions à but informatif (e.g. envoyer un mail notifiant la connexion d'un compte Global Admin). Ou bien même afin de déclencher des actions de remédiation (e.g. Isoler un Device du réseau)

Les possibilités sont très nombreuses, et s'adaptent donc à des environnements très variés.

Data Connectors

Les Data Connectors sont ce qui permet au SIEM d'aggréger les données de toutes provenances, qu'ils proviennent du même éditeur de la solution SIEM (solutions natives), d'outils conçus dans l'objectif d'être connectés à un SIEM en facilitant donc leur intégration (solutions intégrées) et enfin les source de données plus anciennes (: legacy) qui peuvent tout de même être connectées à un SIEM mais en fournissant un plus grand effort de configuration.

Parmis les nombreuses sources de données, on y retrouve surtout :

Solutions de sécurités : EDR/EPP, IDP/IPS, Firewall, CASB, Protection messagerie, etc
Périphérique réseau : Modems, Routeurs, Hubs, etc
Serveurs : Web

Solutions natives

Les solutions conçues par le même éditeur que votre SIEM permettent très souvent une intégration des sources de données beaucoup plus facile que les catégories suivantes.

e.g intégration de la suite Microsoft Defender avec Sentinel très simplifiée.

Solutions intégrées

Les SIEM proposent souvent une intégration avec des solutions partenaires facilitant largement leur connexion.

La connexion se fait via une API read-only (pour l'utilisation seule du SIEM) permettant de communiquer les données sous un format commun permettant une interopérabilité entre les différentes sources, facilitant ainsi leur analyse.

Solutions non-intégrées

Syslog [Legacy]

Un serveur syslog permet de superviser des données locales qui ne pourraient être que très peu digeste si consulté une à une.

Il y a la nécessité d'installer un agent log collector pour communiquer ces données locale à votre SIEM pour étendre la gouvernance de celui-ci.

Il est nécessaire de savoir qu'une étape de parsing (formatage de log) est nécessaire pour avoir un format commun des autres sources de données.

Common Event Format [CEF]

Le CEF se range dans la même catégorie que le syslog et globalement a la même architecture à la seule différence de l'agent log collector qui permet de collecter et forwarder les données au SIEM.

C'est un format préférable au Syslog par sa facilité d'intéropérabilité avec les autres sources de données.

Log Analysis

Une fois les données ingérées par le SIEM, elles deviennent obsolètes si aucun dispositif d'analyse ne les traite et tout l'enjeu d'un SIEM se trouve dans cette problématique dont les solutions sont nombreuses.

Là où certaines solutions de sécurité (EDR entre autres) offrent déjà la possibilité d'ingérer et d'analyser des données elles ne permettent pas de couvrir une aussi large variété de produits et ne couvrent en général qu'un type d'asset (EDR couvre uniquement les Endpoints).

Le SIEM ne couvre pas qu'une large variété de sources de données mais permet aussi de les mettre en corrélation afin de comprendre du mieux possible la Kill-Chain de chaque attaque avec les différentes techniques utilisées.

Langage

Afin d'analyser les données ingérées, il est nécessaire d'effectuer des requêtes qui doivent souvent être écrites dans un langage spécifique à chaque éditeur de solutions.

e.g. SPL : Splunk Search Processing Language (Splunk) KQL : Kusto Query Language (Microsoft) FQL : Falcon Query Language (Crowdstrike)

Detection Rules

Les règles de détections permettent d'effectuer de la recherche dans les logs collectés selon les paramètres de votre requête écrite dans le language spécifique à votre solution de sécurité.

Les requêtes de détection permettent d'avoir plus de renseignement lors d'une investigation ponctuelle, mais peuvent aussi s'effectuer de manière programmée afin de détecter des certains comportements.

Il est important d'effectuer une veille sur ces règles de détection pour réduire au possible les faux négatifs. Les communautés sont relativement engagées, actives et mettent souvent à jour les repo de règles de détections. Elles peuvent être des template très intéressant à adapter à chaque environnement.

e.g. Kusto Query (for Sentinel) permettant d'analyser les connexions à des IP blacklistées

```kusto
// this rule detects made connections agains high confidence black list feed
//
//————————————————— TIME WINDOW VARIABLE ——————————————————————//
    let var_ago = ago(24h);
//——————————————————————— USECASE LOGIC ———————————————————————//
let threatwebHighConfidence = (externaldata(ip: string ) [@"https://www.threatweb.com/access/Malware-IPs-High_Confidence_BL.txt"]
    with (format="txt"))
        | project ip;
threatwebHighConfidence
    | extend data = parse_csv(ip)
    | extend IOC_IP = tostring(data[0])
        | join (
            DeviceNetworkEvents | where Timestamp > var_ago
                ) on $left.IOC_IP == $right.RemoteIP
            | project Timestamp,DeviceId, DeviceName, ReportId, ActionType, LocalIP, LocalPort, Protocol, RemoteIP, RemotePort, RemoteUrl,InitiatingProcessParentFileName,InitiatingProcessFolderPath,InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountUpn, InitiatingProcessIntegrityLevel, RuleVersion
```

For more log analytics queries :

repo

detection.fyi

sigma

microsoft

Machine Learning

Built-in ML

Certaines solutions intègrent des modules de Machine Learning permettant à partir des logs de faire de l'analyse compertementale sur des comportement connus à partir d'une base de donnée très générique (qui correspond à l'ensemble des comportement suspect analysé sur l'ensemble des clients de l'éditeur de la solution SIEM)

L'utilisation de Machine Learning ne doit pas exclure la présence de règles de détection configurées selon des paramètres fixes.

BYO-ML

Pour les organisation ayant des équipes d'analyse de données, il est possible d'utiliser ses propres modèles de Machine Learning pour l'analyse comportementale.

L'implémentation de ses propres modèles d'analyse engagent de forte contraintes, que ce soit en terme de coûts, de ressources humaines et d'infrastructure.

SOAR

Une solution SOAR contient toutes les fonctionnalités que l'on retrouve dans un SIEM classique, hormis que nous avons la possibilité d'effectuer des actions de remédiation depuis la console SIEM.

Playbook (Automation)

Les playbook permettent d'automatiser les actions de remédiation selon des paramètres définis, qui peuvent être le déclenchement d'une alerte. Ces actions permettent de gagner du temps mais surtout de prendre l'action au moment de la détection sans devoir attendre qu'un analyste SOC prenne la tâche dû à diverse raison (détection hors temps de travail ou bien une erreur d'inattention).

Bien évidemment se pose la problématique de faux positifs qui peut provenir d'une mauvaise configuration de règle si trop récurrentes mais aussi plus rarement qui sont dû à un simple mauvais verdict donné par l'analyse. Dans ce cas de figure il est important de mettre en place des workload de revue des actions prises par les playbook, car la sécurité ne doit pas entraver la productivité.

e.g.

For more Playbooks :

Managed Detection & Reponse

Sous traiter la gestion de sa détection et réponse à incidents présente un grand avantage pour la grande majorité des entreprises.

Les services MDR permettent d'effectuer une grande économie d'argent, de temps et de supervision. Ils apportent en plus de cela une expertise et une connaissance beaucoup plus pointue des campagnes d'attaques de par la gestion d'autres clients du même secteurs d'activités soumis au mêmes.

Les PME étant bien plus attaqués que les grandes entreprises, se sont aussi les moins équpiées et préparées à l'eventualité de subir des attaques. La causalité provient du seuil critique à partir duquel l'investissement en cybersécurité devient rentable n'étant pas atteint par l'extrême majorité des entreprises.

Ces services commençant à se faire connaître aurpès des entreprises, les solutions répondent de plus en plus à ce genre de besoin pour faciliter leur implémentation.

e.g. Azure Lighthouse

Solutions sur le marché

Parmis les nombreux éditeurs de produits de sécurité on peut retrouver les solutions SIEM suivantes

Solution

Editor

Sentinel

Microsoft

Chronicle

Google

Splunk

QRadar

IBM

Elastick Stack

Elastick

NextEDR

Last updated 1 year ago