Les 13 points impactant les produits ZTNA, PAM, AM et IAM
suite au Cyber Resilience Act (CRA) de l’Union Européenne
Le 23 octobre 2024, un nouveau règlement (et ici dans une forme synthétique) de l’Union Européenne est paru concernant la cyberrésilience et plus exactement dans ces attendus : « exigences de cybersécurité horizontales pour les produits comportant des éléments numériques ».
L’objectif est très clairement affiché : « les produits matériels et logiciels mis sur le marché présentent moins de vulnérabilités et que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d’un produit ».
Il convient de noter que ce règlement devra notamment être appliqué « lors des achats publics » avec la nécessité pour les acheteurs de veiller au « respect des exigences essentielles de cybersécurité […] y compris la capacité du fabricant à traiter efficacement les vulnérabilités. »
Nous nous concentrerons sur les impacts produits des logiciels du domaine Zero Trust (ZTNA), gestion des utilisateurs à privilèges (PAM), de la gestion des accès (AM) et de gestion des identités (IAM).
Quels domaines de la cybersécurité sont concernés ?
Les produits sont répartis en plusieurs catégories qui vont crescendo sur les mesures à prendre pour être compatible avec le Cyber Resilience Act.
Les trois plus importantes de ces catégories sont :
- Les produits importants de classe I (article 7),
- Les produits importants de classe II (article 7),
- Les produits critiques (article 8).
La classe I est celle qui concerne les domaines cyber évoqués avec comme critère : « le produit comportant des éléments numériques exécute des fonctions essentielles pour la cybersécurité d’autres produits, réseaux ou services, y compris la sécurisation des authentifications et des accès, la prévention et la détection des intrusions, la sécurité des points terminaux ou la protection des réseaux; ».
Et de fait, dans l’annexe III qui détaille les domaines concernés par la classe I, nous trouvons notamment :
- « Systèmes de gestion des identités et logiciels et dispositifs de gestion des accès privilégiés, dont lecteurs d’authentification et de contrôle d’accès et lecteurs biométriques »
- « Gestionnaires de mots de passe»
- « Produits comportant des éléments numériques avec la fonction de réseau privé virtuel (VPN) »
Cela touche directement les fonctionnalités présentes au sein de la plate-forme SaaS cyberelements, qu’elles soient du domaine du Zero Trust (ZTNA), de la gestion des utilisateurs à privilèges (PAM), de la gestion des accès (AM) ou de la gestion d’identités (IAM).
Les obligations sont globalement de deux ordres : celles relevant du produit lui-même et celles liées à la communication sur tout sujet de vulnérabilités ou d’incidents graves. Nous adressons ici la partie liée au produit.
Les 13 obligations pour les produits de ZTNA, de PAM, d’AM et d’IAM
Les fabricants doivent maintenir une évaluation de la conformité de leurs produits aux obligations résultant de ce règlement.
Typiquement, on devra trouver dans la documentation du produit, une analyse pour chaque obligation, comment elle est mise en œuvre dans le produit.
Les 13 points sont les suivants avec un impact plus ou moins important sur le produit.
- « être mis à disposition sur le marché sans vulnérabilité exploitable connue » : cela peut paraitre une évidence, il est ici demandé une forme d’attestation de conformité à l’absence de vulnérabilité. La question va être importante pour des composants tiers qui pourraient être concernés. Cela impactera de la même façon les différents types de solution.
- « être mis à disposition sur le marché avec une configuration de sécurité par défaut » avec « compris la possibilité de réinitialiser le produit à son état d’origine » : sage précaution. Un risque étant le mauvais usage d’un produit de cybersécurité. Concernant nos domaines, cela peut être pour un, un chiffrement recommandé AES-256 positionné par défaut, des modes d’accès par défaut pour le ZTNA sans agent installé sur le poste ou bien avec un ensemble de restrictions positionnées par défaut pour l’accès à des ressources.
- « être conçus de façon à ce que leurs vulnérabilités puissent être corrigées par des mises à jour de sécurité, y compris, le cas échéant, par des mises à jour automatiques de sécurité régulières activées par défaut, mais faciles à désactiver, par la communication aux utilisateurs des mises à jour disponibles et par la possibilité de les différer temporairement » : voici un mode opératoire, clair, précis de ce qu’il est nécessaire d’avoir et ceci pour chaque domaine évoqué. Nous retrouvons la description de ce que nous connaissons historiquement sur des systèmes d’exploitation. Il n’est pas évoqué la chaine logistique de la mise à jour automatisée dont on sait qu’elle peut être compromise.
- « assurer la protection contre les accès non autorisés par des mécanismes de contrôle appropriés, y compris, mais sans s’y limiter, par des systèmes d’authentification, d’identité ou de gestion des accès et signaler tout accès non autorisé; » : un principe de base qui appelle à l’usage d’authentification à plusieurs facteurs. Nous sommes sur des principes de Zero Trust et qui impacteront chaque console d’administration des produits, par exemple. Le dispositif doit donc permettre de s’intégrer dans une infrastructure de gestion des identités et des accès, et d’être provisionné en temps réel pour assurer les principes d’accès du Zero-Trust.
- « protéger la confidentialité des données stockées, transmises ou traitées de toute autre manière, à caractère personnel ou autres, par exemple en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes de pointe et par d’autres moyens techniques » : nous sommes ici aussi, sur un acquis normalement de tout produit de cybersécurité. La confidentialité des données en transit procède par tunnels sécurisés de bout en bout, depuis le terminal de l’utilisateur jusqu’au réseau de l’équipement ou du dispositif à protéger. Il s’agit aussi d’éviter tout accès « descendant » vers l’équipement sans protection : on privilégiera les accès « montants » au travers de tunnels sécurisés, chiffrés avec une clé détenue par l’organisation elle-même.
- « protéger l’intégrité des données stockées, transmises ou traitées de toute autre manière, à caractère personnel ou autres, des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l’utilisateur et signaler les corruptions; » : nous retrouvons ici, par exemple, la nécessité d’avoir un serveur d’intégrité des binaires qui à chaque exécution peut garantir l’intégrité des composants. Cela peut impacter l’infrastructure d’un produit. Cela peut être également pour un produit de gestion des utilisateurs à privilèges, une garantie d’intégrité des vidéos de sessions.
- « ne traiter que les données, à caractère personnel ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité prévue du produit comportant des éléments numériques (minimisation des données); » : cela peut concerner les pratiques de rétention de l’information (traces vidéo par exemple), également l’anonymisation des données sensibles qui sont consignées dans des logs quel que soit le format. Un sujet touchant particulièrement le domaine de la gestion des utilisateurs à privilèges.
- « protéger la disponibilité des fonctions essentielles et de base, notamment après un incident, y compris par des mesures de résilience et d’atténuation face aux attaques par déni de service; » : au-delà de protection contre les dénis de services, cela engage à mettre en place des approches de systèmes redondés, au niveau de l’infrastructure et même du data-center. Le coût qui en résulte risque de freiner certains achats d’équipement de cybersécurité.
- « réduire au maximum les répercussions négatives générées par les produits eux-mêmes ou par les appareils connectés sur la disponibilité des services fournis par d’autres dispositifs ou réseaux; » : nous sommes dans la prolongation du point précédent. Pour un produit de PAM par exemple, que faire en cas d’indisponibilité de la plate-forme pour continuer à gérer un système d’information ? Une approche redondée ou un mode dégradé en SaaS par exemple pour continuer à travailler.
- « être conçus, développés et fabriqués de manière à limiter les surfaces d’attaque, y compris les interfaces externes; » : nous sommes sur le concept de sécurité « by design » qui doit être un point d’attention pour chaque étape du développement logiciel. Cela concerne de la même façon tous les types de produits. Un soin particulier doit être porté sur les interfaces web, la simplicité est une approche pertinente également pour limiter les surfaces d’attaque ou bien encore d’avoir des services exposés en nombre limité, voire même de mettre en œuvre une technologie qui n’expose pas les services sur Internet (notamment pour tous les dispositifs « connectés »).
- « être conçus, développés et fabriqués de manière à réduire les répercussions d’un incident, en utilisant des mécanismes et des techniques appropriés de limitation de l’exploitation de failles; » : un point qui concerne assez naturellement les solutions globales de cybersécurité. Ici, pour nos sujets, ce sera par exemple, la mise en œuvre d’une analyse comportementale sur un produit de gestion des utilisateurs à privilèges pour détecter la malveillance d’un utilisateur et immédiatement bloquer ses accès. Cela peut être également dans le domaine du Zero Trust, une approche dynamique des restrictions d’usage, en cas de changement d’un paramètre, les accès sont également bloqués.
- « fournir des informations relatives à la sécurité en enregistrant et en surveillant les activités internes pertinentes, y compris l’accès ou la modification des données, des services ou des fonctions, tout en laissant à l’utilisateur la possibilité de désactiver le mécanisme; » : nous sommes au cœur des produits de Zero Trust et de gestion des utilisateurs à privilèges avec la notion de trace évoluée y compris l’enregistrement de la session. Le consentement de l’utilisateur est à solliciter, le fonctionnement en mode désactivé doit être le sujet des administrateurs des produits.
- « donner aux utilisateurs la possibilité de supprimer facilement, en toute sécurité et de manière permanente toutes les données et tous les paramètres et, lorsque ces données peuvent être transférées vers d’autres produits ou systèmes, veiller à ce que cela puisse se faire de manière sécurisée. » : une attention simple avec la nécessité de pouvoir supprimer ou transférer les données et paramètres, il conviendra également d’en fournir une forme d’attestation aux utilisateurs.
En conclusion, il convient de souligner l’importance vitale pour nos systèmes de continuer en permanence à les faire évoluer pour apporter les meilleures garanties à nos utilisateurs. Une partie des 13 mesures est déjà un standard pour beaucoup de solutions, l’obligation sera pour les éditeurs de bien documenter la conformité et une partie des points nécessitera une adaptation en interprétant au mieux les consignes de cette directive.