Cybersécurité des services informatiques (partie SLAM)

L’essentiel

• Sécurité dès la conception : la sécurité est une exigence du projet, à chaque étape. Un défaut de conception (contrôle jamais prévu) ne se corrige pas par un code parfait ; un défaut d’implémentation est un contrôle prévu mais mal codé.
• Exigences de sécurité : issues des risques, règles de gestion, textes, contrat, référentiels et menaces ; chacune est précise, vérifiable, justifiée, identifiée (EXS-01…). Dans les récits utilisateur : critères d’acceptation négatifs et cas d’abus ; un récit n’est « prêt » qu’avec ses critères de sécurité.
• Modélisation des menaces : diagramme de flux de données (entités externes, traitements, stockages, flux) et frontières de confiance. STRIDE : usurpation (authenticité), falsification (I), répudiation (P), divulgation (C), déni de service (D), élévation de privilèges (autorisation). Évaluation gravité × vraisemblance (échelles de B3-01).
• Principes de conception sûre : moindre privilège (comptes de l’application compris : kermaint_app lit, ajoute, modifie, sans supprimer de table) ; défense en profondeur ; sécurité par défaut et échec sûr (liste blanche, refus par défaut) ; normaliser puis valider à la frontière, champs non prévus refusés ; erreurs génériques avec référence, détail au journal en temps universel ; secrets hors du code.
• Protection des données dès la conception et par défaut (art. 25 RGPD) : quantité, étendue, durée, accessibilité ; purge livrée avec le produit ; aucune donnée réelle hors production ; droits des personnes conçus comme des fonctions.
• Règlement sur la cyberrésilience (UE) 2024/2847 : produits sans vulnérabilité exploitable connue, configuration sécurisée par défaut ; application le 11/12/2027.
• Chaîne de développement : composer.lock versionné, SBOM, composer audit (code 1 en cas de problème), politique de délais 7 / 30 / 90 / 180 jours (critique, élevée, moyenne, faible) ; branche protégée, merge request, revue de code ; crochet pre-commit et détection de secrets dans le pipeline.
• Référentiels : OWASP Top 10:2025 (sensibilisation ; A06 conception non sûre, A10 mauvaise gestion des conditions exceptionnelles) ; OWASP ASVS 5.0.0 (mai 2025 ; 345 exigences, 17 chapitres ; niveaux L1, L2, L3 ; identifiant du type v5.0.0-2.2.1) ; ANSSI « Les essentiels — DevSecOps ».

Les définitions clés

• Exigence de sécurité : condition que l’application doit respecter pour protéger ses données et fonctions ; identifiant, formulation testable, justification, moyen de vérification.
• Frontière de confiance : limite entre deux zones de confiance différente ; ce qui entre est contrôlé, ce qui sort est limité.
• Validation par liste blanche : n’accepter que ce qui est explicitement attendu ; tout le reste est refusé.
• Nomenclature logicielle (SBOM) : inventaire de tous les composants, avec version, origine et licence.

Méthodes et bonnes pratiques

Rédiger les exigences : données et besoins DICP → acteurs et matrice des droits → modélisation des menaces → référentiel (ASVS) → identifiant, formulation, justification, vérification → rattacher aux récits et à la recette, faire valider.

Modéliser les menaces : dessiner le DFD → tracer les frontières → STRIDE élément par élément → une phrase par menace → G et V, classement → une mesure traduite en exigence, avec un responsable → mise à jour à chaque évolution.

Gérer les secrets : gestionnaire de secrets, un secret par environnement, rotation, démarrage refusé si un secret manque.

Vérifier la conformité à l’ASVS : périmètre et niveau justifié → exigences du niveau (non applicables motivées) → vérification → statut et preuve → traitement des écarts → synthèse (taux = conformes ÷ total : 5 ÷ 8 = 62,5 %).

Les 3 pièges à éviter

1. Contrôler les droits par une liste noire (« tous sauf le technicien ») : un nouveau profil obtient le droit en silence.
2. Supprimer un secret versionné « dans le commit suivant » : il reste dans l’historique ; rotation immédiate.
3. Prendre le Top 10 pour une norme de conformité : on vérifie avec l’ASVS, au niveau choisi, en citant la version.