Metodologías de Desarrollo de Aplicaciones Web Seguras

Por: Héctor Garduño Real Máster en Dirección e Ingeniería de Sitios Web

Seguridad en la Web

03 de mayo de 2015 Página 1 de 4

Metodologías de Desarrollo de Aplicaciones Web Seguras

Introducción

Bien es sabido que ningún sistema del tipo que sea, basado en hardware o software, es totalmente seguro, ya sea en mayor o menor medida pero todos resultan inseguros. Por ello se la famosa frase del prestigioso profesor de ciencias computacionales Gene Spafford quién dice que “El único sistema seguro es aquel que está apagado y desconectado, ente-rrado en un refugio de cemento, rodeado por gas venenoso y custodiado por guardianes bien pagados y muy bien armados. Aun así, yo no apostaría mi vida por él”.

Es por ello que desde hace ya varios años los desarrolladores han comenzado a prestar atención en este aspecto y tratar de revisar aspectos de seguridad en sus aplicaciones, sin embargo la técnica tradicional que comúnmente se ocupa es la de desarrollar y una vez concluida la aplicación realizar pruebas de seguridad, sin embargo han comenzado a darse cuenta que esto resulta problemático, difícil de llevar a cabo y sobre todo más caro, pues las correcciones implican la reingeniería de la aplicación, y ello sin considerar que estos pro-blemas son exponenciales al tamaño y robustez de la aplicación.

Con el paso del tiempo los desarrolladores han ido percibiendo estos problemas y han intentado nuevas formas, al grado de establecer muy completas propuestas de procesos a llevar a cabo para construir aplicaciones seguras, incluso al punto de crear metodologías que han sido ampliamente usadas. Las metodologías de desarrollo para software seguro suelen ser un complemento de las metodologías de desarrollo tradicionales, ya que se en-focan estrictamente en la seguridad, y aunque la mayoría de estás metodologías son de propósito general para cualquier tipo de sistema, lenguaje, plataforma o tecnología; tam-bién se han llegado a crear metodologías para usos específicos, como el caso de OWASP que se enfoca al entorno web. Así pues, por esta creciente preocupación por desarrollar aplicaciones web más seguras es que en este documento se recopilan y describe de forma breve las que se podrían considerar como las dos metodologías más influyentes.

1. Security Quality Requirements Engineering (SQUARE)

SQUARE es una metodología creada en 2005 por el equipo CERT del Software Engineering Institute (SEI) que se centra en la obtención y análisis de requerimientos, por lo que es per-fectamente aplicable a la fase inicial del proceso de desarrollo de un software bajo meto-dología tradicional, o a lo largo de todo el desarrollo en el caso de metodologías ágiles. Así que SQUARE resulta ideal pues la mayor parte de problemas de un software se encuentran en la fase de requisitos por lo que en aspectos de seguridad, resultará bastante apropiada su implementación.


Seguridad en la Web


La razón por la que muchos proyectos de software fracasan o no alcanzan sus objetivos iniciales es porque la fase de desarrollo que involucra la determinación, análisis y especifi-cación fue llevada a cabo de forma escaza debido a su dificultad. Si a estos requisitos se le suman los requisitos de seguridad, entonces el proceso se vuelve en una tarea aún más difícil pero que bien vale la pena para lograr un software correcto, y en este caso, seguro, pues precisamente SQUARE lo que plantea es establecer la seguridad desde las etapas tem-pranas del ciclo de vida del desarrollo.

La metodología está basada en nueve pasos, los cuales se describen e el informe, se indica su finalidad, las responsabilidades de los participantes, las técnicas que se pueden emplear y resultados a obtener (Software Engineering Institute, 2005).

1. Establecer un vocabulario común. 2. Identificación de objetivos de seguridad. 3. Desarrollo de artefactos (escenarios, diseños, casos de mal uso, etc.) 4. Evaluación de riesgos 5. Elección de técnicas para obtener requisitos 6. Obtención de requisitos de seguridad 7. Clasificación de requisitos 8. Priorización de requisitos 9. Revisión de los requisitos

Se han creado diferentes informes sobre SQUARE, el primero describe la metodología, el segundo muestra un ejemplo de la aplicación de la metodología a un sistema administra-tivo y el cual puede servir de referencia para su implementación, y finalmente un tercer informe presenta un caso de estudio donde se presentan los resultados después de haber llevado a cabo la metodología con 3 clientes a lo largo de seis meses. SQUARE ha sido exi-tosamente extendido que de hecho se ha incorporado en modelos del Ciclo de vida tradi-cional, se le han creado métricas, evaluaciones de costos de adquisición, e incluso hecho comparaciones con otras metodologías1.

2. Correctness by Construction (CbyC)

Por su parte CbyC es una metodología que desarrolló Praxis High Integrity Systems en 2001, pero que está más orientada a la industria aeroespacial y sistemas críticos de seguridad, por lo que bien puede ser implementada en cualquier otro contexto ya que combina los méto-dos formales con el desarrollo ágil muy usado hoy en día. Con CbyC se busca desarrollar desde un inicio sistemas de calidad y con requerimientos muy estrictos en seguridad lle-gando a niveles extremadamente bajos de errores, ello gracias a que se basa en tres princi-pios básicos (Build Security In, 2006):

1 Se puede consultar una amplia lista de informes con solo buscar “Security Quality Requirements Engineering“ en el sitio http://sei.cmu.edu/

http://sei.cmu.edu/


Seguridad en la Web


1. Hacer que sea muy difícil introducir errores 2. Asegúrese de que los errores se eliminan lo más cerca posible del punto de intro-

ducción, ya que se harán a pesar principio 1 3. Generar pruebas de aptitud para el uso en todo el desarrollo como un subproducto

natural del proceso (debido a que muestra que el sistema desarrollado es seguro o seguro es a menudo más difícil de lo que es así).

En CbyC se logra la detección temprana de errores y alta seguridad gracias a las técni-cas que plantea y que a su vez también son los componentes básicos del proceso, estos procesos o actividades de la metodología son:

1. Planificación de procesos 2. Capacitación del personal y de competencias 3. Trazabilidad de requisitos desde la especificación de casos de código y prueba 4. Gestión de fallos 5. Gestión del cambio 6. Gestión de la configuración 7. Recolección de métricas

Por otro lado las técnicas empleadas durante los procesos son:

Hacer anotaciones de sonido para disminuir ambigüedades en la especificación de requisitos.

Estricta validación de entregables en cada etapa de desarrollo.

Desarrollo incremental, de forma que se escriba algo de código y se verifique.

Evitar la repetición, pues si un requisito fue ambiguo entonces se repetirá el error.

Hacerlo simple, pues de ello dependerá que las revisiones y desarrollo sean fáciles.

Gestionar los riesgos para responder mejor ante incidencias.

Pensar fuerte, para lograr los objetivos.

Así pues, CbyC es una excelente metodología pero no recomendada para todos los ca-sos, sino para entornos que requieran demasiada seguridad, pues resulta demasiado es-tricta y es necesario ceñirse específicamente a los procesos establecidos tanto en CbyC como en la metodología de ingeniería de software usada, por lo que si el proceso de inge-niería no se lleva a cabo correctamente, entonces no resulta viable usar CbyC.

3. Otras metodologías existentes

El análisis de resultados de Vega Zepeda (2011) recoge una lista de un par de metodologías y varios procesos y mejoras de metodologías empleados para construir software seguro. Entre ellos se pueden destacar el proceso de desarrollo propuesto por Apvrille y Pourzandi que emplea el proceso de desarrollo iterativo adaptado con seguridad; el método Clean-room que pretende lograr cero errores, es decir, más estricto que CbyC; también esta RUPsec que es una extensión del Proceso de Desarrollo Unificado (RUP); CLASP es un mé-todo que indica y documenta las actividades para hacer un software seguro.


Seguridad en la Web


Referencias Bibliográficas

Build Security In. (05 de Mayo de 2006). Build Security In. Recuperado el 02 de Mayo de 2015, de Correctness by Construction: https://buildsecurityin.us-cert.gov/articles/knowledge/sdlc-process/correctness-by-construction

navegapolis.net. (17 de Enero de 2006). Recuperado el 02 de Mayo de 2015, de SQUARE: metodología para requisitos de seguridad: http://www.navegapolis.net/content/view/238/52/

Software Engineering Institute. (Noviembre de 2005). Software Engineering Institute. Recuperado el 02 de Mayo de 2015, de Security Quality Requirements Engineering: http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=7657

Vega Zepeda, V. (Noviembre de 2011). Academia.edu. Obtenido de Ingeniería de Requerimientos para Productos Seguros. Resultados de un Análisis Bibliográfico: https://www.academia.edu/6997116/Ingenier%C3%ADa_de_Requerimientos_para_Productos_Seguros._Resultados_de_un_An%C3%A1lisis_Bibliogr%C3%A1fico