La seguridad multinivel o niveles múltiples de seguridad ( MLS ) es la aplicación de un sistema informático para procesar información con clasificaciones incompatibles (es decir, en diferentes niveles de seguridad), permitir el acceso a usuarios con diferentes autorizaciones de seguridad y necesidades de conocimiento , y evitar que los usuarios obtengan acceso a información para la que no están autorizados. Existen dos contextos para el uso de la seguridad multinivel.
Esta distinción es importante porque los sistemas en los que se necesita confiar no necesariamente son confiables.
Un entorno operativo MLS a menudo requiere un sistema de procesamiento de información altamente confiable, a menudo construido sobre un sistema operativo (OS) MLS, pero no necesariamente. La mayoría de las funciones MLS pueden ser soportadas por un sistema compuesto enteramente de computadoras no confiables, aunque requiere múltiples computadoras independientes vinculadas por canales de seguridad de hardware (ver sección B.6.2 de la Interpretación de Red Confiable, NCSC-TG-005). Un ejemplo de MLS forzado por hardware es el aislamiento asimétrico . [1] Si una computadora se está utilizando en modo MLS, entonces esa computadora debe utilizar un sistema operativo (OS) confiable. Debido a que toda la información en un entorno MLS es accesible físicamente por el SO, deben existir fuertes controles lógicos para asegurar que el acceso a la información esté estrictamente controlado. Por lo general, esto implica un control de acceso obligatorio que utiliza etiquetas de seguridad, como el modelo Bell-LaPadula .
Los clientes que implementan sistemas operativos confiables generalmente requieren que el producto complete una evaluación formal de seguridad informática. La evaluación es más estricta para un rango de seguridad más amplio, que son los niveles de clasificación más bajos y más altos que el sistema puede procesar. Los Criterios de evaluación de sistemas informáticos confiables (TCSEC) fueron los primeros criterios de evaluación desarrollados para evaluar MLS en sistemas informáticos. Bajo esos criterios, había una correlación uniforme clara [2] entre los requisitos de seguridad y la amplitud del rango de seguridad de MLS. Históricamente, pocas implementaciones han sido certificadas como capaces de procesar MLS con un rango de seguridad desde No clasificado hasta Alto secreto. Entre ellas se encontraban SCOMP de Honeywell , SACDIN de la USAF , Blacker de la NSA y MLS LAN de Boeing , todas bajo TCSEC, de la década de 1980 y basadas en Intel 80386. Actualmente, los productos MLS se evalúan según los Criterios comunes . A fines de 2008, el primer sistema operativo (más abajo) fue certificado con un alto nivel de garantía evaluado: Nivel de garantía de evaluación (EAL) - EAL 6+ / Alta robustez, bajo los auspicios de un programa del gobierno de los EE. UU. que requiere seguridad de múltiples niveles en un entorno de alta amenaza. Si bien este nivel de garantía tiene muchas similitudes con el del antiguo Libro Naranja A1 (como los métodos formales), los requisitos funcionales se centran en políticas fundamentales de aislamiento y flujo de información en lugar de políticas de nivel superior como Bell-La Padula. Debido a que los Criterios comunes desacoplaron la combinación de garantía (EAL) y funcionalidad (Perfil de protección) de TCSEC, la correlación uniforme clara entre los requisitos de seguridad y la capacidad de rango de seguridad MLS documentada en CSC-STD-004-85 se perdió en gran medida cuando los Criterios comunes reemplazaron a la Serie Rainbow .
Los sistemas operativos de libre acceso con algunas características que admiten MLS incluyen Linux con la característica Security-Enhanced Linux habilitada y FreeBSD . [3] En algún momento se pensó que la evaluación de seguridad era un problema para estas implementaciones MLS gratuitas por tres razones:
A pesar de tales suposiciones, Red Hat Enterprise Linux 5 fue certificado contra LSPP, RBACPP y CAPP en EAL4+ en junio de 2007. [4] Utiliza Security-Enhanced Linux para implementar MLS y fue la primera certificación Common Criteria en aplicar las propiedades de seguridad TOE con Security-Enhanced Linux.
Las estrategias de certificación de proveedores pueden ser engañosas para los profanos. Una estrategia común explota el énfasis excesivo de los profanos en el nivel EAL con una certificación excesiva, como certificar un perfil de protección EAL 3 (como CAPP) [5] a niveles superiores, como EAL 4 o EAL 5. Otra es agregar y certificar funciones de soporte MLS (como el perfil de protección de control de acceso basado en roles (RBACPP) y el perfil de protección de seguridad etiquetado (LSPP)) a un núcleo que no se evalúa como un perfil de protección compatible con MLS. Esos tipos de funciones son servicios que se ejecutan en el núcleo y dependen del núcleo para protegerlos de la corrupción y la subversión. Si el núcleo no se evalúa como un perfil de protección compatible con MLS, no se puede confiar en las funciones MLS, independientemente de lo impresionante que parezca la demostración. Es particularmente digno de mención que CAPP específicamente no es un perfil compatible con MLS, ya que excluye específicamente las capacidades de autoprotección críticas para MLS.
General Dynamics ofrece PitBull, un sistema operativo MLS confiable. PitBull se ofrece actualmente solo como una versión mejorada de Red Hat Enterprise Linux , pero existían versiones anteriores para Sun Microsystems Solaris, IBM AIX y SVR4 Unix. PitBull proporciona un mecanismo de seguridad Bell LaPadula , un mecanismo de integridad Biba , un reemplazo de privilegios para superusuario y muchas otras características. PitBull tiene la base de seguridad para el producto Trusted Network Environment (TNE) de General Dynamics desde 2009. TNE permite el intercambio y acceso de información de múltiples niveles para los usuarios en las comunidades del Departamento de Defensa e Inteligencia que operan en diferentes niveles de clasificación. También es la base para el entorno de intercambio de coalición de múltiples niveles, Battlefield Information Collection and Exploitation Systems Extended [6] (BICES-X).
Sun Microsystems , ahora Oracle Corporation , ofrece Solaris Trusted Extensions como una característica integrada de los sistemas operativos comerciales Solaris y OpenSolaris . Además de los perfiles de protección de acceso controlado (CAPP) y control de acceso basado en roles (RBAC), Trusted Extensions también ha sido certificado en EAL4 para el perfil de protección de seguridad etiquetado (LSPP). [7] El objetivo de seguridad incluye tanto la funcionalidad de escritorio como de red. LSPP exige que los usuarios no estén autorizados a anular las políticas de etiquetado aplicadas por el núcleo y X Window System (servidor X11). La evaluación no incluye un análisis de canal encubierto . Debido a que estas certificaciones dependen de CAPP, ninguna certificación de Common Criteria sugiere que este producto sea confiable para MLS.
BAE Systems ofrece XTS-400 , un sistema comercial que admite MLS con lo que el proveedor afirma que es "alta seguridad". Los productos predecesores (incluido el XTS-300) se evaluaron en el nivel TCSEC B3, que es compatible con MLS. El XTS-400 se ha evaluado según los criterios comunes en EAL5+ frente a los perfiles de protección CAPP y LSPP. CAPP y LSPP son perfiles de protección EAL3 que no son inherentemente compatibles con MLS, pero el objetivo de seguridad [8] para la evaluación de criterios comunes de este producto contiene un conjunto enriquecido de funciones de seguridad que proporcionan capacidad MLS.
La desinfección es un área problemática para los sistemas MLS. Los sistemas que implementan restricciones MLS, como las definidas por el modelo Bell-LaPadula , solo permiten compartir cuando es obvio que no violan las restricciones de seguridad. Los usuarios con autorizaciones inferiores pueden compartir fácilmente su trabajo con usuarios que tienen autorizaciones superiores, pero no al revés. No existe un mecanismo eficiente y confiable mediante el cual un usuario de alto secreto pueda editar un archivo de alto secreto, eliminar toda la información de alto secreto y luego entregársela a usuarios con autorizaciones secretas o inferiores. En la práctica, los sistemas MLS evitan este problema mediante funciones privilegiadas que permiten a un usuario confiable eludir el mecanismo MLS y cambiar la clasificación de seguridad de un archivo. Sin embargo, la técnica no es confiable .
Los canales encubiertos plantean otro problema para los sistemas MLS. Para que un sistema MLS mantenga secretos a la perfección, no debe haber forma posible de que un proceso de alto secreto transmita señales de ningún tipo a un proceso secreto o de nivel inferior. Esto incluye efectos secundarios como cambios en la memoria o el espacio en disco disponibles, o cambios en la sincronización del proceso. Cuando un proceso explota un efecto secundario de este tipo para transmitir datos, está explotando un canal encubierto. Es extremadamente difícil cerrar todos los canales encubiertos en un sistema informático práctico, y puede resultar imposible en la práctica. El proceso de identificación de todos los canales encubiertos es un desafío en sí mismo. La mayoría de los sistemas MLS disponibles comercialmente no intentan cerrar todos los canales encubiertos, aunque esto hace que sea poco práctico utilizarlos en aplicaciones de alta seguridad.
La omisión es problemática cuando se introduce como un medio para tratar un objeto de alto nivel del sistema como si fuera de confianza de MLS. Un ejemplo común es extraer datos de un objeto secreto de alto nivel del sistema para enviarlos a un destino no clasificado, citando alguna propiedad de los datos como evidencia confiable de que "realmente" no están clasificados (por ejemplo, formato "estricto"). No se puede confiar en que un sistema de alto nivel del sistema conserve ninguna evidencia confiable, y el resultado es que se abre una ruta de datos abierta sin una forma lógica de mediarla de manera segura. La omisión puede ser riesgosa porque, a diferencia de los canales encubiertos de ancho de banda estrecho que son difíciles de explotar, la omisión puede presentar una fuga abierta grande y fácilmente explotable en el sistema. La omisión a menudo surge de la falla en el uso de entornos operativos confiables para mantener una separación continua de los dominios de seguridad hasta su origen. Cuando ese origen se encuentra fuera del límite del sistema, puede que no sea posible validar la separación confiable hasta el origen. En ese caso, el riesgo de omisión puede ser inevitable si el flujo es verdaderamente esencial.
Un ejemplo común de omisión inevitable es un sistema sujeto que debe aceptar paquetes IP secretos de una fuente no confiable, cifrar los datos de usuario secretos y no el encabezado y depositar el resultado en una red no confiable. La fuente se encuentra fuera de la esfera de influencia del sistema sujeto. Aunque la fuente no es confiable (por ejemplo, sistema alto), se confía en ella como si fuera MLS porque proporciona paquetes que tienen encabezados no clasificados y datos de usuario de texto sin formato secretos, una construcción de datos MLS. Dado que la fuente no es confiable, podría estar corrupta y colocar secretos en el encabezado del paquete no clasificado. Los encabezados de paquete corruptos podrían no tener sentido, pero es imposible para el sistema sujeto determinarlo con una confiabilidad razonable. Los datos de usuario del paquete están bien protegidos criptográficamente, pero el encabezado del paquete puede contener secretos legibles. Si el sistema sujeto pasa los paquetes corruptos a una red no confiable, es posible que no se puedan enrutar, pero algún proceso corrupto cooperador en la red podría capturar los paquetes y reconocerlos y el sistema sujeto podría no detectar la fuga. Puede tratarse de una fuga manifiesta de gran magnitud que es difícil de detectar. Considerar los paquetes clasificados con encabezados no clasificados como estructuras de alto nivel del sistema en lugar de las estructuras MLS que son en realidad representa una amenaza muy común pero grave.
La mayoría de los casos de omisión son evitables. Los casos de omisión evitables suelen darse cuando los arquitectos de sistemas diseñan un sistema antes de considerar correctamente la seguridad y luego intentan aplicar la seguridad después del hecho como funciones adicionales. En esa situación, la omisión parece ser la única manera (fácil) de hacer que el sistema funcione. Se proponen (¡y se aprueban!) algunos esquemas pseudoseguros que examinan el contenido de los datos omitidos en un vano intento de establecer que los datos omitidos no contienen secretos. Esto no es posible sin confiar en algo sobre los datos, como su formato, lo que es contrario a la suposición de que no se confía en que la fuente preserve ninguna característica de los datos de origen. La "omisión segura" asegurada es un mito, al igual que la llamada Guardia de Alta Seguridad (HAG) que implementa la omisión de forma transparente. El riesgo que esto introduce se ha reconocido desde hace mucho tiempo; las soluciones existentes son en última instancia procedimentales, en lugar de técnicas. No hay forma de saber con certeza cuánta información clasificada se extrae de nuestros sistemas mediante la explotación de la omisión.
Algunos profanos están diseñando sistemas informáticos seguros y están llegando a la conclusión de que MLS no existe. Una explicación podría ser que hay una disminución de expertos en COMPUSEC [9] y el término MLS se ha visto sobrecargado por dos significados/usos diferentes. Estos dos usos son: MLS como entorno de procesamiento vs. MLS como capacidad. La creencia de que MLS no existe se basa en la creencia de que no hay productos certificados para operar en un entorno o modo MLS y que, por lo tanto, MLS como capacidad no existe. Una cosa no implica la otra. Muchos sistemas operan en un entorno que contiene datos que tienen niveles de seguridad desiguales y, por lo tanto, es MLS según el Teorema del valor intermedio de seguridad informática (CS-IVT). [10] La consecuencia de esta confusión es más profunda. Los sistemas operativos, bases de datos y redes MLS certificados por la NSA han existido en modo operativo desde la década de 1970 y los productos MLS continúan construyéndose, comercializándose e implementándose.
Los profanos suelen concluir que admitir que un sistema funciona en un entorno MLS (el significado de MLS centrado en el entorno) es como si se estuviera arrinconando a la percepción de que se tiene un problema sin una solución MLS (el significado de MLS centrado en la capacidad). El MLS es engañosamente complejo y el hecho de que las soluciones simples no sean obvias no justifica la conclusión de que no existen. Esto puede llevar a una ignorancia paralizante sobre COMPUSEC que se manifiesta en rumores de que "no se puede hablar de MLS" y "no existe tal cosa como MLS". Estos esquemas de negación de MLS cambian tan rápidamente que no se pueden abordar. En cambio, es importante aclarar la distinción entre el entorno MLS y la capacidad MLS.
El uso original del término MLS se aplicaba al entorno o modo de seguridad. Una solución a esta confusión es conservar la definición original de MLS y ser específico en cuanto a la capacidad de MLS cuando se utiliza ese contexto.
Multiple Independent Levels of Security (MILS) es una arquitectura que aborda el componente de separación de dominios de MLS. Cabe señalar que UCDMO (el líder del gobierno de los EE. UU. en sistemas multidominio y multinivel) creó el término Acceso a Dominios Cruzados como categoría en su línea base de sistemas acreditados por el Departamento de Defensa y la Comunidad de Inteligencia , y esta categoría puede considerarse esencialmente análoga a MILS.
Los modelos de seguridad como el modelo Biba (para la integridad) y el modelo Bell-LaPadula (para la confidencialidad) permiten un flujo unidireccional entre ciertos dominios de seguridad que, de otro modo, se supone que están aislados. MILS aborda el aislamiento subyacente a MLS sin abordar la interacción controlada entre los dominios abordados por los modelos anteriores. Los canales confiables que cumplen con las normas de seguridad mencionados anteriormente pueden vincular dominios MILS para admitir más funciones de MLS.
El enfoque MILS sigue una estrategia caracterizada por un término más antiguo, MSL ( multiple single level ), que aísla cada nivel de información dentro de su propio entorno de un solo nivel ( System High ).
La comunicación y el aislamiento de procesos rígidos que ofrece MILS pueden resultar más útiles para aplicaciones de software de confiabilidad ultraalta que MLS. En particular, MILS no aborda la estructura jerárquica que se materializa en la noción de niveles de seguridad. Esto requiere la adición de aplicaciones de importación/exportación específicas entre dominios, cada uno de los cuales debe estar acreditado adecuadamente. Por lo tanto, MILS podría denominarse mejor Múltiples Dominios Independientes de Seguridad (la emulación de MLS en MILS requeriría un conjunto similar de aplicaciones acreditadas para las aplicaciones MLS). Al negarse a abordar la interacción inmediata entre niveles coherente con las relaciones jerárquicas de Bell-La Padula, MILS es (casi engañosamente) simple de implementar inicialmente, pero necesita aplicaciones de importación/exportación complementarias no triviales para lograr la riqueza y flexibilidad esperadas por las aplicaciones MLS prácticas.
En cualquier comparación entre MILS y MLS se debe tener en cuenta si es más factible la acreditación de un conjunto de solicitudes de exportación más sencillas que la acreditación de un núcleo MLS más complejo. Esta cuestión depende en parte del alcance de las interacciones de importación y exportación que requieran las partes interesadas. A favor de MILS está la posibilidad de que no todas las solicitudes de exportación requieran la máxima garantía.
Existe otra forma de resolver este tipo de problemas, conocida como multinivel . Cada nivel de seguridad está aislado en un dominio independiente que no es de confianza. La ausencia de un medio de comunicación entre los dominios garantiza que no sea posible ninguna interacción. El mecanismo para este aislamiento suele ser la separación física en equipos separados. Esto se utiliza a menudo para dar soporte a aplicaciones o sistemas operativos que no tienen posibilidad de soportar MLS, como Microsoft Windows .
La infraestructura, como los sistemas operativos confiables, es un componente importante de los sistemas MLS, pero para cumplir con los criterios requeridos según la definición de MLS de CNSSI 4009 (parafraseada al comienzo de este artículo), el sistema debe proporcionar una interfaz de usuario que sea capaz de permitir que un usuario acceda y procese contenido en múltiples niveles de clasificación desde un sistema. La UCDMO llevó a cabo un tema específicamente enfocado en MLS en el Simposio de Seguridad de la Información de la NSA en 2009, en el que destacó varios sistemas MLS acreditados (en producción) y emergentes. Nótese el uso de MLS en SELinux . [11]
Existen varias bases de datos clasificadas como sistemas MLS. Oracle tiene un producto llamado Oracle Label Security (OLS) que implementa controles de acceso obligatorios , generalmente agregando una columna de "etiqueta" a cada tabla en una base de datos Oracle . OLS se está implementando en el INSCOM del ejército de los EE. UU. como la base de una base de datos de inteligencia de "todas las fuentes" que abarca las redes JWICS y SIPRNet . Existe un proyecto para crear una versión etiquetada de PostgreSQL, y también existen implementaciones de bases de datos etiquetadas más antiguas, como Trusted Rubix. Estos sistemas de bases de datos MLS brindan un sistema de back-end unificado para contenido que abarca múltiples etiquetas, pero no resuelven el desafío de que los usuarios procesen contenido en múltiples niveles de seguridad en un sistema mientras se aplican controles de acceso obligatorios.
También hay varias aplicaciones de usuario final MLS. La otra capacidad MLS actualmente en la línea base UCDMO se llama MLChat Archivado el 17 de marzo de 2013 en Wayback Machine , y es un servidor de chat que se ejecuta en el sistema operativo XTS-400 , fue creado por el Laboratorio de Investigación Naval de los EE. UU . Dado que el contenido de los usuarios en diferentes dominios pasa a través del servidor MLChat, se utiliza el escaneo de palabras sucias para proteger el contenido clasificado, y ha habido cierto debate sobre si este es realmente un sistema MLS o más bien una forma de protección de datos de transferencia entre dominios . Los controles de acceso obligatorios se mantienen mediante una combinación de XTS-400 y mecanismos específicos de la aplicación. [12]
El Joint Cross Domain eXchange (JCDX) es otro ejemplo de una capacidad MLS que actualmente se encuentra en la línea base UCDMO [ enlace muerto permanente ] . JCDX es el único sistema de Comando, Control, Comunicación, Computadoras e Inteligencia (C4I) de Seguridad Multinivel (MLS) acreditado por el Departamento de Defensa (DoD) y la Agencia de Inteligencia de Defensa (DIA) que proporciona inteligencia y soporte de alerta casi en tiempo real a comandantes tácticos desplegados en el teatro de operaciones y en el frente. La arquitectura JCDX está completamente integrada con un sistema operativo seguro de Nivel Cuatro de Protección (PL4) de alta seguridad, que utiliza el etiquetado de datos para difundir información de datos casi en tiempo real sobre las actividades de la fuerza y las amenazas terroristas potenciales en los océanos del mundo y sus alrededores. Está instalado en ubicaciones en Estados Unidos y países aliados donde es capaz de proporcionar datos desde niveles de Alto Secreto/SCI hasta niveles Secretos Divulgables, todo en una única plataforma.
Las aplicaciones MLS que actualmente no forman parte de la línea base de UCDMO incluyen varias aplicaciones de BlueSpace . BlueSpace tiene varias aplicaciones MLS, incluido un cliente de correo electrónico MLS, una aplicación de búsqueda MLS y un sistema C2 MLS. BlueSpace aprovecha una estrategia de middleware para permitir que sus aplicaciones sean neutrales en cuanto a la plataforma, orquestando una interfaz de usuario en múltiples instancias del sistema operativo Windows ( sesiones de terminal remotas o virtualizadas ). El Laboratorio de Investigación Naval de los EE. UU. también ha implementado un marco de aplicación web multinivel llamado MLWeb que integra el marco Ruby on Rails con una base de datos multinivel basada en SQLite3 .
Tal vez el mayor cambio que se está produciendo en el ámbito de la seguridad multinivel en la actualidad es la convergencia de MLS con la virtualización. Un número cada vez mayor de sistemas operativos de confianza están dejando de lado el etiquetado de archivos y procesos y, en su lugar, están avanzando hacia los contenedores UNIX o las máquinas virtuales . Algunos ejemplos son las zonas de Solaris 10 TX y el hipervisor de celdas acolchadas de sistemas como la plataforma Integrity de Green Hill y XenClient XT de Citrix. La High Assurance Platform de NSA , tal como se implementó en el Trusted Virtualization Environment (TVE) de General Dynamics , es otro ejemplo: utiliza SELinux en su núcleo y puede admitir aplicaciones MLS que abarcan varios dominios.
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )La política de referencia de SELinux [...] La seguridad multinivel (MLS) agrega un método de acceso de seguridad más refinado. MLS agrega un valor de nivel de seguridad a los recursos.
{{cite journal}}: Se requiere citar una revista |journal=( ayuda ) (también conocido como TCSEC o "Libro Naranja").{{cite journal}}: Se requiere citar una revista |journal=( ayuda ) (también conocida como TNI o "Libro Rojo"). [1]{{cite journal}}: Requiere citar revista |journal=( ayuda )CS1 maint: multiple names: authors list (link)