Checklist NIS2 pour la PME belge : les dix mesures de l'article 21 traduites en tâches serveur concrètes

La directive NIS2 a été transposée en Belgique par la loi du 26 avril 2024, en vigueur depuis le 18 octobre 2024. Le Centre pour la Cybersécurité Belgique (CCB) est l'autorité compétente, et les organisations concernées devaient s'enregistrer sur Safeonweb@Work. Depuis, la question dans chaque service informatique d'une entité « importante » ou « essentielle » est la même : que dois-je faire concrètement maintenant ?

Cet article y répond pour le parc de serveurs. Ce n'est ni un avis juridique ni une déclaration de conformité — si votre entité relève de la loi, dans quelle catégorie, et si vos mesures sont « appropriées et proportionnées » (les mots de la loi), c'est à un juriste ou à un auditeur accrédité CyFun d'en juger. Ce qui est ici, c'est comment préparer la preuve technique pour que ce jugement aille vite.

D'abord : le contexte belge en cinq points

1. Deux catégories. Les entités essentielles (grandes entreprises dans des secteurs comme l'énergie, le transport, la santé, l'infrastructure numérique) et les entités importantes (moyennes dans les mêmes secteurs, plus des secteurs comme la poste, les déchets, la chimie, l'alimentation, l'industrie, les services numériques). Les seuils sont 50 employés ou 10 millions d'euros de chiffre d'affaires — beaucoup de PME sont donc en dessous, mais pas toutes.
2. CyberFundamentals (CyFun). Le CCB a son propre cadre avec trois niveaux : Basic, Important, Essential. Les entités importantes peuvent démontrer leur conformité via CyFun Important ; les essentielles via CyFun Essential ou ISO 27001. Une attestation CyFun d'un organisme accrédité vaut présomption de conformité.
3. Obligation de notification. Un incident significatif : alerte précoce sous 24 heures, notification d'incident sous 72 heures, rapport final sous un mois. Via la plateforme de notification du CCB.
4. Responsabilité des dirigeants. L'organe de direction doit approuver les mesures, superviser leur mise en œuvre, et suivre une formation. C'est nouveau, et c'est personnel.
5. Surveillance. Le CCB peut inspecter, exiger des audits et infliger des amendes (jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires pour les essentielles ; 7 millions ou 1,4 % pour les importantes).

Les dix mesures, traduites

L'article 21 §2 de la directive (repris dans la loi belge) nomme dix domaines, (a) à (j). Par domaine : ce que dit la loi, ce que cela signifie sur un serveur, et la commande ou le fichier qui constitue la preuve.

(a) Analyse des risques et politique de sécurité

Loi : politiques relatives à l'analyse des risques et à la sécurité des systèmes d'information. Serveur : on ne peut pas analyser le risque de ce qu'on ne connaît pas. Commencez par un inventaire reproductible.

# Par hôte, chaque semaine, dans git ou un répertoire partagé :
{
  echo "host=$(hostname -f) date=$(date -Is)"
  echo "os=$(. /etc/os-release; echo "$PRETTY_NAME") kernel=$(uname -r)"
  echo "ip=$(hostname -I)"
  echo "--- listening"; ss -tulnH | awk '{print $1, $5}' | sort -u
  echo "--- services"; systemctl list-units --type=service --state=running --no-legend | awk '{print $1}'
  echo "--- packages"; dpkg-query -W -f='${Package} ${Version}\n' | wc -l
  echo "--- users"; awk -F: '$3>=1000 && $7!~/nologin|false/{print $1}' /etc/passwd
} > "/srv/inventory/$(hostname -s)-$(date +%F).txt"

L'analyse des risques elle-même est un document (quels systèmes, quelles menaces, quel impact, quelle mesure). Ça ne s'écrit pas en bash. Mais chaque ligne de ce document renvoie à un actif de cet inventaire — c'est le lien qu'un auditeur cherche.

(b) Gestion des incidents

Loi : procédures de gestion des incidents. Serveur : vous devez pouvoir voir les incidents (détection), les reconstituer (logs conservés assez longtemps) et les notifier (sous 24 h).

# Conserver les logs assez longtemps (journald) : au moins 90 jours, idéalement 12 mois pour auth
sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=365day
EOF
sudo systemctl restart systemd-journald

# L'heure doit être juste, sinon toute chronologie est sans valeur
timedatectl show -p NTPSynchronized -p Timezone

Détection : voir les guides sur le brute force SSH et les fichiers honeypot. La procédure (qui appelle qui, qui notifie le CCB, où est le formulaire) tient sur une feuille A4 accrochée au mur — et que vous répétez une fois par an.

(c) Continuité des activités : sauvegarde, reprise, gestion de crise

Loi : continuité des activités, telle que la gestion des sauvegardes et les plans de reprise. Serveur : une sauvegarde que vous n'avez jamais restaurée est une hypothèse.

# Preuve 1 : la sauvegarde est récente
restic -r /srv/backup snapshots --latest 1 --json | jq -r '.[0].time'
# Preuve 2 : la sauvegarde est lisible (échantillon de 5 % des données)
restic -r /srv/backup check --read-data-subset=5%
# Preuve 3 : test de restauration, avec date et résultat journalisés
restic -r /srv/backup restore latest --target /tmp/restore-test --include /etc/nginx \
  && echo "$(date -Is) restore-test OK nginx-config" >> /srv/inventory/restore-tests.log

Rythme trimestriel : un test de restauration complet d'un vrai service vers un environnement de test. Voir vérifier les sauvegardes qui disent « réussi ».

(d) Sécurité de la chaîne d'approvisionnement

Loi : sécurité de la chaîne d'approvisionnement, y compris la relation avec les fournisseurs directs. Serveur : savoir quels logiciels tiers vous faites tourner et quelles vulnérabilités ils apportent — paquets OS et dépendances applicatives.

# Couche OS : voir le guide OSV ; en bref
dpkg-query -W -f='${source:Package} ${source:Version}\n' | sort -u > /srv/inventory/$(hostname -s)-packages.txt
# Couche applicative : les lockfiles sont votre SBOM allégé
find /srv /var/www /opt -maxdepth 4 \( -name package-lock.json -o -name requirements.txt -o -name composer.lock -o -name go.sum \) 2>/dev/null

Le côté contractuel (quelles exigences vous imposez à vos fournisseurs, ont-ils eux-mêmes une déclaration NIS2 ou ISO) est une liste dans votre registre des fournisseurs. Le côté technique est un scan CVE daté.

(e) Acquisition, développement et maintenance ; gestion des vulnérabilités

Loi : sécurité de l'acquisition, du développement et de la maintenance, y compris le traitement et la divulgation des vulnérabilités. Serveur : patcher, avec un délai démontrable.

# Mises à jour de sécurité automatiques activées
sudo apt install -y unattended-upgrades
grep -E '^Unattended-Upgrade::Allowed-Origins|security' /etc/apt/apt.conf.d/50unattended-upgrades | head -3
# Preuve : quand quoi a été installé
grep -h 'status installed' /var/log/dpkg.log* | awk '{print $1, $5, $6}' | sort | tail -20
# Mises à jour en attente et état de redémarrage
apt list --upgradable 2>/dev/null | wc -l; [ -f /var/run/reboot-required ] && echo REBOOT-REQUIRED

Voir bien configurer unattended-upgrades. Un auditeur demande le délai entre la publication d'un correctif et son installation. dpkg.log donne la date d'installation ; l'USN donne la date de publication.

(f) Évaluation de l'efficacité

Loi : politiques et procédures pour évaluer l'efficacité des mesures. Serveur : mesurez. Une mesure sans métrique est une intention.

Mesure	Métrique	Source
Correctifs	jours entre USN et installation, p50 et p95	dpkg.log + date USN
Sauvegarde	% de jours avec sauvegarde réussie ; dernier test de restauration	snapshots restic + journal de restauration
Détection	nombre de détections par mois ; % examinées sous 1 h	journal ntfy / système de tickets
Accès	nombre de comptes ; % avec MFA ; date de la dernière revue	/etc/passwd, IdP, journal de revue

Une page, mise à jour chaque trimestre, signée par le responsable. C'est ça, « l'évaluation de l'efficacité ».

(g) Hygiène cyber et formation

Loi : pratiques de base en matière d'hygiène cyber et formation. Serveur : les bases ne sont pas passionnantes, et c'est précisément pour ça qu'on les saute.

# Pas de SSH par mot de passe, pas de connexion root
sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '
# Pare-feu actif, refus par défaut
sudo ufw status verbose | head -4
# Aucun compte sans mot de passe
sudo awk -F: '($2=="" || $2=="!") {print "no-password:", $1}' /etc/shadow
# Délai d'expiration de session sur les serveurs : TMOUT dans /etc/profile.d
grep -rh TMOUT /etc/profile.d/ 2>/dev/null

Formation : la loi exige que l'organe de direction soit aussi formé. Conservez la liste de présence.

(h) Cryptographie et chiffrement

Loi : politiques relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. Serveur : TLS partout, pas de certificats expirés, sauvegardes et disques chiffrés.

# Quels certificats tournent, et quand expirent-ils ? (chaque port TLS en écoute)
for port in $(ss -tlnH | awk '{sub(/.*:/,"",$4); print $4}' | sort -un); do
  end=$(echo | timeout 3 openssl s_client -connect "localhost:$port" -servername "$(hostname)" 2>/dev/null \
        | openssl x509 -noout -enddate 2>/dev/null) && echo "port $port: $end"
done
# Configuration TLS : pas de TLS 1.0/1.1
nmap --script ssl-enum-ciphers -p 443 localhost 2>/dev/null | grep -E 'TLSv1\.[01]' && echo "ANCIEN PROTOCOLE ACTIF"
# Sauvegarde chiffrée ? (restic : toujours ; rsync : non)
restic -r /srv/backup cat config >/dev/null 2>&1 && echo "restic repo: chiffré"
# Chiffrement de disque
lsblk -o NAME,TYPE,FSTYPE | grep -i crypt

Voir les certificats TLS qui expirent en silence pour la version à l'échelle de la flotte.

(i) Sécurité des ressources humaines, contrôle d'accès et gestion des actifs

Loi : sécurité des ressources humaines, politiques de contrôle d'accès et gestion des actifs. Serveur : qui a accès, pourquoi, et depuis quand — et est-ce revu chaque trimestre ?

# Tous les comptes interactifs, avec dernière connexion SSH depuis le journal
# (lastlog/wtmp ne sont plus fiables sur Ubuntu ≥ 24.04 ; le journal, si)
for u in $(awk -F: '$3>=1000 && $7!~/nologin|false/{print $1}' /etc/passwd); do
  last=$(journalctl -u ssh --since "365 days ago" --no-pager -o short-iso 2>/dev/null \
         | grep -E "Accepted (publickey|password) for $u " | tail -1 | awk '{print $1}')
  printf '%-16s last=%s\n' "$u" "${last:-never}"
done
# Qui peut sudo ?
getent group sudo admin wheel 2>/dev/null
grep -rhE '^[^#].*ALL' /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# Quelles clés SSH sont autorisées, et à qui ?
for d in /root /home/*; do [ -f "$d/.ssh/authorized_keys" ] && { echo "== $d"; awk '{print $NF}' "$d/.ssh/authorized_keys"; }; done

Chaque trimestre : poser cette sortie à côté de la liste du personnel, expliquer ou supprimer chaque écart, et conserver le résultat avec date et signature. C'est une revue d'accès, et c'est la pièce de preuve qui manque le plus souvent.

(j) Authentification multifacteur et communications sécurisées

Loi : utilisation de la MFA ou de l'authentification continue, communications vocales, vidéo et textuelles sécurisées, et communications d'urgence sécurisées. Serveur : SSH par clé est un facteur (quelque chose que vous avez). Pour l'accès d'administration, vous en voulez deux.

# Option 1 : clé + TOTP via PAM (google-authenticator-libpam, aucun service Google nécessaire)
sudo apt install -y libpam-google-authenticator
# par administrateur : google-authenticator -t -d -f -r 3 -R 30 -W
# dans /etc/pam.d/sshd :  auth required pam_google_authenticator.so
# dans sshd_config.d :    KbdInteractiveAuthentication yes
#                         AuthenticationMethods publickey,keyboard-interactive
# Option 2 : certificats SSH à courte durée depuis une CA derrière votre IdP (la MFA se fait à l'IdP)
# Preuve : quelle méthode est imposée ?
sshd -T | grep -iE '^authenticationmethods'

Communications d'urgence sécurisées : si votre e-mail et Teams sont à terre à cause de l'incident, comment vous joignez-vous ? Un groupe Signal avec les numéros sur papier est une réponse valable. Écrivez-le.

La checklist (à cocher)

#	Mesure	Preuve serveur prête ?	Fréquence
a	Inventaire par hôte, lié à l'analyse des risques	☐	hebdomadaire, automatisé
b	Rétention des logs ≥ 90 j, NTP synchronisé, détection active, procédure de notification sur une page	☐	continu / exercice annuel
c	Sauvegarde récente + check + test de restauration journalisé	☐	quotidien / trimestriel
d	Inventaire des paquets + scan CVE daté ; registre des fournisseurs	☐	hebdomadaire
e	unattended-upgrades actif ; dpkg.log conservé ; reboot-required surveillé	☐	continu
f	Page de métriques avec quatre KPI, signée	☐	trimestriel
g	SSH par clé uniquement, pare-feu refus par défaut, pas de mots de passe vides ; liste de formation	☐	continu / annuel
h	Inventaire des certificats + alerte d'expiration ; TLS ≥ 1.2 ; sauvegardes chiffrées	☐	continu
i	Revue d'accès : comptes, sudo, clés SSH face à la liste du personnel	☐	trimestriel
j	MFA imposée sur l'accès d'administration ; communications d'urgence décrites	☐	continu

Pièges

• Penser que CyFun Basic suffit. Basic est pour les micro-organisations et les entités hors NIS2. Les entités importantes sont au niveau Important, et ce niveau exige explicitement journalisation, gestion des vulnérabilités et MFA.
• Une politique sans preuve. Une belle politique de sécurité de l'information en Word, c'est l'étape un. L'auditeur demande : « montrez-moi qu'elle tourne ». Chaque commande de cet article est ce « montrer ».
• Une preuve sans date. Une capture d'écran de apt list --upgradable sans horodatage ne prouve rien. Tout ce que vous conservez reçoit un date -Is et va dans un répertoire que vous ne modifiez plus.
• Oublier de répéter la notification sous 24 heures. Qui appelle le CCB quand le responsable informatique est en vacances ? Si la réponse est « euh », la procédure n'est pas finie.
• Oublier les fournisseurs. Votre hébergeur cloud, votre MSP, votre comptabilité SaaS : NIS2 exige que vous évaluiez leur sécurité. Demandez leurs déclarations et conservez-les.

Ce qu'il vous manque encore

Chaque commande ci-dessus fonctionne sur un serveur. Avec dix serveurs, vous avez dix inventaires, dix listes de paquets, dix sorties de revue d'accès — et la question « est-ce que tout est couvert ? » est un tableur que quelqu'un tient à jour. Avec trente serveurs, personne ne tient ce tableur. Et la preuve que vous collectez n'est une preuve que si vous pouvez démontrer qu'elle n'a pas été modifiée après coup — un répertoire de fichiers texte ne l'est pas.

Comment monsys fait

monsys associe chaque mesure NIS2 (et les contrôles ISO 27001 et CRA) à une requête de preuve qui tourne en continu sur tous les hôtes : inventaire, état des correctifs, CVE, fraîcheur des sauvegardes, certificats, comptes, statut MFA, détections. Le résultat est un pourcentage de couverture par contrôle et un audit pack mensuel — signé Ed25519, stable à l'octet, vérifiable hors ligne — que vous remettez à un auditeur CyFun ou au CCB. Un contrôle qui perd sa preuve (un hôte où unattended-upgrades cesse de fonctionner) déclenche une alerte d'érosion de conformité avant que l'auditeur ne le voie. monsys ne juge pas si vous êtes conforme ; il veille à ce que la preuve soit là quand quelqu'un la demande.

FAQ

Ma PME relève-t-elle de NIS2 ?

Cela dépend du secteur et de la taille (à partir de 50 employés ou 10 millions d'euros de chiffre d'affaires dans un secteur NIS2, avec des exceptions vers le bas pour certains secteurs comme le DNS et les services de confiance). Le CCB propose un autotest sur Safeonweb@Work. En cas de doute : demandez à un juriste ; l'obligation d'enregistrement vous incombe.

ISO 27001, est-ce la même chose que conforme NIS2 ?

Non, mais ça aide. Pour les entités essentielles, le CCB accepte un certificat ISO 27001 comme présomption de conformité, si le périmètre correspond. Pour les entités importantes, CyFun Important est la référence. Les mesures techniques se recoupent largement ; l'obligation de notification et les obligations des dirigeants s'y ajoutent.

À quelle vitesse dois-je notifier un incident ?

Alerte précoce sous 24 heures après avoir eu connaissance d'un incident significatif, notification complète sous 72 heures, rapport final sous un mois. Ce qui est « significatif » est défini par la loi (perturbation opérationnelle grave ou perte financière, ou dommage considérable à autrui). En cas de doute : notifiez.