Préparer une vérification utile
La politique dépend de la stratégie, des obligations, des actifs et des capacités opérationnelles.
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 : une règle impose une revue des accès mais aucun responsable n’a le temps de la réaliser, le dispositif doit être organisé et financé.
Le RSSI ne doit pas devenir le seul propriétaire de tous les risques. Les responsables métier conservent leurs arbitrages.
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)
- DYNAMAP SI — Sécurité des systèmes d’information (nouvel onglet) Comprendre ce cadre