Comment se remettre d’une attaque DDoS

Étape 1. Restaurer les services

Le redémarrage ou la remise en ligne des applications et des services après une attaque DDoS nécessite une bonne connaissance du fonctionnement et de l’interconnexion des applications et des systèmes. Les équipes ont besoin d’une feuille de route méthodique et documentée sur la séquence de restauration correcte.

En l’absence d’une telle feuille de route, les équipes peuvent être confrontées à des défaillances en cascade. Par exemple, un système peut ne pas fonctionner correctement si les services sur lesquels il s’appuie ne sont pas encore rétablis, ce qui, à son tour, affecte d’autres services, aggravant ainsi le problème.

Lorsque les services reviennent en ligne, ils peuvent être confrontés à un afflux de tentatives de connexion légitimes de la part d’utilisateurs qui essaient de se reconnecter. Parfois, cela peut créer un effet DDoS au niveau de la couche d’application, forçant tout à se déconnecter à nouveau.

Pour y remédier, une solution simple consiste à abaisser les limites de débit et de connexion à des niveaux que les équipes savent pouvoir supporter. Une meilleure option, si elle est disponible, consiste à acheminer le trafic vers différents centres de calcul en fonction des plages d’adresses IP ou de la géographie.

Si le fournisseur d’accès de l’organisation a interrompu la connectivité, il doit la rétablir. Cela peut nécessiter d’expliquer quelles protections ont été mises en place pour faire face à une nouvelle attaque.

S’il s’agit d’une attaque DDoS sur les couches 3 ou 4, exécutez la commande clear ip bgp * sur les routeurs BGP. Cette opération permet de rétablir les connexions BGP, de sorte que les demandes des utilisateurs sont correctement acheminées vers les services et que ces derniers ne semblent plus hors ligne. Les fournisseurs de transit IP et les partenaires d’échange de trafic ont mis à jour les informations de routage environ 90 secondes après le début de l’attaque.

Étape 2. Procéder à un examen post-attaque

Une fois les services rétablis, les équipes de sécurité doivent collaborer avec les autres parties impliquées pour évaluer les dommages et tirer les leçons de l’expérience afin de mieux se préparer à la prochaine attaque, qui ne manquera pas de se produire un jour ou l’autre.

Les coûts directs d’une attaque comprennent la perte de revenus et de production, ainsi que les coûts d’hébergement, tels que les instances cloud supplémentaires. Ces dépenses dépendent de la manière dont les services ont été affectés et de leur durée. Les coûts peuvent également inclure des coûts indirects ou internes, tels que la perte de productivité, les plaintes des clients, une mauvaise presse ou les atteintes à la réputation.

Il convient de noter que les utilisateurs peuvent également avoir été affectés par l’attaque en raison des mesures de défense qui les ont empêchés d’accéder aux services. Il est important d’évaluer ces coûts, car ils permettent de déterminer les budgets appropriés pour l’atténuation des attaques DDoS futures.

Le travail sur les enseignements retirés doit être axé sur l’évaluation de l’efficacité des défenses et des procédures de réponse existantes, de manière à ce que les faiblesses et les lacunes éventuelles puissent être corrigées. Les logs provenant des appareils et des applications du réseau interne, ainsi que des fournisseurs tiers concernés, devraient révéler quels protocoles et modèles d’attaque ont été utilisés, la durée et la quantité maximale de données et de requêtes enregistrées sur le réseau, et quels actifs ont été ciblés. Ces informations montrent quelles mesures d’atténuation supplémentaires sont nécessaires pour faire face à une attaque similaire.

Recueillez les données clés suivantes pour mieux comprendre l’efficacité ou l’inefficacité des défenses et des plans :

• Le délai de détection mesure la rapidité avec laquelle l’attaque a été détectée.
• Le délai d’alerte mesure la rapidité avec laquelle les principales parties concernées ont été informées de l’attaque.
• Le délai de déviation mesure le temps nécessaire aux contrôles de sécurité pour bloquer et dévier le trafic afin d’éviter les temps d’arrêt.
• La cohérence des mesures d’atténuation mesure le pourcentage de trafic malveillant autorisé à passer – une mesure clé de l’efficacité des défenses.

Ces paramètres permettent également de déterminer dans quelle mesure les fournisseurs de solutions d’atténuation des attaques DDoS ou d’autres fournisseurs tiers concernés ont respecté leurs accords de niveau de service.

Une autre statistique clé à prendre en compte est le rapport entre le trafic légitime et le trafic malveillant qui a été arrêté. Ces informations permettent d’identifier les points faibles des défenses qui ont permis à un type d’attaque, à un vecteur d’attaque ou à un schéma d’attaque particulier, de réussir ou qui ont laissé des services spécifiques plus susceptibles d’être perturbés que d’autres. Remédiez à ces faiblesses dès que possible en améliorant les outils, en modifiant les points et seuils de déclenchement et en augmentant les ressources du réseau.

Examinez également la qualité de la gestion de la communication avec les parties concernées. Était-elle opportune et informative ? Des messages contradictoires peuvent frustrer et aliéner les utilisateurs. À l’avenir, désignez une personne chargée de coordonner les mises à jour sur tous les canaux de communication.

L’équipe juridique pourrait être amenée à déposer un rapport sur une attaque auprès des autorités réglementaires sectorielles, des forces de l’ordre et de la compagnie d’assurance spécialisée dans la cybersécurité.

Même si une organisation ne subit pas d’attaque DDoS de grande ampleur au cours de l’année, il est important d’actualiser régulièrement les prévisions d’impact et les plans de protection contre les attaques DDoS. Examinez chaque année les tendances, les produits et les services actuels pour vous assurer que les environnements informatiques sont résistants aux attaques DDoS et que les meilleurs outils de détection des attaques DDoS sont en place, correctement configurés et paramétrés.