Halflings, dragons et attaques DDoS

Une contrainte trop courante sur les applications aujourd’hui est le budget. Les budgets de sécurité augmentent peut-être, certes, mais pas à un rythme proportionnel à l’approche stratégique consistant à se rendre trop cher pour être piraté.

Cette approche s'apparente au principe Halfling-Dragon qui stipule :

Si vous vous trouvez en compagnie d'un halfelin et d'un dragon de mauvaise humeur, rappelez-vous que vous n'avez pas besoin de distancer le dragon ; vous devez simplement distancer le halfelin.

L'idée est de faire en sorte que votre propre environnement coûte trop cher à attaquer, forçant le dragon à tourner ses yeux affamés vers votre concurrent, le halfelin, à la place.

Maintenant, sans entrer dans le débat éthique qui devrait enflammer la question, l’idée de rendre votre environnement trop coûteux à pirater n’est pas une mauvaise idée.

Le problème est que cela signifie souvent que c’est trop cher pour que vous puissiez vous le permettre. C’est parce que, d’une manière générale, les conseils pour mettre en œuvre une telle stratégie impliquent l’achat de tout un tas de solutions et leur utilisation comme une sorte de gant médiéval, en dressant de nouvelles barrières et en forçant les attaquants à les exécuter pour atteindre ce qu’ils veulent vraiment, vos données. Cela rend la tâche coûteuse pour l’attaquant en l’obligeant à dépenser du temps, de l’énergie et, en fin de compte, de l’argent alors qu’il tente de diffuser ses attaques pour éviter d’être détecté. Cela coûte cher non seulement à l’attaquant, mais aussi à l’entreprise. Pas seulement en termes de solutions (capex) mais aussi d'un point de vue opérationnel (opex), car chaque solution doit être gérée, mise à jour, surveillée et, en fin de compte, mise à l'échelle.

C'est aussi à l'envers. Ce que les attaquants veulent, ce sont vos données, et pourtant nous avons tendance à construire nos défenses et nos protections en commençant par le point le plus éloigné des données, au périmètre du réseau.

Alors, comment faire pour qu’il leur coûte trop cher d’obtenir ce qu’ils veulent, sans que cela vous coûte trop cher de le mettre en œuvre ?

Il n’existe pas de solution miracle à ce problème, mais il existe des moyens de réduire vos coûts tout en augmentant les coûts d’attaque. 

1. Plateformes à effet de levier

Les plateformes reposent sur le partage d’un environnement commun. Elles permettent de réduire les coûts, tout comme la virtualisation et la conteneurisation optimisent l’efficacité des ressources informatiques. Par exemple, un ADC peut s’étendre avec des modules pour intégrer diverses fonctions de prestation, y compris la sécurité. Beaucoup d’organisations utilisent déjà un ADC pour garantir la disponibilité via un équilibrage de charge, pouvant aussi prendre en charge le déploiement de WAF et d’autres fonctions liées à la sécurité. En tant que solution globale, le bon ADC coûte souvent bien moins cher au total que la somme de ses fonctionnalités prises individuellement.

Les capacités de l’équilibreur de charge lui-même méritent également d’être explorées. Contrairement à l’équilibrage de charge rudimentaire, un ADC offre généralement un certain nombre de boutons et de leviers liés à la sécurité qui peuvent être utilisés pour rendre les attaques plus difficiles. La détection de flux SYN, le cryptage des cookies, l'obscurcissement des URL et le filtrage IP/port sont souvent disponibles dans le cadre d'un service d'équilibrage de charge. Augmenter la protection au plus près de l’application rend l’accès plus difficile pour l’attaquant.

2. Opérationnaliser

Il n’existe toujours pas, au grand dam de certains et au plus grand plaisir des autres, de « boîte divine » connue qui puisse à elle seule fournir tout ce dont vous avez besoin pour sécuriser et faire évoluer vos applications. Vous aurez besoin de plusieurs solutions (la clé est de minimiser le nombre de plateformes utilisées, voir ci-dessus) et cela signifie plusieurs consoles, paradigmes de gestion et probablement des personnes. Tout cela va faire exploser votre budget.

En opérationnalisant, vous facilitez l'automatisation et l'orchestration, ce qui vous aide à contenir les coûts des solutions indispensables. Des fonctionnalités comme la mise à l’échelle automatique permettent d'exploiter les ressources dont vous disposez déjà pour renforcer la défense et contraindre un attaquant à augmenter ses dépenses, augmentant ainsi ses coûts tout en gardant les vôtres sous contrôle.

L’opérationnalisation (DevOps, SDN, SDDC, SDx, cloud privé, etc.) réduit également des risques majeurs : l’erreur humaine et l’absence de processus. Pour ce dernier, vous ne pouvez pas automatiser un processus (l’orchestration, d’ailleurs) qui n’existe pas. Si vous n’en avez pas, vous devez en créer un. Il garantit la mise en œuvre des étapes nécessaires pour sécuriser et dimensionner vos applications lors de leur passage en production. L’erreur humaine constitue un risque important : elle peut involontairement créer des brèches dans votre sécurité, permettant aux cybercriminels d’agir, directement ou discrètement pendant une attaque DDoS volumétrique.

3. Le cloud comme échelle

Et lorsque vous ne pouvez plus mettre à l’échelle automatiquement ou que votre bande passante est dépassée, il y a toujours le cloud. Le cloud à grande échelle (cloud bursting, si vous préférez) est une excellente option pour vous permettre de vous défendre efficacement tout en augmentant les coûts d'attaque. Le basculement du nettoyage et de la protection DDoS vers le cloud lors d'une attaque (ou dès son début) peut réduire immédiatement l'impact local sur l'entreprise (en termes de productivité et de profit), ce qui signifie en fait une défense moins coûteuse. Laisser le cloud, avec son échelle (presque) infinie et ses énormes volumes de bande passante, absorber une attaque vous coûtera beaucoup moins cher à long terme, mais pas à l'attaquant.

4. Sécurisé de l'intérieur vers l'extérieur

Comme indiqué précédemment, les attaquants veulent généralement vos données. C’est parce que vos données == $$ sur le marché ouvert et minable. Concentrez-vous donc autant (sinon plus) sur la sécurisation de vos données que sur votre périmètre. Cela signifie employer toutes les astuces et techniques possibles pour rendre très coûteux pour un attaquant l'extraction de valeur de ses attaques (en récupérant des données). Vous y parvenez grâce à une vigilance constante, en protégeant non seulement ce qui entre dans l’application, mais aussi ce qui en sort. C’est la protection des demandes et des réponses.

La majorité (67 %) des répondants à notre étude sur l’état de la distribution des applications en 2016 qui ont déployé un WAF aujourd’hui étaient confiants dans la capacité de leur organisation à résister à une attaque au niveau de la couche applicative (requête-réponse). Il s’agit d’éléments tels que SQLi et XSS, mais aussi de la sécurité WebSocket et de la prévention du piratage de session, ainsi que d’une multitude d’autres fonctionnalités qui garantissent qu’il est très coûteux pour un attaquant de réussir à accéder à vos données.

En fait, une protection plus cohérente sur les trois surfaces d’attaque (client, demande et réponse) est corrélée à une plus grande confiance dans la résistance à une attaque de la couche applicative. Ce n’est pas une fonction « périphérique » ; c’est une fonction centrée sur l’application. Un outil qui se trouve plus près de l’application que de la périphérie du réseau, et dont l’objectif n’est pas d’arrêter les attaques réseau, mais celles qui extraient réellement des données. C’est la valeur que recherchent les attaquants, et c’est la valeur que vous devez rendre si chère que les attaquants abandonneront et iront ailleurs.

Il n’y a aucun moyen de rendre la sécurité bon marché. Absolument aucun. Mais vous pouvez contenir les coûts en rendant l’attaque plus coûteuse pour l’agresseur que pour vous, sans sacrifier votre budget pour sécuriser vos applications. Si vous vous y prenez bien, et que vos défenses forcent l’attaquant à épuiser ses propres ressources (et son argent), le dragon sera trop épuisé (fauché) pour s’en prendre au halfling. Cela donnera au halfling l’opportunité de renforcer ses propres défenses en avance.