owasp latam tour 2014 - poniendo el caballo delante del carro
Post on 03-Jul-2015
299 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related