Sécurité par conception
Le contenu de l’annexe I, partie I, est détaillé dans Sécurité du produit. Cette page décrit comment le produire.
L’analyse de risques : le document pivot
Elle est exigée à deux titres : elle conditionne l’application des exigences essentielles « dans la mesure applicable au produit », et elle est une pièce du dossier technique.
Ce qu’elle doit contenir :
| Section | Contenu |
|---|---|
| Périmètre | Produit, versions, composants, interfaces |
| Environnement de sécurité prévu | Hypothèses sur le déploiement — reprises telles quelles dans la notice utilisateur |
| Biens à protéger | Données, fonctions, secrets, disponibilité |
| Sources de menace et scénarios | Qui, avec quelles capacités, par quel chemin |
| Évaluation | Vraisemblance et impact, sur une échelle définie et écrite |
| Traitement | Mesure retenue pour chaque risque, ou acceptation motivée |
| Couverture de l’annexe I | Exigence par exigence : applicable ou non, et pourquoi |
| Risques résiduels | Assumés, par qui, avec quelle information à l’utilisateur |
La dernière ligne est celle qui alimente le point 5 de l’annexe II — les circonstances connues pouvant entraîner un risque.
Quand la réviser : à chaque évolution majeure de l’architecture, à chaque ajout de fonctionnalité exposée, à chaque changement de l’environnement de déploiement supposé, et au minimum annuellement.
La modélisation des menaces
L’analyse de risques est un document ; la modélisation des menaces est l’atelier qui la produit. À conduire au moment de la conception, pas après.
Déroulé pratique, en deux à quatre heures par périmètre :
- dessiner le flux de données et poser les frontières de confiance ;
- pour chaque frontière, énumérer les menaces selon une grille stable — usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges ;
- retenir les scénarios crédibles, écarter les autres avec le motif ;
- associer une contre-mesure ou une acceptation à chaque scénario retenu ;
- en déduire des critères de test.
Le livrable est un schéma et une liste. Il est versé au dossier technique et rejoint la matrice de traçabilité.
Le plan de tests
L’annexe I, partie II, point 3, exige des tests et revues de sécurité efficaces et réguliers. « Régulier » suppose une cadence écrite et tenue.
| Type de test | Ce qu’il couvre | Cadence type |
|---|---|---|
| Analyse de composition (SCA) | Vulnérabilités des composants tiers | À chaque construction |
| Analyse statique (SAST) | Défauts du code que vous écrivez | À chaque construction |
| Analyse de secrets | Clés et identifiants dans le code | À chaque construction |
| Analyse de configuration | Durcissement, infrastructure déclarative | À chaque construction |
| Analyse dynamique (DAST) | Comportement de l’application exposée | Par version |
| Fuzzing | Robustesse des analyseurs d’entrée | Continu sur les composants exposés |
| Revue de code sécurité | Fonctions sensibles : authentification, cryptographie, analyse d’entrée | Par changement sensible |
| Test d’intrusion | Vision d’ensemble, chaînage de défauts | Annuel, et avant les versions majeures |
Chaque test doit produire un rapport daté et conservé : c’est la preuve de l’exigence. Un test réalisé sans rapport archivé n’existe pas pour l’auditeur.
Le durcissement par défaut
L’exigence de configuration sécurisée par défaut se traduit par un référentiel de durcissement écrit et testé automatiquement :
- aucun identifiant par défaut partagé entre exemplaires ;
- aucun service ou port ouvert sans nécessité fonctionnelle ;
- interfaces de débogage absentes des versions de production ;
- chiffrement activé par défaut sur les flux et les stockages ;
- journalisation activée, avec la possibilité documentée de la désactiver ;
- procédure de réinitialisation à l’état d’origine testée.
Le test d’installation depuis l’état d’usine, exécuté automatiquement, est le contrôle le plus efficace : il vérifie ce que reçoit réellement le client, et non ce que la documentation affirme.
Les référentiels mobilisables
En attendant que les normes harmonisées soient citées au Journal officiel :
| Référentiel | Ce qu’il couvre |
|---|---|
| IEC 62443-4-1 | Processus de développement sécurisé |
| IEC 62443-4-2 | Exigences techniques des composants |
| NIST SP 800-218 (SSDF) | Pratiques de développement sécurisé |
| ETSI EN 303 645 | Objets connectés grand public |
| EN 18031-1/-2/-3 | Équipements radio — travaux réutilisables |
| ISO/IEC 27001 | Système de management de la sécurité de l’information |
| ISO/IEC 29147 et 30111 | Divulgation et traitement des vulnérabilités |
| ISO/IEC 18974 | OpenChain — assurance sécurité du logiciel libre |
Précision importante. Appliquer ces référentiels ne confère aucune présomption de conformité au sens du règlement tant qu’ils ne sont pas des normes harmonisées citées au JOUE. Ils facilitent la démonstration et fournissent des preuves réutilisables ; ils ne remplacent pas la démonstration.