# Preparación
Prepararse para un incidente es fundamental para ofrecer una respuesta oportuna y eficaz ante el incidente. La preparación se hace en tres dominios:
+ **Personal**: la preparación del personal para un incidente de seguridad implica identificar a las partes interesadas pertinentes para la respuesta a los incidentes y capacitarlas en materia de respuesta ante incidentes y tecnologías en la nube.
+ **Procesos**: la preparación de los procesos para un incidente de seguridad implica documentar las arquitecturas, desarrollar planes exhaustivos de respuesta ante los incidentes y crear guías de estrategias para responder de manera coherente a los eventos de seguridad.
+ **Tecnología**: la preparación de la tecnología para un incidente de seguridad implica configurar el acceso, agregar y supervisar los registros necesarios, implementar mecanismos de alerta eficaces y desarrollar capacidades de respuesta e investigación.
Cada uno de estos dominios es igualmente importante para conseguir una respuesta eficaz ante los incidentes. Ningún programa de respuesta ante incidentes es completo o eficaz sin estos tres dominios. Debe preparar al personal, los procesos y la tecnología con una integración estrecha con el fin de estar preparado ante un incidente.
**Topics**
+ [SEC10-BP01 Identificación del personal clave y los recursos externos](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Desarrollo de planes de administración de incidentes](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Preparación de las capacidades forenses](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Desarrollo y prueba de manuales de estrategias de respuesta a incidentes de seguridad](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Aprovisionamiento previo del acceso](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Implementación de las herramientas con anticipación](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Ejecución de simulaciones](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identificación del personal clave y los recursos externos
Identifique las obligaciones legales, el personal y los recursos internos y externos que puedan ayudar a su organización a responder ante un incidente.
**Resultado deseado:** cuenta con una lista del personal clave, su información de contacto y las funciones que desempeñan al responder a un evento de seguridad. Revisa esta información con regularidad y la actualiza para reflejar los cambios de personal desde la perspectiva de las herramientas internas y externas. Al documentar esta información, tener en cuenta a todos los vendedores y proveedores de servicios externos, incluidos los socios de seguridad, los proveedores de nube y las aplicaciones de software como servicio (SaaS). Durante un evento de seguridad, disponer de personal con el nivel adecuado de responsabilidad, contexto y acceso para poder responder y recuperarse.
**Patrones comunes de uso no recomendados:**
+ No mantener una lista actualizada del personal clave con información de contacto, sus cargos y responsabilidades al responder a los eventos de seguridad.
+ Dar por sentada una comprensión general de las personas, las dependencias, la infraestructura y las soluciones pertinentes a la hora de responder a un evento y recuperarse de él.
+ No contar con un repositorio de documentos o conocimientos relacionados con la infraestructura clave o el diseño de aplicaciones.
+ No disponer de procesos de incorporación adecuados para que los nuevos empleados contribuyan de manera eficaz a la respuesta a un evento de seguridad, como llevar a cabo simulacros de eventos.
+ No disponer de una ruta de escalado para los casos en los que el personal clave no esté disponible temporalmente o no responda durante los eventos de seguridad.
**Beneficios de establecer esta práctica recomendada:** esta práctica reduce el tiempo de clasificación y respuesta que se dedica a identificar al personal adecuado y sus funciones durante un evento. También disminuye al mínimo la pérdida de tiempo durante un evento, ya que mantiene una lista actualizada del personal clave y sus cargos, de modo que pueda recurrir a las personas adecuadas para la clasificación y la recuperación de un evento.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
**Identificación del personal clave de la organización:** mantenga una lista de contactos del personal de su organización al que necesitaría involucrar. Revise y actualice periódicamente esta información en caso de que se produzcan cambios de personal, como cambios organizativos, ascensos y cambios en el equipo. Esto es especialmente importante para los puestos clave, como los administradores de incidentes, el personal de respuesta a incidentes y el líder de comunicaciones.
+ **Administrador de incidentes:** los administradores de incidentes tienen la autoridad general durante la respuesta al evento.
+ **Personal de respuesta a incidentes:** el personal de respuesta a incidentes es el responsable de las actividades de investigación y corrección. Estas personas pueden variar según el tipo de evento, pero suelen ser desarrolladores y miembros de los equipos de operaciones responsables de la aplicación afectada.
+ **Líder de comunicaciones:** el líder de comunicaciones es responsable de las comunicaciones internas y externas, especialmente las destinadas a agencias públicas, organismos reguladores y clientes.
+ **Proceso de incorporación:** forme e incorpore periódicamente a nuevos empleados a fin de que adquieran las habilidades y los conocimientos necesarios para contribuir de manera eficaz a los esfuerzos de respuesta a incidentes. Incorpore simulaciones y ejercicios prácticos como parte del proceso de incorporación para facilitar su preparación.
+ **Expertos en la materia (SME):** en el caso de equipos distribuidos y autónomos, le recomendamos que identifique un SME para las cargas de trabajo críticas. Ofrecen información sobre el funcionamiento y la clasificación de datos de las cargas de trabajo críticas relacionadas con el evento.
Formato de tabla de ejemplo:
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
Plantéese el uso de la característica [Administrador de incidentes de AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para determinar los contactos clave, definir un plan de respuesta, automatizar horarios de guardia y crear planes de escalado. Automatice y rote a todo el personal según un horario de guardias, de modo que la responsabilidad de la carga de trabajo se comparta entre los responsables de esta. Esto fomenta las prácticas recomendadas, como la creación de métricas y registros relevantes, y también la definición de los umbrales de alarma pertinentes para la carga de trabajo.
**Identificación de los socios externos:** las empresas utilizan herramientas creadas por proveedores de software independientes (ISV), socios y subcontratistas con el fin de desarrollar soluciones diferenciadoras para sus clientes. Implique al personal clave de estos colectivos que pueda ayudarle a responder y recuperarse de un incidente. Le recomendamos que se registre en el nivel adecuado de Soporte para poder acceder rápidamente a expertos en la materia de AWS a través de un caso de soporte. Plantéese la posibilidad de establecer acuerdos similares con todos los proveedores de soluciones críticas para las cargas de trabajo. Algunos eventos de seguridad requieren que las empresas que coticen en bolsa notifiquen el evento y sus impactos a los organismos públicos y entidades normativas pertinentes. Mantenga y actualice la información de contacto de los departamentos pertinentes y las personas responsables.
## Pasos para la implementación
1. Configure una solución de administración de incidentes.
1. Piense en implementar el Administrador de incidentes en su cuenta de Security Tooling.
1. Defina los contactos en su solución de administración de incidentes.
1. Defina al menos dos tipos de canales de contacto para cada contacto (como SMS, teléfono o correo electrónico) para garantizar la accesibilidad durante un incidente.
1. Defina un plan de respuesta.
1. Identifique los contactos más apropiados para interactuar durante un incidente. Defina planes de escalado alineados con los cargos del personal al que se va a recurrir, en lugar de con los contactos individuales. Considere la posibilidad de incluir contactos que puedan ser responsables de informar a entidades externas, incluso aunque no participen directamente en la resolución del incidente.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**Documentos relacionados:**
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Ejemplos relacionados:**
+ [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Prepare for and respond to security incidents in your AWS environment](https://youtu.be/8uiO0Z5meCs)
**Herramientas relacionadas:**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**Videos relacionados:**
+ [Amazon's approach to security during development](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 Desarrollo de planes de administración de incidentes
El primer documento que se desarrolla para la respuesta a incidentes es el plan de respuesta a incidentes. El plan de respuesta a incidentes está diseñado para ser la base de su programa y estrategia de respuesta a incidentes.
**Beneficios de establecer esta práctica recomendada:** desarrollar procesos de respuesta a incidentes exhaustivos y claramente definidos es clave para que el programa de respuesta a incidentes sea satisfactorio y escalable. Cuando se produce un evento de seguridad, tener unos pasos y flujos de trabajo claros puede ayudarle a responder a tiempo. Es posible que ya tenga procesos de respuesta a incidentes. Independientemente de su estado actual, es importante actualizar, iterar y probar sus procesos de respuesta a incidentes con regularidad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Un plan de administración de incidentes es fundamental para responder y mitigar el impacto potencial de los incidentes de seguridad, así como de cara a la recuperación. 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 en las instalaciones. 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, siga las recomendaciones de 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 que almacenan información de identificación personal (PII), plantéese cómo proteger y responder a los problemas relacionados con la residencia y el uso de datos.
Al crear un plan de administración de incidentes para sus cargas de trabajo en AWS, comience con el [Modelo de responsabilidad compartida de AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) para crear un enfoque de defensa en profundidad para la respuesta a los incidentes. En este modelo, AWS administra la seguridad de la nube y el cliente 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 [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, lo que le permite mantenerse 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.
### Pasos para la implementación
1. Defina las funciones y responsabilidades dentro de su organización para gestionar los eventos de seguridad. Aquí debería incluir a los representantes de varios departamentos, entre los que se incluyen:
+ Recursos humanos (RR. HH.)
+ Equipo ejecutivo
+ Departamento legal
+ Propietarios y desarrolladores de aplicaciones (expertos en la materia o SME)
1. Describa con claridad quién es responsable, encargado, consultado e informado (RACI) durante un incidente. Cree un diagrama RACI para facilitar una comunicación rápida y directa, y describa claramente el liderazgo en las diferentes etapas de un evento.
1. Incluya a los propietarios y desarrolladores de aplicaciones (SME) durante un incidente, ya que pueden proporcionar información y contexto que resultan valiosos para ayudar a medir el impacto. Entable relación con estos SME y practique con ellos escenarios de respuesta a incidentes antes de que se produzca un incidente real.
1. Incluya a socios de confianza o expertos externos en el proceso de investigación o de respuesta, ya que pueden ofrecer una mayor experiencia y amplitud de miras.
1. Acompase sus planes y funciones de administración de incidentes a cualquier normativa o requisito de cumplimiento local por los que se rija su organización.
1. Practique y pruebe sus planes de respuesta a incidentes con regularidad e incluya a todos los roles y responsabilidades definidos. Esto ayuda a agilizar el proceso y a verificar que se cuenta con una respuesta coordinada y eficiente a los incidentes de seguridad.
1. Revise y actualice los roles, las responsabilidades y el diagrama RACI periódicamente o a medida que cambien la estructura organizativa o los requisitos.
**Información sobre los equipos de asistencia y respuesta de AWS**
+ **AWS Support**
+ [Soporte](https://aws.amazon.com/premiumsupport/) ofrece una serie de planes que proporcionan acceso a herramientas y conocimientos que contribuyen al éxito y la salud operativa de sus soluciones de AWS. Si necesita asistencia técnica y más recursos para planificar, implementar y optimizar su entorno de AWS, puede seleccionar el plan de asistencia que mejor se adapte a su caso de uso de AWS.
+ Piense en el [Centro de soporte](https://console.aws.amazon.com/support) de Consola de administración de AWS (es necesario iniciar sesión) como punto de contacto central para obtener asistencia en caso de problemas que afecten a sus recursos de AWS. El acceso a Soporte está controlado por AWS Identity and Access Management. Para obtener más información sobre el acceso a las características de Soporte, consulte [Introducción a Soporte](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **AWS Equipo de respuesta a incidentes de clientes (CIRT) de)**
+ El equipo de respuesta a incidentes de clientes (CIRT) de AWS es un equipo global de AWS especializado que ofrece asistencia a los clientes las 24 horas del día y los 7 días de la semana durante eventos de seguridad activos en el lado del cliente del [Modelo de responsabilidad compartida de AWS](https://aws.amazon.com/compliance/shared-responsibility-model/).
+ Cuando el CIRT de AWS le ofrece asistencia, le ayuda en la clasificación y la recuperación de un evento de seguridad activo en AWS. Puede ayudarle a analizar la causa raíz mediante el uso de registros de servicio de AWS y ofrecerle recomendaciones para la recuperación. También puede proporcionar recomendaciones de seguridad y prácticas recomendadas para ayudarle a evitar eventos de seguridad en el futuro.
+ Los clientes de AWS pueden interactuar con el CIRT de AWS a través de un [caso de Soporte](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ Anunciado en re:Invent 2024, Respuesta frente a incidencias de seguridad de AWS es un servicio administrado de respuesta a incidentes de seguridad que utiliza tanto tecnología moderna de clasificación como intervención humana. El servicio recopila todos los resultados de GuardDuty y cualquier resultado de terceros enviado para su clasificación, con el fin de alertar al cliente solo sobre los resultados que requieren una investigación. El servicio también proporciona un portal para enviar casos reactivos en caso de que el cliente detecte un incidente de seguridad y recibir asistencia del equipo avanzado de respuesta a incidentes de AWS.
+ **Asistencia en respuestas a DDoS**
+ AWS ofrece [AWS Shield](https://aws.amazon.com/shield/), que ofrece un servicio administrado de protección contra ataques de denegación de servicio distribuidos (DDoS) que protege las aplicaciones web que se ejecutan en AWS. Shield proporciona una mitigación en línea automática y detección siempre activa que puede minimizar el tiempo de inactividad y la latencia de la aplicación, por lo que no es necesario disponer de Soporte para beneficiarse de la protección DDoS. Hay dos capas de Shield: AWS Shield Standard y AWS Shield Advanced. Para conocer las diferencias entre estos dos niveles, consulte la [documentación de características de Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) proporciona una administración continua de su infraestructura de AWS para que pueda centrarse en sus aplicaciones. Mediante la implementación de prácticas recomendadas para mantener su infraestructura, AMS le ayuda a reducir la carga y el riesgo operativos. AMS automatiza actividades comunes, como solicitudes de cambios, supervisión, administración de parches, seguridad y servicios de copia de seguridad, y ofrece servicios de ciclo de vida completo para aprovisionar, ejecutar y brindar soporte a su infraestructura.
+ AMS asume la responsabilidad de implementar un conjunto de controles de detección de seguridad y proporciona una primera línea de respuesta a las alertas las 24 horas del día y los 7 días de la semana. Cuando se inicia una alerta, AMS sigue un conjunto estándar de guías automáticas y manuales para verificar una respuesta coherente. Estas guías de estrategias se comparten con los clientes de AMS durante la incorporación para que puedan desarrollar y coordinar una respuesta con AMS.
**Desarrollo del plan de respuesta a incidentes**
El plan de respuesta a incidentes está diseñado para ser la base de su programa y estrategia de respuesta a incidentes. El plan de respuesta a incidentes debe figurar en un documento formal. Un plan de respuesta a incidentes suele incluir las siguientes secciones:
+ **Descripción general del equipo de respuesta a incidentes:** describe los objetivos y las funciones del equipo de respuesta a incidentes.
+ **Funciones y responsabilidades:** enumera las partes interesadas de la respuesta a los incidentes y detalla sus funciones cuando se produce un incidente.
+ **Un plan de comunicación:** detalla la información de contacto y cómo se comunica durante un incidente.
+ **Métodos de comunicación auxiliares:** se recomienda tener un método de comunicación auxiliar fuera de banda para informar de los incidentes. Un ejemplo de una aplicación que proporciona un canal de comunicaciones fuera de banda seguro es AWS Wickr.
+ **Fases de la respuesta a un incidente y medidas que tomar:** se enumeran las fases de la respuesta a un incidente (por ejemplo, detección, análisis, erradicación, contención y recuperación), incluidas las medidas de alto nivel que se deben tomar en esas fases.
+ **Definiciones de gravedad y priorización del incidente:** detalla cómo clasificar la gravedad de un incidente, cómo priorizar el incidente y, a continuación, cómo las definiciones de gravedad afectan a los procedimientos de escalamiento.
Aunque estas secciones son comunes en empresas de diferentes tamaños y de diferentes sectores, el plan de respuesta a incidentes de cada organización es único. Debe elaborar un plan de respuesta a incidentes que mejor se adapte a su organización.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC04 Detección](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documentos relacionados:**
+ [AWS Security Incident Response Guide](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)
# SEC10-BP03 Preparación de las capacidades forenses
Antes de que se produzca un incidente de seguridad, considere la posibilidad de desarrollar capacidades forenses que lo ayuden a investigar los eventos de seguridad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
Los conceptos de la ciencia forense tradicional que se utiliza en el entorno en las instalaciones también son aplicables a AWS. Para obtener información sobre cómo comenzar a desarrollar capacidades forenses en la Nube de AWS, consulte [Forensic investigation environment strategies in the Nube de AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/).
Una vez que haya configurado la estructura del entorno y la Cuenta de AWS para el análisis forense, defina las tecnologías necesarias para ejecutar de forma eficaz unas metodologías sólidas desde el punto de vista forense en las cuatro fases:
+ **Recopilación:** recopile registros de AWS pertinentes, como los registros de AWS CloudTrail, AWS Config, de flujo de VPC y de nivel de host. Siempre que sea posible, recopile instantáneas, copias de seguridad y volcados de memoria de los recursos de AWS afectados.
+ **Examen:** examine los datos recopilados mediante la extracción y la evaluación de la información importante.
+ **Análisis:** analice los datos recopilados para comprender el incidente y sacar conclusiones.
+ **Informes:** presente la información resultante de la fase de análisis.
## Pasos para la implementación
**Preparación del entorno forense**
[AWS Organizations](https://aws.amazon.com/organizations/) le permite administrar y gestionar un entorno de AWS de forma centralizada a medida que aumentan y se escalan los recursos de AWS. Una organización de AWS se encarga de agrupar las cuentas de Cuentas de AWS para que pueda administrarlas como una sola unidad. Puede utilizar unidades organizativas para agrupar las cuentas que desee administrar como una sola unidad.
Para la respuesta a incidentes, es útil contar con una estructura de Cuenta de AWS que respalde las funciones de respuesta ante incidentes, lo que incluye una *OU de seguridad* y una *OU forense*. Dentro de la unidad organizativa de seguridad, debe tener cuentas para:
+ **Archivo de registros:** agregue los registros en una Cuenta de AWS de archivo de registros con permisos limitados.
+ **Herramientas de seguridad:** centralice los servicios de seguridad en una Cuenta de AWS de herramientas de seguridad. Esta cuenta funciona como un administrador delegado de los servicios de seguridad.
Dentro de la unidad organizativa forense, tiene la opción de implementar una o varias cuentas forenses diferentes para cada una de las regiones en las que opera, en función de lo que le venga mejor a su modelo empresarial y operativo. Si crea una cuenta forense para cada región, puede impedir que se creen recursos de AWS fuera de esa región y reducir el riesgo de que esos recursos se copien en una región no deseada. Por ejemplo, si solo opera en la región Este de EE. UU. (Norte de Virginia) (`us-east-1`) y Oeste de EE. UU. (Oregón) (`us-west-2`), tendría dos cuentas en la unidad organizativa forense: una para `us-east-1` y otra para `us-west-2`.
Puede crear una Cuenta de AWS forense para varias regiones. Debe tener cuidado al copiar los recursos de AWS en esa cuenta y asegurarse de que cumple los requisitos de soberanía de datos. Dado que aprovisionar nuevas cuentas lleva tiempo, es imperativo crear e instrumentar las cuentas forenses mucho antes de que se produzca un incidente para que los responsables puedan estar preparados y utilizarlas eficazmente en su respuesta.
En el siguiente diagrama, se muestra un ejemplo de una estructura de cuentas que incluye una unidad organizativa forense con cuentas forenses para cada región:
![\[Diagrama de flujo en el que se muestra una estructura de cuentas por región para la respuesta a incidentes que se divide en una unidad organizativa de seguridad y una unidad organizativa de análisis forense.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**Captura de copias de seguridad e instantáneas**
Crear copias de seguridad de los principales sistemas y bases de datos es fundamental para poder recuperarse de un incidente de seguridad y para fines forenses. Con las copias de seguridad, puede restaurar los sistemas a su estado seguro anterior. En AWS, puede crear instantáneas de diversos recursos. Las instantáneas le proporcionan copias de seguridad puntuales de esos recursos. Hay muchos servicios de AWS que pueden ayudarle con la copia de seguridad y la recuperación. Para obtener más detalles sobre estos servicios y enfoques de copia de seguridad y recuperación, consulte la [Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) y [Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Es esencial que las copias de seguridad estén bien protegidas, especialmente en ciertas situaciones, como el ransomware. Para obtener información sobre cómo proteger las copias de seguridad, consulte [Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Además de proteger las copias de seguridad, debe probar periódicamente los procesos de copia de seguridad y restauración para comprobar que la tecnología y los procesos que tiene implementados funcionan según lo previsto.
**Automatización de los análisis forenses**
Durante un evento de seguridad, es necesario que el equipo de respuesta a incidentes pueda recopilar y analizar las pruebas rápidamente y, al mismo tiempo, mantener la precisión durante todo el tiempo que rodee al evento (por ejemplo, capturar registros relacionados con un evento o recurso específico, o recopilar un volcado de memoria de una instancia de Amazon EC2). Para el equipo de respuesta a incidentes, resulta difícil y lleva mucho tiempo recopilar manualmente las pruebas pertinentes, especialmente en una gran cantidad de instancias y cuentas. Además, la recopilación manual puede ser más propensa a errores humanos. Por estas razones, debe desarrollar e implementar la automatización del análisis forense en la medida que sea posible.
AWS ofrece una serie de recursos de automatización para el análisis forense, que se enumeran en la sección de recursos. Estos recursos son ejemplos de patrones forenses que hemos desarrollado y que los clientes han implementado. Aunque pueden resultar útiles como arquitectura de referencia al empezar, valore la posibilidad de modificarlos o crear nuevos patrones de automatización forense en función del entorno, los requisitos, las herramientas y los procesos forenses.
## Recursos
**Documentos relacionados:**
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the Nube de AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [AWS Prescriptive Guidance - Automate incident response and forensics ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**Videos relacionados:**
+ [ Automating Incident Response and Forensics ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**Ejemplos relacionados:**
+ [ Automated Incident Response and Forensics Framework ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Automated Forensics Orchestrator for Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 Desarrollo y prueba de manuales de estrategias de respuesta a incidentes de seguridad
Una parte esencial de la preparación de los procesos de respuesta a incidentes consiste en desarrollar manuales de estrategias. Los manuales de estrategias de respuesta a incidentes ofrecen directrices y pasos prescriptivos que deben seguirse cuando se produce un evento de seguridad. Contar con una estructura y unos pasos claros simplifica la respuesta y reduce la probabilidad de que se produzcan errores humanos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Deben crearse guías estratégicas para escenarios de incidentes, como, por ejemplo:
+ **Incidentes esperados**: deben crearse manuales de estrategias para los incidentes que anticipe. Esto puede incluir amenazas como la denegación de servicio (DoS), el ransomware y las amenazas de las credenciales.
+ **Alertas o resultados de seguridad conocidos:** deben crearse manuales de estrategias para abordar las alertas y los resultados de seguridad conocidos, como los resultados de Amazon GuardDuty. Cuando reciba un resultado de GuardDuty, el manual debería incluir medidas claras para evitar que la alerta se gestione mal o se ignore. Para obtener más información y orientación sobre las soluciones, consulte [Corrección de problemas de seguridad detectados por GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html).
Las guías estratégicas deben incluir los pasos técnicos que los analistas de seguridad deben completar para investigar y responder adecuadamente a un posible incidente de seguridad.
El equipo de respuesta a incidentes del cliente (CIRT) de AWS ha publicado un [repositorio de GitHub que contiene manuales de estrategias de respuesta ante incidentes](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs) organizados por recurso, tipo y situación de amenaza. Estos manuales de estrategias se pueden adaptar para alinearlos con sus procedimientos de respuesta a incidentes existentes o servir como base para desarrollar otros nuevos.
### Pasos para la implementación
Algunos de los elementos que deben incluirse en un manual de estrategias son los siguientes:
+ **Descripción general de la guía estratégica**: ¿qué escenario de riesgo o incidente se aborda en este manual de estrategias? ¿Cuál es el objetivo del manual de estrategias?
+ **Requisitos previos**: ¿qué registros, mecanismos de detección y herramientas automatizadas se necesitan en el escenario de este incidente? ¿Cuál es la notificación esperada?
+ **Información sobre la comunicación y la información de escalado**: ¿quiénes participan y cuál es su información de contacto? ¿Cuáles son las responsabilidades de cada una de las partes interesadas?
+ **Medidas de respuesta**: en las diferentes fases de respuesta a un incidente, ¿qué medidas tácticas se deben tomar? ¿Qué consultas deben ejecutar los analistas? ¿Qué código debe ejecutarse para lograr el resultado deseado?
+ **Detección**: ¿cómo se va a detectar el incidente?
+ **Análisis**: ¿cómo se va a determinar el alcance del impacto?
+ **Contención**: ¿cómo se va a aislar el incidente para limitar el alcance?
+ **Erradicación**: ¿cómo se va a eliminar la amenaza del entorno?
+ **Recuperación**: ¿cómo se va a conseguir que el sistema o recurso afectado vuelva a ser productivo?
+ **Resultados esperados**: después de ejecutar las consultas y el código, ¿cuál es el resultado esperado de la guía estratégica?
## Recursos
**Prácticas recomendadas de Well-Architected relacionadas:**
+ [SEC10-BP02 Desarrollo de planes de administración de incidentes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**Documentos relacionados:**
+ [Framework for Incident Response Playbooks](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Develop your own Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Incident Response Playbook Samples](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 Aprovisionamiento previo del acceso
Verifique que haya 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:**
+ Usar la cuenta raíz para la respuesta ante incidentes.
+ Alterar las cuentas 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
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 los 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 tareas de respuesta ante incidentes, le recomendamos que implemente la [federación de identidades](https://aws.amazon.com/identity/federation/) junto con el [escalado temporal para el 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 se aprueba la solicitud, el usuario recibe un conjunto de [credenciales de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) temporales que puede utilizar 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 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) y las [políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) para limitar el 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 de emergencia *break glass* configurado para permitir la investigación y la reparación oportuna de los incidentes. Se recomienda utilizar un [usuario, grupo o rol con los permisos adecuados](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) para llevar a cabo tareas y acceder a los recursos de AWS. Utilice el usuario raíz únicamente para llevar a cabo [tareas que requieran credenciales de 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 exclusivas. Las cuentas 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 llevar a cabo 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 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 IAM creadas para este fin no se compartan con otras personas y que el Usuario raíz de la cuenta de AWS no se utilice a menos que [se requiera para tareas específicas](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 las credenciales de inicio de sesión y el token MFA del usuario raíz.
Para configurar las políticas de IAM para los roles de respuesta ante incidentes, considere la posibilidad de utilizar el [Analizador de acceso de IAM](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 hechas. 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 manual de estrategias a fin de facilitar la administración y la auditoría. Entre los ejemplos de manuales 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 respuesta ante incidentes para asumir los [roles de IAM dedicados de respuesta ante incidentes 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 de `AssumeRole` para estos roles estén registradas en CloudTrail y se haya alertado de ellas y que se registre cualquier acción hecha con estos roles.
Se recomienda que tanto las cuentas 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 `-BREAK-GLASS` y a 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 la API en sus cuentas de AWS y debe usarse para [configurar alertas sobre el uso de las funciones 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 de [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) de filtro a filtro en los eventos de `AssumeRole` relacionados con el rol de IAM de respuesta ante incidentes:
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.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. Puede tratarse de instancias de Amazon Elastic Compute Cloud, bases de datos de Amazon Relational Database Service o plataformas de software como servicio (SaaS). Se recomienda encarecidamente que, en lugar de utilizar protocolos nativos como SSH o RDP, [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) se utilice 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 es posible automatizar partes de sus guías de estrategias mediante [documentos de ejecución de comandos de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), lo que puede reducir los errores de los usuarios 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 gestión de las cuentas de IAM de respuesta ante incidentes debe agregarse a sus [procesos de incorporación, traslado y abandono](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html), así como revisarse y probarse periódicamente para comprobar que solo se permite el acceso previsto.
## Recursos
**Documentos relacionados:**
+ [Managing temporary elevated access to your AWS environment](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [AWS Security Incident Response Guide ](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)
+ [Configuración de una política de contraseñas de la cuenta para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Uso de autenticación multifactor (MFA) en AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [ Configuring Cross-Account Access with 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 ](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 ](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 ](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 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Videos relacionados:**
+ [ Automating Incident Response and Forensics in AWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo)
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 Implementación de las herramientas con anticipación
Asegúrese de que el personal de seguridad implementa las herramientas correctas con anticipación para reducir el plazo de investigación hasta conseguir la recuperación.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Para automatizar las funciones de operaciones y de respuesta de seguridad, puede utilizar un completo conjunto de API y herramientas de AWS. Puede automatizar totalmente las funcionalidades de administración de identidades, seguridad de red, protección de datos y supervisión, y hacer que estén disponibles a través de métodos de desarrollo de software populares que ya tenga establecidos. Al crear procesos de automatización de seguridad, el sistema podrá supervisar, revisar e iniciar una respuesta, y no necesitará empleados que supervisen el nivel de seguridad y reaccionen manualmente a los eventos.
Si los equipos de intervención de incidentes siguen respondiendo a alertas de la misma forma, corren el riesgo de fatigarse por el excesivo número de alertas. Con el paso del tiempo, el equipo puede llegar a no reaccionar ante las alertas e incluso cometer errores durante la gestión de situaciones habituales o pasar por alto alertas inusuales. La automatización ayuda a evitar este problema con funciones que procesan alertas repetitivas y habituales, dejando a las personas que gestionen los incidentes extraordinarios y delicados. La integración de sistemas de detección de anomalías, como Amazon GuardDuty, AWS CloudTrail Insights y Detección de anomalías de Amazon CloudWatch, puede reducir la carga de alertas comunes basadas en umbrales.
Puede mejorar los procesos manuales automatizando los pasos del proceso mediante programación. Después de definir el patrón de solución de un evento, puede descomponer dicho patrón en una lógica procesable y escribir el código que ejecute dicha lógica. A continuación, los equipos de intervención pueden ejecutar ese 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.
Durante una investigación de seguridad, necesitará poder revisar los registros correspondientes para registrar y comprender todo el alcance y la cronología del incidente. También necesita los registros para generar alertas que indican que se han producido determinadas acciones de interés. Es fundamental seleccionar, habilitar, almacenar y configurar mecanismos de consulta y recuperación, así como de alerta. Además, una forma eficaz de proporcionar herramientas para buscar datos de registro es usar [Amazon Detective](https://aws.amazon.com/detective/).
AWS tiene a su disposición más de 200 servicios en la nube y miles de características. Le recomendamos que revise los servicios que pueden respaldar y simplificar su estrategia de respuesta a incidentes.
Además de los registros, debe desarrollar e implementar una [estrategia de etiquetado](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). El etiquetado puede ayudarle a proporcionar contexto en relación con el propósito de un recurso de AWS. El etiquetado también se puede utilizar en la automatización.
### Pasos para la implementación
**Selección y configuración de registros de análisis y alertas**
Consulte la siguiente documentación sobre la configuración de registros para la respuesta a incidentes:
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 Configuración del registro de servicios y aplicaciones](sec_detect_investigate_events_app_service_logging.md)
**Activación de los servicios de seguridad para respaldar la detección y la respuesta**
AWS ofrece funcionalidades de detección, prevención y respuesta, y se pueden utilizar otros servicios para diseñar soluciones de seguridad personalizadas. Para obtener una lista de los servicios más relevantes para la respuesta a incidentes de seguridad, consulte [Definiciones de capacidades en la nube](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html) y la [página de inicio de Respuesta a un incidente de seguridad](https://aws.amazon.com/security-incident-response/).
**Desarrollo e implementación de una estrategia de etiquetado**
Puede resultar difícil obtener información contextual sobre el caso de uso empresarial y las partes interesadas internas pertinentes en relación con un recurso de AWS. Una forma de hacerlo es mediante etiquetas, que asignan metadatos a los recursos de AWS y se componen de una clave y un valor definidos por el usuario. Puede crear etiquetas para clasificar los recursos en función de su propósito, propietario, entorno, tipo de datos procesados y otros criterios de su elección.
Una estrategia de etiquetado coherente puede acelerar los tiempos de respuesta y minimizar el tiempo que se invierte en el contexto de la organización al permitirle identificar y discernir rápidamente la información contextual sobre un recurso de AWS. Las etiquetas también pueden servir como un mecanismo para iniciar automatizaciones de respuesta. Para obtener más información sobre qué etiquetar, consulte [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Primero tendrá que definir las etiquetas que desea implementar en toda la organización. Después, implementará y hará cumplir la estrategia de etiquetado. Para obtener más información sobre la implementación y el cumplimiento, consulte [Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs).](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)
## Recursos
**Prácticas recomendadas de Well-Architected relacionadas:**
+ [SEC04-BP01 Configuración del registro de servicios y aplicaciones](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Recopilación de registros, resultados y métricas en ubicaciones estandarizadas](sec_detect_investigate_events_logs.md)
**Documentos relacionados:**
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Definiciones de las capacidades de la nube de respuesta ante incidentes ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**Ejemplos relacionados:**
+ [ Threat Detection and Response with Amazon GuardDuty and Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub Workshop ](https://catalog.workshops.aws/security)
+ [ Vulnerability Management with Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 Ejecución de simulaciones
Las organizaciones crecen y evolucionan con el tiempo, pero también las amenazas, por lo que es importante que revise continuamente sus capacidades de respuesta a los incidentes. Ejecutar simulaciones (también conocidas como días de juego) es un buen método para llevar a cabo esta evaluación. En las simulaciones, se utilizan escenarios de eventos de seguridad reales diseñados para imitar las tácticas, técnicas y procedimientos (TTP) del actor de una amenaza y permiten a la organización probar y evaluar sus capacidades de respuesta a los incidentes respondiendo a estos simulacros de ataques cibernéticos tal y como podría ocurrir en la realidad.
**Beneficios de establecer esta práctica recomendada:** las simulaciones ofrecen una serie de beneficios:
+ Comprobar si se está preparado para un ataque cibernético y mejorar la confianza de los equipos de respuesta a los incidentes.
+ Probar la precisión y la eficiencia de las herramientas y los flujos de trabajo.
+ Perfeccionar los métodos de comunicación y escalamiento en consonancia con su plan de respuesta a incidentes.
+ Ofrecer la oportunidad de responder a vectores menos comunes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Hay tres tipos principales de simulaciones:
+ **Ejercicios prácticos:** el enfoque de los ejercicios prácticos consiste en llevar a cabo una sesión de debate en la que participen las diversas partes interesadas en la respuesta a los incidentes para practicar las funciones y responsabilidades y utilizar las herramientas de comunicación y los manuales de estrategia establecidos. Por lo general, este ejercicio se puede hacer durante un día completo en un lugar virtual o físico, o bien en una combinación de ambos. Como se trata de un debate, el ejercicio de simulación se centra en los procesos, las personas y la colaboración. La tecnología forma parte integral del debate, pero en este tipo de ejercicio no se hace un uso real de las herramientas o los guiones de respuesta a incidentes.
+ **Ejercicios del equipo morado:** los ejercicios del equipo morado aumentan el nivel de colaboración entre las personas que se encargan de la respuesta a los incidentes (equipo azul) y los actores de las amenazas simuladas (equipo rojo). El equipo azul está compuesto por miembros del centro de operaciones de seguridad (SOC), pero también puede incluir a otras partes interesadas que participarían durante un ataque cibernético real. El equipo rojo está compuesto por un equipo de pruebas de penetración o partes interesadas clave que cuentan con formación en seguridad ofensiva. El equipo rojo trabaja en colaboración con los facilitadores del ejercicio para diseñar un escenario que sea preciso y factible. Durante los ejercicios del equipo morado, la atención se centra en los mecanismos de detección, las herramientas y los procedimientos operativos estándar (SOP) que facilitan las iniciativas de respuesta a los incidentes.
+ **Ejercicios del equipo rojo:** durante un ejercicio del equipo rojo, el atacante (equipo rojo) hace una simulación para lograr un determinado objetivo o conjunto de objetivos desde un ámbito predeterminado. Los defensores (equipo azul) no conocen necesariamente el ámbito y la duración del ejercicio; de esta manera, se consigue una evaluación más realista de cómo responderían ante un incidente real. Dado que los ejercicios de equipo rojo pueden ser pruebas invasivas, tenga cuidado e implemente controles para verificar que el ejercicio no produzca un daño real en su entorno.
Considere la posibilidad de llevar a cabo simulaciones de ataques cibernéticos con regularidad. Cada tipo de ejercicio puede aportar ventajas únicas para los participantes y la organización en su conjunto, por lo que puede optar por empezar con tipos de simulaciones menos complejos (como los ejercicios prácticos) y pasar luego a los más complejos (ejercicios de equipo rojo). El tipo de simulación se debe elegir en función de su nivel de madurez en seguridad, sus recursos y los resultados deseados. Es posible que algunos clientes opten por no llevar a cabo los ejercicios de equipo rojo por su complejidad y su costo.
## Pasos para la implementación
Independientemente del tipo de simulación que elija, las simulaciones suelen tener estos pasos de implementación:
1. **Definición de los elementos básicos del ejercicio:** defina el escenario de simulación y los objetivos de la simulación. Ambos deben contar con la aceptación de los directivos.
1. **Identificación de las principales partes interesadas:** como mínimo, en un ejercicio debe haber facilitadores y participantes. En función del escenario, podrían participar otras partes interesadas, como los directivos del departamento legal, de comunicaciones o ejecutivo.
1. **Creación y prueba del escenario:** es posible que sea necesario redefinir el escenario a medida que se crea si algunos elementos específicos no son factibles. Se espera que, al final de esta etapa, haya un escenario definitivo.
1. **Facilitación de la simulación:** el tipo de simulación determina la forma de llevarla a cabo (un escenario en papel o un escenario simulado muy técnico). Los facilitadores deben adaptar sus tácticas de facilitación a los objetivos del ejercicio y, siempre que sea posible, involucrar a todos los participantes del ejercicio para obtener la mayor ventaja.
1. **Desarrollo del informe posterior a la acción (AAR):** identifique las áreas que funcionaron bien, las que pueden mejorar y las posibles carencias. El AAR debe medir la eficacia de la simulación, así como la respuesta del equipo al evento simulado, de modo que se pueda seguir su progreso a lo largo del tiempo con futuras simulaciones.
## Recursos
**Documentos relacionados:**
+ [Guía de respuestas ante incidentes de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Videos relacionados:**
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs)
+ [Running effective security incident response simulations](https://www.youtube.com/watch?v=63EdzHT25_A)