Dix agences (dont la CISA, le FBI et la NSA) de sept pays (États-Unis, Royaume-Uni, Australie, Canada, Nouvelle-Zélande, Allemagne et Pays-Bas, mais pas la France) ont cosigné un appel à l'intention des développeurs de logiciels afin de garantir que leurs produits soient sécurisés à la fois dès la conception (« by design ») et par défaut, d'alléger le fardeau de la sécurité pour le client et de réduire le risque d'un incident de sécurité, rapporte Le Monde Informatique.
« Historiquement, les développeurs de technologies se sont contentés de corriger les vulnérabilités découvertes après que les clients ont déployé les produits, exigeant d'eux qu'ils appliquent ces correctifs à leurs propres frais. Ce n'est qu'en incorporant des pratiques de sécurité dès la conception que nous mettrons fin au cercle vicieux de création et d'application de correctifs », indique le document d'orientation.
L'objectif serait d'éviter aux clients de devoir effectuer en permanence des contrôles, mais également de limiter les dégâts sur leurs systèmes afin d'atténuer les risques de cyber-intrusions.
Le document qualifie de produits sécurisés « dès leur conception » ceux pour lesquels la sécurité est « un objectif commercial essentiel, et non une simple caractéristique technique ». De leur côté, les produits sécurisés « par défaut » sont ceux qui ne nécessitent que peu ou pas de changements de configuration et dont les fonctions de sécurité sont disponibles sans coût supplémentaire « dès leur sortie de l'emballage ».
Les agences signataires « recommandent aux sociétés de tenir leurs éditeurs responsables de la sécurité de leurs produits », relève notre confrère. Le document suggère ainsi aux services IT d’ « exiger dans leurs politiques une évaluation de la sécurité des logiciels des fabricants avant leur achat, et de donner à ces services les moyens de s'opposer à leur mise en œuvre si nécessaire » :
« Les décisions de l’entreprise d'accepter les risques associés à des produits technologiques spécifiques doivent être formellement documentées, approuvées par un cadre dirigeant, et régulièrement présentées au conseil d'administration. »
Les agences ayant collaboré à la rédaction de ce guide sont : le Centre australien de cybersécurité (Australian Cyber Security Centre, ACSC) ; le Centre canadien de cybersécurité (Canadian Centre for Cyber Security, CCCS) ; l’Office fédéral allemand de la sécurité des technologies de l’information (Bundesamt für Sicherheit in der Informationstechnik, BSI) ; le Centre national de cybersécurité des Pays-Bas (Netherlands’ National Cyber Security Centre, NCSC-NL) ; le centre d'alerte et de réaction aux attaques informatiques de Nouvelle-Zélande (New Zealand’s Computer Emergency Response Team New Zealand, CERT NZ) et le Centre national pour la cybersécurité de Nouvelle-Zélande (National Cyber Security Centre, NCSC-NZ) ; le centre national pour la cybersécurité du Royaume-Uni (National Cyber Security Centre, NCSC-UK) ; la CISA (Cybersecurity and Infrastructure Security Agency), le Federal Bureau of Investigation (FBI) et l’Agence nationale de la sécurité (National Security Agency, NSA) des États-Unis.
Commentaires (43)
#1
C’est bizarre que l’ANSSI ne soit pas partenaire de cet appel.
#1.1
Je me suis fait la même réflexion. Après les problèmes de non sécurités sont encore plus responsabilités en Europe RGPD oblige.
#1.2
T’as les US en gros quand même.
Ca sent plus le “bon, les gars, les russes et les chinois ont commencé a nous tomber dessus, on est pas bon, donc tout le monde en ordre de marche pour corriger le tire !”
#1.3
Cela ne me semble pas bizarre que la France pays latin soit exclu du monde anglo saxon et nordique à majorité protestante.
xc’ est d’ ailleurs assez systématique comme vous l’ aurez remarqué dans l’ affaire des sous marins avec l’ Australie.
La langue, la religion, la mentalité ont des rôles bien spécifiques dans les alliances qui se nouent.
Quand on se parle, il faut aussi pouvoir se comprendre sans se parler ce qui ne peut pas être le cas avec une histoire religieuse, un climat, une langue différente.
Je rappelle que les américains voulaient juste faire de la France une colonie américaine à la fin de la seconde guerre mondiale et que sans De Gaulle ce serait le cas.
Finalement Sarkozy nous a remis dans l’ OTAN et les présidents français suivants ont parfait le souhait américain.
il n’ y a eu que Chirac pour s’ être opposé à l’ idée suprêmaciste américaine.
#2
Ça fait très promo Five Eyes & friends tout de même
#3
Tout ça n’est pas clair. “Les développeurs” c’est qui, les éditeurs, ou les personnes qui écrivent le code ?
Parce que, pour ce qui est d’écrire le code, faudrait d’abord que les demandes ne changent pas tout les trois jours, et que du temps soit alloué pour s’occuper de la dite sécurité…
#4
Et pis aussi, il faudrait que les contraintes de sécurité soient présentes ET pertinentes dans les cahiers des charges … figés !
#4.1
On peut aussi imaginer que l’éditeur soit responsable de la sécurité qu’il développe et en parle au client.
Si le garagiste change tes pneus et tes freins tu t’attends à ce que ça fonctionne et pas à mourir au premier virage.
Autrement dit, la sécurité initiale dans Windows peut être renforcée par exemple, pas de compte administrateur au quotidien par exemple… Sauf que de nombreux ne fonctionnent pas s’ils ne sont pas avec des droits administrateurs. Il y a déjà tout un travail de base ici.
Et puis les projets à millions de Capgemini et autres avec l’argent publique devraient aussi être
sécurisés par designfinis avant d’être livrés.#4.2
+1 sur le compte admin dans Windows
Ce que je lis dans cette annonce c’est la demande de la suppression dans les CLUF des clauses de garantie de sécurité.
#4.3
Cap G. ? … les copy-cat Accenture en moins bien ?
Pour avoir bossé dans des grands comptes à côté des équipes CG, ben, je n’en garde pas un souvenir impérissable. Les gars, même de bonne volonté, sont tenus de servir les objectifs de rentabilité même si cela doit mettre en péril le logiciel et l’exploitation du client. Après tout, le plus important c’est le paiement de la prestation.
Une fois, un chef de projet CG a expliqué en réunion (avec toute l’armée mexicaine des acteurs projet) que les erreurs d’exécution des livrables étaient de la responsabilité de l’opérateur et non de l’éditeur. A ce niveau là, je ne sais quoi répondre. Le plus grave, c’est que ce genre de comportement est commun dans les équipes CG.
Pour en revenir au sujet, en regardant côté Windows et la sécurité by design, disons qu’on part de très loin. Entre l’héritage DOS et la mauvaise utilisation des capacités du noyau NT, on en est au point où il est raisonnable de se poser la question si un changement d’OS ne résoudrait pas la majorité des problèmes identifiés.
#5
C’est bizarre que le FBI signe ça, alors qu’il demande régulièrement à abaisser la sécurité des systèmes et des applications.
#6
Et si en roulant tu te prends un clou dans le pneu, c’est la faute du garagiste ?
#7
C’est l’équivalent de l’appel contre la faim dans le monde version IT ?
Au-dela des grands principes, j’aimerais bien que ces agences proposent des ébauches de solution et non un voeux pieux, partagé je pense par toute l’industrie.
Ça va ouvrir la porte à pas mal de question, de la simple augmentation des prix des solutions pour y adjoindre les produits de sécurité complémentaires, à la responsabilité en cas d’environnement hétérogènes (solution d’un éditeur A, solution de sécurité d’un éditeur B), en passant par la question devoir de moyen vs devoir de résultat (surtout pour les plus petits éditeurs)
Vu que c’est vendredi : une fois que toutes ces agences de sécurité auront réussi à vaincre le méchant lobby des failles de sécurité, combien de temps faudra-t-il avant un nouvel appel de ces mêmes acteurs pour leur garantir une backdoor “by design et par défaut” ?
#8
Encore des tenants du yakafokon mais qui n’ont aucune idée du comment.
Vu le nombre de briques utilisées pour développer un logiciel, ça va être compliqué. Par contre, ça va faire la fortune des évaluateurs, sans pour autant garantir la sécurité des utilsateurs, car même avec la meilleure volonté et tous les moyens nécessaires, on est jamais à l’abri d’une faille.
#8.1
« by design » est une autre façon de dire plus simple et plus léger, ce que les logiciels aujourd’hui ne sont pas.
Mais bon, faut une expression qui claque.
#9
Un lien avec ce précédent article ?
https://www.nextinpact.com/article/71029/nous-avons-besoin-produits-securises-et-non-produits-securite
#10
“Le document qualifie de produits sécurisés « dès leur conception » ceux pour lesquels la sécurité est « un objectif commercial essentiel, et non une simple caractéristique technique ».”
Si la sécurité doit se retrouver ravalée au rang d’objectif commercial, on ne sera pas le cul sorti des ronces! On peut vendre tout un tas de trucs comportant les mots clef magiques (secure-boot, tpm…) mais avec des gouffres de sécurité qui rendent tout cela caduque pour qui prendra un peu de temps d’exploration.
Puis c’est pas comme si certains équipement d’infrastructures jugées vitales n’avaient pas quelques contraintes. Genre, pour pouvoir être vendus aux USA, fournir tout les sources/outils de build etc… bref tout le nécessaire permettant de refaire un load identique (disons aux en-têtes/dates de compilation près) sur des serveurs localisés aux USA et accessibles à la NSA.
Hors de ce cadre, de toutes manières, les contraintes de production/sav ou d’upgrade laissent fatalement quelques possibilités (niveau login parfois, outils de signatures de binaires embarqués presque toujours…) plus ou moins aisées pour qui prends le temps de les chercher.
#11
Sans critiquer l’initiative (bien au contraire), mais quand on lit ça :
… avouez qu’il y a de quoi rire. C’est quand même extrêmement naïf, même les applis “secure by design” ne sont pas exemptes de failles, espérer que les clients/utilisateurs n’aient plus à se soucier de patcher paraît illusoire.
#12
Étape suivante : les dix agences afficheront sur les produits - qu’elles auront expertisés au préalable - un logo «Garanti sécurisé “by design” par la CISA, le FBI et la NSA, etc. » Les clients seront rassurés à 100%.
Sans rire, cette sécurisation est orthogonale à la raison d’exister des dites agences. Rien que ça pose problème.
#13
Vivement un nouveau label qui oblige de souscrire à ces solutions (et qui feront la fortune de l’éditeur).
#14
Et c’est ceux qui ont créé AN0M qui le disent.
#15
Il faudrait quand même qu’ils se décident au FBI, la sécurité, c’est bien ou pas ?
https://arstechnica.com/tech-policy/2023/04/meta-plan-to-make-facebook-messages-more-secure-faces-law-enforcement-backlash/
#16
Tous les jours je signe si on me demande sérieusement de faire du sécurité “by design”. Le problème c’est que dans la réalité, déjà il faut des compétences, mais aussi et surtout le temps et le budget pour le faire.
C’est le même cinéma à chaque fois, on part d’un bon principe, 6 mois et 17 changements de direction plus tard, le projet prend l’eau de partout, faut sortir absolument un livrable, hop à la trappe toutes les belles promesses, on patchera “plus tard”.
#17
En 17 ans de développement logiciel, je n’ai pas la sensation que les développeurs dans leur généralité soit à blâmés.
Ils font ce qu’il peuvent avec les moyens que l’on leurs donnent.
Par contre des chefs de projets qui ne savent pas trop ce qu’ils font à par dire “oui” aux donneur d’ordres, ça j’en ai croisé beaucoup.
Que l’on donne le temps et les moyens aux développeurs de faire correctement leur job et la qualité du produit (comme l’ambiance dans les équipes) n’en sortira que renforcé.
Oui le développement logiciel coûte chère, et cela à toujours été le cas!
La compression des coûts à des limites qui ensuite font baisser la qualité.
Et ce n’est pas de comparer le coût d’un développeur Français / Allemand / … avec un Indien qui changera quoi que ce soit; Pour rappel même Microsoft qui à fait ce mouvement par le passé, à finir par rendre Microsoft India indépendante (c’est un partenaire Microsoft Platinium de Microsoft US) et ne lui commande que les traductions de Windows tellement le résultat était catastrophique (mais peu chère).
Et ceux qui seraient tenté de parler de la Chine, les salaires des ingénieurs se sont envolés ces dernières années et frôles ceux des californiens; Autrement dits les Français commencent à être vus que de la mains d’œuvre bon marché pour les ingénieurs…
#18
De tout temps
Ce sont donc des pays qui plaident pour la sécurité tout en n’ayant pas vraiment définit cela dans leurs cahiers de charge… quand il y en a un.
les mêmes qui :
Et aujourd’hui ils en demandent plus. Parce qu’ils :
Et l’éditeur va dire: “C’est possible mais ça coute plus cher. “
Parce qu’au lieu de se précipiter à taper sur les claviers comme avant, Il faudra d’abord étudier. MCD, MLD, MPD, use cases, user story, Analyse et j’en passe.
Et là tout le monde lui crachera dessus.
Bref ça change pas quoi.
#19
Parce qu’il ne veulent pas assumer les risques d’utiliser les logiciels non-sécurisés mis à disposition par des éditeurs pour qui la sécurité n’est pas une priorité car cela coute plus que cela ne rapporte.
Quand un président Français utilise son smartphone asiatique pour poster une vidéo sur un réseau américain (ou l’inverse), il doit accepter de prendre le risque de la non-sécurité.
#20
S’il t’a placé des pneus avec chambre à air au lieu des habituels tubeless, on peut considérer qu’il n’a pas travaillé dans le respect de la sécurité.
#20.1
Je ne vois pas le rapport avec le clou, mais ok 🤷
#20.2
Les pneus avec chambre à air (en tout cas sur les voitures particuliéres), ce n’est plus utilisé depuis longtemps.
#21
Ce qui est réellement sous entendu : faites des produits sécurisés si vous voulez, mais n’oubliez pas de nous envoyer le code pour la backdoor
#21.1
J’ai compris exactement la même chose : logiciels sécurisés pour les autres mais open bar pour nous, ce qui est forcement impossible mais bon le jour où les décideurs seront compétents techniquement …
#22
Ils se foutent du monde. Qu’ils commencent déjà à notifier Microsoft d’améliorer le design de leurs bouzewares. En plus ils ont surement déjà des membres de la NSA dans leurs bureaux, ils peuvent en parler à la machine à café sans avoir à faire de déclaration publique.
D’ailleurs c’est pas la NSA qui a imposé à changer un paramètre de clé de registre pour les versions non américaines de Windows, ce qui a pour effet de réduire la robustesse de certains algo de chiffrements ?
#23
Perso j’ai toujours pensé (banalement) que la clé de la sécurité dans une entreprise ou une administration, quelque soit sa taille, c’est l’humain.
Exemple : si tu m’envoie un pdf super-ch*ant de 110 Mo du style “la sécurité et vous” alors que j’ai trente dossiers à traiter pour avant-hier, le document ira vite fait à la corbeille, quelque soit ta force de persuasion.
Par contre si tu dis aux employés : “Bon les filles et les gars, demain on arrête tout, des êtres humains vont venir ici-même vous former aux meilleures pratiques de sécurité, vont corriger vos défauts éventuels de sécurisation, vous faire répéter les gestes de façon à ce que ça devienne un automatisme tel que même sous le coup du stress dû à une surcharge de travail, vous ne pourrez jamais manquer votre coup.”…
…Ben là ça change tout, surtout si tu fais des rappels réguliers en cours d’année, izuntite ?
Le secret c’est, pour les formateurs, de consacrer un peu de temps à s’occuper de chacun individuellement, de s’adapter au niveau de connaissances de chacun, et surtout de faire répéter les gestes plusieurs fois jusqu’à ce qu’ils soient intégrés.
#24
Et l’infrastructure ? Non ?
Nan parce que les arnaques type serverless ou que sais-je… on aime invisibiliser les exploitants d’infrastructure, mais il faudrait se rappeler que rien ne fonctionne avec du vide.
Je risque de trahir un secret : savez-vous que beaucoup de gens aimeraient produire de la qualité sécurisée & robuste par défaut, mais qu’en étant contraints de faire “rapide & simple” (comprendre : “moins cher & moins cher”), ça pousse de la bouse non-testée remplie de wishful thinking ?
Valable pour le matériel, le logiciel… et d’ailleurs à peu près tout ce qui existe dans notre bas monde. Quelle surprise !
Allongez le pognon, donnez le temps, exigez de vous-même une organisation claire & stable, exigez des demandeurs des spécifications claires & précise, quitte à les travailler en itérations en avant ou en même temps que le produit (le premier qui dit “Agile” je le tape), et tout ira mieux.
Dire “on veut du sécurisé par conception” est crétin, sauf à vouloir infantiliser les connaisseurs par des ignares.
#25
Non, ça c’est un malentendu, par contre ils ont essayé d’imposer un algo de génération de nombres aléatoires, le Dual_EC_DRBG et des algorithmes de négociation de clef à courbes elliptiques mathématiquement faibles, voir défectueux par design, le tout promulgué comme standard NIST avec en appui une licence des brevets imposant le générateur de nombres aléatoires vérolé.
#26
Je ne comprends même pas ce que cela veut dire, pour moi une faille c’est d’exploité quelque chose qui n’a pas été prévu.
Après si le “Security by design” est d’appliquer une checklist minimale, c’est une bonne chose.
#27
Ca me fait penser à la charte d’utilisation de l’informatique qu’on doit faire signer aux nouveaux arrivants à mon taf. L’ancienne faisait 2 pages et était relativement simple et claire, tout en donnant tous les éléments essentiels pour expliquer une bonne hygiène informatique. Elle était sûrement beaucoup trop simple : la nouvelle qu’on doit maintenant utiliser fait 10 pages A4 imprimées (sachant qu’on a 2 A5 sur chaque page A4), sur laquelle sont notés beaucoup de mots pour principalement décrire du vent, difficile à lire à cause de la taille ridicule des caractères (à cause du A5) et du choix des couleurs de fond et de police (ils ont mis du bleu foncé avec des caractères noirs…) et ne dit strictement rien de plus que l’ancienne. En conséquence, celle-là est signée parce qu’elle est obligatoire, mais personne ne la lit jamais (alors que pour l’autre, la lecture était quasi-systématique et on nous demandait souvent un double à garder sous la main).
#28
Security by Design, ça veut tout dire et rien dire… Si c’est appliquer toutes les bonnes pratiques d’architecture et de programmation liées à la sécurité (ne pas travailler directement avec des valeurs saisies pour éviter les injections SQL, ne pas utiliser des modules exotiques fournis par PIP et consort, ne pas utiliser des échanges via ssh avec la même clés privée distribuée sur toute l’infra, etc.), pourquoi pas…
Mais là ça sent à plein nez la certification bidon et chère qui va fermer le marché à ceux qui n’auront pas les moyens de se l’offrir (PME, foundation de logiciels libres, etc.) au profit des gros enfum… Euh, acteurs du logiciel déjà bien installés.
Vive le libéralisme, qu’ils disaient…
#29
Au passage, voici 2 livres que je recommande pour se former. Lus et approuvés.
https://www.editions-eni.fr/livre/securite-informatique-ethical-hacking-apprendre-l-attaque-pour-mieux-se-defendre-6e-edition-9782409033667
https://www.editions-eni.fr/livre/cybersecurite-et-malwares-detection-analyse-et-threat-intelligence-4e-edition-9782409038105
#30
En lisant le communiqué, on a l’impression qu’ils viennent de découvrir l’eau tiède (ou chaude). Ça n’a rien de nouveau, d’ailleurs ça a été le branle-bas de combat général en 2003-2004 chez Microsoft quand Bill Gates a balancé un mémo pour dire que XP Service Pack 2 devait être repensé complètement avec la sécurité comme impératif N.1.
Faut dire que XP était devenu une vraie passoire, une étude avait montré qu’un XP fraîchement installé connecté a internet (sans rien faire d’autre) pouvait se faire infecter tout seul en moins de 20min.
La reprise complète a aussi entraîné par ricochet 2 ans de retard sur la sortie de Vista histoire de faire un SP2 qui tienne un peu la route.
#31
Simplement, si tu roules sur un clou avec un tubeless, il n’y aura pas de fuite d’air (ou très lentement), contrairement avec une chambre à air.
#31.1
🤣
On va dire que ça dépend du clou 😉
#32
Personnellement, ce qui me parle le plus c’est l’avant dernier paragraphe… trop souvent dans ma carrière, j’ai vu les entreprises accepter des risques de manière informelle, sans les inclure dans une quelconque gestion de risque ou de dette technique, et ce en se foutant de l’ampleur du risque encouru ou d’un suivi ultérieur.
Peut-être obliger toutes les entreprises à intégrer l’ISO-27005 à leurs processus de sécurité ne serait pas une mauvaise idée…