Integración del modelado de riesgos con DevOps

Los autores de esta publicación son Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez y Ben Hanson

Introducción

El modelado de riesgos es un método de seguridad importante que ayuda a identificar y priorizar las mitigaciones de riesgos más importantes para una aplicación o sistema. En este documento se incluyen algunas reflexiones sobre cómo es posible adoptar el modelado de riesgos de forma más eficaz y eficiente, integrarlo con metodologías y herramientas modernas de DevOps y centrarse en el valor proporcionado a todos los actores implicados en el ciclo de vida de desarrollo de software.

¿Es este documento para usted?

Este documento es el resultado del trabajo de un pequeño equipo de expertos en modelado de riesgos y seguridad de Microsoft e incorpora aportaciones e ideas de algunos de los expertos más destacados de fuera de Microsoft. Intenta abordar una pregunta sencilla pero urgente: ¿qué debemos hacer para asegurarnos de que el proceso de modelado de riesgos que usamos esté actualizado según los requisitos modernos impuestos por las metodologías ágiles y DevOps, de modo que proporcionemos el valor necesario a un coste más bajo?

Si es propietario de un producto, miembro de un equipo de seguridad o simplemente un desarrollador que está considerando la posibilidad de adoptar el modelado de riesgos como parte del ciclo de vida de desarrollo, este documento es para usted.

De forma análoga, si ya ha adoptado el modelado de riesgos, puede encontrar ideas prácticas para mejorar el proceso.

Sin embargo, el documento está diseñado para introducir ideas a fin de mejorar los procesos actuales o adoptar correctamente el modelado de riesgos como parte del proceso de DevOps. No presenta herramientas ni productos específicos, aunque esperamos que ver esas ideas implementadas por algunas herramientas o productos en el futuro. Por lo tanto, no encontrará anuncios de nuevas herramientas o vistas previas de las próximas características aquí.

¿Por qué es importante el modelado de riesgos?

El modelado de riesgos es uno de los enfoques principales para diseñar soluciones de software de forma segura. Mediante el modelado de riesgos, se analiza un sistema que identifica vectores de ataque y se desarrollan acciones para mitigar los riesgos provocados por esos ataques. De forma adecuada, el modelado de riesgos es un componente excelente de cualquier proceso de administración de riesgos. También puede ayudar a reducir los costes mediante la identificación y corrección de problemas de diseño en las primeras fases. Un antiguo estudio de NIST estimaba que el coste de corregir un problema de diseño en el código de producción era aproximadamente 40 veces mayor que repararlo durante la fase de diseño. También evita incurrir en costes debidos a incidentes de seguridad para los problemas de diseño finales. Tenga en cuenta que en el informe 2022 Cost of Data Breach Report de IBM Security y Ponemon Institute se estima que el coste promedio de una vulneración de datos es de 4,35 millones de dólares. En el caso de las llamadas megavulneraciones, que implican que se ponen en peligro más de 50 millones de registros, el coste promedio alcanza los 387 millones de dólares.

El modelado de riesgos es la primera actividad que puede hacer para proteger la solución porque funciona en el diseño de la solución. Esta característica hace que sea la práctica de seguridad más eficaz que puede aplicar a su SDLC.

Microsoft tiene una larga historia con el modelado de riesgos. En 1999, dos empleados de Microsoft (de aquel entonces), Loren Kohnfelder y Praerit Garg, escribieron un documento titulado The threats to our products. En este documento se introdujo el enfoque STRIDE, un sinónimo del proceso de modelado de riesgos de Microsoft.

El modelado de riesgos es un proceso evolutivo

El modelado de riesgos no es un proceso estático; evoluciona a medida que cambian las necesidades y las tecnologías.

• Los ataques de la cadena de suministro, como el reciente dirigido a SolarWinds, demuestran la necesidad de cubrir con el modelado de riesgos más escenarios que la propia solución, incluido el desarrollo y la implementación.

• Las vulnerabilidades de código abierto, como la reciente de Log4j, han demostrado la necesidad de complementar el enfoque actual en función de la adopción de herramientas de análisis de composición de software para analizar en busca de componentes vulnerables mediante el diseño de la solución de forma defensiva para limitar su exposición.

• La aplicación de nuevas tecnologías, como Machine Learning, presenta nuevos vectores de ataque que deben entenderse y controlarse. Considere, por ejemplo, la posibilidad de reproducir sonidos creados de forma malintencionada y que los oídos humanos no pueden escuchar para provocar la ejecución de comandos mediante servicios de IA, como se describe en https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.

En Microsoft, los diferentes grupos de productos practican diferentes variantes del modelado de riesgos en función de sus requisitos de seguridad específicos. Cada variante tiene como objetivo garantizar un nivel adecuado de garantía de seguridad a los escenarios a los que se aplica, pero el significado de "adecuado" cambia en función del contexto específico.

Por ejemplo, la protección de Windows es diferente de la protección de Azure Cognitive Services porque esos sistemas tienen tamaños y características muy diferentes. Un aspecto clave del modelado de riesgos es equilibrar su coste con respecto a la tolerancia al riesgo de una aplicación. Aunque esto puede dar lugar a la decisión de evitar el modelado de riesgos por completo para algunos escenarios, es tan eficaz cuando se hace correctamente que solo se puede recomendar su adopción para todas las iniciativas de TI, incluidos los proyectos de desarrollo de software e implementación de infraestructura.

La importancia de centrarse en el ROI

Durante el último par de años se ha observado un aumento constante en el interés por el modelado de riesgos como un proceso clave de desarrollo de software. Este interés se debe al aumento exponencial de los ataques en infraestructuras y soluciones. Iniciativas como NIST Recommended Minimum Standard for Vendor or Developer Verification of Code y Threat Modeling Manifesto han aumentado aún más la demanda hasta el punto de que los enfoques actuales han mostrado algunos límites. Por ejemplo, los resultados del modelado de riesgos dependen en gran medida del proceso adoptado y de quién realiza el modelo de riesgos. Por lo tanto, existe una preocupación por conseguir una mayor calidad constantemente fuera de la experiencia.

No obstante, ¿qué significa calidad para el modelado de riesgos? Para nosotros, un modelo de riesgos de calidad debe tener las siguientes características:

• Debe identificar mitigaciones accionables, actividades que puede realizar para reducir las posibles pérdidas como consecuencia de ataques. Accionable significa que esas mitigaciones deben estar bien definidas, lo que significa que obtiene suficiente información para implementarlas y, a continuación, probar la implementación. Esto también significa que deben proporcionarse para permitir un fácil consumo del equipo de desarrollo. Con DevOps y las metodologías ágiles, esto significa que hay una vía fácil para importar las mitigaciones en el trabajo pendiente.

• Para cada mitigación, debe identificar su estado. Algunas mitigaciones son nuevas, mientras que otras ya existían. El modelo de riesgos debe reconocer lo que ya existe y centrarse en el riesgo actual para identificar cómo mejorar la situación.

• Debe identificar claramente por qué cada mitigación es necesaria mediante su vinculación a las amenazas respectivas.

• Además, las mitigaciones tienen una intensidad relativa para cada amenaza. Por ejemplo, el cifrado TLS puede ser una mitigación fuerte para el riesgo de que se revelen datos en tránsito y, al mismo tiempo, puede ser una mitigación casi completa para el riesgo de que el servidor se haya suplantado electrónicamente.

• Las amenazas deben ser creíbles, estar bien definidas y ser específicas de la solución.

• Las amenazas deben tener una gravedad asociada, que debe tener en cuenta tanto su probabilidad como el impacto. La gravedad debe ser razonable e idealmente no debe estar sesgada.

• Debe ser posible obtener una visión completa de los riesgos y la forma en que se pueden abordar. Esta visión sería fundamental para impulsar una conversación útil con el equipo de seguridad y con los responsables de toma de decisiones empresariales, y nos permitiría ocultar las complejidades innecesarias.

En esta lista ya se muestra un concepto importante: el modelado de riesgos puede proporcionar valor a muchos roles implicados durante el ciclo de vida del software, pero cada rol tiene necesidades y requisitos diferentes. Por ejemplo, los desarrolladores deben recibir información clara sobre lo que necesitan implementar y cómo comprobar que lo implementado se comporta según lo previsto. Por otro lado, el equipo de seguridad suele preocuparse por la seguridad general del ecosistema de infraestructura y aplicaciones propiedad de la organización; por lo tanto, necesitan recibir información que permita decidir si el sistema en el ámbito es lo suficientemente seguro como para satisfacer sus requisitos de cumplimiento. Por último, los propietarios de productos y los responsables de toma de decisiones empresariales deben comprender qué se necesita para que el riesgo sea aceptable para la organización.

Estas necesidades diferentes requieren proporcionar visiones diferentes sobre el modelo de riesgos, cada una de ellas centrada en un escenario de uso específico.

Un problema típico con el modelado de riesgos es que cuanto más exitoso sea, más difícil será que los pocos expertos disponibles cubran la demanda a la vez que proporcionan la alta calidad esperada de esta experiencia. Como resultado, en algunos casos, la calidad puede verse afectada negativamente. Todo va bien hasta que el modelado de riesgos deja de proporcionar un valor significativo en comparación con la inversión. Más de un par de organizaciones se ven afectadas por este problema. Ya ha habido un par de informes de los responsables de toma de decisiones empresariales que empiezan a cuestionar el modelado de riesgos porque no ofrece un valor significativo para el coste.

Con el valor, nos referimos al valor empresarial, que es la capacidad de proporcionar la información necesaria para comprender los riesgos que representa el sistema en el ámbito e impulsar un proceso de decisión significativo para seleccionar las mitigaciones adecuadas que se deben implementar. Además, el valor también está relacionado con proporcionar la información correcta a los desarrolladores y evaluadores. Por último, el valor está relacionado con la comunicación del riesgo residual a todas las partes implicadas. Por ejemplo, podemos medir el impacto del proceso de modelado de riesgos para medir el valor. Supongamos que medimos el riesgo general de la solución asignando un número a la gravedad identificada para cada amenaza. En ese caso, esperamos que el riesgo general disminuya con el tiempo por efecto del modelo de riesgos. Si el riesgo general sigue siendo constante o aumenta, es posible que tengamos un problema. Cuanto mayor sea la disminución, mayor será el impacto del modelo de riesgos. Por supuesto, el modelo de riesgos no controlaría las mitigaciones implementadas. Es responsabilidad del propietario del producto decidir qué se debe implementar. No obstante, la ventaja de vincular la eficacia del modelo de riesgos con la implementación real de las mitigaciones es que aumenta el impacto en la seguridad real de la solución, lo que reduce el riesgo de que el modelo de riesgos siga siendo un ejercicio teórico.

En su lugar, el coste está relacionado con las actividades necesarias para realizar el propio modelo de riesgos, que es el tiempo que necesitan todas las partes implicadas para generar el modelo de riesgos y analizarlo.

Esto plantea la siguiente pregunta: ¿podemos definir un proceso de modelado de riesgos centrado en maximizar el valor empresarial y minimizar el coste?

La importancia de DevOps

Ya hemos resaltado lo importante que es asegurarse de que el modelado de riesgos sea una práctica valiosa integrada con el proceso de DevOps. Esto significa que el proceso debe estar disponible para todos los miembros del equipo, normalmente mediante su simplificación y automatización. Lo más importante es que centrarse en el modelado de riesgos para DevOps significa que necesitamos asegurarnos de que la experiencia esté profundamente integrada con los procesos de DevOps existentes.

El modelado de amenazas no debe convertirse en otra carga, sino quedebe ser un recurso para facilitar la recopilación y la determinación de requisitos de seguridad, el diseño de soluciones seguras, la inclusión de actividades en la herramienta Task & Bug Tracking de elección y la evaluación del riesgo residual dado el estado actual y futuro de la solución.

Alineación con DevOps

Podemos emplear varias técnicas para alinear el modelado de riesgos con la práctica actual de DevOps.

Amenazas y mitigaciones

En primer lugar, debemos centrar el proceso de modelado de riesgos en lo que se debe hacer. Las amenazas, que son los patrones de ataque y cómo pueden ocurrir, son necesarias para explicar por qué el equipo debe implementar un control de seguridad. También son un factor para determinar cuándo se deben implementar mitigaciones. Aun así, el objetivo real es determinar lo que se debe hacer: las mitigaciones. Por lo tanto, el enfoque debe conducir a la identificación rápida de las mitigaciones necesarias y debe informar del proceso de decisión para que sea más fácil determinar qué hacer y cuándo. La meta principal de este proceso de decisión es tener las mitigaciones seleccionadas en el trabajo pendiente para que formen parte del proceso estándar. Lo ideal es que la herramienta de modelado de amenazas y la herramienta de seguimiento de errores y tareas se sincronicen para reflejar las actualizaciones del estado de mitigación en el modelo de amenazas. Esto permite revisar el riesgo residual de forma dinámica y automática, lo que es fundamental para apoyar las decisiones informadas como parte de las coreografías habituales de la metodología ágil adoptada, como la reunión de planificación de sprints.

¿Qué puede hacer hoy?

Como experto en modelado de amenazas, debe asegurarse de implementar un proceso de modelado de amenazas que sea capaz de identificar claramente las acciones e incluirlas en su tarea y seguimiento de errores de su elección. Una manera puede consistir en la adopción de una de las muchas herramientas de modelado de riesgos capaces de automatizar este proceso.

Como desarrollador, debe centrarse en los controles de seguridad identificados como necesarios. El proceso debe diseñarse para proporcionarlos de la misma manera que espera recibir cualquier otra actividad.

Características, casos de usuarios y tareas

Ya hemos indicado que las mitigaciones representan el artefacto más importante generado por el modelo de riesgos en relación con la integración de DevOps. Por lo tanto, es importante definir claramente el tipo de objetos creados a partir de esas mitigaciones en la herramienta Task & Bug Tracking de su elección. Algunas mitigaciones pueden durar más que un sprint. Por lo tanto, puede ser mejor crearlos como características. No obstante, muchos son más fáciles y podrían implementarse en un único sprint; por lo tanto, sería posible representarlos como casos de usuarios o tareas. Aunque la generación de diferentes tipos de elementos de trabajo puede ser posible, puede dar lugar a un proceso complicado que puede provocar errores y confusión. Por esta razón, parece más práctico seguir con un solo tipo de elemento de trabajo. Dado que las mitigaciones pueden considerarse elementos secundarios de los casos de usuarios, puede considerar la posibilidad de representarlas como tareas, lo que implica relajar el requisito de que se ejecute el tipo de elemento de trabajo mencionado en un único sprint.

¿Qué puede hacer hoy?

Asegúrese de que las mitigaciones identificadas por el modelo de riesgos se representen en el trabajo pendiente. Identifique una manera de representarlas claramente.

Casos de usuario

Las mitigaciones no son la única parte de artefactos de un modelo de amenazas, que podría y debe alinearse con lo que tiene en la herramienta Task & Bug Tracking. Por ejemplo, puede que también desee representar amenazas. Este objetivo puede lograrse si se amplían los casos de usuarios a través de la adición de una cláusula WITHOUT a la habitual "As a [who am I] I want to [what I want] so that I can [do something]". Por ejemplo: "As a user, I want to pay with my credit card so that I can buy some goods, WITHOUT having my credit card stolen data stolen". La cláusula WITHOUT se puede asignar a una o varias amenazas y, a veces, puede expresar requisitos de seguridad. Al garantizar que esta alineación entre las amenazas y las cláusulas WITHOUT se hace explícita dentro del modelo de riesgos, podemos asegurarnos de que el equipo refleje los posibles riesgos y se ocupe de ellos porque se incluyen como parte de los casos de usuarios. También puede usar esta relación para asignar cada requisito de seguridad identificado como parte de los casos de usuarios a al menos una amenaza.

Está bien saber

La cláusula WITHOUT no es una idea original del equipo que ha producido esta página. No estamos seguros de quién la introdujo por primera vez, pero estamos agradecidos a quien haya tenido esta idea.

Figura 1: alineación de los requisitos

Por ejemplo, en la imagen anterior se muestran las siguientes situaciones:

• La amenaza A está vinculada al caso de usuario 1 a través de la cláusula WITHOUT 1.

• La amenaza B está vinculada al caso de usuario 2 a través de la cláusula WITHOUT 2.

• La amenaza B también está vinculada al caso de usuario 3. No obstante, el caso de usuario 3 no está asignado a ninguna cláusula WITHOUT. ¿Por qué? Representa una anomalía potencial que debe investigar.

• La amenaza B también está vinculada al caso de usuario 1. Aún no está claro si deberíamos permitir que los casos de usuarios estén vinculados a más de una amenaza.

• La amenaza C está vinculada al caso de usuario 4, que está asociada a WITHOUT 3 y 4. Aún no está claro si deberíamos permitir tener más de una cláusula WITHOUT.

• La amenaza D no está vinculada a ningún caso de usuario. ¿Falta un caso de usuario o una cláusula WITHOUT?

• El caso de usuario 5 está vinculado a una cláusula WITHOUT, pero no tiene ninguna amenaza asociada. ¿Falta una amenaza o simplemente un vínculo entre un caso de usuario y una amenaza?

Rara vez identificamos los requisitos de seguridad como parte del modelo de riesgos. Por lo tanto, la cláusula WITHOUT presenta la oportunidad de integrar aún más la experiencia al ampliar los modelos de riesgos con requisitos de seguridad y vincularlos con los casos de usuarios relacionados. Este enfoque desempeñaría un papel importante en el desarrollo de la experiencia del modelado de riesgos y pasaría de ser una evaluación repetida a lo largo del tiempo para convertirse en la herramienta de diseño de seguridad para DevOps.

¿Qué puede hacer hoy?

Empiece a usar la cláusula WITHOUT en los casos de usuarios.

Asigne las amenazas que identifique a los casos de usuarios con cláusulas WITHOUT y viceversa.

Una experiencia integrada

Puede aplicar la misma idea a otros escenarios. Por ejemplo, el modelo de amenazas podría vincular los requisitos de seguridad con artefactos dentro del propio modelo de amenazas, como amenazas y mitigaciones, y los de la herramienta Track & Bug Tracking. Por ejemplo, el requisito de implementar la supervisión para identificar ataques en curso debe asignarse a todas esas mitigaciones relacionadas con la supervisión y, a continuación, a los artefactos correspondientes en la herramienta Task & Bug Tracking. Como resultado, sería fácil identificar situaciones en las que no se cumple un requisito de seguridad: de hecho, no estaría vinculado a nada.

Puede usar los mismos vínculos entre los artefactos de la herramienta Task & Bug Tracking y las amenazas y mitigaciones identificadas por el modelo de amenazas para facilitar la priorización de las actividades de seguridad. La seguridad suele implementarse en último lugar, a veces para abordar vulnerabilidades de forma reactiva identificadas por alguna herramienta o una prueba de penetración. Por el contrario, sería más eficaz implementar las mitigaciones junto con las características o casos de usuarios relacionados. ¿Por qué esperar a implementar los controles para proteger los datos de tarjetas de crédito cuando se deben implementar junto con las funciones de pago relacionadas? El modelo de riesgos debe resaltar esas relaciones y proporcionar una manera sencilla de determinar cuándo la implementación de alguna característica durante un sprint requiere la implementación de alguna característica de seguridad relacionada. Esta información podría usarse, por ejemplo, durante la reunión de planificación de sprints para tener un debate útil e impulsar una priorización informada. El mecanismo es sencillo. Supongamos que el propietario del producto de un proyecto en el que trabajamos decide planificar un caso de usuario para el siguiente sprint. Dicho caso de usuario tiene una cláusula WITHOUT que está vinculada a la amenaza. El modelo de riesgos identifica varias mitigaciones para la misma amenaza. Por lo tanto, podemos deducir inmediatamente que deberíamos priorizar una o varias de las mitigaciones identificadas.

Figura 2: priorización de la seguridad

Por ejemplo, en la imagen anterior, podemos ver que el caso de usuario 1 está vinculada a la amenaza 1, que a su vez está vinculada a las mitigaciones A y B. Por lo tanto, también debemos considerar la posibilidad de implementar una mitigación o ambas.

¿Qué puede hacer hoy?

Vincule casos de usuarios con cláusulas WITHOUT a los elementos de trabajo correspondientes a las mitigaciones seleccionadas con el modelo de riesgos como referencia. Al planificar el siguiente sprint, asegúrese de priorizar las actividades de seguridad vinculadas al implementar uno de esos casos de usuarios con cláusulas WITHOUT.

Integración para resaltar errores de alineación

Una vez que empezamos a pensar en cómo podríamos vincular los artefactos que componen el modelo de amenazas con los de la herramienta Task & Bug Tracking, resulta más fácil identificar oportunidades para mejorar la calidad de ambos. La clave es sacar provecho de sus relaciones para resaltar discrepancias y aprovechar la información presente en uno para complementar, integrar e interpretar lo que está presente en el otro. Como se ha explicado anteriormente, puede hacerlo sin afectar significativamente a cómo funciona el equipo. Esto se debe a que el enfoque se basa en la información existente y crea relaciones entre los distintos objetos de los distintos mundos. Por lo tanto, el modelo de riesgos se convertirá en la fuente de la verdad para la seguridad de la solución. Al mismo tiempo, el trabajo pendiente se alinea continuamente con el estado de la solución.

¿Qué puede hacer hoy?

Compruebe periódicamente que no haya amenazas sin asignar ni casos de usuarios con cláusulas WITHOUT.

Modelado de riesgos y las operaciones

Todas esas ideas se centran principalmente en el aspecto de desarrollo de DevOps. ¿Podemos hacer algo para mejorar también las operaciones? Creemos que sí. Por ejemplo, sería posible usar el modelado de riesgos como herramienta para facilitar el análisis de la causa principal, ya que proporciona una visión completa del sistema desde una perspectiva de seguridad y, por tanto, puede proporcionar una mejor comprensión de las implicaciones de algunos ataques. Para lograrlo, sería necesario integrar el modelo de riesgos con las fuentes existentes de las herramientas de supervisión elegidas. Este enfoque puede representar un complemento para el SIEM elegido.

Otra idea para integrar el modelado de riesgos con las operaciones consiste en usar el primero para impulsar el diseño de cómo podría ocurrir esto último. Un ejemplo de esto es el diseño de eventos para la solución. El modelado de riesgos identifica posibles ataques y podemos usar ese conocimiento para identificar los eventos que la solución en el ámbito puede generar cuando esos ataques fracasen. Si realiza una validación de entrada estricta, un atacante malintencionado necesitará algunos intentos antes de llevar a cabo la acción correctamente. Inicialmente, los intentos fracasan y uno de ellos finalmente se realiza correctamente. Al generar eventos para cada error y desencadenar alertas cuando se alcanza algún umbral, es posible que pueda detectar ataques y tomar medidas para corregirlos. Estas situaciones rara vez se detectan si se limita a supervisar la infraestructura. Por lo tanto, es necesario incluir eventos personalizados, que el equipo debe diseñar e implementar para que el SOC pueda sacar provecho de ellos.

Además, es posible que este último no sepa mucho sobre la solución. Por lo tanto, es posible que el SOC no pueda determinar cómo reaccionar cuando se produce un error en la validación de entrada. Desafortunadamente, cuando se produce una vulneración de datos, es imperativo reaccionar rápidamente para reducir el daño directo y la probabilidad y la entidad de las posibles sanciones.

Por lo tanto, tenemos que planificar con antelación qué se debe supervisar, en qué condiciones podemos tener un problema y qué hacer cuando esto sucede. La mejor manera de identificar esos eventos consiste en confiar en un modelo de riesgos. Por lo tanto, sería útil sacar provecho de él para generar artefactos estandarizados para guiar y acelerar la implementación de las configuraciones necesarias para impulsar la supervisión y auditoría y facilitar la respuesta a incidentes.

¿Qué puede hacer hoy?

Use activamente el modelo de riesgos para identificar los eventos que puede generar para cada amenaza. Dichos eventos puede proporcionarlos la infraestructura o algo que la aplicación debe generar. Incluya elementos de trabajo en el trabajo pendiente para asegurarse de que se implementan esos eventos.

Trabaje activamente con los equipos de operaciones y seguridad, incluido el equipo de SOC, para asegurarse de que se saque provecho de los eventos para generar alertas e identificar incidentes de seguridad.

El impacto en el ROI

Es posible que se pregunte por qué esas técnicas pueden afectar positivamente al ROI del modelado de riesgos. Desde nuestro punto de vista, son cruciales para aumentar el valor del modelado de riesgos para los equipos de DevOps. El problema que hemos visto repetidamente es que los equipos perciben la seguridad como un coste que proporciona un valor limitado y requiere mucho trabajo imprevisto. A veces, no está claro por qué deben invertir tanto tiempo para solucionar la seguridad. Como resultado, la seguridad se convierte en un problema en lugar de ser una oportunidad. El modelado de riesgos tiene la posibilidad de superar esos problemas porque proporciona las razones para implementar la seguridad. Además, se puede iniciar al principio del proceso de desarrollo y evita errores de diseño que pueden costar mucho si no se detectan pronto. Las técnicas anteriores tienen como objetivo integrar mejor el modelado de riesgos con DevOps. Esto garantiza que los responsables de toma de decisiones empresariales y los desarrolladores perciban el modelado de riesgos como un complemento natural para el proceso de desarrollo y operaciones. Por lo tanto, el valor recibido mediante la adopción del modelado de riesgos aumenta y sus costes se reducen debido a la integración con las diversas herramientas que ya están en uso.

Simplificación del trabajo de los modeladores de riesgos

Otro aspecto importante necesario para mejorar el ROI del modelado de riesgos está relacionado con la reducción de su coste y el aumento del número de personas capaces de entregarlo a la vez que se mantienen niveles de calidad más homogéneos.

Hay muchos intentos de abordar la escasez de personas competentes. Algunos de ellos se basan en la participación activa del equipo completo de DevOps en el ejercicio de modelado de riesgos. La idea es identificar a un líder de la iniciativa, que es alguien con conocimientos intermedios sobre el proceso, pero no es necesariamente un experto, y que dirija el debate entre los demás miembros del equipo. Los firmantes de Threat Modeling Manifesto respaldan activamente este enfoque.

Estamos de acuerdo en que este enfoque permite obtener un buen valor y representa una mejora con respecto a la situación actual. También proporciona buena información y permite al equipo aumentar su cultura de seguridad. Sin embargo, no está exento de inconvenientes, porque cubre solo unos cuantos problemas y deja fuera a muchos. Esto crea un problema de coherencia porque sería demasiado fácil profundizar y perder tiempo valioso en los problemas secundarios mientras se dejan de lado otros importantes. La experiencia del líder desempeñaría un papel importante para evitar que se produjesen esas situaciones. Además, este enfoque requiere mucho tiempo de todos los miembros del equipo para debatir cada problema.

Por este motivo, dedicar incluso un par de horas por sprint para este ejercicio puede representar una inversión significativa. Todos saben que la mayoría de los equipos tienden a perder tiempo en grandes reuniones que implican a todos y esas sesiones de modelado de riesgos no serían una excepción. Sin embargo, este enfoque es excelente para productos pequeños, en los que el equipo consta de unos cuantos miembros sénior.

Un método diferente

Dadas las limitaciones del enfoque anterior, preferimos limitar el número de reuniones, su duración y el número de participantes. Por lo tanto, la responsabilidad del modelador de riesgos sería más significativa: no solo para dirigir las entrevistas, sino también para crear y mantener el propio modelo de riesgos. Este enfoque requiere competencias y conocimientos más significativos. Los modeladores de riesgos pueden estar representados por expertos en seguridad o por miembros del equipo de seguridad interno. La mayoría de las organizaciones elegirían a los primeros porque el equipo de seguridad suele estar totalmente reservado.

Los expertos en seguridad son miembros de los equipos de DevOps con un interés particular en la seguridad. No están especializados en absoluto, pero tienen un conocimiento básico y la voluntad de mejorar la posición de seguridad de su equipo. La idea es crear una conexión con privilegios entre los expertos en seguridad y el equipo de seguridad interno para que los primeros se capaciten para ayudar a sus equipos a hacer lo correcto, mientras que el equipo de seguridad puede reducir su carga de trabajo. Con el modelado de riesgos, los expertos en seguridad actuarían como modeladores de riesgos y el equipo de seguridad interno tendría la responsabilidad de guiarlos y revisar su trabajo.

¿Qué puede hacer hoy?

Investigue la posibilidad de adoptar un programa de expertos en seguridad y sacar provecho de él para fortalecer aún más su ciclo de vida de desarrollo de software seguro.

El papel de las bases de conocimiento

Un problema significativo con el modelado de riesgos es asegurarse de que la calidad de la experiencia y el valor del equipo de DevOps sea alto independientemente de quién realice el modelo de riesgos. Con los expertos en seguridad, este problema se vuelve aún más urgente. Una idea para abordar esto es proporcionar bases de conocimiento para impulsar la creación del modelo de riesgos. Las bases de conocimiento para el modelado de riesgos son paquetes de información sobre un contexto específico: contienen una definición de las entidades relacionadas con ese contexto, los patrones de ataque posibles sobre esas entidades y las mitigaciones estándar que se pueden aplicar. Las bases de conocimiento permiten a la organización obtener resultados mejores y más coherentes porque representan material de referencia que guía a los modeladores de riesgos de una manera prescriptiva. Las bases de conocimiento deben tener reglas que nos permitan aplicar amenazas y mitigaciones a un sistema automáticamente. Esta automatización nos permitiría superar el hecho de que algunos modeladores de riesgos podrían no tener la experiencia necesaria para determinar si se debe aplicar una amenaza o si alguna mitigación es eficaz.

Las bases de conocimiento no son una idea nueva: muchas herramientas actuales de modelado de riesgos ya las admiten de alguna forma. No obstante, muchas implementaciones actuales tienen desventajas significativas. Por ejemplo, debería poder mantener las bases de conocimiento fácilmente. Su mantenimiento es un problema que sigue sin resolverse. Por ejemplo, no es fácil identificar los mejores orígenes de información que se usarán para crearlas. Además, el mantenimiento suele ser manual. La creación y el mantenimiento de las bases de conocimiento deben ser responsabilidad del equipo de seguridad interno de la organización. Esperamos que las empresas empiecen a proporcionar bases de conocimiento para las herramientas de modelado de riesgos más comunes para elevar algunas de las cargas de sus clientes en el futuro. Esas bases de conocimiento deben ser flexibles para respaldar y facilitar su adopción incluso por parte de las organizaciones más maduras, que necesitan adaptar dichas bases de conocimiento a sus prácticas, directivas y reglamentos.

¿Qué puede hacer hoy?

Considere la posibilidad de dedicar parte del esfuerzo del equipo de seguridad centralizado para desarrollar bases de conocimiento que puedan usar los distintos equipos de desarrollo para acelerar el modelado de riesgos.

Consumo de bases de conocimiento

Otro problema con las bases de conocimiento es que a veces son demasiado complejas de consumir. Muchas de ellas intentan ser completas al incluir problemas esenciales y menos críticos. Desafortunadamente, no todos los sistemas los requieren todos. Le gustaría adoptar un enfoque más sencillo cuando el sistema que está analizando es pequeño y no gestiona los datos confidenciales. Por el contrario, querrá profundizar más si el sistema es complejo y procesa los datos de DCP y de alto valor empresarial. Por lo tanto, debe ser posible aplicar diferentes versiones del conocimiento en función del contexto o marcar algunos patrones de ataque y mitigaciones asociadas como "PRINCIPAL". Como resultado, los modeladores de riesgos podrían decidir si quieren una experiencia completa o apostar por lo fácil y minimizar el trabajo necesario.

Hablando de eficiencia, es imperativo asegurarse de que las actividades se simplifican y automatizan tanto como sea posible para reducir la cantidad de trabajo necesaria. Creemos que un punto óptimo para realizar un modelo de riesgos de una solución de tamaño medio debe ser 1 día de trabajo para el modelador de riesgos. Estos resultados solo son posibles si la herramienta de elección proporciona aceleradores para permitir reducir el tiempo necesario. Por ejemplo, si la herramienta aplica 20 tipos diferentes de mitigaciones en 100 lugares diferentes y se le solicita que especifique para cada uno de ellos su estado, sería 5 veces más eficaz si se centrase en el primero en lugar de en el último. La herramienta de elección debe proporcionar esta funcionalidad al mismo tiempo que permite la posibilidad de realizar un trabajo más exhaustivo cuando sea necesario.

¿Qué puede hacer hoy?

Si las bases de conocimiento que usa actualmente no admiten el concepto de amenazas y mitigaciones "PRINCIPALES", considere la posibilidad de eliminar lo que rara vez es necesario o útil para permitir centrarse solo en lo que realmente importa.

A veces, el problema es que las bases de conocimiento adoptadas intentan ser genéricas y cubren varios escenarios. Puede mejorar la situación si las especializa.

Las preguntas adecuadas

Durante nuestro análisis, hemos considerado la posibilidad de usar una herramienta para apoyar un marco de preguntas a fin de impulsar las primeras fases del análisis. Hemos observado que la mayoría de los modeladores de riesgos inexpertos no pueden formular las preguntas adecuadas para obtener la información necesaria para su análisis. Algunos de nuestros expertos han demostrado que es posible determinar algunas preguntas cruciales en función de un diagrama de sistema en el ámbito. Esas preguntas se pueden aplicar automáticamente, con algunas reglas de generación. El problema es que este enfoque puede no proporcionar el valor que parece prometer. Eso se debería a que necesita comprender la lógica detrás de cada pregunta. De lo contrario, no podría evaluar la respuesta y determinar si es satisfactoria. Sin embargo, la generación automatizada de preguntas puede proporcionar un valor significativo a los modeladores de riesgos menos expertos al mejorar su comprensión de los sistemas en el ámbito.

¿Qué puede hacer hoy?

Adopte un enfoque estructurado para hacer preguntas. Por ejemplo, nuestro equipo ha tenido buenos resultados al adoptar Microsoft STRIDE como referencia. Para ello, para cada componente de la solución, haga preguntas como las siguientes:

• Suplantación electrónica: ¿cómo se autentica el componente en los servicios y los recursos que usa?

• Alteración: ¿el componente valida los mensajes que recibe? ¿La validación es flexible o estricta?

• Rechazo: ¿el componente registra las interacciones en un registro de auditoría?

• Divulgación de información: ¿se cifra el tráfico entrante y saliente del componente? ¿Qué protocolos y algoritmos se permiten?

• Denegación de servicio: ¿está configurado el componente en alta disponibilidad? ¿Está protegido contra ataques DDoS?

• Elevación de privilegios: ¿los usuarios tienen asignados los privilegios mínimos necesarios? ¿La solución combina código destinado a usuarios normales con código para usuarios con privilegios elevados?

Se pueden enseñar técnicas como esta y se pueden mejorar con experiencia. Por lo tanto, es importante implementar un enfoque de aprendizaje continuo diseñado para recopilar aprendizajes y distribuirlos en la organización.

El impacto en el ROI

En resumen, es posible identificar muchas ideas para mejorar la eficiencia de la experiencia de modelado de riesgos, su calidad y, en última instancia, aumentar el ROI. Sin embargo, este esfuerzo debe considerarse un proceso continuo, que debe dirigirse a la mejora continua de la práctica.

Conclusiones

El modelado de riesgos es una metodología excelente para mejorar la seguridad de su organización. Si se realiza correctamente, puede proporcionar valor a un coste muy razonable. Ya hemos identificado varias técnicas que pueden resultar esenciales para mejorar el valor del modelado de riesgos para proteger soluciones modernas, entre las que se incluyen las siguientes:

• Alineación del modelo de riesgos con la práctica de DevOps de las siguientes formas:

  • Centrarse en las mitigaciones

  • Vincular mitigaciones con casos de usuarios

  • Resaltar discrepancias entre el modelo de riesgos y el trabajo pendiente

  • Usar el modelo de riesgos para impulsar una supervisión y auditoría de seguridad más completas

• Simplificar la creación de modelos de riesgos y aumentar la coherencia de los resultados:

  • Confiar en expertos en seguridad

  • Adoptar bases de conocimiento para automatizar la identificación de amenazas y mitigaciones

  • Crear mejores bases de conocimiento

  • Proporcionar un marco de preguntas compatible con la automatización

Esperamos que algunas de estas técnicas ya se encuentren en la herramienta de modelado de riesgos de su elección. En el futuro se incluirán más. Sabemos que maximizar el ROI para el modelado de riesgos es un esfuerzo a largo plazo que requiere respuestas que aún no tenemos. También sabemos que todavía se desconocen algunas preguntas. En este documento se debe proporcionar algún sustento para pensar y, con suerte, la información podría ayudarle a mejorar la forma en que lleva a cabo el modelado de riesgos. Esperamos que pueda ser un faro para usted y para nosotros y creemos que será útil dirigir nuestros esfuerzos durante los próximos años.