Zero Trust : anti-SOC, tu perds ton sang froid ?

Introduction

Le Security Operation Center (SOC) est aujourd’hui un acteur incontournable de l’entreprise avec son cœur de métier : la supervision du système d’information (SI). Cette entité couvre souvent un périmètre variable selon les besoins des services et fonctionne différemment d’une organisation à l’autre, incluant parfois : les activités des Computer Emergency Response Team (CERT) et Computer Security Incident Response Team (CSIRT) [1] (voir figure 1) avec notamment la veille en vulnérabilité et la réponse aux incidents, mais également le pilotage de projets, ou encore le rôle de bras armé du responsable de la sécurité des systèmes d’information (RSSI) ou du directeur cybersécurité [2] pour faire appliquer la politique de sécurité du système d’information (PSSI).

Avec des casquettes allant de simple cellule d’expertise en sécurité des systèmes d’information (SSI) à autorité déléguée de l’autorité qualifiée pour la sécurité des systèmes d’information (AQSSI), quand il ne fournit pas aussi le service de puits de log pour la direction des systèmes d’information (DSI) ou les plateformes de Big Data. Une chose est certaine, ce ne sont pas les sujets qui manquent dans un SOC, que le candidat ait un profil dit « technique », « projet » ou « fonctionnel ». Toutes les entités qui possèdent une DSI et ayant atteint une certaine maturité possèdent en général un SOC (interne, externe ou hybride).

Le SOC, au sens large, est souvent sollicité au sujet des évolutions du SI et il n’y pas de raison que ce dernier ne le soit pas sur le sujet de Zero Trust [3] à partir du moment où celles-ci portent sur la sécurité des SI. Dans cet article, après avoir rappelé rapidement les principes Zero Trust qui concernent les SOC, nous ferons état des éléments du contexte actuel d’un SOC pour enfin mieux présenter quelques enjeux techniques dont ces derniers devront tenir compte dans le passage au Zero Trust.

1. Zero Trust SOC ?

Nous allons commencer par rappeler que Zero Trust n’est pas une solution clé en main, mais un framework sur lequel nous pouvons nous appuyer pour concevoir des socles d’architectures ou de réseaux « sécurisés » et orientés sur la protection de la donnée et donc de l’activité. Si le terme est à la mode ces derniers temps les concepts associés ne sont pas nouveaux, en particulier dans les milieux bancaires ou militaires.

Il y a trois idées principales à retenir de la vision initiale Zero Trust (notions qui sont d’ailleurs présentées depuis longtemps dans les cours de SSI) :

• toute ressource est accédée, de manière sécurisée, c’est-à-dire de manière authentifiée, chiffrée, tracée (potentiellement signée) et plus important indépendamment de la provenance du client : Internet, intranets, extranets, Bring Your Own Device (BYOD), laptop, smartphone, etc. ;
• les Access-Control Lists (ACL) sont construites en suivant le principe du moindre privilège, par rôle et par microservices ;
• tous les endpoints (laptop, smartphone, etc.) sont supervisés, aussi finement que possible sur le réseau, mais aussi en local. Point important, le modèle remet systématiquement en cause la confiance dans ces éléments, en particulier parce qu’ils viendraient d’une provenance connue supposée de confiance (par exemple : l’intranet de l’entreprise).

Ce dernier point est une des raisons pour lesquelles les SOC existent aujourd’hui : voir précisément ce qui se passe sur le SI. Ils doivent avoir la capacité de détailler finement l’activité d’un utilisateur, d’un poste ou d’un serveur en temps pour ainsi dire réel, dans des objectifs de sécurité seule : détecter le maximum d’anomalies et de menaces, ainsi que diminuer le temps de réponse aux incidents.

1.1 Rappels des principes du Zero Trust

Avant d’aller plus loin, rappelons quels sont les grands principes qui régissent un projet Zero Trust :

1. maîtriser, ou a minima connaître, le périmètre et les usages ;
2. prendre en compte la sécurité dès la conception ;
3. partir du principe que tout réseau est hostile, interne comme externe ;
4. authentifier et autoriser chaque utilisateur, device et flux ;
5. construire des politiques de sécurité dynamiques et automatisées.

Il s’avère qu’aujourd’hui, un SOC qui se respecte devrait déjà avoir une connaissance avancée de l’existant concernant les points 1, 3, 4 et 5 pour l’entreprise, mais aussi probablement pour le 2 si l’équipe porte également des projets d’entreprises.

Cette connaissance des systèmes numériques est fondée sur l’expérience et la connaissance opérationnelle du SI qu’a le SOC et non pas sur des règles stratégiques portées par la PSSI (règles qui prennent évidemment en compte ces retours d’expérience). Nous parlons bien ici de l’exposition des analystes, admins, responsables du SOC aux données que le SIEM ingère ainsi que des événements de sécurité plus ou moins courants, mais aussi des échanges que cela génère avec le reste des acteurs du SI. Il s’agit d’un travail de terrain, qui décline de manière très opérationnelle les règles stratégiques de la PSSI.

Vos serviteurs ont coutume de dire que : « Le métier d’un SOC : c’est de connaître le SI de l’entreprise mieux que les personnes qui le gèrent ».

1.2 One does not simply walk into Zero Trust

Zero Trust n’est pas un « projet » dans lequel il suffit de basculer le SI de l’entreprise. Un certain degré de maturité est nécessaire pour parler d’un SI Zero Trust. Que la DSI ou le RSSI parle de faire du Zero Trust dans un projet traditionnel, de l’intégrer dans du mode agile ou de migrer le SI en s’engageant dans une conduite du changement sur plusieurs années ; voici quelques étapes à suivre :

• définir la surface à protéger : identifier les risques encourus et ce qu’il faut protéger ;
• construire le diagramme des interactions : applications, réseaux, utilisateurs ;
• concevoir l’architecture, en mode Zero Trust ;
• définir la politique de droits ;
• surveiller, maintenir, faire évoluer.

Comme nous l’avons vu dans le rappel des principes, le SOC est un acteur indéniable pour construire des projets Zero Trust, mais il sera également incontournable après le projet pour le maintien en condition de sécurité (MCS) et opérationnelle (MCO) du dispositif qui sera mis en place.

2. Et le SOC là-dedans ?

Mais arrêtons de parler Zero Trust un instant et attardons-nous un peu sur les challenges que rencontre un SOC en 2020.

2.1 Les challenges que rencontre un SOC aujourd’hui

S’ils sont désormais bien intégrés et le plus souvent reconnus dans l’entreprise, le centre de supervision est aussi confronté aux évolutions effrénées d’un SI moderne :

• dilution des périphériques et sources d’accès au SI : laptop, smartphone, PC (personnel ou professionnel) ;
• diversification et perte de contrôle des devices des utilisateurs (les impératifs de production, de marché, d’actualité transforment en nébuleuse les sources de logs possibles qui alimentent le SIEM) ;
• construction des bases de connaissances de référence toujours plus complexes ;
• dispersion des SI : Cloud, Shadow IT et IOT ;
• augmentation de volume de logs qu’il faut analyser, traiter, consolider, documenter et pour lesquels les besoins exprimés touchent parfois aux limites des produits SIEM actuels ;
• gestion de l’historique de certains SI industriels pour lesquels à l’époque aucun système de logs ou de surveillance n’était prévu, mais désormais interconnectés avec le reste du SI.

La crise du Covid-19 n’a évidemment fait que renforcer ce phénomène, devant l’urgence sanitaire de proposer « le travail à distance pour tous » beaucoup de DSI ont ainsi autorisé de nouveaux usages en catastrophe et mis en place des systèmes avec une rapidité peut-être excessive (mais nécessaire) pour que la chaîne Sécurité puisse s’adapter correctement [4].

Mais toutes ces difficultés sont-elles vraiment liées à Zero Trust ? Non. La tendance était déjà en marche depuis plusieurs années et les SOC sont déjà en train de s’adapter et de répondre aux nouvelles exigences, sans volonté de contrecarrer ces évolutions.

2.2 Quels enjeux pour le SOC ?

Nous l’avons évoqué dans l’introduction, beaucoup de SOC ont encore une approche « traditionnelle » du SI fondée sur les présupposés suivants :

• les utilisateurs et machines « internes » sont de confiance ;
• les réseaux sont compartimentés par « bulles » regroupant des machines de niveaux de sensibilités similaires ;
• tout ce qui est externe aux réseaux « de confiance » est considéré comme dangereux ;
• le SOC est une entité centrale surveillant au moins les échanges réseaux entre « dehors » et « dedans » et, lorsque c’est possible, les devices et applications présents au sein du réseau interne.

La dispersion du SI, dont rend compte Zero Trust, implique que cette approche devienne de moins en moins efficace à l’avenir. Quelles évolutions globales pour nos supervisions par rapport aux principes de Zero Trust ?

Tout d’abord, le concept d’une supervision unique et centrale risque de voler en éclats, le chiffrement systématique des communications masquant la majorité des indicateurs de compromission réseau que l’on pourrait y chercher. À moins de mettre en place du déchiffrement SSL à grande échelle, mais nous montrerons par la suite que ce choix est, au mieux, cornélien.

La suite logique serait donc de doter le SOC de capacités de détection et de contrôle directement sur tous les endpoints : postes, mais aussi smartphone et IoT. De même en ce qui concerne les logs serveurs, et notamment applicatifs ou de stockage, pour tout ce qui touche au contrôle strict des accès aux microservices.

La plupart des antivirus et y compris leurs modules Endpoint Detection and Response (EDR) peuvent aujourd’hui répondre à ce besoin de supervision en remontant les logs d’exécution de processus et les événements d’intérêts. Même s’ils n’ont pas vocation à remplacer complètement l’envoi des journaux systèmes, ils peuvent apparaître comme un compromis entre coût, risque, sécurité et visibilité plutôt intéressant.

Le projet Zero Trust de l’entreprise devra s’appuyer sur les connaissances du SI détenues par le SOC pour se construire en impliquant en tant qu’acteur ce dernier dès sa phase de conception puis lors du monitoring, a minima. Néanmoins, la suite nous montrera aussi les challenges techniques et organisationnels qu’implique un « SOC Zero Trust ».

2.3 Défis organisationnels et financiers

Le SOC de 2020 est aujourd’hui au cœur des entreprises, des enjeux métier et en visibilité des COMEX, ses challenges sont donc nombreux. La crise liée au COVID-19 avec la multiplication de nos utilisations des environnements collaboratifs ou des services de visioconférence aura amené encore de nouveaux défis.

Avec les nouveaux modes de connexions (accès distant VPN, 4G et bientôt 5G) ainsi que l’ouverture au Cloud, nos SI sont désormais en dehors des murs de l’entreprise, ils sont exposés au monde. Comment superviser ce qui est en dehors et qui n’est pas maîtrisé par l’entreprise ? Faire confiance à ces infrastructures ne suffit pas, il faut intégrer au cœur des applicatifs et du business un processus de supervision et des procédures de réponses aux incidents.

La mise en place d’une stratégie Zero Trust ne doit pas élever le SOC au rang de Big Brother. Au contraire, un de ses enjeux est d’être au plus proche des utilisateurs des SI et des métiers. En effet, il doit avoir la connaissance technique de son SI, mais également du contexte de l’entreprise, de son métier et donc de ses données afin de comprendre et interpréter les événements du SI correctement.

La supervision doit être au plus proche de la donnée, intégrer les SI métier à cette supervision est un challenge, mais cela permet de détecter des attaques non visibles sur une vue globale du SI.

L’explosion du volume de données à traiter fait que certains incidents échappent aux équipes ; dans une stratégie Zero Trust si le SOC ne peut pas tout superviser, il faut quand même tout analyser. Nous devons donc repenser le travail pour pouvoir analyser et réagir aux signaux faibles comme aux comportements inattendus des utilisateurs.

Les attaques sont de plus en plus sophistiquées, les attaquants mieux organisés et leurs méthodes évoluent en permanence. L’utilisation de la Threat Intelligence afin de révéler des indicateurs d’attaque ou de compromission, la détection de comportements anormaux via du Machine Learning et enfin, l’automatisation des tâches avec des outils tels que les SOAR (Security Orchestration Automation and Response) permettent aux SOC de relever le défi d’analyser l’ensemble du SI et de gagner en efficacité.

Enfin, les compétences en sécurité sont rares et l’industrialisation des SOC doit par conséquent repositionner l’humain au centre du SOC sur des tâches à forte valeur ajoutée.

3. Quels impacts pour les outils utilisés par le SOC ?

Les SOC et les SIEM ont déjà un pied dans les principes Zero Trust depuis quelques années. Dans cette dernière partie, nous allons lister 3 éléments d’intérêts en vue d’une supervision Zero Trust.

3.1 Proxy deciphering : augmenter sa visibilité du réseau à l’ère de TLS 1.3

La vision Zero Trust présente un paradoxe, elle recommande :

• que le trafic réseau soit systématiquement chiffré et authentifié ;
• de mettre en place une supervision de sécurité du réseau.

Mais celle-ci ne pourra presque rien analyser du trafic en question dans la mesure où 90 % [5] de celui-ci est chiffré à l’heure actuelle, sauf si des systèmes d’interception SSL sont mis en place, en particulier pour le trafic web des utilisateurs.

/// Image : activite_reseau.png ///

Dans un modèle décompartimenté en microservices comme Zero Trust, positionner des sondes d’interception semble être un exercice complexe et potentiellement coûteux selon l’architecture en place, sauf si l’on choisit de ramener les utilisateurs et les administrateurs dans des zones réseaux sources bien identifiées (au travers de VPN ou de positionnement physique des réseaux par exemple), ce qui va à l’encontre du modèle. Et nous n’abordons pas ici les impacts sur l’architecture réseau et l’augmentation des débits.

Cette complexité est aussi soulignée par des études [6] [7] qui montrent que ces systèmes détruisent le modèle de confiance sur lequel repose le chiffrement des communications, malgré des avantages certains en détection pour l’analyse antivirale et le sandboxing à la volée ou encore la recherche d’IoC. Ces produits auraient en fin de compte tendance à réduire la sécurité globale, principalement en inhibant le contrôle des certificats et les mécanismes de sécurité des navigateurs, voire par l’introduction de vulnérabilités en forçant les versions inférieures des protocoles ou simplement par de mauvaises configurations.

Et comment terminer sans évoquer l’interception SSL et le défi que présente l’arrivée de TLS 1.3 pour ces systèmes ? Pour rappel, la nouvelle mouture de TLS est une réécriture importante du code source qui apporte de nouvelles fonctionnalités notamment en termes de sécurité et de performances. Les nouveautés les plus significatives pour l’interception [8] sont dans la manière dont le handshake TLS est réalisé avec :

• l’usage Ephemeral Diffie-Hellman pour le Forward Secrecy [9] ;
• l’envoi chiffré du certificat X509 ;
• le chiffrement du SNI (Server Name indication) [10].

Ces points remettent en cause la manière dont l’interception TLS est faite aujourd’hui, même si intercepter TLS 1.3 reste possible, la réalisation nécessite un engagement R&D non négligeable de la part des vendeurs de proxy SSL, pour des systèmes qui vont devenir complexes à administrer et surtout à maintenir à l’état de l’art de la cryptographie [11].

Pour les SOC, cela signifie que le paradigme de la supervision cœur de réseau uniquement trouve sa limite, l’étape suivante étant de positionner ses collecteurs de logs directement sur les endpoints et les serveurs.

3.2 Live Forensics

Dans cette optique, les antivirus et le cas échéant leurs modules d’EDR (Broadcom Symantec EDR, SentinelOne Endpoint Protection Plateform, Trend Micro Endpoint Sensor, Cybereason, GRR [12]) semblent être des solutions idéales : déjà en place sur une grande partie des parcs informatiques pour les antivirus, la plupart des EDR s’installent comme module du client Antivirus ou en tant qu’agent dédié avec une empreinte limitée, ce qui facilite leur industrialisation et l’acceptation par l’exploitation.

Ces outils deviennent progressivement disponibles sur les parcs de smartphones d’entreprises et peuvent donc accompagner le passage à Zero Trust en permettant une supervision très détaillée du parc (exécution de processus, suivi des flux réseaux) pour un impact, opérationnel comme de sécurité, limité sur les machines. Déployer un EDR sur son parc informatique doit se faire via un projet piloté par la DSI dans lequel les métiers sont des acteurs incontournables afin d’aider le SOC à traiter les faux positifs révélés par cet outil. Dans les SI pour lesquels le déploiement d’un EDR n’est pas aisé, des solutions de forensic offline qui plus est gratuites comme Redline de FireEye peuvent permettre de pallier ce manque d’information du poste de travail. Elles permettent donc en cas de suspicion de réaliser le forensic via une collecte unitaire des informations et de ne rapatrier le poste en offline que lorsque c’est nécessaire.

3.3 Des SIEMS et des logs

Les logs sont des éléments nécessaires pour une efficacité des activités du SOC. La pratique du modèle Zero Trust aura des répercussions non négligeables sur l’utilisation des logs.

D’une part, ce modèle implique de récupérer toujours davantage de logs. En d’autres termes, les volumes des logs augmenteront sans fin apparente parallèlement à la multiplication des sources de logs. En effet, en plus de la quantité, le modèle Zero Trust exige des logs de qualité. À la différence des logs de type réseau non modifiables, les logs de type « event » peuvent être modifiés par les cybercriminels. Ceux-ci, piratant de plus en plus les comptes à privilèges, n’hésitent pas à modifier leurs traces en altérant les sources de logs, ce qui entrave la détection d’activités malveillantes par le SOC.

Ainsi le défi pour les SOC n’est plus seulement de détecter des attaques, mais également de bien comprendre tout ce qui passe dans le SI, parfois mieux que les administrateurs. Cela engendre la collecte et le contrôle systématique des accès et données d’authentification sur tous les composants du SI de l’entreprise (on-premise comme dans le Cloud) [13]. Pour le SOC, cela a donc comme conséquence l’utilisation de SIEM Cloud ou hybrides en plus de SIEM On-premise.

D’autre part, un autre élément pour le Zero Trust réside dans la protection du transfert des logs. En effet, du point de vue du SIEM, comment s’assurer que les logs émis par les sources ne sont pas interceptés ? Le standard de la remontée de logs aujourd’hui est le protocole syslog qui est très performant et facile à mettre en place. Cependant, celui-ci est non chiffré et non signé. Ainsi, pour les besoins du Zero Trust, il peut être nécessaire de rajouter au protocole syslog des fonctions de sécurité telles que le chiffrement, l’authentification et la signature.

L’utilisation du protocole syslog-tls [14] permet d’apporter une réponse en garantissant l’authentification et le chiffrement des logs entre les différentes parties prenantes. Pour ce faire, il est nécessaire d’installer au préalable des certificats sur le récepteur et l’émetteur. Mais pour l’instant peu de solutions SIEM sont compatibles avec cette RFC, et son support par des éditeurs est presque inexistant, ces derniers s’appuient à la place sur des appels à des API REST protégées en HTTPS. Une autre alternative pour les systèmes ne pouvant faire du syslog-tls consiste à faire du syslog, mais dans un tunnel VPN entre les différentes entités de manière locale lorsque c’est nécessaire.

En clair, ce modèle conduit les SOC à changer leurs habitudes et à utiliser des outils propres à garantir l’intégrité des logs collectés.

Conclusion

Au terme de cet article, il ressort que l’application du concept Zero Trust dans son ensemble a des conséquences non négligeables pour le SOC.

Au travers des impacts, nous avons vu que ce modèle pousse le SOC à se doter de capacités de collecte à grande échelle afin de fiabiliser leur supervision. À l’affût de sévices informatiques et sans perdre son sang froid, le SOC doit donc tout collecter de façon massive, distribuée, diversifiée et sécurisée, mais aussi analyser sans exception les comportements du SI, quel que soit l’élément et son emplacement. Ces objectifs doivent être adressés en respectant une réglementation complexe et en empêchant toutes les dérives possibles avec une visibilité aussi complète. Tous ces éléments lui donnent parfois un caractère antisocial vu de l’extérieur.

Parfois réduit à tort au périmètre de la détection d’incident et du support associé, ce modèle ouvre de nouvelles perspectives pour les SOC et les conduit à repenser leurs modalités de fonctionnement et leurs outils, face à des contraintes toujours plus fortes et exigeantes qu’auparavant. Nous en voulons pour preuve les limites qui peuvent survenir sur les SIEM du fait de la nécessité d’intégrer davantage de logs et de l’utilisation de protocole de transfert plus sécurisé.

Néanmoins, nous pouvons affirmer que le concept Zero Trust n’est pas nouveau pour les SOC puisque bon nombre le pratiquent déjà. Il apparaît clairement qu’une adoption générale de ce modèle ne fera que renforcer cette tendance sans « temps perdu qu’on ne rattrape plus ». De ce fait, les projets d’entreprise Zero Trust doivent impérativement s’appuyer sur l’expérience et la connaissance du terrain qu’ont les SOC pour identifier non seulement leurs cibles et architectures par rapport aux interactions connues avec les modèles de droits actuels, mais aussi comme d’habitude les périmètres à surveiller. Pour un SOC dans les années à venir il risque d’être « impossible d’avancer sans son gilet pare-balles ».

Remerciements

Les auteurs tiennent à remercier particulièrement Nicolas, Grégoire, Frédéric, Sabine et Marion pour leurs relectures attentives ainsi que l’ensemble de l’équipe du SOC EDF pour avoir rendu possible cet article.

Références

[1] « Dossier CERT, CSIRT et SOC en pratique comment s’organiser et quels outils mettre en place ? », MISC n°94, https://connect.ed-diamond.com/MISC/MISC-094

[2] « De l'urgence de nommer des Directeurs Cybersécurité », CESIN,https://www.cesin.fr/fonds-documentaire-le-directeur-cybersecurite-decrypte.html

[3] « No More Chewy Centers: The Zero Trust Model Of Information Security », http://crystaltechnologies.com/wp-content/uploads/2017/12/forrester-zero-trust-model-information-security.pdf

[4] « Recommandations de sécurité informatique pour le télétravail en situation de crise », https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/recommandations-securite-informatique-teletravail

[5] « HTTPS encryption on the web », https://transparencyreport.google.com/https/overview?hl=en

[6] « TLS Proxies: Friend or Foe?, Mark O’Neill, Scott Ruoti, Kent Seamons, Daniel Zappala », https://arxiv.org/pdf/1407.7146.pdf

[7] « The Security Impact of HTTPS Interception », https://jhalderm.com/pub/papers/interception-ndss17.pdf

[8] « Responsibly Intercepting TLS and the Impact of TLS 1.3 », https://docs.broadcom.com/doc/responsibly-intercepting-tls-and-the-impact-of-tls-1.3.en

[9] « Forward secrecy », https://en.wikipedia.org/wiki/Forward_secrecy

[10] « Encrypt it or lose it: how encrypted SNI works », https://blog.cloudflare.com/encrypted-sni/

[11] « Why Cryptography Is Harder Than It Looks », https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html

[12] « Arrêtez de grogner avec GRR Rapid Response ! », MISC n°87, https://connect.ed-diamond.com/MISC/MISC-087/Arretez-de-grogner-avec-GRR-Rapid-Response

[13] « On Premises, Hybrid or Cloud SIEM : Which one is right for you ? », https://blog.rapid7.com/2019/05/23/siem-delivery-models-where-do-todays-risks-and-future-technology-lead-us/

[14] « RFC 5425 - Transport Layer Security (TLS) Transport Mapping for Syslog », https://tools.ietf.org/html/rfc5425