Modelización de amenazas

Capítulo 1. Modelización de sistemas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Todos los modelos son erróneos, pero algunos son útiles.

G. E. P. Box, "Ciencia y Estadística", Journal of the American Statistical Association, 71 (356), 791-799, doi:10.1080/01621459.1976.10480949.

El modelado del sistema (crear abstracciones o representaciones de un sistema) es un primer paso importante en el proceso de modelado de amenazas. La información que reúnas a partir del modelo del sistema proporciona la entrada para el análisis durante la actividad de modelado de amenazas.

En este capítulo trataremos los distintos tipos de modelos de sistemas, las razones por las que puedes elegir un tipo de modelo en lugar de otro y una guía para crear los modelos de sistemas más eficaces. El dominio experto de la construcción de modelos de sistemas informará tus modelos de amenazas y conducirá a un análisis y una identificación de amenazas más precisos y eficaces.

Nota

A lo largo de este capítulo, utilizamos las palabras modelo o modelado para referirnos a una abstracción o representación de un sistema, sus componentes e interacciones.

Por qué creamos modelos de sistemas

Imagina, si quieres, a un grupo de monjes benedictinos mirando la iglesia monástica de San Gall y luego un manuscrito, de un lado a otro. En algún momento, uno se vuelve hacia los demás y dice: "Bueno, escuchad, no era un plan en sí. Era más bien una 'meditación bidimensional sobre la comunidad monástica ideal altomedieval'".¹ Tal es el propósito asociado al Plano de San Galo, reconocido actualmente como la visualización y el plano 2D más antiguos conservados de un complejo de edificios. La iglesia tiene un aspecto muy diferente al del plano.

Los humanos creamos modelos para planificar con antelación o para decidir qué recursos pueden ser necesarios, qué marcos hay que establecer, qué colinas hay que mover, qué valles hay que rellenar y cómo interactuarán las piezas independientes una vez unidas. Los humanos creamos modelos porque es más fácil visualizar los cambios a una escala esquemática y menor que embarcarse en la construcción de inmediato. Es más fácil y barato hacer cambios en ese esquema, y cambiar la forma en que interactúan esas piezas, que mover paredes, armazones, tornillos, motores, suelos, alas, cortafuegos, servidores, funciones o líneas de código, a posteriori.

También reconocemos que, aunque el modelo y el resultado final puedan diferir, tener un modelo siempre ayudará a comprender matices y detalles relevantes para el proceso de fabricación y construcción. A efectos de seguridad, modelamos los sistemas de software y hardware, en particular, porque nos permite someter los sistemas a tensiones teóricas, comprender cómo afectarán esas tensiones a los sistemas antes de implementarlos, y ver los sistemas de forma holística para poder centrarnos en los detalles de la vulnerabilidad según sea necesario.

En el resto de este capítulo, te mostraremos las distintas formas visuales que puede adoptar tu modelo de amenazas y te explicaremos cómo reunir la información necesaria para apoyar el análisis del sistema. Las acciones concretas que emprendas tras construir tu modelo dependerán de la metodología que elijas seguir; llegaremos a las metodologías en los próximos capítulos.

Tipos de modelado del sistema

Como sabes, los sistemas pueden ser complejos, con muchas piezas móviles e interacciones entre sus componentes. Los seres humanos no nacen con amplios conocimientos de seguridad (aunque conocemos a algunos que bien podrían haberlo sido), y la mayoría de los diseñadores y desarrolladores de sistemas no están íntimamente familiarizados con la forma en que se puede abusar o hacer un mal uso de la funcionalidad. Por eso, quienes quieran asegurarse de que el análisis de su sistema es práctico y eficaz, tienen que reducir la complejidad y la cantidad de datos a tener en cuenta para el análisis y mantener la cantidad adecuada de información.

Aquí es donde el modelado del sistema, o una abstracción de un sistema que describa sus partes y atributos más destacados, viene al rescate. Disponer de una buena abstracción del sistema que quieres analizar te dará suficiente información para tomar decisiones de seguridad y diseño con conocimiento de causa.

Los modelos se han utilizado durante siglos para expresar ideas o transmitir conocimientos a otras personas. Los constructores de tumbas de la antigua China creaban maquetas de edificios,² y los arquitectos desde los antiguos egipcios han creado habitualmente modelos a escala para demostrar la viabilidad y las intenciones de un diseño.³

La creación de un modelo de sistema -una abstracción o representación de un sistema que se va a analizar en busca de amenazas- puede hacer uso de uno o varios tipos de modelo :⁴

Diagramas de flujo de datos

Los diagramas de flujo de datos (DFD) describen el flujo de datos entre los componentes de un sistema y las propiedades de cada componente y flujo. Los DFD son la forma más utilizada de modelos de sistemas en el modelado de amenazas y son compatibles de forma nativa con muchos paquetes de dibujo; las formas de los DFD también son fáciles de dibujar a mano para los humanos.

Diagramas de secuencia

Son diagramas de actividad en Lenguaje Unificado de Modelado (UML) que describen las interacciones de los componentes del sistema de forma ordenada. Los diagramas de secuencia pueden ayudar a identificar amenazas contra un sistema porque permiten al diseñador comprender el estado del sistema a lo largo del tiempo. Esto te permite ver cómo cambian las propiedades del sistema, y cualquier suposición o expectativa sobre ellas, a lo largo de su funcionamiento.

Diagramas de flujo del proceso

Los diagramas de flujo de procesos (PFD) ponen de relieve el flujo operativo a través de las acciones entre los componentes de un sistema.

Árboles de ataque

Los árboles de ataque representan los pasos a lo largo de una ruta que un atacante podría intentar como parte de su objetivo de realizar acciones con intención nefasta.

Diagramas de espina de pescado

También conocidos como diagramas de causa y efecto o de Ishikawa, muestran las relaciones entre un resultado y la(s) causa(s) raíz(es) que permitieron que se produjera dicho efecto.

Por separado o en conjunto, puedes utilizar estas técnicas de modelado de sistemas para ver eficazmente los cambios en la postura de seguridad que facilitan el trabajo de un atacante. Esto es importante para ayudar a los diseñadores a reconocer y eliminar posibles problemas cambiando sus diseños o supuestos del sistema. Utiliza distintos tipos de modelos para los fines para los que son más adecuados. Por ejemplo, utiliza los DFD para describir las relaciones entre objetos, y los diagramas de secuencia para describir el orden de las operaciones. Exploraremos cada uno de ellos con cierto detalle, para que puedas comprender las ventajas de cada uno.

Diagramas de flujo de datos

Al modelar un sistema para realizar un análisis de seguridad, los expertos identificaron los DFD como una forma útil de describir visualmente un sistema. Las DFD se desarrollaron con una simbología que expresa la complejidad de los sistemas.

El uso de modelos para comprender los componentes de un sistema y cómo se relacionan entre sí surgió en los años 50 con el diagrama de bloques de flujo funcional. Más tarde, en los años 70, la técnica de análisis y diseño estructurados introdujo el concepto de DFD.⁵ Los DFD se han convertido en una forma estándar de describir un sistema cuando se realiza un análisis de amenazas.

Los DFD tienen niveles

Los diagramas de flujo de datos suelen dar lugar a varios dibujos, cada uno de los cuales indica una capa o nivel de abstracción. La capa superior se denomina a veces capa de contexto, o capa 0 o simplemente L0, y contiene el sistema desde una visión de alto nivel y sus interacciones con entidades externas, como sistemas remotos o usuarios. Las capas siguientes, denominadas L1, L2 y así sucesivamente, profundizan en más detalles sobre los componentes individuales del sistema y sus interacciones, hasta que se haya alcanzado el nivel de detalle deseado o no se pueda obtener ningún valor adicional de una mayor descomposición de los elementos del sistema.

Aunque no existe una norma formal que defina las formas utilizadas al modelar el flujo de datos de un sistema, muchos paquetes de dibujo utilizan una convención para asociar las formas y su significado y uso.

Al construir DFD, nos parece útil destacar elementos arquitectónicos concretos junto a los flujos de datos. Esta información adicional puede ser útil cuando setrata de tomar decisiones precisas al analizar el modelo por motivos de seguridad, o cuando se utiliza el modelo para educar a personas nuevas en el proyecto. Incluimos tres formas de extensión no estándar para tu consideración; funcionan como atajos que pueden hacer que tus modelos sean más fáciles de crear y comprender.

Un elemento (mostrado en la Figura 1-1) es una forma estándar que representa un proceso o unidad operativa dentro del sistema considerado. Siempre debes etiquetar tu elemento, para que se pueda hacer referencia a él fácilmente en el futuro. Los elementos son la fuente y/o el destino de los flujos de datos (descritos más adelante) hacia y desde otras unidades del modelo. Para identificar a los actores humanos, utiliza el símbolo del actor (consulta la Figura 1-4 para ver un ejemplo).

Figura 1-1. Símbolos de elementos para dibujar diagramas de flujo de datos

También debes anotar cada objeto con una descripción de sus propiedades básicas y metadatos. Puedes poner la anotación en el propio diagrama, o en un documento aparte, y luego utilizar la etiqueta para asociar la anotación al objeto.

La siguiente es una lista de información potencial que podrías querer capturar en anotaciones para objetos del modelo:

Nota

Esta lista de posibles metadatos a obtener sobre un elemento, como anotaciones al modelo, no es exhaustiva. La información que necesitas saber sobre los elementos de tu sistema depende de la metodología que finalmente decidas utilizar (véanse los Capítulos 3 a 5), así como de las amenazas que intentes identificar. Esta lista presenta algunas de las opciones que puedes encontrar.

• Nombre de la unidad. Si es un ejecutable, ¿cómo se llama cuando se construye o se instala en un disco?

• ¿Quién es el propietario dentro de tu organización (el equipo de desarrollo, normalmente)?

• Si se trata de un proceso, ¿a qué nivel de privilegios se está ejecutando (por ejemplo, siempre root, o setuid, o algún usuario sin privilegios)?

• Si se trata de un objeto binario, ¿se espera que esté firmado digitalmente y, en caso afirmativo, con qué método y/o qué certificado o clave?

• ¿Qué lenguaje o lenguajes de programación se utilizan para el elemento?

• Para el código gestionado o interpretado, ¿qué procesador de tiempo de ejecución o de código de bytes se utiliza?

Nota

La gente suele pasar por alto la influencia de su elección de lenguaje de programación. Por ejemplo, C y C++ son más propensos a errores basados en la memoria que un lenguaje interpretado, y un script se prestará más fácilmente a la ingeniería inversa que un binario (posiblemente ofuscado). Estas son características importantes que debes comprender durante el diseño del sistema, especialmente si las identificas mientras estás modelando las amenazas, para evitar problemas de seguridad comunes y graves. Si no conoces esta información lo suficientemente pronto en el proceso de desarrollo del sistema como para incluirla en el modelo de amenazas (porque, como ya sabrás a estas alturas, el modelado de amenazas debe hacerse pronto y con frecuencia), éste es un ejemplo perfecto de por qué los modelos de amenazas deben mantenerse actualizados a medida que evoluciona el sistema. ⁶

Hay algunos metadatos adicionales, que proporcionan contexto y oportunidades para una evaluación más profunda, así como el debate entre los equipos de desarrollo y las partes interesadas del sistema, que tal vez quieras tener en cuenta:

• ¿La unidad está preparada para la producción o es una unidad de desarrollo , o el elemento sólo existe a tiempo parcial? Por ejemplo, ¿la unidad sólo existe en sistemas de producción, pero no en modo de desarrollo? Esto puede significar que el proceso representado por el elemento no se ejecute o no se inicialice en determinados entornos. O puede no estar presente, por ejemplo, porque se compila cuando se activan determinados indicadores de compilación. Un buen ejemplo de esto es un módulo de prueba o un componente que sólo se aplica en un entorno de ensayo para facilitar las pruebas. Sería importante señalarlo en el modelo de amenazas. Si el módulo funciona a través de determinadas interfaces o API que están abiertas en el entorno de pruebas para facilitar las pruebas, pero siguen abiertas en producción aunque se haya eliminado el módulo de pruebas, se trata de un punto débil que hay que abordar.

• ¿Existe información sobre su flujo de ejecución previsto, y puede describirse mediante una máquina de estados o un diagrama de secuencia? Los diagramas de secuencia pueden ayudar a identificar puntos débiles, como veremos más adelante en este capítulo.

• Opcionalmente, ¿utiliza o tiene activadas banderas específicas desde la compilación, enlazado o instalación,⁷ ¿o está cubierto por una política SELinux distinta de la predeterminada del sistema? Como ya se ha dicho, puede que no sepas esto cuando construyas el primer modelo de amenazas, pero te ofrece otra oportunidad de añadir valor manteniendo actualizado el modelo de amenazas a lo largo del proyecto.

Utiliza el símbolo de elemento para mostrar una unidad de procesamiento autónoma, como un ejecutable o un proceso (según el nivel de abstracción), en la que subdividir el elemento en componentes representativos probablemente no ayude a comprender cómo funciona la unidad y a qué amenazas puede ser susceptible. Esto puede requerir cierta práctica: a veces puede ser necesario describir los subelementos de la unidad de procesamiento para comprender mejor las interacciones que contiene. Para describir los subelementos, utiliza un símbolo contenedor.

Un contenedor, o elemento contenedor, mostrado en la Figura 1-2, es otra forma estándar que representa una unidad dentro del sistema considerado que contiene elementos y flujos adicionales. Esta forma suele utilizarse en la capa de contexto (ver "Las DFD tienen niveles") de un modelo, destacando las unidades principales dentro del sistema. Cuando creas elementos contenedores, estás señalando la necesidad de comprender los elementos contenidos, y que el contenedor representa las interacciones y supuestos combinados de todos los elementos incluidos. También es una buena forma de reducir el recargamiento de un modelo al dibujarlo. Los contenedores pueden ser la fuente y/o el destino de los datos que fluyen hacia y desde otras entidades del modelo cuando están presentes en cualquier nivel de abstracción.

Figura 1-2. Símbolos contenedores para dibujar diagramas de flujo de datos

Al igual que con el elemento descrito anteriormente, debes asignar una etiqueta a tus objetos contenedores, e incluir metadatos para el objeto en sus anotaciones. Los metadatos deben incluir (al menos) cualquiera de los elementos de metadatos del elemento descrito anteriormente, además de un breve resumen de lo que contiene (es decir, los principales subsistemas o subprocesos que podrían encontrarse en su interior).

A diferencia de un elemento, que representa una unidad dentro del sistema considerado, una forma de entidad externa, mostrada en la Figura 1-3, representa un proceso o sistema que participa en la operación o función del sistema, pero que no está en el ámbito del análisis. Una entidad externa es una forma estándar. Como mínimo, las entidades externas ofrecen una fuente para los flujos de datos que llegan al sistema desde un proceso o mecanismo remoto. Ejemplos de entidades externas suelen ser los navegadores web utilizados para acceder a servidores web o servicios similares, pero pueden incluir cualquier tipo de componente o unidad de procesamiento.

Figura 1-3. Símbolo de entidad externa para dibujar diagramas de flujo de datos

Los actores (ver Figura 1-4), que representan principalmente a los usuarios humanos del sistema, son formas estándar que tienen conexiones con interfaces ofrecidas por el sistema (directamente, o a través de una entidad externa intermedia como un navegador web) y suelen utilizarse en la capa de contexto del dibujo.

Figura 1-4. Símbolo de actor para dibujar diagramas de flujo de datos

El símbolo de almacén de datos, que se muestra en la Figura 1-5, es una forma estándar que representa una unidad funcional que indica dónde se guardan datos "a granel", como una base de datos (pero no siempre el servidor de la base de datos). También podrías utilizar el símbolo de almacén de datos para indicar un archivo o búfer que contenga pequeñas cantidades de datos relevantes para la seguridad, como un archivo que contenga la clave privada del certificado TLS de tu servidor web,⁸ o para un almacén de datos de objetos, como un cubo de Amazon Simple Storage Service (S3) que contenga la salida del archivo de registro de tu aplicación. Los símbolos de almacén de datos también pueden representar un bus de mensajes, o una región de memoria compartida.

Figura 1-5. Símbolos del almacén de datos para dibujar diagramas de flujo de datos

Los almacenes de datos deben estar etiquetados y tener metadatos como los siguientes

Tipo de almacenamiento

¿Se trata de un archivo, un cubo de S3, una malla de servicio o una región de memoria compartida?

Tipo y clasificación de los datos conservados

¿Los datos que se envían a este módulo o se leen desde él son estructurados o no? ¿Están en algún formato concreto; por ejemplo, XML o JSON?

Sensibilidad o valor de los datos

¿Los datos gestionados son información personal, relevante para la seguridad o de naturaleza sensible?

Protecciones en el propio almacén de datos

Por ejemplo, ¿ofrece el mecanismo de almacenamiento raíz encriptación a nivel de unidad?

Replicación

¿Se replican los datos en un almacén de datos diferente?

Copia de seguridad

¿Se copian los datos a otro lugar por seguridad, pero con controles de seguridad y acceso potencialmente reducidos?

Consejo

Si estás modelando un sistema que contiene un servidor de bases de datos (como MySQL o MongoDB), tienes dos opciones a la hora de representarlo en un modelo: (a) utilizar el almacén de datos para representar tanto el proceso del SGBD como la ubicación de almacenamiento de datos, o (b) un elemento para el SGBD y un almacén de datos conectado para la unidad de almacenamiento de datos real.

Cada opción conlleva ventajas e inconvenientes. La mayoría de la gente elegiría la opción (a), pero la opción (b) es especialmente útil con un análisis de amenazas eficaz para los modelos de sistemas en la nube e integrados, en los que los datos pueden vivir en canales de datos compartidos o nodos de almacenamiento temporal.

Si un elemento es autónomo y no tiene conexión con entidades externas, el elemento describe una pieza de funcionalidad segura, pero probablemente bastante inútil, dentro del sistema (¡esperemos que no sea tu única unidad dentro del sistema!). Para que una entidad tenga valor, al menos debe proporcionar datos o crear una función transformadora. La mayoría de las entidades también se comunican con unidades externas de alguna manera. Dentro de un modelo de sistema, utiliza los símbolos de flujo de datos para describir dónde y cómo se realizan las interacciones entre las entidades. El flujo de datos es en realidad un conjunto de símbolos que representan las múltiples formas en que pueden interactuar los componentes del sistema.

La Figura 1-6 muestra una línea básica, que indica una conexión entre dos elementos del sistema. No transmite, ni puede transmitir, ninguna información adicional, por lo que este símbolo es una opción excelente cuando no dispongas de esa información en el momento de realizar el ejercicio de modelado.

Figura 1-6. Símbolo de una línea para un flujo de datos básico no dirigido

La Figura 1-7 muestra una línea básica con una flecha en un extremo, que se utiliza para representar un flujo unidireccional de información o acción.

Figura 1-7. Símbolo de una flecha para el flujo de datos dirigido básico

En la Figura 1-8, la parte izquierda de la imagen muestra una línea básica con flechas en ambos extremos que representa un flujo de comunicación bidireccional. La parte derecha de la imagen muestra un símbolo alternativo para el flujo de comunicación bidireccional. Cualquiera de los dos es aceptable, aunque la versión de la derecha es más tradicional y más fácil de reconocer en un diagrama recargado (con el riesgo de que, como resultado, el diagrama quede demasiado recargado).

Figura 1-8. Flechas de dos puntas para el flujo bidireccional de datos

Las figuras 1-6, 1-7 y 1-8 son formas estándar en la construcción de diagramas de flujo de datos.

Nota

Ten en cuenta que estamos presentando convenciones, no reglas. Estas formas y lo que representan o cómo se utilizan en un diagrama proceden de la práctica colectiva, no de un documento oficial estándar.⁹ En nuestra práctica de modelado de amenazas, a veces nos resulta útil ampliar las formas y metadatos convencionales para adaptarlos mejor a nuestras necesidades. Verás algunas de estas extensiones en este capítulo y a lo largo del libro. Pero debes sentirte cómodo, una vez que te hayas familiarizado con los objetivos y los resultados esperados de la actividad, para hacer las modificaciones que creas oportunas. La personalización puede hacer que la actividad, la experiencia y la información obtenida a través de ella sean valiosas para ti y para los miembros del equipo implicados.

La Figura 1-9 muestra una forma de extensión no estándar (ver nota anterior) que proponemos por encima del conjunto normal de formas DFD. Esta forma es una flecha de una sola punta que indica dónde se originó la comunicación. La hemos rodeado con un círculo para resaltar la marca. La marca está disponible en plantillas de ingeniería para flujos de transmisión en los principales paquetes gráficos.

Figura 1-9. Marca de iniciador opcional

Los flujos de datos deben tener una etiqueta de referencia, y debes proporcionar los siguientes metadatos críticos:

Tipo o naturaleza del canal de comunicación

¿Se trata de un flujo de comunicación basado en la red o de una conexión local de comunicación entre procesos (IPC)?

Protocolo(s) en uso

Por ejemplo, ¿los datos transitan por HTTP o HTTPS? Si utiliza HTTPS, ¿se basa en certificados del lado del cliente para autenticar un punto final, o en TLS mutuo? ¿Los propios datos están protegidos de algún modo independientemente del canal (es decir, con cifrado o firma)?

Datos que se comunican

¿Qué tipo de datos se envían por el canal? ¿Cuál es su sensibilidad y/o clasificación?

Orden de operaciones (si procede o es útil para tus fines)

Si los flujos son limitados en cantidad dentro del modelo, o las interacciones no son muy complejas, puede ser posible indicar el orden de las operaciones o el orden de los flujos como parte de las anotaciones de cada flujo de datos, en lugar de crear un diagrama de secuencia independiente.

Nota

Ten cuidado al expresar la autenticación u otros controles de seguridad de en el propio flujo de datos. Los puntos finales (servidores o clientes) son responsables de, y/o "ofrecen", controles de acceso independientes de cualquier flujo de datos potencial entre ellos. Considera la posibilidad de utilizar el elemento de modelado ampliado de interfaz, descrito más adelante en esta sección, como un "puerto" para simplificar tu dibujo y facilitar un análisis más eficaz en busca de amenazas.

Ten en cuenta las siguientes consideraciones cuando utilices flujos de datos en tus modelos.

En primer lugar, utiliza flechas para indicar la dirección de los flujos de datos en tu diagrama y en tu análisis. Si tienes una línea que empieza en el elemento A y va hasta el elemento B, donde termina en una flecha (como se muestra en la Figura 1-7), indica que el flujo de comunicaciones significativas va de A a B. Se trata del intercambio de datos que tienen valor para la aplicación, o para un atacante, pero no necesariamente de paquetes y tramas individuales y acuses de recibo (ACK). Del mismo modo, una línea que empieza en B y termina en una flecha en A significaría que la comunicación fluye de B a A.

En segundo lugar, puedes elegir entre dos enfoques básicos para mostrar los flujos de comunicación bidireccionales en tu modelo: utilizar una sola línea con una flecha en cada extremo, como se muestra en la Figura 1-8 (izquierda), o utilizar dos líneas, una para cada dirección, como se muestra en la Figura 1-8 (derecha). El método de las dos líneas es más tradicional, pero son funcionalmente equivalentes. La otra ventaja de utilizar el método de dos líneas es que cada flujo de comunicación puede tener propiedades diferentes, por lo que tus anotaciones pueden quedar más limpias en el modelo utilizando dos líneas en lugar de una. Puedes elegir utilizar cualquiera de los dos métodos, pero sé coherente en todo tu modelo.

Por último, la finalidad de un flujo de datos en un modelo es describir la dirección principal de desplazamiento de las comunicaciones que es relevante a efectos de análisis. Si una ruta de comunicación representa cualquier protocolo estándar basado en el Protocolo de Control de Transmisiones (TCP) o en el Protocolo de Datagramas de Usuario (UDP), los paquetes y las tramas van y vienen por el canal desde el origen hasta el destino. Pero este nivel de detalle no suele ser importante para la identificación de amenazas.

En cambio, es importante describir que se están pasando datos o mensajes de control a nivel de aplicación por el canal establecido; esto es lo que se pretende transmitir con el flujo de datos. Sin embargo, a menudo es importante comprender para el análisis qué elemento inicia el flujo de comunicación. La Figura 1-9 muestra una marca que puedes utilizar para indicar el iniciador del flujo de datos.

El siguiente escenario pone de manifiesto la utilidad de esta marca para comprender el modelo y analizar el sistema.

El elemento A y el elemento B están conectados por un símbolo de flujo de datos unidireccional, con datos que fluyen de A a B, como se muestra en la Figura 1-10.

Figura 1-10. Elementos de muestra A y B

El elemento A está anotado como servicio A, mientras que el elemento B es el cliente del registrador. Podrías llegar a la conclusión de que B, como receptor de datos, inició el flujo de comunicación. O, alternativamente, puedes llegar a la conclusión de que A inició el flujo de datos, basando tu análisis en la etiqueta de cada punto final. En cualquiera de los dos casos, puede que tengas razón, porque el modelo es ambiguo.

Ahora bien, ¿qué ocurre si el modelo contiene la marca adicional de iniciador, adjunta al punto final en el elemento A? Esto indica claramente que el elemento A, y no el elemento B, inicia el flujo de comunicación y que empuja datos a B. Esto puede ocurrir en casos que estés modelando; por ejemplo, si estuvieras modelando un microservicio que empuja información de registro a un cliente de registro. Es un patrón arquitectónico habitual, que se muestra en la Figura 1-11.

Figura 1-11. Elementos de muestra A y B, con marca de iniciador en el elemento A

Sin embargo, si la marca iniciadora se coloca en B en lugar de en A, llegarías a una conclusión diferente sobre las amenazas potenciales con este segmento del modelo. Este diseño reflejaría un modelo alternativo en el que el cliente registrador, al estar quizás detrás de un cortafuegos, necesita comunicarse de salida con el microservicio en lugar de al revés (ver Figura 1-12).

Figura 1-12. Elementos de muestra A y B, con marca de iniciador en el elemento B

El símbolo que aparece en la Figura 1-13 se utiliza tradicionalmente para delinear un límite de confianza: todos los elementos de situados detrás de la línea (la curvatura de la línea determina lo que está detrás de la línea frente a lo que está delante) confían los unos en los otros. Básicamente, la línea de puntos identifica un límite en el que todas las entidades confían al mismo nivel. Por ejemplo, podrías confiar en todos los procesos que se ejecutan detrás de tu cortafuegos o VPN. Esto no significa que los flujos carezcan automáticamente de autentificación, sino que un límite de confianza significa que los objetos y entidades que operan dentro del límite lo hacen al mismo nivel de confianza (por ejemplo, el Anillo 0).

Este símbolo debe utilizarse al modelar un sistema en el que desees asumir una confianza simétrica entre los componentes del sistema. En un sistema que tenga una confianza asimétrica entre componentes (es decir, el componente A puede confiar en el componente B, pero el componente B no confía en el componente A), la marca de límite de confianza sería inadecuada, y deberías utilizar una anotación en el flujo de datos con información que describa larelación de confianza.

Figura 1-13. Símbolos de límites de confianza para dibujar diagramas de flujo de datos

A veces también se utiliza el mismo símbolo, como se muestra en la Figura 1-14, para indicar el esquema de protección de seguridad de un flujo de datos concreto, como marcar que el flujo de datos tiene confidencialidad e integridad mediante el uso de HTTPS. Una alternativa a este símbolo y anotación, que podría generar mucho desorden en modelos con un número significativo de componentes y/o flujos de datos, es proporcionar una anotación al propio flujo de datos.

Los metadatos necesarios para un límite de confianza, si se utiliza en el sentido tradicional (para denotar un límite más allá del cual todas las entidades tienen el mismo nivel de confianza), son una descripción de la relación de confianza simétrica de las entidades. Si este símbolo se utiliza para indicar un control sobre un canal o flujo, los metadatos deben incluir el protocolo o protocolos en uso (por ejemplo, HTTP o HTTPS, TLS mutuo o no), el número de puerto si no es el predeterminado, y cualquier información adicional sobre el control de seguridad que desees expresar.

Figura 1-14. Símbolo de un límite de confianza anotado

Un elemento de interfaz, marcado con un círculo en la Figura 1-15, es otra forma de extensión no estándar que indica un punto de conexión definido para un elemento o contenedor. Resulta útil para mostrar puertos o puntos finales de servicio expuestos por el elemento. Esto es especialmente útil cuando el uso específico del punto final es indefinido o indeterminado en el momento del diseño, o dicho de otro modo, cuando los clientes del punto final se desconocen de antemano, lo que dificulta el dibujo de un flujo de datos concreto. Aunque esto pueda parecer una preocupación trivial, un punto final de escucha abierto en un servicio puede ser una fuente importante de riesgo arquitectónico, por lo que tener la capacidad de reconocerlo desde el modelo es clave.

Figura 1-15. Símbolo del elemento de interfaz

Cada interfaz debe tener una etiqueta y metadatos que describan sus características principales:

• Si la interfaz representa un puerto conocido, indica el número de puerto.

• Identifica el canal o mecanismo de comunicación -por ejemplo, PHY o Capa 1/Capa 2: Ethernet, VLAN, dispositivo USB de interfaz humana (HID) o una red definida por software- y si la interfaz está expuesta externamente al elemento.

• Protocolo(s) de comunicación que ofrece la interfaz (por ejemplo, protocolos de Capa 4 y superiores; o TCP, IP, HTTP).

• Controles de acceso a las conexiones entrantes (o potencialmente a los flujos de datos salientes), como cualquier tipo de autenticación (contraseñas o claves SSH, etc.) o si la interfaz está afectada por un dispositivo externo, como un cortafuegos.

Conocer esta información puede facilitar el análisis, ya que todos los flujos de datos que se conecten a la interfaz pueden heredar estas características. Como resultado, tu dibujo también será más sencillo y fácil de entender. Si no quieres utilizar este elemento opcional, crea una entidad ficticia y un flujo de datos al punto final de servicio abierto, lo que puede hacer que el dibujo parezca más complejo.

Advertencia

La forma de la Figura 1-16 -elbloque- no forma parte de la colección aceptada de formas DFD. Se incluye aquí porque Matt la considera útil y quería demostrar que el modelado de amenazas no tiene por qué limitarse únicamente a la plantilla tradicional cuando existe la oportunidad de añadir valor y/o claridad a los modelos propios.

Un elemento bloque, mostrado en la Figura 1-16, representa un elemento arquitectónico de que altera selectivamente el flujo de datos en el que está unido. Los bloques también pueden modificar un puerto en la conexión de un flujo de datos o el límite de un proceso. Esta forma pone de relieve cuándo existe un cortafuegos de host, otro dispositivo físico o un mecanismo lógico en función de la arquitectura, e importante para el análisis. Los elementos de los bloques también pueden mostrar equipos opcionales o añadidos que pueden afectar al sistema de una forma fuera del control del equipo del proyecto, aunque no sean entidades externas en el sentido tradicional.

Figura 1-16. Símbolos de bloque

Los metadatos que debes recopilar para los bloques incluyen las etiquetas habituales, así como lossiguientes:

El tipo de bloque

Un dispositivo físico o una unidad lógica, y si la unidad es un componente opcional para el sistema.

Comportamiento

Qué hace el bloque y cómo puede modificar el flujo o el acceso al puerto o proceso. Utiliza un diagrama de secuencia o una máquina de estados para proporcionar detalles adicionales sobre la modificación del comportamiento que admite la unidad que representa el bloque.

Consejo

Cuando desarrolles un modelo de tu sistema, asegúrate siempre de decidir si tú y el equipo del proyecto vais a utilizar un símbolo concreto, y si decidís alterar su significado (creando de hecho vuestras propias reglas de la casa para el modelado de amenazas, ¡lo cual es perfectamente aceptable!) Sé coherente con el uso del símbolo, lo que hará que la actividad sea eficaz y muestre valor.

Diagramas de secuencia

Mientras que los DFD muestran las interacciones e interconexiones entre los componentes del sistema y cómo se mueven los datos entre ellos, los diagramas de secuencia muestran una secuencia de acciones basada en el tiempo o en eventos. Los diagramas de secuencia proceden del UML, y son una especialización del tipo de diagrama de interacción en UML. Complementar los DFD con diagramas de secuencia como parte del modelado para preparar el análisis de amenazas puede ser decisivo para proporcionar el contexto necesario sobre la forma en que se comporta tu sistema y los aspectos temporales necesarios para un análisis adecuado. Por ejemplo, los DFD pueden mostrarte que un cliente se comunica con un servidor y le pasa algún tipo de datos. Un diagrama de secuencia te mostrará el orden de las operaciones utilizadas en ese flujo de comunicación. Esto puede revelar información importante, como quién inicia la comunicación y cualquier paso del proceso que pueda introducir un riesgo para la seguridad o la privacidad, como un fallo en la aplicación correcta de un protocolo o algún otro punto débil.

En la comunidad de seguridad se ha debatido si el diagrama de secuencia es en realidad más importante para realizar esta actividad que la elaboración de DFD. Esto se debe a que un diagrama de secuencia correctamente construido puede proporcionar datos significativamente más útiles que los DFD. El diagrama de secuencia no sólo muestra qué datos intervienen en un flujo y qué entidades están implicadas, sino que también explica cómo fluyen los datos por el sistema y en qué orden. Por tanto, los fallos en la lógica empresarial y el manejo de protocolos son más fáciles de encontrar (y en algunos casos son la única forma posible de encontrarlos) con un diagrama de secuencia.

Los diagramas de secuencia también ponen de manifiesto fallos críticos de diseño, como áreas que carecen de manejo de excepciones, o puntos de fallo u otras áreas en las que los controles de seguridad no se aplican de forma coherente. También puede exponer controles suprimidos o vencidos inadvertidamente, o casos potenciales de condiciones de carrera -incluida la temida debilidad del tiempo de comprobación del tiempo de uso (TOCTOU) - en los que el simple hecho de saber que los datos fluyen, pero no el orden en que lo hacen, no identifica estas debilidades. Sólo el tiempo dirá si se populariza el uso de diagramas de secuencia como socio igualitario en el modelado de amenazas.

La definición formal de un diagrama de secuencia en UML incluye un número importante de elementos de modelado, pero a efectos de crear un modelo adecuado para el análisis de amenazas, sólo debes preocuparte por el siguiente subconjunto.

La Figura 1-17 muestra un diagrama de secuencia de muestra que simula un posible flujo de comunicación y llamada de un sistema mítico.

Figura 1-17. Formas del diagrama de secuencia

Los elementos de modelado que aparecen en la Figura 1-17 son los siguientes:

Entidades (objetos A y B)

Dentro del ámbito del sistema que se está considerando, y su "línea de vida" para conectar con las interacciones con otras entidades.

Actores (humanos)

No se representan aquí, pero residen externamente a los componentes del sistema e interactúan con las distintas entidades del sistema.

Mensajes

Mensajes que contienen datos ("Llamar A", "Devolver B") que se pasan de una entidad a otra. Los mensajes pueden ser síncronos o asíncronos entre entidades; los mensajes síncronos (representados por puntas de flecha sólidas) se bloquean hasta que la respuesta está lista, mientras que los mensajes asíncronos (representados por puntas de flecha abiertas, no mostradas) no se bloquean. Las líneas discontinuas terminadas en puntas de flecha representan mensajes de retorno. Los mensajes también pueden iniciarse y terminar desde una entidad sin pasar a otra, lo que se representa con una flecha que da la vuelta a la línea de vida de la entidad desde la que se inició.

Lógica condicional

Se puede colocar en los flujos de mensajes para proporcionar restricciones o condiciones previas, que ayuden a identificar los problemas introducidos por los fallos de la lógica empresarial y su impacto en los flujos de datos. Esta lógica condicional (no mostrada en la Figura 1-17) tendría la forma de [condition] y se colocaría en línea con la etiqueta del mensaje.

Tiempo

En un diagrama secuencial, el tiempo fluye de arriba abajo: un mensaje situado más arriba en el diagrama ocurre antes en el tiempo que los mensajes que le siguen.

Construir un diagrama de secuencia es bastante fácil. Lo difícil es decidir cómo dibujarlo. Te recomendamos que encuentres una buena herramienta de dibujo que pueda manejar líneas rectas (tanto sólidas como discontinuas), formas básicas y flechas que puedan curvarse o doblarse. Microsoft Visio (y cualquiera de las alternativas libres o abiertas como draw.io o Lucidchart) o una herramienta de modelado UML como PlantUML deberían servir.

También tendrás que decidir qué acciones piensas modelar como una secuencia. Una buena elección son los flujos de autenticación o autorización, ya que implican a varias entidades (al menos un actor y un proceso, o varios procesos) que intercambian datos críticos de una manera predefinida. Puedes modelar con éxito interacciones que impliquen un almacén de datos o un módulo de procesamiento asíncrono, así como cualquier procedimiento operativo estándar que implique a varias entidades.

Una vez que hayas decidido las acciones que quieres modelar, identifica la interacción y el funcionamiento de los elementos de tu sistema. Añade cada elemento al diagrama como un rectángulo hacia la parte superior del diagrama (como se muestra en la Figura 1-17), y traza una línea larga recta hacia abajo desde el centro inferior del rectángulo del elemento. Por último, empezando hacia la parte superior del diagrama (a lo largo de las líneas verticales largas), utiliza líneas terminadas en flechas en una u otra dirección para mostrar cómo interactúan los elementos.

Continúa describiendo las interacciones, avanzando en el modelo, hasta que llegues a la conclusión natural de las interacciones en el nivel de granularidad esperado. Si utilizas una pizarra física o un medio similar para dibujar tu modelo y tomar notas, puede que tengas que continuar tu modelo en varias pizarras, o hacer una foto del modelo incompleto y borrarla para seguir ampliando y profundizando en tu modelización. Después tendrías que unir las piezas para formar un modelo completo.

Diagramas de flujo del proceso

Utilizados tradicionalmente en el diseño de procesos y la ingeniería química, los diagramas de flujo de procesos( PFD ) muestran la secuencia y direccionalidad delflujo de operaciones a través de un sistema . Los PFD son similares a los diagramas de secuencia, pero suelen estar a un nivel superior, mostrando la cadena de actividades de los acontecimientos del sistema en lugar del flujo de mensajes específicos y las transiciones de estado de los componentes.

Mencionamos aquí los flujos de procesos para completar, pero el uso de PFD en el modelado de amenazas no es habitual. Sin embargo, la herramienta ThreatModeler utiliza los PFD como su principal tipo de modelo, por lo que algunos pueden encontrarlo de utilidad.

Los PFD pueden ser de naturaleza complementaria a los diagramas de secuencia. A veces puedes describir la cadena de actividades de un PFD con un diagrama de secuencia utilizando etiquetas que indiquen qué segmentos del flujo de mensajes están vinculados a una actividad o evento concretos. La Figura 1-18 muestra un PFD para los eventos de una aplicación web sencilla.

Figura 1-18. Ejemplo de diagrama de flujo del proceso

La Figura 1-19 muestra el mismo PFD redibujado como diagrama de secuencia con marcos de actividad añadidos.

Figura 1-19. Diagrama de secuencia como PFD

Árboles de ataque

Los árboles de ataque se utilizan en el campo de la informática desde hace más de 20 años. Son útiles para comprender la vulnerabilidad de un sistema modelando cómo puede influir en él un atacante. Los árboles de ataque son el principal tipo de modelo en el análisis de amenazas cuando se utiliza un enfoque centrado en el atacante.

Este tipo de modelo comienza en el nodo raíz que representa el objetivo o resultado deseado. Recuerda que en este tipo de modelo el resultado es negativo para los propietarios del sistema, ¡pero positivo para los atacantes! Los nodos intermedios y de hoja representan posibles formas de alcanzar el objetivo del nodo raíz. Cada nodo está etiquetado con una acción a realizar, y debe incluir información como la siguiente:

• La dificultad de realizar la acción para lograr el objetivo del nodo padre

• El coste que supone hacerlo

• Cualquier conocimiento o condición especial necesarios para que el atacante tenga éxito

• Cualquier otra información relevante para determinar la capacidad global de éxito ofracaso

La Figura 1-20 muestra un árbol de ataque genérico con un objetivo y dos acciones y dos subacciones que un atacante utiliza para alcanzar el objetivo.

Figura 1-20. Un diagrama de árbol de ataque genérico

Los árboles de ataque, que pueden ser valiosos para el análisis de amenazas y para comprender el nivel y el grado real de riesgo de un sistema frente a los atacantes, necesitan un par de cosas para estar bien construidos y proporcionar un análisis correcto del impacto:

• Conocimiento completo de cómo puede comprometerse algo -favorecer la exhaustividad y "lo que es posible" sobre "lo que es práctico"

• Comprensión de las motivaciones, habilidades y recursos de que disponen los distintos tipos y grupos de atacantes.

Puedes construir un árbol de ataque con relativa facilidad, siguiendo los pasos siguientes:

1. Identifica un objetivo o meta para un ataque.

2. Identifica las acciones que deben emprenderse para alcanzar el objetivo o la meta.

3. Aclara y repite.

Identificar un objetivo o meta para un ataque

Para este ejemplo, digamos que un atacante quiere establecer una presencia persistente en un sistema a través de ejecución remota de código (RCE) en un dispositivo embebido. La Figura 1-21 muestra el aspecto que podría tener esto en un árbol de ataque evolutivo.

Figura 1-21. Ejemplo de árbol de ataque, paso 1: identificar el objetivo o meta de alto nivel

Identificar las acciones que deben emprenderse para alcanzar el objetivo o la meta

¿Cómo se llega al RCE en este sistema? Una forma es encontrar un desbordamiento de búfer de pila explotable y utilizarlo para entregar una carga útil ejecutable. O podrías encontrar un desbordamiento de montón y utilizarlo de forma similar. Llegados a este punto, puede que estés pensando: "Pero espera, ¡no sabemos nada del sistema para saber si esto es siquiera factible!". Y tienes razón.

Cuando realices este ejercicio en la vida real, debes ser realista y asegurarte de que sólo identificas objetivos y acciones que tengan sentido para el sistema que estás evaluando. Así que, para este ejemplo, vamos a suponer que este dispositivo embebido ejecuta código escrito en C. También vamos a suponer que este dispositivo ejecuta un sistema operativo embebido similar a Linux, ya sea un sistema operativo en tiempo real (RTOS) o alguna otra variante de Linux con recursos limitados.

Entonces, ¿cuál podría ser otra acción necesaria para obtener la capacidad RCE? ¿Permite el sistema un shell remoto? Si suponemos que este dispositivo tiene memoria flash y/o algún tipo de medio de arranque, y puede aceptar actualizaciones por aire (OTA), podemos añadir la manipulación de archivos y la suplantación o modificación del firmware OTA como acciones para conseguir también el RCE. Todas las acciones posibles que puedas identificar deben añadirse como elementos al árbol de ataque, como se muestra en la Figura 1-22.

Figura 1-22. Ejemplo de árbol de ataque, paso 2: identificar las acciones necesarias para alcanzar el objetivo

Aclarar y repetir

¡Aquí es donde realmente se pone interesante! Intenta pensar en formas de conseguir el siguiente orden de resultados. No te preocupes por la viabilidad o la probabilidad; el análisis y las decisiones tomadas a partir de dicho análisis se producirán más tarde. Piensa fuera de la caja. Recuerda que te estás poniendo el sombrero de hacker, así que piensa como lo harían ellos. Por muy locas que sean tus ideas, alguien podría intentar algo parecido. En esta fase, es mejor una lista exhaustiva de posibilidades que una lista parcial de viabilidades.

Tu árbol está terminado cuando no se necesitan subpasos adicionales para completar una acción. No te preocupes si tu árbol parece desigual; no todas las acciones necesitan el mismo nivel de complejidad para lograr resultados. Tampoco te preocupes si tienes nodos colgantes: puede que no sea fácil identificar todos los escenarios posibles para que un atacante consiga un objetivo (es bueno pensar en tantos escenarios como puedas, pero puede que no seas capaz de identificarlos todos). La Figura 1-23 muestra un árbol de ataque evolucionado (y posiblemente completo) que indica los métodos por los que un atacante puede alcanzar su objetivo.

Figura 1-23. Ejemplo de árbol de ataque, paso 3 y siguientes: identificar subacciones para alcanzar subobjetivos

Aprender a romper algo o a cumplir unos requisitos previos es más fácil como ejercicio de lluvia de ideas en grupo. Esto permite a las personas con conocimientos técnicos y de seguridad aportar su experiencia al grupo para que podáis identificar todos los posibles nodos y hojas del árbol de ataques. Comprender el apetito de riesgo de tu organización, o la cantidad de riesgo que tu organización está dispuesta a aceptar, aclarará cuánto tiempo debes dedicar al ejercicio y si la organización está dispuesta a tomar las medidas necesarias para abordar cualquier preocupación identificada.

Saber cómo se comportan los atacantes es un reto importante para la mayoría de las empresas y profesionales de la seguridad, pero recursos comunitarios como el marco MITRE ATT&CK facilitan enormemente la identificación y caracterización de las técnicas, habilidades y motivaciones de los actores de amenazas . Desde luego, no es una panacea, ya que sólo es tan bueno como la comunidad que lo respalda, pero si no estás familiarizado con cómo se comportan los grupos de atacantes en el mundo real, esta entrada de blog de Adam Shostack, que resume una charla de Jonathan Marcil, es un recurso excelente que debes tener en cuenta.

Diagramas de espina de pescado

Los diagramas de espina de pescado, también conocidos como diagramas de causa y efecto, o de Ishikawa, se utilizan principalmente para el análisis de la causa raíz del enunciado de un problema. La Figura 1-24 muestra un ejemplo de diagrama de espina de pescado.

De forma similar a los árboles de ataque, los diagramas de espina de pescado pueden ayudarte a identificar los puntos débiles del sistema en un área determinada. Estos diagramas también son útiles para identificar escollos o puntos débiles en procesos como los que se encuentran en la cadena de suministro de un sistema, donde puede que tengas que analizar la entrega o fabricación de componentes, la gestión de la configuración o la protección de activos críticos. Este proceso de modelado también puede ayudarte a comprender la cadena de acontecimientos que conducen a la explotación de un punto débil. Conocer esta información te permite construir mejores DFD (sabiendo qué preguntas hacer o qué datos buscas), e identificar nuevos tipos de amenazas, así como casos de pruebas de seguridad.

Construir un diagrama de espina de pescado es similar a crear árboles de ataque, salvo que en lugar de identificar un objetivo y las acciones para conseguirlo, identificas el efecto que quieres modelar. Este ejemplo modela las causas de la exposición de datos.

En primer lugar, define el efecto que quieres modelar; la Figura 1-24 muestra la técnica con la exposición de datos como efecto a modelar.

Figura 1-24. Ejemplo de diagrama de espina de pescado, paso 1: efecto principal

A continuación, debes identificar un conjunto de causas primarias que conduzcan al efecto. Hemos identificado tres: registros demasiado verbosos, canales encubiertos y error del usuario, como se muestra en la Figura 1-25.

Figura 1-25. Ejemplo de diagrama de espina de pescado, paso 2: causas primarias

Por último, identificas el conjunto de causas que impulsan las causas primarias (y así sucesivamente). Hemos identificado que una causa primaria de error del usuario es una IU confusa. Este ejemplo sólo reconoce tres amenazas, pero querrás crear modelos más amplios y extensos, en función del tiempo y el esfuerzo que quieras dedicar frente a la granularidad de tus resultados. La Figura 1-26 muestra el diagrama de espina de pescado en un estado completo, con el efecto esperado, las causas primarias y las secundarias.

Figura 1-26. Ejemplo de diagrama de espina de pescado, paso 3: causas secundarias

Cómo construir modelos de sistemas

El proceso básico para crear modelos de sistemas empieza por identificar los principales bloques de construcción del sistema : pueden ser aplicaciones, servidores, bases de datos o almacenes de datos. A continuación, identifica las conexiones con cada bloque principal:

• ¿Admite la aplicación una API o una interfaz de usuario?

• ¿El servidor escucha en algún puerto? Si es así, ¿sobre qué protocolo?

• Lo que habla con la base de datos, y lo que se comunica con ella, ¿sólo lee datos, o también los escribe?

• ¿Cómo controla la base de datos el acceso?

Continúa siguiendo hilos de conversación e itera a través de cada entidad en esta capa de contexto del modelo hasta que hayas completado todas las conexiones, interfaces, protocolos y flujos de datos necesarios.

A continuación, elige una de las entidades -normalmente una aplicación o un elemento del servidor- que pueda contener detalles adicionales que necesites descubrir para identificar áreas de preocupación, y divídela aún más. Céntrate en los puntos de entrada y salida a/de la aplicación, y en dónde se conectan estos canales, cuando examines las subpartes que componen la aplicación o el servidor.

Considera también cómo pueden comunicarse entre sí las distintas subpartes, incluidos los canales de comunicación, los protocolos y el tipo de datos que se transmiten a través de los canales. Querrás añadir cualquier información relevante basada en el tipo de forma añadida al modelo (más adelante en el capítulo aprenderás a anotar el modelo con metadatos).

Cuando construyas modelos, tendrás que aprovechar tu criterio y tus conocimientos de los principios y la tecnología de seguridad para reunir información que permita realizar una evaluación de las amenazas. Lo ideal sería que realizaras esta evaluación de amenazas inmediatamente después de construir tu modelo.

Antes de empezar, decide qué tipos de modelo puedes necesitar y el conjunto de símbolos de cada tipo de modelo que pretendes utilizar. Por ejemplo, puedes decidir utilizar el DFD como tipo de modelo principal, pero utilizar el conjunto de símbolos por defecto definido por el paquete de dibujo que estés utilizando. O puedes decidir incluir también diagramas de secuencia, lo que sería apropiado si tu sistema utiliza interacciones no estándar entre componentes, donde pueden esconderse debilidades explotables.

Como líder de un ejercicio de modelado (que, a efectos de este capítulo, suponemos que eres tú, por suerte), tienes que asegurarte de que incluyes a las partes interesadas adecuadas. Invita a la sesión de modelado al arquitecto jefe, a los demás diseñadores y al jefe o jefes de desarrollo. También deberías considerar la posibilidad de invitar al jefe de control de calidad (QA). Anima a todos los miembros del equipo del proyecto a que aporten su contribución a la construcción del modelo, aunque por una cuestión práctica, recomendamos mantener la lista de asistentes en un conjunto manejable para maximizar el tiempo y la atención de los que asistan.

Si es la primera vez que tú o tu equipo de desarrollo creáis un modelo de sistema, empieza despacio. Explica al equipo los objetivos o resultados esperados del ejercicio. También debes indicar cuánto tiempo esperas que dure el ejercicio y el proceso que vais a seguir, así como tu papel en el ejercicio y el de cada parte interesada. En el caso improbable de que los miembros del equipo no se conozcan todos, recorre la sala para hacer las presentaciones antes de empezar la sesión.

También debes decidir quién se encarga de dibujar y tomar notas durante la sesión. Te recomendamos que dibujes tú mismo, porque te sitúa en el centro de la conversación en todo momento y ofrece a los asistentes la oportunidad de centrarse en la tarea que tienen entre manos.

Merece la pena mencionar algunos puntos mientras exploras el sistema:

El momento del ejercicio es importante

Si te reúnes demasiado pronto, el diseño no estará lo suficientemente formado, y se producirá mucho ajetreo, ya que los diseñadores con puntos de vista diferentes se desafían mutuamente y llevan la discusión por la tangente. Pero si te reúnes demasiado tarde, el diseño estará fijado, y los problemas detectados durante el análisis de las amenazas pueden no resolverse a tiempo, convirtiendo tu reunión en un ejercicio de documentación más que en un análisis en busca de amenazas.

Las distintas partes interesadas verán las cosas de forma diferente

Hemos comprobado que es habitual, especialmente a medida que aumenta el número de asistentes, que las partes interesadas de no siempre están de acuerdo en cómo se diseñó o implementó el sistema; tienes que guiar la conversación para identificar el camino correcto para el diseño. También es posible que tengas que moderar la discusión para evitar agujeros de conejo e hilos de conversación circulares, y desconfiar de las conversaciones paralelas, ya que suponen una distracción innecesaria y que lleva mucho tiempo. Una conversación bien moderada entre las partes interesadas en el proceso de modelado del sistema suele conducir a momentos "¡eureka!", ya que la discusión revela que la expectativa del diseño y la realidad de la implementación chocan, y el equipo puede identificar los puntos en los que las limitaciones modificaron el diseño inicial sin control.

Los cabos sueltos están bien

Como hemos dicho antes, aunque busques la perfección, siéntete cómodo con la falta de información. Sólo asegúrate de evitar o minimizar la información incorrecta a sabiendas. Es mejor tener un flujo de datos o un elemento del modelo lleno de signos de interrogación que tenerlo todo completo pero con algunas inexactitudes conocidas. Basura dentro, basura fuera; en este caso, las imprecisiones darán lugar a un análisis deficiente, que puede significar múltiples hallazgos falsos, o peor aún, la falta de hallazgos en una región potencialmente crítica del sistema.

Te recomendamos que presentes el modelado del sistema como un ejercicio guiado. Esto es especialmente importante si el equipo del proyecto no está familiarizado con el proceso de construcción de modelos. A menudo es beneficioso que alguien externo al equipo de desarrollo del producto facilite el ejercicio de modelado, porque así se evita un conflicto de intereses con respecto al diseño del sistema y su posible impacto en los requisitos de entrega.

Esto no quiere decir que alguien que facilite la construcción de un modelo deba ser totalmente imparcial. El líder será responsable de reunir a los participantes necesarios y de trabajar con este equipo para definir el sistema que el equipo pretende construir con el suficiente detalle para apoyar el análisis posterior. Como tal, el líder debe ser un facilitador de los resultados, no un tercero desinteresado. Debe estar lo suficientemente alejado del diseño (y de las suposiciones o atajos que se hagan o de los riesgos que se ignoren) como para ofrecer una visión crítica del sistema y poder extraer fragmentos de información que sean útiles para el análisis de las amenazas.

Como líder, es importante que dispongas de información precisa y completa, en la medida de lo posible, cuando analices tu modelo; tu análisis puede dar lugar a cambios en el diseño del sistema, y cuanto más precisa sea la información con la que comiences, mejores análisis y recomendaciones podrás hacer. No pierdas de vista el detalle y estate dispuesto y sé capaz de volcar "piedras" para encontrar la información adecuada en el momento oportuno. También debes estar familiarizado con las tecnologías consideradas, la finalidad del sistema que se está diseñando y las personas implicadas en el ejercicio.

Aunque no hace falta ser un experto en seguridad para construir un buen modelo de sistema, la construcción del modelo suele realizarse como requisito previo a la fase de análisis de amenazas. Esto suele ocurrir en rápida sucesión, lo que sugiere que probablemente tú también deberías ser el líder de seguridad para esa parte del proyecto. La realidad es que, en los proyectos de desarrollo modernos, puede que no seas un experto en todo lo relacionado con un sistema. Tienes que confiar en tus compañeros de equipo para cubrir tus lagunas de conocimiento, y actuar más como facilitador para garantizar que el equipo desarrolle eficazmente un modelo representativo y preciso. Recuerda, no necesitas ser mecánico de automóviles para conducir un coche, pero sí debes saber conducirlo y conocer las normas de circulación.

Consejo

Si eres el líder encargado de entregar un modelo de sistema para su análisis, debes estar de acuerdo con la imperfección, sobre todo al iniciar un nuevo modelo de un sistema. Tendrás la oportunidad de mejorar el modelo en sucesivas iteraciones.

Por muy hábil que seas dibujando modelos o interrogando a los diseñadores sobre los sistemas que te presentan, es muy probable que la información que necesitas en su totalidad falte o no esté disponible, al menos al principio. Y eso está bien. Los modelos de sistemas representan el sistema que se está considerando y no necesitan ser precisos al 100% para ser valiosos. Debes conocer algunos datos básicos sobre el sistema y cada elemento del sistema para que tu análisis sea eficaz, pero no intentes alcanzar la perfección o te desanimarás (por desgracia, lo sabemos por experiencia).

Puedes mejorar tus posibilidades de éxito al dirigir esta actividad teniendo en cuenta algunas cosas sencillas:

Establece una zona libre de culpas

Las personas con un fuerte apego a un sistema que se está analizando tendrán opiniones y sentimientos. Aunque debes esperar profesionalidad por parte de los asistentes, la contención y las discusiones acaloradas pueden crear relaciones de trabajo agrias si no evitas ponerte personal en una sesión de modelado de sistemas. Prepárate para moderar el debate para evitar señalar a las personas por sus errores, y redirige la conversación hacia el reconocimiento de la gran oportunidad de aprendizaje que tienes ahora.

Sin sorpresas

Sé franco sobre lo que pretendes conseguir, documenta tu proceso y avisa a tus equipos de desarrollo con suficiente antelación.

Formación

Ayuda a tu equipo a ayudarte mostrándoles lo que hay que hacer y qué información se les pedirá para que puedan tener éxito. La formación práctica es especialmente eficaz (por ejemplo, "muestra uno, haz uno"), pero en esta era de registros de vídeo (vlogs) y retransmisiones en directo, también puedes plantearte grabar una sesión de modelado en directo al estilo Critical Role y poner el vídeo a disposición de tus equipos de desarrollo para que lo revisen. Podrían ser las dos o tres horas mejor invertidas enformación.

Prepárate

Pide información sobre el sistema de destino antes de tu ejercicio de modelado del sistema, como requisitos del sistema, especificaciones funcionales o historias de usuario. Esto te dará una idea de por dónde podrían ir los diseñadores al considerar un conjunto de módulos, y te ayudará a formular preguntas que puedan ayudar a obtener el nivel de información necesario para un buen modelo.

Motivar a los asistentes con comida y bebida

Trae donuts o pizza (según la hora del día) y café u otros aperitivos. La comida y la bebida ayudan mucho a generar confianza y a conseguir que los asistentes hablen de temas difíciles (¡como ese gran agujero de seguridad que se introdujo por accidente!).

Conseguir la implicación de la dirección

Los asistentes se sentirán más cómodos estando presentes y compartiendo sus pensamientos e ideas (y descubriendo esqueletos en el armario, por así decirlo) si saben que su equipo directivo está de acuerdo con esta actividad.

Nota

En el momento de escribir esto, la pandemia de COVID-19 nos está haciendo pensar de forma creativa sobre cómo reunirnos de forma segura y crear camaradería virtual con aperitivos enviados (o de origen local) y videollamadas en grupo. Son lecciones que puedes aplicar a la colaboración en equipos distribuidos en cualquier momento.

Cuando creas un modelo de sistema, sea del tipo que sea, puedes optar por dibujarlo en una pizarra o en una aplicación de pizarra virtual y trasladarlo a tu paquete de dibujo favorito. Pero no tienes por qué hacerlo siempre a mano. Debes saber que hoy en día existen utilidades online y offline¹⁰ que te permiten crear modelos sin dibujarlos manualmente primero.

Si utilizas alguno de estos paquetes de dibujo, debes idear tu propio método para añadir anotaciones de metadatos para cada elemento, como se ha descrito antes. Puedes hacerlo dentro del propio diagrama como un cuadro de texto o una llamada, lo que podría desordenar el diagrama. Algunas aplicaciones de dibujo realizan una disposición automática de objetos y conexiones, que en diagramas complejos puede parecer un espagueti. También puedes crear un documento aparte, en tu editor de texto favorito, y proporcionar los metadatos necesarios para cada elemento mostrado en el diagrama. La combinación de diagrama(s) y documento(s) de texto se convierte en el "modelo" que permite a un humano realizar un análisis capaz de identificar amenazas y puntos débiles.

¿Cómo es un buen modelo de sistema?

A pesar de tus mejores esfuerzos, la complejidad puede producirse porque tienes demasiada información o, peor aún, información incorrecta. A veces, el nivel potencial de detalle del propio modelo y la consiguiente cantidad de esfuerzo que necesitas para realizar el análisis del modelo es una distracción bienvenida de todos los incendios que estás combatiendo. Otra posibilidad es que un nivel de detalle extremo sea un requisito de tu entorno o segmento de mercado. Por ejemplo, algunas industrias, como el transporte o los dispositivos médicos, requieren un mayor grado de análisis para abordar un mayor grado de seguridad. Para la mayoría de nosotros, sin embargo, el modelado de amenazas suele considerarse poco familiar, desconcertante o una "distracción" inoportuna de otras tareas aparentemente más críticas. Pero a estas alturas ya lo sabes: un buen modelo de amenazas se paga solo.

Pero, ¿qué hace que un modelo sea bueno? Depende de varios factores, como la metodología que utilices, tus objetivos y el tiempo y la energía que puedas dedicar a elaborar el modelo. Aunque un buen modelo es difícil de describir, podemos destacar los puntos clave que conforman un buen modelo de sistema. Los buenos modelos tienen, como mínimo, las siguientes propiedades:

Preciso

Mantén tus modelos libres de información inexacta o engañosa que dé lugar a un análisis de amenazas imperfecto. Esto es difícil de hacer solo, por lo que es fundamental contar con el apoyo de los diseñadores del sistema, los desarrolladores y otras personas del proyecto. Si el equipo del proyecto se pregunta en voz alta "¿Qué es eso?" cuando todo está dicho y hecho, algo malo ocurrió durante la construcción del modelo del sistema y debería revisarse.

Significativo

Los modelos deben contener información, no sólo datos. Recuerda que estás intentando capturar información que apunte a "condiciones para un compromiso potencial" dentro de tu sistema. Identificar esas condiciones depende de la metodología de modelado de amenazas que elijas finalmente. La metodología que utilices identifica si buscas sólo debilidades explotables (también conocidas como vulnerabilidades) o si quieres identificar distintas partes del sistema que tienen el potencial de contener debilidades, explotables o no (porque en teoría es probable que lleguen a ser explotables en la práctica, aunque no lo sean sobre el papel).

A veces la gente quiere capturar tantos metadatos sobre el sistema como sea posible. Pero el objetivo del modelado es crear una representación del sistema sin recrearlo, proporcionando datos suficientes para hacer inferencias y juicios directos sobre las características del sistema.

Representante

El modelo debe intentar ser representativo de las intenciones de diseño del arquitectoo de la implementación realizada por los equipos de desarrollo. El modelo puede decirnos qué esperar de la postura de seguridad del sistema tal como se diseñó o tal como se implementó, pero normalmente no ambas cosas. En cualquier caso, la conversación en la mesa de la sala de conferencias será el equivalente corporativo de "él dijo, ella dijo". El equipo debe reconocer claramente su sistema en el modelo creado.

Vivir

Tu sistema no es estático. Tu equipo de desarrollo siempre está haciendo cambios, actualizaciones y correcciones. Como tus sistemas cambian constantemente, tus modelos deben ser documentos vivos. Revisa el modelo periódicamente para asegurarte de que sigue siendo preciso. Debe reflejar el diseño del sistema previsto en ese momento o la implementación actual del sistema. Modela "lo que es" en lugar de "lo que debería ser".

Decidir cuándo tu modelo es "bueno" no es fácil. Para determinar la calidad y "bondad" de un modelo de sistema, debes elaborar unas directrices y ponerlas a disposición de todos los participantes. Estas directrices deben detallar qué construcciones de modelado (es decir, formas, métodos) utilizar y con qué fines. También deben identificar el nivel de granularidad al que hay que aspirar y cuánta información es demasiada. Incluyan orientaciones estilísticas, como la forma de registrar las anotaciones o de utilizar el color en el diagrama del modelo.

Las directrices no son normas en sí mismas. Están ahí para proporcionar coherencia en el ejercicio de modelado. Sin embargo, si los miembros del equipo se desvían de las directrices pero son eficaces en el desarrollo de un modelo de calidad, llévatelos a todos a tomar una copa. Declara el éxito del primer modelo creado por un equipo cuando los participantes -los diseñadores y otras partes interesadas del sistema, y tú mismo- estén de acuerdo en que el modelo es una buena representación de lo que queréis construir. Puede que sigan existiendo retos y que las partes interesadas tengan reservas sobre su creación (el sistema, no el modelo), pero el equipo ha superado el primer obstáculo y debe felicitarse.

Resumen

En este capítulo, has aprendido una breve historia de la creación de modelos de sistemas complejos y los tipos de modelos que se utilizan habitualmente en el modelado de amenazas. También hemos destacado técnicas que te ayudarán a ti y a tu equipo a introducir la cantidad adecuada de información en tus modelos. Esto te ayudará a encontrar las agujas (datos) en el pajar de la información, evitando al mismo tiempo la parálisis por análisis.

A continuación, en el Capítulo 2, presentamos un enfoque generalizado del modelado de amenazas. En el Capítulo 3, cubriremos una colección de metodologías aceptadas por la industria para identificar y priorizar las amenazas.

¹ "El plano de San Galo", Cultura carolingia en Reichenau y San Galo, https://oreil.ly/-NoHD.

² A. E. Dien, Civilización de las Seis Dinastías (New Haven: Yale University Press, 2007), 214.

³ A. Smith, Architectural Model as Machine (Burlington, MA: Architectural Press, 2004).

⁴ Existen otros métodos para producir modelos gráficos adecuados para el análisis, como utilizar otros tipos de modelos UML , o el Lenguaje de Modelado de Sistemas (SysML), y otros tipos de modelos que pueden ser útiles para realizar un análisis eficaz, como los gráficos de flujo de control y las máquinas de estados. Pero esas metodologías están fuera del alcance de este libro.

⁵ "Diagramas de flujo de datos (DFD): Una introducción ágil", Agile Modeling Site, https://oreil.ly/h7Uls.

⁶ Para un amplio debate sobre el tema, véase Brook S.E. Schoenfield, Securing Systems: Applied Security Architecture and Threat Models (Boca Ratón, FL: CRC Press, 2015).

⁷ Entre las banderas más comunes están las de soporte ASLR o DEP o las canarias de pila.

⁸ Como en el uso que hace Apache Tomcat de este mecanismo.

⁹ Adam Shostack, "DFD3", GitHub, https://oreil.ly/OMVKu.

¹⁰ draw.io, Lucidchart, Microsoft Visio, OWASP Threat Dragon y Dia, por nombrar algunos.