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 d...
Intro: Proyecto típico…
Ciclo de vida genérico y defectos
Análisis
Diseño
ConstrucciónPruebas
Operación y
Mantenimiento
Donde se originan aprox. e...
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
...
Requerimientos
Requerimientos
funcionales
(FR)
Requerimientos
NO funcionales
(NFR)
Requerimiento
Especificación de requeri...
Técnicas de obtención-generales
Técnica / Característica
principal Método de elicitación Metodología/ Proceso particular
E...
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...
Metodologías
• SQUARE (Security Quality Requirements Engineering)
– 9 pasos
• SQUARE-Lite (Security Quality Requirements E...
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...
10 ideas finales
5. Considerar los elementos de contexto
– Leyes, marco regulatorio, contratos, etc
– Marco normativo inte...
10 ideas finales
8. Analizar si de la organización/agrupación
no se derivan nuevos requerimientos
9. Priorizar los requeri...
Conclusiones
• Requerimientos de seguridad en etapas
tempranas = menor costo e impacto
• Empatizar con los desarrolladores...
ANEXO II
Especificación de requerimientos.
Como especificar
• Requerimiento mandatorio = DEBE
• Requerimiento no mandatorio = DEBERIA o
SE RECOMIENDA
• Sugerencias =...
Ejemplos
[Condición] [Sujeto] [Acción] [Objeto] [Restricción]
Ejemplo: Cuando se recibe la señal x [CondIción], el sistema...
Ejemplo de plantilla de especificación
Nro. de Requerimiento:
Prioridad:
Tipo de requerimiento:
Relacionado con caso de us...
¿Preguntas?
?
Bibliografía
• Firesmith, D. G. (2003). Security use cases. Journal of Object Technology , 53-64.
• Hernan, S., Lambert, S...
Bibliografía
• Mellado, D., Fernandez-Medina, E., & Piattini, M. (2006). A Common Criteria Based Security Requirements
Eng...
Contacto
www.portoyasociados.com.ar
jantunez@portoyasociados.com.ar
Upcoming SlideShare
Loading in …5
×

Owasp Latam tour 2014 - Poniendo el caballo delante del carro

695 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
695
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
17
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Owasp Latam tour 2014 - Poniendo el caballo delante del carro

  1. 1. Poniendo el caballo delante del carro – Requerimientos de seguridad OWASP LATAM Tour 2014 Argentina 9 de Mayo 2014
  2. 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. 3. Intro: Proyecto típico…
  4. 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. 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. 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. 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. 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. 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. 10. Si no nos queda tiempo… GOTO…10 ideas finales
  11. 11. Si nos queda tiempo… Anexo I Ejemplos de técnicas de elicitación de requerimientos
  12. 12. Casos de abuso
  13. 13. Casos de mal uso
  14. 14. Caso de uso de seguridad
  15. 15. Caso de uso de obligación
  16. 16. Arboles de ataque
  17. 17. Twin Peak + CC
  18. 18. Secure Tropos
  19. 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. 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. 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. 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. 23. ANEXO II Especificación de requerimientos.
  24. 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. 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. 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. 27. ¿Preguntas? ?
  28. 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. 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. 30. Contacto www.portoyasociados.com.ar jantunez@portoyasociados.com.ar

×