Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Diseño de Sistemas Operativos Confiables
Los Sistemas Operativos proveen multiprogramación, se
comparten recursos, etc. que aseguran restricciones
sobre el comportamiento de los programas. Debido a
este “poder” de los S.O.s, ellos también son objetivos de
ataque.
.
1
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
¿Qué es un S.O. Confiable? (1)
La palabra seguro es binaria: algo es seguro o no. Si algo
es seguro debe resistir ataques hoy, mañana y siempre.
Por eso en general en seguridad se habla de sistemas
confiables en lugar de hablar de seguros.
Un Sistema Operativo Confiable cumple con ciertos
requisitos de seguridad que justifican su confianza.
2
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
¿Qué es un S.O. Confiable? (2)
Por supuesto existen diferentes grados de confianza:
secretos que les puedo contar a ciertas personas.
La confianza se basa en la evidencia y en la experiencia.
Ej: préstamos en bancos.
Seguro
Confiable
• Si-No: es o no es seguro
• Grados: grados de confianza
• Aserción: basado en el producto
• Juzgado: basado en evidencia y análisis.
• Absoluto: no importa el como,
• Relativo: visto en el contexto de su uso.
cuando, donde o quien lo usa.
• Un objetivo.
• Una característica.
3
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
¿Qué es un S.O. Confiable? (3)
Existen 3 conceptos relacionados con la confianza:
• Política de Seguridad.
• Medidas y mecanismos.
• Evaluación.
4
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Políticas de Seguridad
Una Política define la seguridad que esperamos que el
sistema asegure. Un S.O. solamente será confiable en
relación a la política de seguridad que le compete, i.e., la
seguridad que se espera que mantenga.
Política de Seguridad Militar (1)
Esta basada en proteger información secreta. Cada porción
de información es “rankeada”: no clasificada, restringida,
confidencial, secreta, o super secreta (top secret).
La información se accede según la regla: need-to-know.
5
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Políticas de Seguridad Militar (2)
La info. puede ser asociada a uno o más proyectos:
compartimentos.
Ayudan a asegurar la regla need-to-know.
Toda información se accede entonces según:
<rango, compartimiento>
que dará acceso según la
relación dominance.
La seguridad militar utiliza requerimientos de:
• “sensibilidad” (jerárquico)
• need-to-know (no-jerárquico)
6
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Políticas de Seguridad Comercial (1)
El mundo comercial está estructurado de forma menos rígida
y menos jerárquica. Pero muchos conceptos de la política de
seguridad militar siguen siendo válidos.
Una Universidad puede dividirse en Departamentos y cada
Departamento es responsable de cierto número de proyectos
disjuntos. Pero también existen responsabilidades a nivel
Universidad, p. ej.: personal. Las responsabilidades a nivel
corporativo suelen solaparse con las de sus divisiones, ej:
departamentos que necesitan info. acerca de su personal.
Diferencias con la política militar?
7
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Políticas de Seguridad Comercial (2)
Política de Seguridad Comercial Clark-Wilson
Integridad sobre confidencialidad.
El objetivo es mantener la consistencia entre los datos
internos y lo que esperan los usuarios externos de esos
datos.
Separación de Responsabilidades
Ejemplo de comercio. Fácil de implementar a partir del
anterior si se especifica en la política como un
requerimiento.
8
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Políticas de Seguridad Comercial (2)
Política de Seguridad de la Muralla China (Chinese Wall)
Protección de acceso a la información.
Confidencialidad sobre Integridad.
3 niveles de abstracción:
• Objetos.
• Grupos.
• Clases de Conflictos.
Una persona accede a cualquier información mientras nunca
haya accedido a información de una compañía distinta en la
misma clase de conflictos.
9
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Modelos de Seguridad
En seguridad los modelos se usan para:
• verificar que una política sea completa y consistente
• documentar una política
• ayuda a conceptualizar y diseñar una implementación
• verificar si una implementación cumple con sus
requerimientos.
Asumiremos que existe una política de control de acceso que
decide si un usuario puede acceder a un objeto. Esta política
es también independiente del modelo.
10
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Seguridad Multinivel (1)
La idea es crear modelos capaces de representar
adecuadamente distintos niveles de seguridad que se ajustarán
a personas y objetos.
Modelo Lattice (Seguridad de Acceso)
Modelo a partir de la política de seguridad militar.
Lattice es una estructura matemática de elementos ordenados
según un orden parcial.
Representación natural de grados en forma creciente.
11
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Seguridad Multinivel (2)
Bell-La Padula (Modelo de Confidencialidad)
Descripción formal sobre los caminos del flujo de
información en un sistema seguro. El objetivo del modelo es
identificar caminos de comunicación donde es importante
mantener la confidencialidad. Se suele usar donde se accede a
datos en forma concurrente en distintos niveles de una organización. Es una formalización de la política de seguridad
militar.
US DoD…
12
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Seguridad Multinivel (3)
Biba (Modelo de Integridad)
En ciertos ambientes es importante mantener la integridad y
no el secreto. Este modelo es el dual del modelo Bell-La
Padula. Biba define niveles de integridad análogos a los
niveles de “sensibilidad”del modelo antes visto. Por lo tanto
este nuevo modelo no se hará cargo de la confidencialidad.
Modelos que prueban limitaciones teóricas
NO
13
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Diseño de un Sistema Operativo Confiable
Elementos
• Menor privilegio.
• Economía de mecanismo.
• Diseño abierto (open).
• Mediación completa.
• Basado en permisos.
• Separación de privilegio.
• Mecanismo menos conocido.
• Fácil de utilizar.
14
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Seguridad en S.O.s Convencionales
Funciones relativas a la Seguridad
• Autentificación de usuarios.
• Protección de memoria.
• Control de acceso a archivos y a I/O en gral.
• Asignación y control de acceso a objetos generales.
• Sharing controlado.
• Servicio “justo”.
• IPC y sincronicación.
• Protección de datos de protección del S.O.
15
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Seguridad en S.O.s Confiables
El diseño es delicado.
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.
16
Seguridad en Sistemas: Seguridad en Sistemas Operativos (2)
Sigue...
Temas Pendientes
• Diseño del kernel.
• Separación/Aislamiento.
• Virtualización (brevemente).
• Diseño por capas.
• Seguridad en un Sistema Operativo Confiable.
• Evaluación.
• Algunos ejemplos de implementación.
17
Descargar

Document