# Proceso Desarrollar procesos de respuesta ante incidentes exhaustivos y claramente definidos es clave para que el programa de respuesta ante incidentes sea satisfactorio y escalable. Cuando se produce un evento de seguridad, tener unos pasos y flujos de trabajo claros puede lo ayudará a responder a tiempo. Es posible que ya tenga un proceso de respuesta ante incidentes. Independientemente de su estado actual, es importante actualizar, iterar y probar sus procesos de respuesta a incidentes con regularidad. # Desarrollo y prueba de un plan de respuesta ante incidentes El primer documento que se desarrolla para la respuesta ante incidentes es el *plan de respuesta ante incidentes*. El plan de respuesta a incidentes está diseñado para ser la base de su programa y estrategia de respuesta a incidentes. Un plan de respuesta ante incidentes es un documento de alto nivel que normalmente incluye estas secciones: + **Descripción general del equipo de respuesta ante incidentes**: describe los objetivos y las funciones del equipo de respuesta ante incidentes. + **Roles y responsabilidades**: enumera las partes interesadas de la respuesta ante incidentes y detalla sus roles cuando se produce un incidente. + **Un plan de comunicación**: detalla la información de contacto y cómo se comunicará durante un incidente. 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](https://aws.amazon.com/wickr/). + **Fases de la respuesta ante incidentes y medidas que tomar**: se enumeran las fases de la respuesta ante incidentes (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. Deberá elaborar un plan de respuesta ante incidentes que mejor se adapte a su organización. # Documentación y centralización de los diagramas de arquitectura Para responder de forma rápida y precisa ante un incidente de seguridad, debe comprender la arquitectura de sus sistemas y redes. Comprender estos patrones internos no solo es importante para responder ante incidentes, sino también para verificar la coherencia entre las aplicaciones con las que se diseñan los patrones, de acuerdo con las prácticas recomendadas. También debe comprobar que esta documentación esté actualizada y se actualice periódicamente de acuerdo con los nuevos patrones de arquitectura. Debe desarrollar documentación y repositorios internos que detallen elementos como: + **Estructura de cuentas de AWS**: necesita saber: + ¿Cuántas cuentas de AWS tiene? + ¿Cómo están organizadas esas cuentas de AWS? + ¿Quiénes son los propietarios de la empresa de las cuentas de AWS? + ¿Utiliza políticas de control de servicio (SCP)? Si es así, ¿qué barreras de protección organizativas se implementan mediante las SCP? + ¿Limita las regiones y los servicios que se pueden usar? + ¿Qué diferencias hay entre las unidades de negocio y los entornos (desarrollo/pruebas/producción)? + **Patrones de servicio de AWS** + ¿Qué servicios de AWS utiliza? + ¿Cuáles son los servicios de AWS más utilizados? + **Patrones de arquitectura** + ¿Qué arquitecturas en la nube utiliza? + **Patrones de autenticación de AWS** + ¿Cómo se suelen autenticar los desarrolladores en AWS? + ¿Utiliza roles o usuarios de IAM (o ambos)? ¿Su autenticación en AWS está conectada a un proveedor de identidades (IdP)? + ¿Cómo asigna un rol o un usuario de IAM a un empleado o un sistema? + ¿Cómo se revoca el acceso cuando alguien ya no está autorizado? + **Patrones de autorización de AWS** + ¿Qué políticas de IAM utilizan sus desarrolladores? + ¿Utiliza políticas basadas en recursos? + **Registro y supervisión** + ¿Qué orígenes de registro utiliza y dónde se almacenan? + ¿Agrega los registros de AWS CloudTrail? Si es así, ¿dónde se almacenan? + ¿Cómo consulta los registros de CloudTrail? + ¿Ha activado Amazon GuardDuty? + ¿Cómo accede a los resultados de GuardDuty (por ejemplo, consola, sistema de tickets, SIEM)? + ¿Los resultados o eventos se agregan en un SIEM? + ¿Los tickets se crean automáticamente? + ¿Qué herramientas se utilizan para analizar los registros en una investigación? + **Topología de red** + ¿Cómo se organizan física o lógicamente los dispositivos, los puntos de conexión y las conexiones de su red? + ¿Cómo se conecta su red con AWS? + ¿Cómo se filtra el tráfico de red entre entornos? + **Infraestructura externa** + ¿Cómo se implementan las aplicaciones orientadas al exterior? + ¿Qué recursos de AWS son de acceso público? + ¿Qué cuentas de AWS contienen infraestructura orientada al exterior? + ¿Qué filtros de DDoS o externos existen? La documentación de los procesos y diagramas técnicos internos facilita el trabajo del analista de respuesta ante incidentes y lo ayuda a obtener rápidamente los conocimientos institucionales necesarios para responder a un incidente de seguridad. La documentación exhaustiva de los procesos técnicos internos no solo simplifica las investigaciones de seguridad, sino que también permite racionalizar y evaluar los procesos. # Desarrollo de sus manuales de estrategias de respuesta ante incidentes 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 una serie de 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. # ¿Para qué crear manuales de estrategias? 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 las alertas y los resultados de seguridad conocidos, como los resultados de GuardDuty. Podría recibir un resultado de GuardDuty y pensar: “¿Y ahora qué?”. Si desea evitar que un resultado de GuardDuty no se gestione del modo correcto, cree una manual de estrategias para cada posible resultado de GuardDuty. Puede encontrar información e instrucciones sobre los procesos de corrección en la [documentación de GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Conviene señalar que GuardDuty no está habilitado de forma predeterminada y que tiene un costo. Puede encontrar más detalles sobre GuardDuty en el Apéndice A: Definiciones de capacidades en la nube: [Visibilidad y alertas](visibility-and-alerting.md). # ¿Qué incluir en los manuales de estrategias? 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. Algunos de los elementos que deben incluirse en un manual de estrategias son los siguientes: + **Descripción general del manual de estrategias**: ¿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 y mecanismos de detección se necesitan en el escenario de este incidente? ¿Cuál es la notificación esperada? + **Información sobre las partes interesadas**: ¿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 ante 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 del manual de estrategias? Para comprobar que la información de cada manual de estrategias sea coherente, puede resultar útil crear una plantilla de manual de estrategias para utilizarla en los demás manuales de estrategias de seguridad. Algunos de los elementos enumerados anteriormente, como la información de las partes interesadas, se pueden compartir entre varios manuales de estrategias. Si ese es el caso, puede crear una documentación centralizada para esa información y hacer referencia a ella en el manual de estrategias y, a continuación, enumerar las diferencias explícitas en el manual. Esto evitará que tenga que actualizar la misma información en todos sus manuales de estrategias individuales. Al crear una plantilla e identificar la información común o compartida en los manuales de estrategias, puede simplificar y acelerar el desarrollo de estos. Por último, es probable que sus manuales de estrategias evolucionen con el tiempo; una vez que haya confirmado que los pasos son coherentes, estos forman los requisitos para la automatización. # Manuales de estrategias de ejemplo Puede encontrar varios manuales de estrategias de ejemplo en el Apéndice B en [Recursos de manuales de estrategias](appendix-b-incident-response-resources.md#playbook-resources). Los ejemplos que aparecen aquí se pueden usar como guía sobre qué manuales de estrategias crear y qué incluir en ellos. Sin embargo, es importante que elabore manuales de estrategias que incorporen los riesgos más pertinentes para su empresa. Debe verificar que los pasos y los flujos de trabajo de sus manuales de estrategias incluyan sus tecnologías y procesos. # Realización de simulaciones periódicas Las organizaciones crecen y evolucionan con el tiempo, al igual que el panorama de amenazas. Por este motivo, es importante revisar continuamente sus capacidades de respuesta ante incidentes. Ejecutar simulaciones 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. Las simulaciones tienen diversas ventajas, como, por ejemplo: + 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. # Tipos de simulaciones Hay tres tipos principales de simulaciones: + **Ejercicios prácticos**: el enfoque de los ejercicios prácticos consiste estrictamente 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 los roles 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. Debido a su naturaleza de 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; sin embargo, en este tipo de ejercicio no se hace un uso real de las herramientas o los guiones de respuesta ante 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*). Por lo general, 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 suele estar 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 del equipo rojo pueden ser pruebas invasivas, debe tener cuidado e implementar controles para verificar que el ejercicio no produzca un daño real en su entorno. **nota** AWS exige que los clientes revisen la política sobre pruebas de penetración, que está disponible en el [sitio web de pruebas de penetración](https://aws.amazon.com/security/penetration-testing/), antes de realizar los ejercicios de equipo morado y el equipo rojo. En la tabla 1 se resumen algunas de las principales diferencias entre estos tipos de simulaciones. Es importante tener en cuenta que, por lo general, las definiciones se consideran definiciones vagas y se pueden personalizar para adaptarlas a las necesidades de la organización. *Tabla 1: tipos de simulaciones* | | Ejercicio práctico | Ejercicio del equipo morado | Ejercicio del equipo rojo | | --- | --- | --- | --- | | Resumen | Ejercicios en papel que se centran en un escenario de incidente de seguridad específico. Estos pueden ser de alto nivel o técnicos y están impulsados por una serie de inyecciones en papel. | Una oferta más realista en comparación con los ejercicios prácticos. Durante los ejercicios del equipo morado, los facilitadores trabajan en colaboración con los participantes para aumentar su participación en el ejercicio y ofrecen formación cuando es necesario. | Por lo general, se trata de una oferta de simulación más avanzada. Suele haber un alto nivel de encubrimiento, por lo que es posible que los participantes no conozcan todos los detalles del ejercicio. | | Recursos necesarios | Recursos técnicos limitados requeridos | Se requieren diversas partes interesadas y un alto nivel de recursos técnicos | Se requieren diversas partes interesadas y un alto nivel de recursos técnicos | | Complejidad | Bajo | Medio | Alto | 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 del 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 del equipo rojo por su complejidad y su costo. # Ciclo de vida del ejercicio Independientemente del tipo de simulación que elija, las simulaciones suelen tener estos pasos: 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.