Cyber Resilience Act (CRA) : les 13 exigences clés qui concernent les solutions ZTNA, PAM, AM et IAM

Le 23 octobre 2024, l’Union européenne a publié un nouveau règlement relatif à la cyberrésilience, intitulé plus précisément : « exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques ».

L’objectif est clairement affiché : « faire en sorte que 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 est important de noter que ce règlement doit notamment s’appliquer aux marchés publics, en imposant aux acheteurs de s’assurer du « respect des exigences essentielles de cybersécurité […], y compris de la capacité du fabricant à traiter efficacement les vulnérabilités ».

Cet article porte sur les impacts produit pour les logiciels des domaines de l’accès réseau Zero Trust (ZTNA), de la gestion des accès à privilèges (PAM), de la gestion des accès (AM) et de la gestion des identités et des accès (IAM).

Quels domaines de la cybersécurité sont concernés ?

Les produits sont répartis en plusieurs catégories, chacune imposant des mesures de plus en plus strictes pour se conformer au Cyber Resilience Act.

Les trois catégories les plus importantes 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 comprend les domaines de cybersécurité cités plus haut, selon le critère suivant :

« Le produit comportant des éléments numériques remplit des fonctions de cybersécurité essentielles pour d’autres produits, réseaux ou services, notamment la sécurisation de l’authentification et de l’accès, la prévention et la détection des intrusions, la sécurité des terminaux ou la protection des réseaux. »

En conséquence, l’annexe III, qui énumère les domaines relevant de la classe I, mentionne notamment :

• « Les systèmes de gestion des identités et les logiciels et dispositifs de gestion des accès à privilèges, y compris les lecteurs d’authentification et de contrôle d’accès et les lecteurs biométriques »
• « Les gestionnaires de mots de passe »
• « Les produits comportant des éléments numériques offrant une fonctionnalité de réseau privé virtuel (VPN) »

Cela concerne directement les fonctionnalités de la plateforme SaaS CyberElements, qu’il s’agisse du Zero Trust (ZTNA), de la gestion des accès à privilèges (PAM), de la gestion des accès (AM) ou de la gestion des identités et des accès (IAM).

Les obligations se répartissent globalement en deux grandes catégories : celles qui portent sur le produit lui-même, et celles qui concernent la communication sur les vulnérabilités ou les incidents majeurs. Cette section porte sur les obligations liées au produit.

Les 13 obligations pour les produits ZTNA, PAM, AM et IAM

Les fabricants doivent tenir à jour une évaluation de la conformité de leurs produits aux obligations découlant de ce règlement.

En règle générale, la documentation produit comprendra une analyse de la mise en œuvre de chaque obligation dans le produit.

Les 13 points ci-dessous ont des impacts plus ou moins importants sur le produit :

1. « Être mis sur le marché sans vulnérabilité exploitable connue » : cela peut sembler évident, mais une forme d’attestation de conformité sur l’absence de vulnérabilités est ici exigée. La question sera particulièrement importante pour les composants tiers susceptibles d’être concernés. Elle aura le même impact sur tous les types de solutions.
2. « Être mis sur le marché avec une configuration sécurisée par défaut », y compris « la possibilité de réinitialiser le produit à son état d’origine » : une mesure de prudence. L’un des risques est la mauvaise utilisation d’un produit de cybersécurité. Dans nos domaines, cela peut se traduire par exemple par un chiffrement AES-256 recommandé et activé par défaut, des modes d’accès ZTNA par défaut sans agent installé sur le terminal, ou un ensemble de restrictions appliquées par défaut à l’accès aux ressources.
3. « Être conçus de manière à ce que leurs vulnérabilités puissent être corrigées au moyen de mises à jour de sécurité, y compris, le cas échéant, de mises à jour de sécurité automatiques régulières activées par défaut mais faciles à désactiver, d’une information des utilisateurs sur les mises à jour disponibles et de la possibilité de les reporter temporairement » : il s’agit d’un mode de fonctionnement clair et précis, nécessaire pour chacun des domaines cités. Il reprend ce que l’on connaît depuis longtemps pour les systèmes d’exploitation. En revanche, la chaîne d’approvisionnement des mises à jour automatiques, dont on sait qu’elle peut être compromise, n’est pas abordée.
4. « Assurer une protection contre les accès non autorisés au moyen de mécanismes de contrôle appropriés, notamment, mais pas exclusivement, des systèmes d’authentification, de gestion des identités ou des accès, et signaler tout accès non autorisé » : un principe fondamental qui appelle l’utilisation de l’authentification multifacteur. Ce sont les principes du Zero Trust, qui auront par exemple un impact sur toutes les consoles d’administration des produits. Le système doit donc pouvoir s’intégrer à une infrastructure de gestion des identités et des accès et être provisionné en temps réel pour appliquer les principes d’accès Zero Trust.
5. « Protéger la confidentialité des données stockées, transmises ou traitées d’une autre manière, à caractère personnel ou non, 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 » : c’est aussi une attente classique pour tout produit de cybersécurité. La confidentialité des données en transit est assurée par des tunnels sécurisés de bout en bout, du terminal de l’utilisateur jusqu’au réseau de l’équipement ou de l’appareil protégé. Il est aussi important d’empêcher tout accès « descendant » non protégé à l’équipement : on privilégiera un accès « montant » via des tunnels sécurisés, chiffrés avec une clé détenue par l’organisation elle-même.
6. « Protéger l’intégrité des données stockées, transmises ou traitées d’une autre manière, à caractère personnel ou non, ainsi que des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l’utilisateur, et signaler les altérations » : on retrouve ici, par exemple, la nécessité d’un serveur d’intégrité des binaires capable de vérifier l’intégrité des composants à chaque exécution. Cela peut avoir un impact sur l’infrastructure d’un produit. Cela peut aussi s’appliquer à un produit de gestion des utilisateurs à privilèges, pour garantir l’intégrité des vidéos de session.
7. « Ne traiter que les données, à caractère personnel ou non, adéquates, pertinentes et limitées à ce qui est nécessaire au regard de l’usage prévu du produit comportant des éléments numériques (minimisation des données) » : cela peut concerner les pratiques de conservation des informations (traces vidéo, par exemple), ainsi que l’anonymisation des données sensibles journalisées, quel qu’en soit le format. Un sujet particulièrement pertinent pour la gestion des utilisateurs à privilèges.
8. « Protéger la disponibilité des fonctions essentielles et de base, y compris après un incident, notamment au moyen de mesures de résilience et d’atténuation des attaques par déni de service » : au-delà de la protection contre le déni de service, cela implique de mettre en place des approches redondantes au niveau de l’infrastructure, voire du centre de données. Les coûts qui en découlent peuvent freiner certains achats d’équipements de cybersécurité.
9. « Réduire au minimum l’incidence négative des produits eux-mêmes ou des appareils connectés sur la disponibilité des services fournis par d’autres appareils ou réseaux » : c’est le prolongement du point précédent. Pour un produit PAM, par exemple, quelles mesures sont prévues pour continuer à administrer un système d’information si la plateforme devient indisponible ? Une approche redondante ou un mode SaaS dégradé, par exemple, pourraient être mis en place pour maintenir l’activité.
10. « Être conçus, développés et fabriqués de manière à limiter les surfaces d’attaque, y compris les interfaces externes » : c’est le principe de la sécurité « dès la conception », qui doit faire l’objet d’une attention à chaque étape du développement logiciel. Il s’applique de la même façon à tous les types de produits. Une attention particulière doit être portée aux interfaces web ; la simplicité est aussi une approche pertinente pour limiter les surfaces d’attaque, tout comme le fait de limiter le nombre de services exposés, voire de mettre en œuvre une technologie qui n’expose aucun service sur Internet (en particulier pour tous les appareils « connectés »).
11. « Être conçus, développés et fabriqués de manière à réduire l’incidence d’un incident, au moyen de mécanismes et de techniques appropriés d’atténuation de l’exploitation des vulnérabilités » : un point qui concerne assez naturellement les solutions de cybersécurité dans leur ensemble. Pour nos sujets, il s’agirait par exemple de mettre en œuvre une analyse comportementale sur un produit de gestion des utilisateurs à privilèges, pour détecter un comportement malveillant et bloquer immédiatement l’accès. Ou, dans le domaine du Zero Trust, d’une approche dynamique des restrictions d’usage : si un paramètre change, l’accès est lui aussi bloqué.
12. « Fournir des informations relatives à la sécurité en enregistrant et en surveillant les activités internes pertinentes, notamment l’accès aux données, services ou fonctions ou leur modification, tout en offrant à l’utilisateur la possibilité de désactiver ce mécanisme » : nous sommes au cœur des produits Zero Trust de gestion des utilisateurs à privilèges, avec la notion de traçabilité avancée, enregistrement des sessions compris. Le consentement de l’utilisateur doit être recherché, et le fonctionnement en mode désactivé doit relever des administrateurs du produit.
13. « Donner aux utilisateurs la possibilité de supprimer facilement, de manière sécurisée et définitive, 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 ce transfert soit effectué de manière sécurisée » : au-delà de la simple attention portée à la possibilité de supprimer ou de transférer données et paramètres, il faudra aussi fournir aux utilisateurs une forme de certification.

En conclusion, il est essentiel que nos systèmes continuent d’évoluer pour offrir les meilleures garanties possibles à nos utilisateurs. Certaines des 13 mesures sont déjà la norme pour de nombreuses solutions ; les éditeurs devront donc documenter leur conformité, et certains points devront être adaptés en interprétant au mieux les dispositions du règlement.