Validación de la configuración AWS Security Incident Response
Una vez completada la incorporación, puede validar que la inscripción, las fuentes de detección, los permisos de AWS Identity and Access Management (IAM), la contención y las notificaciones estén configurados correctamente antes de que se produzca un evento de seguridad real. En esta sección se proporcionan procedimientos de verificación paso a paso que utilizan tanto la AWS Management Console como la CLI de AWS.
Temas
Antes de la validación
Requisitos previos para validar la configuración de respuesta a incidentes de seguridad
Para completar estos pasos de validación, asegúrese de que dispone de lo siguiente:
Acceso mediante la consola o AWS Command Line Interface (AWS CLI) a su cuenta de administrador delegado (la cuenta que designó durante la incorporación)
La Región de AWS en la que activó la suscripción
Su ID de membresía (si la validación se hace con la AWS CLI)
Confirmación de que el registro está listo
AWS Security Incident Response no habilita las fuentes de registro en su nombre. Durante una investigación, los ingenieros se basan en los registros que ya están presentes en su entorno. Antes de validar la configuración, confirme que los siguientes registros estén habilitados en todas las cuentas y en las Regiones de AWS cubiertas. Sin estos registros, los ingenieros de respuesta a incidentes de seguridad tienen una visibilidad limitada durante las investigaciones. Habilítelos antes de continuar.
AWS CloudTrail: registro de eventos de administración (obligatorio)
Registros de flujo de Amazon VPC (recomendado)
Registro de acceso al servidor de Amazon S3 para buckets confidenciales (recomendado)
Registro de consultas de DNS de Amazon Route 53 Resolver (recomendado)
Verificación de que GuardDuty está habilitado
Ejecute el siguiente comando para verificar que Amazon GuardDuty está activo en sus cuentas:
aws guardduty list-detectors
Una respuesta que no esté vacía confirma que GuardDuty está activado en la Región de AWS actual. Repita este paso para cada región activa o realice la verificación en toda la organización a través de la cuenta de administrador delegado de GuardDuty.
nota
Los costos de AWS Security Incident Response no incluyen los costos de uso de GuardDuty. Consulte la página Precios de GuardDuty
Paso 1: Verificación de la inscripción y la membresía
Uso de la consola de AWS Security Incident Response
Inicie sesión en la cuenta de administrador delegado.
Confirme que el estado de su membresía sea Activa. El estado Pendiente indica que la incorporación está incompleta.
En Ámbito de la cuenta, compruebe que aparecen en la lista las unidades organizativas que pretendía cubrir. La cobertura se selecciona a nivel de unidad organizativa (UO), no a nivel de cuenta individual. Están cubiertas todas las cuentas de una unidad organizativa seleccionada (incluidas las unidades organizativas secundarias).
Confirme que la región de la lista coincide con el lugar en el que se ejecutan sus cargas de trabajo. La selección de la región se bloquea en el momento del registro y no se puede cambiar después de la configuración.
Uso de AWS CLI
Ejecute el comando siguiente desde la cuenta de administrador delegado.
aws security-ir list-memberships
El comando anterior devuelve su ID de membresía y su estado.
Ejecute el siguiente comando para obtener los detalles completos de la membresía, incluida la configuración del equipo de respuesta a incidentes:
aws security-ir get-membership --membership-idmembership-id
Use el resultado del comando para verificar la siguiente información.
El estado de la membresía es
ActiveLos miembros del equipo de respuesta a incidentes que aparecen en la lista coinciden con las partes interesadas previstas
Hay al menos dos miembros del equipo de respuesta a incidentes configurados (obligatorio)
Verificación del administrador delegado
Ejecute el siguiente comando para confirmar que la cuenta correcta está registrada como administrador delegado para Respuesta ante incidentes de seguridad:
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
nota
Práctica recomendada: utilice la misma cuenta de administrador delegado que configuró para otros servicios de seguridad de AWS (como AWS Security Hub CSPM y GuardDuty). La Arquitectura de referencia de seguridad de AWS recomienda utilizar la cuenta Security Tooling.
Paso 2: Verificación de las fuentes de detección y clasificación
AWS Security Incident Response controla los hallazgos de seguridad de GuardDuty y herramientas de terceros a través de Security Hub CSPM. El servicio utiliza un rol vinculado al servicio para incorporar los resultados a través de las reglas de Amazon EventBridge implementadas en sus cuentas durante la incorporación.
Verificación del rol vinculado al servicio de clasificación
El rol vinculado al servicio de AWSServiceRoleForSecurityIncidentResponse_Triage debe existir en su cuenta de administración y en todas las cuentas de miembro dentro del alcance.
Para verificarlo, ejecute el siguiente comando en las cuentas de administración y en las cuentas de miembro dentro del alcance:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Una respuesta correcta confirma que el rol existe. Si recibe un error NoSuchEntity, haga alguna de las siguientes opciones:
Si se incorporó mediante la consola: el rol debería haberse creado automáticamente. Póngase en contacto con AWS Support.
Si se incorporó mediante la API o la AWS CLI: Consulte Habilitación de la respuesta a incidentes de seguridad mediante la API/CLI para obtener instrucciones sobre la creación manual del rol.
Verificación del rol vinculado al servicio primario
El rol AWSServiceRoleForSecurityIncidentResponse también debe existir en su cuenta de administrador delegado. Ejecute el siguiente comando para verificar que el rol existe:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Verificación de la respuesta proactiva y las reglas de EventBridge
En la consola de AWS Security Incident Response, confirme que la respuesta proactiva aparezca como habilitada. El servicio realiza lo siguiente cuando está habilitado:
Ingiere los resultados de GuardDuty y Security Hub (CSPM) mediante las reglas de EventBridge
Clasifica automáticamente los resultados mediante el contexto específico del cliente (IP conocidas, entidades de IAM esperadas)
Crea casos de investigación proactivos cuando se identifican problemas de seguridad confirmados
Archiva los resultados de GuardDuty que se determinaron como benignos (visibles en la consola de GuardDuty en resultados archivados)
Comprobación de que las reglas de EventBridge están implementadas en las cuentas de los miembros
Siga los pasos que se describen a continuación para comprobar que las reglas de EventBridge estén implementadas en las cuentas de los miembros.
Abra la consola de Amazon EventBridge en una cuenta de miembro cubierta.
Elija Rules (Reglas).
Confirme que las reglas con
SecurityIncidentResponseen su nombre estén presentes y habilitadas.
Si las reglas no están, vuelva a ejecutar la configuración de respuesta proactiva desde la consola de respuesta a incidentes de seguridad o póngase en contacto con AWS Support.
Verificación de integraciones de terceros (si corresponde)
Si se utilizan herramientas de detección de terceros (como CrowdStrike Falcon, Trend Micro Cloud One o Fortinet Lacework FortiCNAPP), compruebe que sus resultados se transmitan a través de Security Hub CSPM:
Abra la consola de AWS Security Hub CSPM
. Vaya a Integraciones.
Confirme que la integración de su proveedor externo aparezca como Aceptando resultados.
nota
No es necesario habilitar los estándares o controles de la CSPM de Security Hub. Solo se requieren las integraciones de los proveedores para que la respuesta a un incidente de seguridad asimile los resultados de terceros.
Paso 3: Verificación de la canalización de resultados automatizada
En este paso se confirma que la canalización de EventBridge está activa y que los resultados están llegando a la clasificación automática.
Acerca de los ejemplos de resultados de GuardDuty
La característica integrada de GuardDuty Generar resultados de muestra produce resultados marcados como muestras. La clasificación automática filtra los resultados de muestra para evitar el ruido; no fluyen por todo el proceso de clasificación y no se pueden utilizar para validar la configuración de respuesta a incidentes de seguridad. No los utilice para este paso.
Validación con el dominio de prueba de GuardDuty
La documentación de GuardDuty proporciona un dominio de prueba (guarddutyc2activityb.com) que genera un resultado real sin necesidad de eventos de seguridad del mundo real. Al consultar este dominio desde una instancia de Amazon EC2 en una cuenta cubierta, se genera un resultado que la respuesta a incidentes de seguridad ingiere y procesa.
Para generar un resultado de prueba:
Conéctese a una instancia de Amazon EC2 en una cuenta cubierta mediante el administrador de sesiones de Systems Manager o SSH.
-
Use el siguiente comando:
dig guarddutyc2activityb.com Abra la consola de GuardDuty y, a continuación, seleccione Resultados. El resultado aparece en aproximadamente 5 minutos.
Qué esperar:
La clasificación automática procesa el resultado y determina que no es indicativo de un problema de seguridad real.
El resultado está archivado en GuardDuty. Para verlo, se debe seleccionar Archivado en el filtro Estado.
Si se utiliza Security Hub CSPM, el estado del flujo de trabajo del resultado cambia a
SUPPRESSED.No se crea ningún caso proactivo: este es el comportamiento correcto. Un caso se abre solo cuando la clasificación automática identifica una actividad que justifica una investigación humana.
nota
Si el resultado de la prueba no aparece en la lista archivada de GuardDuty en 15 minutos, consulte Solución de problemas. Si no hay ninguna instancia de Amazon EC2 disponible, continúe con el paso 4 y vuelva a esta prueba cuando el entorno esté listo.
Paso 4: Verificación de las notificaciones y del equipo de respuesta a incidentes
Verificación del equipo de respuesta a incidentes
En la consola de Respuesta a incidentes de seguridad, analice los miembros del equipo de respuesta a incidentes configurados. Cada miembro recibe notificaciones inmediatas por correo electrónico cuando se crea un caso.
O bien, ejecute el siguiente comando para verificar el uso de la AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Confirme que:
Se enumeran todas las partes interesadas previstas
Las direcciones de correo electrónico son correctas
Las preferencias de comunicación de cada miembro están configuradas adecuadamente (todas las opciones de comunicación están habilitadas de forma predeterminada, si un miembro no recibe notificaciones, se debe verificar que no se hayan borrado sus preferencias)
Descripción del rol de los observadores de casos
Los observadores de casos son partes interesadas a las que se les concede acceso para ver un caso específico. Detalles clave:
Los observadores son por caso, no por cuenta. Si se añade un observador a un caso, esta acción no le da acceso a ningún otro caso. Debe añadir observadores de forma explícita a cada caso en el que desee que tengan visibilidad.
Los observadores tienen acceso de solo lectura. Pueden ver los detalles de los casos y recibir notificaciones sobre las actualizaciones de estos, pero no pueden realizar acciones de contención ni de corrección en los recursos.
Se pueden añadir hasta 30 partes interesadas por caso individual.
Cada caso incluye una política de IAM rellenada previamente que tan solo permite el acceso a dicho caso específico, y se mantienen los privilegios mínimos.
Este análisis por caso es especialmente importante cuando se permite el acceso a partes externas, como los socios de detección y respuesta gestionadas (MDR) o los equipos de investigación de terceros, que solo deberían ver el caso específico en el que están involucrados.
Verificación de la entrega de las notificaciones con un caso de prueba
La forma más eficaz de validar el flujo de notificaciones de manera integral es crear un caso de prueba reactivo (autoadministrado):
En la consola de respuesta a incidentes de seguridad, cree un nuevo caso autoadministrado.
En el título y la descripción del caso, indique claramente: “Esto es una prueba de validación de la configuración, no hay ningún problema de seguridad real”.
Compruebe que todos los miembros del equipo de respuesta a incidentes configurado reciban la notificación por correo electrónico.
Cierre el caso después de confirmar que se recibieron las notificaciones.
importante
La creación de un caso de prueba puede provocar una respuesta por parte de los ingenieros de respuesta a incidentes de seguridad si se solicita la colaboración con soporte de AWS. Marque claramente su caso como prueba para evitar una escalada innecesaria. Utilice este paso una vez para confirmar que el canal funciona y, a continuación, cierre el caso de inmediato.
Qué esperar de las notificaciones de casos
Cuando se crea un caso (ya sea de forma proactiva por parte del servicio o de forma reactiva por parte de su equipo), todos los miembros del equipo de respuesta a incidentes configurado reciben una notificación por correo electrónico con los detalles del caso.
Verificación de la integración de EventBridge (si está configurada)
Si se ha configurado EventBridge para redirigir los eventos de casos a plataformas de terceros (como ServiceNow, Jira, Slack o PagerDuty), se debe comprobar que el caso de prueba active la notificación esperada en esos sistemas.
Paso 5: Verificación de la preparación para la contención (opcional)
nota
La contención es opcional y no está habilitada de forma predeterminada. La infraestructura de contención que se describe en esta sección solo es necesaria si decide habilitar la contención. No es necesaria para que la respuesta a incidentes de seguridad supervise su entorno, investigue los resultados o abra casos.
Si no se ha habilitado la contención
Entonces no hay nada que validar. La respuesta a incidentes de seguridad proporciona orientación e investigación durante los eventos de seguridad, pero no toma medidas de contención automatizadas a menos que usted autorice dicha acción de forma explícita.
Si se ha habilitado la contención
Compruebe el estado de la contención en la consola. Compruebe si las acciones de contención aparecen como Autorizadas. Las acciones de contención admitidas incluyen manuales de procedimiento para lo siguiente:
Buckets de Amazon S3 afectados
Instancias de Amazon EC2 afectadas
Entidades principales de IAM afectadas
Compruebe que el StackSet de CloudFormation esté implementado. La contención requiere funciones de IAM (AWSSecurityIncidentResponseContainment y AWSSecurityIncidentResponseContainmentExecution) en las cuentas cubiertas:
Abra AWS CloudFormation en su cuenta de administración.
Elija StackSets.
Confirme que el StackSet de contención de respuesta a incidentes de seguridad muestra
SUCCEEDEDen todas las cuentas de destino.
Si el StackSet no está implementado, la autorización de contención en la consola no implica que se tomen acciones de contención reales.
Confirme su preferencia de contención. La respuesta a incidentes de seguridad admite tres niveles de contención:
Aprobación obligatoria (valor predeterminado): no se realiza contención proactiva de ningún recurso sin autorización explícita caso por caso.
Contención confirmados: contención proactiva de los recursos que se confirma que están afectados.
Contención sospechosos: contención proactiva de los recursos con una alta probabilidad de estar afectados.
Para enviar o actualizar sus preferencias, cree un caso AWS Support con el tipo de caso Técnico: Servicio de respuesta a incidentes de seguridad/Otro.
Si desea la clasificación de EC2: implemente la plantilla de CloudFormation Contención con clasificación de EC2. Esto permite que los ingenieros de respuesta a incidentes de seguridad recopilen datos de investigación de las instancias de Amazon EC2 mediante AWS Systems Manager.
Paso 6: Confirmación de la operación continua
Tras realizar la validación inicial, utilice estos indicadores para confirmar que la respuesta a incidentes de seguridad funciona de forma continua según lo previsto.
La ausencia de casos es normal
La respuesta a incidentes de seguridad crea un caso proactivo solo cuando la clasificación automática identifica una actividad que justifica una investigación humana. Cuando la clasificación determina que un resultado es benigno, lo archiva sin crear un caso ni ponerse en contacto con su equipo. Una implementación sin casos abiertos y con un flujo constante de resultados archivados de GuardDuty funciona según lo previsto.
Si no ve ningún caso ni ningún resultado archivado después de que su entorno haya estado activo durante varios días, es posible que la canalización no esté conectada. Compruebe los pasos 2 y 3.
nota
Los casos proactivos que no hayan recibido respuesta del cliente durante 5 días se cierran de forma automática.
Resultados archivados y reglas de supresión como señales de estado
A medida que la respuesta a incidentes de seguridad procesa los resultados a lo largo del tiempo, se crean dos artefactos observables:
Resultados archivados: resultados que la clasificación automática determinó como benignos. Se acumulan con el tiempo y están visibles en la consola de GuardDuty, en Resultados, y luego seleccione Archivados.
Reglas de supresión de GuardDuty: para los tipos de resultados confirmados como actividad esperada en su entorno, la respuesta a incidentes de seguridad implementa reglas de supresión con nombre (con el prefijo
SIRTriage-). Estas son la señal continua más clara de que la clasificación automática funciona de forma activa. Visite Reglas de supresión en la consola de GuardDuty para verlos.
Su equipo de respuesta a incidentes recibe una notificación cuando se crea una regla de supresión. Si se creó una regla por error, póngase en contacto con AWS Support para solicitar su reversión. Los resultados archivados se conservan en GuardDuty durante 90 días.
Informe de actividad mensual
La respuesta a incidentes de seguridad envía un informe de actividad mensual a su equipo de respuesta a incidentes en el que se resumen los hallazgos procesados, los resultados de la clasificación y los casos que se han abierto. Si su equipo no ha recibido ningún informe después del primer mes natural completo de funcionamiento, compruebe que la comunicación está habilitada con los miembros del equipo de respuesta a incidentes. Para cualquier otro problema relacionado con el informe mensual, póngase en contacto con su equipo de cuentas o abra un caso de soporte con el tipo de caso: Técnico: Servicio de respuesta a incidentes de seguridad/Otro e incluya la siguiente información:
Nombre de su organización
El mes/año del informe previsto (por ejemplo, “mayo de 2026”)
Su identificación de suscripción a la respuesta a incidentes de seguridad, si la conoce
Los identificadores de cuenta incluidos en su suscripción a la respuesta a incidentes de seguridad
Qué esperar de los ingenieros de Respuesta ante incidentes de seguridad de
Cuando crea un caso con soporte de AWS o el servicio crea uno de forma proactiva, los ingenieros de respuesta a incidentes de seguridad reconocen los nuevos casos en 15 minutos. Este SLO de confirmación de 15 minutos se aplica a todos los tipos de casos con soporte de AWS, tanto a los incidentes de seguridad activos como a las investigaciones. La confirmación inicial indica que su caso está siendo revisado. El plazo de evaluación completo puede variar en función de la gravedad y la complejidad del caso.
En los casos proactivos (que se crean de forma automática cuando el servicio de clasificación identifica un problema de seguridad confirmado), el servicio crea el caso después de que la clasificación automática confirme el problema y se notifica al equipo de respuesta a incidentes cuando se abre el caso.
Lista de comprobación de validación
Se debe utilizar esta lista de comprobación para confirmar que la configuración está completa:
Fuentes de registro habilitadas: eventos de administración de CloudTrail (obligatorio), registros de flujo de Amazon VPC, registro de acceso a Amazon S3, registro de consultas de DNS (recomendado)
GuardDuty está activado en todas las cuentas y regiones activas
El estado de la membresía es Activo en la consola de respuesta a incidentes de seguridad
La región es correcta (bloqueada en el momento del registro)
La cuenta de administrador delegado es correcta (se recomienda la cuenta de Security Tooling)
El alcance de la cuenta cubre las unidades organizativas previstas
AWSServiceRoleForSecurityIncidentResponse_Triageexiste en la cuenta de administraciónAWSServiceRoleForSecurityIncidentResponse_Triageexiste en las cuentas de miembros incluidas en el alcanceAWSServiceRoleForSecurityIncidentResponseexiste en la cuenta de administrador delegadoLas integraciones de terceros (si corresponde) aparecen como aceptando resultados en Security Hub CSPM
Las reglas de EventBridge con
SecurityIncidentResponseen el nombre están presentes y activadas en las cuentas de miembrosLos miembros del equipo de respuesta a incidentes están configurados con la información de contacto correcta y las comunicaciones habilitadas
Se creó un caso de prueba y todos los miembros del equipo recibieron notificaciones por correo electrónico
El resultado de dominios de prueba (
guarddutyc2activityb.com) se archivó en 15 minutosEl StackSet de contención se implementó de forma correcta (si la contención está habilitada)
Se envió la preferencia de contención (si la contención está habilitada)
Las integraciones de EventBridge (si están configuradas) distribuyen eventos a plataformas de terceros
Los resultados archivados son visibles en GuardDuty después de la primera semana de funcionamiento
Facturación pendiente
Clientes de Enterprise Support y Unified Operations: la respuesta a incidentes de seguridad se incluye sin costo adicional como parte de su plan de soporte. No verá los cargos de respuesta a incidentes de seguridad en AWS Cost Explorer ni en el Informe de costo y uso de AWS.
Todos los demás clientes: Los precios de Security Hub se basan en parte en el número de resultados incorporados. Los primeros 10 000 resultados al mes son gratuitos. Consulte Precios de AWS Security Incident Response
Solución de problemas
| Síntoma | Causa probable | Resolución |
|---|---|---|
| El estado de la suscripción está pendiente | Incorporación no completada | Complete todos los pasos de configuración. Consulte Introducción. |
list-memberships se devuelve vacío |
La región de la CLI no coincide con la región de suscripción | Especifique la región en la que se activó: --region |
| No se encuentra el SLR de clasificación en la cuenta de administración | Incorporado mediante API/CLI sin crearlo | Crear manualmente aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Faltan cuentas de miembros en la cobertura | El SLR no está implementado en la cuenta de miembro | Vuelva a ejecutar la configuración de respuesta proactiva desde la consola de respuesta a incidentes de seguridad |
| Las reglas de EventBridge no están presentes en una cuenta | La configuración de respuesta proactiva está incompleta | Vuelva a ejecutar la configuración o compruebe si hay errores de StackSet en CloudFormation |
| No se procesaron los resultados de muestra de GuardDuty | Los resultados de muestra se filtran mediante la clasificación automática (esperado) | Revise los resultados archivados en GuardDuty |
| El resultado de dominios de prueba no se archivó en 15 minutos | Faltan reglas de EventBridge o están deshabilitadas; GuardDuty no está habilitado | Compruebe los pasos 2 y 3 |
| No hay casos después de un período prolongado | Todos los resultados se archivaron por clasificación (esperado) o la canalización no está conectada | Revise los resultados archivados en GuardDuty Si no existen, verifique la respuesta proactiva y las reglas de EventBridge. |
| No se están clasificando los resultados de GuardDuty | GuardDuty no está activado o no genera resultados | Verifique que GuardDuty está habilitado: aws guardduty list-detectors |
| El servicio no procesa los resultados | La clasificación automatizada determinó que la actividad detectada era la esperada | Revise los resultados archivados de GuardDuty y los resultados SUPPRESSED de CSPM de Security Hub |
| Los miembros del equipo no reciben notificaciones | El correo electrónico no es correcto, las comunicaciones están deshabilitadas o el correo es spam | Compruebe las direcciones de correo electrónico y las preferencias de comunicación; compruebe las carpetas de correo no deseado |
| Las acciones de contención no se están ejecutando | StackSet no está implementado o no se ha enviado la preferencia | Verifique el estado de StackSet en CloudFormation y confirme la preferencia enviada mediante AWS Support |
Recursos relacionados
