Introducción al podcast de Edgio Beyond the Edge Episodio 5: Identificación y mitigación de amenazas de día cero organizado por Andrew Johnson, Sr. Gerente de Marketing de Producto – Seguridad en Edgio.
Andrew Johnson: Bienvenido a Beyond the Edge, donde profundizamos en los entresijos de las tendencias que afectan a los negocios digitales modernos. Soy Andrew Johnson, tu copiloto para este episodio. Y hoy estamos explorando el tema de las amenazas de día cero, específicamente cómo las identificamos y las mitigamos. Hoy nos acompañan Dave Andrews Edgio, vicepresidente de ingeniería, y Marcel Flores, científico investigador principal de Edgio.
Bienvenido, Dave. Y Marcel, es genial tenerlos a los dos aquí. ¿Puedes contarnos un poco sobre ti mismo y tus papeles aquí en Edgio?
Dave Andrews: Claro. Gracias por tenernos Andrew. Es un placer estar en él. Así que soy vicepresidente de ingeniería. He estado en Edgio porque creo que solo una sombra más de 11 años. Y soy responsable de las plataformas perimetrales y mucho del tipo de infraestructura central desde una perspectiva de ingeniería.
Andrew Johnson: Impresionante. Gracias.
Marcel FLORES: Sí. Muchas gracias por tenernos. Como dijiste, soy Marcel Flores. Soy el científico investigador principal en Edgio Labs, el grupo de investigación aquí en Edgio. Mi equipo trabaja en mejorar el rendimiento, la confiabilidad y las operaciones de la red mediante la realización de investigaciones y desarrollo rigurosos, así como la participación con los sistemas más amplios y la comunidad de investigación en red.
¿Qué es un Día Cero?
Andrew Johnson: Impresionante. Gracias de nuevo por unirse a nosotros hoy, chicos. Así que el tema de las amenazas de día cero, creo que es importante dar rápidamente a nuestra audiencia un fondo sobre lo que son las vulnerabilidades de día cero y los ataques. Trataré brevemente de cubrir eso antes de entrar en algunas de sus experiencias protegiendo a Edgio y a nuestros clientes. Entonces, ¿qué es un día cero en términos de lo que estamos hablando aquí? Bueno, básicamente las aplicaciones modernas, las empresas modernas, los servicios modernos se componen de software, software de código abierto, bases de código comercializado diferentes protocolos, etc. Sabemos que ningún software es perfecto, y de vez en cuando, se van a detectar vulnerabilidades en ese código. Básicamente, “día cero” se refiere al período de tiempo dentro del cual se descubre una vulnerabilidad y el tiempo para llegar a un parche o una solución, ¿verdad?
Por lo tanto, los desarrolladores, una vez que sepan sobre una vulnerabilidad, intentarán parcharla lo más rápido posible o dar a los clientes y usuarios de ese software pasos que pueden hacer para evitar la explotación. Pero básicamente, como mencioné, es un problema que no va a desaparecer. Vemos que el número de CVE o vulnerabilidades y exposiciones comunes aumenta cada año en un aumento de aproximadamente un 25% en 2022 en comparación con 2021. No es muy sorprendente que más vulnerabilidades van a ser detectadas. Hay herramientas de IA que pueden escanear bases de código rápidamente. Ciertamente, hay incentivos financieros tanto para los buenos actores como para los malos actores para encontrar estas vulnerabilidades en el lado bueno, el buen actor. Hay programas de recompensas de errores.
Estás familiarizado con cuando Apple empuja las correcciones de código para tu iPhone todo el tiempo. Los investigadores de un buen sombrero blanco están enviando hazañas a estos desarrolladores, y luego hay malos actores que también están explotando vulnerabilidades. Así que, solo un poco de antecedentes sobre eso. Tal vez algunos comunes de los que has oído hablar recientemente. HTTP2/Rapid Reset fue una gran cosa muy notable en el mundo de la seguridad de las aplicaciones recientemente. Tal vez hayas oído hablar de Log4j, Spring4Shell, o hace unos años, de la vulnerabilidad Apache Struts 2 que causó violaciones masivas de datos aquí en los Estados Unidos, en realidad en todo el mundo. Así que eso es solo un poco de antecedentes sobre las amenazas de día cero, pero sí, tal vez voy a seguir adelante y empezar por preguntarle a Dave solo un poco sobre lo que ustedes hacen para proteger a Edgio y a nuestros clientes de las amenazas de día cero.
¿Cómo se protege Edgio a sí mismo y a sus clientes de las amenazas Zero-Day?
Dave Andrews: Sí, absolutamente. Así que la seguridad creo que se trata de la defensa en profundidad, ¿verdad? Como, nunca hay una cosa en particular que hagas. Se trata más de asegurarse de tener un número de capas todas unidas. La idea es si una o dos capas son imperfectas, como todas son porque tenemos humanos muy inteligentes tratando activamente de romperlas, el gran número de capas y con protecciones y mitigaciones superpuestas está diseñado, ya saben, el punto completo aquí es, no importa si una cosa falla porque hay otras cinco cosas sentadas allí que te protegerán. Así que, dando un paso atrás, como el primero, y creo que podría decirse que una de las cosas más importantes es que generalmente cae en el mar de la preparación.
Hay por lo menos tres aspectos distintos a eso. El primero que me viene a la mente es, la higiene. Tener una buena higiene de seguridad es absolutamente crítico. Y realmente ayuda en gran medida al reducir su área de preocupación. Entonces, ¿qué quiero decir con higiene? Hay dos cosas principales. Uno es mantener el software actualizado, o parches regulares. Esto es lo más aburrido del mundo. También es posiblemente una de las mejores y más críticas líneas de defensa. Significa que aprovechas todas las revelaciones responsables de las que estabas hablando, Andrew, los buenos investigadores del sombrero blanco, encontrando vulnerabilidades, revelarlos a los vendedores, arreglarlos y desplegar arreglos.
Puedes aprovechar todos los vectores de ataque básicamente conocidos en el software que estás usando. Solo porque sea aburrido no significa necesariamente que sea fácil, especialmente cuando estás trabajando a la escala que estamos en Edgio, así como en varios otros lugares, es muy, muy difícil de gestionar el riesgo que conlleva actualizar todo su software de forma regular. Así que, como veremos más adelante, hay muchas cosas que hacemos operacionalmente para que eso sea más seguro y fácil de hacer. Pero todavía cae bastante directamente en el cubo de higiene, si se quiere. La siguiente pieza que aterriza dentro de la higiene es el escaneo. Lo que todo el punto aquí es buscar activamente cosas que sean indicaciones de que tienes un problema antes de que un mal actor lo encuentre.
Así que esto toma una serie de formas. Puede ser equipos de seguridad interna o equipos de seguridad de la información. Puede contratar a partes externas para realizar escaneos. Puede ser ambos. A menudo, las organizaciones aprovechan la recompensa por errores para básicamente alentar a las personas a tomar la ruta del sombrero blanco, encontrar vulnerabilidades que se nos revelan a nosotros o a la parte en particular para que puedan ser corregidos antes de que sean explotados activamente. Así que esas cosas caen en este cubo de cualquier cosa que puedas arreglar, arreglar eso primero, ¿verdad? Al igual que, aproveche el buen trabajo que toda la comunidad está haciendo para hacer que Internet y el software en general sean más seguros. Y luego, mirando activamente sus propias aplicaciones, tratando de encontrar vulnerabilidades y arreglarlas proactivamente lo mejor que pueda. La siguiente sección que diría acerca de la preparación, voy a entregar a Marcel, es la observabilidad.
Marcel Flores: Sí, gracias Dave. Así que creo que otra cosa importante que se puede hacer en muchos de estos casos es poder ver lo que está pasando en su red o con su infraestructura. Así que creo que este tipo se divide en dos categorías que se abordan fundamentalmente de la misma manera, pero creo que son importantes para llamar. La primera es pensar en comportamientos a nivel de aplicación, ¿verdad? Asegúrese de entender qué solicitudes entran en su red y qué características tienen esas solicitudes, cómo se configuran y cómo se ven normalmente y cómo pueden verse durante ciertos eventos. Creo que también es importante, tener en cuenta que cada vez que se está comunicando en Internet, ¿verdad, es una especie de operación de pila completa, ¿verdad?
Donde cada solicitud va a pasar a través de la capa de aplicación, pero también los protocolos de nivel inferior. Así que es importante vigilar lo que está pasando más abajo en la pila, ¿verdad? Y entienda que puede haber comportamientos y respuestas complejos de sistemas de nivel inferior que no están bien capturados en esos comportamientos de capa de aplicación. Así que es importante hacer un seguimiento de ambos componentes de eso y tener la observabilidad de lo que está sucediendo en ambos casos. Y creo que una pieza clave es ser capaz de entender cuándo cambia ese tráfico, ¿verdad? Cuando su tráfico desafía las expectativas, ¿verdad? Es posible que empieces a ver características de las solicitudes de aplicaciones que no son lo que normalmente ves, ¿verdad? Por ejemplo, un aumento repentino en las publicaciones HTTP en lugar de Gets, pensando en la capa de aplicación, pensando en el nivel de protocolo, ¿verdad?
Esto puede ser algo muy complejo en el protocolo como HTTP2 o algo aún más bajo. Y pensar en lo que está sucediendo con los sockets TCP y lo que está pasando con las interacciones de protocolo a ese nivel, especialmente cuando está pensando en cosas como ataques DDoS que podrían intentar explotar vulnerabilidades particulares. Creo que la clave para tener estas vulnerabilidades, para esta observabilidad no es solo tener métricas que te permitan ver lo que está pasando, sino también tener la capacidad de indagar en estos comportamientos, ¿verdad? Y para segmentarlos en consecuencia, ¿verdad? Para entender si hay una población de usuarios en particular que está generando un cierto conjunto de tráfico. Hay redes específicas, son clientes específicos, propiedad específica de un determinado cliente, ¿verdad? Así que puedes entender y reducir dónde están sucediendo las cosas en realidad y cómo podrían estar sucediendo.
Andrew Johnson: Eso es interesante. Eso es interesante. Entonces, ¿qué, después de observar estos diferentes tipos de comportamiento o algo que cree que podría ser un día cero, cuáles son algunos de los pasos operacionalmente que puede tomar?
¿Qué pasos puedes tomar para mitigar las amenazas de Zero-Day?
Dave Andrews: Sí, puedo tomar esa, Andrew. Sí. Los dos tipos de elementos de los que hablaba Marcel son realmente los fundamentos, ¿verdad? Al igual que el primero es mirar las cosas, mirar la tendencia, que se reduce a desde una perspectiva, mirar las cosas en conjunto, ¿verdad? Como, ¿cómo se ve esto en general? Y el punto es que se obtiene una visión de alto nivel de lo que está pasando, y se le permite identificar los cambios muy, muy rápidamente, como usted dijo. La segunda parte en términos de buceo profundo es en realidad ser capaz de burlarse y desarrollar su comprensión sobre qué cambio, en qué nivel está operando, y es un riesgo, ¿verdad? Como, ya sabes, Internet es el salvaje oeste salvaje, ¿verdad? Al igual que, las cosas cambian todo el tiempo.
Nuevos comportamientos están sucediendo todo el tiempo. No todas esas cosas son un problema de seguridad, ¿verdad? Por ejemplo, la capacidad de tener un conjunto agregado de información mucho más amplio, pero le permite profundizar y preguntar y observar o más bien responder preguntas que son mucho más matizadas, le permite llegar al corazón de lo que ha cambiado y por qué, y le permite tomar esa decisión. Como, oh mi bondad, como, esto está bien. Es un nuevo cliente haciendo algo. O saben que esto es realmente un problema, o tenemos que ir a mirar. Así que alejarse de, ya sabes, ver lo que ha sucedido, y desarrollar un poco de comprensión sobre esto es un problema. Te metes en el reino de lo semejante, grande, entonces ¿qué?
Como, ¿qué haces al respecto? Y este cubo de lo que llamamos agilidad operativa y agilidad. Hay algunos temas de alto nivel que pensamos cuando consideramos la agilidad operativa. Una vez más, tres pero esos son la capacidad de respuesta, la seguridad y la redundancia. Así que simplemente pasar un poco de tiempo en cada una de esas respuestas es exactamente lo que suena, ¿verdad? Cuando algo va mal desde una perspectiva de seguridad, el tiempo es esencial, ¿verdad? Como sabes, quieres ser capaz de cerrar los problemas de seguridad muy, muy rápidamente para dar a los atacantes un tiempo mínimo para causar estragos y darle la cantidad máxima de tiempo para limpiar. Así que a lo que nos dirigimos desde un sentido muy amplio, no solo en torno a los problemas de seguridad, sino en torno a todo tipo de cambios operativos que hacemos, nos dirigimos a alrededor de cinco segundos para alcanzar el 99,99% de la infraestructura.
Ese es el objetivo. No siempre llegamos allí porque algunas cosas necesariamente toman más tiempo, pero ese es el objetivo. Y muchos de nuestros subsistemas cumplen con ese objetivo. La seguridad es un tipo de tema extraño en el que pensar con la agilidad de la operación. Así que permítanme despreciar un poco ese tema. Uno de los riesgos que tiene cuando está tratando de hacer algo con un alto nivel de capacidad de respuesta, es decir, muy rápido, es que podría solucionar el problema muy, muy rápidamente, asumiendo que tiene una perfecta observabilidad y una comprensión perfecta de exactamente lo que está sucediendo, y puedes predecir perfectamente la respuesta al cambio que estás a punto de hacer. Eso es genial, y muchas veces ese es el caso. Sin embargo, también existe la posibilidad de que tu comprensión de cualquiera de esas cosas sea imperfecta, y es posible que también empeore muy, muy rápidamente.
Nadie quiere eso. Así que todo el punto sobre la seguridad es que usted pone sistemas en su lugar, y los procesos, y la automatización, y muchas otras cosas van en ella para asegurarse de que, de hecho, no lo empeora. Eso se reduce a un par de cosas de muy, muy alto nivel. Al principio. Es como el modelado proactivo. Esto se aplica realmente en gran medida a la planificación básica de la capacidad, ¿verdad? Por ejemplo, si tiene que sacar máquinas de producción por alguna razón para parcharlas porque requiere que los servicios se reinicien por cualquier razón. Uno de los riesgos que existen si intentas hacerlo muy, muy rápidamente es sacar demasiadas máquinas de la producción para la carga que están experimentando actualmente. Usted puede saber eso de antemano, ¿verdad?
Por lo tanto, tenemos muchos sistemas de modelado que se integran con los sistemas de flujo de trabajo para que cuando una solicitud para parchear todo lo más rápido posible, no retire inmediatamente todos los servidores de producción. Así que hay sistemas de seguridad básicos que puedes construir e integrar para evitar que te dispares en el pie. Y así, suponiendo que no vamos a empeorar las cosas desde esa perspectiva, solo en una perspectiva de infraestructura de planificación de capacidad pura, también queremos saber que el cambio que estamos haciendo tiene el efecto deseado a nivel de aplicación o en el nivel que sea, aplicación de observabilidad, protocolo, etc. sea lo que sea que estamos tratando de mitigar. Entonces, lo que hacemos es aprovechar un sistema que llamamos mina de carbón. Hemos blogueado y hablado de ello públicamente antes, pero la idea de que hay básicamente todo sale como lo que llamamos canario – canario en la mina de carbón.
El punto es que no sucede nada globalmente de una sola vez, no importa lo grave que sea. Un mínimo de dos fases para que algo salga. Así que lo pusimos en un subconjunto de infraestructura. Por lo general, la infraestructura que está experimentando el evento de forma más atroz o es más visible, validamos que hace lo que esperamos, y luego lo implementamos muy rápidamente más adelante. Disculpe, llévelo más ampliamente y valide que el problema general se resuelva a nivel global. Así que la mina de carbón y los canarios se integraron estrechamente con sus métricas y sistemas de observabilidad para que pueda correlacionarse de un vistazo como, ¿qué es esto? ¿Qué está haciendo este canario a las métricas agregadas que estoy viendo? Así que recibimos comentarios en tiempo real de que, oye, el cambio que estamos haciendo de hecho está abordando el problema.
Así que eso es muy, muy práctico. En lo que realmente estamos trabajando en este momento y preparándonos para lanzarnos internamente y más adelante, produciremos esto para los clientes y sus cambios de configuración, es básicamente un análisis métrico totalmente automatizado. Así que actualmente, cuando hacemos un cambio como este, se requiere que un humano se siente allí y lo mira, se asegure de que lo correcto está sucediendo y se asegure de que las métricas que les preocupan se muevan en la dirección correcta. Y luego, básicamente, avanza el canario, dile al sistema como, genial, has pasado la primera fase. Todo se ve bien. Adelante e ir a la fase global de ese canario. Hacemos esto, aprovechamos el sistema para todos los cambios, no solo, usted conoce los cambios operativos de seguridad, sino todos los cambios que fluyen en todo el sistema.
Y a lo que nos estamos topando es a medida que construimos más y más visibilidad a nuestro punto de venta, más y más visibilidad, más y más métricas, más y más información sobre lo que está sucediendo, hay más y más para que los humanos miren, ¿verdad? Y esa carga está llegando al punto en el que es demasiado alta. Y así los humanos están empezando a cometer errores, ¿verdad? Porque simplemente hay demasiados gráficos para mirar, demasiados gráficos para mirar y la gente se cansa y la gente es imperfecta de todos modos. Así que estamos lanzando un sistema llamado Birdwatcher, la cosa que mira a las canarias básicamente que hace un análisis estadístico sofisticado sobre las métricas, como cuando los cambios se están desplegando y le da un pulgar hacia arriba o un pulgar hacia abajo. Y eso está integrado con la mina de carbón para que podamos decir, Hey, de una manera automatizada, tenemos alguna indicación de que canarias es bueno, está haciendo lo que esperamos.
Y también por separado no está haciendo nada malo que no esperemos, y que, ese despliegue se llevará a cabo sin ninguna intervención humana. Tan super emocionado por eso. Eso hará que nuestra capacidad de respuesta sea aún más rápida e incluso más segura. Así que esas son las principales cosas que consideramos cuando hablamos de seguridad, ser capaces de hacer que el problema desaparezca de forma rápida y segura. El último punto que mencioné fue la redundancia, que es relativamente autoexplicativa. Hay un punto clave o filosofía que aprovechamos y desplegamos, que es básicamente un camino dual para muchos de estos cambios, tantos como podamos reunir. Entonces, lo que significa el doble camino, los dos caminos que pensamos son básicamente rápidos, el mejor esfuerzo y lentos, confiables. La idea es que operamos una gran cantidad de infraestructura en lugares muy, muy, dispares en todo el mundo.
La capacidad de golpear todo con un cien por ciento de fiabilidad en pocos segundos es un cuento de hadas. Al igual que, eso no es algo que sea factible. Algo en algún lugar es siempre una especie de tener un problema. Y realmente no hay nada que puedas hacer al respecto. Entonces, lo que hacemos es básicamente juntar estas cosas de manera similar a la seguridad, a la defensa en profundidad, ¿verdad? Al igual que, usted pone estas dos cosas juntas y, y lo que esto realmente se ve es aprovechar el camino rápido. Ve a golpear tanto como puedas. Y luego cualquier cosa que se pierda, nos aseguramos de que tengamos un camino confiable redundante que seguiremos reintentando hasta que funcione, que es un poco más lento. Así que para poner algunos números a eso, la ruta rápida tocará que haremos un cambio en aproximadamente el 99.9% de nuestra infraestructura en menos de cinco segundos, ¿verdad?
Como, y ese 99,9% es repetible y confiable. Y luego el camino lento y confiable se ejecuta en el orden de 60 segundos. Y ese sistema seguirá intentándolo hasta que tenga éxito básicamente. Así que, al aprovechar estos dos juntos, obtenemos lo mejor de ambos mundos. Y si uno de esos subsistemas cae completamente, no significa que todo esté caído, seguiremos donde necesitamos estar como máximo cinco minutos después. Así que esas dos cosas juntas nos dan esta capacidad de respuesta y agilidad con la fiabilidad que estamos buscando. Hay otras cosas como, divertidas para asegurarnos de que tenemos algunas redundancias. ¿Cómo se desactivan estos sistemas? Como muchos sistemas lo saben, chatbots integrados, por lo que es muy, muy fácil.
Cualquiera puede hacerlo desde cualquier parte del mundo en su teléfono. Muchas otras cosas tienen APIs. Hay un CLI para muchos de los subsistemas. Por lo tanto, asegurarnos de que no haya una sola forma de iniciar estas tareas es otro ejemplo de cómo tratamos de construir redundancia para que siempre podamos tener esa agilidad operativa al alcance de la mano, independientemente de lo que esté sucediendo o qué sistema en particular podría estar experimentando un problema. Nos aseguramos de tener el control y la capacidad operativa que necesitamos. Muchas de estas cosas, ya saben, son de propósito general, pero como dije, las aprovechamos tanto como podamos. Todo, desde nuestros propios flujos de trabajo de infraestructura, como sacar una máquina de la producción y parcharla hasta los cambios de configuración del cliente. Todo aprovecha el mismo sistema central que nosotros los alimentos para perros y nos apalancamos agresivamente. Así que el producto que exponemos a nuestros clientes es confiable y muy, muy sólido.
Andrew Johnson: Impresionante. Impresionante. Aprecia a ese Dave. Y Marcel, creo que hablaste de las mejores prácticas o consideraciones que los equipos de seguridad pueden aplicar a su práctica. Aprecia esos consejos. Sé que ustedes definitivamente han tratado con algunos ejemplos de día cero realmente interesantes en la naturaleza para proteger a Edgio y a nuestros clientes. Estoy seguro de que tienes algunas buenas historias y aplicaciones de estas mejores prácticas. ¿Podrías hablar un poco sobre eso?
Ejemplos de día cero: HTTP2/Restablecimiento rápido
Dave Andrews: Sí, absolutamente. Creo que el que es más pertinente o más reciente, supongo, y fue un poco interesante es, lo mencionaste anteriormente, es el ataque HTTP2/Restablecimiento Rápido. Fue una experiencia muy interesante. Así que solo para transmitirlo desde la perspectiva de Edgio, hay un pequeño blog que escribimos sobre este tipo como sucedió. HTTP2/Rapid Reset fue un ataque de día cero donde la gente se dio cuenta de que no solo la implementación de las bibliotecas de servidores HTTP2 de modo había tomado algo en el HTTP2 RFC, la especificación, la especificación del protocolo como una recomendación general y básicamente codificó eso en las propias bibliotecas. Y ese era el número de solicitudes concurrentes que se permitía ser, lo siento, las corrientes concurrentes que se permitía estar en vuelo en una conexión particular, que estaba en la especificación, escrito como un centenar.
Eso, junto con una pequeña faceta interesante de H2, que es, ya sabes, la idea de ser el multiplex – muchas y muchas solicitudes en un solo socket TCP – y la capacidad de cancelar solicitudes llevó a esta vulnerabilidad muy, muy interesante o vulnerabilidad DDoS. Todo el punto allí lo que los atacantes están buscando es algo que cuesta una pequeña cantidad para el atacante y cuesta más para el atacante, para la persona en el otro extremo Y lo encontraron en HTTP2 rápido reset. Lo que eso significaba básicamente era que el atacante podía muy, muy, muy rápidamente introducirse como un solo paquete iniciando una solicitud y luego cancelándola una y otra y otra vez, como cientos de los que están en un solo socket lo siento, en un solo paquete y enviarlo al servidor.
El servidor entonces tiene que hacer mucho más trabajo que solo enviar un solo paquete. Tenemos que crear una solicitud, a menudo tenemos que iniciar una conexión proxy. Eso es lo que hacen las CDN para ir y buscar cualquier activo que el atacante estaba solicitando. Y luego finalmente tenemos que registrar que la solicitud sucedió. Así que el hecho de que los atacantes fueron capaces de generar esas iniciaciones y la cancelación de las solicitudes es muy, muy rápido. Básicamente la mayoría, como cualquiera que haya sido víctima de ese ataque, es más caro. Era más caro procesarlos que generarlos. Y así, eso se convierte en una vulnerabilidad DDoS. Así que nos gusta que muchas otras personas en la industria corrieron, ya saben, fueron atacadas por eso.
Y todo el mundo fue atacado alrededor del mismo tiempo, lo que lo hizo particularmente interesante. Fue un ataque muy amplio. Y me encantaría entender lo que los atacantes estaban pensando cuando comenzaron eso. Porque estaban atacando a muchos, muchos, muchos proveedores, todos al mismo tiempo. Lo que descubrimos cuando empezamos a hablar con los otros proveedores y ser como, oh, ¿cuándo vieron esto? Oh, ese es exactamente el mismo tiempo que lo vimos, con el que nos topamos porque encontramos el ataque. Identificamos lo que estaba sucediendo por la observabilidad de la que habla Marcel. Y empezamos a construir mitigaciones, ¿verdad? Así que la mitigación parece agregar aún más observabilidad para llegar al centro de exactamente lo que estaba sucediendo y luego construir controles operativos que nos permitan ajustar una respuesta a ella.
Así que lo que realmente parecía era, hacer un seguimiento de cuántas veces un cliente está restableciendo las solicitudes en un socket en particular, y si el porcentaje allí va por encima de un umbral predefinido, terminar esa conexión. Así que la idea es básicamente no permitir que el atacante envíe continuamente estas solicitudes para ponerle un tope y así poder mitigar el ataque. Así que publicamos ese blog después de haber construido esa mitigación, la implementamos, la promulgamos y validamos que de hecho estaba evitando que esos ataques se repitieran. Entonces tuvimos gente de la industria que se acercaba y me gusta, oh, vimos el blog. En realidad, también nos vimos afectados por eso y estamos trabajando en la divulgación responsable. Así que nos plegamos con un grupo de la industria que trabajó como Vince, que es una parte del certificado para pasar por el flujo de divulgación responsable, asegúrese de que en este caso las personas que estaban implementando bibliotecas HTTP2 o servidores HPD tuvieron tiempo de generar parches, implementar esos parches antes de que la vulnerabilidad fuera más ampliamente publicitada.
Así que fue un flujo muy, muy interesante, interesante. Hemos sido capaces de cambiar eso muy rápidamente, ¿verdad? Como en parte por el trabajo que hacemos en higiene y operación y visibilidad y agilidad operativa, hemos sido capaces de tener un cambio muy pequeño que hacer, ¿verdad? Como, no lo era, ya sabes, oh Dios mío, tenemos que actualizar esta biblioteca y estamos como 10 versiones detrás porque no la actualizamos regularmente. No fue que era como, en realidad estamos, estamos una versión detrás, ¿verdad? Por ejemplo, porque actualizamos regularmente que el riesgo se reduce porque es un salto pequeño, lo que significa que puede hacerlo muy rápidamente mientras mantiene ese umbral de bajo riesgo que tenemos. Así que lo hicimos muy, muy rápidamente y somos capaces de desplegarlo y mitigar el ataque. Y luego pusimos el blog sin saber que el ataque había golpeado a más personas en parte para tratar de socializar no solo con nuestros clientes, sino con la industria. Como, Hey, esto es algo extraño que vimos que parece que no es nada específico para Edgio y de hecho potencialmente más aplicable. Y resultó que lo era.
Andrew Johnson: Eso es, eso es realmente interesante. Un poco interesante ver una visión interna de usted sabe, la comunidad de seguridad en todo el mundo trabajando juntos para, a usted sabe, mejorar los resultados para todos. Marcel, ¿querías añadir algo en torno a esto?
Marcel Flores: Sí, solo quería agregar una nota que yo, creo que este ejemplo fue interesante en el que la observabilidad inicial que definitivamente habíamos mostrado comportamientos extraños como Dave estaba describiendo, ¿verdad? Esta interacción de tipo de característica de protocolo de nivel inferior con los comportamientos de nivel superior de la CDN creó algunos comportamientos realmente inesperados. Y parte de eso, parte de averiguar lo que estaba pasando aquí era entender que había este desequilibrio severo, ¿verdad? Que el número de solicitudes que estábamos viendo en comparación con el número de solicitudes que realmente estábamos entregando a los clientes estaba sesgado, ¿verdad? Y eso se destacó. Y aunque ambas eran métricas que habíamos estado recopilando, no las habíamos comparado exactamente de esa manera. Así que parte del resultado de esto fue sentarse y mirarlo y decir, Hey, ¿qué, cómo podemos combinar la visibilidad que ya tenemos en algo que está hecho a medida para detectar este problema? Y pudimos hacer exactamente eso y mejorar el alcance de nuestra visibilidad mirando los datos que ya teníamos a través de una lente ligeramente diferente.
Andrew Johnson: Impresionante. Impresionante. Eso es bueno para tener en cuenta. Y gracias por eso, Marcel. Sí, chicos, así que creo que estamos, estamos terminando. Si, si hay alguna recomendación adicional que quieras compartir? Creo que cubrimos un alto nivel, algunos muy buenos.
Recomendaciones para fortalecer su postura de seguridad
Dave Andrews: Buena pregunta. Creo que una recomendación general es que la higiene es de importancia crítica. Centrándome en su observabilidad, creo que lo que llamaría es encontrar personas que puedan ayudar, ¿verdad? Como parte del valor de una propuesta de valor crítico que una empresa como Edgio proporciona es que definitivamente podemos ayudar, ¿verdad? Tienes todo un equipo de personas como Marcel y yo que están trabajando en esto y trabajando proactivamente para prevenir que clases enteras de ataques impacten a la gente. Así que encuentra gente que pueda ayudar, ¿verdad? Al igual que hay un montón de herramientas y tecnología que construimos, que la comunidad tiene disponible que puede hacer su trabajo más fácil. Cuando estamos hablando, ya sabes, generalmente cosas en Internet, un WAF es como, es el más crítico, como el más básico también, yo diría el ejemplo más crítico de algo así.
Le da la capacidad si se implementa adecuadamente, le da la capacidad de combinar la agilidad y los elementos de seguridad juntos. Por lo tanto, el Edgio WAF se ejecuta en un modo dual, lo que significa que puede implementar nuevas reglas a la producción, a las máquinas reales que lo están obteniendo, que están observando el tráfico. Y pueden ver lo que está sucediendo. Un buen ejemplo de eso fue con Log4j, que era, ya sabes, retroceder en el tiempo un poco. Cuando desarrollamos la respuesta a eso, somos capaces de desarrollar la regla muy, muy rápidamente y validarla muy, muy rápidamente. Debido a que estábamos impulsando actualizaciones de reglas y pudimos implementarlas en modo de alerta en las máquinas reales y ver que coincidieron con los ataques, mostrarles a nuestros clientes que o bien no estaban siendo atacados o estaban siendo atacados. Y luego tomar una decisión muy basada en datos para habilitar esa regla en modo de bloqueo y evitar que esos ataques lleguen a nuestros clientes. Así que combina todas esas cosas, ¿verdad? Como la velocidad de respuesta, la seguridad, la redundancia y la fiabilidad. Consiga personas que puedan ayudar. Creo que sería mi recomendación clave.
Andrew Johnson: Eso tiene mucho sentido. Aprecio eso, Dave. Sí, quiero decir, al responder a cero días, el tiempo es crítico. Así que tener estas soluciones especializadas, pero también más importante, las personas que pueden ayudarte a superar esto es clave para cerrar esa puerta a los atacantes. Así que con esos chicos muchas gracias por unirse a nosotros. También me gustaría dar las gracias al público, y te veremos en el próximo episodio. Gracias.
