Capítulo 4. Modelización automatizada de amenazas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

No parecía haber ningún proceso dirigido por ordenador que no pudiera mejorarse con humanos arrastrándose por la estructura real y escribiendo sobre ella con lápices de grasa.

Neal Stephenson, Atmosphæra Incognita

En el Capítulo 1 profundizaste en la mecánica de construcción de distintos tipos de modelos de sistemas "a mano", dibujando en una pizarra o utilizando una aplicación como Visio de Microsoft o draw.io. También viste la información que necesitas reunir al construir esos modelos. En el Capítulo 3, obtuviste una visión general de los enfoques de modelado de amenazas que consumen los modelos de sistema que creas, permitiéndote identificar áreas de preocupación de seguridad dentro de tu sistema bajo evaluación. Conociste métodos que encuentran amenazas de alto nivel, teniendo en cuenta a los adversarios que tienen la capacidad y la intención de llevar a cabo un ataque. También viste metodologías que miran más profundamente en la "pila" de amenazas para analizar las causas subyacentes que conducen a las amenazas (y a los objetivos de los adversarios): debilidades y vulnerabilidades, que solas o combinadas provocan un desastre para la funcionalidad y los datos de tu sistema (así como para tu reputación y marca).

Estas técnicas y metodologías son un enfoque eficaz tanto para el modelado de sistemas como de amenazas, si tienes tiempo y energía, y puedes convencer a tu organización de que este enfoque es importante. Sin embargo, en esta era del todo continuo, y de todo como código, se ejerce mucha presión sobre los equipos de desarrollo para que entreguen más en menos tiempo. Por tanto, las prácticas de seguridad que se aceptaban como males necesarios porque consumían más de unos minutos del tiempo de los desarrolladores se están abandonando por ser demasiado costosas (percibidas o no). Eso deja a las personas que se centran en la seguridad en una posición difícil. ¿Intentas influir en tu organización para que se muerda la bala y sea más rigurosa en la aplicación de prácticas de ingeniería de seguridad, o intentas hacer todo lo posible con tus cada vez más escasos recursos, sabiendo que la calidad de tus resultados (y, por extensión, la seguridad del producto final) puede verse afectada? ¿Cómo puedes mantener un alto nivel de seguridad y la atención al detalle necesarios para crear un sistema bien diseñado?

Una forma de facilitar una buena ingeniería de seguridad es limitar la necesidad de construir modelos de sistemas y amenazas a mano y recurrir a la automatización para reducir la carga que te supone, a fin de satisfacer las necesidades de la empresa y del equipo de seguridad. Aunque puede decirse que el elemento humano es una parte importante de una actividad de modelado de amenazas, la construcción y el análisis de modelos de sistemas es algo que un ordenador puede realizar con facilidad; tú, por supuesto, debes suministrar la entrada.

La automatización no sólo te ayuda a diseñar el modelo, sino que también puede ayudarte a responder preguntas. Por ejemplo, si no estás seguro de si el flujo de datos A entre los puntos finales X e Y deja tus datos críticos expuestos a la mítica Eva,¹ puedes utilizar un programa para averiguarlo.

En este capítulo, exploramos una evolución en ciernes. Cuando se trata de crear el estado del arte en técnicas de modelado de amenazas, realizar análisis de amenazas y elicitación de defectos, puedes utilizar técnicas de automatización denominadas modelado de amenazas con código y modelado de amenazas a partir del código.²

Puede que te estés preguntando: ¿cómo te facilitará la vida la automatización del modelado de amenazas, y no una herramienta/proceso/responsabilidad más de la que preocuparte a largo plazo? Nosotros también nos preguntamos lo mismo.

¿Por qué automatizar el modelado de amenazas?

Admitámoslo: modelar amenazas de la forma tradicional es difícil, por muchas razones:

Se necesita un talento poco común y altamente especializado: para hacer bien el modelado de amenazas, tienes que descubrir los puntos débiles de un sistema. Esto requiere formación (como la lectura de éste u otros manuales sobre modelado de amenazas) y una buena dosis de pesimismo y pensamiento crítico cuando se trata de lo que es y lo que podría ser (y de cómo podrían ir mal las cosas).
Hay mucho que saber, y eso requerirá una amplitud y profundidad de conocimientos y experiencias. A medida que tu sistema crece en complejidad, o se introducen cambios (como la transformación digital que muchas empresas están experimentando en estos días), los cambios en las tecnologías traen consigo un número acelerado de puntos débiles: se identifican nuevas debilidades y amenazas, y se crean nuevos vectores de ataque; el personal de seguridad debe estar aprendiendo constantemente.
Hay innumerables opciones entre las que elegir.³ Esto incluye herramientas y metodologías para realizar el modelado y análisis de amenazas, como representaciones modeladas, y cómo registrar, mitigar o gestionar los hallazgos.
Convencer a las partes interesadas de que el modelado de amenazas es importante puede ser difícil, en parte por lo siguiente:
- Todo el mundo está ocupado (como ya se ha dicho).
- No todos los miembros del equipo de desarrollo comprenden el sistema tal y como se especificó y/o diseñó. Lo que se diseña no es necesariamente lo que figuraba en la especificación, y lo que se implementa puede no coincidir tampoco. Encontrar a las personas adecuadas que puedan describir correctamente el estado actual del sistema analizado puede ser todo un reto.
- No todos los arquitectos y programadores tienen un conocimiento completo de aquello en lo que están trabajando; excepto en los equipos pequeños y de alto funcionamiento, no todos los miembros del equipo tendrán un conocimiento cruzado de las áreas de los demás. A esto lo llamamos la metodología de desarrollo de los tres ciegos y el elefante.
- Algunos miembros del equipo (esperemos que sólo sean unos pocos) tienen intenciones poco perfectas, lo que significa que pueden estar a la defensiva o hacer declaraciones intencionadamente engañosas).
Aunque seas capaz de leer el código, eso no te muestra el panorama completo. Si tienes que leer el código, puedes haber perdido la oportunidad de evitar errores potencialmente graves introducidos por el diseño que la codificación no puede mitigar. Y a veces puede ser difícil deducir el diseño superpuesto sólo a partir del código.
Crear un modelo de sistema requiere tiempo y esfuerzo. Y como nada es estático, mantener un modelo de sistema requiere tiempo. El diseño de un sistema cambiará a medida que se modifiquen los requisitos del sistema en respuesta a la implementación, y tienes que mantener el modelo del sistema sincronizado con cualquier cambio.

Éstas son algunas de las razones por las que algunos miembros veteranos de la comunidad de seguridad han expresado su preocupación por el uso práctico del modelado de amenazas como actividad defensiva durante el ciclo de vida del desarrollo.⁴ Y para ser sinceros, estas razones sondesafiantes.

Pero, ¡no temas! La comunidad de seguridad es un grupo resistente que nunca se avergüenza de aceptar un reto para abordar un problema del mundo real, especialmente aquellos problemas que te causan dolor, angustia y noches sin dormir. Y la automatización puede ayudar a resolver estos problemas (véase la Figura 4-1).

Lo difícil de utilizar la automatización es la complejidad de los sistemas y la relativa incapacidad de un programa para hacer algo que el cerebro humano puede hacer mejor: el reconocimiento de patrones.⁵ La dificultad estriba en expresar el sistema de forma que un ordenador pueda entenderlo sin crear realmente el sistema. Como resultado, existen dos enfoques relacionados :

Modelado de amenazas a partir del código: Creación de código informático en un lenguaje de programación o en un lenguaje específico del dominio (DSL) de nueva definición que, cuando se ejecuta, da lugar a que el análisis de las amenazas se realice sobre un modelo que representa los datos de entrada proporcionados
Modelado de amenazas con código (también conocido como modelado de amenazas en código): Utilizar un programa informático para interpretar y procesar la información que se le proporciona para identificar amenazas o vulnerabilidades.

Ambos enfoques pueden ser eficaces siempre que resuelvas el problema GIGO. Los resultados que obtengas deben guardar una relación directa con la calidad de tus entradas (la descripción del sistema y sus atributos) para la automatización. Ambos métodos también requieren que los algoritmos y reglas utilizados en el análisis sean "correctos", de modo que un conjunto determinado de entradas genere salidas válidas y justificables. Cualquiera de las dos implementaciones puede eliminar la necesidad de talento especializado para interpretar un modelo de sistema y comprender la información sobre elementos, interconexiones y datos para identificar los indicadores de un posible problema de seguridad. Por supuesto, esto requiere que el marco o lenguaje soporte este análisis y esté programado para hacerlo correctamente.

Hablaremos primero de la construcción de un modelo de sistema en un formato legible por máquina, y luego presentaremos las teorías de cada tipo de modelado automatizado de amenazas y proporcionaremos proyectos comerciales y de código abierto que los aplican. Más adelante en el capítulo (y en el siguiente), aprovechamos estos conceptos para ofrecer información sobre otras técnicas evolutivas de modelado de amenazas que se esfuerzan por funcionar dentro del mundo rápidamente acelerado de DevOps y CI/CD.

Fundamentalmente, el modelado de amenazas se basa en la entrada en forma de información que contiene o codifica datos suficientes para que los analices; esta información te permite identificar las amenazas. Cuando se utiliza código en lugar de inteligencia humana para realizar el modelado de amenazas, tú describes el sistema que se va a evaluar (por ejemplo, las entidades, flujos o secuencias de acontecimientos que componen un sistema, junto con los metadatos necesarios para apoyar el análisis y la documentación de los resultados), y la aplicación representa y analiza la representación del sistema para producir resultados, y opcionalmente representa la representación en forma de diagramas.

Modelado de amenazas a partir del código

El modelado de amenazas a partir del código procesa información sobre un sistema almacenada en de forma legible por máquina para generar información de salida relacionada con debilidades, vulnerabilidades y amenazas. Lo hace basándose en una base de datos o conjunto de reglas de cosas que debería buscar, y necesita ser resistente a entradas inesperadas (ya que este tipo de aplicaciones necesitan datos de entrada para interpretarlos). En otras palabras, el modelado de amenazas a partir del código es un enfoque interpretado para crear un modelo de sistema a partir del cual generar amenazas.

El modelado de amenazas a partir del código también puede denominarse modelado de amenazas en el código, como en el caso de Threatspec (descrito en "Threatspec").

Nota

La frase "modelado de amenazas desde el código" es una evolución del pensamiento, que combina dos conceptos sobre cómo un sistema captura, mantiene y procesa la información para identificar amenazas. La idea del modelado de amenazas en el código surgió de las conversaciones que Izar mantuvo con Fraser Scott (el creador de Threatspec, descrito más adelante) en torno a la noción de que los módulos de código pueden almacenar la representación del sistema y la información sobre amenazas junto con el código u otra documentación, y pueden mantenerse durante todo el ciclo de vida. Las herramientas que procesan la información pueden ejecutarse para generar datos significativos. En el modelado de amenazas a partir del código -que surgió de otra conversación entre Izar y el creador de ThreatPlaybook, Abhay Bhargav-, la información sobre amenazas puede codificarse, pero necesita ser "manipulada" y correlacionada por algo para que tenga sentido. Colectivamente, estos paradigmas forman la base de esta área en evolución del modelado de amenazas como código, en la que la interpretación y manipulación de datos de diversas fuentes son las operaciones clave.

Cómo funciona

En el modelado de amenazas a partir de código, utilizas un programa (código) para analizar información creada en un formato legible por máquina que describe un modelo de sistema, sus componentes y datos sobre esos componentes. El programa interpreta el modelo de sistema y los datos de entrada, y utiliza una taxonomía de amenazas y debilidades, y criterios de detección, para (a) identificar posibles hallazgos y (b) producir resultados que puedan ser interpretados por un humano. Normalmente, el resultado será un documento de texto o un informe tipo PDF.

Threatspec

Threatspec es un proyecto de código abierto dirigido tanto a los equipos de desarrollo como a los profesionales de la seguridad de . Proporciona una forma cómoda de documentar la información sobre amenazas junto con el código, lo que te permite generar documentación o un informe que permita tomar decisiones sobre riesgos con conocimiento de causa. Threatspec está escrito y mantenido por Fraser Scott en https://threatspec.org.

Nota

Threatspec se llama aquí en esta clase de herramienta por lo que hace frente a lo que no hace:

Requiere que exista un código.
Facilita la documentación de la información sobre amenazas.
No realiza análisis ni detección de amenazas por sí mismo.

Algunas de las ventajas de utilizar Threatspec son las siguientes:

Aporta seguridad a los programadores utilizando anotaciones de código (con las que probablemente estén familiarizados)
Permite a la organización definir un léxico común de amenazas y otras estructuras para que las utilicen los equipos de desarrollo
Facilita el debate sobre la seguridad del modelado y análisis de amenazas
Genera automáticamente documentación detallada y útil, incluidos diagramas y fragmentos de código

Por otra parte, aunque Threatspec es una herramienta excelente para ofrecer a los programadores una forma de anotar su código con información sobre amenazas y acercar así la seguridad al proceso de desarrollo, tiene un par de desventajas que hay que tener en cuenta.

En primer lugar, la herramienta requiere primero que exista código, o que se cree junto con anotaciones, lo que puede significar que el diseño ya está solidificado. En este caso, el equipo de desarrollo está creando principalmente documentación de seguridad, que es muy valiosa, pero diferente del modelado de amenazas. Efectivamente, para este tipo de proyectos, el modelado de amenazas "se desplaza a la derecha", lo que va en la dirección equivocada.

Pero la documentación de Threatspec deja claro que el uso más productivo de la herramienta es en entornos que han adoptado la mentalidad de "todo como código", como DevOps. En esos entornos, el dilema del diseño frente al desarrollo de código no es un problema. Threatspec también ha añadido recientemente la capacidad de documentar amenazas y anotaciones sin haber escrito código, poniendo esta información en archivos de texto sin formato que se pueden analizar. Esto puede ayudar a mitigar esta posible preocupación a los equipos que tienen más estructurado su ciclo de vida de desarrollo o siguen prácticas de ingeniería de sistemas más estrictas.

En segundo lugar, el equipo de desarrollo necesita el conocimiento de un experto. El equipo necesita la orientación de un experto, sobre qué es una amenaza y cómo describirla. Esto significa que no puedes abordar directamente el problema de la escalabilidad de . Este enfoque se presta, como describe la documentación de la herramienta, a discusiones o ejercicios guiados entre el equipo de desarrollo y el personal de seguridad. Pero al hacerlo, la escalabilidad se pone aún más en entredicho, al añadir de nuevo el cuello de botella del experto en seguridad. Una formación exhaustiva de los equipos de desarrollo puede superar este obstáculo, o tener la seguridad integrada en el grupo de desarrollo puede ayudar a facilitar las conversaciones más cerca de dónde y cuándo se está desarrollando el código.

Nota

En el futuro, Threatspec puede ser especialmente adecuado para tomar el resultado de las herramientas de análisis estático de código y generar anotaciones que describan las amenazas a partir de la naturaleza del código (en lugar de sólo lo que los codificadores puedan o quieran documentar por sí mismos). Como Threatspec tiene acceso directo al código fuente, puede, como mejora, realizar actividades de verificación y proporcionar información directamente en el código fuente cuando descubra amenazas, riesgos o puntos débiles. Por último, la ampliación de las amenazas a los ámbitos de la seguridad funcional y la privacidad puede producir una visión completa de la postura de seguridad, privacidad y protección de un sistema, lo que es especialmente importante cuando se trata con responsables de cumplimiento o reguladores (por ejemplo, para el cumplimiento de PCI-DSS, GDPR u otros entornos reguladores) o para orientar el análisis de causas raíz o peligros como actividades de seguimiento.

Puedes obtener Threatspec de GitHub en https://oreil.ly/NGTI8. Requiere Python 3 y Graphviz para ejecutarse y generar informes. El creador/mantenedor de Threatspec participa activamente en la comunidad de seguridad, especialmente en el grupo de trabajo OWASP Threat Modeling y en el Slack de Threatspec, y anima a hacer aportaciones y comentarios sobre la herramienta.

ThreatPlaybook

ThreatPlaybook es un proyecto de código abierto de la gente de we45, dirigido por Abhay Bhargav. Se comercializa como un "marco DevSecOps [para] el modelado colaborativo de amenazas para la automatización de pruebas de seguridad de aplicaciones". Está orientado a los equipos de desarrollo para proporcionar una forma cómoda de documentar la información sobre amenazas e impulsar la automatización de la detección y validación de vulnerabilidades de seguridad. ThreatPlaybook tiene una versión estable (V1) y una versión beta (V3); no existe una versión V2.⁶

Nota

La especialidad de ThreatPlaybook es facilitar el uso de la información sobre modelos de amenazas:

Facilita la documentación de la información sobre amenazas.
Se conecta con otras herramientas de seguridad para la orquestación y validación de vulnerabilidades, por ejemplo mediante laautomatización de pruebas de seguridad.
No realiza análisis ni detección de amenazas por sí mismo.

ThreatPlaybook utiliza GraphQL en MongoDB, y descripciones basadas en YAML de casos de uso y amenazas con construcciones descriptivas, para apoyar la orquestación de pruebas para la verificación de vulnerabilidades. También ofrece una API completa, una aplicación cliente capaz y un generador de informes decente. Para las integraciones de automatización de pruebas, tiene dos opciones: las Bibliotecas del Marco Robot originales de ⁷ y en la V3 su propia funcionalidad Test Orchestration Framework. La documentación sugiere que ThreatPlaybook tiene una buena integración (a través de Robot Framework) con OWASP Zed Attack Proxy, Burp Suite de PortSwigger y npm-audit.

Puedes obtener ThreatPlaybook de GitHub en https://oreil.ly/Z2DZd o mediante la utilidad pip de Python. Un sitio web complementario tiene una buena documentación, aunque algo escasa, y vídeos que explican cómo instalar, configurar y utilizar ThreatPlaybook.

Modelado de amenazas con código

A diferencia de Threatspec y ThreatPlaybook descritos anteriormente, que son ejemplos de uso de código para facilitar la actividad de modelado de amenazas en el ciclo de vida de desarrollo del sistema, el modelado de amenazas con código toma una descripción de la arquitectura o del sistema que está codificada en una forma como uno de los lenguajes de descripción descritos anteriormente, y realiza un análisis para la identificación automatizada de amenazas y la elaboración de informes. Las utilidades que siguen el paradigma "con código" son herramientas que pueden leer la información del modelo del sistema y generar resultados significativos que encapsulan el conocimiento y la experiencia de los profesionales de la seguridad, y permiten a los profesionales de la seguridad escalar a través de unacomunidad de desarrollo más amplia.

Cómo funciona

Un usuario escribe un programa en un lenguaje de programación para construir una representación de un sistema y sus componentes , así como información sobre dichos componentes. Este programa describe la información sobre el sistema en código y proporciona restricciones para realizar el análisis. El proceso resultante utiliza un conjunto de API (funciones) para realizar el análisis de amenazas sobre el estado y las propiedades del sistema modelado. Cuando se compila y ejecuta el "código fuente" (o se interpreta, según las particularidades del lenguaje utilizado), el programa resultante produce conclusiones sobre amenazas a la seguridad basadas en las características y restricciones del sistema modelado.

El concepto de crear modelos sin dibujar en una pizarra existe al menos desde 1976, cuando A. Wayne Wymore, entonces profesor de la Universidad de Arizona, publicó Systems Engineering Methodology for Interdisciplinary Teams (Wiley). Este libro, y otros que le siguieron, sentaron las bases del dominio técnico conocido como ingeniería de sistemas basada en modelos (MBSE). Las lecciones que la industria aprendió de la MBSE influyeron en las construcciones de modelado de sistemas a las que se hace referencia en el Capítulo 1, y en los lenguajes de descripción de sistemas para el análisis computacional que trataremos brevemente.⁸

Los lenguajes de descripción de arquitecturas (ADL) describen representaciones de sistemas. Relacionados con los ADL están los lenguajes de diseño de sistemas , o SDL. Dentro del conjunto de los ADL, dos lenguajes relacionados proporcionan la capacidad de construir y analizar modelos de sistemas que buscan amenazas a la seguridad:⁹

Lenguaje de Análisis y Diseño de Arquitecturas, o AADL
El lenguaje de descripción Acme para el modelado de sistemas basados en componentes

La ingeniería de sistemas utiliza AADL, que es más amplio y expresivo, cuando crea modelos de sistemas embebidos y en tiempo real. Esto es especialmente cierto en los campos de la aviónica y los sistemas de automoción, que requieren seguridad funcional -la propiedad de preservar la salud y la vida de los ocupantes humanos- cuando se trata del comportamiento del sistema. ACME es menos expresivo y, por tanto, más aplicable a sistemas menos complejos o de menor tamaño (definido por el número de componentes e interacciones). ACME también es una especificación de lenguaje de libre acceso, mientras que AADL requiere una licencia de pago, aunque hay disponible material de formación gratuito para que puedas familiarizarte con el lenguaje.¹⁰

Estos lenguajes introducen conceptos sencillos que los ingenieros de sistemas y de software siguen utilizando hoy en día. Puede que notes similitudes con los conceptos que describimos en el Capítulo 1:

Componentes: Representar unidades funcionales como procesos o almacenes de datos
Conectores: Establecer relaciones y conductos de comunicación entre los componentes
Sistemas: Representar configuraciones específicas de componentes y conectores
Puertos: Puntos de interacción entre componentes y conectores
Funciones: Proporcionar información útil sobre la función de los elementos del sistema
Propiedades o anotaciones: Proporcionar información sobre cada constructo que pueda utilizarse para el análisis o la documentación

Nota

Tanto en ACME como en AADL, los puertos existen como puntos de conexión entre objetos y flujos. Nuestra discusión sobre las técnicas de modelado utiliza este concepto, tanto mediante dibujos y técnicas de análisis manual, como mediante metodologías automatizadas que utilizan objetos con propiedades. Lo recomendamos como mejora del DFD tradicional (descrito en el Capítulo 1) para mejorar la legibilidad del modelo del sistema. Este concepto también admite la inclusión de restricciones o capacidades arquitectónicas en el modelo del sistema, donde mantener protocolos o esquemas de protección sólo en los flujos de datos no es fácil de procesar para sistemas complejos con múltiples flujos de datos que son más difíciles de analizar. El uso de puertos ayuda a realizar este análisis y a representar tu diagrama.

Lenguaje minimalista de descripción de arquitecturas para el modelado de amenazas

¿Qué información es necesaria para describir y analizar un modelo de sistema? Vamos a refrescarte la memoria de lo que aprendiste en el Capítulo 1 sobre la construcción de un dibujo representativo "a mano". Necesitas información sobre lo siguiente

Las entidades que existen en el sistema
Cómo interactúan estas entidades: qué elementos se conectan entre sí mediante flujos de datos
Características de los elementos y flujos de datos

Éstos son los requisitos básicos para describir un modelo de sistema, de modo que la automatización pueda identificar patrones que representen debilidades y amenazas potenciales. Más concretamente, el lenguaje o las construcciones que describen el sistema deben permitirte especificar las relaciones básicas entre entidades y describir las unidades básicas de elementos (y colecciones de elementos), puertos y flujos de datos.

Además, debes incluir metadatos en las propiedades de los objetos -el quién, el qué y el por qué- de los sistemas y sus elementos. Hay múltiples razones por las que esto es necesario cuando construyes una representación del sistema, ya que los metadatos hacen losiguiente:

Los metadatos proporcionan información de fondo que ayuda a identificar lagunas en los controles y procesos de seguridad, así como a generar un informe o documento que utilizará el equipo de desarrollo. Estos metadatos incluyen elementos como el nombre del objeto dentro del modelo del sistema, el nombre de la aplicación o del proceso, quién o qué equipo es responsable de su implementación y/o mantenimiento, y la finalidad general del objeto dentro del sistema.
Asigna a cada objeto un identificador corto para facilitar su consulta en el futuro y para facilitar la documentación y la representación de diagramas.
Te permite proporcionar información específica, como el valor (valor financiero, o la importancia de los datos para los usuarios del sistema, por ejemplo) de los datos gestionados y/o almacenados por el sistema considerado. También debes proporcionar el valor que aporta la funcionalidad del sistema, en qué medida el sistema apoya la identificación y priorización de riesgos, y otra información necesaria para la documentación. Esta información no es estrictamente necesaria para identificar los problemas de seguridad, pero debe considerarse necesaria cuando realices la evaluación de riesgos, la priorización y la elaboración de informes.

Elementos y colecciones

Los objetos se conectan a otros objetos dentro de un sistema, y tienen propiedades pertinentes para el análisis de amenazas; estos objetos se denominan elementos. Los elementos pueden representar un proceso, un objeto o un individuo (actor). Los elementos también representan datos dentro de un sistema. Los datos se asocian a elementos o flujos de datos (para más detalles, consulta "Datos y flujos de datos").

Las colecciones son una forma especial de elemento. Las colecciones forman una relación abstracta agrupación de elementos (y por extensión sus flujos de datos o cualquier elemento y/o puerto huérfano arbitrario) para establecer una comunidad o un punto de referencia para el análisis. Te permiten crear una representación de un grupo de elementos, cuyo valor o finalidad es importante para ti de alguna manera. La agrupación puede informar el análisis independientemente de los miembros del grupo: si determinados elementos funcionan o existen como parte de un grupo, eso puede ofrecer pistas sobre su funcionalidad compartida que cada elemento por sí solo no indicaría. Las agrupaciones recomendadas son las siguientes

Sistema: Esto te permite indicar que un conjunto de elementos comprende miembros de un elemento compuesto mayor. A efectos de dibujo, y para el análisis con distintos grados de granularidad, un sistema puede representarse como una colección o como un elemento. Como comentamos en el Capítulo 1, al dibujar modelos de sistemas, existe un proceso para comenzar con un elemento y descomponerlo en sus partes representativas. Recordemos que al crear el contexto, o capa inicial, que muestra los componentes principales del sistema, se utilizó una única forma para representar una colección de partes subcomponentes; cuando se dibuja con un mayor nivel de especificidad (es decir, ampliando el zoom), las partes representativas se individualizan. Al crear un modelo de sistema en un lenguaje de descripción, las partes representativas deben especificarse individualmente y, por comodidad, agruparse (normalmente asignándoles una etiqueta compartida o un indicador de sus relaciones entre sí).
Contexto de ejecución: Es de vital importancia poder tener en cuenta el contexto en el que se ejecuta un proceso, o el ámbito de una unidad de datos, durante el análisis. Utiliza una colección de contextos de ejecución para asociar cosas como procesos con otras cosas como CPU virtuales o físicas, nodos de cálculo, sistemas operativos, etc., en el ámbito en el que opera. Entender esto te ayuda a identificar problemas de contexto cruzado y otras oportunidades de abuso.
Límite de confianza: Una colección de elementos puede ser puramente abstracta y/o arbitraria, y no requerir adyacencia física o virtual, para tener significado para ti. En el momento de definir los objetos del modelo del sistema, puede que no se conozcan todos los componentes del sistema. Por eso puede ser útil poder asociar un conjunto de elementos como una colección que comparte una relación de confianza, o para la que la confianza cambia entre ellos y otros elementos que no están en la colección.

La información asociada a los nodos -otro nombre para los elementos- se codifica como propiedades o características del objeto, y proporciona información crítica para el análisis y la documentación. Para que la comprobación del modelo del sistema y el análisis de amenazas sean correctos, los elementos deben tener propiedades básicas.¹¹ Aquí se muestra una muestra representativa:

Element:
  contains      
  exposes       
  calls         
  is_type:      
    - cloud.saas
    - cloud.iaas
    - cloud.paas
    - mobile.ios
    - mobile.android
    - software
    - firmware.embedded
    - firmware.kernel_mod
    - firmware.driver
    - firmware
    - hardware
    - operating_system
    - operating_system.windows.10
    - operating_system.linux
    - operating_system.linux.fedora.23
    - operating_system.rtos
  is_containerized                  
  deploys_to:
    - windows
    - linux
    - mac_os_x
    - aws_ec2
  provides
    - protection                    
    - protection.signed
    - protection.encrypted
    - protection.signed.cross       
    - protection.obfuscated
  packaged_as:                      
    - source
    - binary
    - binary.msi
    - archive
  source_language:                  
    - c
    - cpp
    - python
  uses.technology:                  
    - cryptography
    - cryptography.aes128
    - identity
    - identity.oauth
    - secure_boot
    - attestation
  requires:                         
    - assurance
    - assurance.privacy
    - assurance.safety
    - assurance.thread_safety
    - assurance.fail_safe
    - privileges.root
    - privileges.guest              
  metadata:                         
    - name
    - label
    - namespace
    - created_by
    - ref.source.source             
    - ref.source.acquisition        
    - source_type.internal          
    - source_type.open_source
    - source_type.commercial
    - source_type.commercial.vendor
    - description

: Lista (matriz o diccionario) de elementos conectados a este elemento (para un sistema de sistemas, por ejemplo), que puede incluir datos
: Lista de nodos portuarios
: De un elemento a otro, estableciendo un flujo de datos
: Los elementos tienen un tipo (genérico o específico)
: Las características booleanas pueden ser Verdadero o Falso, o (establecido) o (no establecido)
: Esquema genérico de protección
: Uso del soporte de firma cruzada Microsoft Authenticode
: ¿Qué forma tiene el elemento en uso?
: Si el sistema es o contiene software, ¿qué idioma(s) se utiliza(n)?
: Tecnología o capacidades específicas que utiliza el componente
: ¿Qué necesita o supone el componente para existir?
: Establece sólo los valores que correspondan. Cuidado con los atributos conflictivos
: Información general para informes, referencias y otra documentación
: Referencia a dónde reside el código fuente o la documentación
: Referencia a la procedencia de este componente (lugar del proyecto, quizás)
: Este componente era de origen interno
: Información arbitraria definida por el usuario

Los elementos deben admitir relaciones particulares con otras entidades u objetos:

Los elementos pueden contener otros elementos.
Un elemento puede exponer un puerto (los puertos se describen en la sección siguiente).
- Los puertos están asociados a los datos.
Los elementos pueden conectarse a otros elementos mediante un puerto, estableciendo un flujo de datos.
Un elemento puede hacer una llamada a otro elemento (como cuando un ejecutable hace una llamada a una biblioteca compartida).
Un elemento puede leer o escribir datos. (Los objetos de datos se describen en "Datos y flujos de datos") .

Puertos

Los puertos proporcionan un punto de entrada o conexión en el que se producen interacciones entre nodos. Los puertos son expuestos por los nodos (especialmente los nodos que representan procesos) y están asociados a un protocolo. Los puertos también identifican requisitos sobre su seguridad, como cualquier expectativa de seguridad en las comunicaciones posteriores que pasen por el puerto. Los métodos que ofrece el puerto protegen los canales de comunicación expuestos; algunos de estos métodos proceden del nodo que expone el puerto (como un nodo que abre un puerto para el tráfico protegido por TLS) o del propio puerto (por ejemplo, para una interfaz físicamente segura).

Para su consumo y legibilidad por un programa informático,¹² es imprescindible identificar y segregar los flujos de comunicación por protocolo. Dado que los distintos protocolos pueden ofrecer opciones de configuración variadas que pueden afectar a la seguridad general del diseño, intenta evitar sobrecargar los flujos de comunicación. Por ejemplo, un servidor HTTPS que permita tanto interacciones RESTful como WebSockets a través del mismo servicio y el mismo puerto debería utilizar dos flujos de comunicación. Del mismo modo, un proceso que admita tanto HTTP como HTTPS a través de la misma interfaz debe describirse en el modelo con canales de comunicación distintos. Esto facilitará el análisis del sistema.

Las propiedades relacionadas con los puertos pueden ser las siguientes

Port:
  requires:                 
    - security              
    - security.firewall     
  provides:                 
    - confidentiality
    - integrity
    - qos
    - qos.delivery_receipt
  protocol:                 
    - I2C
    - DTLS
    - ipv6
    - btle                  
    - NFS                   
  data:                     
    - incoming              
    - outbound              
    - service_name          
    - port                  
  metadata:                 
    - name
    - label
    - description

: ¿Qué requiere o espera este puerto?
: Cuando se establece, significa que se espera que exista algún tipo de mecanismo de seguridad para proteger el puerto
: Este puerto debe tener un cortafuegos que lo proteja (como ejemplo concreto de protección de seguridad)
: ¿Qué capacidades ofrece el puerto?
: ¿Qué protocolo utiliza el puerto?¹³
: Bluetooth de baja energía
: Sistema de archivos en red
: ¿Qué datos están asociados a este puerto?
: Datos que se comunican a este puerto (nodos de datos, lista)
: Datos que se comunican desde este puerto (nodos de datos, lista)
: Describe el servicio que se expone, especialmente si este objeto representa un servicio bien conocido¹⁴
: Número de puerto numérico, si se conoce (no efímero)
: Información general para informes, referencias y otra documentación
: Información arbitraria definida por el usuario

Datos y flujos de datos

Los flujos de datos (consulta el Capítulo 1 para ver ejemplos de flujos de datos) se denominan a veces perímetros porque se convierten en líneas de conexión en un diagrama.¹⁵ Los flujos de datos son las rutas por las que viajan los objetos de datos entre los elementos (y a través de los puertos).

Quizá te preguntes por qué es importante o útil separar los datos de los flujos de datos. La respuesta es que un canal de comunicación suele ser sólo una vía o tubería por la que puede viajar información arbitraria, similar a una autopista. El canal de datos en sí no suele tener ningún contexto respecto a la sensibilidad de los datos que fluyen por él. Tampoco tiene ningún sentido del valor empresarial, la criticidad u otros factores que puedan afectar a su uso o a los requisitos de protección. Utilizando nodos de datos y asociándolos a flujos de datos, puedes crear una abstracción que represente un sistema que pasa diferentes tipos de datos a través de flujos de datos.

Puede resultar obvio, pero debes asignar la clasificación más restrictiva de los datos que pasan por el flujo de datos como la clasificación de datos para el propio flujo de datos, ya que esto impulsará los requisitos del flujo de datos para proteger los datos que pasan por él. Esto permite planificar la representación del sistema para que admita el análisis de variantes, lo que significa probar diversas combinaciones de datos asociados a los flujos de datos para predecir cuándo puede surgir un problema de seguridad.

Éstas son algunas propiedades sugeridas para los datos:

Data:
  encoding:
    - json
    - protobuf
    - ascii
    - utf8
    - utf16
    - base64
    - yaml
    - xml
  provides:
    - protection.signed
    - protection.signed.xmldsig
    - protection.encrypted
  requires:
    - security
    - availability
    - privacy
    - integrity
  is_type:                      
    - personal
    - personal.identifiable     
    - personal.health           
    - protected
    - protected.credit_info     
    - voice
    - video
    - security
  metadata:                     
    - name
    - label
    - description

: Tipo de datos que representa este objeto
: Información personal identificable (IPI)
: Información sanitaria protegida (PHI)
: Datos protegidos por PCI-DSS
: Información general para informes, referencias y otra documentación
: Información arbitraria definida por el usuario

Los servicios que exponen el puerto definen las capacidades y propiedades del flujo de datos (el flujo de datos hereda las propiedades representadas por el puerto). Los flujos de datos pueden seguir beneficiándose de disponer de metadatos, que les permitan diferenciar cada flujo cuando, por ejemplo, generen un diagrama o un informe.

Otros idiomas de descripción de modelos

Para completar tus conocimientos, vamos a hablar de un par de lenguajes más, algunos de los cuales encajan en la categoría SDL. Te animamos a que las investigues si te interesan.

El Modelo de Información Común, o CIM, es un estándar del Grupo de Trabajo de Gestión Distribuida (DMTF) para representar, a un nivel granular de detalle, un sistema informático y sus propiedades. Puedes utilizar CIM, y variantes como SBLIM para sistemas Linux, para comprender y documentar la configuración de un sistema para tareas como la orquestación de políticas y la gestión de la configuración. Para obtener una guía sobre el tipo de datos que debes utilizar al anotar modelos de sistemas, revisa la lista de propiedades disponibles que ofrece la CIM para los sistemas que describe la especificación.

El Lenguaje Unificado de Modelado, o UML, es un estándar del Grupo de Gestión de Objetos, u OMG, , muy orientado a la descripción de sistemas centrados en software. Puede que ya estés familiarizado con UML, ya que se enseña habitualmente como parte de un plan de estudios de informática. El diagrama de secuencia (del que hablamos en el Capítulo 1) forma parte de la especificación UML. Recientemente, se han presentado investigaciones a nivel académico que utilizan UML más para la descripción de sistemas de software cuando se busca identificar amenazas que para el análisis para identificar esas amenazas.¹⁶

El Lenguaje de Modelado de Sistemas (SysML) también es una norma OMG. Esta variante de UML está diseñada para ser más directamente aplicable a la ingeniería de sistemas (en lugar de puramente al software) que UML. SysML añade dos tipos de diagramas a UML, y modifica ligeramente un par de los otros tipos de diagramas para eliminar construcciones específicas del software, pero en general reduce los diagramas disponibles de 13 a 9.¹⁷ En teoría, esto hace que el SysML sea más "ligero" y más funcional para su uso general en ingeniería de sistemas. Las empresas y organizaciones que se basan en procesos de ingeniería de sistemas muy estructurados, y por supuesto el mundo académico, han publicado estudios de casos sobre cómo aplicar el SysML para modelar sistemas en busca de amenazas, aunque en el momento de escribir esto la disponibilidad de estudios de casos que muestren la automatización del análisis en busca de amenazas es limitada.¹⁸^,¹⁹

Los tipos de modelos de sistemas, o abstracciones, disponibles, y los datos que pueden asociarse a ellos, tanto en UML como en SysML, son clave para su aplicación en el ámbito del modelado de amenazas, y en concreto del modelado de amenazas mediante código. Ambos proporcionan un medio para especificar objetos e interacciones, y parámetros sobre esos objetos e interacciones. Ambos utilizan también XML como formato de intercambio de datos. XML está diseñado para ser procesado por aplicaciones informáticas, lo que lo hace ideal para crear modelos de sistemas que puedas analizar en busca de amenazas.

Análisis de gráficos y metadatos

Consideremos por un momento el sencillo ejemplo de la Figura 4-2.

Estas anotaciones acompañan al esquema del sistema de la Figura 4-2:

El cliente está escrito en C y llama al servidor en el puerto 8080 para autenticar al usuario del cliente.
El servidor comprueba una base de datos interna, y si la información enviada por el cliente coincide con lo esperado, el servidor devuelve un testigo de autorización al cliente.

Ponte el sombrero de seguridad (consulta la Introducción si necesitas repasar la autenticación y otros fallos aplicables) e identifica los problemas de seguridad en este sencillo modelo de sistema.²⁰ Ahora, piensa en cómo has llegado a la conclusión a la que has llegado. (Probablemente) observaste el modelo de sistema, viste la información proporcionada como anotaciones y determinaste las amenazas potenciales. Realizaste un análisis de patrones comparándolo con una base de datos de información sobre amenazas almacenada en tu memoria. Esto es lo que hacen regularmente los asesores de seguridad de los equipos de desarrollo, y es uno de los retos de la escalabilidad de : no hay suficiente "memoria" y "potencia de cálculo" para todos.

Este análisis de patrones y extrapolación es fácil de hacer para un cerebro humano. Nuestros cerebros, con los conocimientos adecuados, pueden ver fácilmente patrones y hacer extrapolaciones. Incluso tenemos un subconsciente que nos permite tener "corazonadas" sobre nuestro análisis. Establecemos conexiones con y entre cosas que parecen aleatorias y ambiguas. Ni siquiera procesamos todos los pasos que da nuestro cerebro al trabajar; nuestros pensamientos "simplemente suceden". Los ordenadores, a diferencia de nuestros cerebros, hacen las cosas rápidamente, pero necesitan ser conscientes de cada paso y proceso que se necesita. Los ordenadores no pueden inferir ni suponer. Así pues, lo que nosotros damos por supuesto, los ordenadores necesitan ser programados para hacerlo.

Entonces, ¿cómo analizaría este escenario un programa informático?

En primer lugar, tienes que desarrollar un marco de análisis. Este marco debe ser capaz de aceptar entradas (del modelo) y realizar análisis de patrones, sacar conclusiones, establecer conexiones y, ocasionalmente, adivinar, para producir un resultado que los humanos puedan interpretar como significativo. ¿Ya estás preparado con esa IA?

En realidad, no es un gran reto, y no lo ha sido durante bastante tiempo. El planteamiento básico es sencillo:

Crea un formato para describir una representación del sistema con información, utilizando algo parecido a un ADL.
Crea un programa para interpretar la información del modelo del sistema.
Amplía el programa para realizar análisis basados en un conjunto de reglas que rigen los patrones de información presentes en el modelo del sistema.

Veamos de nuevo ese sencillo ejemplo de la Figura 4-3.

Ahora, utilicemos nuestro lenguaje de descripción idealizado de antes para describir la información del modelo del sistema. Para hacer referencia a cada objeto de forma diferenciada en el modelo del sistema, utilizamos un identificador de marcador de posición para cada objeto, y conectamos las propiedades a ese identificador:

# Describe 'Node1' (the client)
Node1.name: client
Node1.is_type: software
Node1.source_language: c
Node1.packaged_type: binary

# Describe 'Node2' (the server)
Node2.name: server
Node2.is_type: software

# Describe 'Node3' (an exposed port)
Node3.is_type: port
Node3.port: 8080
Node3.protocol: http

# Establish the relationships
Node2.exposes.port: Node3
Node1.connects_to: Node3

# Describe the data that will be passed on the channel
Data1.is_type: credential
Data1.requires: [confidentiality, integrity, privacy]
Data1.metadata.description: "Data contains a credential to be checked by
the server"

Data2.is_type: credential
Data2.requires: [confidentiality, integrity]
Data2.metadata.description: "Data contains a session token that gives/
 authorization to perform actions"

Node3.data.incoming = Data1
Node3.data.outbound = Data2

Ahora bien, obviamente, en el ejemplo anterior (que nos hemos inventado por completo y creado sólo con fines explicativos), puedes notar una o dos cosas preocupantes. Tu cerebro humano es capaz de hacer inferencias sobre el significado de las propiedades y el aspecto que podría tener el sistema. En el Capítulo 3, aprendiste a determinar algunas de las vulnerabilidades que pueden existir en un sistema de ejemplo.

Pero, ¿cómo hará el programa informático esta misma tarea? Tiene que estar programado para hacerlo: necesita un conjunto de reglas y estructuras para unir la información y obtener los resultados necesarios para el análisis.

Construir reglas significa examinar las fuentes de amenazas disponibles e identificar los "indicadores" que revelan que una amenaza es posible. La lista de Conceptos Arquitectónicos CWE o Mecanismos de Ataque CAPEC son repositorios que constituyen excelentes recursos atener en cuenta.

Nota

Habrás observado que nos referimos a las bases de datos CWE y CAPEC varias veces a lo largo del libro. Nos gusta especialmente utilizarlas como recursos centrales porque son abiertas, públicas y están llenas de información consumible y aplicable que ha sido aportada por expertos de toda la comunidad de seguridad.

Para nuestra demostración, veamos dos posibles fuentes de una regla:

La CWE-319 nos dice que la debilidad se produce cuando "el software transmite datos sensibles o críticos para la seguridad en texto claro en un canal de comunicación que puede ser olfateado por actores no autorizados". A partir de esta sencilla descripción, deberías ser capaz de identificar los indicadores que deben estar presentes para que exista una amenaza potencial en un sistema:

Un proceso: Realiza una acción.
"Transmite": La unidad de software se comunica con otro componente.
"Datos sensibles o críticos para la seguridad": Datos de valor para un atacante.
Sin encriptación: En el canal o protegiendo directamente los paquetes de datos (es necesario que se dé una de estas condiciones).
Impacto: Confidencialidad.

CAPEC-157 describe un ataque contra información sensible como "en este patrón de ataque, el adversario intercepta información transmitida entre dos terceros. El adversario debe ser capaz de observar, leer y/o escuchar el tráfico de comunicación, pero no necesariamente bloquear la comunicación o cambiar su contenido. En teoría, cualquier medio de transmisión puede ser interceptado si el adversario puede examinar el contenido entre el emisor y el receptor." A partir de esta descripción, obtenemos detalles de cómo un atacante puede realizar este ataque:

Se intercepta el tráfico entre dos partes (puntos finales).
El ataque es pasivo; no se espera ninguna modificación ni denegación de servicio.
El atacante (actor) necesita acceder al canal de comunicación.

Así pues, con estas dos descripciones, podríamos considerar las siguientes reglas unificadas (en texto):

El punto final de origen se comunica con el punto final de destino.
El flujo de datos entre puntos finales contiene datos sensibles.
El flujo de datos no está protegido en cuanto a confidencialidad.

El impacto de la presencia de estas condiciones en un sistema permitiría a un actor malicioso obtener datos sensibles mediante sniffing.

El código para identificar este patrón e indicar la condición de existencia de amenaza podría parecerse (en pseudocódigo, sin todas las comprobaciones de seguridad) a lo siguiente:

def evaluate(node n, "Threat from CWE-319"):
    if n.is_type is "software":
        for i in range(0, len(n.exposes)):
            return (n.exposes[i].p.data.incoming[0].requires.security)
            and
            (n.exposes[i].p.provides.confidentiality)

Éste es un ejemplo extremadamente simplificado de lo que podría conseguir una herramienta o automatización. Sin duda existen algoritmos más eficientes para realizar esta concordancia de patrones, pero esperamos que este ejemplo te dé una idea de cómo el modelado de amenazas utiliza el código para realizar la detección automática de amenazas.

Aunque el modelado de amenazas con código es un truco bastante ingenioso, el modelado de amenazas a partir del código hace que la tecnología sea potencialmente más accesible. En este paradigma, en lugar de utilizar código para ayudar a gestionar la información sobre amenazas, o utilizar un programa para analizar una descripción textual de un modelo "con código" para hacer coincidir construcciones con reglas para determinar amenazas, se escribe un programa real que, cuando se ejecuta, realiza el análisis del modelado de amenazas y la representación "automáticamente".

Para que esto sea posible, el autor de un programa necesita crear una lógica de programa y APIs para describir elementos, flujos de datos, etc. y las reglas por las que se analizarán. A continuación, los desarrolladores utilizan las API para crear programas ejecutables. La ejecución (con o sin precompilación, dependiendo del lenguaje elegido para las API) del código del programa da lugar a estos pasos básicos:

Traduce las directivas que describen objetos para construir una representación del sistema (como un gráfico, o sólo una matriz de propiedades, o en otra representación interna del programa).
Carga un conjunto de reglas.
Recorre el gráfico de objetos realizando la comparación de patrones con el conjunto de reglas para identificar los hallazgos.
Genera resultados basados en plantillas para dibujar el gráfico como un diagrama que sea (esperemos) visualmente aceptable para un humano y para dar salida a los detalles de los resultados.

Escribir código para autogenerar información sobre amenazas proporciona algunas ventajas:

Como programador, ya estás acostumbrado a escribir código, así que esto te ofrece la oportunidad de tener algo procesable en tus propios términos.
El modelado de amenazas como código se alinea perfectamente con las filosofías de todo como código o DevOps.
Puedes registrar código y mantenerlo bajo control de revisión en herramientas a las que tú, como desarrollador, ya estás acostumbrado, lo que debería ayudar a la adopción, así como a la gestión de la información.
Si las API y las bibliotecas que se construyen para contener los conocimientos y la experiencia de los profesionales de la seguridad admiten la capacidad de cargar dinámicamente reglas para el análisis, el mismo programa puede dar servicio a múltiples dominios. Un programa puede volver a analizar un sistema previamente descrito en código a medida que nuevas investigaciones o inteligencia sobre amenazas revelen nuevas amenazas, de modo que siempre estén actualizadas, sin cambiar el modelo ni tener que rehacer ningún trabajo.

Sin embargo, este método también tiene algunas desventajas que hay que tener en cuenta:

Los desarrolladores como tú ya escriben código todos los días para aportar valor a tu empresa o a tus clientes. Escribir código adicional para documentar tu arquitectura puede parecer una carga adicional.
Con tantos lenguajes de programación disponibles hoy en día, la probabilidad de que encuentre un paquete de código que utilice (o admita la integración con) un lenguaje que utilice tu equipo de desarrollo puede ser todo un reto.
La atención sigue centrándose en los desarrolladores que, como guardianes del código, necesitan las habilidades para comprender conceptos como la programación orientada a objetos y las funciones (y las convenciones de llamada, etc.).

Estos retos no son insuperables; sin embargo, el espacio del modelado de amenazas a partir del código aún está inmaduro. El mejor ejemplo que podemos ofrecer de módulo de código y API para realizar modelado de amenazas a partir del código es pytm.

Nota

Descargo de responsabilidad: estamos muy, muy, muy predispuestos hacia pytm, como creadores/líderes del proyecto de código abierto. Queremos ser justos en este libro con todas las grandes innovaciones en el campo de la automatización del modelado de amenazas. Pero creemos sinceramente que pytm ha abordado una laguna en los métodos que se han puesto a disposición de los profesionales de la seguridad y los equipos de desarrollo que intentan hacer que el modelado de amenazas sea procesable y eficaz para ellos.

pytm

Una de las principales razones por las que escribimos este libro fue el sincero deseo de que las personas implicadas en el desarrollo tuvieran información inmediatamente accesible que les ayudara a desarrollar sus capacidades de seguridad en el ciclo de vida del desarrollo de software seguro. Por eso hablamos de formación, del reto de "pensar como un hacker", de árboles de ataques y bibliotecas de amenazas, de motores de reglas y de diagramas.

Como profesionales experimentados de la seguridad, hemos oído muchos argumentos de los equipos de desarrollo contra el uso de herramientas de modelado de amenazas: "¡Es demasiado pesada!", "¡No es agnóstica a la plataforma; yo trabajo en X, y la herramienta sólo funciona en Y!", "¡No tengo tiempo para aprender una aplicación más, y ésta requiere que aprenda una sintaxis completamente nueva!". Aparte de la presencia de muchos signos de exclamación, un patrón común en estas declaraciones es que se pide al programador que salga de su zona de confort inmediata y añada una habilidad más a su caja de herramientas o que interrumpa un flujo de trabajo conocido y añada un proceso extraño. Así que pensamos, ¿y si en lugar de eso intentáramos aproximar el proceso de modelado de amenazas a uno ya familiar para el codificador?

Al igual que ocurre con el modelado continuo de amenazas (que describimos en profundidad en el Capítulo 5), basarse en herramientas y procesos de ya conocidos por el equipo de desarrollo ayuda a crear comunalidad y confianza en el proceso. Ya te sientes cómodo con ellos y los utilizas a diario.

Luego nos fijamos en la automatización. ¿Qué áreas del modelado de amenazas planteaban más retos al equipo de desarrollo? Aparecieron los sospechosos habituales: identificar amenazas, diagramar y anotar, y mantener actualizado el modelo de amenazas (y por extensión, el modelo del sistema) con el mínimo esfuerzo. Charlamos sobre los lenguajes de descripción, pero entraban en la categoría de "una cosa más que el equipo tiene que aprender", y su aplicación parecía pesada en el proceso de desarrollo, mientras los equipos intentaban hacerlo más ligero. ¿Cómo podíamos ayudar al equipo de desarrollo a cumplir su objetivo (eficacia/fiabilidad) y seguir alcanzando nuestro objetivo de educación en seguridad?

Entonces se nos ocurrió: ¿por qué no describir un sistema como una colección de objetos de una forma orientada a objetos, utilizando un lenguaje de programación conocido, fácil, accesible y existente, y generar diagramas y amenazas a partir de esa descripción? Añade Python, y ahí lo tienes: una biblioteca pitónica para el modelado de amenazas.

Disponible en https://oreil.ly/nuPja (y en https://oreil.ly/wH-Nl como proyecto de la Incubadora OWASP), en su primer año de vida, pytm ha captado el interés de muchos en la comunidad de modelado de amenazas. La adopción interna en nuestras propias empresas y en otras, las charlas y talleres de Jonathan Marcil en conferencias de seguridad populares como OWASP Global AppSec DC y los debates en la Cumbre de Seguridad Abierta, e incluso el uso por parte de Trail of Bits en su modelo de amenazas de Kubernetes, ¡indican que nos estamos moviendo en la dirección correcta!

Nota

pytm es una biblioteca de código abierto que se ha beneficiado enormemente de los debates, el trabajo y adiciones de personas como Nick Ozmore y Rohit Shambhuni, cocreadores de la herramienta; y Pooja Avhad y Jan Was, responsables de muchos parches y mejoras centrales. Esperamos la participación activa de la comunidad para mejorarla. ¡Considera esto una llamada a la acción!

Aquí tienes un ejemplo de descripción del sistema utilizando pytm:

#!/usr/bin/env python3   


from pytm.pytm import TM, Server, Datastore, Dataflow, Boundary, Actor, Lambda  


tm = TM("my test tm")  
tm.description = "This is a sample threat model of a very simple system - a /
web-based comment system. The user enters comments and these are added to a /
database and displayed back to the user. The thought is that it is, though /
simple, a complete enough example to express meaningful threats."

User_Web = Boundary("User/Web")   
Web_DB = Boundary("Web/DB")

user = Actor("User")   
user.inBoundary = User_Web   

web = Server("Web Server")
web.OS = "CloudOS"
web.isHardened = True   

db = Datastore("SQL Database (*)")
db.OS = "CentOS"
db.isHardened = False
db.inBoundary = Web_DB
db.isSql = True
db.inScope = False

my_lambda = Lambda("cleanDBevery6hours")
my_lambda.hasAccessControl = True
my_lambda.inBoundary = Web_DB

my_lambda_to_db = Dataflow(my_lambda, db, "(&lambda;)Periodically cleans DB")  
my_lambda_to_db.protocol = "SQL"
my_lambda_to_db.dstPort = 3306

user_to_web = Dataflow(user, web, "User enters comments (*)")
user_to_web.protocol = "HTTP"
user_to_web.dstPort = 80
user_to_web.data = 'Comments in HTML or Markdown'
user_to_web.order = 1   

web_to_user = Dataflow(web, user, "Comments saved (*)")
web_to_user.protocol = "HTTP"
web_to_user.data = 'Ack of saving or error message, in JSON'
web_to_user.order = 2

web_to_db = Dataflow(web, db, "Insert query with comments")
web_to_db.protocol = "MySQL"
web_to_db.dstPort = 3306
web_to_db.data = 'MySQL insert statement, all literals'
web_to_db.order = 3

db_to_web = Dataflow(db, web, "Comments contents")
db_to_web.protocol = "MySQL"
db_to_web.data = 'Results of insert op'
db_to_web.order = 4

tm.process()

: pytm es una biblioteca de Python 3. No hay disponible ninguna versión para Python 2.
: En pytm, todo gira en torno a los elementos. Los elementos específicos son Process, Server, Datastore, Lambda, (Confianza) Boundary, y Actor. El objeto TM contiene todos los metadatos sobre el modelo de amenaza, así como la potencia de procesamiento. Importa sólo lo que vaya a utilizar tu modelo de amenazas, o amplía Element en tus propios específicos (¡y luego compártelos con nosotros!)
: Instanciamos un objeto TM que contendrá toda la descripción de nuestro modelo.
: Aquí instanciamos un límite de confianza que utilizaremos para separar distintas áreas de confianza del modelo.
: También instanciamos un actor genérico para representar al usuario del sistema.
: E inmediatamente lo colocamos en el lado correcto de un límite de confianza.
: Cada elemento específico tiene atributos que influirán en las amenazas que se puedan generar. Todos ellos tienen valores por defecto comunes, y sólo debemos cambiar los que sean exclusivos del sistema.
: El elemento Dataflow enlaza dos elementos previamente definidos, y lleva detalles sobre la información que fluye, el protocolo utilizado y los puertos de comunicación en uso.
: Además de los DFD habituales, pytm también sabe generar diagramas de secuencia. Añadiendo un atributo .order a Dataflow, es posible organizarlos de forma que tengan sentido una vez expresados en ese formato.
: Tras declarar todos nuestros elementos y sus atributos, una llamada a TM.process() ejecuta las operaciones requeridas en la línea de comandos.

Además del análisis línea por línea, lo que podemos aprender de este trozo de código es que cada modelo de amenaza es un script individual separado. De este modo, un proyecto grande puede mantener los scripts pytm pequeños y colocados con el código que representan, de modo que puedan mantenerse actualizados y controlados por versiones más fácilmente. Cuando cambia una parte concreta del sistema, sólo es necesario editar y cambiar ese modelo de amenaza concreto. Esto concentra el esfuerzo en la descripción del cambio, y evita los errores que se cometen al editar una gran pieza de código.

En virtud de la llamada a process(), cada script pytm tiene el mismo conjunto de conmutadores y argumentos de la línea de comandos:

tm.py [-h] [--debug] [--dfd] [--report REPORT] [--exclude EXCLUDE] [--seq] /
[--lis] [--describe DESCRIBE]

optional arguments:
  -h, --help           show this help message and exit
  --debug              print debug messages
  --dfd                output DFD (default)
  --report REPORT      output report using the named template file /
(sample template file is under docs/template.md)
  --exclude EXCLUDE    specify threat IDs to be ignored
  --seq                output sequential diagram
  --list               list all available threats
  --describe DESCRIBE  describe the properties available for a given element

Destacan --dfd y --seq: generan los diagramas en formato PNG. El DFD lo genera pytm escribiendo en Dot, un formato consumido por Graphviz, y el diagrama de secuencia por PlantUML. También tiene soporte multiplataforma. Los formatos intermedios son textuales, por lo que puedes hacer modificaciones, y el diseño está gobernado por las herramientas respectivas y no por pytm. Trabajando así, cada herramienta puede centrarse en lo que mejor sabe hacer.²¹

Consulta las Figuras 4-4 y 4-5.

Poder diagramar a la velocidad del código ha demostrado ser una propiedad útil de pytm. Hemos visto cómo se anotaba código durante las reuniones iniciales de diseño para describir el sistema en juego. pytm permite a los miembros del equipo salir de una sesión de modelado de amenazas con una representación funcional de su idea que tiene el mismo valor que un dibujo en una pizarra, pero que se puede compartir, editar y en la que se puede colaborar inmediatamente. Este enfoque evita todos los escollos de las pizarras blancas ("¿Alguien ha visto los rotuladores? No, ¡los rotuladores negros!", "¿Puedes mover un poco la cámara? El resplandor oculta la mitad de la vista", "Sarah es la responsable de convertir el dibujo en un archivo Visio. Espera, ¿quién es Sarah?", y los temidos carteles de "No borrar").

Pero aunque todo eso es valioso, una herramienta de modelado de amenazas es bastante deficiente si no, bueno, revela las amenazas. pytm tiene esa capacidad, aunque con una advertencia: en esta fase de su desarrollo, nos preocupa más identificar las capacidades iniciales que ser exhaustivos en las amenazas identificadas. El proyecto comenzó con un subconjunto de amenazas que es aproximadamente paralelo a las capacidades de la Herramienta de Modelado de Amenazas de Microsoft descritas en este capítulo, y añadió algunas amenazas relacionadas con lambda. Actualmente, pytm reconoce más de 100 amenazas detectables, basándose en un subconjunto de CAPEC. Aquí puedes ver algunas de las amenazas que pytm es capaz de identificar (y se pueden listar todas las amenazas utilizando el modificador --list ):

INP01 - Buffer Overflow via Environment Variables
INP02 - Overflow Buffers
INP03 - Server Side Include (SSI) Injection
CR01 - Session Sidejacking
INP04 - HTTP Request Splitting
CR02 - Cross Site Tracing
INP05 - Command Line Execution through SQL Injection
INP06 - SQL Injection through SOAP Parameter Tampering
SC01 - JSON Hijacking (aka JavaScript Hijacking)
LB01 - API Manipulation
AA01 - Authentication Abuse/ByPass
DS01 - Excavation
DE01 - Interception
DE02 - Double Encoding
API01 - Exploit Test APIs
AC01 - Privilege Abuse
INP07 - Buffer Manipulation
AC02 - Shared Data Manipulation
DO01 - Flooding
HA01 - Path Traversal
AC03 - Subverting Environment Variable Values
DO02 - Excessive Allocation
DS02 - Try All Common Switches
INP08 - Format String Injection
INP09 - LDAP Injection
INP10 - Parameter Injection
INP11 - Relative Path Traversal
INP12 - Client-side Injection-induced Buffer Overflow
AC04 - XML Schema Poisoning
DO03 - XML Ping of the Death
AC05 - Content Spoofing
INP13 - Command Delimiters
INP14 - Input Data Manipulation
DE03 - Sniffing Attacks
CR03 - Dictionary-based Password Attack
API02 - Exploit Script-Based APIs
HA02 - White Box Reverse Engineering
DS03 - Footprinting
AC06 - Using Malicious Files
HA03 - Web Application Fingerprinting
SC02 - XSS Targeting Non-Script Elements
AC07 - Exploiting Incorrectly Configured Access Control Security Levels
INP15 - IMAP/SMTP Command Injection
HA04 - Reverse Engineering
SC03 - Embedding Scripts within Scripts
INP16 - PHP Remote File Inclusion
AA02 - Principal Spoof
CR04 - Session Credential Falsification through Forging
DO04 - XML Entity Expansion
DS04 - XSS Targeting Error Pages
SC04 - XSS Using Alternate Syntax
CR05 - Encryption Brute Forcing
AC08 - Manipulate Registry Information
DS05 - Lifting Sensitive Data Embedded in Cache

Como ya se ha mencionado, el formato que pytm utiliza para definir las amenazas está siendo revisado en para adaptarlo a un mejor motor de reglas y proporcionar más información. Actualmente, pytm define una amenaza como una estructura JSON con el siguiente formato:

{
   "SID":"INP01",
   "target": ["Lambda","Process"],
   "description": "Buffer Overflow via Environment Variables",
   "details": "This attack pattern involves causing a buffer overflow through/
 manipulation of environment variables. Once the attacker finds that they can/
 modify an environment variable, they may try to overflow associated buffers./
 This attack leverages implicit trust often placed in environment variables.",
   "Likelihood Of Attack": "High",
   "severity": "High",
   "condition": "target.usesEnvironmentVariables is True and target.sanitizesInp
ut is False and target.checksInputBounds is False",
   "prerequisites": "The application uses environment variables.An environment/
 variable exposed to the user is vulnerable to a buffer overflow.The vulnerable/
 environment variable uses untrusted data.Tainted data used in the environment/
 variables is not properly validated. For instance boundary checking is not /
done before copying the input data to a buffer.",
   "mitigations": "Do not expose environment variables to the user.Do not use /
untrusted data in your environment variables. Use a language or compiler that /
performs automatic bounds checking. There are tools such as Sharefuzz [R.10.3]/
 which is an environment variable fuzzer for Unix that support loading a shared/
 library. You can use Sharefuzz to determine if you are exposing an environment/
 variable  vulnerable to buffer overflow.",
   "example": "Attack Example: Buffer Overflow in $HOME A buffer overflow in
   sccw allows local users to gain root access via the $HOME
   environmental variable. Attack Example: Buffer Overflow in TERM A
   buffer overflow in the rlogin program involves its consumption of
   the TERM environment variable.",
   "references": "https://capec.mitre.org/data/definitions/10.html, CVE-1999-090
6, CVE-1999-0046, http://cwe.mitre.org/data/definitions/120.html, http://cwe.mit
re.org/data/definitions/119.html, http://cwe.mitre.org/data/definitions/680.html
"
 },

El campo objetivo describe un único elemento o una tupla de posibles elementos sobre los que actúa la amenaza. El campo condición es una expresión booleana que se evalúa como Verdadero (la amenaza existe) o Falso (la amenaza no existe) en función de los valores de los atributos del elemento objetivo.

Advertencia

Curiosamente, el uso de la función eval() de Python para evaluar la expresión booleana en una condición introduce una posible vulnerabilidad en el sistema: si pytm está instalado en todo el sistema, por ejemplo, pero los permisos del archivo de amenazas son demasiado permisivos y cualquier usuario puede escribir nuevas amenazas, un atacante podría escribir y añadir su propio código Python como condición de amenaza, que se ejecutaría alegremente con los privilegios del usuario que ejecuta el script. Pretendemos arreglar esto en un futuro próximo, pero hasta entonces, ¡estás avisado!

Para completar el conjunto inicial de capacidades, añadimos una capacidad de elaboración de informes basada en plantillas .²² Aunque simple y sucinto, el mecanismo de plantillas es suficiente para proporcionar un informe utilizable. Permite crear informes en cualquier formato basado en texto, incluidos HTML, Markdown, RTF y texto simple. Nosotros hemos optado por Markdown:

# Threat Model Sample
***

## System Description
{tm.description}

## Dataflow Diagram
![Level 0 DFD](dfd.png)

## Dataflows
Name|From|To |Data|Protocol|Port
----|----|---|----|--------|----
{dataflows:repeat:{{item.name}}|{{item.source.name}}|{{item.sink.name}}/
|{{item.data}}|{{item.protocol}}|{{item.dstPort}}
}

## Potential Threats
{findings:repeat:* {{item.description}} on element "{{item.target}}"
}

Esta plantilla, aplicada al script anterior, generaría el informe que puedes ver en el Apéndice A.

Realmente esperamos seguir creciendo y desarrollando más capacidades en un futuro próximo, con la esperanza de reducir la barrera de entrada al modelado de amenazas por parte de los equipos de desarrollo, al tiempo que proporcionamos resultados útiles.

Threagile

Threagile, de Christian Schneider, es un sistema prometedor que acaba de entrar (en julio de 2020) en el espacio del modelado de amenazas como código. Actualmente está en modo oculto, pero pronto estará disponible en código abierto.

Al igual que pytm, Threagile entra en la categoría de modelado de amenazas con código, pero utiliza un archivo YAML de para describir el sistema que va a evaluar. Un equipo de desarrollo puede utilizar las herramientas que los miembros del equipo ya conocen, en su IDE nativo, y que se pueden mantener junto con el código del sistema que representa, controlado por versiones, compartido y en el que se puede colaborar. La herramienta está escrita en Go.

Dado que en el momento de escribir este artículo la herramienta aún está en desarrollo, te aconsejamos que visites el sitio web del autor de Threagile para ver ejemplos de los informes y diagramasgenerados.

Los elementos principales del archivo YAML que describe el sistema de destino son sus activos de datos, activos técnicos, enlaces de comunicación y límites de confianza. Por ejemplo, la definición de un activo de datos tiene el siguiente aspecto:

Customer Addresses:
	id: customer-addresses
	description: Customer Addresses
	usage: business
	origin: Customer
            owner: Example Company
            quantity: many
            confidentiality: confidential
	integrity: mission-critical
	availability: mission-critical
	justification_cia_rating: these have PII of customers and the system /
needs these addresses for sending invoices

En este momento, la definición de activos de datos es la principal diferencia de enfoque entre Threagile y pytm, ya que las definiciones de activos técnicos (en pytm, elementos como Server, Process, etc.), límites de confianza y enlaces de comunicación (flujos de datos pytm) siguen más o menos la misma amplitud de información sobre cada elemento específico del sistema.

Las diferencias son más marcadas en el sentido de que Threagile considera explícitamente distintos tipos de límites de confianza, como Red On Prem, Proveedor de Nube de Red y Grupo de Seguridad de Nube de Red (entre muchos otros), mientras que pytm no diferencia. Cada tipo impone una semántica diferente que interviene en la evaluación de las amenazas.

Threagile dispone de un sistema de plug-ins para soportar reglas que analizan el grafo del sistema descrito por la entrada YAML. En el momento de escribir esto, admite unas 35 reglas, pero se están añadiendo más. Una selección aleatoria de reglas de muestra muestra lo siguiente:

falsificación de petición de sitio cruzado
respaldo de código
inyección ldap
acceso-desprotegido-de-internet
servicio-registro-envenenamiento
transferencia-innecesaria-de-datos

A diferencia de pytm, que funciona como un programa de línea de comandos, Threagile también proporciona una API REST que almacena modelos (encriptados) y te permite editarlos y ejecutarlos. El sistema Threagile mantendrá el YAML de entrada en un repositorio, junto con el código que el YAML describe, y se puede indicar al sistema que realice el procesamiento a través de la CLI o de la API. La salida de Threagile consiste en lo siguiente:

Un informe de riesgos PDF
Una hoja de cálculo Excel de seguimiento de riesgos
Un resumen del riesgo con detalles del riesgo como JSON
Un DFD trazado automáticamente (con coloreado que expresa la clasificación de activos, datos y enlaces de comunicación)
Un diagrama de riesgos de los activos de datos

Este último diagrama es de especial interés, ya que expresa, para cada activo de datos, dónde se procesa y dónde se almacena, con colores que expresan el estado de riesgo por activo de datos y activo técnico. Que sepamos, ésta es la única herramienta que ofrece esa vista en este momento.

El formato del informe PDF generado es extremadamente detallado, y contiene toda la información necesaria para hacer llegar el riesgo a la dirección o para que los desarrolladores puedan mitigarlo. La clasificación STRIDE de las amenazas identificadas está presente, así como un análisis del impacto de los riesgos por categoría.

Estamos deseando ver más de esta herramienta y participar en su desarrollo, y te sugerimos encarecidamente que le eches un vistazo cuando se abra al público.

Visión general de otras herramientas de modelado de amenazas

Hemos intentado representar estas herramientas de la forma más imparcial posible, pero superar el sesgo de confirmación puede ser difícil. Cualquier error, omisión o tergiversación es responsabilidad exclusiva nuestra. Ningún proveedor o proyecto ha participado en esta revisión, y no sugerimos una herramienta sobre otra. La información que aquí se presenta es simplemente con fines educativos y para ayudarte a iniciar tu propia investigación.

IriusRiesgo

Metodologías aplicadas: Basadas en cuestionarios, biblioteca de amenazas

Propuesta principal: La edición gratuita/comunitaria de IriusRisk (ver Figura 4-6) ofrece la misma funcionalidad que la versión Enterprise, con una limitación en el tipo de informes que puede producir y en los elementos que ofrece en su menú para incluir en el sistema. La edición gratuita tampoco contiene una API, pero es suficiente para mostrar las capacidades de la herramienta. La Figura 4-6 muestra un ejemplo de los resultados del análisis realizado por IriusRisk sobre el modelo de un sencillo sistema navegador/servidor. Su biblioteca de amenazas parece basarse al menos en CAPEC, con menciones a CWE; Web Application Security Consortium, o WASC; OWASP Top Ten; y OWASP Application Security Verification Standard (ASVS) y OWASP Mobile Application Security Verification Standard (MASVS).

Frescura: Actualizada constantemente

Obtener de: https://oreil.ly/TzjrQ

Un hallazgo típico en un informe IriusRisk contendría el componente donde se identificó, el tipo de fallo ("Acceso a datos sensibles"), una breve explicación de la amenaza ("Los datos sensibles se ven comprometidos mediante ataques contra SSL/TLS") y una representación gráfica/color del riesgo y el progreso de las contramedidas.

Al profundizar en una amenaza determinada se muestra un ID único (que contiene información CAPEC u otro índice), una división del impacto en confidencialidad, integridad y disponibilidad, una descripción más larga y una lista de referencias, debilidades asociadas y contramedidas que informarán al lector sobre cómo abordar el problema identificado.

Elementos SD

Metodologías aplicadas: Basadas en cuestionarios, biblioteca de amenazas

Propuesta principal: En el momento de escribir este artículo, en la versión 5, SD Elements pretende ser una solución de gestión de la seguridad de ciclo completo para tu empresa. Una de las capacidades que ofrece es el modelado de amenazas basado en cuestionarios. Dada una política de seguridad y cumplimiento predefinida, la aplicación intenta verificar la conformidad del sistema en desarrollo con esa política, sugiriendo contramedidas.

Frescura: Oferta comercial actualizada con frecuencia

Obtener de: https://oreil.ly/On7q2

ThreatModeler

Metodologías aplicadas: Diagramas de flujo del proceso; Amenaza Visual, Ágil y Simple (VAST); biblioteca de amenazas

Propuesta principal: ThreatModeler es una de las primeras herramientas de diagramación y análisis de modelado de amenazas disponibles comercialmente. ThreatModeler utiliza diagramas de flujo de procesos (que mencionamos brevemente en el Capítulo 1) e implementa el enfoque de modelado VAST para el modelado de amenazas.

Frescura: Oferta comercial

Obtener de: https://threatmodeler.com

Dragón de amenazas OWASP

Metodologías aplicadas: Biblioteca de amenazas basada en reglas, STRIDE

Propuesta principal: Threat Dragon es un proyecto que acaba de salir del estado de incubadora en OWASP. Es una aplicación de modelado de amenazas online y de escritorio (Windows, Linux y Mac) que proporciona una solución de diagramación (arrastrar y soltar), y un análisis basado en reglas de los elementos definidos, sugiriendo amenazas y mitigaciones. Esta herramienta multiplataforma y gratuita es utilizable y ampliable (ver Figura 4-7).

Frescura: En desarrollo activo, dirigido por Mike Goodwin y Jon Gadsden

Obtener de: https://oreil.ly/-n5uF

Observa en la Figura 4-7, que la DFD se ajusta a la simbología sencilla presentada a lo largo del libro; cada elemento tiene una hoja de propiedades que proporciona detalles y contexto sobre él. El elemento se muestra en el contexto del sistema completo, y se dispone de información básica sobre si está en el ámbito del modelo de amenaza, y qué contiene, y cómo se almacena o procesa.

Los usuarios también pueden crear sus propias amenazas, lo que añade un nivel de personalización que permite a una organización o equipo hacer hincapié en aquellas amenazas que son particulares de su entorno o del funcionamiento de su sistema. Existe una correlación directa con la elicitación de amenazas STRIDE y una simple clasificación de criticidad Alta/Media/Baja sin correlación directa con una puntuación CVSS.

Threat Dragon ofrece una completa capacidad de elaboración de informes que mantiene el diagrama del sistema en el punto de mira, y proporciona una lista de todos los hallazgos (con sus mitigaciones, si están disponibles) ordenados por elementos, o el motivo si un elemento determinado forma parte del diagrama pero está marcado como fuera del alcance del modelo de amenazas.

Herramienta de modelado de amenazas de Microsoft

Metodologías aplicadas: Dibujar y anotar, STRIDE

Proposición principal: Otra importante contribución de Adam Shostack y el Equipo SDL en Microsoft, la Herramienta de Modelado de Amenazas de Microsoft es una de las primeras apariciones en el espacio de las herramientas de modelado de amenazas. Inicialmente se basaba en una biblioteca de Visio (y, por tanto, requería una licencia para ese programa), pero esa dependencia se ha eliminado, y ahora la herramienta es una instalación independiente. Una vez instalada, ofrece opciones para añadir un nuevo modelo o plantilla, o cargar los existentes. La plantilla por defecto es una orientada a Azure, con una plantilla SDL genérica para los sistemas que no son específicos de Azure. Microsoft también admite una biblioteca de plantillas, que, aunque de momento no es muy extensa, es sin duda una contribución bienvenida al panorama. La herramienta utiliza una aproximación de la simbología DFD que usamos en el Capítulo 1, y ofrece herramientas que te permiten anotar cada elemento con atributos, tanto predefinidos como definidos por el usuario. Basándose en reglas preconfiguradas (que viven en un archivo XML y que, en teoría, pueden ser editadas por el usuario), la herramienta genera un informe del modelo de amenazas que contiene el diagrama, las amenazas identificadas (clasificadas según STRIDE) y algunos consejos de mitigación. Aunque los elementos y sus atributos están muy orientados a Windows, la herramienta tiene valor para los usuarios no Windows (véase la Figura 4-8).

Frescura: Parece que se actualiza cada dos años.

Obtener de: https://oreil.ly/YL-gI

Al igual que en otras herramientas, cada elemento puede editarse para proporcionar sus propiedades. La principal diferencia aquí es que algunas propiedades de los elementos están muy relacionadas con Windows; por ejemplo, el elemento Proceso del SO contiene propiedades como Ejecutar como, con Administrador como posible valor, o Tipo de código: Administrado. Cuando el programa genere amenazas, ignorará las opciones que no sean aplicables al entorno objetivo.

Los informes de esta herramienta están estrechamente ligados a STRIDE, y cada hallazgo tiene una categoría STRIDE, además de una descripción, una justificación, un estado de mitigación y unaprioridad.

CAIRIS

Metodologías aplicadas: Diseño de seguridad basado en activos y en amenazas

Propuesta principal: Creada y desarrollada por Shamal Faily, CAIRIS, que significa Integración Asistida por Ordenador de Requisitos y Seguridad de la Información, es una plataforma para crear representaciones de sistemas seguros centradas en el análisis de riesgos que se basa en los requisitos y la usabilidad. Una vez definido un entorno (es decir, un contenedor en el que existe el sistema: una encapsulación de activos, tareas, personas y atacantes, objetivos, vulnerabilidades y amenazas), puedes definir el contenido del entorno. Las personas definen a los usuarios, y las tareas describen cómo interactúan las personas con el sistema. Las personas también tienen roles, que pueden ser parte interesada, atacante, controlador de datos, procesador de datos y sujeto de datos. Las personas interactúan con los activos, que tienen propiedades como Seguridad y Privacidad (como CIA), Responsabilidad, Anonimato e Inobservabilidad, valoradas como Ninguna, Baja, Media y Alta. Las tareas modelan el trabajo que una o varias personas realizan en el sistema en viñetas específicas del entorno. CAIRIS es capaz de generar DFD UML con la simbología habitual, así como representaciones textuales de un sistema. El sistema es complejo, y nuestra descripción nunca le hará justicia, pero en el transcurso de nuestra investigación, CAIRIS nos intrigó lo suficiente como para justificar una exploración más profunda. Un libro de que amplía la herramienta y las formas de utilizarla, y que ofrece un curso completo sobre seguridad por diseño es Designing Usable and Secure Software with IRIS and CAIRIS, de Shamal Faily (Springer).

Frescura: En desarrollo activo

Obtener de: https://oreil.ly/BfW2l

Esponja marina Mozilla

Metodologías aplicadas: Impulsada visualmente, sin elicitación de amenazas

Propuesta principal: Mozilla SeaSponge es una herramienta basada en web que funciona en cualquier navegador relativamente moderno y proporciona una interfaz de usuario limpia y de buen aspecto, que también promueve una experiencia intuitiva. En este momento, no ofrece un motor de reglas ni una capacidad de elaboración de informes, y su desarrollo parece haber finalizado en 2015 (ver Figura 4-9).

Frescura: El desarrollo parece haberse estancado.

Obtener de: https://oreil.ly/IOlh8

Automatizador del Modelo de Amenaza Tutamen

Metodologías aplicadas: Visually driven, STRIDE y bibliotecas de amenazas

Propuesta principal: Tutamen Threat Model Automator es una oferta comercial de software como servicio (SaaS) (a partir de octubre de 2019, en beta gratuita) con un planteamiento interesante: sube un diagrama de tu sistema en formatos draw.io o Visio, o una hoja de cálculo Excel, y recibe tu modelo de amenazas. Debes anotar tus datos con metadatos relacionados con la seguridad, zonas de confianza y permisos que quieras asignar a los elementos. El informe generado identificará los elementos, los flujos de datos y las amenazas, y propondrá mitigaciones.

Frescura: Oferta comercial actualizada con frecuencia

Obtener de: http://www.tutamantic.com

Modelado de amenazas con ML e IA

Estamos en la era de "la IA lo resuelve todo".²³ Sin embargo, el estado de la industria de la seguridad es tal que no estamos preparados para dar ese salto (todavía) para el modelado de amenazas.

Se han realizado algunas investigaciones sobre el uso del aprendizaje automático (AM) y la IA en el modelado de amenazas. Esto es natural, dado que la IA actual es un avance de los sistemas expertos del pasado (reciente). Estos sistemas se basaban en reglas procesadas por motores de inferencia que intentaban satisfacer un conjunto de requisitos para que el sistema modelado alcanzara un estado satisfactorio. O los sistemas señalaban cualquier discrepancia que considerara imposible la solución. Suena familiar, ¿no?

El aprendizaje automático se basa en la premisa de que, tras clasificar suficientes datos, surgen patrones que te permiten clasificar cualquier dato nuevo. Intentar trasladar esto al ámbito del modelado de amenazas puede ser complicado. Por ejemplo, en el campo de la seguridad de las redes, es fácil generar grandes cantidades de datos con tráfico "bueno" y "malo" para entrenar un algoritmo de clasificación. Sin embargo, en el modelado de amenazas, puede que no exista un corpus suficiente de datos, lo que significa que serías incapaz de entrenar un algoritmo para reconocer las amenazas con fidelidad. Eso te devuelve inmediatamente al enfoque en el que una amenaza es la expresión de un estado no deseado causado por la configuración del sistema, en una constelación específica de elementos y atributos.

Los enfoques de aprendizaje automático para el modelado de amenazas siguen siendo principalmente un ejercicio académico, con pocos artículos publicados o pruebas de concepto que nos permitan demostrar un sistema de IA/ML que funcione.²⁴^,²⁵ Al menos una patente aborda ya una cadena genérica de modelado de amenazas mediante aprendizaje automático como la descrita anteriormente, pero a día de hoy no conocemos ningún prototipo funcional de una herramienta o un conjunto de datos que la soporte.

Incluso cuando se recurre a ellos y se aprovechan para mejorar la seguridad en otros sistemas, los sistemas de ML necesitan ser modelados para detectar amenazas. He aquí algunos ejemplos de investigaciones realizadas en este ámbito:

El Grupo NCC ha proporcionado los resultados de su investigación en este ámbito y ha desarrollado modelos de amenazas para los sistemas ML de que ponen de relieve cómo pueden ser atacados o utilizados indebidamente por adversarios sin escrúpulos.²⁶ Los investigadores del Grupo NCC utilizaron en su investigación una de las herramientas no ML más antiguas disponibles para el modelado de amenazas: la Herramienta de Modelado de Amenazas de Microsoft, Edición 2018.
Los investigadores del Instituto de Ingeniería Informática de la Universidad Tecnológica de Viena publicaron su modelo de amenazas para los mecanismos de entrenamiento e inferencia de algoritmos de ML, junto con un buen debate sobre las vulnerabilidades, los objetivos de los adversarios y las contramedidas para mitigar las amenazas identificadas.²⁷
El Instituto Berryville de Aprendizaje Automático, cofundado por el famoso científico de seguridad Gary McGraw, PhD, publicó un análisis del riesgo arquitectónico de los sistemas de ML que revela interesantes áreas de preocupación en el campo de la seguridad cuando se aplica a sistemas de ML (algunas de las cuales pueden aplicarse a su vez para detectar problemas de seguridad en otros sistemas).²⁸

El CWE de MITRE está empezando a incluir puntos débiles de seguridad para los sistemas de aprendizaje automático, con la adición del CWE-1039, "Mecanismo de Reconocimiento Automatizado con Detección o Manejo Inadecuados de Perturbaciones de Entrada Adversarias".

Resumen

En este capítulo, hemos analizado más detenidamente algunos de los retos existentes en el modelado de amenazas y cómo puedes superarlos. Aprendiste acerca de los lenguajes de descripción de arquitecturas y cómo proporcionan la base para la automatización del modelado de amenazas. Aprendiste sobre las distintas opciones para automatizar el modelado de amenazas, desde simplemente generar una mejor documentación de amenazas hasta realizar un modelado y análisis completos escribiendo código.

Hablamos de herramientas que utilizan técnicas de modelado de amenazas con código y de modelado de amenazas a partir del código (denominadas colectivamente en el sector modelado de amenazas como código), al tiempo que implementan las metodologías de modelado de amenazas del Capítulo 3. Algunas de estas herramientas también implementan otras funciones, como la orquestación de pruebas de seguridad. Te mostramos nuestra herramienta de modelado de amenazas desde el código, pytm, y terminamos discutiendo brevemente el reto de aplicar algoritmos de aprendizaje automático al modelado de amenazas.

En el próximo capítulo, echarás un vistazo al futuro próximo del modelado de amenazas con nuevas técnicas y tecnologías apasionantes.

¹ Randall Munroe, "Alicia y Bob", webcómic xkcd, https://xkcd.com/177.

² Algunas personas también utilizan la frase que engloba el modelado de amenazas como código para alinearse con la jerga DevOps. Al igual que DevOps (¡y su jerga!) hace un par de años, todo el vocabulario está en transición: mucha gente quiere decir muchas cosas diferentes con él, pero creemos que poco a poco se está uniendo una convención.

³ En la última comprobación, contamos más de 20 metodologías y variaciones.

⁴ "DtSR Episode 362-Real Security Is Hard", Down the Security Rabbit Hole Podcast, https://oreil.ly/iECWZ.

⁵ Ophir Tanz, "¿Puede la inteligencia artificial identificar imágenes mejor que los humanos?" Entrepreneur, abril de 2017, https://oreil.ly/Fe9w5.

⁶ Para más detalles, consulta la documentación de ThreatPlaybook, en https://oreil.ly/lhSPc.

⁷ Véase el Marco Robot, un marco de código abierto para pruebas, en https://oreil.ly/GWGKP.

⁸ La autobiografía de A. Wymore está disponible en este sitio de la Universidad de Arizona.

⁹ Puedes consultar un estudio de los ADL en "Lenguajes de descripción de arquitecturas", de Stefan Bjornander, https://oreil.ly/AKo-w.

¹⁰ "Páginas de recursos de la AADL", Open AADL, http://www.openaadl.org.

¹¹ Hay muchas formas posibles de representar objetos dentro de un sistema; aquí se muestra un conjunto idealizado o representativo de propiedades basado en nuestra investigación. La lista se ha modificado para incluirla en este texto, y el original puede consultarse en https://oreil.ly/Vdiws.

¹² Como en todo buen código, lo mejor es la simplicidad para que el programa fluya de forma inteligible al "siguiente mantenedor".

¹³ Para los lectores que no estén familiarizados con I2C, consulta la página Conceptos básicos del circuito del protocolo de comunicación I2C de Scott Campbell.

¹⁴ Véase "Registro de nombres de servicio y números de puerto de protocolo de transporte", IANA, https://oreil.ly/1XktB.

¹⁵ Para una discusión sobre perímetros y grafos, véase "Teoría de Grafos" de Victor Adamchik, https://oreil.ly/t0bYp.

¹⁶ Michael N. Johnstone, "Modelado de amenazas con Stride y UML", Conferencia Australiana sobre Gestión de la Seguridad de la Información, noviembre de 2010, https://oreil.ly/QVU8c.

¹⁷ "¿Cuál es la relación entre SysML y UML?" Foro SysML, consultado en octubre de 2020, https://oreil.ly/xL7l2.

¹⁸ Aleksandr Kerzhner et al., "Analyzing Cyber Security Threats on Cyber-Physical Systems Using Model-Based Systems Engineering ", https://oreil.ly/0ToAu.

¹⁹ Robert Oates y otros, "Security-Aware Model-Based Systems Engineering with SysML ", https://oreil.ly/lri3g.

²⁰ Pista: Utilizar este modelo de sistema conlleva al menos cinco amenazas potenciales, como la suplantación de identidad y el robo de credenciales.

²¹ Graphviz tiene paquetes para los principales sistemas operativos.

²² Véase "El motor de plantillas Python más sencillo del mundo" de Eric Brehault, https://oreil.ly/BEFIn.

²³ Corey Caplette, "Más allá del bombo publicitario: The Value of Machine Learning and AI (Artificial Intelligence) for Business (Part 1)", Towards Data Science, mayo de 2018, https://oreil.ly/324W3.

²⁴ Mina Hao, "Machine Learning Algorithms Power Security Threat Reasoning and Analysis", NSFOCUS, mayo de 2019, https://oreil.ly/pzIQ9.

²⁵ M. Choras y R. Kozik, ScienceDirect, "Técnicas de aprendizaje automático para el modelado y la detección de amenazas", 6 de octubre de 2017, https://oreil.ly/PQfUt.

²⁶ "Building Safer Machine Learning Systems-A Threat Model", NCC Group, agosto de 2018, https://oreil.ly/BRgb9.

²⁷ Faiq Khalid y otros, "Seguridad para los sistemas basados en el aprendizaje automático: Ataques y desafíos durante el entrenamiento y la inferencia", Universidad de Cornell, noviembre de 2018, https://oreil.ly/2Qgx7.

²⁸ Gary McGraw y otros, "An Architectural Risk Analysis of Machine Learning Systems", BIML, https://oreil.ly/_RYwy.

Get Modelización de amenazas now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Capítulo 4. Modelización automatizada de amenazas

¿Por qué automatizar el modelado de amenazas?

Figura 4-1. "Script de shell muy pequeño" (fuente: https://oreil.ly/W0Lqo)

Modelado de amenazas a partir del código

Nota

Cómo funciona

Threatspec

Nota

Nota

ThreatPlaybook

Nota

Modelado de amenazas con código

Cómo funciona

Nota

Lenguaje minimalista de descripción de arquitecturas para el modelado de amenazas

Elementos y colecciones

Puertos

Datos y flujos de datos

Otros idiomas de descripción de modelos

Análisis de gráficos y metadatos

Figura 4-2. Modelo simple de sistema cliente/servidor

Figura 4-3. Modelo de sistema cliente/servidor simple revisado

Nota

Nota

pytm

Nota

Figura 4-4. Representación DFD del código de muestra

Figura 4-5. El mismo código, ahora representado como un diagrama de secuencia

Advertencia

Threagile

Visión general de otras herramientas de modelado de amenazas

IriusRiesgo

Figura 4-6. Resultados del análisis en tiempo real de IriusRisk

Elementos SD

ThreatModeler

Dragón de amenazas OWASP

Figura 4-7. Un sistema de muestra, disponible como demostración

Herramienta de modelado de amenazas de Microsoft

Figura 4-8. DFD del sistema de demostración de muestra proporcionado con la herramienta

CAIRIS

Esponja marina Mozilla

Figura 4-9. Interfaz de usuario de Mozilla SeaSponge

Automatizador del Modelo de Amenaza Tutamen

Modelado de amenazas con ML e IA

Resumen

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly