SEC01-BP07 Identifique las amenazas y priorice las mitigaciones mediante un modelo de amenazas - Pilar de seguridad

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

SEC01-BP07 Identifique las amenazas y priorice las mitigaciones mediante un modelo de amenazas

Realice un modelado de amenazas para identificar y mantener un up-to-date registro de las posibles amenazas y las mitigaciones asociadas a su 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”. — El proyecto abierto de seguridad de aplicaciones web (OWASP): modelado de amenazas para aplicaciones

¿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. Esto permite que todos los que contribuyen al modelo de amenazas se centren en lo mismo y eviten perder tiempo dedicándose a out-of-scope los temas (incluidas las versiones anticuadas 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, utilice un modelo para identificar las amenazas, por ejemplo, que sugiera diferentes categorías para evaluarlas: suplantación de identidad STRIDE, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Además, tal vez desee contribuir a la reflexión consultando las listas existentes y buscando inspiración en sus investigaciones, incluidas las 10 OWASP principales, el catálogo de amenazas y el catálogo de amenazas de su propia organización. HiTrust

  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 equilibrio de responsabilidades entre ustedes le AWS ayudará a adaptar su proceso de modelado de amenazas a las mitigaciones que están bajo su control, que suelen consistir en una combinación de opciones de configuración de AWS servicios y mitigaciones específicas de su propio sistema.

    En cuanto a la AWS parte de la responsabilidad compartida, descubrirá que los AWS servicios forman parte del ámbito de aplicación de muchos programas de conformidad. Estos programas le ayudan a comprender los sólidos controles que existen AWS para mantener la seguridad y el cumplimiento de la nube. Los informes de auditoría de estos programas están disponibles para que AWS los clientes los descarguen en AWS Artifact.

    Independientemente de AWS los servicios que utilice, siempre hay un elemento de responsabilidad del cliente, y su modelo de amenazas debe incluir medidas de mitigación acordes con estas responsabilidades. Para mitigar el control de seguridad de los propios AWS servicios, conviene plantearse la posibilidad de implementar controles de seguridad en todos los dominios, incluidos dominios como la gestión de identidades y accesos (autenticación y autorización), la protección de datos (en reposo y en tránsito), la seguridad de la infraestructura, el registro y la supervisión. La documentación de cada AWS servicio 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 las aplicaciones de su organización, consulte la publicación Cómo abordar el modelado de amenazas en el blog de AWS seguridad.

Threat Composer

Para ayudarlo y guiarlo a la time-to-value hora de modelar las amenazas, considere la posibilidad de utilizar la herramienta Threat Composer, que tiene como objetivo reducir el tiempo empleado en el modelado 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: