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.
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é.
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).
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.
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)
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.
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.
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.
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.
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é ».
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.