¿Es posible modelar amenazas desde la arquitectura?
Generalmente al comenzar un desarrollo tenemos una incertidumbre generalizada sobre como vamos a formar la arquitectura de la aplicación y claro si existe una gran cantidad de requerimientos no funcionales que atacan conceptualmente la plataforma crece esta sensación de inseguridad.
La razón para desarrollar un modelo de amenaza es simple: identificar las amenazas potenciales con el propósito de desarrollar una estrategia de seguridad sólida para protegerse de ellos.
Es racional pensar que no se puede diseñar un sistema seguro hasta que no se comprenden las amenazas.
Si comprendemos el contexto gran parte del trabajo está solucionado
La idea siempre hablando del entorno arquitectónico, es facilitar esta tarea de la mejor manera posible, en este caso haciendo uso de los recursos de patterns an practices de la empresa Microsoft.
Voy a analizar un entorno ficticio para que podamos visualizar las bondades de la herramienta “Microsoft Threat Analysis and Modeling Tool”.
En primero lugar voy a utilizar la opción de generar un modelo utilizando un asistente.
El asistente nos muestra un esqueleto de 8 pasos para completar un esquema general de análisis de amenazas.
En primer lugar lo que nos propone la herramienta es la definición de roles que tentativamente van a utilizar la plataforma.
En el escenario propuesto existen 4 roles
El cliente
El vendedor
El gerente
El administrador
Para nuestro supuesto escenario el cliente utilizará accesos Web, el vendedor usará un smart client, el gerente un acceso Web de gestión general y al administrador la administración completa Web
El punto que llega en este segundo paso es definir la data en el banco de datos o en transito dentro de mi circuito arquitectónico.
Para el escenario solo he definido data de compras.
En este paso una vez definida la información definida en el banco de datos o en transito del circuito resta establecer la matriz de acceso.
Este punto es muy importante ya que me permite mapear a cada usuario con la data establecida y a cada una de estas relaciones le puedo definir los permisos pertinentes.
En este paso la herramienta de forma automatizada muestra casos de uso que llegan desde las operaciones definidas en la matriz de control de acceso y nos muestra los casos tentativos.
Desde mi punto de vista esto es un dato extra y solo lo tomo como una definición de magnitud ya que la gestión de estos artefactos lo manejo con otros modelos.
Actualmente una decisión interesante es la definición de componentes, para nuestro escenario existen:
Cliente Web
Capa de Servicios (orientado a Web Services)
Capa de Negocios
Capa de Datos
En este segmento del asistente debemos colocar las relevancias de los componentes especificados, para que la herramienta pueda cotejar las buenas prácticas sobre las tecnologías implantadas.
Esto es muy interesante que lo hagamos de la mejor manera posible porque influye de forma directa sobre el report final y claro sobre el análisis propiamente dicho.
Como podemos apreciar en la figura anterior, queda especificado para el cliente web el detalle de la relevancia
En uno de los últimos pasos podemos definir para cada caso de uso definido de forma automática los flujos de información en las llamadas.
Esto implica seleccionar como muestra la siguiente figura el llamador, el componente en cuestión y los datos enviados y recibidos.
Una vez definido es su completitud estamos en condiciones de pasar al último paso del asistente que nos va a permitir un análisis preliminar básico de las amenazas y una noción de modelado teniendo en cuenta las normas de seguridad estándares.
Como vemos en la figura anterior, la herramienta nos muestra las amenazas detectadas según criterios por ejemplo de confidencialidad, integridad y disponibilidad.
De esta manera termina el asistente pero, solo comienza lo rico que nos ofrece la plataforma.
Veamos un reporte antes de operar con las funcionalidades de configuración de amenazas.
Por ejemplo el sistema coteja toda la información y genera gráficos de vinculación delineando la arquitectura contra los componentes.
Además como vemos en la figura anterior nos muestra de las amenazas de confidencialidad el detalle de cada una de las detectadas, y claro está nosotros desde la plataforma podemos mitigar y reconfigurar las medidas que llevaremos adelante.
Todo lo realizado con el asistente de forma predeterminada se puede extender para profundizar más en la arquitectura, por ejemplo les voy a mostrar una personalización de uno de los componentes.
En este caso al cliente Web le apliqué el tipo, que es en este caso un Website, además le incorporé la tecnología sobre la cual estará desarrollado “.Net Framework 2.0” lo roles que lo operarán y la data que manipulará.
Todo esto enriquece el detalle de mi entorno permitiéndome modelar una arquitectura con prácticas de seguridad gestionadas y disminuir notoriamente la incertidumbre en la definición de escenarios.
Para finalizar, una funcionalidad que está buena nombrar es que permite importar un VS deployment Report desde VSTS y exportar a Team Foundation como work item el desarrollo que se ejemplificó.
Comentarios
Publicar un comentario