Quels sont les indicateurs et données pertinentes au service du SOC ? (Par Julien Steunou, Provadys)

Sous la pression de la recherche de la détection de toutes les formes d’attaques et de tous les signaux faibles possibles, un SOC se retrouve régulièrement confronté au risque de noyer son dispositif de détection sous un déluge de données dépassant de loin les capacités de traitement efficace des outils et des analystes. Pour préserver une réelle efficacité de détection et éviter l’érosion rapide des équipes d’analystes, il est essentiel dans la gouvernance du SOC de travailler sur deux axes :

1/ La sélection des données pertinentes

Le SOC doit traiter uniquement les sources et les types d’événements significatifs au regard des événements redoutés qui sont inscrit dans la stratégie de détection.

Modéliser ces événements redoutés via des outils méthodologiques comme les « kill chain » permet d’identifier à chaque étape d’une attaque les informations qui peuvent contribuer à sa détection et les dispositifs capables de générer ou capter ces données.

Pour autant, il est important et utile de conserver un maximum d’événements à des fins d’investigation. Dans beaucoup d’organisations, le SOC est à l’initiative des projets de gestion de logs et doit porter cette fonction. Il est cependant beaucoup plus efficient de mettre en place un projet transverse de gestion de logs, assurant la collecte, l’indexation et le stockage des logs dans un datalake dans lequel le SOC viendra avec d’autres services consommer de la donnée.

Les solutions d’analyse comportementale vont probablement à terme impacter la stratégie de sélection des données pertinentes car leur efficacité ne répond pas aux mêmes règles que les outils traditionnels type SIEM qui reposent sur la corrélation d’événements.

2/ L’enrichissement des données permettant l’aide à la décision

La performance du service de détection du SOC dépend d’une succession de décisions prises d’abord par une stack technique puis par des analystes. L’enrichissement automatisé des données via des sources externes (threat intelligence) et internes (historique d’incident, CMDB) est un levier très efficace d’amélioration de la qualité et de la rapidité de décision, en particulier celle des équipes d’analystes. Sur un exemple simple d’alerte de type « suspicion de malware » dans une pièce jointe d’un mail, beaucoup de SOC ont un processus de traitement manuel reposant sur le dépilage d’une boîte mail par des analystes et un traitement manuel de la pièce jointe à travers différents outils.

Les évolutions des outils d’orchestration du SOC permettent aujourd’hui d’automatiser et d’enrichir l’alerte, et de présenter à l’analyste une alerte dans laquelle :

– La pièce jointe à investiguer aura été récupérée, passée dans les outils d’analyse interne (moteur antimalware, sandbox…), les hash auront été calculés et requêtés sur des plateformes comme Virus Total, et l’ensemble des résultats sera affiché.

– Des liens auront été faits avec des incidents similaires dans la base d’incidents ;

– Les marqueurs techniques disponibles dans le mail et par analyse de la pièce jointe auront été comparés aux bases de threat intelligence et aux données présentes sur le datalake ;

– Les IP auront été géolocalisées, avec leurs scores de réputation ;

– Les liens auront été faits avec l’annuaire et la CMDB pour récupérer les informations essentielles sur le destinataire et sur son poste de travail ;

Beaucoup de SOC présentent des tableaux de bord simplistes, contenant les volumes d’incidents détectés chaque mois par ses propres moyens et une ventilation par catégorie d’incidents. Ce qui n’est clairement pas suffisant. La gouvernance du SOC doit non seulement fixer les objectifs en termes de détection d’événements redoutés mais également mettre en place un cadre d’évaluation des performances adapté.

Les indicateurs pertinents peuvent être du type :

– La ventilation des incidents de sécurité par canaux de détection, en couvrant l’ensemble des incidents de sécurité identifiés sur la période considérée. Cette information, avec l’identification claire des incidents détectés par les propres moyens du SOC, doit être délivrée et analysée par le SOC, en assumant complètement qu’il ne peut pas détecter 100% des attaques.

– Le positionnement de la détection dans la « kill chain », ce qui permet de mesurer la proportion d’incidents détectés pendant les phases de livraison, d’installation, d’établissement des canaux de command&control, de mouvement latéral, … Cette information permet d’aller plus loin que la volumétrie d’incidents, et fournit une appréciation de la fenêtre d’attaque des adversaires.

– L’évaluation des dates auxquelles surviennent les incidents, ce qui permet aux équipes d’identifier quand cela est possible la date de compromission initiale, et d’en déduire le délai de détection.

– L’attribution à groupe d’adversaire ou à minima à des types de motivations. Cette attribution est particulièrement difficile à réaliser mais constitue un réel marqueur de montée en maturité et un indicateur de la qualité du renseignement tactique.

– Le pourcentage d’incident dont le traitement a suivi un playbook identifié, qui permet de mesurer la qualité de la préparation et l’efficacité des analyses post mortem.

Il est évident qu’alimenter ces indicateurs est souvent difficile, voire impossible pour certains d’entre eux en deçà d’un seuil de maturité. Cependant, les mettre en place permet de remettre en cause le SOC et de prouver son efficacité au management, alors même que certains incidents continuent de se produire sans qu’ils ne soient détectés par le SOC. Le SOC s’inscrit à travers ces indicateurs dans une stratégie globale de cyber défense où l’incidentologie est prise en compte pour améliorer les mesures de sécurité, les capacités de détection d’une nouvelle occurrence, et la mise en place des stratégies de réponse aptes à réduire les impacts.