El modelado de amenazas (MA) es una práctica de seguridad fundamental en cualquier proceso de desarrollo de software. Uno de sus principales diferenciadores con respecto a otras prácticas es que MA es una de las actividades con mejor retorno de inversión, ya que permite identificar y gestionar fallas de seguridad a nivel de diseño, antes de que estas lleguen a ser implementadas en el código fuente, en el cual el costo de mitigación sería exponencialmente mayor. Su 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.

A diferencia de las acciones realizadas en aplicaciones ya construidas, como las pruebas de seguridad y revisiones de código fuente, en las que se identifican fallas de seguridad generadas por errores de codificación u omisiones en el cumplimiento de estándares de desarrollo, en el MA se tiene el objetivo de identificar y eliminar fallas de seguridad a nivel de diseño, desde las fases iniciales del ciclo de vida de desarrollo de software. Este tipo de fallas pueden referirse a vulnerabilidades o incluso a requerimientos de seguridad que están siendo omitidos y que deben ser implementados en el aplicativo.

Identificar las amenazas y posibles consecuencias de un ataque exitoso hacia el aplicativo, antes de que este sea construido, es la primera línea de defensa que debe ser forjada.

MA en el proceso de desarrollo de software

En un escenario ideal, el MA debe ser desarrollado tan pronto como la arquitectura del software haya sido definida, esto es, una vez que los requerimientos de seguridad han sido identificados, documentados y han comenzado las actividades de la fase de diseño. Sin embargo, es importante tener presente que, independientemente de lo tarde que pudiera realizarse el MA en el ciclo de vida de desarrollo, siempre será fundamental considerar las debilidades a nivel de diseño, ya que el costo de mitigar fallas de seguridad suele incrementarse cuando estas son descubiertas en las fases finales del ciclo de desarrollo, o peor aún, cuando el aplicativo se encuentra en producción.

Imagen 1. Costo de remediación de fallas de seguridad en el ciclo de vida de desarrollo de software.

El MA puede ser una herramienta muy útil para la definición de requerimientos de seguridad, ya que se basa en una primera revisión general de la arquitectura del software. También puede ser utilizada como una técnica de análisis de diseño desde una perspectiva de seguridad, antes de que se comience a codificar o construir el aplicativo.

A pesar de que se recomienda encarecidamente realizar el MA en fases iniciales del proceso de desarrollo, si esto no puede ser llevado a cabo, también es muy útil si se efectúa cuando el proyecto está próximo a su liberación o incluso si ya tiene tiempo liberado. En estos casos, los siguientes ciclos de desarrollo pueden ser utilizados para mitigar los riesgos que hayan sido identificados en el MA.

¿Cuándo actualizar un MA?

Actualizaciones importantes en el software, creación de nuevos componentes y cambios a nivel diseño de seguridad, derivados de MA anteriores, son algunas de las razones por las cuales es importante considerar realizar nuevamente el modelado. Identificar “cambios importantes” puede ser confuso, por esta razón se sugiere la siguiente lista de cambios a incorporar en dicho análisis:

Tabla 1. Cambios en una aplicación que invalidan un MA.

Debido a que es imposible documentar una lista completa de todos los tipos de cambios que llevan a un nuevo MA, se recomienda que la lista sugerida anteriormente sirva como referencia y sea complementada de acuerdo con las necesidades particulares de cada organización. En algunos casos, la ejecución podría confirmar que el MA anterior aún es vigente, es decir, que los cambios realizados al aplicativo no derivaron en posibles nuevas amenazas.

Definición de alcances en un MA

Definir el alcance es crucial para el éxito en el desarrollo de esta práctica de seguridad, ya que permitirá saber dónde iniciar y dónde concluir. Algunos puntos importantes para tomar en cuenta son:

  • ¿Qué tan profundo será el análisis en el MA hacia la estructura de una aplicación?

La respuesta a esta pregunta dependerá del tamaño y complejidad del aplicativo en cuestión, también dependerá de factores como el entorno de ejecución o despliegue, la infraestructura o servicios que el software consumirá o utilizará, el lenguaje en que será desarrollado y la forma en que será desplegado para su uso, entre otros. No existe una definición que se adecue a todas las aplicaciones, por lo tanto, se deberá analizar cada proyecto para identificar el factor o combinación de factores que será necesario considerar.

  • ¿Cuáles son los prerrequisitos para comenzar el MA?

Se recomienda listar los activos críticos del aplicativo y relacionarlos con cada posible ataque que podrían tener. Otra alternativa es listar cada posible vector de ataque que una amenaza podría materializar, así como todos los posibles puntos en el aplicativo en los que se pueden implementar controles para mitigarlos. Cualquiera que sea el camino seleccionado, tener estas listas finitas permitirá que se realice el MA orientado a un alcance definido y bien conocido.

  • ¿Cuándo o qué significará que el MA ha concluido?

Identificar el punto final es un verdadero problema. Una recomendación es considerar que el MA está completo cuando todas las posibilidades de ataques que podrían afectar a la organización o al mismo aplicativo, de manera significativa, han sido enumeradas y documentadas. Adicionalmente, se puede determinar que está completo cuando todos los posibles controles para proteger la aplicación ante dichos ataques han sido definidos.

 

Metodologías y buenas prácticas para el MA

A continuación, se listan algunas metodologías y buenas prácticas reconocidas por la industria:

  • Es una metodología y también una herramienta opensource, utilizada para realizar MA enfocados principalmente en modelos de requerimientos, diseñados para asegurar que el nivel de riesgo asociado con cada activo sea clasificado y aceptado por los dueños del aplicativo.
  • PASTA (Process for Attack Simulation and Threat Analysis). Proceso de 7 pasos, aplicable a la mayoría de las metodologías de desarrollo de software. Se encarga de alinear los objetivos de negocio con los requerimientos técnicos. También toma en cuenta el cumplimiento de los mismos requerimientos, el análisis de impacto de negocio y un enfoque dinámico para la enumeración, clasificación y gestión de amenazas.
  • ATASM (Architecture, Threats, Attack Surfaces and Mitigations). Enfoque que resalta la importancia de la comprensión estructural de un aplicativo para poder realizar el MA. La arquitectura del aplicativo se descompone en componentes lógicos y funcionales para descubrir todas las superficies de ataques potenciales. Esta descomposición también es utilizada para definir aquellos puntos en los cuales es posible incorporar los controles de seguridad o defensas.
  • Microsoft Threat Modeling Process. Proceso descriptivo para realizar MA que se enfoca en identificar activos, conocer la arquitectura del aplicativo, descomponer la aplicación e identificar y documentar las amenazas; las clasifica de acuerdo con su criticidad.
  • Modelo utilizado para la identificación de amenazas de seguridad en tecnologías de la información. El nombre STRIDE está compuesto por las iniciales de los 6 tipos de amenazas que incluye este modelo: Spoofing, Tampering, Repudiation, Message Disclosure, Denial of Service and Elevation of Privilege.

Cada organización es libre de adoptar la metodología y práctica a utilizar en un MA, o incluso de realizar variaciones en cualquiera de ellas para cubrir sus necesidades.

Fallar en un MA ¿Es posible?

Como con cualquier práctica de seguridad, proceso o actividad que se esté implementando, es importante conocer bajo qué circunstancias podría fallar y también cómo podría ser exitoso.

No se trata solamente de saber cómo fueron omitidas amenazas o fallas de seguridad, también es fundamental identificar fallas en el proceso de MA ejecutado. Por ejemplo, ¿es incorrecto pensar que el MA no es necesario porque el aplicativo en cuestión es sometido a pruebas de seguridad y revisiones de código fuente?, o, ¿es una falla pensar que no hay razones para realizar MA porque el aplicativo ya se encuentra en producción y aparentemente no se han descubierto vulnerabilidades en él? Estas dos preguntas representan fallas de mentalidad. Algunos otros mitos relacionados con este tipo de fallas son:

  • “Nosotros realizamos pruebas de seguridad y revisiones de código manuales y automatizadas, por lo tanto, no necesitamos hacer MA”.
  • “Realizamos un MA cuando la aplicación fue construida, no hay razón para hacer un MA nuevamente”.
  • “Realizar un MA es extremadamente complicado”.
  • “No tenemos expertos de seguridad en el equipo, por lo que es imposible para nosotros hacer un MA”.
  • “Nosotros sí realizamos MA en las fases del ciclo de desarrollo sugeridas y después de cada cambio importante en el aplicativo, por lo tanto, no hay razón para hacer pruebas de seguridad y revisiones de código fuente”.

Todos estos mitos representan una barrera, ya que intentan justificar algún motivo por el cual se debe posponer o incluso no realizar el modelado.

Por otra parte, también existen fallas en la práctica, que regularmente son causadas por no cumplir con una metodología adecuada, por ejemplo:

  • Fallas en el alcance del MA. Es prácticamente imposible que el equipo tenga todo el tiempo necesario o deseado para realizar un MA, por lo tanto, debe haber control sobre lo que realmente se analizará. No definir correctamente el alcance podría afectar el tiempo de ejecución de esta práctica de seguridad.
  • Dedicar tiempo y esfuerzo en áreas que son innecesarias o que ya están bien identificadas. Por ejemplo, expertos en criptografía haciendo énfasis en la implementación de cifrado en módulos del aplicativo que no lo requieren.
  • No definir cuándo será exitoso el MA. Cuando se construye un programa de aseguramiento de software que integra la práctica de modelado, es relevante definir cuándo será considerada como exitosa, por ejemplo:
    • Identificar fallas importantes de seguridad que no podrían haber sido identificadas por medio de pruebas de seguridad o revisiones de código fuente.
    • Identificar fallas que solo podrían ocurrir bajo un conjunto de condiciones muy particular.
    • Cuando se obtienen los controles de seguridad que permitirán un diseño e implementación seguros.

El MA es una práctica de seguridad “humana” que se enriquece si es realizada por un equipo que cuenta con variedad de conocimientos en el área de seguridad, sin embargo, esta no es una limitante para desarrollarla. El MA se realiza cuando existe un entendimiento sólido de la estructura básica del aplicativo para que este pueda modelarse; con esto será posible descubrir amenazas en esa estructura y definir los controles de seguridad a nivel de diseño requeridos, es decir, la primera línea de defensa.

[email protected]