pathfinding_labs_aws

Pathfinding Labs: el “parque de atracciones” en AWS Security

Hace tiempo que no encontraba un proyecto open source tan útil para practicar seguridad cloud de forma realista. Esta semana descubrí Pathfinding Labs, un framework creado por el equipo de seguridad de Datadog que despliega entornos AWS intencionadamente vulnerables para practicar ataques, validar detecciones y entender cómo se producen realmente los movimientos laterales y las escaladas de privilegios en la nube.

Y sinceramente, me parece una de las mejores ideas que han salido últimamente para cualquiera que trabaje en cloud security, red teaming, CSPM o hardening de AWS.

¿Qué es exactamente Pathfinding Labs?

El proyecto gira alrededor de más de 100 laboratorios desplegables en AWS que recrean configuraciones inseguras reales:

  • Escaladas de privilegios IAM
  • Roles excesivamente permisivos
  • Lambdas públicas con privilegios administrativos
  • Buckets S3 expuestos
  • Chains multi-hop entre cuentas
  • Toxic combinations de servicios AWS

La idea es sencilla pero potente:

  1. Despliegas un entorno vulnerable en una cuenta sandbox.
  2. Lo explotas manualmente o con scripts automatizados.
  3. Validas si tus herramientas CSPM/SIEM detectan el problema.
  4. Destruyes todo cuando terminas.

Todo automatizado.

How Pathfinding Labs works: blue team and red team workflows from enabling labs to cleanup

Lo interesante: no es teoría, es práctica real

Lo que más me llamó la atención es que esto no es una colección de “ejemplos académicos”.

Cada laboratorio:

  • despliega recursos reales en AWS,
  • crea permisos IAM funcionales,
  • incluye scripts de explotación,
  • y valida que el ataque funciona de verdad.

Eso elimina muchísimo “falso positivo mental” que vemos a veces en artículos de seguridad cloud donde algo parece explotable… hasta que intentas hacerlo.

Aquí cada path está probado.

La filosofía detrás del proyecto me parece brillante

El proyecto nace de otro recurso muy interesante llamado pathfinding.cloud, un catálogo de técnicas de privilege escalation en AWS.

Pero los autores dieron un paso más:

“No queremos publicar paths teóricos. Queremos demostrar que funcionan.”

Así que empezaron creando laboratorios Terraform para validar cada técnica documentada.

Y acabaron construyendo un ecosistema completo de labs reutilizables.

El workflow es absurdamente cómodo

Han creado una CLI llamada plabs que abstrae Terraform completamente.

El flujo típico es algo así:

plabs init
plabs

Eso abre una TUI interactiva donde puedes activar laboratorios con el teclado.

Después:

plabs apply

Y automáticamente despliega los entornos vulnerables.

Cuando quieras probar el ataque:

plabs demo iam-002-iam-createaccesskey

Y el propio framework ejecuta la explotación paso a paso.

Finalmente:

plabs destroy

Y limpia todos los recursos.

Algunos escenarios son especialmente buenos

Hay laboratorios bastante realistas y muy útiles para equipos cloud security:

Escaladas IAM clásicas

Por ejemplo:

  • iam:CreateAccessKey
  • iam:PassRole
  • lambda:UpdateFunctionCode
  • ssm:SendCommand

Escenarios que muchísima gente subestima en auditorías AWS.

Multi-hop attacks

Aquí es donde el proyecto se pone realmente interesante.

No se limitan a:

“usuario A puede asumir rol B”.

También modelan cadenas completas:

User → RoleA → RoleB → AdminRole

O movimientos laterales entre cuentas AWS distintas.

Eso se acerca muchísimo más a cómo funcionan los ataques cloud reales.

“Attackers think in graphs”

Hay una frase de John Lambert que mencionan y que define perfectamente el problema:

“Defenders think in lists. Attackers think in graphs.”

Y es totalmente cierto en cloud.

Muchos equipos siguen viendo permisos IAM de forma aislada:

  • “este rol parece seguro”
  • “esta Lambda no tiene admin”
  • “este bucket no es público”

Pero cuando conectas relaciones:

  • AssumeRole
  • PassRole
  • Lambda invoke
  • STS chaining
  • Resource policies

…aparecen caminos completos hacia privilegios críticos.

Ese enfoque “graph-based” es probablemente la parte más valiosa de todo el proyecto.

También sirve para validar herramientas CSPM

Esto me parece especialmente potente para empresas.

Puedes usar los labs para responder preguntas reales:

  • ¿Mi CSPM detecta esta mala configuración?
  • ¿Mi SIEM genera alertas?
  • ¿Mi graph engine reconstruye el path completo?
  • ¿Mi equipo detectaría esto en producción?

En otras palabras: no solo practicas explotación.

También puedes validar controles defensivos de manera reproducible.

Todo está hecho pensando en entornos aislados

Y aquí viene la advertencia importante.

Estos labs crean cosas deliberadamente peligrosas:

  • usuarios admin,
  • buckets públicos,
  • Lambdas expuestas a Internet,
  • security groups abiertos,
  • roles excesivamente permisivos.

NO están pensados para cuentas reales.

De hecho, los propios autores insisten constantemente en:

  • usar cuentas sandbox,
  • preferiblemente organizaciones AWS separadas,
  • activar billing alerts,
  • y destruir recursos cuando termines.

Me parece una decisión acertada porque el proyecto intenta ser útil sin minimizar el riesgo.

Supported lab types: self-escalation, one-hop, multi-hop, cross-account, misconfig labs, and toxic combination labs

Instalación rápida

La instalación es bastante sencilla.

Con Go:

go install -v github.com/DataDog/pathfinding-labs/cmd/plabs@latest

Con Homebrew:

brew tap DataDog/pathfinding-labs https://github.com/DataDog/pathfinding-labs
brew install DataDog/pathfinding-labs/plabs

Después:

plabs init

Y el asistente configura perfiles AWS y Terraform automáticamente.

Lo mejor: es open source

El repositorio está aquí: https://github.com/DataDog/pathfinding-labs

Y el catálogo web aquí: https://pathfinding.cloud/labs

Mi impresión

Sinceramente, creo que este proyecto puede convertirse en una referencia para entrenamiento práctico en seguridad cloud AWS.

Especialmente porque cubre un hueco que hasta ahora estaba muy fragmentado:

  • teoría IAM,
  • privilege escalation,
  • CSPM validation,
  • graph security,
  • attack simulation.

Todo unido en un mismo framework.

Si trabajas en:

  • cloud security,
  • offensive security,
  • detección,
  • IAM hardening,
  • o arquitectura AWS,

merece muchísimo la pena dedicarle unas horas.

Porque pocas cosas enseñan tanto como explotar tú mismo una mala configuración que podrías tener mañana en producción.

Una introducción a los contenedores: ECS y EKS en AWS

En el mundo de la tecnología, los contenedores se han convertido en un elemento esencial para optimizar la forma en que las aplicaciones son diseñadas, implementadas y administradas. Este artículo te guiará a través de los conceptos fundamentales, el funcionamiento interno y las ventajas que los contenedores ofrecen, así como su papel dentro de los servicios de AWS.

¿Qué son los contenedores y por qué son importantes?

Los contenedores son una tecnología que permite empaquetar aplicaciones junto con sus dependencias esenciales, asegurando que estas funcionen de manera consistente en cualquier entorno. A diferencia de las máquinas virtuales, los contenedores no requieren un sistema operativo completo, sino que comparten el kernel del sistema operativo del host. Este enfoque reduce significativamente el uso de recursos y mejora la velocidad de ejecución.

La importancia de los contenedores radica en su capacidad para simplificar los procesos de desarrollo y despliegue, al mismo tiempo que aumentan la eficiencia operativa. Son ideales para entornos donde la escalabilidad y la portabilidad son prioritarias.

El funcionamiento de los contenedores: de la virtualización tradicional a un modelo eficiente

En los sistemas tradicionales, la virtualización implica el uso de un hipervisor que permite ejecutar múltiples máquinas virtuales (VMs) en un solo servidor físico. Cada VM tiene su propio sistema operativo, lo que conlleva un consumo elevado de recursos. Por ejemplo, en AWS, una instancia EC2 puede utilizar el hipervisor NITRO, que permite que diferentes sistemas operativos coexistan en el mismo hardware.

Por otro lado, los contenedores adoptan un enfoque más ligero conocido como «virtualización a nivel de sistema operativo». Esto significa que, en lugar de virtualizar todo el hardware, los contenedores utilizan el kernel del sistema operativo del host y encapsulan únicamente las aplicaciones y sus dependencias. Este modelo no solo reduce la sobrecarga, sino que también acelera los tiempos de arranque, ya que no hay necesidad de cargar un sistema operativo completo.

Beneficios clave de los contenedores

  1. Optimización de Recursos: Al compartir el kernel del sistema operativo, los contenedores requieren menos memoria y potencia de procesamiento que las máquinas virtuales, permitiendo un uso más eficiente de los recursos disponibles.
  2. Portabilidad y Consistencia: Al empaquetar aplicaciones junto con todas sus dependencias, los contenedores aseguran que el software funcione de manera uniforme en diferentes plataformas, desde un entorno local hasta una infraestructura en la nube.
  3. Escalabilidad Simplificada: Los contenedores son ideales para entornos que requieren escalar rápidamente, ya que se pueden replicar y gestionar con facilidad.
  4. Velocidad en el Desarrollo: Los contenedores se inician casi instantáneamente, lo que acelera tanto el desarrollo como la entrega de software, permitiendo ciclos de iteración más cortos.
  5. Aislamiento Mejorado: Cada contenedor opera de forma independiente, garantizando que los cambios realizados en una aplicación no afecten a otras que estén en ejecución.

AWS y el ecosistema de contenedores

Amazon Web Services (AWS) ofrece una gama de herramientas para trabajar con contenedores, como Amazon ECS (Elastic Container Service) y Amazon EKS (Elastic Kubernetes Service). Estas soluciones permiten a los desarrolladores desplegar y administrar aplicaciones basadas en contenedores con facilidad, eliminando la necesidad de preocuparse por la infraestructura subyacente.

Amazon ECS (Elastic Container Service)

ECS es una opción ideal para aquellos que buscan simplicidad y una integración nativa con AWS. Este servicio se encarga de la gestión de clústeres de contenedores sin necesidad de supervisar directamente los nodos subyacentes. ¿Cuándo elegir ECS?

  • Fácil de usar: Es adecuado para equipos sin experiencia previa en Kubernetes, gracias a su configuración sencilla.
  • Aplicaciones simples: Ideal para microservicios básicos o aplicaciones monolíticas.
  • Integración con AWS: Se conecta perfectamente con otros servicios de AWS como CloudWatch, IAM y ELB.
  • Experiencia previa con ECS: Si ya utilizas ECS, puede ser más eficiente mantenerlo en lugar de migrar a Kubernetes.

Amazon EKS (Elastic Kubernetes Service)

Por otro lado, EKS está diseñado para equipos que necesitan la flexibilidad y potencia de Kubernetes. Este servicio gestionado te permite aprovechar la amplia comunidad y herramientas de Kubernetes. ¿En qué casos es ideal EKS?

  • Complejidad avanzada: Es perfecto para aplicaciones de gran escala o con requisitos sofisticados.
  • Ecosistema Kubernetes: Si ya usas Kubernetes en otros entornos, EKS es una extensión natural.
  • Personalización: Ofrece un control granular sobre la configuración y el despliegue.
  • Escalabilidad global: Permite administrar clústeres distribuidos en varias regiones.

Reflexiones finales

Los contenedores han cambiado la forma en que las aplicaciones son creadas, distribuidas y ejecutadas. Gracias a su eficiencia, portabilidad y escalabilidad, esta tecnología se ha convertido en un pilar fundamental para la innovación en TI. Tanto si eres un desarrollador que busca mejorar los flujos de trabajo como si eres un líder empresarial que desea optimizar la infraestructura, los contenedores ofrecen una solución flexible y robusta.

¡Es hora de aprovechar al máximo esta tecnología y explorar cómo puede transformar tus proyectos!

 

GuardDuty: Un viaje a través del tiempo en AWS Security

En el vasto panorama de la seguridad en AWS, GuardDuty ha emergido como un componente crucial en la defensa contra amenazas en constante evolución. Desde su lanzamiento el 28 de noviembre de 2017, este servicio ha experimentado una transformación significativa para adaptarse a las demandas cambiantes del entorno de seguridad en la nube.

Orígenes de GuardDuty

GuardDuty hizo su entrada en escena con el objetivo claro de reforzar la seguridad en AWS. Lanzado como un servicio de detección de amenazas en la red, GuardDuty inicialmente se centró en la identificación de patrones sospechosos de tráfico, proporcionando una capa adicional de protección para las cuentas de AWS. Este enfoque pionero se estableció como un hito en la evolución de la seguridad en la nube.

Mejoras en la Detección de Amenazas

A lo largo del tiempo, las actualizaciones clave de GuardDuty han sido fundamentales para mantenerse a la vanguardia. Con la versión 2.0 lanzada en febrero de 2019, se incorporaron algoritmos de aprendizaje automático, elevando la capacidad del servicio para identificar amenazas avanzadas. Esta mejora fue un paso audaz en la dirección de la adaptabilidad y la inteligencia frente a amenazas emergentes.

Integración con AWS Security Hub y EventBridge

La colaboración esencial llegó con la integración de GuardDuty con AWS Security Hub y EventBridge. Anunciada en el AWS re:Invent de 2020, esta integración permitió a los usuarios correlacionar eventos de seguridad de manera más efectiva y responder de manera más ágil ante amenazas. La interconexión de estos servicios marcó un antes y un después en la capacidad de las organizaciones para gestionar la seguridad de sus entornos en la nube.

Automatización y Respuesta Activa

En agosto de 2021, GuardDuty dio un salto cuántico al introducir capacidades de automatización y respuesta activa. Esta función permitió a los usuarios definir acciones automatizadas en respuesta a eventos específicos de seguridad, reduciendo drásticamente el tiempo de respuesta. Este cambio marcó un hito en la capacidad de GuardDuty para no solo identificar amenazas, sino también mitigarlas de manera proactiva.

Perspectivas Futuras de GuardDuty

Mirando hacia adelante, las perspectivas de GuardDuty son aún más emocionantes. Con la continua integración de tecnologías de inteligencia artificial y aprendizaje automático, el servicio se perfila para abordar amenazas avanzadas con mayor eficacia. Además, se espera que futuras actualizaciones optimicen la interoperabilidad con otros servicios de seguridad en la nube de AWS.

 

GuardDuty, desde su lanzamiento hasta las innovaciones más recientes, refleja la dedicación de AWS a la mejora continua en materia de seguridad. En un entorno donde la ciberseguridad es una prioridad crítica, GuardDuty ha demostrado ser un recurso indispensable. Para obtener más información sobre su evolución a lo largo del tiempo, se pueden explorar las actualizaciones oficiales en el blog de AWS. Esta evolución continua promete seguir fortaleciendo la postura de seguridad en la nube de AWS y brindar a los usuarios una defensa confiable contra las amenazas en constante cambio.

SecurityInside Live: CISO Day 2020

Todos sabemos la importancia del flujo de información dentro de una industria tan cambiante y retadora como la de la ciberseguridad. Si eres CISO, CIO, responsable de ciberseguridad, experto en la materia, investigador o hacker… serás bienvenido a CISO Day 2020, un evento centrado en el responsable de la ciberseguridad corporativa.

Si recuerdas, ya hemos hablado en este blog otras veces de la importancia del CISO, en este evento se profundiza en su importancia desde varios puntos de vista.

CISO DAY 2020 basa su agenda en 6 niveles fundamentales de la ciberseguridad: Estratégico (CISO), Analítico (Ciberinteligencia), Institucional (INCIBE), Innovador (CyberStartup), Security (Proveedores) y Técnico (Hacking).

En este enlace tienes toda la información que necesitas sobre la agenda y en este sobre los ponentes que van a dar las charlas.

Y no olvides que, si no puedes ir y lo quieres ver, tienes acceso al streaming. Si no lo ves es porque no quieres 😀

Leer más

Software Defined Perimeter

SDP – Software Defined Perimeter: 10 motivos por los que es interesante

Hoy os traigo el resultado de mi actualización en relación a las soluciones SDP (Software Defined Perimeter) con las que me he encontrado hace poco, espero que os resulte interesante.

Como mucho de vosotros sabéis, las redes privadas virtuales (VPN) basadas en perímetro se despliegan para proporcionar acceso a empleados o terceros a las redes de la empresa. Hasta hace poco tiempo, este era uno de los mecanismos habituales para mantener un acceso remoto seguro.

Este tipo de conexiones son muy utilizadas debido al creciente (y maravilloso) auge tanto de los entornos cloud como del teletrabajo (con empleados que trabajan desde casa, en cafeterías o aeropuertos).

Sin embargo, el daño que se deriva de las intrusiones en la red es tan grande que los inconvenientes de los servicios VPN basados en el perímetro se están haciendo más tangibles que nunca. En este contexto, las empresas están empezando a considerar alternativas como las soluciones SDP (Perímetro Definido por Software), que aprovechan el paradigma de confianza cero.

¿Pero, qué es SDP?

La premisa de la arquitectura de red empresarial tradicional es crear una red interna separada del mundo exterior por un perímetro fijo que consiste en una serie de funciones de firewalls que bloquean la entrada de los usuarios externos, pero que permiten la salida de los usuarios internos.

Los perímetros fijos tradicionales ayudan a proteger los servicios internos de las amenazas externas mediante técnicas sencillas para bloquear la visibilidad y la accesibilidad desde el exterior del perímetro a las aplicaciones y la infraestructura internas. Pero las debilidades de este modelo de perímetro fijo tradicional son cada vez más problemáticas debido a la popularidad de los dispositivos gestionados por los usuarios y los ataques de phishing, que proporcionan un acceso no fiable dentro del perímetro, y a que el SaaS y el IaaS extienden el perímetro a Internet.

sdp_different_users

Los perímetros definidos por software tratan estos problemas dando a los propietarios de las aplicaciones la habilidad de desplegar perímetros que retienen el valor del modelo tradicional de invisibilidad e inaccesibilidad, pero que pueden ser desplegados en cualquier lugar (en Internet, en la nube, en un CPD, en la red corporativa privada, …)

Me interesa, ¿cómo funciona esto del SDP?

La arquitectura del SDP consta de dos componentes: Los Hosts SDP y los Controladores SDP que pueden iniciar o aceptar conexiones. Estas acciones se gestionan mediante interacciones con los controladores SDP a través de un canal de control (ver figura 1). Así, en un perímetro definido por software, el plano de control está separado del plano de datos para permitir una mayor escalabilidad. Además, todos los componentes pueden ser redundantes para una mayor disponibilidad.

Software Defined Perimeter Architecture

Figura 1: La arquitectura del Perímetro Definido por Software consiste en dos componentes: Hosts SDP y Controladores SDP

El marco SDP tiene el siguiente flujo de trabajo (ver figura 2).

  1. Uno o más controladores SDP se ponen en línea y se conectan a los servicios opcionales de autenticación y autorización adecuados (por ejemplo, PKI, huellas digitales de dispositivos, geolocalización, SAML, OpenID, OAuth, LDAP, Kerberos, autenticación multifactorial y otros servicios similares).
  2. Se ponen en línea uno o más Hosts SDP de aceptación. Estos hosts se conectan y se autentican con los Controladores. Sin embargo, no reconocen la comunicación de ningún otro Host y no responderán a ninguna petición no proporcionada.
  3. Cada uno de los Host SDP de inicio que se pone en línea se conecta y se autentica con los Controladores SDP.
  4. Después de autentificar el Host SDP de inicio, los Controladores SDP determinan una lista de Hosts de aceptación a los que el Host de inicio está autorizado a comunicarse.
  5. El Controlador SDP indica a los Hosts SDP aceptantes que acepten la comunicación del Host Iniciador, así como cualquier política opcional requerida para las comunicaciones cifradas.
  6. El controlador SDP proporciona al host SDP iniciador la lista de hosts de aceptación, así como las políticas opcionales necesarias para las comunicaciones cifradas.
  7. El Host SDP iniciador inicia una conexión VPN mutua con todos los Hosts de aceptación autorizados.
Software_Defined_Perimeter_Workflow

Figura 2: Flujo de trabajo de la arquitectura del perímetro definido por el software

 

10 razones de esta tendencia que está tomando fuerza

  1. Problemas de seguridad con las VPN tradicionales

Las empresas se han expuesto más a las violaciones de datos. Los empleados que trabajan a distancia, así como la migración a la nube, son factores que complican la protección efectiva del perímetro de la red. Los servicios tradicionales de VPN son demasiado indulgentes, lo que permite al personal acceder a muchas más áreas de la red de las que necesitan para su trabajo diario. Como resultado, estos recursos asumen una visibilidad injustificada y se vuelven más susceptibles de ser comprometidos.

  1. Acceso remoto y aislamiento de la red sin confianza

Desde el punto de vista de la seguridad, las soluciones SDP tienen una serie de ventajas sobre la VPN. En primer lugar, no existen zonas de confianza en este escenario. Un administrador de TI debe definir claramente y conceder privilegios de usuario para acceder a aplicaciones específicas. A los dispositivos de los usuarios se les asignan conexiones «punto a punto». El resto de los recursos de la red están aislados y permanecen completamente inaccesibles. Algunas soluciones SDP permiten la autenticación continua así como la verificación de usuarios y/o dispositivos a nivel de paquetes, utilizando una tecnología de red basada en ID. Todo el tráfico de la red se registra para su posterior auditoría y análisis.

  1. Los inconvenientes de utilizar una VPN

Todo empleado que haya utilizado una VPN empresarial anteriormente sabe que estos servicios funcionan de forma lenta y poco fiable. Si está utilizando aplicaciones dispersas geográficamente, se sentirá frustrado por tener que conectarse o desconectarse todo el tiempo y hacer un seguimiento de la ubicación a la que se está conectando cuando acceda a una aplicación que necesita.

  1. SDP: basta con conectarse una vez para acceder a todo lo que necesita

Con la solución SDP adecuada, los usuarios finales conectados pueden acceder a las aplicaciones necesarias independientemente de su ubicación. Las soluciones basadas en navegadores que no utilizan agentes de software facilitan el acceso a los empleados que utilizan dispositivos personales, así como a los contratistas, socios y clientes.

  1. Dolor de cabeza de los administradores

En el caso de la migración a la nube, la gestión de la VPN se complica. Los administradores de TI tienen que configurar y coordinar las políticas de VPN y cortafuegos en diferentes ubicaciones geográficas. Esto, a su vez, dificulta la prevención de accesos no autorizados.

  1. Discrepancias en la configuración

Las VPNs necesitan ser configuradas por separado en cada centro de datos y en la nube. Con SDP, los administradores pueden añadir un recurso de red a la plataforma una vez y, a continuación, gestionar todas las políticas en la nube de forma centralizada. Una ventaja más de utilizar soluciones SDP totalmente basadas en la nube es que muy pocos elementos están sujetos a una configuración y mantenimiento adicionales cuando se concede el acceso dentro de un centro de datos o una nube privada virtual. Todas las actividades, incluidas las relacionadas con la seguridad, se realizan en la nube.

  1. Escalado costoso

A medida que las organizaciones añaden nuevos usuarios y aumentan el número de servicios cloud que aprovechan, gastan mucho más en VPNs y cortafuegos. La razón se reduce a la necesidad de adquirir licencias adicionales y dispositivos más potentes.

  1. El potencial de un crecimiento desenfrenado

Si una organización utiliza una solución de SDP basada en la nube, la expansión no es casi nunca un problema. No importa cuántos usuarios estén conectados y cuántas aplicaciones necesiten, este servicio permite un escalado gradual en la nube sin necesidad de equipos costosos.

  1. Flexible pero no gratuito

Las VPNs proporcionan flexibilidad ya que pueden conectar múltiples puntos finales distribuidos geográficamente, centros de datos y nubes privadas virtuales. Sin embargo, se necesitan recursos significativos y gastos crecientes para establecer y mantener estas conexiones.

  1. Conecte todo sin complicaciones

Las soluciones SDP permiten a las empresas proporcionar a sus empleados acceso a recursos informáticos específicos de la empresa sin necesidad de aumentar los requisitos de control y los gastos.

Conclusiones

El profundo conocimiento de los mecanismos de acceso remoto seguro incentiva a las organizaciones que están migrando a la nube a desplegar soluciones SDP. Estos servicios implementan una política de acceso a la red personalizada para los usuarios y los recursos de forma individual. Estos recursos permanecen invisibles para los usuarios no autorizados, lo que reduce la superficie potencial de ataque. La orientación al cliente de las soluciones SDP hace que sean más fáciles de controlar, aplicables en todos los ámbitos, adecuadamente protegidas y flexibles. Estas características superan los beneficios de los servicios VPN tradicionales por lo que no os extrañe que veamos esta tecnología mucho más en un futuro cercano.

 

Fuentes:

https://en.wikipedia.org/wiki/Software_Defined_Perimeter

https://www.vectoritcgroup.com/tech-magazine/cybersecurity/el-modelo-sdp-desbanca-a-las-soluciones-vpn/

https://www.perimeter81.com/blog/network/5-reasons-why-you-need-to-replace-your-vpn-with-sdp/

https://www.metanetworks.com/sdp-vs-vpn-5-reasons-to-make-the-switch/