Aujourd’hui, le budget constitue une contrainte bien trop courante pour les applications. Certes, les budgets consacrés à la sécurité sont peut-être en hausse, mais pas à un rythme suffisant pour s’inscrire dans une stratégie visant à rendre le piratage de vos systèmes trop coûteux.
Cette approche s’apparente au principe du Halfelin et du Dragon, qui stipule :
Si vous vous retrouvez en compagnie d’un halfelin et d’un dragon de mauvaise humeur, rappelez-vous que vous n’avez pas besoin de courir plus vite que le dragon ; il vous suffit de courir plus vite que le halfelin.
L’idée est de rendre l’attaque de votre propre environnement trop coûteuse, afin de contraindre le dragon à tourner plutôt son regard affamé vers votre concurrent, le halfelin.
À présent, sans nous égarer dans le débat éthique qui devrait faire rage, l’idée de rendre votre environnement trop coûteux à pirater n’est pas mauvaise.
Le problème, c’est que cela signifie souvent que le coût devient également trop élevé pour vous. En effet, de manière générale, les conseils pour mettre en œuvre une telle stratégie consistent à acheter toute une série de solutions et à les déployer comme une sorte de parcours d’obstacles médiéval, en dressant de nouvelles barrières que les attaquants doivent franchir pour atteindre ce qu’ils convoitent réellement : vos données. Cela augmente le coût pour l’attaquant en l’obligeant à consacrer du temps, de l’énergie et, en fin de compte, de l’argent à disperser ses attaques afin d’éviter d’être détecté. Mais cela coûte cher non seulement à l’attaquant, mais aussi à l’entreprise. Et pas uniquement en matière de solutions (CapEx), mais également sur le plan opérationnel (OpEx), puisque chaque solution doit être gérée, mise à jour, surveillée et, à terme, adaptée à la montée en charge.
C’est aussi une approche à l’envers. Ce que veulent les attaquants, ce sont vos données, et pourtant, nous avons tendance à mettre en place nos défenses et nos protections en partant du point le plus éloigné des données, à savoir le périmètre du réseau.
Alors, comment faire en sorte qu’il leur soit trop coûteux d’obtenir ce qu’ils veulent, sans que la mise en œuvre ne vous coûte trop cher ?
Il n’existe pas de solution miracle (même plaquée argent) dans ce cas, mais certaines méthodes permettent de limiter vos coûts tout en augmentant ceux d’une attaque.
1. Tirez parti des plateformes
Les plateformes reposent sur le principe du partage d’un environnement commun. Elles réduisent les coûts de la même manière que la virtualisation et la conteneurisation optimisent l’utilisation des ressources informatiques. Un ADC, par exemple, peut être enrichi de modules prenant en charge un large éventail de fonctions de mise à disposition, notamment en matière de sécurité. De nombreuses organisations utilisent déjà un ADC pour garantir la disponibilité grâce à l’équilibrage de charge. Celui-ci peut également permettre le déploiement d’un WAF et d’autres fonctions liées à la sécurité. En tant que solution globale, le bon ADC peut revenir bien moins cher au total que l’ensemble de ses fonctions individuelles déployées sous forme de solutions ponctuelles.
Il convient également d’examiner les fonctionnalités propres à l’équilibreur de charge. Contrairement à un système d’équilibrage de charge rudimentaire, un ADC offre généralement plusieurs options et mécanismes de sécurité permettant de compliquer les attaques. La détection des attaques par inondation SYN, le chiffrement des cookies, l’obfuscation des URL et le filtrage des adresses IP et des ports sont souvent proposés dans le cadre d’un service d’équilibrage de charge. Renforcer la protection au plus près de l’application rend son accès plus difficile pour l’attaquant.
2. Opérationnaliser
Il n’existe toujours pas, au grand dam des uns et pour le plus grand plaisir des autres, de « solution miracle » connue capable de fournir à elle seule tout ce dont vous avez besoin pour sécuriser les applications et les faire évoluer. Vous aurez besoin de plusieurs solutions (l’essentiel étant d’en réduire le nombre grâce à des plateformes, comme indiqué ci-dessus), ce qui implique plusieurs consoles, différents modèles de gestion et probablement davantage de personnel. Autant d’éléments qui feront exploser votre budget.
L’opérationnalisation, qui permet l’automatisation et l’orchestration, peut limiter le coût des solutions indispensables à mettre en place. Même des fonctionnalités telles que la mise à l’échelle automatique, qui permet d’exploiter les ressources dont vous disposez (probablement) déjà pour augmenter votre capacité et contraindre un attaquant à faire de même, peuvent accroître le coût d’une attaque tout en maîtrisant celui de la défense.
L’opérationnalisation (DevOps, SDN, SDDC, SDx, cloud privé, etc.) permet également de réduire des sources de risque élevé : l’erreur humaine et l’absence de processus. Concernant cette dernière, il est impossible d’automatiser un processus inexistant (c’est d’ailleurs ce que l’on appelle l’orchestration). Si vous n’en avez pas, vous devriez en mettre un en place. Il garantit que les mesures nécessaires sont prises pour sécuriser les applications et adapter leur capacité lorsqu’elles passent en production. Quant à l’erreur humaine, elle représente un risque majeur, car elle peut créer par inadvertance des failles de sécurité permettant à des acteurs malveillants de s’introduire dans votre système, soit directement, soit furtivement en profitant de la diversion créée par une attaque DDoS volumétrique.
3. Le cloud comme levier de mise à l’échelle
Et lorsque vous ne pouvez plus procéder à une mise à l’échelle automatique, ou que votre bande passante est saturée, il reste toujours le cloud. Le recours au cloud pour sa capacité de mise à l’échelle (« cloud bursting », si vous préférez) est une excellente solution pour vous permettre de vous défendre efficacement tout en augmentant le coût de l’attaque. Le transfert vers le cloud du nettoyage du trafic DDoS et de la protection contre ces attaques pendant une attaque (ou dès son déclenchement) peut immédiatement réduire l’impact local sur l’entreprise, en matière de productivité et de bénéfices, ce qui se traduit effectivement par une défense moins coûteuse. Laisser le cloud, avec sa capacité de mise à l’échelle (presque) infinie et son immense bande passante, absorber une attaque vous coûtera beaucoup moins cher à long terme, mais pas à l’attaquant.
4. Sécurisez de l’intérieur vers l’extérieur
Comme indiqué précédemment, les attaquants cherchent généralement à s’emparer de vos données. En effet, vos données valent de l’argent sur les marchés interlopes. Accordez donc autant d’importance, voire davantage, à la sécurisation de vos données qu’à celle de votre périmètre. Cela implique d’employer toutes les astuces et techniques possibles pour qu’il soit très coûteux pour un attaquant de tirer profit de ses attaques en dérobant des données. Pour ce faire, vous devez faire preuve d’une vigilance constante et protéger non seulement ce qui entre dans l’application, mais aussi ce qui en sort. C’est ce qu’on appelle la protection des requêtes et des réponses.
La majorité (67 %) des personnes interrogées dans le cadre de notre rapport State of Application Delivery 2016 et disposant actuellement d’un WAF se déclaraient confiantes dans la capacité de leur organisation à résister à une attaque au niveau de la couche applicative (requête-réponse). Il s’agit notamment d’attaques telles que les injections SQL (SQLi) et les attaques XSS, mais aussi de la sécurisation des WebSockets, de la prévention du détournement de session et de nombreuses autres fonctionnalités qui rendent l’accès à vos données extrêmement coûteux pour un attaquant.
En fait, une protection plus homogène sur les trois surfaces d’attaque (client, requête et réponse) était corrélée à une plus grande confiance dans la capacité à résister à une attaque au niveau de la couche applicative. Il ne s’agit pas d’une fonction de « périphérie », mais d’une fonction centrée sur l’application. Elle se situe plus près de l’application que de la périphérie du réseau, et son objectif n’est pas d’arrêter les attaques réseau, mais celles qui visent réellement à exfiltrer des données. C’est cette valeur que recherchent les attaquants, et c’est son obtention que vous devez rendre si coûteuse qu’ils finiront par abandonner et chercher ailleurs.
Il n’existe aucun moyen de rendre la sécurité bon marché. C’est tout simplement impossible. Mais il est possible d’en limiter les coûts et de faire en sorte qu’une attaque coûte plus cher à l’attaquant qu’à vous, sans pour autant vous ruiner au point de ne plus pouvoir sécuriser vos applications. Et si vous vous y prenez bien, et que vos défenses obligent les attaquants à mobiliser une trop grande part de leurs propres ressources — et de leur argent —, le dragon sera peut-être trop épuisé — ou trop fauché — pour s’en prendre à ce semi-homme. Celui-ci aura alors une chance de prendre de l’avance dans la mise en place de ses propres défenses.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.