Face à des menaces de plus en plus insistantes et évoluées, le SOC (Security Operations Center) se doit d’être capable de détecter les incidents de sécurité au plus vite pour réagir toujours plus efficacement.
Cependant, de nouvelles réglementations le soumettent à des contraintes de plus en plus fortes telles que le GDPR (General Data Protection Regulation) visant toutes les données à caractère personnel, ou les différentes lois sur la protection des infrastructures critiques des pays. La France est particulièrement en avance aujourd’hui avec la LPM (Loi de Programmation Militaire [lien EN / lien FR ]) qui s’applique aux organisations les plus critiques pour le fonctionnement de l’Etat.
Comment mettre en place un système de détection de plus en plus fin, tout en s’inscrivant dans un cadre réglementaire toujours plus strict ?
Une standardisation des SOC à l’échelle européenne (et mondiale)
Au milieu des années 2000, la mise en place des premiers SOC consistait, dans la plupart des cas, à déployer un collecteur de logs par plaque géographique et à mettre en place une gestion des alertes en central. Cependant, des évolutions réglementaires récentes peuvent imposer des changements d’architecture. En particulier en France dans le cadre de la LPM, l’obligation de mise en place d’un « système de corrélation et d’analyses de journaux » (autrement dit : SOC outillé par un SIEM) s’est accompagnée d’une structuration règlementaire stricte décrite dans le référentiel d’exigences PDIS (Prestataires de Détection des Incidents de Sécurité [lien FR]).
Trois points sont traités en particulier pour la standardisation :
- D’abord, l’organisation de la surveillance : il existe dorénavant une obligation de détection de certains types d’attaques communes et d’implémentation de contrôles faisant suite à des recommandations réalisées via des audits qualifiés suivant le référentiel PASSI (Prestataires d’Audit de la Sécurité de Systèmes d’information [lien EN / lien FR]). L’entreprise doit également mettre en place une cellule de veille permettant de notifier l’ANSSI en cas de compromission du SI d’importance vitale.
- Le second point concerne la sécurisation des actifs du SOC : de nouvelles mesures de sécurisation décrites dans le référentiel de qualification PDIS imposent notamment un durcissement des postes des opérateurs et des administrateurs du SOC (authentification à deux facteurs, limitations des accès à internet…). Ces mesures de sécurité seront vérifiées par l’ANSSI via des audits ou rétroactivement suite à la notification de compromission du SI.
- L’architecture enfin, avec une complexification de celle-ci : un découpage en zones de confiance cloisonnées ainsi qu’un élargissement du périmètre du réseau surveillé sont imposés (outre les « classiques » équipements de sécurité, les serveurs métiers et les terminaux mobiles doivent maintenant aussi être surveillés). Les informations liées à un incident de sécurité (événements, rapports d’analyses et les notifications associées) doivent également être conservées pendant toute la durée de la prestation.
Sécurisation forte et respect des données personnelles : 2 enjeux incompatibles ?
Afin de pouvoir assurer des analyses a posteriori et notamment d’être capable de déterminer l’origine des cyberattaques, de nombreuses données personnelles et critiques doivent être collectées, conservées et exploitées. Pourtant, ces données sont soumises au GDPR qui tend à l’inverse à limiter leur collecte et leurs usages.
La récente amende de l’AGPD (l’autorité de protection des données à caractère personnel en Espagne) à Google met en lumière des problématiques que pourrait rencontrer le SOC concernant le traitement des données à caractère personnel :
- Le droit à la manipulation des données personnelles et le droit à l’oubli des utilisateurs a été la première cause de condamnation de Google. En effet, le GDPR compte offrir aux citoyens européens la possibilité d’accéder, de modifier ou de supprimer leurs données où qu’elles soient stockées (y compris dans le Cloud). Cela signifie, en pratique, que l’entreprise doit connaître exactement la teneur des données collectées par son SOC pour pouvoir en informer les clients, ses employés… Cela signifie également que ceux-ci devraient pouvoir exiger leur suppression à tout moment. Cependant, le GDPR semble indiquer qu’il est possible de conserver certaines données si celles-ci sont nécessaires à la protection des entreprises. Cette définition est appelée à être discutée dans les années à venir.
- L’obligation de transparence quant à l’exploitation des données est la seconde problématique soulevée par l’AGPD. Cependant, dans le cadre de PDIS, l’obligation de monitorer une grande variété d’équipements va engendrer la récupération d’un grand nombre de données de natures différentes. Un travail sur le contenu des logs collectés va donc être nécessaire afin de s’assurer que seules les données nécessaires à l’activité de surveillance sécurité sont récupérées.
- Enfin, le GDPR impose la justification de la conservation de la donnée. Or PDIS impose de conserver les données sur au moins six mois afin de pouvoir effectuer des analyses sur du long terme ou rétroactivement créant ainsi un flou législatif : jusqu’où peut-on aller pour assurer la protection de son SI ?
Au-delà du cas Espagnol, il est intéressant de noter les approches des différents textes sur la notification des incidents. Ceux dédiés à la protection des données à caractère personnel ciblent une notification rapide pour limiter les impacts sur la vie des citoyens, quand les textes sur la protection des infrastructures critiques eux imposent des notifications limitées et très confidentielles pour prendre le temps de gérer correctement l’incident sans révéler à l’attaquant le fait qu’il a été découvert. GDPR a finalement prévu ce cas de figure mais d’autres textes pourraient également être contradictoires.
Un cadre réglementaire strict mais bénéfique
Le durcissement du cadre réglementaire pour le SOC, que ce soit direct (PDIS) ou indirect (GDPR), va engendrer une transformation de l’écosystème. De nouveaux profils pourraient ainsi s’intégrer aux équipes comme le DPO (Data Privacy Officer) que le SOC pourrait considérer comme un acteur clé pour maintenir sa conformité dans la durée.
De plus, ces réglementations vont tirer vers le haut les niveaux de maturité des acteurs soumis à ces référentiels ainsi que de ceux s’en inspirant. D’ores et déjà on observe de nombreux chantiers de mise en conformité touchant tant à l’architecture du SOC qu’à ses processus et sa gouvernance.
Pour satisfaire aux réglementations, l’outillage compte également, et il faut jouer avec les innovations telle que la surveillance orientée sur les données (avec de l’outillage de type Data Leakage Prevention – DLP), qui peut aider à la mise en conformité sur la protection des données sensibles.
Vers des réglementations plus réalistes…
L’apport des référentiels est indéniable, en tant que standard et en tant que cible à atteindre pour nombre d’organisations.
Si la barre peut sembler haute, ou que l’on trouve encore quelques incohérences entre les différents textes, on peut gager que les prochaines révisions apporteront un cadre solide pour la conception et l’amélioration des SOC.
