SecurityInsider
Le blog des experts sécurité Wavestone

Focus sur les jetons JWT

Introduction

JWT (JSON Web Token) définit dans la RFC 7519 est un standard permettant la transmission d’information entre deux parties via l’utilisation d’objets JSON. JWT repose sur les standards JSON Web Signature (JWS) et JSON Web Encryption (JWE) permettant d’assurer l’intégrité et / ou la confidentialité des données transmises. En pratique, les jetons JWT sont principalement utilisés afin de sécuriser l’accès à des Web services REST ou encore comme solution de SSO.

Exemple d’utilisation des jetons JWT dans le cas d’un SSO :

L’utilisation de jetons JWT permet la mise en place d’application « stateless» et ainsi supprimer la dépendance des sessions. Ainsi la mise en place de ce type de jeton est souvent vue comme une protection contre les attaques CSRF.

Format

Les jetons JWT sont constitués de différentes parties chacune séparée par le caractère point « . ». Bien que le nombre de parties puisse varier, les jetons JWT sont souvent constitués de trois parties : 

Figure 3 : Format d’un jeton JWT
  • Entête : permet de déclarer que le format JWT est utilisé et de préciser l’algorithme (et potentiellement ses paramètres) utilisé pour la signature numérique et / ou le chiffrement.
{
  "alg": "HS256",
  "typ": "JWT"
}
  • Charge utile : représente l’objet à transmettre au format JSON. Il peut posséder différents attributs / affirmations dont certains sont définis par la RFC (iss, sub, iat, exp…) :
{
  "sub": "1234567890",
  "name": "anonymous",
  "society": "Wavestone",
  "email": "anonymous@wavestone.com",
  "isadmin": false
}
  • Signature : cette partie permet  au destinataire du jeton de pouvoir vérifier l’intégrité du message ainsi que l’identité de l’émetteur :
35cbb7559f29a26e1220983cc059965eadd005d6deeba450a05b70bcfe52eae3
La signature du message est calculée de la façon suivante :
key           = 'laclesecrete'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature     = HMAC-SHA256(key, unsignedToken)
Ensuite, l’ensemble des parties sont encodés en base64 (en mode URL compatible et sans les caractères « = » de bourrage) et concaténée (séparées par le caractère « . ») pour être transmise dans les requêtes. Pour l’exemple précédent, le jeton JWT encodé est le suivant :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
.
Ncu3VZ8pom4SIJg8wFmWXq3QBdbe66RQoFtwvP5S6uM

Cryptographie

Afin d’assurer la sécurité (authentification, confidentialité, intégrité) des données transmises, le standard JWS s’appuie sur les standards JWS et JWE.

Signature

Le standard JWA définit les algorithmes de signature numérique et MACs pouvant être utilisés, le standard JWT n’impose que le support des suivants :
  • None
  • HS256 : HMAC-SHA-256
Cependant, les algorithmes asymétriques suivants sont supportés par les principales implémentations :
  • RS256: RSA (PKCS1-v1.5) et SHA-1
  • ES256: ECDSA (P-256) et SHA-256

Chiffrement

Le support du chiffrement pour les jetons JWT est optionnel, les algorithmes les plus souvent supportés sont les suivants :
  • RSA1_5 : RSA (PKCS1-v1_5) et AES
  • A128CBC-HS256 : AES-CBC et HMAC-SHA2

Sécurité

Algorithme « none »

Alors que les algorithmes de chiffrement et de signature supportés sont majoritairement robustes, le support de la méthode « None » par les serveurs représente un réel risque. En effet, si cette méthode est considérée comme valide par le client JWT alors un attaquant est en capacité de forger ou d’altérer le contenu d’un message.
Dans l’exemple ci-dessus, il faudrait alors modifier l’entête :
{
  "alg": "none",
  "typ": "JWT"
}
Le jeton transmis serait le suivant :
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
.

Attaque par recherche exhaustive

L’ensemble de la sécurité des jetons JWT repose sur la confidentialité de la clé de chiffrement. Bien qu’aucune attaque efficace ne soit connue, un attaquant pourrait tenter de la récupérer par recherche exhaustive. Pour les modes HMAC, il est alors possible d’utiliser l’outil John jumbo afin d’effectuer ce type d’attaques en mode « hors connexion ».
Afin de faciliter ce type d’attaque, nous avons développé un script prenant en entrée un jeton JWT et fournissant en sortie un format utilisable par John jumbo.

Lors d’un test d’intrusion, nous avons également été surpris de pouvoir valider un jeton JWT obtenu auprès de l’application testée sur le site jwt.io :

Il se trouve que le secret utilisé par l’application pour signer les jetons avait une valeur par défaut, à savoir « secret »…. Importance du choix de l’algorithme de signature / chiffrement
Dans une architecture utilisant des jetons JWT, les clients ont besoins de connaitre :
  • La clé partagée : si un algorithme symétrique est utilisé (HMAC, AES…) ;
  • La clé publique : si un algorithme asymétrique est utilisé (RSA, ECDSA…).
Par conséquent, en cas d’utilisation d’un algorithme symétrique, les clients (service providers…) sont aussi en capacité de signer / chiffrer un jeton ; en cas de compromission d’un client par un attaquant, ce dernier pourrait alors tenter de compromettre la totalité de l’infrastructure (via la construction de jetons spécifiques). Ainsi, il est préférable d’utiliser des algorithmes de chiffrement asymétriques s’il n’est pas nécessaire que les clients (service providers…) puissent signer des jetons.

Vérification de la signature

La vérification de la signature est une étape sensible et doit ainsi être correctement implémentée. En 2015, une vulnérabilité permettant sur l’implémentation des mécanismes de vérification de signature affectant de nombreux composants (node.js, pyjwt, php-jwt...) a ainsi été signalée par Tim McLean. Sous certaines conditions, cette vulnérabilité permettait alors à un attaquant d’utiliser une clé publique RSA afin de signer un jeton via HMAC et ainsi de pouvoir générer des jetons acceptés par les applications clientes.

Dangers du stockage local

Certaines applications conservent les jetons localement afin de pouvoir les utiliser ultérieurement via l’utilisation de code côté client (JavaScript…) notamment pour les applications « stateless » dont la taille des jetons est importante. Alors que les cookies sont protégés par les attributs « secure » et « httpOnly », les jetons manipulés par le JavaScript ne possèdent quant à eux aucun attribut de sécurité et sont ainsi vulnérable à des attaques de type vol de session (pas d’équivalent de « httpOnly ») ou encore transmission des jetons sur des canaux non sécurisés (pas d’équivalent de l’attribut « secure »).

Conclusion

L’utilisation de jeton JWT permet d’augmenter la sécurité des Web services via la mise en place de certains mécanismes cryptographiques. Cependant, la sécurité ne pourra être assurée qu’à condition de définir les différents éléments en fonction de leurs cas d’usage. Il sera ainsi nécessaire de :
  • Utiliser des clés de taille suffisamment grande ;
  • Adapter les algorithmes cryptographiques utilisés au contexte de l’application (SSO, Web service unique…) ;
  • Mettre en place des mécanismes anti-rejeu (limiter la durée de vie des sessions…) ;
  • Prévoir des mécanismes d’invalidation de jeton ;
  • Conserver les clés de chiffrement de manière sécurisée.
Ressources :
Mahdi BRAIK

Compte-rendu de la BotConf 2016

La quatrième édition de la BotConf se tenait cette année du 30 novembre au 2 décembre, à l’université Lyon 2. Cette conférence, orientée sur la lutte contre les botnets, a regroupé une vingtaine de présentations en anglais dont voici un bref compte-rendu.

Locky, Dridex, Necurs: the evil triad

Après une introduction d’Éric Freysinnet, Jean-Michel Picot, de Google, a présenté la façon dont les malwares sont perçus du point de vue de Gmail. Une grande partie de la présentation fut dédiée aux techniques utilisés par ces malwares pour éviter la détection. La présentation étant identifiée comme confidentielle, les détails ne seront pas divulgués dans cet article.

Visiting the Bear’s Den

Jessy Campos de la société ESET, prit alors la parole pour présenter son travail, ainsi que celui de Joan Calvet et Thomas Dupuy qui étaient absents, concernant le groupe d’attaquants connu sous le nom de Sednit, ou encore APT28, Fancy Bear, Sofacy, et bien d’autres. Le groupe Sednit vise principalement des personnes impliquées dans la vie politique d’Europe de l’est. Les capacités des personnes qui composent le groupe sont très avancées, preuve en est l’utilisation de nombreuses 0-days et d’un outillage bien fourni.

Au travers de l’histoire de Serge, une cible imaginaire du groupe Sednit, Jessy Campos a présenté le déroulement d’une attaque, ainsi que les différents outils que son équipe et lui ont pu analyser.

Lundi, 9h30, Serge ouvre un email, et clique sur un lien dont l’URL ressemble fortement à une URL légitime. Malheureusement pour lui, il fait alors la rencontre de SEDKIT. SEDKIT est un Exploit Kit utilisé pour la première fois en septembre 2014, et encore actif de nos jours. Généralement transmis par le biais d’un mail de phishing, l’outil permet aux membres de Sednit de sélectionner leurs cibles.
Imitation d’URLs légitimes dans les mails de phishing
Une fois la cible choisie, SEDKIT va alors télécharger SEDUPLOADER, un outil composé de deux parties, un dropper et une charge malveillante, aperçu pour la première fois en mars 2015, et étant toujours actif. Au travers d’un workflow en quatre étapes durant lesquelles de nombreuses techniques sont utilisées, SEDUPLOADER va télécharger SEDRECO.

Workflow suivi par SEDUPLOADER
Lundi, 10h, Serge est donc infecté par SEDRECO. Cette backdoor, vu pour la première fois en 2012, et toujours active, a la capacité de charger des plugins externes. C’est la configuration de cette charge malveillante, présente dans un fichier « .msd » chiffré, qui va donc définir les actions de SEDRECO, avec toujours pour objectif l’espionnage des actions effectuées sur le terminal infecté.
Extrait des fonctionnalités proposées par SEDRECO
SEDUPLOADER va également permettre le téléchargement de l’outil XAGENT, une backdoor modulaire disposant de versions pour Windows, Linux et iOS, généralement déployée par le groupe Sednit après la phase de reconnaissance. Cet outil va alors permettre l’extraction d’informations jusqu’au serveur C&C par le biais de mails dont l’objet, le contenu, ainsi que les pièces jointes se doivent de sembler le plus légitime possible.
Schéma d’extraction des données par XAGENT
À partir de ce moment, les différentes informations et actions de Serge sont enregistrées et envoyées au serveur C&C. Différents codes malveillants permettent ainsi l’extraction des mots de passe, mais également la prise de captures d’écran à chaque déplacement de souris. De plus, l’outil XTUNNEL permet les mouvements latéraux au sein du Système d’Information de Serge.
Mouvements latéraux effectués par XTUNNEL
L’arsenal de Sednit contient également de nombreux moyens de persistance que Jessy Campos a pu détailler lors de sa conférence.
Le support de présentation, ainsi que des papiers de recherche sur le groupe, sont disponibles aux adresses suivantes pour de plus amples informations :


LURK – The story about Five Years of Activity

Vladimir Kroporov de Trend Micro a alors présenté un autre groupe d’attaquants que lui et Fyodor Yarochkin, de l’académie Sinica, ont pu étudier. Ce groupe, qui vise principalement la Russie à l’aide du banking trojan LURK, est actif depuis de nombreuses années. LURK a en effet été détecté pour la première fois en 2011, et est le premier malware à intégrer une charge malveillante directement en mémoire, ce qui rend complexe sa détection, mais implique l’absence de persistance.

Vladimir Kroporov a présenté les différents patterns permettant la détection de LURK, ainsi que l’infrastructure, les méthodes, et l’évolution du malware. Les supports de présentation peuvent être trouvés à l’adresse suivante :

Browser-based Malware: Evolution and Prevention

Ce fût ensuite au tour de Andrey Kovalev et Evgeny Sidorov, travaillant pour Yandex, d’effectuer leur présentation sur les attaques de type Man-in-the-Browser utilisées par certains malwares. Ce type d’attaques consiste à intercepter et détourner les appels entre le navigateur et ses mécanismes de sécurité. Les attaques de ce type proviennent principalement d’extensions, de proxy WFP, ou encore de VPN.
Principe de fonctionnement d’une attaque Man-in-the-Browser
La suite de la présentation fût consacrée à la présentation des malwares Eko et SmartBrowse. Eko est une extension malveillante pour Chrome. Pour parvenir à faire installer cette extension à d’autres cibles, Eko utilise la technique précédente pour envoyer aux contacts des messages privés Facebook contenant un lien vers cette extension. Une fois le navigateur infecté, Eko va récupérer les accès au compte Facebook de l’utilisateur.
Architecture du malware Eko
SmartBrowse est également une extension Chrome malveillante qui sert de plateforme pour l’installation d’autres malwares. L’une des fonctionnalités de SmartBrowse est qu’il parvient à passer outre le mécanisme de sécurité interdisant l’installation d’extensions.
Architecture du malware SmartBrowse
Concernant la détection et la protection de ce type d’attaque, les techniques sont limitées. L’utilisation de Content-Security-Policy, habituellement utilisé pour limiter les attaques de type XSS, est une première approche mais peut être contrôlé par les extensions. Une autre approche est la validation de l’intégrité du code en JavaScript. Cette méthode est plus complexe à contourner pour les malwares, étant donné que la suppression du script de détection risque de limiter les fonctionnalités de la page.
Le support de présentation est disponible à l’adresse suivante :



Language Agnostic Botnet Detection Based on ESOM and DNS

Cette présentation, effectuée par Rocco Mandrysh de RUAG, présente les travaux qu’il a effectué avec Christian Dietz, Urs Anliker et Gabi Dreo, à propos d’une méthode de détection des malwares à partir de noms de domaine. Les malwares, comme l’explique Rocco Mandrysh, utilisent souvent des algorithmes de génération de noms de domaine (DGA) qui, si leur fonctionnement peut être déduit à partir des exécutables, pourraient permettre de générer la liste des domaines possiblement utilisés par un malware donné, créant ainsi une liste d’IOC complète.
L’approche de Rocco Mandrysh et de ses collègues vient compléter cette pensée en présentant une méthode par machine learning, permettant de regrouper les malwares sur une carte en utilisant l’outil ESOM, facilitant ainsi leur identification.
Exemple de sortie d’ESOM
Le support de présentation est disponible à l’adresse suivante :

 

Vawtrak Banking Trojan: A threat to the Banking Ecosystem

Raashid Bhat et Victor Acin, de l’entreprise Blueliv, ont présenté leurs travaux d’analyse sur le malware Vawtrak. Ce malware, historiquement nommé Neverquest, a été observé pour la première fois en 2013 et a beaucoup évolué depuis. C’est un cheval de Troie à visée financière qui utilise des techniques avancées de type Man-in-the-Browser pour parvenir à récupérer les identifiants des utilisateurs infectés.
Le support de présentation, ainsi que l’analyse technique du malware, sont accessibles aux URLs suivantes :

Snoring Is Optional: The Metrics and Economics of cyber Insurance for Malware Related Claims

Wayne Crowder, travaillant chez Risk Analytics, a effectué une présentation non technique sur les botnets, en prenant le point de vue des cyber-assurances. Cette présentation, reprend les différents éléments qui composent une bonne cyber-assurance, ainsi que de nombreux exemples et chiffres d’attaques passées.
Le support de présentation est disponible à l’URL suivante :
 

Hunting Droids from the Inside

Lukasz Siewierski, également de Google, a conclu la première journée en présentant différentes méthodes utilisées par les botnets Android. Cette présentation étant également confidentielle, les détails ne seront pas présentés dans cet article


Ransomware and Beyond

Pour entamer le deuxième jour de conférence, Christiaan Beek travaillant chez Intel Security a choisi de parler de ransomwares, et notamment de leur évolution cette année. Après une brève introduction sur les différentes familles de ransomwares en 2015, ainsi que sur l’intérêt grandissant pour le terme dans les recherches Google cette même année, Christiaan s’est donc concentré sur une année qui a vu de nombreuses évolutions chez les ransomwares : 2016.
Le nombre de ransomwares, mais également les techniques utilisées par cette famille de malware a en effet grandement évolué cette année, avec des exemples comme Petya et Mamba qui réalisent respectivement un chiffrement partiel (MBR) et complet du disque.
Évolution des techniques utilisées par les ransomwares ces derniers mois
Christiaan a ensuite continué sa présentation en expliquant pourquoi les ransomwares sont tant utilisés. L’un des arguments qu’il a évoqué est notamment la « satisfaction client », qui peut paraitre étonnant pour un malware, mais s’applique parfaitement pour la sous famille des ransomwares. En effet, il n’est pas rare de voir sur les forums des messages de remerciement écrits par les victimes et à destination des attaquants, expliquant qu’ils ont bien reçu la clé de déchiffrement après avoir payé. Certains ransomwares proposent même de poser directement des questions aux attaquants, même s’il semble assez rare que des négociations aboutissent.
Exemple de page de contact provenant d’un ransomware
Enfin, Christiaan a présenté sa démarche d’utilisation du machine learning dans l’objectif d’améliorer la détection et le classement des ransomwares, pour enfin finir par la présentation de la plateforme « No more ransom ! » dont l’objectif est la mise à disposition par les professionnels de techniques de déchiffrement adaptées aux ransomwares.
Page d’accueil du site nomoreransom.org
Le support de la présentation est disponible à l’adresse suivante :


Attacking Linux/Moose 2.0 Unraveled an EGO MARKET

La seconde présentation de la journée fût celle d’Olivier Bilodeau et Masarah Paquet-Clouston travaillant chez GoSecure, qui présentaient leurs travaux de recherche sur le botnet Linux/Moose. Ce sujet, qui avait déjà été abordé en 2015, fût largement orienté sur les cibles et le marché du botnet.
Le support de présentation ainsi qu’un article complémentaire sont disponibles aux adresses suivantes :

Tracking Exploit Kits

John Bambenek, travaillant pour Fidelis Cybersecurity, a ensuite effectué une présentation sur la traque des Exploit Kits. L’objectif d’une telle traque est la mise à mal de l’écosystème qui tourne autour des Exploit Kits. John a présenté différentes techniques et outils pouvant faciliter cette démarche, comme par exemple l’outil ekdeco ou encore le site contagiodump.blogspot.fr.

Le support de présentation est accessible à l’adresse suivante :

Improve DDoS Botnet Tracking With Honeypots

La présentation suivante, effectuée par Ya Liu, du laboratoire de recherche en sécurité réseau de Qihoo 360 avait pour objet l’utilisation de honeypots dans la traque des botnets, et notamment l’identification de familles de botnets à l’aide des algorithmes de génération de paquets (PGA).
Le support de la présentation est disponible à l’adresse suivante :

Function Identification and Recovery Signature Tool

Angel Villega a conclu la matinée en présentant l’outil FIRST, un plugin IDA permettant l’identification de fonctions partagées par de multiples échantillons de malware. Les analystes pourraient donc rapidement identifier des fonctions déjà étudiées, automatisant ainsi les tâches répétitives. Le plugin se base sur une base de données qu’il est possible d’héberger sur un serveur en interne, et un serveur publique est déjà disponible : first-plugin.us.
Le support de présentation est accessible à l’adresse suivante :
 

Advanced Incident Detection and Threat Hunting using Sysmon (and Splunk)

Tom Ueltschi, qui travaille au CERT de la poste Suisse, a ensuite détaillé l’utilisation de Sysmon et Splunk comme outils de détection. Deux types de détection sont importantes sur un environnement : les détections au niveau réseau et les détections basées sur l’hôte. Pour Tom, les meilleurs outils pour effectuer ces détections sont Bro du côté réseau, et Sysmon et Splunk pour les éléments présents sur l’hôte.
L’un des avantages majeurs de Sysmon est qu’il fait partie de la suite SysInternals qui est gratuite et adaptée aux environnements de Microsoft. Son déploiement et son intégration sont alors aisés. Sysmon permet ainsi de récupérer les événements du journal d’événements Windows et, à l’aide de règles adaptées qu’a pu développer Tom (notamment pour limiter le nombre d’événements envoyés à Splunk afin de limiter le coût de licence), remonter des alertes en cas de comportement malveillant.
La difficulté majeure lors de l’installation de ces outils est la création de règles adaptées pour isoler les événements malveillants des événements légitimes. Le poster du SANS dédié à ce sujet (https://www.sans.org/security-resources/posters/dfir/dfir-find-evil-35) peut être un bon point de départ pour parvenir à un résultat cohérent.
Durant sa présentation, Tom a mis l’accent sur trois événements majeurs :
  1. La création de processus
  2. La création de connexions réseaux
  3. L’utilisation de la fonction CreateRemoteThread
Il a ainsi pu présenter différents exemples et conseils permettant une détection efficace.

How Does Dridex hide Friends

Sébastien Larinier et Alexandra Toussaint de Sekoia, ont ensuite présenté les analyses qu’ils ont effectué pour l’un de leur client. Cette analyse, qu’ils ont pu détailler, s’est soldée par la conclusion que le système était infecté par Dridex. En continuant l’analyse, ils ont cependant pu découvrir d’autres éléments suspects, notamment l’installation d’un RAT (malware permettant un accès à distance) sur le système infecté.

A Tete-a-Tete with RSA Bots

Puis, ce fût au tour de Jens Friess et Laura Fuevara de Fraunhofer de présenter une approche automatique pour l’analyse de communications chiffrées. Pour cela, ils utilisent un faux serveurs C&C muni d’un certificat adapté ainsi qu’un serveur DNS pour pouvoir analyser les requêtes et en déduire la clé de déchiffrement.

Le support de présentation est accessible à l’adresse suivante :

Takedown client-server botnets the ISP-way

Après une petite pause, ce fût au tour de Quang Tran de Viettel d’effectuer une présentation sur une méthode de lutte contre les botnets. Travaillant pour un fournisseur d’accès Internet vietnamien, Quang Tran a orienté ses recherches sur le monitoring du trafic dans l’objectif de découvrir les noms de domaine utilisés par les botnets, puis de les remplacer par de faux serveurs C&C envoyant des commandes d’arrêts aux malwares. Une remarque intéressante a cependant été levée lors de la séance de question/réponse, à savoir que cette méthode est illégale dans de nombreux pays.
Le support de présentation est disponible à l’adresse suivante :

Detecting the Behavioral Relationships of Malware Connections

Une autre approche d’automatisation pour la détection des botnets, basée sur le machine learning, a été présentée par Sebastian Garcia, de l’université CTU à Prague. L’idée de Sebastian est que les IoC ne sont souvent pas suffisant pour détecter de nouveaux malwares, ou des versions évoluées de malwares connus. Pour pallier à cela, il utilise les connexions effectuées par un utilisateur pour créer un modèle différentiant une activité suspecte d’une activité normale.
Une représentation sous forme de graphes peut alors être faite et, en fonction du nombre de nœuds, de liens, et surtout du pourcentage de liens répétitifs en fonction du nombre total, il parvient à isoler les comportements suspects.
Exemple de graphe obtenu pour le ransomware Cerber
Le support de présentation est accessible à l’adresse suivante :


Analysis of Free Movies and Series Websites Guided by Users Search Terms

La dernière présentation de cette seconde journée fût effectuée par Martin Clauß et Luis Alberto Benthin Sanguino de Fraunhofer, qui ont détaillés leurs recherches sur l’utilisation des sites proposant le téléchargement et le streaming de films et séries par les attaquants. L’idée de leurs recherches était de collecter les URLs visités lors de la navigation sur ces sites pour déterminer s’ils étaient malveillants. L’étude, qui a été faite sur des sites proposant du contenu en différentes langues, révèle que les sites proposant ce genre de contenu en allemand sont le plus rarement malveillants, alors que les sites espagnols le sont le plus souvent.
Le support de présentation est disponible à l’adresse suivante :

Nymain Origins, Revival and Reversing Tales

Pour entamer la dernière journée de la conférence, Alberto Ortega, travaillant chez Fox-IT, a choisi de partager l’analyse qu’il a pu effectuer sur le malware Nymaim. Il a ainsi pu présenter les nombreuses techniques avancées, notamment d’obfuscation et anti-analyse, utilisées par ce malware découvert en 2013 et qui utilise des attaques de type Man-in-the-Browser pour effectuer des transactions bancaires illégitimes.

Le détail de son analyse est accessible à l’adresse suivante :

Rough Diamonds in Banking Botnets

Travaillant également chez Fox-IT, Jose Miguel Esparza et Frank Ruiz ont continué en présentant leurs recherches sur les interfaces utilisées par les attaquants pour contrôler leurs malwares. Cette présentation étant classée TLP:RED, elle ne sera pas détaillée.

ISFB, Still Live and Kicking

Maciej Kotowicz du CERT polonais prit alors la parole pour présenter son analyse du malware ISFB. Ce malware découvert en 2014 est l’un des chevaux de Troie à visée financière les plus populaires de nos jours. Tout comme les autres malwares présentés, il utilise des techniques avancées qu’a pu présenter Macjej.

Le support de la présentation est accessible à l’adresse suivante :

Challenges for a cross-juridictional botnet takedown

Margarita Louca a ensuite présenté l’un des plus gros défis rencontrés par Europol ces dernières années, et ce avec une approche juridique. Sa présentation est cependant confidentielle.

Preventing File-Based Botnet Persistence and Growth

Kurtis Armour a alors parlé de méthodes efficaces de protection d’un environnement. Les malwares récents utilisant de plus en plus de scripts (JavaScript, Powershell, etc.) en tant que charge malveillante, les détections basées sur les exécutables ne sont plus suffisantes. Kurtis a ainsi présenté différentes méthodes d’implémentation de listes blanches et de configuration permettant de se protéger contre ces nouvelles menaces.

Quelle que soit sa forme, le code malveillant doit être exécuté par le système. L’objectif de Kurtis est donc d’empêcher cette exécution par les charges malveillantes. Une règle d’or pour cela étant de ne pas posséder de droits d’administration sur le système, limitant ainsi les possibilités du malware. Mais différents autres outils peuvent également être utilisés pour réduire la surface d’attaque. C’est par exemple le cas de LAPS de Microsoft qui permet la gestion des comptes administrateurs locaux sur un domaine Windows.

Différentes méthodes permettant de limiter l’utilisation de Powershell ont également été abordées, l’utilisation des Local Security Policies ou Execution Policies n’étant pas la solution. Enfin, AppLocker est un autre outil qui peut permettre de bloquer ce type de comportement, comme par exemple l’utilisation de macros en empêchant l’exécution de dll depuis le dossier VBA.

Le support de présentation est accessible à l’adresse suivante :

Dridex Gone Phishing

Pour terminer cette quatrième édition de la BotConf, Magal Baz et Gal Meiri d’IBM ont détaillé les méthodes de type Man-in-the-Browser utilisées par Dridex pour effectuer sa fraude bancaire. Pour cela, le malware intercepte en effet les appels aux fonctions d’entrée et de sorties du navigateur, afin de dupliquer les données, les envoyant à la fois au site légitime de la banque, mais également au serveur contrôlé par les attaquants. Dridex peut alors modifier les requêtes qui lui sont nécessaires, et en créer de nouvelles pour vider le compte en banque de l’utilisateur. Une manière simple de se protéger semble être de renommer l’exécutable du navigateur (firefox_renamed.exe à la place de firefox.exe par exemple), rendant ainsi inefficace le malware qui se base sur ces noms pour trouver les navigateurs à compromettre.

BotConf 2017

Eric Freysinet a conclu en annonçant la cinquième édition de la BotConf qui aura lieu à Montpellier du 5 au 8 décembre 2017.
Nicolas DAUBRESSE

CERT-W : retour sur l'actualité de la semaine du 19 décembre au 25 décembre 2016


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Google lance le projet Wycheproof, un ensemble de tests de sécurité qui vérifient la présence de failles connues sur les bibliothèques de logiciels cryptographiques
En tout, 80 tests disponibles sur le GitHub ont été mis à disposition des développeurs afin de repérer des faiblesses de chiffrement courantes qui pourraient servir aux pirates à mener leurs attaques. 40 bugs de sécurité dans les bibliothèques existantes ont déjà été découverts et corrigés (ou presque).
Sources :
https://security.googleblog.com/2016/12/project-wycheproof.html
https://github.com/google/wycheproof 

[Brève] Piratage de YAHOO! : des informations de comptes d’utilisateurs vendues sur le marché noir
La base de données ayant fuité contenant les informations de plus d’un milliard de comptes YAHOO!, serait vendue sur le marché noir. Trois personnes se seraient déjà portées acquéreurs de cette base, mise en vente pour $300 000.
Sources :

[Brève] Une Vulnérabilité dans Cisco CloudCenter Orchestrator Docker Engine permettant une élévation de privilège sur le système cible
Sources :

[Brève] Une nouvelle version de Signal intègre une technique permettant de contourner les censures
Signal est considérée comme l’application de messagerie instantanée la plus sécurisée. Sa dernière mise à jour vient d'être développée pour mettre en place des mécanismes appelés "domain fronting" pour contourner les censures et les restrictions appliquées par les gouvernements qui veulent éviter son utilisation. La technique consiste à envoyer des requêtes à un "front domain" et à utiliser l'en-tête HTTP pour déclencher une redirection vers un domaine différent.
Sources :

[Brève] Karpustkiy : le groupe de hackers a piraté le site web de l’ambassade de la chine au Costa Rica
Une base de données de plus de 280 identifiants de connexion a pu être accédée dont 50 publiés comme une preuve de l’attaque : Les enregistrements fuités concerneraient les ID, les courriels et les mots de passe chiffrés. Le site serait en effet, affecté par plusieurs vulnérabilités de type injection SQL.
Source :

[Brève] Un nouvel outil de déchiffrement permettant de récupérer les fichiers chiffrés par la dernière version du ransomware CryptXXX a été rendu public par Kaspersky
Plus de 80 000 internautes seraient touchés par le ransomware. Kaspersky a mis en place un outil permettant de déchiffrer les fichiers chiffrés par CryptXXX v.3. Il conseille aussi aux victimes de ransomwares de ne pas payer la rançon demandée, même s’il n’existe pas encore d’outil de déchiffrement pour la version du malware qui les a attaqués. Il leur suggère d’enregistrer les fichiers endommagés et d’attendre que des outils de déchiffrement appropriés soient disponibles.
Sources :

[Brève] Une vulnérabilité de sécurité permettant de voir les adresses email privées de n’importe quel utilisateur Facebook a été découverte à travers un programme de bug bounty
Sources :

[Brève] Une vulnérabilité dans OpenSSH permettrait une escalade de privilège
Source :

[Brève] Des hackers peuvent contrôler un avion en exploitant une vulnérabilité présente dans un système de divertissement pour avions de ligne
Une vulnérabilité a été découverte dans un système de divertissement pour avion, développé par Panasonic et utilisé par 13 compagnies aériennes majeures. Cette faille pourrait permettre à un attaquant d’infiltrer les systèmes d’avion et même de les contrôler. Il serait ainsi possible d'afficher des informations erronées sur une trajectoire de vol, par exemple, ou dans d'autres cas, de voler des informations personnelles et des données de carte de paiement des voyageurs.
Sources :

[Brève] Après Mirai, le malware Rakos cible les machines Linux et les appareils IoT
Il ciblerait à la fois les périphériques grand public et les serveurs. Les attaquants ciblent les ports SSH ouverts sur divers périphériques linux et utilisent des méthodes de force brute pour compromettre les cibles. Le malware pourrait ensuite recruter des hôtes dans un botnet qui peut être utilisé pour une variété d'activités malveillantes, notamment les campagnes de DDOS à grande échelle.
Sources :

[Brève] Fandroid : le trojan bancaire maintenant doté de fonctions de ransomware
Le malware aurait déjà la capacité de voler les informations d'identification de plus de 2 000 applications financières Android. Des fonctions de chiffrement de fichiers appelées Faketoken ont été rajoutées au cheval de troie.
Source :
http://www.theregister.co.uk/2016/12/20/faketoken_mobile_banking_malware/
Nicolas DAUBRESSE & Binetou LO

EDR, ces outils « Next-Gen » sont-ils utiles contre les menaces actuelles ?


Au vu des différentes attaques qui assaillent le quotidien des entreprise et par rebond des investigateurs et analystes sur incident, l’assertion suivante reflète assez fidèlement le niveau de protection des systèmes d’information :

« La présence d’un antivirus, HIPS, IDS sur le système cible ne présente que peu, voire aucun challenge pour l’attaquant. »

Certes, ces solutions forcent l’attaquant à prendre quelques précautions standards qui relèvent plus du bon sens que de l’ingéniosité :
  • Réserver de nouveaux noms de domaine.
  • Recompiler le programme malveillant.
  • Éviter les scans massifs…
Mais les mécanismes de détection et de prévention actuels n’empêchent aucunement l’attaquant de pénétrer dans le réseau de l’entreprise, encore moins de se propager sur les partages et postes internes des collaborateurs.

Fort de ce constat, plusieurs acteurs mettent en valeur une vague d’outils « innovants » afin de répondre à trois problématiques majeures identifiées par les entreprises :
  • Détecter une attaque avancée.
  • Obtenir plus de visibilité sur le terminal (poste et serveur).
  • Remédier à distance les nuisances d’une attaque.
Avant d’aborder en détail le fonctionnement de ces nouvelles solutions marketing-ment appelées EDR, « Endpoint Detection and Response » ou encore « anti-APT endpoint », prenons le temps de souligner les limites des solutions classiques.

Limites des solutions classiques 

Solutions antivirales 

Les solutions antivirales, positionnées tant au niveau du terminal qu’au niveau des serveurs de messagerie présentent des fonctions de sécurité indispensables et permettent de se protéger contre les menaces et attaques diffuses. Toutefois, force est de constater que ces outils ne sont pas équipés pour détecter, encore moins bloquer, une attaque ciblée qui utilise un malware inconnu voire dans certains cas aucun malware (cf. Hacking team).
Sans forcément naviguer dans le monde obscur de l’obfuscation manuelle du code, il est assez trivial de contourner tous les antivirus du marché via une simple exécution en mémoire. En effet, un antivirus scanne automatiquement tout fichier qui est écrit sur le disque. Dès lors, un malware qui s’exécute uniquement en mémoire via l’une des nombreuses techniques existantes (dropper, injection de processus, injection de DLL, etc.) contourne toutes les protections présentes sur le terminal.

Intrusion Detection System

Les solutions IDS en contrepartie font face à un problème encore plus challenging : l’obsolescence des signatures. La protection qu’offre un IDS est aussi efficace que sa base de signatures. Certes il est possible et recommandé d’implémenter des règles de corrélation comportementales, via un SIEM à titre d’exemple, mais peu d’entreprises prennent le temps d’étudier et mettre en place ces règles soit par manque de temps, de ressource, d’expertise ou à cause des limitations des outils du marché.

Endpoint Detection & Response : une nouvelle approche

De plus en plus d’éditeurs s’intéressent à la problématique du poste de travail afin d’offrir une solution qui puisse détecter intelligemment une attaque mais également mener une investigation à distance et effectuer des actions de remédiation.

Nous aborderons en détail chacune de ces trois fonctionnalités afin d’apporter un éclairage sur la valeur ajoutée de ces outils par rapport aux solutions antivirales classiques, mais également mettre en évidence leurs limitations face à une véritable attaque ciblée.

Acteurs du marché

De manière très macroscopique, il est possible de distinguer quatre constellations importantes d’acteurs dans l’univers des EDR :
  • Des pure-players qui sont dédiés au domaine de l’EDR et focalisent toute leur énergie sur les différents aspects du sujet : SentinelOne, Cylance, Carbon Black, etc.
  • Des acteurs globaux, ces géants de l’informatique et de la sécurité : RSA, Cisco et Palo Alto proposent également des solutions EDR, principalement issus de rachat de pure-players mais qui ont généralement l’avantage de bien s’intégrer avec leurs solutions classiques.
  • Des acteurs spécialisés en investigation numérique (Digital Forensics & Incident Response - DFIR) : certains acteurs tels que Guidance et FireEye se sont fortement inspirés de leurs interventions sur des incidents afin de développer des outils EDR.
  • Enfin, contre toute attente, les éditeurs de solutions antivirales qui agrémentent leur antivirus de quelques fonctionnalités inspirées du monde EDR.

Détection des menaces

L’une des attentes majeures d’un EDR est bien sûr sa capacité de détecter des attaques avancées pour lesquelles aucun IOC (indicateur de compromission) n’est disponible. Nous nous limiterons donc aux solutions proposant un moteur de détection intelligent et autonome.
Quatre techniques de détection sont généralement employées par les acteurs du marché.

Détection de l’exploitation d’une vulnérabilité

Cette approche typiquement adoptée par des acteurs tels que FireEye, Confer (racheté par Carbon Black) ou encore Palo Alto profite d’un constat assez simple.
Qu’elle soit connue ou non (zéro-day) une vulnérabilité est exploitée via des techniques classiques, répertoriées et surtout dénombrables : dépassement de tampon, retour à des instructions, injection DLL, préparation du tas, etc.
Ces solutions ciblent donc la manifestation de ces techniques dans la mémoire des processus lancés sur le système et lèvent une alerte le cas échéant.
Ceci dit, afin d’avoir un niveau de visibilité satisfaisant sur le système, il est nécessaire de détourner une partie non négligeable des appels systèmes effectués par le système d’exploitation, intervenir dans le maniement des objets par le noyau, etc. Autant d’opérations qui peuvent facilement causer des dénis de service voire endommager le système.
Aussi l’approche généralement suivie est de ne surveiller que les processus souvent exploités par les attaquants i.e : une zéro-day sur flash aurait en revanche de grandes chances d’être détectée par ces outils. Une zéro-day sur le process smb.exe qui gère le partage de fichiers aurait beaucoup de chance de passer inaperçue.

Détection d’un comportement malveillant

Contrairement à la détection de l’exploitation d’une vulnérabilité, qui intervient dans les phases amont d’une attaque, la détection d’un comportement malveillant suppose que l’attaquant a pris, ou est en train de prendre, la main sur le poste.
Certains outils tels que Carbon Black, RSA ou encore SentinelOne préfèrent ainsi se concentrer sur des enchainements d’actions qui sont caractéristiques d’une attaque. À titre d’exemple, un éditeur de texte (notepad) qui exécute un processus cmd.exe et ouvre une connexion sur le port 443 d’un serveur hébergé dans un autre continent, est synonyme d’une action pour le moins suspecte et sera (dans l’idéal) remontée comme telle par ces outils.
L’inconvénient majeur de ce mode de détection est bien entendu le nombre de faux positifs que cela peut générer. Un exemple assez parlant se présente sous la forme des documents Office, qui pour peu qu’ils embarquent une macro un tant soit peu complexe, sont instantanément détectés par certaines de ces solutions comme des malwares. L’une des principales raisons est l’écriture massive dans les répertoires temporaires de l’utilisateur %APPDATA% ou %TEMP% d’icônes, d’images, etc. comportement assez similaire à celui d’un malware.

Détection via sandbox

Certains éditeurs, principalement les acteurs de solutions antivirales, proposent une mise à jour de leur agent afin d’inclure des « capacités EDR ». Ceci est certes séduisant d’un point de vue déploiement et exploitation, mais bien souvent la mise à jour de l’agent n’ajoute qu’une étape de validation externe dans le processus de détection : si un fichier présent sur le disque ne correspond à aucune signature mais est tout de même considéré comme suspect, via une analyse statique du dit-fichier, ce dernier est envoyé à une sandbox qui l’exécute dans un environnement virtuel afin de statuer sur son état.
Outre le temps de détection inhérent à l’envoi et l’analyse du fichier sur un serveur distant ainsi que les potentiels problématiques de déploiement dans le cloud d’une telle sandbox, la détection se base toujours sur l’inspection des fichiers présents sur le disque uniquement et n’inspecte pas les processus qui tournent en mémoire sur l’endpoint.
Par ailleurs, le fait d’avoir un écart entre l’environnement d’exécution du malware (machine virtuelle - sandbox) et l’environnement de dépôt du fichier (terminal) introduit un biais qui peut se révéler fatal. En effet, plusieurs malwares se servent de cet écart afin de conditionner l’exécution de la charge utile malveillante et ainsi tromper les systèmes de sandboxing.

Détection via apprentissage

Contrairement aux outils de détection réseau, très peu d’acteurs EDR se sont aventurés dans le domaine de la détection des menaces via l’apprentissage du comportement de l’utilisateur.
Les techniques de détection présentées précédemment identifient bien des écarts, mais ces écarts sont renseignés sous forme de « liste noire » de comportements connus pour être malveillants. Là est la nuance qui ne va pas sans rappeler les principes des signatures, quoique sous une forme plus raffinée.
C’est ainsi que des acteurs tels que Triumfant suivent une approche assez intéressante : ils construisent un modèle mathématique qui décrit l’état nominal de l’activité d’un utilisateur sur un poste de travail. Toute variation par rapport à cet état : utilisation du privilège se_debug pour la première fois, présence de cinq comptes actifs sur le poste au lieu d’un seul, etc. remonte une alerte sécurité, qui sera validée ou non par l’opérateur.
Des acteurs comme Guidance s’inspirent de cette démarche mais modélisent plutôt le comportement de l’ensemble du parc informatique, ce qui permet effectivement de détecter un malware qui se propage sur le SI, mais pourrait faire défaut lors d’une attaque ciblée qui n’impacte que quelques postes.

Synthèse

Ces mécanismes de détection sont bien sûr très complémentaires et certains éditeurs n’hésitent pas à s’inspirer de plusieurs approches pour construire leur moteur de détection, toutefois ceci ne couvre pas l’intégralité des menaces. De ce fait, presque toutes les solutions incorporent un flux d’intelligence communiqué par les laboratoires de recherche des éditeurs, des clients, etc.
Ces flux d’intelligence reposent sur les traditionnels indicateurs de compromission (IOC), qui reprennent finalement les avantages, et surtout limitations, de la détection via signatures depuis longtemps proposée par les antivirus…

Capacités d’investigation

L’un des besoins majeurs mis en avant par les entreprises est la possibilité d’obtenir l’état de du terminal et de collecter des informations techniques à un instant t. Ceci se traduit par exemple par la récupération sur demande des artefacts suivants :
  • Les processus et services actuellement présents sur l’endpoint.
  • La liste des fichiers présents dans le répertoire %AppData%.
  • Une copie de la mémoire vive.
Ce qui autrefois nécessitait un script powershell développé à la main peut maintenant s’effectuer presque instantanément depuis une console centralisée et ainsi offrir une vision exhaustive de l’état du parc informatique.
Outre le gain indéniable en efficacité, la fiabilité des résultats en est également améliorée. En effet, les fonctions de recherches à distance présentes nativement sur Windows sont limitées à l’espace utilisateur (ring 4) et ne peuvent pas détecter les processus/fichiers/clés de registres cachés par des malwares avancés (ring 0).
Ceci représente en effet l’atout majeur d’un agent installé sur le poste, pourvu qu’il soit installé au niveau du noyau et implémente des fonctions bas niveau.
Beaucoup d’éditeurs vont un cran plus loin en exposant des API permettant d’automatiser ces actions redondantes de recherche.
Le format des IOC supportés varie d’un éditeur à un autre selon les choix stratégiques effectués : YARA pour Guidance qui a un background investigation, OpenIOC pour CarbonBlack et FireEye, alors que RSA supporte de nombreux formats. Néanmoins presque tous les éditeurs convergent petit à petit vers le support de l’ensemble des formats.
Aussi, afin d’approfondir certaines analyses suite à une alerte, les éditeurs n’hésitent pas à s’interfacer avec des outils de sandbox tiers, ou propres à l’éditeur afin de mener des analyses plus avancées, c’est le cas de Cisco, Hexis, et tant d’autres.

Options de remédiation

Le troisième aspect naturellement traité par les EDR est bien sûr la remédiation à distance des terminaux. Avant de traiter ce sujet néanmoins, il est intéressant de considérer la réelle valeur ajoutée d’une telle fonctionnalité. En effet, supprimer un fichier, DLL, processus à distance ne garantit aucunement l’éradication du malware. Certains malwares tels que Greyfish s’attaquent par exemple au BIOS et peuvent persister après le formatage du disque.
Toutefois, les incidents quotidiens n’impliquent pas systématiquement un malware aussi complexe que Greyfish et la possibilité de supprimer une clé de registre de persistance classique pourrait bien faciliter la vie de nombre d’analystes.
Du fait de cette problématique, d’un côté des éditeurs comme FireEye proposent uniquement d’isoler le poste infecté ce qui garantit un certain confinement de la menace, d’un autre côté des éditeurs comme Carbon Black ou Guidance proposent d’agir au niveau du système afin d’effectuer des opérations avancées au niveau du noyau et tenter de remédier le poste.
Enfin, d’autres acteurs comme Cisco ou RSA permettent de supprimer à distance quelques artefacts mais cela ne traite que superficiellement l’infection.
Un acteur peu connu en France, Triumfant permet lui d’effectuer des opérations chirurgicales au niveau de la mémoire afin de corriger les altérations du malware (tables IDT, SSDT, etc.) et traiter ainsi des malwares assez complexes.

Attention par contre, si la console de l’outil EDR tombe dans de mauvaises mains, elle peut devenir une arme de destruction assez massive.

Conclusion

Les solutions classiques antivirales, IDS, etc. présentent certes des protections faillibles mais il est illusoire de penser que les « nouvelles » solutions du marché fournissent des résultats parfaits et infaillibles, surtout sur l’aspect détection.
Un antivirus reste de mise, en particulier pour se protéger des malwares basiques et ne pourra être remplacé par un EDR.
Au final, la valeur ajoutée d’un tel outil se situerait plus au niveau des options de collecte d’artefacts, de recherche d’IOC voire de remédiation à distance qui faciliteront grandement les opérations des équipes de réponse à incident en cas d’attaque d’ampleur.
Ces outils devront cependant être particulièrement sécurisés pour ne pas être eux-mêmes des vecteurs facilitateurs de l’attaque.
Ayoub ELAASSAL

SIRP, la panacée de la réponse à incident ?

    Le SIRP, une plateforme dédiée à la gestion des incidents de sécurité

    Comme son nom l’indique, un SIRP est une plateforme d’aide à la réponse à incident. Contrairement à un SIEM, dont l’objectif principal est de corréler les logs pour en extraire des alertes de sécurité, le SIRP participe à la gestion des alertes émises. En cela il se rapproche plus d’un outil de gestion de ticket (type ITSM) largement utilisé par les équipes d’exploitation SI au quotidien.

    Il est néanmoins dédié à la gestion des alertes et incident de sécurité grâce à des fonctionnalités spécifiques (avec des workflows de traitement spécifiques, la gestion des IOC et de la threat intelligence, l’interfaçage avec le SIEM et les autres outils de sécurité, etc.). L’objectif du SIRP est d’aider les analystes ainsi que leurs managers dans leur travail quotidien et plus globalement d’améliorer l’efficacité des activités de réponse à incident.

    Positionnement du SIRP dans l’environnement de détection

    Le SIRP, en tant que plateforme de réponse à incident peut se positionner dans le « prolongement du SIEM », notamment pour faciliter l’analyse, les notifications et l’organisation de la réaction.

    Principales fonctionnalités : collaboration, standardisation et automatisation 

    La plateforme de SIRP, en tant que point central pour la gestion des incidents de sécurité, offre des fonctionnalités propres à ses utilisateurs (analystes, responsable de SOC, RSSI, etc.). En cela, elle dépasse, fonctionnellement et en termes de sécurité, les plateformes ITSM utilisées usuellement. En particulier une plateforme de SIRP complète et mature doit être en mesure d’apporter les gains suivants :
    • Une collaboration accrue, via :
      • Des workflows ou playbooks (processus de gestion des incidents, assimilables à des arbres de décisions/ traitement) par défaut (i.e. fournies avec la solution) et facilement et hautement personnalisables. Par exemple, un workflow de traitement d’un malware détecté sur un poste de travail, avec une branche dédiée à la gestion d’un ransomware.
      • Un interfaçage avec l’ITSM corporate (ou les ITSM dans le cas d’un SI / une organisation très éclatée) afin de pouvoir communiquer de manière transparente (et ce sans changer les habitudes, sur la base des outils existants) avec les autres équipes IT (ex. équipes réseau, poste de travail, helpdesk, etc.).
    • Une efficacité améliorée dans le traitement des incidents, via :
      • La centralisation et l’accessibilité offerte par la plateforme à tous les analystes avec des rôles bien définis (N1, N2, N3, responsable MSSP, responsable SOC, RSSI BU, etc.), permettant notamment de gérer les priorités (automatiquement ou par assignation des incidents) ainsi que la continuité du traitement via la gestion des rotations d’équipes (dans le cadre d’un service en 24/7 par exemple).
      • L’automatisation des actions d’analyse et de levée de doute réalisées habituellement manuellement par les analystes via l’interfaçage du SIRP avec certaines solutions existantes : puit(s) de logs, IDS, proxys, antivirus, et solution(s) de threat intelligence. Ces intégrations permettent au SIRP d’aller récupérer des informations complémentaires relatives à l’incident pour l’enrichir.Par exemple, pour une alerte créée dans le SIRP via le SIEM et originalement générée par plusieurs alertes IDS, le SIRP pourrait automatiquement (ou sur simple demande de l’analyste) aller chercher dans :
        • Pour la recherche de traces / de marqueurs :
          • Les logs (du proxy Web) s’il retrouve trace de la requête et de la réponse.
          • La CMDB ou référentiels LDAP/AD pour récupérer des informations relatives aux machines concernées par l’alerte (nom, type, département, OS, dernier utilisateur connecté, etc.).
          • L’antivirus poste de travail : les alertes et version de l’antivirus.
          • La sandbox mail/réseau : les derniers éléments de menaces potentielles identifiées mais laissées passer.
        • Pour la contextualisation de la menace :
          • Recherche d’informations relatives au cas en cours (marqueurs, menaces, cibles, etc.) dans sa propre base regroupant les incidents passés (notion de capitalisation).
          • Une base de threat intelligence interne (ex. instance MISP) ou externe via soumissions de marqueurs à des plateformes externes / SaaS (par exemple à Virus Total, IBM Xforce, FireEye, Trend Micro, Palo Alto, etc.).
        • Pour la qualification :
        • A des applications externes (ex. envoi de hash ou URL vers Virus Total).
        • A des solutions internes, par exemple envoi des fichiers suspects (remontés depuis une alerte antivirus ou IDS) vers une sandbox pour analyse dynamique (via exécution dans un environnement contrôlé).
        • Vers les différentes solutions antivirus en place (antivirus sur les passerelles email, antivirus endpoints, etc.) permettant de vérifier de manière centralisée et industrielle si la menace est connue par les solutions de confinement en place.
      • L’industrialisation / l’automatisation de la réponse. Bien que source de polémiques, l’automatisation de la réponse sur incident (notamment des actions de mitigation) est un sujet de discussion chez nombre d’entreprises. Certaines plateformes SIRP permettent, via des mécanismes similaires (interfaçage avec des solutions tierces en place) d’industrialiser les actions de confinement / mitigation. Par exemple en proposant à l’analyste un bouton « bloquer l’URL et l’IP désignée sur les proxys Web » ou encore « générer une signature pour le fichier désigné sur l'ensemble des antivirus ».
      • Une industrialisation du traitement et des décisions portées par les workflows et un wiki intégré et géré par les analystes. Par exemple, une fiche réflexe pour la mitigation d’un ransomware ou d’un DDOS, une liste des contacts pour escalade dans telle business unit ou filiale, un exemple de rapport d’incident, une liste globale des lessons learned (plans d’actions d’amélioration identifiés post incident), etc.
    Évidemment, l’interfaçage avec les solutions tierces n’est pas « naturel », le SIRP propose en général des API et supporte certaines solutions partenaires de l’éditeur, reste ensuite à s’assurer des capacités des solutions tierces avec lesquelles s’interfacer, soit au niveau de l’application via une API, à défaut au niveau de la base de données.

    Des atouts transverses, tels que :

    • Des capacités de reporting avancées : les SIRP proposent des métriques propres à la gestion des menaces et incidents de sécurité (ex. répartition par type d’incidents, par impacts, respect des SLA, etc.) ainsi qu’un « reporting role based » (les indicateurs et rapports pour l’analyste N1 sont différents de celui du responsable de SOC ou encore du RSSI d’une business unit).
    • L’aide au respect des contraintes règlementaires via une confidentialité et une traçabilité accrue des informations et actions relatives aux incidents de sécurité. En effet, le SIRP, en tant solution dédiée et pensée secure by design, intègre son propre contrôle d’accès et moyens de chiffrement et est maitre des interfaces avec les solutions tierces (par exemple dans le cadre d’un interfaçage avec l’ITSM corporate seules les informations strictement nécessaires à l’opérateur de la tâche sont transmises à l’ITSM). Certaines solutions permettent d’avoir une traçabilité ainsi qu’un historique de tous les champs d’un incident (par exemple la criticité de l’incident créée à « haute », descendue à « moyenne » le 29/07/2016 par l’ « analyse N2 Jean Dupont »).
    • La gestion (prise en compte, suivi, capitalisation) des « demandes de sécurité » (par exemple la campagne de recherche de marqueur sur demande de l’ANSSI).
    • L’aide à l’organisation de war room, gestion de crise, etc.

    Le SIRP supporte l'ensemble du processus de réponse à incident

    Finalement, le SIRP, grâce à ses fonctionnalités intrinsèques et lorsqu’il est interfacé avec les solutions clés, apporte un gain sur les différentes phases de la réponse à incident.

    Intégration dans l'existant technologique et organisationnel 

    Le SIRP, en tant que brique centrale de la réponse à incident est à la croisée des chemins, entre les :
    • Informations techniques : évènements / logs, alertes, incidents, rapports, etc.
    • Les solutions de gestion du système d’information (CMDB, ITSM, etc.) et de sécurité (puit de logs, SIEM, IDS, antivirus, proxy, etc.).
    • Les équipes de sécurité et de production IT.
    Le schéma ci-dessous offre une vue des échanges fonctionnels entre le SIRP est les éléments suscités :

    S'équiper d'un SIRP

    Même si cet outillage peut paraître très séduisant vu ses capacités, de nombreuses questions se posent avant de se lancer sur un projet d’acquisition.

    Prioriser ses besoins pour définir une première cible 

    Avant de se lancer dans le choix et le déploiement de son outil de SIRP, il s’agit, pour en tirer un maximum parti, d’évaluer son organisation et son niveau de maturité sur les aspects de la détection et réponse à incident pour ensuite définir la cible attendue et enfin estimer l’écart (gap analysis) et notamment les points que le SIRP pourra et devra supporter.

    Voici quelques questions à se poser :
    • Sur l’existant : quelle est ma maturité sur la détection et la réponse à incident ? Comment sont répartis mes actifs ? Quelles sont les équipes qui les exploitent et gèrent les incidents ? Quels sont les processus existants ou manquants (traitement, escalade, communication, etc.) ? Quelles sont les solutions préventives et de détections principales ? Même si l’outillage pourra aider, il ne remplacera pas une organisation non fonctionnelle ou encore qui manque complètement de compétences.
    • Quelles sont les contraintes règlementaires qui s’imposent à tout ou partie des métiers et du SI (LPM, PDIS, BALE, etc.) ? Le SIRP peut-il jouer un rôle dans cette mise en conformité ? 
    • Finalement, quels sont les gains attendus ? Par exemple, s’agit-il principalement de renforcer la communication entre plusieurs périmètres / équipes de supervision et gestion des incidents ? S’agit-il d’améliorer la traçabilité et la capitalisation d’informations ? S’agit-il aussi de standardiser et d’automatiser au maximum les actions d’analyse et/ou de réaction ? 
    Un travail collaboratif est vivement encouragé afin de s’assurer que chacun puisse y trouver son compte pour choisir l’outil le mieux adapté aux besoins et en maximiser son adoption et donc sa valeur.

    Choisir la solution adaptée à son contexte 

    La phase d’identification des besoins prend réellement toute son importance dans le processus de choix d’une solution SIRP. En effet, il existe une forte variété de solutions pouvant répondre à tout ou partie des attentes.

    Ces solutions peuvent être classées suivant deux grands critères :
    • La solution est-elle open source (issue d’un projet, gratuite et modifiable à souhait mais potentiellement sans support professionnel) ou au contraire commerciale (packagée et prête à l’emploi avec un support technique mais en contrepartie payante) ? 
    • La solution a-t-elle été créée dans l’objectif de gérer les incidents de sécurité IT ou au contraire est-elle issue du monde de la production IT et en ce sens une extension d’un outil de ticketing / ITSM ?
    À noter par exemple :
    1. Côté open source : la plateforme FIR (Fast Incident Response) créée et maintenue par le CERT-SG et la toute récente plateforme TheHive du CERT-BDF.
    2. Côté ITSM : ServiceNow, leader de l’ITSM en SaaS qui a récemment ajouté une offre « Security Operation Management » supportée par 3 applications ServiceNow : « Security Incident Response », « Vulnerability Management » et « Threat Intelligence ».
    3. Côté des pure players SOAR / SIRP :
    • Resilient (acquis par IBM en mai 2016) qui propose sa solution éponyme dédiée. Resilient est certainement l’acteur historique sur le marché des SIRP.
    • RSA (division sécurité d’EMC, en cours de rachat par Dell) propose la solution « SecOps » intégrée à son offre « Advanced SOC ».
    • DFLabs, société italienne, dont la solution « IncMan » est le produit phare.

    Typiquement, si vous êtes un CERT/CSIRT ou une seule équipe de réponse à incident à « forte expertise », un outil développé par un autre CERT/CSIRT (ex. FIR du CERT-SG ou TheHive du CERT-BDF), personnalisé et exploité par vos soins constitue certainement le meilleur choix.

    A contrario si votre société utilise une solution ITSM largement déployée et que celle-ci offre un module de gestion des incidents de sécurité, peut-être faut-il porter un soin particulier à l’idée de capitaliser sur l’ITSM en évaluant soigneusement les fonctionnalités spécifiques aux incidents de sécurité.

    Si vous avez un haut niveau de maturité, que vous recherchez définitivement des fonctionnalités avancées pour la réponse à incident et qui soient supportées par défaut (par exemple un plugin multi-SIEM, la multi-threat intelligence, etc.), peut-être est-il judicieux d’examiner les quelques pure-player du marché ; ceux-ci étant largement tirés par les États-Unis et ses MSSP (Managed Security Service Provider).

    Conclusion

    Un SIRP n’est bien sûr pas indispensable nous pouvons faire de la réponse à incident sans SIRP. Mais pour certains organismes, notamment les grandes entreprises réparties sur plusieurs plaques géographiques et/ou plusieurs sites, cela peut être intéressant.
    Un SIRP permet de gagner en efficacité sur le traitement des incidents (délais, qualité de la réponse, valorisation des actions, etc.), offre un reporting de la réponse à incident et assure une coordination entre les différentes équipes.

    Mais comme toute nouvelle solution sur un système d’information, c’est par un accompagnement des différentes parties prenantes au changement que pourra passer sa bonne intégration.
    Mathieu HARTHEISER