L’audit de securite informatique est une demarche d’evaluation systematique de la securite d’un systeme d’information. Il vise a identifier les vulnerabilites, a evaluer l’efficacite des mesures de protection en place et a formuler des recommandations d’amelioration. Qu’il soit impose par une reglementation ou initie volontairement, l’audit constitue un outil indispensable de la gouvernance de la securite.

Les differents types d’audits de securite

Il n’existe pas un audit de securite unique, mais plusieurs types complementaires, chacun repondant a des objectifs distincts.

Le test d’intrusion (pentest)

Le test d’intrusion consiste a simuler une attaque reelle contre le systeme d’information, dans des conditions controlees, afin d’identifier les vulnerabilites exploitables. Le pentester utilise les memes techniques qu’un attaquant reel : reconnaissance, enumeration, exploitation de failles, elevation de privileges, mouvement lateral.

On distingue plusieurs approches selon le niveau d’information fourni a l’auditeur :

• Test en boite noire (black box) : l’auditeur ne dispose d’aucune information prealable sur le systeme cible. Il simule un attaquant externe sans connaissance interne. Cette approche est la plus realiste mais aussi la plus couteuse en temps.

• Test en boite grise (grey box) : l’auditeur dispose d’informations partielles (comptes utilisateurs, documentation technique partielle). Cette approche simule un attaquant ayant deja un certain niveau d’acces, par exemple un employe malveillant ou un prestataire.

• Test en boite blanche (white box) : l’auditeur dispose de toutes les informations techniques disponibles (architecture, code source, comptes administrateurs). Cette approche permet une couverture maximale et une identification plus exhaustive des vulnerabilites.

Le test d’intrusion peut cibler differents perimettres : infrastructure reseau, applications web, applications mobiles, reseaux sans fil, ingenierie sociale (tests de phishing), securite physique.

L’analyse de vulnerabilites

L’analyse de vulnerabilites (vulnerability assessment) consiste a scanner automatiquement les systemes pour identifier les failles connues : logiciels obsoletes, configurations incorrectes, ports ouverts inutilement, certificats expires, etc. Elle repose sur des outils automatises qui comparent l’etat du systeme a des bases de donnees de vulnerabilites connues (CVE).

Contrairement au pentest, l’analyse de vulnerabilites ne cherche pas a exploiter les failles identifiees. Elle produit un inventaire des vulnerabilites classees par severite, qui sert de base a un plan de remediation priorise.

L’analyse de vulnerabilites est complementaire du test d’intrusion : elle offre une couverture large mais superficielle, tandis que le pentest fournit une evaluation approfondie mais sur un perimetre plus restreint.

L’audit organisationnel

L’audit organisationnel evalue la maturite de l’organisation en matiere de securite au regard d’un referentiel (ISO 27001, guide d’hygiene informatique de l’ANSSI, etc.). Il porte sur les politiques, les procedures, la gouvernance, la sensibilisation, la gestion des risques et la conformite reglementaire.

Cet audit repose principalement sur des entretiens avec les acteurs cles (RSSI, DSI, DPO, responsables metiers), l’examen de la documentation (PSSI, procedures, registres) et l’analyse des preuves d’application des mesures declarees.

L’audit organisationnel est essentiel pour evaluer les aspects humains et processuels de la securite, que les tests techniques ne couvrent pas. Une organisation peut disposer de pare-feu de derniere generation mais avoir des procedures de gestion des acces defaillantes : seul l’audit organisationnel le revelera.

L’audit de code source

L’audit de code source (ou revue de code securite) consiste a analyser le code source d’une application pour y detecter des vulnerabilites : injections SQL, cross-site scripting (XSS), gestion incorrecte de l’authentification, exposition de donnees sensibles, failles de logique metier, etc.

L’audit de code peut etre realise manuellement par des experts ou assistee par des outils d’analyse statique (SAST). L’approche manuelle est plus couteuse mais permet d’identifier des failles de logique metier que les outils automatises ne detectent pas. La combinaison des deux approches est recommandee.

L’audit de configuration

L’audit de configuration verifie que les systemes (serveurs, equipements reseau, bases de donnees, services cloud) sont configures conformement aux bonnes pratiques de securite et aux standards de l’organisation. Il s’appuie sur des referentiels de durcissement (benchmarks CIS, guides de l’ANSSI, recommandations constructeurs).

Le cadre juridique de l’audit de securite

L’autorisation prealable : une obligation incontournable

L’article 323-1 du Code penal sanctionne le fait d’acceder ou de se maintenir, frauduleusement, dans tout ou partie d’un systeme de traitement automatise de donnees. Les peines prevues sont de trois ans d’emprisonnement et 100 000 euros d’amende, portees a cinq ans et 150 000 euros lorsque l’acces entraine une modification ou suppression de donnees ou une alteration du fonctionnement du systeme.

Cette qualification penale s’applique meme en l’absence d’intention malveillante. Un audit de securite, par nature, implique des tentatives d’acces non autorises aux systemes. Sans autorisation ecrite prealable du proprietaire du systeme, un pentest constitue une infraction penale.

L’autorisation doit etre formalisee dans une convention d’audit ou un mandat de test d’intrusion qui precise :

• L’identite du commanditaire et de l’auditeur
• Le perimetre exact des tests autorises (adresses IP, applications, plages horaires)
• Les techniques autorisees et les limites (par exemple, interdiction des tests de deni de service en production)
• La duree de la mission
• Les obligations de confidentialite
• Les modalites de restitution des resultats

Les obligations liees aux donnees personnelles

Lorsque l’audit porte sur des systemes contenant des donnees personnelles, le RGPD s’applique. L’auditeur peut etre amene a acceder a des donnees personnelles dans le cadre de ses tests. Le respect de l’article 32 du RGPD et les principes de minimisation doivent guider la demarche : l’auditeur ne doit acceder qu’aux donnees strictement necessaires a l’evaluation de la securite.

Un contrat de sous-traitance au sens de l’article 28 du RGPD peut etre necessaire si l’auditeur est amene a traiter des donnees personnelles pour le compte du responsable de traitement.

Les exigences NIS2

La directive NIS2 impose aux entites essentielles et importantes d’evaluer regulierement l’efficacite de leurs mesures de gestion des risques en matiere de cybersecurite. L’article 21, paragraphe 2, point f, mentionne explicitement les “politiques et procedures pour evaluer l’efficacite des mesures de gestion des risques en matiere de cybersecurite”.

Les audits de securite constituent le moyen privilegie de satisfaire cette exigence. NIS2 renforce ainsi l’obligation de tester regulierement la securite, au-dela du seul cadre volontaire.

Par ailleurs, les autorites competentes peuvent, en vertu de NIS2, ordonner des audits de securite cibles ou periodiques aupres des entites soumises a la directive.

La qualification PASSI de l’ANSSI

L’ANSSI a mis en place la qualification PASSI (Prestataires d’Audit de la Securite des Systemes d’Information) pour garantir la competence et la fiabilite des prestataires d’audit de securite.

La qualification PASSI couvre cinq portees d’audit :

1. Audit organisationnel et physique
2. Audit d’architecture
3. Audit de configuration
4. Audit de code source
5. Tests d’intrusion

Un prestataire qualifie PASSI a demontre, aupres de l’ANSSI, qu’il dispose des competences techniques, de l’organisation et des processus necessaires pour realiser des audits de securite dans les regles de l’art.

Le recours a un prestataire qualifie PASSI n’est obligatoire que dans certains contextes reglementaires (operateurs d’importance vitale, certaines administrations). Neanmoins, le choix d’un prestataire qualifie constitue un gage de qualite et de serieux appreciable pour toute organisation.

La liste des prestataires qualifies PASSI est publiee sur le site de l’ANSSI et mise a jour regulierement.

Methodologie d’un audit de securite

Phase 1 : Cadrage et preparation

Cette phase est determinante pour le succes de l’audit. Elle comprend :

• La definition du perimetre : quels systemes, quelles applications, quels sites sont couverts par l’audit ? Le perimetre doit etre clairement delimite pour eviter les debordements et maitriser les couts.

• La definition des objectifs : que cherche-t-on a evaluer ? La resistance aux attaques externes ? La securite des applications ? La conformite a un referentiel ? Les objectifs conditionnent le type d’audit a mener.

• La planification : dates, duree, interlocuteurs, conditions d’acces, contraintes operationnelles (periodes de gel, systemes critiques a ne pas perturber).

• La formalisation juridique : convention d’audit, autorisations, clauses de confidentialite.

• La communication interne : selon l’approche retenue, les equipes internes peuvent etre informees ou non de l’audit. Un pentest en conditions reelles implique souvent de ne prevenir que la direction et le RSSI.

Phase 2 : Collecte d’informations

L’auditeur recueille les informations necessaires a la conduite de ses tests : documentation technique, architecture reseau, inventaire des actifs, politiques de securite, resultats des audits precedents. En mode boite noire, cette phase correspond a la reconnaissance externe.

Phase 3 : Realisation des tests

C’est la phase technique de l’audit. L’auditeur execute les tests prevus en respectant strictement le perimetre et les limites definis. Il documente methodiquement chaque test realise, chaque vulnerabilite identifiee et chaque preuve collectee.

Les outils utilises varient selon le type d’audit : scanners de vulnerabilites (Nessus, Qualys, OpenVAS), outils de pentest (Burp Suite, Metasploit, Nmap), outils d’analyse de code (SonarQube, Checkmarx, Semgrep), outils d’audit de configuration (scripts CIS-CAT, Lynis).

Phase 4 : Analyse et redaction du rapport

L’auditeur analyse les resultats, evalue la criticite de chaque vulnerabilite en fonction de son exploitabilite et de son impact potentiel, et redige un rapport structure.

Un rapport d’audit de qualite comprend :

• Un resume executif : synthese des conclusions a destination de la direction, avec une evaluation globale du niveau de securite.
• La methodologie employee : outils, techniques, conditions de realisation.
• Les resultats detailles : chaque vulnerabilite identifiee avec sa description, son niveau de criticite (typiquement CVSS pour les vulnerabilites techniques), la preuve d’exploitation et les recommandations de remediation.
• Un plan de remediation priorise : les actions correctives classees par priorite (critique, haute, moyenne, faible) avec une estimation de la complexite de mise en oeuvre.

Phase 5 : Restitution

L’auditeur presente ses conclusions au commanditaire, idealement lors d’une reunion de restitution permettant d’echanger sur les resultats et de clarifier les recommandations. Deux niveaux de restitution sont souvent necessaires : une presentation synthetique pour la direction et une restitution technique detaillee pour les equipes operationnelles.

Phase 6 : Suivi de la remediation

L’audit ne se termine pas avec la remise du rapport. Un suivi de la remediation doit etre organise pour s’assurer que les vulnerabilites identifiees sont effectivement corrigees. Un contre-audit (ou audit de verification) peut etre realise quelques mois apres pour verifier l’application des recommandations.

Couts et frequence

Couts indicatifs

Les couts d’un audit de securite varient considerablement selon le perimetre, le type d’audit et le prestataire :

Type d’audit	Ordre de grandeur
Test d’intrusion externe (application web)	5 000 - 15 000 EUR
Test d’intrusion interne (reseau d’entreprise)	10 000 - 30 000 EUR
Analyse de vulnerabilites (infrastructure)	3 000 - 10 000 EUR
Audit organisationnel (ISO 27001)	10 000 - 40 000 EUR
Audit de code source	8 000 - 25 000 EUR

Ces fourchettes sont indicatives et dependent fortement de la taille du perimetre et de la qualification du prestataire (un prestataire PASSI sera generalement plus couteux mais offrira un niveau de qualite garanti).

Frequence recommandee

La frequence des audits doit etre adaptee au niveau de risque de l’organisation :

• Tests d’intrusion : au moins une fois par an pour les systemes critiques, et apres chaque modification majeure (mise en production d’une nouvelle application, changement d’architecture).
• Analyses de vulnerabilites : mensuellement ou trimestriellement pour une surveillance continue.
• Audits organisationnels : annuellement dans le cadre d’un SMSI ISO 27001, ou tous les deux a trois ans pour les autres organisations.
• Audits de code : a chaque version majeure d’une application critique, idealement integres dans le cycle de developpement (DevSecOps).

L’audit RGPD est un exercice complementaire qui porte specifiquement sur la conformite des traitements de donnees personnelles. Il peut etre combine avec l’audit de securite pour une approche integree.

L’alignement avec ISO 27001

La norme ISO 27001 exige, dans sa clause 9, la surveillance, la mesure, l’analyse et l’evaluation de la performance du systeme de management de la securite de l’information. Les audits de securite constituent un element central de cette exigence.

Plus specifiquement, la clause 9.2 impose la conduite d’audits internes a intervalles planifies pour verifier que le SMSI est conforme aux exigences de la norme et aux exigences de l’organisation elle-meme. Les audits techniques (pentest, scans de vulnerabilites) completent les audits internes en apportant une evaluation concrete de l’efficacite des mesures de securite.

Conclusion

L’audit de securite informatique est un exercice exigeant qui requiert des competences techniques pointues, une methodologie rigoureuse et un cadre juridique maitrise. Il ne s’agit pas d’une depense ponctuelle mais d’un investissement recurrent dans la securite de l’organisation. Avec les exigences croissantes de NIS2 en matiere d’evaluation de l’efficacite des mesures de securite, les organisations soumises a cette directive doivent integrer l’audit de securite dans leur cycle de gouvernance. Pour les autres, l’audit reste le meilleur moyen de passer d’une securite declarative a une securite demontree.