Gestionar riesgos es inherente a la actividad humana, de alguna manera todos lo hacemos: tanto en el ámbito personal como profesional la vida está llena de decisiones que tomamos buscando eliminar o disminuir los riesgos.

La gestión de riesgos de seguridad de la información debe ser parte de la vida diaria de cualquier organización. La economía globalizada, la dependencia creciente en los sistemas digitales de información, el explosivo crecimiento del cibercirmen[1] y la naturaleza VUCA[2] del entorno actual obligan a ello, pues la operación, incluso la supervivencia de las organizaciones actuales está determinada en buena medida por el correcto manejo de la información de su ecosistema.

Según la Norma ISO 31000:2018 (2018), un riesgo es el “efecto de la incertidumbre sobre los objetivos (desviación respecto a lo previsto. Puede ser positivo, negativo o ambos, y puede abordar, crear o resultar en oportunidades y amenazas). Con frecuencia, el riesgo se expresa en términos de fuentes de riesgo, eventos potenciales, sus consecuencias y sus probabilidades” y la gestión del riesgo son las “actividades coordinadas para dirigir y controlar la organización con relación al riesgo”. Así pues, de lo que se trata es de estimar la probabilidad de que una amenaza aproveche una vulnerabilidad, que puede ocasionar efectos adversos en las operaciones y en los objetivos de un negocio.

Dado que el software está en el centro de todas las soluciones de TIC, pues todo sistema automatizado o dispositivo implica el desarrollo de código en mayor o menor medida, la eliminación de riesgos en el desarrollo de software es cada vez más importante, lo que nos ha llevado a que la seguridad desde el diseño sea fundamental en el SDLC (Software Development Life Cycle) y, por ende, a que se desarrollen metodologías y marcos de referencia para ello.

Así pues, en los últimos 20 años se ha ido imponiendo el uso del modelado de amenazas como una herramienta básica en el desarrollo de sistemas, que precisamente busca evaluar los riesgos desde el diseño de una aplicación y cuyo principal objetivo es “identificar los ataques a los que una aplicación podría ser susceptible, así como los controles de seguridad que permitirán al software alcanzar el nivel de seguridad deseado” (Rivera, 2021).

En resumen, podría decirse que el modelado de amenazas es una manera de afrontar el análisis de riesgos para incorporar la seguridad desde las fases de diseño, de una manera estructurada, que permita tener claridad de las posibles amenazas y vulnerabilidades, de manera que se eliminen, se mitiguen o, al menos, se consideren salvaguardas adecuadas desde antes de crear un sistema.

¿Y cómo afrontar el modelado de amenazas? Adam Shostack, uno de los autores más conocidos en el tema, en su libro “Threat Modeling: Designing for Security” (Shostack, 2014), menciona cuatro preguntas esenciales:

  1. ¿Qué se está construyendo?
  2. ¿Qué puede fallar una vez que está construido?
  3. ¿Qué debería hacerse acerca de esas situaciones que podrían salir mal?
  4. ¿El análisis realizado fue suficientemente bueno?

Que, a su vez, llevan a un modelo de cuatro pasos:

Figura 1. Modelo de cuatro pasos (Shostack, 2014).

Una nota importante antes de pasar al resumen de algunas de las metodologías más empleadas: el modelado del sistema es una parte muy importante y, creo yo, es la que más diferencia a esta herramienta de otras de análisis de riesgos. En palabras de Della Corte, A. (2019), “se trata de un proceso para entender a fondo la aplicación y su interacción con otras entidades, lo que implica crear casos de uso para comprender cómo se usa, identificar puntos de entrada para ver dónde un atacante podría interactuar con ella, identificar activos, es decir, elementos en los que el atacante estaría interesado, e identificar los niveles de confianza que representan los derechos de acceso que la aplicación otorgará a entidades externas”.

Metodologías existentes

CORAS

CORAS (Consultative Objective Risk Analysis System) es una metodología de modelado de amenazas con origen en la Unión Europea, que busca facilitar el descubrimiento y análisis de vulnerabilidades y, por ende, de los riesgos.

Está basada en modelos, que se construyen con un lenguaje llamado UML (Unified Modelling Language), tanto para el objetivo del análisis, el análisis en sí y la presentación de resultados. Es importante mencionar que existe una aplicación (CORAS Language Editor), disponible para Windows, MacOS y Linux, que se usa para la documentación del análisis.

La metodología CORAS contempla ocho pasos (Source Forge, 2015):

  1. Preparación inicial para el análisis.

El objetivo principal es tener una buena idea de lo que se requiere y del nivel de esfuerzo que se necesitará.

  1. Junta inicial con el cliente que solicitó el análisis.

Para entender cuál será el sistema por analizar, los objetivos buscados con el análisis y las preocupaciones principales.

  1. Afinación del alcance mediante diagramas de activos.

De manera que se tenga un entendimiento común del objetivo y las tareas que se llevarán a cabo. El resultado de este paso es una descripción detallada del sistema a analizar y de los objetivos por alcanzar.

  1. Aprobación del alcance.

Esto para asegurar que el cliente o solicitante está de acuerdo con el resultado del paso anterior y de las premisas del análisis. En esta parte también se deciden los criterios de evaluación de riesgo para cada activo.

  1. Identificación de los riesgos, mediante diagramas de amenazas.

Se identifican los riesgos mediante una lluvia de ideas estructurada, en la que debe participar personal con diferentes roles, para asegurar todos los puntos de vista a tomar en cuenta. En esta parte del análisis se lleva a cabo una identificación sistemática de las amenazas, los incidentes no deseados, los escenarios de amenaza y las vulnerabilidades de los activos.

  1. Estimación de los riesgos, mediate diagramas de amenazas.

Se debe determinar el nivel de riesgo representado por las amenazas o los incidentes no deseados. Nuevamente se hace uso de la lluvia de ideas para estimar las posibilidades y las consecuencias de los incidentes no deseados, que llevarán a definir un nivel de riesgo en cada caso.

  1. Evaluación de los riesgos, mediate diagramas de amenazas.

El objetivo de este paso es definir cuáles de los riesgos encontrados son aceptables y cuáles deben ser analizados para su tratamiento. Es importante tener en cuenta que la estimación de los riesgos incluye también aquellos relacionados con activos indirectos.

  1. Tratamiento de los riesgos, mediate diagramas de amenazas.

Finalmente, hay que definir cómo se tratarán los riesgos identificados, para llevarlos a niveles aceptables, siempre considerando el costo-beneficio de las salvaguardas.

Figura 2. Ejemplo de diagrama de identificación de riesgos (Solhaug, 2011).

OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) surgió en el SEI (Software Engineering Institute) de la Universidad Carnegie Mellon. Se trata de una metodología centrada en activos cuyo foco está en los riesgos organizacionales más que en los tecnológicos y, a grandes rasgos, consta de tres fases (Hajrić et al, 2020):

  1. Construir perfiles base de las amenazas, con base en los activos y recursos de la organización (evaluación organizacional).
  2. Identificar las vulnerabilidades de la infraestructura (evaluación de la infraestructura de información).
  3. Desarrollar la estrategia y planes de seguridad (identificación de riesgos para los recursos críticos de la organización y toma de decisiones).

Figura 3. Proceso de OCTAVE (Alberts et al, 2003).

OCTAVE trata de tomar ventaja del conocimiento de la gente de una organización sobre sus prácticas de seguridad y procesos, por ello se dice que los dos aspectos principales de esta metodología son el riesgo operacional y las prácticas de seguridad (Obiora Nweke, L., & Wolthusen, S., 2020). La tecnología es evaluada en relación con las prácticas de seguridad, y para el riesgo operacional se consideran todos sus aspectos (activos, amenazas, vulnerabilidades e impacto organizacional).

A continuación, planteo los puntos considerados durante el proceso de evaluación mencionado:

  • Identificación de activos relacionados con la información, que son importantes para la organización.
  • Foco en actividades de análisis de riesgo en aquellos activos que se consideran críticos para la organización.
  • Consideración de las relaciones entre los activos críticos, las amenazas a las que están sujetos y sus vulnerabilidades, tanto organizacionales como tecnológicas.
  • Evaluación del riesgo en un contexto operacional, para ver cómo es que los riesgos influyen en el negocio y cómo es que los activos están en riesgo por las amenazas.
  • Creación de una estrategia de protección, basada en la práctica, para la mejora organizacional, así como planes de mitigación de riesgos en los activos críticos.

Para Alberts et al (2003) uno de los conceptos primordiales de esta metodología es el de “Criterios de OCTAVE”, que son un conjunto de principios, atributos y resultados definidos por el enfoque OCTAVE:

  • Los principios son los conceptos fundamentales que impulsan la naturaleza de la evaluación y definen su filosofía. Un ejemplo de ello es la autodirección.
  • Los atributos son las cualidades o características distintivas de la evaluación. Cada principio tiene una serie de atributos; por ejemplo, el principio de autodirección tiene 2 atributos: equipo de análisis y el aumento de las habilidades de este.

Lo relevante de los criterios de OCTAVE es que se pueden desarrollar distintos métodos (versiones) consistentes con ellos. A la fecha hay tres:

  1. La versión original, especialmente útil para organizaciones grandes.
  2. OCTAVE-S, para organizaciones pequeñas.
  3. OCTAVE Allegro, que es una versión simplificada que se enfoca solo en los activos de la organización, y no requiere mucha participación del personal de la organización.

PTA

Normalmente conocida como PTA, la metodología CTMM (Calculative Threat Modeling Methodology) es obra de la empresa Practical Threat Analisys Technologies, que además ha desarrollado una serie de programas de cómputo para su uso y aplicación, que permiten crear y mantener una base de datos de amenazas, crear documentación para revisiones de seguridad y producir informes sobre las amenazas y las contramedidas respectivas.

Esta metodología plantea que antes de comenzar el proceso de modelado, el analista debe familiarizarse con la aplicación o sistema por analizar, recopilando al menos la siguiente documentación:

  • Descripción funcional del sistema, que incluya casos de uso.
  • Diagrama de la arquitectura del sistema y documentación de los módulos que lo componen.
  • Diccionario de términos de todos los documentos para la familiarización y el análisis posterior.

PTA CTMM considera cuatro pasos para el modelado de amenazas:

  1. Identificación de los activos.

Mapeo de los activos más valiosos para las organización y de las perdidas potenciales debido a fallas o afectaciones en los mismos. El valor de los activos se empleará como base para definir la prioridad del análisis y cálculo de amenazas, riesgos y salvaguardas.

  1. Identificación de vulnerabilidades.

Para ello se requiere el conocimiento de la funcionalidad del sistema, su arquitectura, procedimientos operacionales, procesos de negocio y tipos de usuario. Se trata de una tarea contina iterativa, junto con el paso 4.

  1. Definición de salvaguardas.

Las salvaguardas deben elegirse por su grado de relevancia para remediar o mitigar las vulnerabilidades del sistema, y su relación costo-beneficio se calcula de acuerdo con el costo estimado de implementación.

  1. Construcción de escenarios de amenaza y planes de mitigación.

Para ello, PTA CTMM recomienda:

  1. Iniciar con una descripción breve de cada escenario de amenaza.
  2. Identificar los activos en riesgo y el potencial nivel de daño en cada uno.
  3. Identificar las vulnerabilidades que la amenaza puede explotar, lo que automáticamente llevará a una lista de posibles salvaguardas.
  4. Calcular la probabilidad de la amenaza. El nivel de riesgo de la amenaza se calcula automáticamente en función del daño que puede causar y su probabilidad.
  5. Decidir el plan de mitigación, seleccionando la combinación más efectiva de salvaguardas.

A continuación, un diagrama que describe las interrelaciones entre una amenaza, los activos, las vulnerabilidades y las salvaguardas (contramedidas):

Figura 4. Ejemplo del modelo de datos de PTA (PTA Technologies, 2007).

Trike

Trike consta de una metodología y una herramienta de software para el modelado de amenazas, ambas Open Source (Larcom & Saitta, 2009). Según sus autores, es un marco conceptual unificado para la auditoría de seguridad desde una perspectiva de gestión de riesgos a través de la generación de modelos de amenazas, además de distinguirse de otras metodologías por el altos niveles de automatización posible dentro del sistema, la perspectiva defensiva del sistema, y ​​el grado de formalismo presente en la metodología.

Trike parte de un punto de vista defensivo y separa los ataques, amenazas y vulnerabilidades, lo que permite construir un sistema experto para la toma de decisiones. En resumen, se enfoca en el riesgo asociado con cada activo de la organización, para lo que emplea un modelo de requerimientos, que asigna un nivel aceptable de riesgo en cada activo. Este es un diagrama con el resumen de esta metodología:

Figura 5. Metodología Trike (Brathwaite, 2021)

Durante el desarrollo, se debe construir un modelo que permita enumerar y comprender los actores del sistema, los recursos, las acciones previstas y las normas; esto crea una matriz de actores de actividades versus recursos:

Figura 6. Creación del modelo en Trike (Larcom, 2012).

Y cada celda de la matriz se divide en cuatro secciones, una para cada acción de las siguientes: crea, lectura, actualización y eliminación (CRUD). En estas celdas, se asigna uno de tres valores posibles: acción permitida, acción ilegal o regla acción, que al final llevan a la elaboración de un diagrama de flujo de datos (DFD).

Finalmente, las amenazas se identifican iterando a través de los DFD para que cada una se convierta en nodo raíz nodo de un árbol de ataque (algo característico de Trike es que las amenazas solo tienen dos categorías: denegación de servicio o elevación de privilegios).

TAM

Microsoft Threat Analysis and Modeling (TAM) contempla cuatro grandes pasos del proceso de modelado de amenazas (Microsoft, 2018):

  1. Definir los requerimientos de seguridad, lo que ayudará a determinar el nivel de esfuerzo en los siguientes pasos.
  2. Crear un diagrama de la aplicación o sistema, para entender la arquitectura, funcionalidades y módulos que lo integran.
  3. Identificar las amenazas.
  4. Mitigar las amenazas.

Una vez efectuados los pasos iniciales del proceso, se procede a realizar una clasificación y puntuación de las amenazas, de modo que el equipo de trabajo pueda determinar las distintas prioridades. Hay dos modelos de clasificación y puntuación: STRIDE y DREAD.

STRIDE (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege) es un sistema de clasificación para los diferentes tipos de amenazas: suplantación de identidad (Spoofing), manipulación de datos (Tampering), repudio (Repudiation), revelación de información (Information Disclosure), denegación de servicio (Denial of Service) y escalación de privilegios (Elevation of Privilege).

Figura 7. STRIDE (Brathwaite, 2021)

Por su parte, DREAD (Damage potential, Reproducibility, Exploitability, Affected users, Discoverability) es un modelo para puntuación que permite asignar valores al riesgo, para priorizar su tratamiento. Normalmente se emplea la fórmula siguiente:

Riesgo = Probabilidad * Impacto

Donde se usa una escala de 1 al 10, tanto para la probabilidad como para el impacto.

DREAD ayuda en la adopción de criterios comunes mediante las siguientes preguntas:

  • Damage (daño): ¿Cuál es el impacto de un ataque?
  • Reproducibilty (reproducibilidad): ¿Es fácil reproducir las condiciones que conduzcan al ataque?
  • Exploitability (explotabilidad): ¿Qué tan fácil es lanzar el ataque?
  • Affected Users (usuarios afectados): ¿Cuantos usuarios se verían afectados?
  • Discoverability (descubrimiento): ¿Qué tan fácil es hallar la vulnerabilidad?

Figura 8. DREAD (Brathwaite, 2021)

PASTA

Process for Attack Simulation and Threat Analysis (PASTA), como su nombre lo indica, es una metodología con foco en el punto de vista del atacante. El objetivo es proporcionar un proceso estructurado para simular ataques a aplicaciones, analizar las amenazas que se originan a partir de las simulaciones y después mitigar los riesgos presentes.

Consta de siete etapas: definir los objetivos, definir el alcance técnico, descomposición/análisis de la aplicación, análisis de amenazas, análisis de vulnerabilidades y debilidades, modelado de ataque y simulación, y, finalmente, análisis de riesgo e impacto.

Figura 9. Etapas de PASTA (Brathwaite, 2021).

Cuadro 1. Resumen comparativo de metodologías

Conclusiones

Sin duda, el modelado de amenazas es una herramienta fundamental en el mundo de la ciberseguridad. Dado que uno de sus objetivos principales es identificar fallas de seguridad desde el diseño, permite minimizar el uso de controles detectivos y correctivos, que en la vida diaria se traducen en inversiones enormes en gente, procesos y tecnología para subsanar las vulnerabilidades en los sistemas modernos: revisiones de código, firewalls aplicativos, SIEM, equipos de DFIR y un largo etcétera.

[email protected]

Referencias

  1. Alberts C., Dorofee A., Stevens J., & Woody C. (2003). “Introduction to the OCTAVE approach”.
  2. BID & OEA. (2020). Ciberseguridad. Riesgos, avances y el camino a seguir en América Latina y El Caribe. Banco Interamericano de Desarrollo. https://publications.iadb.org/publications/spanish/document/Reporte-Ciberseguridad-2020-riesgos-avances-y-el-camino-a-seguir-en-America-Latina-y-el-Caribe.pdf.
  3. Brathwaite, S. (2021, 23 febrero). Top 7 Popular Cyber Threat Models for identifying threat actors, vectors and cyber threat surface. Recuperado 26 de mayo de 2022, de https://www.securitymadesimple.org/cybersecurity-blog/top-7-popular-cyber-threat-models.
  4. (2021). The 2021 Security Outcomes Study. https://www.cisco.com/c/dam/en/us/products/collateral/security/2020-outcomes-study-main-report.pdf.
  5. Della Corte, A. (2019, 2 junio). Threat Modeling. Andrea Della Corte. Recuperado 20 de mayo de 2022, de https://dellacorte.me/information-security/threat-modeling/.
  6. Fruhlinger, J. C. (2020, 14 mayo). Qué es el modelado de amenazas. CIO Perú. Recuperado 17 de mayo de 2022, de https://cioperu.pe/articulo/30200/que-es-el-modelado-de-amenazas/.
  7. Hajrić, A., Smaka, T., Baraković, S., & Baraković, J. (2020). Methods, Methodologies, and Tools for Threat Modeling with Case Study. Telfor Journal, Vol. 12(No. 1).
  8. Hsu, T. (2018). Hands-On Security in DevOps. Van Haren Publishing.
  9. (2018, febrero). ISO 31000:2018(es) Gestión del riesgo — Directrices. ISO Online Browsing Platform. Recuperado 20 de mayo de 2022, de https://www.iso.org/obp/ui#iso:std:iso:31000:ed-2:v1:es
  10. Kohnfelder, L., & Garg, P. (1999, abril). The threats to our products. https://adam.shostack.org/microsoft/The-Threats-To-Our-Products.docx.
  11. Larcom, B. (2012, 27 febrero). Threat Modeling Using Trike [Diapositivas]. Octotrike.org. http://www.octotrike.org/talks/Trike-Mozilla-20120227.pdf.
  12. Larcom, B., & Saitta, E. (2009). Trike. Org. Recuperado 25 de mayo de 2022, de http://www.octotrike.org/.
  13. (s. f.). Microsoft Security Development Lifecycle Threat Modelling. Recuperado 27 de mayo de 2022, de https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling.  
  14. Obiora Nweke, L., & Wolthusen, S. (2020). A Review of Asset-Centric Threat Modelling Approaches. (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 11(No. 2).
  15. Ohlinger, M. (2022, 7 abril). Análisis de modelos de amenazas – BizTalk Server. Microsoft Docs. Recuperado 20 de mayo de 2022, de https://docs.microsoft.com/es-es/biztalk/core/threat-model-analysis.
  16. PTA Technologies. (2007). The PTA (Practical Threat Analysis) Methodology in a Nutshell. Practical Threat Analysis. Recuperado 17 de mayo de 2022, de http://www.ptatechnologies.com/Documents/PTA_InANutshell.pdf.
  17. PTA Technologies. (2008). PTA – Practical Threat Analysis Calculative Tool. Practical Threat Analysis. Recuperado 17 de mayo de 2022, de http://www.ptatechnologies.com/Documents/PTA_Calculative_Tool.pdf.
  18. Rivera, A. (2021, 19 abril). El modelado de amenazas como primera línea de defensa. Magazcitum. Recuperado 17 de mayo de 2022, de https://www.magazcitum.com.mx/index.php/archivos/5490.
  19. Saitta, P., Larcom, B., & Eddington, M. (2005, julio). Trike v.1 Methodology Document [Draft].

http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf.

  1. Shawn, H. (2019, 7 octubre). Uncover Security Design Flaws Using The STRIDE Approach. Microsoft Docs. Recuperado 17 de mayo de 2022, de https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach
  2. Shostack, A. (2014). Threat Modeling: Designing for Security (Illustrated ed.).
  3. Solhaug, B. (2011, agosto 21–27). Part II: Example-Driven Walkthrough of the CORAS Method [Conferencia]. SECURWARE 2011–08-21, Niza, Francia. https://www.iaria.org/conferences2011/filesSECURWARE11/part2_securware_CORAS.pdf.
  4. Source Forge. (2015, 16 noviembre). The CORAS Method. The Coras Method. Recuperado 23 de mayo de 2022, de http://coras.sourceforge.net/.
  5. Wigmore, I. (2017, febrero 1). VUCA (volatilidad, incertidumbre, complejidad y ambigüedad). ComputerWeekly.es. Recuperado 30 de octubre de 2021, de https://www.computerweekly.com/es/definicion/VUCA-volatilidad-incertidumbre-complejidad-y-ambigueedad.

 

[1] (BID & OEA, 2020), (Cisco, 2021), (Checkpoint Software, 2021) y (LexisNexis, 2021).

[2] Término empleado para representar los adjetivos volátil, incierto, complejo y ambiguo (Wigmore, 2017).