Quels qu’ils soient le périmètre technologique, le contexte organisationnel et le cadre réglementaire, les principes de sécurité suivants ont une valeur pratiquement universelle.

Connaître ses actifs : la première chose à faire quand on souhaite protéger son patrimoine informationnel est d’en acquérir une connaissance précise.

Cela passe par la formalisation d’un inventaire, souvent implémenté dans une CMDB (Configuration Management DataBase), concept emprunté par la cybersécurité au référentiel ITIL.

Il est très important d’identifier un responsable pour chaque actif, soit en tant que personne physique (par exemple : Responsable Réseau), soit en tant qu’équipe ou service (par exemple : Service RH).

Un défaut d’exhaustivité de l’inventaire, ou une définition manquante ou imprécise des responsabilités, mènent inexorablement à la création de “zones d’ombre”, où les règles de sécurité ne sont pas appliquées et les vulnérabilités ont tendance à proliférer. Citons l’exemple d’un serveur oublié dont personne ne connaît la fonction et personne ne s’occupe de ses mises à jour de sécurité : ce serveur “poussiéreux” constitue une porte d’entrée de premier choix pour un attaquant à la recherche du maillon faible d’un système d’information.

Il est intéressant de remarquer que la connaissance des actifs est significativement facilitée par le déploiement de solutions d’inventaire automatisées : quand on répertorie les éléments “à la main”, on s’expose à l’erreur humaine, à un défaut d’exhaustivité et à un défaut de mise à jour (inventaire toujours en retard par rapport à la réalité).

Notons que la méthode de déploiement “Infrastructure as Code”, adoptée principalement dans les clouds publics (à travers des outils comme Terraform, AWS CloudFormation, Azure Resource Manager), aide à garder un suivi précis et nativement versionné des éléments d’une infrastructure.

Il faut aussi noter que les fournisseurs de cloud public fournissent des solutions “as a service” pour gérer l’inventaire des actifs déployés, l’exemple le plus parlant étant peut-être le service AWS Config.

Principe de défense en profondeur : il s’agit d’une technique qui vise à retarder ou à démotiver l'attaquant, en employant plusieurs mesures de sécurité, afin de réduire le risque lorsqu'une mesure particulière est contournable ou défaillante. On le désigne aussi sous le nom de défense multicouche.

La pertinence de ce concept est probablement plus compréhensible quand on pense à la sécurité des biens physiques plutôt qu’à la sécurité des informations. Par exemple, quand on souhaite protéger des locaux en appliquant une défense en profondeur, on déploie plusieurs couches de sécurité : mur d’enceinte, barrière, tourniquet, système de badges à l’entrée, caméras de vidéosurveillance, alarme, etc.

Par analogie, quand il s’agit de protéger un système d’information, ce principe est implémenté en déployant plusieurs familles de mesures de sécurité, que ce soit d’un point chronologique par rapport au déroulement d’un incident de sécurité (mesures dissuasives, préventives, de détection, correctives et de restauration), ou par catégorie (mesures techniques/logiques, physiques, administratives).

Décrivons plus en détail les mesures de sécurité par positionnement chronologique :

- Mesures dissuasives : elles visent à décourager une violation, en essayant d’influencer un attaquant afin qu’il renonce à passer à l’acte, ou qu’il se tourne vers une autre cible. Exemples :

- Obligation pour les employés de signer une charte de bonne utilisation du système d’information, qui prévoit des mesures disciplinaires en cas de transgression

- Affichage d’avertissements lors de la connexion à l’interface d’administration d’un système sensible

- Obtention de certifications de sécurité et communication autour de cela

- Mesures préventives : elles visent à empêcher la survenue d’incidents de sécurité, en bloquant l’attaque à ses débuts. Exemples :

- Déploiement d’un pare-feu applicatif qui filtre les requêtes web malveillantes dirigées vers le site à protéger

- Chiffrement des données sensibles

- Déploiement d’un système d’authentification multifacteur

- Mesures de détection : elles visent à identifier une activité malveillante, potentiellement liée à une compromission du système d’information. Exemples :

- Déploiement d’un IDS (Intrusion Detection System).

- Déploiement d’un SIEM (Security Information and Event Management)

- Achat des services d’un SOC (Security Operations Center)

- Mesures correctives : elles visent à répondre efficacement à une attaque. Exemples :

- Déploiement d’un anti-malware capable de bloquer une tentative d’infection

- Application d’un patch capable de corriger une faille exploitée par un attaquant

- Déconnexion du réseau d’un système compromis

- Mesures de restauration : elles visent la reprise d’activité à la suite d'un sinistre éventuellement lié à un incident de sécurité. Exemples :

- Mise en place d’un PRA (Plan de Reprise d’Activité) et déclenchement en cas de besoin

- Restauration des sauvegardes à la suite d'une infection de type cryptolocker

- Activation du télétravail pour permettre aux employés de continuer à travailler en cas d’indisponibilité du site sinistré

Et voici le détail des catégories de mesures de sécurité :

- Mesures techniques, appelées aussi logiques : elles agissent principalement sur les données en format électronique. Exemples :

- Configuration d’une interdiction de branchement de clés USB personnelles

- Déploiement d’un serveur proxy pour filtrer le trafic web des employés

- Déploiement d’une solution MDM (Mobile Device Management) pour gérer la conformité de la flotte de téléphones mobiles

- Mesures physiques : elles visent surtout la protection des locaux et des biens matériels. Exemples :

- Mise en place d’un sas unipersonnel pour réguler l’accès à une salle serveurs

- Déploiement de lecteurs biométriques pour réguler l’accès à des zones sensibles

- Déploiement d’un système anti-incendie dans une salle serveurs

- Mesures administratives : elles se basent sur des documents écrits (politiques, chartes, contrats, assurances). Exemples :

- Définition d’une politique de sécurité

- Définition, dans un contrat de sous-traitance, de clauses spécifiques à la sécurité de l’information (taux de disponibilité des systèmes, fréquence d’application des sauvegardes, obligation de remplacer les systèmes obsolètes, etc.)

- Définition d’une charte d’administration des systèmes informatiques, réservée au personnel technique

Principe du moindre privilège : on accorde à un utilisateur les permissions minimales pour qu’il puisse accomplir son travail. L’idée de base est que toute permission non nécessaire peut donner lieu à des abus, soit par l’utilisateur en question, soit par un attaquant qui aurait pris contrôle du compte.

Une simple application de ce principe est la non-attribution aux employés des droits d’administration sur leur poste de travail, d’un côté pour interdire l’installation “sauvage” de software potentiellement dangereux (cf. shadow IT), d’un côté pour limiter les conséquences d’une compromission du compte (l’attaquant devra réussir une escalade de privilèges pour “passer administrateur”).

La philosophie du principe du moindre privilège se retrouve dans les déclinaisons suivantes :

- Principe du besoin d’en connaître, qui restreint l’accès aux informations sensibles

- Principe de réduction de la surface d’attaque, qui consiste à désactiver sur un serveur ou équipement réseau tous les services ou composants logiciels non strictement nécessaires, afin de limiter les possibilités d’attaque

- Principe “deny all” dans la configuration des règles des pare-feux, où par défaut tout flux est interdit, et seulement les flux nécessaires sont autorisés

- Préférence du whitelisting au blacklisting : il est préférable d’interdire par défaut et d’autoriser des exceptions, plutôt qu’autoriser par défaut et interdire des exceptions.

Retour d’expérience et réflexions pratiques

- Le fait de maintenir une CMDB exhaustive et à jour est beaucoup plus facile à dire qu’à faire, pourtant l’enjeu est de taille. Toute CMDB maintenue de façon manuelle risque d’avoir un temps de retard par rapport à la réalité, comme évoqué : nouveaux actifs non répertoriés, numéros de version pas à jour, présence de serveurs déjà décommissionnés… Il faut s’appuyer sur un logiciel d’inventaire et se doter d’un processus d’intégration d’actifs qui comporte une étape où on vérifie que les nouveaux actifs “remontent” bien dans la CMDB

- L’application du principe du moindre privilège est aussi plus facile à énoncer qu’à appliquer. Il faut mettre en place des revues régulières des accès, aussi automatisées et fréquentes que possible ; certaines normes imposent une périodicité de trois mois

- Il est relativement fréquent, lorsqu’on réalise une revue des règles d’un pare-feu, qu’on y trouve des règles trop permissives (incluant une permission pour “any”), qui étaient censées être temporaires, le temps d’une session de débogage. Dans ce cas, ce n’est pas immédiat d’assainir la situation, car si on restreint les flux, on risque de rencontrer des effets de bord en coupant des flux légitimes. En pratique, on procède comme ça : monitorer les logs pendant plusieurs jours, identifier les flux légitimes et ensuite restreindre la règle permissive aux flux légitimes, en se tenant prêts à élargir au cas par cas si besoin.

Dans cette conférence, j'aborde plusieurs concepts fondamentaux ; je vous propose cependant de sauter la section

sur la démonstration de piratage, qui ne rend pas très bien à l'écran :