Introducción
En la actualidad muchas son
las voces que comentan sobre la calidad de las aplicaciones, del pobre
ejercicio de validación y aseguramiento que tiene el software y cómo los
atacantes son capaces de revelar estas situaciones comprometiendo la seguridad
de las operaciones en las empresas. Si bien cada organización adelanta un
proceso de desarrollo de software siguiendo metodologías probadas y
procedimientos estandarizados, la seguridad de sus productos, cada vez más se
ve comprometida y probada, frente a eventos deliberados como a efectos de
borde.
Así las cosas, comprender
como hacer evidente la inseguridad de las aplicaciones, exige un ejercicio de
humildad y prueba permanente por parte de los desarrolladores, para
interiorizar que, como dice Gary Mcgraw, “la seguridad (en las aplicaciones) no
es una característica que se incorpora, sino una propiedad emergente que se
diseña y valida”. En este sentido, se plantea un cambio de paradigma en el
desarrollo de aplicaciones, toda vez que las características funcionales son la
norma que los programadores utilizan para construirlas y la seguridad no es parte
natural de este concepto.
Entendiendo que los atacantes
no son clientes o usuarios normales, que son creativos y prueban las
condiciones de interacción de la aplicación como son entre otras condiciones de
borde, desbordamiento de pila, intercomunicación entre procesos y supuestos de
funcionamiento del sistema, se hace necesario establecer una estrategia que
permita, desde el proceso de desarrollo de las aplicaciones, anticiparse a
comportamientos anormales o no estándares de los usuarios que adviertan
condiciones de inestabilidad del software que lleven al compromiso, de su
ejecución o de los datos, que transitan a través de éste.
Casos de mal uso - CMA
En este sentido, la
literatura ha acuñado el concepto de casos de mal uso - CMA (abuse case o misuse case) los cuales buscan, siguiendo a Mcgraw en su libro “Software
Security”, empezar a pensar como el atacante, estableciendo eventos y condiciones inesperadas que reten el modelo
actual de funcionalidad para el cual la aplicación fue creada. Por tanto, se
espera que dichos casos intencionalmente generen problemas y hagan evidente los
riesgos del software para proponer acciones de remediación y aseguramiento que
hagan el producto más resistente a los ataques. (Nótese que no se dice “más
seguro”).
Uno de los objetivos de los CMA
es documentar y decidir a priori como el software debe reaccionar frente a un
uso ilegítimo. Algo que podríamos llamar postura de falla segura. Es decir,
poder establecer un comportamiento previsible frente a los abusos que se puedan
cometer contra las aplicaciones. Esto exige del analista de seguridad de
aplicaciones (nótese que no se habla del desarrollador) hacer las preguntas
correctas, pensar por el complemento y exigir al modelo de desarrollo enfrentar
la realidad de la inevitabilidad de la falla.
Ejemplo CMA para sistemas de comercio electrónico
Siguiendo las reflexiones de
Mcgraw, plantear un conjunto de CMA, exige entender el entorno de operación de
la organización, aquellos grupos de interés o agentes que estarían interesados
en generar un ataque en su contra. En este sentido, en el ejercicio normal de
validación del ambiente y sus amenazas podemos advertir elementos y escenarios
que pueden determinar un ataque para comprometer la reputación, buen nombre,
ventaja competitiva o peor aún, impactar o destruir el valor de la empresa,
bien en sus clientes o en su flujo financiero.
Así las cosas, el académico
propone el diseño de “anti-requerimientos”, para pensar “en aquellas cosas que usted
no quiere que su aplicación haga”, los cuales son generados, no por los
constructores del software, sino por los analistas de seguridad en conjunto con
los analistas de requerimientos (tanto técnicos como los de negocio). Los “anti-requerimientos”
proveen ideas de cómo usuarios maliciosos, atacantes, competidores, terceros no
autorizados pueden abusar o comprometer el sistema.
Mientras los requerimientos
hablan y materializan la funcionalidad del sistema que se quiere diseñar, así
como los comportamientos aceptables asociados con sus usuarios, los “anti-requerimientos”
son definidos para determinar que ocurre cuando esta funcionalidad no se
cumple. Generalmente los “anti-requerimientos” están atados a la falta o falla
de las funciones de seguridad definidas en las aplicaciones, pero igualmente a
comportamientos no estándar que puede recibir el software.
Los CMA, materializados vía
la idea de “anti-requerimientos”, establece un discurso metodológico que permite
ver tanto al desarrollador como a los analistas de negocio, como revelar
situaciones límite o de borde, que las aplicaciones pueden recibir para comprometer
su adecuada ejecución o vulnerar las condiciones de seguridad previamente
establecidas.
Cuando pensamos en el modelo
de “anti-requerimientos” estamos implícitamente diseñando un modelo de ataque
que busca considerar patrones de agresión contra la aplicación para probar su
resistencia a comportamientos no estándar o condiciones de presión o exigencia
límite en su ejecución. En consecuencia, plantear este tipo de ejercicios,
busca descubrir cómo reacciona el sistema frente a un embate y qué tipo ataques
tienen mayor probabilidad de ocurrir.
Patrones de ataque
Como quiera que el desarrollo
de aplicaciones demanda formalidades que se deben cumplir frente a la exigencia
de los requerimientos y la disciplina para materializar los mismos, se hace
necesario articular los casos de mal uso dentro de éstas, como práctica que
custodia los intereses de los usuarios e incrementa la confiabilidad del
producto. En consecuencia, se debe contar con un conjunto de patrones de
ataques conocidos que deben ser revisados para materializar de manera práctica
CMAs y establecer una línea base de control y validación que nos indique que
tan seguros podemos llegar a ser.
El profesor Mcgraw lista al
menos 48 patrones de ataques, que denomina un catálogo naciente, los cuales ya
cuentan con historias prácticas que han logrado, cambiar el paradigma del aseguramiento
de las aplicaciones, superando el entendimiento de la seguridad “más allá de un
requerimiento funcional”, por una propiedad emergente que se debe diseñar y
validar.
A manera de ilustración
detallamos a continuación los elementos que constituyen un patrón de ataque: (BARNUM,
S. y SETHI, A. 2006)
- Patrón Nombre y clasificación: Un identificador único y descriptivo para el patrón.
- Requisitos Ataque: ¿Qué condiciones deben existir o qué funcionalidad y qué características debe tener el software objetivo, o qué comportamiento debe exhibir, para este ataque tenga éxito?
- Descripción: Una descripción del ataque que incluye la cadena de las medidas adoptadas.
- Las vulnerabilidades relacionadas o Debilidades: ¿Qué vulnerabilidades específicas o debilidades apalancan el ataque?
- Método de Ataque: ¿Cuál(es) es(son) el(los) vector(es) de ataque utilizado(s) (por ejemplo, entrada, datos maliciosos, el archivo creado de manera malintencionada, la falla en el protocolo)?
- Ataque Motivación-Consecuencias: ¿Qué es lo que el atacante quiere lograr mediante el uso de este ataque? Esta información es útil para la alineación de patrones de ataque a los modelos de amenaza y para determinar qué patrones de ataque son relevantes para un contexto dado.
- Habilidad o conocimiento que se requiere Atacante: ¿Qué nivel de habilidad o conocimiento específico tiene el atacante para ejecutar este tipo de ataque? Esto debe ser comunicado en una escala aproximada (por ejemplo, bajo, medio, alto), así como en detalle contextual de qué tipo de habilidades o conocimientos son necesarios.
- Recursos necesarios: ¿Qué recursos (por ejemplo, ciclos de CPU, direcciones IP, herramientas, tiempo) son necesarios para ejecutar el ataque?
- Soluciones y mitigaciones: ¿Qué acciones o enfoques se recomiendan para mitigar este ataque, ya sea a través de la resistencia o capacidad de recuperación?
- Descripción del contexto: ¿En qué contextos técnicos (por ejemplo, plataforma, sistema operativo, lenguaje, diseño arquitectónico) es el patrón relevante? Esta información es útil para la selección de un conjunto de patrones de ataque que son apropiados para un contexto dado.
- Referencias: ¿Qué otras fuentes de información están disponibles para describir este ataque?
Reflexiones finales
Si podemos aplicar ejercicios
metodológicos como los comentados previamente, estamos avanzando en los caminos
de la inseguridad de la información, recorriendo algunos de los comportamientos
asimétricos que se presentan, buscando comprender tanto la dinámica de la
organización como la de su flujo de información materializado a través de las
aplicaciones.
Sin perjuicio de las bondades de las
prácticas formales establecidas para el desarrollo de software, las cuales
cuentan con incontables historias de éxito y grandes logros en múltiples
proyectos de grande y mediano alcance, los casos de mal uso y los patrones de
ataque, nos pueden ayudar a reinventar dichas prácticas, para encontrar “espacios
en blanco” en la construcción de software de mayor confiabilidad (que
necesariamente es de mejor calidad), para que ante la eventualidad de un “cisne
negro”, podamos poner a prueba la resistencia de las aplicaciones y sumar
nuevas lecciones aprendidas frente a la inevitabilidad de la falla.
Referencias
MCGRAW, G. (2006) Software security. Building security in. Addison
Wesley.
BARNUM,
S. y SETHI, A. (2006) Introduction to attack
patterns. CIGITAL Inc. Disponible en: https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/attack/585-BSI.html
