A finales de la década de 1960, las agencias gubernamentales, al igual que otros usuarios de computadoras, habían avanzado mucho en la transición del procesamiento por lotes a sistemas multiusuario y de tiempo compartido. La Agencia de Proyectos de Investigación Avanzada (ARPA, por sus siglas en inglés) del Departamento de Defensa de los EE. UU., ahora DARPA , fue el principal financiador de la investigación sobre el tiempo compartido. [1] En 1970, el Departamento de Defensa estaba planeando una importante adquisición de computadoras centrales conocidas como Sistema Mundial de Comando y Control Militar (WWMCCS) para respaldar las operaciones de comando militar. El deseo de afrontar 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 aéreo de carga y pasajeros en gran medida sin clasificar, pero en raras ocasiones se le pidió que clasificara algunas de sus misiones utilizando los mismos aviones y tripulaciones; por ejemplo, en casos de contingencias militares u operaciones especiales. En 1970, MAC había articulado el requisito de procesar información clasificada en sus mainframes WWMCCS que pronto llegarían, al tiempo que permitía a los usuarios sin autorización de seguridad acceder a información clasificada (usuarios no autorizados) 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 podría procesar y proteger información clasificada.
El esfuerzo de estudio se organizó como el Grupo de Trabajo sobre Seguridad Informática de la Junta de Ciencias de la Defensa (DSB) bajo la presidencia del difunto 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 produjo 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 llamó el informe del grupo de trabajo del DSB, proporcionó orientación sobre el desarrollo y operación de sistemas informáticos multiusuario que se utilizarían para procesar información clasificada.
Grace Hammonds Nibaldi, mientras trabajaba en Mitre Corporation, publicó un informe que exponía los planes iniciales para la evaluación de sistemas operativos comerciales disponibles en el mercado . [4] El documento de Nibaldi pone gran énfasis en la importancia de la seguridad obligatoria. Al igual que el Libro Naranja que sigue, define siete niveles de productos evaluados con el nivel más bajo y menos seguro (0) reservado para "no evaluados". En el esquema Nibaldi, todos menos el nivel 1 (el nivel más bajo que realmente se somete a evaluación) deben incluir características para una seguridad obligatoria amplia.
El trabajo en el Libro Naranja comenzó en 1979. La creación del Libro Naranja fue un proyecto importante que abarcó el período comprendido entre el informe de Nibaldi de 1979 [4] y 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 principales a su desarrollo. Entre ellos estaban 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, el Libro Naranja (también conocido como DoDD 5200.28-STD) fue cancelado por DoDD 8500.1, que luego fue reeditado 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, bien definida y 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 un individuo, la autorización para la información y el nivel de confidencialidad de la información que se busca. Otros factores indirectos son físicos y ambientales. Esta política también debe reflejar con precisión las leyes, políticas generales y otras orientaciones 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 el objeto se exporta.
Política de seguridad discrecional : aplica un conjunto coherente de reglas para controlar y limitar el acceso en función de las personas identificadas que se ha determinado que necesitan 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 luego pueda evaluar la información de rendición de cuentas dentro de un período de tiempo 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 para categorías específicas de información.
Auditoría : la información de auditoría debe conservarse y protegerse selectivamente 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/software que puedan evaluarse de forma independiente para proporcionar una garantía suficiente de que el sistema cumple los requisitos anteriores. Por extensión, la seguridad debe incluir una garantía de que la parte confiable del sistema funciona sólo según lo previsto. Para lograr estos objetivos se necesitan dos tipos de aseguramiento con sus respectivos elementos: [6]
Mecanismos de aseguramiento
Garantía operativa: arquitectura del sistema, integridad del sistema, análisis de canales encubiertos, gestión confiable de instalaciones 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 confiable del sistema
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, implementación y gestión del sistema en lugar de sus capacidades. Esta documentación incluye: [ cita necesaria ]
Guía del usuario de funciones de seguridad, manual de instalación confiable, documentación de prueba y documentación de diseño
Divisiones y clases
La 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 indican 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 con el requisito de una división superior. [8]
Un ejemplo de tal 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.
Ejemplos de sistemas de clase A1 son SCOMP de Honeywell, GEMSOS de Aesec y SNS Server de Boeing. Dos que no fueron evaluados fueron la plataforma LOCK de producción y el kernel de seguridad DEC VAX cancelado .
Más allá de A1
La arquitectura del sistema demuestra que los requisitos de autoprotección e integridad para los monitores de referencia se han implementado en Trusted Computing Base (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.
Entorno de diseño confiable es donde se diseña el TCB en una instalación confiable con personal confiable (autorizado).
Adaptación de las clases a los requisitos medioambientales
La publicación titulada "Reglamento del Ejército 380-19" es un ejemplo de una guía para determinar qué clase de sistema debe usarse en una situación determinada. [12]
^ abcde Lipner, Steve (2 de junio de 2015). "El nacimiento y la muerte del Libro Naranja" . Anales IEEE de la historia de la informática . 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 .
^ Mercancías, Willis H., ed. (10 de octubre de 1979). "Controles de seguridad para sistemas informáticos: Informe del grupo de trabajo de la Junta Científica de Defensa sobre seguridad informática". Randa . doi :10.7249/R609-1 . Consultado el 28 de enero de 2024 .
^ ab Nibaldi, GH (25 de octubre de 1979). «Criterios de evaluación técnica propuestos para sistemas informáticos confiables» (PDF) . Proyecto de historia del laboratorio de seguridad informática de UC Davis . La Corporación Mitre . Consultado el 28 de enero de 2024 .
^ "INSTRUCCIÓN del Departamento de Defensa - Ciberseguridad" (PDF) . www.dtic.mil . 2014-03-14. Archivado desde el original el 29 de abril de 2014 . Consultado el 28 de enero de 2024 .{{cite web}}: CS1 maint: unfit URL (link)
^ abc Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). págs. 3–4. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ ab Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). pag. 5. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). pag. 9. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). pag. 12. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). pag. 20. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ Klein, Melville H. (15 de enero de 2014). Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa (PDF) (Reporte). Departamento de Defensa (publicado el 15 de agosto de 1983). pag. 44. CSC-STD-001-83 . Consultado el 28 de enero de 2024 - vía CIA .
^ Walker, Robert M. (27 de marzo de 1998). Reglamento del Ejército 380-19: Seguridad de los sistemas de información (PDF) (Reporte). Armada de Estados Unidos . Consultado el 28 de enero de 2024 .
enlaces externos
Instituto de Seguridad Nacional - Criterios de evaluación de sistemas informáticos confiables 5200.28-STD
FAS IRP DOD Criterios de evaluación de sistemas informáticos confiables DOD 5200.28
Criterios de evaluación técnica propuestos para sistemas informáticos confiables
