

# Respuesta ante incidentes
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10 ¿Cómo anticipa, responde a y se recupera de los incidentes?](w2aac19b7c15b5.md)

# SEC 10 ¿Cómo anticipa, responde a y se recupera de los incidentes?
<a name="w2aac19b7c15b5"></a>

La preparación es fundamental para investigar de forma oportuna y efectiva, dar respuesta a incidentes de seguridad, así como para minimizar posibles interrupciones en su organización.

**Topics**
+ [SEC10-BP01: Identificar el personal clave y los recursos externos](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02: Desarrollar planes de administración de incidentes](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03: Preparar capacidades forenses](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04: Automatización de la capacidad de contención](sec_incident_response_auto_contain.md)
+ [SEC10-BP05: Aprovisionamiento previo del acceso](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06: Implementar previamente herramientas](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Ejecutar los días de juego](sec_incident_response_run_game_days.md)

# SEC10-BP01: Identificar el personal clave y los recursos externos
<a name="sec_incident_response_identify_personnel"></a>

 Identifique las obligaciones legales, el personal y los recursos internos y externos que ayudarían a su organización a responder ante un incidente. 

Al definir su enfoque a la hora de responder ante un incidente en la nube, de forma conjunta con otros equipos (como el consejo jurídico, el equipo directivo, las partes interesadas de la empresa, los servicios de asistencia de AWS, entre otros), debe identificar el personal clave, las partes interesadas y los contactos pertinentes. Con el fin de reducir la dependencia y el tiempo de respuesta, asegúrese de que su equipo, los equipos especializados en seguridad y los equipos de intervención cuenten con los conocimientos adecuados sobre los servicios que utiliza y que tengan la oportunidad de realizar una formación práctica.

Le animamos a identificar a socios de seguridad externos de AWS que puedan ofrecerle una experiencia externa y una perspectiva diferente para aumentar sus capacidades de respuesta. Sus socios de seguridad de confianza pueden ayudarle a identificar posibles riesgos o amenazas con los que podría no estar familiarizado.

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto 

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Identificar al personal clave de la organización: mantenga una lista de contactos del personal de su organización al que tendría que involucrar para responder ante un incidente y recuperarse de él. 
+  Identificar a los socios externos: si es necesario, póngase en contacto con socios externos que puedan ayudarle a responder ante un incidente y recuperarse de él. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Guía de respuesta ante incidentes de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Vídeos relacionados:** 
+  [Cómo prepararse y responder ante incidentes de seguridad en el entorno de AWS](https://youtu.be/8uiO0Z5meCs)

 **Ejemplos relacionados:** 

# SEC10-BP02: Desarrollar planes de administración de incidentes
<a name="sec_incident_response_develop_management_plans"></a>

 Cree planes que le ayuden a responder ante un incidente, tanto en el proceso de comunicación como en su recuperación. Por ejemplo, puede iniciar un plan de respuesta ante incidentes con las situaciones más probables para su carga de trabajo y organización. Incluya la forma en que se comunicaría y derivaría tanto interna como externamente. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Un plan de administración de incidentes es fundamental para responder y mitigar el impacto potencial de los incidentes de seguridad y recuperarse de él. Un plan de administración de incidentes es un proceso estructurado para identificar y solucionar los incidentes de seguridad y responder a ellos en el momento oportuno. 

 La nube tiene muchos de los mismos roles y requisitos operativos que se encuentran en un entorno local. A la hora de crear un plan de administración de incidentes, es importante tener en cuenta las estrategias de respuesta y recuperación que mejor se ajusten al resultado empresarial y a los requisitos de conformidad. Por ejemplo, si trabaja con cargas de trabajo en AWS que cumplen con la normativa FedRAMP en Estados Unidos, es útil cumplir con la [guía de administración de seguridad informática NIST SP 800-61](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Del mismo modo, cuando opere con cargas de trabajo con datos de información de identificación personal (PII) de Europa, considere situaciones como la forma en que podría proteger y responder a los problemas relacionados con la residencia de datos según lo dispuesto por las [normativa del Reglamento General de Protección de Datos (RGPD)](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en). 

 Al crear un plan de administración de incidentes para sus cargas de trabajo que operan en AWS, empiece con el [modelo de responsabilidad compartida de AWS](https://aws.amazon.com/compliance/shared-responsibility-model/), para crear un enfoque de defensa en profundidad en la respuesta ante incidentes. En este modelo, AWS administra la seguridad de la nube y usted es responsable de la seguridad en la nube. Esto significa que retiene el control y es responsable de los controles de seguridad que decida implementar. La [AWS Security Incident Response Guide (Guía de respuesta ante incidentes de seguridad de AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) expone en detalle los conceptos clave y las orientaciones básicas para crear un plan de administración de incidentes centrado en la nube.

 Un plan eficaz de administración de incidentes debe iterarse continuamente, manteniéndose al día con su objetivo de operaciones en la nube. Considere la posibilidad de utilizar los planes de implementación que se detallan a continuación cuando cree y haga evolucionar su plan de administración de incidentes. 
+  **Forme para la respuesta ante incidentes:** cuando se produzca una desviación de la base de referencia definida (por ejemplo, un despliegue erróneo o una configuración incorrecta), tal vez tenga que responder e investigar. Para hacerlo correctamente, debe comprender qué controles y capacidades puede utilizar para la respuesta ante incidentes de seguridad en su entorno de AWS, así como los procesos que debe tener en cuenta para preparar, educar y formar a sus equipos de la nube que participan en la respuesta ante incidentes. 
  +  [Guías de estrategias](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) y [runbooks](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) son mecanismos eficaces para crear coherencia en la formación sobre cómo responder a los incidentes. Empiece por crear una lista inicial de procedimientos que se ejecuten con frecuencia durante la respuesta ante incidentes y siga iterando a medida que aprenda o utilice nuevos procedimientos. 
  +  Socializar las guías de estrategias y los runbooks a través de [días de juego programados](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html). Durante los días de juego, simule la respuesta ante incidentes en un entorno controlado para que su equipo pueda recordar cómo responder y para verificar que los equipos implicados en la respuesta ante incidentes conocen bien los flujos de trabajo. Revise los resultados del evento simulado para identificar las mejoras y determinar si se necesita más formación o herramientas adicionales. 
  +  La seguridad se debe considerar el trabajo de todos. Genere un conocimiento colectivo del proceso de administración de incidentes mediante la participación de todo el personal que normalmente se encarga de las cargas de trabajo. Incluye todos los aspectos de su empresa: las operaciones, la prueba, el desarrollo, la seguridad, las operaciones empresariales y los líderes empresariales. 
+  **Documentar el plan de administración de incidentes:** documente las herramientas y el proceso para registrar, actuar, comunicar el progreso y proporcionar notificaciones sobre incidentes activos. El objetivo del plan de administración de incidentes es verificar que se restaura el funcionamiento normal lo antes posible, se minimiza el impacto empresarial y se mantiene informadas a todas las partes interesadas. Los ejemplos de incidentes incluyen, aunque no de forma exhaustiva, la pérdida o el deterioro de la conectividad de red, un proceso o una API que no responden, una tarea programada que no se realiza (por ejemplo, una aplicación de revisiones con errores), la falta de disponibilidad de los datos de la aplicación o del servicio, la interrupción no planificada del servicio debido a eventos de seguridad, la filtración de credenciales o errores de configuración. 
  +  Identifique al principal responsable de la resolución de incidentes, por ejemplo, el propietario de la carga de trabajo. Tenga una orientación clara sobre quién dirigirá el incidente y cómo se tratará la comunicación. Cuando haya varias partes que participen en el proceso de resolución de incidentes, como un proveedor externo, considere la posibilidad de crear una *matriz de responsabilidades (RACI)*, en la que se detallen los roles y responsabilidades de los distintos equipos o personas necesarias para la resolución de incidentes. 

     En una matriz RACI se detalla lo siguiente: 
    +  **R: parte** *encargada* de completar la tarea. 
    +  **A: parte o parte interesada** *responsable* con la autoridad final sobre la realización correcta de la tarea específica. 
    +  **C: parte** *consultada* cuyas opiniones normalmente se consideran expertas. 
    +  **I: parte** *informada* a la que se le notifica el progreso, a menudo solo cuando se completa la tarea o el resultado. 
+  **Clasificar los incidentes:** la definición y la clasificación de los incidentes en función de la gravedad y la puntuación del impacto ofrecen un enfoque estructurado para clasificar y resolver los incidentes. Las siguientes recomendaciones ilustran una *matriz de urgencia de impacto a resolución* para cuantificar un incidente. Por ejemplo, un incidente de impacto y urgencia bajos se considera un incidente de gravedad baja. 
  +  **Alta (A):** su empresa se ve considerablemente afectada. Las funciones fundamentales de su aplicación relacionadas con los recursos de AWS no están disponibles. Se reserva para los eventos más críticos que afectan a los sistemas de producción. El impacto del incidente aumenta rápidamente y el tiempo de corrección es muy importante. 
  +  **Media (M):** un servicio o una aplicación empresarial relacionado con los recursos de AWS está moderadamente afectado y funciona en un estado deteriorado. Las aplicaciones que contribuyen a los objetivos de nivel de servicio (SLO) se ven afectadas según los límites del acuerdo de nivel de servicio (SLA). Los sistemas pueden funcionar con una capacidad reducida sin mucho impacto financiero o de reputación. 
  +  **Baja (B):** las funciones no esenciales de su servicio o aplicación empresarial relacionadas con los recursos de AWS se ven afectadas. Los sistemas pueden funcionar con una capacidad reducida con un mínimo impacto financiero o de reputación. 
+  **Estandarizar los controles de seguridad:** el objetivo de la estandarización de los controles de seguridad es lograr coherencia, trazabilidad y repetibilidad con respecto a los resultados operativos. Impulse la estandarización de las actividades clave que son fundamentales para la respuesta ante incidentes; por ejemplo: 
  +  **Administración de identidades y accesos:** establezca mecanismos para controlar el acceso a los datos y administrar los privilegios de las identidades de personas y máquinas. Amplíe su propia administración de identidades y accesos a la nube, mediante la seguridad federada con inicio de sesión único y privilegios basados en roles para optimizar la administración de los accesos. Para obtener prácticas recomendadas y planes de mejora para estandarizar la administración de los accesos, consulte la [sección de administración de identidades y accesos](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) del documento técnico Pilar de seguridad. 
  +  **Administración de vulnerabilidades:** establezca mecanismos para identificar las vulnerabilidades de su entorno de AWS que puedan utilizar los atacantes para comprometer el sistema y hacer un uso indebido de él. Implemente controles de detección y prevención como mecanismos de seguridad para responder ante incidencias de seguridad y mitigar su posible impacto. Estandarice procesos como, por ejemplo, el modelado de amenazas como parte del ciclo de vida de la creación de su infraestructura y de la entrega de aplicaciones.
  +  **Administración de configuraciones:** defina las configuraciones estándar y automatice los procedimientos para desplegar los recursos en la Nube de AWS. La estandarización tanto de la infraestructura como del aprovisionamiento de recursos contribuye a mitigar el riesgo de configuración incorrecta por despliegues erróneos o configuraciones incorrectas accidentales por intervención humana. Consulte la [sección de principios de diseño](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) del documento técnico Pilar de excelencia operativa para obtener orientación y planes de mejora a fin de implementar este control.
  +  **Registro y supervisión del control de auditoría:** implemente mecanismos para supervisar los recursos en busca de errores, deterioro del rendimiento y problemas de seguridad. La estandarización de estos controles también proporciona registros de auditoría de las actividades que se producen en su sistema, lo que contribuye a clasificar y solucionar a tiempo los problemas. Las prácticas recomendadas en [SEC04 («¿Cómo detecta e investiga los eventos de seguridad?»)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) proporcionan orientación para implementar este control.
+  **Usar la automatización:** gracias a la automatización, se pueden resolver los incidentes oportunamente y a escala. AWS proporciona varios servicios para automatizar en el contexto de la estrategia de respuesta ante incidentes. Céntrese en encontrar un equilibrio adecuado entre la automatización y la intervención manual. A medida que crea su respuesta a incidentes en guías de estrategias y runbooks, automatice los pasos repetibles. Use servicios de AWS como Administrador de incidentes de AWS Systems Manager para [resolver los incidentes de TI más rápidamente](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/). Use [herramientas para desarrolladores](https://aws.amazon.com/devops/) a fin de proporcionar control de versiones y automatizar [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) y los despliegues de infraestructura como código (IaC) sin intervención humana. Donde sea aplicable, automatice la detección y la evaluación de la conformidad mediante servicios administrados como Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, AWS Config y Amazon Macie. Optimice las capacidades de detección con machine learning como Amazon DevOps Guru para detectar problemas de patrones de funcionamiento anómalos antes de que se produzcan. 
+  **Realice un análisis de la causa raíz y actuar sobre las lecciones aprendidas:** implemente mecanismos para aprovechar las lecciones aprendidas como parte de una revisión de la respuesta ante incidentes. Cuando la causa raíz de un incidente revela un defecto mayor, un fallo de diseño, una configuración errónea o la posibilidad de que se repita, se clasifica como un problema. En estos casos, analice y resuelva el problema para minimizar la interrupción de las operaciones normales. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Security Incident Response Guide (Guía de respuesta ante incidentes de seguridad de AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: guía de administración de incidentes de seguridad informática ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **Vídeos relacionados:** 
+  [Automating Incident Response and Forensics in AWS (Automatización de la respuesta ante incidentes y el análisis forense en AWS) ](https://youtu.be/f_EcwmmXkXk)
+ [ DIY guide to runbooks, incident reports, and incident response (Guía paso a paso sobre runbooks, informes de incidentes y respuesta a incidentes) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment (Cómo prepararse y responder ante incidentes de seguridad en el entorno de AWS) ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Ejemplos relacionados:** 
+  [Laboratorio: Guía de estrategias de respuesta ante incidentes con Jupyter (AWS IAM)](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ Laboratorio: Respuesta ante incidentes con la consola de AWS y la CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP03: Preparar capacidades forenses
<a name="sec_incident_response_prepare_forensic"></a>

 Es importante que los equipos de intervención de incidentes comprendan cuándo y cómo deben hacer uso de la investigación forense en su plan de respuesta. Su organización debe definir las pruebas que deben recopilarse y las herramientas que deben utilizarse en el proceso. Identifique y prepare las capacidades de investigación forense disponibles, como los especialistas externos, las herramientas y la automatización. Una decisión clave que debe tomar de forma anticipada es si recopilará datos de un sistema activo. Algunos datos, como el contenido de la memoria volátil o las conexiones de red activas, se perderán si el sistema se apaga o se reinicia. 

El equipo de respuesta puede combinar herramientas, tales como AWS Systems Manager, Amazon EventBridge y AWS Lambda, para ejecutar automáticamente herramientas forenses en un sistema operativo y en una creación de reflejo de tráfico de VPC para obtener una captura del paquete de red y recopilar pruebas no persistentes. Lleve a cabo otras actividades, como análisis de registros o de imágenes de disco, en una cuenta de seguridad dedicada con herramientas y estaciones de trabajo forenses personalizadas a las que pueden acceder los equipos de intervención.

Envíe periódicamente registros pertinentes a un almacén de datos con alta durabilidad e integridad. Los equipos de intervención deben tener acceso a estos registros. AWS ofrece varias herramientas que pueden facilitar la investigación de registros, como, por ejemplo, Amazon Athena, Amazon OpenSearch Service (OpenSearch Service) y Amazon CloudWatch Logs Insights. Asimismo, conserve las pruebas de forma segura mediante Amazon Simple Storage Service (Amazon S3) Object Lock. Este servicio sigue el modelo WORM (escribir una vez, leer muchas veces) e impide que se eliminen o se sobrescriban objetos durante un periodo definido. Dado que las técnicas de investigación forense requieren formación especializada, puede que tenga que interactuar con especialistas externos.

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Medio 

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Identificar capacidades forenses: investigue las capacidades de investigación forense de su organización, las herramientas disponibles y los especialistas externos. 
+  [Automatización de la respuesta ante incidentes y el análisis forense ](https://youtu.be/f_EcwmmXkXk)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cómo automatizar la recopilación de discos forenses en AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 

# SEC10-BP04: Automatización de la capacidad de contención
<a name="sec_incident_response_auto_contain"></a>

Automatice la contención y la recuperación de un incidente para reducir los tiempos de respuesta y el impacto en la organización. 

Una vez que haya creado y practicado los procesos y herramientas de las guías de estrategias, puede deconstruir la lógica en una solución basada en código, que numerosos equipos de intervención pueden usar como herramienta para automatizar la respuesta y eliminar la varianza o las conjeturas. Esto puede agilizar el ciclo de vida de una respuesta. El próximo objetivo es habilitar este código para que sea totalmente automatizado y que las propias alertas o eventos puedan invocarlo, en lugar de tener que recurrir a la intervención humana, para crear una respuesta basada en eventos. Estos procesos también deben añadir automáticamente datos relevantes para los sistemas de seguridad. Por ejemplo, un incidente relacionado con el tráfico de una dirección IP no deseada puede rellenar automáticamente una lista de direcciones IP bloqueadas WAF de AWS o un grupo de reglas de Network Firewall para evitar posibles actividades.

![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)


*Figura 3: Bloqueo automatizado por parte de AWS WAF de direcciones IP malintencionadas*

Con un sistema de respuesta basado en eventos, un mecanismo de detección desencadena un mecanismo de respuesta para corregir el evento de forma automática. Puede utilizar capacidades de respuesta basadas en eventos para reducir el tiempo entre los mecanismos de detección y los de respuesta. Para crear esta arquitectura basada en eventos, puede utilizar AWS Lambda, que es un servicio de computación sin servidor que ejecuta el código en respuesta a eventos y gestiona automáticamente los recursos de computación subyacentes. Por ejemplo, supongamos que tiene una cuenta de AWS con el servicio AWS CloudTrail habilitado. Si alguna vez se llega a deshabilitar AWS CloudTrail (a través de la llamada a la API `cloudtrail:StopLogging` ), podrá utilizar Amazon EventBridge para supervisar el evento específico de `cloudtrail:StopLogging` e invocar una función de AWS Lambda para llamar a `cloudtrail:StartLogging` con el fin de reiniciar el registro. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Automatice la capacidad de contención. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Guía de respuesta ante incidentes de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Vídeos relacionados:** 
+  [Cómo prepararse y responder ante incidentes de seguridad en el entorno de AWS](https://youtu.be/8uiO0Z5meCs) 

# SEC10-BP05: Aprovisionamiento previo del acceso
<a name="sec_incident_response_pre_provision_access"></a>

Verifique que ha aprovisionado previamente el acceso correcto a los equipos de intervención de incidentes en AWS para reducir el tiempo necesario de investigación hasta la recuperación.

 **Patrones comunes de uso no recomendados:** 
+  Uso de la cuenta raíz para la respuesta ante incidentes. 
+  Alterar las cuentas de usuario existentes. 
+  Manipular los permisos de IAM directamente al proporcionar un aumento puntual de los privilegios. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

AWS recomienda reducir o eliminar la dependencia de credenciales de larga duración siempre que sea posible, en favor de credenciales temporales y mecanismos de aumento *puntual* de escalada de privilegios. Las credenciales de larga duración están expuestas a riesgos de seguridad y aumentan la carga operativa. Para la mayoría de las tareas de administración, así como para las de respuesta ante incidentes, le recomendamos que implemente la [federación de identidades](https://docs.aws.amazon.com/identity/federation/) junto con el [escalado temporal del acceso administrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). En este modelo, un usuario solicita el aumento a un nivel superior de privilegios (como un rol de respuesta ante incidentes) y, siempre que el usuario reúna los requisitos para el aumento, se envía una solicitud a un aprobador. Si la solicitud es aprobada, el usuario recibe un conjunto de [credenciales de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) temporales que puede usar para completar sus tareas. Una vez que caducan estas credenciales, el usuario debe enviar una nueva solicitud de aumento.

 Recomendamos el uso del escalado temporal de privilegios en la mayoría de las situaciones de respuesta ante incidentes. La forma correcta de hacerlo es utilizar el [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) y [políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) para definir el alcance del acceso. 

 Hay situaciones en las que las identidades federadas no están disponibles; por ejemplo: 
+  Interrupción relacionada con un proveedor de identidades (IdP) comprometido. 
+  Una configuración deficiente o un error humano provocan la ruptura del sistema de administración de acceso federado. 
+  Actividad maliciosa como un evento de denegación de servicio distribuido (DDoS) o un sistema no disponible. 

 En los casos anteriores, debe haber un acceso *inmediato* de emergencia configurado para permitir la investigación y la reparación puntual de los incidentes. También le recomendamos que utilice un [usuario de IAM con los permisos adecuados](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) para realizar tareas y acceder a los recursos de AWS. Utilice las credenciales del usuario raíz solo para [tareas que requieren el acceso del usuario raíz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Para verificar que los equipos de intervención de incidentes disponen del nivel correcto de acceso a AWS y otros sistemas pertinentes, recomendamos el aprovisionamiento previo de cuentas de usuario exclusivas. Las cuentas de usuario requieren un acceso con privilegios y se deben controlar y supervisar de forma estricta. Las cuentas deben crearse con el menor número de privilegios requeridos para realizar las tareas necesarias y el nivel de acceso debe basarse en las guías de estrategias creadas como parte del plan de administración de incidentes. 

 La práctica recomendada es crear usuarios y roles personalizados y exclusivos. El hecho de escalar temporalmente el acceso de los usuarios o de los roles mediante la incorporación de políticas de IAM provoca que no esté claro qué acceso tenían los usuarios durante el incidente y se corre el riesgo de que los privilegios escalados no se revoquen. 

 Es importante eliminar tantas dependencias como sea posible para verificar que se puede acceder en el mayor número posible de escenarios de error. Como medida de apoyo, cree una guía de estrategias para verificar que los usuarios de respuesta ante incidentes se crean como usuarios de AWS Identity and Access Management en una cuenta de seguridad exclusiva y no se administran a través de una federación existente o una solución de inicio de sesión único (SSO). Cada miembro del equipo de intervención debe tener su propia cuenta con nombre. La configuración de la cuenta debe aplicar una [política de contraseñas seguras](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) y la autenticación multifactor (MFA). Si las guías de estrategias de respuesta ante incidentes solo requieren acceso a la Consola de administración de AWS, el usuario no debería tener configuradas las claves de acceso y se le debería prohibir explícitamente la creación de claves de acceso. Esto se puede configurar con políticas de IAM o políticas de control de servicios (SCP) como se menciona en las prácticas recomendadas de seguridad de AWS para [SCP de AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Los usuarios solo deben tener el privilegio de poder asumir roles de respuesta ante incidentes en otras cuentas. 

 Durante un incidente, podría ser necesario conceder acceso a otras personas internas o externas para respaldar las actividades de investigación, reparación o recuperación. En este caso, utilice el mecanismo de guía de estrategias mencionado anteriormente. Debe haber un proceso para verificar que cualquier acceso adicional se revoque inmediatamente después de que finalice el incidente. 

 Para verificar que el uso de los roles de respuesta ante incidentes se puede supervisar y auditar de forma adecuada, es esencial que las cuentas de usuario de IAM creadas para este fin no se compartan con otras personas y que el usuario raíz de Cuenta de AWS no se utilice a menos que [se requiera para una tarea específica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Si el usuario raíz es necesario (por ejemplo, no está disponible el acceso de IAM a una cuenta específica), utilice un proceso aparte con una guía de estrategias disponible para verificar la disponibilidad de la contraseña y el token MFA del usuario raíz. 

 Para configurar las políticas de IAM de los roles de respuesta ante incidentes, utilice [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) para generar políticas basadas en los registros de AWS CloudTrail. Para ello, conceda acceso de administrador al rol de respuesta ante incidentes en una cuenta que no sea de producción y ejecute las guías de estrategias. Una vez completado, se puede crear una política que únicamente permita las acciones realizadas. Esta política se puede aplicar a los roles de respuesta ante incidentes en todas las cuentas. Es recomendable crear una política de IAM independiente para cada guía de estrategias a fin de facilitar la administración y la auditoría. Entre los ejemplos de guías de estrategias se podrían incluir planes de respuesta para ransomware, vulneraciones de datos, pérdida de acceso a la producción y otras situaciones. 

 Utilice las cuentas de usuario de respuesta ante incidentes para asumir los [roles de IAM de respuesta ante incidentes exclusivas en otras Cuentas de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Estos roles se deben configurar para que solo puedan asumirlos los usuarios de la cuenta de seguridad. La relación de confianza debe requerir que la entidad principal de llamada se haya autenticado mediante MFA. Los roles deben utilizar políticas de IAM de ámbito estricto para controlar el acceso. Asegúrese de que todas las solicitudes `AssumeRole` para estos roles estén registradas en CloudTrail y se haya alertado de ellas y que se registre cualquier acción realizada con estos roles. 

 Se recomienda que tanto las cuentas de usuario de IAM como los roles de IAM tengan nombres claros para poder encontrarlos fácilmente en los registros de CloudTrail. Un ejemplo sería asignar a las cuentas de IAM el nombre `<ID_USUARIO>-BREAK-GLASS` y los roles de IAM `BREAK-GLASS-ROLE`. 

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) se utiliza para registrar la actividad de API en sus cuentas de AWS y debe utilizarse para [configurar alertas sobre el uso de los roles de respuesta ante incidentes](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Consulte la publicación del blog sobre la configuración de alertas cuando se utilizan claves de usuario raíz. Las instrucciones se pueden modificar para configurar la métrica [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) filtro a filtro en los eventos `AssumeRole` relacionados con el rol IAM de respuesta ante incidentes: 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<ARN_DE_ROL_DE_RESPUESTA_ANTE_INCIDENTES>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 Como es probable que los roles de respuesta ante incidentes tengan un nivel de acceso alto, es importante que estas alertas lleguen a un grupo amplio y se actúe con rapidez. 

 Durante un incidente, es posible que un miembro del equipo de intervención necesite acceder a sistemas que no están directamente protegidos por IAM. Pueden ser instancias de Amazon Elastic Compute Cloud, bases de datos de Amazon Relational Database Service o plataformas de software como servicio (SaaS). Se recomienda que en lugar de utilizar protocolos nativos como SSH o RDP, se use [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) para todos los accesos administrativos a las instancias de Amazon EC2. Este acceso se puede controlar mediante IAM, que es seguro y está auditado. También se podrían automatizar partes de sus guías de estrategias mediante [documentos de AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), lo que puede reducir los errores del usuario y mejorar el tiempo de recuperación. Para el acceso a las bases de datos y a las herramientas de terceros, recomendamos almacenar las credenciales de acceso en AWS Secrets Manager y conceder el acceso a los roles de equipos de intervención ante incidentes. 

 Por último, la administración de las cuentas de usuario de IAM de respuesta ante incidentes debe agregarse a sus [procesos de incorporación, traslado y abandono de los empleados](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) y revisarse y probarse periódicamente para verificar que solo se permite el acceso previsto. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Managing temporary elevated access to your AWS environment (Administrar el acceso de alto nivel temporal al entorno de AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (Guía de respuesta ante incidentes de seguridad de AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [Administrador de incidentes de AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [Setting an account password policy for IAM users (Establecer una política de contraseñas de cuenta para los usuarios de IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [Using multi-factor authentication (MFA) in AWS (Uso de la autenticación multifactor [MFA] en AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (Configuración del acceso entre cuentas con MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Uso de IAM Access Analyzer para generar políticas de IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Prácticas recomendadas para las políticas de control de servicios de AWS Organizations en un entorno de varias cuentas) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Cómo recibir notificaciones cuando se utilizan las claves de acceso raíz de su cuenta de AWS) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Crear permisos de sesión detallados mediante políticas administradas de IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **Vídeos relacionados:** 
+ [ Automating Incident Response and Forensics in AWS (Automatización de la respuesta ante incidentes y el análisis forense en AWS) ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [DIY guide to runbooks, incident reports, and incident response (Guía paso a paso sobre runbooks, informes de incidentes y respuesta a incidentes)](https://youtu.be/E1NaYN_fJUo) 
+ [ Prepare for and respond to security incidents in your AWS environment (Cómo prepararse y responder ante incidentes de seguridad en el entorno de AWS) ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Ejemplos relacionados:** 
+ [ Laboratorio: Configuración de la cuenta y usuario raíz de AWS](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Laboratorio: Respuesta ante incidentes con la consola de AWS y la CLI ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06: Implementar previamente herramientas
<a name="sec_incident_response_pre_deploy_tools"></a>

 Asegúrese de que se hayan implementado previamente las herramientas correctas en AWS para que el personal de seguridad pueda reducir el tiempo de investigación hasta la recuperación. 

Con el fin de automatizar las funciones de operaciones e ingeniería de seguridad, puede utilizar un conjunto completo de API y herramientas de AWS. Puede automatizar totalmente las capacidades de administración de identidades, seguridad de red, protección de datos y supervisión, y ofrecerlas con métodos de desarrollo de software populares que ya tenga establecidos. Al crear procesos de automatización de seguridad, su sistema podrá supervisar, revisar e iniciar una respuesta en lugar de tener a empleados supervisando el nivel de seguridad y reaccionando manualmente ante eventos. Una forma eficaz de proporcionar automáticamente datos de registros que se pueden buscar y relevantes en los servicios de AWS a los equipos de intervención de incidentes es habilitar [Amazon Detective](https://aws.amazon.com/detective/).

Si los equipos de intervención de incidentes siguen respondiendo a alertas de la misma forma, corren el riesgo de sufrir fatiga causada por un número excesivo de alertas. Con el paso del tiempo, el equipo puede llegar a no reaccionar ante las alertas y puede incluso cometer errores durante la gestión de situaciones habituales o pasar por alto alertas inusuales. La automatización ayuda a evitar este problema mediante el uso de funciones que procesan alertas repetitivas y habituales, dejando a las personas que gestionen incidentes únicos y delicados. La integración de sistemas de detección de anomalías, como, por ejemplo, Amazon GuardDuty, AWS CloudTrail Insights y Amazon CloudWatch Anomaly Detection, puede reducir la carga de alertas comunes basadas en umbrales.

Puede mejorar los procesos manuales mediante la automatización en forma programática de los pasos del proceso. Después de definir el patrón de solución de un evento, puede descomponer dicho patrón en lógica procesable y escribir el código para llevar a cabo dicha lógica. A continuación, los equipos de intervención pueden ejecutar dicho código para solucionar el problema. Con el paso del tiempo, puede automatizar cada vez más pasos y, en última instancia, gestionar automáticamente todas las clases de incidentes comunes.

En el caso de las herramientas que se ejecutan en el sistema operativo de la instancia de Amazon Elastic Compute Cloud (Amazon EC2), debe realizar una evaluación con Run Command de AWS Systems Manager, lo que le permite administrar de forma remota y segura instancias con un agente que instale en el sistema operativo de la instancia de Amazon EC2. Requiere el uso de Systems Manager Agent (SSM Agent), que está instalado de forma predeterminada en numerosas imágenes de máquina de Amazon (AMI). No obstante, tenga en cuenta que una vez que una instancia se haya visto afectada, no se deben considerar fiables las respuestas de las herramientas o de los agentes que se ejecuten en ella.

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo 

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Implementar previamente las herramientas: asegúrese de que se hayan implementado previamente las herramientas correctas en AWS para que el personal de seguridad pueda dar una respuesta adecuada a un incidente. 
  +  [Laboratorio: Respuesta ante incidentes con Consola de administración de AWS y CLI ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
  + [ Guía de estrategias de respuesta ante incidentes con Jupyter (AWS IAM) ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
  +  [ Automatización de seguridad de AWS](https://github.com/awslabs/aws-security-automation)
+  Implementar el etiquetado de recursos: etiquete recursos con información, como un código para el recurso que se encuentra en proceso de investigación, para que pueda identificar recursos durante un incidente. 
  + [ Estrategias de etiquetado de AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [ Guía de respuesta ante incidentes de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

 **Vídeos relacionados:** 
+  [ Guía autogestionada para runbooks, informes de incidentes y repuesta ante incidentes ](https://youtu.be/E1NaYN_fJUo)

# SEC10-BP07 Ejecutar los días de juego
<a name="sec_incident_response_run_game_days"></a>

Los días de juego, también conocidos como simulaciones o ejercicios, son eventos internos que proporcionan una oportunidad estructurada para practicar sus planes y procedimientos de administración de incidentes durante una situación realista. Estos eventos deben ejercitar a los intervinientes con las mismas herramientas y técnicas que se utilizarían en una situación real, incluso con la imitación de entornos reales. Los días de juego consisten fundamentalmente en estar preparado y mejorar de forma iterativa su capacidad de respuesta. Algunos de los motivos por los que puede encontrar valor en la realización de las actividades de los días de juego son: 
+ Validación de la preparación
+ Desarrollo de la confianza: aprender de las simulaciones y formar al personal
+ Cumplimiento de las obligaciones de conformidad o contractuales
+ Generación de artefactos para la acreditación
+ Agilidad: mejora incremental
+ Aumento de la velocidad y mejora de las herramientas
+ Perfeccionamiento de la comunicación y el traslado a una instancia superior
+ Desarrollo de la comodidad con lo raro y lo inesperado

Por estos motivos, el valor derivado de la participación en una actividad de simulación aumenta la eficacia de una organización durante los eventos estresantes. El desarrollo de una actividad de simulación que sea a la vez realista y beneficiosa puede ser un ejercicio difícil. Aunque probar sus procedimientos o la automatización que gestiona eventos bien entendidos tiene ciertas ventajas, es igual de valioso participar en actividades de [simulaciones de respuesta a incidencias de seguridad (SIRS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) creativas para probarse ante lo inesperado y mejorar continuamente.

Cree simulaciones personalizadas adaptadas a su entorno, equipo y herramientas. Encuentre un problema y diseñe su simulación en torno a él. Puede tratarse de algo como una credencial filtrada, un servidor que se comunica con sistemas no deseados o una configuración errónea que da lugar a una exposición no autorizada. Designe a ingenieros que conozcan su organización para crear la situación y a otro grupo para que participe. La situación debe ser lo suficientemente realista y desafiante como para que sea valiosa. Debe incluir la oportunidad de ponerse manos a la obra con el registro, las notificaciones, los traslados a una instancia superior y la ejecución de runbooks o la automatización. Durante la simulación, los intervinientes deben ejercitar sus competencias técnicas y organizativas y los líderes deben participar para desarrollar sus competencias de administración de incidentes. Al final de la simulación, celebre los esfuerzos del equipo y busque formas de iterar, repetir y ampliar en otras simulaciones.

[AWS ha creado plantillas de runbook de respuesta a incidentes](https://github.com/aws-samples/aws-incident-response-playbooks) que puede utilizar no solo para preparar sus acciones de respuesta, sino también como base para una simulación. A la hora de planificar, una simulación puede dividirse en cinco fases.

**Obtención de pruebas: **en esta fase, un equipo recibirá alertas a través de diversos medios, como un sistema interno de tickets, alertas de herramientas de supervisión, denuncias anónimas o incluso noticias públicas. Los equipos comienzan a revisar los registros de la infraestructura y de las aplicaciones para determinar el origen del peligro. Este paso también debería incluir los traslados internos a instancias superiores y el liderazgo de incidentes. Una vez identificado, los equipos pasan a contener el incidente

**Contención del incidente: **los equipos habrán determinado que ha habido un incidente y establecido el origen del peligro. Los equipos ahora deben tomar medidas para contenerlo, por ejemplo, mediante la desactivación de las credenciales en peligro, el aislamiento de un recurso de computación o la revocación del permiso de un rol.

**Erradicación del incidente: **ahora que han contenido el incidente, los equipos trabajarán para mitigar cualquier vulnerabilidad en las aplicaciones o en las configuraciones de la infraestructura que han sido susceptibles de estar en peligro. Esto podría incluir la rotación de todas las credenciales utilizadas para una carga de trabajo, la modificación de las listas de control de acceso (ACL) o el cambio de las configuraciones de red.

**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Ejecutar [días de juego](https://wa.aws.amazon.com/wat.concept.gameday.en.html): ejecute eventos [de respuesta a](https://wa.aws.amazon.com/wat.concept.incident.en.html) incidentes [simulados (días de juego)](https://wa.aws.amazon.com/wat.concept.event.en.html) para diferentes amenazas que implican al personal clave y a los directivos. 
+  Capture las lecciones aprendidas: las lecciones aprendidas al ejecutar [días de juego](https://wa.aws.amazon.com/wat.concept.gameday.en.html) debe formar parte de un bucle de comentarios para mejorar sus procesos. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+ [ Guía de respuesta ante incidentes de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) 

 **Vídeos relacionados:** 
+ [ Guía autogestionada para runbooks, informes de incidentes y repuesta ante incidentes ](https://youtu.be/E1NaYN_fJUo)