A finales de los años 1960, las agencias gubernamentales, al igual que otros usuarios de computadoras, habían avanzado mucho en la transición del procesamiento por lotes a los sistemas multiusuario y de tiempo compartido. La Agencia de Proyectos de Investigación Avanzada (ARPA) del Departamento de Defensa de los Estados Unidos , ahora DARPA , fue uno de los principales financiadores de la investigación sobre el tiempo compartido. [1] En 1970, el Departamento de Defensa estaba planeando una importante adquisición de computadoras mainframe conocidas como el Sistema Mundial de Comando y Control Militar (WWMCCS) para apoyar las operaciones de comando militar. El deseo de enfrentar los desafíos más avanzados surgió pronto. El Comando de Transporte Aéreo Militar (MAC) de la Fuerza Aérea, por ejemplo, proporcionó a los servicios militares un servicio de carga aérea y pasajeros en gran parte no clasificado, pero en raras ocasiones se le pidió que clasificara algunas de sus misiones utilizando las mismas aeronaves y tripulaciones, por ejemplo, en casos de contingencias militares u operaciones especiales. En 1970, MAC había articulado un requisito para procesar información clasificada en sus mainframes WWMCCS que pronto llegarían, permitiendo al mismo tiempo que los usuarios sin autorización de seguridad accedieran a la información clasificada (usuarios sin autorización) a los mainframes. [2]
La comunidad de seguridad nacional respondió a los desafíos de dos maneras: la Oficina del Secretario de Defensa encargó un estudio de las cuestiones políticas y técnicas asociadas con la seguridad de los sistemas informáticos, mientras que ARPA financió el desarrollo de un prototipo de sistema operativo seguro que pudiera procesar y proteger información clasificada.
El estudio se organizó como el Grupo de Trabajo sobre Seguridad Informática del Consejo Científico de Defensa (DSB) bajo la presidencia del fallecido Willis Ware. Entre sus miembros se encontraban tecnólogos del gobierno y contratistas de defensa, así como funcionarios de seguridad del Departamento de Defensa y la comunidad de inteligencia. El grupo de trabajo se reunió entre 1967 y 1969 y elaboró un informe clasificado que se puso a disposición de las organizaciones con la autorización de seguridad adecuada a partir de 1970. [3] El Informe Ware , como se denominó al informe del grupo de trabajo del DSB, proporcionó orientación sobre el desarrollo y el funcionamiento de sistemas informáticos multiusuario que se utilizarían para procesar información clasificada.
Grace Hammonds Nibaldi, mientras trabajaba en la Corporación Mitre, publicó un informe que establecía los planes iniciales para la evaluación de sistemas operativos comerciales listos para usar . [4] El documento de Nibaldi hace gran hincapié en la importancia de la seguridad obligatoria. Al igual que el Libro Naranja que le siguió, define siete niveles de productos evaluados, con el nivel más bajo y menos seguro (0) reservado para los “no evaluados”. En el esquema de Nibaldi, todos los productos, excepto el nivel 1 (el nivel más bajo que realmente se somete a evaluación), deben incluir características para una seguridad obligatoria extensiva.
El trabajo sobre el Libro Naranja comenzó en 1979. La creación del Libro Naranja fue un proyecto importante que abarcó el período desde el informe de Nibaldi de 1979 [4] hasta la publicación oficial del Libro Naranja en 1983. El primer borrador público de los criterios de evaluación fue el Libro Azul publicado en mayo de 1982. [1] El Libro Naranja se publicó en agosto de 1983. Sheila Brand fue la autora principal y varias otras personas fueron contribuyentes fundamentales a su desarrollo. Entre ellos se encontraban Grace Hammonds Nibaldi y Peter Tasker de Mitre Corporation ; Dan Edwards, Roger Schell y Marvin Schaeffer de la Conferencia Nacional de Seguridad Informática; y Ted Lee de Univac . Varias personas del gobierno, contratistas gubernamentales y proveedores, incluidos Jim Anderson, Steve Walker, Clark Weissman y Steve Lipner, fueron citados como revisores que influyeron en el contenido del producto final. [1]
El 24 de octubre de 2002, The Orange Book (también conocido como DoDD 5200.28-STD) fue cancelado por DoDD 8500.1, que luego se reeditó como DoDI 8500.02, el 14 de marzo de 2014. [5]
Objetivos y requisitos fundamentales
Política
La política de seguridad debe ser explícita, estar bien definida y ser aplicada por el sistema informático. Se especifican tres políticas de seguridad básicas: [6]
Política de seguridad obligatoria : aplica reglas de control de acceso basadas directamente en la autorización de una persona, la autorización para acceder a la información y el nivel de confidencialidad de la información solicitada. Otros factores indirectos son los físicos y ambientales. Esta política también debe reflejar con precisión las leyes, las políticas generales y otras pautas relevantes de las que se derivan las reglas.
Marcado : Los sistemas diseñados para hacer cumplir una política de seguridad obligatoria deben almacenar y preservar la integridad de las etiquetas de control de acceso y conservar las etiquetas si se exporta el objeto.
Política de seguridad discrecional : aplica un conjunto coherente de reglas para controlar y limitar el acceso en función de personas identificadas que se ha determinado que tienen la necesidad de conocer la información.
Responsabilidad
Se debe hacer cumplir la responsabilidad individual, independientemente de la política. Debe existir un medio seguro para garantizar el acceso de un agente autorizado y competente que pueda evaluar la información de rendición de cuentas en un plazo razonable y sin dificultades indebidas. El objetivo de rendición de cuentas incluye tres requisitos: [6]
Identificación : El proceso utilizado para reconocer a un usuario individual.
Autenticación : La verificación de la autorización de un usuario individual a categorías específicas de información.
Auditoría : la información de auditoría debe conservarse y protegerse de forma selectiva para que las acciones que afectan la seguridad puedan rastrearse hasta el individuo autenticado.
Garantía
El sistema informático debe contener mecanismos de hardware y software que puedan evaluarse de forma independiente para proporcionar la seguridad suficiente de que el sistema cumple con los requisitos anteriores. Por extensión, la seguridad debe incluir una garantía de que la parte confiable del sistema funciona únicamente como está previsto. Para lograr estos objetivos, se necesitan dos tipos de seguridad con sus respectivos elementos: [6]
Mecanismos de garantía
Garantía operativa: arquitectura del sistema, integridad del sistema, análisis de canales encubiertos, gestión de instalaciones confiables y recuperación confiable
Garantía del ciclo de vida: pruebas de seguridad, especificación y verificación del diseño, gestión de la configuración y distribución de sistemas de confianza
Garantía de protección continua : los mecanismos confiables que hacen cumplir estos requisitos básicos deben estar protegidos continuamente contra manipulaciones o cambios no autorizados.
Documentación
Dentro de cada clase, un conjunto adicional de documentación aborda el desarrollo, la implementación y la gestión del sistema en lugar de sus capacidades. Esta documentación incluye: [ cita requerida ]
Guía del usuario de funciones de seguridad, Manual de instalación confiable, Documentación de pruebas y Documentación de diseño
Divisiones y clases
El TCSEC define cuatro divisiones: D, C, B y A, donde la división A tiene la mayor seguridad. Cada división representa una diferencia significativa en la confianza que un individuo u organización puede depositar en el sistema evaluado. Además, las divisiones C, B y A se dividen en una serie de subdivisiones jerárquicas llamadas clases: C1, C2, B1, B2, B3 y A1. [7]
Cada división y clase amplía o modifica según se indique los requisitos de la división o clase inmediatamente anterior. [7]
D – Protección mínima
Reservado para aquellos sistemas que han sido evaluados pero que no cumplen el requisito para una división superior. [8]
Un ejemplo de este tipo de sistema es el XTS-300, un precursor del XTS-400.
A – Protección verificada
A1 – Diseño verificado [11]
Funcionalmente idéntico al B3
Técnicas formales de diseño y verificación, incluida una especificación formal de alto nivel
Procedimientos formales de gestión y distribución
Entre los ejemplos de sistemas de clase A1 se encuentran SCOMP de Honeywell, GEMSOS de Aesec y SNS Server de Boeing. Dos de los sistemas que no se evaluaron fueron la plataforma de producción LOCK y el núcleo de seguridad DEC VAX , que fue cancelado .
Más allá de A1
La arquitectura del sistema demuestra que los requisitos de autoprotección e integridad de los monitores de referencia se han implementado en la Base de Computación Confiable (TCB).
Las pruebas de seguridad generan automáticamente casos de prueba a partir de la especificación formal de nivel superior o de las especificaciones formales de nivel inferior.
La especificación y verificación formal es donde se verifica el TCB hasta el nivel del código fuente, utilizando métodos de verificación formal cuando sea posible.
Un entorno de diseño confiable es aquel en el que el TCB se diseña en una instalación confiable y solo con personal confiable (autorizado).
Adecuación de las clases a los requisitos medioambientales
La publicación titulada "Reglamento del Ejército 380-19" es un ejemplo de guía para determinar qué clase de sistema se debe utilizar en una situación determinada. [12]
^ abcde Lipner, Steve (2 de junio de 2015). "El nacimiento y la muerte del Libro Naranja" . IEEE Annals of the History of Computing . 37 (2): 19–31. doi :10.1109/MAHC.2015.27. S2CID 16625319. Consultado el 28 de enero de 2024 a través de IEEE.
^ ab Lipner, SB (6 de enero de 1971). "Configuraciones de seguridad MACIMS" (PDF) . stevelipner.org . Consultado el 28 de enero de 2024 .
^ Ware, Willis H., ed. (1979-10-10). "Controles de seguridad para sistemas informáticos: Informe del grupo de trabajo de la Junta Científica de Defensa sobre seguridad informática". Rand . doi :10.7249/R609-1 . Consultado el 28 de enero de 2024 .
^ ab Nibaldi, GH (1979-10-25). "Criterios de evaluación técnica propuestos para sistemas informáticos de confianza" (PDF) . Proyecto de historia del laboratorio de seguridad informática de la UC Davis . The Mitre Corporation . Consultado el 28 de enero de 2024 .
^ "Departamento de Defensa INSTRUCCIÓN - Ciberseguridad" (PDF) . www.dtic.mil . 2014-03-14. Archivado desde el original el 2014-04-29 . Consultado el 2024-01-28 .{{cite web}}: CS1 maint: unfit URL (link)
^ abc Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). págs. 3-4. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ ab Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 5. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 9. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 12. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 20. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 44. CSC-STD-001-83 . Consultado el 28 de enero de 2024 a través de CIA .
^ Walker, Robert M. (27 de marzo de 1998). Reglamento del Ejército 380-19: Seguridad de los sistemas de información (PDF) (Informe). Ejército de los Estados Unidos . Consultado el 28 de enero de 2024 .
Enlaces externos
Instituto de Seguridad Nacional - Criterios de evaluación de sistemas informáticos de confianza 5200.28-STD
Criterios de evaluación de sistemas informáticos confiables del DOD de FAS IRP DOD 5200.28
Criterios de evaluación técnica propuestos para sistemas informáticos confiables
