Points clés
- Des contrôles de conservation incapables de respecter la politique sans ingénierie sur mesure Quand un produit impose des réglages par défaut faibles autour des renseignements personnels, l’EIVP en aval devient une négociation avec la feuille de route d’un fournisseur.
- Essayez de l’exploiter en sécurité avec seulement les réglages par défaut documentés.
- Les équipes de plateformes internes sont mesurées sur l’adoption des réglages par défaut sûrs.
Le mode de défaillance silencieux de la sécurité d’entreprise
Si vous avez déjà hérité d’un parc d’appliances, de connecteurs SaaS ou de « plateformes d’entreprise », vous connaissez ce scénario :
- Le produit est livré avec des réglages par défaut pensés pour la commodité
- L’équipe de sécurité du client passe des mois à le durcir
- Certains contrôles ne peuvent pas être activés sans briser les configurations prises en charge
- Un rapport de brèche dira plus tard « mauvaise configuration »
- Tout le monde fera semblant que la cause profonde est née dans la fenêtre de changement du client
Parfois, le client a vraiment failli. Souvent, le produit a fait de l’exploitation sûre le chemin difficile et de l’exploitation risquée le chemin par défaut. Ce n’est pas un partage équitable du travail.
Le programme Secure by Design de la CISA existe pour rééquilibrer ce partage.
Sources primaires à lire directement :
- Carrefour : https://www.cisa.gov/securebydesign
- Guide conjoint PDF (mise à jour d’oct. 2023) : Secure by Design — Shifting the Balance of Cybersecurity Risk
- Page de ressources : ressource Secure-by-Design
Ce que la CISA demande vraiment aux fabricants
Les principes de sécurité des produits du guide n’ont rien de mystérieux :
- Assumer la responsabilité des résultats de sécurité des clients
- Adopter une transparence et une obligation de rendre compte radicales
- Donner l’exemple à partir du sommet
Le premier principe est celui que je cite dans les rencontres avec les fournisseurs. Le langage de la CISA est direct : le fardeau de la sécurité ne devrait pas reposer uniquement sur le client; les fabricants devraient faire évoluer leurs produits pour que les clients obtiennent des résultats plus sûrs sans configuration héroïque.
C’est une autre économie morale que « nous fournissons les serrures; à vous de trouver quelles portes existent ».
Assumer les résultats plutôt qu’assumer le blâme
En exploitation, « assumer » doit désigner des choix de conception, pas des déclarations d’excuses après les incidents.
Exemples concrets de responsabilité assumée par le fabricant :
- Aucun mot de passe par défaut sur tout ce qui peut joindre un réseau
- Des réglages par défaut sûrs qui favorisent le moindre privilège et le chiffrement activé
- Une MFA qui va de soi, pas une option haut de gamme enfouie derrière des services professionnels
- Des langages à sûreté de la mémoire / l’élimination de classes de bogues là où c’est faisable, avec une discussion publique des classes de CVE corrigées à la racine
- Des guides de durcissement qui rétrécissent avec le temps parce que les réglages par défaut se sont améliorés — pas qui s’épaississent en romans
- Des SBOM et une réponse aux vulnérabilités qui présument que les clients seront frappés par vos défaillances de dépendances
- Des auto-attestations de pratiques de type SSDF pour que les acheteurs puissent comparer autre chose que des adjectifs de marketing
Le guide de la CISA détaille des tactiques comme la modélisation des menaces qui inclut la façon dont les produits sont attaqués dans la nature, les essais sur le terrain, la réduction de la dépendance au durcissement par le client, la publication des tendances tirées des vulnérabilités passées et le maintien des SBOM. Si vous ne retenez qu’un thème : faites du chemin sécuritaire le chemin facile.
Pourquoi cela touche directement le travail de protection des données
Les équipes de vie privée et de protection des données vivent quotidiennement avec les modes de défaillance des fabricants :
- Une journalisation qui capte des renseignements personnels par défaut et offre la rédaction comme module payant
- Des consoles d’administration incapables d’imposer une MFA résistante à l’hameçonnage pour tous les rôles privilégiés
- Des bascules « analytiques » qui partagent les données largement à moins que le client ne trouve la page 19 d’un PDF
- Des fonctions de chiffrement qui existent mais sont désactivées à moins d’acheter un palier supérieur
- Des contrôles de conservation incapables de respecter la politique sans ingénierie sur mesure
Quand un produit impose des réglages par défaut faibles autour des renseignements personnels, l’EIVP en aval devient une négociation avec la feuille de route d’un fournisseur. Secure by Design, c’est l’argument selon lequel le contrôle aurait dû être en amont.
Secure by Design, c’est aussi Secure by Default
On sépare parfois les deux formules. En pratique, elles voyagent ensemble.
- Par conception : la sécurité est une exigence produit de premier ordre dans l’architecture et le développement, pas une liste de vérification d’avant-lancement
- Par défaut : l’état à la sortie de la boîte est sûr pour un déploiement réaliste, pas pour une démo de laboratoire
Un produit peut avoir une élégante architecture de sécurité et être quand même livré avec des interfaces de gestion ouvertes et des privilèges tentaculaires. Cela échoue au test des résultats pour le client.
Ce que les acheteurs devraient exiger (utilisable dans les appels d’offres)
Je n’ai pas besoin que les fournisseurs récitent les slogans de la CISA. J’ai besoin d’artefacts :
Dossier de preuves
- Modèles de menaces du produit (même à haut niveau)
- Posture de configuration par défaut et ce qui est activé ou non à l’installation
- Matrice de prise en charge MFA/SSO pour tous les chemins privilégiés
- Politique de divulgation des vulnérabilités et caractéristiques de délai moyen qu’ils s’engageront à publier
- Mode de livraison des SBOM et cadence de mise à jour
- Historique d’élimination d’une classe de problèmes (pas seulement le correctif du cas nº 47)
- Déclaration claire des responsabilités du client par rapport à celles du fabricant
Leviers contractuels
- Réglages de sécurité par défaut documentés comme base garantie
- Délais de notification pour les problèmes critiques
- Droit de recevoir les SBOM et les artefacts d’attestation
- Engagements de feuille de route pour les schémas d’insécurité connus (par exemple, le retrait de l’accès administrateur par mot de passe seul)
Essais opérationnels
- Installez en laboratoire sans le « script de durcissement recommandé » de l’ingénieur commercial. Observez ce qui est exposé.
- Essayez de l’exploiter en sécurité avec seulement les réglages par défaut documentés. Chronométrez l’écart. Cet écart, c’est votre coût total de possession caché.
Où la pensée CISSP s’aligne
Cela correspond proprement à :
- Architecture et ingénierie de la sécurité — réglages par défaut sûrs, moindre privilège, défense en profondeur intégrée
- Risque de la chaîne d’approvisionnement — la qualité du fabricant comme risque lié aux tiers
- Gouvernance — obligation de rendre compte de la sécurité des produits au niveau du conseil (le « donner l’exemple à partir du sommet » de la CISA)
- Sécurité du développement logiciel — pratiques alignées sur le SSDF, modélisation des menaces, stratégies de sûreté de la mémoire
Le point de vue de l’examen insiste sur l’intégration de la sécurité dès la conception. La contribution de la CISA est d’économie politique : qui paie le risque résiduel quand la sécurité n’a pas été intégrée — les opérations du client, ou la gestion de produit du fabricant?
Les objections des fabricants que vous entendrez (et mes réponses)
« Chaque environnement est différent. » Vrai. Les réglages par défaut ne devraient quand même pas être trivialement exploitables. La complexité n’excuse pas une posture universellement faible.
« Les guides de durcissement sont la norme de l’industrie. » Les guides sont acceptables comme aide en couches. Ils sentent mauvais quand ils sont requis pour atteindre un minimum.
« Il nous faut de la convivialité pour la première installation. » Convivialité et réglages par défaut sûrs sont un problème de conception, pas une paire mutuellement exclusive. Une administration ouverte à la sortie de la boîte avec un mot de passe bien connu, ce n’est pas de la convivialité; c’est de la négligence avec un assistant de bienvenue.
« Les clients d’entreprise exigent de la flexibilité. » La flexibilité peut exister derrière des choix explicites et authentifiés — pas comme une insécurité silencieuse.
La TI interne est aussi un fabricant
C’est la partie que les praticiens esquivent. Si votre équipe livre des plateformes internes, des API, des images de machines ou des outils d’analyse au reste de l’entreprise, vous êtes dans le rôle du fabricant.
Appliquez les mêmes principes à l’interne :
- Réglages par défaut sûrs sur les applications internes
- Aucun mot de passe partagé de contournement d’urgence dans les wikis
- Des schémas d’authentification et d’autorisation que les équipes produit héritent facilement
- Des chemins balisés plus sûrs que les chemins de la TI fantôme
Secure by Design échoue si les équipes de sécurité ne l’externalisent que vers les fournisseurs pendant que les outils internes restent « temporaires » pendant trois ans.
Friction opérationnelle à l’intérieur des organisations clientes
Même de bons produits Secure by Design créent du travail :
- Migrer hors des modes hérités non sécuritaires
- Rebâtir les manuels d’installation qui présumaient des réglages par défaut ouverts
- Recycler le personnel de soutien qui utilisait des fonctions de commodité non sécuritaires
- Mettre à jour le contenu de détection quand la surface d’attaque rétrécit ou se déplace
Faites ce travail de bon cœur. Il coûte toujours moins cher que des contrôles compensatoires éternels.
Autre friction : le marketing revendiquera « Secure by Design » sans preuve. Votre travail est de demander les artefacts énumérés ci-dessus et de passer votre chemin quand la réponse est un logo sur un kiosque de conférence.
Une grille d’évaluation concrète pour le prochain cycle de fournisseurs
Notez chaque fournisseur critique de 0 à 2 sur :
- Réglages par défaut sûrs à l’installation
- Durcissement de l’accès privilégié sans héroïsme
- Transparence (SBOM, analyse de l’historique des vulnérabilités, engagements publics)
- Capacité à éliminer des classes de problèmes
- Signaux d’implication de la direction (pas seulement un alias de courriel d’un dirigeant)
- Alignement du langage contractuel avec les résultats de sécurité
Utilisez la note dans les décisions d’attribution. Si la sécurité ne peut pas influer sur l’attribution, vous faites du théâtre.
À quoi ressemble le « bien » un an après avoir pris cela au sérieux
- Le nombre de pages des guides de durcissement chute pour les produits stratégiques
- Moins d’exceptions d’urgence pour « impossible d’activer la MFA »
- Les revues de risque fournisseur incluent des preuves de conception, pas seulement des PDF de tests d’intrusion
- Les équipes de plateformes internes sont mesurées sur l’adoption des réglages par défaut sûrs
- Les bilans d’incidents distinguent l’erreur du client de la dette prévisible du fabricant
Sources
- Carrefour CISA Secure by Design : https://www.cisa.gov/securebydesign
- Guide conjoint PDF : https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf
- Fiche de ressources de la CISA (résumé des principes et contexte de mise à jour) : https://www.cisa.gov/resources-tools/resources/secure-by-design
À retenir et à appliquer
CISA Secure by Design est un transfert de responsabilité : les fabricants assument les résultats de sécurité, pas seulement la livraison de fonctions, et les clients devraient acheter — et bâtir — en conséquence. Les trois principes (responsabilité, transparence, leadership) ne comptent que quand ils changent les réglages par défaut, les feuilles de route, les contrats et les normes des plateformes internes. Cessez de célébrer le durcissement héroïque comme le sommet de la maturité. Le sommet, c’est un produit qui n’a pas besoin d’héroïsme pour être sûr.