Comment conduire un audit de firewalls

Par Stephan Mesguich, directeur régional de Tufin Technologies France et Benelux

Un des aspects les plus importants d’un audit de firewall est l’examen du processus de changement et de la base des règles de sécurité. Voici quelques-unes des principales caractéristiques techniques dont le service en charge de l’audit préalable de l’audit final pourrait avoir besoin.

1) Audit du processus de changement

La première étape de la vérification technique d’un firewall est généralement l’analyse de son processus de changement. L’objectif de cette étape est de s’assurer que les modifications demandées ont été dûment validées, mises en œuvre et documentées. Il y a plusieurs manières de faire – soit de manière automatique via un outil, soit manuellement.

Il est important de prendre en compte, au hasard, environ 10 demandes de changements faites depuis le dernier audit. Les questions fondamentales que l’on doit se poser lors de la vérification des modifications du firewall, sont les suivantes :

• Le demandeur est-il enregistré, est-il autorisé à faire des demandes de modifications du firewall ?

• La raison métier de cette modification est-elle notée ?
• Les personnes en charge de la relecture et de la validation ont-elles signé (électroniquement ou physiquement) ?
• Les validations ont-elles été enregistrées avant la mise en œuvre de la modification?
• Les personnes en charge de la validation sont-elles toutes autorisées à approuver les modifications du firewall (une liste des personnes autorisées devra être réalisée) ?
• Les modifications sont-elles bien documentées dans le ticket de modification ?
• Existe-t-il des documents d’analyse des risques pour chaque changement ?
• Une documentation sur les fenêtres de changement et/ou de dates d’installation de chaque changement existe-t-elle ?
• Y a-t-il une date d’expiration pour le changement ?

Si ces tâches sont réalisées manuellement, la première chose est de faire correspondre chaque modification avec un dispositif du firewall et avec une politique. Puis, de faire coïncider les demandes de modification avec la ou les règles de firewall qui ont mis en œuvre le trafic demandé. Le commentaire de chaque règle doit être lié à au moins deux éléments de données : l’ID de modifications de la demande et les initiales de l’ingénieur qui a mis le changement en œuvre.

Des outils d’automatisation sont largement disponibles et, en raison du grand nombre de règles que gèrent la plupart des firewalls modernes, ils sont fortement recommandés pour aider les DSI dans le processus de vérification. Ils permettent d’avoir une visibilité beaucoup plus grande et donc, un meilleur contrôle des bases de règles.

Par exemple, ils montrent qui a ajouté la règle et quand, et si la personne a également ajouté quelque chose à la politique. Ils permettent aussi de mettre le numéro du ticket de modification dans le champ de commentaires, de sorte que la règle intègre un lien hypertexte vers le ticket de modification, ce qui simplifie la recherche de la piste de vérification. L’on peut même générer un rapport historisé pour voir comment cette règle a changé avec les autres tickets de modification depuis qu’elle a été mise en œuvre. Des solutions dotées de fonctionnalités de gestion du changement plus avancées affichent la demande de règle avec la signature de l’audit, l’analyse des risques et la mise en œuvre dans la base de règles. Le cycle de vie complet, de la demande à la mise en œuvre, est documenté et vérifiable.

2) Audit de la base de règles du firewall

La deuxième étape technique d’un audit est généralement l’analyse de la base de règles du firewall (également appelée politique). La méthodologie de cette étape varie considérablement selon les auditeurs, car le processus a toujours été difficile et très dépendant de la technologie.

Pour chacune des questions, il faut disposer d’un ranking fondé sur le type de firewall et sur son emplacement dans l’infrastructure. Par exemple, un firewall qui n’est pas connecté à Internet, ne comporte pas le même risque que celui qui est connecté à Internet. Les firewalls internes sont généralement plus laxistes que les firewalls externes.

Les premières questions à poser au sujet de la base de règles sont liées à la maintenance de base des politiques et aux bonnes pratiques de conception qui accordent un accès minimal pour chaque périphérique. Pour répondre à ces questions, l’on doit afficher chaque règle de la base de règles et une année de logs, qui diront quelles règles sont utilisées. Jusqu’à  récemment, c’était toujours très long et manuel. L’arrivée d’outils qui peuvent être utilisés pour répondre automatiquement et de façon programmée, a largement permis de raccourcir les temps de traitement.

• Combien de règles comporte la politique ? Combien en avait-elle au dernier audit ? Et l’an dernier ?
• Des règles sont-elles dépourvues de commentaires ?
• Des règles redondantes peuvent-elle être supprimées ?
• Des règles sont-elles inutilisées ?
• Des services des règles sont-ils inutilisés ?
• Des groupes ou réseaux des règles sont-ils inutilisés ?
• Existe-t-il des règles de firewall comportant « ANY » dans trois champs (source, destination, service/protocole) et une action permissive ?
• Existe-t-il des règles comportant « ANY » dans deux champs et une action permissive?
• Existe-t-il des règles comportant « ANY » dans un champ et une action permissive ?
• Existe-t-il des règles trop laxistes : des règles avec plus de 1000 adresses IP autorisées dans la source ou la destination ? (l’on peut prendre un autre nombre que 1000, comme 10 000, ou 500).

La deuxième liste de questions à poser sur une base de règles est liée aux risques et à la conformité. Il est plus difficile techniquement d’analyser ces règles. Il faut comprendre différents points : la technologie du pare-feu utilisé pour comprendre quel trafic est géré par chaque règle ; s’il y a un groupe de services appelés « services autorisés » ; et enfin, les ports et protocoles par lesquels passe cette règle.

• Existe-t-il des règles qui violent la politique de sécurité de l’entreprise ?
• Existe-t-il des règles qui laissent entrer des services entrant risqués depuis Internet ? Même s’il existe une liste différente de ce qui est considéré comme « à risque » pour l’entreprise, la plupart des règles commencent par des protocoles qui transmettent des identifiants de connexion en clair comme Telnet, FTP, POP, IMAP, http, NetBIOS, etc.
• Existe-t-il des règles qui permettent à des services risqués de sortir vers Internet ?
• Existe-t-il des règles qui autorisent du trafic directement depuis Internet vers le réseau interne (pas vers la DMZ) ?
• Existe-t-il des règles qui autorisent le trafic d’Internet vers des serveurs des réseaux, des dispositifs ou des bases de données sensibles ?

Mais si l’on prend le temps de maîtriser ces deux processus, on constatera qu’il est beaucoup plus facile de réussir des audits de firewalls.

En effet, après avoir répondu à des centaines d’audits de firewalls, je suis un grand fan de l’automatisation la plus poussée de ce processus. Non seulement, cela fournit des informations dont les administrateurs ont besoin pour répondre aux questions difficiles de l’audit, mais si l’on est chargé de l’audit d’un grand ensemble de firewalls dans une grande base de règles difficile à manier, le temps et l’argent économisés, ainsi que l’élimination de la marge d’erreur systématique pour ces processus lourds et gourmands en données comme les audits manuels, les rendent particulièrement attrayants.

Si l’automatisation n’est pas envisageable, il est absolument essentiel de traiter ces deux domaines pour conserver des règles et politiques de firewalls saines et efficaces.