Points clés
- Un cadre de sécurité projet unifié s'applique à tous les projets selon leur niveau de criticité, pas uniquement aux projets IT sensibles
- Le NIST Secure Software Development Framework (SSDF) fournit le référentiel le plus largement adopté pour structurer ce cadre
- Goldman Sachs a mis en place un processus de Technology Risk Assessment obligatoire pour tout projet dépassant un seuil de matérialité défini
- La structure du cadre comprend : classification, revues aux jalons, responsabilités, indicateurs et plan de remédiation
Structurer un cadre de sécurité applicable à l'ensemble des projets d'une organisation répond à un besoin fondamental : l'homogénéité. Sans cadre unifié, chaque projet traite la sécurité différemment selon la sensibilité de son chef de projet, les pratiques de l'équipe technique impliquée, ou la pression du moment. Cette hétérogénéité produit des angles morts dans le portefeuille de projets.
Un cadre de sécurité projet efficace n'est pas un catalogue de contrôles techniques. C'est un processus de gouvernance qui définit comment les décisions relatives à la sécurité sont prises, par qui, et à quel moment dans le cycle de vie de chaque projet. Sa valeur est dans sa systématisation, pas dans sa sophistication technique.
Les composantes d'un cadre de sécurité projet
Un cadre structuré comprend cinq composantes : la classification initiale (quel niveau de sécurité s'applique à ce projet ?), les Security Gates (quels contrôles doivent être validés à chaque jalon ?), la désignation des responsabilités (qui est responsable de quoi sur la dimension sécurité ?), les indicateurs de suivi (comment mesure-t-on le niveau de sécurité du projet en cours ?) et le plan de remédiation (comment les risques résiduels identifiés seront-ils traités après déploiement ?).
L'OWASP Application Security Verification Standard (ASVS) fournit des critères de vérification détaillés pour les projets applicatifs, organisés par niveau de criticité. Le NIST SSDF structure l'ensemble du cycle de développement sécurisé. Ces référentiels sont complémentaires et peuvent être combinés selon le contexte.
L'adaptation selon la criticité
Un cadre applicable à tous les projets doit être modulaire : les exigences applicables à un projet de criticité faible doivent être significativement plus légères que celles applicables à un projet stratégique, sans que cela crée des angles morts. La classification initiale est donc le pivot du cadre : elle détermine le niveau d'exigence applicable et les ressources sécurité mobilisées.
La matrice de classification peut prendre des formes variées : classification binaire (projet standard / projet sensible), classification à trois niveaux (standard / sensible / critique), ou classification continue basée sur un score composite. L'important est que la classification soit objectivée par des critères explicites, pas laissée à l'appréciation individuelle.
L'intégration dans les processus existants
Un cadre de sécurité projet ne doit pas créer de processus parallèles mais s'intégrer dans les processus de gestion de projet existants. Les Security Gates s'intègrent aux jalons de gouvernance existants. Les indicateurs de sécurité s'intègrent aux tableaux de bord de pilotage de projet. Les revues de sécurité s'intègrent aux comités de pilotage. Cette intégration est la condition de son adoption opérationnelle par les équipes projet.
La résistance la plus fréquente à la mise en place d'un tel cadre vient du sentiment qu'il alourdit les processus. Cette résistance se réduit significativement lorsque le cadre est proportionné à la criticité des projets et intégré aux processus existants plutôt qu'ajouté en superposition.
Microsoft a développé le SDL en réponse à la vague de vulnérabilités Windows du début des années 2000. Le SDL définit des exigences de sécurité spécifiques à chaque phase du développement logiciel, applicables à tous les produits Microsoft selon leur classification. En vingt ans d'application, Microsoft mesure une réduction de 91 % du taux de vulnérabilités dans les produits ayant suivi le SDL par rapport aux produits antérieurs. Le SDL est aujourd'hui un standard de référence largement adapté par d'autres organisations. Microsoft a publié ses pratiques sous une licence permettant leur réutilisation.
La Commission européenne a publié un cadre de sécurité applicable à l'ensemble de ses projets numériques internes, s'appuyant sur les recommandations de l'ENISA et les exigences RGPD. Ce cadre classe les projets en trois niveaux de criticité et définit des exigences différenciées pour chaque niveau, incluant des obligations de Privacy Impact Assessment (PIA) pour les projets traitant des données personnelles. Le cadre est obligatoire pour tous les projets IT dépassant un seuil budgétaire défini. Il a été adopté comme modèle par plusieurs États membres pour leurs propres cadres nationaux.
La MAS a publié des Technology Risk Management Guidelines imposant aux établissements financiers singapouriens un cadre de gestion des risques technologiques incluant les projets de transformation. Les guidelines définissent des obligations de Security Assessment pour tout projet IT "significatif", des critères de classification de la significativité, et des exigences de reporting vers le Board sur l'état des projets en cours. Plusieurs incidents dans des établissements financiers asiatiques, révélés lors d'audits MAS, ont été directement liés à l'absence d'un tel cadre dans les projets de transformation concernés.