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 sont basées sur l’idée de partager un environnement commun. Ils réduisent les coûts de la même manière que la virtualisation et la conteneurisation augmentent l’efficacité des ressources de calcul. Un ADC, par exemple, peut être étendu avec des modules pour prendre en charge une grande variété de fonctions de livraison, y compris la sécurité. De nombreuses organisations utilisent déjà un ADC pour garantir la disponibilité avec un équilibrage de charge qui peut être en mesure de 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 peut coûter bien moins cher au total que la somme de ses fonctions individuelles en tant que solutions ponctuelles.
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.
L’opérationnalisation, permettant l’automatisation et l’orchestration, peut limiter les coûts des solutions que vous devez mettre en place. Même des fonctionnalités telles que la mise à l'échelle automatique, qui permettent de tirer parti des ressources dont vous disposez (probablement) déjà, pour augmenter et forcer un attaquant à réagir de la même manière, peuvent augmenter les coûts d'attaque tout en gardant les coûts de défense sous contrôle.
L’opérationnalisation (DevOps, SDN, SDDC, SDx, cloud privé, etc.) aborde également les sources de risque élevé : l’erreur humaine et le manque de processus. Sur ce dernier point, vous ne pouvez pas automatiser un processus (c’est-à-dire l’orchestration, soit dit en passant) qui n’existe pas. Et si vous n’en avez pas, vous devriez en avoir un. Il garantit que les mesures nécessaires sont prises pour sécuriser et faire évoluer les applications lorsqu'elles passent en production. Le premier, l’erreur humaine, constitue un risque énorme car il peut ouvrir par inadvertance des failles dans votre sécurité qui permettent aux méchants de s’infiltrer, soit directement, soit en secret lors d’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’existe aucun moyen de rendre la sécurité bon marché. Il n’y en a tout simplement pas. Mais il existe des moyens de réduire les coûts, de rendre la tâche plus coûteuse pour l'attaquant que pour vous, sans pour autant vous retrouver dans une situation financière trop difficile pour sécuriser vos applications. Et si vous le faites bien et que vos défenses forcent les attaquants à consommer trop de leurs propres ressources (et de leur argent), le dragon pourrait tout simplement être trop fatigué (cassé) pour s'en prendre à cette moitié. Et cela donnera au halfelin une chance de prendre une longueur d'avance sur ses propres défenses.