Ocho herramientas de código abierto que usamos en cada revisión de postura cloud
Una revisión de postura vale lo que vale su cobertura. Estos son los escáneres, analizadores de IAM y comprobadores de infraestructura como código que ejecutamos en AWS, Google Cloud y Azure, en qué destaca cada uno y dónde engaña.
Una revisión de postura cloud tiene un objetivo simple: encontrar lo que haría posible un incidente, ordenarlo por lo grave que sería ese incidente y entregar correcciones que se puedan aplicar como código. Los productos comerciales de CSPM lo hacen bien. También lo hace un puñado de herramientas de código abierto, si sabes qué cubre cada una y qué se le escapa. Este es el conjunto que ejecutamos, en el orden en que lo hacemos, en cada auditoría de seguridad cloud que el cliente ha autorizado.
Todas necesitan únicamente acceso de solo lectura. Si una herramienta pide más, eso ya es un hallazgo.
1. Prowler: la primera pasada amplia
Prowler ejecuta varios cientos de comprobaciones contra AWS, Google Cloud y Azure, mapeadas a los benchmarks CIS, al ENS, a PCI DSS y a otros marcos. Es lo primero que ejecutamos porque produce el inventario más amplio de configuraciones incorrectas en el menor tiempo.
En qué destaca: cobertura y mapeo de cumplimiento. Si necesitas decir "cumplimos el 84 por ciento de los controles de nivel medio del ENS que se pueden comprobar automáticamente", Prowler te da la cifra y la evidencia.
Dónde engaña: en el volumen. Una cuenta recién revisada produce mil hallazgos, la mayoría de severidad baja y muchos con la misma causa raíz repetida por recurso. No entregues la salida en bruto a nadie. Agrupa por comprobación, luego por causa raíz, y después ordena.
2. ScoutSuite: la segunda opinión
ScoutSuite cubre los mismos proveedores con otro conjunto de reglas y un informe organizado por servicio en vez de por comprobación. Lo ejecutamos después de Prowler y comparamos. Los hallazgos que aparecen en ambos son casi siempre reales; los que aparecen solo en uno merecen mirar la regla para ver qué se le escapó al otro.
El informe HTML es además el mejor artefacto para recorrer con un equipo su propia cuenta, porque muestra la configuración junto al hallazgo.
3. Steampipe: las preguntas que los escáneres no hicieron
Los escáneres responden a sus propias preguntas. Steampipe te deja hacer las tuyas, en SQL, contra la API en vivo de la nube. Consultas típicas en una revisión:
-- Grupos de seguridad que permiten 0.0.0.0/0 en algo distinto de 80 y 443
select group_id, from_port, to_port, cidr_ipv4
from aws_vpc_security_group_rule
where cidr_ipv4 = '0.0.0.0/0' and not is_egress
and (from_port not in (80, 443) or to_port not in (80, 443));
Combínalo con Powerpipe y los mods de CIS y AWS Well-Architected cuando quieras paneles, pero el valor real está en responder a la pregunta concreta que plantea la arquitectura del cliente: qué funciones Lambda llegan a la base de datos de pagos, qué buckets se replican fuera de la UE, qué roles IAM no se han asumido en un año.
4. Cloudsplaining: IAM a escala
IAM es donde están los hallazgos serios y donde los escáneres genéricos son más flojos, porque el riesgo de una política depende de a qué puede llegar. Cloudsplaining descarga los detalles de autorización de la cuenta e informa de las políticas que permiten escalada de privilegios, exposición de recursos, modificación de infraestructura o exfiltración de datos, con las sentencias exactas.
Ejecútalo contra todas las cuentas de la organización, no solo producción. El camino hacia producción suele empezar en una cuenta de desarrollo que nadie audita.
5. Pacu: demostrar el camino
Encontrar un rol con permisos de más es una cosa. Enseñar que lleva desde un portátil de desarrollador comprometido hasta la base de datos de producción es lo que cambia las prioridades en un comité de dirección. Pacu es un framework de explotación de AWS construido justo para eso, con módulos de enumeración, escalada de privilegios y persistencia.
Lo usamos solo con autorización por escrito, solo dentro del alcance acordado y solo para demostrar caminos ya identificados por el análisis anterior. No es un escáner y no debe ejecutarse como tal. Lo que conservamos de su salida es la cadena de pasos, para que el cliente pueda verificar que la corrección cierra cada eslabón.
6. Trivy: imágenes e infraestructura como código
Trivy analiza imágenes de contenedor en busca de vulnerabilidades conocidas y manifiestos de Terraform, CloudFormation y Kubernetes en busca de configuraciones incorrectas. Dos usos en una revisión:
- Cada imagen que corre en el clúster, descargada por digest, para que el informe corresponda a lo que está desplegado de verdad y no a lo que la pipeline construyó la semana pasada.
- El repositorio de infraestructura, para cazar la configuración incorrecta antes de aplicarla. Un bucket público encontrado en Terraform es una pull request; el mismo bucket encontrado en vivo es un informe de incidente.
7. Checkov: política para la pipeline
Checkov se solapa con Trivy en comprobaciones de infraestructura como código, pero su fuerte son las políticas personalizadas en YAML o Python y una integración limpia en CI. El entregable al final de una revisión no es la lista de hallazgos, sino el paso de la pipeline que impide que vuelvan. Checkov, con un conjunto de políticas derivado de los hallazgos de la revisión, es ese paso.
8. kube-bench y kube-hunter: el propio clúster
Si hay Kubernetes, la postura de la cuenta cloud es la mitad de la foto. kube-bench comprueba los nodos y el plano de control contra el benchmark CIS de Kubernetes; en servicios gestionados como EKS o GKE comprueba lo que el proveedor deja en tus manos. kube-hunter sondea el clúster desde dentro de un pod para mostrar a qué podría llegar una carga comprometida.
Lo que las herramientas no hacen
Ninguna ordena por impacto en el negocio. Un bucket público de imágenes de marketing y un bucket público de facturas son el mismo hallazgo para cualquier escáner. Ordenar es la parte de una revisión de seguridad que necesita a una persona que haya preguntado para qué sirve cada sistema.
Ninguna corrige nada. El valor de una revisión es el conjunto de pull requests contra el repositorio de infraestructura que cierra los hallazgos, en un orden que empieza por los que importarían a las tres de la mañana.
Y ninguna sustituye al registro de actividad. Las herramientas te dicen qué está expuesto hoy. CloudTrail, los registros de auditoría y un servicio de detección te dicen si alguien lo ha usado. Actívalos antes de ejecutar cualquiera de las anteriores, para poder ver lo que hizo la propia revisión.