La gestion de la menace DDoS passe par une analyse de risques préliminaire. Elle définira la meilleure stratégie de défense possible. En voici donc l’anti-sèche ultime pour vous aider à mieux anticiper et répondre aux menaces de déni de service.
DDoS : comment s’y préparer ?
La compréhension de la nature et de la classification des attaques DDoS est un pré-requis vital pour la mise en place d’un plan de réponse adapté. En effet, il est difficile de se défendre efficacement contre quelque chose qu’on ne comprend pas. Pour rappel, une attaque DDoS a pour but de rendre indisponible un service (fourni par une ou plusieurs machines) empêchant ainsi ses utilisateurs légitimes de s’en servir. N’hésitez pas à vous rafraîchir la mémoire ou à nous contacter si vous avez besoin d’éclaircissements.
Vous avez donc à coeur de maintenir vos services en état de fonctionnement. Vous savez également qu’on peut facilement être victime d’une attaque. Et maintenant, on fait quoi, docteur 🙂 ?
Comme la plupart des problématiques sécurité, la gestion de la menace DDoS commence par une analyse de risques préliminaire. Elle fournit le niveau de sensibilité de l’organisation face à ces attaques et permet ainsi d’en déduire la stratégie de défense à mettre en place.
Cette analyse peut être réalisée de façon pragmatique et simple en trois étapes :
1. Définir un périmètre d’étude ;
2. Évaluer l’impact de la perte des composants et services ;
3. Calculer le niveau de risque de chaque composant de la chaîne d’accès.
Regardons-y de plus près.
Cette étape consiste à définir clairement ce que vous souhaitez protéger. Il s’agit en pratique de choisir les services (site web, portail intranet, outils de gestion de paie,…) qui seront considérés dans l’analyse de risques.
Chaque service retenu devra a minima se voir accompagné de cartographies, chacune détaillant notamment :
– la chaîne d’accès technique qui le compose. Il s’agit d’un schéma faisant apparaître, généralement de façon séquentielle, les différents composants réseaux traversés pour atteindre le service : câbles réseau, routeurs, pare-feux, répartiteurs de charge, commutateurs, serveurs, etc.
– l’ensemble des personnes/équipes gérant chacun des composants traversés. Ces informations permettront d’établir ultérieurement un plan de réponse organisationnel adéquat.
Cette deuxième étape consiste à répondre à la question suivante : si le service tombe, qu’est ce que cela entraîne ? La question est simple mais la réponse n’est pas toujours évidente.
Cet exercice reste toutefois crucial car il permet de se préparer dans de bonnes conditions :
- prioriser les services et composants à sécuriser ;
- définir les taux/temps de pertes acceptables ainsi que les exigences sécurité à atteindre ;
- préparer les équipes internes aux impacts ;
- préparer les plans de réponses techniques et organisationnels.
Vous l’aurez compris : cette évaluation nécessite également une approche transverse, donc ne rechignez pas à impliquer des collaborateurs avec des expertises diverses
Le niveau de risque d’un composant correspond à son niveau de sensibilité théorique face à chaque type d’attaque DDoS.
Cette sensibilité est directement liée à 3 éléments :
- la nature du service rendu par le composant. Par ex., un serveur fournissant un service HTTP sera beaucoup moins sensible à une attaque applicative NTP que ne le serait un serveur NTP ;
- la configuration actuelle du composant. Celui-ci peut, par exemple, être déjà configuré pour résister à certaines attaques ;
- la zone d’exposition de ce service (réseau local, Internet, population restreinte d’adresse IP,…). Ce critère permet, entre autres, d’identifier les différentes provenances possibles d’attaques et les principales zones à défendre.
Une fois l’ensemble des composants étudié, le niveau de risque associé à la chaîne est rapidement déterminable. En effet, dans la mesure où l’interruption de service d’un seul composant provoque une rupture de l’accès au service, la chaîne est aussi forte que son maillon le plus faible.
L’issue de cette analyse de risque se poursuit par la mise en place d’une architecture technique de défense adossée à un plan de réponse organisationnel. Ce thème fera l’objet d’un prochain billet et a sans doute été un élément-clé ayant permis à GitHub d’enrayer la récente attaque DDoS dont il a été victime.