I. Présentation

Dans cet article, nous allons définir et comprendre ce qu’est un audit de sécurité. Nous verrons à quels besoins il peut répondre, quels sont ses enjeux, ses modalités et objectifs.

Avez-vous déjà pensé à la sécurité de vos données et de votre système d’information ? Il n’y a pas un jour, même une minute, sans que les systèmes du monde entier ne reçoivent les sollicitations de hackers (humains ou robots) souhaitant s’introduire dans vos systèmes. Leurs objectifs peuvent être l’argent, la défense d’idéologies religieuses ou (géo)politiques, l’espionnage industriel, etc. Dans ce contexte, nous allons voir que l’audit de sécurité est une étape incontournable de la sécurisation des systèmes. Mais, en quoi consiste exactement un audit de sécurité et pourquoi est-il indispensable pour votre organisation ?

Note : Étant moi-même auditeur cybersécurité/pentester depuis de nombreuses années, je ne pourrais m’empêcher de glisser quelques mots de ce qu’est le métier d’auditeur, même si ce n’est pas le sujet principal de l’article.

Contrairement à ce que l’on pense, un audit de sécurité n’est pas à confondre avec un test d’intrusion, qui en est seulement l’un de ses composants. Voyons tout cela de plus près.

II. Audit de sécurité : objectifs et enjeux

Un audit de sécurité consiste en une évaluation approfondie et méthodique de votre système d’information. Le but est d’identifier les vulnérabilités et les risques potentiels en matière de sécurité. En gros, c’est comme un check-up complet de votre système pour voir quelles sont ses faiblesses et comment renforcer sa robustesse. Cette analyse peut être réalisée en interne par vos équipes, ou en externe par des experts spécialisés. Chaque approche a ses avantages, mais un regard externe apporte souvent une perspective nouvelle et une expertise.

Un audit de sécurité peut prendre plusieurs formes. Nous allons passer en revue ces différentes formes par la suite pour comprendre leurs intérêts et leurs méthodologies. Cependant, il faut bien comprendre que chaque situation est différente et peut nécessiter un angle d’attaque et d’analyse spécifique.

Pour réaliser leur analyse, les auditeurs se basent sur des guides, référentiels, bonnes pratiques, voir directement sur des normes ou des lois. Le travail de fond d’un auditeur est donc de confronter une situation, une configuration, une architecture ou un bout de code à l’un de ces éléments et de constater ou non une conformité.

Par exemple, la directive n°1 du guide d’hygiène informatique de l’ANSSI s’intitule “Former les équipes opérationnelles à la sécurité des systèmes d’information”. Les auditeurs vont donc chercher à savoir et à prouver que c’est bien le cas, et de rappeler cette directive ainsi que fournir des recommandations plus détaillées si ça ne l’est pas. Cela tout en exposant l’intérêt de la formation des équipes, les risques concrets pour l’entité lorsque ce n’est pas fait, etc.

Dans un audit, tout doit être basé sur des faits pour éviter toute ambiguïté. On parle alors de preuve d’audit. Il peut s’agir des notes prises pendant un entretien oral, d’un relevé de configuration, d’un extrait de documentation ou encore d’un relevé technique (preuve du succès d’une attaque, bout de code, etc.).

La cybersécurité est une composante centrale pour toutes les organisations, quelle que soit leur taille. Voici les trois raisons principales qui rendent les audits indispensables :

A. Protéger et se conformer

Les audits réguliers permettent d’identifier les faiblesses du système d’information avant qu’elles ne soient exploitées par des hackers, offrant ainsi une opportunité de les corriger proactivement. Par ailleurs, de nombreuses réglementations comme le RGPD ou la directive NIS2 imposent des exigences strictes en matière de sécurité des données. Les audits aident les organisations à maintenir cette conformité légale. 

Aussi, les auditeurs en cybersécurité, grâce à leur expertise et leur connaissance des risques et techniques d’attaques les plus récentes, jouent un rôle pédagogique important. Ils aident les équipes internes à comprendre les risques qui pèsent sur leur système d’information et démontrent concrètement comment différentes faiblesses pourraient être exploitées.

B. Optimisation et amélioration continue

Les conclusions d’un audit de cybersécurité aident à identifier les investissements prioritaires en matière de sécurité. Un audit permet donc de faire des choix sur l’orientation du budget alloué à la cybersécurité, mais aussi à contrôler si les choix passés sont efficaces.

Aussi, ils permettent une surveillance et une amélioration continue des mesures de sécurité. Ils aident à identifier les nouvelles vulnérabilités qui pourraient apparaître avec l’évolution du système d’information, les nouvelles techniques d’attaques et à ajuster les stratégies de sécurité en conséquence. Cette approche est comparable au contrôle technique d’une voiture : elle permet de s’assurer régulièrement que, malgré ses évolutions et son utilisation quotidienne, un système d’information maintient un certain niveau de robustesse.

C. Image et confiance l’organisation

Les audits de sécurité ont aussi un rôle dans le renforcement de la confiance des partenaires d’une organisation (clients, fournisseurs). Ils démontrent de manière tangible que l’organisation prend au sérieux la sécurité des données et met en œuvre des mesures pour les protéger. Cette démonstration de sérieux est parfois même un prérequis pour établir des partenariats stratégiques ou finaliser des opérations d’acquisition, notamment lorsqu’il est prévu une interconnexion des SI.

Enfin, en prévenant les cyberattaques et les vols de données, les audits contribuent directement à protéger la réputation de l’organisation, évitant ainsi les dommages financiers et d’image associés à des incidents de sécurité.

La réalisation d’un audit se conclut par la rédaction d’un rapport d’audit qui vise à fournir les détails, les métriques et la synthèse des éléments relevés. Cela peut être les points positifs, les points négatifs, les détails techniques des vulnérabilités trouvées. Le rapport d’audit contient également des éléments permettant d’évaluer la gravité d’une vulnérabilité, le niveau de sécurité global, une estimation de l’urgence d’application des recommandations, mais aussi les détails des éléments à mettre en place pour corriger une vulnérabilité.

Comme indiqué précédemment, un audit peut prendre plusieurs formes (parfois appelées portées d’audit), qui peuvent être plus ou moins techniques et avoir des méthodologies ou des angles d’analyse différents. Chaque type d’audit est généralement complémentaire et vient apporter une confirmation, invalidation ou information supplémentaire par rapport aux résultats d’un autre type d’audit. Voyons ce que sont ces différentes portées.

III. Les types d’audit de sécurité

A. Le test d’intrusion

C’est certainement le type d’audit le plus connu, si bien qu’il en prend parfois la place et la définition. Le test d’intrusion (et non test de pénétration, traduction maladroite de pentest) consiste pour les auditeurs à prendre la place, la mentalité, les objectifs et les outils d’un pirate (hacker). Leur objectif est donc de s’introduire sur le système d’information à partir d’une position donnée (qui peut être Internet, une proximité physique, le réseau Wifi, une salle de réunion, etc.) puis de progresser, compromettre des comptes, des systèmes et des données. 

Bien que le test d’intrusion désigne souvent l’attaque d’un système d’information, il peut aussi se limiter à une ressource ou quelques composants. Par exemple un site web, un ERP, un environnement cloud, etc.

Cette démarche est la plus parlante, car on peut factuellement confirmer qu’un système est vulnérable. Elle permet d’exposer pas à pas les faiblesses exploitées et les impacts possibles.

Pour réaliser cette démarche, qui en temps normal serait totalement illégale, les auditeurs disposent d’une autorisation spécifique de l’audité.

L’objectif premier est de référencer les faiblesses du périmètre audité, comme un système d’information. Un second objectif peut être de compromettre un compte administrateur du domaine (ou autre type d’accès privilégié), car celui-ci possède les clés de l’ensemble des systèmes et permet de “tout faire” sur le SI. Cela permet de démontrer qu’une compromission complète est possible grâce au “chainage” de certaines des vulnérabilités découvertes. Il peut aussi être défini des trophées plus spécifiques et précis que les auditeurs vont chercher à atteindre. Cela peut être “obtenir les détails du dernier contrat passé avec notre client”, “lire les e-mails de notre PDG”, “avoir accès aux fiches de paies”, etc.  Atteindre ces différents objectifs ou pas permettra à l’audité d’évaluer la robustesse des mécanismes de sécurité mis en place pour protéger les cibles définies.

Pour ce faire, les auditeurs vont repérer plusieurs faiblesses ou vulnérabilités, et les exploiter de façon chainée pour dessiner un chemin de compromission complet (parfois appelé scénario d’attaque).

Dans le cadre de ce relevé des faiblesses ou non conformité aux bonnes pratiques présentes sur le SI, un certain nombre de scans et de cartographies sont réalisés pour obtenir le plus d’informations possible. On pourra, par exemple, dresser la liste des utilisateurs ayant un mot de passe faible, des systèmes n’ayant pas l’obligation de signer les échanges SMBv1 ou encore les services FTP accessibles sans authentification. De nombreux contrôles sont aussi à faire sur l’Active Directory, ses objets et leurs relations.

Voici une liste de quelques outils et ressources utilisées en tests d’intrusion :

Nmap : Pour l’analyse et la cartographie réseau (voir notre cours gratuit sur le sujet)

Metasploit : Framework d’exploitation et d’automatisation d’attaque

Exegol : Package d’outils sous forme de container Docker (made in France !)

BurpSuite: Proxy local, pour l’interception, l’analyse, la modification et le rejeu des requêtes web.

BloodHound : Outil d’analyse des faiblesses de l’Active Directory et des chemins d’attaque (voir notre cours gratuit sur le sujet)

OWASP Testing Guide : Référentiel de test pour les applications web

MITRE ATT&CK : Référentiels de techniques d’attaque.

Lors d’un test d’intrusion, on distingue trois types d’approche, qui peuvent être combinées. Elles se distinguent par le niveau d’information fourni aux auditeurs pour réaliser leurs tests.

Approche “boîte noire” :  Elle se rapproche le plus d’une attaque réelle. Dans ce cas, aucune information n’est fournie aux auditeurs avant le début des tests. Ils doivent découvrir et exploiter les vulnérabilités sans connaissance préalable du système. C’est l’approche la plus réaliste pour simuler une cyberattaque, mais elle peut aussi être la plus longue et la plus coûteuse.

Approche “boîte grise” : Dans ce cas, les auditeurs reçoivent certaines informations sur le système, mais pas toutes. Le niveau de détail fourni dépend des objectifs spécifiques de l’audit et de la cible testée. Cette méthode simule une situation dans laquelle un attaquant aurait déjà obtenu un accès limité au système, par exemple, en ayant compromis un compte utilisateur standard ou en ayant accès à certaines parties non publiques de l’infrastructure. L’avantage de cette approche est qu’elle permet de tester la résistance du système face à un attaquant qui aurait déjà franchi une première ligne de défense, tout en restant plus réaliste qu’une approche en boîte blanche complète (exemple : on dispose d’un compte stagiaire valide sur l’AD, et d’un poste utilisateur).

Approche “boîte blanche” : À l’opposé de la boîte noire, l’approche en boîte blanche fournit aux auditeurs un maximum d’informations sur le système cible : code source, identifiants administrateur, documentation technique, etc. Cette méthode permet d’identifier des vulnérabilités qui pourraient passer inaperçues sans une connaissance approfondie du système. Elle est particulièrement efficace pour détecter des failles complexes ou des problèmes de configuration qui nécessitent une compréhension fine de l’architecture. C’est une approche qui permet aussi de pallier au problème du temps restreint que présente un audit et pour laquelle l’approche boite noire apparaît comme chronophage.

Attention toutefois, bien qu’il puisse paraitre comme le côté le plus “sexy” du métier d’auditeur, il n’est pas forcément leur activité principale. Certains auditeurs vont, par exemple, être spécialisés dans la réalisation d’audit organisationnel ou physique et, bien qu’ils en comprennent les enjeux et objectifs, ils ne seront pas forcément des experts techniques capables de réaliser des tests d’intrusion (l’inverse est aussi vrai). Le métier d’auditeur est donc en réalité composé de plusieurs casquettes, que l’on peut avoir ou non en fonction de ses expériences et appétences (sans parler des nombreuses casquettes normatives et technologiques).

B. L’audit d’architecture

L’audit d’architecture est une portée à ne pas négliger pour évaluer la conception globale de votre système d’information. Il ne s’agit pas seulement de vérifier les composants individuels, mais de comprendre comment ils interagissent et s’intègrent pour former un tout cohérent et sécurisé. Il consiste en la revue de l’architecture (au sens réseaux et sous-réseau), des pare-feu et des mécanismes de contrôle/filtrage des flux, des systèmes de sauvegarde, de mise à jour, de journalisation, d’administration et de tous les composants ayant un impact sur la sécurité.

L’objectif est de s’assurer que l’architecture est robuste et capable de résister aux menaces potentielles, mais qu’elle permet aussi de bloquer, voire détecter un attaquant. 

Les auditeurs utilisent souvent la documentation interne et les schémas pour visualiser l’architecture et identifier les points faibles. Cette revue documentaire est complétée par des entretiens oraux avec les personnes en charge du SI : administrateurs systèmes, réseaux, RSSI, DSI, etc. En cela, l’audit d’architecture se combine très bien avec le test d’intrusion, qui permet souvent de confirmer ou d’infirmer la composition architecturale telle que définie dans la documentation ou évaluée pendant les entretiens.

Par exemple, il arrive fréquemment qu’un pare-feu entre deux zones soit mal configuré, laissant passer des flux qui devraient être bloqués. Dans ce cas, l’audit d’architecture permet d’identifier un composant central et important du point de vue de la sécurité. La revue de la documentation d’architecture peut donner l’impression d’une situation maîtrisée et sécurisée, tandis que le test d’intrusion peut révéler une réalité différente.

Les référentiels externes et publiques sont souvent utilisés pour confronter les éléments de l’architecture en place avec les bonnes pratiques. On peut notamment citer les guides de l’ANSSI, comme les Recommandations relatives à l’administration sécurisée des SI, les Recommandations relatives à l’interconnexion d’un SI à Internet ou plus récemment celui sur la cybersécurité des systèmes industriels.

Par exemple, le chapitre 2.4 des Recommandations relatives à l’interconnexion d’un SI à Internet de l’ANSSI présente une architecture “modèle” de passerelle Internet sécurisée. En effectuant un audit d’architecture à l’aide des schémas, de la documentation et des entretiens oraux, un auditeur va chercher à comprendre si ce modèle est respecté. Il va devoir pour cela, avoir une vue claire de ce qui est en place, et prendre en considération les éléments supplémentaires présents (éventuelle zone en plus, spécificités techniques ou métiers, etc.) : 

Extrait du guide de l’ANSSI sur l’interconnexion d’un SI à Internet.

Les “écarts” aux modèles devront alors être analysés afin d’évaluer s’ils apportent une faiblesse ou au contraire une robustesse supplémentaire par rapport au modèle.

L’utilisation de référentiels connus, qu’ils soient techniques ou moins techniques, permet à la fois de faire argument d’autorité, mais aussi d’évaluer chaque SI sur une base commune et éprouvée. Cependant, il est important pour un auditeur de ne pas se restreindre à ces guides, checklists ou normes et de savoir aller plus loin pour s’adapter à son contexte d’audit.

C. L’audit de code

L’audit de code consiste à examiner le code source d’une application, d’un site web ou encore d’une application mobile pour identifier les vulnérabilités potentielles, les erreurs de programmation, et les non-conformités aux bonnes pratiques de développement. On parle souvent de “boite blanche” dans la mesure où tous les secrets de l’application sont fournis aux auditeurs.

Ce type d’audit est souvent combiné à un test d’intrusion. Cela permet de valider les faiblesses découvertes via des attaques concrètes. Il s’agit souvent d’un exercice difficile, car une vulnérabilité évidente d’un bout de code doit être replacée dans son contexte d’exécution. Les contrôles de sécurité sur une entrée utilisateur peuvent, par exemple, être réalisés en amont ou en aval du code que l’on est en train d’analyser à l’instant T.

Les auditeurs utilisent des outils d’analyse statique et dynamique pour détecter les failles de sécurité. Ces outils permettent de scanner le code à la recherche de motifs connus de vulnérabilités, tels que des fonctions non sûres, les injections SQL, les débordements de tampon, et les failles de type cross-site scripting (XSS). Les résultats de ces outils sont analysés et complétés par le travail manuel de l’auditeur, ce qui permet notamment d’effectuer des contrôles relatifs à l’aspect métier du code analysé.

Voici quelques outils pouvant être utilisés lors d’un audit de code :

SonarQube : Pour l’analyse statique.

Checkmarx : Pour l’analyse de code source.

D. L’audit de configuration

L’audit de configuration vise à vérifier que les systèmes et les applications sont configurés de manière sécurisée, en conformité avec les bonnes pratiques. Cela inclut la vérification des paramètres de sécurité, des permissions d’accès, des configurations réseau, et des politiques de gestion des utilisateurs, etc. En fonction des systèmes analysés, les éléments passés en revue peuvent être très différents. 

Pour donner quelques exemples, on peut inclure dans un audit une portée “audit de configuration” ciblant le socle Windows des serveurs du SI, un système Windows client, l’image master qui permet de déployer tous les serveurs Linux, etc. Cela peut aussi inclure les pare-feu, qui possèdent des fonctionnalités et des paramètres spécifiques à chaque éditeur, les hyperviseurs, mais aussi les solutions applicatives (par exemple : Office 365 et ses nombreux paramètres de sécurité, ou encore GLPI). Bref, tout ce qui contient un paramétrage de sécurité.

L’audit de configuration apparait le plus souvent comme une portée complémentaire à d’autres audits. On parle souvent de défense en profondeur dans la mesure où les faiblesses relevées sont rarement très impactantes prises unes à unes et constituent plutôt des écarts aux guides de bonnes pratiques.

Il faut garder à l’esprit cependant que l’accumulation de ces écarts aux bonnes pratiques ouvre la porte à des vulnérabilités plus importantes ou peuvent faciliter l’exécution de certaines attaques très concrètes. C’est pour cette raison qu’il ne faut pas négliger le paramétrage de sécurité des composants d’un SI, même si unitairement, ils peuvent paraître accessoires.

Pour être plus concret, lors de l’analyse d’un socle système Windows, il va, par exemple, être vérifié que chaque système possède bien un seuil de verrouillage automatique de l’écran au bout de X secondes d’inactivité, que la politique de mot de passe oblige la saisie d’un mot de passe de 14 caractères, que l’IPv6 est bien désactivé si non utilisé, que la signature des échanges SMB est obligatoire, que la taille des journaux d’évènement est bien au-dessus d’une certaine valeur, etc.

Pour vous donner une idée du nombre de paramètres à vérifier, sachez, par exemple, que le guide CIS pour les bonnes pratiques de Windows Server 2022 fait plus de 1000 pages et contient des centaines de points de contrôle ! En voici un (tout petit) extrait  :

Extrait du guide CIS_Microsoft_Windows_Server_2022_Benchmark_v1.0.0

Les auditeurs utilisent des outils de prélèvement et d’analyse automatisés pour détecter les configurations non sécurisées. Ils peuvent également effectuer des tests manuels pour vérifier que les configurations sont conformes aux bonnes pratiques et aux politiques de sécurité de l’organisation. La tâche est souvent ardue, car il existe de nombreux référentiels, parfois contradictoires, mais aussi de nombreuses technologies ou versions d’une technologie. Des outils de prélèvement fonctionnant sur un Windows 10 ne fonctionneront pas tout à fait sur un Windows Server 2022 ou 2016, et pas du tout sur un pare-feu ou une version UNIX exotique.

Dans tous les cas, et vue la complexité de la tâche, il est souvent opté pour une démarche d’échantillonnage qui consiste à prélever un extrait représentatif des composants du SI. Généralement, un défaut de configuration constaté sur un système se retrouvera sur tous les systèmes du même type au sein d’une organisation.

Pour ce qui est des guides et supports, les CIS Benchmark (Center for Internet Security) sont la référence en la matière. Cet organisme fournit gratuitement et maintient grâce à sa communauté des centaines de guides portant sur un très grand nombre de technologies : 

Extrait de la liste des guides CIS.

E. L’audit organisationnel

Moins connu, mais tout aussi important, l’audit organisationnel se concentre sur les aspects humains, procéduraux et managériaux de la sécurité de l’information. Contrairement aux audits techniques qui se concentrent sur les systèmes et les infrastructures, l’audit organisationnel évalue les politiques, les processus, les procédures et les pratiques de gestion de la sécurité au sein d’une organisation. En effet, ces différents éléments sont souvent la source de nombreuses erreurs, négligences et faiblesses persistantes au sein du système d’information.

Les objectifs de l’audit organisationnel sont les suivants :

Évaluer la conformité aux politiques et réglementations : respect des politiques internes de sécurité ainsi que les réglementations externes applicables (RGPD, ISO 27001, NIS, etc.).

Identifier les lacunes dans les processus : détection des faiblesses dans les processus de gestion de la sécurité, tels que la gestion des incidents, la gestion des accès, la sensibilisation à la sécurité, etc.

Évaluer la culture de la sécurité : examiner la sensibilisation et la formation des employés en matière de sécurité, ainsi que leur adhésion aux politiques de sécurité.

Vérifier la gouvernance de la sécurité : évaluer la structure de gouvernance de la sécurité, y compris les rôles et responsabilités des différents acteurs (DSI, RSSI, responsables métiers, etc.).

Lors d’un audit organisationnel, de nombreux points sont vérifiés. Parmi ceux-ci, on trouve, par exemple, l’existence et la mise à jour des politiques de sécurité, les processus de gestion des incidents de sécurité, la formation et la sensibilisation des employés à la sécurité, la gestion des accès et des identités, les plans de continuité d’activité et de reprise après sinistre ou encore la conformité aux réglementations applicables.

Généralement, l’audit organisationnel se déroule de la même façon que l’audit d’architecture. La revue documentaire est la première étape où les auditeurs examinent les politiques, les procédures, les rapports d’incidents, les plans de continuité d’activité et les registres de formation. Ensuite, des entretiens sont menés avec les responsables de la sécurité, les responsables métiers, les employés et d’autres parties prenantes pour comprendre les pratiques réelles et identifier les écarts par rapport aux politiques. Enfin, les pratiques de l’organisation sont comparées aux bonnes pratiques du secteur et aux normes internationales telles que l’ISO 27001.

Voici quelques-uns des outils et référentiels utilisés lors d’un audit organisationnel. 

ISO 27001 : Norme internationale pour les systèmes de management de la sécurité de l’information (SMSI).

RGPD : Règlement général sur la protection des données.

NIS : Directive sur la sécurité des réseaux et des systèmes d’information.

L’audit organisationnel est donc un complément aux audits techniques, car il permet de s’assurer que les aspects humains et managériaux de la sécurité sont bien pris en compte. Ses conclusions et ses recommandations s’appliquent généralement sur le plus long terme au niveau de l’entreprise.

F. Et les autres…

Nous sommes loin d’avoir fait le tour des types d’audit qui existent en cybersécurité. En fonction des besoins et des périmètres, ceux-ci peuvent prendre nombreuses formes.

On peut notamment citer des audits spécifiques pour le Cloud, l’IoT (Internet of things), les systèmes industriels, la sécurité physique, les audits orientés menaces (Red Team), et les audits orientés détection (Purple Team), les campagnes de phishing, etc.

Pour en savoir plus sur les audits Red Team et Purple Team, qui portent notamment sur les capacités de détection des outils et équipes de sécurité et surveillance, je vous oriente vers cet article dédié :

La mise en œuvre d’un audit de sécurité passe par plusieurs phases qu’il ne faut pas négliger, au risque de faire un mauvais usage de son budget et de ne pas atteindre les objectifs fixés.

A. Définir son besoin

Avant de commencer l’audit, il est nécessaire de définir clairement le besoin. Comme nous l’avons vu, la réalisation d’un audit peut répondre à un besoin réglementaire, permettre de mieux orienter son budget sécurité, voir si un système est assez robuste pour passer en production, faire un état des lieux, etc. La définition de ce besoin permettra normalement de commencer à définir le périmètre de l’audit.

B. Dessiner le périmètre de l’audit

Il est également important de savoir bien cadrer le périmètre de l’audit. En sachant que l’audit sera d’autant plus couteux que le périmètre est grand. Pour cela, l’un des meilleurs outils pour cela reste l’analyse de risque. Elle est censée, d’une part, mettre en avant les principaux évènements redoutés d’un périmètre technique ou d’une organisation entière (“qu’est-ce que je crains le plus ?”), mais aussi définir les différents composants critiques et leurs relations techniques ou organisationnelles. Celle-ci peut-être réalisée à l’échelle d’une entreprise, d’un système d’information, d’une agence régionale ou même d’une application. Pour en savoir plus sur cette analyse de risque, je vous oriente vers ce document de l’ANSSI sur la méthodologie EBIOS : 

Pour les audits techniques, il faut également se souvenir de la notion de surface d’attaque, qui est composée de l’ensemble des points d’entrés et d’échange d’un système avec l’extérieur. Cette surface d’attaque deviendra, en fonction des types d’audit, des scénarios simulés en tests d’intrusion, définissant au même titre les prérequis nécessaires. Mais également des points d’attention particuliers lors de l’audit de code source (entrée utilisateur, authentification) de la configuration (système prioritaire, car particulièrement exposé).

Par exemple, un composant évident de la surface d’attaque d’un système d’information sont les adresses IP publiques des serveurs qui exposent des services sur Internet tout en étant hébergés dans le SI. On pense notamment au site web vitrine, au webmail, etc. Mais il ne faut pas négliger la navigation des utilisateurs, les mails, voir les clés USB ou les terminaux mobiles des utilisateurs qui, eux aussi, envoient et réceptionnent des données avec l’extérieur tout en étant connecté au SI. Ces composants sont donc aussi à considérer dans le périmètre de l’audit.

Bref, avant de faire intervenir une équipe d’experts, il faut savoir pourquoi l’on souhaite faire un audit et ce que l’on redoute particulièrement dans le cadre d’une cyberattaque.

Une fois que ce périmètre est défini, il faut déterminer quels sont les types d’audit qui permettraient le mieux d’évaluer la sécurité du périmètre. Certains périmètres ne nécessitent que des audits techniques alors que d’autres, plus complexes et faisant intervenir plus significativement l’humain, doivent inclure une portée organisationnelle. Les prestataires externes capables de réaliser ces audits peuvent ici normalement vous aider à mieux définir les types d’audits pertinents en fonction du périmètre et du besoin..

C. Choisir son prestataire

Sans aller trop dans le détail de cette phase, il faut naturellement choisir le prestataire qui correspond le mieux à votre besoin et votre budget. Dans certains cas spécifiques, la liste des prestataires possibles peut être plus réduite en raison de la nécessité de faire un appel à un prestataire disposant de certains agréments.

Dans d’autres cas, les audits sont réalisés par des équipes de sécurité internes et spécialisées.

D. Définir et préparer les prérequis

Comme nous l’avons vu, chaque type d’audit nécessite des éléments différents pour être réalisé. Cela peut être un simple nom de domaine (test d’intrusion externe avec une composante OSINT), une prise réseau (test d’intrusion interne), un accès au serveur (configuration) ou au code source. Les audits organisationnels et d’architecture utiliseront eux la documentation du SI ainsi que la disponibilité de différents responsables et équipes techniques.

Tous ces éléments sont à définir avec l’équipe d’audit et dépendront aussi du périmètre. L’important concernant les prérequis et qu’ils soient dans un premier temps clairement définis et listés, en accord avec l’équipe d’audit. Puis, mis à disposition de ces derniers pour que tous les éléments à vérifier puissent l’être sans encombre.

Voici, pêle-mêle, des exemples de prérequis qui peuvent être attendus (tout type d’audit confondu) :

Inventaire des actifs informatiques ;

Liste des applications critiques ;

Cartographie du réseau ;

Accès à une prise réseau ;

Comptes sur l’Active Directory ou une application web ;

Identification des données sensibles ;

Définition des rôles métiers ;

Documentation technique ;

Politiques de sécurité existantes ;

Historique des incidents ;

Rapports d’audits précédents ;

Etc.

Cette phase consiste donc à rassembler et préparer toutes les données pertinentes sur votre système informatique. S’en suis naturellement l’exécution de l’audit et de ses différentes portées. On pourrait facilement écrire un livre sur chacune des portées ! Décrire l’ensemble des éléments vérifiés, attendus et des méthodologies de chaque type d’audit serait bien de trop pour cet article ;).

E. (Ré)évaluer les risques et les priorités

Suite au déroulement de l’audit, vous vous retrouverez normalement avec un rapport détaillé des observations et découvertes des auditeurs. Le rapport d’audit contiendra notamment différentes métriques permettant d’évaluer la criticité d’une faiblesse ou d’une non-conformité. Cela peut inclure la gravité, la difficulté et probabilité d’exploitation (pour une vulnérabilité technique), un score CVSS, mais aussi une priorité, et facilité de correction.

Il faut savoir que les auditeurs sont rarement au fait de la composition exacte de votre équipe, des expertises qui la composent, des disponibilités et du budget de chacun. Parfois, certaines faiblesses peuvent aussi être atténuées (ou amplifiées) par des mesures techniques ou organisationnelles de composants hors du périmètre initial de l’audit. Ainsi, il est toujours nécessaire de passer en revue les différentes métriques des vulnérabilités et de les confirmer ou réévaluer à la lumière des informations dont vous disposez. 

Par exemple, une recommandation peut devenir plus simple ou complexe à mettre en place grâce (ou à cause) d’un élément dont l’auditeur externe n’avait pas connaissance. Cette phase est importante puisqu’elle permet d’assurer ou corriger le plan d’action et la criticité de certaines vulnérabilités, qui pourront ensuite être traitées plus efficacement.

F. Faire un suivi régulier des vulnérabilités

Cette phase est certainement la plus longue. Elle consiste à effectuer un suivi régulier des vulnérabilités et non conformité, mais aussi à définir les personnes ou équipes responsables de leur correction. Cela permet de s’assurer que l’audit soit réellement utile, que chaque vulnérabilité et recommandation soit adressée, et d’afficher clairement l’évolution et les bénéfices de la réalisation de l’audit.

Souvent, un simple tableau suffit à faire ce suivi, le plus compliqué étant de mettre en œuvre les recommandations. 

À l’issue d’un audit, des recommandations peuvent être simples à mettre en place. Par exemple : activer une option de sécurité n’ayant pas de risque d’effets de bord, réalisable avec un composant central de gestion de la sécurité comme l’AD. D’autres peuvent être beaucoup plus longues et fastidieuses. Je pense, par exemple, aux recommandations nécessitant une modification de l’organisation ou de l’architecture réseau d’un système d’information, nécessitant l’achat de matériel couteux ou des opérations de migration lourdes. Tout cela pour dire que certains rapports d’audit pourront faire office de plan d’action à suivre pour des mois et des années, d’où l’importance d’effectuer un suivi clair, précis et régulier.

V. Conclusion

Il y aurait encore énormément à dire sur les audits cybersécurité, mais nous avons dans cet article vu le principal. Les enjeux et les intérêts de ces types d’audit sont nombreux et leurs formes également. 

Outre le fait de connaitre leur déroulement et leurs différents composants, le plus important reste de savoir quand et comment les mener en évitant les erreurs fréquentes qui peuvent vous faire rater l’objectif initial de l’audit.

Concernant le métier d’auditeur en cybersécurité dont je pourrais également longuement vous parler, il est passionnant et complexe. Tantôt frustrant, car l’on n’a pas forcément réussi à tout faire ou que l’on dispose de ressources (temps, connaissances) limitées. Tantôt très satisfaisant, car l’on a réussi à mettre le doigt sur une vulnérabilité impactante pour une entité, qu’un attaquant réel aurait pu exploiter pour faire de gros dégâts et qui est corrigée grâce à nous… 

Avant de se lancer, il est important de se rappeler qu’il est plus complet que celui de pentester (orienté surtout sur l’aspect offensif et les tests d’intrusion). Les différentes portées d’un audit deviennent si complexes à maitriser qu’il est à présent fréquent d’avoir des équipes où chaque intervenant est spécialisé dans une portée, l’ensemble permettant alors de réaliser un audit de sécurité complet.

Je vous invite à poursuivre votre lecture à propos des audits de cybersécurité sur cet article dédié aux erreurs à éviter lors de la préparation d’un audit de sécurité :

N’hésitez pas à partager vos avis et questions dans les commentaires de cet article ! Je serai ravi d’y répondre.

Co-fondateur d’IT-Connect.fr.
Auditeur/Pentester chez Orange Cyberdéfense.

Source link