De la prévention à la résilience
La cybersécurité s’est longtemps concentrée sur la prévention des incidents. Mais la réalité est que les incidents vont se produire — la question est de savoir à quel point vous pouvez bien les gérer.
La résilience opérationnelle consiste à construire la capacité de l’organisation à absorber les perturbations, s’adapter et continuer à délivrer. C’est un changement de paradigme de « ça ne nous arrivera pas » à « quand ça arrive, nous sommes prêts ».
La question fondamentale : Si votre système le plus important tombe demain — à quelle vitesse pouvez-vous récupérer ? Et le savez-vous avec certitude, ou ne faites-vous que le supposer ?
Les quatre piliers de la résilience
1. Continuité d’activité (PCA) Plans pour maintenir les processus métier critiques lors de perturbations. Qu’est-ce qui est critique ? Comment continuons-nous si X ne fonctionne pas ?
2. Reprise après sinistre (PRA) Plans techniques pour restaurer les systèmes IT et les données. Sauvegarde, redondance, procédures de restauration.
3. Gestion d’incident Processus pour détecter, gérer et apprendre des incidents de sécurité. Rôles, escalade, communication.
4. Communication de crise Comment communiquons-nous en interne et en externe lors d’une crise ? Qui dit quoi à qui ?
Exigences NIS2 sur la résilience
L'Article 21.2c de NIS2 exige la continuité d'activité et la gestion de crise, incluant la sauvegarde et la reprise après sinistre.
L'Article 21.2b exige la gestion des incidents de sécurité, incluant la déclaration sous 24 heures à l'ANSSI.
Exigence implicite que les plans doivent fonctionner en pratique. Les processus non testés sont peu fiables.
Les mesures doivent être proportionnelles au risque. Les systèmes critiques nécessitent une résilience plus robuste.
Construire la résilience étape par étape
- Identifier les processus et systèmes critiques Qu'est-ce qui doit fonctionner pour que l'activité survive ? Cartographier les dépendances. Prioriser basé sur l'impact métier en cas d'indisponibilité.
- Définir RTO et RPO À quelle vitesse chaque processus/système critique doit-il être restauré (RTO) ? Quelle perte de données est acceptable (RPO) ? Ceci guide la conception des solutions.
- Implémenter la capacité technique Sauvegarde, réplication, redondance, basculement. S'assurer que la technologie peut délivrer selon RTO/RPO. Documenter les procédures de restauration.
- Créer plans et procédures Plan de continuité d'activité, plan PRA, plan d'incident, plan de communication de crise. Rôles clairs, responsabilités et voies d'escalade.
- Tester et exercer Les plans non testés fonctionnent rarement. Conduire des exercices : sur table, tests techniques, simulations à grande échelle. Apprendre des résultats.
- Améliorer continuellement Mettre à jour les plans basé sur les leçons apprises, les changements dans l'activité et les nouvelles menaces. La résilience est un processus, pas un projet.
Types d’exercices
| Type | Description | Fréquence |
|---|---|---|
| Sur table | Exercice de discussion sans activation technique. « Que faisons-nous si X arrive ? » | Trimestriel |
| Déroulé | Parcours étape par étape des procédures. Identifier les lacunes. | Semestriel |
| Fonctionnel | Tester une capacité spécifique, ex. restauration de sauvegarde | Mensuel |
| Grande échelle | Simuler un incident réel. Activer tous les processus. | Annuel |
Défaillances communes
Le document existe, mais personne ne sait s'il fonctionne. 73% qui testent trouvent des défaillances.
Le plan référence des systèmes qui n'existent plus, ou manque de nouveaux systèmes critiques.
Plan PRA existe, mais pas de plan de continuité d'activité. L'IT peut restaurer, mais l'activité ne sait pas quoi faire.
La technologie fonctionne, mais personne ne sait comment communiquer avec clients, médias, autorités.
Dépendances critiques sur des personnes clés, systèmes uniques ou fournisseurs.
Les sauvegardes sont prises, mais personne n'a testé la restauration. « La sauvegarde de Schrödinger. »
Liste de contrôle pour la résilience
Identification :
- Processus métier critiques identifiés
- Systèmes critiques cartographiés
- Dépendances documentées
- RTO et RPO définis
Capacité technique :
- Stratégie de sauvegarde implémentée
- Restauration testée et vérifiée
- Redondance pour systèmes critiques
- Mécanismes de basculement en place
Plans et processus :
- Plan de continuité d’activité documenté
- Plan PRA documenté
- Plan de gestion d’incident documenté
- Plan de communication de crise documenté
Test et exercice :
- Exercice sur table conduit le dernier trimestre
- Test PRA technique conduit le dernier semestre
- Exercice à grande échelle conduit la dernière année
- Leçons apprises documentées et plans mis à jour
Comment Securapilot peut aider
Securapilot soutient le travail de résilience de l’organisation :
- Continuité d’activité — Documenter et gérer le PCA
- Gestion d’incident — Gestion structurée et déclaration à l’ANSSI
- Gestion des risques — Identifier les menaces à la résilience
- Documentation — Plans et procédures en un seul endroit
- Suivi — Tracer exercices et actions d’amélioration
Réserver une démo et voir comment nous pouvons soutenir votre capacité de résilience.
Questions fréquentes
Quelle est la différence entre résilience et sauvegarde ?
La sauvegarde est une mesure technique pour restaurer les données. La résilience est la capacité de l'organisation à continuer de fonctionner malgré les perturbations. La sauvegarde fait partie de la résilience, mais n'en est qu'une composante.
Comment la résilience s'articule-t-elle avec NIS2 ?
L'Article 21 de NIS2 exige explicitement la continuité d'activité et la gestion de crise. Les organisations doivent pouvoir maintenir ou restaurer les services critiques lors de perturbations.
À quelle fréquence devons-nous tester notre résilience ?
Au minimum annuellement pour la continuité d'activité globale. La restauration de sauvegarde et PRA technique plus souvent. Exercices d'incident 1-2 fois par an. Les exercices sur table peuvent être trimestriels.
Que sont RTO et RPO ?
RTO (Recovery Time Objective) est le temps maximal acceptable pour restaurer un service. RPO (Recovery Point Objective) est la perte de données maximale acceptable, mesurée en temps. Exemple : RTO 4 heures, RPO 1 heure.
