Découvrez notre société Contactez-nous

e-Xpert Solutions Genève

109, chemin du Pont-Du-Centenaire
CH-1228 Plan-les-Ouates / Genève
SUISSE

Tel. : +41 22 727 05 55 Fax : +41 22 727 05 50

e-Xpert Solutions Lausanne

Avenue de Gratta-Paille 20
CH-1018 Lausanne
SUISSE

Tel. : +41 21 802 26 78 Fax : +41 22 727 05 50
Contactez notre support : +41 22 727 05 56
En cochant cette case, vous acceptez notre politique de confidentialité disponible en cliquant ici
Envoyez votre message

Swiss Security Hackademy

Suivez notre blog bilingue en sécurité informatique !

Retour aux articles

Automatiser la réponse aux incidents de sécurité en entreprise !


Auteur : Michael Molho

Date de publication : 20 juillet 2020 - Dernière mise à jour : 14 juillet 2020


Dans le cadre de nos missions, nous constatons régulièrement que la gestion d’un incident est souvent perçue comme une tâche fastidieuse.
Un incident peut demander aux équipes (aka SOC/Incident Response team), plusieurs heures jusqu’à plusieurs jours de traitement en fonction de l’étendue de la brèche. La complexité du problème est un facteur mais c’est souvent des tâches répétitives qui occupent les ressources.

Les défaillances de la réponse classique aux incidents :

  • Une mauvaise optimisation des coûts liés aux tâches répétées des analystes,
  • Un traitement inadéquat car non exhaustif de l’incident (faux positifs/faux négatifs),
  • Un manquement dans le suivi du processus classique (processus et/ou reporting),
  • Une activité à forte valeur ajoutée délaissée (nouveaux use cases, détection avancée, …) au profit des activités répétitives à faible valeur ajoutée.

Processus usuel de traitement d’un incident de sécurité

Le processus le plus communément appliqué a été créé par le NIST.

Il repose sur un processus d’amélioration continue (roue de Deming) et peut être résumé de la façon suivante :

  • Préparation : Mise en place de plan d’actions à tous les niveaux (People/Process/Products) : Incidents Response Guideline, SOC Book, Incident, Workflows, RACI, use cases, etc.
  • Identification : Détection d’un incident basée sur les différents processus mis en place dans la phase de préparation,
  • Contention : C’est l’action permettant de bloquer une menace en deux phases : Court ou long terme. Cette étape comprend également la collecte de preuves, de la communication, …
  • Éradication : On s‘assure que l’incident n’aura plus d’impact sur l’ensemble du système d’information (analyse des systèmes environnants, réinstallation, etc.),
  • Remise en service : Le ou les systèmes « bloqués » sont remis en production avec un monitoring actif,
  • Enseignements :Le retour d’expérience de l’incident permet de tirer des conclusions sur les forces et faiblesses du traitement mis en place. Des plans d’améliorations sont envisagés notamment au niveau des processus depuis la phase de « Préparation » avec les nouveaux inputs.
Automatiser la réponse aux incidents de sécurité en entreprise !

Le traitement fastidieux des incidents de sécurité n’est pas une fatalité, l’automatisation de processus identifiés et définis à tous les niveaux permet de rendre cette gestion accessible et plus efficace.
La mise en œuvre de cette automatisation était jusqu’à peu un processus requérant des développements personnalisés complexes avec la nécessité pour les développeurs de s’adapter à chaque composant de l’infrastructure cible (Endpoints, Firewalls, IPS, Gateway mail…).

La société américaine Phantom, créée en 2014 avant d'être rachetée puis intégrée à Splunk en 2018, est spécialisée dans l’automatisation et l’orchestration de processus de réponse à incident avec des solutions de standardisation et d’industrialisation. Ce type de solutions est appelée SOAR pour "Security Orchestration, Automation and Response".

Ces technologies permettent d’interagir avec un grand nombre d'équipements de sécurité divers tels que les Antivirus, les IPS, les Firewalls, les postes et serveurs Windows, les serveurs de messagerie Exchange, les Proxies, les APIs Cloud (Virustotal, OpenDNS, …) et les scanners de vulnérabilités.

Fonctionnement

Ce travail d’intégration simplifié est un atout majeur et permet de s’intégrer dans n’importe quel écosystème pour toutes sortes d’activités liées à la réponse à incident.

Automatiser la réponse aux incidents de sécurité en entreprise !

Les solutions de type SOAR fonctionnent généralement sous forme de « Playbooks » gérés en partie de façon graphique via une interface Web bien conçue permettant d’enchainer des actions parmi lesquelles figurent la recherche d’informations, l'enrichissement et le blocage.

Automatiser la réponse aux incidents de sécurité en entreprise !

La gestion de l’incident est d’autant plus facilitée qu’elle est décrite via un workflow construit de façon graphique.

Automatiser la réponse aux incidents de sécurité en entreprise !

Dans ces conditions, il devient donc aisé d’automatiser une tâche répétitive même complexe si celle-ci est bien définie dans la phase de préparation.

Des exemples concrets

Dans le cas de la solution Splunk Phantom, de nombreux cas d’usages sont d’ores et déjà disponibles dans la solution.

Exemple 01 : L’exemple suivant est un cas d’usage régulier des opérateurs SOC : une investigation manuelle sur un fichier joint à un email et le traitement complet d’incidents potentiels qui y sont liés.

Automatiser la réponse aux incidents de sécurité en entreprise !

Investigation en détail selon les étapes du schéma ci-dessus :

  • 1) Identification : Le mail et sa pièce jointe sont récupérés par Phantom (dans une boite générique),
  • 2) Identification : La pièce jointe est envoyée dans une Sandbox (Environnement de test de malwares) qui analyse l’exécution à l’ouverture,
  • 3) - 4) Identification : Si le mail contient des URLs, ces dernières seront analysées avec des moteurs de Threat Intelligence
  • 5) Contention : Une recherche est effectuée dans Splunk avec les indicateurs extraits dans la Sandbox pour déterminer si un utilisateur a été infecté, dans le même temps un dashboard et/ou une alarme sont générés.
  • 6) Contention : Un processus d’investigation et de blocage est initié via Phantom, permettant par exemple de déconnecter les postes infectés, de prévenir les analystes et les managers.
  • 7) Éradication : Le mail est détruit dans l’ensemble des boites mails qui ont pu le recevoir, l’ensemble des utilisateurs victimes sont identifiés et traités de façon formelle.

À noter : L’ensemble de ce processus prend quelques minutes, contre plusieurs heures s’il est effectué par un analyste SOC.


Exemple 02 : Allons plus loin !

Un autre cas concret et représentant un temps d’activité certains pour des analystes concerne la recherche de malwares persistants après « découverte » par un antivirus. Il est courant que les malwares sont détectés par les antivirus sans être supprimés par ces derniers à 100%.
Dans ce cas le processus consiste généralement à avoir une approche de « fast forensic » basée sur une analyse de la mémoire vive ou des outils tiers à la recherche d’indicateurs de compromissions persistants.
Ce processus peut être automatisé !

Automatiser la réponse aux incidents de sécurité en entreprise ! Automatiser la réponse aux incidents de sécurité en entreprise !

Imaginons le workflow suivant sur la base des deux schémas ci-dessus :

  • 1) Identification : Un antivirus détecte un malware sur un serveur,
  • 2) Identification/Contention : Une capture de la mémoire vive est effectuée via l’API de VMWARE,
  • 3) Identification : La capture mémoire est ensuite analysée avec Volatility (memory forensic),
  • 4) Contention : Des indicateurs de compromissions (IPs de Command & Control) persistants sont découverts,
  • 5) Identification/Contention : Ces indicateurs sont recherchés sur le tout le parc,
  • 5) Contention : Changement de VLAN (idem pour d’autres serveurs/workstations compromis identifiés dans la phase précédente),
  • 6) Éradication: Demande de confirmation pour réinstallation des serveurs/workstations,
  • 7) Enseignements: Apport d’informations sur l’incident via le Dashboard Phantom, diffusion des indicateurs de compromission sur les équipements périphériques (Firewall/IPS/Endpoints…).

Ce dernier exemple montre le temps gagné par des analystes pour résoudre un incident puisque l’ensemble des étapes sont automatisées, sécurisées et tracées.

Pour conclure

Anecdotique il y a encore quelques années, l'automatisation de la réponse aux incidents est aujourd'hui un incontournable, allant de pair avec le développement et l'optimisation des SOC. L'objectif premier étant d'éviter la répétition de tâches manuelles d'investigation et de réponse de la part des analystes SOC pour des alertes similaires et potentiellement nombreuses.

Nous constatons aujourd'hui un développement important des solutions de type SOAR, qui gagnent également en maturité de jour en jour. En effet, il existe aujourd'hui tant des solutions commerciales telles que Splunk Phantom, mais aussi des alternatives communautaires telles que Demisto ou même open source telles que Shuffle. Toutes ces solutions développent continuellement des plugins permettant de s'intégrer avec de plus en plus de produits et services, offrant des possibilités d'orchestration toujours plus riches sans introduire de complexité ni de nécessité de développements spécifiques.

Suivant le modèle de SIGMA, standard ouvert permettant de définir des règles de correlation pour détecter des attaques, Demisto a publié et propose le standard COPS (pour "Collaborative Open Playbook Standard") permettant de définir de manière standard des playbooks de réponse à incident. Sans aucune certitude que ce standard soit adopté par la majorité, cette initiative ouvre néanmoins une nouvelle porte à la contribution et au partage communautaire de playbooks.