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 non 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é d’activité et des services.
- Mesurez ce qui compte : les équipes doivent savoir si les services critiques peuvent être rétablis, combien de temps dure réellement la Recovery et si elles sont en mesure de le prouver.
- Sélectionnez un ou deux services essentiels, définissez ce qu’est une Recovery réussie, menez un exercice en toute honnêteté 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 j’espère que tous les RSSI, DSI et membres de conseil d’administration que je connais liront ce nouvel ouvrage, *ResOps : Guide à l’intention des dirigeants**. 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 rançongiciel 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 de cet incident 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 répéter : la question n’est pas de savoir si une perturbation va se produire, mais quand. 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 livre articule l’ensemble du problème autour de trois questions, et j’ai pris l’habitude de commencer chaque bilan 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 démontrer, en apportant des preuves, devant le 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 traduit un manque de résilience, et il est plus important et plus coûteux que ne le pensent la plupart des dirigeants.
Des preuves, pas des promesses
Voici une distinction que ce livre met en avant mieux que je ne l’ai jamais entendue ailleurs : un objectif de délai de reprise 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 propre et vérifié, avec une tolérance de quatre heures ». La première phrase est un plan. La seconde est une preuve. Une seule de ces deux affirmations tiendra la route lorsque votre conseil d’administration, votre autorité de régulation ou votre assureur cyber commencera à poser des questions plus pointues, ce qu’ils ne manqueront pas de faire.
Nous appelons cette discipline « ResOps », abréviation de « resilience operations » (opérations de résilience). Ce n’est ni un produit que l’on achète, ni un dossier que l’on classe. Il s’agit d’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 livre 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 à réduire l’écart entre la découverte et l’exploitation tout aussi rapidement, voire plus vite. Détecter davantage de problèmes ne vous rend pas plus en 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 n’implique de vouloir tout changer d’un seul coup, et je mentirais si je disais que ma propre équipe a réussi du premier coup. Le livre propose un parcours de 90 jours : choisissez un ou deux de vos services les plus critiques, définissez ce que « récupéré » signifie réellement pour chacun d’entre eux, menez un exercice de Recovery en toute honnêteté, 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 livre vous guide concrètement.
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 communes 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 mis en œuvre. Elles contribuent à renforcer la confiance des conseils d’administration, des autorités de régulation, des assureurs et des dirigeants d’entreprise, bien plus que ne le font à eux seuls les plans ou les objectifs de « Recovery ».
Q : Quels indicateurs les organisations doivent-elles mesurer dans le cadre d’un programme ResOps ?
R : Les organisations doivent déterminer si les services critiques peuvent être rétablis, combien de temps la reprise prend réellement, si les points de reprise sont intacts et ont été 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é d’activité, ainsi que les responsables des applications et des services, et les dirigeants concernés, afin que les priorités et les preuves de Recovery reflètent les besoins de l’entreprise.
Q : Comment une organisation peut-elle se lancer dans le 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, consignez les résultats et utilisez ces données pour améliorer le prochain test.
Bill O’Connellest directeur de la sécurité chez Commvault.
