Deux des dirigeants de la CISA (l'ANSSI états-unienne), ainsi que le directeur juridique d'Alphabet et le vice-président pour la confidentialité, la sûreté et la sécurité de Google, en appellent à une sécurité « par défaut » et « by design ». Objectif : empêcher autant que faire se peut les pirates de pouvoir exploiter les failles de sécurité.
« Les entreprises doivent-elles être tenues pour responsables des cyberattaques ? Le gouvernement américain pense que oui – et franchement, nous aussi », viennent d'écrire sur le Security Blog de Google Kent Walker, président des affaires mondiales et directeur juridique de Google et Alphabet, et Royal Hansen, vice-président de l'ingénierie pour la confidentialité, la sûreté et la sécurité.
Leur billet, intitulé « Le gouvernement américain estime que les entreprises devraient assumer davantage de responsabilités en matière de cyberattaques. Nous sommes d'accord. », fait écho à une longue tribune co-signée Jen Easterly (@CISAJen) et Eric Goldstein.
La première a longtemps œuvré à la NSA (y compris dans son unité d'élite Tailored Access Operations, ou TAO, pour Opérations d'accès sur mesure en français) avant d'être désignée directrice de la Cybersecurity and Infrastructure Security Agency (CISA) en 2021, le second est son directeur adjoint exécutif, chargé de protéger et de renforcer l'infrastructure critique du pays contre les cybermenaces.
Intitulée « Arrêtez de vous renvoyer la balle en matière de cybersécurité », sous-titrée « Pourquoi les entreprises doivent intégrer la sécurité dans les produits technologiques » et publiée le 1er février dans Foreign Affairs (la publication états-unienne de référence pour ce qui est des relations internationales, ndlr), leur tribune a le mérite de mettre les pieds dans le plat, estiment les responsables de Google :
« Les incitations au développement et à la vente de technologies ont éclipsé en importance la sécurité des clients. [...] Les Américains en sont venus, sans le vouloir, à accepter qu'il est normal que les nouveaux logiciels et dispositifs soient indéfendables "by design".
Ils acceptent que des produits soient mis sur le marché avec des dizaines, des centaines, voire des milliers de défauts. Ils acceptent que le fardeau de la cybersécurité pèse de manière disproportionnée sur les consommateurs et les petites organisations, qui sont souvent les moins conscients de la menace et les moins capables de se protéger. »
Faire de la sécurité « par défaut » et « by design »
« Nous pensons qu'ils ont raison », plussoient le directeur juridique et le vice-président à l'ingénierie de la confidentialité, la sûreté et la sécurité de Google : « il est temps pour les entreprises d'agir de leur propre chef et de collaborer avec les gouvernements pour contribuer à réparer un écosystème défectueux ».
Ils rappellent que les rançongiciels « se nourrissent de vulnérabilités préexistantes : logiciels non sécurisés, architectures indéfendables et investissements insuffisants en matière de sécurité », et trouvent « alarmant de constater que la source la plus importante de compromission est l'exploitation de vulnérabilités connues, des failles parfois non corrigées depuis des années » :
« N'oubliez pas que les opérateurs de ransomwares sophistiqués ont aussi des patrons et des budgets. Ils augmentent leur plus-value en exploitant des systèmes technologiques obsolètes et peu sûrs, trop difficiles à défendre. »
Or, « si les forces de l'ordre s'efforcent de traduire en justice les exploitants de ransomwares, elles ne font que traiter les symptômes du problème ».
Pour traiter les causes profondes, Easterly et Goldstein estiment qu'il faut s'attaquer aux sources sous-jacentes des vulnérabilités numériques, et donc mettre en avant les notions de sécurité « par défaut » et « by design » (ou « dès la conception », en français), comme le recommande également le National Cyber Security Centre (NCSC, l'ANSSI britannique) depuis 2018.
Leurs tribunes ne mentionnent pas le RGPD, pas plus que deux de ses principaux piliers, le « privacy by design » et le « privacy by default », mais on sent l'inspiration :
« Les gens méritent des produits sécurisés par défaut et des systèmes construits pour résister à l'assaut croissant des attaquants. La sécurité doit être fondamentale : intégrée, activée dès le départ, et non ajoutée après coup. En d'autres termes, nous avons besoin de produits sécurisés, et non de produits de sécurité. »
Faire en sorte que le chemin le plus sûr soit le plus facile
Les deux Googlers déplorent aussi que d'aucuns croient, « malheureusement, que les fonctions de sécurité sont encombrantes et nuisent à l'expérience des utilisateurs », alors que « ce n'est pas une fatalité ».
Ils sont persuadés, a contrario, que « nous pouvons faire en sorte que le chemin le plus sûr soit le plus facile et le plus utile pour les utilisateurs de nos produits », et prennent pour exemple leur approche de l'authentification multifactorielle, « l'un des contrôles les plus importants pour se défendre contre les attaques de phishing » :
« Depuis 2021, nous avons activé l'authentification à deux facteurs (2FA) par défaut pour des centaines de millions de personnes afin d'ajouter une couche supplémentaire de sécurité sur leurs comptes en ligne. Si nous avions simplement annoncé 2FA comme une option disponible à laquelle les gens pouvaient adhérer, elle aurait échoué comme tant d'autres fonctionnalités de sécurité. »
Leur approche, reposant sur des notifications dans l'application, « était si transparente et intégrée que beaucoup des millions de personnes que nous avons inscrites automatiquement n'ont jamais remarqué qu'elles avaient adopté 2FA ».
Concernant la sécurité « by design », les responsables de Google estiment que « nous devons tous passer de la réponse réactive aux incidents au développement de logiciels en amont ». Ils sont conscients que « cela exigera une approche totalement nouvelle de la manière dont les entreprises conçoivent leurs produits et services ».
Ils n'en estiment pas moins que « les développeurs doivent réfléchir en profondeur aux menaces auxquelles leurs produits seront confrontés, et les concevoir dès le départ pour résister à ces attaques ».
La force dépend du maillon le plus faible
Au-delà de ces notions de sécurité « par défaut » et « by design », ils en appellent à « une collaboration constante entre les partenaires des secteurs privé et public », qualifiée d' « essentielle » :
« Aucune entreprise ne peut relever le défi de la cybersécurité à elle seule. Il s'agit d'un problème d'action collective qui exige une solution collective, notamment une coordination et une collaboration internationales. »
S'ils se félicitent des nombreuses initiatives publiques et privées de partage des menaces, réponse aux incidents et coopération entre les services répressifs, ils déplorent qu' « elles ne s'attaquent qu'aux symptômes, pas aux causes profondes », et estiment que « nous pouvons faire mieux que de demander des comptes aux attaquants après coup » :
« Construire ce modèle et s'assurer qu'il peut évoluer nécessite une coopération étroite entre les entreprises technologiques, les organismes de normalisation et les agences gouvernementales. »
Ils en appellent à « une vision globale », et donc à une « coordination internationale », au motif que « les technologies et les entreprises ne connaissent pas de frontières ».
Cette « large coopération réglementaire en matière de cybersécurité permettra de promouvoir des principes de sécurité par défaut pour tous », si et seulement si elle ne se limite pas aux seules nations « technologiquement avancées ». Relever le niveau global, à l'international, serait en effet « bien plus rentable » :
« Étant donné la nature interdépendante de l'écosystème, notre force dépend de notre maillon le plus faible. Cela signifie que le renforcement des normes cybernétiques au niveau mondial améliorera également la résilience des États-Unis. »
Ils sont conscients que « les logiciels auront probablement toujours des défauts », et que ces mesures n'empêcheront pas les pirates de pirater, « mais nous pouvons commencer par sécuriser les bases, corriger les risques de sécurité les plus flagrants et trouver de nouvelles approches qui éliminent des catégories entières de menaces ».
« La sécurité est un processus, pas un produit »
Un constat qui fait écho à celui formulé par Bruce Schneier, cryptographe de renom et réputé vulgarisateur des questions de cybersécurité, qui a beaucoup écrit sur la responsabilité des éditeurs de logiciels et qui, dès l'an 2000, expliquait que « la sécurité est un processus, pas un produit » :
« Les produits offrent une certaine protection, mais la seule façon de faire des affaires efficacement dans un monde non sécurisé est de mettre en place des processus qui reconnaissent l'insécurité inhérente aux produits. L'astuce consiste à réduire votre risque d'exposition, quels que soient les produits ou les correctifs. »
Il déplorait alors, et lui aussi, que « les systèmes se brisent, les vulnérabilités sont rapportées dans la presse, et pourtant de nombreuses personnes font confiance au prochain produit, à la prochaine mise à jour ou au prochain correctif ».
À l'époque, Schneier déplorait le fait qu' « il y a beaucoup moins de gens qui y prêtent attention qu'il ne le faudrait », et que « personne ne fait attention parce que personne n'est obligé de le faire ». Et ce, alors que « l'énorme besoin de produits de sécurité numérique nécessite un énorme besoin de personnes pour les concevoir, les développer et les mettre en œuvre » :
« La plupart des produits qui font appel à la sécurité ne sont pas conçus par des personnes compétentes en la matière. Même les produits spécifiques à la sécurité sont généralement conçus et mis en œuvre par des personnes qui n'ont qu'une expertise limitée en matière de sécurité. »
Et ce, d'autant que « les fabricants de logiciels n'ont pas à produire un produit de qualité, car ils ne peuvent être poursuivis s'ils ne le font pas », et qu'ils ne sont pas non plus « forcés de fabriquer des produits réellement sécurisés, car personne ne peut les poursuivre s'ils font un tas de fausses déclarations de sécurité ».
Planter un énorme pieu en espérant que l'ennemi fonce dessus
La lecture, 23 ans après, des conseils et exemples de processus qu'ils prodiguaient afin d'améliorer la sécurité des réseaux laisse songeur, comme si rien ou presque n'avait évolué depuis, quand on voit les failles de sécurité, tactiques, techniques et procédures les plus exploitées dans les cyberattaques :
- « Surveillez les vulnérabilités connues. La plupart des attaques réussies en matière de sécurité réseau ciblent des vulnérabilités connues pour lesquelles il existe déjà des correctifs. Pourquoi ? Parce que les administrateurs réseau n'ont pas installé les correctifs ou parce que les utilisateurs ont réinstallé les systèmes vulnérables.
- Surveillez en permanence les produits de votre réseau. Presque tout ce qui se trouve sur votre réseau produit un flux continu d'informations de vérification : pare-feu, systèmes de détection d'intrusion, routeurs, serveurs, imprimantes, etc. La plupart de ces informations ne sont pas pertinentes, mais certaines d'entre elles contiennent des empreintes d'attaques réussies. »
Il appelait en outre à limiter les privilèges, sécuriser le maillon le plus faible (au motif que « trop souvent, les mesures de sécurité informatique reviennent à planter un énorme pieu dans le sol en espérant que l'ennemi lui fonce dessus », plutôt que de « construire une large palissade »), assurer une défense en profondeur, adopter la simplicité et impliquer les utilisateurs :
« Gardez les choses aussi simples que possible. La sécurité est une chaîne ; le maillon le plus faible la brise. La simplicité signifie moins de maillons.
Faites participer les utilisateurs. La sécurité ne peut pas fonctionner si les utilisateurs ne sont pas de votre côté. Les attaques d'ingénierie sociale sont souvent les plus dommageables de toutes les attaques, et on ne peut s'en défendre qu'en éduquant les utilisateurs. »
Commentaires (13)
#1
Si encore du point de vue infrastructure mal sécurisée (composants exposés, RBAC YOLO, etc) la position s’entend et le by design est possible à mettre en oeuvre (compliance policies, pentests, etc), du côté du dev ça devient un voeu pieu de mon point de vue.
A moins de développer l’entièreté du logiciel à la maison, en testant rigoureusement tous les composants et en l’auditant régulièrement, c’est difficile d’imaginer la “security by design” dans un monde où un logiciel n’est qu’un gloubi-boulga de libs disponibles sur le Web à la maintenance et sécurisation (voire sabotage de son propre auteur par militantisme) hasardeuses assemblées pour faire tomber en marche un produit…. J’ai des doutes.
Sans oublier le côté organisationnel. De mon expérience, je peux vous assurer que la sécurité et les améliorations d’architecture, ce sont les premiers trucs qui passent à la trappe à la moindre restriction budgétaire versus les évolutions métier. Sur ce point là, une meilleure responsabilisation serait la bienvenue car lorsque j’évoque ce point avec les différents projets que je côtoie, ça leur en touche une sans bouger l’autre.
…. Et le maillon le plus faible de la chaîne : l’utilisateur final. Baladez-vous dans un magasin et comptez le nombre de PC vendeurs déverrouillés avec le progiciel métier ouvert sur une session active et vous comprendrez qu’il ya du taff.
#1.1
Je plussoie complètement, sur la partie infra cela reste possible, sur la partie dev, c’est clairement ce que tu décris.
#1.2
+1 mais l’éducation est possible. ma femme a plusieurs campagnes de pishing faite par sa boîte pour tester ses employés (qui sont en full remote c’est pour ça). c’est bien foutu je trouve, et ça va jusqu’à des fausses pannes de VPN avec envoi de liens bizarres pour se connecter sur Teams et consorts.
dans la mienne on prévoit des sessions windows/avaya/vidéo génériques pour pas compliquer la vie des gens… bref.
#1.3
Alors ça… Les entreprises sont souvent elles-mêmes à l’origine d’une partie des problèmes de phishing de leurs employés.
Quand les différents services de la boîte utilisent des prestataires externes pour tout et n’importe quoi, les utisateurs finissent par avoir l’habitude de prendre en compte et cliquer sur des liens externes pour la newsletter, l’outil RH, une formation, un sondage commandé par la direction, etc, etc… Et le jour où arrive un phishing on va leur tomber dessus parce que “mais vous auriez dû voir que ça venait d’un domaine externe”
“Ouais, comme tout le reste en fait…”
#1.4
surtout lorsque le preta externe s’est fait péter et t’envoie un lien foireux !
#2
La sécurité n’est pas un processus mais plusieurs processus qui s’appliquent à des facettes différentes des activités d’une entreprise.
Les premiers processus où la majorité des entreprises pour lesquelles j’ai travaillé échouent, c’est la gestion de risque et la gestion de la dette technique: et quand ces processus ne sont pas correctement implémentés, les trous se multiplient sans jamais être comblés, ce qui peut prendre des proportions absolument dramatiques assez rapidement.
Par exemple, si la gestion de vulnérabilités ou des mises à jour n’est pas correctement chapeautée par une gestion de risque correcte capable de chiffrer le risque financier de ne pas mettre à jour, impossible de justifier les investissements pour lancer un projet de modernisation sur une application ancienne et coincées dans des dépendances vulnérables.
#2.1
Oui c’est effectivement un ensemble de process qui doit s’appliquer à chaque élément de la chaîne, je n’aurais pas dit mieux
Les 3⁄4 des dossiers d’architecture que je traite ont tous les mêmes parents pauvres : le SLA (avec le SLO derrière encore plus souvent oublié), RTO, RPO, tous sont décrits dedans par le projet mais ils ne sont jamais concrètement évalués ni même remis en cause. Ils n’ont que la vision métier, soit généralement uniquement le D de la matrice CID pour s’assurer que l’utilisateur final aura accès au produit. Et encore, même le D est pauvrement évalué : tirs de perf, chaos testing, etc, tout ça c’est “oué on verra” (par contre pour venir chouiner post MEP, là y’a du monde).
Et d’ordre général, le projet va formuler une demande délirante de disponibilité (genre supérieure à celle du cloud provider, allez comprendre) et quand il reçoit le devis de l’infra et des moyens mis en oeuvre pour y parvenir, d’un coup le besoin se voit réévalué…
L’éducation en entreprise s’est bien développée ces dernières années, il faut le souligner. J’ai moi-même participé à des sessions de sensibilisation type “enquête donnes personnelles” et campagnes d’intrusion IRL organisées par les services sécurité de différents clients. Le souci de l’exemple que je donne avec les PC ouverts en magasin, c’est juste des pratiques auxquelles un vendeur ne pensera jamais car il est accaparé par 50 personnes et ça on peut pas lui en vouloir (c’est l’effet pervers de l’informatisation du retail… La pénibilité a augmenté car le personnel peut être amené à être plus polyvalent qu’avant). L’une des solutions de remédiation étant de verrouiller/déverrouiller le poste avec le badge mais ça demande un peu plus de moyens (et surtout éviter aussi de bloquer le vendeur si le système ne passe pas, et donc lui donner une solution de repli).
Bref, tout ça c’est pas simple
#3
Rien surprenant venant de Google. Le privacy by design est à l’opposé de leur business model.
Par contre l’exemple du 2FA est en ligne avec leur besoin de se rendre indispensable, et collecter de la (meta)donnée au passage.
Un vrai cheval de Troie.
#4
Il serait intéressant que ce paradigme s’applique, si possible, au chiffrement par défaut des e-mails. Parce que, pour l’instant, si on veut le mettre en œuvre, c’est tout sauf simple.
#5
Hmm… non.
Les produits étant multi-usages (et souvent utilisés pour faire tout et n’importe quoi), il est impossible pour l’éditeur du produit de penser à tous les cas d’usage et donc à tous les cas de vulnérabilité.
Pour exemple l’affaire récente de KeyPass qui est vulnérable si un attaquant modifie un fichier de configuration: a qui la faute ? KeyPass qui utilise le fichier de config (by design), ou l’OS qui laisse la possibilité à l’utilisateur de modifier le fichier (by design aussi) ?
Bref, si chaque produit doit se sécuriser lui-même en partant du principe que les autres produits sont des vecteurs d’attaque on finit par avoir des sécurités en double ou triple. Ca devient vite le bazar à configurer… Et donc les gens finissent par retirer des sécurités à gauche à droite jusqu’à ce que ça fonctionne. Le célèbre “vas-y, désactive l’antivirus/firewall pour voir si ca marche” ou “lance le programme en root/admin pour voir”.
Ce dont nous avons besoin ce sont des produits
sécuriséssécurisables.C’est à dire une interface/API a peu près standard qui permet à un produit de sécurité de faire le job pour lequel il est conçu : sécuriser l’ensemble d’une chaine de traitement.
#6
Oui c’est d’abord pour récupérer de la metadata (faire du cash), et il se trouve que en plus ça sécurise : c’est clairement l’ordre de cette décision.
#7
#7.1
J’étais aussi parti du principe qu’on se mettait dans le cas où on voudrait sécuriser by design et non utiliser des solutions de sécurité. Ce qui est le postulat proposé par l’article et qui est, de mon point de vue, une posture idiote puisque ces deux notions ne doivent pas s’opposer mais se compléter.
Donc oui, dans le cas où les deux concepts sont mis ensemble dans la chaîne de production logicielle, on teste et analyse ses dépendances pour s’assurer qu’on a pas des versions trouées ou frauduleuses (cryptokikoolol intégré, extraction de données, backdoor, activisme…). C’est typiquement le rôle de l’étape software composition analysis. L’un des aspects de la SCA justement c’est de fournir une sorte de réputation des libs utilisées, que ce soit technique mais aussi de son auteur. Les cas l’année dernière de libs nodejs sabotées par leurs auteurs pour emmerder l’utilisation en Russie a justement été intégré dans pas mal de solutions du marché. Et avec le bordel des dépendances transitives, c’est devenu indispensable pour savoir cartographier ce foutoir.
Comme dit précédemment, la sécurité dans le développement fait partie intégrante de la chaîne de valeur et s’applique à chaque maillon. Il y a donc les contrôles avant (libs, analyse statique de code, etc), pendant (au build), et à l’utilisation (DAST, pentest, etc). Perso quand j’intègre une lib dans un script, ou même une Action dans GitHub Actions, le premier truc que je vérifie c’est de quand date le dernier commit du repo. Si celui-ci date de plusieurs mois et que les issues s’accumulent, c’est que ça sent le projet plus maintenu. Et donc à éviter.
Pour l’aspect financier on est d’accord, et l’analogie des bocaux qu’on voit régulièrement sur le Web est aussi toujours pertinente : mon budget sécu avant une fuite de données, mon budget sécu après, coût de la fuite de données.