AWS Builder Center

Builder Center

Security Hub ahora vive en CloudWatch: como reemplazar el dashboard Lambda de 2023

En 2023, una forma de visualizar tendencias compliance de AWS Security Hub en Amazon CloudWatch era una funcion de AWS Lambda que publicaba los puntajes como metricas custom de CloudWatch. Funcionaba. Requeria mantener codigo, permisos IAM, y una o mas funciones Lambda programadas con Amazon EventBridge. Otra opcion era una regla de EventBridge que enviaba los findings a un log group. En marzo de 2026, AWS lanzo la ingestion nativa findings de Security Hub CSPM en CloudWatch Logs. Lambda ya no es necesario.

vtjean



Que cambio en marzo de 2026

Antes de marzo 2026, Security Hub CSPM generaba findings y los mostraba en su propia consola. Si querias buscar, correlacionar, o alarmar sobre esos findings junto a tus metricas operativas, tenias que armar la integracion tu mismo. El blog de AWS de septiembre de 2023 usaba funciones Lambda programadas con EventBridge en la cuenta de administracion, que asumian un rol IAM desplegado con StackSets en cada cuenta miembro, leian los puntajes de compliance de AWS Config y de Security Hub y los publicaban como metricas custom.
Ahora, Amazon CloudWatch puede ingerir findings directamente desde Security Hub CSPM. Creas una telemetry enablement rule en la consola de CloudWatch y los findings empiezan a fluir a un log group administrado. No necesitas Lambda, no necesitas EventBridge, no necesitas codigo.
"To enable Security Hub CSPM findings as a data source in CloudWatch Logs, create a telemetry enablement rule for AWS Security Hub in the CloudWatch console." - Enable logging from third-party sources
Segun el anuncio, los findings se admiten en formato ASFF (AWS Security Finding Format) y OCSF (Open Cybersecurity Schema Framework), usando CloudWatch Pipelines. ASFF es el formato nativo de Security Hub CSPM. OCSF es el estandar abierto que usa Security Hub para sus findings y que permite correlacionar con datos de otros proveedores. Antes de escribir consultas, revisa un evento en tu log group para confirmar que formato te esta llegando.
La habilitacion funciona a nivel de organizacion. Un equipo central de seguridad puede definir la regla una vez y aplicarla a todas las cuentas miembro via AWS Organizations. Esto es lo que el blog de AWS de 2023 resolvia con funciones Lambda centralizadas y un rol IAM en cada cuenta miembro.

5 consultas de Logs Insights que reemplazan el dashboard Lambda

El log group administrado donde llegan los findings se puede consultar con CloudWatch Logs Insights. Las consultas siguientes asumen formato ASFF con JSON auto-parseado por CloudWatch. Los campos de nivel superior (Severity.Label, Compliance.Status, AwsAccountId) se acceden con dot notation. Para campos dentro de arrays como Resources, CloudWatch aplana el indice numerico automaticamente (Resources.0.Type). Logs Insights extrae como maximo 200 campos de un evento JSON, asi que si un campo no resuelve en tu entorno, usa jsonParse(@message) y navega desde ahi. Si usas OCSF en vez de ASFF, los nombres de campo cambian y tendras que adaptar las consultas al esquema que veas en tus eventos.
Un detalle que cambia como se escriben estas consultas: Security Hub CSPM no crea un finding nuevo en cada evaluacion. Mantiene un finding por control y recurso y lo actualiza en cada chequeo, y cada actualizacion llega al log group como un evento nuevo. Por eso las consultas cuentan findings unicos con countDistinct(Id) y usan ProductFields.PreviousComplianceStatus, el estado anterior del finding, para detectar cambios de estado. Logs Insights no tiene una funcion ago(); para filtrar por tiempo relativo se compara toMillis(@timestamp) con now() * 1000 menos los milisegundos de la ventana, o se usa el selector de tiempo de la consola.

Consulta 1: Findings criticos por servicio (ultimas 24 horas)

Donde estan los problemas mas graves ahora mismo.
fields @timestamp, Id, ProductName | filter Severity.Label = "CRITICAL" and RecordState = "ACTIVE" | filter toMillis(@timestamp) >= (now() * 1000 - 86400000) | stats countDistinct(Id) as total by ProductName | sort total desc | limit 20

Consulta 2: Compliance score por estandar

Que porcentaje de findings de controles pasan en cada estandar habilitado. Con consolidated control findings, activo por defecto en las cuentas que habilitaron Security Hub CSPM desde el 23 de febrero de 2023, GeneratorId identifica el control (por ejemplo security-control/IAM.1), no el estandar. Los estandares de cada finding estan en Compliance.AssociatedStandards. Para un porcentaje por estandar, ejecuta una consulta por estandar filtrando por su identificador, y toma el ultimo estado de cada finding:
fields Id, Compliance.Status, RecordState | filter @message like /standards\/aws-foundational-security-best-practices/ | stats latest(Compliance.Status) as estado, latest(RecordState) as registro by Id | filter registro = "ACTIVE" and estado in ["PASSED", "FAILED"] | stats sum(if(estado = "PASSED", 1, 0)) as passed, count(*) as total | fields passed / total * 100 as compliance_pct
Para CIS o PCI DSS, cambia el identificador por el StandardsId que veas en Compliance.AssociatedStandards. Elige en el selector de tiempo un intervalo que cubra al menos un ciclo completo de evaluaciones. Este porcentaje cuenta findings, es decir pares de control y recurso, no controles, asi que puede diferir del puntaje de seguridad que muestra la consola de Security Hub.

Consulta 3: Findings que pasaron a FAILED en las ultimas 24 horas

Que se rompio desde ayer. Util para revision diaria.
fields @timestamp, Title, Severity.Label, Resources.0.Id, AwsAccountId, case(Severity.Label = "CRITICAL", 4, Severity.Label = "HIGH", 3, Severity.Label = "MEDIUM", 2, Severity.Label = "LOW", 1, 0) as sev_rank | filter Compliance.Status = "FAILED" and ProductFields.PreviousComplianceStatus = "PASSED" | filter RecordState = "ACTIVE" | filter toMillis(@timestamp) >= (now() * 1000 - 86400000) | sort sev_rank desc, @timestamp desc | limit 50
Severity.Label es texto, asi que ordenarlo directamente da orden alfabetico; sev_rank lo convierte en un numero para que CRITICAL quede primero. El filtro de PreviousComplianceStatus deja solo los cambios de PASSED a FAILED. Si lo quitas, la consulta tambien muestra findings que ya estaban en FAILED y que Security Hub CSPM volvio a evaluar.

Consulta 4: Remediaciones por dia

Cuantos findings pasan de FAILED a PASSED cada dia. Security Hub CSPM actualiza el mismo finding cuando cambia el estado y guarda el estado anterior en ProductFields.PreviousComplianceStatus. Si este numero baja mientras suben los findings que pasan a FAILED, el equipo esta perdiendo capacidad de respuesta.
fields @timestamp, Id | filter Compliance.Status = "PASSED" and ProductFields.PreviousComplianceStatus = "FAILED" | filter toMillis(@timestamp) >= (now() * 1000 - 604800000) | stats countDistinct(Id) as remediados by bin(1d)
Para medir cuanto tarda cada correccion hay que comparar dos eventos del mismo finding. FirstObservedAt marca cuando cambio el estado por ultima vez, asi que la diferencia entre el FirstObservedAt del evento PASSED y el del ultimo evento FAILED da la duracion. Ese calculo es mas simple fuera de Logs Insights, por ejemplo con la integracion con Amazon S3 Tables que menciona el anuncio.

Consulta 5: Findings por cuenta (multi-cuenta)

Cuales cuentas de tu organizacion acumulan mas problemas. Con una regla de organizacion, la ingestion se activa en cada cuenta miembro y los findings quedan en el log group administrado de cada cuenta. Antes de usar esta consulta para comparar cuentas, verifica en que cuenta y log group estan los findings que quieres analizar. Si necesitas una sola vista, CloudWatch cross-account observability permite compartir log groups de cuentas origen con una cuenta de monitoreo dentro de una Region.
fields @timestamp, Id, AwsAccountId | filter Compliance.Status = "FAILED" and RecordState = "ACTIVE" | stats countDistinct(Id) as failed_findings by AwsAccountId | sort failed_findings desc | limit 20

Construyendo el dashboard

Si seguiste el Blog 4 de la serie CloudWatch, el patron de dashboard por filas aplica igual aqui. Cuatro filas, de la mas abstracta a la mas detallada:
Fila 1: Salud del compliance. Un widget de numero grande por estandar habilitado (CIS v1.4, AWS Foundational Security Best Practices, PCI DSS). Cada numero muestra el porcentaje de findings PASSED de la Consulta 2. Color: verde si > 95%, amarillo si 90-95%, rojo si < 90%.
Fila 2: SLIs de seguridad. Tres graficos de linea:
  • Findings CRITICAL + HIGH activos (total, tendencia 7 dias)
  • Findings que pasan a FAILED por dia (anomalias = algo se rompio o alguien desplego sin revisar)
  • Remediaciones por dia (si baja mientras suben los FAILED, el equipo esta saturado)
Fila 3: Presupuesto de drift. Similar al presupuesto de error del Blog 2. Define un objetivo: "menos de 10 findings CRITICAL activos." Muestra cuantos tienes vs. el objetivo. Si superas el objetivo, el equipo debe priorizar remediacion sobre nuevo trabajo.
Fila 4: Detalle por servicio y cuenta. Tablas de Logs Insights con los findings activos, agrupados por servicio o por cuenta. Aqui es donde el analista investiga.

Alarmas sobre drift de compliance

El dashboard muestra el estado actual. Las alarmas detectan cuando el estado cambia para peor.

Alarma 1: Spike de findings criticos

Crea un metric filter sobre el log group de findings que coincida con findings donde Severity.Label sea CRITICAL, Compliance.Status sea FAILED, y RecordState sea ACTIVE. El patron usa la misma sintaxis JSON de metric filters que los filtros CIS del Blog A. Publica una metrica SecurityHub/CriticalFindings con valor 1. Crea una alarma con threshold > 5 en un periodo de 1 hora. Ten en cuenta que el metric filter cuenta eventos, no findings unicos: cada nueva evaluacion de un finding que ya estaba en CRITICAL y FAILED vuelve a sumar. Para contar solo cambios de estado, agrega al patron JSON una condicion que exija que el campo ProductFields.PreviousComplianceStatus sea PASSED, y valida el resultado con una muestra antes de fijar el umbral. Con esa condicion, mas de 5 findings criticos nuevos en una hora indica que algo cambio significativamente.

Alarma 2: Caida de compliance score

Esto requiere un enfoque diferente. Opciones:
  • Metric filter por control. Crea un filtro que cuente findings FAILED por GeneratorId, que con consolidated control findings identifica el control (por ejemplo security-control/IAM.1), no el estandar. La metrica sube cuando hay mas failures en ese control.
  • Log Alarm. CloudWatch soporta Log Alarms: alarmas que evaluan directamente el resultado de una consulta de Logs Insights ejecutada en un schedule. No necesitas publicar metricas intermedias. Programa una consulta similar a la Consulta 2 cada hora y define un threshold sobre el porcentaje de compliance. Si baja del umbral, la alarma dispara.

Alarma 3: Cuenta miembro con problemas

Si operas multi-cuenta y los findings de varias cuentas llegan al mismo log group, un metric filter que cuente findings FAILED por AwsAccountId permite crear alarmas por cuenta. Si cada cuenta tiene su propio log group administrado, crea el filtro en cada cuenta. Util para detectar cuentas que acumulan deuda de seguridad.

Integracion con los filtros CIS del Blog A

Si ya tienes los 14 metric filters de CIS del Blog A, ahora tienes dos capas de deteccion complementarias:
  • Los metric filters CIS detectan eventos de configuracion via CloudTrail (alguien cambio un security group, alguien uso root). Son alarmas de actividad.
  • Los findings de Security Hub detectan el estado resultante: despues de que alguien cambio el security group, el estado de compliance del recurso puede haber pasado de PASSED a FAILED. Son alarmas de postura.
Ambas capas llegan a CloudWatch. El dashboard puede mostrar las dos en el mismo panel: los composite alarms CIS del Blog A junto a la Fila 2 de este blog (SLIs de seguridad). Cuando un composite CIS dispara y al mismo tiempo un finding de compliance falla, la correlacion te da confianza de que no es ruido.

Lo que no cubre esta integracion (limitaciones honestas)

  • Costo por volumen. Si tu organizacion genera miles de findings por hora, el costo de ingestion en CloudWatch Logs puede ser significativo. Los findings de Security Hub no son logs pequenos: un finding de control en formato ASFF puede llegar a 240 KB, el maximo antes de que Security Hub CSPM recorte Resource.Details. Mide el tamano real con messageSize(@message) sobre una muestra antes de habilitar para toda la organizacion. Las reglas de habilitacion de telemetria permiten acotar por alcance, etiquetas y Regiones, pero la documentacion no incluye un filtro por severidad de los findings. Si el costo es una preocupacion, empieza con una regla para una cuenta o una unidad organizativa, mide el volumen real y luego extiende la regla al resto de la organizacion.
  • Logs Insights re-ejecuta en cada refresh del dashboard. Cada vez que abres el dashboard o se actualiza automaticamente, las consultas de Logs Insights se ejecutan de nuevo contra los logs. Si tu log group es grande, esto genera costo de scan. Para widgets que no necesitan datos en tiempo real (como compliance score diario), considera usar Log Alarms con scheduled queries: la consulta se ejecuta en un schedule fijo y el resultado alimenta la alarma directamente, sin re-ejecucion en cada refresh.
  • No es retroactivo. La documentacion no describe una importacion de findings anteriores a la activacion de la telemetry enablement rule, asi que cuenta con que tu historial en CloudWatch Logs empieza cuando la activas. Si necesitas tendencias desde antes de la activacion, tendras que mantener el pipeline viejo (Lambda + EventBridge) para el periodo historico.
  • El formato cambia tu query. ASFF y OCSF tienen campos diferentes. Las consultas de este blog usan campos ASFF (Compliance.Status, Severity.Label, Resources.0.Type). Si eliges OCSF, los campos son distintos. Elige un formato y manten consistencia en toda la organizacion.

Conclusion

En 2023, la solucion de dashboard centralizado de AWS para findings de Security Hub en CloudWatch requeria Lambda, EventBridge, y codigo custom. En 2026 requiere una regla de telemetria y las consultas de Logs Insights que ya conoces. El destino es el mismo: un dashboard donde seguridad y operaciones comparten la misma vista. El camino es mas corto.

Recursos

  •  Log alarms  - Alarmas que evaluan directamente consultas de Logs Insights
# security-and-compliance# security-hub# amazon-cloudwatch# 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