Explicación de cómo ampliar la seguridad de la API desde el modelo de defensa en profundidad al modelo de confianza cero

“La pandemia impuso una urgencia inmensa a las empresas para que pusieran en marcha todo tipo de proyectos de transformación digital lo más rápido posible, y ese es casi con certeza un factor impulsor detrás de este aumento de ataques”.

— Peter Klimek , Director de Tecnología de Imperva .

Las API de DYKT se han utilizado durante más de 20 años. Desde entonces, las API han evolucionado drásticamente: desde un conjunto limitado de empresas que utilizan API para abordar necesidades específicas hasta, recientemente, una colección interminable de casos de uso en entornos DevOps de todos los tamaños. Las API se pueden encontrar en los desarrollos de aplicaciones: desarrollo ágil, conexión de clientes y socios con servicios y potenciación de iniciativas de transformación digital.

Pero con respecto a la ciberseguridad, según una investigación de ProgrammableWeb , se han agregado un promedio de 220 nuevas API cada mes desde 2019 . Sin embargo, con una adopción más amplia, las API exponen hoy más datos confidenciales que nunca, lo que las convierte en un objetivo valioso para los ataques.

Esta publicación es una introducción a cómo mapear los requisitos de API Security, desde Defense-in-Depth hasta Zero Trust Model.

Antecedentes: el estado de la seguridad de las API

Antes de entrar en cómo proteger la API, veamos el panorama actual de amenazas de la seguridad de la API. Según el Informe sobre el estado de la seguridad de las API de Salt Security:

• Los ataques a API aumentaron un 681 % en los últimos 12 meses
• El 95% de los encuestados ha experimentado un incidente de seguridad de API en el último año
• El 34 % de los encuestados carece de alguna estrategia de seguridad de API
• El 62 % de los encuestados reconoció haber ralentizado la implementación de una nueva aplicación debido a problemas de seguridad de la API.

En resumen, podemos decir que la mayoría de las empresas no están preparadas para un ataque basado en API. Además, la confianza en las herramientas de administración de API y seguridad existentes, por ejemplo, firewalls de aplicaciones web (WAF) y puertas de enlace API, podría haber evitado de manera efectiva los incidentes de seguridad y proporcionado una falsa sensación de seguridad.

¿Qué pasa con Mayús-Izquierda?

El informe destaca que las tácticas de cambio a la izquierda no están ayudando, al menos en la seguridad de la API. Más del 50 % de los encuestados dijeron que los desarrolladores, los equipos DevOps o DevSecOps son responsables de la seguridad de las API. Las empresas que gastan más en esfuerzos previos a la implementación incluyen:

• mejores prácticas de codificación segura,
• escaneado de códigos y
• Prueba manual

Sin embargo, el 85 % reconoció que sus herramientas de seguridad son ineficaces en la prevención de ataques de API , lo que demuestra que estas prácticas de seguridad de DevOps, si bien son importantes, no son suficientes.

Entonces, ¿qué protección debe construir o adoptar una organización para defenderse de los ataques de API? Para responder a esta pregunta, primero debemos comprender los ataques comunes contra la API.

El panorama actual de amenazas

En el informe reciente sobre seguridad de API de Google Cloud , las fuentes de amenazas de seguridad de API son:

1. API mal configuradas (40%),
2. API, datos y componentes obsoletos (35 %),
3. Spam, Abuso, Bots (34%).

Según otro estudio de Imperva Research Labs , el ataque más importante es la ejecución remota de código (RCE) o la inclusión remota de archivos (RFI), que aumentó un 271 %. Los piratas informáticos utilizan ataques RCE o RFI para robar información de la empresa, comprometer servidores y desfigurar sitios web, o incluso tomar el control de los sitios web.

Otras vulnerabilidades de API son, según el top 10 de OWASP API Security:

• Despliegue de API DDOS,
• ataques API de día cero,
• credenciales robadas,
• brechas perimetrales,
• movimiento lateral de brechas,
• fuga de datos en la salida, o
• secuestro de recursos

Ciberseguridad: la API es el nuevo punto final

Como se mencionó anteriormente, la primera razón del aumento del riesgo de seguridad de las API es la explosión de la adopción : muchas API en un entorno. Por ejemplo, una aplicación de Kubernetes tiene cientos de pods y microservicios. Cada uno de ellos administra media docena o más de API. (Ese es un escenario típico en un entorno DevOps).

Ahora agregue que estas cargas de trabajo de microservicios (y, por lo tanto, las llamadas a la API) son temporales, se ejecutan en nubes, están escritas en varios idiomas y usan diferentes protocolos. O, en resumen, las API crean un entorno complejo y desafiante para que el equipo de seguridad supervise la operación de la API.

En segundo lugar, las API nunca tuvieron la intención de estar expuestas al mundo exterior. Sin embargo, esto es lo que enfrentamos con las vulnerabilidades encontradas dentro de las pilas de protocolos de red. Esos desarrolladores nunca imaginarían que sus trabajos serían adoptados en la escala actual. Como resultado, las API tienen vulnerabilidades y riesgos innatos integrados en ellas.

En tercer lugar, los ataques e infracciones se han vuelto cada vez más sofisticados, especialmente aquellos ejecutados en la fase posterior a la autenticación y autorización. También son más profundos dentro de la carga de datos de la API.

Por lo tanto, es necesario mirar la seguridad más allá de la autenticación y la autorización, también la aplicación y la capa de carga de datos de la API. Una forma de hacerlo es pensar en API Security como algo análogo a nuestra seguridad tradicional para Endpoint.

DiD (Defensa en profundidad), ¡otra vez!

Los problemas de seguridad también ocurren en nuestra vida diaria fuera de las computadoras. Desde las primeras etapas de la historia humana, varios países han estado explorando y practicando múltiples mecanismos de defensa y fortificaciones. Estas experiencias e ideas también se aplican a la seguridad de terminales, redes y API.

Digamos que Endpoint Software es análogo al castillo:

• La autenticación de identidad es igual a la prueba de identificación de los comandantes, y
• Los honeypots (o señuelos en guerra) alejan a los atacantes de objetivos de alto perfil.
• Entre estas estrategias de guerra, una de las más efectivas es la Defensa en Profundidad (DiD).

El enfoque de DiD se puede dividir en dos áreas:

1. Defensa de límites (firmas antimalware)
2. Detección/prevención de intrusiones (IDS/ IPS/ EDR)

Explicaré la seguridad de la API con estas áreas DiD una por una.

1 # Defensa de límites

La defensa de límites es el tipo más básico de defensa. Casi todas las empresas invierten en defensas fronterizas. En la seguridad de endpoints, utilizamos firmas y listas de denegación de IP para defendernos de métodos de ataque conocidos.

Como primera línea de protección, esta capa tiene como objetivo detener el 90% de todos los ataques, no dirigidos e iniciados por personas no calificadas que no tienen conocimientos técnicos sólidos o una mentalidad de hacker. En este escenario, la defensa de límites puede resistir suficientemente bien estos ataques indiscriminados.

En API Security, WAF está haciendo un excelente trabajo en esta área. Ofrece características estándar para la defensa de límites:

· Listas de IP permitidas y denegadas,

· Motor de reglas WAF,

· Limitación de velocidad, y

· inyección de fallas/fuzzing.

Cuando se combina, puede bloquear casi todos los ataques de mercancías.

2# Detección de intrusos (++)

La visibilidad de la seguridad es un elemento crítico de la prevención de ataques. Después de que un pirata informático haya violado el perímetro, necesitamos una forma adecuada de identificar qué archivo/proceso/tráfico está probablemente relacionado con el ataque malicioso. En Endpoint Software, tenemos IDS/IPS basados en host para inspeccionar todas las solicitudes que pasan por la puerta principal.

Algunos otros métodos de detección, como la detección APT y el aprendizaje automático, podrían ser más intuitivos para evaluar frente a ataques dirigidos.

Otras formas típicas de implementar el análisis de comportamiento son:

· tarros de miel,

· EDR (Detección y respuesta de punto final), y

· Inteligencia de amenazas (archivo y proceso).

Entre todos esos métodos, los honeypots son uno de los más antiguos (desde el comienzo de las guerras). Al atraer a algunos objetivos de alto valor a trampas/señuelos, pueden analizar los comportamientos del enemigo e incluso ayudar a localizarlos. Hoy en día, adoptamos estas tácticas y las convertimos en técnicas de engaño.

En el mundo moderno, las soluciones de seguridad API brindan combinaciones de las técnicas mencionadas; por ejemplo, los artefactos recopilados en los honeypots pueden luego enviarse a la fuente de inteligencia de amenazas para el consumo de WAF o Protección de API y aplicaciones web (WAAP). En esta capa, tenemos técnicas similares para mejorar la visibilidad y la velocidad para detener un ataque:

· Honeypots de red

· NDR (Detección y respuesta de red), y

· Inteligencia de amenazas (carga útil y red).

El uso de bots para ejecutar ataques de "relleno de credenciales" es otra táctica de ataque común. Intenta robar activos de alto valor. La estrategia es encontrar una manera de obtener información de inicio de sesión, como correos electrónicos/contraseñas filtrados, y luego intentar acceder a ubicaciones de red en lotes (movimiento lateral). Con mucho, la defensa más eficiente para combatir el relleno de credenciales es desde la fuente: identifique el bot de los usuarios reales para interceptar todas las solicitudes realizadas por el bot.

Como tal, algunas herramientas de AppSec también equipan funciones anti-bots, un tipo específico de detección de comportamiento como parte de la seguridad de la API.

Cuando la seguridad de API se encuentra con Zero Trust

No estoy diciendo que DiD sea inútil. Soluciones de seguridad de aplicaciones y API, como la protección WAF para organizaciones contra ataques de productos básicos. Sin embargo, como se mencionó, la API crea un entorno complejo y la mala configuración empeora el problema.

Con un perímetro no despejado, es posible que se necesite más que un enfoque DiD. Zero Trust esencialmente pone obstáculos en todas partes para los atacantes, lo que les impide moverse lateralmente dentro del entorno.

Zero Trust es un marco y una estrategia de seguridad integral. Requiere pasos de verificación estrictos y unificados para todos los terminales, BYOD (traiga sus propios dispositivos), servidores, API, microservicios, almacenamiento de datos y servicios internos.

La idea principal de Zero Trust es convertir el punto de cumplimiento centralizado en múltiples micropuntos de control en cada ruta de sus aplicaciones , incluidas las API. Ya sea una solicitud externa de acceso interno, un teléfono móvil o una PC, una llamada API o una solicitud HTTP, un empleado común o un director ejecutivo, no se puede confiar en ninguno.

Para lograr efectivamente tal objetivo sin detener o ralentizar sus aplicaciones, la orquestación y la automatización serían los pasos determinantes críticos.

¿Por qué la orquestación y la automatización son cruciales para la seguridad de la API Zero Trust?

ZTA, NIST SP800–207 | Imagen del autor

Para explicar la necesidad de los dos, echemos un vistazo más de cerca a un pilar de la arquitectura Zero Trust: la confianza en el acceso del usuario/dispositivo . Este método de defensa es similar a mostrar tu pasaporte en el control del aeropuerto y tus documentos de identidad para comprar alcohol.

Sin la correspondiente identidad y autoridad, es imposible ingresar al sistema relacionado. Aquí es donde una puerta de enlace API cobra fuerza, ya que proporciona algunas funciones de autenticación clave:

• Rotación automática de llaves
• Integración con múltiples sistemas de autenticación como OKTA y Auth 2.0
• Admite cifrado de tráfico TLS y mTLS

Hay dos componentes principales de User and Device Trust:

• Gestión de identidad y acceso
• API Gateway con seguridad integrada

Imagine agregar equipos de identificación en todos los centros de transporte , como aeropuertos y trenes de alta velocidad. También debe comprender todas las rutas hacia y desde todos los centros de transporte e implementar medidas de seguridad.

En una gran empresa, habrá cientos de sistemas, decenas de miles de API y microservicios y cientos de miles de clientes. A menos que tengamos recursos y tiempo ilimitados, el equipo de DevOps, Seguridad o Aplicaciones no puede definir y agregar manualmente cientos de miles de comprobaciones de microidentificación en las aplicaciones modernas.

Todos los demás pilares de Zero Trust Architecture, Application, Workload y Data también requieren la misma lógica para su adopción. La necesidad es una solución que:

1. Utiliza arquitectura moderna,
2. Trabaja en ambientes heterogéneos,
3. Mitiga estos riesgos (no solo los productos básicos), y
4. Hace todo esto de manera automatizada en entornos de múltiples nubes
5. (opcional) de código abierto, de modo que permita la agilidad y la creatividad de la tecnología.

¿Cómo es la seguridad de la API de Idea Zero Trust?

Para adoptar los entornos complejos y heterogéneos de la API, la solución Zero Trust API Security debe poder implementarse en múltiples formatos y, por lo tanto, admitir diferentes configuraciones , por ejemplo:

• Contenedor Docker,
• Un proxy inverso independiente,
• Agente para servidor web/de aplicaciones, o
• Integrado en el controlador de entrada de Kubernetes.

Con el apoyo de la nube y la arquitectura de aplicaciones modernas, se cuidaría la automatización y la escalabilidad.

Pero para mantener la orquestación, el "agente" (o punto de microaplicación) debe poder implementarse sobre una aplicación existente sin cambiar la arquitectura existente y al mismo tiempo garantizar una latencia mínima y un control máximo.

Después de considerar los factores de forma de implementación y arquitectura, también es esencial que el nivel de seguridad no se degrade. Para que se adopte genuinamente Zero Trust, el procesamiento de seguridad debe realizarse localmente sin transmitir a otras nubes o motores, como un espacio aislado en la nube para el análisis.

Si las partes externas no están bajo nuestro control, es difícil verificar la confianza del acceso a datos/red. Hay algunos otros beneficios de hacerlo localmente, tales como:

• Los datos confidenciales no salen del entorno protegido.
• No necesita compartir certificados y claves privadas con terceros.
• No depende del tiempo de actividad de terceros para procesar el tráfico.

La última parte es considerar la orquestación. Idealmente, necesitamos una solución que pueda infundirse en el entorno de la aplicación, mientras que un orquestador puede administrar esos agentes y encargarse de las siguientes operaciones:

• altas/bajas de agentes
• actualización de la política
• actualización de configuración
• actualización de software
• registro y
• Sincronización de datos.

En resumen, Zero Trusted API Security debe tener varias formas para integrarse en los entornos de aplicaciones modernas. Mientras tanto, la mejor solución debería ser capaz de proporcionar orquestación y todas las funciones de seguridad que pueden proporcionar las soluciones tradicionales.

Entonces, como saben, la confianza cero no es impecable. Las soluciones de confianza cero no pueden defenderse completamente contra los ataques de ingeniería social o de día cero, aunque pueden reducir significativamente la superficie y el impacto de los ataques.

Ultimas palabras

Las API se han convertido en el sistema nervioso central de las aplicaciones modernas, trayendo información y datos críticos de una parte de la aplicación a otra o de una aplicación a otra. Como resultado, la seguridad de la API debe ser la prioridad al proteger las aplicaciones. Esto es particularmente cierto para las API públicas, con usuarios de todo el mundo que acceden a componentes de software y datos confidenciales.

La adopción de Zero Trust Framework cambia el enfoque de una protección única a diferentes pilares (Usuarios, Dispositivos, Redes, Aplicaciones y Datos). Eso puede ayudarlo a garantizar que cada parte del acceso a la API, ya sea dentro o fuera del perímetro, esté bajo el enfoque de privilegios mínimos y monitoreado continuamente.

Gracias por leer. Que InfoSec te acompañe🖖.