SEC01-BP07 Identificación de amenazas y priorización de mitigaciones con un modelo de amenazas - Marco de AWS Well-Architected
Guía para la implementaciónRecursos

SEC01-BP07 Identificación de amenazas y priorización de 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 la carga de trabajo. Priorice sus amenazas y adapte sus mitigaciones de controles de seguridad para evitarlas, detectarlas y responder a ellas. Revisite y mantenga todo esto en el contexto de la 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 las mitigaciones en el contexto de la protección de algo de valor”. Threat Modeling de Open Web Application Security Project (OWASP)

¿Por qué debería crear un modelo de 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 costo y un esfuerzo relativamente bajos en comparación con las fases posteriores del ciclo de vida. Este enfoque se alinea con el principio del sector relativo al desplazamiento a la izquierda de la seguridad. 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 se debe llevar a cabo el modelado de amenazas?

Empiece a modelar las amenazas lo antes posible en el ciclo de vida de la 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 las cargas de trabajo. Revisite 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 característica o servicio.

Pasos para la implementación

¿Cómo podemos llevar a cabo el modelado de amenazas?

Hay muchas formas diferentes de llevar a cabo 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 consiste en empezar con Shostack’s 4 Question Frame for Threat Modeling, que plantea preguntas abiertas para estructurar el ejercicio de modelado de amenazas:

  1. ¿En qué están trabajando?

    La finalidad de esta pregunta es ayudarle a comprender y acordar el sistema que está creando y los detalles de ese sistema que son pertinentes para la seguridad. Crear un modelo o diagrama es la forma más popular de responder a esta pregunta, ya que le ayuda a visualizar lo que está creando, por ejemplo, mediante un diagrama de flujo de datos. Anotar las suposiciones y los detalles importantes sobre el 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 del 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 se identifican las amenazas que afectan al sistema. Las amenazas son acciones o acontecimientos accidentales o intencionados que tienen repercusiones no deseadas y podrían afectar a la seguridad del 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. La creación de esta lista requiere una lluvia de ideas y la colaboración de todas las personas del equipo y las personas pertinentes involucradas en el ejercicio de modelado de amenazas. Para facilitar la reflexión, puede utilizar un modelo para identificar amenazas, como STRIDE, que sugiere distintas categorías para evaluarlas: suplantación de identidad, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Además, para contribuir a la lluvia de ideas, tal vez quiera consultar las listas existentes y buscar inspiración; por ejemplo, en OWASP Top 10, HiTrust Threat Catalog y el catálogo de amenazas propio 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.

    Los asuntos relacionados con la seguridad y la conformidad son una responsabilidad compartida entre el cliente 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 el cliente y AWS le ayuda a delimitar el 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 cuanto a la parte de AWS de la responsabilidad compartida, descubrirá que los servicios de AWS forman parte del ámbito de aplicación de muchos programas de cumplimiento. 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 informes de auditoría de estos programas están disponibles para que los clientes de AWS los descarguen de 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 el 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. La documentación de cada servicio de AWS incluye un capítulo dedicado a la seguridad que proporciona orientación sobre los controles de seguridad que se deben considerar como medidas de mitigación. 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 pueden ser, por ejemplo, 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. ¿Hicimos 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 llevan a cabo. 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, le recomendamos que usted y su equipo completen el curso de formación o el taller sobre modelado de amenazas para constructores. Además, si busca orientación sobre cómo integrar el modelado de amenazas en el ciclo de vida del desarrollo de aplicaciones de su organización, consulte la publicación How to approach threat modeling en el blog de seguridad de AWS.

Threat Composer

Como ayuda y orientación a la hora de modelar las amenazas, considere la posibilidad de utilizar la herramienta Threat Composer, cuyo objetivo es reducir el tiempo que se tarda en generar valor a la hora de crear modelos de amenazas. La herramienta le ayuda a hacer lo siguiente:

  • Escribir instrucciones de amenazas útiles alineadas con la gramática de amenazas que funcionen en un flujo de trabajo natural y no lineal

  • 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:

Videos relacionados:

Formación relacionada:

Herramientas relacionadas: