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”.   —   , Director de Tecnología de   . Peter Klimek 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   ,   . 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. ProgrammableWeb se han agregado un promedio de 220 nuevas API cada mes desde 2019  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,   , lo que demuestra que estas prácticas de seguridad de DevOps, si bien son importantes, no son suficientes. el 85 % reconoció que sus herramientas de seguridad son ineficaces en la prevención de ataques de API  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   , las fuentes de amenazas de seguridad de API son: seguridad de API de Google Cloud  API mal configuradas (40%),  API, datos y componentes obsoletos (35 %),  Spam, Abuso, Bots (34%).  Las "API mal configuradas" o las "configuraciones incorrectas de seguridad", como categoría, son la fuente de amenazas más identificada.  Según otro estudio de   ,   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. 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),  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   : 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). es la explosión de la adopción  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:  Defensa de límites (firmas antimalware)  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   para inspeccionar todas las solicitudes que pasan por la puerta principal. IDS/IPS basados en host  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   , 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. convertir el punto de cumplimiento centralizado en múltiples micropuntos de control en cada ruta de sus aplicaciones  Para lograr efectivamente tal objetivo sin detener o ralentizar sus aplicaciones,   serían los pasos determinantes críticos. la orquestación y la automatización  ¿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:   . Este método de defensa es similar a mostrar tu pasaporte en el control del aeropuerto y tus documentos de identidad para comprar alcohol. la confianza en el acceso del usuario/dispositivo  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    , 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. Imagine agregar equipos de identificación en todos los centros de transporte  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   también requieren la misma lógica para su adopción. La necesidad es una solución que: Architecture, Application, Workload y Data  Utiliza arquitectura moderna,  Trabaja en ambientes heterogéneos,  Mitiga estos riesgos (no solo los productos básicos), y  Hace todo esto de manera automatizada en entornos de múltiples nubes  (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   , por ejemplo: debe poder implementarse en múltiples formatos y, por lo tanto, admitir diferentes configuraciones  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   y al mismo tiempo garantizar una latencia mínima y un control máximo. sobre una aplicación existente sin cambiar la arquitectura existente  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,   sin transmitir a otras nubes o motores, como un espacio aislado en la nube para el análisis. el procesamiento de seguridad debe realizarse localmente  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.    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: La última parte es considerar la orquestación.  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.  Para obtener más información sobre la arquitectura de confianza cero:   . Introducción a la arquitectura de seguridad de confianza cero: un concepto, no un producto  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🖖.

This story contains new, firsthand information uncovered by the writer.

Interested in Infosec & Biohacking. Security Architect by profession. Love reading and running.

¿Cómo usar Zero Trust Framework para la seguridad de API?

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Una breve introducción a la teoría del cerebro de Boltzmann

Telegram: el puente de Crypto Island hacia el continente

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps