Presentación brindada en el contexto del OWASP Latam Tour 2014 - Argentina Presentación introductoria sobre el impacto de la inclusión tardia de los requerimientos en general y de seguridad en particular. Inclusión oportuna en las etapas tempranas de los proyectos de desarrollo de software. Técnicas de elicitación de requerimientos de seguridad: Security use cases Mis-use cases Abuse cases Obligation use cases Threat trees STRIDE / DREAD Anti-Goals Secure tropos SQUARE SQUARE-Lite SREP CLASP

1. Poniendo el caballo delante
del carro – Requerimientos de
seguridad
OWASP LATAM Tour 2014
Argentina
9 de Mayo 2014

2. 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

3. Intro: Proyecto típico…

4. Ciclo de vida genérico y defectos
Análisis
Diseño
ConstrucciónPruebas
Operación y
Mantenimiento
Donde se originan aprox. el 64%
de los defectos
(IBM Systems Sciences Institute)

5. 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 y
operación
1
3 5
15
30
1
3 6,5
15
100
NIST IBM Science Institute

6. 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

7. 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

8. 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

9. 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
Modeladode
amenazas
Orientado
alSDLC
Orientadasarequerimientos

10. Si no nos queda tiempo…
GOTO…10 ideas finales

11. Si nos queda tiempo…
Anexo I
Ejemplos de técnicas de
elicitación de requerimientos

12. Casos de abuso

13. Casos de mal uso

14. Caso de uso de seguridad

15. Caso de uso de obligación

16. Arboles de ataque

17. Twin Peak + CC

18. Secure Tropos

19. 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.

20. 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

21. 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

22. 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

23. ANEXO II
Especificación de requerimientos.

24. 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”) .

25. 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.

26. 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

27. ¿Preguntas?
?

28. 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).

29. 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

30. Contacto
www.portoyasociados.com.ar
jantunez@portoyasociados.com.ar