# Detección La alerta es el componente principal de la fase de detección. Genera una notificación para iniciar el proceso de respuesta ante incidentes en función de la actividad de amenazas de interés en la cuenta de AWS. La precisión de las alertas es un desafío; no siempre es posible determinar con total certeza si se ha producido un incidente, si está en curso o si ocurrirá en el futuro. Estas son algunas razones: + Los mecanismos de detección se basan en la desviación de la línea base, los patrones conocidos y la notificación de entidades internas o externas. + Debido a la naturaleza impredecible de la tecnología y las personas, que son *los medios* y *los actores* de los incidentes de seguridad, respectivamente, las líneas de base cambian con el tiempo. Los patrones maliciosos surgen a través de *tácticas*, *técnicas* y *procedimientos* (TTP) de los actores de amenazas novedosos o modificados. + Los cambios en las personas, la tecnología y los procesos no se incorporan inmediatamente al proceso de respuesta ante incidentes. Algunos se descubren durante el progreso de una investigación. # Orígenes de alertas Debería considerar la posibilidad de utilizar los siguientes orígenes para definir las alertas: + **Resultados**: los servicios de AWS como [Amazon GuardDuty](https://aws.amazon.com/guardduty/), [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), [Amazon Macie](https://aws.amazon.com/macie/), [Amazon Inspector](https://aws.amazon.com/inspector/), [AWS Config](https://aws.amazon.com/config/), el [Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) y el [Analizador de acceso a la red](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) generan resultados que se pueden utilizar para elaborar alertas. + **Registros**: los registros de servicios, infraestructura y aplicaciones de AWS almacenados en buckets de Amazon S3 y grupos de registro de CloudWatch se pueden analizar y correlacionar para generar alertas. + **Actividad de facturación**: un cambio repentino en la actividad de facturación puede indicar un evento de seguridad. Siga la documentación de [Crear una alarma de facturación para supervisar los cargos estimados de AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) para monitorearlo. + **Inteligencia de ciberamenazas**: si se suscribe a un origen de inteligencia de ciberamenazas de terceros, puede correlacionar esa información con otras herramientas de registro y monitoreo para identificar posibles indicadores de eventos. + **Herramientas de socios**: los socios de la AWS Partner Network (APN) ofrecen productos de primer nivel que pueden ayudarlo a cumplir sus objetivos de seguridad. Para la respuesta ante incidentes, los productos de socios con detección y respuesta de puntos de conexión (EDR) o SIEM pueden ayudarlo a cumplir sus objetivos de respuesta ante incidentes. Para obtener más información, consulte [Soluciones de socios de seguridad](https://aws.amazon.com/security/partner-solutions/) y [Soluciones de seguridad en AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security). + **Confianza y seguridad de AWS**: Soporte podría contactar a los clientes si identificamos actividad abusiva o malintencionada. + **Contacto único**: dado que pueden ser sus clientes, desarrolladores u otros miembros del personal de su organización quienes adviertan algo inusual, es importante contar con un método conocido y bien publicitado para ponerse en contacto con su equipo de seguridad. Entre las opciones más populares se incluyen los sistemas de tickets, las direcciones de correo electrónico de contacto y los formularios web. Si su organización trabaja con el público en general, es posible que también necesite un mecanismo de contacto de seguridad orientado al público. Para obtener más información sobre las capacidades en la nube que puede utilizar durante sus investigaciones, consulte [Apéndice A: Definiciones de capacidades en la nube](appendix-a-cloud-capability-definitions.md) en este documento. # Detección como parte de la ingeniería de control de seguridad Los mecanismos de detección son una parte integral del desarrollo del control de seguridad. A medida que se definen los controles *directivos* y *preventivos*, se deben construir los controles de *detección* y *respuesta* relacionados. Por ejemplo, una organización establece un control directivo relacionado con el usuario raíz de una cuenta de AWS, que solo debe usarse para actividades específicas y muy bien definidas. Lo asocia a un control preventivo implementado mediante la política de control de servicio (SCP) de una organización de AWS. Si la actividad del usuario raíz supera la línea de base esperada, un control de detección implementado con una regla de EventBridge y un tema de SNS alertará al centro de operaciones de seguridad (SOC). El control de respuesta implica que el SOC seleccione el manual de estrategias adecuado, lleve a cabo el análisis y trabaje hasta que se resuelva el incidente. La mejor forma de definir los controles de seguridad es mediante el modelado de amenazas de las cargas de trabajo que se ejecutan en AWS. El nivel de gravedad de los controles de detección se determinará analizando el análisis del impacto empresarial (BIA) de cada carga de trabajo concreta. Las alertas generadas por los controles de detección no se gestionan a medida que se producen, sino que se basan en su nivel de gravedad inicial, que se ajustará durante el análisis. El nivel de gravedad inicial establecido ayuda a definir prioridades; el contexto en el que se haya producido la alerta determinará su verdadero nivel de gravedad. Por ejemplo, una organización utiliza Amazon GuardDuty como componente del control de detección que se utiliza para las instancias de EC2 que forman parte de una carga de trabajo. Se genera el resultado `Impact:EC2/SuspiciousDomainRequest.Reputation` y le informa de que la instancia de Amazon EC2 que aparece en la lista dentro de su carga de trabajo está consultando un nombre de dominio que se sospecha que es malicioso. Esta alerta se configuró de forma predeterminada como de gravedad baja y, a medida que avanzaba la fase de análisis, se determinó que un actor no autorizado había implementado varios cientos de instancias de EC2 del tipo `p4d.24xlarge`, lo que aumentó considerablemente los costos operativos de la organización. En este punto, el equipo de respuesta ante incidentes toma la decisión de ajustar el nivel de gravedad de esta alerta a *alta*, lo que aumenta la sensación de urgencia y agiliza las acciones futuras. Tenga en cuenta que la gravedad del resultado de GuardDuty no se puede cambiar. # Implementaciones de controles de detección Es importante entender cómo se implementan los controles de detección porque ayudan a determinar cómo se utilizará la alerta para un evento en particular. Hay dos implementaciones principales de los controles de detección técnicos: + La **detección del comportamiento** se basa en modelos matemáticos que se conocen comúnmente como machine learning (ML) o inteligencia artificial (IA). La detección se realiza por inferencia; por lo tanto, es posible que la alerta no refleje necesariamente un evento real. + La **detección basada en reglas** es determinista; los clientes pueden establecer los parámetros exactos de la actividad sobre la que se generarán alertas, y eso es seguro. Las implementaciones modernas de sistemas de detección, como un sistema de detección de intrusiones (IDS), suelen incluir ambos mecanismos. A continuación, se presentan algunos ejemplos de detecciones basadas en reglas y de comportamiento con GuardDuty. + Cuando se genera el resultado `Exfiltration:IAMUser/AnomalousBehavior`, le informa de que “se ha observado una solicitud de API anómala en su cuenta”. A medida que profundiza en la documentación, se indica que “el modelo de ML evalúa todas las solicitudes de API de su cuenta e identifica los eventos anómalos asociados a las técnicas utilizadas por los adversarios”, lo que indica que este resultado se refiere al comportamiento. + Para el resultado `Impact:S3/MaliciousIPCaller`, GuardDuty analiza las llamadas a la API del servicio Amazon S3 en CloudTrail y compara el elemento de registro `SourceIPAddress` con una tabla de direcciones IP públicas que incluye fuentes de inteligencia de amenazas. Una vez que encuentra una coincidencia directa con una entrada, genera el resultado. Recomendamos implementar una combinación de alertas de comportamiento y basadas en reglas, ya que no siempre es posible implementar alertas basadas en reglas para todas las actividades del modelo de amenazas. # Detección basada en personas Hasta este punto, hemos hablado de la detección basada en la tecnología. El otro origen importante de detección proviene de personas dentro o fuera de la organización del cliente. Las *personas internas* se pueden definir como empleados o contratistas, y las *personas externas* son entidades como investigadores de seguridad, fuerzas del orden, medios de comunicación y redes sociales. Aunque la detección basada en la tecnología se puede configurar de forma sistemática, la detección basada en personas se presenta de diversas formas, como correos electrónicos, tickets, correo postal, publicaciones de noticias, llamadas telefónicas e interacciones en persona. Cabe esperar que las notificaciones de detección basadas en la tecnología se envíen en tiempo casi real, pero no hay expectativas de plazos para la detección basada en personas. Es imprescindible que la cultura de seguridad incorpore, facilite y potencie los mecanismos de detección basados en las personas para adoptar un enfoque de defensa en profundidad para la seguridad. # Resumen En el caso de la detección, es importante contar con una combinación de alertas basadas en reglas y en el comportamiento. Además, debe contar con mecanismos para que las personas, tanto internas como externas, envíen tickets sobre los problemas de seguridad. Los seres humanos pueden ser uno de los orígenes más valiosos de eventos de seguridad, por lo que es importante contar con procesos para que las personas puedan derivar sus preocupaciones a los superiores. Debe utilizar los modelos de amenazas de su entorno para empezar a crear detecciones. Los modelos de amenazas lo ayudarán a crear alertas basadas en las amenazas más pertinentes para su entorno. Por último, puede utilizar marcos como MITRE ATT&CK para comprender las tácticas, técnicas y procedimientos (TTP) de los actores de amenazas. Utilizar el marco MITRE ATT&CK como lenguaje común puede resultar útil en sus diversos mecanismos de detección.