Aller au contenu

Mettre en œuvre les systèmes de détection et de prévention d'intrusion

1. Objectif du cours

Concevoir et déployer une architecture IDS/IPS multi-niveaux (NIDS/NIPS, HIDS, SIEM) pour un hébergeur HDS multi-sites en respectant contraintes opérationnelles et réglementaires. Produire procédures opérationnelles et plans de réponse aux incidents pour protéger les données patients sans interrompre les services.

2. Notions et définitions essentielles

  • NIDS/NIPS : détection/prévention au niveau réseau (passerelles/sondes) ; NIPS en inline pour blocage immédiat.
  • HIDS : détection au niveau hôte (FIM, processus, intégrité fichiers).
  • SIEM / corrélation : centralisation logs et corrélation inter-sites pour enrichir détection multi-outils.
  • Kill chain (séquence observée) : reconnaissance → exploitation → persistance → déplacement latéral → exfiltration.
  • IOC / C2 / webshell : indicateurs observés dans les alertes (IPs C2, webshells, tunnels chiffrés).

3. Fonctionnement et principes

  • Approche multi-niveaux : complémentarité réseau / hôte / journaux pour corrélation fine des événements et identification d'attaques avancées.
  • Priorités sectorielles : protection des VLANs transportant données patients (notamment VLAN 300), inspection des liens inter-datacenters et visibilité sur Azure via agents cloud-native.
  • Détection comportementale vs signatures : privilégier détection comportementale pour le secteur médical ; signatures maintenues et testées régulièrement.
  • Phasage opérationnel (3 mois) : périmètre → monitoring interne → endpoints, avec tests et validation à chaque phase.
  • Contrainte temporelle : MTTD requis ≤ 2 minutes pour détection en temps réel.

4. Commandes et manipulations

Groupées par rôle — éléments extraits du fichier snort.conf et des règles proposées (extraits essentiels uniquement) :

  • Variables réseau (définition périmètre de surveillance)
  • var HOME_NET [192.168.100.0/24,192.168.200.0/24,192.168.300.0/24,192.168.400.0/24] — définit réseaux locaux à protéger.

  • var DMZ_NET 192.168.500.0/24 ; var WEB_SERVERS 192.168.500.10/32

  • Moteur et DAQ (performances / mode)

  • config detection_engine: search-method ac-bnfa ; config detection_engine: split-any-any yes ; config policy_mode: inline

  • config daq: afpacket ; config daq_mode: passive

  • Preprocesseurs TCP/HTTP (inspection flux applicatifs)

  • preprocessor stream5_global: track_tcp yes, ...
  • preprocessor stream5_tcp: policy linux, detect_anomalies, require_3whs, ...

  • preprocessor http_inspect_server: server $WEB_SERVERS ports { 80 443 8080 8443 } chunk_length 4096 post_depth 4096 normalize_headers enable_cookie extended_response_inspection inspect_gzip unlimited_decompress

  • Règles et fichiers de règles (gestion)

  • include $RULE_PATH/emerging-threats.rules ; include $RULE_PATH/community.rules ; include $RULE_PATH/local.rules

  • Sorties et logs (audit)

  • output alert_fast: /var/log/snort/alert.log ; output log_tcpdump: /var/log/snort/snort.log ; output alert_csv: /var/log/snort/alert.csv (timestamp,sig_class,sig_priority,msg,dip,sip)

  • Règles IDS exemplaires (but et SID référencés)

  • SID 1000001 : détection pattern chiffrement (anti-ransomware).
  • SID 1000002 : détection exfiltration SQL (seuils volumétriques).
  • SID 1000003 : détection téléchargement malveillant (APT sector healthcare).
  • SID 1000010/1000011/1000012 : règles pour portail patients (SQLi, upload malveillant, brute force).

5. Sécurité et bonnes pratiques

  • Segmentation précise des variables réseau pour réduire faux positifs et améliorer visibilité (spécifier VLANs).
  • Prioriser protection des données patients dès la phase 1 (obligation HDS).
  • Privilégier détection comportementale et tests avec trafic réel anonymisé avant production.
  • Mise à jour automatisée des signatures (quotidienne, validation en bac à sable avant prod).
  • Objectif taux faux positifs < 2 % avant mise en production.
  • Playbooks automatisés SOAR pour containment rapide (isolation, blocage IPs, sauvegarde des états).
  • Respect réglementaire : chiffrement transit/repos, conservation logs 6 ans, notification CNIL < 72 h.
  • Formation et transfert de compétences (formations Suricata/Snort prévues).

6. Points essentiels à retenir pour le TSSR

  • Prioriser sondes sur passerelles Internet et interconnexions ExpressRoute (flux patients).
  • Protéger en priorité VLAN 300 (BDD patients) et DMZ (portail patients).
  • Déployer NIPS périmètre (Suricata appliances) avant NIDS interne et HIDS.
  • Centraliser logs (ELK/SIEM) pour corrélation inter-sites et enrichissement contextuel.
  • Automatiser mises à jour signatures (quotidien, validation), maintenir FP < 2 %.
  • Tester configurations avec PCAPs historiques et trafic anonymisé.
  • Disposer de playbooks pour isolation immédiate et notification CNIL.
  • Dashboard SOC doit afficher MTTD, couverture flux, taux FP et disponibilité sondes (SLA 99,9 %).
  • Documenter règles custom et réviser mensuellement (RSSI + analyste SOC).
  • Mettre en place FIM/HIDS (Wazuh recommandé) sur endpoints critiques.

7. Tableau récapitulatif

Élément Position / Usage Avantage principal
NIPS (Suricata) Périmètre inline (passerelles) Blocage immédiat des attaques externes
NIDS (Snort) Sondes internes (VLAN critiques) Visibilité et corrélation sans impacter trafic
HIDS (Wazuh) Endpoints / serveurs critiques Détection intégrité/processus au niveau hôte
SIEM / ELK Centralisation logs et corrélation Corrélation multi-sites et reporting HDS

8. Vérifications pratiques

  • Cartographie complète des flux critiques et assets "crown jewels" validée.
  • Variables réseau (HOME_NET, DMZ_NET, WEB_SERVERS) définies et limitées aux VLANs.
  • Tests de signatures : mise à jour quotidienne automatisée et déploiement en bac à sable avec rejeu PCAP ; FP < 2 % avant prod.
  • Dashboard : MTTD affiché (objectif ≤ 2 min), taux FP, latence sondes, couverture trafic par zone.
  • En cas d'incident testé : isolation serveur (déconnexion réseau), blocage IPs malveillantes, capture mémoire et sauvegarde état avant recovery.
  • Vérification conformité logs (conservation 6 ans) et traçabilité pour audits HDS/RGPD.

9. Flashcards Anki

Quels sont les trois datacenters de DataSecure ? :: Paris, Lyon, Marseille
Quelle plage IP correspond au VLAN 300 (BDD patients) ? :: 192.168.300.0/24
Quel outil HIDS est recommandé dans la solution proposée ? :: Wazuh
Quelle solution NIPS est préconisée en périmètre ? :: Suricata sur appliances physiques (3x Supermicro)
Quel est l'objectif de délai maximum pour la détection en temps réel ? :: 2 minutes
Quelle est la durée minimale de conservation des logs de sécurité ? :: 6 ans
Quel taux de faux positifs doit être atteint avant production selon le plan ? :: < 2 %
Quelle action immédiate est recommandée pour le serveur web compromis 192.168.500.10 ? :: Isolation immédiate (déconnexion réseau)
Quel est le délai légal de notification CNIL en cas d'incident ? :: 72 heures
Quelle fréquence de mise à jour automatisée des signatures est préconisée ? :: Quotidienne (cron 02:00)