Diseñando Arquitecturas Seguras (preludio)

 En  estos días presentamos, en conjunto con Ale, una sesión sobre Diseño de Arquitecturas Seguras en el marco del Foro Regional de Arquitectura de Software que estamos haciendo en Punta del Este, y que nuclea a los arquitectos de software de todos los países sudamericanos de habla hispana

Hace un tiempo atrás, dialogando con Luis, un jefe de arquitectura de una entidad financiera multinacional, me dio su punto de vista: "la seguridad es un aspecto demasiado complejo de la aplicación como para que los desarrolladores deban perder tiempo estudiándolo o tomando medidas de defensa al desarrollar. La seguridad debería ser algo que desde la misma infraestructura quede resuelto, de manera que los desarrolladores dediquen sus horas/hombre a desarrollar lógica para el negocio"

Si bien lo que Luis sostiene suena a "politicamente correcto" y es lo que todos desearíamos que pase, alcanzar un estadío tal que los desarrolladores se despreocupen de la seguridad es la escala final de un proceso de maduración de todo el equipo de proyecto, que no puede alcanzarse con atajos sino que es el resultado de la aplicación de prácticas intensivas conocidas como "Ingeniería de Seguridad"

El desarrollo debe preocuparse por cosas básicas como enmascarar los mensajes de excepción, para evitar que detalles íntimos sean revelados a usuarios desconocidos (ver fig. 1)


Fig. 1 – Consecuencia de no enmascarar los mensajes de error a presentar al usuario final

Obviamente, descuidos como ése van liberando de a poco información íntima, que combinada con otros deslices a la hora de desarrollar, pueden ser fatales. Sólo por seguir el ejemplo, un mal tratamiento de los datos de entrada nos puede exponer a la inyección de SQL (SQL injection) en los formularios de carga de datos de nuestra aplicación, que luego sean usados para, por ejemplo, elevarse los privilegios en forma indebida (ver fig. 2)

 

Fig. 2 – Elevación de privilegios al nivel de administrador mediante inyección de SQL (SQL injection)

Con estos privilegios de administrador, nos pueden hacer lo que se les venga en gana. Por ejemplo, destruirnos la tabla de Órdenes de Servicio (ver fig. 3)


Fig. 3 – Alteración/destrucción de información, nuevamente por inyección de SQL

Si no terminamos en cana procesados por fraude, nos salió barata: sólo habremos perdido varios millones de las arcas de la compañía

Como se pudo apreciar, para contradecir a Luis, las vulnerabilidades por donde hemos sido atacados están todas relacionadas con malas prácticas de desarrollo. De nada me sirve el mejor firewall si no tengo bien educada a "la tropa". Aunque esto parezca una obviedad, educar a la tropa no es imposible aunque sí complicado. Como decía al principio, es un eslabón más de una cadena llamada "Ingeniería de Seguridad", que añade actividades relacionadas con la seguridad en cada una de las fases del proyecto de desarrollo

Ni la Arquitectura de la Aplicación ni el Arquitecto son ajenos a la Ingeniería de Seguridad sino que juegan un rol preponderante, porque si bien lo que Luis sostiene es más una expresión de deseo que una realidad actual, lo cierto es que mediante una buena arquitectura deberíamos "tender a" (y tratar de aproximarnos al estadío ideal amén de que no lleguemos nunca)

Por qué esto es así? Porque a grandes rasgos la arquitectura componentiza piezas pensadas para satisfacer requerimientos no funcionales de la aplicación (rendimiento, integridad transaccional, etc, entre otros). La seguridad no es ajena a los mismos. De esta manera, los requerimientos funcionales (léase, la lógica de negocio) pasan a ser responsabilidad directa de los desarrolladores y el mundo ideal de Luis estaría más cerca que nunca

En esta presentación que vamos a hacer con Ale vamos a hablar de las actividades para asegurar la aplicación que se desarrollan durante la creación y maduración de la arquitectura. Vamos a contar qué es el Modelado de Amenazas (Threat Modeling). También mencionaremos formas de segmentar los diversos tipos de ataques, y una manera eficaz de priorizar la aplicación de contramedidas

De momento nada más, estimados. Por favor vayan al evento o esperen que se lo cuente el hacker en una nota de despedida

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

3 respuestas a Diseñando Arquitecturas Seguras (preludio)

  1. paulo dijo:

    Primero que nada, muy bueno tu blog Diego, tienes muy buenos articulos, y lo segundo que tenia para decirte es que Microsoft tiene una herramienta bastante interesante para el Modelado de Amenzas la Microsoft Threat Analysis & Modeling v2.0, es bastante completa y personalizable.
     
    Por si alguien esta interesado la pueden bajar de aqui.
    http://www.microsoft.com/downloads/details.aspx?FamilyID=AA5589BD-FB2C-40CF-AEC5-DC4319B491DD&displaylang=en
     
    Nos vemos.
     

  2. Diego dijo:

    Gracias Paulo!!! La verdad? Me anticipaste la sorpresa, porque en la presentación que hice en el Regional Architect Forum le conté a los asistentes de la tool del equipo ACE (Application Consulting Engineering) de MicrosoftTe agradezco tu comentario y te FE-LI-CI-TO por tu blog (todo un descubrimiento para mí) y por la actividad que veo que estás desarrollando. A no parar!!!

  3. Diego dijo:

    Invito a todos los interesados a descargar la presentación de aquíhttp://escribacorporativo.com.ar/raf/Arquitecturas_Seguras_Final.ppt

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s