Préparer une vérification utile
Les risques dépendent de la cartographie, des fournisseurs, des usages et de l’évolution des menaces.
Préparer des conditions représentatives, un résultat attendu et une procédure d’arrêt si le test devient perturbant. Conserver le résultat, les écarts et les corrections. Un test réussi sur un cas simple ne couvre pas automatiquement les exceptions ni les autres périmètres.
Exemple fictif : un scénario de vol de données ignore un prestataire qui dispose d’un accès permanent, l’écosystème doit être réintégré.
Une matrice de risque ne remplace pas une compréhension des mécanismes de défaillance ni un test des mesures.
Application à votre contexte
Définissez les préconditions, le scénario, le résultat attendu et le critère d'arrêt. Le test doit être autorisé et organisé sans mettre en danger la production ou les données.
Confrontez la politique à une preuve de fonctionnement : configuration, test autorisé, traitement d'alerte ou exercice. Les tests offensifs doivent rester dans un périmètre expressément autorisé. Une absence de détection n'est pas une preuve d'absence d'incident.
Références pour approfondir
- NIST — NIST Cybersecurity Framework (nouvel onglet) Comprendre ce cadre
- ISO / IEC — ISO/IEC 27001 (nouvel onglet) Comprendre ce cadre
- Center for Internet Security — CIS Controls (nouvel onglet) Comprendre ce cadre
- OWASP — Application Security Verification Standard (nouvel onglet)
- ANSSI — EBIOS Risk Manager (nouvel onglet) Comprendre ce cadre
- DYNAMAP SI — Sécurité des systèmes d’information (nouvel onglet) Comprendre ce cadre