Améliorer sa sécurité IT #3

Comment protéger son Système d’Information ?

Il est évident que la base de la sécurité IT passe par la formation et la sensibilisation des utilisateurs ainsi que des administrateurs techniques du Système d’Information. Le meilleur “antivirus” reste l’humain devant sa machine qui aura l’habitude de ne pas donner ses identifiants de connexion, de ne pas brancher un média issu de l’extérieur sans précaution, de ne pas consulter des sites dangereux et bien sûr d’ouvrir avec discernement les mails qu’il reçoit.

Mais ce n’est pas de cela dont je veux vous parler. Nous allons nous concentrer ici sur les mesures techniques qui peuvent être prises. SOC, SIEM, antivirus, pare feu applicatif, gestion des identités, cloisonnement des réseaux, IPS, Antispam, Anti DDOS, audit de code, patching… La liste des outils techniques que l’on peut mettre en oeuvre est longue. Alors par où commencer ?

La base: l’urbanisation du Système d’Information

Il semble naturel d’attaquer par ce qui ne coûte rien ou pas grand chose: une architecture IT simple, facile à défendre et régulée.

Simple ici veut dire qu’elle comporte des technologies maîtrisées et un nombre limité de composants à maintenir en condition opérationnelle par votre équipe et vos prestataires.

Facile à défendre implique que l’infrastructure est suffisamment cloisonnée pour limiter les impacts d’un incident de sécurité mais pas au point de faire de son administration un cauchemar pour vos équipes.

Régulée signifie que l’on doit savoir à chaque instant qui a accès à quoi et ce qu’il fait de ses accès.

Simple=Facile à maintenir=Toujours fonctionnel

≠

Simpliste=Incomplet

On emploie fréquemment le terme de “bastion” pour désigner ce qui se trouve derrière un pare feu. Devant celui-ci c’est le chaos et derrière tout est permis. Dans cette conception, presque toute la sécurité repose sur les composants en bordure du Système d’Information et les “gentils” utilisateurs internes ont toute latitude. Le parallèle avec l’univers des châteaux forts a longtemps présidé à la conception de la sécurité du Système d’Information. Hélas, trois fois hélas, le trésor de guerre que constitue les données de l’entreprise doit maintenant être partagé et proposé à la consommation auprès de multiples acteurs internes et externes à l’entreprise et dont le niveau de confiance est parfois très limité. Imaginez un château fort dont le pont levis doit obligatoirement resté baissé pour laisser entrer et sortir des informations. Il y a bien des gardes pour surveiller ce trafic mais trop peu au regard de la quantité et de la complexité des informations à traiter. Et puis comment gérer les “maladresses” des utilisateurs internes ?

Le message est clair: si on ne refonde pas son architecture, on est condamné à essayer de boucher les trous (de sécurité) sans arrêt créés par les nouveaux besoins des métiers.

En fait l’image qui se rapproche le plus d’un Système d’Information actuel est une ville dont les portes permettent de canaliser et réguler le flux des connexions entrantes et sortantes, les rues sont un endroit neutre et la sécurité effectivement gérée au sein de chaque “bâtiment/serveur/service”. Les utilisateurs, qu’ils soient internes ou externes, ne résident plus “en ville” mais au mieux en proche banlieue voir à la campagne. La gestion des bâtiment/serveur/service est réalisée au travers d’un réseau sous la surface inaccessible depuis les rues.

SI-Ville

Filons la métaphore et intéressons nous d’abord aux portes de la ville. Nous avons dit plus haut que c’était ici que les flux entrants et sortants doivent être régulés. Très concrètement il va s’agir de ne laisser entrer et sortir que le trafic qui semble légitime. Seuls les protocoles autorisés peuvent transiter. On bloque les surcharges de trafic et les tentatives d’exploitation des failles protocolaires. Nous pouvons utiliser ici les outils classiques que sont les pare feux stateful et applicatifs, des IDS/IPS et plus récemment des outils anti-DDOS. Mais à la différence du mode “bastion”, il n’y a plus de DMZ ou de double bastion. On ne gère que l’interface entre l’extérieur et l’intérieur de la ville. Comme les utilisateurs “internes” sont désormais logés à l’extérieur de la ville, ils transitent donc par les mêmes briques de sécurité que tout le monde.

Une fois dans les rues de SI-Ville, il n’y a rien d’autre à faire pour les flux que de rejoindre un bâtiment/serveur/service. Ceci implique qu’il ne doit y avoir aucune “trappe” dans la rue permettant à un flux d’atteindre le réseau de gestion technique des bâtiments/serveurs/services. Dans le temps nous aurions déployé un réseau out-of-band. Mais il faut comprendre qu’un Système d’Information aujourd’hui recouvre bien souvent une réalité terrifiante: il peut être étendu entre votre salle machine et celle d’Amazon ou d’Azure pour ne citer que les plus connus et plus probablement celle d’un hébergeur local. Ce réseau d’administration ne peut donc plus rien avoir de physique mais repose sur des réseaux overlay. Très concrètement, cela revient à mettre le flux qui sort de votre réseau dans un tunnel dont il ressort à l’autre bout comme si de rien n’était. Ainsi les machines de chaque côté du tunnel échangent comme si elles étaient sur le même réseau physique (pour aller plus loin, c’est ici).

D’ailleurs les SI-Ville les plus en pointe n’ont même plus de rues. En fait, celles-ci se construisent et se déconstruisent à la volée dès qu’un flux doit passer entre deux points du Système d’Information: c’est le Software Defined Network. Il y a donc encore moins de risque qu’un flux passe par une trappe.

Ce nouveau concept mérite que l’on s’y arrête un peu tant il va jouer un rôle grandissant dans les réseaux de demain. Dans le principe, un réseau “actuel” est très figé et ne possède presque aucune intelligence. Un serveur X, pour dialoguer avec une serveur Y, demande à la cantonade “Où est le serveur Y ?”. Si celui-ci est sur le même réseau, alors le serveur Y lui répond directement et le dialogue s’engage. Si ce n’est pas le cas, alors c’est la passerelle par défaut du réseau qui lui dit “je vais m’en occuper”. Les mécanismes de routage IP se mettent alors en fonctionnement jusqu’à ce que le bon réseau soit trouvé. La passerelle par défaut du réseau dans lequel se situe le serveur Y prend alors contact avec celui-ci et l’échange démarre avec un certain nombre d’intermédiaires entre les deux.

Avec le SDN, cela ne fonctionne plus du tout comme ça. Le serveur X fait toujours la même annonce mais personne d’autre ne lui répondra que le serveur Y et ce, qu’il soit dans la même salle machine ou à l’autre bout du monde !

La magie opère dès que la première trame du flux sort du bâtiment/serveur/service. Le switch sur lequel est branché le serveur X demande à un contrôleur central vers où envoyer ce flux. Le contrôleur central qui connaît toute la topologie du réseau, y compris les liens WAN, va venir programmer tous les équipements réseaux sur le chemin qui vont servir à acheminer le flux vers le serveur Y. Ainsi le serveur X dialogue directement avec le serveur Y même sur une “longue” distance. Le plus beau dans ce type de réseau, c’est que le contrôleur général que l’on appelle plus couramment orchestrateur, est lui-même programmable. C’est à dire que ce sont les applications elles-mêmes qui peuvent venir indiquer des préférences à l’orchestrateur. Par exemple, elle peuvent lui indiquer d’éviter tel ou tel secteur du réseau, que ce flux là doit être prioritaire sur les autres,… Bref, on a fait d’un réseau… une application. Et qui dit application dit sécurité d’application. Je digresse un peu mais que se passerait-il si un programme malicieux s’emparait de l’orchestrateur? Que se passerait-il également si celui-ci devenait indisponible ? (pour aller plus loin, c’est ici)

Exemple d’un SDN en image

Voilà maintenant notre flux au pied d’un bâtiment/serveur/service. Pour y pénétrer, il doit provenir d’une source autorisée. Il est ensuite identifié, authentifié et autorisé. Enfin toute son activité est tracée. Mais cela peut ne pas suffire: un intrus peut avoir volé des identifiants valides. Il faut donc en dernier ressort que l’application soit suffisamment robuste et cloisonnée pour que même un utilisateur autorisé ne puisse pas porter atteinte à son intégrité. On met en oeuvre ici les derniers piliers de la sécurité informatique: la gestion des identités, la qualité du code et pourquoi pas les antivirus qui ont, quoi qu’on en dise, énormément progressés depuis quelques années.

Bien que la métaphore puisse prêter à sourire, ce type d’architecture règle un certain nombre de problèmes:

• les utilisateurs internes peuvent être “maladroits” sans que cela ne porte trop à conséquence
• les évolutions des besoins métiers ne remettent pas en cause à chaque instant la sécurité de l’infrastructure
• la transition vers des infrastructures hybride/on-premise peut se faire en souplesse sans remettre en cause les fondements de l’architecture
• grâce aux règles d’ingénierie qu’implique le concept de bâtiment/serveur/service, il est facile de provisionner de façon industrielle un nouvel environnement ou une nouvelle application avec un haut niveau de sécurité sans que celui-ci ne baisse dans le temps

On vient de le voir: l’architecture du Système d’Information a un rôle prépondérant pour l’atteinte d’un objectif de sécurité. Il est nécessaire de partir sur une base saine qui sera d’autant plus aisée à sécuriser qu’elle aura été rationalisée.

Corréler pour mieux défendre

La surveillance de la sécurité IT relève de la pensée systémique. Appliquée à l’informatique cela consiste à regarder et rapprocher des événements individuels survenus de sources diverses dans le Système d’Information mais dont la cause pourrait être unique. L’objectif de cette approche est de modéliser et mettre en évidence ce qui est en train de se passer, et de faire ressortir d’un brouillard d’informations un ou des évènements spécifiques.

C’est le rôle d’un SIEM (Security Information & Event Management) et c’est le l’outil principal du SOC (Security Operating Center).

Chaque outil de sécurité, mais pas uniquement ceux-ci, remonte ce qu’il voit au SIEM qui se charge de trier, classer, prioriser et enfin agréger ces informations afin que les opérateurs du SOC puissent organiser une réaction aux événements identifiés.

Fonctionnalités d’un SIEM (Source: ManageEngine.com)

En se basant essentiellement sur les logs des différents équipements, le SIEM va permettre de réaliser l’analyse et la corrélation des informations. Dans ces équipements, on retrouve les firewalls, IDS/IPS, Antivirus, reverse-Proxy mais aussi les serveurs et les composants applicatifs eux-mêmes. Et cette liste est loin d’être exhaustive… Une chose est sûre: moins il y aura d’équipements à surveiller, plus la mise en place de la collecte sera simple. Ce qui va dans le sens de la simplification de l’architecture de votre Système d’Information: plus il y a de portes à votre ville, plus il y aura de points de passage à surveiller. Il en va de même avec les bâtiments/serveur/service: ceux-ci peuvent être nombreux. Par contre s’ils sont tous plus ou moins identiques leur intégration au SIEM en sera grandement facilitée.

Sa limite, c’est qu’il ne sait pas le faire tout seul ! En effet, un SIEM n’est pas capable de générer seul les règles qui permettront de rapprocher les informations entre elles. Ce travail est dévolu à des experts de la sécurité qui devront écrire pour ainsi dire une à une ces règles. Il y a donc beaucoup de temps à passer par des ressources humaines très coûteuses pour un résultat souvent difficile à maîtriser. La mise au point de ces règles passe en général par de nombreuses fausses alertes qu’il est nécessaire de vérifier une à une avant de parvenir à un alerting de qualité.

Comment surmonter cette difficulté ? Certains croient en ce que l’on appelle le “Security Analytics”. Ce que l’on peut définir comme une surcouche du SIEM a pour mission justement d’automatiser la création de règles et ainsi limiter le besoin en compétence humaine pour mettre en oeuvre une telle plateforme. D’après plusieurs spécialistes de la question, dont Anton Chuvakin, vice-président de la recherche chez Gartner, cela ne semble qu’une belle promesse commerciale: (https://www.scmagazine.com/rsa-2016-gartner-tries-to-demystify-security-analytics/article/528845/).

N’en n’ayant jamais déployé, je n’ai pas d’opinion personnelle sur le Security Analytics. Par contre, je peux vous certifier que la mise en place d’un SIEM est une véritable gageure ! Il faut donc à tout prix faire le choix d’un périmètre initial restreint et parfaitement maîtrisé pour réussir son implantation.