Speaker #0Bonjour à toi, aujourd'hui je te raconte une autre histoire vraie, une faille interne, une fausse bonne assurance et une attaque simple grâce à l'exploitation d'une vulnérabilité connue. Je t'introduis le process JML, ne cherche pas trop, surtout pas dans l'ISO 27001, il n'y est pas, enfin pas tel quel. Et je vais te donner quelques conseils pour éviter que ceci ne t'arrive. Bienvenue dans Compliance Without Comma, le podcast qui parle cybersécurité, gouvernance, normes ISO sans coma. Tu connais l'Active Directory. C'est la carte d'identité numérique des employés. C'est là que tu gères les comptes, les accès, les droits, bref, le Graal pour tous ses admins. Sauf que quand un admin s'en va, tu penses peut-être que bloquer son compte suffit. Eh bien... Tu vas voir que c'est loin d'être le cas. Petite mise en contexte, je suis en mission dans une boîte de 200 personnes, où il n'y avait jamais véritablement eu de problème de sécurité. Le risque était maîtrisé et l'entreprise relativement mal... mature et stable dans ses développements. Elle faisait encore du waterfall, deux grosseries disparants, environnement vraiment maîtrisé, architecture entière, réseau segmenté, plusieurs data centers, TMZ, vraiment dignes d'un bunker. De l'extérieur, presque impossible à attaquer. Une vraie forteresse. On ne craint pas le hacker du Pérou, me dit mon CIO de l'époque, mon ancien plus ami. Et j'avais beau lui dire que cela ne suffisait pas, Ma mission pour eux n'était pas la sécurité à l'époque, donc difficile de faire remonter les risques en terme de cyber et de sécurité de l'info. Mais un jour, un pentest, un termine cette fois, est lancé. Et là surprise, boum, le pentester devient admin, sans jamais casser un mot de passe, sans brute force, sans phishing, sans social engineering, juste avec un H. Alors un H c'est quoi ? Je pourrais parler crypto pendant 40 heures, mais en fait bref. Donc 1H c'est l'empreinte numérique d'un mot de passe. Pas le mot de passe lui-même, mais une version chiffrée, avec dans certains cas le fait de pouvoir le rejouer. jeton et c'est exactement ce qu'il s'est passé le compte à des de l'ancien 6 admis n'était bloqué oui ok parfait mais son h 100 h traîner encore dans les systèmes dans les sessions dans les caches et dans un serveur samba mal patché Un serveur Samba, c'est un logiciel libre qui permet à des systèmes non Windows, comme Linux ou Unix, de communiquer et de partager des fichiers avec des machines Windows en émulant le protocole de Microsoft. Petit rappel, si tu as écouté l'épisode 3, la faille exploitée dans Samba était une CVE connue, Common Vulnerability Exposure. Résultat, un hash réutilisé via un replay attack sur 100% une escalade de privilèges parce que cette vulnérabilité de Samba permettait l'authentification faible et une replay attack, accès admin et un réveil difficile pour le client. Ils ont vécu avec un trou dans la raquette pendant des années et ce jour là quelque chose a changé, ils ont compris, ils ont vu que leur sécurité interne n'était qu'un vernis et ils ont lancé leur vrai programme de sécurité de l'info avec une priorité absolue pour démarrer sur le patching, Depuis, j'ai pu constater que cette société était devenue entre-temps ISO 27001, et donc j'imagine que le patching est devenu un réflexe chez eux et fait partie vraiment de leur ADN et de leur analyse de risque, parce que dans l'ISO 27001, je le dis souvent, que ce qui est au cœur du PDCA, c'est ton analyse de risque, c'est elle qui donne le battement pour que tu puisses développer ton plan de traitement des risques, tes améliorations quantiques. Mais surtout, ce qui a changé chez ce client-là, c'est cette prise de conscience. Conscience de quoi ? Qu'ils sont vulnérables. Et donc, leur playbook, leur plan disaster recovery, ont été beaucoup plus poussés par rapport à une réponse aux incidents. Et depuis lors aussi, ils ont un SOC. Donc, Security Operating Center. Et donc avant ils pensaient que le danger venait du Pérou, c'est à dire probabilité très faible quand même, je vais pas te la jouer comme bigard avec sa chauve-souris, mais aujourd'hui ils savent que l'ennemi peut être leur propre passé. Et toi, est-ce que tu as un process JML en béton ? JML, peut-être que tu ne l'as jamais entendu. Parce que ce n'est pas dans l'ISO. Ce n'est pas dans l'ISO 27001, en tout cas, pas tel quel. JML, moi, j'utilise pour Joiner, Mover, Lever avec tous mes clients. et je le mets systématiquement dans mon système de management de la sécurité de l'information. En moyenne, je touche une grosse quinzaine de contrôles de l'ISO 27001 grâce à ça. Alors, pourquoi c'est important d'avoir un processus JML ? Lorsque quelqu'un arrive, tu as le joiner. Lorsque quelqu'un change de rôle, de manière horizontale ou verticale, ou un product owner qui change d'équipe, que sais-je, il y a également... des revues de droits d'accès, il y a également une série de documents auxquels il aura accès ou qui n'aura plus accès, etc. Mais quand quelqu'un part également, tu te rappelles le titre de mon podcast avec mon CIS admin quand il quitte, c'est un peu ça. Quand quelqu'un part, tu peux avoir plusieurs personnes, plusieurs types de personnes qui vont partir. La personne qui a remis son préavis, et donc peut-être que tu as 6 semaines, 6 mois, etc. La personne que tu vas devoir licencier pour faute grave. Alors là, c'est plus tout à fait le même, on rentre dans une autre procédure. La personne, comme moi, qui est externe et donc qui a un contrat à durée déterminée, et qui est peut-être renouvelable de 3 mois en 3 mois ou d'année en année, ou voire même des jobs étudiants. Je te parle exprès de tous ces différents rôles pour bien te montrer qu'on a des casquettes différentes, des rôles et responsabilités différentes, et donc on doit avoir un suivi quand on quitte une société. Donc chaque transition, en fait, est une faille potentielle. Et si tu ne documentes pas, si tu ne vérifies pas, si tu ne nettoies pas les restes numériques, tu es vulnérable, même sans le savoir. Donc, dans ce cas-ci, qu'est-ce qu'on aurait pu faire pour éviter que cela ne se produise ? On aurait pu challenger le statu quo, c'est-à-dire que la stabilité n'est pas une assurance. Et assurance, je n'aime pas ce terme-là en français parce qu'on pense tous au premier degré. au terme à la fameuse compagnie avec laquelle on va travailler, pour laquelle on paye des primes très chères, et qui va nous la faire à l'envers dès qu'on a un sinistre. Non, ce n'est pas de cette assurance-là que je parle, je te parle d'une confiance et d'une certitude. Est-ce qu'on est vraiment confiant ? Est-ce qu'on est vraiment certain ? Même lors d'audit, j'ai vu des choses dans ma carrière. Donc, il faut challenger le statu quo, mais avec un bon compromis. On ne va pas le challenger non-stop non plus. Restons pragmatiques. Mais débattez de tout ça en comité de direction. Comment peut-on s'améliorer encore ? Est-ce qu'on a terminé notre analyse de risque ? Est-ce qu'on est complet ? Que sais-je ? Attention aussi que patcher sans tester induit d'autres risques. Et j'ai vu des cow-boys dans ma carrière, des gens qui voulaient absolument patcher sans test, et des gens qui étaient fiers d'avoir un uptime de leur serveur de trois ans. C'est-à-dire qu'ils me garantissaient que le serveur n'avait jamais été redémarré. C'était très beau pour leur ego, le seed admin. Et de l'autre côté, il me garantissait surtout que le serveur n'avait jamais été patché pendant 3 ans. Ok ? Voilà, il faut essayer de trouver un compromis. Donc, challenger le statu quo. Mettre en place un vrai process de patching. Application des correctifs et analyse de ceux-ci en mode découverte. Et puis derrière, vous faites une mini-analyse de risque pour voir par rapport au contexte. Parce que vos outils de scan, ils vont vous sortir toute une série de faux positifs. A vous de les remettre en contexte et à valider ça derrière. peut-être avec des tickets Jira ou sur une page Confluence, que sais-je, afin de pouvoir démontrer que votre processus marche pour l'auditeur. Donc vous allez maintenant mettre une priorité de criticité sur les CVR par exemple. Faites aussi des exercices tabletop. Donc posez la question au ciseau pour voir jusqu'où il sait répondre sur un process, et posez la question aux bonnes parties prenantes autour de la table pour voir vraiment s'il maîtrise ou pas. Et moi, quand on ne maîtrise pas, je lève ça comme un risque. C'est-à-dire que c'est un faux sentiment de confiance. Il y a peut-être un risque de croire qu'on est compliant ou de croire qu'on est bon, alors qu'on ne mesure même pas l'efficacité du contrôle. En conclusion, on arrive tout doucement à la fin, le danger ne vient pas toujours de l'extérieur. Et bloquer un compte à D, ce n'est pas suffisant. Donc, si tu penses que ton infrat est blindé, reviens écouter cet épisode à chaque nouveau départ de ton système d'information. Et si tu as aimé cet épisode, mets-lui un 5 sur Spotify ou Apple, partage-le, commente et revois ta politique de livreur avant qu'on ne doive en reparler dans un exercice de crise. Très vite.
