Que permet de vérifier un audit cybersécurité du SI ?
L’audit donne une vision commune de la sécurité du système d’information avant d’engager des corrections isolées. Nous cherchons en priorité les situations capables de provoquer une compromission de compte, une fuite de données, une interruption de service, une propagation dans le SI ou une perte de capacité à restaurer l’activité.
L’analyse relie les composants entre eux : un compte administrateur, un VPN, une application métier ou une sauvegarde peuvent être correctement configurés séparément et malgré tout créer un risque lorsqu’ils sont combinés.
La restitution doit d’abord distinguer les risques à corriger immédiatement de ceux qui peuvent être planifiés. Elle doit aussi montrer quels systèmes ou accès concentrent le plus d’exposition et quelles actions réduisent le risque le plus rapidement.
Enfin, l’audit doit rendre explicites les chantiers qui nécessitent un budget, un arbitrage d’architecture ou une décision de gouvernance.
Que regardons-nous dans le système d’information ?
Identités, comptes et accès
Nous examinons les comptes administrateurs, la MFA, le SSO, les comptes dormants, les droits trop larges et les accès prestataires. La revue couvre aussi les comptes de service, les clés, les secrets, les arrivées et départs ainsi que la séparation entre utilisateurs et administrateurs.
Nous vérifions qui peut accéder à quoi, avec quel niveau de privilège et depuis quel environnement. L’objectif est notamment d’éviter qu’un compte compromis ou un ancien accès prestataire permette de progresser inutilement dans le SI.
Réseau et exposition externe
Nous vérifions les services exposés sur Internet, les VPN, les accès distants, les pare-feu et la segmentation. Nous rapprochons ces éléments des réseaux utilisateurs, serveurs et administration, des accès entre sites, du DNS et des certificats lorsque le périmètre le justifie.
Nous cartographions les principaux points d’entrée et les chemins permettant de passer d’une zone du SI à une autre. Une exposition utile doit être connue, limitée et surveillée.
Serveurs, postes et systèmes
Nous examinons les systèmes d’exploitation, les versions obsolètes, les correctifs, le durcissement et les services inutiles. La revue peut également couvrir les droits locaux, les postes privilégiés, l’antivirus ou l’EDR, l’annuaire et Active Directory lorsque le périmètre le justifie.
La revue cherche les configurations qui faciliteraient une compromission ou permettraient à une attaque locale de devenir un incident à l’échelle de l’entreprise.
Cloud, hébergement et environnements
Nous regardons les comptes et rôles Cloud, la séparation production/test, le stockage, les secrets, les règles réseau, les consoles d’administration, les journaux, les configurations publiques et les services managés critiques, qu’il s’agisse d’AWS, Azure, GCP ou d’un autre hébergeur.
Nous regardons particulièrement les droits d’administration, les ressources exposées et les écarts entre ce que l’équipe pense avoir configuré et ce qui est réellement accessible. Le cloud reste une partie de l’audit SI global, pas un audit AWS ou Azure isolé.
Applications et données critiques
Nous relions les applications critiques et leurs données : ERP, CRM, applications métier, SaaS, API, bases de données, comptes techniques, échanges, dépendances, interfaces d’administration et intégrations externes.
L’objectif n’est pas de refaire ici l’audit complet du code de chaque application. Nous vérifions surtout la manière dont les applications critiques s’intègrent au SI, les accès qu’elles ouvrent et les données qu’elles exposent. Un audit dédié d’une application web peut compléter cette lecture lorsqu’un composant précis le justifie.
Sauvegardes, supervision et continuité
Nous vérifions les sauvegardes et leur restauration, leur séparation, leur rétention et leurs accès. Nous regardons aussi les logs, les alertes, la supervision, les procédures d’incident, la capacité de reprise et les dépendances critiques.
Une sauvegarde n’est utile que si elle peut réellement être restaurée. Nous vérifions donc autant la capacité de reprise que l’existence des mécanismes de sauvegarde.
Audit SI, scan de vulnérabilités ou pentest : quelle différence ?
Un scan détecte automatiquement certaines vulnérabilités connues. Un pentest cherche à exploiter un périmètre défini pour vérifier jusqu’où un attaquant pourrait aller.
Un audit cybersécurité du SI est plus transverse : il croise architecture, configurations, accès, exposition, sauvegardes, systèmes et organisation technique afin d’identifier les scénarios de risque les plus importants. Un pentest peut être recommandé sur un périmètre précis lorsque l’audit montre qu’une exposition mérite d’être testée plus profondément.
Comment se déroule l’audit ?
01 — Cadrage du périmètre
Un échange de 45 à 60 minutes avec la direction, la DSI ou le responsable IT définit les sites, environnements, applications critiques, prestataires, données sensibles, contraintes métier et incidents récents éventuels. Le périmètre doit être assez large pour comprendre les dépendances critiques, mais assez précis pour produire des conclusions exploitables.
02 — Collecte des accès et de la documentation
Selon le périmètre, nous réunissons inventaire, architecture, comptes de lecture, configurations, documentation réseau, consoles cloud, politiques de sauvegarde, journaux, outils de supervision et informations des prestataires. Les accès en lecture sont privilégiés lorsque cela permet d’obtenir les informations nécessaires.
03 — Entretiens ciblés
Les échanges réunissent généralement le DSI ou responsable IT, l’infrastructure ou le cloud, les responsables des applications critiques et, si nécessaire, l’infogérance. Pour un périmètre classique, 2 à 4 échanges techniques ciblés suffisent généralement ; la direction intervient surtout au cadrage et à la restitution.
04 — Analyse et vérifications
Nous croisons ce qui est documenté avec ce qui est réellement configuré. Un point n’est pas classé uniquement parce qu’un outil génère une alerte : nous cherchons à comprendre son exposition, les droits nécessaires pour l’exploiter et ses conséquences possibles pour le SI.
Les risques sont classés selon l’impact, la probabilité, l’exposition, la difficulté de correction et les dépendances métier.
05 — Restitution et plan de remédiation
Une restitution de 60 à 90 minutes avec la direction et l’équipe technique présente les risques critiques, les preuves utiles, les quick wins, les chantiers structurants et l’ordre recommandé des corrections.
Combien de temps dure un audit cybersécurité du SI ?
Un audit transverse sur un SI de taille PME ou ETI prend généralement autour de 10 à 15 jours ouvrés d’intervention, répartis sur deux à quatre semaines calendaires selon la disponibilité des équipes et des accès.
Le délai augmente notamment avec plusieurs sites, plusieurs environnements cloud, un Active Directory important, de nombreuses applications critiques, plusieurs prestataires, un périmètre de test offensif ou une documentation incomplète. Le périmètre est défini avant le démarrage afin d’éviter un audit qui s’étend sans produire davantage de valeur.
Que recevez-vous à la fin de l’audit ?
Synthèse direction
Un document court pour comprendre les principaux scénarios de risque, leur impact métier, les décisions à prendre et les priorités immédiates.
Cartographie des risques
Pour chaque point significatif : composant concerné, risque, conséquence possible, niveau de priorité, preuve utile et recommandation.
Plan de remédiation
Immédiat : traiter les risques critiques et les quick wins. À 30 jours : réaliser les corrections prioritaires. À 60 jours : reprendre les accès, configurations ou éléments d’architecture concernés. À 90 jours et plus : engager les chantiers structurants.
Backlog exploitable par les équipes
Les recommandations sont transformées en actions avec responsable, priorité, dépendance et niveau d’effort indicatif.
Restitution technique
La direction comprend les décisions à prendre et les équipes techniques comprennent ce qu’elles doivent corriger. Le rapport ne se limite pas à des captures de scanners de vulnérabilités.
Que se passe-t-il après l’audit ?
L’audit peut rester indépendant de la remédiation. Si Koragence poursuit l’intervention, nous reprenons le backlog par priorité : accès, durcissement, réseau, cloud, secrets, sauvegardes, monitoring ou corrections applicatives selon les constats.
Les corrections peuvent être regroupées en chantiers courts ou intégrées à une roadmap plus large lorsque plusieurs composants du SI doivent évoluer ensemble. La sécurisation des accès et du cloud ou la sécurisation et exploitation de l’infrastructure peuvent alors constituer les suites naturelles de l’audit.
Quand lancer un audit cybersécurité du système d’information ?
La mission s’adresse aux PME structurées et aux ETI qui disposent déjà d’une équipe IT, de plusieurs outils, de données ou applications critiques, de cloud, de prestataires ou de plusieurs sites.
L’audit est particulièrement pertinent avant une transformation importante, une ouverture à de nouveaux partenaires, un changement de DSI, de prestataire ou d’équipe technique. Il devient également utile après plusieurs années d’accumulation d’outils, lorsqu’aucune cartographie claire des accès n’existe, lorsque des environnements cloud et on-premise coexistent ou lorsqu’un incident, une alerte, une demande client ou un investissement de sécurisation impose des garanties concrètes.
