Introduction au podcast Beyond the Edge d’Edgio, épisode 5 : identifier et atténuer les menaces Zero-Day, hébergé par Andrew Johnson, Sr. Responsable marketing produit – sécurité chez Edgio.
Andrew Johnson : Bienvenue à Beyond the Edge, où nous fouillons les tenants et aboutissants des tendances qui affectent les entreprises numériques modernes. Je suis Andrew Johnson, votre copilote pour cet épisode. Et aujourd’hui, nous explorons le sujet des menaces zero-day, en particulier la façon dont nous les identifions et les atténuons. Dave Andrews Edgio, vice-président de l’ingénierie, et Marcel Flores, chercheur principal chez Edgio, se joignent à nous aujourd’hui.
Bienvenue, Dave. Et Marcel, c’est génial de vous avoir tous les deux ici. Pouvez-vous nous en dire un peu plus sur vous et sur vos rôles ici chez Edgio ?
Dave Andrews : bien sûr. Merci de nous avoir Andrew. C’est un plaisir d’être sur. Je suis donc vice-président de l’ingénierie. Je suis chez Edgio depuis plus de 11 ans, je pense. Et je suis responsable des plates-formes périphériques et de beaucoup d’infrastructures centrales du point de vue de l’ingénierie.
Andrew Johnson : génial. Merci.
Marcel Flores : Oui. Merci beaucoup de nous avoir accueillis. Comme vous l’avez dit, je suis Marcel Flores. Je suis le chercheur principal chez Edgio Labs, le groupe de recherche ici à Edgio. Mon équipe travaille à l’amélioration de la performance, de la fiabilité et des opérations du réseau en effectuant des recherches et des développements rigoureux, ainsi qu’en s’engageant avec la communauté de recherche sur les systèmes et les réseaux.
Qu’est-ce qu’un Zero-Day ?
Andrew Johnson : génial. Merci encore de vous joindre à nous aujourd’hui, les gars. Donc, le sujet des menaces zero-day, je pense qu’il est important de donner rapidement à notre public un aperçu de ce que sont les vulnérabilités et les attaques zero-day. Je vais brièvement essayer de couvrir cela avant d’entrer dans certaines de vos expériences en matière de protection d’Edgio et de nos clients. Qu’est-ce qu’un zero-day en termes de ce dont nous parlons ici ? Eh bien, fondamentalement, les applications modernes, les entreprises modernes, les services modernes sont composés de logiciels, de logiciels à partir de code open-source, de bases de code commercialisées différents protocoles, etc Nous savons qu’aucun logiciel n’est parfait, et de temps en temps, des vulnérabilités vont être détectées dans ce code. Fondamentalement, le « jour zéro » fait référence à la période au cours de laquelle une vulnérabilité est découverte et au temps nécessaire pour trouver un correctif ou une solution de contournement, n’est-ce pas ?
Ainsi, les développeurs, une fois qu’ils auront connaissance d’une vulnérabilité, ils vont essayer de la corriger le plus rapidement possible ou de donner aux clients et aux utilisateurs de ce logiciel les étapes qu’ils peuvent faire pour empêcher l’exploitation. Mais fondamentalement, comme je l’ai mentionné, c’est un problème qui ne disparaît pas. Nous constatons que le nombre de CVE ou de vulnérabilités et d’expositions courantes augmente chaque année d’environ 25 % en 2022 par rapport à 2021. Il n’est pas super surprenant que davantage de vulnérabilités soient repérées. Il existe des outils d’IA qui peuvent scanner les bases de code rapidement. Il y a certainement des incitations financières pour les bons et les mauvais acteurs à trouver ces vulnérabilités du bon côté, du bon côté acteur. Il y a des programmes bug Bounty.
Vous savez quand Apple envoie des corrections de code pour votre iPhone tout le temps. De bons chercheurs chapeau blanc soumettent des exploits à ces développeurs, et puis il y a de mauvais acteurs qui exploitent également des vulnérabilités. Donc, juste un peu de contexte là-dessus. Peut-être certains courants dont vous avez entendu parler récemment. HTTP2/Rapid Reset a été une grande chose très notable dans le monde de la sécurité des applications récemment. Peut-être avez-vous entendu parler de Log4j, Spring4Shell, ou il y a quelques années, de la vulnérabilité Apache Struts 2 qui a causé des violations de données massives ici aux États-Unis, en fait dans le monde entier. Ce n’est donc qu’un peu un peu de contexte sur les menaces zero-day, mais oui, peut-être que je vais aller de l’avant et commencer par demander à Dave ce que vous faites pour protéger Edgio et nos clients contre les menaces zero-day.
Comment Edgio se protège-t-il et protège-t-il ses clients contre les menaces Zero-Day ?
Dave Andrews : Oui, absolument. Donc, je pense que la sécurité est une question de défense en profondeur, n’est-ce pas ? Comme, il n’y a jamais une seule chose particulière que vous faites. Il s’agit plus de s’assurer que vous avez un certain nombre de couches toutes enchaînées ensemble. L’idée étant que si une ou deux couches sont imparfaites, comme elles le sont toutes parce que nous avons des humains très intelligents qui essaient activement de les briser, le nombre de couches et avec des protections et des atténuations qui se chevauchent est conçu, vous savez, le, tout le point ici est de, peu importe si une chose échoue parce qu’il y a cinq autres choses assis là qui vous protégeront. Donc, prendre du recul, comme le premier, et je pense que l’une des choses les plus importantes est juste généralement tomber dans le seau de la préparation.
Il y a au moins trois aspects distincts à cela. La première qui me vient à l’esprit pour moi est, c’est l’hygiène. Avoir une bonne hygiène de sécurité est absolument essentiel. Et cela aide vraiment en grande partie en réduisant votre domaine de préoccupation. Qu’est-ce que j’entends par hygiène ? Il y a deux choses principales. L’une consiste à maintenir le logiciel à jour ou à appliquer régulièrement des correctifs. C’est la chose la plus ennuyeuse au monde. C’est aussi sans doute l’une des meilleures et des plus critiques lignes de défense. Cela signifie que vous tirez parti de toutes les divulgations responsables dont vous parliez, Andrew, le bon, les chercheurs de chapeau blanc, trouver des vulnérabilités, les divulguer aux fournisseurs, les corriger et déployer des correctifs.
Vous pouvez tirer parti de tous les vecteurs d’attaque connus dans le logiciel que vous utilisez. Juste parce que c’est ennuyeux ne signifie pas nécessairement que c’est facile, surtout lorsque vous travaillez à l’échelle que nous sommes chez Edgio, ainsi que dans un certain nombre d’autres endroits, il est très, très difficile de gérer le risque qui vient avec la mise à niveau régulière de tous vos logiciels. Donc, comme nous le verrons plus tard, il y a beaucoup de choses que nous faisons sur le plan opérationnel pour rendre cela plus sûr et plus facile à faire. Mais il tombe quand même assez carrément dans le seau d’hygiène, si vous voulez. La prochaine pièce qui atterrit dans l’hygiène est la numérisation. Ce qui tout le point ici est de rechercher activement des choses qui sont des indications que vous avez un problème avant qu’un mauvais acteur le trouve.
Cela prend donc plusieurs formes. Il peut s’agir d’équipes de sécurité internes ou d’équipes de sécurité de l’information. Vous pouvez embaucher des tiers pour effectuer des analyses. Cela peut être les deux. Souvent, les organisations tirent parti de bugs Bounty pour encourager fondamentalement les gens à prendre la voie du chapeau blanc, trouver des vulnérabilités les divulguent à nous ou à une partie particulière afin qu’ils puissent être corrigés avant qu’ils ne soient activement exploités. Donc ces choses tombent dans ce seau de tout ce que vous pouvez réparer, réparer cela d’abord, n’est-ce pas ? Par exemple, profitez du bon travail que toute la communauté fait pour rendre Internet et les logiciels en général plus sûrs. Et puis examinez activement vos propres applications, en essayant de trouver les vulnérabilités et de les corriger de manière proactive du mieux que vous le pouvez. La prochaine section que je dirais sur la préparation, que je vais transmettre à Marcel, est l’observabilité.
Marcel Flores : Oui, merci Dave. Je pense donc qu’une autre chose importante à faire dans beaucoup de ces cas est de pouvoir voir ce qui se passe sur votre réseau ou avec votre infrastructure. Je pense donc que ce genre de choses tombe dans deux catégories qui sont fondamentalement abordées de la même manière, mais je pense qu’il est important de les appeler. La première est de penser aux comportements au niveau des applications, n’est-ce pas ? Assurez-vous que vous comprenez quelles demandes arrivent dans votre réseau et quelles sont les caractéristiques de ces demandes, comment elles sont formées et à quoi elles ressemblent normalement et à quoi elles pourraient ressembler lors de certains événements. Je pense que c’est aussi important, de garder à l’esprit que chaque fois que vous communiquez sur Internet, c’est une sorte d’opération de pile complète, n’est-ce pas ?
Où chaque requête va passer à la fois par la couche application, mais aussi par les protocoles de niveau inférieur. Il est donc important de garder un œil sur ce qui se passe plus bas dans la pile, non ? Et comprenez qu’il peut y avoir des comportements et des réponses complexes des systèmes de niveau inférieur qui ne sont pas bien capturés dans ces comportements de couche application. Il est donc important de garder une trace des deux composantes de cela et d’avoir une observabilité de ce qui se passe dans les deux cas. Et je pense qu’un élément clé est d’être capable de comprendre quand ce trafic change, n’est-ce pas ? Quand votre trafic défie les attentes, non ? Vous pourriez commencer à voir des fonctionnalités des demandes d’application qui ne sont pas ce que vous voyez normalement, n’est-ce pas ? Par exemple, une augmentation soudaine des posts HTTP par opposition aux GET, en pensant à la couche applicative, en pensant au niveau du protocole, n’est-ce pas ?
Cela peut être quelque chose de très complexe dans le protocole comme HTTP2 ou quelque chose d’encore plus bas. Et en pensant à ce qui arrive aux sockets TCP et à ce qui se passe avec les interactions de protocole à ce niveau, en particulier lorsque vous pensez à des choses comme les attaques DDoS qui pourraient essayer d’exploiter des vulnérabilités particulières. Je pense que la clé pour avoir ces vulnérabilités, pour cette observabilité est non seulement d’avoir des métriques qui vous permettent de voir ce qui se passe, mais aussi d’avoir la capacité de creuser dans ces comportements, n’est-ce pas ? Et de les segmenter en conséquence, n’est-ce pas ? Pour comprendre s’il y a une population d’utilisateurs particulière qui génère un certain ensemble de trafic. Il y a des réseaux spécifiques, c’est des clients spécifiques, la propriété spécifique d’un certain client, n’est-ce pas ? Ainsi, vous pouvez comprendre et affiner où les choses se passent réellement et comment elles pourraient se passer.
Andrew Johnson : C’est intéressant. C’est intéressant. Alors, après avoir observé ces différents types de comportement ou quelque chose que vous pensez être un jour zéro, quelles sont certaines des étapes opérationnelles que vous pouvez prendre ?
Quelles mesures pouvez-vous prendre pour atténuer les menaces Zero-Day ?
Dave Andrews : Oui, je peux prendre celui-là, Andrew. Oui. Les deux types d’éléments dont Marcel parlait sont vraiment les fondations, non ? Comme le premier est regarder les choses, regarder la tendance, ce qui se résume à d’un point de vue, regarder les choses dans leur ensemble, n’est-ce pas ? À quoi cela ressemble-t-il dans l’ensemble ? Et tout le point là, c’est que vous obtenez une vue de haut niveau de ce qui se passe, et cela vous permet d’identifier les changements très, très rapidement, comme vous l’avez dit. La deuxième partie en termes de plongée profonde est en fait d’être capable de taquiner et de développer votre compréhension de quel changement, à quel niveau fonctionne-t-il, et est-ce un risque, non ? Comme, vous savez, l’Internet est le sauvage, l’ouest sauvage, n’est-ce pas ? Comme, les choses changent tout le temps.
De nouveaux comportements se produisent tout le temps. Toutes ces choses ne sont pas une question de sécurité, n’est-ce pas? Par exemple, la possibilité d’avoir un ensemble d’informations agrégées beaucoup plus large, mais vous permet de creuser et de poser et d’observer ou plutôt de répondre à des questions beaucoup plus nuancées, vous permet d’aller au cœur de ce qui a changé et pourquoi, et vous permet de prendre cette décision. Genre, oh mon Dieu, genre, c’est très bien. C’est un nouveau client qui fait quelque chose. Ou vous savez que c’est vraiment un problème, ou nous devons aller chercher. Donc, s’éloigner de, vous savez, voir ce qui s’est passé, et développer une certaine compréhension à ce sujet est un problème. Vous entrez dans le Royaume de Like, Great, alors quoi ?
Qu’est-ce que tu fais à ce sujet ? Et ce seau de ce que nous appelons l’agilité opérationnelle et l’agilité. Il y a quelques thèmes de haut niveau que nous réfléchissons lorsque nous considérons l’agilité opérationnelle. Encore une fois, trois, mais ce sont la réactivité, la sécurité et la redondance. Donc, juste passer un peu de temps sur chacune de ces réactivité est exactement ce que cela ressemble, non ? Quand quelque chose ne va pas du point de vue de la sécurité, le temps est essentiel, n’est-ce pas ? Comme vous le savez, vous voulez être en mesure de résoudre les problèmes de sécurité très, très rapidement pour donner aux attaquants un minimum de temps pour faire des ravages et vous donner le maximum de temps pour nettoyer. Donc, ce que nous ciblons d’un point de vue très large, non seulement autour des problèmes de sécurité mais aussi autour de toutes sortes de changements opérationnels que nous apportons, nous ciblons environ cinq secondes pour atteindre 99,99% de l’infrastructure.
C’est le but. Nous n’y arrivons pas toujours parce que certaines choses prennent nécessairement plus de temps, mais c’est l’objectif. Et beaucoup de nos sous-systèmes atteignent cet objectif. La sécurité est un thème bizarre à considérer avec l’agilité opérationnelle. Alors laissez-moi taquiner celui-là un peu. L’un des risques que vous avez lorsque vous essayez de faire quelque chose avec un haut niveau de réactivité, c’est-à-dire très, très rapidement, c’est que vous pourriez résoudre le problème très, très rapidement, en supposant que vous avez une observabilité parfaite et une parfaite compréhension de ce qui se passe exactement, et que vous pouvez parfaitement prédire la réponse au changement que vous êtes sur le point d’apporter. C’est génial, et souvent c’est le cas. Cependant, il y a aussi la chance que votre compréhension de l’une de ces choses soit imparfaite, et vous pourriez bien l’aggraver aussi très, très rapidement.
Personne ne veut ça. Donc, tout ce qui concerne la sécurité, c’est que vous mettez des systèmes en place, des processus, et de l’automatisation, et beaucoup d’autres choses y entrent pour vous assurer que vous n’aggravez pas, en fait, les choses. Cela se résume à deux choses très, très haut niveau. Au début. C’est comme la modélisation proactive. Cela s’applique vraiment fortement à la planification de base des capacités, n’est-ce pas ? Par exemple, si vous devez retirer des machines de la production pour une raison ou une autre, vous devez les corriger parce que les services doivent être redémarrés pour une raison ou une autre. L’un des risques si vous essayez de le faire très, très rapidement est que vous retirez trop de machines de la production pour la charge qu’elles subissent actuellement. Vous pouvez le savoir à l’avance, n’est-ce pas ?
Nous avons donc beaucoup de systèmes de modélisation qui s’intègrent aux systèmes de flux de travail de sorte que lorsqu’une demande de tout corriger aussi vite que possible, elle ne retire pas immédiatement tous les serveurs de la production. Il existe donc des systèmes de sécurité de base que vous pouvez construire et intégrer pour vous empêcher de vous tirer dans le pied. Et donc, en supposant que nous n’allons pas empirer les choses de ce point de vue, juste dans une perspective d’infrastructure de planification de la capacité pure, nous voulons aussi savoir que le changement que nous apportons a l’effet escompté au niveau de l’application ou à n’importe quel niveau, de l’observabilité, du protocole, peu importe ce que nous essayons d’atténuer. Ce que nous faisons, c’est que nous exploitons un système que nous appelons mine de charbon. Nous avons blogué à ce sujet et en avons parlé publiquement auparavant, mais l’idée qu’il y a fondamentalement tout se passe comme ce que nous appelons un canari – canaris dans la mine de charbon.
Le point où il n’y a rien qui se passe globalement tout à la fois, aussi désastreux soit-il. Un minimum de deux phases pour quelque chose à sortir. Nous l’avons donc placé sur un sous-ensemble d’infrastructures. Généralement, l’infrastructure qui subit l’événement le plus flagrant ou est la plus visible, nous validons qu’elle répond à nos attentes, puis nous la déployons très rapidement plus tard. Désolé, déployez-le, déployez-le plus largement possible et validez que le problème global est résolu à l’échelle mondiale. Les mines de charbon et les canaris sont étroitement intégrés à leurs métriques et à leurs systèmes d’observabilité pour que vous puissiez corréler en un coup d’œil, comme, qu’est-ce que c’est ? Qu’est-ce que ce canary fait aux métriques agrégées que je regarde? Nous obtenons donc des retours en temps réel que, hey, le changement que nous faisons résout en fait le problème.
C’est donc très, très pratique. Ce sur quoi nous travaillons en ce moment et nous préparons à lancer en interne et plus tard, nous produirons cela pour les clients et leurs modifications de configuration, c’est essentiellement une analyse métrique entièrement automatisée. Donc, actuellement, lorsque nous faisons un changement comme celui-ci, il faut qu’un humain s’assoit là et le regarde, s’assure que la bonne chose se passe, et s’assure que les mesures qui les préoccupent vont dans la bonne direction. Et puis, fondamentalement, avancez le canari, dites au système comme, génial, vous avez passé la première phase. Tout a l’air bien. Allez-y et allez à la phase globale de ce canari. Nous faisons cela, nous exploitons le système pour tous les changements, pas seulement, vous connaissez les changements opérationnels de sécurité, mais tous les changements qui circulent dans tout le système.
Et ce que nous rencontrons, c’est que nous construisons de plus en plus de visibilité sur notre point de vente, de plus en plus de visibilité, de plus en plus de métriques, de plus en plus d’informations sur ce qui se passe, il y a de plus en plus de choses que les humains peuvent regarder, n’est-ce pas ? Et cette charge atteint le point où elle est trop élevée. Et donc les humains commencent à faire des erreurs, non ? Parce qu’il y a tout simplement trop de graphiques à regarder, trop de graphiques à regarder et les gens se fatiguent et les gens sont imparfaits de toute façon. Nous lançons donc un système appelé Birdwatcher, la chose qui surveille les canaris qui fait une analyse statistique sophistiquée sur les métriques, comme lorsque les changements se déroulent et lui donne un pouce en haut ou un pouce en bas. Et cela est intégré à la mine de charbon pour que nous puissions dire, Hey, de manière automatisée, nous obtenons une indication que ce canari est bon, il fait ce que nous attendons.
Et aussi séparément, il ne fait rien de mal que nous ne nous attendons pas, et que, ce déploiement se fera sans aucune intervention humaine. Tellement super excité à ce sujet. Cela va rendre notre réactivité encore plus rapide et encore plus sûre. Ce sont donc les principales choses que nous considérons lorsque nous parlons de sécurité, être capable de faire disparaître le problème rapidement et en toute sécurité. Le dernier point que j’ai mentionné était la redondance, qui est relativement explicite. Il y a un point clé ou une philosophie que nous exploitons et déployons, qui est fondamentalement un double chemin pour beaucoup de ces changements, autant que nous pouvons rassembler. Donc, ce que signifie double chemin, les deux chemins que nous réfléchissons sont essentiellement rapides, au meilleur effort et lents, fiables. L’idée étant là, nous exploitons une grande quantité d’infrastructures dans des endroits très, très, disparates partout dans le monde.
La capacité de tout frapper avec une fiabilité à cent pour cent en quelques secondes est un conte de fées. Comme, ce n’est pas quelque chose qui est faisablement possible. Quelque chose quelque part, c’est toujours avoir un problème. Et il n’y a vraiment rien que vous puissiez faire à ce sujet. Donc, ce que nous faisons, c’est que nous empilons ces choses ensemble comme la sécurité, la défense en profondeur, n’est-ce pas ? Comme, vous mettez ces deux choses ensemble et, et ce à quoi cela ressemble en fait, c’est tirer parti du chemin rapide. Allez frapper autant que vous le pouvez. Et puis tout ce que vous manquez, nous nous assurons d’avoir un chemin fiable redondant que nous continuerons à essayer jusqu’à ce que cela fonctionne, c’est un peu plus lent. Donc, pour mettre quelques chiffres à cela, le chemin rapide va toucher nous allons faire un changement sur environ 99,9% de notre infrastructure en moins de cinq secondes, n’est-ce pas?
Comme, et que 99,9% est répétable et fiable. Et puis le chemin fiable lent tourne de l’ordre de 60 secondes. Et ce système continuera d’essayer jusqu’à ce qu’il réussisse fondamentalement. Donc, en exploitant ces deux-là ensemble, nous obtenons le meilleur des deux mondes. Et si l’un de ces sous-systèmes tombe complètement en panne, cela ne signifie pas que tout est en panne, nous resterons là où nous devons être au maximum cinq minutes plus tard. Donc, ces deux choses ensemble nous donnent cette réactivité et cette agilité avec la fiabilité que nous recherchons. Il y a d’autres petites choses comme, amusantes pour s’assurer que nous avons quelques redondances. Comment lancer ces systèmes ? Comme beaucoup de systèmes vous le savez, les chatbots intégrés, donc c’est très, très facile.
N’importe qui peut le faire de n’importe où dans le monde sur son téléphone. Beaucoup d’autres choses ont des API. Il y a une CLI pour beaucoup de sous-systèmes. S’assurer qu’il n’y a pas qu’une seule façon de lancer ces tâches est un autre exemple de la façon dont nous essayons de construire la redondance afin que nous puissions toujours avoir cette agilité opérationnelle à portée de main, indépendamment de ce qui se passe ou du système particulier qui pourrait rencontrer un problème. Nous nous assurons d’avoir le contrôle et la capacité opérationnelle dont nous avons besoin. Beaucoup de ces choses, vous savez, sont toutes d’usage général, mais comme je l’ai dit, nous les exploitons autant que possible. Tout, des workflows de notre propre infrastructure, comme le retrait d’une machine de la production et l’application de correctifs jusqu’aux modifications de configuration du client. Tout cela tire parti du même système de base que nous la nourriture pour chiens et nous utilisons nous-mêmes de manière agressive. Le produit que nous exposons à nos clients est donc fiable et très, très solide.
Andrew Johnson : génial. Génial. Apprécie ce Dave. Marcel, je pense que vous avez parlé des meilleures pratiques ou des considérations que les équipes de sécurité peuvent appliquer à leur pratique. Appréciez ces conseils. Je sais que vous avez certainement eu affaire à des exemples de zero-day vraiment intéressants dans la nature pour protéger Edgio et nos clients. Je suis sûr que vous avez quelques bonnes histoires et applications de ces meilleures pratiques. Seriez-vous en mesure d’en parler un peu ?
Exemples jour zéro : HTTP2/réinitialisation rapide
Dave Andrews : Oui, absolument. Je pense que celle qui est la plus pertinente ou la plus récente, je suppose, et qui était assez intéressante est, vous l’avez mentionné plus tôt, l’attaque HTTP2/Rapid Reset. Ce fut une expérience très intéressante. Donc, juste pour relayer cela du point de vue d’Edgio, il y a un petit blog que nous avons écrit sur ce gars comme ça s’est passé. HTTP2/Rapid Reset était une attaque zero-day où les gens se sont rendu compte que non seulement la mise en œuvre des bibliothèques de serveur HTTP2 en mode avait pris quelque chose dans le RFC HTTP2, la spécification, la spécification de protocole comme une recommandation générale et a fondamentalement codifié cela dans les bibliothèques elles-mêmes. Et c’était le nombre de requêtes simultanées qui ont été autorisées à être, désolé, les flux concurrents qui ont été autorisés à être en vol sur une connexion particulière, qui était dans la spécification, écrit comme étant une centaine.
Cela associé à une petite facette intéressante de H2, qui est, vous savez, l’idée étant le multiplex – beaucoup et beaucoup de requêtes sur un seul socket TCP – et la capacité d’annuler des requêtes a conduit à cette vulnérabilité très, très intéressante ou vulnérabilité DDoS. Tout le point là ce que les attaquants recherchent est quelque chose qui coûte un petit montant pour l’attaquant et coûte plus cher pour l’attaquant, pour la personne à l’autre extrémité. Et ils l’ont trouvé dans HTTP2 RAPID reset. Ce que cela signifiait fondamentalement, c’est que l’attaquant pouvait très, très, très rapidement craquer comme un seul paquet initiant une requête et l’annulant encore et encore, comme des centaines de ceux sur un seul socket désolé, sur un seul paquet et l’envoyer au serveur.
Le serveur doit alors faire beaucoup plus de travail que simplement envoyer un seul paquet. Nous devons créer une requête, souvent nous devons initier une connexion proxy. C’est ce que font les CDN pour aller chercher n’importe quelle ressource que l’attaquant demandait. Et enfin, nous devons consigner que la demande a eu lieu. Donc, le fait que les attaquants ont pu générer ces initiations et l’annulation des requêtes est très, très rapide. Fondamentalement, la plupart, comme tous ceux qui ont subi cette attaque, c’est plus cher. Il était plus coûteux de les traiter que de les générer. Et donc cela devient une vulnérabilité DDoS. Donc nous aimons beaucoup d’autres gens dans l’industrie ont été attaqués par ça.
Et tout le monde a été attaqué à peu près au même moment, ce qui a rendu cela particulièrement intéressant. C’était une attaque très large. Et j’aimerais bien comprendre ce que les attaquants pensaient quand ils ont commencé ça. Parce qu’ils attaquaient beaucoup, beaucoup, beaucoup de fournisseurs tous en même temps. Ce que nous avons découvert quand nous avons commencé à parler aux autres fournisseurs et disons, oh, quand as-tu vu ça ? OH, c’est exactement la même fois que nous l’avons vu, dans laquelle nous sommes tombés parce que nous avons trouvé l’attaque. Nous avons identifié ce qui se passait à cause de l’observabilité dont parle Marcel. Et nous avons commencé à construire des atténuations, n’est-ce pas ? Cette atténuation ressemble donc à ajouter encore plus d’observabilité pour être au cœur de ce qui se passait et ensuite à construire des contrôles opérationnels qui nous permettent d’ajuster une réponse.
Donc, à quoi cela ressemblait en fait, gardez une trace du nombre de fois qu’un client réinitialise des requêtes sur un socket particulier, et si le pourcentage dépasse un seuil prédéfini, mettez fin à cette connexion. Donc, l’idée est fondamentalement de ne pas permettre à l’attaquant d’envoyer continuellement ces requêtes pour mettre un cap sur elle et ainsi être en mesure d’atténuer l’attaque. Nous avons donc publié ce blog après avoir construit cette atténuation, l’avoir déployée, l’avoir promulguée et validé qu’elle empêchait en fait ces attaques de se reproduire. Ensuite, nous avons eu des gens de l’industrie tendre la main et comme, oh, nous avons vu le blog. Nous avons également été touchés par cela et nous travaillons sur la divulgation responsable. Nous nous sommes donc repliés avec un groupe de l’industrie avec lequel nous avons travaillé comme Vince, qui fait partie du certificat pour passer par le flux de divulgation responsable, nous assurer que dans ce cas les gens qui implémentaient des bibliothèques HTTP2 ou des serveurs HPD avaient le temps de générer des correctifs, déployer ces correctifs avant le, la vulnérabilité a été plus largement médiatisée.
C’était donc un flux très, très intéressant, intéressant. Nous avons pu, inverser ça très rapidement, non ? Comme en partie à cause du travail que nous faisons sur l’hygiène et le fonctionnement, la visibilité opérationnelle et l’agilité, nous avons pu avoir un très petit changement à faire, n’est-ce pas ? Comme, ce n’était pas, vous savez, oh mon Dieu, nous devons mettre à jour cette bibliothèque et nous sommes comme 10 versions en retard parce que nous ne la mettons pas régulièrement à jour. Ce n’était pas que c’était comme si, en fait, nous étions une version derrière, n’est-ce pas ? Comme, parce que nous corrigeons régulièrement la mise à niveau que le risque est réduit parce que c’est un petit saut, ce qui signifie que vous pouvez le faire très rapidement tout en maintenant ce seuil de risque faible que nous avons. Nous l’avons donc fait très, très rapidement et nous sommes en mesure de le déployer et d’atténuer l’attaque. Et puis nous avons mis en place le blog sans savoir que l’attaque avait frappé plus de gens en partie pour essayer de socialiser avec non seulement nos clients, mais l’industrie. Comme, Hey, c’est quelque chose de bizarre que nous avons vu qui semble que ce n’est rien de spécifique à Edgio et en fait potentiellement plus applicable. Et il s’est avéré que c’était le cas.
Andrew Johnson : C’est, c’est vraiment intéressant. C’est plutôt cool de voir une vue de l’intérieur de vous savez, la communauté de la sécurité à travers le monde travaillant ensemble pour, vous savez, améliorer les résultats pour tout le monde. Marcel, tu voulais ajouter quelque chose autour de ça ?
Marcel Flores : Oui, je voulais juste ajouter une note que je, je pense que cet exemple était intéressant dans lequel l’observabilité initiale que nous avions clairement montré des comportements étranges comme Dave le décrivait, non ? Cette interaction de la sorte de fonctionnalité de protocole de niveau inférieur avec les comportements de niveau supérieur du CDN a créé des comportements vraiment inattendus. Et une partie de cela, une partie de comprendre ce qui se passait ici était de comprendre qu’il y avait ce déséquilibre grave, non ? Que le nombre de demandes que nous voyions par rapport au nombre de demandes que nous remettions aux clients était biaisé, n’est-ce pas ? Et cela s’est démarqué. Et même si ces deux indicateurs étaient collectés, nous ne les avions pas comparés exactement de cette façon. Une partie du résultat était de nous asseoir et de regarder le problème et de dire, Hey, quoi, comment pouvons-nous combiner la visibilité que nous avons déjà dans quelque chose qui est fait sur mesure pour détecter ce problème ? Et nous avons pu faire exactement cela et améliorer la portée de notre visibilité en regardant les données que nous avions déjà sous un angle légèrement différent.
Andrew Johnson : génial. Génial. C’est bon à garder à l’esprit. Et merci pour ça Marcel. Ouais, les gars, donc je pense que nous sommes, nous terminons. Si, s’il y a d’autres recommandations que vous souhaitez partager? Je pense que nous avons couvert un haut niveau, certains très bons.
Recommandations pour renforcer votre posture de sécurité
Dave Andrews : bonne question. Je pense qu’une recommandation générale est que l’hygiène est d’une importance cruciale. En me concentrant sur votre observabilité, je pense que la chose que j’appellerais est de trouver des gens qui peuvent vous aider, n’est-ce pas ? Comme une partie de la valeur d’une proposition de valeur critique qu’une entreprise comme Edgio fournit est que nous pouvons certainement aider, n’est-ce pas? Vous avez toute une équipe de personnes comme moi et Marcel qui travaillent sur ce sujet et qui travaillent de manière proactive à empêcher des classes entières d’attaques d’avoir un impact sur les gens. Alors trouvez des gens qui peuvent vous aider, non ? Comme il y a un tas d’outils et de technologies que nous construisons, que la communauté a à disposition pour vous faciliter la tâche. Quand nous parlons, vous savez, généralement des choses sur Internet, un WAF est comme, est le plus critique, comme le plus basique aussi, je dirais l’exemple le plus critique de quelque chose comme ça.
Il vous donne la capacité si elle est mise en œuvre de manière appropriée, il vous donne la capacité de combiner l’agilité et les éléments de sécurité ensemble. Le pare-feu Edgio WAF fonctionne en mode double, ce qui signifie que vous pouvez déployer de nouvelles règles en production, sur les machines réelles qui l’obtiennent, qui observent le trafic. Et vous pouvez voir ce qui se passe. Un bon exemple de cela a été avec Log4j, qui, vous savez, remontait un tout petit peu dans le temps. Lorsque nous développons la réponse à cela, nous sommes en mesure de développer la règle très, très rapidement et de la valider très, très rapidement. Parce que nous poussions des mises à jour de règles et que nous étions capables de les déployer en mode alerte sur les machines réelles et de voir qu’elles correspondaient aux attaques, montrer à nos clients qu’ils n’étaient pas attaqués ou qu’ils étaient attaqués. Puis, prenez une décision très axée sur les données pour activer cette règle en mode blocage et empêcher ces attaques d’atteindre nos clients. Donc, il combine toutes ces choses ensemble, non ? Comme la rapidité de réactivité, la sécurité, la redondance et la fiabilité. Obtenez des gens qui peuvent vous aider. Je pense que ce serait ma principale recommandation.
Andrew Johnson : cela a beaucoup de sens. J’apprécie ça, Dave. Ouais, je veux dire, quand on répond à zéro jour, le temps est critique. Donc avoir ces solutions spécialisées, mais aussi, plus important encore, les personnes qui peuvent vous aider à traverser cela est la clé pour fermer cette porte aux attaquants. Donc avec ça, merci beaucoup de nous rejoindre. J’aimerais également remercier le public, et nous vous reverrons dans le prochain épisode. Merci.
