Ciclo de vida de desarrollo de Software Seguro

Transcripción

1 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 (ccappo@pol.una.py) NIDTEC - Núcleo de Investigación y Desarrollo Tecnológico - FPUNA

2 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

3 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) Diseño abierto 2) Seguro a fallas, por defecto 3) Privilegios mínimos 4) Economía de mecanismo 5) Separación de privilegios 6) Mediación completa 7) Mecanismo de menos común 8) Aceptabilidad psicológica *Saltzer & Schoroeder. The protection of information in Computer Systems. Proceedings of the IEEE. Vol. 63 Num 9. Pag: DOI: /PROC

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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. Cómo esta técnica puede prevenir que usuarios legítimos acceda al sistema?. Qué principio de diseño viola y porqué? 2. 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

13 Componentes de la seguridad(ext) Confidencialidad El dato es accesible solo para los que poseen permiso para ello. Integridad Privacidad: personas Condidencialidad: datos. 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

14 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,

15 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

16 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

17 Seguridad en el ciclo de vida de un software 17

18 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

19 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

20 Actividades de seguridad en el ciclo de vida de una aplicación 20

21 1) Objetivos de seguridad 21

22 Descubriendo los objetivos de seguridad Matriz de roles Derivar de los requerimientos funcionales 22

23 Matriz de roles Ejemplo 23

24 Derivar de los requerimientos funcionales Ejemplo 24

25 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

26 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

27 Categoría de vulnerabilidades común en muchos tipos de aplicaciones 27

28 Directrices específicas para una aplicación específica Ejemplo: aplicación web 28

29 Consideraciones de despliegue 29

30 Directrices de diseño que son comunes en muchas aplicaciones 30

31 Directrices de diseño que son comunes en muchas aplicaciones (2) 31

32 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

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

34 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

35 Modelado de amenazas proceso iterativo 35

36 Modelado de amenazas en el ciclo de vida de un SW En el modelo SDL de MS 36

37 Proceso de modelo de amenazas, resumen de entrada/salida por cada paso 37

38 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 Tampering Modificación de dato o código Repudiation Negar que se ha realizado una acción Componente de seguridad Autenticación Integridad No Repudio Information disclosure Exponer información no autorizada Denial of service Denegar o degradar el servicio a los usuarios Elevation of privilege Ganar capacidades sin la debida autorización Confidencialidad Disponibilidad Autorización 38

39 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

40 El proceso de modelado con STRIDE 40

41 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

42 Elementos del DFD 42

43 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

44 Ejemplo (diagrama de contexto) 44

45 Ejemplo (Diagrama de nivel 1) 45

46 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

47 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

48 Amenazas por cada elemento del sistema (Identificando amenazas) En caso de almacenar datos de auditoría/logging tiene una amenaza de Repudio 48

49 Mitigación: algunas mitigaciones estándar 49

50 Mitigaciones Tipo de amenaza Spoofing Tampering Repudiation Técnica de mitigación Autenticación apropiada, Protección de datos secretos No guardar secretos Autorización apropiada, Hashes, MAC(message authentication code), Firma digital, Uso de protocolos resistentes a modificaciones 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 Elevation of privilege Autenticación, autorización, filtrado, calidad de servicio, regulación de tráfico Ejecución con menos privilegio posible 50

51 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

52 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

53 DFD Inicial Vendedores Sucursal 01 Datos Vendedores Aplicación de ventas Datos Venta Proceso de envío Proceso Recolección Aplicación de ventas Datos Venta Proceso de envío Proceso Análisis Vendedores Sucursal NN Datos Análisis Cliente Límite de confianza Servidor 53

54 Un DFD mejor analizado Datos Vendedores Vendedores Sucursal 01 Vendedores Sucursal NN 1 2 Proceso recolección y análisis 3 Datos Análisis Generación Reportes Administrador 54

55 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

56 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

57 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 El navegador puede contener parte del mensaje en su caché Implementar un buen esquema de validación de datos Implementar un buen chequeo de autorización Implementar anticaching de cabeceras HTTP Usar SSL 57

58 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

59 Otros abordajes de modelado de amenazas OWASP ( Básicamente es el mismo mostrado aquí. Trike ( OCTAVE (CERT) (SEI - Carnegie Mellon University ) ( 59

60 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 : Alto : Medio : Bajo 60

61 App: Payroll 61

62 DFD - Payroll 62

63 4) Diseño arquitectónico seguro 63

64 Consideraciones de despliegue e infraestructura 64

65 Arquitectura de la aplicación y consideración de diseño 65

66 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

67 Lista de preguntas para revisar el código 67

68 Lista de preguntas para revisar el código(2) 68

69 7) Revisión de Despliegue seguro Categorías de configuración de un servidor 69

70 Revisión de despliegue seguro Categorías de aseguramiento del servidor 70

71 Revisión de despliegue seguro Categorías de aseguramiento del servidor(2) Aquí termina el modelo SDL de MS 71

72 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

73 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

74 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

75 OWASP ASVS (4) Ejemplo de tabla de verificación por área 75

76 Bibliografía/Referencias M. Bishop. Introduction to Computer Security. Addison Wesley (capítulo 13) J.D. Meir et al. Security Engineering Explained. Patterns & practices. Microsoft STRIDE Model. Microsoft. NIST rev. 2 Security considerations in the System Development Life Cycle ( Rev2/SP Revision2.pdf) OWASP - SAMM ( OWASP ASVS ( on_standard_project) Microsoft SDL ( 76

77 Gracias! Preguntas? 77