Comment expliquer en 2020 l’échec des SOCs ?
Les Security Operations Center (SOC) sont confrontés à leurs limites. En effet, les cyber-attaques sont de plus en plus fréquentes, virulentes et coûteuse. Il suffit de feuilleter l’actualité des attaques cyber pour devoir l’admettre. Le nombre d’attaques explose. Et elles aboutissent avec un succès destructeur, y compris dans des environnements disposant de services de surveillance de type SOCs.
Face à ces attaques destructives, les SOCs, promesse de rapidité de détection et de réaction devraient être les garants de la survie des entreprises. Mais alors, comment s’explique l’échec des SOCs ?
Quelle est la mission d’un SOC ?
Un SOC est une organisation en charge de la surveillance et la détection des attaques informatiques. Sa mission de sécurité globale. Essentiellement, le SOC surveille les environnements informatiques, identifie des scénarios d’attaques et de rechercher ou toute compromission.
Pour réaliser sa mission, le SOC s’appuie sur un socle technologique (souvent un SIEM). Le socle technologique se charge de collecter, corréler, analyser et alerter sur des événements suspects survenus sur un terminal. Il peut s’agir d’un serveur, un routeur ou au cœur d’une DMZ, d’un sous-réseau, etc.
Le SOC est une organisation. Bien qu’une partie des analyses soit automatisée, il repose sur une équipe d’analystes chargés de superviser les outils, de qualifier les événements et d’engager une réaction en cas d’attaque avérée. La réaction peut couvrir un spectre large d’actions : configuration ou blocage technique, investigation sur incident, déclenchement de dispositif de crise, cloisonnement réseau.
On l’aura compris, l’efficacité d’un SOC repose sur une détection tendant le plus possible vers le temps réel. Cela exige une actualisation permanente des scénarios de surveillance, une connaissance « instantanée » des nouveaux paterns d’attaques et des IOCs (la Threat Intel), une surveillance H24 sur la totalité de la surface du SI (interne, interconnexions, infrastructure réseau, déploiements en mode Saas, etc.) et des analystes aguerris prêts à dégainer à tout moment.
Si un de ces rouages grince, c’est la totalité de la chaine de détection et réaction impacte l’efficacité globale qui chute.
Quels sont les constats ?
Afin de comprendre l’échec des SOCs, nous avons réalisé plusieurs actions de stress test de SOCs. L’objectif étant d’en mesurer l’efficacité réelle en situation réelle.
Ces stress tests consistent à exécuter depuis des boitiers autonomes connectés au réseau cible, des flux malveillants (non destructifs évidemment…), afin de tester les capacités des SOCs à les détecter et à enclencher les réactions appropriées. Les événements générés ne sont pas furtifs et sont manifestement malveillants (sans jamais rien casser) et doivent donc faire l’objet d’une détection.
Nous partageons ici, quelques résultats éloquents des tests joués durant le premier semestre et mis à jour avec nos données du second trimestre 2020.
Les dispositifs de sécurité existants ont détecté 38% des événements générés et environ 15% ont fait l’objet d’une alerte vers l’équipe RSSI. Les écarts sont très variables selon l’environnement et le niveau de maturité (c’est sans surprise)
Plusieurs facteurs permanents freinent l’efficacité de la sécurité opérationnelle
Le volume de faux positifs dilue les informations de qualité ; le paramétrage des dispositifs de sécurité et les process de qualification des événements ne sont pas optimisés.
Parmi ces événements, plusieurs explorations agressives de réseaux locaux ont été effectuées et répétées. En moyenne 80% ont été détectées et 5% ont fait l’objet d’une alerte vers l’équipe RSSI. Moins de 1% lorsque les événements sont générés en heure non ouvrée.
Les scans réseaux sont perçus comme des événements à gravité faible ou comme complexes à qualifier car éphémères ou simplement légitimes. Durant le confinement, avec la majorité des collaborateurs intervenant à distance, bien que les équipements de sécurité aient détectés ces événements comme malveillants, très peu d’alertes sont remontées vers le management. Plusieurs organisations ont donné pour instruction de focaliser les investigations et analyses sur des incidents avec une suspicion de gravité élevée, au détriment des événement plus « soft » ou plus classiques comme les scans de réseaux.
Environ 65% des tentatives d’exploitation de vulnérabilités connues, ont abouti (valeur constante). Les dispositifs de sécurité ont détecté 62% et une moyenne de 15% ont fait l’objet d’une alerte vers l’équipe RSSI.
Les événements simulant des exploitations ou tentatives d’exploitation de vulnérabilités, sont conçus pour déployer des marqueurs caractéristiques d’actions malveillantes. En condition « normale » de surveillance, ces évènements font l’objet d’une alerte de sécurité. Cependant, durant cette période nous constatons que peu de ces événements font l’objet d’une remontée d’alerte.
100% des exfiltrations de données ont réussi. Les dispositifs ont détecté 6% et 0% ont fait l’objet d’une alerte.
La détection d’une exfiltration de données est variable d’une organisation à l’autre. En général, le signalement est rapide lors de la détection d’une fuite.
Durant le confinement, aucune des exfiltrations de données, détectée par les dispositifs de filtrage n’a fait l’objet d’un signalement.
En bref.
Concernant les SOCs visés par ces tests, leur efficacité réelle est donc toute relative.
Plusieurs limites qui peuvent expliquer l’échec des SOCs sont une évidence, et certains points ressortent de manière récurrente :
– Les périmètres de surveillance sont loin d’être exhaustifs. Les réseaux informatiques bougent beaucoup et vite, de nouveaux environnements s’intègrent, des matériels décommissionnent, etc. Cette réalité complexifie considérablement la capacité des SOCs à conserver une vue exhaustive du réseau ;
– Le paramétrage des outils de sécurité n’est pas toujours pertinent dans ses seuils d’alerte ou la catégorisation des événements ;
– Le fléau des faux positifs : c’est un phénomène bien connu des analystes. Trop souvent, masse de signalements sans intérêt ou erronés noient les alertes pertinentes. Cela a un impact direct sur l’efficacité et la mobilisation des analystes ;
– Le manque de vigilance des analystes et une forme de fatigue des analystes entretenue par les points précédents.
La période confinement et la bascule généralisée en télétravail a également eu un impact sur les activités des SOCs. Ce qui s’explique du fait d’un transfert accéléré de certains services vers le Cloud. Par conception, ces environnements applicatifs ne s’intègrent dans le périmètre de surveillance des SOCs du fait du difficile (et non fluide) accès aux logs techniques.
Inefficaces, donc inutiles ?
Il faut rester raisonnable : inefficace ne signifie pas inutile. Malgré l’échec des SOCs, ceux-ci restent indispensables à la mise en œuvre d’une politique de sécurité opérationnelle. Ils sont le bras armé de la filière cyber et à ce titre, ils marquent la ligne de front avec la réalité des menaces Cyber.
Et cette menace cyber est complexe, mouvante, imaginative, … En un mot moderne elle est « agile » et peut être plus que les défenseurs.
Pour faire face à cette réalité, il faut repenser les modes d’action des SOCs, et notamment mettre en œuvre des dispositifs d’entrainements et de tests permanents.
On ne doit plus parler de MCO (Maintien en Condition Opérationnelle) mais de MCC (Maintien en Condition de Combat) avec des actions de simulation permanentes, pour mesurer le niveau d’efficacité réelle de la SecOps.