Speaker #0Son œuvre a largement influencé d'autres domaines, notamment l'architecture moderne avec le mouvement Baos et le corbusier, le design graphique et industriel avec la marque de vélo Look dans les années 80, ainsi que la mode avec Yves Saint Laurent qui créa une célèbre collection inspirée de Mondrian en 1965. Et sans le savoir, Mondrian a même influencé la cybersécurité. D'une certaine manière, Pete Mondrian cherche à trouver une représentation minimale en réduisant au maximum les éléments dont il a besoin. Et bien c'est exactement ce que l'on cherche à faire quand on travaille sur le renforcement d'un système, ce qu'on appelle en anglais le hardening, éliminer tout ce qui est superflu pour ne garder que l'essentiel et réduire ainsi la surface d'attaque. Mais vous ne le savez peut-être pas, mais quand vous installez un système, que ce soit un système d'exploitation, un logiciel ou même un composant réseau comme un firewall, le système arrive avec tout un ensemble de paramètres par défaut. Le plus connu et le plus problématique, c'est le compte administrateur de la machine avec souvent comme mot... passe et identifiant le très célèbre admin admin c'est à dire que l'identifiant du compte est admin et que son mot de passe est également admin vu comme ça on voit tout de suite qu'il ya un problème de sécurité majeur mais en réalité il y a bien plus de paramètres de ce genre à prendre en compte pensez par exemple au service qui tourne d'office sur la machine un service c'est par exemple un moyen de se connecter à la machine comme le ftp ou le telnet ces protocoles sont obsolètes depuis depuis des années et pourtant, Il n'est pas rare de les voir activés par défaut sur un système juste après son installation. Revenons à notre artiste, Pete Boundrian. Rappelez-vous, il cherchait à atteindre l'essence même de la représentation visuelle en éliminant tout ce qui n'était pas strictement nécessaire. Pas de courbes, pas de couleurs superflues, pas de détails inutiles. Seulement les lignes droites, les angles droits et quelques couleurs primaires. L'hardening, c'est exactement la même philosophie appliquée à la cybersécurité. L'idée est simple. Chaque service, chaque... Chaque port ouvert, chaque fonctionnalité activée représente une porte d'entrée potentielle pour un attaquant. Et donc, tout comme mandrillant éliminer les éléments superflus sur ces toiles, nous devons éliminer tous les services, fonctionnalités et configurations qui ne sont pas strictement nécessaires au fonctionnement de notre système. Mais pourquoi les configurations, par défaut, sont-elles aussi dangereuses ? Laissez-moi vous expliquer pourquoi les fabricants livrent leur système avec autant de fonctionnalités activées par défaut. La raison est purement commerciale. Ils veulent que leur produit soit le plus simple possible à utiliser dès le déballage. Imaginez que vous achetiez un nouveau roteur dans votre entreprise. Si vous deviez passer 3 heures à configurer manuellement chaque service avant de pouvoir l'utiliser, vous ne serez pas très content. Alors les fabricants activent tout par défaut. FTP pour le transfert de fichiers, Telnet pour l'administration à distance, SNMP pour la supervision, ainsi que des comptes génériques pour la configuration initiale, etc. Le problème, c'est que cette facilité d'utilisation se fait au détriment de la sécurité. Pire encore, beaucoup d'administrateurs système ne prennent jamais le temps de désactiver ses services après l'installation. Ils laissent tout tel quel, créant ainsi des vulnérabilités béhérentes dans votre infrastructure. Alors concrètement, quels sont les éléments qu'il faut impérativement sécuriser lors du hardening d'un système ? Passons-les en revue. Premièrement, les comptes utilisateurs et les mots de passe par défaut. C'est la base absolue de la cybersécurité. Tout système livré avec des comptes par défaut doit voir ses comptes soit supprimés, soit sécurisés immédiatement. Le fameux admin-admin n'est que la partie émergée de l'iceberg. Il existe des bases de données entières recensant les identifiants par défaut de milliers d'équipements. Et tout y passe. routers qui sont caméras de surveillance, imprimantes réseau, serveurs, etc. Les attaquants connaissent et s'identifient par cœur et les testent systématiquement. La première étape du hardening consiste donc à changer tous les mots de passe par défaut par des mots de passe forts et uniques, désactiver ou supprimer les comptes génériques non utilisés, implémenter une politique de mots de passe robuste, avec une longueur minimale, une certaine complexité et une date d'expiration. Mais aussi mettre en place l'authentification multifacteur quand c'est possible. Parlons maintenant des services. Chaque service qui tourne sur votre machine est comme une fenêtre ouverte dans votre maison. Même si vous avez fermé la porte à clé, quelqu'un pourrait entrer par la fenêtre que vous auriez laissée ouverte par négligence. Prenons l'exemple du FTP, FTP pour File Transfer Protocol. C'est un protocole qui date des années 70 et qui permet de transférer des fichiers entre machines. Le problème, il transmet tout en clair, y compris les identifiants et le mode passe. N'importe qui qui écoute le trafic réseau peut intercepter ces informations. Pourtant de nombreux systèmes, l'active encore par défaut. Un autre exemple, Telnet, c'est un protocole d'administration à distance qui lui aussi transmet tout en clair. Il devrait être remplacé systématiquement par SSH pour Secure Shell qui chiffre toutes les communications. La démarche du hardening consiste donc à faire l'inventaire de tous les services actifs sur la machine, se poser la question pour chacun, ai-je réellement besoin de ce service, désactiver tout ce qui n'est pas strictement nécessaire, Et pour les services nécessaires, s'assurer qu'ils utilisent des versions sécurisées et à jour. Intimement liés aux services, les ports réseau sont des numéros qui permettent d'identifier quel service répond à quelle requête. Par exemple, le port 80 est traditionnellement utilisé pour le web, le HTTP, le port 443 pour le web sécurisé, le HTTPS, et le port 22 pour le SSH, et ainsi de suite. Chaque port ouvert est une cible potentielle. Les attaquants utilisent des outils de scan de port pour Identifier quels ports sont ouverts sur votre système, puis ils essaient d'exploiter les services qui écoutent sur ces ports. Le principe du hardening ici est simple, ne laisser ouverts que les ports strictement nécessaires, et filtrez l'accès à ces ports par un firewall. Si votre serveur web n'a besoin que du port 80 et 443, tous les autres ports doivent être fermés. Au-delà des services réseau, il faut aussi penser aux fonctionnalités logicielles activées par défaut. Par exemple, beaucoup de systèmes d'exploitation activent par défaut le partage des fichiers, l'exécution de scripts ou encore des protocoles de découverte réseau qui diffusent des informations sur votre machine. Chacune de ces fonctionnalités peut être exploitée par un attaquant. Le principe reste le même, si vous n'en avez pas besoin, désactivez-le. Un autre aspect crucial du hardening concerne la gestion des privilèges. Trop souvent, les utilisateurs et les applications fonctionnent avec des droits administrateurs alors qu'ils n'en ont pas vraiment besoin. C'est ce qu'on appelle le principe du moindre privilège. Chaque utilisateur, chaque application, chaque service ne doit avoir que les droits strictement nécessaires à son fonctionnement, et pas plus. Si un attaquant compromet un compte utilisateur standard, les dégâts seront limités. Mais s'il compromet un compte administrateur, il aura les clés du royaume. Maintenant que nous avons vu les différents éléments à sécuriser, voyons comment mettre en œuvre concrètement un processus de hardening. Avant de commencer à sécuriser quoi que ce soit, il faut savoir où on en est. Cela passe par un audit complet du système. Quels services sont actifs ? Quels ports sont ouverts ? Quel compte utilisateur existe ? Quelles sont les configurations actuelles ? Quels logiciels sont installés ? Il existe des outils automatisés qui réalisent ces audits, comme Nmap pour scanner les ports, ou des scripts spécifiques pour analyser les configurations du système. Une fois l'audit réalisé, il faut définir précisément ce dont vous avez besoin. Posez-vous les bonnes questions. Quel est le rôle de ce système ? Quels services doivent être absolument attractifs ? Qui doit pouvoir y avoir accès et comment ? Quelles sont les fonctionnalités critiques ? C'est exactement comme Mandrian qui se demandait de quoi ai-je vraiment besoin pour exprimer un message ? Des lignes, des couleurs primaires, et c'est tout. C'est le moment de passer à l'action. Méthodiquement, vous allez désactiver tous les services non nécessaires, fermer tous les ports inutiles, changer tous les mots de passe par défaut, supprimer ou désactiver les comptes inutilisés, réduire les privilèges au strict minimum, désactiver les fonctionnalités superflues et appliquer les derniers correctifs de sécurité. Attention, après avoir appliqué vos mesures de hardening, Il est crucial de tester que le système fonctionne toujours correctement. Vous ne pouvez pas découvrir en production que vous avez désactivé un service critique. Testez toutes les fonctionnalités essentielles. Vérifiez que les utilisateurs légitimes peuvent toujours accéder au système et assurez-vous que les performances n'ont pas été dégradées. Le hardening n'est pas une opération ponctuelle, c'est un processus continu. Documentez toutes les modifications que vous avez apportées, créez des procédures standards et mettez en place un processus de révision régulier. De nouvelles vulnérabilités sont découvertes régulièrement, de nouveaux correctifs sont publiés et vos besoins peuvent évoluer. Votre configuration de hardening doit suivre ces évolutions. Heureusement, vous n'avez pas à réinventer la roue. Il existe des standards et des guides de hardening reconnus dans l'industrie. Les plus connus sont les benchmarks du CIS pour Center for Internet Security. Ils proposent des guides détaillés pour sécuriser pratiquement tous les systèmes courants, Windows, Linux, bases de données, etc. Il y a aussi les STIG pour Security Technical Implementation Guide du département de la défense américaine. Il y a aussi en France les recommandations de l'ANSI pour l'Agence Nationale de la Sécurité des Systèmes d'Information. Ces guides fournissent des listes de vérification détaillées, des scripts automatisés et des explications pour chaque mesure de sécurité recommandée. Un autre aspect crucial à prendre en compte, c'est le cycle de vie du hardening. D'un point de vue pratique, il est extrêmement difficile de s'assurer que la mesure de renforcement reste en place dans le temps. Et ce, pour une raison très simple. Votre système d'information évolue en permanence. Pensez-y un instant. Au quotidien, vous devez installer de nouvelles machines, appliquer des correctifs de sécurité, Déployer de nouvelles applications, mettre à jour des logiciels existants, modifier des configurations pour répondre à de nouveaux besoins, etc. Chacune de ces actions, aussi anodines soient-elles, peut potentiellement modifier ou annuler vos règles de renforcement. Il n'est pas rare de constater que ces opérations d'intens modifient les règles de renforcement, et cela peut arriver de plusieurs manières. Imaginez les situations suivantes. Votre équipe doit installer une mise à jour critique sur un serveur de production, Mais cette mise à jour nécessite temporairement d'activer un service que vous aviez désactivé lors du hardening initial, disons un accès à FTP pour transférer rapidement des fichiers volumines. L'opération se déroule en pleine nuit, sous pression. L'équipe active le service FTP, effectue la mise à jour, vérifie que tout fonctionne et rentre se coucher, soulager que tout se soit bien passé. Mais dans la précipitation, personne ne pense à désactiver à nouveau le service FTP. Et voilà, ce port qui était fermé depuis des mois, Cette vulnérabilité que vous aviez éliminée est de retour. Et elle restera ouverte jusqu'à ce que quelqu'un s'en rende compte. Si toutefois, quelqu'un s'en rend compte un jour. Un autre cas de figure, encore plus insidieux. L'opération modifie la configuration de votre système sans que vous le sachiez. Comment est-ce possible ? Prenons l'exemple d'une mise à jour automatique d'un logiciel. Le fabricant a décidé d'activer une nouvelle fonctionnalité par défaut dans cette version. Cette fonctionnalité, bien sûr, ouvre un nouveau port réseau ou active... un nouveau service. Votre système se met à jour automatiquement pendant la nuit, et au réveil, votre configuration de hard-learning a été partiellement défaite, sans que personne ne s'en aperçoive. Ou encore, imaginez qu'un illustrateur installe une nouvelle application sans se rendre compte qu'elle vient avec ses propres services et dépendances. Ces services s'activent automatiquement et contournent vos règles de sécurité. Il est 3h du matin, votre système de production est en panne. Les clients ne peuvent plus accéder aux services. Chaque minute de downtime coûte des milliers d'euros. L'équipe technique identifie le problème. Il faut ouvrir temporairement un accès pour qu'un prestataire externe puisse intervenir. Dans l'urgence, on ouvre l'accès. Le problème est résolu, tout le monde est soulagé. Mais dans le chaos de la résolution de l'incident, personne ne documente cette modification temporaire et personne ne pense à refermer l'accès une fois la crise passée. Face à ces risques, il est crucial de mettre en œuvre des contrôles automatisés pour vérifier le plus souvent possible que vos règles de renforcement sont toujours bien en place. Il existe aujourd'hui de nombreux outils qui permettent d'automatiser ces vérifications. Les scanners de conformité, ces outils comparent régulièrement la configuration actuelle de vos systèmes avec votre baseline de sécurité, c'est-à-dire votre configuration de référence. Ils vous alertent immédiatement si quelque chose a changé. Les systèmes de gestion de configuration, des outils comme Ansible, peuvent non seulement détecter les déviations par rapport à votre configuration sécurisée, mais aussi les corriger automatiquement. Si un service indésirable est activé, Le système peut le désactiver automatiquement sans intervention humaine. Les solutions de titre continuent. Elles scrutent en permanence vos systèmes et génèrent des rapports de conformité. Vous savez ainsi en temps réel quel pourcentage de vos machines respecte vos règles de hardening. Une approche particulièrement efficace consiste à traiter votre configuration de hardening comme du code. Vous définissez dans des fichiers textes, versionnés dans un système de gestion de version comme Git, exactement quelle doit être la configuration de chaque type de système. Ensuite, des outils automatisés appliquent et vérifient régulièrement que cette configuration est bien en place. Si quelqu'un modifie manuellement la configuration d'une machine, Le système la remet automatiquement dans l'état désiré lors du prochain contrôle. C'est un peu comme si vous aviez un gardien qui, toutes les heures, passe vérifier que toutes les portes et les fenêtres de votre maison sont bien fermées, et le referme si quelqu'un les a ouvertes. Maintenant, abordons un autre dilemme fondamental. Est-ce que toutes les machines doivent être renforcées de la même manière ? La réponse est à la fois oui et non. Mais laissez-moi vous expliquer pourquoi. D'un point de vue purement sécuritaire, Il lui aurait du sens à appliquer les mêmes règles de renforcement quel que soit le système, que ce soit une machine de production ou une machine de test, qu'elle soit au fin fond de votre réseau interne ou dans la DMZ, cette zone démilitarisée qui fait l'interface entre votre réseau et Internet. La logique qui soutient ce choix est assez simple et s'appuie sur un principe de défense en profondeur. Si une machine est compromise, quelle que soit sa localisation, il sera possible de l'utiliser comme point d'entrée pour aller plus loin dans le réseau. Prenons un exemple concret. Imaginons qu'un attaquant réussisse à compromettre une machine de test dans votre réseau interne. Cette machine n'émerge rien de critique, juste un environnement de développement pour tester de nouvelles fonctionnalités. Vous vous dites peut-être que ce n'est pas grave, il n'y a rien d'important dessus. Mais voilà le problème. Maintenant que l'attaquant a un pied dans votre réseau, il peut utiliser cette machine comme base pour scanner votre réseau interne, identifier d'autres cibles et progresser vers votre système de production. C'est ce qu'on appelle le lateral movement, le mouvement latéral dans un réseau. Si cette machine de test était renforcée avec le même niveau de sécurité que vos serveurs de production, l'attaquant aurait eu beaucoup plus de mal à la compromettre en premier lieu. C'est le principe du maillon faible, votre sécurité est aussi forte que votre élément le plus vulnérable. Cela dit, cette vision des choses atteint assez vite des limites opérationnelles. Dans la vraie vie, il serait peut-être plus utile et plus efficace d'avoir des niveaux de renforcement différents selon les environnements. Pourquoi ? Parce que la sécurité ne doit pas paralyser l'activité de l'entreprise. Elle doit la protéger tout en permettant aux équipes de travailler efficacement. Prenons l'exemple d'un environnement de développement. Les développeurs ont besoin de pouvoir tester rapidement leurs codes, d'installer de nouvelles bibliothèques, d'expérimenter avec différentes versions de configuration. Si vous appliquez les mêmes restrictions que sur la production, vous allez considérablement ralentir leur travail. Par exemple, vous pourriez autoriser les accès directs depuis la zone de développement vers une machine de test. Les développeurs peuvent se connecter en SSH, déployer leurs codes, Consulter les logs en temps réel, redémarrer les services autant de fois que nécessaire. Est-ce moins sécurisé qu'un environnement de production verrouillé ? Oui. Est-ce que c'est un compromis acceptable compte tenu de la nature de l'environnement ? Probablement. A l'inverse, vous pourriez imaginer qu'une machine de production ne donne aucun accès direct. Personne ne peut se connecter directement dessus, même avec des privilèges administrateurs. La seule chose que l'on puisse récolter, ce sont ces logs d'exécution, qui sont envoyés automatiquement vers un système centralisé de gestion des logs. Comment administre-t-on alors cette machine ? Par des mécanismes automatisés de déploiement et de configuration. Si vous ne vous connectez jamais directement, vous poussez des changements de configuration via un système d'orchestration, et c'est tout. Ainsi, l'environnement de production sera parfaitement isolé, avec une surface d'attaque minimum. Les environnements de test seront un peu plus accessibles, mais ils ne contiennent pas de données sensibles et ne sont pas directement exposés à Internet. Cette approche différenciée s'inscrit dans le concept de zone de sécurité. Vous divisez votre infrastructure en zones distinctes, chacune avec son propre niveau de risque et son propre niveau de renforcement. On pourrait par exemple avoir une première zone de production critique, avec un renforcement maximal, aucun accès interactif, un déploiement automatisé uniquement, des logs centralisés et une surveillance 24h sur 7. Une seconde zone de production standard, avec un renforcement élevé, des accès interactifs limités et fortement contrôlés, des processus de changement strict et des logs centralisés. Et vous pourriez aussi avoir un environnement de pré-production avec des renforcements modérés, un accès plus large pour les équipes d'exploitation et un environnement miroir de la production pour les tests finaux. Et pour finir, un environnement de développement avec un renforcement de base, un accès large pour les équipes de développement et un environnement isolé du reste du réseau pour des contrôles de réseau strict. Cette différenciation repose sur une approche basée sur les risques. Où l'on évalue chaque environnement ? Quelles sont les probabilités d'attaque ? L'exposition à internet, l'accessibilité, quel serait l'impact d'une compromission sur les données sensibles et les critiques des métiers, et quel est le coût opérationnel d'un renforcement maximum. En fonction de ces trois facteurs, on définit le niveau de renforcement approprié. En définitive, le choix entre uniformité et différenciation dépend de votre contexte, la taille de votre entreprise, la nature de vos activités, vos ressources en sécurité, votre appétit pour le risque, vos contraintes opérationnelles. Une petite startup avec quelques serveurs pourra peut-être se permettre d'appliquer le niveau de renforcement partout. Une grande entreprise avec des centaines de systèmes devra probablement adopter une approche différenciée pour rester gérable. L'essentiel est de faire un choix conscient et documenté, pas de laisser la situation évoluer au hasard. Et surtout, quel que soit votre choix, mettez en place les contrôles automatisés dont nous avons parlé pour vous assurer que vos règles de hardening, quelles qu'elles soient, restent en place dans le temps. Le hardening n'est pas un projet qu'on termine et qu'on oublie. C'est un processus continu, un combat permanent contre l'entropie qui tend naturellement à affaiblir vos défenses. Comme un jardin qui redeviendrait en friche si on cessait de l'entretenir, votre infrastructure redeviendra vulnérable si vous ne maintenez pas activement votre niveau de renforcement. La clé du succès ? L'automatisation. La surveillance continue est une culture où la sécurité n'est pas vue comme une contrainte mais comme une partie intégrante de toutes les opérations. Revenons une dernière fois à Pete Mandrian. Ses œuvres les plus célèbres, comme Composition avec Rouge, Jaune et Bleu, sont d'une simplicité apparente. Mais cette simplicité est le résultat d'un processus réfléchi d'élimination de tout ce qui n'est pas essentiel. Le résultat est puissant, élégant et intemporel. Le hardening, c'est exactement la même démarche appliquée à la cybersécurité. Un système durci, c'est un système qui ne garde que l'essentiel, qui élimine toutes les surfaces d'attaque inutiles, et qui... par sa simplicité même, devient plus robuste et plus facile à défendre. Alors la prochaine fois que vous installez un nouveau système, pensez à Mandrian. Demandez-vous de quoi ai-je vraiment besoin ? Qu'est-ce qui est superflu ? Et comment le maître du néoplasticisme avait le courage d'éliminer tout ce qui n'était pas strictement nécessaire ? Votre système n'en sera que plus beau, plus pur et surtout beaucoup plus sûr. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Et surtout n'oubliez pas, pour certains, la cybersécurité est un enjeu de vue de mort, c'est bien plus sérieux que ça.
