Seguridad desde la
perspectiva del arquitecto
Para el arquitecto de software, la seguridad representa uno de los atributos
de calidad más importantes de un sistema. Se trata de un atributo
naturalmente multidimensional que abarca varios temas extremadamente
relevantes. Según Michael Howard y Steve Lipner, autores del libro “The Security Development Lifecycle”, la seguridad debería ser
abordada a partir de una metodología probada y rigurosa que
cuantitativamente tienda a disminuir las vulnerabilidades en la arquitectura
de una aplicación.
¿Cómo abordar este tema?
Para crear aplicaciones seguras debemos
necesariamente incorporar prácticas de seguridad durante todo el ciclo de
vida de desarrollo. La siguiente tabla intenta resumir que prácticas de
seguridad deberíamos incorporar dependiendo de la fase y del tipo de tarea
que estemos realizando:
|
Fase o Iteración
|
Tarea típica
|
Práctica de Seguridad
|
|
Requerimientos
y Análisis
|
Análisis
de Requerimientos Funcionales, Requerimientos No Funcionales y
Requerimientos Tecnológicos
|
Determinar
objetivos de seguridad
|
|
Arquitectura
y Diseño
|
Definir
y documentar Arquitectura, Construir Guías de Diseño
|
Revisar
vulnerabilidades de la Arquitectura
Modelar
amenazas
Construir
guías de diseño de seguridad
|
|
Desarrollo
|
Testing
unitario
Revisión
de código
Building
automatizado
|
Definir
guías para crear código seguro
Revisar
vulnerabilidades en el código
|
|
Testing
|
Pruebas
de Integración
Pruebas
Funcionales
|
Definir
y ejecutar pruebas de seguridad
|
|
Distribución
|
Generar
deployment automatizado
|
Identificar
vulnerabilidades de seguridad a nivel del deployment
|
Modelado de amenazas (Threat
Modeling)
Una de las prácticas de seguridad que
consideramos más relevantes es el “Modelado de amenazas”. Dicha práctica se
basa en un concepto muy simple, para crear aplicaciones seguras debemos
identificar y comprender las distintas amenazas a las cuales se expone
nuestra aplicación. Por lo general, esta actividad consiste en lo
siguiente:
-
Identificar activos (assets) de
la aplicación.
Un activo representa algo valioso a proteger (ej. la base de datos).
-
Detectar amenazas (threats). Una amenaza es un potencial
evento indeseado que podría ocurrirle a un activo (ej. eliminación o
alteración no autorizada de datos).
-
Identificar vulnerabilidades por
donde se pueda atacar la aplicación. Un ataque es la acción de llevar a cabo
una amenaza (ej. hackear la base de datos utilizando SQL Injection).
-
Identificar contramedidas
(countermeasures).
Una contramedida combate una vulnerabilidad para eliminar o disminuir la
probabilidad de un ataque (ej. encapsular correctamente la lógica de acceso
a datos y utilizar sentencias SQL parametrizables)
Para conocer más sobre esta práctica, los invitamos
a revisar esta página del Microsoft Security Developer Center
dedicada exclusivamente a este tema. De hecho podrán encontrar una
herramienta muy interesante denominada “Microsoft Threat Analysis & Modeling Tool” que sirve para generar visualmente
modelos de análisis de amenazas.
Conclusión
Escribir sobre seguridad es y será siempre
muy desafiante, en esta nueva edición del Architect Newsletter hemos
seleccionado una serie de artículos y recursos vinculados con seguridad que
esperamos les aporte al día a día laboral de cada uno de ustedes.
Será hasta la próxima edición!
Martín Cabrera
Arquitecto de Software
Microsoft Cono Sur
Martin.Cabrera@microsoft.com
http://dmartincabrera.spaces.live.com
http://blogs.msdn.com/mcabrera
è Conoce
nuestra Comunidad de Arquitectura de Software en Español
|
