SEC01-BP07 Identificar amenazas y priorizar mitigaciones con un modelo de amenazas - AWS Well-Architected Framework
Guía para la implementaciónRecursos

SEC01-BP07 Identificar amenazas y priorizar mitigaciones con un modelo de amenazas

Utilice el modelado de amenazas para identificar y mantener un registro actualizado de las amenazas potenciales y las mitigaciones asociadas para su carga de trabajo. Priorice sus amenazas y adapte sus mitigaciones de controles de seguridad para evitarlas, detectarlas y responder a ellas. Revise y mantenga todo esto en el contexto de su carga de trabajo y de la evolución del panorama de seguridad.

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

Guía para la implementación

¿Qué es el modelado de amenazas?

«El modelado de amenazas sirve para identificar, comunicar y comprender las amenazas y mitigaciones dentro del contexto de la protección de algo de valor» – «Application Threat Modeling» de Open Web Application Security Project (OWASP)

¿Por qué debe modelar las amenazas?

Los sistemas son complejos y, con el tiempo, se hacen más complejos y potentes aún, por lo que aportan más valor empresarial y aumentan la satisfacción y el compromiso de los clientes. Esto significa que, en las decisiones de diseño de TI, se deben tener en cuenta un número cada vez mayor de casos de uso. Debido a esta complejidad y al número de combinaciones de casos de uso, los enfoques no estructurados suelen resultar ineficaces para encontrar y mitigar las amenazas. En su lugar, se necesita un enfoque sistemático para encontrar las amenazas potenciales para el sistema, pero también para concebir mitigaciones y priorizarlas para asegurarse de que los limitados recursos de la organización tengan el máximo impacto en la mejora de la postura de seguridad general del sistema.

El modelado de amenazas está diseñado para proporcionar este enfoque sistemático, con el objetivo de encontrar y abordar los problemas en las primeras fases del proceso de diseño, cuando las mitigaciones tienen un coste y un esfuerzo relativamente bajos en comparación con las fases posteriores del ciclo de vida. Este enfoque se ajusta al principio de seguridad shift-left (desplazamiento a la izquierda) del sector. En última instancia, el modelado de amenazas se integra en el proceso de administración de riesgos de una organización y ayuda a tomar decisiones sobre qué controles aplicar mediante un enfoque basado en las amenazas.

¿Cuándo debe realizarse el modelado de amenazas?

Empiece a modelar las amenazas lo antes posible en el ciclo de vida de su carga de trabajo, ya que así tendrá más flexibilidad para actuar en relación con las amenazas que identifique. Al igual que ocurre con los errores de software, cuanto antes identifique las amenazas, más rentable le resultará abordarlas. Un modelo de amenazas es un documento vivo y debe evolucionar a medida que cambien sus cargas de trabajo. Revise los modelos de amenazas a lo largo del tiempo, especialmente cuando se produzca un cambio importante, un cambio en el panorama de las amenazas o cuando adopte una nueva función o servicio.

Pasos para la implementación

¿Cómo podemos realizar el modelado de amenazas?

Hay muchas formas diferentes de realizar el modelado de amenazas. Al igual que ocurre con los lenguajes de programación, cada una tiene sus ventajas y sus inconvenientes, por lo que debe elegir la que mejor le convenga. Un enfoque es comenzar con Shostack’s 4 Question Frame for Threat Modeling (Marco de 4 preguntas para el modelado de amenazas de Shostack), que plantea preguntas abiertas para proporcionar una estructura a su modelado de amenazas:

  1. ¿En qué está trabajando?

    La finalidad de esta pregunta es ayudarle a comprender y acordar el sistema que está construyendo y los detalles de ese sistema que son relevantes para la seguridad. Lo más habitual es responder que se está creando un modelo o diagrama, ya esto ayuda a visualizar lo que está construyendo, por ejemplo, con un diagrama de flujo de datos. Anotar las suposiciones y los detalles importantes sobre su sistema también le ayuda a definir el alcance del trabajo. De esta manera, todas las personas que contribuyen al modelo de amenazas pueden centrarse en lo mismo, y evita dar largos rodeos hacia temas que están fuera del alcance (lo que incluye versiones desactualizadas de su sistema). Por ejemplo, si crea una aplicación web, probablemente no merezca la pena que modele la secuencia de arranque de confianza del sistema operativo para los clientes del navegador, ya que no tiene capacidad para influir en esto con su diseño.

  2. ¿Qué puede salir mal?

    Aquí es donde usted identifica las amenazas que afectan a su sistema. Las amenazas son acciones o acontecimientos accidentales o intencionados que tienen repercusiones no deseadas y podrían afectar a la seguridad de su sistema. Si no tiene una idea clara de lo que podría salir mal, no podrá hacer nada al respecto.

    No existe una lista formal de lo que puede salir mal. Para crear esta lista, todos los miembros de su equipo y las personas relevantes implicadas en el modelado de amenazas deben hacer una lluvia de ideas y colaborar. Para facilitar la lluvia de ideas, puede utilizar un modelo de identificación de amenazas, como STRIDE, que sugiere diferentes categorías para evaluar las siguientes amenazas: suplantación de identidad, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Además, puede facilitar la lluvia de ideas inspirándose en listas e investigaciones existentes, como OWASP Top 10 (Los 10 principales riesgos de seguridad de OWASP), HiTrust Threat Catalog (Catálogo de amenazas de HiTrust) y el propio catálogo de amenazas de su organización.

  3. ¿Qué vamos a hacer al respecto?

    Igual que en la pregunta anterior, no existe una lista formal de todas las mitigaciones posibles. En este paso, tenemos las amenazas, los actores y las áreas de mejora identificados en el paso anterior.

    La seguridad y la conformidad constituyen una responsabilidad compartida entre usted y AWS. Es importante entender que, cuando se pregunta «¿Qué vamos a hacer al respecto?», también se está preguntando «¿Quién es responsable de hacer algo al respecto?». Comprender el reparto de responsabilidades entre usted y AWS le ayuda a delimitar su modelado de amenazas a las mitigaciones que están bajo su control, que suelen ser una combinación de opciones de configuración de los servicios de AWS y las mitigaciones específicas de su propio sistema.

    En lo que se refiere a la parte de AWS de esa responsabilidad compartida, descubrirá que los servicios de AWS están dentro del ámbito de muchos programas de conformidad. Estos programas le ayudan a conocer los sólidos controles que hay en AWS para mantener la seguridad y la conformidad de la nube. Los clientes de AWS pueden descargar informes de auditoría de estos programas desde AWS Artifact.

    Independientemente de los servicios de AWS que utilice, el cliente siempre tiene una parte de la responsabilidad y las mitigaciones que se corresponden con estas responsabilidades deben incluirse en su modelo de amenazas. En cuanto a las mitigaciones de los controles de seguridad de los propios servicios de AWS, debe considerar la posibilidad de implementar controles de seguridad en todos los dominios, como los de administración de identidades y accesos (autenticación y autorización), protección de datos (en reposo y en tránsito), seguridad de la infraestructura, registro y supervisión. En la documentación de cada servicio de AWS, hay un capítulo dedicado a la seguridad que ofrece orientación sobre los controles de seguridad que deben considerarse como mitigaciones. Y lo que es más importante, considere el código que está escribiendo y sus dependencias, y piense en los controles que podría establecer para hacer frente a esas amenazas. Estos controles podrían ser cosas como la validación de entradas, la gestión de sesiones y la gestión de límites. Muchas veces, la mayoría de las vulnerabilidades se introducen en el código personalizado, así que céntrese en esta área.

  4. ¿Hemos hecho un buen trabajo?

    El objetivo es que su equipo y su organización mejoren con el tiempo tanto la calidad de los modelos de amenazas como la velocidad a la que los realizan. Estas mejoras se deben a una combinación de práctica, aprendizaje, enseñanza y revisión. Para profundizar y ponerse manos a la obra, es recomendable que usted y su equipo completen el curso de formación el taller Threat modeling the right way for builders training course (Modelado de amenazas de la forma adecuada para constructores). Además, si busca orientación sobre cómo integrar el modelado de amenazas en el ciclo de vida de desarrollo de aplicaciones de su organización, consulte la publicación How to approach threat modeling (Cómo abordar el modelado de amenazas) en el blog de seguridad de AWS.

Threat Composer

Para ayudarle y guiarle en la creación de modelos de amenazas, considere la posibilidad de utilizar la herramienta Threat Composer, que tiene como objetivo obtener valor más rápido al modelar amenazas. La herramienta le ayuda a hacer lo siguiente:

  • Escribir instrucciones de amenazas útiles adaptadas a la gramática de amenazas que funcionan en un flujo de trabajo no lineal natural

  • Generar un modelo de amenazas legible por humanos

  • Generar un modelo de amenazas legible por máquina que le permita tratar los modelos de amenazas como código

  • Ayudarle a identificar rápidamente las áreas de mejora de la calidad y la cobertura mediante el panel de información

Para obtener más información, visite «Threat Composer» y cambie al espacio de trabajo de ejemplo definido por el sistema.

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Formación relacionada:

Herramientas relacionadas: