Taller 2 Grupal Metodologías de S-SDLC
Método STRIDE
Análisis de riesgo - Threat Modeling
Programación orientada a aspectos
Ayuda a identificar amenazas en los componentes de un sistema
I (Information Disclosure)
S (Spoofing identity)
T (Tampering with Data)
R (Repudiation)
D (Denial of Services)
E (Elevation of privilege)
Conseguir privilegios mayores a los asignados
Provocar que un servicio deje de funcionar.
Suplantación de indentidad
Modificar maliciosamente datos almacenados.
Imposibilidad de identificar el autor de una acción.
Divulgar información a usuarios no autorizados
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 6 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.
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. Todo, a través de mecanismos.
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.
Testing de seguridad basado en Riesgo
Se identifican todas las interfaces de la
aplicación y se generan casos de test sobre cada interfaz basado en STRIDE.
Consiste en diseñar un cliente o server “Ad Hoc” que permita:
Enviar peticiones/ respuestas fuera de orden.
Insertar delays arbitrarios.
Enviar peticiones /respuestas incorrectas o inválidas.
Comportarse de manera diferente al cliente o servidor real.