La severidad dice qué tan grave, la criticidad dice sobre qué recurso: criticidad de recursos en AWS Security Hub
AWS Security Hub agregó la criticidad de recursos para priorizar exposiciones: un nivel (Very High a Unknown) que dice qué tan importante es el recurso para el negocio, no qué tan grave es el problema. Este artículo explica cómo se infiere de nombres y etiquetas, cómo se fija con una regla de automatización, cómo entra en la severidad, el choque de nombres con el campo Criticality de ASFF, y un runbook de revisión.
El tablero muestra dos exposiciones. Una es CRITICAL y está sobre una instancia de un entorno de pruebas que alguien levantó la semana pasada y que se borra el viernes. La otra es HIGH y está sobre la base de datos que guarda los datos de los clientes. Si ordenas solo por severidad, la del entorno de pruebas va primero. Cualquiera que conozca el entorno sabe que ese orden está mal, pero el tablero no lo sabe, porque la severidad mide qué tan explotable y grave es el problema, no qué tan importante es el recurso para el negocio.
AWS Security Hub agregó el 14 de octubre de 2026 la criticidad de recursos como dimensión para priorizar exposiciones. Es la pieza que le dice al tablero que la base de datos de clientes importa más que el entorno de pruebas. Este artículo explica qué es, cómo se asigna, cómo entra en la severidad de una exposición y dónde se ve. Incluye una aclaración importante sobre un choque de nombres, un procedimiento para que la criticidad refleje la realidad, y las limitaciones.
Qué es la criticidad de recursos
Security Hub asigna un nivel de criticidad a cada recurso de tu entorno. La criticidad indica qué tan importante es un recurso para el negocio y sirve para priorizar el trabajo de seguridad. El nivel es uno de cinco valores: Very High, High, Medium, Low o Unknown.
La criticidad está incluida en el plan Essentials de Security Hub, sin costo adicional, y está siempre activa para todas las cuentas. No hay nada que habilitar.
Conviene separar desde el principio dos ideas que es fácil confundir. La severidad de una exposición mide qué tan grave y explotable es el problema. La criticidad mide qué tan importante es el recurso afectado. Un problema explotable sobre un recurso descartable y un problema moderado sobre un recurso central no se parecen, aunque su severidad coincida. La criticidad es lo que separa esos dos casos.
Cómo se asigna la criticidad
Por defecto, Security Hub infiere la criticidad a partir de señales del propio recurso:
- Nombre del recurso: Security Hub busca patrones en el nombre. Un recurso con pci o prod en el nombre se trata como más importante que uno llamado sandbox.
- Etiquetas: busca patrones en las etiquetas. Un recurso con environment=production se trata como más importante que uno con environment=dev.
La inferencia es cómoda porque funciona sin configuración, pero es heurística. Depende de que tus nombres y etiquetas digan la verdad sobre la importancia del recurso. Una base de datos de producción mal etiquetada, o sin etiquetar, puede terminar con una criticidad que no corresponde a lo que realmente vale.
Para esos casos, puedes anular la criticidad inferida con una regla de automatización que fije la criticidad de forma explícita en los recursos que cumplan sus criterios. Por ejemplo, marcar todo el cómputo de una cuenta determinada como Very High. La regla se aplica tanto a los recursos que ya están en el inventario como a los nuevos a medida que Security Hub los descubre. Una regla de automatización siempre tiene precedencia sobre la criticidad inferida.
Security Hub registra qué fuente determinó el valor, así que puedes ver si la criticidad de un recurso vino de la inferencia o de una regla. Ese dato importa cuando revisas por qué un recurso quedó con cierta prioridad.
Cómo entra en la severidad de una exposición
La criticidad no vive aparte. Security Hub la usa como una de las entradas cuando calcula el impacto y la severidad de un hallazgo de exposición. De hecho, la criticidad del recurso es uno de los rasgos que contribuyen a una exposición, junto con las vulnerabilidades, las configuraciones incorrectas, la exposición de red y los permisos del recurso. La severidad de la exposición sale del número y la combinación de esos rasgos.
Hay un detalle que conviene tener presente. Los recursos con criticidad Unknown no influyen en la severidad de la exposición. Si un recurso importante quedó en Unknown porque no tiene ni nombre ni etiquetas que lo delaten, su importancia no se está reflejando en la priorización. Esa es otra razón para no dejar la criticidad enteramente a la inferencia en los recursos que de verdad importan.
Dónde se ve
La criticidad aparece en dos lugares de la consola. En la página de Resources es una columna, y la puedes usar para ordenar, filtrar y agrupar los recursos. Y en la pestaña de Impact assessment de un hallazgo de exposición, donde muestra la criticidad del recurso afectado.
Esto permite dos lecturas distintas. Desde la página de Resources ves tu inventario ordenado por importancia, independientemente de si hay un problema abierto. Desde una exposición ves si el recurso afectado es importante o no, que es el dato que faltaba en el ejemplo del inicio.
Una aclaración sobre el nombre
Aquí hace falta una advertencia, porque hay dos cosas distintas en Security Hub que se llaman casi igual, y confundirlas lleva a errores.
Lo que describe este artículo es el nivel de criticidad de recurso del Security Hub actual: un valor de Very High, High, Medium, Low o Unknown, que mide la importancia del recurso y entra en la priorización de exposiciones.
Existe además, desde hace años, un campo llamado Criticality en el formato de hallazgos de seguridad de AWS (AWS Security Finding Format, ASFF) de Security Hub CSPM. Ese campo es numérico, va de 0 a 100 en una escala de enteros, donde 0 significa que el recurso no tiene criticidad y 100 se reserva para los más importantes. Ese campo se actualiza con la operación BatchUpdateFindings y pertenece al mundo de los hallazgos de CSPM.
Son dos cosas diferentes: una es un nivel sobre el recurso en la experiencia de exposiciones, la otra es un número sobre un hallazgo en ASFF. Comparten la palabra criticidad y nada más. Si automatizas o escribes reglas, vale la pena confirmar con cuál de las dos estás trabajando antes de fijar un valor.
Señal, objetivo y runbook
El hilo de esta serie encaja aquí.
La señal es una exposición sobre un recurso de criticidad alta. Ese es el evento que debería subir en la cola, por encima de una exposición más grave sobre un recurso descartable.
El objetivo lo pone el equipo. Una meta razonable es que la criticidad de los recursos que de verdad importan no quede en manos de la inferencia: que toda base de datos con datos de clientes, todo recurso en una cuenta de producción regulada, tenga su criticidad fijada a propósito y no adivinada a partir del nombre. Es una meta de higiene, no un umbral que el servicio imponga.
El runbook es la revisión periódica de la criticidad: comprobar qué recursos quedaron en Unknown o con un valor inferido que no corresponde, y corregirlos con etiquetas o con una regla de automatización.
Runbook de revisión
Un procedimiento que un equipo de seguridad o de CloudOps puede adaptar:
- En la página de Resources, ordena por criticidad y revisa primero los recursos en Very High y High. Confirma que de verdad son tan importantes como dice el valor.
- Filtra los recursos en Unknown. Para cada uno que sí importe, decide cómo va a dejar de ser Unknown: con una etiqueta que refleje su entorno, o con una regla de automatización.
- Donde la inferencia se equivocó, por ejemplo una base de datos de producción marcada como poco importante por su nombre, crea o ajusta una regla de automatización. Recuerda que la regla siempre gana sobre la inferencia.
- Revisa la fuente que Security Hub registró para los recursos críticos. Si un recurso central depende solo de la inferencia, considera fijarlo con una regla para que no cambie si alguien edita una etiqueta.
- Vuelve a mirar las exposiciones abiertas. Con la criticidad corregida, el orden de prioridad debería reflejar la importancia real de los recursos.
- Repite la revisión cuando entren cuentas o cargas nuevas, porque la regla de automatización se aplica a los recursos nuevos a medida que aparecen, pero la convención de nombres y etiquetas depende de cada equipo.
Limitaciones
- La inferencia es heurística. Depende de patrones en nombres y etiquetas, así que un recurso importante mal nombrado o sin etiquetar puede quedar con una criticidad que no corresponde.
- Los recursos con criticidad Unknown no influyen en la severidad de la exposición. Un recurso importante en Unknown no sube de prioridad por su importancia.
- La criticidad por nivel que describe este artículo es la de la experiencia de exposiciones del Security Hub actual. No es el campo numérico Criticality de 0 a 100 del formato ASFF de Security Hub CSPM, aunque compartan el nombre.
- La función se anunció el 14 de octubre de 2026. La documentación describe la inferencia por nombre y etiquetas y la anulación por regla de automatización, pero conviene revisar la página de acciones y criterios de reglas de recurso para la sintaxis exacta de la regla antes de automatizar.
- La criticidad entra en el cálculo de severidad junto con otros rasgos. No es una perilla que fije la severidad por sí sola: cambia la prioridad en combinación con las vulnerabilidades, configuraciones y exposición de red del recurso.
Recursos
- Resources in Security Hub - Los cinco niveles de criticidad, cómo se infieren del nombre y las etiquetas, y la anulación por regla de automatización
- Exposure findings in Security Hub - La criticidad del recurso como rasgo que contribuye a una exposición
- Reviewing exposure findings - Las pestañas del detalle de una exposición, incluida la del recurso afectado
- Optional top-level ASFF attributes - El campo numérico Criticality de 0 a 100 del formato ASFF, distinto del nivel descrito aquí
- AWS Security Hub now supports resource criticality for prioritization - Anuncio con la disponibilidad en Essentials y el comportamiento siempre activo
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article