Points clés à retenir
- La résilience dépend de la rapidité et de la confiance avec lesquelles l’entreprise est capable de se remettre sur pied – et pas uniquement de sa capacité à se prémunir contre toutes les menaces.
- Transformez les plans de Recovery en preuves concrètes : des résultats validés par des tests sont plus crédibles aux yeux des conseils d’administration, des autorités de régulation et des assureurs que de simples objectifs ou hypothèses.
- Faites des ResOps un modèle opérationnel partagé entre les responsables de la sécurité, de l’infrastructure, de la continuité des activités et des services.
- Mesurez ce qui compte : les équipes doivent savoir si les services critiques peuvent être rétablis, combien de temps la Recovery prend réellement et si elles sont en mesure de le prouver.
- Sélectionnez un ou deux services critiques, définissez ce qu’est une Recovery réussie, menez un exercice sans complaisance et consignez les résultats.
- Vingt ans passés à la tête d’une équipe de sécurité vous apprennent très tôt une chose : l’attaque que vous avez stoppée ne fait jamais l’objet d’une discussion au conseil d’administration. Celle que vous n’avez pas réussi à contrer est la seule dont tout le monde se souvient. À un moment donné, j’ai cessé d’évaluer mon équipe uniquement en fonction du nombre d’attaques que nous avions subies et j’ai commencé à la juger également sur la rapidité avec laquelle nous nous remettions sur pied.
- C’est pourquoi je souhaite que tous les RSSI, DSI et membres de conseil d’administration que je connais lisent le nouveau rapport O’Reilly, « ResOps : An Executive Guide », publié cette semaine. Commvault l’a parrainé, mais je le recommanderais de toute façon.
Le mur n’a jamais été le seul objectif
Pendant la majeure partie de ma carrière, mon travail a consisté à ériger des remparts plus hauts : une meilleure détection, des contrôles plus stricts, une réponse plus rapide. Ce travail reste important, et le restera toujours. Mais un rempart ne répond qu’à une seule question, et ce n’est plus celle que pose votre conseil d’administration.
En septembre dernier, une attaque par ransomware a contraint Jaguar Land Rover à interrompre sa production mondiale. Les chaînes de montage se sont arrêtées. Les chaînes d’approvisionnement se sont figées. Le Cyber Monitoring Centre britannique a estimé le coût pour l’économie dans son ensemble à environ 1,9 milliard de livres sterling, et JLR a enregistré son plus faible volume de production mensuel en 73 ans. JLR disposait de défenses. Ce que cet incident a mis à l’épreuve, ce n’était pas la solidité du mur, mais la capacité de l’entreprise à se remettre sur pied une fois que celui-ci avait cédé.
Je l’ai déjà dit et je continuerai à le dire : la question n’est pas de savoir si une perturbation se produira, mais quand elle se produira. Les RSSI qui dorment sur leurs deux oreilles ne sont pas ceux qui croient pouvoir tout empêcher ; ce sont ceux qui se sont entraînés à se remettre sur pied tant de fois que cet entraînement lui-même est source de confiance.
Trois questions que je pose à ma propre équipe
Le rapport structure l’ensemble du problème en trois questions, et j’ai pris l’habitude de commencer chaque évaluation de résilience par celles-ci :
- Si nous étions touchés ce soir, pourrions-nous nous remettre sur pied ?
- Combien de temps cela prendrait-il réellement ?
- Pouvons-nous le prouver, avec des éléments concrets, au conseil d’administration ?
La plupart des organisations répondent aux deux premières questions en présentant un plan, et à la troisième par le silence. Ce silence correspond au déficit de résilience, et il est plus important et plus coûteux que ne le réalisent la plupart des dirigeants.
Des preuves, pas des promesses
Voici une distinction que le rapport met en avant mieux que je ne l’ai jamais entendue ailleurs : un objectif de délai de reprise (RTO) est une cible. Il vous indique ce que vous visez, mais il ne vous dit pas si vous l’atteindrez.
Comparez « nous pensons pouvoir rétablir le service de paiement en quatre heures » à « nous l’avons rétabli en 3,2 heures au trimestre dernier, à partir d’un point de reprise vérifié et sain, avec une tolérance de quatre heures ». La première phrase est un projet. La seconde est une preuve. Seule l’une de ces deux affirmations tiendra la route lorsque votre conseil d’administration, votre autorité de régulation ou votre assureur cyber commenceront à poser des questions plus pointues, ce qu’ils ne manqueront pas de faire.
Le rapport qualifie cette discipline de « ResOps », abréviation de « resilience operations » (opérations de résilience). Il ne s’agit ni d’un produit que l’on achète, ni d’un dossier que l’on classe. C’est un modèle opérationnel qui relie la sécurité, l’infrastructure, la continuité des activités et les responsables métier qui dépendent de ces services, tous travaillant à partir des mêmes données factuelles plutôt que de plans distincts.
Ce qui devrait inquiéter tous les RSSI
Le rapport met également en lumière un phénomène que je ressens depuis un certain temps et pour lequel j’ai enfin trouvé les mots : le paradoxe de l’IA. La même capacité de l’IA qui nous aide à détecter plus rapidement les vulnérabilités aide les attaquants à combler le fossé entre la découverte et l’exploitation tout aussi rapidement, voire plus vite. Détecter davantage de problèmes ne renforce pas votre sécurité si vous ne pouvez pas vous remettre de ceux qui parviennent à passer entre les mailles du filet. La vitesse de détection n’a jamais été la ligne d’arrivée. C’est la capacité de Recovery qui l’est.
Commencez par un seul service
Rien de tout cela ne nécessite de tout changer d’un seul coup, et je mentirais si je disais que ma propre équipe a réussi du premier coup. Le rapport propose un parcours de 90 jours : choisissez un ou deux de vos services les plus critiques, définissez ce que « remise en état » signifie réellement pour chacun d’entre eux, menez un exercice de Recovery sérieux et produisez votre première preuve concrète. C’est un projet que n’importe quelle équipe peut lancer ce trimestre, y compris la mienne.
Des preuves plutôt que des promesses. Readiness plutôt que la perfection. C’est la norme que j’impose à mon équipe, et c’est celle vers laquelle ce rapport vous indique une voie concrète.
Procurez-vous votre exemplaire de « ResOps : An Executive Guide » ici.
FAQ
Q : Qu’est-ce que ResOps ?
R : ResOps, abréviation de « resilience operations » (opérations de résilience), est un modèle opérationnel qui rassemble les responsables de la sécurité, de l’infrastructure, de la continuité d’activité et des services autour de pratiques de reprise partagées et fondées sur des preuves.
Q : En quoi ResOps diffère-t-il de la reprise après sinistre traditionnelle ?
R : La reprise après sinistre traditionnelle est souvent axée sur des plans et des objectifs techniques. ResOps met l’accent sur la validation continue, la responsabilité interfonctionnelle et la preuve mesurable que les services critiques peuvent être rétablis dans les limites de tolérance de l’entreprise.
Q : Pourquoi les preuves de Recovery sont-elles importantes ?
R : Les preuves de Recovery montrent ce qu’une organisation a réellement testé et réalisé. Elles contribuent à donner aux conseils d’administration, aux autorités de régulation, aux assureurs et aux dirigeants d’entreprise une plus grande confiance que ne le font les plans ou les objectifs de Recovery à eux seuls.
Q : Que doivent mesurer les organisations dans le cadre d’un programme ResOps ?
R : Les organisations doivent évaluer si les services critiques peuvent être rétablis, combien de temps la reprise prend réellement, si les points de reprise sont intacts et vérifiés, et si les résultats respectent les tolérances opérationnelles définies.
Q : Qui devrait être impliqué dans les ResOps ?
R : Le programme ResOps doit réunir les responsables de la sécurité, de l’infrastructure, de la continuité des activités, des applications et des services, ainsi que les dirigeants concernés, afin que les priorités et les preuves de Recovery reflètent les besoins de l’entreprise.
Q : Comment une entreprise peut-elle se lancer dans les ResOps ?
R : Commencez par un ou deux services critiques. Définissez ce que signifie une reprise réussie, menez un exercice de Recovery en toute transparence, documentez les résultats et utilisez ces données pour améliorer le prochain test.
Bill O’Connell est directeur de la sécurité chez Commvault.
