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 :
- Côté open source [3] : la plateforme FIR (Fast Incident Response) créée et maintenue par le CERT de la Société Générale.
- Côté ITSM [2] : 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 ».
- Côté des pure players SOAR / SIRP [4] :
• 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), 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.