Una 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 Productos – 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 mitigamos. Hoy nos acompañan Dave Andrews Edgio, Vicepresidente de Ingeniería, y Marcel Flores, científico investigador principal de Edgio.
Bienvenidos, Dave. Y Marcel, es genial tener a los dos aquí. ¿Puedes contarnos un poco acerca de ustedes mismos y de sus papeles aquí en Edgio?
Dave ANDREWS: Claro. Gracias por tenernos Andrew. Es un placer estar en. Así que soy VP de Ingeniería. He estado en Edgio para creo que solo una sombra más de 11 años. Y soy responsable de las plataformas perimetrales y de gran parte 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 de Edgio Labs, el grupo de investigación aquí en Edgio. Mi equipo trabaja para mejorar el rendimiento, la confiabilidad y las operaciones de la red realizando una investigación y desarrollo rigurosos, así como interactuando con la comunidad más amplia de investigación de sistemas y redes.
¿Qué es un día cero?
Andrew Johnson: Impresionante. Gracias de nuevo por unirse a nosotros hoy, chicos. Así que, en el tema de las amenazas de día cero, creo que es importante dar rápidamente a nuestra audiencia un antecedente sobre qué son las vulnerabilidades de día cero y los ataques. Brevemente trataré de cubrirlo 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 comercial 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 crear un parche o una solución, ¿verdad?
Por lo tanto, los desarrolladores, una vez que sepan acerca de una vulnerabilidad, van a tratar de parchearla lo más rápido posible o dar a los clientes y usuarios de ese software los pasos que pueden hacer para prevenir la vulnerabilidad. 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 aumentan cada año en un 25% en 2022 en comparación con 2021. No es súper 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 para que los buenos actores y los malos actores encuentren estas vulnerabilidades en el lado bueno, en el de los buenos actores. Hay programas de bounty bug.
Estás familiarizado con cuando Apple expulsa las correcciones de código para tu iPhone todo el tiempo. Los buenos investigadores de sombrero blanco están enviando exploits 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 hayas 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, 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 preguntando 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 es todo acerca de la defensa en profundidad, ¿verdad? Como, nunca hay ninguna cosa en particular que hagas. Se trata más de asegurarse de que tiene una serie de capas todas juntas. La idea es que si una o dos capas son imperfectas, como todas lo 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 sabes, el, todo el punto aquí es, no importa si una cosa falla porque hay otras cinco cosas sentadas allí que te protegerán. Así que, dar 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 balde de la preparación.
Hay al menos tres aspectos separados en 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 podría decirse que es una de las mejores y más críticas líneas de defensa. Significa que usted toma ventaja de todas las revelaciones responsables de las que usted estaba hablando, Andrew, los buenos investigadores de sombrero blanco, encontrar vulnerabilidades, revelarlas a los proveedores, arreglarlas, y desplegar soluciones.
Puedes aprovechar todos los vectores de ataque básicamente conocidos en el software que estás utilizando. Solo porque es 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 manejar el riesgo que viene con la actualización de todo tu 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 escanear. Lo que el punto aquí es buscar activamente cosas que son indicios de que tienes un problema antes de que un mal actor lo encuentre.
Así que esto toma varias formas. Puede ser equipos de seguridad interna o equipos de seguridad de la información. Puedes contratar a terceros para realizar escaneos. Puede ser ambas cosas. A menudo, las organizaciones aprovechan la recompensa de bugs para animar a las personas a tomar la ruta del sombrero blanco, encontrar vulnerabilidades que nos revelan a nosotros o a la parte en particular para que puedan ser arreglados antes de ser 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 mirar activamente sus propias aplicaciones, tratar de encontrar vulnerabilidades y corregirlas proactivamente lo mejor que pueda. La siguiente sección que diría acerca de la preparación, voy a pasar a Marcel, es observabilidad.
Marcel Flores: Sí, gracias Dave. Así que creo que otra cosa importante que 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 de categorías cae en dos categorías que fundamentalmente se abordan de la misma manera, pero creo que son importantes de llamar. La primera es pensar en comportamientos a nivel de aplicación, ¿verdad? Asegúrate de entender qué solicitudes entran en tu red y cuáles son las características de esas solicitudes, cómo se configuran y cómo se ven normalmente y cómo podrían verse durante ciertos eventos. Creo que también es importante, tener en cuenta que cada vez que te estás 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. Y así que es importante mantener un ojo en lo que está pasando más abajo de la pila, ¿verdad? Y entienda que puede haber comportamientos y respuestas complejos de sistemas de nivel de capa inferior que no están bien capturados en esos comportamientos de capa de aplicación. Por lo tanto, es importante realizar un seguimiento de los dos componentes de eso y tener 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? Podrías empezar a ver características de solicitudes de aplicaciones que no son lo que normalmente ves, ¿verdad? Por ejemplo, un aumento repentino en 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 intrincado 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 en ese nivel, especialmente cuando está pensando en cosas como los 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 le permitan ver lo que está pasando, sino también tener la capacidad de profundizar 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 determinado conjunto de tráfico. Hay redes específicas, son clientes específicos, propiedad específica de un determinado cliente, ¿verdad? Así que usted puede entender y acotar dónde están sucediendo las cosas realmente 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 crees que podría ser un día cero, cuáles son algunos de los pasos operacionalmente que puedes tomar?
¿Qué pasos puede tomar para mitigar las amenazas 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? Como la primera es mirar las cosas, mirar la tendencia, que se reduce desde una perspectiva, mirar las cosas en conjunto, ¿verdad? Como, ¿cómo se ve esto en general? Y todo el punto es que se obtiene una visión de alto nivel de lo que está pasando, y te permite identificar los cambios muy, muy rápidamente, como dijiste. La segunda parte en términos de buceo profundo es en realidad ser capaz de desentrañar y desarrollar su comprensión sobre qué cambio, a qué nivel está operando, y es un riesgo, ¿verdad? Como, ya sabes, Internet es el salvaje, salvaje oeste, ¿verdad? Como, 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, Dios mío, 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 al respecto es un problema. Te metes en el reino de lo semejante, genial, 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. De nuevo, tres pero esos son la capacidad de respuesta, la seguridad y la redundancia. Así que 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 poder cerrar los problemas de seguridad muy, muy rápidamente para dar a los atacantes un tiempo mínimo para causar estragos y darle la máxima cantidad de tiempo para limpiar. Así que lo que buscamos desde un sentido muy amplio, no solo en torno a cuestiones de seguridad, sino solo 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 para pensar con agilidad de operación. Así que déjenme burlarme de eso un poco aparte. Uno de los riesgos que tienes cuando estás tratando de hacer algo con un alto nivel de capacidad de respuesta, es decir, muy, muy rápidamente, es que podrías solucionar el problema muy, muy rápidamente, asumiendo que tienes una perfecta observabilidad y una perfecta comprensión 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 su comprensión de cualquiera de esas cosas sea imperfecta, y usted puede empeorar también muy, muy rápidamente.
Nadie quiere eso. Así que el punto de la seguridad es que se ponen en marcha sistemas, procesos y automatización, y muchas otras cosas entran en juego para asegurarse de que, de hecho, no empeore las cosas. Eso se reduce a un par de cosas de muy, muy alto nivel. Al principio. Es como un modelado proactivo. Esto se aplica realmente en gran medida a la planificación de la capacidad básica, ¿verdad? Por ejemplo, si usted tiene que sacar máquinas fuera de producción por alguna razón para parchearlas porque requiere que los servicios se reinicien por cualquier razón. Uno de los riesgos que hay si intentas hacer eso muy, muy rápidamente es que sacas demasiadas máquinas de la producción para la carga que están experimentando actualmente. Usted puede saber eso antes de tiempo, ¿verdad?
Por lo tanto, tenemos muchos sistemas de modelado que se integran con sistemas de flujo de trabajo para que cuando se solicita parchear todo lo más rápido posible, no saque inmediatamente todos los servidores fuera de producción. Por lo tanto, hay sistemas de seguridad básicos que puede construir e integrar para evitar que se dispare en el pie. Y así, asumiendo 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, lo que sea que estemos tratando de mitigar. Lo que hacemos es aprovechar un sistema que llamamos mina de carbón. Hemos blogueado sobre ello y hablado sobre ello públicamente antes, pero la idea es que básicamente todo sale como lo que llamamos un canario – canarios en la mina de carbón.
El punto es que nada sucede globalmente a la vez, no importa lo grave que sea. Un mínimo de dos fases para que algo salga. Así que lo ponemos en un subconjunto de infraestructura. Típicamente, la infraestructura que está experimentando el evento de manera más atroz o es más visible, validamos que hace lo que esperamos, y luego la implementamos muy rápidamente más adelante. Lo sentimos, rodar, desplegar más ampliamente y validar que el problema general se resuelve a nivel global. Así que la mina de carbón y los canarios están estrechamente integrados con sus métricas y sistemas de observabilidad para que pueda correlacionarse de un vistazo como, ¿qué es esto? ¿Qué está haciendo este canario con las métricas agregadas que estoy viendo? Así que obtenemos retroalimentación en tiempo real que, oye, el cambio que estamos haciendo es, de hecho, abordar 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 tarde, 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, requiere que un humano se siente allí y lo mire, asegúrese de que lo correcto está sucediendo, y asegúrese de que las métricas que les preocupan se mueven 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 y pasar a la fase global de ese canario. Hacemos esto, aprovechamos el sistema para todos los cambios, no solo, usted sabe los cambios operativos de seguridad, sino todos los cambios que fluyen en todo el sistema.
Y lo que nos estamos topando es a medida que construimos más y más visibilidad de 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 lo miren, ¿verdad? Y esa carga está llegando al punto donde 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 observa a los canarios básicamente que hace un análisis estadístico sofisticado de 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, Oye, de una manera automatizada, tenemos alguna indicación de que canario es bueno, está haciendo lo que esperamos.
Y también por separado no está haciendo nada malo que no esperamos, y eso, ese despliegue procederá sin ninguna intervención humana. Tan super emocionado con eso. Eso hará que nuestra capacidad de respuesta sea aún más rápida y aún más segura. Así que esas son las principales cosas que consideramos cuando hablamos de seguridad, poder hacer que el problema desaparezca de forma rápida y segura. El último punto que he mencionado ha sido 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 camino dual, 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, muy dispares en todo el mundo.
La capacidad de golpear todo con un cien por ciento de fiabilidad en unos pocos segundos es un cuento de hadas. Por ejemplo, eso no es algo que sea factible. Algo en algún lugar siempre está teniendo un problema. Y realmente no hay nada que puedas hacer al respecto. Así que lo que hacemos es básicamente poner estas cosas juntas de manera similar a la seguridad, a la defensa en profundidad, ¿verdad? Por ejemplo, juntan estas dos cosas y, y lo que esto realmente parece es aprovechar el camino rápido. Ve a golpear tanto como puedas. Y luego cualquier cosa que se pierda, nos aseguramos de tener una ruta confiable redundante que seguiremos intentando hasta que funcione, que es un poco más lento. Así que para poner algunos números a eso, el camino rápido tocará Haremos un cambio en aproximadamente el 99.9% de nuestra infraestructura en menos de cinco segundos, ¿verdad?
Como, y que el 99,9% es repetible y confiable. Y luego la ruta confiable lenta corre en el orden de 60 segundos. Y ese sistema seguirá intentando hasta que básicamente tenga éxito. Así que nosotros, aprovechando estos dos juntos, obtenemos lo mejor de ambos mundos. Y si uno de esos subsistemas cae por completo, no significa que todo esté abajo, seguiremos donde necesitamos estar 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, pequeñas y divertidas para asegurarse de que tenemos algunas redundancias. Como ¿cómo arrancar estos sistemas? Como muchos sistemas que conoces, chatbots integrados, así 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. Así que asegurarnos de que no hay una sola forma de poner en marcha estas tareas es otro ejemplo de cómo intentamos construir redundancia para que siempre podamos tener esa agilidad operativa al alcance de nuestra mano, independientemente de lo que esté sucediendo o qué sistema en particular podría estar experimentando un problema. Nos aseguramos de que tenemos el control y la capacidad operativa que necesitamos. Muchas de estas cosas, saben, son todas 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 parchearla hasta los cambios de configuración del cliente. Todo aprovecha el mismo sistema central que nosotros la comida 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 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. Aprecie esos consejos. Sé que ustedes definitivamente han lidiado 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 de eso?
Ejemplos de día cero: HTTP2/Rapid Reset
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 antes, el ataque HTTP2/Rapid Reset. 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 servidor HTTP2 en 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 fue el número de solicitudes concurrentes que se permitieron ser, lo siento, las corrientes concurrentes que se permitieron estar en vuelo en una conexión particular, que estaba en la especificación, escrita como cien.
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 meterse en un solo paquete iniciando una solicitud y luego cancelarla una y otra vez, como cientos de aquellos 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, muchas veces tenemos que iniciar una conexión proxy. Eso es lo que las CDN hacen 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 hayan podido generar esas iniciaciones y cancelación de las solicitudes es muy, muy rápido. Básicamente la mayoría, como cualquiera que haya sido objeto de ese ataque, es más caro. Era más costoso procesarlos que generarlos. Y eso se convierte en una vulnerabilidad DDoS. Así que nos gustan muchas otras personas en la industria que fueron atacadas por eso.
Y todo el mundo fue atacado aproximadamente al 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 decir, oh, ¿cuándo viste esto? Oh, ese es exactamente el mismo tiempo que lo vimos, en el que tropezamos porque encontramos el ataque. Identificamos lo que estaba sucediendo debido a la observabilidad de la que Marcel está hablando. Y empezamos a construir mitigaciones, ¿verdad? Así que esa 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 ello.
Así que lo que realmente parecía era, hacer un seguimiento de cuántas veces un cliente está restableciendo solicitudes en un socket en particular, y si el porcentaje allí supera un umbral predefinido, finalice 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, por lo tanto, ser capaz de mitigar el ataque. Así que publicamos ese blog después de haber construido esa mitigación, implementarla, promulgarla y validar que de hecho estaba evitando que esos ataques se repitieran. Luego tuvimos gente de la industria que se acercó y como, oh, vimos el blog. En realidad, también nos impactó eso y estamos trabajando en una divulgación responsable. Así que nos reunimos con un grupo de la industria que trabajó con Vince, que es una parte del cert para pasar por el flujo de divulgación responsable, asegurarnos de que en este caso la gente que estaba implementando bibliotecas HTTP2 o servidores HPD tuvieron tiempo para generar parches, implementar esos parches antes de que, la vulnerabilidad fuera más ampliamente publicitada.
Así que fue un flujo muy, muy interesante, interesante. Pudimos, darle la vuelta muy rápidamente, ¿verdad? Como en parte debido al trabajo que hacemos en higiene y operación y visibilidad operativa y agilidad, pudimos 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 era que fuera como, en realidad estamos, estamos una versión detrás, ¿verdad? Como, porque regularmente actualizamos parches, el riesgo se reduce porque es un salto pequeño, lo que significa que puedes hacerlo muy rápidamente mientras mantenemos 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 raro 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 genial para ver una vista interna de usted sabe, la comunidad de seguridad en todo el mundo trabajando juntos para, por lo que usted sabe, mejorar los resultados para todos. Marcel, ¿querías añadir algo al respecto?
Marcel Flores: Sí, solo quería añadir una nota que yo, creo que este ejemplo era interesante en el que la observabilidad inicial que habíamos mostrado definitivamente comportamientos extraños como Dave describía, ¿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 un 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 estado comparando exactamente de esa manera. Así que parte del resultado de esto fue sentarse y mirarlo y decir, Oye, ¿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 observando los datos que ya teníamos a través de una lente ligeramente diferente.
Andrew Johnson: Impresionante. Impresionante. Eso es bueno 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 tu postura de seguridad
Dave Andrews: Buena pregunta. Creo que una recomendación general es que la higiene es de vital importancia. Centrándome en tu 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 ofrece una empresa como Edgio, definitivamente podemos ayudar, ¿verdad? Tienes todo un equipo de personas como yo y Marcel que están trabajando en esto y trabajando proactivamente para prevenir que clases enteras de ataques impacten a la gente. Así que encuentra personas que puedan ayudar, ¿verdad? Al igual que hay un montón de herramientas y tecnología que construimos, que la comunidad tiene disponible que pueden hacer su trabajo más fácil. Cuando estamos hablando de, ya sabes, generalmente las cosas en Internet, un WAF es como, es el más crítico, como el más básico también, yo diría que es 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. Así que el Edgio WAF se ejecuta en un modo dual, lo que significa que puede implementar nuevas reglas en la producción, en las máquinas reales que lo están recibiendo, 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, retrocediendo en el tiempo un poquito. Cuando desarrollamos la respuesta a eso, podemos desarrollar la regla muy, muy rápidamente y validarla muy, muy rápidamente. Debido a que estábamos empujando actualizaciones de reglas y capaces de implementarlas en modo de alerta en las máquinas reales y ver que coinciden con los ataques, muestre a nuestros clientes que o bien no estaban siendo atacados o estaban siendo atacados. Y luego tome una decisión muy basada en datos para permitir esa regla en el modo de bloqueo y evitar que esos ataques lleguen a nuestros clientes. Así que combina todas esas cosas juntas, ¿verdad? Como la velocidad de respuesta, la seguridad, la redundancia y la confiabilidad. 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, cuando se responde a cero días, el tiempo es crítico. Así que tener estas soluciones especializadas, pero también, lo que es más importante, las personas que pueden ayudarle a superar esto es clave para cerrar esa puerta a los atacantes. Así que con esos chicos muchas gracias por unirse a nosotros. Me gustaría agradecer a la audiencia también, y te veremos en el próximo episodio. Gracias.
