AWS Builder Center

Builder Center

Los 14 filtros de CIS que Security Hub te obliga a crear (y como sobrevivir despues)

Desplegaste los metric filters de Amazon CloudWatch que CIS AWS Foundations Benchmark exige. AWS Security Hub CSPM marca verde. Compliance: aprobado. Pero ahora tu telefono vibra 47 veces por semana con alertas de IAM, security groups y VPC changes. Empiezas a ignorarlas. Felicidades: eres compliant y estas ciego al mismo tiempo.

vtjean

El dia despues del despliegue

Todo blog, todo tutorial, toda guia de CIS te dice como crear los 14 filtros. El patron es siempre el mismo: crea un metric filter en el log group de AWS CloudTrail, conectalo a una alarma de Amazon CloudWatch, apunta la alarma a un Amazon SNS topic. Repite 14 veces. Security Hub valida que los patrones de filtro sean exactos:
"This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters." -  Security Hub CSPM controls for Amazon CloudWatch 
Eso cubre el dia del despliegue. Este post cubre el dia siguiente: cuando las alarmas empiezan a sonar y necesitas decidir cuales importan, cuales son ruido, y como organizarlas para que no termines ignorandolas todas.

Una nota sobre versiones de CIS

CIS AWS Foundations Benchmark v1.2 definia 14 metric filters (controles 3.1 a 3.14). La version v1.4 redujo los automatizados a 12 (elimino la evaluacion automatica de CW.2 y CW.3). Las versiones v3.0 y v5.0 (disponibles en Security Hub CSPM desde mayo 2024 y octubre 2025) fueron mas lejos: movieron todos los controles de metric filters a "manual check" y ya no los evaluan automaticamente.
Pero los controles CW.1 a CW.14 siguen existiendo como controles independientes en Security Hub CSPM. Ademas de CIS v1.2 y v1.4, todos excepto CW.3 estan mapeados a NIST SP 800-171 Rev. 2, y CW.1 tambien a PCI DSS v3.2.1. Si tienes habilitado CIS v1.2 o v1.4 (como muchas organizaciones que aun no migran), Security Hub los evalua. Si tienes habilitado el estandar NIST SP 800-171 Rev. 2, Security Hub tambien evalua todos excepto CW.3. Desde octubre de 2026, el estandar CRI Profile v2.2 tambien incluye los 14. AWS Foundational Security Best Practices no incluye estos controles. En la practica, la mayoria de las cuentas que veo tienen al menos uno de estos estandares activo, y los filtros siguen disparando alarmas.
Este post asume que tienes los controles activos, sin importar cual estandar los habilite.

Los 14 filtros, clasificados por calidad de senal

No todos los filtros CIS son iguales. Algunos casi nunca disparan y cuando lo hacen siempre significa algo. Otros disparan en cada despliegue de infraestructura y el equipo aprende a ignorarlos en la primera semana.

Tier 1: senal alta, ruido bajo

Estos filtros detectan eventos que son raros y casi siempre significativos. Si uno de estos dispara, investiga.
Control
Que detecta
Por que importa
CW.1
Uso del root user
Root tiene acceso irrestricto. Cualquier uso fuera de tareas de administracion de cuenta es sospechoso.
CW.5
Cambios en la configuracion de CloudTrail
Si alguien desactiva o modifica CloudTrail, esta borrando sus huellas.
CW.7
Deshabilitacion o eliminacion programada de CMKs
Destruir claves KMS puede dejar datos irrecuperables.
CW.9
Cambios en la configuracion de AWS Config
Detener Config corta el registro de cambios de recursos.
Patron del filtro CW.1 (root user): detecta cualquier uso de la cuenta root que no sea un evento de servicio de AWS. Los patrones exactos de cada filtro estan en la  documentacion de Security Hub . Estos filtros se quedan con umbral de 1 o mas. Un solo evento justifica revision.

Tier 2: util pero ruidoso

Estos filtros detectan eventos reales, pero disparan con frecuencia en entornos activos. Necesitan umbrales o contexto para ser utiles.
Control
Que detecta
Fuente de ruido
CW.2
API calls no autorizadas
Service-linked roles, AWS Config consultando Macie en cuentas sin Macie habilitado
CW.3
Console sign-in sin MFA
IAM users con contrasena de consola que inician sesion sin MFA, por ejemplo usuarios de emergencia o cuentas heredadas
CW.4
Cambios en politicas IAM
Cada despliegue de IaC que cambia politicas IAM dispara esta alarma
CW.6
Fallos de autenticacion en la consola
Intentos de login fallidos de cualquier usuario, incluidos errores de typo
CW.8
Cambios en politicas de bucket S3
Cada despliegue que crea o modifica buckets dispara esta alarma
Patron del filtro CW.2 (API calls no autorizadas): captura todo evento con errorCode UnauthorizedOperation o AccessDenied.
Patron del filtro CW.3 (sign-in sin MFA): solo cuenta inicios de sesion exitosos en la consola de tipo IAMUser donde MFAUsed no es Yes, asi que las sesiones federadas no lo disparan.
El problema con CW.2: en un entorno real, este filtro genera mucho ruido. Un caso documentado: AWS Config, a traves de su service-linked role, llama a macie2:GetMacieSession y recibe AccessDenied en cuentas donde Amazon Macie no esta habilitado. Es comportamiento esperado, no malicioso. En re:Post hay un hilo donde un usuario reporta falsos positivos continuos en sus alarmas CIS por esas llamadas de AWS Config a Macie. Excluir ese evento del metric filter rompe el control CW.2, porque Security Hub exige el patron exacto; por eso el ajuste se hace en la alarma, no en el filtro:
"Recently I've noticed I've started getting a lot more AccessDeniedExceptions in my CloudTrail logs, which cause false-positive alarms for my SecurityHub/CIS metric filters." -  re:Post 

Tier 3: ruido en entornos con IaC

Estos filtros detectan cambios en la configuracion de red. Son utiles en teoria, pero en cualquier entorno donde la infraestructura se despliega con Terraform, CDK, o CloudFormation, disparan en cada apply.
Control
Que detecta
Por que es ruido con IaC
CW.10
Cambios en security groups
Cada despliegue que toca SGs
CW.11
Cambios en NACLs
Cada despliegue que toca NACLs
CW.12
Cambios en network gateways
Cada creacion, attach o eliminacion de internet gateways o customer gateways (los NAT gateways no estan en el patron)
CW.13
Cambios en route tables
Cada despliegue de VPC
CW.14
Cambios en VPCs
Cada creacion o modificacion de VPC
Patron del filtro CW.10 (security groups): captura las 6 operaciones de API sobre security groups (Authorize/Revoke Ingress/Egress, Create, Delete).
No puedes modificar estos patrones (Security Hub falla el control si el patron no es exacto). Pero si puedes controlar como alarmas sobre ellos.

El problema de las organization trails

CIS requiere que los metric filters se creen sobre el log group de CloudTrail. Pero si usas organization trails (recomendado por AWS para multi-cuenta), el trail pertenece a la cuenta de administracion de AWS Organizations o a la cuenta de administrador delegado de CloudTrail. Security Hub solo genera findings para la cuenta duena del trail, asi que en las cuentas miembro estos controles quedan en  NO_DATA :
"Using an organization trail results in a control status of  NO_DATA  for controls evaluated in organization member accounts." -  Security Hub CSPM controls for Amazon CloudWatch 
Tienes dos opciones:
  1. Crear un trail adicional por cuenta. Cada cuenta miembro tiene su propio trail que envia a su propio log group de CloudWatch Logs. Los 14 metric filters se crean en cada cuenta. Funciona para compliance pero multiplica el costo: CloudTrail cobra las copias adicionales de management events, y cada log group paga su ingestion en CloudWatch Logs.
  1. Aceptar  NO_DATA  en cuentas miembro. Centralizar los 14 filtros en la cuenta duena del organization trail. Las cuentas miembro muestran  NO_DATA , no FAILED. Funciona operativamente (las alarmas centralizadas ven los eventos de todas las cuentas que registra el trail) pero Security Hub no muestra verde en las cuentas miembro.
La mayoria de los equipos con los que trabajo eligen la opcion 2 y documentan la excepcion. El costo de duplicar trails y filtros en 50+ cuentas rara vez se justifica.

Composite alarms: de 14 alertas a 3

El problema real no es que los filtros detecten cosas incorrectas. Es que 14 alarmas individuales enviando a un solo SNS topic producen fatiga de alertas. El equipo empieza a ignorar el canal de notificaciones despues de la primera semana de despliegues.
La solucion: composite alarms de CloudWatch. Un composite alarm combina el estado de multiples alarmas en una sola, usando logica booleana. Solo el composite notifica al equipo. Las alarmas individuales alimentan el composite sin llegar al canal de guardia.
"You can use composite alarms to reduce alarm noise by taking actions only at an aggregated level." -  Composite alarms 
Un detalle de compliance antes de quitar acciones. La remediacion de los controles CW.1 a CW.14 configura cada alarma con un SNS topic que tenga al menos una suscripcion. Ademas, CloudWatch.15 (mapeado a NIST SP 800-53 Rev. 5 y NIST SP 800-171 Rev. 2) marca FAILED las alarmas de metrica sin acciones, aunque formen parte de un composite que si las tiene. Por eso, en vez de dejar las alarmas individuales sin acciones, apuntalas a un SNS topic de bajo ruido (con al menos una suscripcion que no sea el canal de guardia) y deja que solo los composites notifiquen al equipo.

Tres composites que cubren los 14 filtros

Composite 1: "Compromiso de identidad y accesos" Regla: CW.2 (unauthorized API) OR CW.3 (sign-in sin MFA) OR CW.4 (IAM changes) OR CW.6 (auth failures) OR CW.8 (S3 bucket policy) Cuando dispara: alguien esta usando credenciales de forma anomala, o las politicas de acceso cambiaron.
Composite 2: "Postura de red modificada" Regla: CW.10 (security groups) OR CW.11 (NACLs) OR CW.12 (gateways) OR CW.13 (route tables) OR CW.14 (VPC changes) Cuando dispara: la topologia de red cambio. Si no hubo un despliegue programado, investiga.
Composite 3: "Integridad de la pista de auditoria y uso de root" Regla: CW.1 (root) OR CW.5 (CloudTrail config) OR CW.7 (CMK disabled) OR CW.9 (Config changes) Cuando dispara: alguien usa la cuenta root o modifica los mecanismos que registran y protegen evidencia. Agrupa los cuatro filtros Tier 1, que casi nunca disparan durante despliegues, y por eso no lleva supresion ni mute.

Silenciar durante despliegues

Los composites 1 y 2 van a disparar durante despliegues programados. Tienes dos opciones para silenciar notificaciones sin desactivar las alarmas:
Opcion 1: Alarm Mute Rules (sin infraestructura adicional). Desde febrero 2026, CloudWatch soporta mute rules: defines una ventana de tiempo con una expresion cron o at (por ejemplo, "lunes a viernes 10am-11am") y las alarmas que pongas como target, hasta 100 por regla, dejan de ejecutar sus acciones durante esa ventana. Puedes apuntar la regla directamente a los composites. No necesitas crear metricas adicionales ni alarmas extra. Funciona bien para despliegues con horario predecible.
"Alarm Mute Rules is a CloudWatch feature that provides you a mechanism to automatically mute alarm actions during predefined time windows." -  Alarm Mute Rules 
Opcion 2: Suppressor alarms (para CI/CD dinamico). Si tus despliegues no siguen un horario fijo, puedes crear una metrica custom (por ejemplo, "deployment-in-progress"), publicarla desde tu pipeline de CI/CD, y definir una alarma sobre esa metrica como suppressor del composite. Mientras el suppressor este en ALARM (despliegue en curso), el composite no envia notificaciones. Cuando el suppressor vuelve a OK (despliegue terminado), el composite retoma sus acciones. Es mas trabajo de configuracion, pero se adapta a despliegues ad-hoc.
En ambos casos, el composite 3 (integridad de auditoria y uso de root) NO debe tener supresion ni mute. Si alguien usa root o modifica CloudTrail o Config durante un despliegue, quieres saberlo.

Tuning del Tier 2: como bajar el ruido sin perder la senal

CIS dice umbral de 1 o mas. Eso es correcto para Tier 1 (root, CloudTrail). Para Tier 2 es impracticable.

CW.2: Unauthorized API calls

El patron captura todo AccessDenied y UnauthorizedOperation. En un entorno activo, el volumen normal de estos eventos puede ser alto y depende de cada cuenta, por eso el primer paso es medirlo.
Paso 1: establece tu baseline. Antes de ajustar el umbral, ejecuta esta consulta de CloudWatch Logs Insights en tu log group de CloudTrail:
fields @timestamp, errorCode, userIdentity.arn, eventName | filter errorCode like /UnauthorizedOperation|AccessDenied/ | stats count(*) as total by bin(5m)
Ejecutala sobre 7 dias con el bin alineado al periodo de la alarma: bin(5m) si la alarma evalua periodos de 5 minutos. Si el pico observado es, por ejemplo, de 20 eventos en 5 minutos, un umbral de 40 a 60 en 5 minutos detecta spikes anomalos sin disparar en operacion normal.
Paso 2: ajusta el umbral de la alarma, no el metric filter. El metric filter debe ser exacto (Security Hub lo valida). Pero la alarma puede tener otro umbral. Cambia de "Greater/Equal than 1" al valor que obtuviste del baseline, con el mismo periodo de 5 minutos, y confirma despues que el control sigue en PASSED.
Paso 3: Anomaly detection como alternativa. En vez de un umbral fijo, puedes crear una alarma de anomaly detection sobre la misma metrica. CloudWatch aprende el patron normal de AccessDenied de tu entorno y alarma cuando se desvie. Esto se adapta automaticamente a cambios de trafico sin necesidad de recalibrar manualmente.

CW.4: IAM policy changes

Cada Terraform apply que crea, adjunta o cambia politicas IAM genera eventos que el patron captura. Si despliegas 3 veces al dia, esto son 3+ alarmas diarias de comportamiento esperado.
La solucion no es subir el umbral (un solo cambio de IAM no autorizado es grave). Es correlacionar con despliegues. Si el composite 1 dispara al mismo tiempo que un despliegue de CloudFormation/CDK, el composite 2 (red) probablemente tambien disparo. Si los composites 1 y 2 disparan juntos dentro de una ventana de despliegue conocida, lo mas probable es que sea el despliegue. Si solo el composite 1 dispara sin despliegue, investiga. Si el composite 3 dispara, investiga siempre, haya o no despliegue.

El runbook: una alarma CIS disparo, que hago?

Similar al protocolo de respuesta a burn rate del Blog 5 de la serie CloudWatch:
  1. PASO 1, cual composite disparo? Composite 3 (auditoria y root): prioridad maxima, investiga inmediatamente. Composite 1 (identidad y accesos): prioridad alta, verifica si hay despliegue en curso. Composite 2 (red): prioridad media, casi siempre es IaC, verifica.
  1. PASO 2, hubo un despliegue en los ultimos 30 minutos? Si: revisa que los cambios sean los esperados y documenta. No: investiga e identifica el principal (IAM user o role) via CloudTrail.
  1. PASO 3, es un evento Tier 1? Root activity (CW.1): escala inmediatamente, root no debe usarse. CloudTrail o Config changes (CW.5, CW.9): escala, alguien modifica la auditoria. CMK deletion (CW.7): escala, claves en riesgo.
  1. PASO 4, es un evento Tier 2 sin despliegue? Unauthorized API (CW.2): identifica el principal, verifica si las credenciales estan comprometidas y cruza con Amazon GuardDuty para findings relacionados. IAM changes (CW.4): verifica quien hizo el cambio y si estaba autorizado. S3 bucket policy (CW.8): verifica si el bucket es publico ahora.
  1. PASO 5, documenta: hora, composite que disparo, controles individuales activos, despliegue relacionado (si o no), accion tomada y resultado.

Lo que estos filtros no hacen (limitaciones honestas)

No reemplazan a Amazon GuardDuty. Los filtros CIS detectan cambios de configuracion en CloudTrail. No detectan amenazas activas como cryptomining o exfiltracion de datos. GuardDuty usa threat intelligence y machine learning para eso. Los filtros CIS son un requisito de compliance, no una estrategia de deteccion de amenazas.
No cubren data plane events. Los 14 filtros operan sobre management events de CloudTrail (API calls de control plane). No ven accesos a datos en S3, invocaciones de Lambda, o queries a DynamoDB. Para eso necesitas CloudTrail data events (costo adicional) o GuardDuty S3 Protection.
El umbral de 1 o mas es un problema de diseno, no de implementacion. CIS Benchmark define el umbral como parte del control. La documentacion de Security Hub dice que el control falla si el patron del filtro no es exacto, y no menciona el umbral de la alarma. Puedes ajustar el umbral de la alarma, pero verifica que el control siga en PASSED. Y si auditas contra CIS literalmente, el auditor puede cuestionar un umbral diferente a 1. Documenta tu justificacion.
14 filtros x N cuentas = costo. Cada metric filter evalua los logs de CloudTrail que llegan al log group, y cada cuenta con su propio trail paga la ingestion de esos logs en CloudWatch Logs. En una cuenta con alto volumen de API calls, ese costo puede ser significativo. Evalua si la ingestion nativa de eventos de CloudTrail en Amazon CloudWatch (lanzada en diciembre 2025) encaja con tu escala; esa opcion cobra la entrega de eventos de CloudTrail mas la ingestion de CloudWatch Logs. Ten en cuenta que esa ingestion usa service-linked channels y no requiere trails, mientras que los controles CW.1 a CW.14 evaluan un trail de CloudTrail con su log group, metric filters y alarmas. Si dependes de esos controles para compliance, la ingestion nativa no los reemplaza por si sola.

Conclusion

Los 14 filtros CIS existen para cumplir un benchmark, no para operarlos uno a uno. Clasificarlos por calidad de senal (Tier 1, 2, 3), agruparlos en composite alarms, y ajustar los umbrales de Tier 2 transforma una lista de compliance en un sistema de deteccion que alguien puede operar sin ignorar.
El dia del despliegue es el dia facil. El dia despues es el que importa.

Recursos

# security-hub# amazon-cloudwatch# aws-cloudtrail# security-and-compliance# cloud-operations
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article