Tester son système de sécurité informatique face à une intrusion consiste à vérifier, dans un cadre autorisé, si une attaque peut être bloquée, détectée puis contenue et si l’activité peut reprendre. Un scan de vulnérabilités ne suffit pas : il faut aussi éprouver les alertes, les décisions des équipes et la restauration des services. Le résultat attendu est un ensemble de preuves permettant de corriger les faiblesses qui exposent réellement votre organisation.
Tester la résistance de votre SI à une intrusion contrôlée
Un dispositif de sécurité associe des technologies, des procédures et des personnes. Pare-feu, gestion des identités, protection des postes, supervision et sauvegardes doivent fonctionner ensemble. La présence de ces outils ne prouve pas leur efficacité face à un scénario concret.
Pour une PME ou une collectivité, la question est opérationnelle : un compte compromis peut-il conduire à l’arrêt de la facturation, à l’indisponibilité d’un service public ou à l’accès aux sauvegardes ? Le test doit apporter une réponse vérifiable, sans provoquer lui-même l’incident que l’on cherche à prévenir.
Quel type de test choisir ?
Le choix dépend de ce que vous souhaitez démontrer. Pour évaluer un système de sécurité informatique, il faut distinguer la recherche de faiblesses, la validation d’un chemin d’intrusion et l’exercice de gestion d’incident.
| Approche | Question traitée | Limite à connaître |
|---|---|---|
| Scan de vulnérabilités | Quelles faiblesses techniques connues sont repérables sur le périmètre analysé ? | Ne démontre pas, à lui seul, leur exploitation ni la réaction des équipes |
| Test d’intrusion, ou pentest | Un intervenant autorisé peut-il franchir certaines protections et atteindre un objectif défini ? | Résultat limité au périmètre, au temps disponible et aux conditions du test |
| Simulation d’incident technique | Les alertes, l’escalade et le confinement fonctionnent-ils ? | Ne remplace pas une recherche approfondie de vulnérabilités |
| Exercice de crise sur table | La direction et les équipes savent-elles décider et coordonner la réponse ? | N’éprouve pas directement les protections techniques |
| Test de restauration | Peut-on rétablir un service et ses données dans les objectifs prévus ? | Ne valide pas la prévention d’une intrusion |
Ces approches sont complémentaires. Notre article sur les étapes et livrables d’un audit de sécurité permet de situer ces tests dans une évaluation plus large du SI.
1. Définir un périmètre autorisé et maîtrisé
Avant toute intervention, formalisez une autorisation écrite et des règles d’engagement. Tester un système de sécurité informatique ne donne pas carte blanche sur les applications d’un partenaire, les services d’un opérateur ou l’infrastructure d’un hébergeur.
Le cadrage doit préciser les actifs concernés, les propriétaires des ressources et les opérations permises. Pour les services cloud ou mutualisés, vérifiez les conditions contractuelles et les autorisations éventuellement nécessaires.
Le document de préparation doit notamment fixer :
- Le périmètre technique et métier : sites, comptes, applications, adresses réseau et services critiques concernés.
- Les exclusions : équipements sensibles, environnements industriels, traitements destructifs et données à ne pas manipuler.
- Les conditions d’intervention : créneaux, comptes de test, accès accordés et limites de charge.
- Les règles d’arrêt : dégradation de service, comportement imprévu ou suspicion d’une attaque réelle.
- Les responsabilités : pilote habilité, contacts d’urgence et personnes autorisées à décider d’un confinement.
- Le traitement des preuves : collecte minimale, stockage sécurisé, accès restreint et suppression convenue.
Le guide NIST SP 800-115 fournit un cadre méthodologique pour préparer et conduire des évaluations techniques de sécurité.
En production, privilégiez les actions non destructives et les données fictives. Une sauvegarde préalable ne rend pas une manipulation risquée acceptable : sa restauration peut elle-même demander du temps et interrompre l’activité.
2. Choisir des scénarios d’intrusion liés à vos métiers
Un scénario utile part d’un événement plausible et vise une conséquence métier précise. Votre système de sécurité informatique doit être évalué sur sa capacité à limiter cette conséquence, pas uniquement sur le nombre d’alertes générées.
Choisissez quelques situations prioritaires à partir des accès réellement utilisés : télétravail, messagerie, administration distante, échanges entre sites ou accès des prestataires. Il vaut mieux vérifier complètement trois parcours critiques que multiplier les essais sans analyser leurs résultats.
Les contrôles à mettre à l’épreuve
| Scénario encadré | Contrôles à vérifier | Preuves attendues |
|---|---|---|
| Utilisation d’un compte de test depuis un contexte inhabituel | Authentification multifacteur, restrictions d’accès et journalisation | Accès refusé ou soumis à une vérification, événement exploitable |
| Simulation d’une activité suspecte sur un poste de test | Protection du poste et EDR, outil de détection et de réponse sur les terminaux | Alerte contextualisée et action de réponse vérifiée |
| Tentative autorisée de passage entre deux zones réseau | Segmentation et filtrage des flux | Flux interdit effectivement bloqué et trace disponible au point prévu |
| Accès d’un compte utilisateur à une ressource sensible fictive | Droits d’accès et séparation des privilèges | Refus conforme aux règles définies |
| Indisponibilité simulée d’un service critique | Escalade, procédures de crise et solutions de repli | Décision tracée et procédure applicable |
| Restauration d’un service dans un environnement isolé | Sauvegardes, dépendances et accès d’administration | Service fonctionnel et données contrôlées |
Les scénarios peuvent être rapprochés des techniques documentées dans MITRE ATT&CK. Ce référentiel aide à décrire les comportements à observer, mais ne constitue pas un certificat de couverture complète.
Exemple : un compte compromis sur un site distant
Prenons une entreprise disposant de bureaux en Martinique et en Guadeloupe. Le scénario retenu est l’utilisation abusive d’un compte de test sur un site secondaire, avec pour objectif fictif d’atteindre un partage administratif du siège.
L’évaluation du système de sécurité informatique doit vérifier plusieurs barrières : droits du compte, séparation des réseaux, visibilité des connexions puis capacité à couper l’accès sans bloquer tous les utilisateurs. Utilisez une ressource factice pour démontrer le risque, sans consulter de documents confidentiels.
Les résultats peuvent révéler une faiblesse d’architecture plutôt qu’un défaut d’antivirus. Les principes permettant de renforcer le réseau sans complexifier le SI deviennent alors un levier de correction concret.
3. Mesurer la réaction du système de sécurité informatique
Une intrusion simulée n’est pas correctement gérée parce qu’un événement figure dans un journal. Il faut vérifier qu’il devient une alerte compréhensible, qu’une personne la prend en charge et qu’une décision adaptée suit.
Consignez une chronologie commune : début de l’action de test, génération de l’alerte, qualification, notification puis confinement. Les horloges des équipements doivent être synchronisées pour rendre cette chronologie exploitable.
Mesurez séparément le délai de détection et le délai de prise en charge. Une alerte immédiate laissée sans traitement pendant plusieurs heures ne répond pas au même problème qu’une absence de détection.
Vérifiez aussi le contenu transmis : compte concerné, équipement, site, comportement observé et action recommandée. Si un SOC managé intervient, examinez la chaîne complète jusqu’au décideur habilité, y compris hors des horaires habituels lorsque cette couverture est prévue au contrat.
Enfin, testez le confinement : qui peut suspendre un compte, isoler un poste ou fermer un accès distant ? La mesure doit être techniquement réalisable et proportionnée à l’impact métier. Un blocage généralisé peut aggraver l’interruption de service.
4. Vérifier la reprise après l’incident
Le système de sécurité informatique doit aussi permettre de reprendre l’activité lorsque les protections initiales ont été contournées. La présence d’une sauvegarde réussie ne démontre pas qu’une application peut redémarrer avec des données utilisables.
Définissez deux objectifs avant l’exercice. Le RTO correspond à l’objectif de délai de rétablissement du service. Le RPO correspond à la perte de données maximale acceptable, exprimée en durée. Ces objectifs se fixent avec les métiers, selon les conséquences d’une interruption.
Restaurez ensuite un service représentatif dans un environnement isolé. Vérifiez ses dépendances : annuaire, résolution de noms, bases de données, licences et accès réseau. Faites valider le fonctionnement par un utilisateur métier, pas seulement par l’équipe technique.
Contrôlez également que les comptes compromis dans le scénario ne permettraient pas de supprimer les copies de sauvegarde. Les identités d’administration, la séparation des accès et la protection des copies font partie du test.
Aux Antilles-Guyane, intégrez les conditions locales pertinentes : indisponibilité d’un lien intersite, accès dégradé au cloud ou impossibilité temporaire d’intervention sur place. Le plan de reprise doit rester praticable dans ces situations, avec des responsabilités connues et une procédure accessible même si le SI principal est indisponible.
5. Prioriser les corrections et refaire les tests
Le rapport doit distinguer une faiblesse observée, son effet démontré et les limites de l’évaluation. Un chemin d’intrusion possible n’a pas la même portée selon les privilèges obtenus, les données accessibles et les services susceptibles d’être interrompus.
Pour chaque défaut du système de sécurité informatique, demandez une preuve, une conséquence métier, une correction proposée et un responsable de traitement. Les éléments sensibles du rapport doivent être protégés : ils peuvent décrire précisément les faiblesses de l’organisation.
Priorisez selon l’exposition, la facilité d’exploitation constatée et l’impact potentiel. Une possibilité d’accès non autorisé aux sauvegardes peut demander une action plus urgente qu’une faiblesse isolée sur un équipement peu critique.
Pour un dirigeant ou une DAF, le plan d’action doit rendre visibles les arbitrages : correction de configuration, évolution d’architecture, modification d’un contrat de support ou investissement complémentaire. Une mesure compensatoire peut réduire temporairement le risque, sans remplacer la correction définitive.
La correction n’est validée qu’après un nouveau contrôle. Le contre-test doit confirmer que le scénario ne fonctionne plus, sans créer de régression pour les utilisateurs. Conservez les preuves de clôture et le risque résiduel accepté par la personne habilitée.
Quand tester et comment choisir l’intervenant ?
Programmez les évaluations selon la criticité de vos services et l’évolution de votre SI. Un calendrier périodique est utile, mais il ne remplace pas un test après une migration cloud, une modification des accès distants, une interconnexion de sites ou un incident significatif.
Le périmètre du système de sécurité informatique change avec les usages. Un nouveau prestataire disposant d’un accès d’administration ou une application ouverte sur Internet peut justifier un contrôle ciblé, sans attendre une campagne générale.
Pour choisir l’intervenant, examinez sa méthode, son expérience sur des environnements comparables et sa capacité à limiter l’impact sur la production. Demandez un exemple anonymisé de livrable, les modalités de protection des preuves et les conditions du contre-test.
Distinguez aussi la réalisation du test et la correction des défauts. Les responsabilités doivent être explicites, notamment si plusieurs prestataires gèrent le réseau, les applications et l’hébergement. Pour une organisation multisite, vérifiez les modalités de coordination locale, les créneaux d’intervention et la chaîne d’escalade réellement prévue.
Questions fréquentes
Un scan de vulnérabilités suffit-il pour évaluer la résistance à une intrusion ? Non. Il repère certaines faiblesses techniques, mais ne valide pas à lui seul les chemins d’intrusion, la réaction des équipes ou la restauration. Il constitue une composante de l’évaluation.
Peut-on tester sans interrompre l’activité ? Le cadrage, les comptes de test et les simulations non destructives réduisent le risque. Ils ne permettent pas de garantir l’absence d’incident. Les actions sensibles doivent être exclues, isolées ou réalisées dans un créneau convenu.
Faut-il prévenir son hébergeur ou son fournisseur cloud ? Vérifiez les conditions applicables avant le test. Certaines opérations sont autorisées sous conditions, d’autres nécessitent un accord préalable ou sont interdites. L’autorisation de votre entreprise ne couvre pas automatiquement les infrastructures tierces.
Un système de sécurité informatique ayant réussi les tests est-il totalement sûr ? Non. Le résultat concerne des scénarios, un périmètre et une période donnés. Il réduit l’incertitude sur certains risques, sans exclure d’autres vulnérabilités ni les évolutions futures du SI.
Que faire si une intrusion réelle est découverte pendant l’exercice ? Suspendez les actions de test et déclenchez la procédure de réponse à incident. Préservez les traces, informez le responsable habilité et coordonnez les mesures de confinement. Évitez les manipulations improvisées qui pourraient détruire des preuves.
Définir une évaluation adaptée avec AITEC
AITEC accompagne les entreprises et collectivités de Martinique, Guadeloupe et Guyane en audit, conseil, cybersécurité, infogérance et continuité d’activité. Cette approche permet de relier les constats techniques aux corrections, à la supervision et à l’exploitation quotidienne du SI.
Pour préparer votre évaluation, rassemblez la liste de vos services critiques, vos accès externes, vos contrats de support et les résultats de vos derniers tests de restauration. Échangez avec un expert AITEC pour définir les priorités, les intervenants nécessaires et un périmètre de contrôle compatible avec votre activité.
