Articulo de referencia

Criterios de evaluación de sistemas informáticos confiables

El Libro Naranja Los Criterios de Evaluación de Sistemas Informáticos Confiables ( TCSEC ) son un estándar del Departamento de Defensa (DoD) del Gobierno de los Estados Unidos q...

El Libro Naranja

Los Criterios de Evaluación de Sistemas Informáticos Confiables ( TCSEC ) son un estándar del Departamento de Defensa (DoD) del Gobierno de los Estados Unidos que establece los requisitos básicos para evaluar la eficacia de los controles de seguridad informática integrados en un sistema informático . El TCSEC se utilizó para evaluar, clasificar y seleccionar sistemas informáticos que se consideraban para el procesamiento, almacenamiento y recuperación de información sensible o clasificada . [ 1 ]

El TCSEC, conocido frecuentemente como el Libro Naranja , es la publicación principal de la serie Rainbow del Departamento de Defensa . Publicado inicialmente en 1983 por el Centro Nacional de Seguridad Informática (NCSC), una rama de la Agencia de Seguridad Nacional , y actualizado posteriormente en 1985, el TCSEC fue finalmente reemplazado por el estándar internacional Common Criteria , publicado originalmente en 2005.

Historia

A finales de la década de 1960, las agencias gubernamentales, al igual que otros usuarios de computadoras, habían avanzado considerablemente 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 (DoD), ahora DARPA , fue uno de los principales financiadores de la investigación sobre el tiempo compartido. [ 1 ] Para 1970, el DoD estaba planeando una importante adquisición de computadoras centrales conocidas como el Sistema Mundial de Comando y Control Militar (WWMCCS) para apoyar 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, proporcionaba a los servicios militares un servicio aéreo de carga y pasajeros en gran medida no clasificado, pero en raras ocasiones se le exigía clasificar algunas de sus misiones utilizando las mismas aeronaves y tripulaciones, por ejemplo, en casos de contingencias militares u operaciones especiales. Para 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 la información clasificada (usuarios no autorizados) acceso 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 sobre las cuestiones políticas y técnicas relacionadas 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 de la Junta de Ciencias de la Defensa (DSB, por sus siglas en inglés), presidido por el 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 de 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 correspondiente a partir de 1970. [ 3 ] El Informe Ware , como se denominó al informe del grupo de trabajo de la DSB, proporcionó orientación sobre el desarrollo y el funcionamiento de sistemas informáticos multiusuario que se utilizarían para procesar información clasificada.

A principios de la década de 1970, los requisitos de la Fuerza Aérea de los Estados Unidos para el desarrollo de nuevas capacidades de sistemas informáticos se dirigieron a la División de Sistemas Electrónicos de la Fuerza Aérea (ESD), más tarde conocida como el Centro de Sistemas Electrónicos en la Base de la Fuerza Aérea Hanscom en Massachusetts. La ESD recibió asesoramiento y apoyo técnico de la Corporación Mitre , uno de los centros de investigación y desarrollo financiados por el gobierno federal (FFRDC) del país. Un informe inicial de MITRE [ 2 ] sugirió enfoques alternativos para cumplir con el requisito MAC sin desarrollar un nuevo sistema operativo seguro multinivel, con la esperanza de que estos enfoques pudieran evitar los problemas que el Informe Ware caracterizó como intratables.

Grace Hammonds Nibaldi, mientras trabajaba en Mitre Corporation, publicó un informe que describí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 se publicará más adelante, define siete niveles de productos evaluados, con el nivel más bajo y menos seguro (0) reservado para los productos "no evaluados". En el esquema de Nibaldi, todos los niveles, excepto el nivel 1 (el nivel más bajo que realmente se somete a evaluación), deben incluir características de seguridad obligatoria exhaustiva.

El trabajo en 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 contribuyeron de manera fundamental a su desarrollo. Entre ellas 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 ]

En 1999, el Libro Naranja fue reemplazado por los Criterios Comunes Internacionales para la Evaluación de la Seguridad de las Tecnologías de la Información . [ 1 ]

El 24 de octubre de 2002, el Libro Naranja (también conocido como DoDD 5200.28-STD) fue cancelado por el DoDD 8500.1, que posteriormente 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, 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 normas de control de acceso basadas directamente en la autorización de acceso de cada 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 demás directrices pertinentes de las que se derivan las normas.
  • 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 conservarlas 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 tienen necesidad de conocer la información.

Responsabilidad

Se debe exigir la rendición de cuentas 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: Proceso utilizado para reconocer a un usuario individual.
  • Autenticación: Verificación de la autorización de un usuario individual para acceder 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 afecten a la seguridad puedan rastrearse hasta la persona autenticada.

Garantía

El sistema informático debe contener mecanismos de hardware/software que puedan evaluarse de forma independiente para garantizar suficientemente que el sistema cumpla con los requisitos anteriores. Por extensión, la garantía debe incluir la seguridad de que la parte confiable del sistema funcione únicamente según lo previsto. Para lograr estos objetivos, se necesitan dos tipos de garantía 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 de confianza y recuperación de confianza.
  • 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 confiables.
  • Garantía de protección continua: Los mecanismos de confianza que hacen cumplir estos requisitos básicos deben estar protegidos de forma continua 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:

  • Guía del usuario de las funciones de seguridad, manual de instalaciones de confianza, 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 ofrece la máxima 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 subdividen 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 indica, 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 para una división superior. [ 8 ]

C – Protección discrecional

  • C1 – Protección de seguridad discrecional [ 9 ]
    • Identificación y autenticación
    • Separación de usuarios y datos
    • Control de acceso discrecional (DAC) capaz de imponer limitaciones de acceso de forma individual.
    • Documentación del sistema y manuales de usuario requeridos
  • C2 – Protección de acceso controlado
    • DAC de grano más fino
    • Responsabilidad individual a través de procedimientos de inicio de sesión
    • Registros de auditoría
    • reutilización de objetos
    • aislamiento de recursos
    • Un ejemplo de este tipo de sistema es HP-UX.

B – Protección obligatoria

  • B1 – Protección de seguridad etiquetada [ 10 ]
    • Declaración informal del modelo de política de seguridad
    • Etiquetas de confidencialidad de datos
    • Control de acceso obligatorio (MAC) sobre sujetos y objetos seleccionados
    • Capacidades de exportación de etiquetas
    • Algunos fallos detectados deben eliminarse o mitigarse de alguna otra manera.
    • Especificaciones de diseño y verificación
    • Un ejemplo de dicho sistema fue la variante SEVMS de OpenVMS [ 11 ].
  • B2 – Protección Estructurada
    • Modelo de política de seguridad claramente definido y documentado formalmente.
    • La aplicación de DAC y MAC se extiende a todos los sujetos y objetos.
    • Se analizan los canales de almacenamiento encubiertos en cuanto a su frecuencia y ancho de banda.
    • Estructurado cuidadosamente en elementos críticos para la protección y elementos no críticos para la protección.
    • El diseño y la implementación permiten realizar pruebas y revisiones más exhaustivas.
    • Se refuerzan los mecanismos de autenticación.
    • Se proporciona una gestión de instalaciones confiable con separación entre administrador y operador.
    • Se imponen estrictos controles de gestión de la configuración.
    • Los roles de operador y administrador están separados.
    • Un ejemplo de dicho sistema fue Multics.
  • B3 – Dominios de seguridad

A – Protección verificada

  • A1 – Diseño verificado [ 12 ]
    • Funcionalmente idéntico a B3
    • Técnicas formales de diseño y verificación, incluyendo 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 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 para 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 el TCB se verifica hasta el nivel del código fuente, utilizando métodos de verificación formal cuando sea factible.
    • El Entorno de Diseño Confiable es aquel en el que el TCB se diseña en una instalación de confianza con personal autorizado (de confianza).

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 utilizarse en una situación determinada. [ 13 ]

Véase también

Referencias

  1. 1 2 3 4 5 Lipner, Steve (2015-06-02). "El nacimiento y la muerte del Libro Naranja". IEEE Annals of the History of Computing . 37 (2): 19– 31. Bibcode : 2015IAHC...37b..19L . doi : 10.1109/MAHC.2015.27 . S2CID 16625319 . 
  2. 1 2 Lipner, SB (1971-01-06). "Configuraciones de seguridad de MACIMS" (PDF) . stevelipner.org . Recuperado el 28 de enero de 2024 .
  3. Ware, Willis H., ed. (1979-10-10). "Controles de seguridad para sistemas informáticos: Informe del Grupo de Trabajo de la Junta de Ciencias de la Defensa sobre Seguridad Informática" . Rand . doi : 10.7249/R609-1 . Recuperado el 28 de enero de 2024 .
  4. 1 2 Nibaldi, GH (1979-10-25). "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 . The Mitre Corporation . Recuperado el 28 de enero de 2024 .
  5. "Instrucción del Departamento de Defensa - Ciberseguridad" (PDF) . www.dtic.mil . 14 de marzo de 2014. Archivado del original el 29 de abril de 2014. Consultado el 28 de enero de 2024 .
  6. 1 2 3 Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático de confianza del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). págs. 3–4 . CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  7. 1 2 Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático confiable del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 5. CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  8. Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático confiable del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 9. CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  9. Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático confiable del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 12. CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  10. Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático confiable del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 20. CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  11. ""Entrada EPL para SEVMS VAX Versión 6.0"" . hpe.com . DOD . 1994-06-30 . Consultado el 25-05-2025 .
  12. Klein, Melville H. (15 de enero de 2014). Criterios de evaluación del sistema informático confiable del Departamento de Defensa (PDF) (Informe). DOD (publicado el 15 de agosto de 1983). pág. 44. CSC-STD-001-83 . Recuperado el 28 de enero de 2024 vía CIA . 
  13. Walker, Robert M. (1998-03-27). Reglamento del Ejército 380-19: Seguridad de los Sistemas de Información (PDF) (Informe). Ejército de los Estados Unidos . Recuperado el 28 de enero de 2024 .
  • Instituto de Seguridad Nacional - 5200.28-STD Criterios de evaluación de sistemas informáticos confiables
  • Criterios de evaluación del sistema informático de confianza FAS IRP del Departamento de Defensa (DOD 5200.28)
  • Criterios de evaluación técnica propuestos para sistemas informáticos confiables
Obtenido de " https://en.wikipedia.org/w/index.php?title=Trusted_Computer_System_Evaluation_Criteria&oldid=1355970385 "