Introducción A Los S-SDLC

TÍTULO Introducción a los S-SDLC

Santiago Acosta M

Contenido Introducción a los S-SDLC. ................................................................................................ 2 SREP Security Requirements Engineering Process......................................................... 3 SQUARE Security Quality Requirements Engineering ...................................................... 4 CoSMo Conceptual Security Modeling .............................................................................. 4 UMLSec ............................................................................................................................. 5 Casos de Mal Uso ............................................................................................................. 6 Análisis de riesgo Threat Modeling .................................................................................... 6 Método STRIDE................................................................................................................. 6 Árboles de ataque.............................................................................................................. 7 Método DREAD ................................................................................................................. 8

Introducción a los S-SDLC. Ciclo de Vida de Desarrollo de Software SDLC(por sus siglas en inglés) puede decirse que es un proceso iterativo en el cual se identifican cuatro etapas principales: Requisitos, Diseño, Desarrollo y Pruebas. Existen otros modelos, como CMMI, que define buenas prácticas para el desarrollo de software y plantea básicamente que el SDLC es un micro proyecto, donde un cambio en alguna de las etapas afecta todo el proyecto, el cual, se debe ir refinando hasta lograr el objetivo deseado. Aunque la calidad y funcionalidad del software ha sido de gran interés para quienes lo desarrollan y adquieren, la seguridad solo se está considerando como factor o elemento crítico actualmente, debido a los informes sobre ataques a las organizaciones mediante la explotación de vulnerabilidades detectadas en el software. Si en cada una de las etapas del desarrollo se considera la seguridad como parte integral del software, se está hablando del S-SDLC o ciclo de vida del desarrollo de software seguro. Para implementar seguridad en las aplicaciones se deben analizar y gestionar los riesgos que afectan o afectarán los activos informáticos y dentro de estos el software para poder

garantizar el logro de los objetivos que se pretenden con estos activos en las organizaciones. Lo primero que se debe hacer para comenzar a implementar seguridad en las aplicaciones es identificar cuáles son los activos de información que se deben proteger, cómo protegerlos, cuáles son las vulnerabilidades de los elementos que interactúan con la información y como mitigarlas, al punto de reducirlas a un nivel de riesgo aceptable mediante un proceso iterativo que analice profundamente los riesgos durante todo el SDLC. También es muy importante identificar patrones de ataque en todas las fases y almacenarlos en una base de conocimiento que permita prevenir futuros ataques en otras aplicaciones

Los siguientes modelos hacen énfasis en las etapas de ingeniería de requisitos, modelado, y especificación teniendo en cuenta que los costos de corrección del software es mucho menor si se abordan en las etapas tempranas del ciclo de vida del desarrollo.

SREP Security Requirements Engineering Process Es un método basado en activos y orientado a riesgos, que permite el establecimiento de requisitos de seguridad durante el desarrollo de las aplicaciones. Básicamente lo que define este método es la implementación de Common Criteria durante todas las fases del desarrollo de software; CC es un estándar internacional ISO/IEC 15408 para seguridad informática, cuyo objetivo es definir requisitos seguros que les permitan a los desarrolladores especificar atributos de seguridad y evaluar que dichos productos si cumplan con su cometido. En este proceso también se apunta a integración con el Systems Security Engineering Capability Maturity Model (ISO/IEC 21827) Considera nueve actividades en cada iteración: 1. Acuerdo en las definiciones, 2. Identificación de activos críticos o vulnerables 3.

Identificar los objetivos y dependencias de seguridad

4. Identificar amenazas y desarrollar artefactos 5. Evaluación del riesgo 6. Elicitación de los requisitos de seguridad 7. Categorizar y priorizar los requisitos 8. Inspección de requisitos 9. Mejora el repositorio de documentación

SQUARE Security Quality Requirements Engineering Propone varios pasos para construir modelos de seguridad desde las etapas tempranas del ciclo de vida del software. En este modelo se hace un análisis enfocado a la seguridad, los patrones de ataque, las amenazas y las vulnerabilidades y se desarrollan malos casos de uso/abuso. Considera las siguientes actividades o pasos: 1. Acuerdo en las definiciones de seguridad con el cliente. 2. Identificar metas de seguridad. 3. Desarrollar artefactos, diagramas de arquitectura, casos de mal uso, casos de uso de seguridad. 4.

Evaluación de los riesgos.

5. Elicitación de los requisitos de seguridad. 6. Clasificar los requisitos de acuerdo con el nivel o las metas de seguridad. 7. Priorizar los requisitos. 8. Revisión por pares.

CoSMo Conceptual Security Modeling Debido a la necesidad de integrar aspectos de seguridad en el proceso de modelado de software, el modelado conceptual debe abarcar los requisitos y los mecanismos de seguridad de alto nivel.

Antes de definir los mecanismos de seguridad para

hacer cumplir los requisitos, se

elaboran cuestionamientos fundamentales de las políticas de seguridad; las cuales consisten de un conjunto de leyes, normas y prácticas que regulan cómo una organización gestiona, protege y distribuye información sensible. Cada requisito de seguridad lo puede ejecutar uno o más mecanismos de seguridad, resultando en una matriz de requisitos y mecanismos. Se enumeran de forma sistemática los requisitos de seguridad frecuentes e indican claramente cuáles son los mecanismos para hacerlos cumplir. En general, un requisito de seguridad exigido no es parte del diagrama de casos de uso, sino de la descripción del caso de uso. En CoSMo, es posible modelar este requisito en el nivel conceptual, incluso en un diagrama de casos de uso.

UMLSec Es una metodología de desarrollo basada en UML para especificar requisitos de seguridad relacionados con integridad y confidencialidad. Mediante mecanismos ligeros de extensión de UML es posible expresar los estereotipos, las etiquetas, las restricciones y el comportamiento de un subsistema en presencia de un ataque. El modelo define un conjunto de operaciones que puede efectuar un atacante a un estereotipo y trata de modelar la actuación del subsistema en su presencia. Esta metodología define varios estereotipos que identifican requisitos de seguridad, como secrecy, en el que los subsistemas deben cumplir con que ningún atacante pueda ver su contenido mientras este esté en ejecución y secure

link, con el que se asegura el

cumplimiento de los requisitos de seguridad en la comunicación a nivel físico; lo que pretende evaluar es que un atacante en una dependencia de un subsistema estereotipada, como secrecy, que tenga dos nodos n, m que se comunican a través de un enlace l nunca pueda leer el contenido del subsistema.

Casos de Mal Uso Es el caso inverso de un caso de uso UML y es lo que el sistema no debería permitir. Así como en un caso de uso se define la secuencia de acciones que le dan un valor agregado al usuario, en uno de mal uso se define la secuencia de acciones que se traducen en pérdida para la organización o los usuarios interesados. Un mal actor es lo contrario a un actor. Es un usuario que no se quiere que el sistema soporte y que podría ser un agresor. Para las fases de diseño se utilizan algunas técnicas y pruebas o testeos como:

Análisis de riesgo Threat Modeling Técnica formal, estructurada y repetible que permite determinar y ponderar los riesgos y amenazas a los que estará expuesta la aplicación. Consta de las siguientes etapas: 1) Conformar un grupo de análisis de riesgos 2) Descomponer la aplicación e identificar componentes clave. 3) Determinar las amenazas a cada componente de la aplicación. 4) Asignar un valor a cada amenaza. 5) Decidir cómo responder a las amenazas. 6) Identificar las técnicas y tecnologías necesarias para mitigar los riesgos identificados.

Método STRIDE Ayuda a identificar amenazas en los componentes de un sistema, su nombre es un acrónimo de: Spoofing Identity: Suplantar la identidad de otro usuario o servicio. Tampering with Data: Modificar maliciosamente datos almacenados. Repudiation: Imposibilidad de identificar el autor de una acción.

IInformation Disclosure: Divulgar información a usuarios no autorizados. Denial of Service: Provocar que un servicio deje de funcionar. Elevation of privilege: Conseguir privilegios mayores a los asignados

Árboles de ataque Es un método que permite identificar vulnerabilidades en cada uno de los componentes del software y jerarquizarlos, ver el siguiente ejemplo:

1.1 El usuario tenía una contraseña débil 1.2.1 La comunicación no estaba encriptada 1.2 El atacante capturó datos de autenticación de la red 1.2.2 El mecanismo de autenticación es vulnerable a “replay” de paquetes 1.3 Amenaza #1

El sistema permitió un

Un usuario accede en

ataque de diccionario /

nombre de otro

fuerza bruta 1.4.1El sistema de validación no falla de manera segura 1.4 El sistema de validación / autenticación es defectuoso 1.4.2 El sistema de validación es vulnerable a ataques de “SQL Injection” 1.5 El sistema permite armar peticiones con IDs de otros usuarios

Método DREAD Ayuda a ponderar las amenazas identificadas. Su nombre corresponde a un acrónimo de los siguientes 5 ítems: Damage Potencial: ¿Cuán importante es el daño de esta amenaza? Reproducibility: ¿Cuán reproducible es la vulnerabilidad? Exploitability: ¿Cuán fácil es de explotar vulnerabilidades? Affected Users: ¿Cuáles y cuántos usuarios se verían afectados? Discoverability: ¿Cuán fácil de descubrir es la vulnerabilidad?

Testing Funcional (clásico) Aplicado a las funcionalidades de seguridad de una aplicación. Ej: 

Requisitos de autenticación



Requisitos de complejidad de contraseñas



Bloqueo automático de cuentas



Funcionalidad de captchas para la detección de robots



Restricciones de acceso según diseño



Mecanismos de registro y logging



Mensajes de error especificados

Testing de seguridad basado en Riesgo Técnica que se desprende del Threat Modelling, ƒ se identifican todas las interfaces de la aplicación y se generan casos de test sobre cada interfaz basado en STRIDE.

Testing con un cliente / server falso Consiste en diseñar un cliente o server “Ad Hoc” que permita: 

Enviar peticiones /respuestas incorrectas o inválidas.



Enviar peticiones/ respuestas fuera de orden.



Insertar delays arbitrarios.



Comportarse de manera diferente al cliente o servidor real.

Test de stress Consiste en llevar la carga o funcionalidad de la aplicación al límite 

Generar una carga alta de peticiones/transacciones a la aplicación.



Mantener esta carga durante tiempos prolongados.



Simular tráfico en ráfagas.

Test de mutación de datos Se testea la aplicación ingresando en sus interfaces datos “mutados” 

Con diferente signo



De diferente tipo



Con diferente longitud



Fuera de rango



Con caracteres especiales



Con Código (ej: javascripts)



Con valores nulos



Con valores aleatorios

Revisión de código Permite encontrar vulnerabilidades que son muy difíciles de detectar con otros métodos de testing de seguridad (ej: BackDoors)



Enfoque tradicional: Grupo de revisión



Enfoque rápido: Revisión por pares

En la fase de implementación más que métodos se habla de buenas prácticas como:

Hardening de software de base 

Evitar Servicios innecesarios



Evitar Usuarios y contraseñas default



Configuración de intérpretes y compiladores apropiadamente

Proceso de implementación 

Separación de ambientes



Administración de implementación y mantenimiento



Establecer políticas Releases y Patches



Generar Firma de código

Propuesta de un nuevo S-SDLC.

Considero que tener en cuenta la seguridad en el desarrollo de software no admite modificaciones en el ciclo de vida de su desarrollo pero si se pueden adoptar diferentes metodologías y aún más, nuevos paradigmas de desarrollo, en este sentido creo que es conveniente revisar el paradigma de “Programación orientada a Aspectos” de la cual expongo algunos conceptos generales.

La Programación Orientada a Aspectos es una nueva metodología de programación que permite la separación de los elementos funcionales del software de otros conceptos no funcionales pero son requeridos en él, como la sincronización, el manejo de memoria, distribución, el chequeo de errores, la seguridad, y el uso redes. Esto implica separar la funcionalidad básica de dichos aspectos, y los aspectos entre sí, a través de mecanismos

que permitan la abstracción y la composición de los mismos, a fin de poder implementar todos los requerimientos del sistema.

La Programación Orientada a Aspectos permite a los desarrolladores escribir, ver, y editar un aspecto diseminado por todo el sistema como una entidad por separado, de una manera inteligente, eficiente e intuitiva. Los tres elementos constitutivos principales de la Programación Orientada a Aspectos son: • Un lenguaje para definir la funcionalidad básica, conocido como lenguaje base o componente. El mismo puede ser un lenguaje imperativo, o no, como por ejemplo C++, Java, Lisp, ML. • Uno o varios lenguajes de aspectos, para especificar el comportamiento de los distintos aspectos. Algunos ejemplos son COOL, para especificar sincronización,

IDL para

especificar distribución, ASPECJ de Java y otros. • Un tejedor de aspectos, del inglés weaver, que se encarga de combinar los lenguajes en tiempo de ejecución o de compilación. Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para encapsular aquellos conceptos que cruzan todo el código. Al momento de tejer los componentes funcionales y los aspectos para formar el sistema final, es evidente que se requiere una interacción entre el código que provee la funcionalidad básica, y el código de los aspectos. Esta interacción no es la misma que ocurre entre los módulos del lenguaje base, donde la comunicación está basada en declaraciones de tipo, y llamadas a procedimientos y funciones. Por esta razón, la POA define una nueva forma de interacción, provista a través de puntos de enlace. Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del código donde es posible agregar el comportamiento adicional que caracteriza a la POA. Dicho comportamiento adicional es especificado en los aspectos, y puede

agregarse antes, después, o en el lugar del punto de enlace. Por ejemplo, dentro de la POO algunos puntos de enlace pueden ser: llamadas a métodos, creación de objetos, acceso a atributos, etc. El encargado principal en el proceso de la POA, el tejedor, este debe realizar la parte final y más importante: tejer los diferentes mecanismos de abstracción y composición que aparecen tanto en los lenguajes de aspectos, como en los lenguajes de componentes, guiado por los puntos de enlace.

Conclusiones.

El desarrollo de software ha presentado varias etapas en su evolución, de productos monolíticos paso a productos modulares con independencia de funciones o reglas de negocio, de datos y de la presentación para el usuario donde la calidad fue factor decisivo para su aceptación.

Para garantizar dicha calidad fue necesario abordar su desarrollo identificando las fases de su desarrollo mediante un ciclo de vida y de acuerdo a la forma de enfrentar estas fases se aplican diferentes modelos o metodologías.

Con la expansión de las redes y la utilización de internet el software salió de las fronteras empresariales y con esto se ve la necesidad de tener en cuenta el factor seguridad en su desarrollo, con lo cual surge el término Ciclo de Vide del desarrollo de software seguro SSDLC.

No bastó la identificación del ciclo de vida de desarrollo, sino que fue necesario revisar los paradigmas y se pasó de la orientación a procesos a la orientación a objetos y hoy se discute el paradigma de orientación a aspectos para separar algunos factores que se intercalan en cada uno de los componentes del software como la seguridad.