Vulnérabilités et conformité CIS : Vulnerability Detection et SCA

La détection des vulnérabilités de Wazuh compare la liste des logiciels installés sur chaque machine, relevée par l'agent, aux failles connues et publiées (les CVE), pour dire quelles machines sont vulnérables à quoi. L'évaluation de la configuration de sécurité (SCA, Security Configuration Assessment) vérifie, elle, que la configuration des machines respecte des règles de durcissement, le plus souvent celles des CIS Benchmarks. Ce chapitre explique les deux modules, la façon de prioriser ce qu'ils trouvent, et l'écriture d'une politique SCA maison.

Comment Wazuh trouve les vulnérabilités

Le mécanisme tient en trois étapes :

1. L'inventaire. Le module syscollector de l'agent relève, toutes les heures par défaut, le système d'exploitation et sa version, les paquets et logiciels installés avec leur version, les correctifs Windows, les ports ouverts et les processus. Il l'envoie au serveur. Tu le consultes dans Security operations > IT Hygiene.
2. La comparaison. Le module de détection des vulnérabilités du serveur compare cet inventaire à la base de failles de Wazuh, un flux de renseignement sur les menaces (CTI, publié par l'éditeur sur cti.wazuh.com) qui agrège les sources publiques : la base américaine NVD, les avis des éditeurs de systèmes (Microsoft, Debian, Ubuntu, Red Hat…). La base est mise à jour toutes les heures par défaut.
3. Le résultat. Chaque couple « machine, faille » devient une entrée de l'inventaire des vulnérabilités, et une alerte dont le niveau dépend de la sévérité : 23503 (faible, niveau 5), 23504 (moyenne, niveau 7), 23505 (haute, niveau 10), 23506 (critique, niveau 13). Quand une mise à jour corrige la faille, la règle 23502 signale qu'elle est résolue.

Le module est actif par défaut, avec ce bloc dans l'ossec.conf du serveur :

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Les résultats sont dans Threat intelligence > Vulnerability Detection : un tableau de bord (vulnérabilités par sévérité, par machine, par paquet), l'inventaire détaillé et les événements de détection et de résolution.

Une vulnérabilité y est décrite par :

Prioriser une vulnérabilité

Le premier inventaire d'un parc donne souvent des centaines de vulnérabilités. Tout corriger en même temps est impossible ; tout traiter dans l'ordre du score CVSS est une erreur, parce que le score mesure la gravité de la faille dans l'absolu, pas le risque chez toi. On priorise avec quatre questions :

1. La machine est-elle exposée ? Une faille critique sur srv-web, joignable depuis Internet, passe avant la même faille sur un poste du VLAN 10.
2. La faille est-elle exploitée ? Le catalogue Known Exploited Vulnerabilities (KEV) de l'agence américaine CISA recense les failles exploitées dans des attaques réelles ; en France, le CERT-FR publie des alertes pour les failles exploitées ou sur le point de l'être, et des avis pour les autres. Une faille exploitée se traite en urgence, quel que soit son score.
3. La machine est-elle critique ? Un contrôleur de domaine ou le serveur de la paie comptent plus qu'une machine de test.
4. Le logiciel vulnérable est-il réellement utilisé ? Un composant installé mais inactif reste à corriger, mais moins vite ; s'il ne sert à rien, le désinstaller supprime la faille.

Corriger, puis vérifier. On applique la mise à jour (Windows Update ou le serveur de mises à jour pour Windows, voir le cours Windows Server ; apt pour Debian), puis on attend le prochain inventaire de l'agent (une heure par défaut) : la vulnérabilité passe en résolue et disparaît de l'inventaire actif. C'est la preuve que la correction a pris, à joindre au ticket.

L'évaluation de configuration (SCA)

Une machine à jour peut rester vulnérable par sa configuration : un compte invité actif, des mots de passe trop courts, une connexion SSH de root autorisée, un pare-feu local désactivé. Le module SCA de l'agent vérifie la configuration selon des politiques écrites en YAML. Wazuh en fournit une par système, presque toutes tirées des CIS Benchmarks, les guides de durcissement publiés par le Center for Internet Security :

L'agent choisit seul la politique qui correspond à son système et l'exécute au démarrage puis toutes les 12 heures. Chaque contrôle (check) donne l'un de trois résultats :

Le score d'une politique est la part de contrôles réussis parmi ceux qui ont pu s'appliquer : score = réussis ÷ (réussis + échoués). Les contrôles non applicables ne comptent pas. Les résultats sont dans Endpoint security > Configuration Assessment, par agent et par politique, avec pour chaque contrôle sa justification et la façon de corriger.

Un contrôle typique de la politique Windows Server, présenté ainsi dans le tableau de bord :

Wazuh alerte aussi sur les changements de résultat : un contrôle qui passe de réussi à échoué déclenche la règle 19011, de niveau 9. C'est une détection précieuse : quelqu'un vient d'affaiblir la configuration d'une machine, par erreur ou pour préparer la suite d'une attaque.

Écrire une politique SCA maison

La politique de sécurité de Sorbier impose deux règles sur les serveurs Linux : pas de connexion SSH directe de root, pas d'authentification SSH par mot de passe (clés uniquement). Une politique SCA de quelques lignes vérifie que c'est vrai partout, en permanence.

Sur le serveur Wazuh, crée /var/ossec/etc/shared/linux/sorbier_ssh.yml : les fichiers du dossier d'un groupe sont envoyés à tous les agents du groupe, comme agent.conf.

policy:
  id: "sorbier_ssh"
  file: "sorbier_ssh.yml"
  name: "Sorbier : configuration SSH des serveurs Linux"
  description: "Vérifie les règles SSH imposées par la politique de sécurité de Sorbier Logistique."

requirements:
  title: "Le serveur OpenSSH est installé"
  description: "La politique ne s'applique qu'aux machines qui ont un fichier sshd_config."
  condition: any
  rules:
    - 'f:/etc/ssh/sshd_config'

checks:
  - id: 100001
    title: "SSH : la connexion directe de root est interdite"
    description: "Le compte root ne doit pas pouvoir ouvrir de session SSH."
    rationale: "Une connexion nominative suivie de sudo laisse une trace de la personne qui administre."
    remediation: "Ajouter la ligne 'PermitRootLogin no' dans /etc/ssh/sshd_config, puis recharger le service ssh."
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PermitRootLogin\s+no'

  - id: 100002
    title: "SSH : l'authentification par mot de passe est désactivée"
    description: "Seules les clés SSH doivent permettre de se connecter."
    rationale: "Un mot de passe se devine par force brute ; une clé privée, non."
    remediation: "Ajouter la ligne 'PasswordAuthentication no' dans /etc/ssh/sshd_config, puis recharger le service ssh."
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PasswordAuthentication\s+no'

Active-la dans l'agent.conf du groupe linux ; le chemin relatif part du dossier d'installation de l'agent, et etc/shared est le dossier où il reçoit les fichiers du groupe :

<agent_config>
  <sca>
    <policies>
      <policy>etc/shared/sorbier_ssh.yml</policy>
    </policies>
  </sca>
</agent_config>

Au prochain passage (ou au redémarrage de l'agent), la politique « Sorbier : configuration SSH des serveurs Linux » apparaît dans Configuration Assessment pour srv-web, avec son score.

Exercices

  - id: 100003
    title: "SSH : trois tentatives d'authentification au plus par connexion"
    description: "Le serveur SSH coupe la connexion après trois échecs."
    rationale: "Limiter les essais par connexion ralentit une attaque par force brute et la rend plus visible."
    remediation: "Ajouter la ligne 'MaxAuthTries 3' dans /etc/ssh/sshd_config, puis recharger le service ssh."
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> n:^\s*MaxAuthTries\s+(\d+) compare <= 3'