Le piège des guidelines cybersécurité
Teodor Chabin
Introduction
Dans de nombreuses organisations, notamment dans les départements infrastructures, réseaux ou OT (Operational Technology), on observe une forte demande de « guidelines de sécurité ». L’idée paraît simple : fournir un document générique rassemblant les bonnes pratiques de cybersécurité, afin de compléter les guides techniques déjà existants en matière d’ingénierie.
Cependant, il est fréquent que l’on propose ces guidelines sans réaliser d’analyse de risques. On se retrouve donc avec un document universel, compilant des recommandations plus ou moins applicables à tous les projets. Sur le papier, cela semble pratique et rapide à déployer, mais la réalité est plus nuancée.
Dans cet article, nous allons voir pourquoi cette approche peut poser problème et, surtout, comment proposer une alternative plus adaptée.
Pourquoi c’est une mauvaise chose
1. L’analyse de risques cybersécurité est un standard à appliquer sur chaque projet
Aujourd’hui, l’analyse de risques est considérée comme le socle incontournable de toute démarche cybersécurité. Les normes (ISO 27001, ISO 27005, etc.) ou les méthodologies (EBIOS, MEHARI, OCTAVE) convergent vers la nécessité d’évaluer précisément les menaces et impacts potentiels liés à un système.
Si l’on se contente d’un document de guidelines générique, on fait l’impasse sur cette étape fondamentale. Or, chaque projet, chaque environnement, chaque technologie présente ses propres vulnérabilités et risques.
Négliger ces spécificités conduit immanquablement à des solutions inadaptées et, surtout, à un faux sentiment de sécurité.
2. Chaque projet numérique a besoin d’un niveau de cybersécurité adapté
Un projet de déploiement d’un réseau industriel n’a pas les mêmes exigences qu’une plateforme de e-commerce. Le niveau de criticité diffère, tout comme les contraintes opérationnelles et la surface d’attaque.
L’impact d’un incident ne sera pas le même selon qu’il touche une base de données clients ou un dispositif de contrôle-commande dans une usine.
De plus, même au sein d’un même projet, tous les composants n’ont pas la même importance. Certains éléments, dits « critiques », nécessitent une protection renforcée, tandis que d’autres, moins sensibles, peuvent être sécurisés de manière plus légère.
Les guidelines génériques ne font pas cette distinction et risquent soit de surprotéger des éléments non essentiels (coût élevé), soit de sous-protéger des éléments critiques (risques majeurs).
3. Chaque guideline technique devrait incorporer la sécurité « by design »
Les équipes d’ingénierie, qu’elles soient infrastructure, réseau, OT ou même développement logiciel, ont déjà théoriquement leurs propres guides techniques. Ces documents décrivent la manière de concevoir et de mettre en œuvre les solutions, en tenant compte des bonnes pratiques de performance, de qualité et de fiabilité.
La cybersécurité doit être intégrée dans ces référentiels plutôt que d’être traitée à part. Autrement dit, la sécurité « by design » n’est pas un supplément qu’on ajoute en fin de projet : elle doit être un critère de conception, au même titre que la robustesse ou l’évolutivité du système. Un guide séparé et trop générique risque de se retrouver ignoré, car il n’est pas suffisamment ancré dans la réalité des projets techniques.
Comment proposer une alternative
1. Accompagner chaque projet numérique par la cybersécurité
La première approche consiste à mettre en place un processus d’intégration de la sécurité dans la gestion de projet. En pratique, cela signifie que pour chaque nouveau développement ou chaque nouvelle installation, un référent cybersécurité (RSSI, consultant spécialisé, etc.) participe aux réflexions initiales.
On établit alors un plan de cybersécurité adapté :
-
Identification des risques et menaces spécifiques
-
Définition d’un niveau de protection en phase avec la criticité de l’application ou de l’infrastructure
-
Mise en place de contrôles et de tests de sécurité durant toutes les phases du projet (conception, réalisation, recette, exploitation)
2. Des étapes cybersécurité et des exigences minimales
Pour être efficace, l’accompagnement cybersécurité ne doit pas être perçu comme une charge superflue. Il doit s’insérer naturellement dans le cycle de vie du projet. Par ailleurs, il existe des obligations réglementaires à respecter : RGPD pour les données personnelles, exigences sectorielles (ex. secteur bancaire, santé, etc.), normes de conformité…
Ainsi, un cadre commun peut être défini au niveau de l’entreprise : une directive de sécurité des systèmes d’information (ou ISP – « Instruction Sécurité Projets ») qui liste les étapes cybersécurité à réaliser ainsi que des exigences minimales. Par exemple :
-
Réaliser une analyse de risques avant le lancement du projet
-
Mettre en place un plan de gestion des vulnérabilités (patch management)
-
Réaliser un test d’intrusion ou un audit de configuration avant la mise en production
-
Assurer la journalisation des événements et mettre en place une politique de logs fiable
Ce document, plus global, donne un fil conducteur tout en restant suffisamment souple pour s’adapter à la variété des projets.
3. Une directive ISP (Instruction Sécurité Projets) pour regrouper les exigences
Cette directive ISP peut servir de référence aux chefs de projets, aux équipes techniques, et aux auditeurs internes ou externes. Elle va au-delà d’une simple liste de points de contrôle : elle explicite le « pourquoi » de chaque exigence, renvoie à des exemples concrets, et incite les parties prenantes à réfléchir en termes de risques.
Les guidelines techniques existantes (rédigées par les équipes ingénierie, dev, infra ou OT) peuvent alors intégrer les principes de sécurité explicités dans l’ISP. On évite ainsi la création de documents multiplicateurs, qui risquent de se contredire ou de ne pas être à jour.
Le cas spécifique où un guide cybersécurité est pertinent
1. Des systèmes numériques déployés chez les clients
Dans certaines situations, notamment lorsque l’entreprise fournit des systèmes ou services numériques à ses clients, la responsabilité légale et contractuelle est particulièrement forte. Une faille de sécurité peut entraîner des litiges, une atteinte à la réputation ou des pénalités financières.
Ici, il peut être pertinent de formaliser un guide de cybersécurité spécifiquement destiné aux équipes qui conçoivent, livrent ou maintiennent ces solutions. Ce guide précisera les contrôles obligatoires, les règles d’authentification, les exigences de chiffrement, etc.
2. Des obligations réglementaires ou sectorielles
Certains secteurs (industrie pharmaceutique, transport ferroviaire, énergie, etc.) sont soumis à des réglementations strictes qui imposent des contrôles de sécurité spécifiques. L’IoT (Internet of Things) est également de plus en plus encadré : protection des données personnelles, certifications de sécurité, obligation d’informer les utilisateurs sur les mises à jour…
Dans ces cas, un guide cybersécurité regroupant l’ensemble des exigences légales et normatives peut s’avérer très utile. Il servira de référence pour tous les acteurs : développeurs, intégrateurs, équipes qualité, service juridique, etc.
3. Un modèle « product security » et « security by design »
Lorsque l’organisation commercialise ou déploie des produits numériques, adopter un modèle de « product security » est crucial. L’idée est d’intégrer, dès la phase de conception, les bonnes pratiques de sécurité :
-
Architecture sécurisée (modèle de menace, cloisonnement, etc.)
-
Mécanismes de mise à jour fiables (OTA – Over The Air, par exemple)
-
Validation et tests de sécurité réguliers (tests unitaires, audits de code…)
-
Plan de réponse en cas de vulnérabilités découvertes après la mise sur le marché
Ainsi, le guide cybersécurité se présente comme un référentiel opérationnel pour l’équipe projet, garantissant que chaque fonctionnalité est pensée avec un angle « sécurité ».
Conclusion
L’idée d’un « guideline sécurité classique », au format générique et indépendant de tout contexte, peut paraître séduisante pour les directions techniques. Mais en réalité, la cybersécurité ne se décrète pas sur un document unique : elle doit être intégrée dans chaque étape des projets. Une analyse de risques préalable, une définition claire des niveaux de criticité, et une coordination avec les guides techniques existants sont essentiels pour éviter les écueils.
Pour pallier l’absence de directives adaptées, deux documents peuvent réellement faire la différence :
-
La directive sur l’intégration de la sécurité dans les projets (ISP)
-
Elle liste les exigences cybersécurité minimales
-
Elle décrit les étapes de validation nécessaires tout au long du cycle de vie du projet
-
Elle renvoie à des normes ou réglementations spécifiques selon la nature du projet
-
-
Le guide « security by design » pour les systèmes délivrés aux clients
-
Il décrit comment intégrer la sécurité dès la conception du produit
-
Il couvre les obligations légales et réglementaires (IoT, secteur d’activité, RGPD, etc.)
-
Il définit un cycle de vie de la sécurité pour les mises à jour, les audits et la maintenance
-
En choisissant une démarche plus contextuelle et adaptée, les organisations gagnent en efficacité, en réactivité et en crédibilité. La cybersécurité devient alors un atout stratégique plutôt qu’une contrainte imposée par un simple document générique.
