seguridad en s.os. confiables

1

Seguridad en Sistemas: Seguridad en Sistemas Operativos (3)

Seguridad en S.Os. ConfiablesSeguridad en S.Os. ConfiablesEl 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)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



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



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



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)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 KernelDiseñ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


MicrokernelMicrokernel

• 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)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)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)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)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 TCBFunciones 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 TCBVentajas 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 TCBAgregando 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 TCBEmpezando 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/AislamientoSeparació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)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)Virtualización (2)

20


Diseño por CapasDiseñ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 CapasDiseño Seguro por Capas

Ejemplos:

hardware,

kernel,

S.O,

usuario

22


Diseño por CapasDiseñ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 CapasControl 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)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)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 ConfiablesCerteza 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ípicosFallas 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: TestingMé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 TestingTé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 FormalVerificació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ónValidació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ónCriterios 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)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



• 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



• 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)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



• 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



• Clase A1: Diseño Verificado

• 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ónOtros 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 ObjetivoProfile de Prot. & Seguridad de Objetivo

41


Resumen de Criterios de EvaluaciónResumen 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.

Coming Next!Coming Next!

• Seguridad en B.D.Seguridad en B.D.

JAVIERECHAIZ

seguridad en s.os. confiables

Documents