Ciclo de vida de desarrollo de Software Seguro

Ciclo de vida de desarrollo
de Software Seguro
Facultad Politécnica – UNA
Maestría en TICs – 2015
Énfasis Auditoría y Seguridad de la Información
Seguridad en aplicaciones y base de datos
Cristian Cappo ([email protected])
NIDTEC - Núcleo de Investigación y Desarrollo Tecnológico - FPUNA
Contenido
 Principios de diseño de seguridad
 Seguridad en el ciclo de vida de un software
 Modelo de desarrollo de software seguro de
OWASP (OpenSMMI) (diapositivas prestadas)
2
Principios de diseño de seguridad (PDS)*
Estos principios se aplican para el diseño e implementación de
mecanismos de seguridad. Se enfoca en las ideas de simplicidad y
restricción
1)
2)
3)
4)
5)
6)
7)
8)
Diseño abierto
Seguro a fallas, por defecto
Privilegios mínimos
Economía de mecanismo
Separación de privilegios
Mediación completa
Mecanismo de menos común
Aceptabilidad psicológica
*Saltzer & Schoroeder. The protection of information in Computer Systems. Proceedings of the
IEEE. Vol. 63 Num 9. Pag: 1278-1308. 1975.
DOI: 10.1109/PROC.1975.9939
3
PDS (2)
1) Diseño abierto/público (Open Design)
 Sugiere que la complejidad no agrega seguridad
 Definición: la seguridad de un mecanismo no
debería depender del secreto de su diseño o
implementación.
 El término “seguridad por oscuridad” captura el
concepto.
 Ejemplo: El sistema CSS (Content Scrambling System) es un
algoritmo criptográfico que protegía a los DVDs de copias no
autorizadas. Aunque el algoritmo se mantuvo oculto, en 1999 se
descubrió el algoritmo, se publicó y se rompió.
4
PDS (3)
2) Seguro ante fallas, por defecto
 Restringe como los privilegios son inicializados
cuando un sujeto u objeto es creado.
 Definición: un privilegio a un sujeto debe ser dado
explícitamente sobre un objeto, de lo contrario se
debe denegar el acceso al mismo.
 El acceso por defecto es “ninguno”
 Ejemplo: Si un servidor de mail no puede crear el directorio de
spool, éste debe cerrar la conexión, emitir un mensaje de error
y parar. No debe tratar de guardar el mensaje o expandir sus
privilegios para guardar el mensaje en otro lugar, esto daría
lugar a un atacante para sobrescribir o alzar nuevos archivos o
llenando el disco (ataque DoS).
5
PDS (4)
3) Privilegios mínimos
 Indica como los privilegios son otorgados
 Definición: un sujeto debe tener solo los privilegios
necesarios a fin de completar su tarea.
 Si alguien no necesita de un privilegio, no lo debe
tener.
 Ejemplo 1: En Unix al usuario root no se le aplica control de
acceso, tiene privilegio a todo. Viola este principio
 Ejemplo 2: un mail server que acepta conexiones de internet y
copia los mensajes al directorio spool. Solo necesita acceso al
puerto de red, crear los archivos y modificarlos. Debe renunciar
a sus derechos sobre el archivo tan pronto como termina su
tarea. Este no debe poder leer luego los archivos de usuarios.
6
PDS (5)
4) Economía en los mecanismos
 Enfatiza que el diseño e implementación de los
mecanismos de seguridad deben ser simples.
 Definición: los mecanismos de seguridad deben ser
tan simples como se pueda.
 Si los mecanismos son simples, existe menos
posibilidades de error. El proceso de pruebas de los
mecanismos es menos complejo.
 Los mecanismos complejos a veces hacen asunciones
sobre el sistema o entorno donde se ejecutan. Si
éstas con incorrectas, podrían generar problemas de
seguridad.
7
PDS (6)
5) Separación de privilegios
 Limita el acceso a las entidades del sistema
 Definición: un sistema no debe otorgar permisos
basados en una simple decisión.
 Sistemas y programas deben dar acceso a recursos
solo cuando mas de una condición es cumplida.
 Ejemplo: En Berkeley-Unixs, los usuarios no pueden cambiarse
a la cuenta root a no ser que se den dos situaciones. La primera
es que conozca la contraseña de root y la segunda que se
encuentre en el grupo wheel.
8
PDS (7)
6) Mediación completa
 Este principio restringe la información en caché.
 Definición: requiere que todos los accesos a los
objetos sean chequeados para asegurar que ellos
sean permitidos.
 Ejemplo: El DNS guarda información en el caché de los
nombres de hosts con sus direcciones IP. Si un atacante
envenena el caché implantando registros asociados a un IP falso
con un nombre válido, un host puede enrutar conexiones a otro
host incorrectamente.
9
PDS (8)
7) Mecanismo común mínimo
 Es restrictivo ya que limita el compartir
 Definición: los mecanismos para acceso a recursos
no deben ser compartidos.
 Compartir recursos provee un canal por el cual la
información puede ser transmitida, por lo que debe
minimizarse el compartir.
 Ejemplo: un sitio web provee servicio de comercio electrónico
a una compañía. Los atacantes quieren privar a esa compañía
de sus ganancias, así que inundan el sitio con mensajes
obstruyendo el servicio de comercio electrónico haciendo que
los usuarios legítimos no puedan accederlo. En este caso el
compartir Internet con el sitio de los atacantes causan que el
ataque sea exitoso.
10
PDS (9)
8) Aceptabilidad psicológica
 Se reconoce el elemento humano en la seguridad
informática.
 Definición: los mecanismos de seguridad no deben
hacer mas dificultoso el acceso a un recurso que
cuando éstos no estén presentes.
 Configurar y ejecutar un programa debe ser fácil e
intuitivo tanto como sea posible, y la salida debe ser
clara, directa y útil.
 Ejemplo: el programa ssh permite al usuario configurar el
mecanismo de clave pública para cifrar la comunicación. Si se
guarda la clave pública, se permite la conexión sin proveer la
contraseña pero se mantiene la conexión cifrada.
11
Ejercicios sobre PDS
1. Un programa llamado lsu da acceso a un rol en un sistema. Se
chequea los derechos del usuario y entonces se requiere introducir
su contraseña. Si tiene derecho y su contraseña es correcta
entonces lsu permite el cambio. María utiliza lsu desde su cuenta,
¿porqué lsu requiere su contraseña? ¿Cuál es el principio aplicado?
2. Un mecanismo común para proteger de obtención de contraseña
por fuerza bruta es deshabilitar la cuenta luego de 3 o un número
definido de intentos.
1.
2.
¿Cómo esta técnica puede prevenir que usuarios legítimos acceda al sistema?.
¿Qué principio de diseño viola y porqué?
Se puede argumentar que este es un mecanismo que aborda el principio de
seguro ante fallas, por defecto. Indique porqué se aplicaría este principio. En
que caso no es una aplicación de este principio.
12
Componentes de la seguridad(ext)
 Confidencialidad
 El dato es accesible solo para los que poseen permiso para ello.
 Privacidad: personas
Condidencialidad: datos.
 Integridad
 Datos y sistema son cambiados solo de la forma apropiada por las
personas apropiadas
 Disponibilidad
 El sistema esta disponible cuando se le necesita y su performance
es aceptable.
Otros componentes extendidos pero relacionados a los
anteriores
 Autenticación: La identidad de usuarios es establecida (Confidencialidad).
 Autorización: El acceso o no de usuarios a los recursos es explícito.
(Integridad)
 No repudio: Usuarios no pueden realizar una acción y luego negar que la
hicieron. (Integridad)
13
Seguridad en el ciclo de vida de un
software
 Abordaje erróneo: diseñar y construir software
ignorando la seguridad desde el principio
 Agregar seguridad una vez que los requerimientos funcionales
son satisfechos.
 Mejor abordaje: incorporar seguridad desde el
principio, en todas las fases del proceso de desarrollo.
 Descubrir problemas de seguridad en fases avanzadas
del desarrollo son difíciles de arreglar y solucionar y
generalmente más costosas.
Según Fortify corregir errores de seguridad en el nivel de requerimiento es 100
veces menos costoso que hacerlo en un software terminado. Business Software
Assurance: Identifying and Reducing - 9th Semi-Annual Software Assurance Forum,
Gaithersburg, MD, 2008
14
Seguridad en el ciclo de vida de un
software
 Fase del proceso de desarrollo de un software
(presentes generalmente en todas las metodologías de
desarrollo)
 Requerimientos
 Diseño
 Implementación
 Testing
 Implantación
 ¿Dónde agregar seguridad?
 En todas las fases
15
Seguridad en el ciclo de vida de un
software
 El diseño, construcción y despliegue de una
aplicación debe integrar seguridad en todo su
ciclo de vida.
 Veremos en las siguientes diapositivas
actividades específicas que integran la seguridad
en cada ciclo de la vida de la aplicación
 Estas actividades se basan en las
recomendaciones de Microsoft para desarrollo
de aplicaciones (SDL). Mandatorio en MS desde
2004.
16
Seguridad en el ciclo de vida de un software
17
Terminología - revisión
 Amenaza
 Es un evento no deseado. Una ocurrencia potencial o un efecto
que puede dañar o comprometer un activo u objetivo.
 Vulnerabilidad
 Es una debilidad (falla) en algún aspecto o característica del
sistema que hace posible su ataque. Puede existir en la red,
host, aplicación o prácticas operacionales.
 Ataque (o exploit)
 Es una acción que usa una o más vulnerabilidades para
concretar una amenaza.
 Contramedida
 Aplicar acciones para reducir la probabilidad de ataques o el
impacto de ellas. No abordan directamente las amenazas sino
se enfocan en las causas que las generan.
18
Actividades de seguridad en el SDLC
1. Objetivos de seguridad:
 Define los objetivos y requerimientos de seguridad de forma temprana en el proceso.
Son metas y restricciones que afectan la CID de datos y aplicación.
2. Guía de Diseño por seguridad
 Eliminar los vulnerabilidades comunes por mala elección de diseño.
3. Modelado de amenazas
 Identificar y comprender las amenazas y vulnerabilidades relevantes en el contexto del
sistema. Identifica acciones de un atacante y como puede comprometer el sistema.
4. Diseño y arquitectura por seguridad
 Analiza el diseño y la arquitectura desde el punto de vista de seguridad. Incluye
aspectos como implantación e infraestructura.
5. Revisión de código por seguridad
 Identificar vulnerabilidades de seguridad en la implementación.
6. Pruebas de seguridad
 Abordaje basado en riesgo (asegurar que el sistema pueda defenderse de ataques
probables y ataques más costosos)
7. Revisión de implantación por seguridad:
 Incluye la evaluación del entorno de ejecución y configuración del sistema
19
Actividades de seguridad en el ciclo de vida de
una aplicación
20
1) Objetivos de seguridad
21
Descubriendo los objetivos de seguridad
 Matriz de roles
 Derivar de los requerimientos funcionales
22
Matriz de roles
 Ejemplo
23
Derivar de los requerimientos funcionales
 Ejemplo
24
2) Guía de Diseño por seguridad
 Consisten en un conjunto de prácticas que pueden ser
empleados para reducir el riesgo de vulnerabilidades de
seguridad.
 Cada directriz/guía debe ser:
 Accionable
 Asociada a una vulnerabilidad a ser mitigada
 Relevante
 Asociada a una vulnerabilidad que es conocida afecta a
aplicaciones reales.
 De impacto
 Debe representar una decisión de ingeniería que tenga un impacto
amplio.
 Este conjunto es referenciado en un marco de seguridad
o de trabajo (framework)
25
Marco de seguridad
 Es una modelo de información-patrón que
define un conjunto de aspectos de seguridad
para la aplicación que se está diseñando.
 Las guías de patrones y prácticas incluyen un
marco de seguridad específico por cada tipo de
aplicación.
26
Categoría de vulnerabilidades común en
muchos tipos de aplicaciones
27
Directrices específicas para una aplicación
específica
 Ejemplo: aplicación web
28
Consideraciones de despliegue
29
Directrices de diseño que son comunes en
muchas aplicaciones
30
Directrices de diseño que son comunes en
muchas aplicaciones (2)
31
3) Modelado de amenazas
 “Software security” es un área de la seguridad
computacional que se enfoca en el diseño e
implementación segura del software. Construir software
seguro que funcione como es esperado a través de todo
su ciclo de vida. Es diferente a “security software”
¿Porqué?
 El modelado de amenazas es parte integral del ciclo de
desarrollo seguro de una aplicación.
 Cuando desarrolla o actualiza un sistema, debe
considerar cómo un intruso puede atacarlo y cómo
construir las defensas apropiadas en los estadios de
diseño e implementación del mismo.
32
Modelado de amenazas
 Existen muchos abordajes
 No existe una forma bien establecida para
medirla calidad de un modelo de amenazas.
 Aun en el campo más maduro, como por
ejemplo el de criptografía, muchos programas
populares aun no han probado ser seguros
(HeartBleed – bug de OpenSSL - CVE-20140160).
33
Modelado de amenazas
 Es una técnica de ingeniería que se utiliza para
identificar amenazas, ataques, vulnerabilidades y
contramedidas
 Ayuda a:
 Reconocer los objetivos de seguridad
 Amenazas relevantes
 Vulnerabilidades y contramedidas
 Es realizado para identificar cuando y donde se
requieren más recursos para reducir los riesgos.
 Se realiza usualmente en la fase de diseño de un
sistema y se retroalimenta de otras fases.
 Provee también las bases para el plan de test de
seguridad (penetration test) y para la revisión de código
34
Modelado de amenazas – proceso iterativo
35
Modelado de amenazas en el
ciclo de vida de un SW
 En el modelo SDL de MS
36
Proceso de modelo de amenazas, resumen de
entrada/salida por cada paso
37
Utilizando STRIDE
STRIDE es una taxonomía de amenazas que identifica varios tipos de
amenazas considerándolas desde la perspectiva del atacante. Es también
una propuesta de MS.
Amenaza
Spoofing
Falsificación de identidad
Componente de seguridad
Autenticación
Tampering
Modificación de dato o código
Integridad
Repudiation
Negar que se ha realizado una acción
No Repudio
Information disclosure
Exponer información no autorizada
Confidencialidad
Denial of service
Denegar o degradar el servicio a los usuarios
Disponibilidad
Elevation of privilege
Ganar capacidades sin la debida autorización
Autorización
38
Modelado de amenazas
 Forma parte del SDL (Security Development Lifecycle)
 En el modelo de amenazas utilizando STRIDE,
se descompone el sistema en componentes
relevantes, se analiza cada componente por
susceptibilidad a las amenazas y se mitiga las
mismas.
 Este proceso se repite hasta que uno se
encuentre confortable con las amenazas que
restan.
 Si hace esto puede argumentar que su sistema
es seguro.
39
El proceso de modelado con STRIDE
40
El proceso de modelado con STRIDE
 Diagrama: se utiliza DFD (Data Flow Diagram
– Diagrama de Flujo de Datos) aunque se puede
utilizar cualquier otro para representar el diseño
del sistema.
41
Elementos del DFD
42
DFD
 Puede hacerse en varios niveles
 Diagrama de contexto.
 Alto nivel, el producto/sistema completo
 Nivel 1
 Alto nivel con los principales componentes
 Nivel 2
 Bajo nivel con detalle de subcomponentes
 Nivel 3
 Mucho más detallado, solo para grandes proyectos
43
Ejemplo (diagrama de contexto)
44
Ejemplo (Diagrama de nivel 1)
45
DFD
 Análisis o Síntesis
 TopDown
 Comienza del contexto
 Se focaliza en el sistema como un todo
 Bottom up
 Se conoce en detalle las características
 Se comienza desde abajo
 Abordaje no es conveniente para la síntesis
46
Reglas básicas
 Los datos no aparecen mágicamente, los datos
vienen de un DataStore (almacenamiento) o de
una entidad externa.
 Los datos no mueren en un DataStore, se indica
un DataStore por alguna razón.
 Los datos no fluyen mágicamente entre los
DataStores, debe existir un proceso entre ellos.
 No reensamblar el diagrama de clases o grafos
de llamadas.
47
Amenazas por cada elemento del sistema
(Identificando amenazas)
En caso de almacenar datos de auditoría/logging
tiene una amenaza de Repudio
48
Mitigación: algunas mitigaciones estándar
49
Mitigaciones
Tipo de amenaza
Técnica de mitigación
Spoofing
Autenticación apropiada, Protección de datos secretos
No guardar “secretos”
Tampering
Autorización apropiada, Hashes, MAC(message
authentication code), Firma digital,
Uso de protocolos resistentes a modificaciones
Repudiation
Firma digital, Timestamps, logs de auditoría
Information disclosure Autorización, Protocolos de privacidad mejorados,
encripción, protección de “secretos”, no guardar
“secretos”
Denial of service
Autenticación, autorización, filtrado, calidad de servicio,
regulación de tráfico
Elevation of privilege
Ejecución con menos privilegio posible
50
Validación
 Validar todo el modelo
 ¿Coincide con el código final?
 ¿Son todas las amenazas enumeradas?
 Mínimo: STRIDE de cada elemento que toca la línea
o límite de confianza
 ¿Esta cada amenaza mitigada?
 ¿Son las mitigaciones correctas?
 Validar la información capturada
 ¿Qué otro código utiliza? ¿Qué funciones de
seguridad esta en otro código? ¿Es seguro?
51
Ejemplo
 Suponga un sencillo sistema que colecta las
ventas desde varias sucursales, procesa los
datos de ventas y produce reportes semanales.
 Existen muchas amenazas obvias a este sistema
(¿Cuáles son?)
52
DFD Inicial
Vendedores
Sucursal 01
Aplicación de
ventas
Aplicación de
ventas
Datos Vendedores
Datos Venta
Datos Venta
Proceso de
envío
Proceso de
envío
Proceso
Recolección
Proceso
Análisis
Datos Análisis
Vendedores
Sucursal NN
Cliente
Límite de confianza
Servidor
53
Un DFD mejor analizado
Datos Vendedores
2
Vendedores
Sucursal 01
1
Proceso
recolección
y análisis
3
Vendedores
Sucursal NN
Datos Análisis
Generación
Reportes
Administrador
54
Analizando los flujo de datos y
almacenamientos
 Flujo de Dato 1:
Tampering - Information disclosure - Denial of Service
 Flujo de Dato 2:
Tampering - Information disclosure - Denial of Service
 Flujo de Dato 3:
Tampering - Information Disclosure - Denial of service
 Almacenamiento Datos Vendedores
Tampering - Information Disclosure - Denial of service
 Almacenamiento Datos Análisis
Tampering - Information Disclosure - Denial of service
 Proceso de recolección y análisis de datos
Spoofing - Information Disclosure - Denial of service - Elevation of privilege Repudiation
55
Determinando el riesgo
Opción 1:
Riesgo = Chance del ataque x Daño Potencial.
Problemático para determinar la probabilidad a priori
Opción 2:
 El modelo de MS utiliza DREAD para determinar el riesgo.
 Damage Potencial: ¿cuál es el grado de daño en caso de ataque?
 Reproducibility: ¿qué tan fácil es reproducir un ataque?
 Exploitability: ¿Cuánto tiempo, expertise y esfuerzo es necesario para explotar
la amenaza?
 Affected users: si la amenaza es explotada, ¿cuántos usuarios son afectados?
 Discoverability: ¿qué tan fácil es descubrir esta amenaza?
 Para determinar el riesgo se da a cada amenaza un valor de 1 al
10, donde 10 indica más riesgo. Se promedia y se puede distribuir
en alto, medio y bajo riesgo.
56
Otra forma de ver las amenazas y contramedidas
Grafo de amenazas
Atacante puede leer
los mensajes de
usuarios
Usuario no cerró su
sesión en una
computadora
compartida
Mala validación de
los datos,
permitiendo
inyección SQL
Autorización puede
fallar permitiendo
acceso no
autorizado
Implementar un
buen esquema de
validación de datos
Implementar un
buen chequeo de
autorización
El navegador
puede contener
parte del mensaje
en su caché
Implementar anticaching de
cabeceras HTTP
Usar SSL
57
Modelado de amenazas (conclusiones)
 Es una actividad estructurada que permite
identificar y evaluar amenazas y vulnerabilidades.
 Debe empezar temprano con el diseño
arquitectónico del sistema
 Debe ser refinado en la etapa de implementación
 Debe coincidir plenamente con el diseño de los
objetivos de seguridad
 Debe ayudar a ponderar contra otros aspectos de
diseño como el rendimiento.
58
Otros abordajes de modelado de
amenazas
 OWASP (https://www.owasp.org/index.php/Threat_Risk_Modeling)
 Básicamente es el mismo mostrado aquí.
 Trike (http://www.octotrike.org/home.shtml)
 OCTAVE (CERT) (SEI - Carnegie Mellon University )
(http://www.cert.org/resilience/products-services/octave/octavemethod.cfm)
59
Ejercicio
 Realice el Modelado de amenazas de la
aplicación payroll utilizado en clases pasadas.
Asuma que esta aplicación será instalada en un
servidor web disponible en la red Interna de la
entidad.




Analice la aplicación
Construya el DFD
Indique las amenazas posibles
Proponga las contramedidas posibles para cada amenaza en
caso de que estas sean de alto o medio riesgo considerando el
modelo DREAD y los valores promedios
 10-8
 7-5
 4-1
: Alto
: Medio
: Bajo
60
App: Payroll
61
DFD - Payroll
62
4) Diseño arquitectónico seguro
63
Consideraciones de despliegue e infraestructura
64
Arquitectura de la aplicación y consideración de
diseño
65
5) Revisión de Código seguro
 1: establecer metas y
restricciones de la revisión
 2: usar análisis estático para
encontrar un conjunto inicial de
vulnerabilidades
 3: revisión de código buscando
vulnerabilidades comunes
guiados por el paso 2
 4: revisar mecanismos únicos
de seguridad en la arquitectura
 Técnicas de revisión:
 ControFlow
 DataFlow
66
Lista de preguntas para revisar el código
67
Lista de preguntas para revisar el
código(2)
68
7) Revisión de Despliegue seguro
 Categorías de configuración de un servidor
69
Revisión de despliegue seguro
Categorías de aseguramiento del servidor
70
Revisión de despliegue seguro
 Categorías de aseguramiento del servidor(2)
Aquí termina el modelo SDL de MS
71
Verificación de aplicaciones web
 OWASP ASVS
(Application Security Verification Standard)
 Normaliza el rango de cubrimiento y nivel de rigor
disponible en el mercado cuando se realiza una
verificación de una aplicación web por seguridad.
 Ideal para verificar software de terceros o empresas
de consultoría de seguridad.
 Define niveles de verificación
72
OWASP ASVS (2)
Nivel
O (Coursory)
Es opcional e indica que la aplicación ha pasado algún
tipo de verificación
1 (Opportunistic)
Existen defensas adecuadas para vulnerabilidades fáciles
de descubrir
2 (Standard)
Existen defensas adecuadas para vulnerabilidades
prevalentes cuya existencia genera un riesgo moderado
a serio. Puede incluir las vulnerabilidades “Top 10
OWASP” y vulnerabilidades lógicas.
3 (Advanced)
Existen defensas adecuadas contra todas las
vulnerabilidades avanzadas y se muestra principios de un
buen diseño por seguridad.
73
OWASP ASVS (3)
 Áreas de verificación que define













Autenticación
Manejo de sesión
Control de acceso
Manejo de entrada maliciosa
Criptografía y REST
Manejo de errores y logging
Protección de datos
Comunicación
HTTP
Control de código malicioso
Lógica del negocio
Archivos y recursos
Mobile
74
OWASP ASVS (4)
Ejemplo de tabla de verificación por área
75
Bibliografía/Referencias
 M. Bishop. Introduction to Computer Security. Addison
Wesley. 2005. (capítulo 13)
 J.D. Meir et al. Security Engineering Explained. Patterns
& practices. Microsoft. 2005.
 STRIDE Model. Microsoft.
 NIST 800-64 rev. 2 “Security considerations in the System
Development Life Cycle” (http://csrc.nist.gov/publications/nistpubs/800-64Rev2/SP800-64-Revision2.pdf)
 OWASP - SAMM (http://www.opensamm.org)
 OWASP – ASVS
(https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verificati
on_Standard_Project)
 Microsoft SDL (http://www.microsoft.com/security/sdl/default.aspx)
76
¡Gracias!
¿Preguntas?
77