Règle #1 : Cloisonner son SI interne !

Ah la confiance… cette précieuse denrée qui a fait prendre aux architectes et aux urbanistes des systèmes d’information (SI) des choix très… étonnants… au cours des deux dernières décennies.

Non mais sérieux, pourquoi cloisonner notre SI interne ? 🤔

« Nous sommes entre nous, dans un cadre de confiance… »

« Ce sont nos collègues, qui travaillent à côté… »

« Les prestataires à demeure dans nos locaux… ils sont aussi de confiance…
Nous les avons d’ailleurs invités à notre Team Building… »

« De toute façon, on participe régulièrement à des tests de “phishing” et notre score s’améliore d’année en année! »

« C’est pas comme s’il suffisait d’un seul clic pour faire écrouler tout l’édifice…“

👉Pourquoi sortir de ce fameux “réseau à plat”, où toutes les machines voient toutes les autres machines ?

👉Pourquoi passer un minimum de temps à se demander s’il y a une justification métier ou technique à ce que telle ressource IT voit telle autre ressource IT ?

👉Pourquoi se tracasser la tête à mettre en place des zones de sécurité (VLAN), pourtant hyper démocratisées avec les “smart switches” DÉJÀ EN PLACE sur le SI ?

👉 Pourquoi se mettre dans la peau d’un attaquant et d’identifier les chemins d’attaque possible ? 

Toujours ces mêmes biais cognitifs qui nous paralysent et qui nous empêchent d’imaginer des scenarii qui peuvent tourner mal !
(Ceci dit on a une parade pour ça, les Hacker Stories©)

Voici comment un attaquant ou encore un pentester qui “joue” éthiquement le rôle d’un attaquant va procéder :

1. Mettre un “doigt de pied” sur votre SI, grâce à un accès physique aux locaux, au réseau WiFi et/ou aux prises Ethernet brassées (par exemple dans une salle de réunion pendant que l’hôte s’absente pour chercher le café) ou encore obtenu à distance via un VPN ou un clic malheureux sur un lien d’hameçonnage.
2. Obtenir une adresse IP, probablement par DHCP, à moins que la règle #2 ne soit mise en place (c’est le sujet d’un prochain article 🤫)
3. Scanner son environnement…

… Il se retrouve alors dans un labyrinthe plus ou moins lisible, plus ou moins permissif, plus ou moins complexe.

Un système d’information dit “à plat” correspond à un labyrinthe tellement lisible et permissif en termes de sécurité réseau, qu’il ne mérite d’ailleurs pas d’être affublé du mot “labyrinthe” : cela signifie que tout utilisateur d’un réseau voit… l’ensemble des appareils connectés au réseau 😅

Attention ici à une idée reçue, souvent mise en avant par les équipes IT :

Certes le réseau est « à plat » mais il faut des mots de passe pour se connecter aux applications métiers ! 🔐

Encore heureux … nous rétorquons !

Souvent les équipes IT ont tendance à confondre sécurité réseau avec sécurité système et sécurité applicative, des vases communicants qui sous-tendent la sécurité des systèmes d’information et qui se doivent à tout moment d’être équilibrés – nous aurons d’ailleurs l’opportunité d’y revenir lors d’un prochain billet.

Ainsi, une multitude d’adresses IP et autant de services TCP/UDP en écoute viennent peupler cette très large surface d’attaque. (D’ailleurs, notre produit Knock.Xplore© automatise cette cartographie et ce recensement.)

Il va donc de soi que pour retarder l’attaquant :

Il faut complexifier le labyrinthe et donc réduire cette surface de visibilité, et ce en cloisonnant le système d’information. 🦾🤖

Comment faire alors ?

Voici quelques pistes qui vous permettront d’amorcer cette action qui mettra en place des “gestes barrières réseau” au sein de vos systèmes d’information :

• Recenser l’ensemble de vos ressources IT : end points, serveurs et objets connectés, que ces ressources vous appartiennent ou appartiennent à vos éditeurs (coucou Usine 4.0 et IoT)
• Attribuer à chacune des ressources un identifiant unique
• Constituer une matrice, que nous aimons appeler la matrice des “0” et des “1” qui affiche à la verticale et à l’horizontale ces ressources IT identifiées – oui ça fera un gros fichier .xls, mais vous maîtrisez l’outil non ? 😉
• Lisez la matrice de gauche à droite en vous posant la question suivante : est-ce que la ressource N devrait voir en terme réseau la ressource M – exemple : est-ce que le poste de l’agent de l’accueil doit voir le poste du DRH ?
  • Si la réponse est NON, vous mettez un “0”
  • Si la réponse est OUI, vous mettez un “1” 
  • Pour chaque “0” :
    • Vous prenez votre plus belle paire de ciseaux et vous coupez ce câble Ethernet qui relie N à M, 
    • Ou plus sérieusement, vous définissez une liste de contrôle d’accès ou ACL pour couper cette route réseau,
    • Ou vous définissez ce qui est communément désigné par zone de sécurité ou VLAN, grâce à vos switchs intelligents. 
  • Pour chaque “1” : 
    • Vous conservez cette route réseau,
    • Vous identifiez précisément les flux TCP/UDP qui ont BESOIN d’y transiter
    • Vous implémentez des listes de contrôle d’accès étendues ou blen vous définissez des règles de filtrage au niveau de votre pare-feu

Il est certes fortement conseillé de dérouler cette démarche dès la conception d’un SI, by design, cela sera plus rapide et nettement moins coûteux. 🚀

Toutefois, il faudra également faire cela a posteriori, sur un SI existant. Certes, cela prendra un peu de temps mais c’est un chantier incontournable si d’aventure on souhaite retarder efficacement un attaquant. 🏗️

Pour vous qui êtes arrivé à la fin de cet article, selon vous, où est-ce qu’on devrait trouver plus de “1” que de “0” :

• Réponse A : Dans la matrice d’un SI en cours de conception ?
• Réponse B  : Dans la matrice d’un SI existant ?