Poniendo el caballo delante

del carro – Requerimientos de

seguridad OWASP LATAM Tour 2014

Argentina

9 de Mayo 2014

Agenda

• Intro

• Ciclo de vida genérico y defectos

• Requerimientos

• Técnicas de obtención de requerimientos

• Técnicas de obtención de requerimientos de seguridad

• Metodologías relacionadas

• 10 ideas finales

• Conclusiones

Intro: Proyecto típico…

Ciclo de vida genérico y defectos

Análisis

Diseño

Construcción Pruebas

Operación y Mantenimiento

Donde se originan aprox. el 64%

de los defectos

(IBM Systems Sciences Institute)

Esfuerzo corrección vs Fase

Esfuerzo de corrección de acuerdo a la fase donde es detectado el defecto

0

10

20

30

40

50

60

70

80

90

100

Analisis Diseño Desarrollo Pruebas Mantenimiento yoperación

1 3 5

15

30

1 3 6,5

15

100

NIST IBM Science Institute

Requerimientos

Requerimientos

funcionales

(FR)

Requerimientos

NO funcionales

(NFR)

Requerimiento

Especificación de requerimientos

Documento de especificación de

requerimientos (SRS)

Necesario

Conciso

Consistente

No ambiguo

Completo

Verificable

Función que el

sistema o

componente debe

ser capaz de

realizar

Restricciones.

Normalmente no

son expresados

por el usuario y se

dan por sobre

entendidos

Una condición o

necesidad de un usuario

para resolver un problema

o alcanzar un objetivo

Declaración oficial de

que deben

implementar los

desarrolladores del

sistema

Proveedor

Desarrollador

Cliente

Usuario

Técnicas de obtención-generales Técnica / Característica

principal Método de elicitación Metodología/ Proceso particular

Entrevistas Reuniones con partes interesadas N/A

Cuestionarios Respuesta de partes interesadas N/A

Análisis de actividades Observación N/A

Análisis del dominio Conocimiento del dominio del sistema

Feature-Oriented Domain Analysis

(FODA)

Brainstorming Presentación de ideas N/A

JAD Desarrollo en conjunto JAD

ARM Reunión con partes interesadas facilitada ARM

Etnografía

Observación o participación en el proceso

analizado

Observación

Análisis de protocolo

Aprendiz

Prototipado Presentación de prototipos

RAD

XP

Elicitación por metas Obtención de incremental de metas

Proyecto F3

Metamodelo KAOS

Framework i*

Tropos

Técnicas de obtención-seguridad

Técnica Técnica base Modela o expresa

Casos de mal uso Casos de uso UML Situaciones que el sistema no debe permitir

Casos de abuso Casos de uso UML Situaciones perjudiciales para el sistema

Casos de uso de seguridad Casos de uso UML Funcionalidad de seguridad requerida

Casos de uso de obligación Casos de uso UML

Obligaciones de la organización a considerar en el

sistema

Arboles de ataque Especificación de metas Eventos que pueden dañar a la organización

Anti-metas Especificación de metas

Situaciones que pueden prevenir alcanzar las

metas

Twin peak + common criteria Catalogo de requerimientos Amenazas al sistema y posibles soluciones

Secure tropos Tropos

Restricciones de seguridad, dependencias de

seguridad y ataques posibles

Metodologías

• SQUARE (Security Quality Requirements Engineering)

– 9 pasos

• SQUARE-Lite (Security Quality Requirements Engineering Lite)

– 4 pasos (subset de SQUARE)

• SREP (Security Requirements Engineering Process)

– 9 pasos (algunos puntos de contacto/pasos comunes con SQUARE)

• CLASP (CLASP- Comprehensive, Lightweight Application Security Process)

– 5 vistas, 7 mejores prácticas (1 de ellas para requerimientos), 24 actividades, 104 vulnerabilidades en 5 categorias

• STRIDE/DREAD (Spoofing, Tampering, Repudiation, Disclosure, DoS,

Elevation of privilege / Damage, Reproducibility, Exploitability, Affected users,

Discoverability ) – Se pueden derivar requerimientos basados en 6 amenazas de alto nivel

– Se puede priorizar usando DREAD

Mo

dela

do

de

am

en

aza

s

Ori

en

tad

o

al S

DL

C

Ori

en

tad

as

a r

eq

ueri

mie

nto

s

Si no nos queda tiempo…

GOTO…10 ideas finales

Si nos queda tiempo…

Anexo I

Ejemplos de técnicas de

elicitación de requerimientos

Casos de abuso

Casos de mal uso

Caso de uso de seguridad

Caso de uso de obligación

Arboles de ataque

Twin Peak + CC

Secure Tropos

10 ideas finales

1. Elegir una metodología

2. Elegir técnicas para elicitar

3. Definir conceptos que puedan no ser comunes

para los desarrolladores

– Usar fuentes serias (IEEE, ISO, NIST,etc.)

– Crear un catálogo (glosario)

4. Dar intervención a todas las partes necesarias

durante la elicitación

– Ej.: Legales, Cumplimiento regulatorio, Auditoria, etc.

10 ideas finales

5. Considerar los elementos de contexto

– Leyes, marco regulatorio, contratos, etc

– Marco normativo interno

– Tipo de aplicación a desarrollar

– Tipo de información a ser tratada

6. Reutilizar requerimientos comunes

– Catálogo de requerimientos

– Requerimientos para tipos de aplicaciones

7. Organizar y agrupar los requerimientos obtenidos

10 ideas finales

8. Analizar si de la organización/agrupación

no se derivan nuevos requerimientos

9. Priorizar los requerimientos

10. Especificar los requerimientos y sus

atributos (clasificación, grupo, prioridad,

identificación) en el SRS

Conclusiones

• Requerimientos de seguridad en etapas

tempranas = menor costo e impacto

• Empatizar con los desarrolladores,

facilitarles su labor

• Involucrar a todas las partes necesarias

• Utilizar alguna metodología

• Reutilizar el conocimiento

ANEXO II

Especificación de requerimientos.

Como especificar

• Requerimiento mandatorio = DEBE

• Requerimiento no mandatorio = DEBERIA o SE RECOMIENDA

• Sugerencias = PUEDE

• Evitar declaraciones negativas (ej: “No debe”)

• Evitar frases impersonales (ej.: “el informe se genera”, en su lugar “el componente x debe generar el informe y”) .

Ejemplos

[Condición] [Sujeto] [Acción] [Objeto] [Restricción]

Ejemplo: Cuando se recibe la señal x [CondIción], el sistema [Sujeto] debe fijar

[Acción] la señal x bit recibidos [Objeto] dentro de los 2 segundos [Restricción].

O

[Condición] [Acción o Restricción] [Valor]

Ejemplo: En el estado de mar 1 [Condición], El sistema de radar debe detectar

objetivos a rangos fuera de [Acciónn o Restricción] 100 Millas náuticas [Valor].

O

[Sujeto] [Acción] [Valor]

Ejemplo: El sistema de facturación [Sujeto], debe mostrar las facturas pendientes

de clientes [Acción] En orden ascendente [Valor] en el que las facturas han ser

pagadas.

Ejemplo de plantilla de especificación

Nro. de Requerimiento:

Prioridad:

Tipo de requerimiento:

Relacionado con caso de uso Nro:

Descripción:

Justificación:

Origen:

Criterio de verificación:

Dependencias:

Conflictos:

Documentos de soporte:

Historial del requerimiento:

Creación: Fecha

Modificación: Versión Fecha Cambio realizado

¿Preguntas?

?

Bibliografía

• Firesmith, D. G. (2003). Security use cases. Journal of Object Technology , 53-64.

• Hernan, S., Lambert, S. O., & Shostack, A. (2006, November 1). Uncover Security Design Flaws Using The

STRIDE Approach. Retrieved Octubre 06, 2012, from MSDN Magazine: http://msdn.microsoft.com/hi-

in/magazine/cc163519%28en-us%29.aspx

• Kabasele Tenday, J.-M. (2010). Using Special use case for security in the software development life cycle.

Information Security Applications: 11th International Workshop WISA 2010 (pp. 122-134.). Springer.

• Lamsweerde, A. v., Brohez, S., De Landsheer, R., & Janssens, D. (2003). From System Goals to Intruder Anti-

Goals:Attack Generation and Resolution for Security Requirements Engineering. 11th IEEE International

Requirements Engineering Conference RE03 - 2nd Workshop on Requirements for High Assurance Systems

REHAS 03 (pp. 49-56). Monterrey Bay, CA, USA: Carnegie Mellon - Software Engineering Institute.

• Mead, N. R. (2006-2008, 09 22). Requirements Elicitation Case Studies Using IBIS, JAD, and ARM. Retrieved 10

14, 2012, from Build Security In: https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/532-

BSI.html

• Mead, N. R., Houg, E. D., & Stehney, T. R. (2005). Security Quality Requirements Engineering (SQUARE)

Methodology. Pittsburgh, PA: Carnegie Mellon University - Software Engineering Institute (CMU-SEI).

Bibliografía

• Mellado, D., Fernandez-Medina, E., & Piattini, M. (2006). A Common Criteria Based Security Requirements

Engineering Process for the Development of Secure Information Systems. In Varios, Computer Standard and

Interfaces (pp. 244-253). Madrid y Ciudad Real - España: Elsevier.

• Mouratidis, H., & Giorgini, P. (2007). SECURE TROPOS: A SECURITY-ORIENTED EXTENSION OF THE

TROPOS METHODOLOGY. World Scientific Publishing , 17 (2) 285-309 .

• NIST. (2002). NIST Report "The Economic impacts of inadequate infrastructure for software testing". NIST.

• Ponemon Institute LLC. (2012). The impact of cybercrime on Business. Ponemo Institute LLC sponsored by

Checkpoint Software Technologies.

• Saeki, M., & Kaiya, H. (2009). Using Common Criteria as Reusable Knowledge in Security Requirements

Elicitation. Tokio, Japón: Dept. of Computer Science, Tokyo Institute of Technology.

• Schneier, B. (1999). Modeling Security Threaths. Dr. Dobb´s Journal , December ISSUE.

• Sindre, G. O. (2001). Capturing security requirements trough misuse cases. Retrieved 05 01, 2006, from

folk.uio.no: http://folk.uio.no/nik/2001/21-sindre.pdf

Contacto

www.portoyasociados.com.ar

jantunez@portoyasociados.com.ar