Les six idées stupides de la sécurité informatique (2005)

• La sécurité informatique est un domaine où les produits, conférences, livres et projets de loi se multiplient, mais à la racine des échecs répétés se trouvent de mauvaises hypothèses de départ comme Default Permit et Enumerating Badness
• Le problème central est une logique qui poursuit sans fin "ce qu’il faut bloquer" au lieu de définir étroitement "ce qu’il faut autoriser" ; pour les pare-feu, l’exécution de code et la réponse aux vers, ne pas choisir Default Deny mène à une course aux armements avec les attaquants
• Dresser une liste des mauvaises choses consiste à suivre plus de 75 000 virus et 200 à 700 nouvelles menaces chaque mois ; c’est moins efficace que gérer les quelque 30 applications légitimes réellement nécessaires via Enumerating Goodness
• La recherche de vulnérabilités et les correctifs, la culture qui consomme le hacking comme quelque chose de cool, et les stratégies reposant sur l’éducation des utilisateurs conduisent toutes à répéter une réponse a posteriori au lieu de réduire les défauts de conception
• Pour les nouvelles technologies, attendre et valider peut être plus sûr qu’adopter immédiatement ; les praticiens de la sécurité devraient privilégier la conception de bon sens et une attitude sceptique plutôt que les effets de mode

---

Les « anti-bonnes idées » qui produisent des échecs de sécurité

• En sécurité informatique, de nouveaux produits, de nouvelles conférences, de nouveaux livres et de nouveaux projets de loi apparaissent sans cesse, mais les problèmes se répètent
• Une « idée stupide » est une approche située à l’opposé d’une bonne idée ; elle apparaît quand on essaie de faire l’impossible ou qu’on ignore la réalité
• Ces approches peuvent venir de malentendus de bonne foi, ou de produits bien emballés conçus pour gagner rapidement de l’argent
• Les six idées sont présentées dans l’ordre où on les rencontre le plus souvent, et éviter ne serait-ce que les trois premières suffit déjà à vous placer parmi la minorité des très bons professionnels de la sécurité

1. Default Permit : autorisation par défaut

• Default Permit consiste à autoriser tout ce qui n’est pas explicitement interdit ; c’est particulièrement visible dans les règles de pare-feu
  • Les premiers administrateurs réseau bloquaient telnet, rlogin et FTP en entrée, mais autorisaient tout le reste
  • À chaque nouvelle vulnérabilité découverte, l’administrateur devait décider s’il fallait la bloquer, en devant garder une longueur d’avance avant de se faire compromettre
  • Cette approche aurait dû disparaître avec l’arrivée des vers dans les années 1990, mais beaucoup de réseaux conservent encore une architecture cœur ouverte sans segmentation fine
• Le même problème se répète avec l’exécution de code
  • Si l’utilisateur clique, pratiquement n’importe quoi s’exécute par défaut, et l’exécution n’est refusée que si un antivirus ou un bloqueur de spyware l’empêche
  • En pratique, on utilise souvent une quinzaine d’applications, et 20 à 30 autres plus occasionnellement, pourtant le système d’exploitation autorise par défaut l’exécution de virus ou de spyware
• Un projet de sécurité e-banking a utilisé l’approche inverse
  • Au lieu qu’un load balancer envoie en trou noir uniquement les attaques connues, tout trafic ne correspondant pas à une liste d’URL valides est envoyé vers un serveur verrouillé qui sert une image et une page 404
  • Ce n’est pas un Default Permit qui bloque uniquement les attaques connues, mais un mécanisme qui rejette les requêtes sortant de la structure normale
• Si vous êtes dans une course aux armements avec les attaquants, c’est le signe que vous êtes tombé dans le piège du Default Permit
• Le concept opposé, Default Deny, exige engagement, réflexion et compréhension dans l’implémentation, mais c’est une meilleure approche

2. Enumerating Badness : lister les mauvaises choses

• Enumerating Badness consiste à établir une liste exhaustive des mauvaises choses connues, puis à les détecter ou les bloquer
• Au début, cela semblait possible parce qu’il existait peu de failles connues, mais vers 1992, les « mauvaises choses » sur Internet sont devenues bien plus nombreuses que les « bonnes »
  • Un produit antivirus typique connaît plus de 75 000 virus
  • Un ordinateur personnel contient environ 30 applications légitimes installées
  • Si l’on suit ces 30 applications légitimes et qu’on empêche tout le reste de s’exécuter, on peut réduire en même temps les problèmes de spyware, de virus, de chevaux de Troie de prise de contrôle à distance et d’exploits à exécution de code préinstallés rarement utilisés
• Selon certaines analyses du secteur, 200 à 700 nouvelles « mauvaises choses » apparaissent chaque mois sur Internet
• À l’objection selon laquelle, dans un réseau d’entreprise complexe, il est difficile d’identifier les applications légitimes, l’auteur répond que si un CTO ne sait même pas à peu près ce que fait sa technologie, il ne peut pas faire de planification de capacité, de reprise après sinistre ni de sécurité
• L’analyse des logs d’un produit de pare-feu en 1994 cherchait d’abord des conditions mauvaises, mais une deuxième version a utilisé Artificial Ignorance
  • On jette les logs que l’on sait inintéressants
  • Les logs restants sont considérés comme intéressants
  • Cette approche a permis de détecter des conditions opérationnelles et des erreurs qu’on n’aurait pas imaginées
• Les antivirus, la détection d’intrusion, la prévention d’intrusion, la sécurité applicative et les pare-feu à inspection profonde des paquets reposent souvent sur cette logique
• Un système qui nécessite des mises à jour régulières de signatures, ou qui laisse passer un ver jamais vu auparavant, est un symptôme d’Enumerating Badness
• Le remède est Enumerating Goodness, mais les systèmes d’exploitation offrent selon l’auteur très peu de prise en charge pour ce niveau de contrôle logiciel

3. Penetrate and Patch : pénétrer puis corriger

• Penetrate and Patch est une boucle où l’on attaque de l’extérieur des pare-feu, logiciels, sites web, etc., pour trouver des défauts, les corriger, puis recommencer
• Cette méthode ne produit pas des systèmes intrinsèquement meilleurs par conception ; elle produit seulement des systèmes durcis par essais et erreurs
• Personal Observations on the Reliability of the Space Shuttle de Richard Feynman est recommandé pour comprendre comment atteindre la fiabilité dans des systèmes complexes
  • Le message central est proche de : « si un système n’a pas été conçu pour pouvoir être piraté, alors il ne devrait pas pouvoir l’être »
• La mode de la divulgation de vulnérabilités et des mises à jour de correctifs repose aussi sur cette approche
  • Les chercheurs en vulnérabilités pensent aider la communauté en trouvant des failles avant les hackers afin qu’elles soient corrigées
  • Les éditeurs pensent faire ce qu’il faut en publiant des correctifs avant que les hackers et auteurs de vers ne les exploitent
  • Mais si le code avait été conçu dès le départ pour être sûr et fiable, la découverte de vulnérabilités deviendrait un travail ennuyeux et peu gratifiant
• Si Internet Explorer a eu 2 à 3 bugs de sécurité par mois pendant dix ans, il est difficile de dire que Penetrate and Patch a été efficace
• Certaines applications comme PostFix et Qmail ont selon l’auteur très peu d’antécédents de bugs de sécurité parce qu’elles ont été conçues pour modulariser et cloisonner les privilèges et les traitements
• Les tests d’intrusion ont les mêmes limites
  • Un réseau dont la conception fondamentale ou les pratiques de sécurité sont mauvaises continuera à se faire compromettre même après plusieurs tests d’intrusion
  • Sur un réseau conçu dès le départ pour ne laisser passer que certaines directions, certains trafics et des serveurs soigneusement configurés, un test d’intrusion classique peut devenir peu pertinent
• Si vous êtes vulnérable chaque semaine au « bug de la semaine », vous êtes pris dans Penetrate and Patch
• Les logiciels et systèmes doivent être secure by design et conçus en tenant compte du traitement des défauts

4. Hacking is Cool : l’idée que le hacking est cool

• Hacking is Cool critique une culture qui récompense ou glorifie les hackers avec des stock-options, des livres, des formations et des tests d’intrusion très rémunérateurs
• Donn Parker estime que l’informatique à distance a supprimé, dans le crime, la nécessité de la proximité physique, et que l’anonymat ainsi que l’absence de confrontation avec la victime ont abaissé les barrières émotionnelles au passage à l’acte
• Le hacking est moins un problème technique qu’un problème social
  • Internet offre un nouvel espace d’activité à des personnes peu à l’aise socialement
  • Quand les professionnels de la sécurité héroïsent les hackers, ils encouragent implicitement le hacking
  • Les médias décrivent parfois les hackers comme des « whiz kids » ou des « brilliant technologists »
• Le fait que les professionnels de la sécurité apprennent eux-mêmes les techniques de hacking est aussi considéré comme faisant partie de cette idée
  • Les exploits et leur mode d’emploi deviennent vite obsolètes une fois la faille corrigée
  • On rend sa compétence professionnelle dépendante de la course aux armements propre à Penetrate and Patch
  • Il est plus rationnel d’apprendre à concevoir des systèmes de sécurité résistants au piratage que d’apprendre à trouver des systèmes piratables
• L’auteur prédit que « Hacking is Cool » disparaîtra en dix ans, mais ne voit aucun signe indiquant que l’idée inverse, « Good Engineering is Cool », prendra la relève

5. Educating Users : éduquer les utilisateurs

• Educating Users ressemble à un Penetrate and Patch appliqué aux personnes
• L’éducation paraît positive en soi, mais si elle était efficace, elle aurait déjà dû produire des résultats
  • Plusieurs études auraient montré qu’une part importante des utilisateurs donne son mot de passe contre un simple bonbon
  • Le ver Anna Kournikova est cité comme exemple montrant que presque la moitié de l’humanité clique sur tout ce qui semble contenir des photos nues d’une femme à moitié célèbre
  • Si l’éducation des utilisateurs est votre stratégie, vous devrez peut-être « corriger » les utilisateurs chaque semaine
• La vraie question n’est pas « peut-on mieux former les utilisateurs à être prudents ? », mais « pourquoi faut-il les former en premier lieu ? »
  • Pourquoi les utilisateurs reçoivent-ils des pièces jointes exécutables ?
  • Pourquoi s’attendent-ils à recevoir un e-mail d’une banque où ils n’ont même pas de compte ?
• Les pièces jointes et la lutte contre le phishing relèvent aussi d’un problème de Default Permit
  • Si tous les utilisateurs sont autorisés à recevoir des pièces jointes par e-mail, alors on autorise par défaut tout ce qui est envoyé
  • Une meilleure approche consiste à mettre toutes les pièces jointes en quarantaine, supprimer les exécutables et ne conserver sur un serveur intermédiaire que les types de fichiers autorisés
  • Les utilisateurs peuvent alors se connecter avec un navigateur compatible SSL pour récupérer les fichiers, et l’exigence d’un mot de passe affaiblit immédiatement de nombreux mécanismes de propagation des vers
• Des outils gratuits comme MIMEDefang peuvent servir à détacher les pièces jointes des e-mails entrants, les stocker dans des répertoires par utilisateur, puis remplacer les pièces jointes dans le message par l’URL correspondante
• À l’époque où l’auteur dirigeait une petite startup de sécurité, tout employé voulant utiliser Windows devait savoir l’installer et l’administrer lui-même ; sinon, il n’était pas embauché
• Il prédit que, dans les dix ans, les utilisateurs nécessitant encore une formation sortiront du marché du travail high-tech, ou s’entraîneront eux-mêmes chez eux pour rester compétitifs

6. Action is Better Than Inaction : croire qu’agir vaut mieux que ne pas agir

• Les dirigeants IT se divisent entre les « early adopters » et les « pause and thinkers », et ceux qui ont construit des systèmes critiques sûrs et performants ressemblent davantage aux seconds
• Lorsqu’une nouvelle technologie arrive, il peut être plus sûr d’attendre plutôt que de l’installer tout de suite, d’observer les résultats chez d’autres adopteurs précoces, puis de la déployer une fois qu’il existe des personnes expérimentées
  • Un haut dirigeant IT avait planifié le déploiement du réseau sans fil en entreprise ainsi : « attendre deux ans puis embaucher quelqu’un qui a déjà réussi un déploiement wireless dans une entreprise plus grande que la nôtre »
  • Entre-temps, la technologie devient plus mature et les prix chutent fortement
• La proposition subsidiaire essentielle est qu’« il est souvent plus facile de ne pas faire quelque chose de stupide que de faire quelque chose d’intelligent »
• Le même conseil vaut pour l’externalisation de la sécurité : la retarder d’un ou deux ans, puis écouter les recommandations et retours des organisations qui auront survécu
• Dans le cas d’un client prêt à dépenser beaucoup sans validation, il est suggéré d’envoyer des employés à la conférence LISA pour rencontrer des gens ayant une expérience réelle du produit
  • Cet employé pouvait inviter à dîner des personnes ayant utilisé le produit afin d’obtenir une évaluation informelle
  • Un responsable IT a indiqué qu’un dîner à 200 dollars avait évité plus de 400 000 dollars de souffrance technique
• Le véritable « kung-fu » professionnel consiste à éviter les décisions stupides en ne faisant rien, puis à obtenir de ses supérieurs qu’ils reconnaissent le mérite de cette retenue

Autres petites stupidités

• « Nous ne sommes pas une cible »
  • Les vers ne sont pas assez intelligents pour décider si un site web ou un réseau domestique est intéressant
• « Si tout le monde utilise tel OS sécurité à la mode, tout ira mieux »
  • Les systèmes d’exploitation ont des problèmes de sécurité parce qu’ils sont complexes, et l’administration système n’est toujours pas un problème résolu
  • Suivre la mode peut même rendre plus difficile l’acquisition de l’expertise qu’un administrateur accumule avec le temps
• « Nous avons une bonne sécurité hôte, donc pas besoin de pare-feu »
  • Si l’on ne peut pas faire confiance au tissu réseau, toute application traversant ce réseau est une cible potentielle
  • Le Domain Naming System est cité en exemple
• « Nous avons un bon pare-feu, donc pas besoin de sécurité hôte »
  • Si le pare-feu laisse passer du trafic vers les hôtes derrière lui, il faut aussi prendre en compte la sécurité hôte de ces systèmes
• « Mettons-le en production maintenant, on fera la sécurité plus tard »
  • Si l’on n’a pas le temps de bien faire les choses maintenant, il faut se demander si l’on aura le temps de les refaire après la casse
  • Quelques jours non investis au départ peuvent conduire à des années de corrections continues
• « Les problèmes occasionnels, on ne peut pas les empêcher »
  • Si l’industrie aérienne raisonnait ainsi quand des vies sont en jeu, accepterait-on de monter dans un avion de ligne ?

L’attitude attendue des professionnels de la sécurité

• L’auteur estime que la sécurité informatique s’est trop laissée absorber par la « nouvelle technologie de la semaine » au point d’abandonner le bon sens
• Le travail des professionnels de la sécurité consiste à remettre en question les idées reçues et l’état actuel des choses, et si nécessaire à les contester frontalement
• Le texte se conclut sur une interrogation simple : si les idées reçues étaient efficaces, le taux de compromission des systèmes devrait baisser

[GN⁺]

Commentaires sur Hacker News

• On dirait qu’on remet encore ça : https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
  Il y a beaucoup de choses à décortiquer dans cet article, mais le point sur lequel je veux toujours revenir, c’est le fond de la pensée de Ranum à propos de la recherche sur les vulnérabilités, à laquelle il s’opposait. À la fin des années 1990 et au début des années 2000, Marcus Ranum et Bruce Schneier faisaient partie des intellectuels emblématiques de l’idée que la divulgation de vulnérabilités faisait plus de mal que de bien, et que ce travail devait être fait par les éditeurs, pas par des chercheurs externes. Ce point de vue s’est finalement révélé incorrect : en 2002, on pouvait encore ranger la recherche externe avec divulgation complète des vulnérabilités sous l’étiquette de « hacking », mais aujourd’hui ce n’est plus du tout le cas. Les quatre grandes conférences du domaine de la sécurité, et même la littérature en cryptographie, traitent de recherche offensive.

  • À l’époque, ils avaient peut-être raison. Pour rationaliser a posteriori des décisions passées, il faut les évaluer à l’aune des preuves disponibles à ce moment-là. Depuis, la taille des réseaux et le nombre de participants ont explosé.
  • Je me demande à quelles « quatre grandes conférences » en sécurité il est fait référence.
  • Il est vrai que la recherche offensive est devenue un sujet central dans les grandes conférences. En conséquence, on observe encore des externalités négatives sous forme d’exploitation réelle après divulgation, et les éditeurs n’ont souvent ni les compétences ni la volonté de répondre correctement aux publications académiques. Le monde académique peut aussi s’améliorer ; plutôt que de revenir en arrière, il est plus probable que les grandes conférences définissent des attentes plus concrètes pour réduire les dommages liés à la divulgation. Par exemple, en élargissant la notion d’« éditeur » aux acteurs capables de fournir des mesures d’atténuation, comme les éditeurs de systèmes d’exploitation ou de pare-feu.

• Je ne sais pas si c’est un oubli, mais je suis surpris qu’il n’y ait rien sur les mots de passe. Les règles de composition imposées, à part une longueur minimale, les changements périodiques et les tentatives de « remplacement du mot de passe » me semblent intrinsèquement stupides. Les règles de composition conduisent à écrire les mots de passe sur papier, à réutiliser le même mot de passe ou à ajouter un 1 à la fin ; les solutions de remplacement ont une UX horrible ou prêtent à confusion, et finissent par revenir au mot de passe. Si on me laisse simplement créer un mot de passe d’au moins X caractères avec les caractères de mon choix, je peux réellement m’en souvenir même sans téléphone ni ordinateur, ou lorsque je suis à l’étranger.

  • Le changement périodique de mot de passe était peut-être une bonne idée à l’époque. Il y a des décennies, les pratiques de sécurité étaient très mauvaises, avec par exemple des mots de passe envoyés en clair, et il a fallu longtemps pour corriger cela. Il y a aussi des gens qui partagent les mots de passe comme des bonbons ; je ne parle pas de partage de compte de streaming, mais de collègues qui partagent l’accès à des ressources importantes au sein d’une organisation. C’est pourquoi je ne suis pas d’accord avec l’idée d’ignorer la formation des utilisateurs finaux. Certains problèmes peuvent être résolus techniquement, mais les problèmes sociaux comme le partage de mots de passe ne se règlent pas bien par la seule technique.
  • Les organisations qui recommandent encore de forcer un changement de mot de passe tous les mois ou tous les deux mois ne suivent même pas les pratiques de sécurité récentes des régulateurs. Le NIST américain (https://pages.nist.gov/800-63-FAQ/) et le NCSC britannique (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) publient tous deux des recommandations plutôt solides qui n’exigent pas cela.
  • Je répète ce message depuis des années. Les générateurs de mots de passe créent en pratique des clés impossibles à mémoriser, ce qui a conduit aux gestionnaires de mots de passe, et tout cela est protégé par un seul mot de passe. Désormais, le point de défaillance unique devient un mot de passe, et si un attaquant l’obtient, il a accès à tous les autres. De toute façon, comme les règles de verrouillage après n tentatives coupent dans la plupart des cas la voie des attaques par force brute, elles sont bien plus efficaces. Je ne suis pas expert en sécurité, donc il peut y avoir des cas où des mots de passe complexes et longs font une différence, mais avec l’authentification multifacteur, la majeure partie de ce débat devient sans objet.
  • J’allais aussi parler des mots de passe, mais aujourd’hui les passkeys me semblent être un candidat encore plus sérieux au titre d’idée stupide. Pour l’utilisateur moyen, cela risque de créer une confusion sans fin.
  • Les politiques de mots de passe sont une blague. Si vous utilisez 5 sites web, vous avez 5 politiques différentes. Certains sites, comme des banques, bloquent les caractères spéciaux en les considérant comme une « tentative de piratage », si bien que même le générateur de mots de passe de Firefox ne fonctionne pas, et l’utilisateur contourne le problème en saisissant quelque chose comme suckmyDICK123!!. Malgré cela, en général, le débit de force brute est insuffisant, ou le compte est verrouillé après 5 échecs, donc ils ne se font pas facilement compromettre. Aujourd’hui, la plupart des gens savent au moins que « des bots essaient des mots de passe à une vitesse surhumaine », et aucune politique de mot de passe n’empêche vraiment de choisir un mauvais mot de passe. C’est un cas où des gens « responsables » gaspillent énormément de temps à essayer de résoudre la réalité. À part un ou deux comptes sensibles comme ceux des banques, pour les services qui exigent un compte de force — comme 80 jeux testés une minute — on a envie d’utiliser le même mot de passe. Souvent, c’est une interface graphique séparée où le copier-coller ne fonctionne même pas ; on pourrait utiliser un gestionnaire de mots de passe, mais il n’y a aucune raison de s’embêter.

• Le hacking peut être cool. Pas accéder aux données et systèmes des autres, mais comprendre en profondeur un système qui m’appartient et trouver comment le faire dysfonctionner à mon avantage, c’est cool. Crocheter la serrure du voisin, ce n’est pas terrible ; crocheter sa propre serrure, c’est cool. Manipuler un ordinateur distant pour obtenir un accès indu, ce n’est pas terrible ; faire faire à son propre ordinateur quelque chose qu’il n’était pas censé permettre, c’est cool. L’attitude qui consiste à explorer les limites du possible fait avancer le monde, et il y a sans doute eu très peu de sociétés humaines prospères qui ont célébré le fait de rester dans le cadre.

  • On peut dire que le crime n’est pas cool, mais il y a clairement un attrait à connaître des choses subversives comme le crochetage, le démarrage d’une voiture sans clé, la fabrication d’armes ou l’exécution de John the Ripper. Cela donne une sorte d’effet de magicien qui n’est pas lié par les règles auxquelles tout le monde croit.
  • Si l’ordinateur distant était utilisé par une organisation de phishing vocal pour stocker les informations personnelles de nombreuses victimes âgées, alors un accès non autorisé pourrait aussi être cool. Si cet accès perturbe l’activité frauduleuse, cela peut être très cool et même drôle. Techniquement, ce serait illégal et relèverait de la justice de justicier, mais ici on parle de ce qui est « cool », pas de légalité. Les justiciers paraissent généralement cool quand ils agissent par sens personnel de la justice.

• Cet article contient beaucoup de très mauvais jugements. Une phrase du genre « j’ai conçu, implémenté et configuré mon système avec soin, donc je n’ai pas besoin de le tester » est peut-être la pire vision de la sécurité que j’aie réellement entendue. Dire que « le hacking est un problème social, pas un problème technique » ressemble aussi beaucoup à de la sécurité par l’obscurité, et ce n’est pas toujours un problème social. Il suffit de regarder l’espionnage industriel ou les acteurs étatiques pour s’en rendre compte.

• Le problème central est généralement le compromis malheureux entre utilisabilité et sécurité ; la plupart des idées stupides citées ici résultent du fait d’avoir sacrifié la sécurité pour réduire la gêne de l’utilisateur moyen. Par exemple, l’autorisation par défaut est catastrophique pour la sécurité et explique beaucoup de problèmes de Windows, mais les utilisateurs détestent devoir autoriser explicitement chaque nouveau programme. Même lorsque Microsoft a ajouté des boîtes de confirmation, beaucoup y ont vu une mauvaise conception rendant le logiciel bien plus pénible à utiliser. C’est ainsi que « autoriser par défaut », « énumérer les mauvaises choses » et « corriger après l’intrusion » sont devenus les comportements par défaut. Personnellement, je considère que les mots de passe eux-mêmes font partie des idées les plus stupides en matière de sécurité. Par définition, un bon mot de passe est difficile à mémoriser, difficile à saisir sur des appareils sans vrai clavier, et pénible pour l’utilisateur à presque tous les égards. Mais il n’existe pas non plus d’alternative réaliste. Les liens par e-mail tombent entièrement si l’accès à l’e-mail est compromis, et c’est généralement pareil pour la réinitialisation de mot de passe. Les dispositifs d’authentification physiques empêchent l’utilisateur de se connecter hors de chez lui ou l’obligent à transporter constamment un accessoire, et presque toutes les méthodes exigent de bonnes habitudes de sécurité, auxquelles 99,9 % de la population ne s’intéresse guère.

  • C’est de ce constat que sont nés les passkeys, avec une connexion unique et une authentification à deux facteurs comme éléments de connexion. Apple a totalement intégré les passkeys synchronisés dans le cloud ; sur les appareils Apple, cela fonctionne sur l’appareil lui-même, et si l’on possède un appareil Apple, avec seulement une authentification à deux facteurs. Chrome peut aussi faire office de passkey, tout comme BitWarden. On ne peut pas vous piéger, on ne peut pas les contourner, vous pouvez choisir votre fournisseur, et comme le site peut indiquer le nom du fournisseur enregistré, il n’y a rien à mémoriser.
  • Je recommande d’utiliser un gestionnaire de mots de passe basé sur le navigateur réputé, protégé par un mot de passe fort, et de le laisser générer des mots de passe forts que l’on ne mémorisera pas. Les sites web qui empêchent cela avec du JavaScript dans les champs de saisie de mot de passe devraient être condamnés à des dommages et intérêts, avec des sanctions aggravées. Les banques, en particulier.
  • Les mots de passe ont longtemps été une bonne idée. Pendant les dix premières années, peut-être même vingt, il n’existait pas d’appareils dépourvus de vrai clavier. Le plus gros problème a été l’idée selon laquelle les mots de passe devaient être complexes et longs, du genre mélanger des caractères alphanumériques aléatoires et des caractères spéciaux, avec au moins 12 caractères ; utiliser quelques mots aurait été préférable. On sous-estime souvent à quel point l’environnement technologique a changé depuis l’arrivée du smartphone, mais dans le contexte antérieur des ordinateurs et des ordinateurs portables, le mot de passe était un bon choix.

• L’affirmation selon laquelle « apprendre plusieurs exploits et leur utilisation revient à passer du temps à apprendre des outils et techniques qui seront obsolètes dès qu’ils seront corrigés » est fausse. En réalité, on apprend les aspects pratiques en même temps que la théorie, et c’est très utile.

  • Je vois aussi un problème dans cette partie. On ne peut pas devenir écrivain sans apprendre à lire. Publier un livre ne rend pas la lecture moins utile. Il faut apprendre comment fonctionnent les exploits connus pour pouvoir découvrir des exploits inconnus. Même lorsqu’une vulnérabilité connue est corrigée, la valeur des connaissances sur la façon dont elle est apparue ne diminue pas. Il se peut qu’on ne puisse plus l’utiliser, mais l’utiliser n’était probablement pas l’objectif de l’apprentissage au départ.
  • Pas forcément. Il y a aussi beaucoup de script kiddies qui savent faire tomber un site avec LOIC sans avoir la moindre idée de ce qu’est TCP ni de ce à quoi ressemble une requête HTTP.

• Dans cette liste, je retirerais « le hacking, c’est cool » et j’ajouterais la confiance accordée au client. On voit récemment davantage de tentatives de faire confiance au client. Par exemple, des applications mobiles qui exigent une preuve que le système d’exploitation n’a pas été modifié, ou Google qui a essayé d’introduire un DRM similaire sur le web. Si un modèle de sécurité réseau dépend de la confiance accordée au logiciel client, il est déjà cassé.

  • Ce n’est pas une question de sécurité, mais de contrôle. Un système modifié peut servir à des objectifs maléfiques comme le blocage des publicités, et Google n’aimerait pas ça.

• À propos du « blocage par défaut », il est dit que ce n’est « pas beaucoup plus difficile que l’autorisation par défaut et que l’on dort mieux la nuit ». Le responsable sécurité IT dormira peut-être mieux, mais tous les autres dans l’entreprise seront extrêmement agacés s’ils doivent faire trois allers-retours avec le service IT pour la moindre chose. Et plus les gens sont agacés, plus ils sont susceptibles d’utiliser des contournements qui sapent le concept de sécurité. Si l’on impose un changement de mot de passe tous les mois, les gens utilisent des choses comme password1, password2, password3. Une bonne sécurité IT ne consiste pas simplement à débrancher le câble réseau ; elle doit être invisible et non intrusive pour l’utilisateur, comme par magie.

  • Dans le service d’un ami, une application fournisseur très importante a cessé de fonctionner à un moment donné, et il a ouvert un ticket auprès de l’IT. Le problème était si complexe qu’il a fini par obtenir l’autorisation d’exécuter Microsoft Packet Capture. Même avec la capture, l’IT n’a pas réussi à résoudre le problème ; frustré, il me l’a envoyée. Comme je suis développeur, j’ai des droits administrateur et MSDN sur mon ordinateur portable ; j’ai donc téléchargé les outils Microsoft et examiné la capture. Il s’est avéré que cette application était une implémentation client/serveur à l’intérieur de la machine locale. Le frontend communiquait avec le backend via un port réseau, et le backend communiquait avec les serveurs du fournisseur. Quand l’entreprise a commencé à appliquer le « blocage par défaut », cela a aussi cassé mon flux de développement de plusieurs façons, et j’ai trouvé des contournements que l’IT ne connaissait pas. J’ai indiqué à l’IT quoi dire et comment le mettre sur liste blanche, mais il rencontre encore des problèmes. Si je reste vague sur les détails, ce n’est pas seulement pour des raisons de confidentialité : c’est aussi parce que mon ami a travaillé plus d’un an avec l’IT pour en arriver là, et que c’était il y a deux ans, donc j’ai oublié beaucoup de détails. Quand une entreprise industrielle legacy commence à faire du « blocage par défaut », « trois allers-retours supplémentaires » est une sous-estimation.
  • J’aimerais que davantage d’administrateurs IT prennent la ceinture de sécurité et l’airbag comme modèle de sécurité. Ils ne causent qu’un très léger inconfort dans l’usage normal d’une voiture, mais en cas d’accident, leur valeur devient immense. À la place, beaucoup d’administrateurs considèrent comme normal de bloquer le travail lui-même pour masquer leur ignorance et leur manque de professionnalisme.
  • Une bonne sécurité IT n’est pas invisible. Elle existe pour empêcher le déploiement d’applications médiocres qui exigent un accès Internet sortant illimité. Elle doit pousser l’authentification multifacteur, collaborer avec les parties prenantes dès le départ et intégrer la sécurité dès le lancement. Il s’agit surtout d’identifier et d’atténuer les risques métier. Il faut garder à l’esprit que chaque application est considérée comme un élément de responsabilité, et que toute nouvelle application qui s’écarte des standards doit être traitée au cas par cas.
  • Je pense qu’une politique de « blocage par défaut » est une bonne idée pour l’infrastructure de sécurité autour des postes de travail. L’effort demandé à l’IT pour modifier le profil de sécurité lorsqu’un nouvel outil utilisant un nouveau port, etc., arrive est bien inférieur au coût d’une fuite du contenu d’un poste de travail donné. En revanche, les serveurs applicatifs et l’infrastructure publique doivent absolument fonctionner en blocage par défaut. J’ai du mal à imaginer une situation où ce ne serait pas nécessaire.
  • L’IT d’entreprise existe pour servir l’entreprise. Ses coûts ne doivent pas dépasser ses bénéfices. Il faut un équilibre. Ouvrir un port ne devrait pas prendre une semaine, mais on ne veut pas non plus que des gens fassent tourner un serveur web sur leur poste de bureau de l’entreprise avec, par hasard, un fichier de plans propriétaires posé à côté.

• Les textes centrés sur la sécurité sont généralement écrits par des personnes qui accordent une importance extrême à la sécurité, et ignorent souvent les difficultés qu’une approche purement axée sur la sécurité impose aux utilisateurs de logiciels sûrs. Je vois toujours la sécurité comme un curseur entre sûreté et commodité. Une conception totalement sûre est si peu pratique qu’elle n’a presque pas d’utilisateurs, et une conception totalement pratique n’est pas suffisamment sûre, ce qui peut finir par mener au même résultat. Cela dit, cet article reste globalement intéressant à lire, mais je m’oppose fermement à l’idée selon laquelle il serait idiot pour un expert en sécurité d’écrire des exploits ou d’apprendre à abuser d’un système donné. J’ai appris beaucoup plus sur la sécurité en étudiant des vulnérabilités et des exploits, puis en les implémentant moi-même dans une démarche white hat, qu’en étudiant la « conception sécurisée ». C’est un peu comme dire : « pour connaître son ennemi, il faut devenir son ennemi »

  • Cette analogie est sans doute plus accessible, mais j’ai tendance à le formuler de façon un peu plus offensive. Quand je débat avec des gens qui ne jurent que par la sécurité, je commence parfois par quelque chose comme : « le plus sûr serait de fermer la boutique demain, mais ça risque d’être difficile à faire approuver ». Une fois qu’on a ri ensemble, on peut discuter des compromis à faire. J’ai aussi obtenu de bons résultats en les amenant à changer de posture de base avec : « si vous dites non, on le fera simplement sans vous, et dans ce cas il y aura seulement autant de sécurité que j’en aurai mise. On trouvera toujours un moyen, donc j’aimerais que vous nous guidiez vers une voie plus sûre ». Cela dit, j’essaie de l’éviter, car cela peut facilement susciter de l’hostilité

• C’est en grande partie une liste médiocre vieille de 19 ans. Dire que « les logiciels et les systèmes devraient être sécurisés dès la conception et conçus en tenant compte du traitement des défauts » revient à dire que « dans un monde parfait, tout aurait été sécurisé dès le départ ». Comme cela n’arrivera jamais, il faut utiliser des techniques de découverte puis correctif, et cela a bien fonctionné pour les entreprises qui corrigent effectivement les vulnérabilités découvertes et tirent de leurs erreurs des pratiques de codage futures. De plus, la plupart des systèmes ne sont pas statiques. On ne publie pas une fois pour toutes un système sécurisé sans jamais le mettre à jour ; la plupart des applications et systèmes sont mis à jour fréquemment, et de nouvelles vulnérabilités y sont alors introduites

  • En l’interprétant de la manière la plus charitable possible, ce que l’auteur veut probablement dénoncer, c’est le fait de se contenter de « correctifs » trop étroitement ciblés sans corriger les mauvaises pratiques de conception qui ont créé la vulnérabilité. Par exemple, « corriger » une vulnérabilité de cross-site scripting dans une application web en bloquant les requêtes contenant des mots-clés comme script ou onclick
  • C’est un exemple du fait que, quand on dit des idioties avec assurance, beaucoup de gens vous prennent pour quelqu’un d’intelligent
  • Le texte lui-même est franchement stupide. La phrase selon laquelle « les timides peuvent devenir des criminels » comprend de travers le hacking, la criminalité et la nature humaine. Les criminels vont là où se trouve l’argent ; il n’est pas nécessaire d’être un énorme catcheur pour braquer quelqu’un devant un distributeur, pas plus qu’il n’est nécessaire d’être le nerd stéréotypé pour s’y connaître en informatique. C’est d’une bêtise digne des pires comédies des années 1980. Dire que « l’informatique à distance a supprimé l’exigence historique, pour les criminels, d’être proches de la scène du crime » n’a pas non plus de sens. Il suffit de penser à ce que le courrier a rendu possible. L’arnaque du prisonnier espagnol existe depuis des siècles, avec la même structure que les arnaques 419. Dire que l’anonymat et l’absence de face-à-face avec la victime réduisent la difficulté émotionnelle du crime est également exagéré. Les criminels peuvent escroquer quelqu’un en le regardant en face, recourir à la violence ou le menacer pour lui faire vider ses comptes. Enfin, « fais tout parfaitement dès le départ, idiot » n’est pas un plan applicable
  • Les mises à jour fréquentes ont largement pour effet de masquer de mauvaises pratiques d’ingénierie et d’encourager des produits inadéquats. Le monde n’est pas statique, mais dans la plupart des cas il existe des schémas à identifier et à traiter. Si l’on court de correctif rapide de MVP en correctif rapide, on ne se donne pas ce temps
  • Il y a bien quelques éléments de valeur, mais au moins la moitié se lit comme une diatribe embarrassante qu’on pourrait entendre de la part d’un stagiaire débutant au helpdesk, ivre en fin de soirée de Noël de l’entreprise. Il est étonnant que cela ait été écrit par un expert du sujet, qu’il l’ait laissé sur son site web pendant 20 ans, et que ce soit encore autant recommandé