Cómo priorizar AWS security checks en entornos productivos

Problema

Los equipos que gestionan cuentas AWS reciben diariamente cientos de hallazgos provenientes de Security Hub, GuardDuty, Config Rules y herramientas de terceros. La mayoría son advertencias de “best‑practice” que, en teoría, deberían corregirse, pero en la práctica generan tanto ruido que los ingenieros terminan ignorándolos. El reto no es habilitar más controles, sino decidir qué hallazgos merecen una respuesta inmediata y cuáles pueden posponerse sin exponer la infraestructura a un riesgo significativo. Sin un proceso de priorización, el tiempo de respuesta se diluye y los incidentes críticos pueden pasar desapercibidos.

Causa

1. Configuraciones predeterminadas demasiado permisivas
   IAM policies con *:* o bucket policies con PublicRead aparecen en la mayoría de los escaneos. Son fáciles de detectar pero, si el recurso está aislado por VPC y no tiene datos sensibles, el impacto real es bajo.

2. Reglas de Config que no se alinean con la arquitectura
   Un rule que verifica “S3 bucket versioning enabled” dispara en cada bucket nuevo, aunque la versión no sea requerida por la política de retención de la empresa. El desajuste entre la regla y la realidad del negocio genera falsos positivos.

3. Alertas de GuardDuty basadas en patrones de tráfico benigno
   Escaneos de puertos internos, accesos desde IPs de CI/CD o health checks de ELB aparecen como “Port scanning” o “UnauthorizedAccess”. Son ruidos típicos en entornos con auto‑escalado.

4. Falta de clasificación de severidad
   Muchos equipos importan los hallazgos sin mapear la gravedad a un modelo propio (Critical, High, Medium, Low). Sin esa capa, todos los hallazgos aparecen con la misma prioridad.

5. Dependencia de herramientas de terceros sin integración de contexto
   Scripts personalizados que simplemente marcan como “remediado” cualquier hallazgo sin validar si la corrección realmente elimina la vulnerabilidad.

Solución

1. Definir un modelo de riesgo propio

Crea una tabla que relacione tipo de hallazgo, impacto potencial y probabilidad de explotación. Por ejemplo:

Este modelo permite mapear cualquier hallazgo a una prioridad sin depender de la etiqueta de severidad que entrega AWS.

2. Filtrar y agrupar con AWS CLI / SDK

Utiliza un script que extraiga los hallazgos, aplique el modelo y los agrupe por prioridad. Un ejemplo mínimo con AWS CLI:

aws securityhub get-findings \
  --filters '{"ProductArn":["arn:aws:securityhub:*:*:product/aws/guardduty"],"SeverityLabel":["HIGH","CRITICAL"]}' \
  --query 'Findings[*].{Id:Id,Title:Title,Severity:Severity.Label,Resource:Resources[0].Id}' \
  --output json > /tmp/high_findings.json

Luego, un proceso Python (o cualquier lenguaje) recorre el JSON, asigna la prioridad según la tabla y escribe en una tabla de DynamoDB o en un ticket de Jira. La clave es centralizar la lógica de priorización para que cualquier fuente de hallazgos siga el mismo criterio.

3. Automatizar la remediación de los críticos

Para los hallazgos con prioridad Critical que tienen una solución conocida (por ejemplo, habilitar MFA en la cuenta root), implementa runbooks con AWS Systems Manager (SSM) Automation. Un documento SSM para habilitar MFA en root podría verse así:

description: "Enable MFA for the root account"
schemaVersion: "0.3"
mainSteps:
  - action: aws:executeAwsApi
    name: enableMFA
    inputs:
      Service: iam
      Api: CreateVirtualMFADevice
      VirtualMFADeviceName: root-mfa

Ejecuta el documento automáticamente cuando el script detecte un hallazgo crítico de “Root account without MFA”.

4. Establecer un umbral de “ruido aceptable”

Identifica los hallazgos que aparecen en más del 80 % de los recursos y que, según el modelo, tienen prioridad Low. Agrégalos a una lista blanca y exclúyelos de los reportes diarios. Mantén la lista bajo revisión trimestral para evitar que una excepción se convierta en vulnerabilidad.

5. Revisiones periódicas de reglas

Cada sprint, revisa las Config Rules activas y verifica que siguen alineadas con la arquitectura actual. Desactiva o modifica aquellas que generan falsos positivos constantes. Lo mismo aplica a GuardDuty: ajusta los trusted IP lists para excluir rangos internos de los resultados de “UnauthorizedAccess”.

Cuándo aplicar esta solución

• Entornos con más de 50 recursos AWS donde el número de hallazgos supera los 200 al mes.
• Equipos que usan Security Hub, GuardDuty y Config simultáneamente y sienten que el tiempo de triage es excesivo.
• Organizaciones que deben cumplir con normas externas (PCI‑DSS, HIPAA) pero necesitan demostrar que priorizan los riesgos críticos.

No es necesario implementar este flujo si tu cuenta tiene menos de 10 recursos y recibes menos de 20 hallazgos mensuales; en ese caso la revisión manual es suficiente.

Código

# Exportar hallazgos críticos de Security Hub y GuardDuty a CSV
aws securityhub get-findings \
  --filters '{"SeverityLabel":["CRITICAL","HIGH"]}' \
  --query 'Findings[*].[Id,Title,Severity.Label,Resources[0].Id]' \
  --output text | tr '\t' ',' > critical_findings.csv

# Ejecutar runbook SSM para habilitar MFA en root (ejemplo)
aws ssm start-automation-execution \
  --document-name "EnableRootMFA" \
  --parameters '{"RootAccountId":["123456789012"]}'

Verificación

1. Validar la tabla de prioridades: ejecuta el script y revisa que al menos el 90 % de los hallazgos críticos aparecen en la salida critical_findings.csv.
2. Confirmar la remediación automática: después de ejecutar el runbook, verifica en la consola IAM que el root tiene un dispositivo MFA asociado.
3. Medir la reducción de ruido: compara el número total de hallazgos diarios antes y después de aplicar la lista blanca; una caída del 60 % o más indica que el filtro está funcionando.
4. Auditar la lista blanca trimestralmente: revisa los hallazgos excluidos y asegura que ninguno haya escalado a un incidente real.

Notas adicionales

• Etiquetas de recursos son clave para filtrar. Añade tags como environment=prod y usa esos tags en los filtros de Security Hub para enfocarte solo en producción.
• Costos de API: al ejecutar get-findings con filtros amplios, podrías alcanzar los límites de llamadas. Usa paginación y almacena resultados intermedios en S3.
• Integración con ticketing: si tu organización usa Jira, crea un webhook en Security Hub que envíe los hallazgos críticos directamente a un proyecto de “Security Incidents”.
• Revisión de permisos del script: el IAM role que ejecuta los comandos necesita securityhub:GetFindings, ssm:StartAutomationExecution y iam:CreateVirtualMFADevice. Limita el scope a los recursos necesarios.
• Cultura de “fail fast”: cuando un hallazgo crítico se remedia, documenta la causa raíz y actualiza la tabla de riesgos. Con el tiempo, la lista de críticos reales tiende a disminuir, lo que simplifica el proceso de triage.