Le règlement européen relatif à la cybersécurité bientôt adopté ?
Le 10 décembre dernier, les institutions européennes sont parvenues à un accord politique s’agissant du règlement sur la cybersécurité.
Ce texte crée, notamment, un cadre européen pour la certification de la cybersécurité. Cette certification est destinée aux produits et services TIC. Cela pourra, par exemple, concerner la sécurité des objets connectés (assistant vocal, montre, lunette, réfrigérateur…).
Un cadre européen de certification
L’une des innovations majeures de ce règlement est d’instituer un cadre européen de certification de la cybersécurité. Le règlement ne vise pas à instaurer des systèmes de certification immédiatement opérationnels, mais plutôt à créer un cadre pour l’instauration de systèmes de certification spécifiques à certains produits et services. Les systèmes européens de certification de cybersécurité seront préparés par l’ENISA, Agence de l’Union européenne pour la cybersécurité. Ils définiront notamment les objectifs de sécurité et préciseront le niveau de sécurité attendu (élémentaire, substantiel ou élevé). Le principe de « security by design » est au cœur de cette certification, la sécurité devant être intégrée dès la conception et le développement.
Un certificat européen de cybersécurité pourra ainsi être délivré par un organisme d’évaluation de la conformité. Ce certificat sera alors valable au sein de toute l’Union européenne. Ce mécanisme ira donc bien au-delà des accords de reconnaissance mutuelle qui existent actuellement entre certains Etats membres. Il ne sera donc par exemple pas nécessaire pour une entreprise de faire certifier son produit dans tous les pays qu’elle cible.
Un avantage concurrentiel pour les produits et services certifiés
L’obtention d’un tel certificat sera un gage de confiance pour les clients puisqu’il garantira que le produit ou service concerné répond à toutes les exigences de sécurité applicables. Il permettra donc aux clients de vérifier que le niveau d’assurance de la sécurité des produits et services qu’ils acquièrent ou achètent est satisfaisant.
Son obtention constituera dès lors un réel avantage compétitif pour les entreprises.
La procédure d’adoption du texte
Le règlement doit encore être formellement adopté par le Parlement européen et le Conseil de l’UE. Un vote au Parlement est prévu en mars 2019. Dans la mesure où il s’agit d’un règlement européen, ce texte sera directement applicable au sein de tous les Etats membres sans qu’aucun texte de transposition ne soit nécessaire.
Je partage
Derniers articles
Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client
Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?
Angular, N’Tier et HttpOnly
Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?