Seguridad en S.Os. Confiables

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 80s.
• 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 gt 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 70s 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
• 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.