Contrôler la conformité d’un FortiGate au CIS
Cyberwatch évalue la conformité des pare-feu FortiGate au CIS FortiGate 7.4.x Benchmark v1.0.1, publié par le CIS en janvier 2026.
Les 64 recommandations du benchmark sont disponibles sous forme de règles de conformité. 61 d’entre elles sont vérifiées automatiquement à partir de la configuration du FortiGate, lue par son API REST. Les trois autres dépendent de votre organisation et sont à vérifier manuellement.
Ajouter le FortiGate
La conformité s’évalue sur un FortiGate ajouté avec le connecteur FortiGate (API), directement ou par un FortiManager. Après son premier scan, l’actif a le système d’exploitation FortiOS, auquel s’appliquent les règles du benchmark.
Un FortiGate scanné en SNMP a aussi le système FortiOS, mais ses règles ne sont pas évaluées : le SNMP ne donne pas accès à la configuration.
Le profil en lecture seule préparé pour le connecteur suffit, sauf pour les comptes d’administrateur, qu’il ne permet pas toujours de lire : les règles 2.4.1 et 2.4.2 sont alors en état Passé, avec la raison.
Associer les référentiels
Un nouveau FortiGate (API) reçoit d’office le référentiel CIS_Benchmark_level_1, qui regroupe les 39 recommandations de niveau 1.
Pour évaluer aussi les 25 recommandations de niveau 2, ajouter le référentiel CIS_Benchmark_level_2, ou bien CIS_Benchmark, qui regroupe les deux niveaux. Ces référentiels sont présents par défaut dans Cyberwatch.
Fonctionnement de l’évaluation
À chaque évaluation, Cyberwatch lit la configuration du FortiGate par son API, en lecture seule, puis évalue les règles. La configuration n’est pas conservée. L’évaluation a lieu tous les 30 jours par défaut, selon la politique de l’actif.
Les tables propres à un VDOM, comme les règles de pare-feu ou les profils de sécurité, sont lues pour tous les VDOM. Quand il y en a plusieurs, chaque constat indique son VDOM.
Si le FortiGate ne répond pas, ou refuse la clé d’API, l’évaluation échoue et les règles gardent le résultat de l’évaluation précédente. Si une table de configuration est illisible (lecture refusée par le profil, absente de cette version de FortiOS, ou incomplète), seules les règles qui en dépendent sont en état Passé, avec la raison.
Les règles qui portent sur des objets donnent un constat par objet, visible dans l’onglet « Conformité » de l’actif : par règle de pare-feu, interface, zone, profil de sécurité, compte d’administrateur ou utilisateur SNMPv3. Les autres donnent la valeur lue de chaque réglage, suivie de la valeur attendue quand elle diffère.
Règles de pare-feu et profils de sécurité
Les recommandations sur les profils de sécurité ne considèrent que les règles de pare-feu actives qui acceptent le trafic et l’inspectent : un profil n’est pris en compte que si la règle active les profils de sécurité (utm-status enable), directement ou par un groupe de profils. Les profils qu’aucune règle n’applique ne sont pas évalués.
Sans règle de pare-feu dans leur périmètre, ces recommandations sont en Succès. Si des règles existent mais qu’aucune n’applique de profil du type attendu, la recommandation est en Échec. Un profil appliqué mais introuvable dans son VDOM donne un constat non évalué.
Une règle de pare-feu mène à Internet quand sa destination est une interface de rôle WAN, une zone ou une zone SD-WAN qui en contient une, ou any. Sans interface de rôle WAN, les recommandations sur les règles vers Internet (4.1.1 et 4.3.3) sont en état Passé.
Seules les règles de pare-feu (Firewall Policy) sont lues : les politiques de sécurité du mode NGFW basé sur les politiques ne sont pas évaluées.
Recommandations vérifiées automatiquement
| Règle | Niveau | Contrôle |
|---|---|---|
| CIS-FortiGate-1.1 | 1 | Un serveur DNS primaire ou secondaire est configuré |
| CIS-FortiGate-1.2 | 1 | Chaque zone bloque le trafic entre ses interfaces (intrazone deny) |
| CIS-FortiGate-1.3 | 1 | Aucune interface active de rôle WAN n’autorise l’administration en PING, HTTPS, HTTP, SSH, SNMP, RADIUS accounting ou Telnet, en IPv4 comme en IPv6. L’accès d’un FortiManager (fgfm) reste permis |
| CIS-FortiGate-2.1.1 | 1 | pre-login-banner est activé |
| CIS-FortiGate-2.1.2 | 1 | post-login-banner est activé |
| CIS-FortiGate-2.1.4 | 1 | La synchronisation NTP est activée et un serveur NTP joignable est sélectionné |
| CIS-FortiGate-2.1.5 | 1 | Le nom d’hôte n’est ni le numéro de série ni le nom du modèle |
| CIS-FortiGate-2.1.6 | 2 | FortiGuard ne propose pas de correctif plus récent de la branche de FortiOS installée |
| CIS-FortiGate-2.1.7 | 2 | auto-install-config et auto-install-image sont désactivés |
| CIS-FortiGate-2.1.8 | 2 | ssl-static-key-ciphers est désactivé |
| CIS-FortiGate-2.1.9 | 2 | strong-crypto est activé |
| CIS-FortiGate-2.1.10 | 1 | L’administration HTTPS n’accepte que TLS 1.3 (admin-https-ssl-versions tlsv1-3) |
| CIS-FortiGate-2.1.11 | 2 | gui-cdn-usage est activé |
| CIS-FortiGate-2.1.12 | 1 | log-single-cpu-high est activé |
| CIS-FortiGate-2.1.13 | 2 | gui-display-hostname est désactivé |
| CIS-FortiGate-2.2.1 | 1 | La politique de mots de passe est activée, couvre les mots de passe des administrateurs et les clés IPsec, et exige au moins 14 caractères |
| CIS-FortiGate-2.2.2 | 1 | admin-lockout-threshold vaut au plus 3, et admin-lockout-duration au plus 900 secondes |
| CIS-FortiGate-2.3.1 | 1 | L’agent SNMP est activé, sans communauté SNMPv1/v2c, avec au moins un utilisateur SNMPv3 actif |
| CIS-FortiGate-2.3.2 | 2 | Chaque utilisateur SNMPv3 actif est limité à des hôtes précis (notify-hosts) |
| CIS-FortiGate-2.3.3 | 2 | Aucun utilisateur SNMPv3 actif ne peut interroger l’agent (queries disable) |
| CIS-FortiGate-2.3.4 | 1 | L’agent SNMP est activé, trap-free-memory-threshold vaut au moins 20 et trap-freeable-memory-threshold au plus 50 |
| CIS-FortiGate-2.4.1 | 1 | Aucun compte d’administrateur ne s’appelle admin |
| CIS-FortiGate-2.4.2 | 1 | Chaque compte d’administrateur est limité à des hôtes de confiance. Quand seuls ses hôtes IPv4 le sont, le constat invite à vérifier l’accès en IPv6 |
| CIS-FortiGate-2.4.4 | 1 | admintimeout vaut au plus 5 minutes |
| CIS-FortiGate-2.4.5 | 1 | Aucune interface active n’autorise l’administration en HTTP ou en Telnet |
| CIS-FortiGate-2.4.6 | 1 | Chaque VDOM a au moins une politique local-in active |
| CIS-FortiGate-2.4.7 | 1 | Les ports d’administration ne sont pas 443 et 80, et admin-https-redirect est désactivé |
| CIS-FortiGate-2.4.8 | 1 | Chaque politique local-in active qui accepte du trafic applique le virtual patching |
| CIS-FortiGate-2.5.1 | 2 | La haute disponibilité est activée |
| CIS-FortiGate-2.5.2 | 1 | La HA surveille au moins une interface (monitor) |
| CIS-FortiGate-2.5.3 | 1 | La HA réserve une interface de gestion, avec sa passerelle |
| CIS-FortiGate-2.5.4 | 2 | Le group-id de la HA n’est pas 0 |
| CIS-FortiGate-3.2 | 1 | Aucune règle de pare-feu active qui accepte du trafic n’utilise le service ALL |
| CIS-FortiGate-3.3 | 1 | Des règles de pare-feu actives refusent le trafic entrant, sur tous les services, et sortant des services à risque de l’ISDB énumérés par le benchmark. Les règles inversées (negate) ne comptent pas |
| CIS-FortiGate-3.4 | 1 | Chaque règle de pare-feu active qui accepte du trafic journalise toutes ses sessions (logtraffic all), chaque règle de refus le trafic refusé, et la règle de refus implicite de chaque VDOM aussi (fwpolicy-implicit-log) |
| CIS-FortiGate-4.1.1 | 2 | Les profils IPS des règles vers Internet bloquent les connexions aux botnets |
| CIS-FortiGate-4.1.2 | 1 | Chaque règle qui accepte du trafic applique un profil IPS |
| CIS-FortiGate-4.2.1 | 2 | Les mises à jour FortiGuard sont activées en mode automatique |
| CIS-FortiGate-4.2.2 | 2 | Chaque règle qui accepte du trafic applique un profil antivirus |
| CIS-FortiGate-4.2.3 | 2 | Les profils antivirus appliqués bloquent les épidémies sur chaque protocole qu’ils scannent (outbreak-prevention block) |
| CIS-FortiGate-4.2.4 | 2 | La détection par apprentissage automatique (machine-learning-detection) est activée |
| CIS-FortiGate-4.2.5 | 2 | La détection des grayware est activée |
| CIS-FortiGate-4.2.6 | 1 | Le scan en ligne du bac à sable FortiGuard est activé, et les profils antivirus appliqués l’utilisent en mode bloquant sur chaque protocole qu’ils scannent |
| CIS-FortiGate-4.2.7 | 2 | Les profils antivirus appliqués sont en mode proxy et désarment le contenu (CDR) |
| CIS-FortiGate-4.3.1 | 2 | Les filtres DNS appliqués bloquent les domaines des botnets |
| CIS-FortiGate-4.3.2 | 1 | Les filtres DNS appliqués journalisent toutes les requêtes (log-all-domain) |
| CIS-FortiGate-4.3.3 | 1 | Chaque règle vers Internet applique un filtre DNS |
| CIS-FortiGate-4.4.1 | 1 | Les filtres web appliqués bloquent les catégories Malicious Websites, Phishing et Spam URLs |
| CIS-FortiGate-4.5.1 | 1 | Les profils de contrôle applicatif appliqués bloquent les catégories P2P et Proxy : la première entrée qui vise chacune la bloque en entier, sans filtre |
| CIS-FortiGate-4.5.2 | 2 | Les profils de contrôle applicatif appliqués bloquent les applications sur un port inhabituel |
| CIS-FortiGate-4.5.3 | 1 | Les profils de contrôle applicatif appliqués ne laissent passer aucune catégorie sans la journaliser |
| CIS-FortiGate-4.5.4 | 1 | Chaque règle qui accepte du trafic applique un profil de contrôle applicatif |
| CIS-FortiGate-5.1.1 | 1 | Une automatisation active met en quarantaine les hôtes compromis |
| CIS-FortiGate-5.2.1.1 | 2 | La Security Fabric est activée et nommée, et les journaux partent vers FortiAnalyzer. La sortie donne le rôle du FortiGate, racine ou en aval |
| CIS-FortiGate-6.1.1 | 2 | Le VPN SSL présente un certificat autre que ceux de Fortinet |
| CIS-FortiGate-6.1.2 | 2 | Le VPN SSL n’accepte que TLS 1.2 et 1.3, en chiffrement fort |
| CIS-FortiGate-7.1.1 | 2 | Tous les types d’événements sont journalisés |
| CIS-FortiGate-7.2.1 | 2 | Les journaux partent vers un des serveurs syslog (syslogd à syslogd4), un des FortiAnalyzer (fortianalyzer à fortianalyzer3) ou FortiAnalyzer Cloud |
| CIS-FortiGate-7.3.1 | 1 | Les journaux envoyés à chaque FortiAnalyzer actif sont chiffrés (enc-algorithm high) et fiables (reliable enable) |
| CIS-FortiGate-7.3.2 | 1 | Les journaux envoyés à chaque serveur syslog actif sont chiffrés (enc-algorithm high) et fiables (mode reliable) |
| CIS-FortiGate-7.3.3 | 1 | Identique à 7.3.2, que le benchmark répète |
Les contrôles reprennent la procédure d’audit du benchmark, y compris quand elle est stricte : la règle 2.1.10 exige TLS 1.3 seul, et la règle 2.2.2 une durée de blocage d’au plus 900 secondes.
La sortie de la règle 5.2.1.1 rappelle ce qui reste à vérifier manuellement : les réglages de FortiAnalyzer et les interfaces qu’empruntent les équipements de la Security Fabric. La règle 6.1.1 ne vérifie pas que le certificat est signé par une autorité de confiance.
Recommandations sans objet
Certaines recommandations sont en état Passé quand elles ne s’appliquent pas au FortiGate :
- 1.3, sans interface active de rôle WAN : les ports WAN sont à identifier manuellement ;
- 2.1.6, quand le FortiGate n’a pas la liste des versions de FortiOS, faute de joindre FortiGuard ;
- 2.5.2 à 2.5.4, sur un FortiGate sans haute disponibilité ;
- 4.1.1 et 4.3.3, sans interface de rôle WAN : les règles vers Internet ne peuvent pas être repérées ;
- 6.1.1 et 6.1.2, sans VPN SSL actif ;
- 7.3.1, quand les journaux ne partent vers aucun FortiAnalyzer, et 7.3.2 et 7.3.3, quand ils ne partent vers aucun serveur syslog. La surcharge de la journalisation par un VDOM n’est pas lue.
Recommandations à vérifier manuellement
Trois recommandations dépendent de votre organisation :
- 2.1.3, le fuseau horaire : sa sortie donne le fuseau configuré ;
- 2.4.3, les profils des comptes d’administrateur ;
- 3.1, la revue périodique des règles de pare-feu inutilisées.
Ces règles sont en état Passé, avec la mention « Manual verification required » suivie de la raison. La fiche de chaque règle reprend la procédure d’audit du CIS.
Une fois une recommandation vérifiée, il est possible d’ignorer la règle et de commenter ce choix.