Seguridad en S.Os. Confiables

Presentación del tema: "Seguridad en S.Os. Confiables"— Transcripción de la presentación:

1 Seguridad en S.Os. Confiables
El diseño es delicado y no es fácil agregar seguridad a S.Os. que no incluyeron seguridad en su diseño original. Características: Identificación y autentificación de usuarios. Control de acceso mandatorio. Control de acceso discreto. Mediación completa. Auditoría. Reducción de logs. Caminos confiables. Detección de intrusos.

2 Seguridad en S.Os. Confiables (1)
Identificación El acceso se basa en la identidad de los individuos. Los S.Os. confiables requieren identificación segura de individuos. Control de Acceso Mandatorio y Discreto (1) Mandatory Access Control (MAC): las decisiones de control de acceso son independientes del dueño de un objeto. Existe una autoridad central que decide qué información es accesible por quién, y el individuo no puede cambiar permisos.

3 Seguridad en S.Os. Confiables (2)
Control de Acceso Mandatorio y Discreto (2) Discretionary Access Control (DAC): opuesto a MAC. El usuario fija los permisos sobre sus objetos. Más usado en ambientes comerciales. Why? Se puede usar MAC y DAC sobre un mismo objeto con MAC mayor precedencia que DAC. Ej.? Protección de Reutilización de Objeto Un atacante puede utilizar memoria, registros de procesador, disco, etc. que fueron previamente usados y liberados por otro usuario con el fin de “conseguir” información.

4 Seguridad en S.Os. Confiables (3)
Mediación Completa Para que MAC y DAC sean efectivos es obvio que todos los accesos deben ser controlados. Es insuficiente, por ej., proteger archivos si el atacante tiene “luz verde” en memoria. Caminos Confiables Es altamente deseable que nadie intercepte un camino de comunicación donde viaje información confidencial. Por ej.: logueo de teclado cuando alguien escribe su password, spoofing en red, etc.

5 Seguridad en S.Os. Confiables (4)
Auditoría Todas las acciones que tengan que ver con la seguridad deben ser registradas y almacenadas en lugares “seguros”. Reducción de Logs de Auditoría Problema con los Logs: Gigantes. La idea aquí es reducir el volumen sin perder información importante. Se suele trabajar con este log reducido y en caso de necesidad se puede recurrir al log completo. En general se utilizan herramientas especializadas para esta tarea.

6 Seguridad en S.Os. Confiables (5)
Detección de Intrusos El sw de detección de instrusos crea patrones de comportamiento normales sobre el uso del sistema y dispara alarmas frente al comportamiento anormal. Es un campo hasta ahora no muy explorado. Veremos a continuación implementaciones de seguridad en el diseño de sistemas operativos. Consideraremos tres propiedades: Diseño del Kernel (menor privilegio - economía de mecanismo). Aislamiento (extensión de menor privilegio). Estructura de Anillo (diseño abierto - mediación completa).

7 Diseño del Kernel Las funciones de más bajo nivel del S.O. se encuentran en el kernel. Los microkernels suplantaron a los kernels monolíticos en los S.Os. de los 80’s. ¿Qué es microkernel?

8 Microkernel Solamente las funciones esenciales del S.O. se encuentran en el kernel (direccionado, IPC, scheduling básico). Los otros servicios del S.O. se implementan como servers en memoria de usuario (drivers, fs, vm). Más flexibles, extensibles, portables, fáciles de implementar y debuggear, ... A un precio: performance! Why? Las llamadas a sistema se reemplazan por mensajes entre procesos...

9 Security Kernel (1) Responsable de hacer que se cumplan los mecanismos de seguridad del S.O. En general está contenido dentro del kernel del S.O. Razones (1): Cobertura: mediación completa. Separación: más fácil de proteger frente a ataques desde usuarios o incluso desde el S.O. Unidad: el código está unificado. Modificabilidad: más fácil de verificar y mantener.

10 Security Kernel (2) Razones (2):
Compacto: como solamente realiza las funciones de seguridad es pequeño. Verificable: dado que es pequeño, es fácil de analizar rigurosamente. Monitor de Referencias (1) Es la parte más importante del security kernel. Controla el acceso a los objetos.

11 Monitor de Referencias (2)
Características Tamperproof. Siempre invocado. Todos los accesos deben ser examinados. Suficientemente pequeño como para ser analizado. La certeza de correctitud decrece cuando la complejidad y tamaño aumenta. Colección de controles de acceso a: archivos, dispositivos, memoria, IPC y otros objetos.

12 Trusted Computing Base (TCB)
Es todo lo necesario en un S.O. Confiable para asegurar que se cumpla una política de seguridad. Es la parte del S.O. donde recae toda nuestra confianza acerca de la seguridad de todo el sistema.

13 Funciones de Monitoreo del TCB
Activación de Procesos: los cambios de contexto, crear y destruir procesos requiere información sensitiva. Cambio de Dominio de ejecución: procesos en un dominio pueden llamar a un proceso de otro dominio para obtener datos o servicios más confidenciales. Protección de Memoria: cada dominio tiene código y datos, por lo tanto la confidencialidad y la integridad de cada dominio es importante. Operaciones de I/O: pueden atravesar dominios y puede haber software involucrado.

14 Ventajas de Diseño del TCB
La separación del TCB de lo no-TCB es conveniente. El código TCB debe correr en un estado protegido que lo proteja. Items fuera del TCB pueden ser cambiados a voluntad: utilidades, compiladores, GUI, etc. Mediante técnicas de Separación se simplifica la evaluación de código confiable.

15 Agregando un TCB Tomar los módulos existentes del S.O.
Los módulos incluyen funciones referidas a la seguridad y otras funciones. Reunir todas las funciones que tengan que ver con la seguridad en algo llamado TCB.

16 Empezando con un TCB Diseñar primero el security kernel.
Diseñar el S.O. alrededor de él. El security kernel es una capa de interfase con el hw. Monitorea todos los accesos del S.O. al hw y realiza todas las funciones de protección. Pequeño y eficiente. Dominios: security kernel, S.O. y usuario.

17 Separación/Aislamiento
Separación física de procesos: los procesos utilizan hardware separado. Separación temporal de procesos: los procesos “confidenciales” corren en distintos momentos que el resto de los procesos. Separación criptográfica de procesos: se usa la criptografía para proteger los datos de un proceso. Separación lógica de procesos: Aislamiento: monitor de referencias separa los objetos de usuarios distintos.

18 Virtualización (1) La máquina real es emulada en una “máquina virtual”. Funcionalidad del S.O. sobre la máquina virtual. Buena protección y Aislamiento. Difícil emular hw.

19 Virtualización (2)

20 Diseño por Capas Sistemas por capas.
Una o más capas se ejecutan en modo kernel. Buena performance, modular, extensible, estructura rígida. Difícil hacer un buen diseño de capas.

21 Diseño Seguro por Capas
Ejemplos: hardware, kernel, S.O, usuario

22 Diseño por Capas Las operaciones más “sensitivas” están en los círculos más internos. Una única función lógica implementada en varios módulos es un ej. de diseño por capas. La figura muestra una función realizada por un conjunto de módulos que operan en distintas capas.

23 Control de Daños mediante Capas
La estructura jerárquica permite la identificación de las partes más críticas. Las porciones críticas pueden ser analizadas (correctitud). El aislamiento limita los efectos de los problemas y fallas.

24 Estructura de Anillos (1)
Los anillos más bajos tienen mayor privilegio. Cada proceso corre en un nivel de anillo particular. El Anillo I incluye los privilegios de todos los anillos J con J > I. Cada área de datos de procedimiento se denomina segmento.

25 Estructura de Anillos (2)
Un segmento es protegido por b1, b2 y b3, donde b1  b2  b3. Ring bracket: (b1, b2, b3). Indica grado de confianza de un segmento. Access bracket: (b1, b2) Conjunto de anillos de procesos que pueden acceder al segmento libremente. Segmentos menos confiables tienen access bracket que empieza en números más altos. Call bracket: (b2, b3) Conjunto de anillos que pueden llamar en este segmento solamente en ciertos puntos.

26 Certeza en Sistemas Confiables
El entorno afecta las necesidades, ¿es apropiado el S.O. para cierto conjunto de necesidades? Testeo Verificación Formal Validación Informal

27 Fallas Conocidas en S.O.s Típicos
Procesamiento de I/O Frecuentemente escapan a las restricciones del security kernel. Dependencias de I/O, código dependiente del hw. Ambigüedad en la Política de Acceso Acceso separado de protección/sharing de recursos. Mediación incompleta Tradeoff entre performance y mediación completa. Generalidad Cabos sueltos (pueden ser trapdoors!) que se dejan en el sistema para que sea más flexible. Nivel de privilegio para software de instalación.

28 Métodos de Confianza: Testing
Puede demostrar la existencia de una falla, pero que pase los tests no me asegura que no existan. La cantidad de posibles entradas y el gigantesco estado interno hacen que sea una tarea difícil. El testeo de efectos observables en lugar de analizar las estructuras internas no asegura completitud. El testeo basado en agregar código que haga evidente el estado interno de un producto afecta su comportamiento y luego puede ser el punto de partida de nuevas vulnerabilidades.

29 Técnicas de Testing Funcional Unidad Integridad Regresión
Cobertura (Ingeniería del SW) Penetración o Tiger teams: expertos tratan de “hackear” el S.O o sistema. si un sistema resiste este tipo de ataques no quiere decir que esté libre de errores.

30 Verificación Formal Un S.O. se reduce a un teorema que debe ser probado: Tarea formidable. Meses o años de esfuerzo. Los probadores de teoremas pueden ayudar, pero la mayor parte del trabajo requiere esfuerzo humano. Temas a considerar: La verificación lleva más tiempo que escribir el propio algoritmo del producto. Las verificaciones llevan muchísimo tiempo. Es un proceso muy complejo: en ciertos sistemas no vale la pena ni intentarlo.

31 Validación Más general que la Verificación.
Incluye verificación pero también puede consistir en: Chequeo de requerimientos. Revisión de diseño y de código. Testing de módulo y de sistema.

32 Criterios de Evaluación
El US DoD publicó a fines de los 70’s un conjunto de standards informalmente llamado Orange Book por el color de la tapa. El nombre real es Trusted Computer System Evaluation Criteria o abreviado: TCSEC. 4 divisiones básicas: A, B, C, D. A es el nivel más seguro. Hay subcategorías a partir de estas divisiones: D, C1, C2, B1, B2, B3, A1.

33 Clases de Seguridad (1) Clase D: Protección mínima – sin características de seguridad (falló en las pruebas). Clase C1: Protección de Seguridad Discreta Usuarios al mismo nivel. Separación entre usuarios y sus datos. Limitación de acceso de algún tipo. Keyword discreta: El usuario decide cuando se aplican controles y puede definir individuos y grupos de acceso.

34 Clases de Seguridad (2) Clase C2: Protección de Acceso Controlado
Sigue implementando keyword discreta pero con controles más finos: usuario = 1 individuo. Debe ser posible auditar todos los accesos de un individuo a un objeto. Clase B

35 Clases de Seguridad (3) Todo el nivel B incluye control de acceso no discreto. Clase B1: Protección de Seguridad Etiquetada Los objetos deben ser etiquetados (asignados) a un dado nivel de seguridad. Debe basarse en niveles jerárquicos y no jerárquicos. El control MAC sigue el modelo Bell-La Padula. Debe implementar DAC para mayor control de acceso. Clase B2

36 Clases de Seguridad (4) Clase B2: Protección Estructurada
El diseño y la implementación de B2 debe habilitar testeo y revisión más exhaustivos. Se debe presentar un nivel superior verificable. El testing debe confirmar que el sistema implementa el diseño. El principio de menor privilegio deber ser incluido en el diseño. El control de acceso debe ser aplicado a objetos, individuos y dispositivos. Se requiere análisis de covert channels.

37 Clases de Seguridad (5) Clase B3: Dominios de Seguridad
Se debe contar con diseño de alto nivel: completo y conceptualmente simple (testing extensivo). Debe existir un argumento fuerte que demuestre que el sistema implementa el diseño. La implementación debe utilizar: capas, abstracción y ocultamiento de información. Funciones de seguridad a prueba de interferencias. Sistema altamente resistente a tiger teams. Auditoría: requerida y debe identificar violaciones de seguridad inminentes.

38 Clases de Seguridad (6) Clase A1: Diseño Verificado Incluye:
Diseño formalmente verificado. Mismas capacidades que B3. Incluye: Prueba de consistencia y debe ser adecuado. Especificación formal de alto nivel del sistema de protección. Demostración de que esta especificación corresponde al modelo. Una implementación “informal” muestra ser consistente con la especificación. Análisis formal de covert channels.

39 Otros Criterios de Evaluación
Europa: ITSEC (Information Technology Security Evaluation Criteria). TCSEC se actualizó (1993) en respuesta al NIST y a la NSA y se creó el Combined General Criteria. Introduce: Profile de Protección: detalla las necesidades de protección. Seguridad de Objetivo: crea el producto que debe concordar con el profile. Common Criteria para todo el mundo a partir de estos dos criterios anteriores más proyecto canadiense.

40 Profile de Prot. & Seguridad de Objetivo

41 Resumen de Criterios de Evaluación
¿Hay un desarrollo exitoso de Criterios de Evaluación? No se sabe. El ámbito comercial no está utilizando productos “confiables”. Algunos vendedores se quedan con evaluaciones de escaso vuelo. El mercado, y no un documento de criterios, será quien dicte que es lo que realmente se desea.

42 JAVIER ECHAIZ Coming Next! Seguridad en B.D.