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 explorons les tenants et aboutissants des tendances qui affectent les entreprises numériques modernes. Je suis Andrew Johnson, votre co-pilote 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. Aujourd’hui, Dave Andrews Edgio, vice-président de l’ingénierie, et Marcel Flores, chercheur principal à Edgio, se joignent à nous.
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 vos rôles ici à Edgio ?
Dave Andrews : bien sûr. Merci de nous avoir Andrew. C’est un plaisir d’être en marche. Je suis donc vice-président de l’ingénierie. Je suis à Edgio depuis que je pense juste une ombre plus de 11 ans. Et je suis responsable des plates-formes de périphérie et d’une grande partie du type d’infrastructure centrale du point de vue de l’ingénierie.
Andrew Johnson : génial. Merci.
Marcel Flores : Oui. Merci beaucoup de nous avoir reçus. Comme vous l’avez dit, je suis Marcel Flores. Je suis le chercheur principal à 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 collaborant avec la communauté de recherche plus large sur les systèmes et le réseautage.
Qu’est-ce qu’un Zero-Day ?
Andrew Johnson : génial. Merci encore de vous joindre à nous aujourd’hui, les gars. Donc, en ce qui concerne les 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. J’essaierai brièvement de couvrir cela avant d’aborder certaines de vos expériences en matière de protection d’Edgio et de nos clients. Qu’est-ce qu’un jour zéro par rapport à 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és 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, « jour zéro » fait référence à la période pendant laquelle une vulnérabilité est découverte et au temps nécessaire pour trouver un correctif ou une solution de contournement, non ?
Donc, les développeurs, une fois qu’ils connaissent 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’exploit. 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 vulnérabilités et expositions courantes augmente chaque année d’environ 25 % en 2022 par rapport à 2021. Il n’est pas super surprenant que plus de vulnérabilités vont être 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, du bon côté des acteurs. Il existe des programmes de primes de bogue.
Vous êtes familier avec quand Apple pousse des correctifs de code pour votre iPhone tout le temps. Les bons chercheurs en chapeau blanc soumettent des exploits à ces développeurs, et puis il y a de mauvais acteurs qui exploitent également les vulnérabilités. Donc, juste un peu d’arrière-plan là-dessus. Peut-être quelques-uns communs 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 massives de données ici aux États-Unis, en fait dans le monde entier. C’est juste un peu d’arrière-plan sur les menaces zero-day, mais oui, peut-être que je vais aller de l’avant et commencer par demander à Dave un peu ce que vous faites pour protéger Edgio et nos clients des menaces zero-day.
Comment Edgio se protège-t-elle et protège-t-elle ses clients contre les menaces Zero-Day ?
Dave Andrews : Oui, absolument. Donc la sécurité, je pense, c’est une question de défense en profondeur, non ? 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 attachées ensemble. L’idée étant 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, car il y a cinq autres choses qui vous protégeront. Donc, prendre un peu de recul, comme le premier, et je pense que l’une des choses les plus importantes est de tomber généralement dans le seau de la préparation.
Il y a au moins trois aspects distincts à cela. Le premier qui me vient à l’esprit 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 les logiciels à 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 profitez de toutes les divulgations responsables dont vous parliez, Andrew, les bons chercheurs du 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 fondamentalement connus dans le logiciel que vous utilisez. Juste parce que c’est ennuyeux ne signifie pas nécessairement que c’est facile surtout quand on travaille à l’échelle que nous sommes à Edgio, ainsi qu’à un certain nombre d’autres endroits, c’est très, il est très difficile de gérer le risque lié à 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 encore 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. Dont tout le point ici est activement à la recherche de choses qui sont des indications que vous avez un problème avant qu’un mauvais acteur ne 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 engager des parties externes pour effectuer des analyses. Il peut s’agir des deux. Souvent, les organisations tirent parti de bug Bounty pour encourager les gens à prendre la route du chapeau blanc, trouver des vulnérabilités les divulguer à nous ou à la partie particulière afin qu’elles puissent être corrigées avant qu’elles ne soient activement exploitées. 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 ensuite, en regardant activement vos propres applications, en essayant de trouver des vulnérabilités et de les corriger de manière proactive du mieux que vous le pouvez. La prochaine section que je dirais autour de la préparation, je vais passer la parole à 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. Donc, je pense que ce genre de tombe dans deux catégories qui sont fondamentalement approchées de la même manière, mais je pense qu’il est important d’appeler. La première consiste à réfléchir aux comportements au niveau de l’application, n’est-ce pas ? Assurez-vous que vous comprenez quelles requêtes arrivent dans votre réseau et en quelque sorte quelles sont les caractéristiques de ces requêtes, comment elles sont formées et à quoi elles ressemblent normalement et à quoi elles peuvent 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, n’est-ce pas, c’est une sorte d’opération full stack, n’est-ce pas ?
Où chaque requête passe à la fois par la couche application, mais aussi par les protocoles de niveau inférieur. Et donc il est important de garder un œil sur ce qui se passe plus bas dans la pile, n’est-ce pas ? 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 d’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, non ? Lorsque 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 publications HTTP par opposition à GETS, en pensant à la couche application, au niveau protocole, non ?
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, surtout quand 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é, c’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 pour les segmenter en conséquence, non ? 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, une propriété spécifique d’un certain client, n’est-ce pas ? Vous pouvez donc comprendre et préciser où les choses se passent réellement et comment elles peuvent se produire.
Andrew Johnson : C’est intéressant. C’est intéressant. Après avoir observé ces différents types de comportements ou quelque chose que vous pensez être un jour zéro, quelles sont les étapes opérationnelles que vous pouvez suivre ?
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, n’est-ce pas ? Comme le premier est regarder les choses, regarder la tendance, qui se résume à d’un point de vue, regarder les choses dans leur ensemble, n’est-ce pas ? Par exemple, à quoi cela ressemble-t-il globalement ? Et tout ce qui importe, 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 être capable de taquiner et de développer votre compréhension sur quel changement, à quel niveau fonctionne-t-il, et est-ce un risque, non? Comme, vous savez, l’Internet est le sauvage, l’ouest sauvage, non ? Comme, les choses changent tout le temps.
De nouveaux comportements se produisent tout le temps. Toutes ces choses ne sont pas un problème de sécurité, n’est-ce pas ? Par exemple, la capacité 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. Comme, Oh mon Dieu, comme, c’est très bien. C’est un nouveau client qui fait quelque chose. Ou vous savez que c’est en fait 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 genre, super, alors quoi?
Comme, que faites-vous à ce sujet ? Et ce seau de ce que nous appelons agilité et agilité opérationnelles. 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 il s’agit de réactivité, de sécurité et de redondance. Passer un peu de temps sur chacune de ces réponses est exactement ce à quoi ça ressemble, n’est-ce pas ? Quand quelque chose ne va pas d’un 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 questions de sécurité, mais juste autour de toutes sortes de changements opérationnels que nous effectuons, 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 la cible. Et beaucoup de nos sous-systèmes atteignent cet objectif. La sécurité est un genre de thème étrange à penser avec l’agilité d’opération. Alors laisse-moi taquiner celui-là un peu. Un des risques que vous avez quand vous essayez de faire quelque chose avec un haut niveau de réactivité, c’est-à-dire très, très rapidement, est que vous pourriez résoudre le problème très, très rapidement, en supposant que vous avez une observabilité parfaite et une compréhension parfaite de ce qui se passe exactement, et vous pouvez parfaitement prédire la réponse au changement que vous êtes sur le point de faire. C’est génial, et c’est souvent le cas. Cependant, il y a aussi la possibilité 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 cela. Donc, tout le point à propos de la sécurité, c’est que vous mettez en place des systèmes, des processus, et de l’automatisation, et beaucoup d’autres choses entrent dans elle pour vous assurer que vous n’aggravez pas les choses. Cela se résume à quelques choses de très, très haut niveau. Au début. C’est comme de la modélisation proactive. Cela s’applique vraiment fortement à la planification de la capacité de base, n’est-ce pas ? Par exemple, si vous devez retirer des machines de la production pour une raison quelconque pour les corriger, car cela nécessite le redémarrage des services pour une raison quelconque. L’un des risques là-bas si vous essayez de le faire très, très rapidement, est de retirer 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 correctif de tout le système aussi vite que possible, cela 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 aggraver les choses de ce point de vue, juste du point de vue de l’infrastructure de planification de capacité pure, nous voulons également savoir que le changement que nous apportons a l’effet escompté au niveau de l’application ou à n’importe quel niveau, application observabilité, protocole, quoi qu’il en soit, nous essayons d’atténuer. Donc, 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 – des canaris dans la mine de charbon.
Le fait qu’il n’y a rien qui se passe globalement tout à la fois, peu importe à quel point c’est terrible. Un minimum de deux phases pour que quelque chose sorte. Nous l’avons donc placé sur un sous-ensemble d’infrastructure. En général, l’infrastructure qui subit le plus l’événement ou qui est la plus visible, nous validons qu’elle fait ce que nous attendons, puis nous la déployons très rapidement plus tard. Désolé, déployez-le plus largement possible et validez que le problème global se résout au niveau mondial. Donc mine de charbon et canaris étroitement intégrés avec leurs systèmes de métriques et d’observabilité pour que vous puissiez corréler en un coup d’œil comme, qu’est-ce que c’est ? Que fait ce canary aux métriques agrégées que je regarde ? Nous recevons donc des commentaires en temps réel que, hé, 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 nous préparons à lancer en interne et plus tard, nous produirons cela pour les clients et leurs modifications de configuration, 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’assoie là et regarde, s’assure que la bonne chose se passe et que les mesures qui les préoccupent évoluent dans la bonne direction. Et puis, fondamentalement, avancez le canari, dites au système comme, super, vous avez passé la première phase. Tout a l’air bien. Allez-y et passez à la phase mondiale 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 le système.
Et ce dans quoi nous nous heurtons, 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 à regarder pour les humains, n’est-ce pas ? Et cette charge atteint le point où elle est trop élevée. Et donc les humains commencent à faire des erreurs, n’est-ce pas ? Parce qu’il y a tout simplement trop de graphiques à regarder, trop de graphiques à regarder et les gens sont fatigués et les gens sont imparfaits de toute façon. Nous lançons donc un système appelé BirdWatcher, la chose qui surveille les canaris en gros qui fait une analyse statistique sophistiquée sur les métriques, comme lorsque les changements se déroulent et lui donne un pouce vers le haut ou un pouce vers le bas. Et cela est intégré à la mine de charbon afin que nous puissions dire, Hey, d’une manière automatisée, nous obtenons une indication que canary 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 déroulera sans aucune intervention humaine. Tellement 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 le double chemin, les deux chemins que nous réfléchissons sont essentiellement rapides, au meilleur effort et lents, fiables. L’idée étant que nous exploitons une grande quantité d’infrastructures dans des endroits très, très, disparates partout dans le monde.
La possibilité 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 a toujours 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 superposons ces choses 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. Va frapper autant que tu peux. Et puis tout ce que vous manquez, nous nous assurons que nous avons 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, non?
Comme, et que 99,9% est reproductible et fiable. Et puis le chemin fiable lent court de l’ordre de 60 secondes. Et ce système continuera d’essayer jusqu’à ce qu’il réussisse fondamentalement. Donc, en tirant parti de ces deux ensembles, nous obtenons le meilleur des deux mondes. Et si un de ces sous-systèmes tombe complètement en panne, cela ne signifie pas que tout est en panne, nous serons toujours là où nous devons être au maximum cinq minutes plus tard. Ces deux éléments réunis nous donnent donc cette réactivité et cette agilité avec la fiabilité que nous recherchons. Il y a d’autres petites choses amusantes pour s’assurer que nous avons des redondances. Comme comment lancez-vous ces systèmes ? Comme beaucoup de systèmes vous le savez, 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. Donc, 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 d’intégrer 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 que nous avons le contrôle et la capacité opérationnelle dont nous avons besoin. Beaucoup de ces choses, vous savez, sont toutes générales, mais comme je l’ai dit, nous les exploitons autant que possible. Tout, de nos propres workflows d’infrastructure, comme le retrait d’une machine de la production et son application de correctifs jusqu’aux modifications de configuration du client. Tout cela tire parti du même système de base que la nourriture pour chiens et nous tirons parti de nous-mêmes agressivement. Le produit que nous exposons à nos clients est donc fiable et très, très solide.
Andrew Johnson : génial. Génial. J’apprécie Dave. Marcel, je pense que vous avez parlé des meilleures pratiques ou considérations que les équipes de sécurité peuvent appliquer à leur pratique. Appréciez ces conseils. Je sais que vous avez certainement traité 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 pratiques exemplaires. Seriez-vous capable d’en parler un peu ?
Exemples Zero-Day : HTTP2/réinitialisation rapide
Dave Andrews : Oui, absolument. Je pense que celui qui est le plus pertinent ou le plus récent, je suppose, et c’était assez intéressant, c’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 le relayer du point de vue d’Edgio, il y a un petit blog que nous avons écrit sur ce gars comme il s’est passé. HTTP2/Rapid Reset était une attaque zero-day où les gens se sont rendu compte que non seulement l’implémentation des bibliothèques de serveur HTTP2 en mode avait pris quelque chose dans la HTTP2 RFC, la spécification, la spécification de protocole comme recommandation générale et fondamentalement codifié cela dans les bibliothèques elles-mêmes. Et c’était le nombre de demandes simultanées qui ont été autorisées à être, désolé, les flux simultanés qui ont été autorisés à être en vol sur une connexion particulière, qui était dans les spécifications, écrit comme étant une centaine.
Cela couplé à une petite facette intéressante de H2, qui est, vous savez, l’idée étant le multiplex – beaucoup et beaucoup de requêtes sur une seule socket TCP – et la possibilité d’annuler des requêtes ont conduit à cette vulnérabilité très, très intéressante ou vulnérabilité DDoS. Tout ce que les attaquants recherchent, c’est quelque chose qui coûte un peu pour l’attaquant et coûte plus cher pour l’attackee, pour la personne de l’autre côté Et ils l’ont trouvé dans HTTP2 réinitialisation rapide. Ce que cela signifiait en gros, c’est que l’attaquant pouvait très, très, très rapidement s’engouffrer 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 d’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 quel actif demandé par l’attaquant. Et puis finalement, nous devons enregistrer que la demande a eu lieu. Ainsi, le fait que les attaquants aient pu générer ces initiations et annulations de 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 personnes dans l’industrie ont été attaquées par ça.
Et tout le monde a été attaqué à peu près au même moment, ce qui le rendait 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 à dire, Oh, quand avez-vous vu ça ? Oh, c’est exactement au même moment que nous l’avons vu, dans lequel nous sommes tombés parce que nous avons trouvé l’attaque. Nous avons identifié ce qui se passait à cause de l’observabilité dont Marcel parle. Et nous avons commencé à construire des atténuations, non ? Donc, cette atténuation ressemble à ajouter encore plus d’observabilité pour aller au cœur de ce qui se passait exactement et ensuite construire des contrôles opérationnels qui nous permettent d’ajuster une réponse à cela.
Donc, à quoi cela ressemblait, gardez une trace du nombre de fois où un client réinitialise des requêtes sur un socket particulier, et si le pourcentage dépasse un seuil prédéfini, terminez 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 donc ê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, mise en œuvre et validé qu’elle empêchait en fait ces attaques de se reproduire. Ensuite, nous avons eu des gens de l’industrie qui ont tendu la main et genre, Oh, nous avons vu le blog. Nous avons également été touchés par cela et nous travaillons sur la divulgation responsable. Nous avons donc fait équipe avec un groupe de l’industrie avec qui nous avons travaillé comme Vince, ce qui fait partie du cert pour passer par le flux de divulgation responsable, assurez-vous que dans ce cas, les gens qui implémentaient des bibliothèques HTTP2 ou des serveurs HPD ont eu le temps de générer des correctifs, de déployer ces correctifs avant, la vulnérabilité a été plus largement diffusée.
C’était donc un flux très, très intéressant, intéressant. Nous avons pu, pour inverser cela très rapidement, non ? Comme en partie à cause du travail que nous faisons sur l’hygiène et le fonctionnement et la visibilité et l’agilité opérationnelles, 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 derrière parce que nous ne la mettons pas à jour régulièrement. Ce n’était pas que c’était comme, en fait nous sommes, nous sommes une version derrière, n’est-ce pas ? Par exemple, 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 faible risque 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 vraiment intéressant. Un peu cool de voir une vue de l’intérieur de vous savez, la communauté de la sécurité à travers le monde travaillant ensemble pour, comme vous le savez, améliorer les résultats pour tout le monde. Marcel, tu voulais ajouter quelque chose autour de ça ?
Marcel Flores : Ouais, 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 décrivait, n’est-ce pas ? Cette interaction d’une 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, c’était de comprendre qu’il y avait ce grave déséquilibre, n’est-ce pas ? Que le nombre de demandes que nous voyions par rapport au nombre de demandes que nous remettions réellement aux clients était biaisé, n’est-ce pas ? Et cela s’est démarqué. Et même s’il s’agissait des deux métriques que nous avions collectées, nous ne les avions pas comparées exactement de cette façon. Une partie du résultat a été de s’asseoir et de l’examiner et de dire, 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 examinant 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 finissons. Si, s’il y a des recommandations supplémentaires que vous souhaitez partager? Je pense que nous avons couvert un niveau élevé, 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 critique. 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 gens comme Marcel et moi qui travaillent sur ce sujet et 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, n’est-ce pas ? Comme il y a un tas d’outils et de technologies que nous construisons, que la communauté a à votre disposition qui peuvent 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 possibilité de combiner l’agilité et les éléments de sécurité ensemble. Ainsi, le WAF Edgio fonctionne en mode double, ce qui signifie que vous pouvez déployer de nouvelles règles à la production, aux machines réelles qui l’obtiennent, qui observent le trafic. Et vous pouvez voir ce qui se passe. Un bon exemple de cela était avec Log4j, qui, vous savez, revenait 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 les mises à jour des règles et que nous pouvions les déployer en mode alerte sur les machines réelles et voir qu’elles correspondaient aux attaques, montrez à nos clients qu’ils n’étaient pas attaqués ou qu’ils étaient attaqués. Et puis prendre une décision très axée sur les données pour activer cette règle en mode de blocage et empêcher que ces attaques ne parviennent à nos clients. Donc ça combine toutes ces choses ensemble, n’est-ce pas ? Comme la rapidité de réactivité, la sécurité, la redondance et la fiabilité. Trouvez 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 à surmonter cela est la clé pour fermer cette porte aux attaquants. Donc avec ces gars-là, merci beaucoup de vous joindre à nous. J’aimerais également remercier le public, et nous vous reverrons dans le prochain épisode. Merci.
