AWS Builder Center

Builder Center

Planes de remediación en AWS Security Hub: una causa, muchas exposiciones

El lunes por la mañana el tablero de seguridad muestra doce exposiciones nuevas. El equipo las reparte, abre doce tickets y cada persona empieza a investigar la suya. A media semana alguien nota que siete de esas exposiciones comparten el mismo rol con permisos demasiado amplios y que otras tres dependen del mismo grupo de seguridad abierto a internet. Dos cambios habrían cerrado diez tickets. El trabajo se hizo, pero se hizo en el orden equivocado.

vtjean

En un artículo anterior de esta serie la pregunta era qué exposición atender primero en AWS Security Hub. Esta vez la pregunta cambia: qué corrección hacer primero. Son dos decisiones distintas, porque una sola corrección puede cerrar o bajar de severidad varias exposiciones a la vez. Los planes de remediación, anunciados el 1 de octubre de 2026, están pensados para esa segunda decisión.
Este artículo explica qué es un plan, cómo leerlo, por qué su guía ya tiene la forma de un runbook y cómo consultarlo desde la AWS Command Line Interface (AWS CLI). Cierra con un procedimiento de triaje y con las limitaciones que conviene conocer antes de adoptarlo.

Qué es un plan de remediación

Un hallazgo de exposición en Security Hub es la correlación de varias señales de seguridad que, juntas, describen un riesgo concreto sobre un recurso. Security Hub analiza señales de servicios como Amazon Inspector, Amazon GuardDuty, Amazon Macie y AWS Security Hub CSPM, y combina vulnerabilidades, amenazas y configuraciones incorrectas en un solo hallazgo.
Un plan de remediación agrupa las exposiciones que comparten una causa raíz y apunta a un único recurso. Si corriges ese recurso, varias exposiciones se resuelven o bajan de severidad con una sola acción.
Security Hub genera un plan por cada combinación de recurso objetivo y rasgo de exposición que puede atender. El rasgo es el tipo de condición que contribuye a la exposición, como una configuración incorrecta, una vulnerabilidad o la posibilidad de alcanzar el recurso desde la red. Esa combinación importa: un mismo recurso puede tener más de un plan si participa en exposiciones por rasgos distintos, y una misma exposición puede aparecer en más de un plan.
Los planes se ordenan para que los que reducen más riesgo aparezcan primero. La documentación aclara que, cuando Security Hub detecta una exposición nueva, el plan correspondiente puede no aparecer de inmediato.
Según el anuncio, los planes no tienen costo adicional dentro del plan Essentials de Security Hub y están disponibles en todas las Regiones donde Security Hub está disponible.

Cómo leer un plan

En la consola, los planes están en la sección Response, opción Remediations. Cada plan incluye estos campos, y la tabla muestra la mayoría de ellos en cada fila:
  • Prioridad: Critical, High, Medium o Low. Indica la urgencia.
  • Estado: New si el plan es recién identificado, Updated si cambió después de identificarse, Resolved si el objetivo de remediación ya no está presente.
  • Impacto: tres cifras. Cuántas exposiciones resuelve por completo, cuántas baja de severidad y cuántas atiende sin cambiar su severidad.
  • Rollout: Immediate si la corrección aplica de inmediato, Requires deployment si exige un despliegue.
  • Acción: el cambio recomendado.
  • Rasgo: el rasgo de exposición que el plan atiende.
  • Recurso objetivo, cuenta y Región.
Cuando la guía lo incluye, el plan también muestra el alcance afectado, un nivel de riesgo del cambio, si es reversible, el nivel de automatización y si requiere revisión humana.
La prioridad y el impacto se leen juntos, y la documentación recomienda usar ambos para decidir qué corregir primero. La prioridad dice qué tan pronto actuar. El impacto dice cuántas exposiciones cambian con una sola corrección. Una regla práctica, que no viene de la documentación, es respetar la prioridad y usar el impacto para desempatar entre planes con la misma prioridad.
El campo Rollout ayuda a planificar. Una corrección Immediate puede entrar en el turno actual. Una que requiere despliegue tiene que pasar por la ventana de cambios, y conviene saberlo antes de comprometer una fecha.
Al abrir un plan, la pestaña Affected exposures lista las exposiciones que cubre, con la severidad antes y después de la corrección. Si la exposición se atiende sin bajar de severidad, aparece un solo valor. En sentido contrario, al abrir una exposición, la pestaña Remediations muestra los planes que la atienden. Una exposición puede tener más de uno.

La guía ya es un runbook

El contenido que da valor operativo a un plan está en su guía, en la sección Guidance de la pestaña Overview. Describe el problema, el riesgo de hacer el cambio y los pasos para corregirlo.
Los pasos se agrupan en fases, por ejemplo Prerequisite, Snapshot, Fix, Verify y Done. Las fases y su contenido dependen de la guía disponible para cada tipo de recurso. Un paso puede incluir su rollback, es decir, cómo deshacerlo. Los ejemplos vienen en varios formatos, entre ellos AWS CLI, Python, Terraform, AWS Cloud Development Kit (AWS CDK) y AWS CloudFormation.
Esa estructura coincide con la de un procedimiento de cambio bien escrito: condiciones previas, una copia del estado actual, el cambio, una verificación y una vía de regreso. La API lo hace explícito. Cada paso tiene una fase, una acción, una descripción y el servicio donde se ejecuta, y puede incluir un paso inverso y una verificación posterior. La guía también declara los permisos que necesita, los parámetros de entrada y el estado final esperado.
Hay un punto que no se puede perder de vista: Security Hub describe los pasos y el equipo los aplica. Security Hub no modifica tus recursos. El plan entrega el runbook, pero la ejecución, la aprobación del cambio y la verificación siguen siendo responsabilidad de quien opera el entorno.
No todos los recursos tienen guía. Cuando no hay guía disponible para el recurso objetivo, la sección lo indica.

Señal, objetivo y runbook

El hilo de esta serie se aplica sin forzarlo.
La señal es un plan con prioridad Critical o High en estado New. Ese es el evento que debería entrar a la cola del equipo, en lugar de cada exposición por separado.
El objetivo lo define el equipo, porque Security Hub no lo fija. Una propuesta razonable es medir el tiempo que tarda un plan en pasar de New a Resolved y fijar un límite, por ejemplo cinco días hábiles para Critical y diez para High. Esos números son un punto de partida, no una recomendación documentada. Ajústalos a la capacidad real del equipo y a sus ventanas de cambio.
El runbook son las fases de la guía. Prerequisite y Snapshot antes de tocar nada, Fix para el cambio, Verify para confirmar y, cuando la guía lo incluye, el paso inverso a mano por si algo sale mal.
Una ventaja de medir sobre planes es que el indicador refleja trabajo real. Siete tickets cerrados pueden equivaler a un solo cambio, como en el ejemplo del inicio, y un plan resuelto dice cuántas exposiciones cayeron con él.

Desde la AWS CLI

Hay dos operaciones de API para trabajar con planes. En la API, un plan se llama remediation target y se identifica con un TargetUid. La primera operación es GetRemediationsV2. Devuelve los planes ordenados por prioridad, de mayor a menor, y con paginación. Si la cuenta que la llama es el administrador delegado de Security Hub en AWS Organizations, devuelve también los planes de las cuentas miembro. La segunda es ListExposuresByRemediationV2, que devuelve las exposiciones de un plan ordenadas por su severidad anterior.
GetRemediationsV2 acepta tres formas de acotar la consulta que no se pueden combinar entre sí: un plan concreto por su identificador, los planes asociados a una exposición o una lista con filtros. Los filtros admiten hasta dos condiciones, cada una con un solo valor, sobre estos campos: tipo de recurso, prioridad, estado, identificador del recurso, cuenta propietaria del recurso y proveedor de nube. La referencia de la API no dice cómo se combinan las dos condiciones. En la consola se combinan con AND, así que conviene incluir prioridad y estado en la salida para confirmarlo.
Para listar los planes Critical que todavía están en estado New, con dos filtros combinados:
1
aws securityhub get-remediations-v2 --filters '{"CompositeFilters":[{"StringFilters":[{"FieldName":"Priority","Filter":{"Value":"Critical"}},{"FieldName":"Status","Filter":{"Value":"New"}}]}]}' --query "Items[].{Plan:TargetUid,Prioridad:Priority,Estado:Status,Accion:RemediationSummary.Action,Recurso:Resource.Id,Cuenta:Resource.ResourceOwnerAccountId,Resueltas:Outcome.ResolvedFindingsCount,Reducidas:Outcome.SeverityReductionFindingsCount}" --output table
Las columnas Resueltas y Reducidas vienen del bloque de resultado del plan, que también incluye la cantidad de exposiciones atendidas sin cambio de severidad.
Para ver los planes que atienden una exposición concreta, se usa el identificador que aparece en el campo metadata.uid del hallazgo:
1
aws securityhub get-remediations-v2 --metadata-uid ID_DE_LA_EXPOSICION
Para leer la guía de un plan solo con ejemplos de AWS CLI y ver los pasos con su fase, su inverso y su verificación:
1
aws securityhub get-remediations-v2 --target-uid ID_DEL_PLAN --show-guidance --guidance-format AwsCli --query "Items[0].Guidance.Specification.Steps[].{Fase:Phase,Accion:Action,Inverso:Inverse,Verificar:VerifyAfter}"
La misma respuesta incluye los permisos que la guía declara como necesarios y el estado final esperado. Conviene revisar esos dos campos como parte de la fase Prerequisite, antes de ejecutar nada.
Para listar las exposiciones que cubre un plan con su severidad antes y después de la corrección:
1
aws securityhub list-exposures-by-remediation-v2 --target-uid ID_DEL_PLAN --query "Items[].{Exposicion:Title,Antes:PreviousSeverity,Despues:ProjectedSeverity}" --output table
La respuesta de esta operación también trae el total de exposiciones asociadas al plan. Ese número sirve para comparar con lo que muestra la consola, que puede no listar todas.
El anuncio menciona que agentes de IA pueden consumir los planes por la API para automatizar correcciones. La estructura lo permite, porque cada paso es un objeto con campos definidos. Si se automatiza, conviene respetar el campo que indica si el plan requiere revisión humana y mantener una aprobación explícita para los cambios que exigen despliegue.

Runbook de triaje

Un procedimiento que un equipo de SecOps o CloudOps puede adaptar:
  1. Al inicio del turno, consulta los planes Critical y High en estado New. Como cada filtro compara un solo valor y se aceptan dos filtros por consulta, hacen falta dos consultas, una por prioridad. En una organización, ejecuta las consultas desde la cuenta de administrador delegado. Si cada equipo atiende sus propias cuentas, usa el segundo filtro para la cuenta propietaria en lugar del estado y descarta los planes que no estén en New al revisar la salida.
  2. Ordena la cola por prioridad y, dentro de cada prioridad, por cantidad de exposiciones resueltas. Si dos planes tocan el mismo recurso por rasgos distintos, considera atenderlos en la misma ventana de cambio, cada uno con su propia guía.
  3. Abre la lista de exposiciones del plan y confirma que tienen sentido juntas. Si alguna exposición parece ajena a la causa raíz, anótalo antes de seguir.
  4. Revisa el campo Rollout. Si dice Requires deployment, registra el cambio en la ventana correspondiente y comunica la fecha esperada.
  5. Lee la guía completa. Verifica los permisos declarados, el estado final esperado y el nivel de riesgo del cambio. Si la guía indica que requiere revisión humana, pide esa revisión antes de ejecutar.
  6. Ejecuta las fases en orden. Si la guía incluye una fase Snapshot, no la saltes: guarda el estado anterior, que es lo que necesitarías para revertir.
  7. Ejecuta la verificación de cada paso cuando la guía la incluya. Si una falla, aplica el paso inverso, si existe, y detén el cambio.
  8. Si el resumen del plan incluye pasos posteriores a la remediación, ejecútalos. En los días siguientes, consulta el plan y confirma que su estado cambió a Resolved. La documentación no publica cuánto tarda ese cambio, así que define con el equipo cuánto esperar antes de investigar.
  9. Compara la severidad final de las exposiciones con la severidad proyectada. Si una exposición no bajó como se esperaba, revisa si tiene otro plan pendiente.
  10. Registra el tiempo de New a Resolved para medir el objetivo del equipo.

Limitaciones

Antes de adoptar los planes como la cola principal de trabajo, conviene tener presentes estos puntos:
  • Security Hub no aplica la corrección. Entrega la guía, y el equipo la ejecuta a mano o con su propia automatización.
  • No todos los recursos tienen guía disponible.
  • Un plan puede no aparecer de inmediato después de que se detecta una exposición nueva. La documentación no publica cuánto tarda.
  • En la consola, la lista de planes no se puede ordenar por columna.
  • En la consola, los filtros son de igualdad exacta, sin coincidencias parciales ni rangos. Se aplican hasta dos a la vez y se combinan con AND. En la API, cada filtro compara un solo valor y se aceptan hasta dos por consulta. Para consultar dos prioridades o dos estados hacen falta consultas separadas.
  • El widget de planes en el tablero resumen muestra hasta cinco planes en estado New o Updated, ordenados por prioridad, y no acepta filtros. Además reporta el impacto de cada plan por separado: una exposición que atienden dos planes se cuenta en ambos. Sumar el impacto de varios planes puede sobrestimar el resultado.
  • La pestaña de exposiciones afectadas puede no mostrar todas las exposiciones de un plan. Cuando ocurre, indica cuántas está mostrando.
  • La guía describe campos como el nivel de riesgo, la reversibilidad y el nivel de automatización. La referencia de la API da ejemplos de valores, como Fully reversible para la reversibilidad o Full para la automatización, pero no publica la lista completa. Conviene leerlos plan por plan y no construir reglas automáticas sobre valores supuestos.
  • Al momento de escribir este artículo, GetRemediationsV2 y ListExposuresByRemediationV2 no aparecen como acciones propias en la lista de acciones de Security Hub de la referencia de autorización de servicios. Esa misma referencia aclara que a veces una acción controla el acceso a más de una operación. Antes de escribir políticas de AWS Identity and Access Management (IAM) con permisos mínimos para estas consultas, prueba la política en una cuenta que no sea de producción.

Recursos

# security-hub# security-and-compliance
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