En este capítulo, OWASP TOP 10 – A02:2025 Security Misconfiguration,  vas a aprender por qué las configuraciones incorrectas son una de las causas más comunes —y más peligrosas— de compromisos de seguridad en aplicaciones modernas. Vas a entender no solo qué es una misconfiguración, sino cómo se detecta, cómo se explota y, lo más importante, cómo se previene.

Esta vulnerabilidad no depende del código en sí, sino de cómo está configurado el entorno que lo sostiene: servidores, contenedores, cloud, frameworks, bases de datos, APIs, paneles de administración, CORS, TLS, cabeceras HTTP, debug, archivos sensibles expuestos, permisos, y muchísimo más.

Es útil y necesario para tu carrera como hacker porque:

• Es una de las fallas más fáciles de encontrar incluso para atacantes novatos.
• Es una de las fallas más devastadoras cuando se explota bien.
• Aparece en casi todas las aplicaciones reales.
• Forma parte esencial del reconocimiento, enumeración y escalada inicial que realiza cualquier atacante antes de lanzar ataques más complejos.
• Te va a entrenar para pensar como un hacker: buscando accesos olvidados, defaults inseguros, rutas no protegidas, paneles de debug, buckets públicos, configuraciones laxas y errores verbosos que revelan demasiado.
• Te convertirá en un profesional capaz de auditar ambientes reales, tanto on-prem como en la nube, con criterio técnico y mirada ofensiva.

En otras palabras, vas a aprender a romper sistemas mal configurados y, a la vez, a construir infraestructuras seguras aplicando hardening, automatización y buenas prácticas de DevSecOps.

Este capítulo es uno de los más importantes porque la seguridad moderna es 50% configuración, 50% código. Si dominás esto, tenés media batalla ganada.

 

OWASP TOP 10 

OWASP es popular por publicar el TOP 10 Owasp Web cada cuatro años. Este es un  documento que lista los diez riesgos más críticos en aplicaciones web, con el objetivo de  ayudar a las organizaciones a identificar y mitigar las vulnerabilidades asociadas con estos riesgos. https://owasp.org/Top10/es/ Cada uno de estos riesgos representa una debilidad común y significativa que a menudo se puede explotar para comprometer la seguridad de una aplicación web. OWASP proporciona información detallada sobre posibles vulnerabilidades y técnicas de ataque para cada riesgo.

El Top 10 de OWASP es una lista que se actualiza periódicamente de los riesgos de seguridad de las aplicaciones web más críticos. Lo mantiene el Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP), una organización sin fines de lucro centrada en mejorar la seguridad de las aplicaciones web. Sirve como una valiosa guía para que los desarrolladores, los expertos en pruebas de penetración de aplicaciones web y las organizaciones comprendan y prioricen los riesgos de seguridad comunes en las aplicaciones web.

El Top 10 de OWASP es una lista conocida de los diez riesgos de seguridad de aplicaciones web más críticos. Se actualiza periódicamente para garantizar que refleje el panorama actual de amenazas y los desafíos de seguridad en constante evolución que enfrentan las aplicaciones web. La primera versión del Top 10 de OWASP se publicó en 2003. Su objetivo era crear conciencia sobre los riesgos comunes de seguridad de las aplicaciones web y ayudar a los desarrolladores a priorizar los esfuerzos de seguridad. La lista incluía riesgos como secuencias de comandos entre sitios (XSS), inyección de SQL y problemas de gestión de sesiones. Cada lanzamiento del Top 10 de OWASP se basa en las versiones anteriores, mejorando su precisión, relevancia y practicidad.

Evolución de OWASP TOP 10

En el momento de crear este artículo coexiste las dos versiones 2021/2025.

⚪No cambia

🟡Fusionado

🔵Cambia de posición

🟢Nuevo

La evolución histórica de A02:2025 – Security Misconfiguration

Si existe una categoría del OWASP Top 10 que refleja, con precisión casi quirúrgica, el crecimiento exponencial de la complejidad en el desarrollo moderno, esa categoría es Security Misconfiguration. Surgió como un problema constante pero subestimado, oculto detrás de vulnerabilidades más mediáticas como SQL Injection, XSS o Broken Authentication. Sin embargo, con el paso de los años, el avance del cloud computing, la explosión de frameworks, contenedores, microservicios, APIs y automatización DevOps, transformaron este riesgo en una de las causas más frecuentes de brechas de seguridad. La historia de Security Misconfiguration es, en esencia, la historia de cómo la industria adoptó tecnologías cada vez más potentes pero también cada vez más difíciles de configurar correctamente. OWASP, al analizar su evolución desde 2003 hasta 2025, muestra cómo lo que antes se consideraba “un simple error de configuración” se convirtió en un riesgo sistémico que atraviesa aplicaciones, servidores, redes, clouds, contenedores, bases de datos y todo el entorno moderno del software.

Durante las primeras ediciones del OWASP Top 10 (2003, 2004, 2007 y 2010), la categoría existía, pero no con la prominencia que tendría en el futuro. A menudo aparecía dispersa: a veces como “Security Misconfiguration”, otras veces como “Configuration Errors”, otras como “Improper Error Handling”. Su posición inicial solía ser modesta, normalmente en los puestos inferiores, como A6 o A10, reflejando la percepción dominante de la época: se asumía que los desarrolladores y administradores podían mantener configuraciones seguras si simplemente seguían las guías recomendadas. Sin embargo, esta visión ignoraba una realidad incipiente: la creciente cantidad de componentes que requerían configuración, desde servidores web como Apache y IIS hasta bases de datos, máquinas virtuales, firewalls, racks físicos, aplicaciones monolíticas y frameworks en expansión como Java EE o .NET. Aunque OWASP identificaba la amenaza, la industria la subestimaba porque todavía se podía “controlar todo a mano”.

La década de 2010 marcó un punto crítico. El Top 10 de 2013 reorganizó profundamente varias categorías, y Security Misconfiguration comenzó a ganar relevancia. Ya no aparecía como un error menor, sino como un riesgo cada vez más común y cada vez más devastador. ¿La razón? El salto arquitectónico hacia la hiperconectividad. Los equipos adoptaron virtualización, ambientes híbridos cloud/on-premise, frameworks web altamente configurables y arquitecturas REST. Cada capa de la aplicación —el servidor web, el servidor de aplicaciones, el repositorio de código, el WAF, la base de datos, el load balancer, el reverse proxy— requería configuraciones específicas que podían ser explotadas de maneras completamente nuevas. OWASP observó que una sola configuración insegura, como un puerto abierto, un error de permisos en un bucket S3, un directorio sin restricciones o un encabezado de seguridad ausente podía comprometer millones de datos. Por primera vez, Security Misconfiguration escaló posiciones en la lista y se volvió una vulnerabilidad especialmente prevalente.

De un riesgo silencioso a una amenaza estructural en todas las capas del software

Pero la verdadera explosión de esta categoría ocurrió entre 2017 y 2021. Durante estos años, la industria adoptó de forma masiva microservicios, contenedores Docker, orquestadores Kubernetes, pipelines CI/CD, automatización, infraestructura como código (IaC) y servicios de cloud altamente configurables. Esto marcó un antes y un después: el nivel de complejidad se disparó, y con él la probabilidad de errores humanos o de configuraciones por defecto peligrosas. Kubernetes, por ejemplo, introdujo decenas de parámetros de seguridad, desde RBAC hasta Network Policies; AWS, Azure y GCP añadieron cientos de configuraciones críticas en IAM, VPCs, buckets y policies. La industria pasó a una era donde “todo se configura”, pero no siempre se configura bien. OWASP lo reflejó en 2017 ubicando Security Misconfiguration como A6. Cuatro años más tarde, ante incidentes globales como bases de datos expuestas, buckets públicos, dashboards accesibles sin autenticación, APIs sin restricciones y containers mal protegidos, OWASP elevó la categoría a A05:2021, con un reconocimiento explícito: Security Misconfiguration es hoy una de las principales causas de ataques exitosos en todo el mundo.

El salto final llega con OWASP Top 10 – 2025, donde Security Misconfiguration asciende nuevamente, esta vez hasta el puesto A02, convirtiéndose en la segunda vulnerabilidad más crítica del ecosistema web global. Este ascenso no es casual: representa una madurez conceptual de la industria. Mientras que en 2021 la categoría mantenía un equilibrio entre frecuencia y severidad, en 2025 OWASP detecta dos factores contundentes:

1. Los errores de configuración continúan siendo masivos, especialmente en cloud, APIs, almacenamiento y contenedores.
2. La complejidad tecnológica aumenta más rápido que la capacidad humana para configurarla correctamente.

El mundo del desarrollo moderno obliga a equipos distribuidos, automatizados, que trabajan bajo presión y despliegan múltiples veces al día. Las configuraciones se definen en YAML, JSON, pipelines, templates, Terraform, Ansible, y decenas de puntos de control. Un solo parámetro mal definido puede provocar accesos no autorizados, fugas de datos, bypass de firewalls, omisión de logs, exposición de endpoints internos, o pérdida total de integridad. En muchos casos, los incidentes de alto impacto ya no se deben a fallos lógicos, sino a simples configuraciones por defecto: paneles administrativos sin protección, credenciales en variables de entorno accesibles, políticas permisivas, y servicios que deberían estar aislados pero no lo están.

OWASP TOP 10  2025

En la lista de los Diez Principales para 2025, se han incorporado dos categorías nuevas y una consolidada. Esta versión según OWASP está centrada en la causa raíz, más que en los síntomas, en la medida de lo posible. Dada la complejidad de la ingeniería y la seguridad del software, resulta prácticamente imposible crear diez categorías sin cierto grado de superposición.

 

Lo más llamativo es que, en 2025, Security Misconfiguration ya no se limita a un error técnico: OWASP lo describe como una señal de fallas en todo el ecosistema organizacional. No se trata solo de un desarrollador olvidando un header de seguridad o un administrador dejando un puerto abierto; se trata de la incapacidad de las organizaciones de coordinar procesos seguros en entornos nativos cloud, automatizados y distribuidos. La categoría ahora abarca errores en la configuración de CI/CD, configuraciones heredadas, políticas de acceso inconsistentes, exposición accidental de archivos sensibles, configuraciones por defecto inseguras y falta de hardening integral. Esto confirma que la categoría no es un riesgo puntual, sino estructural, transversal a todo el ciclo de vida.

Finalmente, el ascenso de Security Misconfiguration al puesto A02:2025 debe interpretarse como una advertencia global. OWASP indica que los errores de configuración han pasado de ser fallas aisladas a convertirse en el talón de Aquiles del software moderno. Cada nueva herramienta, framework o servicio cloud trae consigo nuevas configuraciones críticas que pueden ser mal interpretadas o mal aplicadas. La industria, además, se encuentra en una carrera difícil entre automatizar configuraciones seguras y evitar que la velocidad del desarrollo genere brechas inadvertidas. El A02:2025 simboliza ese desafío: no importa cuán avanzado sea el sistema, cuánta criptografía use o cuán sólido sea su diseño, si está mal configurado, fallará.

En síntesis, la evolución de Security Misconfiguration desde los orígenes del OWASP Top 10 hasta su destacada posición en 2025 es la historia de la modernización del software: más herramientas, más capacidad, más poder, pero también más responsabilidades y más formas de cometer errores. Lo que hace años era un problema silencioso hoy es una categoría imprescindible para cualquier auditoría, pentest o pipeline de seguridad. A02:2025 no es solo un ranking: es una declaración de la realidad actual, donde las configuraciones inseguras constituyen uno de los riesgos más comunes, más subestimados y más devastadores del ecosistema digital.

 

 

A02:2025 Configuración incorrecta de seguridad

A partir del puesto n.° 5 de la edición anterior, se detectó algún tipo de configuración incorrecta en el 100 % de las aplicaciones analizadas, con una tasa de incidencia promedio del 3 % y más de 719 000 casos de una Enumeración de Debilidades Comunes (CWE) en esta categoría de riesgo. Con la creciente adopción de software altamente configurable, no sorprende ver un ascenso en esta categoría. Entre las CWE más destacadas se incluyen la CWE-16 Configuración y la CWE-611 Restricción incorrecta de la referencia a entidades externas XML (XXE).

Se debe definir e implementar una configuración de seguridad para la aplicación, los marcos, el servidor de aplicaciones, el servidor web, el servidor de bases de datos y la plataforma. Si se configuran correctamente, un atacante puede tener acceso no autorizado a datos o funciones confidenciales.

A veces, estos fallos pueden comprometer por completo el sistema. Mantener el software actualizado también es una buena medida de seguridad.

Implicación

• Aprovechando esta vulnerabilidad, el atacante puede enumerar la tecnología subyacente y la información de la versión del servidor de aplicaciones, información de la base de datos y obtener información sobre la aplicación para montar algunos ataques más.

Objetos vulnerables

• URL
• Campos de formulario
• Campos de entrada

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
16	27,70%	3.00%	100.00%	52,35%	7.96	3.97	719.084	1.375

Descripción.

Una mala configuración de seguridad ocurre cuando un sistema, una aplicación o un servicio en la nube se configura incorrectamente desde una perspectiva de seguridad, lo que crea vulnerabilidades.

La aplicación podría ser vulnerable si:

• Falta un refuerzo de seguridad adecuado en cualquier parte de la pila de aplicaciones o permisos configurados incorrectamente en los servicios en la nube.
• Se habilitan o instalan funciones innecesarias (por ejemplo, puertos, servicios, páginas, cuentas, marcos de prueba o privilegios innecesarios).
• Las cuentas predeterminadas y sus contraseñas siguen habilitadas y sin cambios.
• Falta de una configuración central para interceptar mensajes de error excesivos. La gestión de errores revela a los usuarios rastros de pila u otros mensajes de error excesivamente informativos.
• En el caso de los sistemas actualizados, las funciones de seguridad más recientes están deshabilitadas o no están configuradas de forma segura.
• Priorización excesiva de la compatibilidad con versiones anteriores que conduce a una configuración insegura.
• Las configuraciones de seguridad en los servidores de aplicaciones, los marcos de aplicaciones (por ejemplo, Struts, Spring, ASP.NET), las bibliotecas, las bases de datos, etc., no están establecidas en valores seguros.
• El servidor no envía encabezados o directivas de seguridad, o no están configurados con valores seguros.

Sin un proceso concertado y repetible de fortalecimiento de la configuración de seguridad de las aplicaciones, los sistemas corren un mayor riesgo.

Cómo prevenir.

Se deben implementar procesos de instalación seguros, que incluyan:

• Un proceso de refuerzo repetible que permite la implementación rápida y sencilla de otro entorno debidamente bloqueado. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, con credenciales diferentes en cada uno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.
• Una plataforma minimalista sin funciones, componentes, documentación ni ejemplos innecesarios. Elimine o no instale funciones y frameworks no utilizados.
• Una tarea para revisar y actualizar las configuraciones correspondientes a todas las notas de seguridad, actualizaciones y parches como parte del proceso de gestión de parches (véase A03:2025 – Fallos en la cadena de suministro de software). Revisar los permisos de almacenamiento en la nube (p. ej., permisos de buckets S3).
• Una arquitectura de aplicación segmentada proporciona una separación efectiva y segura entre componentes o inquilinos, con segmentación, contenedorización o grupos de seguridad en la nube (ACL).
• Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de seguridad.
• Un proceso automatizado para verificar la efectividad de las configuraciones y ajustes en todos los entornos.
• Agregue de forma proactiva una configuración central para interceptar mensajes de error excesivos como respaldo.
• Si estas verificaciones no están automatizadas, deberán verificarse manualmente como mínimo una vez al año.
• Una arquitectura de aplicación sólida que proporciona una buena separación y seguridad entre los componentes.
• Cambiar nombres de usuario y contraseñas predeterminados.
• Deshabilite los listados de directorios e implemente controles de control de acceso.

Ejemplos de escenarios de ataque.

Escenario n.° 1: El servidor de aplicaciones incluye aplicaciones de muestra que no se eliminaron del servidor de producción. Estas aplicaciones presentan vulnerabilidades de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y que las cuentas predeterminadas no se han modificado. En ese caso, el atacante inicia sesión con la contraseña predeterminada y toma el control.

Escenario n.° 2: El listado de directorios no está deshabilitado en el servidor. Un atacante descubre que puede simplemente listar directorios. Encuentra y descarga las clases Java compiladas, las descompila y aplica ingeniería inversa para ver el código. A continuación, descubre una grave vulnerabilidad de control de acceso en la aplicación.

Escenario n.° 3: La configuración del servidor de aplicaciones permite que se devuelvan a los usuarios mensajes de error detallados, como seguimientos de pila. Esto podría exponer información confidencial o fallos subyacentes, como versiones de componentes vulnerables.

Escenario n.° 4: Un proveedor de servicios en la nube (CSP) tiene permisos de uso compartido abiertos a Internet por defecto. Esto permite acceder a datos confidenciales almacenados en la nube.

La consola de administración del servidor de aplicaciones se instala automáticamente y no se elimina. Las cuentas predeterminadas no se modifican. El atacante puede iniciar sesión con contraseñas predeterminadas y obtener acceso no autorizado.

La lista de directorios no está deshabilitada en su servidor. El atacante descubre y puede simplemente listar directorios para encontrar cualquier archivo.

ANTERIORMENTE A05:2021 – Configuración incorrecta de seguridad

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Exploit ponderado promedio	Impacto ponderado promedio	Cobertura máxima	Cobertura promedio	Total de ocurrencias	Total de CVEs
20	19,84%	4,51%	8.12	6.56	89,58%	44,84%	208.387	789

Desde el puesto n.° 6 de la edición anterior, el 90 % de las aplicaciones se analizaron para detectar algún tipo de configuración incorrecta, con una tasa de incidencia promedio del 4,51 % y más de 208 000 casos de Enumeración de Debilidades Comunes (CWE) en esta categoría de riesgo. Con la creciente adopción de software altamente configurable, no sorprende ver un ascenso en esta categoría. Entre las CWE más destacadas se incluyen la CWE-16 Configuración y la CWE-611 Restricción incorrecta de la referencia a entidades externas XML .

A02 – Security Misconfiguration (Mala configuración de seguridad)

Pasa cuando el sistema está mal configurado o con ajustes inseguros por defecto. No es un error de código, sino de cómo está montado el entorno o la aplicación. Es cualquier ajuste inseguro (o falta de hardening) en cualquier capa de la app/infra (app, server, DB, cloud, contenedores, CDN, WAF, etc.) que abre puertas no intencionales. A05 ocurre cuando la app o servidor están mal configurados (defaults, debug, headers faltantes, CORS ). Se arregla con hardening, deny-by-default y revisiones periódicas.

Las configuraciones de seguridad incorrectas se diferencian de las otras 10 vulnerabilidades principales porque ocurren cuando la seguridad podría haberse configurado correctamente, pero no se hizo. Incluso si descarga el software más reciente, una configuración deficiente podría hacer que su instalación sea vulnerable.

Las configuraciones de seguridad incorrectas incluyen:

• Permisos mal configurados en servicios en la nube, como los buckets S3 .
• Tener habilitadas funciones innecesarias, como servicios, páginas, cuentas o privilegios.
• Cuentas predeterminadas con contraseñas sin cambios.
• Mensajes de error que son demasiado detallados y permiten a los atacantes obtener más información sobre el sistema.
• No utilizar encabezados de seguridad HTTP .

Esta vulnerabilidad a menudo puede conducir a más vulnerabilidades, como credenciales predeterminadas que brindan acceso a datos confidenciales, entidades externas XML ( XXE ) o inyección de comandos en páginas de administración.

Interfaces de depuración

Una configuración de seguridad errónea común se refiere a la exposición de las funciones de depuración en el software de producción. Estas funciones suelen estar disponibles en los marcos de programación para que los desarrolladores accedan a funciones avanzadas útiles para depurar una aplicación durante su desarrollo. Los atacantes podrían abusar de algunas de estas funciones de depuración si, por algún motivo, los desarrolladores olvidaran desactivarlas antes de publicar sus aplicaciones.

Un ejemplo de tal vulnerabilidad fue presuntamente usado cuando Patreon fue hackeado en 2015. Cinco días antes de que Patreon fuera hackeado, un investigador de seguridad informó a Patreon que había encontrado una interfaz de depuración abierta para una consola Werkzeug. Werkzeug es un componente vital en aplicaciones web basadas en Python, ya que proporciona una interfaz para que los servidores web ejecuten el código Python. Werkzeug incluye una consola de depuración a la que se puede acceder ya sea a través de URL en /console, o también se presentará al usuario si la aplicación lanza una excepción. En ambos casos, la consola proporciona una consola Python que ejecutará cualquier código que le envíes. Para un atacante, esto significa que puede ejecutar comandos arbitrariamente.

Ejemplos fáciles:

• Panel de administración con usuario/contraseña por defecto (admin/admin).
• Servidor con directory listing habilitado (/files/ muestra todo).
• Página de error que expone stacktrace y versiones del framework.
• Falta de headers de seguridad como CSP, HSTS, X-Frame-Options.
• CORS mal configurado (Access-Control-Allow-Origin: *).
• Archivos sensibles expuestos: .git/, .env, backup.zip.
• Sitio que acepta TLS 1.0 o ciphers débiles.

Cómo se ataca (pentesting):

Recon & footprinting

• Puertos/servicios: nmap -sV -sC <host> (SSL/TLS: –script ssl-enum-ciphers).
• Fingerprint web: whatweb, wappalyzer, revisar headers con curl -I.
• Buscar rutas ocultas (/admin, /debug, /backup). Probar credenciales comunes.
• Descubrimiento de contenido: ffuf -w wordlist -u https://site/FUZZ / feroxbuster.
• Errores/verbosidad: provocar inputs inválidos y observar mensajes. (Los errores verbosos filtran versiones/config, típico de A05).
• Escanear con nmap/nikto para detectar servicios innecesarios.

Superficie específica

• Headers de seguridad: validar CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• CORS: probar orígenes (reflejados, *, null, subdominios) y withCredentials. CORS vulnerable suele ser pura misconfig.
• Archivos/artefactos: .env, .git/, backup.zip, index.php~, /swagger-ui, /v2/api-docs.
• Cloud: revisar ACL/Policies excesivas (S3/Azure Blob) y objetos públicos.
• Mgmt/Debug: /actuator, /console, /metrics, /health, phpinfo().

Ataques / PoC frecuentes

• CORS: página maliciosa lee datos de la banca si ACAO permite tu origen (o *) y ACAC: true → exfiltración. (En producción real hay casos públicos; p.ej., empresas corrigiendo CORS por data exfil).
• Errores verbosos: inyectás input malformado, la app devuelve stacktrace con versión vulnerable.
• Directory listing: navegas /statements/ y descargas PDFs.
• .env expuesto: obtienes DB creds → pivoteas.
• Panel admin por defecto: accedés con admin/admin.

Consecuencia:

• Exposición de datos sensibles. Exposición de PII (DNI, cuentas, transacciones), fraude y sanciones regulatorias.
• Compromiso del servidor si se accede a paneles internos. Credenciales por defecto → acceso directo a paneles internos.
• Facilitar otros ataques (XSS, SQLi, RCE). Errores verbosos → filtran información para otros ataques.
• Un atacante puede encontrar archivos internos o claves.
• Configuración insegura en la nube → buckets con datos de clientes públicos.
• Compromiso de sesiones (TLS/headers débiles → MITM/XSS).

Defensa:

• Hardening por capas de servidores y aplicaciones.  (servicios, cuentas, ACL, cloud).
• Eliminar funciones no necesarias (debug, directory listing). Eliminar servicios/rutas de debug y bloquear listing.
• Deny by default en configuraciones.
• Revisiones periódicas de configuración.
• Configuración segura de la nube (S3 privado, IAM correcto).
• Aplicar headers de seguridad bien configurados (CSP, HSTS, XFO, etc.) y protocolos modernos (TLS 1.2/1.3).
• Baseline y checklist (OWASP ASVS, mapeado a verificación de config).
• CORS específico (solo cuando haga falta, con lista blanca estricta; nunca * con credenciales).
• Errores genéricos hacia el cliente; detalles solo a logs internos.
• Desactivar DTD/XXE por defecto en parsers XML. (XXE ahora entra en A05).
• Forzar HTTPS + HSTS; revisar ciphers/PROTOS
• Añadir CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• Errores genéricos y logging seguro (sin secretos).
• Cloud: revisar ACL/Policies; private por defecto.

Cuadro práctico (A02)

Patrón típico	Definición breve	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Credenciales por defecto / cuentas habilitadas	Cuentas/admin por defecto sin cambiar o deshabilitar.	Consola /admin con admin/admin.	Probar combos por defecto y enumerar paneles conocidos.	Login exitoso con credenciales default.	Toma de control, fraude.	Deshabilitar cuentas, rotación/gestor de secretos.	“Default creds” ⇒ A02 inmediato.
Servicios/puertos/funciones innecesarios	Features habilitados sin necesidad (dir listing, paneles debug).	Directory listing en /statements/.	Fuzz de rutas (ffuf, feroxbuster), robots.txt, paneles (/actuator, /phpinfo).	Listado expone PDFs con extractos.	Exposición de PII/boletas.	Principio de mínimo servicio; desactivar listing/paneles.	“Función de debug en producción” ⇒ A02.
Errores verbosos / debug ON	Errores con stacktrace, versiones, rutas internas.	Error 500 muestra versión de framework y cadena de conexión.	Forzar errores con payloads y observar respuesta.	Identificar versión vulnerable por el error.	Info leakage → cadena de ataques.	Manejo de errores genéricos y logs internos.	Si el ítem menciona stacktrace/verbose errors ⇒ A05.
TLS/SSL mal configurado	Protocolos/ciphers inseguros, HSTS ausente.	Sitio banca acepta TLS 1.0 o RC4; sin HSTS.	nmap –script ssl-enum-ciphers, revisar headers (curl -I).	Downgrade/MITM.	Robo de sesión/credenciales.	TLS ≥1.2/1.3, HSTS, ciphers modernos.	“Falta HSTS” y “TLS viejo” entran en A05.
Headers de seguridad faltantes/débiles	CSP, XFO, X-CTO, Referrer-Policy, etc.	No hay Content-Security-Policy → XSS más fácil.	Chequear cabeceras en respuestas.	Clickjacking / XSS facilitado.	Ataques cliente-servidor.	Aplicar HTTP Security Headers recomendados.	Si proponen “agregar CSP/HSTS/XFO” es defensa correcta.
CORS mal configurado	Orígenes arbitrarios o demasiado amplios.	API bancaria permite Access-Control-Allow-Origin: * con datos sensibles.	Probar orígenes controlados, revisar ACAO/ACAC/ACAH.	Exfiltrar datos con exploit en otro dominio.	Robo de datos del usuario autenticado.	CORS específico y solo si es necesario; no usar * con credenciales.	CORS inseguro = A02; es configuración.
Archivos sensibles accesibles	.env, .git/, backups ~/.bak/.zip publicados.	Acceso a .env con claves DB/SMTP.	Fuzz extensiones y rutas comunes.	Descargar .env y tomar secrets.	Compromiso total.	Bloquear archivos ocultos, build/CI que excluya artefactos.	“.env/.git accesible” → A02.
Permisos de archivos/carpetas	ACL/permiso laxo en server o storage.	S3 con ACL pública a extractos.	Listar buckets/objetos, probar GET anónimo.	Leer PDFs de clientes.	Exposición masiva.	Principio de mínimo privilegio, private buckets.	“Cloud bucket público” calza A02.
Endpoints de mgmt expuestos	Consolas admin, métricas, health con datos.	/actuator/env devuelve secretos.	Descubrir endpoints; probar auth.	Leer config/secrets desde mgmt.	Pivoting y RCE.	Proteger con auth fuerte / red interna.	Salud/metrics no deben filtrar secretos.
Políticas de caché erróneas	Respuestas sensibles cacheables públicamente.	Extractos con Cache-Control: public.	Revisar headers de caché.	Obtener datos desde caché compartido.	Fuga de PII.	Cache-Control: no-store para datos sensibles.	Es un “misconfig” clásico.
XML/XXE habilitado	Parsers con DTD/entidades externas activas.	SOAP permite <!ENTITY xxe SYSTEM …>.	Inyectar DTD, probar lectura/SSRF.	Leer /etc/passwd vía XXE.	Fuga de archivos/red interna.	Deshabilitar DTD/XXE por defecto.	Desde 2021, XXE cayó bajo A02.
Version/stack disclosure	Banners de server/framework expuestos.	Header Server: Apache/2.4.x (Ubuntu).	Inspeccionar headers y páginas de error.	Fingerprinting para elegir exploit.	Acelera explotación (A06/A03).	Ocultar banners; WAF/CND sanitiza headers.	Info leakage = misconfig.

 

 

C5: Configuraciones seguras por defecto

«Seguro por defecto» significa que los productos son resistentes a las técnicas de explotación más comunes desde el primer momento, sin coste adicional. El software debe iniciarse en un estado seguro sin requerir una configuración exhaustiva por parte del usuario, garantizando así que la configuración predeterminada sea siempre la opción más segura.

La ventaja de tener una aplicación segura desde el principio es que libera a los desarrolladores de la carga de bloquear un sistema, proporcionándoles un producto ya seguro. Reduce el esfuerzo necesario para implementar productos de forma segura y ofrece mayor confianza en que se mantendrán seguros a lo largo del tiempo.

Amenazas

• Un atacante podría obtener acceso no autorizado explotando credenciales predeterminadas, débiles o conocidas que no hayan sido modificadas respecto de su estado original.
• Un atacante podría aprovechar configuraciones predeterminadas demasiado permisivas para acceder a recursos confidenciales o realizar acciones no autorizadas.
• Un atacante podría recopilar información confidencial al investigar funciones o servicios habilitados innecesariamente que están activos de manera predeterminada.
• Un atacante podría llevar a cabo ataques de secuencias de comandos entre sitios (XSS) explotando encabezados de seguridad predeterminados poco rigurosos que no brindan protección adecuada contra dichas amenazas.

Implementación

En las aplicaciones modernas en la nube, al crear aplicaciones, los desarrolladores también construyen su infraestructura, tomando decisiones sobre infraestructura, incluyendo configuraciones críticas para la seguridad, mientras escriben su código. Estas se implementan en una infraestructura creada y configurada mediante código, Infraestructura como Código (IaC), utilizando configuraciones aplicadas a nivel de aplicación (incluyendo servidor web y base de datos), contenedor, Función como Servicio o infraestructura. Por ejemplo, en el caso de las aplicaciones web, los permisos de carpeta deben seguir el principio de mínimo privilegio para limitar los derechos de acceso a los recursos. Al implementar aplicaciones web y móviles en producción, se debe deshabilitar la depuración.

¿Es importante que cuando los desarrolladores reúnen sus componentes de infraestructura:

1. Implemente configuraciones basadas en el principio de privilegio mínimo; por ejemplo: asegúrese de que su almacenamiento en la nube (S3 u otro) esté configurado para ser privado y se acceda a él durante la mínima cantidad de tiempo.
2. El acceso está denegado de forma predeterminada y se permite a través de una lista de permitidos.
3. Utilice imágenes de contenedores que se hayan escaneado para detectar vulnerabilidades de paquetes y componentes y se hayan extraído de un registro de contenedores privado.
4. Prefiera la configuración declarativa de la infraestructura a las actividades de configuración manual. A nivel básico, utilice plantillas de Infraestructura como Código para el aprovisionamiento y la configuración automatizados de su infraestructura en la nube y local. A nivel general, utilice Política como Código para aplicar políticas, incluyendo la asignación de privilegios.
   El uso de un formato declarativo permite gestionar estas políticas de forma similar al código fuente: incorporadas a un sistema de gestión de código fuente, versionadas, con control de acceso, sujetas a la gestión de cambios, etc.
5. Cifrado de tráfico: de forma predeterminada o no implemente canales de comunicación no cifrados en primer lugar

Verificación continua de configuraciones

Como parte del desarrollo de software, un desarrollador debe asegurarse de que el software esté configurado de forma segura por defecto a nivel de aplicación. Por ejemplo,

• El código que define la infraestructura debe seguir el principio del mínimo privilegio.
• Las configuraciones y funciones que no son necesarias, como cuentas, software y capacidades de demostración, deben deshabilitarse.

Herramientas

• Tfsec : análisis estático de código abierto para sus plantillas de Terraform
• Terrascan : análisis de vulnerabilidades de infraestructura como código
• Checkov : análisis de vulnerabilidades de código abierto e infraestructura como código
• Scout Suite es una herramienta de auditoría de seguridad multicloud de código abierto que actualmente admite: Amazon Web Services, Microsoft Azure, Google Cloud Platform
• merodeador
• Mapeador de nubes
• Snyk : escanea en busca de vulnerabilidades de código abierto, código, contenedores e infraestructura como código
• Trivy : Escanee en busca de vulnerabilidades de código abierto, código, contenedores e infraestructura como código
• KICS – Escaneo en busca de vulnerabilidades de infraestructura como código
• Kubescape : análisis de vulnerabilidades de Kubernetes
• Kyverno : Protección de Kubernetes mediante políticas

Seguridad de Configuración y la Trinchera de DevSecOps

Cuando hablamos de seguridad en aplicaciones modernas, no podés ignorar la configuración. No importa si tu código es perfecto, si usás las últimas versiones de tus dependencias o si tenés una arquitectura de microservicios impecable. Si tu aplicación está mal configurada, sos un blanco fácil. Configuración mal hecha es sinónimo de acceso no autorizado, fugas de datos y ejecuciones de código remoto. Y no es teoría: lo veo todos los días. La mayoría de los exploits más simples explotan una configuración por defecto insegura, una consola de debug expuesta o una dependencia vieja que nadie actualizó. Por eso, asegurar la configuración debería ser una prioridad desde el primer git init.

La configuración de cualquier aplicación debe seguir una lógica: debe ser repetible, automatizable y segura por defecto. Esta es la esencia del control de la versión 14 del estándar de verificación de seguridad de aplicaciones (ASVS). Se trata de tener un entorno de construcción que no dependa del estado de ánimo del desarrollador o de los “pasos mágicos” que sólo uno conoce. Todo debe estar versionado, en código, en pipelines de CI/CD, con validaciones automáticas de seguridad. Si necesitás meter mano en producción manualmente, ya perdiste.

Pipelines, Recompilaciones y el Mito del Backup Manual

El punto de partida es claro: si no podés reproducir tu aplicación con un solo comando, estás corriendo sobre hielo. El pipeline de CI/CD no solo debe compilar el código, sino ejecutar validaciones de seguridad, análisis de dependencias, pruebas estáticas y dinámicas. Todo eso automatizado. Si algo falla, la build se frena. No se negocia. Es el control 14.1.1 del ASVS y es clave para prevenir que errores humanos o dependencias inseguras lleguen a producción.

Pero esto no es solo prevención. También es recuperación. En un mundo donde la infraestructura es código, si te comprometen un servidor, no perdés tiempo revisando logs. Tirás ese nodo y levantás uno nuevo en segundos, con la misma configuración, desde el mismo pipeline. Si tenés que andar restaurando backups manuales, estás en 2005. Esto no es sólo eficiencia, es seguridad. Cada minuto que pasás lidiando con una máquina comprometida, es un minuto donde el atacante sigue adentro.

Compilar No Es Suficiente: Compilá Seguro

Otro punto crítico es cómo compilás tu aplicación. No alcanza con que compile: tiene que compilar seguro. Eso significa que el compilador tiene que estar configurado con todos los flags de seguridad posibles. Stack canaries, PIE, NX, ASLR, detección de overflows, todo habilitado. Si tu código C pasa sin warnings, es porque no estás compilando con suficiente paranoia. Cada warning ignorado es una vulnerabilidad potencial. Y si no estás interrumpiendo la build cuando aparecen funciones inseguras como strcpy() o gets(), estás dejando la puerta abierta de par en par.

Configuración del Servidor: No Confíes en el Default

Una vez que el código está listo, viene el despliegue. Y ahí entramos en un terreno que suele ser olvidado: la configuración del servidor. No alcanza con tirar el WAR en Tomcat o levantar el contenedor en Kubernetes. Tenés que reforzar la configuración del servidor, eliminar las aplicaciones de ejemplo, desactivar consolas de administración, configurar correctamente los headers de seguridad, y eliminar información innecesaria en respuestas HTTP. Esto no es opcional. Es un checklist que tiene que estar automatizado y validado con pruebas.

Dependencias: La Pólvora Mojada del Desarrollador

La seguridad de una aplicación hoy está directamente ligada a cómo gestionás tus dependencias. No se trata solo de actualizar versiones, sino de verificar, validar e inspeccionar cada librería que usás. Usar herramientas como OWASP Dependency-Check, Snyk o Trivy es una obligación, no una recomendación. Y eso incluye dependencias de frontend como librerías JS o CSS externas que vengan desde un CDN. Si estás cargando un script sin SRI (Subresource Integrity), estás confiando ciegamente en internet. Error fatal.

Tampoco alcanza con saber que usás lodash: tenés que saber qué versión, dónde y para qué. Esto es lo que impone el control 14.2.5: una lista de materiales de software (SBOM). Tiene que estar documentado todo lo que entra en tu build. Y no es solo para que lo vean los auditores. Es para vos. Así sabés qué parchear cuando aparezca la próxima vulnerabilidad en NPM o PyPI.

Cabezera HTTP: Tu Primera Línea de Defensa

Una respuesta HTTP mal construida puede dejar expuesto el corazón de tu backend. Por eso es vital reforzar todas las cabeceras. Tenés que tener Content-Type bien definido, Content-Disposition en las respuestas de API, X-Content-Type-Options: nosniff para evitar ataques MIME, Strict-Transport-Security para forzar HTTPS, Referrer-Policy para no filtrar info sensible, X-Frame-Options para evitar clickjacking, y ni hablar de la Content-Security-Policy que, bien configurada, puede ser tu escudo anti-XSS más sólido.

No hay excusas para no tener esto. Son headers. Son líneas de configuración. Se pueden automatizar, auditar y validar con herramientas como ZAP, Burp, curl, o incluso en el navegador.

Infraestructura como Código: El Ataque Silencioso

Pero la trinchera real de hoy es la Infraestructura como Código (IaC). Porque ahí es donde se define cómo vive y muere tu entorno. Es donde se cuela todo lo que se da por sentado: puertos abiertos, configuraciones default, secretos en texto plano, imágenes de contenedor vulnerables. Y lo peor es que esos errores no se ven hasta que alguien los explota. Lo he visto en pentests reales: acceso SSH sin restricción, S3 buckets abiertos, secrets expuestos en repos públicos. Todo por no validar las plantillas de Terraform, CloudFormation o Ansible.

Hoy, si no tenés linters y validadores como Checkov, TFLint o tfsec ejecutándose en cada PR, te estás disparando en el pie. Si tus imágenes de contenedor no pasan por Trivy, Clair o Dagda, estás firmando tu sentencia. Y si no usás bóvedas para los secretos (como HashiCorp Vault o AWS Secrets Manager), estás exponiendo claves de root en GitHub como si nada.

Seguridad por Diseño, no por Reacción

Nada de esto debería ser un parche a posteriori. La seguridad tiene que ser parte del diseño. Desde el pipeline, pasando por IaC, hasta el entorno en producción. DevSecOps no es un buzzword: es la única forma de sobrevivir a este nivel de automatización y complejidad. ¿Querés evitar ser parte del próximo breach? Entonces armá tus pipelines como si fueran sistemas de defensa. Versioná todo. Automatizá todo. Y sobre todo, rompé todo en staging antes de que alguien lo rompa en producción.

Nos vemos en la próxima entrega, donde voy a profundizar en cómo versionar y auditar infraestructura como código con técnicas que uso en entornos reales de alto riesgo. Porque asegurar el código es solo el principio: la guerra se gana configurando bien.

Infraestructura como Seguridad de Código: Haciendo de DevOps una Fortaleza

Hoy, Infraestructura como Código (IaC) no es una elección técnica, es un campo de batalla. Un entorno donde las decisiones que tomás con una línea YAML o HCL definen si tu sistema es una fortaleza inexpugnable o una piñata de vulnerabilidades esperando el primer exploit.

La velocidad con la que se mueve DevOps no te da respiro. Pushás código, disparás pipelines, clonás infra, desplegás microservicios, todo en minutos. Pero esa misma velocidad te puede cegar. El problema no es la automatización en sí, sino automatizar sin consciencia de seguridad. La mayoría de los entornos cloud hoy en producción están construidos con IaC mal configurada, vulnerable por omisión. Es una caja negra que compila y sube entornos que nadie se toma el tiempo de auditar con cabeza de atacante.

Seguridad como Código: No Opcional, Obligatorio

Cuando hablás de CI/CD real, cuando ya no hay tiempo para QA manual o revisiones de seguridad a mano, no podés seguir tratando a la seguridad como algo aparte. Tiene que ser código. Seguridad como Código no es una frase de marketing: es transformar la seguridad en un asset del pipeline. Eso significa linters de configuración, pruebas de seguridad automatizadas, control de versiones de reglas de cumplimiento, y sobre todo, análisis estáticos y dinámicos integrados directamente en el ciclo.

No estamos en 2010. Si tu análisis de IaC corre después del despliegue, estás jugando a tapar incendios con cucharas. La seguridad hay que integrarla antes de que se provisionen los recursos. La revisión tiene que estar en el mismo commit que define la red, las reglas de firewall, los permisos de IAM, el tipo de instancia, el puerto abierto o cerrado. Porque después es tarde.

Los Cuatro Pilares: Seguridad al Ritmo del Pipeline

En IaC, la defensa se construye sobre cuatro columnas: cumplimiento continuo, evaluación dinámica de riesgos, cifrado por defecto y monitoreo inteligente. Todo esto se puede automatizar. De hecho, si no lo automatizás, no lo estás haciendo.

Cumplimiento continuo significa que cada pieza de código que configura tu infraestructura tiene que ser validada contra políticas internas y estándares globales (HIPAA, PCI, SOC2). ¿Querés abrir un puerto? ¿Desplegar en producción? ¿Usar una imagen base? No sin pasar por el escáner. Las reglas no son una documentación en PDF guardada en un drive: son validadores automáticos que rompen el build si algo no cumple.

Evaluación continua de riesgos es más que un escaneo de vulnerabilidades. Es entender cómo cada cambio afecta tu superficie de ataque. ¿Esa nueva instancia EC2? ¿Con qué se conecta? ¿Se integra a una zona que maneja datos regulados? ¿Se rompe el aislamiento? Cada cambio IaC necesita ser modelado como amenaza. Y ese modelado también se puede automatizar. Con herramientas que entienden dependencias, contextos de red, permisos cruzados y relaciones lógicas entre recursos.

El cifrado no se discute. Todo lo que no está cifrado por defecto, está en peligro. Secrets, tokens, passwords, claves privadas, archivos de configuración. Si vivís en texto plano, estás al borde de un incidente. TLS para todo, KMS para manejar claves, SOPS para cifrar YAMLs, Vault para orquestar secretos. Y nada de meter secretos en Git, jamás.

Y finalmente, la automatización de la observación. Monitorear la infraestructura no es esperar que algo falle. Es interceptar comportamiento anómalo antes de que explote. Usá CloudWatch, usá Prometheus, usá Falco, usá lo que quieras, pero hacelo. Hoy, si no estás recolectando logs, auditando accesos y correlacionando eventos con inteligencia artificial, estás manejando una nube ciega.

Desplazá la Seguridad a la Izquierda o Viví a la Derecha en Incendios

La idea de «shift-left security» no es nueva, pero es más urgente que nunca. Porque los errores en la infraestructura ya no se ven en staging: llegan a producción en segundos. Y corregir errores de configuración con infraestructura viva es como cambiar las ruedas de un avión en vuelo. Si los análisis de IaC, las validaciones y los tests de cumplimiento ocurren después de desplegar, no estás haciendo DevSecOps. Estás reaccionando.

Con IaC bien aplicada, podés hacer todo preventivamente. Antes de aprovisionar. Antes de romper cosas. Antes de comprometer datos. Podés capturar vulnerabilidades, prevenir escaladas de privilegios, detectar malas configuraciones. Pero para eso necesitás herramientas que hablen el lenguaje del pipeline: CircleCI, Jenkins, GitHub Actions, lo que uses. Y necesitás herramientas que entiendan múltiples nubes, múltiples formatos (Terraform, CloudFormation, ARM), y que apliquen las mismas reglas antes, durante y después del despliegue.

SAST y DAST para la Infraestructura: Análisis Estructural y de Contexto

En seguridad de aplicaciones ya aprendimos que necesitás SAST (estático) para revisar el código fuente y DAST (dinámico) para verificar su comportamiento real. Lo mismo aplica a IaC. El análisis estático te permite identificar reglas mal configuradas, puertos expuestos, permisos exagerados. El análisis dinámico va más allá: te dice cómo ese recurso impacta en la red, qué conecta, qué permisos hereda. Un firewall puede estar bien definido, pero si se conecta a un recurso crítico sin segmentación, igual estás expuesto.

La combinación de ambos enfoques te da una visión completa. Pero también aumenta la necesidad de una política clara. ¿Qué bloqueás? ¿Qué advertís? ¿Qué dejás pasar? Necesitás un plano de control que unifique decisiones. Un lugar donde definís políticas que se aplican al código, al entorno, a la red, y a los datos. Un único lenguaje de seguridad. Una verdad compartida entre Dev, Ops y Sec.

Preguntas que Tenés que Hacerte Si Quieres Seguridad Real en IaC

¿Usás más de una nube? Entonces necesitás herramientas que no sean vendor lock-in. ¿Usás más de una herramienta IaC? Entonces tenés que unificar tu validación. ¿Tus políticas se aplican en build y en producción? ¿Podés auditar el cumplimiento por contexto de aplicación? ¿Podés detener una build si un recurso viola una política HIPAA? Si no podés responder todo eso, tenés un agujero esperando a ser explotado.

Y no se trata solo de herramientas. Se trata de cultura. Cultura de responsabilidad compartida. Donde los devs entienden seguridad porque tienen feedback en tiempo real. Donde los equipos de seguridad no bloquean, sino que habilitan. Donde el cumplimiento es parte del diseño, no un paso doloroso al final.

Codificá la Seguridad o Esperá el Incidente

La Infraestructura como Código cambió las reglas. Ahora la seguridad tiene que ser parte del código fuente. Parte del pull request. Parte del pipeline. Parte del commit. No hay otra forma de escalar con seguridad real.

Si no desplazás la seguridad hacia la izquierda, vas a vivir en la derecha, apagando fuegos, escribiendo informes post-mortem y gestionando crisis. Pero si lo hacés bien, si integrás seguridad como código, vas a construir una infraestructura inmutable, auditable, escalable y, sobre todo, segura.

Y eso, en el mundo real, es lo que separa a los ingenieros que construyen sistemas a prueba de balas, de los que viven corriendo detrás de los exploits.

Nos vemos en la próxima entrega, donde vamos a meter mano directamente al escaneo automatizado de Terraform con linters, políticas personalizadas, validación de seguridad e integración CI/CD. Porque IaC sin hardening es solo YAML con fecha de muerte.

Configuración V14

Objetivo de control

Asegúrese de que una aplicación verificada tenga:

• Un entorno de construcción seguro, repetible y automatizable.
• Gestión de bibliotecas, dependencias y configuraciones de terceros reforzada, de modo que la aplicación no incluya componentes obsoletos o inseguros.

La configuración de la aplicación lista para usar debe ser segura para estar en Internet, lo que significa una configuración segura lista para usar.

V14.1 Compilación e implementación

Las canalizaciones de compilación son la base de una seguridad repetible: cada vez que se detecta una inseguridad, se puede resolver en el código fuente, en los scripts de compilación o de implementación, y probarse automáticamente. Recomendamos encarecidamente el uso de canalizaciones de compilación con comprobaciones automáticas de seguridad y dependencias que adviertan o interrumpan la compilación para evitar que los problemas de seguridad conocidos se implementen en producción. La ejecución irregular de pasos manuales conduce directamente a errores de seguridad evitables.

A medida que la industria avanza hacia un modelo DevSecOps, es fundamental garantizar la disponibilidad e integridad continuas de la implementación y la configuración para lograr un estado de «buen funcionamiento». Anteriormente, si un sistema era atacado, se tardaba días o meses en demostrar que no se habían producido más intrusiones. Hoy, con la llegada de la infraestructura definida por software, las rápidas implementaciones A/B sin tiempo de inactividad y las compilaciones automatizadas en contenedores, es posible construir, reforzar e implementar de forma automática y continua un reemplazo de «buen funcionamiento» para cualquier sistema comprometido.

Si todavía se utilizan modelos tradicionales, se deben tomar medidas manuales para reforzar y respaldar esa configuración para permitir que los sistemas comprometidos se reemplacen rápidamente con sistemas de alta integridad y sin compromisos de manera oportuna.

El cumplimiento de esta sección requiere un sistema de compilación automatizado y acceso a scripts de compilación e implementación.

Dependencia V14.2

La gestión de dependencias es fundamental para el funcionamiento seguro de cualquier aplicación. La falta de actualización de dependencias obsoletas o inseguras es la causa principal de los ataques más grandes y costosos hasta la fecha.

Nota: En el Nivel 1, el cumplimiento de la norma 14.2.1 se relaciona con la observación o detección de bibliotecas y componentes del lado del cliente y de otros tipos, en lugar del análisis de código estático o de dependencias en tiempo de compilación, que es más preciso. Estas técnicas más precisas podrían detectarse mediante entrevistas, según sea necesario.

V14.3 Divulgación de seguridad no intencionada

Las configuraciones de producción deben reforzarse para protegerse contra ataques comunes, como las consolas de depuración, aumentar la exigencia de ataques de secuencias de comandos entre sitios (XSS) e inclusión remota de archivos (RFI), y eliminar vulnerabilidades triviales de descubrimiento de información, que suelen ser el sello distintivo de muchos informes de pruebas de penetración. Muchos de estos problemas rara vez se consideran un riesgo significativo, pero están vinculados a otras vulnerabilidades. Si estos problemas no están presentes por defecto, se aumenta la exigencia antes de que la mayoría de los ataques tengan éxito.

Hoja de referencia de seguridad de infraestructura como código

La infraestructura como código (IaC), también conocida como infraestructura definida por software, permite la configuración y la implementación de componentes de infraestructura de forma más rápida y consistente al permitir que se definan como un código y también permite implementaciones repetibles en distintos entornos.

Mejores prácticas de seguridad

A continuación se presentan algunas de las mejores prácticas de seguridad para IaC que se pueden integrar fácilmente en el ciclo de vida del desarrollo de software:

Desarrollar y distribuir

• Plugins de IDE: Aproveche los plugins de seguridad estándar del entorno de desarrollo integrado (IDE), lo que facilita la detección temprana de riesgos potenciales y reduce drásticamente el tiempo necesario para abordar cualquier problema posterior en el ciclo de desarrollo. Plugins como TFLint, Checkov, Docker Linter, docker-vulnerability-extension, Security Scan, Contrast Security, etc., facilitan la evaluación de seguridad del IaC.
• Modelado de amenazas: cree el panorama de modelado de amenazas más temprano en el ciclo de desarrollo para garantizar que haya suficiente visibilidad de los aspectos de alto riesgo y gran volumen del código y flexibilidad para incluir seguridad en todo momento para garantizar que los activos se gestionen de forma segura.
• Gestión de secretos: Los secretos son datos e información confidenciales, como tokens de aplicación necesarios para la autenticación, contraseñas y claves SSH (Secure Shell). El problema no son los secretos, sino dónde se almacenan. Si se utiliza un archivo de texto simple o SCM como Git, los secretos pueden quedar expuestos fácilmente. Se pueden utilizar herramientas de código abierto como truffleHog, git-secrets, GitGuardian y similares para detectar este tipo de gestión vulnerable de secretos. Consulte la Guía práctica de gestión de secretos para obtener más información.
• Control de versiones: El control de versiones consiste en rastrear y gestionar los cambios en el código de software. Asegúrese de que todos los cambios en el IaC se rastreen con la información correcta, lo que facilita cualquier operación de reversión. Lo importante es que registre esos cambios junto con las características que soportan, y no por separado. Los requisitos de infraestructura de una característica deben formar parte de la rama o solicitud de fusión de la característica. Git se utiliza generalmente como sistema de control de versiones del código fuente.

Principio de mínimo privilegio: defina las políticas de gestión de acceso según el principio de mínimo privilegio con los siguientes elementos de prioridad:

• Definir quién está y quién no está autorizado a crear/actualizar/ejecutar/eliminar los scripts y el inventario.
• Limitar los permisos de los usuarios autorizados de IaC a lo necesario para realizar sus tareas. Los scripts de IaC deben garantizar que los permisos otorgados a los distintos recursos que crea se limiten a lo necesario para que realicen su trabajo.
• Análisis estático: Analiza el código de forma aislada, identificando riesgos, errores de configuración y fallos de cumplimiento relevantes únicamente para el IaC. Herramientas como kubescan, Snyk, Coverity, etc., permiten realizar análisis estáticos del IaC.
• Comprobación de dependencias de código abierto: Analiza las dependencias de código abierto, como paquetes del sistema operativo, bibliotecas, etc., para identificar posibles riesgos. Herramientas como BlackDuck, Snyk, WhiteSource Bolt para GitHub y similares pueden utilizarse para el análisis de dependencias de código abierto de IaC.
• Análisis de imágenes de contenedores: El análisis de imágenes se refiere al proceso de analizar el contenido y la compilación de una imagen de contenedor para detectar problemas de seguridad, vulnerabilidades o riesgos potenciales. Herramientas de código abierto como Dagda, Clair, Trivy, Anchore, etc., pueden utilizarse para el análisis de imágenes de contenedores. Canalización de CI/CD e informes consolidados: al permitir que las comprobaciones de seguridad estén disponibles en la canalización de CI/CD, se puede analizar cada cambio de código, se elimina la necesidad de intervención manual y se puede mantener el historial de cumplimiento. Junto con los informes consolidados, estas integraciones aceleran el desarrollo de una base de código IaC segura. Herramientas de código abierto como Jenkins, etc., pueden utilizarse para compilar las canalizaciones de CI/CD, y DefectDojo y OWASP Glue pueden ayudar a integrar las comprobaciones y visualizar sus resultados en un único panel.
• Firma de artefactos: la firma digital de artefactos durante la compilación y la validación de los datos firmados antes de su uso protegen los artefactos contra manipulaciones entre la compilación y la ejecución, garantizando así su integridad y procedencia. Herramientas de código abierto como TUF facilitan la firma digital de artefactos.

Desplegar

• Gestión de inventario:
• Puesta en servicio: siempre que se implemente un recurso, asegúrese de que el mismo esté etiquetado, rastreado y registrado como parte de la gestión del inventario.
• Desmantelamiento: siempre que se inicia la eliminación de un recurso, asegúrese de que se borren las configuraciones subyacentes, se eliminen los datos de forma segura y el recurso se elimine por completo del tiempo de ejecución, así como de la gestión de inventario.
• Etiquetado: Es fundamental etiquetar correctamente los activos en la nube. Durante las operaciones de IaC, es muy probable que los activos sin etiquetar generen recursos fantasma que dificultan la detección, visualización y observación en el entorno de la nube, y pueden afectar la postura, causando una desviación. Estos recursos fantasma pueden incrementar los costos de facturación, dificultar el mantenimiento y afectar la confiabilidad. La única solución es etiquetar y monitorear cuidadosamente los recursos sin etiquetar.
• Análisis dinámico: El análisis dinámico ayuda a evaluar los entornos y servicios existentes con los que interoperará o en los que se ejecutará. Esto ayuda a detectar posibles riesgos derivados de la interoperabilidad. Se pueden utilizar herramientas de código abierto como ZAP, Burp, GVM, etc., para el análisis dinámico.

Tiempo de ejecución

• Inmutabilidad de la infraestructura: La idea detrás de la infraestructura inmutable es construir los componentes de la infraestructura según un conjunto preciso de especificaciones. Sin desviaciones, sin cambios. Si se requiere un cambio en una especificación, se aprovisiona una infraestructura completamente nueva según los requisitos actualizados, y la infraestructura anterior se retira del servicio por obsoleta.
• Registro: Mantener un registro es fundamental para controlar los riesgos. Debe habilitar el registro (tanto de seguridad como de auditoría) al aprovisionar la infraestructura, ya que ayuda a evaluar los riesgos de seguridad relacionados con los activos sensibles. También ayuda a analizar la causa raíz de los incidentes e identificar posibles amenazas. Se pueden utilizar herramientas de código abierto como ELK, entre otras, para el análisis de registros.
• Monitoreo: El monitoreo continuo ayuda a detectar cualquier violación de seguridad y cumplimiento, a identificar ataques y a emitir alertas sobre dichos incidentes. Algunas soluciones también incorporan nuevas tecnologías como la IA para identificar amenazas potenciales de forma temprana. Herramientas de código abierto como Prometheus, Grafana, etc., pueden utilizarse para monitorear la infraestructura en la nube.
• Detección de amenazas en tiempo de ejecución: Implementar una solución de detección de amenazas en tiempo de ejecución ayuda a reconocer comportamientos inesperados de la aplicación y a alertar sobre amenazas en tiempo de ejecución. Se pueden utilizar herramientas de código abierto como Falco, etc., para la detección de amenazas en tiempo de ejecución. Algunas aplicaciones, como Contrast (Contrast Community Edition), también pueden detectar los 10 principales ataques de OWASP en la aplicación durante el tiempo de ejecución y ayudar a bloquearlos para protegerla y asegurarla.

Asegurar la infraestructura como código

La demanda de una entrega más rápida de aplicaciones ha dado lugar a prácticas eficientes de desarrollo e implementación como DevOps. Para entregar aplicaciones a la creciente demanda, el panorama de TI requiere una infraestructura próspera, estable y competitiva que mantenga la infraestructura de hardware subyacente. Y aquí es donde la Infraestructura como Código (IaC) entra en escena. En una de mis entradas anteriores, hablé extensamente sobre  IaC y por qué debería adoptarla , y cómo puede aprovecharla eficazmente en la anterior, titulada »  Mejores prácticas y herramientas que elevarán su Infraestructura como Código» .

DevOps permite una entrega rápida, e IaC permite una infraestructura más veloz para esta entrega mediante el control de versiones. Un aspecto en el que todos debemos centrarnos durante este proceso rápido y continuo es la seguridad continua. Según un reciente  Informe sobre Amenazas en la Nube  de Unit 42 de Palo Alto Networks, existen más de 199 000 vulnerabilidades potenciales en las plantillas de IaC en uso. Esta cifra destaca la importancia de contar con rigurosas medidas de seguridad en la Infraestructura como Código. Es posible que encuentre algunos desafíos al ajustar la velocidad de los ciclos de CI/CD a través de IaC, como tener una vulnerabilidad sin parchear en su herramienta de IaC. Esta vulnerabilidad sin parchear puede convertirse en una puerta de entrada de amenazas a su infraestructura principal. Si sus plantillas de IaC no están configuradas correctamente, existe una alta probabilidad de ataques y exposición de datos confidenciales. Veamos algunas áreas destacadas de amenazas en IaC y algunas maneras sencillas de proteger su IaC de estas amenazas.

Áreas de riesgo de seguridad en IaC y medidas a tomar para evitar ataques –

• Canales de comunicación:  La mayoría de las principales herramientas de gestión de configuración de IaC utilizan una arquitectura de nodo maestro. En esta arquitectura, el nodo maestro gestiona todos los nodos. El problema de acceder a la infraestructura gestionada desde un único punto es que este punto único, o nodo maestro, es el que contiene todas las especificaciones relacionadas con la implementación. Por lo tanto, si no se protege correctamente, se podría poner en riesgo toda la infraestructura. La solución es utilizar un canal de comunicación seguro para que el nodo maestro se comunique y gestione los nodos. Prepare entornos en la nube para reducir el riesgo de vulnerabilidades derivadas de configuraciones incorrectas y configure su infraestructura desde cero. También puede utilizar un agente personalizado para gestionar el nodo o aprovechar cualquier software y protocolo de comunicación disponibles para la gestión de los nodos.
• Gestión de acceso de usuarios:  Es habitual usar la aplicación IaC para gestionar la implementación de aplicaciones. Estas aplicaciones no suelen requerir privilegios de root en el equipo de destino. De esta forma, se evitan ceder privilegios innecesarios y compartir las credenciales del proveedor de la nube con acceso de administrador para tareas con menos privilegios. Esto se basa en el principio del mínimo privilegio, según el cual cualquier usuario, programa o proceso tiene los privilegios mínimos necesarios para realizar una tarea específica. Para principiantes, se puede restringir el número de usuarios con acceso administrativo. También se puede optar por AWS Identity and Access Management (IAM), un servicio web que ayuda a controlar de forma segura el acceso a los recursos de AWS, siempre que se utilice la nube de AWS.
• Desviaciones en la configuración:  En ocasiones, es posible que su equipo de operaciones necesite cambiar la configuración directamente en el entorno de producción. Esto podría afectar la estabilidad de la infraestructura. Existe una alta probabilidad de que se introduzcan riesgos al cambiar la configuración, lo que provoca que la nube se desvíe de la postura segura definida por IaC. La respuesta a la cuestión de las desviaciones en la configuración es una práctica sencilla: crear una nueva infraestructura para actualizar, atender o modificar cualquier aspecto. La monitorización frecuente de la infraestructura de la nube y de IaC puede identificar desviaciones existentes o potenciales que pueden abordarse rápidamente.
• Recursos fantasma:  Es fundamental etiquetar correctamente los activos en la nube. Durante las operaciones de IaC, es muy probable que los activos sin etiquetar generen recursos fantasma que dificultan la detección, visualización y observación en el entorno de la nube, y pueden afectar la postura, causando una desviación. Estos recursos fantasma pueden incrementar la facturación, dificultar el mantenimiento y afectar la confiabilidad. La única solución es etiquetar y monitorear cuidadosamente los recursos sin etiquetar.
• Riesgos relacionados con la transmisión de datos:  Proteger sus servidores no es suficiente. Con frecuencia, la información o los datos pueden salir de ellos. Los riesgos en la transmisión de datos son cada vez más visibles, y los casos de robo de información transmitida son cada vez más comunes. Ante la proliferación de ciberataques, es fundamental tomar en serio los desafíos de seguridad. Para reducir los riesgos relacionados con la transmisión de datos, utilice VPN y cifrado de capa de sockets seguros (SSL) para proteger las transmisiones. Cifre sus datos o archivos antes de transmitirlos. También puede analizar los datos utilizando agentes de seguridad de acceso a la nube (CASB) para identificar posibles amenazas.
• Registros de auditoría:  Mantener un registro es fundamental para supervisar los accesos de riesgo. Debe habilitar los registros de auditoría al aprovisionar la infraestructura en la nube, ya que ayudan a evaluar los riesgos de seguridad relacionados con los activos sensibles. También ayudan a analizar la causa raíz de los incidentes e identificar posibles amenazas. Puede utilizar herramientas de registro y monitorización como Amazon CloudWatch, Splunk, Datadog, Elastic, AWS CloudTrail, etc.
• Plantillas IaC:  El elemento más crucial de IaC son las plantillas. Estas plantillas permiten una implementación ágil y gestionan la infraestructura en la nube, proporcionando instancias de computación y contenedores con imágenes base almacenadas en registros de confianza. En ocasiones, las plantillas pueden generar amenazas involuntariamente debido al sistema operativo o a imágenes de contenedor de fuentes desconocidas o no confiables. Es muy probable que las plantillas IaC contengan configuraciones predeterminadas inseguras y vulnerabilidades que puedan amenazar el sistema en general. Realice una evaluación de vulnerabilidades de las imágenes referenciadas en los archivos IaC. Asegúrese de comprobar si las plantillas IaC presentan configuraciones inseguras u otras vulnerabilidades al inicio del proceso de desarrollo. No olvide realizar revisiones periódicas para identificar configuraciones incorrectas.
• Los secretos:  La aplicación IaC utiliza diversas formas de describir el entorno de destino, como la configuración, el almacenamiento y los secretos, para conectarse a la infraestructura administrada. Los secretos suelen ser datos e información confidenciales, como los tokens de aplicación necesarios para la autenticación, las contraseñas y las claves SSH (Secure Shell Keys). El problema no son los secretos, sino dónde se almacenan. Si se utiliza un archivo de texto o Word simple, o SCM como Git, los secretos pueden exponerse fácilmente. La solución es relativamente sencilla: utilice bóvedas para almacenar todos los secretos de la aplicación y referenciarlos dentro de los archivos de configuración en lugar de los secretos.

Además de las amenazas y las maneras de mitigarlas, existen buenas prácticas de seguridad específicas para IaC que puede implementar fácilmente en sus procesos de SDLC e IaC. Estas son algunas de las más sencillas:

• Utilice complementos de seguridad estándar en el entorno de desarrollo integrado (IDE).
• Monitorear continuamente el entorno de producción para buscar problemas relacionados con violaciones de seguridad y cumplimiento durante los cambios automatizados y manuales ayudará a mitigar los riesgos lo antes posible.
• El uso frecuente de entornos sandbox para implementar y probar antes de llevar cualquier cambio a producción puede ayudar a comprender si el cambio cumple con los requisitos de seguridad y cumplimiento.
• Analice siempre el código estático (infraestructura) antes de la implementación realizando pruebas unitarias de seguridad y cumplimiento de las plantillas donde las plantillas se consideran el software.
• Aplique siempre los parches de seguridad inmediatamente cuando estén disponibles o publicados, ya que pueden contener correcciones esenciales.
• Asegúrese de cumplir con los principales estándares regulatorios, como el RGPD, HIPAA, PCI y SOC2. Una forma sencilla sería implementar políticas de protección.

El uso de la nube y DevOps está en auge por razones obvias. IaC desempeña un papel crucial en DevOps y la automatización de la seguridad en la nube. Existen diversas herramientas que pueden ayudarle a aprovisionar, organizar y gestionar componentes de infraestructura como CloudFormation y Terraform, así como a instalar, actualizar y gestionar software en ejecución en componentes de infraestructura como Ansible, Chef y Puppet. Sin duda, estas herramientas facilitarán la implementación de IaC. Sin embargo, es recomendable utilizarlas correctamente para proteger su implementación de IaC. Estas herramientas automatizarán muchos procesos y reducirán los errores que pueden producirse debido a las tareas manuales. Las prácticas mencionadas anteriormente le ayudarán a proteger áreas importantes de sus iniciativas de IaC. Para más información, póngase en contacto con nuestros expertos en SecOps.

Infraestructura como seguridad de código

La Infraestructura como Código y el concepto más amplio de DevOps para aplicaciones empresariales están acelerando el uso de la computación en la nube. Las empresas están trasladando sus soluciones, datos y procesos a la nube y aprovechando sus ventajas, como la automatización y el escalado eficiente.

A medida que el ritmo de los ciclos de desarrollo e implementación se acelera, la Infraestructura como Código se convierte en la única manera de satisfacer las demandas operativas. Mantenerse al día con el rápido ritmo de los ciclos de

CI/CD actuales no está exento de desafíos.

Uno de los mayores desafíos que enfrentan los desarrolladores e ingenieros de DevOps es la seguridad. Cuando el ciclo de CI/CD es muy rápido, es fácil descuidar aspectos importantes de seguridad. Aquí es donde la integración de la Seguridad como Código (seguridad de la información como parte inseparable de DevOps) resulta muy útil.

Comprender los desafíos de la seguridad de la infraestructura como código

El concepto IaC automatiza muchos aspectos de la implementación y el aprovisionamiento en la nube. En lugar de configurar manualmente el hardware físico y los nodos en la nube, ahora puede diseñar un plan y automatizar muchos procesos mediante formatos como CloudFormation Template o soluciones de terceros como Terraform .

Sin embargo, una configuración incorrecta puede dejar todo el entorno de la nube vulnerable a ciberataques. La atención al detalle se vuelve crucial cuando casi todo lo relacionado con la implementación de la infraestructura está automatizado. Las evaluaciones de seguridad manuales realizadas periódicamente ya no son suficientes.

También existen desafíos relacionados con la seguridad de los scripts y códigos. Anteriormente, las pruebas se realizaban una vez que la aplicación completa se encontraba en su fase de prueba. Este enfoque ya no es efectivo, ya que las actualizaciones se implementan en incrementos más pequeños y sin interrumpir el funcionamiento de la aplicación.

El cambio de infraestructura es otro desafío a resolver. Si bien la plantilla de implementación está predeterminada, el entorno de la nube está programado para ser escalable y flexible a la vez. Cuando se producen picos de tráfico o errores que mitigar, el entorno de la nube se autoajusta.

Estos desafíos no pueden resolverse con los métodos de seguridad tradicionales. Con la creciente popularidad de la Infraestructura como Código, también aumenta la necesidad de medidas de seguridad optimizadas, mejores políticas de seguridad y pruebas y revisiones de seguridad igualmente ágiles.

4 principios fundamentales de seguridad

La integración de la seguridad en el flujo de trabajo de DevOps solo es posible una vez definidos correctamente los pilares (los principios fundamentales de seguridad). Con la creciente popularidad de IaC, existen cuatro principios de seguridad que deben mantenerse siempre durante todo el ciclo de CI/CD.

Cumplimiento continuo

El cumplimiento continuo es fundamental para la seguridad de la información en la era de la IaC. Los códigos, incluidos los asociados con el aprovisionamiento de recursos en la nube y la implementación de servicios en la nube, deben seguir un estricto conjunto de normas y estándares. Es necesario implementar controles de cumplimiento de seguridad para que todos los involucrados en el proceso los sigan.

Por ejemplo, los códigos deben verificarse con un estándar IDE , modelarse con amenazas conocidas y ser revisados ​​por pares antes de enviarse al repositorio principal. Esta es la primera línea de defensa que permite una seguridad mejor y más optimizada como proceso.

La confirmación previa y la posibilidad de realizar pruebas previas automatizadas optimizan aún más el flujo. Cuando el código supera la revisión anterior, se prueba automáticamente en un entorno aislado. Se implementan estándares más estrictos, como el Análisis de Composición de Software (SCA) , y modelos basados ​​en amenazas de seguridad conocidas.

Los códigos se envían al repositorio fuente. Antes de enviarlos a un repositorio binario —y finalmente al entorno de producción—, deben someterse a comprobaciones adicionales. Con este enfoque, el cumplimiento normativo se convierte en una parte integral del proceso.

Evaluación continua de riesgos y modelado de amenazas

Otra tarea importante es minimizar la superficie de ataque de su entorno en la nube. Esto se logra mediante una evaluación continua de riesgos que involucra a todos los componentes del entorno. Cuando se detectan vulnerabilidades de seguridad o servicios con un riesgo elevado, se deben implementar cambios de inmediato.

El modelado de amenazas permite garantizar que la evaluación de riesgos se base en los modelos más recientes y los más altos estándares de seguridad. Existen proveedores de servicios externos que ofrecen modelos de amenazas para uso inmediato si desea acelerar el proceso.

Minimizar las superficies de ataque también implica optimizar el control de acceso y los firewalls. AWS IAM , por ejemplo, permite configurar el privilegio mínimo requerido para microservicios dentro de contenedores, automatizando el proceso y manteniendo un cierto nivel de seguridad.

Los motores de computación como EC2, los bloques de almacenamiento, las API accesibles desde fuera del entorno de la nube y los microservicios front-end deben recibir especial atención. Estos componentes deben revisarse y supervisarse de cerca para limitar su exposición a ciberataques.

El cifrado de datos como requisito

El cifrado de datos es el tercer pilar de la seguridad IaC. La información y los archivos confidenciales, como la información de clientes, los datos financieros o los secretos de Kubernetes, deben cifrarse de forma predeterminada. Y lo que es más importante, las transmisiones de datos desde y hacia el entorno de la nube deben recibir el mismo tratamiento.

Los datos en tránsito son vulnerables. SSL y TLS siguen siendo los dos métodos utilizados para proteger los datos en tránsito, pero las herramientas nativas de AWS facilitan la incorporación de capas de seguridad. AWS Certificate Manager gestiona las claves y certificados seguros, pero ahora es la única herramienta disponible.

Amazon CloudFront  es compatible con HTTPS de forma nativa. Amazon RDS funciona con cifrado SSL/TLS en todas las instancias de bases de datos. Lo mismo ocurre con Amazon Redshift . El resto del ecosistema de la nube puede seguir las prácticas recomendadas de seguridad de AWS para mantener la máxima seguridad.

Automatizar la monitorización y las alertas

El último componente es la monitorización continua del entorno de nube implementado, con automatización y alertas. En entornos como AWS, la monitorización continua va más allá de la identificación de ataques y la alerta a ingenieros de DevOps o administradores de la nube. La monitorización moderna incorpora nuevas tecnologías como la IA para identificar posibles amenazas de forma temprana.

La detección de anomalías en AWS CloudWatch es un buen ejemplo de cómo se pueden utilizar las herramientas nativas para mejorar la seguridad. La combinación de CloudWatch con herramientas como Amazon Athena permite a los ingenieros de DevOps optimizar con mayor agilidad su repositorio de modelos de amenazas. Con cada ciclo completado (y el aprendizaje de nuevos modelos de amenazas), todo el flujo se vuelve más seguro.

El resultado es DevOpsSec, un concepto donde la seguridad se integra al flujo de trabajo ágil de las empresas modernas. Los cuatro principios que se abordan en este artículo son los elementos necesarios para establecer una mejor seguridad para su flujo de trabajo de Infraestructura como Código. La Seguridad como Código se convierte en una posibilidad al integrarla desde el principio.

Trasladar la seguridad en la nube a la izquierda con la infraestructura como código

Introducción y resumen ejecutivo

DevOps y la integración continua/implementación continua (CI/CD) están revolucionando el desarrollo, las pruebas y la distribución de aplicaciones en la nube, permitiendo a los desarrolladores escribir el código de la aplicación y definir la infraestructura en la nube. Pero ¿dónde está la seguridad en la nube? 

Lamentablemente, hasta la fecha, las prácticas de seguridad y cumplimiento han sido principalmente reactivas, ya que los equipos se esfuerzan por detectar configuraciones incorrectas, riesgos y violaciones de cumplimiento de la infraestructura de la nube después del aprovisionamiento o la creación (es decir, «en tiempo de ejecución»). 

Depender de la detección en tiempo de ejecución aumenta significativamente los riesgos de seguridad y cumplimiento normativo. También reduce la productividad, ya que los desarrolladores deben dedicar su tiempo a solucionar problemas en el lugar y momento equivocados (más sobre esto más adelante). Esta dependencia de la seguridad en tiempo de ejecución también genera fricción entre los desarrolladores y los profesionales de seguridad, lo que aumenta la probabilidad de que los desarrolladores intenten eludir la seguridad por completo. 

Desplazar la seguridad en la nube hacia la izquierda cambia por completo esta dinámica, mejorando la productividad de los desarrolladores y eliminando los riesgos de seguridad y cumplimiento normativo antes del tiempo de ejecución. Las organizaciones pueden lograr este cambio integrando la seguridad en la nube en el proceso de CI/CD y evaluando las plantillas de Infraestructura como Código (IaC) antes de una compilación para detectar los mismos problemas de seguridad y cumplimiento normativo que la organización ahora evalúa en tiempo de ejecución. 

Este cambio a la izquierda permite escalar la seguridad en la nube y permite a los desarrolladores ser más productivos (y realmente ayuda a que la seguridad deje de ser una palabra de cuatro letras para los desarrolladores). Con este cambio, los equipos de seguridad presentan los riesgos de seguridad en el lugar y momento adecuados, a la vez que guían cómo resolverlos mediante plantillas de IaC. Los desarrolladores tienen más poder para participar, ya que la toma de decisiones sobre cómo solucionar el problema se encuentra ahora en el nivel con mayor contexto. Empoderar a los desarrolladores significa que es más probable que participen, lo que se convierte en un círculo virtuoso mediante el cual se logra una seguridad en la nube aún mejor y a escala.

Riesgos de seguridad en la nube en DevOps

DevOps es fundamental para el ciclo de vida de la seguridad en la nube porque, en el mundo de autoservicio y automatización de los servicios en la nube, las acciones de los desarrolladores determinan en última instancia el éxito o el fracaso de la seguridad y el cumplimiento normativo en la nube. Muchas organizaciones han abordado este problema trasladando la seguridad y el cumplimiento normativo del código de aplicación a su pipeline de CI/CD (por ejemplo, mediante pruebas de seguridad automatizadas, un control estricto de versiones y análisis de vulnerabilidades automatizados). Este cambio ayuda a abordar las vulnerabilidades del código de aplicación, pero ¿qué ocurre con la seguridad y el cumplimiento normativo de la infraestructura subyacente en la nube? Existen cuatro desafíos principales de DevOps para la seguridad y el cumplimiento normativo en la nube.

1. Detectar errores de configuración y riesgos demasiado tarde . La mayoría de las organizaciones detectan riesgos y errores de configuración en la nube durante la ejecución, en lugar de prevenirlos durante el proceso de compilación. Este proceso es ineficiente e ineficaz, y pone a la organización en riesgo inmediato.

1. Pérdida de productividad del desarrollador . Pedir a los desarrolladores que resuelvan problemas en tiempo de ejecución no es el momento ni el lugar adecuados, lo que genera muchas ineficiencias. Además, los problemas de seguridad en tiempo de ejecución suelen ser efímeros, ya que son generados por las plantillas de IaC que contienen el problema raíz, lo que lleva a los desarrolladores a quemar ciclos al abordar repetidamente el mismo fallo principal.

1. Desajuste entre desarrolladores y seguridad . La pérdida de productividad mencionada anteriormente genera fricción entre los desarrolladores y el departamento de seguridad, lo que a la larga lleva a una pérdida de confianza en la seguridad. Este desajuste crea la posibilidad de que los desarrolladores no participen plenamente en el proceso de seguridad o la eludan por completo.

1. Entornos dinámicos . Cada vez que los desarrolladores crean o aprovisionan nuevos servicios en la nube, es muy probable que estos se incorporen a entornos existentes. De forma aislada, los recursos recién creados pueden ser seguros y cumplir con las normativas, pero en el contexto de un entorno más amplio, pueden presentarse desafíos de seguridad y cumplimiento normativo. El mundo en constante evolución de la nube dificulta especialmente la solución de este problema. Por ejemplo, una nueva instancia de Amazon EC2 que se conecta directamente a un servidor de base de datos en el entorno de datos del titular de la tarjeta (CDE) se integra automáticamente en el CDE y, por lo tanto, está sujeta a PCI-DSS.

La seguridad y el cumplimiento están desconectados

Estos desafíos de seguridad en la nube existen porque la seguridad y el cumplimiento normativo suelen estar fuera del proceso de aprovisionamiento de la infraestructura en la nube. Una versión podría tener una simple configuración incorrecta (por ejemplo, un puerto SSH o RDP abierto) que podría exponer información personal o de salud protegida, infringiendo así los requisitos de cumplimiento de HIPAA o PCI-DSS. Detectar estos riesgos después del aprovisionamiento (es decir, en tiempo de ejecución) pone a la organización en un riesgo considerable. La exposición continúa mientras los departamentos de seguridad y cumplimiento normativo aíslan el problema, determinan quién en el área de desarrollo u operaciones es responsable de la solución, contactan a la persona adecuada y le piden que determine cómo y dónde realizar la solución. 

Para abordar estos desafíos de DevOps, las organizaciones deben adoptar el mismo enfoque para el aprovisionamiento de infraestructura en la nube que para el aprovisionamiento de código de aplicaciones, desplazando la seguridad y el cumplimiento normativo hacia la izquierda. El factor que impulsa este cambio es la IaC.

El camino hacia la IaC

La premisa de IaC es simple: escribir sentencias declarativas que definan la infraestructura necesaria para ejecutar el código. Así, en lugar de crear un ticket para que el departamento de operaciones implemente cómputo, red y almacenamiento, los desarrolladores pueden crear una plantilla JSON o YAML que convierte la creación de la infraestructura en un proceso compartido, programático y reproducible. Con IaC, los desarrolladores pueden escribir código de programación, probarlo y publicarlo con la infraestructura que se ejecutará en un proceso altamente integrado que la organización puede automatizar como parte del flujo de trabajo de CI/CD.

Los desarrolladores utilizan una amplia gama de herramientas de IaC, como HashiCorp Terraform, AWS CloudFormation, Microsoft Azure Resource Manager y Google Cloud Deployment Manager. Estas herramientas son muy potentes, ya que permiten declarar no solo los recursos de almacenamiento, red y computación, sino también servicios adicionales, como balanceadores de carga, monitorización y controles de seguridad. 

La IaC es el motor que impulsa a las organizaciones a cambiar la seguridad y el cumplimiento normativo en la nube de reactivos (en tiempo de ejecución) a preventivos (durante el desarrollo). La clave reside en integrar los controles adecuados con la orientación adecuada directamente en el flujo de trabajo de CI/CD. Esta integración facilita la entrega de una infraestructura en la nube segura y conforme desde el principio. Una forma básica de lograrlo es que los equipos de seguridad creen plantillas de IaC para que las utilicen los desarrolladores. Las plantillas son un excelente primer paso, pero abordar los desafíos de la seguridad en la nube requiere un enfoque más integrado y dinámico.

Implementación de IaC segura y compatible 

La esencia de cambiar la seguridad y el cumplimiento normativo en la nube a la izquierda reside en integrar la retroalimentación y la orientación de IaC directamente en las herramientas de CI/CD (p. ej., CircleCI, GitHub, Jenkins). Por ejemplo, los desarrolladores deberían poder determinar si la plantilla de IaC que utilizan creará riesgos de seguridad o cumplimiento normativo antes de construir cualquier infraestructura. Además, deben recibir orientación sobre cómo resolver estos riesgos, ya que los desarrolladores no suelen ser expertos en seguridad. Idealmente, esta orientación debería entregarse al desarrollador de inmediato a través de las herramientas que elija utilizar. La integración de herramientas para desarrolladores es fundamental, ya que pedirles que cambien su comportamiento reduce la productividad y la participación. 

Los desarrolladores ya cuentan con un ecosistema de este tipo para las pruebas de seguridad de aplicaciones mediante herramientas de pruebas de seguridad de aplicaciones estáticas y dinámicas (SAST/DAST) que se integran con sus IDE y pipelines de CI/CD mediante API y webhooks. SAST suele ser el primer punto de prueba. Es rápido, aunque solo prueba el código a nivel de componente. DAST es más preciso para detectar vulnerabilidades reales porque examina la aplicación completa, pero es lento y suele ejecutarse mucho más tarde en el proceso de CI/CD. Juntos, SAST y DAST detectan numerosos errores de configuración, vulnerabilidades y fallos de cumplimiento antes de que el código de la aplicación entre en producción. 

Al igual que SAST y DAST para el código de aplicación, existen enfoques similares para trasladar la seguridad de la nube a la izquierda con el análisis de IaC:

• Análisis estático de IaC . Analiza el código de forma aislada, identificando riesgos, errores de configuración y fallos de cumplimiento relevantes únicamente para la plantilla de IaC. 
• Análisis dinámico de IaC . Va más allá de la propia plantilla de IaC, evaluando cualquier entorno y servicio en la nube existente con el que interoperará o en el que se ejecutará. Por ejemplo, el análisis dinámico detectaría que un servidor configurado correctamente (que superó el análisis estático) sigue incumpliendo los requisitos de PCI-DSS porque se conecta a un CDE sin un firewall adecuado. 

La integración del análisis estático y dinámico de las plantillas de IaC en CI/CD proporciona una visión holística del riesgo. Sin embargo, ofrecer esta nueva experiencia a los desarrolladores requiere un plano de control de seguridad adecuado para establecer límites que separen lo que los desarrolladores pueden y no pueden hacer. Se necesitan herramientas que:

• Se integra en el pipeline de CI/CD
• Admite infraestructuras multicloud
• Proporciona análisis tanto estático como dinámico.
• Aplica las mismas políticas durante la compilación y el tiempo de ejecución.
• Proporciona niveles de cumplimiento personalizables (por ejemplo, aprobar, advertir o reprobar) para estas políticas.
• Proporciona orientación directa a los desarrolladores sobre cómo resolver riesgos y fallas.

Uniendo DevOps, seguridad y cumplimiento

La implementación de una IaC segura y compatible es una piedra angular para alinear DevOps, la seguridad y el cumplimiento para lograr los siguientes beneficios:

• Prevenir riesgos de seguridad en la nube . Con la integración directa de CI/CD de IaC y las herramientas adecuadas, la organización ahora puede prevenir errores de configuración, incumplimientos y riesgos de seguridad antes del tiempo de ejecución. Esta transición hacia la seguridad en la nube a la izquierda ayuda a eliminar la posibilidad de vulnerabilidades. 
• Mejore la productividad de los desarrolladores . Implementar la seguridad en la nube en CI/CD mejora la experiencia de los desarrolladores al detectar estos problemas en el momento oportuno y en la etapa correcta del proceso de desarrollo. Esta integración mejora drásticamente la productividad de los desarrolladores, ya que les permite resolver los desafíos de forma eficiente y puntual, en lugar de dar vueltas en el tiempo de ejecución con problemas efímeros. Además, la guía de seguridad integrada ofrece a los desarrolladores las recomendaciones necesarias para resolver los problemas rápidamente. 
• Fortalecer la seguridad y el cumplimiento normativo . Aumentar la productividad de los desarrolladores, involucrar a los equipos adecuados en el momento oportuno y, en última instancia, ofrecer una mejor experiencia para todos, genera un sentido de pertenencia y responsabilidad compartida. Los desarrolladores se vuelven más propensos a participar en el proceso de seguridad en la nube. Este círculo virtuoso beneficia a todos, desde el desarrollador hasta el profesional de seguridad y la organización en general. 

El primer paso hacia la seguridad en la nube 

Para cambiar la seguridad en la nube de su organización a la izquierda, debe comenzar por considerar preguntas fundamentales sobre sus requisitos, que pueden ayudarlo a identificar la herramienta adecuada para usar: 

• ¿Qué nubes públicas utilizas? ¿Qué nubes públicas podrías utilizar en el futuro?
• El uso de múltiples nubes requiere una visibilidad completa y continua de numerosas infraestructuras en la nube para evaluar el impacto de la provisión de cualquier servicio en cualquier lugar. Las herramientas que solo admiten su entorno de nube actual plantearán todos los desafíos mencionados anteriormente al expandirse a otra nube. Debe asegurar su enfoque de seguridad en la nube para el futuro. 
• ¿Cuántas herramientas IaC utiliza su organización (por ejemplo, Terraform, CFT, ARM)? 
• El uso de múltiples herramientas de IaC aumenta la demanda de recursos de los desarrolladores y complica drásticamente las tareas de seguridad y cumplimiento normativo. Los desarrolladores se centran continuamente en limitar sus conjuntos de herramientas para lograr la máxima flexibilidad. De igual forma, su organización debería minimizar el conjunto de herramientas de IaC.
• ¿Qué herramientas de orquestación CI/CD utiliza su organización? 
• Los desarrolladores toman estas decisiones sobre las herramientas, por lo que las herramientas de seguridad y cumplimiento de IaC deben ser compatibles con cualquiera de ellas. Implementar el análisis de IaC con un soporte limitado para herramientas de canalización de CI/CD puede obstaculizar a una organización si los desarrolladores adoptan nuevas herramientas de CI/CD.
• ¿Necesita aplicar las mismas políticas de manera preventiva durante el proceso de CI/CD y de manera reactiva en el tiempo de ejecución?
• Las acciones de seguridad y cumplimiento deben ser ejecutables a lo largo del proceso de CI/CD: preventivas durante la fase de compilación y reactivas durante el tiempo de ejecución. Las organizaciones se encuentran en diferentes etapas de madurez en el aprovisionamiento de infraestructura. Algunas automatizan solo un subconjunto de la infraestructura a través del proceso de CI/CD; otras ejecutan CI/CD manualmente; y otras automatizan completamente el aprovisionamiento de infraestructura. Independientemente del nivel de madurez, los equipos de seguridad y cumplimiento de la organización deben poder utilizar las mismas definiciones de políticas y mecanismos de cumplimiento en cualquier punto del proceso.
• ¿Necesita aplicar alcance para que las políticas se refieran a aplicaciones específicas o grupos lógicos?
• La aplicación de políticas debe ser específica para el contexto de la aplicación y el entorno operativo. Una misma aplicación que se ejecuta en una nube privada y en una nube pública requerirá diferentes niveles de aplicación de políticas. De igual manera, las aplicaciones que se ejecutan en diferentes nubes públicas pueden requerir una aplicación de políticas específica (por ejemplo, ejecutar una aplicación con datos de salud confidenciales en una nube que cumple con la HIPAA en comparación con una nube de propósito general).
• ¿Necesita niveles de cumplimiento personalizables (por ejemplo, aprobar, advertir o reprobar) por política y alcance de política?
• Las organizaciones se encuentran en diferentes etapas de automatización de la aplicación de políticas. Algunas solo desean advertencias, mientras que otras requieren acciones automatizadas.

Por último, hay preguntas que debe hacerse al evaluar las herramientas que desplazan la seguridad en la nube hacia la izquierda:

• ¿La herramienta admite todos los requisitos enumerados anteriormente? 
• ¿Proporciona análisis estático y dinámico para una protección integral?
• ¿Proporciona protección preventiva y en tiempo de ejecución para la seguridad y el cumplimiento de todo el ciclo de vida?

 

✅ A02:2025 – Configuración Incorrecta de Seguridad (Security Misconfiguration)

Se produce cuando la aplicación, el servidor, la API o los servicios de infraestructura están mal configurados, tienen valores por defecto, permisos inseguros, funciones innecesarias habilitadas, exposición no intencionada o falta de endurecimiento (hardening). A02 es tan común porque los sistemas modernos están formados por docenas de componentes, y uno solo mal configurado rompe toda la cadena de seguridad.

🧩 Ejemplos típicos modernos (2025)

• Consolas administrativas expuestas (/admin, /actuator, /swagger, /console).
• Archivos sensibles expuestos por error: .env, .git/, backup.zip, /config.yaml.
• CORS mal configurado (Access-Control-Allow-Origin: *).
• Buckets S3 / blobs abiertos al público.
• Servidores cloud con puertos innecesarios abiertos.
• Permisos laxos en contenedores (root user).
• Instancias con patches faltantes.
• Debug mode o stack traces habilitados en producción.
• Policies IAM demasiado amplias (*:*).
• API Gateway sin restricción por método, origen, o rol.
• Valores default: credenciales por defecto, puertos por defecto, rutas por defecto.
• Inyección por encabezados gracias a proxies mal configurados.

🧪 Checklist rápida de pentesting A02:2025

• Revisar CORS.
• Enumerar archivos expuestos.
• Buscar debug mode / stack traces.
• Verificar headers de seguridad.
• Enumerar paneles administrativos expuestos.
• Revisar buckets cloud.
• Revisar permisos IAM y credenciales hardcodeadas.
• Verificar métodos HTTP innecesarios (TRACE, OPTIONS, PUT, DELETE).
• Revisar exposición de bases de datos.
• Revisar configuración de contenedores.
• Validar acceso a metadata cloud.
• Escanear puertos y servicios que no deberían estar.

🧾 Resumen ejecutivo para tu curso

A02:2025 Security Misconfiguration ocupa el segundo puesto del OWASP Top 10 porque la mayoría de las aplicaciones modernas dependen de múltiples componentes y un solo elemento mal configurado puede abrir la puerta a un compromiso completo. Incluye CORS permisivo, archivos sensibles expuestos, servicios innecesarios, credenciales por defecto, buckets abiertos, políticas IAM laxas, paneles administrativos visibles, debug activado y headers de seguridad faltantes. La mitigación requiere un enfoque de hardening continuo: deny-by-default, políticas estrictas en servidores, autenticación en cualquier interfaz administrativa, gestión segura de secrets, verificación automática de configuraciones mediante CI/CD e implementación de controles de seguridad en infraestructura como código. Es una de las categorías más fáciles de explotar y una de las principales causas de brechas reales.

 

 

 

Preguntas sobre A02

¿Qué ocurre si el banco deja habilitadas las credenciales por defecto admin/admin en un panel de administración? Security Misconfiguration por uso de credenciales predeterminadas.

¿Qué pasa si el servidor expone un phpinfo() o un panel de debug en producción? Security Misconfiguration por funciones de depuración activas en producción.

¿Qué vulnerabilidad hay si una aplicación devuelve mensajes de error detallados con stacktrace y versión del framework? Security Misconfiguration por errores verbosos que filtran información sensible.

¿Qué ocurre si el servidor web no tiene configurados headers de seguridad como Content-Security-Policy, X-Frame-Options o Strict-Transport-Security? Security Misconfiguration por falta de headers de seguridad.

¿Qué falla existe si una API bancaria permite Access-Control-Allow-Origin: * junto con credenciales en las respuestas? Security Misconfiguration por configuración insegura de CORS.

¿Qué vulnerabilidad hay si el sitio bancario aún acepta conexiones con TLS 1.0 y ciphers débiles como RC4? Security Misconfiguration por configuración insegura de TLS/SSL.

¿Qué pasa si un directorio /statements/ está publicado con “directory listing” habilitado? Security Misconfiguration porque expone archivos sensibles directamente.

¿Qué vulnerabilidad existe si el banco deja accesibles archivos .git/, .env o backups .bak en el servidor?Security Misconfiguration por exposición de archivos sensibles.

¿Qué falla ocurre si los logs de la aplicación son accesibles públicamente desde el navegador? Security Misconfiguration porque los logs quedan expuestos y accesibles a atacantes.

¿Qué ocurre si un bucket S3 de un banco queda con permisos públicos de lectura? Security Misconfiguration por mala configuración de permisos en almacenamiento en la nube.

¿Qué falla ocurre si la aplicación permite caché público de páginas con datos sensibles de usuarios? Security Misconfiguration por políticas de caché inseguras.

¿Qué pasa si un endpoint de gestión /actuator/env o /console está abierto sin autenticación? Security Misconfiguration por exponer endpoints administrativos sin protección.

¿Qué vulnerabilidad existe si un servidor muestra la versión exacta de Apache o Tomcat en los headers de respuesta HTTP? Security Misconfiguration por disclosure de versión del servidor.

¿Cuál es la diferencia entre Security Misconfiguration y Vulnerable Components (A06)? A05 = la configuración está mal (debug, CORS, headers, defaults); A06 = el componente en sí es vulnerable/antiguo.

¿Qué controles debe implementar un banco para evitar Security Misconfiguration? Hardening por capas, eliminación de servicios innecesarios, deny-by-default, revisión de configuraciones, automatización de deploy seguro, pruebas periódicas de seguridad.

1. Credenciales por defecto → Security Misconfiguration.
2. Panel de debug en producción → Misconfiguration.
3. Errores verbosos con stacktrace → Misconfiguration.
4. Falta de headers de seguridad (CSP, HSTS, XFO) → Misconfiguration.
5. CORS con * y credenciales → Misconfiguration.
6. Archivos sensibles (.env, .git, backups) accesibles → Misconfiguration.
7. Diferencia A05 vs A06 (config vs versión vulnerable).

Despedida del capítulo

Llegaste al final de este capítulo y ahora dominás uno de los pilares centrales de la seguridad ofensiva y defensiva: la configuración segura. Aprendiste qué es una misconfiguración, cómo identificarla, cómo explotarla y cómo prevenirla usando hardening, buenas prácticas, automatización y herramientas modernas de IaC y DevSecOps.

Ya entendés cómo un simple detalle —un panel de admin sin protección, un bucket público, un CORS permisivo, un listado de directorios, una cabecera mal configurada o un error verboso— puede abrirle la puerta al atacante y permitirle comprometer datos, escalar privilegios o tomar control total del sistema.

Esto te vuelve un hacker más completo:

✔ Sabés dónde buscar.

✔ Sabés cómo pensar.

✔ Sabés qué configura un entorno seguro.

✔ Y entendés cómo una sola línea mal puesta puede significar un breach.

Desplazar la seguridad en la nube hacia la izquierda mejora la productividad de los desarrolladores y previene errores de configuración e infracciones de políticas. Un enfoque de ciclo de vida completo para la seguridad en la nube (por ejemplo, combinando lo preventivo y lo reactivo) es fundamental para todas las organizaciones que buscan usar servicios en la nube para innovar sin perder el control.

Todo lo que aprendiste en este capítulo te va a acompañar durante toda tu carrera. Porque mientras haya sistemas mal configurados, siempre va a haber oportunidades de ataque… o de defensa inteligente. Nos vemos en el próximo capítulo, donde seguimos fortaleciendo tu mentalidad de hacker profesional.