Speaker #0Je me suis rappelé récemment une interview que j'avais passée il y a plusieurs années. Je venais de créer Nitroxis, je postulais pour une mission de consultant, une mission en fait de séparation de deux infrastructures informatiques. Et pendant l'entretien, on m'a posé une seule question, une question toute simple, enfin en apparence. Aujourd'hui, certaines choses que je vais raconter peuvent paraître évidentes, d'autres sont devenues obsolètes. Mais ce qui n'a pas changé, c'est la manière de réfléchir. Et c'est probablement la compétence la plus importante d'un consultant en sécurité de l'information. Bienvenue dans Compliance Without Coma, le podcast qui parle de cybersécurité, de gouvernance et d'ISO 27001, sans te plonger dans le coma. Je suis Fabrice De Paepe et depuis plus de 20 ans... j'aide les entreprises à construire des systèmes de management de la sécu de l'info qui fonctionnent vraiment. Ici, je te partage ce que je vois sur le terrain, les erreurs, les bonnes pratiques et surtout ce qui marche. J'entre dans la salle. À peine ainsi, la question tombe. Nous sommes une entreprise d'environ 40 000 collaborateurs. Nous travaillons en trois pauses, week-end compris. Notre CIO vient d'autoriser Outlook Web Access pour tout le personnel. Suite à des plaintes concernant les performances, il envisage de publier Outlook Web Access en HTTP plutôt qu'en HTTPS. Que proposez-vous ? Je dois t'avouer que ma première pensée a été « je crois que je ne vais pas accepter cette mission » parce que si le CIO envisage réellement ce genre de décision, on part de très loin en maturité. Puis je me suis dit « ok, mais si j'étais le CISO de cette boîte, je ferais quoi ? » Bon, je mettrais mon casque. Et je partirais aussi en courant. Bon, allez, revenons sur Terre. Ça, c'était pour la blague. Parce qu'en fait, en réalité, j'ai pas répondu à cette question. J'ai commencé à poser des questions. Parce qu'un consultant qui répond avant de comprendre n'est plus un consultant. C'est juste quelqu'un qui distribue des opinions. Et moi, je suis comme le docteur, en fait. Je dois te poser des questions pour comprendre ce qui se cache derrière tes symptômes. Et j'ai besoin de toi, du patient aussi. Pour qu'il se soigne, je ne te soigne pas vraiment tout seul. Et donc ma première question n'était même pas technique. Je voulais comprendre le CIO. Pourquoi voulait-il faire cela ? Est-ce que c'était un choix technique ? Un choix politique ? Une pression de la direction ? Une contrainte budgétaire ? Une méconnaissance du risque ? Bon, comme il n'était pas dans la salle, j'avais pas de réponse. Mais je savais déjà une chose. Je ne pouvais pas proposer une solution. sans comprendre le problème. Je commence donc par faire mentalement mon analyse CIA. Confidentialité, ok. C'est le mail, je le mets au maximum. Parce que le courrier électronique contient énormément d'informations sensibles. Même avant le RGPD. Pour l'intégrité, je dirais que c'est important. Un mail modifié peut avoir des conséquences importantes. Mais on parle du mail client ici, pas du mail transactionnel. Donc je l'ai un peu baissé. Disponibilité. Au départ, je lui donne également une cote élevée. Puis je pose une question. Vos collaborateurs travaillent-ils réellement depuis leur domicile ? Ou consultent-ils simplement leur mail pendant leur congé ? Silence. Ah, mais ça change tout. Est-ce qu'il y a des personnes de garde ? Oui. Et les autres ? Ah, mais pas forcément. Ok, donc finalement, la disponibilité n'a pas la même valeur pour les 40 000 personnes. Premier renseignement. Tous les utilisateurs n'ont pas le même besoin. Je continue mon analyse et je pose cette question. Pourquoi ouvrir Outlook Web Access à tout le monde ? Pourquoi pas uniquement aux personnes réellement concernées ? Combien y a-t-il de collaborateurs qui sont de garde ? Combien ont une obligation de consulter leur mail en dehors des heures de travail ? Nouvelle réponse ? Je ne sais pas. Tiens, ça c'est intéressant. On veut ouvrir l'accès à 40 000 personnes. sans savoir combien en ont réellement besoin. Puis je reviens au point de départ. Je pars des plaintes, en fait. Vous me dites que c'est lent. Très bien. Mais qu'est-ce qui est lent ? Le serveur ? Le réseau ? Internet ? Votre fournisseur d'accès ? Je ne pense pas. Vu la boîte, ils ont de la fibre. Ils avaient déjà de la fibre. Est-ce que c'est le navigateur ? Est-ce que c'est le chiffrement HTTPS ? Est-ce qu'il y a des problèmes de proxy ? Est-ce que... On parle des utilisateurs concernés ou de tout le monde ? C'est lent pour qui ? Quelques personnes ou les 40 000 ? Est-ce que vous avez mesuré le problème ? Ou est-ce simplement une perception ? Parce que c'est lent, c'est pas un diagnostic, c'est un symptôme. Et un consultant ne traite pas un symptôme, il cherche la cause. Bon, je continue à poser mes questions. Je te rappelle que c'est moi qui suis interviewé, en fait. Est-ce que les collaborateurs utilisent leur matériel personnel ? Ou alors, quel matériel utilisent-ils ? Ah, ils utilisent leur ordinateur personnel. Très bien. Est-ce que ça, c'est géré par l'entreprise ? Non. Ok. Ont-ils une configuration minimale de sécurité ? Non. Ok. Les correctifs sont-ils suivis ? Non. Ça me fait peur. Les navigateurs sont-ils imposés ? Non. Un antivirus ? Aucune exigence. Un firewall ? Pas prévu. Je commence à comprendre. Et comment ils se connectent, vos utilisateurs ? Login mot de passe uniquement. Pas de VPN, pas de MFA. Aujourd'hui, cela nous paraît impensable. Mais à l'époque, c'était courant. Je continue. Est-ce que le mot de passe peut-il être enregistré dans le navigateur ? Oui. Ah, donc, si quelqu'un ouvre sa messagerie depuis un cybercafé, il peut enregistrer ses identifiants, ou pire, les laisser derrière lui. Je vois alors mon interlocuteur relever les sourcils, je crois qu'il n'avait jamais envisagé ce scénario-là. Mais revenons au cœur du sujet. En fait, pourquoi HTTPS existe-t-il ? Parce qu'il protège les identifiants, le contenu d'email, les cookies de session... En HTTP... On est d'accord que tout circule en clair. Alors, sur un wifi public dans un hôtel, dans un aéroport, où tu n'as pas de VPN, ou même simplement sur un réseau compromis, les informations peuvent être interceptées. Donc la lenteur était peut-être un problème, mais la confidentialité allait devenir une certitude. On continue l'interview. Tiens, en fait, est-ce que vous journalisez les connexions ? Oui. Ok, très bien. Et qui regarde les journaux ? Silence. Est-ce que vous détectez, vous, les connexions inhabituelles ? Les connexions de nuit depuis un autre pays, un changement d'adresse IP, depuis deux endroits différents en quelques minutes ? Le fameux « impossible travel » , c'est-à-dire être à Bruxelles et deux minutes après être à Singapour. Non. Donc les journaux existent, mais personne ne les exploite. Ok. Et est-ce que vous avez un helpdesk 24 sur 24 ? Oui. Ah, ça c'est très bien. Est-il formé aux incidents de sécurité ou... Uniquement à restaurer le service ? En fait, la réponse est qu'il remet surtout les comptes en état. Ok, je continue. Et quand un utilisateur appelle pour réinitialiser son mot de passe, comment vérifiez-vous son identité ? Silence. Encore silence. Ok. Moi, de mon côté, je comprends que le helpdesk est excellent pour résoudre les incidents IT, mais pas pour détecter une tentative de social engineering. Et tiens, est-ce qu'en fait, vos utilisateurs... reçoivent une sensibilisation avant d'obtenir l'accès ? Non. Connaissent-ils les risques ? Non. Les bonnes pratiques ? Non. Ok, très bien. Nous sommes donc en train d'augmenter la surface d'attaque sans augmenter le niveau de préparation. Puis au fil de l'échange arrive une partie très intéressante. Les syndicats souhaitent que leurs membres puissent consulter leur communication pendant leur congé ou leur absence. Ah ! Avec une vraie motivation métier, les syndicats ne sont pas le problème. Ils défendent leurs membres, ça c'est normal. Mais cela m'apprend quelque chose. Une partie prenante influence directement une décision de sécurité. Et ça, c'est exactement ce que nous retrouvons aujourd'hui dans un SMSI ou ISO 27001. La sécurité n'est jamais uniquement technique. Elle est aussi politique, organisationnelle et humaine. Petite remarque, à ce stade, je n'avais toujours pas répondu à la question initiale. Je n'avais proposé aucune solution, parce que je n'avais toujours pas terminé de comprendre le problème. Mais à ce moment-là, avec toutes les infos que j'avais, voici ce que j'ai recommandé. Limiter l'accès aux personnes qui ont réellement besoin, sur les 40 000. Former ses utilisateurs avant de leur donner un accès distant. Mettre en place un VPN. Ne jamais publier Outlook Web Access sans chiffrement HTTPS. Définir une configuration minimale de sécurité pour les... postes utilisés à distance. Mettre en place une politique claire de télétravail et d'accès distant, synchronisé avec les RH. Améliorer la détection des connexions suspectes. Ils ont les logs, mais ils ne la regardent pas. Documenter tous ces risques dans le registre des risques. Puis réaliser une véritable analyse coût-bénéfice, au lieu de répondre simplement aux plaintes. Et j'ai appris plus tard que cette histoire n'était pas un exercice. Le CIO voulait réellement mettre en oeuvre cette solution. Finalement, ils sont revenus au HTTPS. Mais ce n'est pas ce que j'ai retenu de cette mission. Ce que j'ai retenu, c'est qu'un bon consultant ne vend pas des réponses, il vend des questions. Parce que les bonnes questions permettent souvent au client de découvrir lui-même la bonne réponse. Et ça, aucune technologie ne l'a rendu obsolète. Et si dans ton quotidien, tu te retrouves face à une décision de sécurité ? Tu sais, ce genre de situation où plusieurs solutions sont possibles. Tu hésites entre sécurité, contraintes, métier, budget ou expérience utilisateur, ou simplement Tu te demandes quelles sont les bonnes questions à poser avant de décider. C'est exactement pour ça que j'ai créé Compliance Without Coma SOLO. Tu peux me remettre ton cas concret, ton architecture, ton analyse de risque ou simplement une décision qui te fait hésiter. L'objectif n'est pas que je décide à ta place. L'objectif est de t'aider à poser, à te poser, les bonnes questions. Et avec l'académie, l'objectif va encore plus loin parce que tu vas apprendre à raisonner comme un consultant ou un CISO. Tu comprends pourquoi une mesure est pertinente et dans quel contexte elle ne l'est plus. Tu développes ton jugement plutôt que d'appliquer des recettes toutes faites. Et tu progresses grâce à des cas réels, ceux que je rencontre sur le terrain depuis plus de 20 ans. Parce qu'au final, une certification valide des connaissances. Mais c'est ton raisonnement qui fera la différence. Le jour où quelqu'un te demandera, comme moi ici en interview, qu'est-ce qu'on fait ? Que proposes-tu ? Si cet épisode t'a plu, partage-le avec quelqu'un, un collègue qui répond un peu trop vite aux problèmes de sécurité, ou avec quelqu'un qui pense qu'une bonne réponse vaut toujours mieux. Que de bonnes questions. Et si tu veux vraiment soutenir le podcast, prends 30 secondes de ton temps, s'il te plaît, mets 5 étoiles sur Spotify ou Apple Podcasts, et va jeter un oeil à l'épisode sur YouTube. La narration y est différente. Merci d'être toujours plus nombreux à rejoindre les Coma Breakers. On se retrouve vendredi prochain, déjà, pour un nouvel épisode de Compliance Without Coma. D'ici là, continue à poser les bonnes questions et prends soin de toi, Coma Breaker.
