Metodologías para desarrollar software seguro

Metodologías de desarrollo tradicionales

 La clave de un software seguro, es el proceso de desarrollo utilizado. En el proceso, es donde se produce el producto que pueda resistir o sostenerse ataques ya anticipados, y recuperarse rápidamente y mitigar el daño causado por los ataques que no pueden ser eliminados o resistidos. Muchos de los defectos relacionados con la seguridad en software se pueden evitar si los desarrolladores estuvieran mejor equipados para reconocer las implicaciones de su diseño y de las posibilidades de implementación.

Las metodologías mencionadas, tienden enfocarse en mejorar la calidad en el software, reducir el número de defectos y cumplir con la funcionalidad especificada (Davis, 2005); pero en la actualidad, también es necesario entregar un producto que garantice tener cierto nivel de seguridad. Hay metodologías que contemplan durante su proceso, un conjunto de actividades específicas para remover vulnerabilidades detectadas en el diseño o en el código, la aplicación de pruebas que aportan datos para la evaluación del estado de seguridad, entre otras actividades relacionadas para mejorar la seguridad del software.

Metodologías enfocadas al desarrollo de software seguro

 Existen varias metodologías que establecen una serie de pasos en búsqueda de un software más seguro y capaz de resistir ataques. Entre ellas se encuentran Correctness by Construction (CbyC), Security Development Lifecycle (SDL), Cigital Touchpoints, Common Criteria, Comprehensive, Lightweight Application Security Process (CLASP), TSP-Secure. 

 Correctness by Construction (CbyC) 

Es un método efectivo para desarrollar software que demanda un nivel de seguridad crítico y que además sea demostrable. La empresa Praxis ha utilizado CbyC desde el año 2001 y ha producido software industrial con taza de defectos por debajo de los 0.05 defectos por cada 1000 líneas de código, y con una productividad de 30 líneas de código por persona al día.

Las metas principales de ésta metodología son obtener una taza de defectos al mínimo y un alta resilencia al cambio; los cuales se logran debido a dos principios fundamentales: que sea muy difícil introducir errores y asegurarse que los errores sean removidos tan pronto hayan sido inyectados. CbyC busca producir un producto que desde el inicio sea correcto, con requerimientos rigurosos de seguridad, con definición muy detallada del comportamiento del sistema y un diseño sólido y verificable (Croxford & Chapman, 2005).

1 Fase de Requerimientos 

En la fase de requerimientos se especifica el propósito, las funciones y los requerimientos no funcionales. Se escriben los requerimientos de usuario con sus respectivos diagramas contextuales, diagramas de clase y definiciones operativas. 

2 Fase de Diseño de Alto Nivel

 Se describe la estructura interna del sistema, (distribución de la funcionalidad, estructura de las bases de datos, mecanismos para las transacciones y comunicaciones) la manera en que los componentes colaboran y especifican con mayor énfasis los requerimientos no funcionales de protección y seguridad. 

3 Fase de Especificación del Software

 En ésta fase se documentan las especificaciones de la interfaz de usuario (se define el “look and feel” del sistema), las especificaciones formales de los niveles superiores y se desarrolla un prototipo para su validación.

4 Fase de Diseño Detallado 

Define el conjunto de módulos y procesos y la funcionalidad respectiva. Se utiliza notación formal para eliminar ambigüedad en la interpretación del diseño. 

5 Fase de Especificación de los Módulos

 Se define el estado y el comportamiento encapsulado en cada módulo del software tomando en cuenta el flujo de información. Los módulos deberán de tener el enfoque de bajo acoplamiento y alta cohesión.

6 Fase Codificación 

El concepto de evitar cualquier ambigüedad posible, también se aplica en el código; por ello se sugiere la utilización de SPARK (lenguaje formalmente definido y matemáticamente comprobable, basado en el lenguaje de programación Ada, utilizado en sistema de aeronáutica, sistemas médicos y control de procesos en plantas nucleares) en las partes críticas del sistema por estar diseñado para tener una semántica libre de ambigüedades, permitir realizar análisis estático y ser sujeto de una verificación formal (Brito, 2010).

7 Fase de las Especificaciones de las Pruebas

 Para obtener las especificaciones de las pruebas, se toman en cuenta las especificaciones del software, los requerimientos y el diseño de alto nivel.

8 Fase de Construcción del Software CbyC

 utiliza el desarrollo de tipo ágil; en la primera entrega, se tiene el esqueleto completo del sistema con todas las interfaces y mecanismos de comunicación; con una funcionalidad muy limitada que se irá incrementado en cada iteración del ciclo. CbyC es compatible con los principios de los procesos de Personal Software Process/Team Software Process (PSP/TSP) y al combinar resulta en una taza reducción en la taza de defectos.

Security Development Lifecycle (SDL) 

Es un proceso para mejorar la seguridad de software propuesto por la compañía de Microsoft en el año 2004; con dieciséis actividades enfocadas a mejorar la seguridad del desarrollo de un producto de software (Peterson, 2011). Las prácticas que propone SDL van desde una etapa de entrenamiento sobre temas de seguridad, pasando por análisis estático, análisis dinámico, fuzz testing del código hasta tener plan de respuesta a incidentes.

 Fases de la Metodología SDL 

Existen dos versiones del SDL, la versión rígida y la orientada al desarrollo ágil. Las diferencias versan en que la segunda desarrolla el producto de manera incremental y en la frecuencia de la ejecución de las actividades para el aseguramiento de la seguridad. 

1 Fase de Entrenamiento 

Todos los miembros de un equipo de desarrollo de software deben recibir una formación apropiada con el fin de mantenerse al corriente de los conceptos básicos y últimas tendencias en el ámbito de la seguridad y privacidad. 

2 Fase de Requerimientos

 En la fase de requerimientos, el equipo de producción es asistido por un consultor de seguridad para revisar los planes, hacer recomendaciones para cumplir con las metas de seguridad de acuerdo al tamaño del proyecto, complejidad y riesgo.

3 Fase de Diseño 

Se identifican los requerimientos y la estructura del software. Se define una arquitectura segura y guías de diseño que identifiquen los componentes críticos para la seguridad aplicando el enfoque de privilegios mínimos y la reducción del área de ataques. 

4 Fase de Implementación 

Durante la fase de implementación, se codifica, prueba e integra el software. Los resultados del modelado de amenazas sirven de guía a los desarrolladores para generar el código que mitigue las amenazas de alta prioridad.

4 Fase Verificación

 En ésta parte el software, ya es funcional en su totalidad y se encuentra en fase beta de prueba.

5 Fase de Lanzamiento

 En el lanzamiento, el software es sujeto a una revisión de seguridad final, durante un periodo de dos a seis meses previos a la entrega con el objetivo de conocer el nivel de seguridad del producto y la probabilidad de soportar ataques, ya estando liberado al cliente.  

6 Fase de Respuesta

 Sin importar la cantidad de revisiones que se haga al código o las pruebas en búsqueda de vulnerabilidades, no es posible entregar un software cien por ciento seguro; así que, se debe de estar preparado para responder a incidentes de seguridad y a aprender de los errores cometidos para evitarlos en proyectos futuros (Lipner, 2004).