domingo, 23 de septiembre de 2012

Revelando la inseguridad de las aplicaciones: casos de mal uso y patrones de ataque


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. 
http://komputasi.files.wordpress.com/2008/12/misuse031.jpg
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

No hay comentarios:

Publicar un comentario