Automatice la seguridad con F5 NGINX App Protect y F5 NGINX Plus para reducir el coste de las brechas de seguridad

NGINX | 07 de julio de 2022

Puede que le sorprenda saber que el dinero que invierte en mejorar su postura de seguridad mediante la automatización y la inteligencia artificial (IA) acaba permitiéndole ahorrar cantidades mucho mayores. En su Informe sobre el coste de una filtración de datos de 2021, el equipo de IBM Security revela que una brecha de seguridad cuesta a las organizaciones que no cuentan con automatización de la seguridad ni IA, de media, nada menos que un 80 % más que a aquellas que las han implementado por completo: 6,71 millones de dólares frente a 2,90 millones, una diferencia de 3,81 millones. Al dar prioridad a la automatización de la seguridad y la IA, las organizaciones pueden identificar y contener una brecha con mayor rapidez, lo que les permite ahorrar tiempo y dinero.

Gráfico de barras que muestra el coste medio de una filtración de datos según el nivel de implementación de la automatización de la seguridad
Las filtraciones de datos cuestan millones más a las organizaciones que no cuentan con automatización de la seguridad e IA
(Fuente: Informe sobre el coste de una filtración de datos de 2021)

Sin embargo, al integrar la seguridad en su canalización de CI/CD, es importante no sobrecargar las herramientas. Cuantas menos veces inspeccione el tráfico, menor será la latencia que introduzca. La conclusión desde el punto de vista empresarial es que la complejidad técnica es enemiga de la agilidad.

En F5 NGINX, ofrecemos una plataforma de seguridad única por su integración fluida y su capacidad para ayudar a los equipos a «desplazar la seguridad a la izquierda» durante el ciclo de vida del desarrollo de software. Cuando las organizaciones integran la «seguridad como código» en su canalización de CI/CD, hacen posibles la automatización de la seguridad y la IA, lo que genera el enorme ahorro descrito por IBM. Al incorporar la seguridad en cada etapa del desarrollo de aplicaciones y API, los archivos de configuración y de políticas de seguridad se procesan como código, y el equipo de SecOps puede crear y mantener una política de seguridad declarativa para que DevOps la utilice al desarrollar aplicaciones. Estas mismas políticas pueden aplicarse repetidamente a nuevas aplicaciones, automatizando así la seguridad en la canalización de CI/CD.

Analicemos el tema en profundidad y veamos tres fases del procesamiento del tráfico en las que F5 NGINX App Protect y F5 NGINX Plus le ayudan a automatizar las medidas de protección de seguridad:

  • Fase 1 – F5 NGINX App Protect DoS detecta los ataques de denegación de servicio (DoS) y protege frente a ellos
  • Fase 2 – F5 NGINX App Protect WAF protege frente a los 10 principales riesgos de OWASP y los bots maliciosos
  • Fase 3 – F5 NGINX Plus autentica a los clientes de aplicaciones y API y aplica los requisitos de autorización mediante funciones nativas e integraciones con soluciones de inicio de sesión único (SSO) de terceros

Diagrama de una solución de seguridad en tres fases para gestionar de forma eficiente el tráfico de las aplicaciones, bloquear el tráfico ilegítimo y automatizar la seguridad mediante NGINX App Protect DoS y WAF, además de NGINX Plus
Una solución de seguridad en tres fases para gestionar de forma eficiente el tráfico de las aplicaciones, bloquear el tráfico ilegítimo y automatizar la seguridad, ahorrando tiempo y dinero

Esta solución de seguridad de tres componentes le permite ahorrar dinero de dos maneras, especialmente en un entorno de nube pública:

  1. Solo el tráfico legítimo llega a sus aplicaciones, ya que NGINX App Protect DoS filtra el tráfico procedente de ataques DoS y, a continuación, NGINX App Protect WAF elimina múltiples vectores de ataque, como los incluidos en el OWASP Top 10.
  2. El diseño altamente eficiente y basado en eventos de NGINX Plus permite procesar una enorme cantidad de solicitudes por segundo con un bajo consumo de CPU. Procesar únicamente el tráfico legítimo de las aplicaciones en una plataforma de alta eficiencia requiere muchos menos recursos informáticos, lo que permite ahorrar tiempo y dinero y garantiza la protección frente a múltiples vectores de ataque sin sobrecargar las herramientas.

Si actualmente utiliza F5 BIG-IP Advanced WAF para proteger las aplicaciones que se ejecutan en su centro de datos, puede añadir fácilmente NGINX Plus como controlador de Ingress para Kubernetes con NGINX App Protect DoS y WAF, lo que proporciona una solución integral para escalar y proteger sus aplicaciones modernas y orquestar aplicaciones de Kubernetes en la nube. Mediante el enfoque de seguridad como código de F5, puede definir como código los controles de las políticas de infraestructura y seguridad a través de una API declarativa o de definiciones declarativas con formato JSON en un archivo, y también puede convertir archivos XML de BIG-IP en archivos JSON. Sus políticas —los controles de seguridad corporativos estándar gestionados y mantenidos por SecOps— pueden almacenarse en un repositorio de código, desde donde se recuperan y se integran en su canal de desarrollo como cualquier otro fragmento de código. Este enfoque ayuda a DevOps y SecOps a salvar las brechas operativas y lanzar aplicaciones al mercado con mayor rapidez, menor coste y mejor seguridad.

F5 integra la creación y el establecimiento de una línea base de las políticas de WAF en el proceso de desarrollo, una parte importante del enfoque de «desplazar la seguridad a la izquierda» en el flujo de desarrollo de aplicaciones y de la automatización de su despliegue.

Las herramientas de visibilidad de BIG‑IP y NGINX se complementan entre sí y permiten a los equipos de SecOps integrar los procesos de automatización desde las primeras etapas del ciclo de vida de DevOps. BIG‑IP permite a los equipos convertir archivos XML en archivos JSON que utiliza NGINX para mantener unas políticas de seguridad coherentes. NGINX permite a los equipos ajustar las aplicaciones ya implantadas, al tiempo que incorpora una automatización moderna de la seguridad de las aplicaciones para ayudar a mitigar futuras brechas y el coste de esos posibles ataques.

Fase 1: NGINX App Protect DoS protege frente a ataques DoS

La primera etapa de nuestro recorrido hacia una gestión segura del tráfico consiste en detectar y bloquear los ataques de denegación de servicio (DoS). Detener este abuso desde el principio constituye una primera línea de defensa imprescindible.

Ya hemos señalado anteriormente que los atacantes están sustituyendo cada vez más los ataques volumétricos tradicionales por el uso de solicitudes HTTP y HTTPS o llamadas a API para atacar en la capa 7. ¿Por qué? Porque siguen el camino de menor resistencia. Los ingenieros de infraestructuras llevan años desarrollando defensas eficaces contra los ataques de las capas 3 y 4, por lo que estos son más fáciles de bloquear y tienen menos probabilidades de éxito. Los ataques de capa 7 pueden eludir estas defensas tradicionales.

No todos los ataques DoS son volumétricos. Los ataques diseñados para consumir recursos del servidor mediante métodos de baja intensidad y larga duración, como Slow POST o Slowloris, pueden ocultarse fácilmente entre el tráfico legítimo. Y aunque los frameworks de código abierto para llamadas a procedimientos remotos mediante HTTP/2, como gRPC, ofrecen la velocidad y la flexibilidad necesarias para las aplicaciones modernas, su naturaleza abierta puede hacerlos más vulnerables a los ataques DoS que los protocolos propietarios.

A diferencia de las protecciones tradicionales contra ataques DoS, NGINX App Protect DoS detecta los ataques actuales mediante el análisis automatizado del comportamiento de los usuarios y del sitio, comprobaciones proactivas del estado y una configuración sin intervención. Es una solución de baja latencia para detener ataques habituales como la inundación HTTP GET, la inundación HTTP POST, Slowloris, Slow read y Slow POST.

Para combatir estos ataques, los equipos de SecOps y DevOps deben integrar la automatización de la «seguridad como código» en su flujo de trabajo de CI/CD como parte del enfoque shift-left. NGINX App Protect DoS lo hace posible. Protege las aplicaciones y API modernas y distribuidas frente a las amenazas de DoS mediante funciones avanzadas, y ayuda a armonizar las prioridades, a veces contrapuestas, de SecOps y DevOps al facilitar este modelo con un paquete de software ligero, un ciclo continuo de retroalimentación para la mitigación de amenazas y la integración con herramientas de DevOps conocidas mediante API RESTful.

NGINX App Protect DoS integra la tecnología de aprendizaje automático (ML) que el informe de IBM Security destaca como clave para lograr un ahorro de costes significativo. Analiza el comportamiento de los clientes y el estado de la aplicación para modelar los patrones de tráfico normales, utiliza algoritmos exclusivos para crear un modelo estadístico dinámico que ofrece la protección más precisa e implementa firmas dinámicas para mitigar automáticamente los ataques. También mide continuamente la eficacia de la mitigación y se adapta a los cambios en el comportamiento o el estado de la aplicación. Estas funciones permiten a NGINX App Protect DoS bloquear ataques DoS en los que cada solicitud maliciosa parece completamente legítima, e incluso un único atacante puede generar menos tráfico que el usuario legítimo medio.

Diagrama que muestra ocho tipos de ataques bloqueados por NGINX App Protect WAF y DoS
Fases 1 y 2 de la solución de seguridad: seguridad de las aplicaciones con un procesamiento eficiente del tráfico mediante
NGINX App Protect DoS y WAF

Fase 2: NGINX App Protect WAF protege frente a las diez principales amenazas de OWASP

Aunque la protección contra ataques DoS impide claramente que el tráfico malicioso entre en su infraestructura, algunos ataques aún pueden conseguir atravesarla. Por eso necesita un firewall de aplicaciones web (WAF) para la siguiente fase de una defensa eficaz, centrada en el tráfico de agentes maliciosos que se hace pasar por legítimo.

Ligero y de alto rendimiento, NGINX App Protect WAF proporciona una protección de seguridad integral que inspecciona las respuestas, garantiza el cumplimiento del protocolo HTTP, detecta técnicas de evasión, oculta números de tarjetas de crédito y otra información personal confidencial mediante Data Guard, y comprueba si hay metacaracteres y tipos de archivo no permitidos, código JSON y XML con formato incorrecto y parámetros confidenciales. También ofrece protección frente a la versión actualizada del Top 10 de OWASP:

Control de acceso deficiente
Fallos criptográficos
Inyección
Diseño inseguro
Configuración de seguridad incorrecta
Componentes vulnerables y obsoletos
Fallos de identificación y autenticación
Fallos de integridad del software y los datos
Fallos en el registro y la supervisión de la seguridad
Falsificación de solicitudes del lado del servidor

No es de extrañar que sigan siendo populares los ciberataques dirigidos contra vulnerabilidades del Top 10 de OWASP, como A03:2021 Inyección. En julio de 2021, el sitio de comercio electrónico de código abierto WooCommerce anunció que muchos de sus complementos eran vulnerables a la inyección SQL, y en aquel momento se estaban produciendo varios ataques. Dado que las empresas y los clientes operan principalmente en línea, es lógico que los atacantes se centren en las aplicaciones web, que suelen ser complejas, estar compuestas por microservicios y abarcar entornos distribuidos con numerosas API que se comunican entre sí, lo que aumenta el número de puntos de conexión susceptibles de ser explotados.

Los ataques modernos también cambian y se adaptan rápidamente. Aquí es donde entra en juego la IA y por qué IBM destacó su importancia. Al igual que en NGINX App Protect DoS, el avanzado sistema de aprendizaje automático de NGINX App Protect WAF facilita que los equipos de operaciones de plataforma, DevOps y SecOps compartan datos y tendencias sobre los ataques. Una nueva funcionalidad, Clasificación adaptativa de infracciones, aprovechará aún más el aprendizaje automático al detectar cambios en el comportamiento de una aplicación. Gracias a esta capacidad, NGINX App Protect WAF evalúa constantemente el comportamiento predictivo de cada aplicación. A partir de este aprendizaje, puede permitir solicitudes de clientes que, de otro modo, se bloquearían, lo que reduce la puntuación de infracciones de una aplicación y disminuye considerablemente los falsos positivos para ofrecer una mejor experiencia de usuario con menores costes de gestión.

NGINX App Protect WAF también ofrece protección contra bots. Actualmente, casi el 50 % del tráfico de Internet procede de bots. Al eliminar de entrada el tráfico malicioso conocido, NGINX App Protect WAF puede bloquear rápidamente el tráfico de bots mediante su base de datos de firmas de bots.

Introducir un WAF como capa de seguridad en las primeras fases de la canalización de CI/CD ayuda a mitigar los riesgos de seguridad. Dado que NGINX App Protect WAF se integra fácilmente con CI/CD, puede incorporar y automatizar la seguridad como código desde las primeras etapas del proceso de desarrollo de aplicaciones. Al fomentar desde el principio la concienciación sobre la seguridad y una colaboración adecuada entre los equipos, también se eliminan cuellos de botella, como los riesgos asociados a la entrega. La protección multicapa contra ataques DoS y mediante WAF crea numerosos puntos de inspección, lo que permite a los equipos de seguridad supervisar el uso de las aplicaciones y a los equipos de aplicaciones saber cómo se mantienen.

Fase 3: NGINX Plus autentica y autoriza a los clientes de aplicaciones y API

Incluso después de que NGINX App Protect Dos y NGINX App Protect WAF filtren el tráfico malicioso, aún debe verificar que los clientes sean legítimos y estén autorizados para acceder a los recursos que solicitan. Aquí es donde NGINX Plus entra en juego, encargándose de la autenticación y la autorización y, a continuación, dirigiendo las solicitudes a los servidores adecuados. Al implementar NGINX Plus como puerta de enlace de API, puede proporcionar un único punto de entrada coherente para varias API y, una vez más, simplificar su infraestructura.

La autenticación y la autorización también se pueden automatizar mediante el inicio de sesión único (SSO), lo que permite a los equipos de DevOps mantener la agilidad deseada. NGINX Plus es compatible con OpenID Connect (OIDC), una capa de identidad basada en el protocolo OAuth 2.0. En la documentación de NGINX, explicamos cómo usar OIDC para habilitar el SSO en aplicaciones que utilizan NGINX Plus como proxy.

Fase 3 de la solución de seguridad: autenticación y autorización mediante NGINX Plus y ejemplos compatibles con proveedores de identidad (IdP) OAuth 2.0/OIDC para el inicio de sesión único (SSO)

Dada su característica naturaleza abierta, las API son objetivos vulnerables. En su informe anual, Gartner Research predijo que las API se convertirían en el vector de ataque más habitual durante 2022, provocando innumerables filtraciones de datos en aplicaciones web empresariales. Esa predicción se está cumpliendo a medida que avanza 2022 y observamos que la superficie de ataque de las API sigue creciendo en las organizaciones.

El informe sobre incidentes de autenticación de API: Informe de protección de aplicaciones de 2020 de F5 Labs destaca tres motivos habituales de los incidentes relacionados con las API:

  1. Sin autenticación en los endpoints de la API
  2. Autenticación de API defectuosa
  3. Autorización de API defectuosa

Sin autenticación en los endpoints de la API

Al implementar la autenticación del tráfico de la API, los clientes que demuestran correctamente su identidad reciben un token de un proveedor de identidad de confianza. A continuación, el cliente presenta el token de acceso con cada solicitud HTTP. Antes de que la solicitud se transfiera a la aplicación, NGINX Plus garantiza la autenticación y autorización del cliente validando el token y extrayendo la identidad y otros datos (por ejemplo, la pertenencia a grupos) codificados en él. Si el token se valida y el cliente está autorizado para acceder al recurso, la solicitud se transfiere al servidor de aplicaciones. Existen varios métodos para realizar esta validación, pero OpenID Connect (basado en el protocolo OAuth 2.0) es una forma habitual de habilitar la autenticación de solicitudes de API por parte de terceros.

Sin embargo, muchas de las API disponibles en el mercado carecen de protección en la capa de autenticación. En 2021, se descubrió que la plataforma de fitness interactivo Peloton tenía una API con filtraciones. Un investigador de seguridad descubrió que era posible realizar solicitudes no autenticadas a la API de Peloton y obtener fácilmente datos de usuarios sin autenticación. Aunque Peloton corrigió el código antes de que se produjera una brecha importante, este incidente pone de manifiesto que un enfoque monolítico de la seguridad no tiene en cuenta la multiplicidad inherente de las estructuras de las API ni la consiguiente necesidad de agilidad para protegerlas.

Autenticación de API defectuosa

Las API están diseñadas para conectar ordenadores entre sí, por lo que muchos equipos de DevOps dan por sentado que las personas no interactúan con el endpoint de la API. Un ejemplo recogido en el informe de F5 Labs es el de un investigador que encadenó varias solicitudes a una API para «ganar» cientos de miles de dólares en créditos en una aplicación móvil. La aplicación generaba continuamente tokens diseñados para evitar abusos, pero no establecía fechas de caducidad, lo que permitía utilizarlos una y otra vez.

Si no se validan correctamente los tokens de autenticación de la API, los atacantes pueden aprovechar sus vulnerabilidades. Si este tipo de vulnerabilidad lo descubre un agente malicioso en lugar de un investigador, puede poner en peligro a toda una empresa.

Autorización de API defectuosa

Una autenticación de API fallida conduce inevitablemente a una autorización de API deficiente. El informe de F5 Labs también describe un incidente en el que un error del sistema operativo permitió enviar solicitudes HTTP maliciosas a la API, lo que facilitó a los ciberdelincuentes el acceso a tokens de autorización. Una vez que los atacantes obtuvieron este token de autorización, consiguieron permisos de administrador.

NGINX ofrece varios métodos para proteger las API y autenticar a sus clientes. Para obtener más información, consulte la documentación sobre las listas de control de acceso basadas en direcciones IP (ACL), la autenticación mediante certificados digitales y la autenticación HTTP básica. Además, NGINX Plus admite de forma nativa la validación de tokens web JSON (JWT) para la autenticación de API. Obtenga más información en el artículo Autenticación de clientes de API con JWT y NGINX Plus de nuestro blog.

Empieza hoy mismo

Automatizar la seguridad hace que sea responsabilidad de todos. Al dar prioridad a la automatización de la seguridad, su organización puede crear aplicaciones más fiables, mitigar riesgos, reducir los gastos operativos y acelerar el ritmo de publicación. Esto permite que sus microservicios, aplicaciones y API cuenten con una seguridad ágil, escalable y lo suficientemente rápida como para seguir el ritmo de la competencia actual.

Esta estructura de seguridad en tres fases también ofrece el flujo óptimo, ya que no conviene sobrecargar el WAF inspeccionando el tráfico de un ataque DoS ni malgastar recursos valiosos intentando autenticar y autorizar a actores maliciosos. Al eliminar cuanto antes los ataques fáciles de identificar, puede ahorrar tiempo y dinero, además de mejorar el rendimiento de su aplicación.

¿Quieres probar NGINX Plus y NGINX App Protect? Empieza una prueba gratuita de 30 días hoy mismo o ponte en contacto con nosotros para hablar sobre tus casos de uso.


Compartir

Sobre los autores

Thelen Blum
Thelen BlumResponsable sénior de marketing de producto, NGINX App Protect | F5

Más artículos de Thelen Blum
Matthieu Dierick
Matthieu DierickArquitecto de Soluciones Globales | F5

Más artículos de Matthieu Dierick

Artículos relacionados del blog

Únete a F5 NGINX en AppWorld 2024
NGINX | 04/01/2024

Únete a F5 NGINX en AppWorld 2024

Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
NGINX | 26/09/2023

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source

La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.

Exposición de APIs en Kubernetes
NGINX | 10/03/2022

Exposición de APIs en Kubernetes

La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
NGINX | 23/08/2021

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto

Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.

Presentamos NGINX Plus R22
NGINX | 09/06/2020

Presentamos NGINX Plus R22

NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.

Presentamos NGINX Plus R17
NGINX | 11/12/2018

Presentamos NGINX Plus R17

NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.