Détection d’intrusion : 5 questions à se poser | Padok Security

Historique et composant d’un système de détection d’intrusion

Les premiers systèmes de détection d’intrusion généraient des logs qui étaient ensuite agrégés et corrélés. Pour parvenir à ce mécanisme, il fallait utiliser des technologies différentes ce qui rajoutait une charge de travail lourde, les implémentations et configurations étant différentes.

Aujourd’hui les technologies cloud et SaaS permettent notamment aux petites entreprises et start-up de se simplifier le travail d’implémentation des systèmes de détection d’intrusion. Il existe différents types de sondes.

• Les EDR (Endpoint Detection and Response ou HIDS) visent à détecter et à répondre aux activités malveillantes sur les endpoints. L'objectif principal de l'EDR est de fournir une visibilité approfondie sur les endpoints afin de détecter rapidement les attaques avancées et de répondre efficacement à celles-ci.
• Les NDR (Network Detection and Response ou NIDS) répondent aux activités malveillantes sur un réseau. Les solutions NDR se concentrent sur la détection des menaces internes et externes dans le réseau.
• Les XDR (Extended Detection and Response) agrègent et corrèlent les données de sécurité provenant de différentes sources et les analysent de manière centralisée.

Les questions à se poser pour déployer son système de détection d’intrusion

Quels sont les scénarios d’attaque les plus graves ?

Tout superviser peut coûter cher et, plus le périmètre surveillé est large, plus il va falloir de ressources humaines pour gérer les alertes, faux positifs et autres. La première chose à faire est donc de déterminer les scénarios d’attaques les plus probables et graves qui peuvent vous toucher.

• Quel est le niveau technique de l’attaquant ? Le but est d’imaginer quel type de profil de pirate pourrait s’en prendre à mes services. Cela ne sert à rien de se protéger contre des grands groupes de cyber attaquant si vous êtes une petite entreprise. Vous adaptez ensuite votre IDS (Intrusion Detection System) au profil de l’attaquant. Si ses ressources sont relativement peu avancées vous pourrez mettre en place un IDS peu avancé.
• Quelles sont les attaques les plus probables ? Définissez les attaques que vos actifs peuvent subir. Vous pouvez vous référer à “OWASP Top Ten” pour avoir une liste des attaques les plus répandues
• Quel est l’impact d’une telle attaque ? Enfin vous devez déterminer si les attaques définies peuvent avoir un impact fort sur vos systèmes. Par exemple dans le cadre d’un code open source, l’impact de sa fuite n’est pas aussi fort qu’un code censé être secret.

Je vous conseille de jeter un coup d'œil à la première étape de la matrice MITR (base de connaissances sur les tactiques et techniques de l'adversaire) pour une analyse plus approfondie des scénarios d’attaque.

Quel environnement dois-je protéger ?

Après avoir évalué les scénarios d’attaques auxquels vous faites face, vous devez déterminer quel(s) environnement(s) vous devez protéger.

Il faut superviser l’ensemble des environnements susceptibles d’être attaqués.

• Définissez ce que l’attaquant vise. Listez les systèmes, informations, processus et utilisateurs à protéger. Vous devez visualiser l’ensemble des actifs de votre infrastructure sensible à des cyberattaques par les attaquants définis au-dessus.
• Quels sont les environnements de mon infrastructure ? Avez-vous des environnements de tests en plus de votre environnement de développement et production ? Si oui, vous devez identifier l’ensemble des points de passage et superviser ces deux environnements. L’attaquant pourrait attaquer votre environnement de développement pour ensuite attaquer l’environnement de production et accéder aux données clients.

Si les environnements sont mal cloisonnés, il faudra sûrement tout superviser pour essayer de détecter l’attaque au plus tôt.

Suis-je hébergé dans le cloud ?

Une infrastructure hébergée dans le cloud va vous permettre d’utiliser des solutions de type SaaS.

• Si vous êtes chez un des grands hébergeurs cloud (AWS, GCP ou Azure) vous avez des solutions déjà implémentées qui vous ménagent la partie collection des données pour un prix relativement bas.
• Vous avez également des solutions de type SaaS pour d’autres hébergeurs pour collecter et agréger les données.

Pour un déploiement on-prem, les précédentes solutions ne sont pas les plus adaptées. Vous pouvez installer un système de détection directement à l’entrée/sortie tel que suricata.

Puis-je envoyer mes logs à l’extérieur de mon infrastructure d’un point de vue réglementaire ?

Vous le savez déjà, de nombreuses réglementations peuvent impacter vos stratégies de déploiement (LPM pour les OIV, PCI DSS pour les services de paiement, HIPAA pour les entreprises de santé et autres règles RGPD). À travers nos différentes missions de protection d’hébergeur de données de santé (HDS), nous avons remarqué que c’est un point toujours préoccupant et chronophage pour les CTOs.

Après avoir identifié les environnements à protéger, vous devrez vérifier que vous pouvez envoyer vos données en dehors de votre infrastructure. Il se peut que votre système de détection d’intrusion soit situé à l’extérieur de votre infrastructure. Ces données peuvent être interceptées ou détournées. Il existe donc un risque de fuite. Vérifiez si les réglementations vous limitent dans vos choix.

Comment installer ma solution de système de détection ?

Une fois une idée des actifs que vous souhaitez protéger et une idée des menaces et scénarios d’attaque possibles. Il faut maintenant définir les ressources que vous avez à disposition.

Mettre en place un IDS se décompose généralement en trois grandes étapes :

• Il y a tout d’abord la partie “implémentation”. Il faut intégrer votre système de détection à votre infrastructure pour qu’il supervise vos actifs.
• Il faut ensuite le configurer. Lors de la mise en place de votre système de détection, il utilisera des règles par défaut que vous voudrez sûrement modifier. Une telle configuration demande un effort humain assez important. Grâce aux questions que vous vous êtes posées auparavant, vous avez pu définir et sûrement réduire votre périmètre à superviser ce qui vous permettra d’alléger cette partie du travail.
• Enfin, la partie “run” est la partie la plus importante car un système de détection se maintient tout au long de son fonctionnement. Il faut le mettre régulièrement à jour avec l’apparition de nouvelles attaques. De nouveaux services déployés peuvent nécessiter l’ajustement des règles de détection de votre système.

Vous devez définir les facteurs humains et financiers à votre disposition. Si vous n’avez pas assez de personnes pour gérer un système de détection, vous pouvez vous rediriger vers des solutions SaaS. Elles prennent en charge la gestion des mises à jour et du matériel.

Cependant une solution SaaS peut vous coûter très cher (cela dépend aussi de la taille de votre infrastructure) et n’est pas adaptée si vous avez un budget limité.

Les solutions existantes d’implémentation d’un système de détection d’intrusion

Nous vous présentons différents types de solution que nous avons pu observer durant nos missions d’audit et pentest d’infrastructures.

• SOC dédié : c’est une solution où une équipe est dédiée à la gestion et au traitement des alertes du système de détection d’intrusion. Ils font ensuite remonter les informations importantes et activités malveillantes et prennent les mesures appropriées. Une telle solution nécessite des moyens humains importants.
• SOC mutualisé : cette solution vous permet de déléguer le travail de la gestion de votre système de détection à d’autres équipes. Cela nécessite que les équipes externes accèdent à votre infrastructure ou bien que vous leur envoyez vos données pour qu'elles les traitent.
• Outil en SaaS : il existe différentes solutions de systèmes de détection de ce type telles que PrismaCloud, LaceWork, Sysdig. Les licences coûtent généralement assez cher (au moins 20k€ / an). Une partie du travail de gestion du système est prise en charge. Cependant, vous devez avoir une personne/équipe dédiée à la supervision des alertes.
• Association de composant opensource et de services managés : si vous êtes chez un fournisseur cloud qui propose des solutions de systèmes de détection d’intrusion, vous pouvez les utiliser. Elles s’intégreront très facilement avec vos autres services et coûtent relativement peu chers.
  Durant nos différentes missions de protection d’infrastructures, nous installons généralement un GuardDuty avec un système Falco (pour les clusters Kubernetes) pour collecter et agréger les données. Nous les exportons ensuite sur Slack ou Opsgénie.

Conclusion

Pour savoir quelle solution convient le mieux à votre entreprise, vous devez d’abord vous demander quels sont les scénarios d’attaque probables. Vous devez ensuite déterminer les environnements et actifs à protéger. Puis, vous devez faire une liste des moyens qui sont mis à votre disposition car cela va limiter le choix de votre solution.

Faire un audit de votre infrastructure pourra vous permettre de faire un tour de table de ce qui est critique et pourra aussi vous aider dans cette décision.