# Análisis Análisis Los registros, las capacidades de consulta y la inteligencia de amenazas son algunos de los componentes de apoyo necesarios en la fase de análisis. Muchos de los mismos registros que se utilizan para la detección también se utilizan para el análisis y requerirán la incorporación y configuración de las herramientas de consulta. # Validación, determinación del alcance y evaluación del impacto de la alerta Validación, determinación del alcance y evaluación del impacto de la alerta Durante la fase de análisis, se realiza un análisis exhaustivo del registro con el objetivo de validar las alertas, definir su alcance y evaluar el impacto de la posible interrupción. + La *validación* de la alerta es el punto de partida de la fase de análisis. Los encargados de responder a los incidentes buscarán entradas de registro procedentes de diversos orígenes y se pondrán en contacto directamente con los responsables de la carga de trabajo afectada. + El siguiente paso es *determinar el alcance*, cuando se haría un inventario de todos los recursos involucrados y se ajustaría el nivel de gravedad de las alertas una vez que las partes interesadas están de acuerdo en que es poco probable que se trate de un falso positivo. + Por último, en el *análisis de impacto* se detalla la verdadera interrupción para la empresa. Una vez identificados los componentes de la carga de trabajo afectados, los resultados del análisis del alcance se pueden correlacionar con el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) de la carga de trabajo correspondiente, ajustándose al nivel de gravedad de la alerta, lo que iniciará la asignación de recursos y toda la actividad que tendrá lugar a continuación. No todos los incidentes interrumpirán directamente las operaciones de una carga de trabajo que respalda un proceso empresarial. Es posible que incidentes como la divulgación de información confidencial, el robo de propiedad intelectual o el secuestro de recursos (como en el caso de la minería de criptomonedas) no detengan ni debiliten un proceso empresarial de forma inmediata, pero pueden tener consecuencias en el futuro. # Enriquecimiento de los registros y resultados de seguridad Enriquecimiento de los registros y resultados de seguridad ## Enriquecimiento con inteligencia de amenazas y contexto organizativo Enriquecimiento con inteligencia de amenazas y contexto organizativo Durante el transcurso del análisis, es necesario enriquecer los elementos observados de interés para mejorar la contextualización de la alerta. Como se indica en la sección de preparación, integrar y aprovechar la inteligencia de ciberamenazas puede resultar útil para comprender mejor un resultado de seguridad. Los servicios de inteligencia de amenazas se utilizan para asignar reputación y atribuir la propiedad a las direcciones IP públicas, los nombres de dominio y los hashes de archivo. Estas herramientas están disponibles como servicios de pago y gratuitos. Los clientes que adoptan Amazon Athena como herramienta de consulta de registros obtienen la ventaja de los trabajos de AWS Glue para cargar la información de inteligencia de amenazas en forma de tablas. Las tablas de inteligencia de amenazas se pueden utilizar en consultas SQL para correlacionar elementos del registro, como direcciones IP y nombres de dominio, lo que proporciona una visión enriquecida de los datos que se van a analizar. AWS no proporciona inteligencia de amenazas directamente a los clientes, pero servicios como Amazon GuardDuty utilizan la inteligencia de amenazas para el enriquecimiento y la generación de resultados. También puede cargar listas de amenazas personalizadas en GuardDuty basadas en su propia inteligencia de amenazas. ## Enriquecimiento con automatización Enriquecimiento con automatización La automatización es una parte integral de la gobernanza en la Nube de AWS. Se puede utilizar en las distintas fases del ciclo de vida de la respuesta ante incidentes. Para la fase de detección, la automatización basada en reglas compara los patrones de interés del modelo de amenazas en los registros y toma las medidas adecuadas, como el envío de notificaciones. La fase de análisis permite aprovechar el mecanismo de detección y reenviar el cuerpo de la alerta a un motor capaz de consultar los registros y enriquecer los elementos observados para contextualizar el evento. El cuerpo de la alerta, en su forma fundamental, está compuesto por un *recurso* y una *identidad*. Por ejemplo, podría implementar una automatización para consultar en CloudTrail las actividades de las API de AWS que realizó la identidad o el recurso del organismo de la alerta en el momento de la alerta, lo que proporcionaría información adicional, como `eventSource`, `eventName`, `SourceIPAddress` y `userAgent` de la actividad de la API identificada. Al realizar estas consultas de forma automatizada, los respondedores pueden ahorrar tiempo durante la clasificación y obtener un contexto adicional que les ayude a tomar decisiones mejor fundamentadas. Consulte la publicación en el blog [How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) para ver un ejemplo sobre cómo utilizar la automatización para enriquecer los resultados de seguridad y simplificar el análisis. # Recopilación y análisis de las pruebas forenses Recopilación y análisis de las pruebas forenses La ciencia forense, como se menciona en la sección [Preparación](preparation.md) de este documento, es el proceso de recopilar y analizar artefactos durante la respuesta ante incidentes. En AWS, esto se aplica a los recursos del dominio de infraestructura, como las capturas de paquetes de tráfico de red o el volcado de memoria del sistema operativo, y a los recursos del dominio de servicio, como los registros de AWS CloudTrail. El proceso forense tiene las siguientes características fundamentales: + **Coherente**: sigue los pasos exactos documentados, sin desviaciones. + **Repetible**: produce exactamente los mismos resultados cuando se repite en el mismo artefacto. + **Común**: está documentado públicamente y se ha adoptado ampliamente. Es importante mantener una cadena de custodia para los artefactos recolectados durante la respuesta ante incidentes. La automatización y la generación automática de la documentación de esta colección pueden ayudar, además del almacenamiento de los artefactos en repositorios de solo lectura. El análisis solo debe realizarse en réplicas exactas de los artefactos recopilados para mantener la integridad. # Recolección de artefactos pertinentes Recolección de artefactos pertinentes Teniendo en cuenta estas características y en función de las alertas pertinentes y de la evaluación del impacto y el alcance, tendrá que recopilar los datos que sean pertinentes para continuar la investigación y el análisis. Existen diversos tipos y orígenes de datos que pueden ser pertinentes para la investigación, como los registros del plano de control o de servicio (CloudTrail, eventos de datos de Amazon S3, registros de flujo de VPC), datos (metadatos y objetos de Amazon S3) y recursos (bases de datos o instancias de Amazon EC2). Los registros del plano de control o de servicio se pueden recopilar para analizarlos localmente o, idealmente, se pueden consultar directamente mediante servicios nativos de AWS (cuando proceda). Los datos (incluidos los metadatos) se pueden consultar directamente para obtener información pertinente o para adquirir los objetos de origen; por ejemplo, utilice la AWS CLI para adquirir metadatos de objetos y buckets de Amazon S3 y adquirir directamente los objetos de origen. Los recursos deben recopilarse de manera coherente con el tipo de recurso y el método de análisis previsto. Por ejemplo, las bases de datos se pueden recopilar creando una copia o instantánea del sistema que ejecuta la base de datos, creando una copia o instantánea de toda la base de datos en sí o consultando y extrayendo ciertos datos y registros de la base de datos pertinentes para la investigación. En el caso de las instancias de Amazon EC2, hay un conjunto específico de datos que se deben recopilar y un orden específico de recopilación que se debe seguir para adquirir y conservar la mayor cantidad de datos para su análisis e investigación. En concreto, el orden de respuesta para adquirir y conservar la mayor cantidad de datos de una instancia de Amazon EC2 es el siguiente: 1. **Adquirir metadatos de la instancia**: adquiera los metadatos de la instancia pertinente para la investigación y las consultas de datos (ID de instancia, tipo, dirección IP, ID de VPC/subred, región, ID de imagen de máquina de Amazon (AMI), grupos de seguridad adjuntos, hora de lanzamiento). 1. **Habilitar las protecciones y etiquetas de las instancias**: habilite las protecciones de las instancias, como la protección contra terminación, configure el comportamiento de apagado para que se detenga (si está configurado para terminarse), deshabilite los atributos “Delete on Termination” de los volúmenes de EBS adjuntos y aplique las etiquetas adecuadas tanto para la denotación visual como para su uso en posibles automatizaciones de respuesta (por ejemplo, al aplicar una etiqueta con el nombre `Status` y el valor `Quarantine`, realizar una adquisición forense de datos y aislar la instancia). 1. **Adquirir el disco (instantáneas de EBS)**: adquiera una instantánea de EBS de los volúmenes de EBS adjuntos. Cada instantánea contiene información necesaria para restaurar los datos (del momento en que se tomó) en un volumen de EBS nuevo. Consulte el paso para realizar una recopilación de artefactos o respuestas en vivo si utiliza volúmenes de almacén de instancias. 1. **Adquirir memoria**: dado que las instantáneas de EBS solo capturan los datos que se han escrito en su volumen de Amazon EBS, lo que podría excluir los datos que las aplicaciones o el sistema operativo almacenan o guardan en caché en la memoria, es imprescindible adquirir una imagen de memoria del sistema mediante una herramienta comercial o de código abierto de terceros adecuada para obtener los datos disponibles del sistema. 1. **(Opcional) Realizar una recopilación de artefactos o una respuesta en vivo**: realice una recopilación de datos específica (disco/memoria/registros) mediante una respuesta en vivo en el sistema únicamente si no se puede adquirir el disco o la memoria de otra manera, o si existe un motivo empresarial u operativo válido. Con ello, se modificarán datos y artefactos valiosos del sistema. 1. **Retirar la instancia**: separe la instancia de los grupos de escalado automático, anule el registro de la instancia de los equilibradores de carga y ajuste o aplique un perfil de instancia prediseñado con permisos minimizados o sin permisos. 1. **Aísle o contenga la instancia**: compruebe que la instancia esté aislada de manera efectiva de otros sistemas y recursos del entorno. Para ello, finalice e impida las conexiones actuales y futuras de entrada y salida de la instancia. Para obtener más información, consulte la sección [Contención](containment.md) de este documento. 1. **Decisión del responsable**: en función de la situación y los objetivos, seleccione una de las siguientes opciones: + Retirar y apagar el sistema (recomendado). Cerrar el sistema una vez que se hayan adquirido las pruebas disponibles para verificar la mitigación más efectiva contra un posible impacto futuro en el entorno por parte de la instancia. + Continúe ejecutando la instancia en un entorno aislado instrumentado para el monitoreo. Aunque no se recomienda como enfoque estándar, si una situación justifica una observación continua de la instancia (por ejemplo, cuando se necesitan datos o más indicadores para realizar una investigación y un análisis exhaustivos de la instancia), podría considerar cerrar la instancia, crear una AMI de la instancia y volver a lanzar la instancia en su cuenta de análisis forenses dedicada dentro de un entorno de pruebas que esté preconfigurado para estar completamente aislado y configurado con instrumentación que facilite la supervisión casi continua de la instancia (por ejemplo, registros de flujo de VPC o duplicación de tráfico de VPC). **nota** Es esencial capturar la memoria antes de las actividades de respuesta en vivo o del aislamiento o apagado del sistema para capturar los datos volátiles (y valiosos) disponibles. # Desarrollo de narrativas Desarrollo de narrativas Durante el análisis y la investigación, documente las acciones tomadas, los análisis realizados y la información identificada, para utilizarlos en las fases posteriores y, en última instancia, en un informe final. Estas narrativas deben ser breves y precisas y debe asegurarse de que se incluya la información pertinente para verificar la comprensión efectiva del incidente y mantener una cronología precisa. También son útiles cuando interactúa con personas ajenas al equipo principal de respuesta ante incidentes. A continuación se muestra un ejemplo: **** *El departamento de marketing y ventas recibió una nota de rescate el 15 de marzo de 2022 en la que se exigía el pago en criptomonedas para evitar la divulgación pública de posible información confidencial. El SOC determinó que la base de datos de Amazon RDS perteneciente a marketing y ventas fue de acceso público el 20 de febrero de 2022. El SOC consultó los registros de acceso de RDS y determinó que la dirección IP 198.51.100.23 se utilizó el 20 de febrero de 2022 con las credenciales `mm03434`, pertenecientes a *Major Mary*, una de las desarrolladoras web. El SOC consultó los registros de flujo de VPC y determinó que aproximadamente 256 MB de datos salieron hacia la misma dirección IP en la misma fecha (marca de tiempo 2022-02-20T15:50\$100Z). El SOC determinó, mediante inteligencia de amenazas de código abierto, que las credenciales están disponibles actualmente en texto plano en el repositorio público `https[:]//example[.]com/majormary/rds-utils`.*