Ayant observé, surveillé et participé à de nombreux incidents de cybersécurité au fil des années, il devient de plus en plus clair pour moi que les organisations manquent quelques opportunités clés pour améliorer les résultats et la vitesse de récupération après une attaque. Cela peut faire toute la différence entre la restauration des activités commerciales ou la fermeture définitive.
La raison pour laquelle je me concentre autant sur ce sujet est que j’ai constaté l’ampleur des efforts nécessaires pour redémarrer les opérations après qu’un incident important se soit produit. Plus déconcertant encore est l’absence d’un plan de rétablissement documenté dans de nombreuses situations. Mon objectif en écrivant cet article est de souligner quelques réflexions sur les raisons pour lesquelles nous, en tant qu'industrie, avons échoué à cet égard, et dans une note ultérieure, j'identifierai les moyens de planifier de manière appropriée.
Construire un centre de commandement des incidents
Lorsqu'un incident de cybersécurité est détecté, un centre de commande des incidents est mis en place pour répondre et gérer l'impact du malware. Des experts légistes sont sollicités pour retracer ce qui s'est passé, si les données ont été exfiltrées et confirmer que le logiciel malveillant a été éradiqué. Une fois que les experts ont conclu que tout est sécuritaire, ils rendent l’environnement à l’entreprise. Un rapport d'analyse des causes profondes est généré et l'incident est considéré comme clos, laissant derrière lui un faible espoir que le logiciel malveillant ait été éradiqué et que les systèmes soient restaurés dans un laps de temps relativement court.
Le plus souvent, l'environnement a été si durement touché par des programmes corrompus et des données infectées que le seul recours dont disposent les clients est de reconstruire l'intégralité de leur environnement à partir de zéro.
Si vous savez que le résultat sera une reconstruction totale, alors le travail de préparation devrait commencer en même temps que le centre de commandement des incidents a été déclaré. Malheureusement, cela ne se produit pas.
C’est alors que trois questions doivent être posées :
- Depuis combien de temps le malware infecte-t-il votre environnement ?
- Votre réseau est-il segmenté et savez-vous qu'il est exempt de logiciels malveillants ? (c'est-à-dire tout système à espace d'air ou système immuable)
- Êtes-vous certain que vos systèmes de sauvegarde sont exempts de logiciels malveillants ?
Si vous n’êtes pas vraiment sûr de pouvoir répondre à ces questions, la seule mesure sûre à prendre est d’effectuer un redémarrage « sans système d’exploitation ». Appelé le « scénario apocalyptique », les organisations évitent à tout prix d’avoir à prendre cette décision.
Alors que les entreprises modernes continuent d’investir dans la technologie, des efforts importants sont déployés pour protéger et gérer activement la sécurité de notre environnement technologique. L'industrie technologique a fait un très bon travail en soulignant la nécessité d'une protection de sécurité avec des explications claires sur l'impact d'une défaillance de sécurité. Pour atténuer ces risques, le secteur de la sécurité a développé une multitude d'outils logiciels pour protéger l'infrastructure et détecter les logiciels malveillants. (Gartner a identifié plus de 3 000 produits dans cet espace.)
La phase de récupération
Le NIST Cybersecurity Framework (CSF) est la méthodologie industrielle utilisée pour aligner les fonctions de sécurité dans l'attente d'un incident. La dernière fonction du cadre est la récupération, mais elle se concentre davantage sur la récupération après un incident de sécurité plutôt que sur la récupération de l'entreprise.
En fin de compte, la capacité de restaurer les opérations à un état normal est l’objectif primordial d’un incident, et la phase de récupération offre la meilleure opportunité d’y parvenir. Mais dans bien trop d’événements, cet effort est le plus difficile à réaliser et prend le plus de temps. Pendant ce temps, l’entreprise a du mal à fonctionner, ce qui entraîne une perte de revenus et une diminution de la crédibilité des clients, ce qui peut avoir des répercussions à long terme. Avec des enjeux aussi élevés, on pourrait conclure que la priorité serait accordée au processus de rétablissement. Malheureusement, ce n'est pas le cas. Il existe de nombreux exemples d’entreprises publiques déclarant des centaines de millions de dollars de coûts directs alors qu’elles luttent pour relancer leurs activités.
La décision la plus importante à prendre face à une attaque est d’invoquer le plan de reprise en même temps que l’incident.
Récupération au début de l'attaque
Ceci est distinct du processus de réponse aux incidents. Classés dans la catégorie Continuité d’activité ou Reprise après sinistre, de nombreux clients ont élaboré des plans de restauration des données et des applications comme base de leur processus de récupération. Mais dans la plupart des cas, cela ne fonctionne pas. Pourquoi pas?
Parce que sous-jacentes aux données et aux applications se trouvent des couches d'infrastructure étendues et intégrées composées de systèmes d'exploitation, de composants réseau, de services de virtualisation, d'identité et d'authentification, et de nombreux autres services, à la fois sur site et dans divers environnements cloud. Il ne s’agit pas seulement de ce menu de composants ; ils doivent être redémarrés dans un ordre systématique.
Un exemple d'échec de réponse est l'incapacité de communiquer via la messagerie électronique de l'entreprise après qu'un incident s'est produit. Le plus souvent, ce système a été mis hors service pour se protéger contre de nouvelles infections. Mais sans une méthode de communication secondaire fiable, la capacité à mobiliser des ressources est retardée.
Je suis convaincu que si les organisations prennent la décision d’invoquer immédiatement le plan de relance, le temps nécessaire pour rétablir l’activité opérationnelle sera considérablement raccourci.
Alors pourquoi cela n’arrive-t-il pas ?
Voici cinq obstacles qui empêchent (ou prolongent) les dirigeants de franchir cette étape critique :
- La conviction que les logiciels malveillants peuvent être contrôlés ou éradiqués rapidement.
- Penser qu’il sera assez simple de recharger la ou les applications concernées et de restaurer les données.
- Une mauvaise compréhension de l’interdépendance des systèmes aujourd’hui. Cela inclut les systèmes d’authentification unique, les systèmes d’authentification et d’autorisation.
- Complexité liée à la réalisation d'un redémarrage complet de l'ensemble de l'environnement.
- Manque de planification pour cette éventualité.
Manquer la cible
Alors, quel est le véritable défi du rétablissement ? En fin de compte, les compétences nécessaires pour mettre en œuvre un programme de redémarrage ne résident pas au sein de l’équipe de cybersécurité. Ils ne devraient pas non plus le faire. C’est là que réside la principale raison pour laquelle nous avons échoué, à mon avis. Nous n'avons pas impliqué les architectes d'entreprise, le personnel des opérations informatiques et les autres spécialistes techniques dont les compétences sont requises pour redémarrer l'ensemble de l'environnement. Nous n'avons pas non plus inclus les dirigeants dont la fonction commerciale dépend du fonctionnement de leurs applications. Ils ont un rôle à jouer dans la priorisation des applications les plus critiques pour soutenir l'entreprise.
En conclusion, nous devons élargir notre réflexion sur la réponse aux incidents et inclure la récupération comme une responsabilité clé lors de l'invocation d'un incident.
Dans l’article suivant, je vais expliquer comment procéder pour configurer cela.
Je suis intéressé de savoir quelles sont vos pensées. Êtes-vous d’accord, en désaccord ou avez-vous un point de vue différent à partager sur ce sujet très important ?
.png)