BENCHMARK DE DURCISSEMENT SONICWALL FIREWALL 2026

🔥 AYI NEDJIMI CONSULTANTS (ANC)

Version : 2.0 — Mai 2026
Applicabilité : SonicWall TZ, NSa, NSsp, NSv — Gen 6 (SonicOS 6.x), Gen 7 (SonicOS 7.x), Gen 8 (SonicOS 8.x)
Format : CIS Benchmark-style — Niveau 1 / Niveau 2 / Critique
Sources : SonicWall PSIRT, CERT-EU, Huntress, Beazley Security, CIS Controls v8, NIST SP 800-41, ANSSI, MITRE ATT&CK v15

---

📋 Conventions

Symbole	Signification
🔴 Critique	Exploité activement — action immédiate requise (24-72h)
🟡 L1	Niveau 1 — Applicable à tout environnement, impact opérationnel minimal (30 jours)
🔵 L2	Niveau 2 — Recommandé pour les environnements à sécurité renforcée (90 jours)

---

📑 Table des matières

#	Section	Contrôles
1	Gestion du firmware et des licences	6
2	Gestion des comptes et authentification	10
3	Sécurisation de l’interface d’administration	11
4	Zones et segmentation réseau	6
5	Règles de firewall et politiques d’accès	7
6	Services de sécurité IPS/AV/Anti-Spyware	8
7	VPN SSL et accès distant	8
8	Journalisation et supervision	9
9	Haute disponibilité et résilience	4
10	Gestion du changement et conformité	5
A	Procédure de réponse à incident	—
B	Annexe — Checklist de conformité	74

---

🏆 Top 10 Quick Wins — 80 % du risque éliminé en 72h

Ces 10 actions couvrent les vecteurs d’attaque les plus exploités sur SonicWall en 2024-2025. Priorité absolue avant tout autre durcissement.

Rang	Contrôle	Impact	Temps estimé
🥇 1	Désactiver le SSL-VPN depuis WAN si non utilisé (7.1)	Élimine le vecteur principal de ransomware	5 min
🥈 2	Activer la MFA sur tous les comptes admin et VPN (2.2, 2.3)	Bloque 95 % des compromissions par credential	30 min
🥉 3	Restreindre l’interface d’administration au LAN/MGMT (3.1)	Supprime la surface d’attaque WAN	10 min
4	Mettre à jour le firmware — patcher CVE actifs (1.1, 1.2)	Élimine les exploits connus	30-60 min
5	Changer le mot de passe admin par défaut (2.1)	Bloque l’accès trivial aux credentials par défaut	2 min
6	Activer l’IPS en mode Prevent sur toutes les zones (6.1)	Bloque les exploits réseau en temps réel	15 min
7	Corriger CVE-2024-12802 (LDAP userPrincipalName) (2.3)	Ferme le bypass MFA SSL-VPN	5 min
8	Activer le Botnet Filter + Anti-Spyware (6.3, 6.4)	Bloque communications C&C post-compromission	10 min
9	Configurer Syslog vers un SIEM externe (8.1)	Donne la visibilité pour détecter les compromissions	20 min
10	Activer le lockout après 5 tentatives (2.4)	Bloque les attaques brute-force/password spray	5 min

Résultat estimé : ces 10 actions, applicables en moins de 3 heures, éliminent les vecteurs d’attaque documentés dans >80 % des compromissions SonicWall publiées en 2024-2025.

---

🎯 Préambule — Pourquoi ce benchmark

Les firewalls SonicWall constituent une cible de premier plan pour les groupes de ransomware et les acteurs étatiques. En 2024-2025, plusieurs vulnérabilités critiques ont été massivement exploitées dans la nature :

• CVE-2024-40766 (CVSS 9.3) — Contrôle d’accès défaillant sur SonicOS, exploité par le groupe Akira Ransomware pour obtenir un accès initial avant de pivoter sur le réseau interne.
• CVE-2025-23006 (CVSS 9.8) — Désérialisation sur SonicWall SMA 1000 Series (n’affecte pas les firewalls TZ/NSa/NSsp/NSv — illustre la criticité des patchs zero-day sur l’écosystème SonicWall). Exploité avant patch disponible.
• CVE-2025-32819/32820/32821 — Chaîne d’exploitation sur SSL-VPN permettant la lecture de fichiers arbitraires et la corruption mémoire.
• CVE-2024-12802 — Bypass MFA sur SSL-VPN via manipulation LDAP userPrincipalName.

Huntress et Beazley Security ont documenté des campagnes massives ciblant les firewalls SonicWall Gen 7 exposés sans MFA, avec un délai d’exploitation de moins de 24 heures après divulgation CVE.

Ce benchmark s’inspire des CIS Benchmarks (profil L1/L2) et du NIST SP 800-41 pour fournir un référentiel de durcissement structuré, applicable en audit ou en auto-évaluation.

---

⚡ Découverte Rapide — 10 Vérifications Critiques

Évaluation initiale des risques majeurs en 20 minutes

Q1. Interface d’administration accessible depuis Internet ?

Navigation : Network > Interfaces > WAN — vérifier “HTTPS Management” et “SSH Management”
Seuil critique : Interface de gestion accessible depuis WAN sans restriction IP
Évaluation : ✅ ❌ ⚠️

Q2. MFA activée sur l’interface d’administration ?

Navigation : Device > Users > Local Users > admin > Edit > Login Policies
Seuil critique : MFA désactivée sur tout compte administrateur
Évaluation : ✅ ❌ ⚠️

Q3. MFA activée sur le SSL-VPN ?

Navigation : Device > Settings > SSL VPN > Server Settings
Seuil critique : SSL-VPN accessible sans MFA, même depuis des IPs restreintes
Évaluation : ✅ ❌ ⚠️

Q4. Firmware à jour — CVE critiques patchées ?

Navigation : Device > Settings > Firmware > Current Version
Seuil critique : Version non à jour selon MySonicWall Downloads (Gen 7 : branche 7.1.x/7.2.x ; Gen 8 : 8.0.x — consulter PSIRT pour CVE actives)
Évaluation : ✅ ❌ ⚠️

Q5. Règle “Any Any Allow” active ?

Navigation : Policy > Rules and Policies > Access Rules — filtrer par Action=Allow, Source=Any, Destination=Any
Seuil critique : Présence d’une règle Any-Any-Allow active sur une zone sensible
Évaluation : ✅ ❌ ⚠️

Q6. Logs envoyés vers un SIEM externe ?

Navigation : Device > Settings > Log > Automation — vérifier destination Syslog
Seuil critique : Aucune destination Syslog externe configurée
Évaluation : ✅ ❌ ⚠️

Q7. IPS activé sur toutes les zones ?

Navigation : Network > Zones — vérifier colonne IPS pour chaque zone active
Seuil critique : IPS désactivé sur LAN, DMZ ou WLAN
Évaluation : ✅ ❌ ⚠️

Q8. Capture ATP (sandbox) activé ?

Navigation : Security Services > Capture ATP > Global Settings
Seuil critique : Capture ATP désactivé ou “Block Until Verdict” non configuré
Évaluation : ✅ ❌ ⚠️

Q9. Sauvegarde de configuration récente ?

Navigation : Device > Settings > Firmware — vérifier date dernier export .exp
Seuil critique : Aucune sauvegarde dans les 30 derniers jours
Évaluation : ✅ ❌ ⚠️

Q10. PSIRT SonicWall consulté récemment ?

Source : https://psirt.global.sonicwall.com
Seuil critique : Aucun suivi des bulletins de sécurité SonicWall
Évaluation : ✅ ❌ ⚠️

---

📊 Informations Appliance Auditée

Champ	Valeur	Notes
Organisation	[À compléter]
Modèle	[À compléter]	TZ/NSa/NSsp/NSv
Génération	[À compléter]	Gen 6 / Gen 7 / Gen 8
Version SonicOS	[À compléter]
Date d’audit	[À compléter]
Auditeur	[À compléter]
Interfaces actives	[À compléter]	WAN/LAN/DMZ/WLAN/MGMT
SSL-VPN actif	[À compléter]	Oui / Non
HA configurée	[À compléter]	Oui / Non

---

🔧 DOMAINE 1 — GESTION DU FIRMWARE ET DES LICENCES

La surface d’attaque d’un firewall non patché est directement exploitable depuis Internet. Les CVE SonicWall sont systématiquement intégrées dans les arsenaux des groupes de ransomware dans les 48-72h suivant leur divulgation.

---

1.1 — Mise à jour du firmware vers la dernière version stable

Niveau : 🟡 L1
Référence CIS : CIS Control 7.3 — Perform Automated Operating System Patch Management
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1203 — Exploitation for Client Execution

Description du risque :
Un firmware obsolète expose l’appliance à des vulnérabilités connues et documentées dans les bases CVE. Les groupes de ransomware (Akira, LockBit, RansomHub) automatisent la détection des versions SonicOS non patchées via Shodan et Censys dès publication d’un CVE. Le délai entre divulgation et exploitation active est inférieur à 72 heures pour les CVE critiques.

Impact potentiel :
Accès initial non authentifié, exécution de code à distance, contournement d’authentification, accès au réseau interne depuis Internet.

Vérification :

1. Naviguer vers Device > Settings > Firmware
2. Comparer la version affichée avec les versions courantes sur MySonicWall.com > Downloads
3. Versions minimales recommandées :
   • Gen 6 (SonicOS 6.x) : 6.5.4.15-116n ou plus récent
   • Gen 7 (SonicOS 7.x) : 7.1.x ou 7.2.x selon modèle — consulter MySonicWall pour la version stable la plus récente (changelog disponible sous My Products > Downloads)
   • Gen 8 (SonicOS 8.x) : 8.0.3 ou plus récent
4. Vérifier le bulletin PSIRT pour les CVE actives : https://psirt.global.sonicwall.com

Remédiation :

1. Exporter la configuration courante avant toute mise à jour : Device > Settings > Firmware > Export Settings
2. Se connecter à MySonicWall.com > Downloads > filtrer par modèle
3. Télécharger le firmware signé (.sig)
4. Naviguer vers Device > Settings > Firmware > Upload New Firmware
5. Uploader le fichier .sig et cliquer sur “Upload and Boot”
6. Vérifier le redémarrage et la version post-mise à jour
7. Restaurer la configuration si nécessaire

Valeur par défaut : Firmware d’usine — aucune mise à jour automatique
Critère de conformité : Version ≥ seuil minimal recommandé, aucun CVE actif non patché

---

1.2 — Application immédiate des patches critiques (CVE CVSS ≥ 9.0)

Niveau : 🔴 Critique
Référence CIS : CIS Control 7.1 — Establish and Maintain a Vulnerability Management Process
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1133 — External Remote Services

Description du risque :
Les CVE à score CVSS ≥ 9.0 sur SonicWall ciblent généralement les interfaces exposées (SSL-VPN, API REST, interface de gestion). CVE-2024-40766 a été exploitée par le groupe Akira Ransomware pour compromettre des centaines d’organisations dans les semaines suivant sa publication. La CISA a ajouté cette CVE au catalogue KEV (Known Exploited Vulnerabilities), rendant sa remédiation obligatoire pour les entités fédérales américaines et fortement recommandée pour toutes les organisations.

CVE critiques actives (2024-2026) :

CVE	CVSS	Description	Produits affectés	Statut
CVE-2024-40766	9.3	Contrôle d’accès défaillant — accès non authentifié	SonicOS Gen 5/6/7 (TZ, NSa, NSsp)	CISA KEV — patcher immédiatement
CVE-2024-12802	7.5	Bypass MFA SSL-VPN via LDAP userPrincipalName	Gen 7/8 avec LDAP	Correctif disponible
CVE-2025-32819	8.8	Path traversal SSL-VPN — lecture fichiers arbitraires	Gen 6/7 (TZ, NSa, NSsp)	Correctif disponible (mai 2025)
CVE-2025-32820	8.2	Path traversal SSL-VPN — écriture répertoire	Gen 6/7 (TZ, NSa, NSsp)	Correctif disponible (mai 2025)
CVE-2025-32821	7.1	Injection argument SSL-VPN	Gen 6/7 (TZ, NSa, NSsp)	Correctif disponible (mai 2025)
CVE-2025-23006	9.8	Désérialisation RCE pré-auth	SMA 1000 Series uniquement (ne concerne pas TZ/NSa/NSsp)	Correctif disponible (jan. 2025)

Vérification :

1. Vérifier la version firmware courante (Device > Settings > Firmware)
2. Consulter https://psirt.global.sonicwall.com pour les bulletins actifs
3. Vérifier le CISA KEV catalog pour les CVE SonicWall : https://www.cisa.gov/known-exploited-vulnerabilities-catalog
4. Croiser la version courante avec les versions corrigées dans chaque bulletin

Remédiation :

• Si patch disponible : appliquer immédiatement (voir contrôle 1.1)
• Si patch non encore disponible : mesures de contournement immédiates :
  1. Désactiver le SSL-VPN depuis l’interface WAN si non indispensable
  2. Restreindre l’accès d’administration à des IPs de confiance uniquement
  3. Isoler l’appliance derrière un bastion si possible
  4. Augmenter la surveillance des logs d’authentification

Valeur par défaut : Aucun patch automatique — action manuelle requise
Critère de conformité : Aucun CVE CVSS ≥ 9.0 non patché sur l’appliance exposée à Internet

---

1.3 — Enregistrement de l’appliance sur MySonicWall.com

Niveau : 🟡 L1
Référence CIS : CIS Control 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory
MITRE ATT&CK : T1190 — Exploit Public-Facing Application (prévention)

Description du risque :
Sans enregistrement MySonicWall, l’appliance ne reçoit pas les mises à jour de signatures IPS/AV/Anti-Spyware ni les alertes Capture Labs. Les définitions de menaces obsolètes rendent l’inspection de sécurité inefficace contre les menaces récentes. De plus, l’enregistrement est prérequis au support SonicWall et à l’activation des licences.

Vérification :

1. Naviguer vers Device > Settings > Licenses
2. Vérifier le statut “Registration Status” : doit afficher “Registered”
3. Vérifier que toutes les licences affichent une date d’expiration valide (non expirée)
4. Alternativement depuis MySonicWall.com > My Products > vérifier le numéro de série

Remédiation :

1. Se connecter à https://www.mysonicwall.com
2. Aller dans My Products > Register New Product
3. Entrer le numéro de série et la clé d’authentification (étiquette au dos de l’appliance)
4. Depuis l’appliance : Device > Settings > Licenses > Synchronize
5. Vérifier que toutes les licences s’affichent correctement

Valeur par défaut : Non enregistré en sortie d’usine
Critère de conformité : Statut “Registered”, toutes les licences actives et non expirées

---

1.4 — Activation et vérification des licences de sécurité

Niveau : 🟡 L1
Référence CIS : CIS Control 4.1 — Establish and Maintain a Secure Configuration Process
MITRE ATT&CK : T1027 — Obfuscated Files or Information (prévention via Gateway AV) | T1071 — Application Layer Protocol (prévention via IPS)

Description du risque :
Un firewall SonicWall sans licences actives est essentiellement un routeur avec des règles de base. Les services de sécurité (IPS, Gateway AV, Anti-Spyware, Capture ATP) nécessitent des licences valides pour fonctionner. Une licence expirée stoppe silencieusement l’inspection sans alerte visible dans l’interface, créant une fausse impression de sécurité.

Licences critiques à vérifier :

Service	Fonction	Critique si absent
Gateway Anti-Virus	Analyse malware dans le trafic HTTP/HTTPS/SMTP	Oui
Intrusion Prevention (IPS)	Blocage exploits et signatures d’attaques	Oui
Anti-Spyware	Blocage C&C et communications malveillantes	Oui
Capture Advanced Threat Protection	Sandbox fichiers inconnus	Oui (Gen 7/8)
Content Filtering Service	Filtrage URL par catégories	Recommandé
Botnet Filter	Blocage communications C&C connues	Recommandé
Support (24x7 ou 8x5)	Accès mises à jour firmware	Obligatoire

Vérification :

1. Naviguer vers Device > Settings > Licenses
2. Vérifier l’état de chaque service : “Licensed” et date d’expiration dans le futur
3. Naviguer vers Security Services > Summary pour voir l’état opérationnel de chaque service

Remédiation :

1. Renouveler les licences expirées via MySonicWall.com > My Products > Services
2. Après renouvellement : Device > Settings > Licenses > Synchronize
3. Activer chaque service dans sa section dédiée (Security Services)
4. Configurer des alertes d’expiration de licences : Device > Settings > Log > Automation — event “License Expiry”

Valeur par défaut : Licences d’évaluation incluses à l’achat — expiration à 30 ou 90 jours
Critère de conformité : Toutes les licences critiques valides, aucune expirée

---

1.5 — Configuration de la mise à jour automatique des signatures

Niveau : 🔵 L2
Référence CIS : CIS Control 7.3 — Perform Automated Vulnerability Management
MITRE ATT&CK : T1059 — Command and Scripting Interpreter | T1203 — Exploitation for Client Execution

Description du risque :
Les signatures IPS, AV et Anti-Spyware de SonicWall (alimentées par Capture Labs) sont mises à jour plusieurs fois par jour. Sans mise à jour automatique, les nouvelles variantes de malware et les exploits récents ne sont pas détectés. L’écart entre une signature publiée et son déploiement sur l’appliance peut permettre la compromission.

Vérification :

1. Naviguer vers Security Services > Intrusion Prevention > Settings
2. Vérifier “Signature Database” — vérifier la date de la dernière mise à jour (doit être récente, <24h)
3. Vérifier que “Download Daily Signature Updates” est coché
4. Répéter pour Security Services > Gateway Anti-Virus > Settings
5. Répéter pour Security Services > Anti-Spyware > Settings

Remédiation :

1. Security Services > Intrusion Prevention > Settings : activer “Download Daily Signature Updates” + “Automatically Download and Install Signature Updates”
2. Configurer la fenêtre de mise à jour : heure creuse (ex: 02:00 UTC)
3. Répéter pour Gateway AV et Anti-Spyware
4. Naviguer vers Security Services > Summary pour forcer une mise à jour immédiate si nécessaire

Valeur par défaut : Mise à jour automatique désactivée — mise à jour manuelle requise
Critère de conformité : Mise à jour automatique activée sur IPS, AV, Anti-Spyware ; dernière mise à jour < 24h

---

1.6 — Sauvegarde de la configuration avant toute mise à jour

Niveau : 🔵 L2
Référence CIS : CIS Control 11.1 — Establish and Maintain a Data Recovery Process
MITRE ATT&CK : T1485 — Data Destruction | T1490 — Inhibit System Recovery

Description du risque :
Une mise à jour firmware défaillante ou une erreur de manipulation peut rendre l’appliance inaccessible ou effacer la configuration. Sans sauvegarde récente, la restauration nécessite une reconfiguration manuelle complète, induisant un downtime réseau prolongé. En cas de compromission, la sauvegarde permet de restaurer un état sain connu.

Vérification :

1. Naviguer vers Device > Settings > Firmware
2. Vérifier la présence d’images de configuration sauvegardées avec horodatage récent
3. Vérifier l’existence d’une copie hors-ligne (fichier .exp) datée de moins de 30 jours

Remédiation :

1. Exporter la configuration : Device > Settings > Firmware > Export Settings — sauvegarder le fichier .exp avec nommage sonicwall-{hostname}-{YYYY-MM-DD}.exp
2. Stocker le fichier sur un support sécurisé hors de l’appliance (NAS, coffre numérique, S3 chiffré)
3. Créer un rappel mensuel pour renouveler la sauvegarde
4. Documenter la procédure de restauration et la tester annuellement

Valeur par défaut : Aucune sauvegarde automatique — export manuel requis
Critère de conformité : Sauvegarde .exp datée < 30 jours, stockée hors-ligne

---

🔐 DOMAINE 2 — GESTION DES COMPTES ET AUTHENTIFICATION

L’authentification est le vecteur d’attaque le plus fréquent sur les firewalls SonicWall. CVE-2024-40766, CVE-2024-12802 et les campagnes de brute-force documentées par Huntress ciblent toutes la couche d’authentification. Ce domaine est le plus critique à sécuriser en priorité absolue.

---

2.1 — Changement du mot de passe administrateur par défaut

Niveau : 🔴 Critique
Référence CIS : CIS Control 5.2 — Use Unique Passwords
MITRE ATT&CK : T1078.001 — Default Accounts | T1110.001 — Password Guessing

Description du risque :
Le mot de passe par défaut SonicWall (password) est universellement connu et documenté. Les scanners automatisés (Shodan, Censys, BinaryEdge) identifient les interfaces SonicWall exposées et tentent les credentials par défaut en moins de 5 minutes. En 2024, Beazley Security a documenté des compromissions d’appliances SonicWall Gen 7 accessibles depuis Internet avec des credentials par défaut non changés.

Impact potentiel :
Accès administrateur complet, modification des règles de firewall, création de comptes backdoor, activation du SSL-VPN pour accès au réseau interne, désactivation de l’IPS/AV.

Vérification :

1. Tenter une connexion avec admin / password depuis la page de login
2. Si la connexion réussit : contrôle ÉCHOUÉ — action immédiate requise
3. Vérifier également les autres comptes locaux (Device > Users > Local Users)

Remédiation :

1. Naviguer vers Device > Users > Local Users > admin > Edit
2. Onglet Password : entrer un nouveau mot de passe
3. Exigences minimales : 12+ caractères, majuscules + minuscules + chiffres + symboles
4. Ne pas utiliser de variantes du nom de l’appliance, du domaine ou de l’organisation
5. Stocker le mot de passe dans un gestionnaire de mots de passe (Bitwarden, 1Password, CyberArk)
6. Documenter le compte de récupération break-glass et son mot de passe dans un coffre hors-ligne

Valeur par défaut : admin / password
Critère de conformité : Mot de passe complexe ≥ 12 caractères, non par défaut

---

2.2 — Activation de la MFA pour tous les comptes administrateurs

Niveau : 🔴 Critique
Référence CIS : CIS Control 6.3 — Require MFA for Externally-Exposed Applications | CIS Control 6.4 — Require MFA for Remote Network Access
MITRE ATT&CK : T1078 — Valid Accounts | T1110 — Brute Force | T1556 — Modify Authentication Process

Description du risque :
La MFA est la mesure de protection la plus efficace contre le vol de credentials. Après exploitation de CVE-2024-40766, les acteurs de la menace ont ciblé des appliances SonicWall exposées sans MFA pour établir des comptes backdoor persistants. Sans MFA, un mot de passe volé (phishing, breach, brute-force) suffit à compromettre l’administration complète du firewall.

Impact potentiel :
Compromission totale de l’appliance, modification silencieuse des règles, création d’accès VPN pour le groupe d’attaque, exfiltration de la configuration (secrets VPN, topology réseau).

Vérification :

1. Naviguer vers Device > Users > Local Users
2. Cliquer sur chaque compte administrateur > Edit > Login Policies
3. Vérifier que “Require TOTP” ou “Require RADIUS OTP” est activé
4. Tester le login admin : une demande de code MFA doit apparaître après les credentials

Remédiation :
Méthode TOTP (Gen 7/8) :

1. Device > Users > Local Users > admin > Edit > Login Policies
2. Activer “Require TOTP for this user”
3. Scanner le QR code avec une app TOTP (Google Authenticator, Authy, Microsoft Authenticator)
4. Tester immédiatement avant de fermer la session active

Méthode RADIUS MFA :

1. Configurer le serveur RADIUS MFA (DUO, RSA SecurID, Azure MFA via NPS)
2. Device > Users > Settings > Authentication Method : sélectionner RADIUS
3. Device > Users > Settings > Configure RADIUS : renseigner IP, port, shared secret
4. Tester depuis un compte non-admin avant d’appliquer à tous les admins

Valeur par défaut : MFA désactivée
Critère de conformité : MFA activée sur TOUS les comptes avec accès administrateur, testée et fonctionnelle

---

2.3 — Activation de la MFA pour tous les utilisateurs SSL-VPN

Niveau : 🔴 Critique
Référence CIS : CIS Control 6.3 — Require MFA for Externally-Exposed Applications
MITRE ATT&CK : T1133 — External Remote Services | T1078 — Valid Accounts | T1110.003 — Password Spraying

Description du risque :
Le SSL-VPN SonicWall est le vecteur d’attaque le plus fréquemment exploité par les groupes de ransomware. Huntress a documenté des campagnes de compromission à grande échelle de firewalls SonicWall Gen 7 via SSL-VPN sans MFA. CVE-2024-12802 permet de bypasser la MFA si le champ userPrincipalName est configuré dans les paramètres LDAP — ce bug affecte les configurations LDAP standard.

Bug CVE-2024-12802 — Bypass MFA via LDAP :
Si userPrincipalName (format [email protected]) est utilisé comme “Qualified login name” dans la configuration LDAP, un attaquant peut s’authentifier avec le format [email protected] et contourner la MFA. Retirer userPrincipalName du champ et utiliser sAMAccountName uniquement.

Vérification :

1. Naviguer vers Device > Settings > SSL VPN > Server Settings
2. Vérifier que l’authentification MFA est requise pour tous les utilisateurs VPN
3. Vérifier la configuration LDAP : Device > Users > Settings > Configure LDAP > Edit > Schema
4. Vérifier que le champ “Qualified login name” ne contient PAS userPrincipalName

Remédiation :

1. Correction CVE-2024-12802 :

   • Naviguer vers Device > Users > Settings > Configure LDAP > Edit > Schema (onglet)
   • Dans le champ “Qualified login name (email format)” : retirer userPrincipalName
   • Laisser uniquement sAMAccountName ou désactiver le champ email

2. Activation MFA SSL-VPN :

   • Device > Users > Settings > Authentication Method : RADIUS + MFA ou TOTP
   • Configurer le groupe VPN pour exiger MFA
   • Tester avec un compte de test avant déploiement

3. Restreindre les groupes VPN : seuls les utilisateurs dans un groupe VPN autorisé peuvent se connecter

Valeur par défaut : MFA désactivée sur SSL-VPN
Critère de conformité : MFA obligatoire sur SSL-VPN, LDAP sans userPrincipalName

---

2.4 — Activation du verrouillage de compte après échecs de connexion

Niveau : 🟡 L1
Référence CIS : CIS Control 6.2 — Establish an Access Revoking Process
MITRE ATT&CK : T1110 — Brute Force | T1110.001 — Password Guessing | T1110.003 — Password Spraying

Description du risque :
Sans mécanisme de verrouillage, les attaquants peuvent effectuer des attaques par force brute ou password spraying sans contrainte de taux. Les firewalls SonicWall exposés sur Internet reçoivent en permanence des tentatives de connexion automatisées. Shodan et les scanners de botnet identifient les interfaces de connexion et tentent des milliers de combinaisons par heure.

Vérification :

1. Naviguer vers Device > Settings > Administration > Login/Password
2. Vérifier que “Enable Administrator/User Login Lockout” est coché
3. Vérifier le seuil : ≤ 5 tentatives avant verrouillage
4. Vérifier la durée de verrouillage : ≥ 5 minutes (recommandé : 15 minutes)

Note : SonicOS 7.3+ et 8.0.3+ activent cette fonctionnalité par défaut avec un seuil de 3 tentatives.

Remédiation :

1. Device > Settings > Administration > Login/Password (Gen 7) ou System > Administration (Gen 6)
2. Cocher “Enable Administrator Login Lockout”
3. Configurer : Maximum Login Attempts = 3 à 5
4. Configurer : Lockout Period = 15 minutes minimum
5. Activer également pour les utilisateurs VPN : Device > Users > Settings > Authentication > Login Lockout
6. Configurer les alertes email sur verrouillage de compte

Valeur par défaut : Désactivé sur Gen 6 ; activé (3 tentatives) sur Gen 7 SonicOS 7.3+ et Gen 8 SonicOS 8.0.3+
Critère de conformité : Lockout activé, seuil ≤ 5 tentatives, durée ≥ 15 minutes

---

2.5 — Application d’une politique de complexité des mots de passe

Niveau : 🟡 L1
Référence CIS : CIS Control 5.2 — Use Unique Passwords
MITRE ATT&CK : T1110.002 — Password Cracking | T1110.001 — Password Guessing

Description du risque :
Des mots de passe faibles sont vulnérables aux attaques par dictionnaire et par force brute, même avec un mécanisme de lockout (notamment si l’attaquant utilise un password spray lent pour éviter le lockout). L’application de règles de complexité est une mesure préventive de base.

Vérification :

1. Naviguer vers Device > Settings > Administration > Password Management (Gen 7/8)
2. Vérifier que “Enforce Password Complexity” est activé
3. Vérifier la longueur minimale : ≥ 8 caractères (recommandé : 12)
4. Vérifier que les critères de complexité sont activés : majuscules, minuscules, chiffres, caractères spéciaux

Note : Fonctionnalité disponible uniquement sur Gen 7 SonicOS 7.3+ et Gen 8 SonicOS 8.0.3+

Remédiation :

1. Device > Settings > Administration (SonicOS 7.3/8.0.3+)
2. Section “Password Management” ou “Login Security” :
   • Cocher “Enforce Password Complexity”
   • Minimum Password Length : 12 caractères
   • Cocher toutes les cases : Upper Case, Lower Case, Numeric, Special Character
3. Sur Gen 6 : appliquer une politique de mot de passe par convention documentée (pas de contrôle natif)

Valeur par défaut : Complexité non imposée sur Gen 6/7 (pré-7.3)
Critère de conformité : Complexité imposée, longueur minimale 12 caractères

---

2.6 — Suppression ou désactivation des comptes inutilisés

Niveau : 🟡 L1
Référence CIS : CIS Control 5.3 — Disable Dormant Accounts
MITRE ATT&CK : T1078 — Valid Accounts | T1078.003 — Local Accounts

Description du risque :
Les comptes dormants représentent une surface d’attaque silencieuse. Un compte créé temporairement pour un prestataire ou un test et oublié peut être exploité si ses credentials sont compromis. Les comptes dormants ne génèrent pas d’alertes sur les connexions inhabituelles car leur absence d’activité habituelle les rend invisibles.

Vérification :

1. Naviguer vers Device > Users > Local Users
2. Lister tous les comptes locaux
3. Identifier les comptes sans connexion récente (vérifier les logs) ou sans propriétaire identifiable
4. Identifier les comptes de test, temporaires, ou liés à d’anciens prestataires

Remédiation :

1. Lister tous les comptes : Device > Users > Local Users
2. Pour chaque compte : identifier propriétaire, date de création, justification métier
3. Supprimer les comptes sans propriétaire actif ou désactivés : Edit > uncheck “Enable User”
4. Documenter les comptes actifs avec leur justification dans une feuille d’inventaire
5. Appliquer la revue des comptes tous les 6 mois (aligner avec contrôle 10.2)

Valeur par défaut : Seul le compte admin existe — les comptes supplémentaires sont créés manuellement
Critère de conformité : Aucun compte dormant ou non documenté

---

2.7 — Désactivation du compte local si LDAP/RADIUS actif

Niveau : 🟡 L1
Référence CIS : CIS Control 5.6 — Centralize Account Management
MITRE ATT&CK : T1078.003 — Local Accounts | T1556 — Modify Authentication Process

Description du risque :
Quand l’authentification centralisée (LDAP/RADIUS) est en place, les comptes locaux constituent un vecteur de bypass de la politique centrale (pas de MFA, pas de révocation automatique). Un attaquant qui compromet un compte local peut contourner les contrôles LDAP/RADIUS.

Vérification :

1. Vérifier si LDAP/RADIUS est configuré : Device > Users > Settings > Authentication Method
2. Si LDAP/RADIUS actif : naviguer vers Device > Users > Local Users
3. Vérifier qu’il ne reste que le compte break-glass admin (documenté, mot de passe en coffre)
4. Tous les autres comptes locaux doivent être désactivés ou supprimés

Remédiation :

1. S’assurer que LDAP/RADIUS fonctionne correctement avant de désactiver les comptes locaux
2. Conserver UN compte break-glass admin local avec un mot de passe fort en coffre hors-ligne
3. Désactiver tous les autres comptes locaux : Edit > uncocher “Enable User”
4. Documenter le compte break-glass : accès limité, mot de passe rotatif annuellement

Valeur par défaut : Comptes locaux actifs par défaut
Critère de conformité : Si LDAP/RADIUS actif : un seul compte local break-glass, tous autres désactivés

---

2.8 — Réinitialisation des mots de passe après migration Gen 6 → Gen 7

Niveau : 🔴 Critique
Référence CIS : CIS Control 5.2 — Use Unique Passwords
MITRE ATT&CK : T1078 — Valid Accounts | T1550 — Use Alternate Authentication Material

Description du risque :
SonicWall a documenté que les mots de passe migés depuis Gen 6 vers Gen 7 présentent une vulnérabilité liée au traitement cryptographique des hachages. CVE-2024-40766 a été exploitée sur des appliances Gen 7 — le vecteur exact via la migration Gen 6→Gen 7 n’est pas officiellement documenté par SonicWall comme cause directe. La recommandation de réinitialisation post-migration est une mesure de précaution adoptée par les équipes de réponse à incident (Huntress, Mandiant) plutôt qu’une cause confirmée par l’éditeur.

Vérification :

1. Vérifier si l’appliance Gen 7 a été configurée via import depuis Gen 6 (consulter les logs ou la documentation)
2. Si migration effectuée : vérifier si les mots de passe de tous les comptes ont été réinitialisés depuis
3. Device > System > Diagnostics > Tech Support Report : rechercher “imported config” dans les logs

Remédiation :

1. Réinitialiser le mot de passe de TOUS les comptes locaux (admin + utilisateurs VPN)
2. Réinitialiser également les PSK (Pre-Shared Keys) de tous les tunnels VPN site-à-site
3. Réinitialiser les community strings SNMP
4. Réinitialiser les credentials LDAP/RADIUS si le secret partagé a été migré
5. Après réinitialisation : activer la MFA sur tous les comptes (voir 2.2 et 2.3)

Valeur par défaut : Les mots de passe sont migrés tels quels — aucune réinitialisation automatique
Critère de conformité : Tous les secrets réinitialisés post-migration, documenté et daté

---

2.9 — Configuration RADIUS ou LDAP pour l’authentification centralisée

Niveau : 🔵 L2
Référence CIS : CIS Control 5.6 — Centralize Account Management
MITRE ATT&CK : T1078 — Valid Accounts | T1556 — Modify Authentication Process

Description du risque :
La gestion locale des comptes sur chaque appliance crée une dette opérationnelle : les départs de collaborateurs, les révocations d’accès et les rotations de mots de passe doivent être gérés individuellement sur chaque équipement. L’authentification centralisée via LDAP/Active Directory ou RADIUS permet une gestion cohérente et la révocation instantanée des accès.

Vérification :

1. Naviguer vers Device > Users > Settings > Authentication Method
2. Vérifier que “LDAP + Local Users” ou “RADIUS + Local Users” est sélectionné
3. Cliquer sur Configure LDAP/RADIUS : tester la connectivité

Remédiation :
Configuration LDAP (Active Directory) :

1. Device > Users > Settings > Authentication Method : sélectionner “LDAP + Local Users”
2. Cliquer sur Configure LDAP :
   • Server : IP/nom du contrôleur de domaine
   • Port : 389 (LDAP) ou 636 (LDAPS — recommandé)
   • Bind DN : compte de service AD dédié (lecture seule)
   • Base DN : DC=domain,DC=com
3. Onglet Schema : configurer le mapping des attributs
4. Onglet Directory : tester la connexion et l’importation des groupes
5. Attribuer des groupes AD aux rôles SonicWall (Admin, Limited Admin, Users)

Configuration RADIUS :

1. Sélectionner “RADIUS + Local Users”
2. Renseigner IP serveur RADIUS, port (1812), shared secret
3. Tester avec un compte de test

Valeur par défaut : Authentification locale uniquement
Critère de conformité : LDAP ou RADIUS configuré, testé, groupes mappés aux rôles SonicWall

---

2.10 — Configuration des timeouts de session inactifs

Niveau : 🔵 L2
Référence CIS : CIS Control 4.3 — Configure Automatic Session Locking
MITRE ATT&CK : T1078 — Valid Accounts | T1185 — Browser Session Hijacking

Description du risque :
Une session administrative laissée ouverte sur un poste non surveillé peut être exploitée physiquement ou via un malware de type RAT. Des sessions VPN inactives prolongées augmentent la fenêtre d’exploitation en cas de vol de token de session.

Vérification :

1. Device > Settings > Administration > Login/Password : vérifier “Web Management Inactivity Timeout”
2. Valeur recommandée : 10-15 minutes
3. Device > VPN > SSL VPN > Server Settings : vérifier “Session Timeout” et “Idle Timeout”

Remédiation :

1. Interface d’administration :
   • Device > Settings > Administration > Login/Password
   • “Web Management Inactivity Timeout” : 10 minutes (max recommandé : 15)
2. Sessions SSL-VPN :
   • Device > VPN > SSL VPN > Server Settings
   • “Session Timeout” : 480 minutes (8h) maximum
   • “Idle Timeout” : 30 minutes maximum

Valeur par défaut : Timeout d’inactivité : 5-10 minutes (variable selon version)
Critère de conformité : Timeout admin ≤ 15 minutes, Idle VPN ≤ 30 minutes

---

🖥️ DOMAINE 3 — SÉCURISATION DE L’INTERFACE D’ADMINISTRATION

L’interface de gestion est la cible privilégiée des attaquants cherchant à prendre le contrôle total du firewall. Une interface d’administration exposée sur Internet est une invitation à l’intrusion. Ce domaine couvre la réduction drastique de la surface d’attaque administrative.

---

3.1 — Restriction de l’accès d’administration depuis le WAN

Niveau : 🔴 Critique
Référence CIS : CIS Control 12.3 — Securely Manage Network Infrastructure
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1133 — External Remote Services | T1046 — Network Service Scanning

Description du risque :
L’exposition de l’interface d’administration SonicWall sur Internet est l’un des vecteurs d’attaque les plus documentés. Shodan recense en permanence des milliers d’interfaces SonicWall accessibles depuis Internet. Les groupes Akira, LockBit et les acteurs étatiques automatisent la détection et l’exploitation. La CISA et le CERT-EU recommandent explicitement de ne jamais exposer les interfaces de gestion de firewall sur Internet.

Vérification :

1. Naviguer vers Network > Interfaces > WAN
2. Cliquer sur l’interface WAN > Edit > Management (onglet)
3. Vérifier que “HTTPS” est décoché sous “Management” (ou restreint par règle)
4. Vérifier les Access Rules : Policy > Rules and Policies > Access Rules
5. Filtrer WAN→SonicWall : aucune règle ne doit autoriser HTTPS (port 443 gestion) depuis “Any” source
6. Tester depuis un outil externe (shodan.io, nmap depuis réseau externe)

Remédiation :

1. Network > Interfaces > WAN > Edit > onglet Management : décocher “HTTPS” et “SSH”
2. Créer une Access Rule restrictive si accès WAN temporaire nécessaire :
   • Policy > Rules and Policies > Access Rules > Add
   • Source : groupe d’IPs de confiance (IP fixe du poste admin)
   • Destination : SonicWall (Firewall)
   • Service : HTTPS Management (port 4433 ou port configuré)
   • Action : Allow + Logging activé
3. Ajouter une règle de refus explicite pour toute autre source WAN vers l’interface de gestion
4. Préférer l’accès via Jump Host ou tunnel VPN établi en premier lieu

Valeur par défaut : HTTPS Management accessible depuis WAN par défaut sur certains modèles
Critère de conformité : Aucun accès administration direct depuis WAN sans restriction IP source

---

3.2 — Désactivation de HTTP, forcer HTTPS uniquement

Niveau : 🟡 L1
Référence CIS : CIS Control 3.10 — Encrypt Sensitive Data in Transit
MITRE ATT&CK : T1040 — Network Sniffing | T1557 — Adversary-in-the-Middle

Description du risque :
HTTP transmet les credentials d’administration en clair sur le réseau. Un attaquant en position de man-in-the-middle (sur le même segment réseau de gestion ou via ARP spoofing) peut capturer le mot de passe administrateur. De plus, HTTP n’offre aucune protection contre la falsification des réponses (modification du contenu de l’interface web).

Vérification :

1. Tenter d’accéder à http://{IP-SONICWALL}/ depuis un navigateur
2. Si la page s’affiche sans redirection HTTPS : contrôle ÉCHOUÉ
3. Network > Interfaces : vérifier que “HTTP” est décoché pour chaque interface

Remédiation :

1. Pour chaque interface active : Network > Interfaces > {Interface} > Edit > onglet Management
2. Décocher “HTTP” dans la liste des protocoles de gestion autorisés
3. S’assurer que “HTTPS” est coché
4. Configurer TLS minimum : Device > Settings > Administration > Certificate Settings — TLS 1.2 minimum (TLS 1.3 recommandé)
5. Configurer la redirection HTTP → HTTPS si le HTTP doit rester ouvert pour des raisons opérationnelles

Valeur par défaut : HTTP et HTTPS tous deux activés sur LAN
Critère de conformité : HTTP désactivé sur toutes les interfaces de gestion

---

3.3 — Restriction ou désactivation de SSH

Niveau : 🟡 L1
Référence CIS : CIS Control 12.3 — Securely Manage Network Infrastructure
MITRE ATT&CK : T1021.004 — Remote Services: SSH | T1110 — Brute Force

Description du risque :
L’accès SSH au SonicWall expose une interface de diagnostic et de configuration en ligne de commande. Si SSH est activé sans restriction IP source, il est vulnérable aux attaques par brute-force et aux exploits SSH. Un accès SSH non restreint depuis Internet est détecté et attaqué en quelques minutes par les botnets Mirai et ses variantes.

Vérification :

1. Network > Interfaces > WAN > Edit > onglet Management : vérifier si “SSH” est coché
2. Vérifier les Access Rules pour SSH (port 22) depuis WAN

Remédiation :

1. Si SSH non utilisé : Network > Interfaces > toutes les interfaces > Edit > Management — décocher “SSH”
2. Si SSH nécessaire pour des opérations ponctuelles :
   • Créer une Access Rule restrictive (IP source = IP de l’administrateur uniquement)
   • Activer SSH uniquement pendant la fenêtre de maintenance
   • Désactiver SSH après utilisation
3. Ne jamais laisser SSH ouvert depuis WAN vers “Any” source

Valeur par défaut : SSH activé sur LAN, désactivé sur WAN (selon modèle)
Critère de conformité : SSH désactivé ou restreint à des IPs de gestion documentées

---

3.4 — Utilisation d’un certificat TLS valide pour l’interface web

Niveau : 🟡 L1
Référence CIS : CIS Control 3.10 — Encrypt Sensitive Data in Transit
MITRE ATT&CK : T1557 — Adversary-in-the-Middle | T1040 — Network Sniffing

Description du risque :
Le certificat auto-signé SonicWall par défaut génère des alertes de sécurité dans les navigateurs. Les utilisateurs habitués à ignorer ces alertes sont vulnérables aux attaques man-in-the-middle utilisant un certificat malveillant. De plus, sans certificat valide, la vérification de l’authenticité du serveur est impossible.

Vérification :

1. Accéder à l’interface HTTPS du SonicWall depuis un navigateur
2. Vérifier l’icône cadenas : un certificat valide signé par une CA de confiance doit apparaître
3. Cliquer sur le cadenas > vérifier la CA, le CN (Common Name) et la date d’expiration
4. Device > Settings > Administration > Certificate Settings : voir le certificat actuel

Remédiation :
Option A — Certificat Let’s Encrypt (si accès DNS public) :

1. Générer un certificat via Certbot ou ACME (le SonicWall ne supporte pas nativement Let’s Encrypt — générer sur un serveur externe)
2. Device > System > Certificates > Import Certificate : importer .pfx ou .pem + clé privée
3. Device > Settings > Administration > Certificate Settings : sélectionner le nouveau certificat

Option B — Certificat CA interne :

1. Émettre un certificat depuis la PKI interne (Active Directory Certificate Services ou autre)
2. Importer le certificat dans SonicWall
3. Déployer la CA racine interne sur tous les postes clients via GPO

Valeur par défaut : Certificat auto-signé
Critère de conformité : Certificat valide, signé par CA de confiance, non expiré

---

3.5 — Désactivation de SNMP ou durcissement de sa configuration

Niveau : 🟡 L1
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1046 — Network Service Scanning | T1592 — Gather Victim Host Information

Description du risque :
SNMP v1 et v2c utilisent des community strings en clair sur le réseau UDP. La community string par défaut public (lecture) et private (écriture) sont universellement connues. Un attaquant ayant accès au réseau de gestion peut interroger le firewall via SNMP pour obtenir la topologie réseau complète, les routes, les interfaces et les statistiques. SNMPv2c avec écriture permet même de modifier la configuration sur certaines implémentations.

Vérification :

1. Device > Settings > SNMP : vérifier si SNMP est activé
2. Vérifier la version : v1/v2c (faible) ou v3 (recommandé)
3. Si v1/v2c : vérifier que la community string n’est pas public ou private
4. Vérifier les restrictions d’accès par IP source

Remédiation :
Si SNMP non utilisé :

1. Device > Settings > SNMP : désactiver SNMP

Si SNMP nécessaire pour supervision :

1. Migrer vers SNMPv3 :
   • Créer un utilisateur SNMPv3 avec authentification SHA et chiffrement AES-128
   • Désactiver SNMPv1 et v2c
2. Restreindre par IP source : créer une Access Rule autorisant SNMP (UDP 161) uniquement depuis l’IP du SIEM/NMS
3. Si v2c incontournable : changer la community string (public/private → chaîne aléatoire ≥ 16 caractères)

Valeur par défaut : SNMP désactivé par défaut
Critère de conformité : SNMP désactivé, ou SNMPv3 avec SHA+AES, restreint par IP

---

3.6 — Désactivation des protocoles de gestion non utilisés

Niveau : 🔵 L2
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1046 — Network Service Scanning | T1190 — Exploit Public-Facing Application

Description du risque :
Chaque protocole de gestion activé représente une surface d’attaque supplémentaire. Le principe de moindre exposition dicte de n’activer que les protocoles strictement nécessaires. Telnet transmet tout en clair et ne doit jamais être utilisé.

Vérification :

1. Network > Interfaces : pour chaque interface, vérifier les cases cochées (HTTP, HTTPS, SSH, Ping, SNMP, etc.)
2. Lister les protocoles actifs vs les protocoles réellement utilisés en production

Remédiation :

1. Pour chaque interface : Network > Interfaces > {Interface} > Edit > Management
2. Décocher tout protocole non utilisé
3. Désactiver Ping depuis WAN sauf si nécessaire pour le monitoring ISP :
   • Créer une Access Rule spécifique autorisant ICMP uniquement depuis les IPs du monitoring
4. Si Telnet est activé (rare sur SonicWall récent) : désactiver immédiatement

Valeur par défaut : Variable selon modèle et version SonicOS
Critère de conformité : Seuls les protocoles de gestion strictement nécessaires sont activés

---

3.7 — Compte en lecture seule pour la supervision

Niveau : 🔵 L2
Référence CIS : CIS Control 5.4 — Restrict Administrator Privileges to Dedicated Administrator Accounts
MITRE ATT&CK : T1078.003 — Local Accounts | T1548 — Abuse Elevation Control Mechanism

Description du risque :
Utiliser le compte administrateur principal pour les accès de supervision (monitoring, vérifications périodiques, accès depuis des outils d’audit) expose inutilement les credentials admin. Un compte de lecture seule limite l’impact d’une compromission : l’attaquant voit la configuration mais ne peut pas la modifier.

Vérification :

1. Device > Users > Local Users : vérifier l’existence d’un compte avec rôle “Guest Services” ou “Read Only Admin”
2. Vérifier que les outils de supervision (SIEM, NMS) n’utilisent pas le compte admin principal

Remédiation :

1. Device > Users > Local Users > Add
2. Nom : supervision ou readonly-monitor
3. Mot de passe complexe unique
4. Onglet Privileges : sélectionner “Limited Administrator” avec droits en lecture seule uniquement
5. Activer ce compte dans les outils de supervision/SIEM en remplacement du compte admin

Valeur par défaut : Aucun compte de supervision dédié
Critère de conformité : Compte read-only dédié pour supervision, compte admin non utilisé pour monitoring

---

3.8 — Désactivation de l’API SonicOS REST si non utilisée

Niveau : 🔵 L2
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1059.007 — JavaScript

Description du risque :
L’API REST SonicOS (Gen 7/8) permet une configuration complète de l’appliance via HTTP/HTTPS. Si l’API est exposée et non sécurisée, elle représente un vecteur d’attaque supplémentaire. Des vulnérabilités dans l’implémentation REST peuvent permettre l’accès non authentifié ou l’escalade de privilèges.

Vérification :

1. Device > Settings > Administration : rechercher “REST API” ou “API Management”
2. Vérifier si l’API REST est activée
3. Si activée : vérifier les clés API créées et leur portée (Device > Settings > API Management Keys)

Remédiation :
Si API REST non utilisée :

1. Device > Settings > Administration : désactiver “Enable REST API”

Si API REST utilisée (automatisation, SIEM, SOAR) :

1. Créer des clés API à portée minimale (read-only si possible)
2. Configurer une expiration des clés API
3. Restreindre les appels API par IP source via Access Rules
4. Ne jamais exposer l’API REST depuis le WAN
5. Rotation des clés API tous les 90 jours

Valeur par défaut : API REST désactivée par défaut
Critère de conformité : API REST désactivée, ou activée avec clés à portée minimale, restreinte par IP, rotation 90j

---

3.9 — Liste blanche IPv4/IPv6 pour l’accès d’administration (Administrative Allow List)

Niveau : 🔴 Critique
Référence CIS : CIS Control 12.3 — Securely Manage Network Infrastructure
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1078 — Valid Accounts

Description du risque :
SonicWall Gen 7/8 propose une fonctionnalité native d’IPv4/IPv6 Management Access List permettant de restreindre l’accès à l’interface d’administration à une liste d’adresses IP ou plages explicitement autorisées, indépendamment des Access Rules. C’est le contrôle le plus direct et le plus fiable pour limiter l’exposition de l’interface de gestion : même si une Access Rule est mal configurée, la liste blanche d’administration s’applique en priorité.

Impact potentiel :
Sans cette liste, tout hôte résolvant l’IP de l’appliance (même depuis WAN si HTTPS Management est ouvert) peut accéder au portail de login. Avec la liste, seules les IPs autorisées voient même la page de login.

Vérification :

1. Naviguer vers Device > Settings > Administration
2. Section Management Access ou Administrator Settings
3. Rechercher “IPv4/IPv6 Management Access List” ou “Management Source IP”
4. Vérifier qu’une liste blanche est configurée et active

Remédiation :

1. Device > Settings > Administration > Management Access :
   • Activer “Enable Management Access List”
   • Ajouter les IPs/plages autorisées : postes d’administration, bastion, IP fixe IT
   • Format IPv4 : 192.168.1.0/24 ou 10.0.0.5/32
   • Format IPv6 : 2001:db8::/32
2. Tester l’accès depuis une IP autorisée avant de valider
3. Tester l’absence d’accès depuis une IP non autorisée
4. Documenter les IPs de la liste (propriétaire, justification)

Valeur par défaut : Liste vide — aucune restriction sur les IPs de gestion
Critère de conformité : Liste blanche configurée avec ≥ 1 entrée, accès vérifié depuis IP non autorisée

---

3.10 — Forcer TLS 1.3 et cipher suites modernes

Niveau : 🔵 L2
Référence CIS : CIS Control 3.10 — Encrypt Sensitive Data in Transit
MITRE ATT&CK : T1557 — Adversary-in-the-Middle | T1040 — Network Sniffing

Description du risque :
TLS 1.0 et 1.1 présentent des vulnérabilités connues (BEAST, POODLE, SLOTH). TLS 1.2 avec des cipher suites faibles (RC4, DES, 3DES, export ciphers) peut être attaqué par des adversaires avec capacité de Man-in-the-Middle. TLS 1.3 offre Perfect Forward Secrecy par défaut et supprime les cipher suites obsolètes.

Vérification :

1. Device > Settings > Administration > Certificate Settings ou Advanced Settings
2. Vérifier la version TLS minimale configurée
3. Tester depuis un navigateur : les protocoles acceptés (F12 > Security tab ou testssl.sh)
4. Pour DPI-SSL : vérifier les cipher suites dans Security Services > DPI-SSL > Settings

Remédiation :

1. Device > Settings > Administration :
   • TLS Minimum Version : TLS 1.2 (TLS 1.3 recommandé si tous les clients le supportent)
   • Désactiver TLS 1.0 et TLS 1.1
2. Cipher suites à désactiver (si option disponible) : RC4, DES, 3DES, NULL, EXPORT, anon
3. Cipher suites recommandées : AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305
4. Pour le DPI-SSL : s’assurer que les cipher suites d’inspection sont également modernes

Note de compatibilité SonicOS 8 : Les options de configuration TLS peuvent différer entre Gen 7 et Gen 8. Vérifier la documentation spécifique au firmware installé.

Valeur par défaut : TLS 1.2 activé, TLS 1.0/1.1 parfois encore disponibles
Critère de conformité : TLS 1.0/1.1 désactivés, TLS 1.2 minimum, cipher suites modernes uniquement

---

3.11 — Désactivation des Application Layer Gateways (ALG) non utilisés

Niveau : 🔵 L2
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1203 — Exploitation for Client Execution

Description du risque :
Les Application Layer Gateways (ALG) sont des modules d’inspection applicative intégrés au firewall pour des protocoles spécifiques (SIP/voix, H.323 vidéoconférence, FTP, TFTP, RTSP). Chaque ALG actif représente une surface d’attaque supplémentaire : des vulnérabilités dans l’implémentation d’un ALG peuvent permettre des attaques de traversée de firewall (NAT traversal exploits) ou des déni de service.

ALGs courants sur SonicWall :

ALG	Protocole	Désactiver si…
SIP ALG	VoIP SIP (UDP 5060)	Pas de téléphonie SIP gérée par ce firewall
H.323 ALG	Vidéoconférence H.323	Pas de visioconférence legacy
FTP ALG	FTP (TCP 21)	FTP non utilisé ou remplacé par SFTP/FTPS
TFTP ALG	TFTP (UDP 69)	TFTP non utilisé
RTSP ALG	Streaming RTSP	Pas de streaming media géré

Vérification :

1. Network > Zones > {zone} > Edit ou Firewall > Advanced
2. Rechercher “VoIP”, “H.323”, “FTP” dans les paramètres avancés
3. Lister les ALGs activés vs les protocoles réellement utilisés

Remédiation :

1. Inventorier les protocoles VoIP, vidéo, FTP réellement utilisés sur le réseau
2. Pour chaque ALG non utilisé : Network > Zones > {zone} > Advanced — décocher l’ALG
3. SIP ALG : si la téléphonie IP utilise un codec moderne (Opus, G.722) et un proxy SIP correctement configuré, le SIP ALG peut causer des problèmes — le désactiver et laisser le SIP passer sans inspection ALG
4. Tester la téléphonie/vidéo après désactivation

Valeur par défaut : SIP ALG activé par défaut sur SonicWall
Critère de conformité : Seuls les ALGs pour des protocoles activement utilisés sont activés

---

🌐 DOMAINE 4 — ZONES ET SEGMENTATION RÉSEAU

La segmentation réseau est le principal mécanisme de containment en cas de compromission. Sans segmentation, un attaquant qui compromet un poste utilisateur peut directement atteindre les serveurs critiques, l’AD et les systèmes OT/IoT. Ce domaine implémente le principe de défense en profondeur au niveau réseau.

---

4.1 — Segmentation par zones (LAN/WAN/DMZ/Custom)

Niveau : 🟡 L1
Référence CIS : CIS Control 12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK : T1021 — Remote Services | T1534 — Internal Spearphishing | T1570 — Lateral Tool Transfer

Description du risque :
Un réseau plat (flat network) sans segmentation permet aux attaquants de se déplacer latéralement sans obstacle après une première compromission. Le mouvement latéral est la technique utilisée pour atteindre les systèmes critiques (DC, serveurs de sauvegarde, ERP) depuis un point d’entrée initial (poste utilisateur, imprimante, VPN).

Impact potentiel :
En l’absence de segmentation, le temps moyen pour un attaquant pour passer d’un poste utilisateur compromis à un contrôleur de domaine est de 2-4 heures selon les études MITRE/CrowdStrike.

Vérification :

1. Network > Zones : lister toutes les zones définies
2. Vérifier l’existence de zones distinctes pour : LAN utilisateurs, DMZ serveurs exposés, WLAN, IoT, MGMT
3. Policy > Rules and Policies > Access Rules : vérifier qu’il n’existe pas de flux LAN↔DMZ ou LAN↔Serveurs critiques non contrôlés

Remédiation :

1. Définir le schéma de zones selon la sensibilité des assets :
   • WAN : Internet
   • LAN : postes utilisateurs
   • DMZ : serveurs exposés (web, mail relay, portail)
   • SERVERS : serveurs internes critiques (AD, ERP, backups)
   • WLAN : réseau sans-fil
   • IOT : objets connectés
   • MGMT : gestion réseau (si possible)
2. Créer les interfaces physiques ou VLAN correspondants : Network > Interfaces > Add Interface
3. Assigner chaque interface à la zone appropriée
4. Définir des règles inter-zones explicites avec principe de moindre privilège

Valeur par défaut : Zones LAN, WAN, DMZ, WLAN prédéfinies — segmentation interne non configurée
Critère de conformité : ≥ 3 zones distinctes, aucun trafic non contrôlé entre zones sensibles

---

4.2 — Activation des services de sécurité sur toutes les zones pertinentes

Niveau : 🟡 L1
Référence CIS : CIS Control 13.3 — Deploy a Network Intrusion Detection Solution
MITRE ATT&CK : T1027 — Obfuscated Files or Information | T1071 — Application Layer Protocol

Description du risque :
L’IPS, le Gateway AV et l’Anti-Spyware sont configurés par zone dans SonicWall. Par défaut, ces services peuvent être désactivés sur certaines zones (notamment LAN-to-LAN). Un attaquant déjà présent dans le réseau qui tente un mouvement latéral passera sous le radar si l’inspection n’est pas activée sur les flux est-ouest.

Vérification :

1. Network > Zones : pour chaque zone active
2. Vérifier les colonnes : IPS, Gateway AV, Anti-Spyware — doivent afficher une coche verte pour LAN, DMZ, WLAN, MGMT

Remédiation :

1. Network > Zones > {Zone} > Edit
2. Onglet Security Services :
   • Cocher “Intrusion Prevention” : Enable IPS + Prevent All
   • Cocher “Gateway Anti-Virus” : Enable Gateway AV
   • Cocher “Anti-Spyware” : Enable Anti-Spyware
3. Répéter pour chaque zone active
4. Attention : Ne pas activer sur la zone WAN (l’inspection se fait au niveau des règles, pas de la zone WAN elle-même)

Valeur par défaut : Services de sécurité désactivés sur les zones LAN par défaut
Critère de conformité : IPS, AV, Anti-Spyware activés sur LAN, DMZ, WLAN, MGMT

---

4.3 — Zone dédiée pour les équipements IoT et OT

Niveau : 🟡 L1
Référence CIS : CIS Control 12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK : T1200 — Hardware Additions | T1498 — Network Denial of Service | T1570 — Lateral Tool Transfer

Description du risque :
Les équipements IoT (caméras IP, imprimantes, systèmes de contrôle d’accès, HVAC connecté) et OT (automates, SCADA) présentent des vulnérabilités chroniques : firmware non mis à jour, credentials par défaut, absence de chiffrement. Isoler ces équipements protège le réseau principal en cas de compromission IoT, un vecteur fréquent d’intrusion initiale.

Vérification :

1. Inventorier les équipements IoT/OT présents sur le réseau
2. Network > Zones : vérifier l’existence d’une zone IOT ou KIOSK séparée
3. Vérifier qu’aucun équipement IoT n’est sur le LAN utilisateurs principal

Remédiation :

1. Créer une zone IoT : Network > Zones > Add
   • Name : IOT
   • Security Type : Wireless ou Trusted selon usage
   • Activer IPS + Gateway AV sur cette zone
2. Créer un VLAN dédié pour IoT sur les switches managés
3. Créer une interface SonicWall associée : Network > Interfaces > Add VLAN
4. Access Rules IoT→LAN : refuser tout (sauf flux métier documentés explicitement)
5. Access Rules IoT→Internet : limiter aux destinations nécessaires

Valeur par défaut : Pas de zone IoT — les équipements sont souvent sur le LAN principal
Critère de conformité : Zone IoT dédiée, aucune communication IoT→LAN non autorisée

---

4.4 — Séparation du réseau sans-fil du réseau interne

Niveau : 🟡 L1
Référence CIS : CIS Control 12.6 — Use of Secure Network Management and Communication Protocols
MITRE ATT&CK : T1040 — Network Sniffing | T1557 — Adversary-in-the-Middle

Description du risque :
Le Wi-Fi est un vecteur d’intrusion courant : attaques Evil Twin, WPA2 PMKID, credential stuffing sur portail captif. Si le réseau Wi-Fi est dans la même zone que le LAN filaire, un attaquant qui compromet un client Wi-Fi a immédiatement accès aux ressources internes. La séparation Wi-Fi/LAN est une mesure fondamentale.

Vérification :

1. Network > Zones : identifier la zone WLAN
2. Vérifier que la zone WLAN est distincte de la zone LAN (pas bridgée)
3. Policy > Rules and Policies > Access Rules > WLAN to LAN : vérifier les règles existantes

Remédiation :

1. Configurer le point d’accès Wi-Fi sur une interface/VLAN séparé
2. Assigner l’interface Wi-Fi à la zone WLAN (pas LAN)
3. Access Rules WLAN→LAN : refuser tout par défaut
4. Autoriser uniquement les flux nécessaires (ex: WLAN→Internet, WLAN→imprimantes sécurisées)
5. Si réseau invité : créer une zone GUEST supplémentaire avec accès Internet uniquement

Valeur par défaut : Zone WLAN prédéfinie mais configuration dépend de l’installation
Critère de conformité : WLAN et LAN dans des zones distinctes, aucun accès WLAN→LAN sans règle explicite

---

4.5 — Zone de gestion dédiée (Out-of-Band Management)

Niveau : 🔵 L2
Référence CIS : CIS Control 12.3 — Securely Manage Network Infrastructure
MITRE ATT&CK : T1078 — Valid Accounts | T1021 — Remote Services

Description du risque :
Gérer le firewall depuis le même réseau que les utilisateurs expose l’interface de gestion aux menaces internes et aux malwares. Un réseau de gestion hors-bande (OOB) ou une zone MGMT dédiée garantit que seuls les équipements de gestion autorisés peuvent accéder à l’interface d’administration.

Vérification :

1. Network > Zones : vérifier l’existence d’une zone MGMT
2. Vérifier que les accès administratifs proviennent uniquement de cette zone
3. Access Rules : seule la zone MGMT peut accéder au Firewall (Management)

Remédiation :

1. Créer une zone MGMT : Network > Zones > Add — Zone Type : Management
2. Assigner une interface dédiée (physique ou VLAN)
3. Connecter les postes d’administration et bastions sur cette interface
4. Access Rules : n’autoriser l’accès à “Firewall” que depuis la zone MGMT
5. Bloquer l’accès d’administration depuis LAN, WLAN, DMZ

Valeur par défaut : Pas de zone de gestion dédiée
Critère de conformité : Zone MGMT définie, accès administration restreint à cette zone

---

4.6 — Audit des règles inter-zones et suppression des flux non justifiés

Niveau : 🔵 L2
Référence CIS : CIS Control 12.4 — Establish and Maintain Architecture Diagram(s)
MITRE ATT&CK : T1021 — Remote Services | T1570 — Lateral Tool Transfer

Description du risque :
La dérive des règles firewall (firewall rule creep) est un phénomène bien documenté : des règles temporaires deviennent permanentes, des règles trop permissives sont oubliées, des règles redondantes s’accumulent. Chaque règle “Any Any Allow” ou règle sans restriction de port est une porte potentiellement ouverte pour un mouvement latéral.

Vérification :

1. Policy > Rules and Policies > Access Rules : exporter toutes les règles
2. Filtrer par Action=Allow et analyser les règles Source=Any ou Destination=Any
3. Identifier les règles sans trafic récent (si SonicWall NSM disponible : statistiques de trafic par règle)
4. Identifier les règles sans commentaire/justification

Remédiation :

1. Exporter les règles actuelles comme baseline de référence
2. Pour chaque règle “Any Any Allow” :
   • Identifier le flux métier justifiant la règle
   • Remplacer par une règle précise (source IP/groupe, destination IP/groupe, port/service)
   • Si aucun flux justifié : désactiver (ne pas supprimer immédiatement — risque opérationnel)
3. Ajouter un commentaire à chaque règle : propriétaire, date, justification métier
4. Supprimer les règles désactivées après 30 jours de validation
5. Planifier la revue semestrielle (aligner avec contrôle 10.2)

Valeur par défaut : Règles par défaut incluent souvent des règles LAN→WAN trop permissives
Critère de conformité : Aucune règle “Any Any Allow” active, toutes les règles commentées et revues < 6 mois

---

🛡️ DOMAINE 5 — RÈGLES DE FIREWALL ET POLITIQUES D’ACCÈS

La politique de filtrage est le cœur fonctionnel du firewall. Des règles mal configurées annulent toute la valeur de l’équipement. Ce domaine définit les principes fondamentaux du filtrage : défense par défaut, moindre privilège, visibilité et protection contre les menaces volumétriques.

---

5.1 — Politique de refus par défaut (Default Deny)

Niveau : 🟡 L1
Référence CIS : CIS Control 12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK : T1048 — Exfiltration Over Alternative Protocol | T1571 — Non-Standard Port

Description du risque :
Le principe “default deny” (refus par défaut, autorisation explicite) est fondamental en sécurité réseau. Sans cette règle implicite, tout trafic non couvert par une règle explicite de refus est autorisé. Les malwares et C2 utilisent des ports non standard pour exfiltrer des données ou communiquer avec leur infrastructure — un firewall sans default deny les laisse passer.

Vérification :

1. Policy > Rules and Policies > Access Rules : défiler jusqu’à la dernière règle de chaque zone
2. La règle finale doit être : Source=Any, Destination=Any, Service=Any, Action=Deny
3. Sur SonicWall, la règle de refus implicite est built-in mais vérifier qu’elle n’a pas été outrepassée par une règle “Any Any Allow” en bas de liste

Remédiation :

1. Vérifier la règle implicite de refus : Policy > Rules and Policies > Access Rules — afficher la règle finale pour chaque paire de zones
2. Si une règle “Any Any Allow” existe en position finale : la supprimer ou la remplacer par “Any Any Deny”
3. Vérifier que le logging est activé sur la règle de refus implicite pour la détection d’anomalies
4. Activer : Device > Settings > Log > Categories — activer “Network Access” pour logger les connexions refusées

Valeur par défaut : Règle de refus implicite intégrée — mais peut être outrepassée par des règles explicites “Allow All”
Critère de conformité : Aucune règle “Any Any Allow” couvrant l’ensemble du trafic inter-zones

---

5.2 — Suppression des règles “Any Any Allow”

Niveau : 🟡 L1
Référence CIS : CIS Control 12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK : T1021 — Remote Services | T1570 — Lateral Tool Transfer | T1048 — Exfiltration

Description du risque :
Une règle “Any Any Allow” (source=Any, destination=Any, service=Any, action=Allow) annule tout filtrage et expose le réseau à des mouvements latéraux non contrôlés, à l’exfiltration de données et aux communications C&C. Ces règles sont souvent créées lors de dépannages urgents et oubliées en production.

Vérification :

1. Policy > Rules and Policies > Access Rules : utiliser le filtre pour afficher les règles Action=Allow
2. Chercher les règles avec Source=Any ET Destination=Any ET Service=Any
3. Vérifier également les règles avec destination=Any (même si source restreinte) sur des zones sensibles

Remédiation :

1. Identifier chaque règle “Any Any Allow” et son usage réel (vérifier les logs de trafic)
2. Pour chaque règle : définir la règle précise qui la remplace :
   • Source : groupe d’IPs ou zone spécifique
   • Destination : serveur/groupe cible
   • Service : protocole et port exacts
3. Désactiver la règle “Any Any Allow” (ne pas supprimer immédiatement) et tester en production 48h
4. Supprimer après validation
5. Activer les alertes sur la création de nouvelles règles “Any Any” : Enhanced Audit Logging

Valeur par défaut : SonicWall crée par défaut une règle LAN→WAN Any Allow
Critère de conformité : Aucune règle Any-Any-Allow active sur aucune zone

---

5.3 — Activation du logging sur toutes les règles de refus

Niveau : 🟡 L1
Référence CIS : CIS Control 8.2 — Collect Audit Logs
MITRE ATT&CK : T1046 — Network Service Scanning | T1018 — Remote System Discovery

Description du risque :
Les connexions refusées sont un signal de détection précieux : scans de ports, tentatives d’exploitation, exfiltration bloquée, mouvement latéral stoppé. Sans logging des refus, ces signaux sont perdus et les attaques ne sont pas détectables. Les SIEM utilisent les logs de connexions refusées pour détecter les scans de reconnaissance et les mouvements latéraux.

Vérification :

1. Policy > Rules and Policies > Access Rules : pour chaque règle Deny, vérifier l’icône Log (coche dans colonne Log)
2. Vérifier que la règle implicite de refus final génère des logs

Remédiation :

1. Pour chaque règle Deny : Edit règle > cocher “Log” dans les options
2. Activer le logging global des refus : Device > Settings > Log > Categories > Network Access > Dropped Connections
3. Configurer la destination Syslog pour recevoir ces logs : Device > Settings > Log > Automation > Syslog
4. Dans le SIEM : créer des alertes sur les pics de connexions refusées (indicateur de scan)

Valeur par défaut : Logging sur les règles de refus : désactivé par défaut sur certaines versions
Critère de conformité : Logging activé sur toutes les règles Deny et sur la règle implicite finale

---

5.4 — Désactivation des services WAN non utilisés

Niveau : 🟡 L1
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1046 — Network Service Scanning

Description du risque :
Chaque port ouvert sur l’interface WAN est une cible potentielle. Les services comme FTP (21), Telnet (23), NetBIOS (137-139), RPC (135), SMB (445) exposés sur Internet sont systématiquement scannés et attaqués. SonicWall expose parfois des services par défaut selon la configuration initiale.

Vérification :

1. Scanner l’adresse IP WAN depuis un réseau externe (nmap ou shodan.io)
2. Comparer les ports ouverts avec les services légitimement nécessaires
3. Vérifier les règles WAN→LAN qui exposent des services internes

Remédiation :

1. Pour chaque port ouvert non justifié : créer ou modifier une Access Rule WAN→Firewall ou WAN→LAN pour bloquer ce port
2. Services à bloquer depuis WAN (sauf usage spécifique documenté) : FTP(21), Telnet(23), SMTP(25), NetBIOS(137-139), SMB(445), RDP(3389), NFS(2049)
3. Rescanner après modifications pour valider
4. Documenter les ports WAN légitimement ouverts avec justification métier

Valeur par défaut : Selon la configuration — certains services peuvent être exposés via PAT/NAT sans intention
Critère de conformité : Aucun service non justifié ouvert sur WAN ; tous les ports documentés

---

5.5 — Filtrage Geo-IP pour les pays à risque

Niveau : 🔵 L2
Référence CIS : CIS Control 13.8 — Deploy a Network Intrusion Prevention Solution
MITRE ATT&CK : T1133 — External Remote Services | T1190 — Exploit Public-Facing Application

Description du risque :
La majorité des campagnes d’attaques ciblant les firewalls SonicWall proviennent de pays hébergeant des groupes de cybercriminalité et des acteurs étatiques. Le filtrage Geo-IP ne substitue pas la sécurité (les attaquants utilisent des proxies et VPS dans des pays tiers) mais réduit significativement le volume d’attaques automatisées provenant de ces régions.

Vérification :

1. Security Services > Geo-IP Filter : vérifier si activé
2. Vérifier la liste des pays bloqués
3. Vérifier qu’un groupe d’exclusion personnalisé est créé (ne pas utiliser le groupe par défaut SonicWall)

Remédiation :

1. Security Services > Geo-IP Filter > Enable Geo-IP Filtering
2. Créer un groupe personnalisé “Blocklist-GeoIP” avec les pays à bloquer :
   • Pays sans relation commerciale légitime avec l’organisation
   • Consulter les rapports de threat intelligence pour les pays sources d’attaques
3. Ne pas utiliser le groupe d’exclusion par défaut SonicWall — créer son propre groupe d’exclusion pour les IPs légitimes bloquées par erreur
4. Configurer le logging Geo-IP pour suivre les tentatives bloquées
5. Tester régulièrement : les mises à jour SonicWall peuvent modifier les groupes par défaut

Valeur par défaut : Filtrage Geo-IP désactivé
Critère de conformité : Geo-IP activé, liste pays bloqués documentée, groupe d’exclusion personnalisé créé

---

5.6 — Protection DoS/DDoS

Niveau : 🔵 L2
Référence CIS : CIS Control 13.4 — Perform Traffic Filtering Between Network Segments
MITRE ATT&CK : T1498 — Network Denial of Service | T1498.001 — Direct Network Flood | T1499 — Endpoint Denial of Service

Description du risque :
Les attaques DoS/DDoS peuvent saturer la bande passante WAN ou épuiser les ressources de l’appliance (table de connexions, CPU), rendant le réseau inaccessible. Les attaques SYN Flood sont particulièrement efficaces contre les firewalls avec stateful inspection non protégée. SonicWall implémente des mécanismes de protection intégrés qui doivent être configurés selon le profil de trafic.

Vérification :

1. Firewall Settings > Flood Protection (Gen 6) ou Policy > Security Configuration > Flood Protection (Gen 7/8)
2. Vérifier que SYN Flood, UDP Flood et ICMP Flood Protection sont activés
3. Vérifier les seuils configurés (trop bas = faux positifs, trop haut = protection inefficace)

Remédiation :

1. Firewall Settings > Flood Protection (Gen 6) ou équivalent Gen 7/8 :
   • SYN Flood Protection : Enable + configurer le seuil (ex: 200 incomplete connections/sec)
   • UDP Flood Protection : Enable + seuil adapté au trafic UDP normal
   • ICMP Flood Protection : Enable
2. Activer le SYN Proxy : génère un proxy SYN pour valider les connexions avant de les transmettre
3. Configurer les alertes : log + email sur dépassement de seuil
4. Analyser le trafic normal pour calibrer les seuils sans générer de faux positifs

Valeur par défaut : Protection DoS activée avec seuils par défaut génériques
Critère de conformité : SYN, UDP, ICMP Flood Protection activés avec seuils adaptés au trafic

---

5.7 — Application Control pour bloquer les applications non autorisées

Niveau : 🔵 L2
Référence CIS : CIS Control 9.2 — Use DNS Filtering Services
MITRE ATT&CK : T1090 — Proxy | T1572 — Protocol Tunneling | T1071 — Application Layer Protocol

Description du risque :
Les applications P2P, les proxies anonymisants (Tor, Ultrasurf, Psiphon) et les VPN non autorisés permettent aux utilisateurs de contourner les politiques de filtrage et aux malwares d’exfiltrer des données via des tunnels chiffrés. Les outils de type TeamViewer, AnyDesk non supervisés peuvent être utilisés comme backdoors par des attaquants.

Vérification :

1. Security Services > App Control Advanced : vérifier si activé
2. Vérifier les catégories bloquées : P2P, Proxy/VPN, Remote Access Tools non autorisés

Remédiation :

1. Security Services > App Control Advanced > Enable App Control
2. Configurer les politiques par catégorie d’application :
   • Bloquer : P2P (BitTorrent, eDonkey), Proxy Avoidance & Anonymizers, Tor
   • Bloquer ou surveiller : Remote Access Tools (TeamViewer, AnyDesk) — selon politique
   • Surveiller : Cloud Storage non corporate (Dropbox personnel, etc.)
3. Appliquer les politiques par groupe d’utilisateurs si possible
4. Activer le logging pour les applications bloquées : source de threat intelligence interne

Valeur par défaut : App Control désactivé
Critère de conformité : App Control activé, P2P et proxy anonymisants bloqués, log activé

---

🔍 DOMAINE 6 — SERVICES DE SÉCURITÉ (IPS / AV / ANTI-SPYWARE)

Les services de sécurité SonicWall (alimentés par Capture Labs) constituent la couche d’inspection applicative. Sans ces services correctement configurés, le firewall est un simple routeur avec des règles d’accès. Ce domaine couvre la configuration optimale de chaque service d’inspection.

---

6.1 — Activation de l’IPS sur toutes les zones

Niveau : 🟡 L1
Référence CIS : CIS Control 13.3 — Deploy a Network Intrusion Detection Solution
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1210 — Exploitation of Remote Services

Description du risque :
L’IPS (Intrusion Prevention System) détecte et bloque les exploits, les scans et les tentatives d’exploitation en temps réel. Sans IPS, les vulnérabilités des serveurs exposés (CVE non patchées, mauvaises configurations) peuvent être exploitées même si les règles de firewall autorisent le trafic légitime vers ces serveurs.

Vérification :

1. Security Services > Intrusion Prevention > Settings : vérifier que l’IPS est activé globalement
2. Network > Zones : pour chaque zone — colonne IPS doit afficher une coche
3. Vérifier le mode : “Prevent” (bloque) vs “Detect” (alerte seulement) — Prevent recommandé
4. Vérifier la date de dernière mise à jour des signatures (< 24h)

Remédiation :

1. Security Services > Intrusion Prevention > Settings :
   • Cocher “Enable IPS”
   • Priority : High, Medium, Low : Prevent pour toutes les priorités
   • Cocher “Detect and Prevent OS and App Flaws” et “Detect and Prevent Protocol Anomalies”
2. Network > Zones : pour chaque zone, Edit > cocher “Intrusion Prevention”
3. Mode TCP : activer TCP Stream (inspection du flux TCP réassemblé, plus efficace contre les fragments)

Valeur par défaut : IPS activé avec license mais désactivé sur les zones par défaut
Critère de conformité : IPS en mode Prevent sur toutes les zones actives, signatures < 24h

---

6.2 — Activation du Gateway Anti-Virus sur toutes les zones

Niveau : 🟡 L1
Référence CIS : CIS Control 10.1 — Deploy and Maintain Anti-Malware Software
MITRE ATT&CK : T1566 — Phishing | T1059 — Command and Scripting Interpreter | T1027 — Obfuscated Files

Description du risque :
Le Gateway Anti-Virus inspecte les fichiers transitant par le firewall (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) pour détecter les malwares avant qu’ils n’atteignent les endpoints. Particulièrement utile pour détecter les malwares dans les pièces jointes email et les téléchargements web, complément au AV endpoint.

Vérification :

1. Security Services > Gateway Anti-Virus > Settings : vérifier que Gateway AV est activé
2. Vérifier les protocoles inspectés : HTTP, FTP, SMTP, POP3, IMAP (HTTPS nécessite DPI-SSL activé)
3. Vérifier la date de dernière mise à jour des signatures
4. Network > Zones : colonne AV doit afficher une coche pour LAN, DMZ, WLAN

Remédiation :

1. Security Services > Gateway Anti-Virus > Settings :
   • Cocher “Enable Gateway Anti-Virus”
   • Cocher tous les protocoles : HTTP, FTP, SMTP, POP3, IMAP
   • Activer TCP Stream : inspection du flux TCP réassemblé
   • Action sur détection : Block (ne pas utiliser Notify Only)
2. Network > Zones : pour chaque zone — Edit > cocher “Gateway Anti-Virus”
3. Configurer les alertes email sur détection

Valeur par défaut : Gateway AV activé avec license, désactivé sur les zones
Critère de conformité : Gateway AV activé sur toutes les zones, tous les protocoles, action=Block

---

6.3 — Activation de l’Anti-Spyware en mode Prevent+Detect

Niveau : 🟡 L1
Référence CIS : CIS Control 13.4 — Perform Traffic Filtering Between Network Segments
MITRE ATT&CK : T1071.001 — Web Protocols (C2) | T1071.004 — DNS (C2) | T1573 — Encrypted Channel

Description du risque :
Le service Anti-Spyware de SonicWall détecte les communications entre les postes compromis et les serveurs de Command & Control (C&C) des malwares. Il s’appuie sur les données de Capture Labs pour identifier les domaines, IPs et patterns de communication malveillants. Sans ce service, un malware déjà présent sur le réseau peut communiquer librement avec son infrastructure.

Vérification :

1. Security Services > Anti-Spyware > Settings : vérifier l’activation
2. Vérifier le Log Redundancy Filter : recommandé à 60 secondes (évite les logs dupliqués sans manquer d’événements)
3. Vérifier que le mode est “Prevent” (pas seulement “Detect”)

Remédiation :

1. Security Services > Anti-Spyware > Settings :
   • Cocher “Enable Anti-Spyware”
   • Toutes les signatures : action = Prevent (pas Detect uniquement)
   • Log Redundancy Filter : 60 secondes
   • Désactiver les event IDs bruyants si nécessaire : 1391 et 1197
2. Network > Zones : Edit > cocher “Anti-Spyware” pour LAN, DMZ, WLAN

Valeur par défaut : Anti-Spyware activé avec license, désactivé sur les zones
Critère de conformité : Anti-Spyware en mode Prevent sur toutes les zones, Log Filter = 60s

---

6.4 — Filtrage Botnet Command & Control

Niveau : 🟡 L1
Référence CIS : CIS Control 13.3 — Deploy a Network Intrusion Detection Solution
MITRE ATT&CK : T1071 — Application Layer Protocol | T1095 — Non-Application Layer Protocol | T1572 — Protocol Tunneling

Description du risque :
Le Botnet Filter de SonicWall bloque les communications vers des IPs et domaines connus comme infrastructure de C&C de botnets, ransomware et malwares. Il s’appuie sur la threat intelligence de Capture Labs mise à jour en temps réel. Bloquer les communications C&C limite la capacité d’un malware déjà présent à recevoir des instructions ou à exfiltrer des données.

Vérification :

1. Security Services > Botnet Filter : vérifier si activé
2. Vérifier que “Block connections to/from Botnet C&C” est coché pour le trafic sortant ET entrant
3. Vérifier l’existence d’un groupe d’exclusion personnalisé (ne pas utiliser le groupe par défaut)

Remédiation :

1. Security Services > Botnet Filter > Settings :
   • Cocher “Enable Botnet Filter”
   • Cocher “Block Connections to Botnet Servers” (sortant)
   • Cocher “Block Connections from Botnet Clients” (entrant)
   • Log Redundancy Filter : 60 secondes
2. Créer un groupe d’exclusion personnalisé pour les IPs légitimes bloquées par erreur (services cloud, CDN)
3. Monitorer les logs Botnet : chaque détection est un indicateur de compromission potentielle — alerter le SIEM

Valeur par défaut : Botnet Filter désactivé (nécessite configuration manuelle)
Critère de conformité : Botnet Filter activé, bloc entrant ET sortant, groupe d’exclusion personnalisé

---

6.5 — Activation de Capture ATP pour les fichiers inconnus

Niveau : 🟡 L1
Référence CIS : CIS Control 10.7 — Use Application Allowlisting on Servers
MITRE ATT&CK : T1027.002 — Software Packing | T1027.003 — Steganography | T1204 — User Execution

Description du risque :
Les malwares zero-day et les variantes inconnues ne sont pas détectés par les signatures AV traditionnelles. Capture ATP (Advanced Threat Protection) soumet les fichiers suspects à une analyse sandbox multi-engine dans le cloud SonicWall. Le mode “Block Until Verdict” retient le fichier jusqu’au résultat de l’analyse, empêchant les malwares zero-day de pénétrer le réseau.

Vérification :

1. Security Services > Capture ATP > Global Settings : vérifier l’activation
2. Vérifier que “Block Until Verdict” est activé (pas seulement “Inspect and Allow”)
3. Vérifier les types de fichiers inspectés : PE, Office, PDF, archives

Remédiation :

1. Security Services > Capture ATP > Global Settings :
   • Cocher “Enable Capture ATP”
   • Action : Block Until Verdict (essentiel — sinon les fichiers sont transmis pendant l’analyse)
   • Types de fichiers : sélectionner PE (.exe, .dll), Office (.docx, .xlsx), PDF, archives (.zip, .rar), Scripts
2. Configurer les alertes sur les fichiers malveillants détectés
3. Associer avec Gateway AV pour couverture complète

Valeur par défaut : Capture ATP désactivé
Critère de conformité : Capture ATP activé, Block Until Verdict, types de fichiers à risque couverts

---

6.6 — DPI-SSL pour l’inspection du trafic HTTPS

Niveau : 🔵 L2
Référence CIS : CIS Control 13.8 — Deploy a Network Intrusion Prevention Solution
MITRE ATT&CK : T1573 — Encrypted Channel | T1041 — Exfiltration Over C2 Channel

Description du risque :
Plus de 90% du trafic web est chiffré (HTTPS). Sans DPI-SSL, l’IPS, le Gateway AV et l’Anti-Spyware sont aveugles au contenu des flux HTTPS. Les malwares modernes, les C&C et les exfiltrations utilisent systématiquement HTTPS pour contourner les inspections. DPI-SSL intercepte et déchiffre le trafic HTTPS pour inspection, puis rechiffre vers le client.

Considérations :
DPI-SSL nécessite le déploiement du certificat CA SonicWall sur tous les clients (via GPO AD). Des exclusions doivent être configurées pour les applications sensibles (banking, healthcare, legal) qui utilisent du certificate pinning.

Vérification :

1. Security Services > DPI-SSL > Client SSL : vérifier si activé
2. Vérifier que le certificat CA est déployé sur les postes clients
3. Vérifier les exclusions configurées

Remédiation :

1. Security Services > DPI-SSL > Client SSL :
   • Activer “Enable SSL Client Inspection”
   • Générer ou importer un certificat CA pour l’inspection
2. Déployer le certificat CA sur les clients via GPO AD : Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
3. Configurer les exclusions : Security Services > DPI-SSL > Exclusion List
   • Ajouter les domaines financiers, santé, juridiques
   • Applications avec certificate pinning : ajouter par catégorie CFS
4. Activer l’inspection sur les règles LAN→WAN

Valeur par défaut : DPI-SSL désactivé
Critère de conformité : DPI-SSL activé, certificat CA déployé sur clients, exclusions configurées

---

6.7 — Content Filtering Service (CFS)

Niveau : 🔵 L2
Référence CIS : CIS Control 9.3 — Maintain and Enforce Network-Based URL Filters
MITRE ATT&CK : T1090 — Proxy | T1071.001 — Web Protocols

Description du risque :
Le filtrage URL par catégories bloque l’accès aux sites de phishing, de distribution de malwares, aux proxies anonymisants et aux contenus non conformes à la politique de l’entreprise. Le CFS SonicWall s’appuie sur la base de données Capture Labs pour classer les URL en temps réel.

Vérification :

1. Security Services > Content Filter > Settings : vérifier si CFS est activé
2. Vérifier les catégories bloquées : Hacking Tools, Malware, Proxy Avoidance, Spyware, Phishing
3. Vérifier que le filtrage HTTPS IP est activé (pour bloquer les IPs malveillantes même sans DPI-SSL)

Remédiation :

1. Security Services > Content Filter > Settings :
   • Activer “Enable Content Filtering Service”
   • Catégories à bloquer obligatoirement : Hacking, Malware Sites, Phishing & Fraud, Proxy Avoidance & Anonymizers, Spyware & Adware, Botnets
   • Catégories selon politique : Adult Content, Gambling, P2P
2. Activer “HTTPS IP Filtering” : bloque les IPs malveillantes pour le trafic HTTPS non déchiffré
3. Créer des politiques par groupe d’utilisateurs si nécessaire (différentes règles pour IT vs utilisateurs standard)

Valeur par défaut : CFS désactivé
Critère de conformité : CFS activé, catégories malveillantes bloquées, HTTPS IP filtering activé

---

6.8 — One-Touch Configuration Override DPI

Niveau : 🔵 L2
Référence CIS : CIS Control 4.1 — Establish and Maintain a Secure Configuration Process
MITRE ATT&CK : T1562.004 — Disable or Modify System Firewall

Description du risque :
La fonctionnalité “One-Touch Configuration Override” de SonicWall active en une action l’ensemble des meilleures pratiques d’inspection DPI (Deep Packet Inspection) recommandées par SonicWall. Elle corrige les configurations sous-optimales sans nécessiter une navigation dans chaque sous-menu. Utile lors d’un audit rapide ou d’une reconfiguration initiale.

Vérification :

1. Firewall Settings > Advanced : rechercher “One-Touch Configuration Override”
2. Vérifier si la configuration DPI est conforme aux meilleures pratiques SonicWall

Remédiation :

1. Firewall Settings > Advanced > One-Touch Configuration Override
2. Lire la description des changements qui seront appliqués
3. Sauvegarder la configuration avant application
4. Appliquer “Enable DPI Best Practices”
5. Vérifier les Access Rules et zones après application — certains paramètres peuvent nécessiter un ajustement

Valeur par défaut : Non activé
Critère de conformité : Configuration DPI conforme aux meilleures pratiques SonicWall

---

🔒 DOMAINE 7 — VPN SSL ET ACCÈS DISTANT

Le SSL-VPN SonicWall est le vecteur d’attaque le plus exploité en 2024-2025 par les groupes de ransomware. Akira, LockBit et RansomHub ont utilisé des vulnérabilités SSL-VPN SonicWall comme point d’entrée initial dans des centaines d’organisations. Ce domaine est critique.

---

7.1 — Désactivation du SSL-VPN depuis le WAN si non utilisé

Niveau : 🔴 Critique
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1133 — External Remote Services | T1190 — Exploit Public-Facing Application

Description du risque :
Le portail SSL-VPN expose directement l’appliance SonicWall sur Internet via HTTPS. Chaque CVE publiée sur le SSL-VPN SonicWall est exploitée dans les 24-72 heures par des groupes automatisés. Si le SSL-VPN n’est pas utilisé, il doit être désactivé immédiatement. Si il est utilisé, sa surface d’exposition doit être réduite au maximum.

Impact documenté :
CISA KEV catalog : CVE-2024-40766 (CVSS 9.3) — utilisée par Akira Ransomware pour accès initial via SSL-VPN SonicWall. Huntress a documenté des compromissions massives de firewalls SonicWall Gen 7 avec SSL-VPN exposé sans MFA.

Vérification :

1. Tenter d’accéder à https://{IP-WAN}:{port-SSLVPN} depuis Internet
2. Si le portail de login NetExtender apparaît : service exposé
3. Device > VPN > SSL VPN > Server Settings : vérifier si SSL-VPN est activé sur l’interface WAN

Remédiation :
Si SSL-VPN non utilisé :

1. Device > VPN > SSL VPN > Server Settings : décocher “Enable SSL VPN” sur l’interface WAN
2. Vérifier dans les Access Rules qu’aucune règle ne redirige le trafic vers le portail VPN

Si SSL-VPN requis :

1. Appliquer TOUS les contrôles 7.2 à 7.7 avant de laisser le SSL-VPN actif
2. Surveiller les logs d’authentification en temps réel
3. Abonner le PSIRT SonicWall pour patches d’urgence

Valeur par défaut : SSL-VPN activé par défaut sur certaines configurations
Critère de conformité : SSL-VPN désactivé si non utilisé ; si actif, tous les contrôles 7.2-7.7 appliqués

---

7.2 — Restriction de l’accès SSL-VPN par liste blanche d’IPs

Niveau : 🔴 Critique
Référence CIS : CIS Control 12.3 — Securely Manage Network Infrastructure
MITRE ATT&CK : T1133 — External Remote Services | T1078 — Valid Accounts

Description du risque :
Restreindre le SSL-VPN à des IPs sources connues (IPs fixes des employés en télétravail, IPs des sites distants) réduit drastiquement la surface d’attaque. Un attaquant depuis une IP non autorisée ne peut pas atteindre le portail de login, éliminant les tentatives de brute-force et l’exploitation de vulnérabilités du portail lui-même.

Vérification :

1. Policy > Rules and Policies > Access Rules > WAN to SonicWall
2. Identifier la règle autorisant le trafic vers le portail SSL-VPN (port 4433 ou configuré)
3. Vérifier que la source est restreinte à un groupe d’IPs spécifique (pas “Any”)

Remédiation :

1. Créer un groupe d’adresses IP autorisées : Network > Address Objects > Add Group
   • Ajouter les IPs fixes légitimes (télétravail avec IP fixe, sites distants)
2. Policy > Rules and Policies > Access Rules > Add :
   • Source : groupe d’IPs autorisées
   • Destination : Firewall
   • Service : HTTPS (port SSL-VPN)
   • Action : Allow
3. Ajouter une règle explicite de refus pour toute autre source WAN vers le port SSL-VPN
4. Si les utilisateurs n’ont pas d’IP fixe : envisager un pré-authentification par certificat ou MFA renforcée

Valeur par défaut : Accès SSL-VPN ouvert depuis Any sur WAN
Critère de conformité : Accès SSL-VPN restreint à des IPs sources documentées, ou MFA obligatoire si Any source

---

7.3 — MFA obligatoire pour tous les utilisateurs SSL-VPN

Niveau : 🔴 Critique
(Voir contrôle 2.3 pour la description complète et la remédiation)

MITRE ATT&CK : T1133 — External Remote Services | T1078 — Valid Accounts | T1110.003 — Password Spraying

Points clés :

• MFA obligatoire sur TOUS les comptes VPN, sans exception
• Corriger CVE-2024-12802 : retirer userPrincipalName du champ LDAP “Qualified login name”
• Tester la MFA depuis un compte de test avant déploiement
• Surveiller les alertes de bypass MFA dans les logs

---

7.4 — Timeout de session VPN inactif

Niveau : 🟡 L1
Référence CIS : CIS Control 4.3 — Configure Automatic Session Locking
MITRE ATT&CK : T1563 — Remote Service Session Hijacking | T1185 — Browser Session Hijacking

Description du risque :
Une session VPN laissée ouverte indéfiniment représente un risque de session hijacking (token volé) et d’accès non autorisé depuis un poste laissé sans surveillance. Des sessions VPN inactives prolongées consomment également des ressources (licences SSL-VPN, mémoire) et rendent le monitoring plus difficile.

Vérification :

1. Device > VPN > SSL VPN > Server Settings
2. Vérifier “Session Timeout” : durée maximale d’une session (ex: 480 min = 8h)
3. Vérifier “Idle Timeout” : déconnexion si inactivité (recommandé : 30 min)

Remédiation :

1. Device > VPN > SSL VPN > Server Settings :
   • Session Timeout : 480 minutes (8h) — maximum pour une journée de travail
   • Idle Timeout : 30 minutes — déconnexion si aucune activité réseau
2. Communiquer aux utilisateurs la politique de reconnexion (pas d’impact fonctionnel avec une reconnexion MFA rapide si l’app TOTP est disponible)

Valeur par défaut : Timeout variables selon version — souvent trop long ou non configuré
Critère de conformité : Session Timeout ≤ 8h, Idle Timeout ≤ 30 minutes

---

7.5 — Certificats pour l’authentification VPN site-à-site (IKEv2)

Niveau : 🟡 L1
Référence CIS : CIS Control 3.10 — Encrypt Sensitive Data in Transit
MITRE ATT&CK : T1557 — Adversary-in-the-Middle | T1040 — Network Sniffing

Description du risque :
Les tunnels VPN site-à-site utilisant des Pre-Shared Keys (PSK) sont vulnérables si le PSK est faible, partagé entre plusieurs tunnels ou divulgué. L’authentification par certificat PKI offre une sécurité supérieure : chaque tunnel possède un certificat unique, révocable indépendamment, et les échanges IKE sont protégés par cryptographie asymétrique.

Vérification :

1. VPN > Site-to-Site VPN : lister les tunnels actifs
2. Pour chaque tunnel : vérifier la méthode d’authentification (Pre-Shared Key vs Certificate)
3. Si PSK : vérifier la complexité (doit être ≥ 20 caractères aléatoires, unique par tunnel)

Remédiation :
Migration vers certificats (recommandé) :

1. Générer une PKI interne ou utiliser une CA externe
2. Émettre des certificats pour chaque extrémité de tunnel
3. VPN > Site-to-Site VPN > {tunnel} > Edit : changer Authentication Method = Certificate
4. Importer les certificats des deux extrémités

Si PSK maintenu :

1. S’assurer que le PSK est ≥ 20 caractères, aléatoires, uniques par tunnel
2. Rotation annuelle des PSK
3. Ne jamais partager le même PSK entre plusieurs tunnels

Valeur par défaut : PSK par défaut
Critère de conformité : Certificats utilisés pour tunnels site-à-site, ou PSK ≥ 20 caractères uniques par tunnel

---

7.6 — Principe de moindre privilège pour les utilisateurs VPN

Niveau : 🔵 L2
Référence CIS : CIS Control 6.1 — Establish an Access Granting Process
MITRE ATT&CK : T1078 — Valid Accounts | T1021 — Remote Services

Description du risque :
Si tous les utilisateurs VPN ont accès à l’ensemble du réseau interne (full-LAN), une compromission d’un compte VPN donne à l’attaquant un accès total au réseau. Le principe de moindre privilège dicte que chaque utilisateur VPN ne doit accéder qu’aux ressources strictement nécessaires à son activité.

Vérification :

1. VPN > SSL VPN > Virtual Office et VPN > SSL VPN > Client Settings : vérifier les réseaux accessibles
2. Device > Users > Groups : identifier les groupes VPN et leurs politiques d’accès
3. Vérifier que les utilisateurs standard n’ont pas accès aux serveurs d’administration ou aux DCs

Remédiation :

1. Créer des groupes VPN par profil métier :
   • VPN-Users : accès aux applications métier uniquement
   • VPN-IT : accès serveurs + administration
   • VPN-Finance : accès serveurs Finance uniquement
2. Configurer les routes VPN par groupe : VPN > SSL VPN > Client Settings — configurer les routes par groupe
3. Access Rules : créer des règles SSLVPN→LAN restrictives par groupe d’utilisateurs

Valeur par défaut : Accès full-LAN pour tous les utilisateurs VPN
Critère de conformité : Groupes VPN avec accès limité aux ressources nécessaires, documenté

---

7.7 — Politique Split-Tunnel vs Full-Tunnel

Niveau : 🔵 L2
Référence CIS : CIS Control 12.4 — Establish and Maintain Architecture Diagram(s)
MITRE ATT&CK : T1048 — Exfiltration Over Alternative Protocol | T1041 — Exfiltration Over C2 Channel

Description du risque :

• Split-tunnel : seul le trafic vers les réseaux internes passe par le VPN. Le trafic Internet sort directement depuis le poste. Avantage : moins de charge sur le firewall. Inconvénient : le trafic Internet du poste en télétravail n’est pas inspecté par les services SonicWall.
• Full-tunnel : tout le trafic du poste en télétravail transite par le VPN et est inspecté par SonicWall (IPS, AV, CFS). Plus sécurisé mais plus de charge sur l’appliance et latence accrue.

Recommandation : Full-tunnel pour les postes accédant à des données sensibles. Split-tunnel acceptable si les postes disposent d’un endpoint security (EDR) et d’un filtrage DNS (ex: Cloudflare Gateway, Umbrella).

Vérification :

1. VPN > SSL VPN > Client Settings : vérifier si “Tunnel All Mode” est activé

Remédiation :

1. VPN > SSL VPN > Client Settings > {groupe} > Edit :
   • Full tunnel : activer “Tunnel All Mode”
   • Split tunnel : configurer les routes réseau internes uniquement
2. Si split-tunnel : s’assurer que les postes disposent d’un EDR et d’un DNS filtré
3. Documenter la politique choisie et sa justification

Valeur par défaut : Split-tunnel par défaut
Critère de conformité : Politique documentée et alignée avec le niveau de risque des données accédées

---

7.8 — Désactivation de Virtual Office et Clientless VPN si non utilisés

Niveau : 🟡 L1
Référence CIS : CIS Control 4.8 — Uninstall or Disable Unnecessary Services
MITRE ATT&CK : T1133 — External Remote Services | T1190 — Exploit Public-Facing Application

Description du risque :
SonicWall SSL-VPN propose deux modes distincts souvent confondus :

• NetExtender/Mobile Connect : client VPN installé sur le poste — trafic chiffré dans un tunnel
• Virtual Office (Clientless VPN) : portail web HTML5 donnant accès à des ressources internes (RDP, SSH, SMB) directement depuis un navigateur sans client installé

Le Virtual Office expose directement des ressources internes via l’interface web du firewall. Des vulnérabilités dans cette couche HTML5 (notamment dans les plugins Java/ActiveX historiques) peuvent permettre l’accès non autorisé aux ressources internes. Si Virtual Office n’est pas utilisé, le désactiver réduit significativement la surface d’attaque du portail SSL-VPN.

Vérification :

1. Device > VPN > SSL VPN > Virtual Office : vérifier si des bookmarks/ressources sont configurés
2. Naviguer vers https://{IP-WAN}:{port-SSLVPN}/ — si un portail Virtual Office apparaît, le service est actif
3. Vérifier si des utilisateurs se connectent réellement via Virtual Office (logs d’authentification)

Remédiation :
Si Virtual Office non utilisé :

1. Device > VPN > SSL VPN > Virtual Office > Settings : désactiver “Enable Virtual Office”
2. Supprimer tous les bookmarks existants (RDP, SSH, VNC, File Shares) non utilisés
3. Restreindre l’accès au portail Virtual Office par groupe d’utilisateurs

Si Virtual Office utilisé :

1. Appliquer la MFA (contrôle 7.3)
2. Limiter les bookmarks aux ressources strictement nécessaires par groupe
3. Activer l’audit des accès Virtual Office dans les logs

Valeur par défaut : Virtual Office activé par défaut avec le SSL-VPN
Critère de conformité : Virtual Office désactivé ou restreint aux utilisateurs autorisés avec MFA, bookmarks limités

---

📊 DOMAINE 8 — JOURNALISATION ET SUPERVISION

“Vous ne pouvez pas défendre ce que vous ne voyez pas.” La journalisation est le fondement de la détection et de la réponse aux incidents. Sans logs centralisés et exploitables, une compromission peut rester invisible pendant des semaines ou des mois.

---

8.1 — Envoi des logs vers un serveur Syslog externe

Niveau : 🟡 L1
Référence CIS : CIS Control 8.2 — Collect Audit Logs | CIS Control 8.9 — Centralize Audit Logs
MITRE ATT&CK : T1070 — Indicator Removal | T1562.006 — Indicator Blocking

Description du risque :
Les logs stockés uniquement sur l’appliance SonicWall sont vulnérables à plusieurs risques : effacement lors d’une compromission (un attaquant qui contrôle le firewall peut effacer les traces), perte lors d’un crash matériel, espace limité causant la rotation rapide des logs. La centralisation vers un SIEM est obligatoire pour toute investigation forensique sérieuse.

Vérification :

1. Device > Settings > Log > Automation > Syslog : vérifier si une ou plusieurs destinations Syslog sont configurées
2. Vérifier les catégories de logs envoyées vers Syslog
3. Depuis le SIEM : vérifier la réception des logs en temps réel

Remédiation :

1. Device > Settings > Log > Automation > Syslog :
   • Cliquer sur Add
   • Syslog Server : IP du serveur Syslog/SIEM
   • UDP Port : 514 (standard) ou 6514 (Syslog-TLS recommandé)
   • Syslog Format : Default ou ArcSight/CEF selon SIEM
2. Configurer jusqu’à 5 destinations (redondance possible)
3. Dans les Log > Categories : activer toutes les catégories critiques :
   • Network Access (connexions/refus)
   • Authentication (succès/échecs de login)
   • VPN (connexions VPN)
   • Security Services (IPS/AV/Botnet détections)
   • System (config changes, reboots)
4. Valider la réception dans le SIEM et créer les règles de corrélation

Valeur par défaut : Aucune destination Syslog configurée
Critère de conformité : ≥ 1 destination Syslog externe configurée, catégories critiques activées, logs reçus dans le SIEM

---

8.2 — Enhanced Audit Logging

Niveau : 🟡 L1
Référence CIS : CIS Control 8.5 — Collect Detailed Audit Logs
MITRE ATT&CK : T1562.006 — Indicator Blocking | T1070.003 — Clear Command History

Description du risque :
L’Enhanced Audit Logging trace toutes les modifications de configuration de l’appliance : création/modification de règles, changements de paramètres, connexions administratives, exports de configuration. Sans cet audit, il est impossible de détecter les modifications non autorisées (backdoors, ouverture de règles par un attaquant ayant accès admin) ou de les attribuer à un utilisateur spécifique.

Vérification :

1. Device > Settings > Administration (Gen 7/8) : chercher “Enhanced Audit Logging”
2. Vérifier si activé
3. Vérifier que les logs d’audit sont envoyés vers le Syslog externe

Remédiation :

1. Device > Settings > Administration : activer “Enhanced Audit Logging”
2. S’assurer que les logs de catégorie “Administration” sont inclus dans l’export Syslog
3. Dans le SIEM : créer une alerte sur toute modification de règle firewall ou de configuration admin hors-fenêtre de maintenance

Valeur par défaut : Enhanced Audit Logging désactivé
Critère de conformité : Enhanced Audit Logging activé, logs envoyés vers SIEM, alertes sur modifications hors-maintenance

---

8.3 — Alertes email pour les événements critiques

Niveau : 🟡 L1
Référence CIS : CIS Control 8.11 — Conduct Audit Log Reviews
MITRE ATT&CK : T1078 — Valid Accounts | T1133 — External Remote Services

Description du risque :
Les alertes email permettent une notification immédiate des événements critiques même en l’absence d’un SIEM ou d’une équipe SOC disponible en permanence. Des alertes sur les échecs de connexion répétés, les détections IPS/AV et les modifications de configuration peuvent permettre une réaction en moins d’une heure.

Vérification :

1. Device > Settings > Log > Automation > Email : vérifier si une adresse email est configurée
2. Vérifier les catégories d’événements déclenchant des alertes email

Remédiation :

1. Device > Settings > Log > Automation > Email :
   • Send Alerts Via Email : activer
   • Mail Server : configurer le relay SMTP (interne ou SES/SendGrid)
   • Alert Email Address : alias du SOC ou de l’équipe IT
2. Log > Categories — activer l’email pour les catégories critiques :
   • Authentication Failures (>3 par IP en 5 min)
   • IPS Attacks (sévérité High et Critical)
   • Gateway AV Detections
   • VPN connections (optionnel — peut être bruyant)
   • System events (reboot, config change)
3. Configurer un Log Redundancy Filter pour éviter le flood email lors d’une attaque volumétrique

Valeur par défaut : Alertes email non configurées
Critère de conformité : Alertes email configurées pour les événements critiques, testées

---

8.4 — Log Redundancy Filter à 60 secondes

Niveau : 🟡 L1
Référence CIS : CIS Control 8.4 — Standardize Time Synchronization
MITRE ATT&CK : T1498 — Network Denial of Service (impact sur logs)

Description du risque :
Sans Log Redundancy Filter, une attaque volumétrique (scan de ports, flood) peut générer des millions d’événements en quelques minutes, saturant le stockage Syslog, ralentissant l’appliance et masquant les événements importants dans le bruit. Le filtre réduit la redondance tout en conservant la visibilité sur les événements uniques.

Vérification :

1. Security Services > General (ou l’équivalent selon version) : chercher “Log Redundancy Filter”
2. Valeur recommandée : 60 secondes

Remédiation :

1. Security Services > General : configurer Log Redundancy Filter = 60 secondes
2. Désactiver les event IDs particulièrement bruyants sans valeur sécuritaire : ID 1391 (ICMP unreachable), ID 1197 (SYN Flood notification)
3. Note : 60 secondes signifie qu’un événement identique répété toutes les 60s sera loggé une seule fois dans cette fenêtre — les attaques rapides sont toujours détectées mais sans flood de logs

Valeur par défaut : 60 secondes sur certaines versions — vérifier selon la version installée
Critère de conformité : Log Redundancy Filter = 60 secondes, event IDs bruyants désactivés

---

8.5 — Synchronisation NTP avec source de temps fiable

Niveau : 🔵 L2
Référence CIS : CIS Control 8.4 — Standardize Time Synchronization
MITRE ATT&CK : T1070 — Indicator Removal (horodatage altéré rend l’investigation impossible)

Description du risque :
Un horodatage incorrect sur les logs firewall rend la corrélation forensique impossible. Si l’heure du firewall diffère de l’heure des serveurs et des postes, les séquences d’événements ne peuvent pas être reconstituées lors d’une investigation. De plus, les certificats TLS expirent si l’horloge est incorrecte, causant des interruptions de service.

Vérification :

1. Device > Settings > Time ou System > Time : vérifier la synchronisation NTP
2. Vérifier que l’heure affichée correspond à l’heure UTC réelle
3. Vérifier l’adresse du serveur NTP configuré

Remédiation :

1. Device > Settings > Time :
   • Synchronize with NTP Server : activer
   • NTP Server : pool.ntp.org (ou serveur NTP interne AD : {DC-IP})
   • Time Zone : configurer correctement avec l’heure locale
2. Configurer un serveur NTP secondaire pour la redondance
3. Si environnement Active Directory : utiliser le DC comme NTP source pour synchronisation cohérente

Valeur par défaut : NTP configuré par défaut sur pool.ntp.org — vérifier l’horodatage réel
Critère de conformité : NTP synchronisé, écart < 1 seconde avec source de référence

---

8.6 — Traps SNMP v3 vers le SIEM

Niveau : 🔵 L2
Référence CIS : CIS Control 8.9 — Centralize Audit Logs
MITRE ATT&CK : T1498 — Network Denial of Service | T1562 — Impair Defenses

Description du risque :
Les traps SNMP permettent une notification proactive des événements matériels et de performance : interface down, haute utilisation CPU, saturation de la table de connexions, basculement HA. Ces événements peuvent indiquer une attaque DoS ou un problème matériel avant que les utilisateurs ne signalent des problèmes.

Vérification :

1. Device > Settings > SNMP : vérifier SNMPv3 configuré (voir contrôle 3.5)
2. Vérifier les traps configurées : Interface Down/Up, CPU High, Connection Table Full

Remédiation :

1. Device > Settings > SNMP > SNMPv3 : configurer l’utilisateur SNMPv3 (voir 3.5)
2. Configurer les traps vers le SIEM/NMS :
   • Interface status (Up/Down)
   • CPU threshold (>80%)
   • Memory threshold (>80%)
   • Connection table utilization (>80%)
   • HA failover events
3. Dans le SIEM : créer des alertes sur ces traps pour détection d’anomalies

Valeur par défaut : SNMP désactivé, traps non configurées
Critère de conformité : SNMPv3 activé, traps configurées vers SIEM pour événements critiques matériels

---

8.7 — Supervision des modifications de configuration en temps réel

Niveau : 🔵 L2
Référence CIS : CIS Control 8.5 — Collect Detailed Audit Logs
MITRE ATT&CK : T1562.004 — Disable or Modify System Firewall

Description du risque :
Un attaquant ayant obtenu l’accès administrateur modifiera la configuration pour créer des backdoors persistantes : ouverture de ports, création de comptes, désactivation de l’IPS, ajout de règles VPN. La détection en temps réel de ces modifications est critique pour limiter le temps de séjour de l’attaquant.

Vérification :

1. Dans le SIEM : vérifier l’existence de règles de corrélation sur les événements de modification de configuration SonicWall
2. Vérifier si SonicWall NSM (Network Security Manager) ou GMS est utilisé pour la supervision centrale

Remédiation :

1. Enhanced Audit Logging activé (voir 8.2) : les modifications de config génèrent des events Syslog
2. Dans le SIEM : créer une règle d’alerte critique sur :
   • Événement “Configuration changed by user X”
   • Événement “Firewall rule added/modified/deleted”
   • Événement “Admin login from new IP”
3. Si SonicWall NSM disponible : activer Live Monitor pour visualisation en temps réel des changements

Valeur par défaut : Pas de supervision active des changements de config sans NSM
Critère de conformité : Alertes SIEM sur modifications de configuration, Enhanced Audit Logging actif

---

8.8 — Supervision renforcée lors de campagnes de menaces actives

Niveau : 🔵 L2
Référence CIS : CIS Control 17.4 — Establish and Maintain an Incident Response Plan
MITRE ATT&CK : T1078 — Valid Accounts | T1133 — External Remote Services

Description du risque :
Lors de la publication d’une CVE critique sur SonicWall ou d’une alerte CERT-EU/CISA KEV, la fenêtre d’exploitation active est de 24-72 heures. Pendant cette période, la surveillance doit être intensifiée même si le patch n’est pas encore disponible ou applicable immédiatement.

Vérification :

1. Vérifier si un processus de surveillance renforcée existe lors de publications CVE critiques
2. Vérifier l’abonnement aux flux de threat intelligence SonicWall/CERT-EU/CISA

Remédiation :
Processus à mettre en place :

1. Abonnements obligatoires :
   • PSIRT SonicWall : https://psirt.global.sonicwall.com (alertes email)
   • CISA KEV catalog : https://www.cisa.gov/known-exploited-vulnerabilities-catalog
   • CERT-EU Advisories : https://cert.europa.eu/publications/security-advisories
2. Actions lors d’une alerte critique SonicWall :
   • Vérifier immédiatement la version firmware et l’exposition des services
   • Augmenter la fréquence de contrôle des logs d’authentification VPN (toutes les heures vs quotidien)
   • Activer des alertes SIEM spécifiques sur les IOCs publiés
   • Evaluer l’application du patch en urgence hors-fenêtre de maintenance

Valeur par défaut : Pas de processus de surveillance renforcée défini
Critère de conformité : Processus documenté, abonnements PSIRT/CISA actifs, plan de réponse rapide

---

8.9 — Export NetFlow/IPFIX pour analyse de trafic et SIEM

Niveau : 🔵 L2
Référence CIS : CIS Control 8.9 — Centralize Audit Logs
MITRE ATT&CK : T1048 — Exfiltration Over Alternative Protocol | T1071 — Application Layer Protocol

Description du risque :
Le Syslog transmet les événements de sécurité (alertes IPS, connexions refusées, authentifications). Le NetFlow/IPFIX transmet les métadonnées de flux réseau (IP source/destination, port, protocole, volume, durée) pour tous les flux — y compris ceux autorisés. L’analyse NetFlow permet de détecter des comportements anormaux invisibles dans les logs d’événements : exfiltration lente de données, beacon C&C à intervalles réguliers, mouvements latéraux par protocoles autorisés.

Vérification :

1. Device > Settings > Flow Reporting ou NetFlow : vérifier si activé
2. Vérifier la destination configurée (collecteur NetFlow : Splunk, Elastic, ntopng, SolarWinds)

Remédiation :

1. Device > Settings > Flow Reporting > Enable NetFlow :
   • Activer “Enable NetFlow Reporting”
   • Collector IP : IP du collecteur NetFlow dans le SIEM
   • Port : 2055 (standard NetFlow) ou 4739 (IPFIX)
   • Version : NetFlow v9 ou IPFIX (recommandé)
2. Configurer le collecteur pour recevoir et analyser les flux
3. Dans le SIEM : créer des règles de détection basées sur les patterns de flux :
   • Volume sortant anormal depuis un seul hôte
   • Connexions répétées à intervalle régulier (beacon)
   • Flux vers des IPs nouvellement vues (first-seen)
4. SonicWall NSM/Analyzer peut traiter nativement les flux si disponible

Valeur par défaut : NetFlow désactivé
Critère de conformité : NetFlow/IPFIX configuré vers collecteur SIEM, rétention ≥ 30 jours

---

♻️ DOMAINE 9 — HAUTE DISPONIBILITÉ ET RÉSILIENCE

La résilience de l’infrastructure firewall est un prérequis à la continuité d’activité. Un firewall unique représente un SPOF (Single Point of Failure). Ce domaine couvre la configuration HA et les pratiques de sauvegarde.

---

9.1 — Configuration de la Haute Disponibilité (HA) Active/Standby

Niveau : 🔵 L2
Référence CIS : CIS Control 11.3 — Establish and Maintain a Data Recovery Practice
MITRE ATT&CK : T1499 — Endpoint Denial of Service | T1498 — Network Denial of Service

Description du risque :
Un firewall unique est un SPOF critique. Une défaillance matérielle, une mise à jour défaillante ou une attaque DoS réussie peut couper l’accès Internet et le VPN de l’ensemble de l’organisation. La configuration HA Active/Standby garantit le basculement automatique en cas de panne de l’unité primaire.

Vérification :

1. High Availability > Settings : vérifier si HA est configurée
2. Vérifier le statut : Primary Active / Secondary Standby
3. Vérifier que la synchronisation de configuration est active

Remédiation :

1. Acquérir une deuxième appliance identique (même modèle et génération)
2. High Availability > Settings :
   • Enable High Availability
   • Mode : Active/Standby
   • Heartbeat Interface : dédier une interface pour la communication HA
   • Data Synchronization Interface : interface de sync de configuration
3. Configurer les Monitoring IPs sur les interfaces WAN/LAN pour détecter les pannes
4. Vérifier la synchronisation de config : High Availability > Monitoring

Valeur par défaut : HA non configurée — unité unique
Critère de conformité : HA Active/Standby configurée et synchronisée si criticité ≥ L2

---

9.2 — Licence et enregistrement de l’unité HA secondaire

Niveau : 🔵 L2
Référence CIS : CIS Control 11.3 — Establish and Maintain a Data Recovery Practice
MITRE ATT&CK : T1499 — Endpoint Denial of Service

Description du risque :
L’unité HA secondaire doit être enregistrée et licenciée séparément sur MySonicWall.com. Contrairement à certains constructeurs, SonicWall ne synchronise pas automatiquement les licences entre les unités HA. Une unité secondaire non licenciée ne basculera pas avec les mêmes services de sécurité actifs, créant un trou de sécurité lors du failover.

Vérification :

1. Se connecter à l’unité secondaire via son IP de management
2. Device > Settings > Licenses : vérifier que toutes les licences sont actives sur l’unité secondaire
3. MySonicWall.com : vérifier que le numéro de série de l’unité secondaire est enregistré

Remédiation :

1. Enregistrer l’unité secondaire sur MySonicWall.com > My Products > Register
2. Activer les licences de sécurité sur l’unité secondaire (Gateway AV, IPS, Capture ATP, etc.)
3. Vérifier la synchronisation des licences après configuration HA
4. Tester le basculement avec licences actives sur l’unité secondaire

Valeur par défaut : Unité secondaire non licenciée — doit être gérée manuellement
Critère de conformité : Unité secondaire enregistrée et licenciée identiquement à l’unité primaire

---

9.3 — Tests de basculement HA périodiques

Niveau : 🔵 L2
Référence CIS : CIS Control 11.5 — Test Data Recovery
MITRE ATT&CK : T1499 — Endpoint Denial of Service

Description du risque :
Une configuration HA non testée peut présenter des défauts silencieux : problème de synchronisation de configuration, interface heartbeat défaillante, licence expiré sur l’unité secondaire. Un test périodique garantit que le basculement se produit effectivement en cas de panne réelle.

Vérification :

1. Consulter la documentation : date du dernier test de basculement HA
2. High Availability > Monitoring : vérifier le statut actuel

Remédiation :

1. Planifier un test de basculement semestriel en fenêtre de maintenance
2. High Availability > Settings > Force Active/Standby Failover : déclencher un basculement manuel
3. Vérifier : basculement transparent pour les utilisateurs, sessions reprises, services actifs sur secondaire
4. Documenter le test : date, résultat, durée du basculement, incidents
5. Rebascule vers l’unité primaire après validation

Valeur par défaut : Aucun test automatique — procédure manuelle requise
Critère de conformité : Test de basculement HA documenté < 6 mois

---

9.4 — Sauvegarde régulière de la configuration

Niveau : 🟡 L1
Référence CIS : CIS Control 11.2 — Perform Automated Backups
MITRE ATT&CK : T1485 — Data Destruction | T1490 — Inhibit System Recovery

Description du risque :
La configuration SonicWall contient des années de travail de configuration : règles firewall, politiques VPN, certificats, objets réseau, paramètres de sécurité. Sa perte lors d’une défaillance matérielle ou d’une mauvaise manipulation nécessite une reconstruction manuelle pouvant prendre plusieurs jours et impacte directement la continuité d’activité.

Vérification :

1. Device > Settings > Firmware : vérifier la date du dernier export de configuration
2. Vérifier l’existence du fichier .exp sur un support externe sécurisé

Remédiation :

1. Exporter mensuellement : Device > Settings > Firmware > Export Settings
2. Nommage : sonicwall-{hostname}-{YYYY-MM-DD}.exp
3. Stocker sur support sécurisé hors-appliance : NAS interne, S3 chiffré, coffre numérique
4. Conserver les 3 dernières versions (règle 3-2-1 adaptée)
5. Tester la restauration annuellement sur une appliance de test ou la secondaire HA
6. Si SonicWall NSM/GMS disponible : activer la sauvegarde automatique centralisée

Valeur par défaut : Aucune sauvegarde automatique — export manuel requis
Critère de conformité : Sauvegarde mensuelle, stockée hors-appliance, restauration testée annuellement

---

📋 DOMAINE 10 — GESTION DU CHANGEMENT ET CONFORMITÉ

La gestion du changement prévient la dérive de configuration (security drift) — le phénomène par lequel un système sécurisé se dégrade progressivement au fil des modifications non documentées et non revues.

---

10.1 — Documentation des règles firewall avec justification métier

Niveau : 🟡 L1
Référence CIS : CIS Control 12.8 — Establish and Maintain Dedicated Computing Resources for All Administrative Work
MITRE ATT&CK : T1562.004 — Disable or Modify System Firewall

Description du risque :
Des règles sans documentation accumulent une “dette de visibilité” : personne ne sait pourquoi une règle existe, qui l’a créée, si elle est encore nécessaire. Cette opacité facilite le maintien de règles dangereuses (“on ne touche pas car on ne sait pas ce que ça casse”) et rend les audits impossibles.

Vérification :

1. Policy > Rules and Policies > Access Rules : vérifier la colonne “Comment” ou “Description” de chaque règle
2. Compter les règles sans commentaire vs le total — le ratio doit être < 10%

Remédiation :

1. Pour chaque règle sans commentaire : Edit règle > champ “Comment” — documenter :
   • Propriétaire/demandeur : IT-Dupont
   • Date création : 2025-11-15
   • Ticket/référence : INC-20251115-042
   • Justification métier : Accès serveur ERP depuis poste Finance
   • Date de revue prévue : 2026-05-15
2. Refuser toute nouvelle règle sans documentation via le processus de gestion du changement
3. Intégrer la création de règles firewall dans le CMDB ou ITSM (Jira, ServiceNow)

Valeur par défaut : Pas de commentaires sur les règles par défaut
Critère de conformité : >90% des règles commentées avec propriétaire, date, justification

---

10.2 — Revue des règles tous les 6 mois

Niveau : 🟡 L1
Référence CIS : CIS Control 12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK : T1562.004 — Disable or Modify System Firewall

Description du risque :
Le “firewall rule creep” est universel : les règles temporaires deviennent permanentes, les accès prestataires persistent après fin de mission, les flux applicatifs changent mais les règles ne sont pas mises à jour. Une revue périodique identifie et élimine les règles obsolètes qui élargissent inutilement la surface d’attaque.

Vérification :

1. Vérifier l’existence d’un registre de revue de règles firewall (document de suivi)
2. Date de dernière revue : doit être < 6 mois
3. Si SonicWall NSM disponible : vérifier les statistiques de trafic par règle (règles sans trafic récent = candidates à la suppression)

Remédiation :

1. Planifier une revue semestrielle dans le calendrier de sécurité
2. Processus de revue :
   • Exporter toutes les règles en CSV/PDF pour revue hors-ligne
   • Identifier les règles sans trafic dans les 90 derniers jours (si statistiques disponibles)
   • Contacter les propriétaires des règles dont la date de revue est dépassée
   • Désactiver les règles sans propriétaire actif (ne pas supprimer immédiatement)
   • Supprimer après 30 jours de désactivation sans incident
3. Documenter la revue : date, liste des règles désactivées/supprimées, approbateur

Valeur par défaut : Aucun processus de revue — les règles s’accumulent indéfiniment
Critère de conformité : Revue documentée < 6 mois, registre des règles désactivées/supprimées

---

10.3 — Abonnement aux bulletins PSIRT SonicWall

Niveau : 🟡 L1
Référence CIS : CIS Control 7.1 — Establish and Maintain a Vulnerability Management Process
MITRE ATT&CK : T1190 — Exploit Public-Facing Application

Description du risque :
Les CVE SonicWall sont publiées sans préavis sur le portail PSIRT. Sans abonnement actif, une organisation peut ne pas apprendre l’existence d’une CVE critique exploitée dans la nature pendant des semaines, période pendant laquelle l’appliance est exposée sans mesures de mitigation.

Vérification :

1. Vérifier l’existence d’un abonnement aux alertes PSIRT : https://psirt.global.sonicwall.com
2. Vérifier l’adresse email de réception des alertes (fonctionnelle et surveillée)

Remédiation :

1. S’abonner aux notifications PSIRT : https://psirt.global.sonicwall.com > Subscribe
2. Ajouter en veille complémentaire :
   • CISA KEV catalog (alertes CVE exploitées) : https://www.cisa.gov/known-exploited-vulnerabilities-catalog
   • CERT-EU Security Advisories : https://cert.europa.eu/publications/security-advisories
   • NVD (National Vulnerability Database) : https://nvd.nist.gov — filtrer sur “SonicWall”
3. Intégrer la veille CVE SonicWall dans le processus de patch management

Valeur par défaut : Aucun abonnement PSIRT — veille manuelle requise
Critère de conformité : Abonnement PSIRT actif, adresse email surveillée, intégration dans processus patch management

---

10.4 — Audits de configuration périodiques

Niveau : 🔵 L2
Référence CIS : CIS Control 4.1 — Establish and Maintain a Secure Configuration Process
MITRE ATT&CK : T1562.004 — Disable or Modify System Firewall | T1078 — Valid Accounts

Description du risque :
La dérive de configuration (security drift) se produit progressivement : chaque changement individuel est justifié, mais l’accumulation dégrade le niveau de sécurité global. Un audit périodique compare la configuration courante avec la baseline sécurisée définie lors du déploiement initial ou du dernier audit.

Vérification :

1. Vérifier l’existence d’une baseline de configuration documentée
2. Date du dernier audit de configuration (doit être < 12 mois)
3. Si SonicWall NSM disponible : utiliser la comparaison de configurations intégrée

Remédiation :

1. Définir et exporter la baseline de configuration après durcissement initial
2. Audit annuel minimum :
   • Comparer la configuration courante avec la baseline exportée
   • Identifier les dérives : nouvelles règles, comptes créés, paramètres modifiés
   • Analyser et valider ou corriger chaque écart
3. Utiliser des outils d’audit tiers si disponibles (scripts de comparaison, CIS-CAT pour SonicWall si disponible)
4. Documenter les résultats d’audit et les actions correctives

Valeur par défaut : Pas d’audit de configuration intégré — procédure manuelle
Critère de conformité : Audit documenté < 12 mois, baseline définie, dérives documentées et traitées

---

10.5 — Tests de pénétration sur les interfaces exposées

Niveau : 🔵 L2
Référence CIS : CIS Control 18.3 — Test Application Data Encryption
MITRE ATT&CK : T1190 — Exploit Public-Facing Application | T1133 — External Remote Services

Description du risque :
Les tests de pénétration valident l’efficacité des contrôles de sécurité en simulant une attaque réelle. Un firewall peut être correctement configuré selon la checklist mais présenter des vulnérabilités dues à des interactions entre paramètres, des configurations non documentées ou des vulnérabilités firmware non patchées.

Vérification :

1. Vérifier l’existence de rapports de pentest sur l’infrastructure périmétrique
2. Date du dernier pentest (doit être < 12 mois pour les environnements exposés)
3. Vérifier que les vulnérabilités identifiées lors des pentests précédents ont été remédiées

Remédiation :

1. Planifier un test de pénétration externe annuel couvrant :
   • Scan et énumération des services exposés sur l’IP WAN
   • Test de brute-force sur les interfaces d’authentification (SSL-VPN, admin)
   • Test des CVE SonicWall connues sur la version firmware installée
   • Vérification de la résistance au DDoS
2. En interne : effectuer des scans réguliers (mensuels) depuis Internet avec nmap ou Shodan
3. Documenter et traiter toutes les findings dans le processus de patch management

Valeur par défaut : Aucun pentest — tests ponctuels selon disponibilité
Critère de conformité : Pentest annuel documenté, findings remédiés < 90 jours

---

🚨 PROCÉDURE DE RÉPONSE À INCIDENT (POST-COMPROMISSION SUSPECTÉE)

Si une compromission SonicWall est suspectée (connexions anormales, modifications de règles non autorisées, activité SSL-VPN suspecte), exécuter dans cet ordre :

Étape	Action	Priorité
1	Isoler : déconnecter le SSL-VPN depuis WAN. Si impossible, bloquer via règle WAN	Immédiat
2	Préserver les logs : exporter et archiver tous les logs avant toute action	Immédiat
3	Réinitialiser les secrets : tous les mots de passe admin, PSK VPN, credentials LDAP, community strings SNMP, clés API	< 1h
4	Révoquer les certificats : certificats VPN, certificats d’interface, clés d’automatisation	< 2h
5	Auditer les modifications : Enhanced Audit Log — identifier toutes les modifications depuis la date suspectée	< 4h
6	Patcher : appliquer le firmware corrigé si CVE impliquée	< 8h
7	Renforcer : activer MFA sur tous les comptes, restreindre accès WAN	Avant réouverture
8	Surveiller : augmenter le niveau de logging et les alertes SIEM pendant 30 jours	Continu
9	Notifier : si données personnelles compromises — CNIL dans les 72h (RGPD Art. 33)	Selon cas

Références de réponse à incident :

• Huntress SonicWall Incident Response Guide : https://www.huntress.com/blog/sonicwall-sslvpn-compromise
• ANSSI Guide Gestion de Crise Cyber : https://www.ssi.gouv.fr
• SonicWall PSIRT Emergency Contact : https://psirt.global.sonicwall.com

---

📚 RÉFÉRENCES

Références officielles SonicWall

Référence	URL
SonicWall PSIRT — Portail des vulnérabilités	https://psirt.global.sonicwall.com
SonicWall KB — Common Configurations	https://www.sonicwall.com/support/knowledge-base/common-configurations
SonicWall KB — Best Practices Admin	https://www.sonicwall.com/support/knowledge-base/best-practices-admin
SonicWall KB — Login lockout SonicOS 7.3/8.0.3	https://www.sonicwall.com/support/knowledge-base/enhance-security-with-login-lockout
SonicWall Notice — Gen 7 SSLVPN Threat Activity	https://www.sonicwall.com/support/notices/gen-7-sslvpn-recent-threat-activity
SonicWall Advisory — SSL-VPN MFA Bypass CVE-2024-12802	https://www.sonicwall.com/support/notices/ssl-vpn-mfa-bypass-cve-2024-12802

Références CVE et threat intelligence

Référence	URL
CERT-EU Advisory 2024-089 — CVE-2024-40766	https://cert.europa.eu/publications/security-advisories/2024-089/
CISA KEV Catalog	https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Beazley Security — Threat Actors SonicWall Gen 7	https://beazley.security/alerts-advisories/sonicwall-gen7
Huntress — Widespread SonicWall SSLVPN Compromise	https://www.huntress.com/blog/sonicwall-sslvpn-compromise
NVD — CVE SonicWall	https://nvd.nist.gov/vuln/search/results?vendor=sonicwall

Standards et référentiels

Référence	URL
CIS Controls v8	https://www.cisecurity.org/controls/cis-controls-list
MITRE ATT&CK Enterprise	https://attack.mitre.org/matrices/enterprise/
NIST SP 800-41 Rev 1 — Guidelines on Firewalls	https://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final
NIST SP 800-53 Rev 5 — Security Controls	https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
ANSSI — Recommandations sécurité réseaux	https://www.ssi.gouv.fr/guide/recommandations-securite-reseaux
ISO/IEC 27001:2022 — Annexe A.8.20 Networks Security	https://www.iso.org/standard/82875.html

---

---

📊 ANNEXE — CHECKLIST DE CONFORMITÉ (SYNTHÈSE)

Les tableaux ci-dessous constituent la checklist de synthèse à utiliser lors d’un audit terrain. Pour les détails de chaque contrôle, se référer aux sections précédentes.

---

Domaine 1 — Gestion du firmware et des licences

ID	Niveau	Contrôle	Gén.	Statut	Date
1.1	🟡 L1	Firmware à jour (Gen 7 ≥ 7.1.3, Gen 8 ≥ 8.0.3)	Toutes	☐
1.2	🔴 Critique	Aucun CVE CVSS ≥ 9.0 non patché	Toutes	☐
1.3	🟡 L1	Appliance enregistrée sur MySonicWall.com	Toutes	☐
1.4	🟡 L1	Toutes les licences de sécurité actives et non expirées	Toutes	☐
1.5	🔵 L2	MAJ automatique des signatures activée (IPS, AV, Anti-Spyware)	Toutes	☐
1.6	🔵 L2	Sauvegarde configuration (.exp) < 30 jours, stockée hors-appliance	Toutes	☐

---

Domaine 2 — Gestion des comptes et authentification

ID	Niveau	Contrôle	Gén.	Statut	Date
2.1	🔴 Critique	Mot de passe admin par défaut changé (≥ 12 caractères, complexe)	Toutes	☐
2.2	🔴 Critique	MFA activée sur tous les comptes administrateurs	Gen 7/8	☐
2.3	🔴 Critique	MFA activée sur tous les utilisateurs SSL-VPN + CVE-2024-12802 corrigée	Gen 7/8	☐
2.4	🟡 L1	Lockout après 3-5 tentatives, durée ≥ 15 min	Toutes	☐
2.5	🟡 L1	Complexité mots de passe imposée (≥ 12 caractères, 4 critères)	Gen 7/8	☐
2.6	🟡 L1	Aucun compte dormant ou non documenté	Toutes	☐
2.7	🟡 L1	Si LDAP/RADIUS actif : un seul compte local break-glass	Toutes	☐
2.8	🔴 Critique	Mots de passe réinitialisés après migration Gen 6 → Gen 7	Gen 7	☐
2.9	🔵 L2	LDAP ou RADIUS configuré et testé	Toutes	☐
2.10	🔵 L2	Timeout admin ≤ 15 min, Idle VPN ≤ 30 min	Toutes	☐

---

Domaine 3 — Interface d’administration

ID	Niveau	Contrôle	Gén.	Statut	Date
3.1	🔴 Critique	Aucun accès admin direct depuis WAN sans restriction IP	Toutes	☐
3.2	🟡 L1	HTTP désactivé, HTTPS uniquement (TLS 1.2+)	Toutes	☐
3.3	🟡 L1	SSH désactivé ou restreint à des IPs de gestion	Toutes	☐
3.4	🟡 L1	Certificat TLS valide (non auto-signé, non expiré)	Toutes	☐
3.5	🟡 L1	SNMP désactivé ou SNMPv3 avec SHA+AES, restreint par IP	Toutes	☐
3.6	🔵 L2	Seuls les protocoles de gestion nécessaires activés	Toutes	☐
3.7	🔵 L2	Compte read-only dédié pour supervision	Toutes	☐
3.8	🔵 L2	API REST désactivée ou sécurisée (clés minimales, rotation 90j)	Gen 7/8	☐
3.9	🔴 Critique	Liste blanche IPv4/IPv6 pour accès administration activée	Gen 7/8	☐
3.10	🔵 L2	TLS 1.0/1.1 désactivés, TLS 1.2 minimum, cipher suites modernes	Toutes	☐
3.11	🔵 L2	ALGs non utilisés désactivés (SIP, H.323, FTP, TFTP, RTSP)	Toutes	☐

---

Domaine 4 — Zones et segmentation réseau

ID	Niveau	Contrôle	Gén.	Statut	Date
4.1	🟡 L1	≥ 3 zones distinctes, segmentation par sensibilité des assets	Toutes	☐
4.2	🟡 L1	IPS, AV, Anti-Spyware activés sur LAN, DMZ, WLAN	Toutes	☐
4.3	🟡 L1	Zone IoT/OT dédiée, aucun accès IoT→LAN non autorisé	Toutes	☐
4.4	🟡 L1	WLAN et LAN dans zones distinctes, aucun accès implicite	Toutes	☐
4.5	🔵 L2	Zone MGMT dédiée, accès admin depuis MGMT uniquement	Toutes	☐
4.6	🔵 L2	Aucune règle Any-Any-Allow, toutes les règles commentées, revue < 6 mois	Toutes	☐

---

Domaine 5 — Règles de firewall

ID	Niveau	Contrôle	Gén.	Statut	Date
5.1	🟡 L1	Politique de refus par défaut (default deny) active	Toutes	☐
5.2	🟡 L1	Aucune règle “Any Any Allow” active	Toutes	☐
5.3	🟡 L1	Logging activé sur toutes les règles de refus	Toutes	☐
5.4	🟡 L1	Aucun service non justifié ouvert sur WAN	Toutes	☐
5.5	🔵 L2	Filtrage Geo-IP activé, liste pays bloqués documentée	Gen 7/8	☐
5.6	🔵 L2	Protection SYN/UDP/ICMP Flood activée	Toutes	☐
5.7	🔵 L2	App Control activé, P2P et proxies anonymisants bloqués	Toutes	☐

---

Domaine 6 — Services de sécurité

ID	Niveau	Contrôle	Gén.	Statut	Date
6.1	🟡 L1	IPS en mode Prevent sur toutes les zones, signatures < 24h	Toutes	☐
6.2	🟡 L1	Gateway AV activé sur toutes les zones, tous les protocoles	Toutes	☐
6.3	🟡 L1	Anti-Spyware en mode Prevent, Log Redundancy Filter = 60s	Toutes	☐
6.4	🟡 L1	Botnet Filter activé, bloc entrant ET sortant	Gen 7/8	☐
6.5	🟡 L1	Capture ATP activé, Block Until Verdict	Gen 7/8	☐
6.6	🔵 L2	DPI-SSL activé, certificat CA déployé sur clients	Toutes	☐
6.7	🔵 L2	CFS activé, catégories malveillantes bloquées	Toutes	☐
6.8	🔵 L2	Configuration DPI conforme aux best practices SonicWall	Toutes	☐

---

Domaine 7 — VPN SSL et accès distant

ID	Niveau	Contrôle	Gén.	Statut	Date
7.1	🔴 Critique	SSL-VPN désactivé si non utilisé	Toutes	☐
7.2	🔴 Critique	Accès SSL-VPN restreint à des IPs sources documentées	Gen 7/8	☐
7.3	🔴 Critique	MFA obligatoire SSL-VPN + CVE-2024-12802 corrigée	Gen 7/8	☐
7.4	🟡 L1	Session Timeout ≤ 8h, Idle Timeout ≤ 30 min	Toutes	☐
7.5	🟡 L1	Certificats pour tunnels site-à-site ou PSK ≥ 20 chars uniques	Toutes	☐
7.6	🔵 L2	Groupes VPN avec accès limité aux ressources nécessaires	Toutes	☐
7.7	🔵 L2	Politique split/full-tunnel documentée et alignée avec risques	Toutes	☐
7.8	🟡 L1	Virtual Office / Clientless VPN désactivé ou restreint avec MFA	Toutes	☐

---

Domaine 8 — Journalisation et supervision

ID	Niveau	Contrôle	Gén.	Statut	Date
8.1	🟡 L1	≥ 1 destination Syslog externe configurée, catégories critiques activées	Toutes	☐
8.2	🟡 L1	Enhanced Audit Logging activé	Gen 7/8	☐
8.3	🟡 L1	Alertes email configurées pour événements critiques	Toutes	☐
8.4	🟡 L1	Log Redundancy Filter = 60 secondes	Toutes	☐
8.5	🔵 L2	NTP synchronisé, écart < 1 seconde	Toutes	☐
8.6	🔵 L2	SNMPv3 traps configurées vers SIEM pour événements matériels	Toutes	☐
8.7	🔵 L2	Alertes SIEM sur modifications de configuration	Toutes	☐
8.8	🔵 L2	Abonnements PSIRT/CISA actifs, processus de surveillance renforcée	Toutes	☐
8.9	🔵 L2	NetFlow/IPFIX configuré vers collecteur SIEM, rétention ≥ 30 jours	Toutes	☐

---

Domaine 9 — Haute disponibilité et résilience

ID	Niveau	Contrôle	Gén.	Statut	Date
9.1	🔵 L2	HA Active/Standby configurée et synchronisée	Toutes	☐
9.2	🔵 L2	Unité HA secondaire enregistrée et licenciée	Toutes	☐
9.3	🔵 L2	Test de basculement HA documenté < 6 mois	Toutes	☐
9.4	🟡 L1	Sauvegarde mensuelle (.exp), stockée hors-appliance, restauration testée	Toutes	☐

---

Domaine 10 — Gestion du changement et conformité

ID	Niveau	Contrôle	Gén.	Statut	Date
10.1	🟡 L1	>90% des règles commentées (propriétaire, date, justification)	Toutes	☐
10.2	🟡 L1	Revue des règles documentée < 6 mois	Toutes	☐
10.3	🟡 L1	Abonnement PSIRT SonicWall actif et surveillé	Toutes	☐
10.4	🔵 L2	Audit de configuration documenté < 12 mois	Toutes	☐
10.5	🔵 L2	Pentest externe annuel documenté, findings remédiés < 90 jours	Toutes	☐

---

📊 Résumé par niveau de priorité

Priorité	Nombre de contrôles	Délai cible
🔴 Critique	10	Immédiat — dans les 24 à 72h
🟡 L1	32	Court terme — dans les 30 jours
🔵 L2	32	Moyen terme — dans les 90 jours
Total	74

---

📊 Score de conformité (calculé lors de l’audit)

Domaine	Critiques OK	L1 OK	L2 OK	Score
D1 — Firmware & Licences	/1	/3	/2	/6
D2 — Comptes & Auth	/3	/4	/3	/10
D3 — Interface Admin	/2	/3	/6	/11
D4 — Zones & Segmentation	/0	/4	/2	/6
D5 — Règles Firewall	/0	/4	/3	/7
D6 — Services Sécurité	/0	/5	/3	/8
D7 — VPN SSL	/3	/3	/2	/8
D8 — Logs & Supervision	/0	/4	/5	/9
D9 — HA & Résilience	/0	/1	/3	/4
D10 — Changement & Conformité	/0	/3	/2	/5
TOTAL	/10	/33	/31	/74

Interprétation :

• Critiques non conformes : risque immédiat — arrêter l’audit et remédier
• Score L1 < 50% : niveau de sécurité insuffisant — plan de remédiation urgent
• Score L2 < 50% : marge de progression sur la sécurité renforcée

---

Versioning

Version	Date	Modifications
1.0	Mai 2026	Création initiale — 69 contrôles, 10 domaines, format tableau
2.0	Mai 2026	Refonte CIS Benchmark-style — description risques, MITRE ATT&CK, remédiation détaillée, checklist en annexe
2.1	Mai 2026	Corrections inexactitudes CVE (SMA 1000 vs firewalls) · Ajout 5 contrôles (3.9, 3.10, 3.11, 7.8, 8.9) · Table des matières · Top 10 Quick Wins · Notes versions SonicOS

Document produit en mai 2026. Sources : SonicWall PSIRT, CERT-EU, Huntress, Beazley Security, CIS Controls v8, MITRE ATT&CK v15, NIST SP 800-41, ANSSI.