Fundamentos de la Seguridad Informática. Políticas y Modelos de Seguridad

Transcripción

1 Fundamentos de la Seguridad Informática Políticas y Modelos de Seguridad GSI - Facultad de Ingeniería

2 Políticas de seguridad Qué es una política de seguridad? Qué reglas deben ser definidas? Para formular un política de seguridad se deben describir Las entidades gobernadas por la política La reglas que constituyen la política Qué tipo de definición? Definición informal: documento en lenguaje natural Definición formal: lógica y especificación de alto nivel del sistema Abril 2017 FSI - Modelos I

3 Modelos Han jugado un rol muy importante desde el comienzo de la actividad en el área Proceso de diseño y verificación Especificación formal de la política que debe ser aplicada Especificación de alto nivel del sistema de estudio y modelado de los mecanismos de seguridad Verificación que la política es satisfecha por el modelo (prueba formal si alto nivel de aseguramiento es requerido) Abril 2017 FSI - Modelos I

4 Plan El modelo HRU (DAC) El modelo Bell-LaPadula (MAC) Formalización de políticas de seguridad Explicación del modelo, su alcance y limitaciones Otros Modelos de Seguridad El modelo Chinese Wall combina elementos de DAC y MAC Modelo RBAC es usualmente considerado un modelo neutral El modelo Biba relevante para integridad El modelo de Information-Flow generaliza las ideas subyacentes en MAC Abril 2017 FSI - Modelos I

5 Introducción Dos categorías principales: Discretionary Access Control Models (DAC) Definición [Bishop p.53] Si un usuario individual puede setear un mecanismo de control de acceso para permitir o denegar un acceso a un recurso, ese mecanismo constituye un control de acceso discrecional (DAC), también llamado un control de acceso basado en identidad (IBAC). Mandatory Access Control Models (MAC) Definición [Bishop p.53] Cuando un mecanismo de un sistema controla acceso a un objeto y un individuo no puede alterar ese acceso, entonces el control de acceso es mandatorio (MAC) (ocasionalmente llamado control de acceso basado en reglas) Abril 2017 FSI - Modelos I

6 DAC Políticas de seguridad DAC gobiernan el acceso de sujetos a objetos basándose en la identidad del sujeto, la identidad del objeto y los permisos de acceso Cuando un access request (AR) es sometido al sistema, el mecanismo de control de acceso verifica si existe un permiso que autorice el acceso Estos mecanismos son discrecionales ya que permiten que los sujetos puedan otorgarle a otros sujetos autorización de acceder sus propios objetos Abril 2017 FSI - Modelos I

7 DAC Ventajas: Flexibilidad para especificar políticas Provisto por todos los SOs y DBMS Desventajas: No pueden controlar flujo de la información (ataques con Troyanos) Abril 2017 FSI - Modelos I

8 DAC El modelo HRU El modelo Harrison-Ruzzo-Ullman (HRU) introdujo conceptos muy importantes: La noción de authorization systems La noción de safety M.Harrison, W. Ruzzo, J. Ullman. Protection in Operating Systems. Comm. of ACM 19(8), August Abril 2017 FSI - Modelos I

9 El Modelo HRU Para describir el modelo HRU se requiere: Un conjunto de sujetos S Un conjunto de objetos O Un conjunto R de permisos de acceso Una matriz de control de acceso M = (M so ) s S, o O La entrada M so es el subconjunto R que especifica los permisos que el sujeto s tiene sobre el objeto o Abril 2017 FSI - Modelos I

10 El modelo HRU Operaciones Primitivas El modelo incluye 6 operaciones primitivas para manipular el conjunto de sujetos, el de objetos y la matriz de acceso: enter r into M so delete r from M so create subject s delete subject s create object o delete object o Abril 2017 FSI - Modelos I

11 El modelo HRU - Comandos Los comandos tienen la forma command c(x 1,...,x k ) if r 1 in M s 1,o1 and if r 2 in M s 2,o2 and. if r m in M s m,om then op 1,...,op n end Abril 2017 FSI - Modelos I

12 El modelo HRU - Comandos Los índices s 1,...,s m y o 1,...,o m son sujetos y objetos que ocurren en la lista de parámetros c(x 1,...,x k ) La condición de los comandos chequean determinados permisos de acceso Si todas las condiciones se hacen verdaderas entonces se ejecuta la secuencia de operaciones básicas Cada comando contiene al menos una operación Los comandos que contienen exactamente una operación son llamados comandos mono-operacionales Abril 2017 FSI - Modelos I

13 El modelo HRU Ejemplos de Comandos command create_file (s,f) create f enter o into M s,f enter r into M s,f enter w into M s,f end command grant_read (s,p,f) if o in M s,f then enter r into M p,f end Abril 2017 FSI - Modelos I

14 El modelo HRU Sistemas de protección Un sistema de protección se define como Un conjunto finito de permisos Un conjunto finito de comandos Un sistema de protección es un sistema de transición de estados Abril 2017 FSI - Modelos I

15 El modelo HRU Estados Los efectos de un comando son registrados como cambios en la matriz de acceso ( usualmente denotada M ) La matriz entonces describe el estado del sistema de protección Qué representa el estado del sistema de protección? El estado de un sistema es la colección de los valores corrientes de las celdas de memoria, la memoria secundaria y los registros y otros componentes del sistema El estado del sistema de protección es el subconjunto de esa colección que está asociado a las direcciones de los permisos de acceso, representado por la matriz de acceso Abril 2017 FSI - Modelos I

16 El modelo HRU Estados Definición. Un estado, es decir, una matriz de acceso, se dice que gotea (leaks) el permiso r si existe un comando c que agrega el permiso r en una entrada de la matriz de acceso que anteriormente no contenía ese permiso. Más formalmente, existen s y o tales que r M so y, luego de la ejecución de c, r M so. Nota: El hecho de que un permiso gotee no es necesariamente malo, muchos sistemas permiten a sujetos darle acceso a otros sujetos Abril 2017 FSI - Modelos I

17 El modelo HRU Estados seguros Qué se entiende por un estado seguro? Definición 1: acceso a los recursos sin el consentimiento del propietario es imposible [HRU76] Definición 2: un usuario debería ser capaz de saber si la acción que va a efectuar (por ejemplo, otorgar un permiso) puede provocar que el mismo gotee hacia sujetos no autorizados [HRU76] Abril 2017 FSI - Modelos I

18 El modelo HRU Safety El problema que motiva la introducción de este concepto puede ser descrita de la siguiente forma: Suponer que un sujeto s planea darle al sujeto s el permiso r sobre el objeto o. La pregunta obvia es si la matriz de acceso corriente, con r agregado en la entrada (s,o), es tal que ese permiso r podría a su vez posibilitar la entrada de algún otro permiso no existente. Abril 2017 FSI - Modelos I

19 El modelo HRU Un ejemplo de sistema de protección unsafe Asuma un sistema de protección con los siguientes dos comandos: command grant_execute (s,p,f) if o in M s,f then enter x into M p,f end command modify_own_right (s,f) if x in M s,f then enter w into M s,f end Abril 2017 FSI - Modelos I

20 El modelo HRU Un ejemplo de sistema de protección inseguro Suponer que el usuario Juan desarrolló un programa que él desea sea ejecutado por otros usuarios pero no puedan modificarlo El sistema anterior no es seguro respecto a esta política, considere la siguiente secuencia de comandos: - Juan: grant_execute (Juan, José, P 1 ) - José: modify_own_right (José, P 1 ) resulta en una matriz de acceso donde la entrada M José,P1 contiene el permiso de acceso w Abril 2017 FSI - Modelos I

21 El modelo HRU Safety Definición. Dado un sistema de protección y un permiso r, la configuración inicial Q 0 es unsafe para r (o gotea r) si existe una configuración Q y un comando c tales que Q es alcanzable desde Q 0 c gotea r desde Q Q 0 es safe para r si Q 0 no es unsafe para r. Definición alternativa. Un estado de un sistema de protección, o sea, su matriz M, es safe respecto al permiso r si no existe secuencia de comandos que puedan transformar M en un estado que gotee r. Teorema. Dada una matriz de acceso M y un permiso r, verificar la seguridad de M respecto a r es un problema indecidible Abril 2017 FSI - Modelos I

22 El modelo HRU - Conclusiones Los resultados sobre la decibilidad del problema de safety ilustran un principio importante, el principio de economía de mecanismos Si uno diseña sistemas complejos que pueden solamente ser descriptos por modelos complejos, resulta muy difícil encontrar pruebas de safety de los mismos en el peor caso (indecibilidad), no existe un algoritmo universal que verifica la seguridad del mismo para todas las posibles instancias del problema Abril 2017 FSI - Modelos I

23 Otros Modelos Teóricos El modelo take-grant (A. Jones, R. Lipton, and L. Snyder) El modelo Typed Access Matrix (R. Sandhu) Abril 2017 FSI - Modelos I

24 Otros Modelos Los modelos DAC han sido extensivamente investigados en el área de DBMS El primer modelo para bases de datos relacionales fue desarrollado por Grifiths y Wide Varias extensiones a ese modelo han sido desarrolladas Abril 2017 FSI - Modelos I

25 DAC Características adicionales Flexibilidad es incrementada soportando diferentes clases de permisos Positivos vs. negativos Implícitos vs. explícitos Basados en contenido Abril 2017 FSI - Modelos I

26 Permisos Positivos y Negativos Positivos Permiten acceso Negativos Niegan acceso Útiles para especificar excepciones a una política dada y para reforzar control en datos particulares Abril 2017 FSI - Modelos I

27 Permisos Positivos y Negativos + - Problema: Conflictos Abril 2017 FSI - Modelos I

28 Conflictos de Autorización Soluciones: No admitir conflictos Permisos negativos tienen precedencia Permisos positivos tienen precedencia Ninguno tiene precedencia Permisos más específicos tienen precedencia Abril 2017 FSI - Modelos I

29 Permisos Implícitos y Permisos Explícitos Algunos modelos proveen permisos implícitos Permisos implícitos pueden ser derivados: Por un conjunto de reglas de propagación que explotan el sujeto, objeto y jerarquía de privilegios Por un conjunto de reglas de derivación definidas por el usuario Abril 2017 FSI - Modelos I

30 Reglas de Derivación: Ejemplo Ana puede leer file F 1 desde una tabla si a Juan le ha sido explícitamente denegado ese permiso Tomás tiene sobre file F 2 los mismos permisos que Juan tiene sobre ese file Reglas de derivación son una forma de expresar concisamente un conjunto de requerimientos de seguridad Abril 2017 FSI - Modelos I

31 Reglas de Derivación Son usualmente expresadas usando programación lógica (Datalog) Existen mucho trabajo de investigación desarrollados con el objetivo de comparar el poder expresivo de ese tipo de lenguajes Se necesitan languajes basados en SQL y/o XML Abril 2017 FSI - Modelos I

32 Permisos basados en contenido Este tipo de control de acceso condiciona el acceso a un objeto basado en el contenido del mismo Este tipo de permisos es principalmente relevante para sistemas de base de datos Ejemplo: en un RDBMS que implementa control de acceso basado en contenidos es posible autorizar un sujeto a acceder información solamente de aquellos empleados cuyo salario no es mayor que una suma dada Abril 2017 FSI - Modelos I

33 Permisos basados en contenido Son dos los enfoques más comunes para enforzar control de acceso basado en contenidos en DBMS: Associando un predicado con el permiso Definiendo una vista que selecciona aquellos objetos cuyo contenido satisface una condición dada, y entonces otorgando permisos sobre la vista en vez de hacerlo sobre los objetos básicos Abril 2017 FSI - Modelos I

34 Modelos DAC - DBMS vs SO Mayor número de objetos a ser protegidos Diferentes niveles de granularidad (relaciones, tuplas, atributos simples) Protección de estructuras lógicas (relaciones, vistas) en lugar de recursos reales (files) Diferentes niveles de arquitectura con diferentes requerimietnos de protección Relevancia no solamente de la representación física de los datos, también de su semántica Abril 2017 FSI - Modelos I

35 Troyanos (Trojan Horse) Proceso P read O1 write O2 O1 (ana,r,o1) O2 (ana,r,o2), (ana,w,o2), (juan,r,o2) Abril 2017 FSI - Modelos I

36 Troyanos Los modelos DAC no tienen capacidad para proteger datos contra Troyanos embebidos en programas de una aplicación Los modelos MAC fueron desarrollados para prevenir este tipo de acceso ilegal Abril 2017 FSI - Modelos I

37 MAC MAC especifica el acceso que los sujetos tienen sobre objetos basado en la clasificación de seguridad que se hace de esos sujetos y objetos Este tipo de seguridad también es conocido como multilevel security Los sistemas de base de datos que satisfacen seguridad multinivel son llamados multilevel secure database management systems (MLS/DBMSs) La mayoría de los MLS/DBMSs han sido diseñados usando el modelo de Bell y LaPadula (BLP) Abril 2017 FSI - Modelos I

38 El Modelo BLP Uno de los modelos de seguridad más difundidos Seguridad de SO multi-usuario Sistemas que procesan información clasificada de distintos niveles deberían implementar MLS Los usuarios sólo deberían poder acceder a la información que están autorizados (clearance) Abril 2017 FSI - Modelos I

39 El Modelo BLP BLP se formuló como un modelo de Máquinas de Estado que captura aspectos de confidencialidad Permisos de acceso se definen usando una matriz de control de acceso y etiquetas de seguridad Las políticas establecen que la información no puede fluir hacia niveles de seguridad inferiores a los del repositorio origen El modelo sólo considera el flujo que ocurre cuando un subject observa o altera un objeto Abril 2017 FSI - Modelos I

40 El Estado Se desea utilizar el estado del sistema para verificar su seguridad, entonces el conjunto de estados del modelo debe capturar todas las instancias de sujetos que están accediendo a objetos y todos los permisos especificados Conjuntos base Conjunto S de sujetos Conjunto O de objetos Conjunto A = {read,write,execute, append} de operaciones de acceso Conjunto L de etiquetas de seguridad, con un orden parcial Abril 2017 FSI - Modelos I

41 El Estado Componentes Tabla de operaciones de acceso: b : B = [S x O x A] Matriz de permisos: m : M = (M so ) Funciones de asignación de niveles de seguridad F s : S -> L (nivel maximal de seg. de sujetos) F c : S -> L (nivel de seguridad corriente de sujetos) F o : O -> L (clasificación de los objetos) f: F = F s x F c x F o El estado = (b,m,f) : B x M x F Abril 2017 FSI - Modelos I

42 Seguridad simple BLP define seguridad como una propiedad que cumplen los estados MLS permite a un sujeto leer un objeto sólo si el nivel de seguridad del sujeto domina al del objeto Propiedad de Seguridad Simple (ss): Un estado (b,m,f) satisface la propiedad ss, si para cada tupla (s,o,a) de b donde la operación a es read o write se cumple F o (o) F s (s) Esta propiedad captura la política de confidencialidad no read-up Abril 2017 FSI - Modelos I

43 Desclasificación Sistemas donde sujetos son procesos No tienen memoria, pero Tienen acceso a objetos de memoria Pueden actuar como canales leyendo un objeto y transfiriendo la información a otro objeto Un atacante puede insertar un troyano en un objeto de alto nivel de seguridad y copiar información de objetos de alto nivel en objetos de inferior nivel de seguridad Abril 2017 FSI - Modelos I

44 La propiedad * BLP incluye una propiedad de no escritura hacia abajo pero que refiere al nivel corriente de seguridad del sujeto La propiedad *: Un estado (b,m,f) satisface esta propiedad si para cada tupla (s,o,a) de b donde la operación a es write o append el nivel corriente de seguridad del sujeto s es dominado por la clasificación de o, es decir se cumple que F c (s) F o (o). Mas aún, si existe una tupla (s,o,a) de b donde la operación a es write o append, entonces de debe cumplir que F o (o') F o (o) para o' en (s,o',a') y a' es write o append Abril 2017 FSI - Modelos I

45 Estado y Transición Seguros Un estado (b,m,f) se dice que es seguro si satisface las propiedades ss, * y sd Una transición del estado s 1 = (b 1,m 1,f 1 ) al estado s 2 = (b 2,m 2,f 2 ) es segura si los dos estados son seguros Transiciones deben preservar las propiedades de seguridad Ejemplo: La propiedad ss es preservada por la transición sii cada (s,o,a) {b 2 b 1 } satisface ss respecto a f 2 si (s,o,a) Є b 1 no satisface ss respecto a f 2, entonces (s,o,a) b 2 Abril 2017 FSI - Modelos I

46 Tranquility Cuestionamiento de McLean al modelo BLP: sistema con una transición que Asigna a sujetos y objetos el nivel mínimo de seguridad Asigna todos los permisos a cada entrada de la matriz de control de acceso Esta transición es segura según la definición de BLP,... realmente lo es? En contra de BLP: un sistema que puede degenerarse así no es seguro (McLean) A favor de BLP: si es un requerimiento del usuario la transición debe ser admitida, sino no lo debe ser (Bell) Abril 2017 FSI - Modelos I

47 Tranquility El punto central de esta discusión es una transición de estado que cambia los permisos de acceso Estos cambios son admitidos en el marco general de BLP Los autores consideraron sistemas donde los permisos de acceso son invariantes La propiedad de que los permisos de acceso y los niveles de seguridad nunca son modificados es llamada Tranquility Abril 2017 FSI - Modelos I

48 La interpretación Multics de BLP Multics: proyecto de investigación cuyo objetivo era desarrollar un SO multi-usuario seguro y confiable Motivó una gran cantidad de trabajo en seguridad Precursor de Unix: balance entre seguridad y usabilidad Modelo de seguridad usado para diseñar un SO seguro: definición de Multics consistente con BLP Abril 2017 FSI - Modelos I

49 Sujetos en Multics Los sujetos en Multics son procesos Cada sujeto tiene un descriptor segment con información sobre el sujeto y los objetos sobre los que éste tiene acceso Por cada objeto existe un segment descriptor word (SDW): Nombre del objeto (segment-id) Puntero al mismo Flags de acceso: r,e,w (on,off) Abril 2017 FSI - Modelos I

50 Sujetos en Multics Los niveles de seguridad de los sujetos son almacenados en dos tablas: Process level Current-level Una tabla, llamada active segment table, registra todos los procesos activos Sólo procesos activos pueden tener acceso a objetos Abril 2017 FSI - Modelos I

51 Instancia Multics del estado BLP Las tripletas de acceso b En los SDWs de los DS de los procesos Los procesos activos se encuentran en la tabla active segment La matriz de control de acceso M: Representada por las ACLs de los objetos Cada entrada en la ACL (en el directorio padre del objeto) especifica un proceso y los permisos asociados Abril 2017 FSI - Modelos I

52 Instancia Multics del estado BLP Función de nivel F: F s : tabla process level F c : tabla current-level F o : el nivel de seguridad de un objeto se almacena en el directorio padre del mismo Abril 2017 FSI - Modelos I

53 Traducción de políticas La propiedad *: Para toda SDW en el descriptor segment de un proceso activo, el nivel corriente del proceso Domina el nivel del segmento si el indicador read o execute está en on y el indicador write está en off Es dominado por el nivel del segmento si el indicador read está en off y el write está en on Es igual al nivel del segmento si los dos indicadores, read y write, están en on Abril 2017 FSI - Modelos I

54 Verificando primitivas Kernel primitives: transiciones de estado en el modelo abstracto de Multics Probar que preservan las propiedades de BLP get-read: toma como parámetros un process-id (pid) y un segment-id (dsid) El SO debe chequear La ACL de dsid lista a pid con acceso read El nivel de seguridad de pid domina al de dsid pid es trusted o su nivel corriente domina al de dsid Abril 2017 FSI - Modelos I

55 Verificando get-read Si las tres condiciones son satisfechas entonces se permite al acceso y Si no existe SDW para dsid se agrega una al descriptor de pid Si la SDW existe entonces se setea al indicador read en on Si alguna de las condiciones no se cumple, entonces el acceso es denegado Abril 2017 FSI - Modelos I

56 Bibliografía y Referencias D. Gollman, Computer Security, Wiley, E. Bertino, Notes of Information Security course, Purdue University, M.A. Harrison, W.L. Ruzzo, J.D. Ullman, Protection in Operating Systems, Comm. ACM, D.E. Bell, L. LaPadula, Secure Computer Systems: Mathematical Foundations, MTR-2457, Vol. 1, The MITRE Corporation, D.E. Bell, L. LaPadula, Secure Computer Systems: Unified Exposition and Multics Interpretation, MTR-2997, The MITRE Corporation, Abril 2017 FSI - Modelos I

57 Bibliografía y Referencias K.J. Biba, Integrity Considerations for Secure Computer Systems. MITRE report TR-3153, D.F.C Brewer, M.J. Nash, The Chinese Wall Security Policy, Proc. IEEE Symp. Research in Security and Privacy, D.R. Clark, D.R. Wilson, A comparison of commercial and military computer security policies, Proc. IEEE Symp. Research in Security and Privacy, R.S. Sandhu, Lattice-Based Access Control Models, IEEE Computer, Abril 2017 FSI - Modelos I