Seguridad multinivel

La seguridad multinivel o seguridad de múltiples niveles ( MLS , por sus siglas en inglés) 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 , e impedir 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. Un contexto se refiere a un sistema que es capaz de protegerse de la subversión y que cuenta con mecanismos robustos para separar los dominios de información; es decir, un sistema confiable. El otro contexto se refiere a una aplicación informática que requiere que la computadora sea lo suficientemente robusta para protegerse de la subversión y que cuente con mecanismos adecuados para separar los dominios de información; es decir, un sistema en el que debemos confiar. Esta distinción es importante porque los sistemas que requieren confianza no son necesariamente confiables.

Un entorno operativo MLS a menudo requiere un sistema de procesamiento de información altamente confiable, generalmente basado en un sistema operativo (SO) MLS, pero no necesariamente. La mayor parte de la funcionalidad MLS puede ser soportada por un sistema compuesto enteramente por computadoras no confiables, aunque requiere múltiples computadoras independientes conectadas por canales que cumplan con la seguridad de hardware (ver sección B.6.2 de la Interpretación de Red Confiable, NCSC-TG-005 ). Un ejemplo de MLS reforzado por hardware es el aislamiento asimétrico . ^{[ 1 ]} Si una computadora se está utilizando en modo MLS, entonces esa computadora debe usar un sistema operativo confiable. Debido a que toda la información en un entorno MLS es físicamente accesible por el SO, deben existir controles lógicos fuertes para garantizar 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 clara correspondencia uniforme ^{[ 2 ]} entre los requisitos de seguridad y la amplitud del rango de seguridad de MLS. Históricamente, pocas implementaciones han sido certificadas capaces de procesar MLS con un rango de seguridad desde No clasificado hasta Alto Secreto. Entre ellas estaban SCOMP de Honeywell , SACDIN de la USAF , Blacker de la NSA y MLS LAN de Boeing , todos bajo TCSEC, de la década de 1980 y basados ​​en Intel 80386. Actualmente, los productos MLS se evalúan bajo los Criterios Comunes . A finales 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 EE. UU. que requería seguridad multinivel 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 el emparejamiento de garantía (EAL) y funcionalidad (Perfil de Protección) de TCSEC, el mapeo uniforme claro entre los requisitos de seguridad y la capacidad del rango de seguridad MLS documentado en CSC-STD-004-85 se ha perdido en gran medida cuando los Criterios Comunes reemplazaron la Serie Rainbow .

Los sistemas operativos de libre acceso con algunas características que admiten MLS incluyen Linux con la función Security-Enhanced Linux habilitada y FreeBSD . ^{[ 3 ]} En el pasado se pensó que la evaluación de seguridad era un problema para estas implementaciones gratuitas de MLS por tres razones:

1. Siempre es muy difícil implementar una estrategia de autoprotección del núcleo con la precisión necesaria para la confianza en MLS, y estos ejemplos no fueron diseñados ni certificados para un perfil de protección MLS, por lo que es posible que no ofrezcan la autoprotección necesaria para admitir MLS.
2. Aparte de los niveles EAL, los Criterios Comunes carecen de un inventario de perfiles de protección de alta seguridad adecuados que especifiquen la robustez necesaria para operar en modo MLS.
3. Incluso si se cumplieran (1) y (2), el proceso de evaluación es muy costoso e impone restricciones especiales al control de configuración del software evaluado.

A pesar de tales suposiciones, Red Hat Enterprise Linux 5 fue certificado según LSPP, RBACPP y CAPP en EAL4+ en junio de 2007. ^{[ 4 ]} Utiliza Security-Enhanced Linux para implementar MLS y fue la primera certificación de Common Criteria en aplicar propiedades de seguridad TOE con Security-Enhanced Linux.

Las estrategias de certificación de proveedores pueden resultar engañosas para los usuarios no expertos. Una estrategia común se basa en la excesiva importancia que se le da al nivel EAL mediante la sobrecertificación, como certificar un perfil de protección EAL 3 (como CAPP) ^{[ 5 ]} a niveles superiores, como EAL 4 o EAL 5. Otra estrategia consiste en añadir y certificar características 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 ha evaluado con un perfil de protección compatible con MLS. Este tipo de características son servicios que se ejecutan en el núcleo y dependen de él para protegerse de la corrupción y la subversión. Si el núcleo no se ha evaluado con un perfil de protección compatible con MLS, no se puede confiar en las características MLS, por muy impresionante que parezca la demostración. Es especialmente relevante que CAPP no sea 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. Actualmente, PitBull solo se ofrece 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 ha sido la base de seguridad del producto Trusted Network Environment (TNE) de General Dynamics desde 2009. TNE permite el intercambio y acceso a información multinivel para usuarios del Departamento de Defensa y las comunidades de inteligencia que operan con diferentes niveles de clasificación. También es la base del entorno de intercambio de coalición multinivel, el 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 certificada en EAL4 para el perfil de protección de seguridad etiquetado (LSPP). ^{[ 7 ]} El objetivo de seguridad incluye tanto la funcionalidad de escritorio como la de red. LSPP exige que los usuarios no estén autorizados a anular las políticas de etiquetado aplicadas por el kernel y el sistema X Window (servidor X11). La evaluación no incluye un análisis de canal encubierto . Dado que estas certificaciones dependen de CAPP, ninguna certificación de Common Criteria indica 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. Tanto CAPP como 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 este producto según los Criterios Comunes contiene un conjunto enriquecido de funciones de seguridad que proporcionan capacidad MLS.

La sanitizació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 obviamente no viola las restricciones de seguridad. Los usuarios con menor nivel de autorización pueden compartir fácilmente su trabajo con usuarios con mayor autorización, pero no al revés. No existe un mecanismo eficiente y confiable mediante el cual un usuario con autorización de alto secreto pueda editar un archivo de alto secreto, eliminar toda la información confidencial y luego entregarlo a usuarios con autorización de secreto o inferior. En la práctica, los sistemas MLS sortean este problema mediante funciones privilegiadas que permiten a un usuario de confianza eludir el mecanismo MLS y cambiar la clasificación de seguridad de un archivo. Sin embargo, esta técnica no es confiable.

Los canales encubiertos representan otro problema para los sistemas MLS. Para que un sistema MLS mantenga la confidencialidad absoluta, no debe existir ninguna forma posible de que un proceso de alto secreto transmita señales de ningún tipo a un proceso de nivel secreto o inferior. Esto incluye efectos secundarios como cambios en la memoria o el espacio en disco disponibles, o cambios en la sincronización de los procesos. Cuando un proceso aprovecha uno de estos efectos secundarios para transmitir datos, está explotando un canal encubierto. Es extremadamente difícil cerrar todos los canales encubiertos en un sistema informático práctico, e incluso puede resultar imposible en la práctica. El proceso de identificar todos los canales encubiertos es, en sí mismo, un desafío. La mayoría de los sistemas MLS disponibles comercialmente no intentan cerrar todos los canales encubiertos, a pesar de que esto dificulta su uso en aplicaciones de alta seguridad.

El bypass resulta problemático cuando se introduce como un medio para tratar un objeto de nivel superior del sistema como si fuera de confianza MLS. Un ejemplo común es extraer datos de un objeto secreto de nivel superior del sistema para enviarlos a un destino no clasificado, citando alguna propiedad de los datos como prueba de confianza de que realmente no están clasificados (por ejemplo, formato "estricto"). No se puede confiar en que un sistema de nivel superior preserve ninguna prueba de confianza, y el resultado es que se abre una ruta de datos abierta sin una forma lógica de mediarla de forma segura. El bypass puede ser arriesgado porque, a diferencia de los canales encubiertos de ancho de banda estrecho que son difíciles de explotar, el bypass puede presentar una fuga abierta grande y fácilmente explotable en el sistema. El bypass suele surgir por la falta de uso de entornos operativos de confianza 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 de confianza hasta el origen. En ese caso, el riesgo de bypass puede ser inevitable si el flujo es realmente esencial.

Un ejemplo común de evasión inevitable es un sistema sujeto que debe aceptar paquetes IP secretos de una fuente no confiable, cifrar los datos de usuario secretos pero no la cabecera 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, de alto nivel del sistema), se le da confianza como si fuera MLS porque proporciona paquetes con cabeceras no clasificadas y datos de usuario secretos en texto plano, una estructura de datos MLS. Dado que la fuente no es confiable, podría estar corrupta e insertar secretos en la cabecera no clasificada del paquete. Las cabeceras corruptas podrían ser sin sentido, pero es imposible para el sistema sujeto determinarlo con una fiabilidad razonable. Los datos de usuario del paquete están bien protegidos criptográficamente, pero la cabecera del paquete puede contener secretos legibles. Si el sistema sujeto pasa los paquetes corruptos a una red no confiable, es posible que no sean enrutables, pero algún proceso corrupto cómplice en la red podría capturar los paquetes y confirmarlos, y el sistema sujeto podría no detectar la fuga. Esto puede constituir una fuga de información importante y difícil de detectar. Interpretar paquetes clasificados con encabezados no clasificados como estructuras de nivel superior del sistema, en lugar de las estructuras MLS que realmente son, representa una amenaza muy común pero grave.

La mayoría de las omisiones son evitables. Las omisiones evitables suelen producirse cuando los arquitectos de sistemas diseñan un sistema sin considerar adecuadamente la seguridad, y luego intentan aplicarla a posteriori como funciones adicionales. En esa situación, la omisión parece ser la única forma (fácil) de hacer funcionar el sistema. Se proponen (¡e incluso se aprueban!) algunos esquemas pseudoseguros que examinan el contenido de los datos omitidos en un vano intento de establecer que no contienen información confidencial. Esto no es posible sin confiar en algún aspecto de los datos, como su formato, lo cual contradice la suposición de que no se confía en que la fuente conserve ninguna característica de los datos originales. La "omisión segura" garantizada es un mito, al igual que el llamado High Assurance Guard (HAG, por sus siglas en inglés), que implementa la omisión de forma transparente. El riesgo que estas soluciones introducen se conoce desde hace tiempo; las soluciones existentes son, en última instancia, procedimentales, no 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 legos están diseñando sistemas informáticos seguros y 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 sobrecargado con dos significados/usos diferentes. Estos dos usos son: MLS como entorno de procesamiento frente a 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 no implica la otra. Muchos sistemas operan en un entorno que contiene datos con niveles de seguridad desiguales y, por lo tanto, son 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 estado en modo operativo desde la década de 1970 y los productos MLS se siguen construyendo, comercializando e implementando.

Las personas sin conocimientos técnicos suelen concluir que admitir que un sistema opera en un entorno MLS (concepción de MLS centrada en el entorno) equivale a acorralarse ante la idea de tener un problema sin solución MLS (concepción de MLS centrada en la capacidad). 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 generar una profunda ignorancia sobre COMPUSEC, que se manifiesta en rumores como «no se puede hablar de MLS» y «MLS no existe». Estos esquemas de negación de MLS cambian tan rápidamente que resultan imposibles de abordar. En cambio, es importante aclarar la distinción entre entorno MLS y capacidad MLS.

• MLS como entorno o modo de seguridad : Una comunidad cuyos usuarios tienen diferentes niveles de autorización de seguridad puede percibir MLS como una capacidad de intercambio de datos : los usuarios pueden compartir información con destinatarios cuya autorización les permita recibirla. Un sistema opera en modo MLS cuando tiene (o podría tener) conectividad con un destino con un nivel de seguridad inferior al de los datos que contiene. Esto se formaliza en el CS-IVT. La determinación del modo de seguridad de un sistema depende completamente de su entorno de seguridad; la clasificación de los datos que contiene, la autorización de quienes pueden obtener acceso directo o indirecto al sistema, sus salidas o señales, y la conectividad y los puertos del sistema con otros sistemas. El modo de seguridad es independiente de las capacidades, aunque un sistema no debe operar en un modo que no sea digno de confianza.
• MLS como capacidad : Los desarrolladores de productos o sistemas destinados a permitir el intercambio de datos MLS suelen concebirlo, de forma general, como una capacidad para imponer restricciones al intercambio de datos o una política de seguridad, similar a los mecanismos que aplican el modelo Bell-LaPadula . Un sistema es compatible con MLS si se demuestra que implementa de forma sólida una política de seguridad.

El uso original del término MLS se refería al entorno o modo de seguridad. Una solución a esta confusión consiste en mantener la definición original de MLS y especificar que es compatible con MLS cuando se utilice ese contexto.

El sistema de seguridad de múltiples niveles independientes (MILS, por sus siglas en inglés) es una arquitectura que aborda el componente de separación de dominios del MLS. Cabe destacar que la UCDMO (la entidad gubernamental estadounidense líder en sistemas multinivel y de dominio cruzado) creó el término Acceso de Dominio Cruzado como una categoría en su base de datos 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 considerarían aislados. MILS aborda el aislamiento subyacente a MLS sin abordar la interacción controlada entre los dominios que abordan los modelos anteriores. Los canales de seguridad confiables mencionados anteriormente pueden vincular los dominios MILS para admitir una mayor funcionalidad de MLS.

El enfoque MILS persigue una estrategia caracterizada por un término más antiguo, MSL ( múltiple nivel único ), que aísla cada nivel de información dentro de su propio entorno de nivel único ( Sistema Alto ).

La comunicación y el aislamiento de procesos rígidos que ofrece MILS pueden ser más útiles para aplicaciones de software de ultra alta fiabilidad que MLS. Cabe destacar que MILS no aborda la estructura jerárquica que implica el concepto de niveles de seguridad. Esto requiere la adición de aplicaciones específicas de importación/exportación entre dominios, cada una de las cuales debe estar debidamente acreditada. Por lo tanto, MILS podría denominarse mejor Dominios Múltiples Independientes de Seguridad (la emulación de MLS en MILS requeriría un conjunto similar de aplicaciones acreditadas para las aplicaciones MLS). Al no abordar la interacción inmediata entre niveles, coherente con las relaciones jerárquicas de Bell-La Padula, MILS es (aparentemente) sencillo de implementar inicialmente, pero requiere aplicaciones suplementarias de importación/exportación no triviales para lograr la riqueza y flexibilidad que esperan las aplicaciones MLS prácticas.

Cualquier comparación entre MILS y MLS debe considerar si la acreditación de un conjunto de solicitudes de exportación más sencillas es más factible 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/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 seguridad de nivel único múltiple (MLS) . Cada nivel de seguridad se aísla en un dominio independiente no confiable. 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 ordenadores separados. Esto se utiliza a menudo para admitir aplicaciones o sistemas operativos que no pueden 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 en la definición de MLS de CNSSI 4009 (parafraseada al inicio de este artículo), el sistema debe proporcionar una interfaz de usuario que permita al usuario acceder y procesar contenido en múltiples niveles de clasificación desde un mismo sistema. La UCDMO organizó una sesión específica sobre MLS en el Simposio de Seguridad de la Información de la NSA en 2009, donde 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 cuenta con un producto llamado Oracle Label Security (OLS) que pretende implementar controles de acceso obligatorios mediante la adición de una columna de "etiqueta" a cada tabla en una base de datos Oracle . Sin embargo, estas son etiquetas arbitrarias desvinculadas de cualquier mecanismo de aplicación subyacente del sistema operativo. 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 . En este caso, se utilizan medidas físicas, incluido el acceso en modo dedicado y de alto nivel del sistema, para garantizar el control de acceso obligatorio según los estándares federales. Trusted Rubix es la única implementación de MLS que se ejecutaba sobre un puerto MLS UNIX y que podía adquirirse empaquetada. De hecho, Trusted Rubix era el único producto de DBMS relacional disponible en el Centro de Información de Productos de Seguridad Autorizados (ASPIC) de la NSA.

También existen varias aplicaciones MLS para usuarios finales. La otra funcionalidad MLS actualmente en la base de datos de UCDMO se llama MLChat ( archivada 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 Estados Unidos . Dado que el contenido de usuarios de diferentes dominios pasa por el servidor MLChat, se emplea un escaneo de palabras malsonantes para proteger el contenido clasificado, y ha habido cierto debate sobre si se trata realmente de un sistema MLS o más bien de una forma de protección de datos para la transferencia entre dominios . Los controles de acceso obligatorios se mantienen mediante una combinación de mecanismos específicos de XTS-400 y de la aplicación. ^{[ 12 ]}

Las aplicaciones MLS que actualmente no forman parte de la base de datos de UCDMO incluyen varias aplicaciones de BlueSpace . BlueSpace cuenta con varias aplicaciones MLS, incluyendo un cliente de correo electrónico MLS, una aplicación de búsqueda MLS y un sistema MLS C2. BlueSpace utiliza una estrategia de middleware para que sus aplicaciones sean independientes de la plataforma, orquestando una interfaz de usuario en múltiples instancias del sistema operativo Windows ( sesiones de terminal virtualizadas o remotas ). El Laboratorio de Investigación Naval de 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 .

Quizás el cambio más significativo en el ámbito de la seguridad multinivel actual sea la convergencia de MLS con la virtualización. Un número creciente de sistemas operativos de confianza está dejando de etiquetar archivos y procesos y, en su lugar, se está orientando hacia contenedores UNIX o máquinas virtuales . Algunos ejemplos son las zonas en Solaris 10 TX y el hipervisor de celdas rellenas en sistemas como la plataforma Integrity de Green Hill y XenClient XT de Citrix. La plataforma High Assurance de la NSA , implementada en el Trusted Virtualization Environment (TVE) de General Dynamics , es otro ejemplo: utiliza SELinux como base y puede admitir aplicaciones MLS que abarcan múltiples dominios.

• Modelo de Bell-LaPadula
• Modelo Biba , Modelo de Integridad Biba
• Modelo de Clark-Wilson
• Control de acceso discrecional (DAC)
• Nivel de Garantía de Evaluación (EAL)
• Modelo de Graham-Denning
• Control de acceso obligatorio (MAC)
• Seguridad multicategoría (MCS)
• autenticación multifactor
• Modelo de no interferencia (seguridad)
• Control de acceso basado en roles (RBAC)
• Modos de operación de seguridad
• Sistema en modo alto
• modelo de captación de subvenciones

• Lampson, B. (1973). "Una nota sobre el problema del confinamiento" . Communications of the ACM . 16 (10): 613– 615. CiteSeerX 10.1.1.129.1549 . doi : 10.1145/362375.362389 . S2CID 9355455 .  
• NCSC (1985). "Criterios de evaluación de sistemas informáticos confiables". Centro Nacional de Seguridad Informática.{{cite journal}}: La cita de la revista requiere |journal=( ayuda ) (también conocido como TCSEC o "Libro Naranja").
• NCSC (1986). "Interpretación de redes confiables". Centro Nacional de Seguridad Informática.{{cite journal}}: La cita de la revista requiere |journal=( ayuda ) (también conocido como TNI o "Libro Rojo").
• Smith, Richard (2005). «Capítulo 205: Seguridad multinivel» . En Hossein Bidgoli (ed.). Manual de seguridad de la información, volumen 3, Amenazas, vulnerabilidades, prevención, detección y gestión . Nueva York: John Wiley. Archivado del original el 6 de mayo de 2006. Consultado el 21 de mayo de 2006 .ISBN 0-471-64832-9.
• Patel, D., Collins, R., Vanfleet, WM, Calloni, BA, Wilding, MM, MacLearn, L., y Luke, JA (noviembre de 2002). "Arquitectura MILS de alta seguridad profundamente integrada (múltiples niveles independientes de seguridad)" (PDF) . Centro de investigación sobre desarrollo económico y reforma de políticas. Archivado del original (PDF) el 28 de abril de 2003. Recuperado el 6 de noviembre de 2005 .{{cite journal}}: La cita de la revista requiere |journal=( ayuda ) CS1 maint: nombres múltiples: lista de autores ( enlace )
• PA Loscocco, SD Smalley, PA Muckelbauer, RC Taylor, SJ Turner y JF Farrell. La inevitabilidad del fallo: la errónea suposición de seguridad en los entornos informáticos modernos . En Actas de la 21.ª Conferencia Nacional sobre Seguridad de los Sistemas de Información, páginas 303-314, octubre de 1998..

• Primer RTOS con certificación de integridad 178B para admitir MILS.
• Página del producto INTEGRITY 178B
• Sistema operativo de confianza PitBull