Date post: | 14-Dec-2015 |
Category: |
Documents |
Upload: | forgetmelater-1 |
View: | 221 times |
Download: | 3 times |
DoD 5200.28-STD
Reemplaza
CSC-STD-00l-83, l5 dtd agosto 83
Biblioteca Nº S225,7ll
DEPARTAMENTO DE DEFENSA STANDARD
DEPARTAMENTO DE
DEFENSA
ORDENADOR DE CONFIANZA
SISTEMA DE EVALUACIÓN
CRITERIOS
Diciembre l985
?
26 de diciembre de l985
PRÓLOGO
Computer Esta publicación, DoD 5200.28-STD, "Departamento de Defensa de confianza
Criterios de evaluación del sistema ", se emite bajo la autoridad de un acuerdo
con la Directiva DoD 5200.28, "Requisitos de seguridad para Automatic Data
Procesamiento (ADP) Sistemas ", y en cumplimiento de las responsabilidades asignadas por
DoD Directiva 52l5.l, "Seguridad Informática Centro de evaluación." Su propósito es
proporcionar / / criterios técnicos de hardware de firmware y software de seguridad asociado
metodologías de evaluación técnica en apoyo del sistema de ADP general
la política de seguridad, evaluación y aprobación / responsabilidades de acreditación
promulgada por la Directiva DoD 5200.28.
Lo dispuesto en este documento se aplican a la Oficina del Secretario de Defensa
(ASD), los departamentos militares, la Organización de los Jefes del Estado Mayor Conjunto,
Unificado y especificado los comandos, las agencias y las actividades de Defensa
administrativamente apoyado por OSD (en lo sucesivo denominado "DoD Componentes").
Esta publicación es efectiva inmediatamente y es obligatorio para su uso por parte de todos del Departamento de Defensa
Componentes en la realización de actividades de evaluación de la seguridad técnica del sistema ADP
aplicable al tratamiento y almacenamiento de los clasificados y otra DoD sensibles
información y aplicaciones como se establece en el presente documento.
Se anima Recomendaciones para la revisión de esta publicación y serán
revisado cada dos años por el Centro Nacional de Seguridad Informática a través de un oficial
proceso de revisión. Dirección todas las propuestas de revisión a través apropiada
canales a: Centro Nacional de Seguridad Informática, Atención: Jefe, Computadora
Normas de Seguridad.
Componentes del DoD puede obtener copias de esta publicación a través de su propia
Publicaciones canales. Otras agencias federales y el público puede obtener copias
de: Oficina de Normas y Productos, Centro Nacional de Seguridad Informática,
Fort Meade, MD 20755-6000, Atención: Jefe, Estándares de Seguridad Informática.
_________________________________
Donald C. Latham
El subsecretario de Defensa
(Comando, Control, Comunicaciones e Inteligencia)
?
AGRADECIMIENTOS
Un reconocimiento especial se extiende a Sheila L. Marca, Seguridad Nacional de Informática
Centro (NCSC), que integra la teoría, la política y la práctica en y dirigió
la producción de este documento.
Reconocimiento También se da por las contribuciones de: Gracia y Hammonds
Peter S. Tasker, el MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell,
ex Director Adjunto de NCSC, Marvin Schaefer, NCSC, y Theodore MP Lee,
Sperry Corp., que como arquitectos originales formulados y articulan la
problemas y soluciones técnicas que se presentan en este documento; Jeff Makey, anteriormente
NCSC, Warren F. Shadle, NCSC, y Carole S. Jordan, NCSC, quien colaboró en la
elaboración de este documento; James P. Anderson, James P. Anderson & Co.,
Steven B. Lipner, Digital Equipment Corp., Clark Weissman, Desarrollo de Sistemas
Corp., LTC Lawrence A. Noble, ex Fuerza Aérea de Estados Unidos, Stephen T. Walker,
antes del Departamento de Defensa, Eugene V. Epperly, del Departamento de Defensa, y James E. Studer, anteriormente Departamento de
el Ejército, que dio generosamente su tiempo y experiencia en la revisión y
crítica de este documento; y, finalmente, se dan gracias a la computadora
la industria y otros interesados en la computación de confianza por su entusiasta
asesoramiento y asistencia a través de este esfuerzo.
?
CONTENIDOS
PRÓLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .yo
AGRADECIMIENTOS. . . . . . . . . . . . . . . . . . . . . . . ii
PRÓLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .v
INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . 0.1
PARTE I: LOS CRITERIOS
1.0 DIVISIÓN D: protección mínima. . . . . . . . . . . . . 0.9
2.0 DIVISIÓN C: PROTECCIÓN DISCRECIONAL. . . . . . . . . . 11
2.1 Clase (C1): Discrecional Protección Seguridad. . 12
2.2 Clase (C2): Controlado de protección de acceso. . . . . 15
3.0 DIVISIÓN B: PROTECCIÓN OBLIGATORIA. . . . . . . . . . . . 19
3.1 Clase (B1): Etiquetado de Protección de Seguridad. . . . . 20
3.2 Clase (B2): Protección estructurado. . . . . . . . 26
3.3 Clase (B3): Dominios de Seguridad. . . . . . . . . . . 33
4.0 DIVISIÓN A: PROTECCIÓN VERIFICADO. . . . . . . . . . . . 41
4.1 Clase (A1): Diseño verificada. . . . . . . . . . . 42
4.2 Más allá de la Clase (A1). . . . . . . . . . . . . . . . . 51
PARTE II: JUSTIFICACIÓN Y DIRECTRICES
5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMÁTICOS DE CONFIANZA. . . . . 55
5.1 Una necesidad de consenso. . . . . . . . . . . . . . . 56
5.2 Definición y utilidad. . . . . . . . . . . . . 56
5.3 Criterios de control objetivo. . . . . . . . . . . . 56
6.0 JUSTIFICACIÓN DETRÁS DE LAS CLASES DE EVALUACIÓN. . . . . . . . . 63
6.1 El concepto de monitor de referencia. . . . . . . . . . . 64
6.2 Un modelo de Política de Seguridad formal. . . . . . . . . . 64
6.3 La Base de Trusted Computing. . . . . . . . . . . . sesenta y cinco
6.4 Aseguramiento. . . . . . . . . . . . . . . . . . . . . sesenta y cinco
6.5 Las Clases. . . . . . . . . . . . . . . . . . . . 66
7.0 LA RELACIÓN ENTRE LA POLÍTICA Y LOS CRITERIOS. . . . 69
7.1 establecido políticas federales. . . . . . . . . . . 70
7.2 Políticas del Departamento de Defensa. . . . . . . . . . . . . . . . . . . 70
7.3 Criterios de control objetivo para la Política de Seguridad. . 71
7.4 Criterios de control objetivo para la Rendición de Cuentas. . . 74
7.5 Criterios de control objetivo para la Garantía. . . . . 76
8.0 Una directriz sobre canales encubiertos. . . . . . . . . . . . . 79
9.0 A GUÍA sobre la configuración de control de acceso obligatorio
CARACTERÍSTICAS . . . . . . . . . . . . . . . . . . . . . . . . 81
10.0 Una GUÍA SOBRE LAS PRUEBAS DE SEGURIDAD. . . . . . . . . . . . 83
10.1 Pruebas de División C. . . . . . . . . . . . . . 84
10.2 Pruebas de División B. . . . . . . . . . . . . . 84
10.3 Las pruebas para la División A. . . . . . . . . . . . . . 85
ANEXO A: Proceso de evaluación comercial del producto. . . . . . 87
ANEXO B: Resumen de Evaluación Divisiones Criterios. . . . 89
ANEXO C: Sumario de las clases criterios de evaluación. . . . . . 91
APÉNDICE D: Directorio de los Menesteres. . . . . . . . . . . . . . 93
GLOSARIO. . . . . . . . . . . . . . . . . . . . . . . . . . 0,109
REFERENCIAS. . . . . . . . . . . . . . . . . . . . . . . . . 0,115
?
PRÓLOGO
Los criterios de evaluación del sistema informático de confianza definidos en este documento
clasificar los sistemas en cuatro grandes divisiones jerárquicas de seguridad mejorada
protección. Ellos proporcionan una base para la evaluación de la eficacia de
controles de seguridad integrados en productos automáticos del sistema de procesamiento de datos. Los
criterios se han desarrollado con tres objetivos en mente: (a) para proporcionar a los usuarios
con un punto de referencia con el que evaluar el grado de confianza que se puede colocar
en los sistemas informáticos para el procesamiento seguro de clasificado u otro sensibles
la información; (b) para proporcionar orientación a los fabricantes en cuanto a lo de construir en
sus nuevos productos comerciales, ampliamente disponibles confianza con el fin de satisfacer
requisitos fiduciarios para aplicaciones sensibles; y (c) proporcionar una base para
especificando los requisitos de seguridad en las especificaciones de adquisición. Dos tipos de
requisitos son delineados para el procesamiento seguro: (a) la seguridad específica
requisitos de características y (b) los requisitos de garantía. Algunos de estos últimos
requisitos permiten al personal de evaluación para determinar si las características requeridas
están presentes y funcionando según lo previsto. El ámbito de aplicación de estos criterios es ser
aplicada al conjunto de componentes que comprenden un sistema de confianza, y no es
necesariamente que debe aplicarse a cada componente del sistema individualmente. Por lo tanto, algunos
componentes de un sistema puede ser completamente no es de confianza, mientras que otros pueden ser
evaluado individualmente a una clase de evaluación más baja o más alta que la grande
producto considerado como un sistema completo. En los productos de confianza en el extremo superior de
la gama, la fuerza del monitor de referencia es tal que la mayoría de las
componentes pueden ser completamente confiable. Aunque los criterios se pretende que sean
independiente de la aplicación, los requisitos específicos de características de seguridad pueden tener que
interpretarse en la aplicación de los criterios a los sistemas específicos con su propia
requisitos funcionales, aplicaciones o entornos especiales (por ejemplo,
procesadores de comunicaciones, ordenadores de control de procesos y sistemas integrados en
general). Los requisitos de garantía subyacentes se pueden aplicar a través de la
todo el espectro de entornos de sistema ADP o procesamiento de aplicación sin
interpretación especial.
?
INTRODUCCIÓN
Perspectiva historica
En octubre de 1967, un grupo de trabajo se reunió bajo los auspicios de la Defensa
Science Board para hacer frente a las garantías de seguridad informática que protegerían
la información clasificada en el acceso remoto, sistemas informáticos de intercambio de recursos.
El informe del Grupo de Trabajo, "Controles de seguridad de sistemas informáticos", publicado en
02 1970, formuló una serie de recomendaciones de políticas y técnicas de
acciones que deben adoptarse para reducir la amenaza de compromiso del clasificado
información procesada en los sistemas informáticos de acceso remoto. [34] Departamento de
Defensa Directiva 5200.28 y su manual que acompaña DoD 5200.28-M, publicado
en 1972 y 1973 respectivamente, respondió a una de estas recomendaciones por
el establecimiento de la política del Departamento de Defensa uniforme, los requisitos de seguridad, administrativos
controles y medidas técnicas para proteger la información clasificada procesados
por los sistemas informáticos del Departamento de Defensa [8, 9]. La investigación y el desarrollo de los trabajos realizados por el
Fuerza Aérea, Advanced Research Projects Agency, y otros organismos de defensa de
los 70 principios y mediados desarrollados y solución demostrado enfoques para la
problemas técnicos asociados con el control del flujo de información en
intercambio de información y los sistemas informáticos de recursos. [1] El ordenador del Departamento de Defensa
Iniciativa de Seguridad se inició en 1977 bajo los auspicios del Bajo
Secretario de Defensa para la Investigación e Ingeniería para enfocar los esfuerzos del Departamento de Defensa
cuestiones abordar la seguridad informática. [33]
Paralelamente a los esfuerzos del Departamento de Defensa para abordar las cuestiones de seguridad informática, el trabajo era
iniciado bajo la dirección de la Oficina Nacional de Estándares (NBS) para definir
problemas y soluciones para la construcción, evaluación y auditoría informática segura
sistemas. [17] Como parte de este trabajo NBS celebró dos talleres de invitación en la
tema de la auditoría y la evaluación de la seguridad informática [20; 28]. El primero fue
celebrada en marzo de 1977, y la segunda en noviembre de 1978. Uno de los productos
del segundo taller fue un documento definitivo sobre los problemas relacionados con
proporcionar criterios para la evaluación de la seguridad del equipo técnico
eficacia. [20] Como consecuencia de las recomendaciones de este informe y, en
apoyo de la Iniciativa de Seguridad del Departamento de Defensa de computadoras, comenzó la Corporación MITRE
trabajar en un conjunto de criterios de evaluación de seguridad informática que podría ser usado para
evaluar el grado de confianza se podría colocar en un sistema informático para proteger
datos clasificada [24; 25; 31]. Los conceptos preliminares para la seguridad informática
Evaluación se define y se amplió en los talleres de invitación y
simposios cuyos participantes representaron experiencia en seguridad informática extrae de
industria y la academia, además del gobierno. Su trabajo tiene ya
sido objeto de mucha revisión por pares y la crítica técnica constructiva de
el Departamento de Defensa, las organizaciones de investigación industrial y de desarrollo, universidades, y
los fabricantes de ordenadores.
El Centro de Seguridad Informática del Departamento de Defensa (el Centro) se formó en enero de 1981 a
personal y ampliar la labor iniciada por el Departamento de Defensa Seguridad informática
Iniciativa. [15] Uno de los objetivos principales del Centro, tal como figura en su Carta del Departamento de Defensa es
alentar a la amplia disponibilidad de los sistemas informáticos de confianza para su uso por
los que procesan la información confidencial clasificada u otros. [10] Los criterios
presentada en este documento han evolucionado a partir de la NBS antes y MITRE
material de evaluación.
Alcance
Se aplican los criterios de evaluación del sistema informático de confianza definidos en este documento
principalmente a confianza procesamiento automático de datos disponible en el mercado (ADP)
sistemas. Ellos también son aplicables, como amplificada a continuación, la evaluación de
los sistemas existentes y la especificación de requisitos de seguridad para ADP
adquisición de sistemas. Se incluyen dos conjuntos distintos de requisitos: 1)
requisitos específicos de características de seguridad; y 2) los requisitos de garantía. Los
requisitos específicos incluyen abarcan las capacidades se encuentran típicamente en
sistemas de procesamiento de información que emplean sistemas operativos de propósito general que
son distintas de las aplicaciones de los programas que se apoyaban. Sin embargo, específica
requisitos de características de seguridad también pueden aplicarse a sistemas específicos con su propia
requisitos funcionales, aplicaciones o entornos especiales (por ejemplo,
procesadores de comunicaciones, ordenadores de control de procesos y sistemas integrados en
general). Los requisitos de garantía, por otro lado, se aplican a los sistemas que
cubrir toda la gama de entornos informáticos de los controladores dedicados a
sistemas de seguridad multinivel gama completa de intercambio de recursos.
Propósito
Como se señala en el prefacio, los criterios han sido developedto servir a un número
de fines previstos:
* Proporcionar un estándar para los fabricantes en cuanto a lo de seguridad
características para construir en su nueva y planificada, comercial
productos a fin de proporcionar sistemas ampliamente disponibles que
requisitos fiduciarios satisfacer (con especial énfasis en la prevención
la divulgación de datos) para aplicaciones sensibles.
* Proporcionar componentes del Departamento de Defensa con una métrica con la que evaluar
el grado de confianza que se puede colocar en los sistemas informáticos de
el procesamiento seguro de clasificada y otra sensible
información.
* Proporcionar una base para especificar los requisitos de seguridad en
especificaciones de adquisición.
Con respecto a la segunda propósito para el desarrollo de los criterios, es decir,
proporcionando componentes del Departamento de Defensa con una métrica de evaluación de seguridad, evaluaciones, puede ser
delineado en dos tipos: (a) una evaluación puede llevarse a cabo en un equipo
producto desde una perspectiva que excluye el entorno de aplicación; o, (b)
que se puede hacer para determinar si se han tomado las medidas de seguridad adecuadas
para permitir que el sistema que se utilizará operativamente en un entorno específico. Los
primer tipo de evaluación es realizada por el Centro de seguridad de la computadora a través de la
Comercial Proceso de evaluación del producto. Ese proceso se describe en el Apéndice
A.
Este último tipo de evaluación, es decir, los que hace con el propósito de evaluar la
atributos de seguridad del sistema con respecto a una misión operativo específico,
que se conoce como una evaluación de la certificación. Se debe entender que la
realización de una evaluación formal producto no constituye certificación o
acreditación del sistema a ser utilizado en cualquier aplicación específica
ambiente. Por el contrario, el informe de evaluación sólo proporciona una confianza
Valoración de la evaluación del sistema informático junto con los datos que apoyan la descripción de la
fortalezas del sistema de productos y debilidades desde el punto de la seguridad informática
punto de vista. La certificación de la seguridad del sistema y lo formal de aprobación / acreditación
procedimiento, realizado de acuerdo con las políticas aplicables de la emisión
agencias, aún debe ser un sistema puede ser aprobado para su uso antes seguidos
procesamiento o manejo de información clasificada [8, 9]. Designado Aprobar
Autoridades (Daas) siguen siendo en última instancia responsable de especificar la seguridad de
sistemas que acreditan.
Los criterios de evaluación sistema informático de confianza se pueden utilizar directamente y
indirectamente en el proceso de certificación. Junto con la política aplicable,
se utilizarán directamente como orientación técnica para la evaluación del sistema total
y para especificar los requisitos de seguridad del sistema y de certificación para la nueva
adquisiciones. ¿Dónde está evaluando un sistema para la certificación emplea un
producto que ha sido objeto de una evaluación del producto comercial, informa de que
proceso se utiliza como entrada para la evaluación de la certificación. Datos técnicos
será proporcionada a los diseñadores, evaluadores y la Aprobando Designado
Autoridades para apoyar sus necesidades de toma de decisiones.
Fundamentales Requisitos de Seguridad Informática
Cualquier discusión sobre la seguridad informática comienza necesariamente de una declaración de
requisitos, es decir, lo que realmente significa para llamar a un sistema informático "seguro".
En general, los sistemas seguros controlarán, a través del uso de la seguridad específica
características, el acceso a la información de tal manera que sólo se autoriza correctamente
individuos o procesos que operan en su nombre, tendrá acceso a la lectura,
escribir, crear o eliminar información. Seis requisitos fundamentales son
derivada de esta declaración básica de objetivo: cuatro se refieren a lo que hay
proporcionarse para controlar el acceso a la información; y dos tratan de cómo se puede
obtener garantías creíbles de que esto se logra en un equipo de confianza
sistema.
Política
Requisito 1 - POLÍTICA DE SEGURIDAD - No debe ser una explícita y
así definidos por la política de seguridad impuesta por el sistema. Sujetos identificados Dadas
y los objetos, debe haber una serie de reglas que son utilizados por el sistema para
determinar si un sujeto dado se puede permitir para obtener acceso a una específica
objeto. Los sistemas informáticos de interés deben hacer cumplir una política de seguridad obligatoria
que puede implementar de manera efectiva las reglas de acceso para el manejo sensible (por ejemplo,
. información clasificada) [7] Estas normas incluyen requisitos tales como: No
persona que carece de espacio libre apropiado de seguridad personal deberá tener acceso a
clasificado
información. Además, se requiere que los controles de seguridad discrecionales para
garantizar que los usuarios o grupos de usuarios seleccionados sólo se puede obtener acceso a los datos
(por ejemplo, sobre la base de una necesidad de saber).
Requisito 2 - MARCADO - etiquetas de control de acceso deben estar asociados
con los objetos. Con el fin de controlar el acceso a información almacenada en un ordenador,
de acuerdo a las reglas de una política de seguridad obligatoria, debe ser posible
marcar todos los objetos con una etiqueta que identifica de forma fiable el objeto de
nivel de sensibilidad (por ejemplo, la clasificación), y / o los modos de acceso concedidos
aquellos sujetos que potencialmente pueden acceder al objeto.
Rendición de cuentas
Requisito 3 - IDENTIFICACIÓN - sujetos individuales deben ser
identificados. Cada acceso a la información debe estar mediada basa en quién es
el acceso a la información y qué clases de información que están autorizados
lidiar con. Esta información de identificación y autorización debe ser
firmemente mantenida por el sistema de ordenador y estar asociada con cada activo
elemento que realiza alguna acción relevante para la seguridad en el sistema.
Requisito 4 - RESPONSABILIDAD - La información de auditoría debe ser
guardado y protegido para que las acciones que afectan a la seguridad se pueden rastrear selectivamente
a la parte responsable. Un sistema de confianza deberá ser capaz de registrar la
ocurrencias de eventos relevantes para la seguridad en un registro de auditoría. La capacidad de
seleccionar los eventos de auditoría para ser registrados es necesario minimizar el gasto de
auditoría y para permitir el análisis eficiente. Los datos de auditoría deben ser protegidos de
modificación y destrucción no autorizada para permitir la detección y
investigaciones después de los hechos de violaciónes de seguridad.
Aseguramiento
Requisito 5 - GARANTÍA - El sistema informático debe contener
mecanismos de hardware / software que pueden ser evaluados de forma independiente para proporcionar
garantías suficientes de que el sistema impone requisitos 1 a 4 anteriores.
Con el fin de asegurar que los cuatro requisitos de la Política de Seguridad, Marcado,
Identificación, y rendición de cuentas son impuestas por un sistema informático, no
Debe haber alguna identificados y colección unificada de hardware y software
controles que realizan esas funciones. Estos mecanismos son típicamente incorporados
en el sistema operativo y están diseñados para llevar a cabo las tareas asignadas en un
manera segura. La base para confiar en este tipo de mecanismos del sistema en su
entorno operativo debe estar claramente documentado de tal manera que es posible
examinar de forma independiente las pruebas para evaluar su suficiencia.
Requisito 6 - Protección continua - Los mecanismos de confianza que
hacer cumplir estos requisitos básicos se deben proteger de forma continua contra
manipulación y / o cambios no autorizados. Ningún sistema informático puede ser considerado
realmente segura si los mecanismos básicos de hardware y software que hacen cumplir la
política de seguridad son a su vez objeto de modificaciones no autorizadas o
subversión. El requisito de protección continua tiene implicaciones directas
a lo largo del ciclo de vida del sistema informático.
Estos requisitos fundamentales forman la base para la evaluación individual
criterios aplicables para cada división de la evaluación y de clase. El interesado
Remitimos al lector a la Sección 5 de este documento, "Objetivos de Control para
Trusted Computer Systems, "para una discusión más completa y más
amplificación de estos requisitos fundamentales que se aplican a
sistemas de procesamiento de información y la Sección 7 para uso general
la amplificación de la relación entre política y estos requisitos.
Estructura del documento
El resto de este documento se divide en dos partes, cuatro apéndices y
un glosario. Parte I (Secciones 1 a la 4) presenta los criterios detallados
derivado de los requisitos fundamentales descritos anteriormente y relevante para el
fundamentos y políticas extractos contenidos en la Parte II.
Parte II (artículos 5 a 10) ofrece una discusión de los objetivos básicos,
razón de ser, y la política nacional detrás del desarrollo de los criterios y
directrices para desarrolladores relacionados con: las reglas de control de acceso obligatorio
aplicación, el problema canal secreto, y las pruebas de seguridad. Es
dividido en seis secciones. Sección 5 discute el uso de objetivos de control
en general, y presenta los tres objetivos básicos de control de los criterios.
Sección 6 proporciona la base teórica detrás de los criterios. Sección 7 da
extractos de pertinente reglamentos, directivas, circulares de la OMB, y Ejecutivo
Órdenes que proporcionan la base para muchos requisitos fiduciarios para procesamiento
información a nivel nacional sensible y clasificada con los sistemas informáticos.
Sección 8 proporciona orientación a los desarrolladores de sistemas en las expectativas en el trato
el problema canal encubierto. Sección 9 proporciona directrices tratar con
seguridad obligatoria. Sección 10 proporciona directrices para las pruebas de seguridad.
Hay cuatro apéndices, incluyendo una descripción de la Informática de confianza
Sistema de Productos Comerciales de Evaluación de proceso (Apéndice A), resúmenes de la
divisiones de evaluación (Apéndice B) y clases (Apéndice C), y, finalmente, una
directorio de los requisitos ordenados alfabéticamente. Además, hay una
glosario.
Estructura de los Criterios
Los criterios se dividen en cuatro divisiones: D, C, B y A ordenaron en un
de manera jerárquica con la división más alta (A) está reservado para los sistemas
proporcionando la seguridad más completa. Cada división representa un importante
mejora en la confianza general se puede colocar en el sistema para la
protección de la información sensible. Dentro de las divisiones C y B hay un
número de subdivisiones conocidas como clases. Las clases también se ordenan en un
de manera jerárquica con sistemas representante de la división C e inferior
clases de división B se caracterizan por el conjunto de la seguridad informática
mecanismos que poseen. Aseguramiento del correcto diseño y completa y
la implementación de estos sistemas se consigue principalmente a través de la prueba del
partes pertinentes del sistema de seguridad-. Las partes relevantes para la seguridad de
un sistema se hace referencia a lo largo de este documento como la Computación Confiable
Base (TCB). Sistemas representante de las clases más altas en la división B y
Una división de derivar los atributos de su seguridad más de su diseño y
estructura de ejecución. El aumento de la seguridad de que las características requeridas son
operativa, correcta y manipulaciones en todas las circunstancias se gana a través de
análisis cada vez más riguroso durante el proceso de diseño.
Dentro de cada clase, se abordan cuatro grandes conjuntos de criterios. El primero de tres
representar características necesarias para satisfacer los objetivos generales de control de
Política de Seguridad, Responsabilidad y Seguridad de que se discuten en la Parte II,
Sección 5. El cuarto set, Documentación, describe el tipo de escrito
pruebas en forma de guías de usuario, manuales, y la prueba y diseño
la documentación requerida para cada clase.
Un lector utilizando esta publicación por primera vez puede que le resulte útil
lea primero la parte II, antes de continuar con la Parte I.
?
PARTE I: LOS CRITERIOS
Destacando (MAYÚSCULAS) se utiliza en la primera parte para indicar criterios no contenía
en una clase inferior o cambios y adiciones a la ya definida criterios. Dónde
no hay resaltado, los requisitos han sido prorrogados del menor
clases sin adición o modificación.
?
1.0 DIVISIÓN D: protección mínima
Esta división contiene una sola clase. Se reserva para aquellos sistemas que
han sido evaluados, pero que no cumplen con los requisitos para una mayor
clase de evaluación.
?
2.0 DIVISIÓN C: PROTECCIÓN DISCRECIONAL
Las clases de esta división prevén (necesidad de conocer) la protección discrecional
y, a través de la inclusión de mecanismos de auditoría, para la rendición de cuentas
temas y las acciones que inician.
?
2.1 CLASE (C1): PROTECCIÓN DE SEGURIDAD DISCRECIONAL
La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente satisface
los requisitos de seguridad discrecionales al proporcionar separación de usuarios y
datos. Incorpora alguna forma de controles creíbles, capaces de hacer cumplir
limitaciones de acceso de forma individual, es decir, con el pretexto adecuado para
permitiendo a los usuarios para poder proteger a proyecto o información privada y
mantener a los demás usuarios de la lectura de forma accidental o la destrucción de sus datos. Los
Se espera que la clase (C1) el medio ambiente a ser uno de cooperar procesamiento usuarios
los datos en el mismo nivel (s) de la sensibilidad. Los siguientes son mínimos
requisitos para los sistemas asignados a (C1) habilitación de clase:
2.1.1 Política de Seguridad
2.1.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP. Los
mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos, el acceso
listas de control) deberán permitir a los usuarios especificar y compartir el control
de esos objetos por personas nombradas o grupos definidos o ambos.
2.1.2 Rendición de Cuentas
2.1.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB utilizará un protegida
mecanismo (por ejemplo, contraseñas) para autenticar la identidad del usuario.
El TCB deberá proteger los datos de autenticación de modo que no puede ser
visitada por cualquier usuario no autorizado.
2.1.3 Aseguramiento
2.1.3.1 Aseguramiento Operacional
2.1.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
protege de interferencias externas o manipulación
(por ejemplo, por modificación de sus código o datos strucutres).
Recursos controlados por el TCB puede ser un subconjunto definido
de los sujetos y objetos en el sistema de ADP.
2.1.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el funcionamiento correcto
de los elementos de hardware y firmware en el sitio de la TCB.
2.1.3.2 Ciclo de Vida de Garantía
2.1.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Los ensayos deben realizarse para asegurar que no hay obvia
formas para que un usuario no autorizado a pasar por alto o de otra manera
derrotar a los mecanismos de protección de la seguridad de la TCB.
(Vea las líneas directrices de ensayo de seguridad.)
2.1.4 Documentación
2.1.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
2.1.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura.
Documentación 2.1.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
los mecanismos de seguridad se pusieron a prueba, y los resultados del
pruebas funcionales mecanismos de seguridad.
2.1.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Si el TCB
se compone de módulos distintos, las interfaces entre ellas
módulos se describen.
?
2.2 CLASE (C2): PROTECCIÓN DE ACCESO CONTROLADO
Sistemas de esta clase hacen cumplir un acceso discrecional más de grano fino
usuarios de control de sistemas (C1), por lo que individualmente responsables de su
acciones a través de los procedimientos de acceso, la auditoría de los eventos relevantes para la seguridad, y
aislamiento de recursos. Los siguientes son los requisitos mínimos para los sistemas
asignado a (C2) habilitación de clase:
2.2.1 Política de Seguridad
2.2.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP. Los
mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos, el acceso
listas de control) deberán permitir a los usuarios especificar y compartir el control
de esos objetos por personas nombradas, o grupos de definido
individuos, o por ambos, y proporcionarán los controles para limitar
propagación de los derechos de acceso. El control de acceso discrecional
mecanismo deberá, ya sea por acción explícita del usuario o por defecto,
establecen que los objetos están protegidos contra el acceso no autorizado.
Estos controles de acceso deberán ser capaces de incluir o excluir
el acceso a la granularidad de un único usuario. Permiso de acceso
a un objeto por los usuarios no ya que posee permiso de acceso
sólo podrán ser asignadas por los usuarios autorizados.
2.2.1.2 Objeto Reutilización
Todas las autorizaciones de la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB
de objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado
representaciones de información, producidos por un sujeto antes de
acciones es estar a disposición de cualquier objeto que obtiene acceso
a un objeto que se ha lanzado de nuevo al sistema.
2.2.2 Rendición de Cuentas
2.2.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB utilizará un protegida
mecanismo (por ejemplo, contraseñas) para autenticar la identidad del usuario.
El TCB deberá proteger los datos de autenticación de modo que no puede ser
visitada por cualquier usuario no autorizado. El TCB deberá ser capaz de
hacer cumplir la responsabilidad individual, proporcionando la capacidad de
identificar de forma única a cada usuario del sistema ADP individual. El TCB
facilitará también la capacidad de asociar esta identidad
con todas las acciones que se pueden auditar tomadas por ese individuo.
2.2.2.2 Auditoría
El TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una auditoría
rastro de accesos a los objetos que protege. Los datos de auditoría
estarán protegidos por la TCB para que el acceso de lectura a la misma es
limitado a aquellos que están autorizados para los datos de auditoría. El TCB
será capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificación y autenticación, introducción o
objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa
iniciación), la supresión de los objetos, y las medidas adoptadas por
operadores de computadoras y administradores de sistemas y / o sistema de
oficiales de seguridad, y otros eventos relevantes de seguridad. Por
cada evento registrado, el registro de auditoría deberá identificar: fecha y
hora del evento, el usuario, el tipo de evento, y el éxito o el fracaso
del evento. Para eventos de identificación / autenticación las
origen de la solicitud (por ejemplo, el terminal ID) se incluirá en el
registro de auditoría. Para los eventos que introducen un objeto en un usuario de
espacio de direcciones y para los eventos de deleción objeto el registro de auditoría
deberá incluir el nombre del objeto. El sistema de ADP
administrador podrá auditar selectivamente las acciones de
cualquier uno o más usuarios basados en la identidad individual.
2.2.3 Aseguramiento
2.2.3.1 Aseguramiento Operacional
2.2.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
que lo protege de las interferencias externas o manipulación
(por ejemplo, por modificación de sus estructuras de código o datos).
Recursos controlados por el TCB puede ser un subconjunto definido
de los sujetos y objetos en el sistema de ADP. El TCB
deberá aislar los recursos a ser protegidas de manera que
están sujetos al control de acceso y auditoría
requisitos.
2.2.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el funcionamiento correcto
de los elementos de hardware y firmware en el sitio de la TCB.
2.2.3.2 Ciclo de Vida de Garantía
2.2.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Los ensayos deben realizarse para asegurar que no hay obvia
formas para que un usuario no autorizado a pasar por alto o de otra manera
derrotar a los mecanismos de protección de la seguridad de la TCB.
El ensayo debe incluir también una búsqueda de defectos obvios que
permitiría violación del aislamiento de los recursos, o que lo haría
permitir el acceso no autorizado a la auditoría o la autenticación
datos. (Véanse las directrices de Pruebas de Seguridad.)
2.2.4 Documentación
2.2.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
2.2.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura. Los procedimientos para
examinar y mantener los archivos de auditoría, así como la
estructura de registro de auditoría detallado para cada tipo de evento de auditoría
se le dará.
Documentación 2.2.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad
pruebas funcionales mecanismos.
2.2.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Si el TCB
se compone de módulos distintos, las interfaces entre ellas
módulos se describen.
?
3.0 DIVISIÓN B: PROTECCIÓN OBLIGATORIA
La noción de un TCB que preserve la integridad de las etiquetas de sensibilidad y
los utiliza para hacer cumplir una serie de reglas de control de acceso obligatorio es un importante
requisito en esta división. Sistemas de esta división deben llevar el
sensibilidad etiquetas con las principales estructuras de datos en el sistema. El sistema
desarrollador también ofrece el modelo de la política de seguridad en la que se basa la TCB
y proporciona una especificación de la TCB. La evidencia debe ser proporcionada a
demostrar que el concepto de monitor de referencia ha sido implementado.
?
3.1 CLASE (B1): PROTECCIÓN DE SEGURIDAD CON ETIQUETAS
Sistemas (B1) Clase requieren todas las características requeridas para la clase (C2). En
Además, una declaración informal de la modelo de la política de seguridad, el etiquetado de datos,
y control de acceso obligatorio sobre los sujetos y objetos con nombre debe estar presente.
La capacidad debe existir para marcar con precisión la información exportada. Alguna
defectos identificados por pruebas deben ser removidos. Los siguientes son mínimos
requisitos para los sistemas asignados a (B1) habilitación de clase:
3.1.1 Política de Seguridad
3.1.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP.
El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,
listas de control de acceso) se permitirá a los usuarios especificar y control
compartir de esos objetos por las personas nombradas, o grupos definidos
de los individuos, o por ambos, y le facilitará los controles para limitar
propagación de los derechos de acceso. El control de acceso discrecional
mecanismo deberá, ya sea por acción explícita del usuario o por defecto,
establecen que los objetos están protegidos contra el acceso no autorizado.
Estos controles de acceso deberán ser capaces de incluir o excluir
el acceso a la granularidad de un único usuario. Permiso de acceso
a un objeto por los usuarios no ya que posee permiso de acceso
sólo podrán ser asignadas por los usuarios autorizados.
3.1.1.2 Objeto Reutilización
Todas las autorizaciones de la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB
de objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado
representaciones de información, producidos por un sujeto antes de
acciones es estar a disposición de cualquier objeto que obtiene acceso
a un objeto que se ha lanzado de nuevo al sistema.
3.1.1.3 Las etiquetas
Etiquetas de sensibilidad asociados con cada tema y almacenamiento
objeto bajo su control (por ejemplo, proceso, archivo, segmento, dispositivo)
será mantenida por el TCB. Estas etiquetas se utilizan como
la base para las decisiones de control de acceso obligatorios. A fin de que
importar datos no etiquetados, la TCB deberá solicitar y recibir de
un usuario autorizado el nivel de seguridad de los datos, y toda esa
las acciones deberán ser auditables por el TCB.
3.1.1.3.1 Label Integridad
Etiquetas de sensibilidad deberán representar con precisión la seguridad
niveles de los sujetos u objetos específicos con los que se
están asociados. Cuando exportado por el TCB, la sensibilidad
la etiqueta incluirá la precisión y sin ambigüedades representar el
etiquetas internas y estará asociada a la
información que se exporta.
3.1.1.3.2 Exportación de Información Etiquetada
El TCB designará cada canal de comunicación y
Yo dispositivo de E / S, ya sea a nivel individual o miltilevel. Alguna
cambio en esta designación se realiza de forma manual y
será auditable por el TCB. El TCB mantendrá
y ser capaz de auditar a cualquier cambio en el nivel de seguridad
o los niveles asociados con un canal de comunicación o
Dispositivo de E / S.
3.1.1.3.2.1 La exportación a dispositivos multinivel
Cuando la TCB exporta un objeto a un multinivel I / O
dispositivo, la etiqueta sensibilidad asociada con ese
objeto también se exportará y deberá residir en
el mismo medio físico como el exportado
información y se hará de la misma forma
(es decir, legible por máquina o en forma legible).
Cuando la TCB exporta o importa un objeto durante un
canal de comunicación de múltiples niveles, el protocolo
utilizado en ese canal deberá prever la
vinculación inequívoca entre las etiquetas de sensibilidad
y la información asociada que se envía o
recibido.
3.1.1.3.2.2 Exportación a solo nivel-Devices
Dispositivos S-nivel individual de E / y de un solo nivel
los canales de comunicación no están obligados a
mantener las etiquetas de sensibilidad de la información
que procesan. Sin embargo, la TCB incluirá una
mecanismo por el cual la TCB y un usuario autorizado
comunicar de forma confiable para designar la única
nivel de seguridad de la información importado o exportado
a través de los canales de comunicación de un solo nivel o de E / S
dispositivos.
3.1.1.3.2.3 salida etiquetado legible
El administrador del sistema ADP deberá ser capaz de
especificar los nombres de las etiquetas imprimibles asociados a
etiquetas de sensibilidad exportados. El TCB marcará
el principio y el fin de toda paginado legible,,
salida en papel (por ejemplo, la salida de impresora de líneas) con
etiquetas de sensibilidad legibles que correctamente *
representar la sensibilidad de la salida. El TCB
será, será por defecto, marque la parte superior e inferior de cada
página de la salida legible, paginado, en papel
(por ejemplo, impresora de línea de salida) con legible
etiquetas de sensibilidad que correctamente * representan la
sensibilidad global de la salida o que correctamente *
representar la sensibilidad de la información sobre la
página. El TCB deberá, por defecto y en un
de manera adecuada, marcar otras formas de humanidad
salida legible (por ejemplo, mapas, gráficos) con humanidad
etiquetas de sensibilidad legibles que correctamente *
representar la sensibilidad de la touput. Alguna
anulación de estos incumplimientos marcado será
auditable por el TCB.
3.1.1.4 Control de Acceso Obligatorio
El TCB deberá aplicar una política de control de acceso obligatorio sobre
todas las materias y objetos de almacenamiento bajo su control (por ejemplo,
procesos, archivos, segmentos, dispositivos). Estos temas y
objetos se les asignará etiquetas de sensibilidad que son un
combinación de niveles jerárquicos de clasificación y
categorías no jerárquica, y las etiquetas se utilizan como
la base para las decisiones de control de acceso obligatorios. El TCB
deberá ser capaz de soportar dos o más de tales niveles de seguridad.
(Vea las pautas para el control de acceso obligatorio). El siguiente
requisitos permanecerán en para todos los accesos entre sujetos y
objetos controlados por el TCB: un tema pueden leer un objeto
sólo si la clasificación jerárquica en el tema de
nivel de seguridad es mayor o igual a la jerárquica
clasificación en el nivel de seguridad del objeto y de la no-
categorías jerárquicas en el nivel de seguridad del sujeto incluyen
todas las categorías no jerárquicas en la seguridad del objeto
nivel. Un sujeto puede escribir un objeto sólo si el jerárquica
clasificación en el nivel de seguridad del sujeto es inferior o
igual a la clasificación jerárquica en el objeto de
nivel de seguridad y todas las categorías no jerárquicas en la
nivel de seguridad del sujeto se incluyen en el no-jerárquica
categorías en el nivel de seguridad del objeto. Identificación
y los datos de autenticación se utilizarán por el TCB para autenticarse
Cate la identidad del usuario y para asegurar que el nivel de seguridad
y la autorización de los sujetos externo a la TCB que puede ser
creado para actuar en nombre de cada usuario están dominadas
por la liquidación y la ordenación de ese usuario.
3.1.2 Rendición de Cuentas
3.1.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB deberá mantener la autenticación
datos que incluye información para la verificación de la identidad de
los usuarios individuales (por ejemplo, contraseñas), así como información para
la determinación de la compensación y las autorizaciones o individuo
_____________________________
* El componente de clasificación jerárquica de la sensibilidad legible
etiquetas serán iguales a la mayor clasificación jerárquica o cualquiera de los
información en la salida que las etiquetas se refieren a; la no-jerárquica
componente categoría incluirá todas las categorías no jerárquicas de la
información en la salida de las etiquetas se refieren a, pero ningún otro no jerárquica
categorías.
usuarios. Estos datos podrán ser utilizados por la TCB para autenticar el
la identidad del usuario y para asegurar que el nivel de seguridad y
autorizaciones de sujetos externos a la TCB que puede ser
creado para actuar en nombre de cada usuario están dominadas
por la liquidación y la ordenación de ese usuario. El TCB deberá
proteger los datos de autenticación de modo que no se puede acceder por cualquier
usuario no autorizado. El TCB será capaz de hacer cumplir individuo
la rendición de cuentas, proporcionando la capacidad para identificar de forma única
cada usuario del sistema ADP individual. El TCB facilitará asimismo a la
capacidad de asociar esta identidad con toda auditable
medidas adoptadas por ese individuo.
3.1.2.2 Auditoría
El TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una auditoría
rastro de accesos a los objetos que protege. Los datos de auditoría
estarán protegidos por la TCB para que el acceso de lectura a la misma es
limitado a aquellos que están autorizados para los datos de auditoría. El TCB
será capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificación y autenticación, la introducción de
objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa
iniciación), la supresión de los objetos, y las medidas adoptadas por el ordenador
operadores y administradores de sistemas y / o la seguridad del sistema
oficiales y otros eventos relevantes de seguridad. El TCB deberá también
ser capaz de auditar cualquier anulación de las marcas de salida legibles.
Para cada evento registrado, el registro de auditoría deberá identificar: Fecha
y la hora del evento, el usuario, el tipo de evento, y el éxito o
fracaso del evento. Para eventos de identificación / autenticación
el origen de la solicitud (por ejemplo, la terminal ID) se incluye en
el registro de auditoría. Para los eventos que introducen un objeto en un
espacio de direcciones del usuario y para eventos de eliminación de objetos de la auditoría
expediente deberá incluir el nombre del objeto y el objeto de
nivel de seguridad. El administrador del sistema ADP deberá ser capaz de
auditar de forma selectiva las medidas adoptadas por uno o más usuarios en función de
identidad individual y / o el nivel de seguridad de objetos.
3.1.3 Aseguramiento
3.1.3.1 Aseguramiento Operacional
3.1.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
que lo protege de las interferencias externas o manipulación
(por ejemplo, por modificación de sus estructuras de código o datos).
Recursos controlados por el TCB puede ser un subconjunto definido
de los sujetos y objetos en el sistema de ADP. El TCB
deberá mantener el aislamiento de procesos a través de la provisión de
espacios de direcciones distintas bajo su control. El TCB deberá
aislar los recursos para estar protegidos de manera que sean
sujeto al control de acceso y los requisitos de auditoría.
3.1.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el funcionamiento correcto
de los elementos de hardware y firmware en el sitio de la TCB.
3.1.3.2 Ciclo de Vida de Garantía
3.1.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Un equipo de personas que entienden a fondo la
aplicación específica de la TCB someterá su
documentación de diseño, código fuente y el código objeto para
análisis y pruebas exhaustivas. Sus objetivos serán:
para descubrir todos los defectos de diseño y de ejecución que
permitir que un objeto externo a la TCB para leer, cambiar o
delete normalmente datos negados bajo el obligatorio o
política de seguridad discrecional impuesta por la TCB; así como
que se asegure de que ningún objeto (sin autorización hacer
de modo) es capaz de hacer que el TCB para entrar en un estado tal que
es incapaz de responder a las comunicaciones iniciadas por
otros usuarios. Todos los defectos descubiertos serán removidos o
neutraliza y el TCB repetir la prueba para demostrar que
se han eliminado y que los nuevos defectos no han sido
introducido. (Vea las líneas directrices de ensayo de seguridad.)
3.1.3.2.2 Especificaciones de Diseño y Verificación
Un modelo formal o informal de la política de seguridad
el apoyo de la TCB se mantendrá durante la vida
ciclo del sistema ADP y ha demostrado ser consistente
con sus axiomas.
3.1.4 Documentación
3.1.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
3.1.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura. Los procedimientos para
examinar y mantener los archivos de auditoría, así como la
estructura de registro de auditoría detallado para cada tipo de evento de auditoría
se le dará. El manual deberá describir el operador y
funciones de administrador relacionados con la seguridad, que incluyen el cambio
las características de seguridad de un usuario. Facilitará
directrices sobre el uso coherente y eficaz de la protección
características del sistema, cómo interactúan, la forma de forma segura
generar un nuevo TCB, y procedimientos de las instalaciones, las advertencias, y
privilegios que necesitan ser controladas con el fin de operar el
instalación de una manera segura.
Documentación 3.1.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad
pruebas funcionales mecanismos.
3.1.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Si el TCB
se compone de módulos distintos, las interfaces entre ellas
módulos se describen. Una descripción informal o formal
del modelo de política de seguridad aplicada por el TCB será
disponibles y una explicación proporcionada a demostrar que es
suficiente para hacer cumplir la política de seguridad. El TCB específica
mecanismos de protección deben ser identificados y una explicación
dado para demostrar que satisfacen el modelo.
?
3.2 CLASE (B2): PROTECCIÓN ESTRUCTURADO
En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y documentado
modelo de política de seguridad formal que requiere el discrecional y obligatorio
la aplicación de control de acceso que se encuentra en los sistemas (B1) de clase se extenderá a todos
sujetos y objetos en el sistema de ADP. Además, los canales encubiertos son
abordarse. El TCB debe estructurarse con cuidado en la protección-crítico y
elementos de protección crítico no. La interfaz de TCB está bien definido y de la
Diseño e implementación TCB permiten que pueda ser sometido a más exhaustiva
pruebas y revisión más completa. Mecanismos de autenticación se fortalecen,
la gestión de instalaciones de confianza se proporciona en forma de soporte para el sistema
funciones de administrador y operador, y gestión de la configuración estrictas
se imponen controles. El sistema es relativamente resistente a la penetración. Los
siguientes son los requisitos mínimos para los sistemas asignados a (B2) habilitación de clase:
3.2.1 Política de Seguridad
3.2.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP.
El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,
listas de control de acceso) se permitirá a los usuarios especificar y control
compartir de esos objetos por las personas nombradas, o definido
grupos de individuos, o por ambos, y proporcionarán los controles
para limitar la propagación de los derechos de acceso. El acceso discrecional
mecanismo de control deberá, ya sea por acción explícita del usuario o por
De forma predeterminada, se establece que los objetos están protegidos de la no autorizada
el acceso. Estos controles de acceso deberán ser capaces de incluir
o excluir el acceso a la granularidad de un único usuario.
El permiso de acceso a un objeto por los usuarios no ya que posee
permiso de acceso sólo podrá ser cedido por los usuarios autorizados.
3.2.1.2 Objeto Reutilización
Todas las autorizaciones de la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB de
objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado
representaciones de información, producidos por un sujeto antes de
acciones es estar a disposición de cualquier objeto que obtiene acceso
a un objeto que se ha lanzado de nuevo al sistema.
3.2.1.3 Las etiquetas
Etiquetas de sensibilidad asociados con cada recurso del sistema ADP
(por ejemplo, el asunto objeto de almacenamiento, ROM) que es directa o
indirectamente accesible por sujetos ajenos a la TCB será
mantenida por el TCB. Estas etiquetas se utilizan como base
para las decisiones de control de acceso obligatorios. Para importar
datos no etiquetados, la TCB deberán solicitar y recibir de un
usuario autorizado el nivel de seguridad de los datos, y toda esa
las acciones deberán ser auditables por el TCB.
3.2.1.3.1 Label Integridad
Etiquetas de sensibilidad deberán representar con precisión la seguridad
niveles de los temas específicos u objetos con los que
están asociados. Cuando exportado por el TCB,
etiquetas de sensibilidad deberá precisión y sin ambigüedades
representar las etiquetas internas y estará asociada
con que se exporta la información.
3.2.1.3.2 Exportación de Información Etiquetada
El TCB designará cada canal de comunicación y
Yo dispositivo de E / S, ya sea a nivel individual o de múltiples niveles. Alguna
cambio en esta designación se realiza de forma manual y
será auditable por el TCB. El TCB mantendrá
y ser capaz de auditar a cualquier cambio en el nivel de seguridad
o los niveles asociados con un canal de comunicación o
Dispositivo de E / S.
3.2.1.3.2.1 La exportación a dispositivos multinivel
Cuando la TCB exporta un objeto a un multinivel I / O
dispositivo, la etiqueta sensibilidad asociada con ese
objeto también se exportará y deberá residir en
el mismo medio físico como el exportado
información y se hará de la misma forma (es decir,
legible por máquina o en forma legible). Cuando
la TCB exporta o importa un objeto durante un
canal de comunicación de múltiples niveles, el protocolo
utilizado en ese canal deberá prever la
vinculación inequívoca entre las etiquetas de sensibilidad
y la información asociada que se envía o
recibido.
3.2.1.3.2.2 Exportación a solo nivel-Devices
Dispositivos S-nivel individual de E / y de un solo nivel
los canales de comunicación no están obligados a
mantener las etiquetas de sensibilidad de la
información que procesan. Sin embargo, la TCB deberá
incluir un mecanismo por el cual el TCB y una
usuario autorizado comunicar de forma fiable para designar
el nivel de seguridad única de información importada
o exportados a través de la comunicación de un solo nivel
los canales o dispositivos de E / S.
3.2.1.3.2.3 salida etiquetado legible
El administrador del sistema ADP deberá ser capaz de
especificar los nombres de las etiquetas imprimibles asociados a
etiquetas de sensibilidad exportados. El TCB marcará
el principio y el fin de toda paginado legible,,
salida en papel (por ejemplo, la salida de impresora de líneas) con
etiquetas de sensibilidad legibles que correctamente *
representar la sensibilidad de la salida. El TCB
será, por defecto, marque la parte superior e inferior de cada
página de la salida legible, paginado, en papel
(por ejemplo, impresora de línea de salida) con legible
etiquetas de sensibilidad que correctamente * representan la
sensibilidad global de la salida o que
* representar adecuadamente la sensibilidad de la
información en la página. El TCB, a más tardar
por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas,
gráficos) con etiquetas de sensibilidad legibles
que adecuadamente * representan la sensibilidad de la
de salida. Cualquier anulación de estos incumplimientos marcado
será auditable por el TCB.
3.2.1.3.3 Asunto etiquetas de sensibilidad
El TCB notificará inmediatamente a un usuario del terminal de cada
cambio en el nivel de seguridad asociado a ese usuario
durante una sesión interactiva. Un usuario del terminal será
capaz de consultar la TCB como se desee para una visualización de la
etiqueta de sensibilidad completa del tema.
3.2.1.3.4 Las etiquetas de dispositivo
El TCB apoyará la asignación de mínima y
niveles de máxima seguridad a todos los dispositivos físicos conectados.
Estos niveles de seguridad deberán ser utilizados por el TCB para hacer cumplir
las restricciones impuestas por el entorno físico en el que
los dispositivos se encuentran.
3.2.1.4 Control de Acceso Obligatorio
El TCB deberá aplicar una política de control de acceso obligatorio sobre
todos los recursos (por ejemplo, temas, objetos de almacenamiento, y dispositivos de E / S
que estén directa o indirectamente accesible por temas externos
a la TCB. Estos sujetos y objetos se asignarán
etiquetas de sensibilidad que son una combinación de jerárquica
niveles de clasificación y categorías no jerárquicas, y la
etiquetas se utilizan como base para el control de acceso obligatorio
decisiones. El TCB deberá ser capaz de soportar dos o más de tales
los niveles de seguridad. (Véanse las directrices de control de acceso obligatorios.)
Los siguientes requisitos deberán mantener durante todos los accesos entre
Todos los sujetos externos a la TCB y todos los objetos directamente o
indirectamente accesible por estos temas: Un sujeto puede leer un
objetar sólo si la clasificación jerárquica en el tema de
nivel de seguridad es mayor o igual a la jerárquica
clasificación en el nivel de seguridad del objeto y de la no-
categorías jerárquicas en el nivel de seguridad del sujeto incluyen
todas las categorías no jerárquicas en la seguridad del objeto
nivel. Un sujeto puede escribir un objeto sólo si el jerárquica
clasificación en el nivel de seguridad del sujeto es inferior o
igual a la clasificación jerárquica en el objeto de
nivel de seguridad y todas las categorías no jerárquicas en la
nivel de seguridad del sujeto se incluyen en el no-jerárquica
categorías en el nivel de seguridad del objeto. Identificación y
datos de autenticación se utilizarán por el TCB para autenticar
la identidad del usuario y para asegurar que el nivel de seguridad y
autorización de los sujetos externo a la TCB que puede ser
creado para actuar en nombre de cada usuario están dominadas
por la liquidación y la ordenación de ese usuario.
3.2.2 Rendición de Cuentas
3.2.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB deberá mantener la autenticación
datos que incluye información para la verificación de la identidad de
los usuarios individuales (por ejemplo, contraseñas), así como información para
la determinación de la compensación y las autorizaciones de individuo
usuarios. Estos datos podrán ser utilizados por la TCB para autenticar el
la identidad del usuario y para asegurar que el nivel de seguridad y
autorizaciones de sujetos externos a la TCB que puede ser
creado para actuar en nombre del usuario individual están dominadas por
la liquidación y autorización de ese usuario. El TCB deberá
proteger los datos de autenticación de modo que no se puede acceder por cualquier
usuario no autorizado. El TCB será capaz de hacer cumplir individuo
la rendición de cuentas, proporcionando la capacidad para identificar de forma única
cada usuario del sistema ADP individual. El TCB facilitará asimismo a la
capacidad de asociar esta identidad con toda auditable
medidas adoptadas por ese individuo.
3.2.2.1.1 Camino de confianza
El TCB apoyará una ruta de comunicación de confianza
entre él mismo y el usuario de inicio de sesión inicial y
autenticación. Comunicaciones a través de este camino serán
iniciado exclusivamente por un usuario.
3.2.2.2 Auditoría
El TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una auditoría
rastro de accesos a los objetos que protege. Los datos de auditoría
estarán protegidos por la TCB para que el acceso de lectura a la misma es
limitado a aquellos que están autorizados para los datos de auditoría. El TCB
será capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificación y autenticación, la introducción de
objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa
iniciación), la supresión de los objetos, y las medidas adoptadas por el ordenador
operadores y administradores de sistemas y / o la seguridad del sistema
oficiales y otros eventos relevantes de seguridad. El TCB deberá
También podrá auditar cualquier anulación de la salida legible
marcas. Para cada evento registrado, el registro de auditoría,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y
éxito o el fracaso del evento. Para la identificación /
eventos de autenticación del origen de la solicitud (por ejemplo, la terminal de Identificación)
se incluirán en el registro de auditoría. Para los eventos que
introducir un objeto en el espacio de direcciones de un usuario y para el objeto
eventos de eliminación del registro de auditoría deberán incluir el nombre de la
objeto y nivel de seguridad del objeto. El sistema de ADP
administrador podrá auditar selectivamente las acciones de
cualquier uno o más usuarios en base a la identidad y / o objeto individual
nivel de seguridad. El TCB podrá auditar el identificada
eventos que se pueden utilizar en la explotación de almacenamiento encubierta
canales.
3.2.3 Aseguramiento
3.2.3.1 Aseguramiento Operacional
3.2.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
que lo protege de las interferencias externas o manipulación
(por ejemplo, por modificación de sus estructuras de código o datos).
El TCB deberá mantener el aislamiento de procesos a través de la
provisión de espacios de direcciones distintas bajo su control.
La TCB se estructurará internamente en bien definido
módulos en gran medida independientes. Se hará uso efectivo
de hardware disponible para separar aquellos elementos que son
protección-crítico de los que no lo son. El TCB
módulos deberán estar diseñados de tal manera que el principio de mínima
privilegio se hace cumplir. Características de hardware, tales como
segmentación, se utilizará para apoyar lógicamente distinta
objetos de almacenamiento con atributos diferentes (a saber:
lectura, escritura). La interfaz de usuario a la TCB
deberá estar totalmente definido y todos los elementos de la TCB
identificados.
3.2.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el correcto
funcionamiento de los elementos de hardware y firmware en el sitio
del TCB.
3.2.3.1.3 Análisis Canal Covert
El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para
canales de almacenamiento encubiertas y tomar una determinación (ya sea
por medición real o por estimación de ingeniería) de
el máximo ancho de banda de cada canal identificado. (Véase
la sección encubierta canales guía.)
3.2.3.1.4 Gestión de Instalaciones de confianza
El TCB apoyará operador independiente y administrador
funciones.
3.2.3.2 Ciclo de Vida de Garantía
3.2.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Un equipo de personas que entienden a fondo la
aplicación específica de la TCB someterá su
documentación de diseño, código fuente y el código objeto para
análisis y pruebas exhaustivas. Sus objetivos serán:
para descubrir todos los defectos de diseño y de ejecución que
permitir que un objeto externo a la TCB para leer, cambiar o
delete normalmente datos negados bajo el obligatorio o
política de seguridad discrecional impuesta por la TCB; así como
que se asegure de que ningún objeto (sin autorización hacer
de modo) es capaz de hacer que el TCB para entrar en un estado tal que se
es incapaz de responder a las comunicaciones iniciadas por otra
usuarios. El TCB se encuentra relativamente resistentes a la
penetración. Todos los defectos detectados serán corregidos y
la TCB repetir la prueba para demostrar que han sido
eliminados y no se han introducido que los nuevos defectos.
El ensayo debe demostrar que la aplicación TCB es
consistente con la memoria descriptiva de nivel superior.
(Vea las líneas directrices de ensayo de seguridad.)
3.2.3.2.2 Especificaciones de Diseño y Verificación
Un modelo formal de la política de seguridad con el apoyo de la
TCB se mantiene a lo largo del ciclo de vida de la ADP
sistema que se ha demostrado en consonancia con sus axiomas. LA
memoria descriptiva de nivel superior (DTLS) de la TCB
se sostuvo que completa y precisa
describe la TCB en términos de excepciones, mensajes de error,
y efectos. Queda demostrado ser un exacto
Descripción de la interfaz de TCB.
Gestión de la Configuración 3.2.3.2.3
Durante el desarrollo y mantenimiento de la TCB, una
sistema de gestión de la configuración será en el lugar que
mantiene el control de cambios en el nivel superior descriptiva
especificación, otros datos de diseño, implementación
documentación, código fuente, el funcionamiento del versiónde
código objeto, y accesorios de la prueba y la documentación. Los
sistema de gestión de la configuración deberá asegurar una coherente
mapeo entre toda la documentación y el código asociado con
la versión actual de la TCB. Herramientas se proporcionarán
para la generación de una nueva versión de la TCB de la fuente
código. También disponible serán herramientas para la comparación de una
versión recién generada con la versión anterior TCB en
Para asegurarse de que sólo los cambios previstos tienen
ha logrado en el código que realmente se utiliza como
nueva versión de la TCB.
3.2.4 Documentación
3.2.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
3.2.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura. Los procedimientos para
examinar y mantener los archivos de auditoría, así como la
estructura de registro de auditoría detallado para cada tipo de evento de auditoría
se le dará. El manual deberá describir el operador y
funciones de administrador relacionados con la seguridad, que incluyen
el cambio de las características de seguridad de un usuario. Incluirá
proporcionar directrices sobre el uso coherente y eficaz de la
características de protección del sistema, cómo interactúan, cómo
segura de generar una nueva TCB, y procedimientos de las instalaciones, las advertencias,
y los privilegios que necesitan ser controlados con el fin de operar
la instalación de un modo seguro. Los módulos de TCB que contienen
deberá identificarse el mecanismo de validación de referencia. Los
procedimientos para la generación segura de un nuevo TCB de la fuente después
Se describirá la modificación de cualquiera de los módulos en el TCB.
Documentación 3.2.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad
pruebas funcionales mecanismos. Incluirá resultados de
probar la eficacia de los métodos utilizados para reducir encubierta
anchos de banda de canal.
3.2.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Los
Se describirán las interfaces entre los módulos de TCB. LA
descripción formal del modelo de política de seguridad aplicada por el
TCB deberá estar disponible y demostrado que es suficiente para
hacer cumplir la política de seguridad. La protección específica TCB
mecanismos deberán ser identificados y una explicación dan para mostrar
que cumplan el modelo. El alto nivel descriptivo
especificación (DTLS) se muestra como una precisa
Descripción de la interfaz de TCB. La documentación debe describir
cómo el TCB implementa el concepto monitor de referencia y dar
una explicación por qué es resistente a la manipulación, no puede ser anulada,
y se ha implementado correctamente. La documentación debe describir cómo
la TCB está estructurado para facilitar las pruebas y hacer cumplir menos
privilegio. Esta documentación deberá presentar también los resultados
del análisis canal encubierto y las compensaciones involucradas en
restringiendo los canales. Todos los eventos auditables que pueden ser
utilizado en la explotación de canales de almacenamiento encubiertas conocidas deberá
ser identificado. Los anchos de banda de los canales de almacenamiento encubiertas conocidas
cuyo uso no es detectable por los mecanismos de auditoría,
se facilitará. (Vea la sección de Orientación del canal Covert.)
?
3.3 CLASE (B3): DOMINIOS DE SEGURIDAD
La clase (B3) TCB debe satisfacer los requisitos del monitor de referencia que
mediar en todos los accesos de los sujetos a los objetos, será inviolable, y ser pequeño
suficiente para ser sometidos a análisis y pruebas. Para este fin, la TCB es
estructurado para excluir el código no es esencial para la aplicación de la política de seguridad, con
ingeniería de sistemas significativa durante el diseño y la aplicación dirigida TCB
para minimizar su complejidad. Un administrador de seguridad es compatible,
mecanismos de auditoría se expanden para señalar acontecimientos seguridad- pertinentes, y el sistema
se requieren procedimientos de recuperación. El sistema es altamente resistente a
penetración. Los siguientes son los requisitos mínimos para los sistemas asignado un
clase (B3) Valoración:
3.1.1 Política de Seguridad
3.3.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP.
El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá
permiten a los usuarios especificar y compartir el control de esos objetos,
y proporcionará controles para limitar la propagación de acceso
los derechos. El mecanismo de control de acceso discrecional deberá,
ya sea por acción explícita del usuario o por defecto, disponer que
objetos están protegidos contra el acceso no autorizado. Estos acceso
controles deberán ser capaces de especificar, para cada objeto nombrado,
una lista de personas con nombre y una lista de los grupos de llamada
individuos con sus respectivos modos de acceso a ese
objeto. Además, para cada uno de tales objeto nombrado, será
posible especificar una lista de personas con nombre y una lista de
grupos de individuos nombrados para la que no tiene acceso al objeto es
que debe darse. El permiso de acceso a un objeto no usuarios
ya que posee permiso de acceso sólo podrá ser cedido por
los usuarios autorizados.
3.3.1.2 Objeto Reutilización
Todas las autorizaciones de la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB
de objetos de almacenamiento no utilizados. No hay información, incluyendo
representaciones cifrados de información, producidos por una previa
las acciones de los sujetos es estar a disposición de cualquier tema que obtiene
el acceso a un objeto que se ha lanzado de nuevo al sistema.
3.3.1.3 Las etiquetas
Etiquetas de sensibilidad asociados con cada recurso del sistema ADP
(por ejemplo, el asunto objeto de almacenamiento, ROM) que es directa o
indirectamente accesible por sujetos ajenos a la TCB será
mantenida por el TCB. Estas etiquetas se utilizan como base
para las decisiones de control de acceso obligatorios. Para importar
datos no etiquetados, la TCB deberán solicitar y recibir de un
usuario autorizado el nivel de seguridad de los datos, y toda esa
las acciones deberán ser auditables por el TCB.
3.3.1.3.1 Label Integridad
Etiquetas de sensibilidad deberán representar con precisión la seguridad
niveles de los temas específicos u objetos con los que
están asociados. Cuando exportado por el TCB,
etiquetas de sensibilidad deberá precisión y sin ambigüedades
representar las etiquetas internas y estará asociada
con que se exporta la información.
3.3.1.3.2 Exportación de Información Etiquetada
El TCB designará cada canal de comunicación y
Yo dispositivo de E / S, ya sea a nivel individual o de múltiples niveles. Alguna
cambio en esta designación se realiza de forma manual y
será auditable por el TCB. El TCB mantendrá
y ser capaz de auditar a cualquier cambio en el nivel de seguridad
o los niveles asociados con un canal de comunicación o
Dispositivo de E / S.
3.3.1.3.2.1 La exportación a dispositivos multinivel
Cuando la TCB exporta un objeto a un multinivel I / O
dispositivo, la etiqueta sensibilidad asociada con ese
objeto también se exportará y deberá residir en
el mismo medio físico como el exportado
información y se hará de la misma forma (es decir,
legible por máquina o en forma legible). Cuando
la TCB exporta o importa un objeto durante un
canal de comunicación de múltiples niveles, el protocolo
utilizado en ese canal deberá prever la
vinculación inequívoca entre las etiquetas de sensibilidad
y la información asociada que se envía o
recibido.
3.3.1.3.2.2 Exportación a solo nivel-Devices
Dispositivos S-nivel individual de E / y de un solo nivel
los canales de comunicación no están obligados a
mantener las etiquetas de sensibilidad de la información
que procesan. Sin embargo, la TCB incluirá una
mecanismo por el cual la TCB y un usuario autorizado
comunicar de forma confiable para designar la única
nivel de seguridad de la información importado o exportado
a través de los canales de comunicación de un solo nivel o de E / S
dispositivos.
3.3.1.3.2.3 salida etiquetado legible
El administrador del sistema ADP deberá ser capaz de
especificar los nombres de las etiquetas imprimibles asociados a
etiquetas de sensibilidad exportados. El TCB marcará
el principio y el fin de toda paginado legible,,
salida en papel (por ejemplo, la salida de impresora de líneas) con
etiquetas de sensibilidad legibles que correctamente *
representar la sensibilidad de la salida. El TCB
será, por defecto, marque la parte superior e inferior de cada
página de la salida legible, paginado, en papel
(por ejemplo, impresora de línea de salida) con legible
etiquetas de sensibilidad que correctamente * representan la
sensibilidad global de la salida o que
* representar adecuadamente la sensibilidad de la
información en la página. El TCB, a más tardar
por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas,
gráficos) con etiquetas de sensibilidad legibles
que adecuadamente * representan la sensibilidad de la
de salida. Cualquier anulación de estos incumplimientos marcado
será auditable por el TCB.
3.3.1.3.3 Asunto etiquetas de sensibilidad
El TCB notificará inmediatamente a un usuario del terminal de cada
cambio en el nivel de seguridad asociado a ese usuario
durante una sesión interactiva. Un usuario del terminal será
capaz de consultar la TCB como se desee para una visualización de la
etiqueta de sensibilidad completa del tema.
3.3.1.3.4 Las etiquetas de dispositivo
El TCB apoyará la asignación de mínima y
niveles de máxima seguridad a todos los dispositivos físicos conectados.
Estos niveles de seguridad deberán ser utilizados por el TCB para hacer cumplir
las restricciones impuestas por el entorno físico en el que
los dispositivos se encuentran.
3.3.1.4 Control de Acceso Obligatorio
El TCB deberá aplicar una política de control de acceso obligatorio sobre
todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S
dispositivos) que están directa o indirectamente accesible por temas
externo a la TCB. Estos sujetos y objetos serán
etiquetas de sensibilidad asignados que son una combinación de
niveles de clasificación jerárquica y no jerárquica
categorías y las etiquetas se utilizan como base para
las decisiones de control de acceso obligatorios. El TCB deberá ser capaz de
el apoyo de dos o tales niveles más seguridad. (Vea la obligatoria
______________________________
* El componente de clasificación jerárquica de la sensibilidad legible
etiquetas serán iguales a la mayor clasificación jerárquica de cualquiera de los
información en la salida que las etiquetas se refieren a; la no-jerárquica
componente categoría incluirá todas las categorías no jerárquicas de la
información en la salida de las etiquetas se refieren a, pero ningún otro no jerárquica
categorías.
Directrices de control de acceso.) Las siguientes condiciones se
mantener durante todos los accesos entre todos los sujetos externos a la TCB
y todos los objetos directamente o indirectamente accesible por éstos
temas: Un sujeto puede leer un objeto sólo si el jerárquica
clasificación en el nivel de seguridad del sujeto es mayor que
o igual a la clasificación jerárquica en el objeto de
nivel de seguridad y las categorías no jerárquicas en la
nivel de seguridad del sujeto incluye todos los no-jerárquica
categorías en el nivel de seguridad del objeto. Un sujeto puede escribir
un objeto sólo si la clasificación jerárquica en el
nivel de seguridad del sujeto es inferior o igual a la
clasificación jerárquica en el nivel de seguridad del objeto y
todas las categorías no jerárquicas en la seguridad del sujeto
nivel se incluyen en las categorías jerárquicas no en el
nivel de seguridad del objeto. Identificación y autentificación
datos serán utilizados por el TCB para autenticar al usuario de
identidad y para asegurar que el nivel de seguridad y autorización
zación de los sujetos externos a la TCB que se puede crear
para actuar en nombre de cada usuario están dominadas por el
aclaramiento y la autorización de dicho usuario.
3.3.2 Rendición de Cuentas
3.3.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB deberá mantener la autenticación
datos que incluye información para la verificación de la identidad de
los usuarios individuales (por ejemplo, contraseñas), así como información para
la determinación de la compensación y las autorizaciones de individuo
usuarios. Estos datos podrán ser utilizados por la TCB para autenticar el
la identidad del usuario y para asegurar que el nivel de seguridad y
autorizaciones de subjectsexternal a la TCB que puede ser
creado para actuar en nombre de cada usuario están dominadas
por la liquidación y la ordenación de ese usuario. El TCB deberá
proteger los datos de autenticación de modo que no se puede acceder por cualquier
usuario no autorizado. El TCB será capaz de hacer cumplir individuo
la rendición de cuentas, proporcionando la capacidad para identificar de forma única
cada usuario del sistema ADP individual. El TCB facilitará asimismo a la
capacidad de asociar esta identidad con toda auditable
medidas adoptadas por ese individuo.
3.3.2.1.1 Camino de confianza
El TCB apoyará una ruta de comunicación de confianza
entre ella misma y los usuarios para el uso cuando un TCB-a-positivo
Se requiere conexión de usuario (por ejemplo, inicio de sesión, cambio de tema
nivel de seguridad). Comunicaciones a través de este camino de confianza
deberá ser activado exclusivamente por un usuario de la TCB y
deberán estar aislados de manera lógica y sin lugar a dudas
distinguible de otros caminos.
3.3.2.2 Auditoría
El TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una auditoría
rastro de accesos a los objetos que protege. Los datos de auditoría
estarán protegidos por la TCB para que el acceso de lectura a la misma es
limitado a aquellos que están autorizados para los datos de auditoría. El TCB
será capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificación y autenticación, la introducción de
objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa
iniciación), la supresión de los objetos, y las medidas adoptadas por el ordenador
operadores y administradores de sistemas y / o la seguridad del sistema
oficiales y otros eventos relevantes de seguridad. El TCB deberá también
ser capaz de auditar cualquier anulación de las marcas de salida legibles.
Para cada evento registrado, el registro de auditoría deberá identificar: Fecha
y la hora del evento, el usuario, el tipo de evento, y el éxito o
fracaso del evento. Para eventos de identificación / autenticación
el origen de la solicitud (por ejemplo, la terminal ID) se incluye en
el registro de auditoría. Para los eventos que introducen un objeto en un
espacio de direcciones del usuario y para eventos de eliminación de objetos de la auditoría
expediente deberá incluir el nombre del objeto y el objeto de
nivel de seguridad. El administrador del sistema ADP deberá ser capaz de
auditar de forma selectiva las medidas adoptadas por uno o más usuarios en función de
identidad individual y / o el nivel de seguridad de objetos. El TCB deberá
ser capaz de auditar los eventos identificados que se pueden utilizar en el
explotación de los canales de almacenamiento encubiertas. El TCB contendrá
un mecanismo que es capaz de monitorear la ocurrencia o
acumulación de eventos auditables de seguridad que puedan indicar una
inminente violación de la política de seguridad. Este mecanismo será
capaz de notificar inmediatamente al administrador de seguridad cuando
umbrales se superan, y si la aparición o acumulación
de estos eventos relevantes de seguridad continúa, el sistema deberá
tomar las medidas menos perjudiciales para dar por terminado el evento.
3.3.3 Aseguramiento
3.3.3.1 Aseguramiento Operacional
3.3.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
que lo protege de las interferencias externas o manipulación
(por ejemplo, por modificación de sus estructuras de código o datos).
El TCB deberá mantener el aislamiento de procesos a través de la
provisión de espacios de direcciones distintas bajo su control.
La TCB se estructurará internamente en bien definido
módulos en gran medida independientes. Se hará uso efectivo
de hardware disponible para separar aquellos elementos que son
protección-crítico de los que no lo son. El TCB
módulos deberán estar diseñados de tal manera que el principio de
privilegio menos se cumple. Características de hardware, tales
como la segmentación, se utilizarán para apoyar lógicamente
objetos de almacenamiento distintas con atributos diferentes (a saber:
lectura, escritura). La interfaz de usuario a la TCB deberá
ser totalmente definido y todos los elementos de la TCB
identificados. El TCB estará diseñado y estructurado para
utilizar un mecanismo de protección completa, conceptualmente simple
con semántica definida con precisión. Este mecanismo deberá
desempeñar un papel central en la aplicación de la estructuración interna
del TCB y el sistema. El TCB incorporará
uso significativo de la estratificación, la abstracción y la ocultación de datos.
Ingeniería de sistemas significativos se dirige hacia
minimizar la complejidad de la TCB y se excluyen de la
los módulos de TCB que no son de protección crítico.
3.3.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el correcto
funcionamiento de los elementos de hardware y firmware en el sitio
del TCB.
3.3.3.1.3 Análisis Canal Covert
El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para
canales encubiertos y tomar una determinación (ya sea por
medición real o por estimación de ingeniería) de la
máximo ancho de banda de cada canal identificado. (Vea el
Sección Orientación Canales Covert.)
3.3.3.1.4 Gestión de Instalaciones de confianza
El TCB apoyará operador independiente y administrador
funciones. Las funciones realizadas en el papel de una
se identificará administrador de seguridad. La ADP
personal administrativo del sistema sólo podrán
realizar funciones de administrador de seguridad después de tomar una
acción auditable distinta a asumir la seguridad
función de administrador en el sistema ADP. No la seguridad
funciones que se pueden realizar en la seguridad
rol de administración se limitará estrictamente a los
esencial para la realización de la función de seguridad efectiva.
3.3.3.1.5 Recuperación de confianza
Procedimientos y / o mecanismos se proporcionarán para asegurar
que, después de un fallo del sistema ADP u otra discontinuidad,
se obtiene la recuperación sin un compromiso de protección.
3.3.3.2 Ciclo de Vida de Garantía
3.3.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Un equipo de personas que entienden a fondo la
aplicación específica de la TCB someterá su
documentación de diseño, código fuente y el código objeto para
análisis y pruebas exhaustivas. Sus objetivos deberán
ser: para descubrir todos los defectos de diseño e implementación que
permitiría un sujeto externo a la TCB de leer,
cambiar o eliminar datos normalmente negados bajo el
política de seguridad obligatoria o discrecional impuesta por
la TCB; así como para asegurar que ningún objeto (sin
autorización para hacerlo) es capaz de hacer que el TCB para entrar
un estado tal que es incapaz de responder a
comunicaciones iniciadas por otros usuarios. El TCB deberá
se encuentran resistente a la penetración. Todos los defectos descubiertos
será corregido y el TCB vuelto a probar para demostrar
que han sido eliminados y que los nuevos defectos tener
no se han introducido. El ensayo debe demostrar que el
Aplicación TCB es consistente con la descriptiva
especificación de nivel superior. (Vea la Prueba de Seguridad
Lineamientos.) No hay defectos de diseño y no más de unos pocos
fallas de implementación corregibles pueden encontrarse en
probando y no habrá confianza razonable de que
pocos permanecen.
3.3.3.2.2 Especificaciones de Diseño y Verificación
Un modelo formal de la política de seguridad con el apoyo de la
TCB se mantiene a lo largo del ciclo de vida de la ADP
sistema que se ha demostrado en consonancia con sus axiomas. LA
memoria descriptiva de nivel superior (DTLS) de la TCB
se sostuvo que completa y precisa
describe la TCB en términos de excepciones, mensajes de error,
y efectos. Queda demostrado ser un exacto
Descripción de la interfaz de TCB. Un argumento convincente
habrá de darse que el DTLS es consistente con el modelo.
Gestión de la Configuración 3.3.3.2.3
Durante el desarrollo y mantenimiento de la TCB, una
sistema de gestión de la configuración será en el lugar que
mantiene el control de cambios en el nivel superior descriptiva
especificación, otros datos de diseño, implementación
documentación, código fuente, la versión de funcionamiento de la
código objeto, y accesorios de la prueba y la documentación. Los
sistema de gestión de la configuración deberá asegurar una coherente
mapeo entre toda la documentación y el código asociado con
la versión actual de la TCB. Herramientas se proporcionarán
para la generación de una nueva versión de la TCB de la fuente
código. También disponible serán herramientas para la comparación de una
versión recién generada con la versión anterior TCB en
Para asegurarse de que sólo los cambios previstos tienen
ha logrado en el código que realmente se utiliza como
nueva versión de la TCB.
3.3.4 Documentación
3.3.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
3.3.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura. Los procedimientos para
examinar y mantener los archivos de auditoría, así como la
estructura de registro de auditoría detallado para cada tipo de evento de auditoría
se le dará. El manual deberá describir el operador y
funciones de administrador relacionados con la seguridad, que incluyen
el cambio de las características de seguridad de un usuario. Incluirá
proporcionar directrices sobre el uso coherente y eficaz de la
características de protección del sistema, cómo interactúan, cómo
segura de generar una nueva TCB, y procedimientos de las instalaciones, las advertencias,
y los privilegios que necesitan ser controlados con el fin de operar
la instalación de un modo seguro. Los módulos de TCB que contienen
deberá identificarse el mecanismo de validación de referencia. Los
procedimientos para la generación segura de un nuevo TCB de la fuente después
Se describirá la modificación de cualquiera de los módulos en el TCB. Ello
incluirá los procedimientos para garantizar que el sistema es
comenzado inicialmente en una manera segura. Los procedimientos deberán ser también
incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en
operación del sistema.
Documentación 3.3.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad
pruebas funcionales mecanismos. Incluirá resultados de
probar la eficacia de los métodos utilizados para reducir encubierta
anchos de banda de canal.
3.3.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Los
Se describirán las interfaces entre los módulos de TCB. LA
descripción formal del modelo de política de seguridad aplicada por el
TCB deberá estar disponible y demostrado que es suficiente para
hacer cumplir la política de seguridad. La protección específica TCB
mecanismos deberán ser identificados y una explicación dan para mostrar
que cumplan el modelo. El alto nivel descriptivo
especificación (DTLS) se muestra como una precisa
Descripción de la interfaz de TCB. La documentación debe describir
cómo el TCB implementa el concepto monitor de referencia y dar
una explicación por qué es resistente a la manipulación, no puede ser anulada,
y se ha implementado correctamente. La implementación TCB (es decir, en
hardware, firmware y software) se muestran de manera informal a
ser coherente con los DTLS. Los elementos de la DTLS serán
se muestra, usando técnicas informales, para corresponder a los elementos
del TCB. La documentación debe describir cómo el TCB es
estructurado para facilitar las pruebas y hacer cumplir privilegios mínimos.
Esta documentación deberá presentar también los resultados de la encubierta
análisis de canal y las ventajas y desventajas implicadas en la restricción de la
canales. Todos los eventos auditables que se pueden utilizar en el
explotación de canales de almacenamiento encubiertas conocidas será
identificados. Los anchos de banda de los canales de almacenamiento encubiertas conocidas,
cuyo uso no es detectable por los mecanismos de auditoría,
se facilitará. (Vea la sección de Orientación del canal Covert.)
?
4.0 DIVISIÓN A: PROTECCIÓN VERIFICADO
Esta división se caracteriza por el uso de la verificación de seguridad formal
métodos para asegurar que los controles de seguridad obligatorios y discrecionales
empleado en el sistema puede proteger eficazmente clasificado u otro sensible
información almacenada o procesada por el sistema. Amplia documentación es
requerida para demostrar que la TCB cumple con los requisitos de seguridad en todo
aspectos de diseño, desarrollo e implementación.
?
4.1 CLASE (A1): DISEÑO VERIFICADO
Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3) en
que no se añaden características arquitectónicas adicionales o requisitos de la política.
La característica distintiva de los sistemas de esta clase es el análisis derivado
desde la especificación de diseño formal y técnicas de verificación y la resultante
alto grado de seguridad de que la TCB se implementa correctamente. Esta
aseguramiento del desarrollo es en la naturaleza, a partir de un modelo formal de la
la política de seguridad y una especificación de alto nivel formales (FTLs) del diseño.
Independiente del lenguaje de especificación en particular o sistema de verificación
utilizado, hay cinco criterios importantes para la clase (A1) la verificación del diseño:
* Un modelo formal de la política de seguridad debe ser claramente
identificado y documentado, incluyendo una prueba matemática
que el modelo es consistente con sus axiomas y es
suficiente para apoyar la política de seguridad.
* Un FTLs debe ser producido que incluye definiciones abstractas
de las funciones de la TCB realiza y del hardware y / o
mecanismos de firmware que se utilizan para apoyar separada
dominios de ejecución.
* Los FTLs de la TCB deben demostrarse que son consistentes con la
modelo mediante técnicas formales cuando sea posible (es decir, donde
herramientas de verificación de existir) y las informales de otra manera.
* La implementación TCB (es decir, en hardware, firmware, y
software) debe demostrar de manera informal para ser coherente con la
FTLs. Los elementos de los FTLs deben mostrarse, usando
técnicas informales, que corresponden a los elementos de la
TCB. Los FTLs deben expresar el mecanismo de protección unificada
necesario para satisfacer la política de seguridad, y es el
elementos de este mecanismo de protección que se asignan a la
elementos de la TCB.
* Técnicas de análisis formal se deben utilizar para identificar y
analizar los canales encubiertos. Técnicas informales pueden ser utilizados para
identificar los canales de temporización encubiertas. La persistencia de
canales encubiertos identificadas en el sistema deben estar justificadas.
De acuerdo con el análisis extenso de diseño y desarrollo de la TCB
requerida de los sistemas en la clase (A1), gestión de la configuración es más estricta
requeridos y se establezcan procedimientos para la distribución segura del sistema
a los sitios. Un administrador de la seguridad del sistema es compatible.
Los siguientes son los requisitos mínimos para los sistemas asignados a una clase (A1)
Puntuación:
4.1.1 Política de Seguridad
4.1.1.1 Control de Acceso Discrecional
El TCB debe definir y controlar el acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP.
El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá
permiten a los usuarios especificar y compartir el control de esos objetos,
y proporcionará controles para limitar la propagación de acceso
los derechos. El mecanismo de control de acceso discrecional deberá,
ya sea por acción explícita del usuario o por defecto, disponer que
objetos están protegidos contra el acceso no autorizado. Estos acceso
controles deberán ser capaces de especificar, para cada objeto nombrado,
una lista de personas con nombre y una lista de los grupos de llamada
individuos con sus respectivos modos de acceso a ese
objeto. Además, para cada uno de tales objeto nombrado, será
posible especificar una lista de personas con nombre y una lista de
grupos de individuos nombrados para la que no tiene acceso al objeto es
que debe darse. El permiso de acceso a un objeto no usuarios
ya que posee permiso de acceso sólo podrá ser cedido por
los usuarios autorizados.
4.1.1.2 Objeto Reutilización
Todas las autorizaciones de la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB
de objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado
representaciones de información, producidos por un sujeto antes de
acciones es estar a disposición de cualquier objeto que obtiene acceso
a un objeto que se ha lanzado de nuevo al sistema.
4.1.1.3 Las etiquetas
Etiquetas de sensibilidad asociados con cada recurso del sistema ADP
(por ejemplo, el asunto objeto de almacenamiento, ROM) que es directa o
indirectamente accesible por sujetos ajenos a la TCB será
mantenida por el TCB. Estas etiquetas se utilizan como base
para las decisiones de control de acceso obligatorios. Para importar
datos no etiquetados, la TCB deberán solicitar y recibir de un
usuario autorizado el nivel de seguridad de los datos, y toda esa
las acciones deberán ser auditables por el TCB.
4.1.1.3.1 Label Integridad
Etiquetas de sensibilidad deberán representar con precisión la seguridad
niveles de los temas específicos u objetos con los que
están asociados. Cuando exportado por el TCB,
etiquetas de sensibilidad deberá precisión y sin ambigüedades
representar las etiquetas internas y estará asociada
con que se exporta la información.
4.1.1.3.2 Exportación de Información Etiquetada
El TCB designará cada canal de comunicación y
Yo dispositivo de E / S, ya sea a nivel individual o de múltiples niveles. Alguna
cambio en esta designación se realiza de forma manual y
será auditable por el TCB. El TCB mantendrá
y ser capaz de auditar a cualquier cambio en el nivel de seguridad
o los niveles asociados con un canal de comunicación o
Dispositivo de E / S.
4.1.1.3.2.1 La exportación a dispositivos multinivel
Cuando la TCB exporta un objeto a un multinivel I / O
dispositivo, la etiqueta sensibilidad asociada con ese
objeto también se exportará y deberá residir en
el mismo medio físico como el exportado
información y se hará de la misma forma (es decir,
legible por máquina o en forma legible). Cuando
la TCB exporta o importa un objeto durante un
canal de comunicación de múltiples niveles, el protocolo
utilizado en ese canal deberá prever la
vinculación inequívoca entre las etiquetas de sensibilidad
y la información asociada que se envía o
recibido.
4.1.1.3.2.2 Exportación a solo nivel-Devices
Dispositivos S-nivel individual de E / y de un solo nivel
los canales de comunicación no están obligados a
mantener las etiquetas de sensibilidad de la información
que procesan. Sin embargo, la TCB incluirá una
mecanismo por el cual la TCB y un usuario autorizado
comunicar de forma confiable para designar la única
nivel de seguridad de la información importado o exportado
a través de los canales de comunicación de un solo nivel o de E / S
dispositivos.
4.1.1.3.2.3 salida etiquetado legible
El administrador del sistema ADP deberá ser capaz de
especificar los nombres de las etiquetas imprimibles asociados a
etiquetas de sensibilidad exportados. El TCB marcará
el principio y el fin de toda paginado legible,,
salida en papel (por ejemplo, la salida de impresora de líneas) con
etiquetas de sensibilidad legibles que correctamente *
representar la sensibilidad de la salida. El TCB
será, por defecto, marque la parte superior e inferior de cada
página de la salida legible, paginado, en papel
(por ejemplo, impresora de línea de salida) con legible
etiquetas de sensibilidad que correctamente * representan la
sensibilidad global de la salida o que
* representar adecuadamente la sensibilidad de la
información en la página. El TCB, a más tardar
por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas,
gráficos) con etiquetas de sensibilidad legibles
que adecuadamente * representan la sensibilidad de la
de salida. Cualquier anulación de estos incumplimientos marcado
será auditable por el TCB.
4.1.1.3.3 Asunto etiquetas de sensibilidad
El TCB notificará inmediatamente a un usuario del terminal de cada
cambio en el nivel de seguridad asociado a ese usuario
durante una sesión interactiva. Un usuario del terminal será
capaz de consultar la TCB como se desee para una visualización de la
etiqueta de sensibilidad completa del tema.
4.1.1.3.4 Las etiquetas de dispositivo
El TCB apoyará la asignación de mínima y
niveles de máxima seguridad a todos los dispositivos físicos conectados.
Estos niveles de seguridad deberán ser utilizados por el TCB para hacer cumplir
las restricciones impuestas por el entorno físico en el que
los dispositivos se encuentran.
4.1.1.4 Control de Acceso Obligatorio
El TCB deberá aplicar una política de control de acceso obligatorio sobre
todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S
dispositivos) que están directa o indirectamente accesible por temas
externo a la TCB. Estos sujetos y objetos serán
etiquetas de sensibilidad asignados que son una combinación de
niveles de clasificación jerárquica y no jerárquica
categorías y las etiquetas se utilizan como base para
las decisiones de control de acceso obligatorios. El TCB deberá ser capaz de
el apoyo de dos o tales niveles más seguridad. (Vea la obligatoria
Directrices de control de acceso.) Las siguientes condiciones se
mantener durante todos los accesos entre todos los sujetos externos a la TCB
y todos los objetos directamente o indirectamente accesible por éstos
temas: Un sujeto puede leer un objeto sólo si el jerárquica
clasificación en el nivel de seguridad del sujeto es mayor que
o igual a la clasificación jerárquica en el objeto de
nivel de seguridad y las categorías no jerárquicas en la
nivel de seguridad del sujeto incluye todos los no-jerárquica
categorías en el nivel de seguridad del objeto. Un sujeto puede escribir
______________________________
* El componente de clasificación jerárquica de la sensibilidad legible
etiquetas serán iguales a la mayor clasificación jerárquica de cualquiera de los
información en la salida que las etiquetas se refieren a; la no-jerárquica
componente categoría incluirá todas las categorías no jerárquicas de la
información en la salida de las etiquetas se refieren a, pero ningún otro no jerárquica
categorías.
un objeto sólo si la clasificación jerárquica en el
nivel de seguridad del sujeto es inferior o igual a la
clasificación jerárquica en el nivel de seguridad del objeto y
todas las categorías no jerárquicas en la seguridad del sujeto
nivel se incluyen en las categorías jerárquicas no en el
nivel de seguridad del objeto. Identificación y autentificación
datos serán utilizados por el TCB para autenticar al usuario de
identidad y para asegurar que el nivel de seguridad y autorización
ción de los sujetos externo a la TCB que puede ser creado para
actuar en nombre de cada usuario están dominados por el
aclaramiento y la autorización de dicho usuario.
4.1.2 Rendición de Cuentas
4.1.2.1 Identificación y autenticación
El TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que se espera que la TCB
para mediar. Además, la TCB deberá mantener la autenticación
datos que incluye información para la verificación de la identidad de
los usuarios individuales (por ejemplo, contraseñas), así como información para
la determinación de la compensación y las autorizaciones de individuo
usuarios. Estos datos podrán ser utilizados por la TCB para autenticar el
la identidad del usuario y para asegurar que el nivel de seguridad y
autorizaciones de sujetos externos a la TCB que puede ser
creado para actuar en nombre del usuario individual están dominadas por
la liquidación y autorización de ese usuario. El TCB deberá
proteger los datos de autenticación de modo que no se puede acceder por cualquier
usuario no autorizado. El TCB será capaz de hacer cumplir individuo
la rendición de cuentas, proporcionando la capacidad para identificar de forma única
cada usuario del sistema ADP individual. El TCB facilitará asimismo a la
capacidad de asociar esta identidad con toda auditable
medidas adoptadas por ese individuo.
4.1.2.1.1 Camino de confianza
El TCB apoyará una ruta de comunicación de confianza
entre ella misma y los usuarios para el uso cuando un TCB-a-positivo
Se requiere conexión de usuario (por ejemplo, inicio de sesión, cambio de tema
nivel de seguridad). Comunicaciones a través de este camino de confianza
deberá ser activado exclusivamente por un usuario o la TCB y
deberán estar aislados de manera lógica y sin lugar a dudas
distinguible de otros caminos.
4.1.2.2 Auditoría
El TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una auditoría
rastro de accesos a los objetos que protege. Los datos de auditoría
estarán protegidos por la TCB para que el acceso de lectura a la misma es
limitado a aquellos que están autorizados para los datos de auditoría. El TCB
será capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificación y autenticación, la introducción de
objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa
iniciación), la supresión de los objetos, y las medidas adoptadas por el ordenador
operadores y administradores de sistemas y / o la seguridad del sistema
oficiales y otros eventos relevantes de seguridad. El TCB deberá
También podrá auditar cualquier anulación de la salida legible
marcas. Para cada evento registrado, el registro de auditoría,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y
éxito o el fracaso del evento. Para la identificación /
eventos de autenticación del origen de la solicitud (por ejemplo, la terminal de Identificación)
se incluirán en el registro de auditoría. Para los eventos que
introducir un objeto en el espacio de direcciones de un usuario y para el objeto
eventos de eliminación del registro de auditoría deberán incluir el nombre de la
objeto y nivel de seguridad del objeto. El sistema de ADP
administrador podrá auditar selectivamente las acciones de
cualquier uno o más usuarios en base a la identidad y / o objeto individual
nivel de seguridad. El TCB podrá auditar el identificada
eventos que se pueden utilizar en la explotación de almacenamiento encubierta
canales. El TCB deberá contener un mecanismo que es capaz de
supervisar la aparición o acumulación de seguridad auditable
hechos que pueden indicar una violación inminente de la seguridad
política. Este mecanismo será capaz de notificar inmediatamente a la
administrador de seguridad cuando los umbrales se superan, y, si es
la aparición o acumulación de éstos de seguridad pertinentes
acontecimientos continúa, el sistema tomará la menor disruptiva
acción para terminar el evento.
4.1.3 Aseguramiento
4.1.3.1 Aseguramiento Operacional
4.1.3.1.1 Arquitectura del Sistema
El TCB mantendrá un dominio para su propia ejecución
que lo protege de las interferencias externas o manipulación
(por ejemplo, por modificación de sus estructuras de código o datos).
El TCB deberá mantener el aislamiento de procesos a través de la
provisión de espacios de direcciones distintas bajo su control.
La TCB se estructurará internamente en bien definido
módulos en gran medida independientes. Se hará uso efectivo
de hardware disponible para separar aquellos elementos que son
protección-crítico de los que no lo son. El TCB
módulos deberán estar diseñados de tal manera que el principio de
privilegio menos se cumple. Características de hardware, tales
como la segmentación, se utilizarán para apoyar lógicamente
objetos de almacenamiento distintas con atributos diferentes (a saber:
lectura, escritura). La interfaz de usuario a la TCB
deberá estar totalmente definido y todos los elementos de la TCB
identificados. El TCB estará diseñado y estructurado para
utilizar un mecanismo de protección completa, conceptualmente simple
con semántica definida con precisión. Este mecanismo deberá
desempeñar un papel central en la aplicación de la estructuración interna
del TCB y el sistema. El TCB incorporará
uso significativo de la estratificación, la abstracción y la ocultación de datos.
Ingeniería de sistemas significativos se dirige hacia
minimizar la complejidad de la TCB y se excluyen de la
los módulos de TCB que no son de protección crítico.
4.1.3.1.2 Sistema de Integridad
Características de hardware y / o software serán siempre que
se puede utilizar para validar periódicamente el correcto
funcionamiento de los elementos de hardware y firmware en el sitio
del TCB.
4.1.3.1.3 Análisis Canal Covert
El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para
canales encubiertos y tomar una determinación (ya sea por
medición real o por estimación de ingeniería) de la
máximo ancho de banda de cada canal identificado. (Vea el
Sección Orientación Canales Covert.) Los métodos formales deberá
ser utilizado en el análisis.
4.1.3.1.4 Gestión de Instalaciones de confianza
El TCB apoyará operador independiente y administrador
funciones. Las funciones realizadas en el papel de una
se identificará administrador de seguridad. La ADP
personal administrativo del sistema sólo podrán
realizar funciones de administrador de seguridad después de tomar una
acción auditable distinta a asumir la seguridad
función de administrador en el sistema ADP. No la seguridad
funciones que se pueden realizar en la seguridad
rol de administración se limitará estrictamente a los
esencial para la realización de la función de seguridad efectiva.
4.1.3.1.5 Recuperación de confianza
Procedimientos y / o mecanismos se proporcionarán para asegurar
que, después de un fallo del sistema ADP u otra discontinuidad,
se obtiene la recuperación sin un compromiso de protección.
4.1.3.2 Ciclo de Vida de Garantía
4.1.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarán
y encontrado para trabajar como se reivindica en la documentación del sistema.
Un equipo de personas que entienden a fondo la
aplicación específica de la TCB someterá su
documentación de diseño, código fuente y el código objeto para
análisis y pruebas exhaustivas. Sus objetivos deberán
ser: para descubrir todos los defectos de diseño e implementación que
permitiría un sujeto externo a la TCB de leer,
cambiar o eliminar datos normalmente negados bajo el
política de seguridad obligatoria o discrecional impuesta por
la TCB; así como para asegurar que ningún objeto (sin
autorización para hacerlo) es capaz de hacer que el TCB para entrar
un estado tal que es incapaz de responder a
comunicaciones iniciadas por otros usuarios. El TCB deberá
se encuentran resistente a la penetración. Todos los defectos descubiertos
será corregido y el TCB vuelto a probar para demostrar
que han sido eliminados y que los nuevos defectos tener
no se han introducido. El ensayo debe demostrar que el
Aplicación TCB es coherente con las láminas superior formales
especificación de nivel. (Vea la Prueba de Seguridad
Lineamientos.) No hay defectos de diseño y no más de unos pocos
fallas de implementación corregibles pueden encontrarse en
probando y habrá una confianza razonable que pocos
permanecer. Mapeo manual u otra de las FTLs al
código fuente puede servir de base para las pruebas de penetración.
4.1.3.2.2 Especificaciones de Diseño y Verificación
Un modelo formal de la política de seguridad con el apoyo de la
TCB se mantiene a lo largo del ciclo de vida de la ADP
sistema que se ha demostrado en consonancia con sus axiomas. LA
memoria descriptiva de nivel superior (DTLS) de la TCB
se sostuvo que completa y precisa
describe la TCB en términos de excepciones, mensajes de error,
y efectos. Una especificación de alto nivel formales (FTLs) de
la TCB se mantendrá que describe con precisión la
TCB en términos de excepciones, mensajes de error y efectos.
Los DTLS y FTLs incluirán aquellos componentes de la
TCB que se implementa como hardware y / o firmware si
sus propiedades son visibles en la interfaz de TCB. Los
FTLs se mostraron ser una descripción exacta de la
Interfaz de TCB. Un argumento convincente se decidió que se
la DTLS es consistente con el modelo y una combinación de
Se utilizarán técnicas formales e informales para demostrar que
la FTLs es consistente con el modelo. Esta verificación
pruebas será compatible con la prevista en el
el estado de la técnica de la seguridad informática en particular
centro-endosado especificación formal y verificación
sistema utilizado. Mapeo manual u otra de las FTLs al
Se realizará el código fuente TCB para proporcionar evidencia de
aplicación correcta.
Gestión de la Configuración 4.1.3.2.3
Durante todo el ciclo de vida, es decir, durante el diseño,
desarrollo y mantenimiento de la TCB, una configuración
sistema de dirección debe estar en su lugar para toda seguridad-
hardware correspondiente, firmware y software que mantiene
el control de cambios en el modelo formal, lo descriptivo
y las especificaciones de alto nivel formales, otros datos de diseño,
documentación de la aplicación, código fuente, el funcionamiento
versión del código objeto, y de prueba y accesorios
documentación. El sistema de gestión de la configuración deberá
asegurar una asignación consistente entre toda la documentación y
código asociado con la versión actual de la TCB.
Herramientas se proporcionan para la generación de una nueva versión
del TCB partir del código fuente. También disponible será
herramientas, mantenidos bajo control estricto de configuración, por
la comparación de una versión recién generado con la TCB anterior
versión a fin de determinar que sólo la intención
se han realizado cambios en el código que realmente será
utilizado como la nueva versión de la TCB. Una combinación de
y salvaguardas técnicas, físicas procedimental será
utilizado para proteger de la modificación no autorizada o
la destrucción de la copia maestra o copias de todo el material
utilizado para generar la TCB.
4.1.3.2.4 Distribución de confianza
Una instalación de control del sistema ADP y distribución de confianza
serán las previstas en el mantenimiento de la integridad de la
asignación entre los datos maestros que describen el actual
versión de la TCB y la copia maestra en el lugar del
código de la versión actual. Procedimientos (por ejemplo, el sitio
pruebas de aceptación de seguridad) deberá existir para asegurar
que el software TCb, actualizaciones de firmware y hardware
distribuido a un cliente son exactamente como se especifica en
las copias maestras.
4.1.4 Documentación
4.1.4.1 Funciones de seguridad Guía del usuario
Un único resumen, capítulo, o manual en la documentación del usuario
deberá describir los mecanismos de protección proporcionados por la TCB,
directrices sobre su uso, y cómo interactúan unos con otros.
4.1.4.2 Manual de Instalación de confianza
Un manual dirigido al administrador del sistema ADP deberá
presentes advertencias acerca de las funciones y privilegios que deberían ser
controlada al ejecutar una instalación segura. Los procedimientos para
examinar y mantener los archivos de auditoría, así como la
estructura de registro de auditoría detallado para cada tipo de evento de auditoría
se le dará. El manual deberá describir el operador y
funciones de administrador relacionados con la seguridad, que incluyen
el cambio de las características de seguridad de un usuario. Incluirá
proporcionar directrices sobre el uso coherente y eficaz de la
características de protección del sistema, cómo interactúan, cómo
segura de generar una nueva TCB, y procedimientos de las instalaciones, las advertencias,
y los privilegios que necesitan ser controlados con el fin de operar
la instalación de un modo seguro. Los módulos de TCB que contienen
deberá identificarse el mecanismo de validación de referencia. Los
procedimientos para la generación segura de un nuevo TCB de la fuente después
Se describirá la modificación de cualquiera de los módulos en el TCB. Ello
incluirá los procedimientos para garantizar que el sistema es
comenzado inicialmente en una manera segura. Los procedimientos deberán ser también
incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en
operación del sistema.
Documentación 4.1.4.3 Prueba
El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad
pruebas funcionales mecanismos. Incluirá resultados de
probar la eficacia de los métodos utilizados para reducir encubierta
anchos de banda de canal. Los resultados de la asignación entre el
especificación de nivel superior formal y el código fuente TCB serán
dado.
4.1.4.4 Diseño de documentación
La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación
de cómo esta filosofía se traduce en la TCB. Los
Se describirán las interfaces entre los módulos de TCB. LA
descripción formal del modelo de política de seguridad aplicada por el
TCB deberá estar disponible y demostrado que es suficiente para
hacer cumplir la política de seguridad. La protección específica TCB
mecanismos deberán ser identificados y una explicación dan para mostrar
que cumplan el modelo. El descriptiva especificado de nivel superior
ficación (DTLS) se demuestra que es una descripción exacta de
la interfaz de TCB. La documentación debe describir cómo el TCB
implementa el concepto de monitor de referencia y dar una explicación
la razón por la que es resistente a la manipulación, no se puede omitir, y
se ha implementado correctamente. La implementación TCB (es decir, en
hardware, firmware y software) se muestran de manera informal a
ser compatible con la especificación de alto nivel formales (FTLs).
Los elementos de las FTLs se indicarán, mediante informal
técnicas, para corresponder a los elementos de la TCB.
La documentación debe describir cómo el TCB está estructurado para
facilitar las pruebas y hacer cumplir privilegio menos. Esta
documentación deberá presentar también los resultados de la encubierta
análisis de canal y las ventajas y desventajas implicadas en la restricción de la
canales. Todos los eventos auditables que se pueden utilizar en el
explotación de canales de almacenamiento encubiertas conocidas será
identificados. Los anchos de banda de los canales de almacenamiento encubiertas conocidas,
cuyo uso no es detectable por los mecanismos de auditoría,
se facilitará. (Vea la sección de Orientación del canal Covert.)
Hardware, el firmware y los mecanismos de software no tratados en
los FTLs pero estrictamente interna a la TCB (por ejemplo, mapeo
registros, acceso directo a memoria de E / S) se describen claramente.
?
4.2 MÁS ALLÁ DE LA CLASE (A1)
La mayor parte de las mejoras de seguridad previsto para los sistemas que proporcionen
características y aseguramiento, además de que ya previstas por clase (Al)
sistemas están más allá de la tecnología actual. La discusión que sigue está destinado a
orientar la labor futura y se deriva de las actividades de investigación y desarrollo
ya en marcha, tanto en los sectores público y privado. A medida que más y mejor
técnicas de análisis se desarrollan, los requisitos para estos sistemas
ser más explícito. En el futuro, el uso de la verificación formal será
extendidos hasta el nivel de la fuente y los canales de temporización encubiertas serán más plenamente
abordarse. En este nivel el entorno de diseño se convertirá en importante y
prueba será ayudado por el análisis de la especificación formal de nivel superior.
Se tendrá en cuenta para la corrección de las herramientas utilizadas en el TCB
desarrollo (por ejemplo, los compiladores, ensambladores, cargadores) y para la correcta
funcionamiento del hardware / firmware en la que la TCB se ejecutará. Las áreas a ser
dirigida por los sistemas más allá de la clase (A1) incluyen:
* Arquitectura del Sistema
Una demostración (formal o no) se debe dar muestra
que los requisitos de auto-protección y la integridad de
monitores de referencia se han implementado en el TCB.
* Pruebas de seguridad
Aunque más allá del estado de la técnica actual, es
prevé que se hará alguna generación de pruebas de los casos
automáticamente de la especificación formal de nivel superior o
especificaciones formales de nivel inferior.
* Especificación formal y Verificación
El TCB debe ser verificada hasta el nivel de código fuente,
utilizando métodos de verificación formal cuando sea factible. Oficial
verificación del código fuente de la seguridad pertinente
partes de un sistema operativo ha demostrado ser una tarea difícil
tarea. Dos consideraciones importantes son la elección de una
lenguaje de alto nivel cuya semántica puede ser plena y
expresado formalmente, y un mapeo cuidadoso, a través de
etapas sucesivas, del diseño formal abstracta a un
formalización de la aplicación de bajo nivel
especificaciones. La experiencia ha demostrado que sólo cuando el
especificaciones de nivel más bajo se corresponden estrechamente a la actual
código puede codificar pruebas se realizó con éxito.
* Trusted Diseño para el Medio Ambiente
El TCB debe estar diseñado en un centro de confianza con solamente
confianza (liquidados) Personal.
PARTE II:
JUSTIFICACIÓN Y DIRECTRICES
?
5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMÁTICOS DE CONFIANZA
Los criterios se dividen dentro de cada clase en grupos de requisitos. Estas
agrupaciones fueron desarrollados para asegurar que los tres objetivos básicos de control de
seguridad informática están satisfechos y sin vecinos. Estos objetivos de control
lidiar con:
* Politica de seguridad
* Rendición de cuentas
* Aseguramiento
En esta sección se ofrece un análisis de estos objetivos generales de control y
su implicación en términos de diseño de sistemas de confianza.
?
5.1 NECESIDAD DE CONSENSO
Un objetivo importante del Centro de Seguridad Informática del Departamento de Defensa es fomentar el ordenador
Industria para desarrollar sistemas informáticos fiables y productos, haciéndolos ampliamente
disponible en el mercado comercial. El logro de este objetivo
requiere el reconocimiento y articulación de los sectores público y privado de
la necesidad y la demanda de este tipo de productos.
Como se describe en la introducción de este documento, los esfuerzos para definir la
problemas y desarrollar soluciones asociados con el procesamiento a nivel nacional sensibles
información, así como otros datos sensibles, tales como financieros, médicos, y
información del personal utilizado por el Establecimiento de Seguridad Nacional, han sido
llevando a cabo para un número de años. Los criterios, tal como se describe en la Parte I,
representar la culminación de estos esfuerzos y describir los requisitos básicos para
edificio confiaba sistemas informáticos. Hasta la fecha, sin embargo, estos sistemas han sido
visto por muchos, ya que sólo la satisfacción de las necesidades de la seguridad nacional. Mientras esta
percepción continúa el consenso necesario para motivar fabricación de confianza
sistemas serán escasas.
El propósito de esta sección es describir en detalle el control fundamental
objetivos. Estos objetivos sentar las bases para los requisitos indicados
en los criterios. El objetivo es explicar las bases para que los que están fuera
el Establecimiento de Seguridad Nacional puede evaluar su universalidad y, por
extensión, la aplicabilidad universal de los requisitos de criterios de
procesamiento de todos los tipos de aplicaciones sensibles ya sean para Nacional
Seguridad o el sector privado.
?
5.2 DEFINICIÓN Y UTILIDAD
El término "controlar objetivo" se refiere a una declaración de intenciones con respecto a la
control sobre algún aspecto de los recursos de una organización, o procesos, o
ambos. En términos de un sistema informático, los objetivos de control proporcionan un marco
para el desarrollo de una estrategia para el cumplimiento de un conjunto de requisitos de seguridad para los
cualquier sistema dado. Desarrollado en respuesta a vulnerabilidades genéricas, tales como
la necesidad de gestionar y manejar datos sensibles con el fin de evitar el compromiso,
o la necesidad de proporcionar la rendición de cuentas con el fin de detectar el fraude, el control
objetivos han sido identificados como un método útil de la seguridad expresar
metas. [3]
Ejemplos de objetivos de control incluyen los tres requisitos básicos de diseño para
la aplicación del concepto monitor de referencia discutió en la Sección 6. Ellos son:
* El mecanismo de validación de referencia debe ser a prueba de manipulaciones.
* El mecanismo de validación de referencia siempre se debe invocar.
* El mecanismo de validación de referencia debe ser suficientemente pequeño para ser
sometido a análisis y pruebas, la integridad de los cuales puede
tener la seguridad. [1]
?
5.3 CRITERIOS OBJETIVOS DE CONTROL
Los tres objetivos básicos de control de los criterios tienen que ver con la seguridad
la política, la rendición de cuentas, y la garantía. El resto de esta sección se ofrece
una discusión de estos requisitos básicos.
5.3.1 Política de Seguridad
En el sentido más general, la seguridad informática se refiere a
controlar la forma en la que un ordenador puede ser utilizado, es decir,
el control de cómo la información procesada por que se puede acceder y
manipulado. Sin embargo, en un examen más detallado, la seguridad informática
puede referirse a una serie de áreas. Un síntoma de esto, FIPS PUB 39,
Glosario para los sistemas informáticos de seguridad, no tiene una única
definición de la seguridad informática. [16] En su lugar hay once
definiciones separadas para la seguridad, que incluyen: sistemas de ADP
la seguridad, la seguridad administrativa, seguridad de datos, etc. Un común
hilo conductor de estas definiciones es la palabra "protección".
Otras declaraciones de los requisitos de protección se pueden encontrar en
Directiva DoD 5200.28, que describe un nivel aceptable de
protección para los datos clasificados como uno que "asegurar que
sistemas que procesan, almacenan o usan datos clasificados y producir
información clasificada hará, con fiabilidad razonable,
impedir: a. Acceso deliberada o inadvertida para clasificarse
material por parte de personas no autorizadas, y b. Unauthorized
manipulación de la computadora y su periférico asociado
dispositivos ". [8]
En resumen, los requisitos de protección deben definirse en términos de
las amenazas percibidas, riesgos y objetivos de una organización. Esta
a menudo se dice en términos de una política de seguridad. Ha sido
señalado en la literatura que se trata de leyes externas, reglas,
reglamentos, etc., que establecen lo que el acceso a la información es
se permitirá, independiente de la utilización de un ordenador. En particular,
un sistema dado sólo puede decirse que es seguro con respecto a su
la ejecución de alguna política específica. [30] Por lo tanto, el control
objetivo de la política de seguridad es:
OBJETIVO DE SEGURIDAD CONTROL DE POLÍTICA
Una declaración de intenciones en relación con el control sobre el acceso y la
difusión de la información, que se conocerá como la política de seguridad
debe ser precisamente definida e implementada para cada sistema que es
utilizado para procesar información sensible. La política de seguridad debe
reflejar con precisión las leyes, reglamentos y políticas generales
a partir del cual se deriva.
5.3.1.1 Política de Seguridad Obligatorio
Cuando se desarrolla una política de seguridad que se va a aplicar
para el control de clasificado u otro específicamente designado
información sensible, la política debe incluir detallada
reglas sobre la manera de manejar esa información durante todo su
ciclo de la vida. Estas reglas son una función de los distintos
sensibilidad designaciones que la información puede asumir
y las diversas formas de acceso soportados por el sistema.
Obligatorio Seguridad se refiere a la aplicación de un conjunto de
reglas de control de acceso que limita el acceso de un sujeto a
información sobre la base de una comparación de ese
despacho / autorización del individuo a la información,
la designación de clasificación / sensibilidad de la
la información y la forma de acceso están mediadas.
Políticas obligatorias o bien exigen o pueden ser satisfechas por
sistemas que pueden hacer cumplir una orden parcial de
designaciones, a saber, las designaciones deben formar lo que se
matemáticamente conocido como un "celosía". [5]
Una clara implicación de lo anterior es que el sistema debe
aseguran que las designaciones asociadas con datos sensibles
no se puede cambiar arbitrariamente, ya que esto podría permitir
las personas que no tienen la autorización apropiada para
acceso a la información sensible. También implícita es la
requisito de que el sistema de control de la circulación de la información
para que los datos no se puede almacenar con menor sensibilidad
ha sido autorizado designaciones a menos que su "degradación".
El objetivo de control es:
CONTROL DE SEGURIDAD OBLIGATORIO OBJETIVO
Las políticas de seguridad definidas para los sistemas que se utilizan para
proceso clasificado u otro clasifica específicamente
información sensible debe incluir disposiciones para la
aplicación de las normas de control de acceso obligatorios. Eso es,
deben incluir un conjunto de reglas para controlar el acceso
basada directamente en una comparación de los individuales de
autorización o autorización para la información y la
clasificación o designación de la sensibilidad
la información que se busca, e indirectamente en consideraciones
de los factores ambientales físicos y de otro tipo de control.
Las reglas de control de acceso obligatorios deben reflejar con precisión
las leyes, los reglamentos y las políticas generales de la que
se derivan.
5.3.1.2 Política de Seguridad Discrecional
Seguridad discrecional es el tipo principal de acceso
de control disponible en los sistemas informáticos en la actualidad. La base de
Este tipo de seguridad es que un usuario individual, o
programa operativo en su nombre, se le permite especificar
explícitamente los tipos de acceso a otros usuarios pueden tener que
la información bajo su control. Seguridad Discrecional
difiere de seguridad obligatorias en que implementa un
política de control de acceso sobre la base de un individuo de
necesita-a-saber en comparación con los controles obligatorios que son
impulsado por la clasificación o la sensibilidad designación de
la información.
Controles discrecionales no son un sustituto de obligatoria
controles. En un entorno en el que la información es
clasificado (como en el Departamento de Defensa) Seguridad discrecional ofrece
para una mayor granularidad de control dentro de la general
restricciones de la política obligatoria. El acceso a clasificado
información requiere la aplicación efectiva de ambos tipos
de los controles como condición previa para la concesión de ese acceso. En
general, ninguna persona puede tener acceso a la clasificada
información a menos que: (a) que la persona se ha determinado que
ser dignos de confianza, es decir, concedió una seguridad del personal
despacho - OBLIGATORIO, y (b) el acceso es necesario para la
desempeño de funciones oficiales, es decir, determinados a tener un
necesita-a-saber - DISCRECIONAL. En otras palabras,
controles discrecionales dan individuos discreción
decidir sobre cuál de los accesos permitidos en realidad
se le permita a la que los usuarios, de acuerdo con imperiosas
restricciones políticas obligatorias. El objetivo de control es:
CONTROL DE SEGURIDAD DISCRECIONAL OBJETIVO
Las políticas de seguridad definidas para los sistemas que se utilizan para
proceso clasificada u otra información sensible debe
incluir disposiciones para la aplicación de la discrecionalidad
reglas de control de acceso. Es decir, se deben incluir una
conjunto coherente de normas para el control y la limitación del acceso
basado en individuos identificados que han sido determinados
tienen una necesidad de conocer la información.
5.3.1.3 Marcado
Para llevar a cabo un conjunto de mecanismos que pondrán en vigor
una política de seguridad obligatorio, es necesario que el
información de marca de sistema con la clasificación correspondiente o
sensibilidad etiquetas y mantener estas marcas como el
la información se mueve a través del sistema. Una vez que la información es
comparaciones inalterable y marcadas con precisión, requeridos por
las reglas de control de acceso obligatorio pueden ser precisa y
consistentemente hecho. Un beneficio adicional de tener la
sistema de mantener la etiqueta de clasificación o la sensibilidad
internamente es la capacidad de generar de forma automática
adecuadamente "etiquetado" de salida. Las etiquetas, si con precisión y
integralmente mantenido por el sistema, siendo preciso cuando
salida del sistema. El objetivo de control es:
MARCADO OBJETIVO DE CONTROL
Los sistemas que están diseñados para hacer cumplir una fianza obligatoria
política debe almacenar y preservar la integridad de
clasificación u otras etiquetas de sensibilidad para todos
información. Las etiquetas exportadas del sistema deben ser
representaciones precisas de la interna correspondiente
etiquetas de sensibilidad que se exportan.
5.3.2 Rendición de Cuentas
El segundo objetivo de control básico aborda uno de los
principios fundamentales de la seguridad, es decir, individuo
la rendición de cuentas. La responsabilidad individual es la clave para asegurar
y el control de cualquier sistema que procesa la información en nombre
de los individuos o grupos de individuos. Una serie de requisitos
se deben cumplir para satisfacer este objetivo.
El primer requisito es para la identificación del usuario individual.
En segundo lugar, hay una necesidad para la autenticación de la identificación.
La identificación es funcionalmente dependiente de autenticación.
Sin autenticación, identificación de usuario no tiene credibilidad.
Sin una identidad creíble, ni obligatorio ni discrecional
las políticas de seguridad se pueden invocar correctamente porque no hay
la garantía de que las autorizaciones adecuadas se pueden hacer.
El tercer requisito es para capacidades de auditoría confiables. Ese
Es decir, un sistema informático de confianza debe proporcionar personal autorizado
con la capacidad de auditar cualquier acción que potencialmente pueden causar
acceso, generación de, o efectuar la liberación de reservada o
información sensible. Los datos de auditoría serán selectivamente
adquiridos en base a las necesidades de auditoría de una instalación en particular
y / o aplicación. Sin embargo, debe haber suficiente granularidad
en los datos de auditoría para apoyar la localización de los eventos auditables a un
individuo específico que ha tomado las acciones o en cuyo nombre
se tomaron las acciones. El objetivo de control es:
OBJETIVO DE CONTROL DE RENDICIÓN DE CUENTAS
Los sistemas que se utilizan para procesar o manipular clasificada u otro
información sensible debe asegurar la responsabilidad individual
siempre que sea una política de seguridad obligatoria o discrecional es
invocado. Además, para asegurar la rendición de cuentas, la capacidad
debe existir para que un agente autorizado y competente para el acceso y
evaluar la información de rendición de cuentas por un medio seguro, dentro de un
tiempo razonable y sin excesiva dificultad.
5.3.3 Aseguramiento
El tercer objetivo de control básico se refiere a garantizar
o proporcionar confianza en que la política de seguridad ha sido
se aplica correctamente y que los elementos de protección pertinentes de
el sistema do, de hecho, mediar y hacer cumplir la intención precisa
de esa política. Por extensión, la garantía debe incluir una garantía
que la parte de confianza del sistema sólo funciona según lo previsto. A
lograr estos objetivos, se necesitan dos tipos de seguridad.
Son la garantía de ciclo de vida y seguridad operacional.
Aseguramiento del ciclo de vida se refiere a las medidas adoptadas por una organización para
asegúrese de que el sistema está diseñado, desarrollado y mantenido
utilizando formalizados y rigurosos controles y normas. [17]
Los sistemas informáticos que procesan y almacenan sensible o clasificada
información depende del hardware y software para proteger esa
información. De ello se desprende que el hardware y software a sí mismos
deben ser protegidos contra cambios no autorizados que podrían hacer
mecanismos de protección al mal funcionamiento o ser anuladas por completo.
Por esta razón, los sistemas informáticos de confianza deben ser cuidadosamente
evaluado y probado durante las fases de diseño y desarrollo y
reevaluados cada vez que se realizan cambios que podrían afectar a la
integridad de los mecanismos de protección. Sólo de esta manera puede
confianza estar previsto que el hardware y el software
interpretación de la política de seguridad se mantiene con precisión
y sin distorsión.
Mientras que la garantía de ciclo de vida tiene que ver con los procedimientos para
la gestión de diseño del sistema, el desarrollo y el mantenimiento; operacional
aseguramiento centra en las características y arquitectura del sistema se utilizan para
asegúrese de que la política de seguridad se aplica uncircumventably
durante el funcionamiento del sistema. Es decir, la política de seguridad debe haber
integrado en las características de hardware y software de protección de
el sistema. Los ejemplos de las medidas adoptadas para proporcionar este tipo de
confianza incluyen: métodos para probar el hardware operativa
y software para su correcto funcionamiento, el aislamiento de proteccionismo
código crítico, y el uso de hardware y software para proporcionar
dominios distintos. El objetivo de control es:
OBJETIVO DE CONTROL DE GARANTÍA
Los sistemas que se utilizan para procesar o manipular clasificada u otro
información sensible debe estar diseñado para garantizar la correcta y
interpretación precisa de la política de seguridad y no debe
distorsionar la intención de que la política. Aseguramiento debe proporcionarse
existe de que la aplicación correcta y el funcionamiento de la política
a lo largo del ciclo de vida del sistema.
?
6.0 JUSTIFICACIÓN DETRÁS DE LAS CLASES DE EVALUACIÓN
?
6.1 EL CONCEPTO DE MONITOR DE REFERENCIA
En octubre de 1972, el Estudio de Planificación de Tecnología de Seguridad Informática, realizó
por James P. Anderson & Co., elaboró un informe para los Sistemas Electrónicos
División (ESD) de la Fuerza Aérea de los Estados Unidos. [1] En ese informe, el concepto
de "un monitor de referencia que hace cumplir las relaciones de acceso autorizados
entre los sujetos y los objetos de un sistema "fue introducido. La referencia
Monitor concepto resultó ser un elemento esencial de cualquier sistema que lo haría
proporcionar multinivel instalaciones informáticas seguras y controles.
El informe Anderson pasó a definir el mecanismo de validación de referencia
"una aplicación del concepto de monitor de referencia... que valida
cada referencia a datos o programas por cualquier usuario (programa) con una lista de
tipos de referencia autorizado para ese usuario. "A continuación, aparece el diseño de tres
requisitos que deben ser cumplidos por un mecanismo de validación de referencia:
a. El mecanismo de validación de referencia debe ser a prueba de manipulaciones.
b. El mecanismo de validación de referencia siempre se debe invocar.
c. El mecanismo de validación de referencia debe ser suficientemente pequeño para ser
sujetos a análisis y pruebas, la integridad de los cuales puede
estar seguro. "[1]
Continuación de las actividades de investigación y desarrollo tienen una amplia revisión por pares y
sostenido la validez de las conclusiones del Comité Anderson. Los primeros ejemplos
del mecanismo de validación de referencia eran conocidos como granos de seguridad. Los
Anderson Informe describe el núcleo de seguridad como "esa combinación de hardware
y el software que implementa el concepto de monitor de referencia ". [1] En este orden de ideas,
se observará que el núcleo de seguridad debe ser compatible con los tres referencia
requisitos de monitor enumerados anteriormente.
?
6.2 A SEGURIDAD FORMAL POLÍTICA DE MODELO
Tras la publicación del informe de Anderson, una considerable investigación fue
iniciado en los modelos formales de requisitos de la política de seguridad y de la
mecanismos que aplicar y hacer cumplir esos modelos de política como la seguridad
kernel. Destacan entre estos esfuerzos fue el desarrollo ESD-patrocinado de
el modelo Bell y LaPadula, un tratamiento formal abstracta de seguridad del Departamento de Defensa
política. [2] El uso de las matemáticas y la teoría de conjuntos, el modelo define con precisión la
noción de estado seguro, modos fundamentales de acceso, y las reglas para
la concesión de los sujetos modos específicos de acceso a los objetos. Por último, un teorema es
probada para demostrar que las reglas son las operaciones de seguridad de preservación, por lo
que la aplicación de cualquier secuencia de las reglas a un sistema que está en una
estado seguro se traducirá en el sistema de entrar en un nuevo estado que es también
seguro. Este teorema es conocido como el Teorema de Seguridad Básica.
Un sujeto puede actuar en nombre de un usuario u otro objeto. El tema es
creado como un sustituto para el usuario autorizado y se le asigna un valor formal,
nivel en función de su clasificación. Las transiciones de estado e invariantes de
el modelo de política formal definir las relaciones invariantes que deben contener
entre el aclaramiento del usuario, el nivel de seguridad formal de cualquier proceso
que puede actuar en nombre del usuario y el nivel de seguridad formal de los dispositivos
y otros objetos a los que cualquier proceso pueden obtener modos específicos de acceso.
El modelo Bell y LaPadula, por ejemplo, define una relación entre lo formal
niveles de seguridad de sujetos y objetos, que ahora hace referencia como el "dominio
relación ". A partir de esta definición, los accesos permitidos entre los sujetos y
objetos se definen explícitamente los modos fundamentales de acceso, incluyendo
acceso de sólo lectura, lectura / escritura, y escribir-único acceso. El modelo define
el Estado de Seguridad simple para controlar la concesión de un sujeto acceso de lectura a un
objeto específico, y la * -Property (léase "Star Propiedad") para el control de la concesión
un acceso por materias de escritura a un objeto específico. Tanto la Seguridad simple
Condición y el * -Property incluyen disposiciones de seguridad obligatorias en función de la
relación de dominación entre los niveles de seguridad formales de los sujetos y objetos del
liquidación de la materia y la clasificación del objeto. Los
Discrecional Seguridad Propiedad también se define, y requiere que un determinado
sujetos autorizados para todo el modo particular de acceso requerido para el Estado
transición. En su tratamiento de temas (procesos que actúan en nombre de un
el usuario), el modelo distingue entre sujetos de confianza (es decir, no limitados
en el modelo por el * -Property) y los sujetos no confiables (los que son
limitada por la * -Property).
Desde el modelo Bell y LaPadula existe un modelo evolucionado del método de la prueba
requerida para demostrar formalmente que las secuencias de todo arbitrarias de Estado
transiciones son la seguridad de preservación. También se demostró que el * - Propiedad
es suficiente para evitar el compromiso de información por Caballo de Troya
ataques.
?
6.3 LA BASE Trusted Computing
Con el fin de fomentar la disponibilidad comercial generalizada de confianza
sistemas informáticos, estos criterios de evaluación han sido diseñados para abordar
aquellos sistemas en los que un núcleo de seguridad se ha implementado específicamente, así
como aquellos en los que un núcleo de seguridad no se ha aplicado. El último caso
incluye aquellos sistemas en los que el objetivo (c) no es totalmente compatible porque
del tamaño o complejidad del mecanismo de validación de referencia. Por
conveniencia, estos criterios de evaluación utilizan el término Trusted Computing Base para
consulte el mecanismo de validación de referencia, ya sea un kernel de seguridad,
filtro de seguridad para el usuario, o de todo el sistema informático de confianza.
El corazón de un sistema informático de confianza es la Trusted Computing Base (TCB)
que contiene todos los elementos del sistema responsables de apoyar
la política de seguridad y apoyar el aislamiento de objetos (código y datos) en
que la protección se basa. Los límites de la TCB equivalen a la "seguridad
perímetro "se hace referencia en alguna literatura seguridad informática. En interés
de la protección comprensible y mantenible, un TCB debería ser tan simple como
posible que sea compatible con las funciones que tiene que realizar. Por lo tanto, la TCB
incluye hardware, firmware y software crítico para la protección y debe ser
diseñado e implementado tales que los elementos del sistema excluidos de ella no tiene por qué
ser de confianza para mantener la protección. Identificación de la interfaz y
elementos de la TCB, junto con por lo tanto su funcionalidad correcta forma la
base para la evaluación.
Para los sistemas de propósito general, la TCB incluirá elementos clave de la
sistema operativo y puede incluir todo el sistema operativo. Para incrustado
sistemas, la política de seguridad pueden tratar con los objetos de una manera que es significativa
a nivel de aplicación en lugar de en el nivel del sistema operativo. Por lo tanto, la
política de protección se puede hacer cumplir en el software de la aplicación y no en
el sistema operativo subyacente. El TCB incluirá necesariamente todos aquellos
partes del sistema y software de aplicación que opera esenciales para la
apoyo a la política. Tenga en cuenta que, como la cantidad de código en los aumentos de TCB,
se hace más difícil estar seguro de que la TCB refuerza el monitor de referencia
requisitos en todas las circunstancias.
?
6.4 ASEGURAMIENTO
El objetivo de diseño tercer monitor de referencia se interpreta actualmente como
lo que significa que la TCB "debe ser de la organización lo suficientemente simple y
complejidad a ser sometido a análisis y pruebas, la integridad de los cuales
puede estar seguro ".
Claramente, como el grado percibido de riesgo aumenta (por ejemplo, la gama de
sensibilidad de los datos protegidos del sistema, junto con la gama de espacios libres
en poder de la población de usuarios del sistema) para un sistema particular de operativa
la aplicación y el medio ambiente, por lo que también deben las seguridades aumentarse a
corroborar el grado de confianza que se colocará en el sistema. Los
jerarquía de requisitos que se presentan para las clases de evaluación en el
criterios de evaluación del sistema informático de confianza reflejan la necesidad de que éstos
garantías.
Como se discutió en la Sección 5.3, los criterios de evaluación requieren un uniforme
declaración de la política de seguridad que se aplica por cada equipo de confianza
sistema. Además, se requiere que se presentará un argumento convincente
eso explica por qué el TCB satisface los dos primeros requisitos de diseño para un
monitor de referencia. No se espera que este argumento será totalmente
formal. Este argumento es necesario para cada sistema candidato con el fin de
satisfacer el objetivo de control de garantía.
Los sistemas a los que se han añadido los mecanismos de aplicación de seguridad, en lugar
de los objetivos de diseño fundamentales incorporadas, no son fácilmente susceptibles de
análisis amplio ya que carecen de la simplicidad conceptual requerido de un
kernel seguridad. Esto es porque su TCB se extiende para cubrir la mayor parte del
todo el sistema. Por lo tanto, su grado de confiabilidad mejor se pueda determinar
Sólo mediante la obtención de resultados de la prueba. Dado que ningún método de ensayo para algo tan
complejo como un sistema informático puede ser verdaderamente exhaustiva, siempre existe la
posibilidad de que un intento de penetración posterior podría tener éxito. Es para
esta razón que tales sistemas deben caer en las clases más bajas de evaluación.
Por otro lado, aquellos sistemas que están diseñados y creados para apoyar
los conceptos TCB son más susceptibles de análisis y pruebas estructurado. Oficial
métodos pueden ser utilizados para analizar la exactitud de su validación referencia
mecanismos para hacer cumplir la política de seguridad del sistema. Otros métodos,
incluyendo argumentos menos formales, se puede utilizar con el fin de fundamentar sus reclamaciones,
por la integridad de su mediación acceso y su grado de
manipulaciones resistencia. Más confianza se puede colocar en los resultados de este
análisis y en el rigor de la prueba estructurada que se puede colocar
en los resultados para sistemas menos estructurados de forma metódica. Por estas razones,
parece razonable concluir que estos sistemas podrían utilizarse en
entornos de alto riesgo. Implementaciones exitosas de tales sistemas serían
clasificado de la forma de evaluación más altas.
?
6.5 LAS CLASES
Es altamente deseable que exista sólo un pequeño número de evaluación global
clases. Tres divisiones principales se han identificado en la evaluación
criterios con una cuarta división reservada para aquellos sistemas que han sido
evaluado y encontrado para ofrecer protección de seguridad inaceptable. Dentro de cada
división principal de evaluación, se encontró que las clases "intermedias" de confianza
diseño y desarrollo del sistema de manera significativa podrían definirse. Estas
clases intermedias han sido designados en los criterios, ya que
identificar los sistemas que:
* Son vistos ofrecer significativamente mejor protección y garantía
sistemas de lo que sería que satisfagan los requisitos básicos para su
clase de evaluación; y
* No hay razón para creer que los sistemas de la intermedia
clases de evaluación eventualmente podrían evolucionado de tal manera que
satisfaga los requisitos para la próxima evaluación más alta
clase.
Excepto dentro de la división A que no se prevé que adicional "intermedia"
clases de evaluación que satisfagan las dos características descritas anteriormente serán
identificados.
Las distinciones en cuanto a la arquitectura del sistema, la aplicación de la política de seguridad, y
pruebas de credibilidad entre las clases de evaluación se han definido de manera que
el "salto" entre las clases de evaluación requeriría una inversión considerable
de esfuerzo por parte de los ejecutores. Correspondientemente, no se espera que
ser diferenciales significativos de riesgo a que los sistemas de la más alta
clases de evaluación serán expuestos.
?
7.0 LA RELACIÓN ENTRE LA POLÍTICA Y LOS CRITERIOS
Sección 1 presenta los requisitos de seguridad fundamentales ordenador y la sección 5
presenta los objetivos de control para sistemas informáticos de confianza. Ellos son
requisitos generales, útiles y necesarias, para el desarrollo de todo seguro
sistemas. Sin embargo, en el diseño de sistemas que se utilizarán para procesar
información confidencial clasificada u otra, los requisitos funcionales para la reunión
los Objetivos de Control se vuelven más específico. Hay un gran cuerpo de la política
establecido en forma de reglamentos, directivas, Ejecutivo Presidencial
Ordenes y Circulares de la OMB que forman la base de los procedimientos para la
manejo y procesamiento de información federal en general y clasificada
información específica. En esta sección se presenta extractos pertinentes de éstos
declaraciones de política y analiza su relación con los Objetivos de Control.
Estos extractos son ejemplos para ilustrar la relación de las políticas de
criterios y pueden no estar completos.
?
7.1 POLÍTICAS federal estableció
Un número importante de las políticas de seguridad informática y los requisitos asociados
se han promulgado por elementos del gobierno federal. El lector interesado
se refiere a la referencia [32] que analiza la necesidad de sistemas de confianza en
las agencias civiles del gobierno federal, así como en el estatal y local
los gobiernos y en el sector privado. Esta referencia también detalla una serie
de las leyes federales, las políticas y requisitos pertinentes no se trata más
a continuación.
Guía de seguridad para los sistemas de información automatizada federales es proporcionada por el
Oficina de Administración y Presupuesto. Dos Circulares específicamente aplicables tienen
ha emitido. OMB Circular No. A-71, Transmisión Memorando Nº 1, "Seguridad
de Federal de Sistemas de Información Automatizado, "[26] dirige cada agencia ejecutiva
para establecer y mantener un programa de seguridad informática. Esto hace que el jefe de
cada rama ejecutiva, departamento y organismo responsable "para asegurar una
nivel adecuado de seguridad para todos los datos de las agencias ya sean elaborados en la empresa o
comercialmente. Esto incluye la responsabilidad de la creación de bienestar físico,
salvaguardias administrativos y técnicos necesarios para proteger adecuadamente
datos confidenciales personales, de propiedad u otros que no están sujetos a la seguridad nacional
regulaciones, así como los datos de seguridad nacional ". [26, párr. 4 p. 2]
OMB Circular No. A-123, "Sistemas de Control Interno", [27] emitió para ayudar
eliminar el fraude, el despilfarro y el abuso en los programas de gobierno se requiere: (a) la agencia
cabezas para emitir directivas de control interno y asignar la responsabilidad, (b)
administradores para revisar los programas de la vulnerabilidad, y (c) los administradores a realizar
revisiones periódicas para evaluar las fortalezas y controles de actualización. Poco después
promulgación de la OMB Circular A-123, la relación de su control interno
requisitos para la construcción de sistemas informáticos seguros fue reconocido. [4] Aunque no
estipulando controles informáticos específicamente, la definición de Interior
Controles en A-123 deja claro que los sistemas informáticos se deben incluir:
"Controles internos - El plan de la organización y todos los métodos y
medidas adoptadas dentro de una agencia para salvaguardar sus recursos, asegurar la
exactitud y fiabilidad de la información, para asegurar la adherencia
leyes, reglamentos y políticas, y promover la operativa
economía y eficiencia. "[27, sec. 4.C]
El asunto de la información de seguridad nacional clasificada procesado por ADP
sistemas fue una de las primeras áreas dadas preocupación grave y extensa en
la seguridad informática. Los documentos de política de seguridad informática promulgadas como
resultado contiene requisitos generalmente más específicos y estructurados que la mayoría,
introducido a su vez a una base de autoridad que sí proporciona un lugar claramente
política de seguridad de la información articulada y estructurada. Esta base, Ejecutivo
Orden 12356, "Información de Seguridad Nacional", establece los requisitos para el
clasificación, desclasificación y la salvaguardia de la "seguridad nacional
información "en sí. [14]
?
7.2 POLÍTICAS DOD
Dentro del Departamento de Defensa, se implementan estos requisitos generales y
más indicado principalmente a través de dos vehículos: 1) El Reglamento DoD 5200.1-R
[7], que se aplica a todos los componentes del Departamento de Defensa, como tal, y 2) DoD 5220.22-M,
"Seguridad Industrial Manual para la protección de información clasificada" [11],
que se aplica a contratistas incluidos dentro de la Seguridad Industrial de Defensa
Programa. Tenga en cuenta que este último trasciende DoD como tal, ya que no se aplica
sólo para los contratistas manejan información clasificada para cualquier componente del Departamento de Defensa,
sino también a los contratistas de otras dieciocho organizaciones federales para los cuales
el Secretario de Defensa está autorizado para actuar en la prestación de la seguridad industrial
servicios. *
______________________________
* Es decir, de la NASA, el Departamento de Comercio, GSA, Departamento de Estado, la pequeña empresa
Administración, Fundación Nacional de Ciencias, Departamento del Tesoro,
Departamento de Transporte, Departamento del Interior, Departamento de Agricultura, EE.UU.
Agencia de Información, Departamento de Trabajo, Agencia de Protección del Medio Ambiente, Justicia
Departamento, US Control de Armas y Desarme Agencia Federal Emergency
Agencia de Gestión, Sistema de la Reserva Federal, y la Oficina de Contabilidad General.
Para los sistemas de ADP, estos requisitos de seguridad de información se amplifican aún más
y especificado en: 1) Directiva DoD 5200.28 [8] y DoD 5200.28-M Manual [9],
para los componentes del Departamento de Defensa; y 2) la Sección XIII del DoD 5220.22-M [11] para los contratistas.
Directiva DoD 5200.28, "Requisitos de seguridad para Automatic Data Processing
(ADP) Sistemas ", estipula:" El material clasificado contenida en un sistema de ADP
deberán tener protección por el empleo continuo de las funciones de protección en
hardware y software de diseño del sistema y la configuración. . . . "[8,
seg. IV] Además, se requiere que los sistemas de ADP que "procesar, almacenar,
o utilizar datos clasificados y producir información clasificada hará, con
fiabilidad razonable, prevenir:
a. Acceso deliberada o inadvertida de material clasificado por
personas no autorizadas, y
b. La manipulación no autorizada de la computadora y sus asociados
dispositivos periféricos ". [8, sec. I B.3]
Requisitos equivalentes a éstas aparecen dentro DoD 5200.28-M [9] y en el Departamento de Defensa
5220.22-M [11].
DoD 5200.28 Directove proporciona los requisitos de seguridad para los sistemas de ADP. Por
algunos tipos de información, como Sensible Información Compartmented (SCI),
Directiva DoD 5200.28 establece que los otros requisitos de seguridad mínimos también
aplicar. Estos mínimos se encuentran en DCID l / l6 (nuevo número de referencia 5), que es
implementado en DIAM 50-4 (nuevo número de referencia 6) para el Departamento de Defensa y el contratista del Departamento de Defensa
Sistemas de ADP.
A partir de los requisitos impuestos por estos reglamentos, directivas y circulares, la
tres componentes del Objetivo de Control de Política de Seguridad, es decir, obligatoria y
Seguridad discrecional y marcado, así como la rendición de cuentas y
Control de Aseguramiento de Objetivos, puede ser funcionalmente definido para el Departamento de Defensa
aplicaciones. La siguiente discusión proporciona más especificidad en la Política
para estos objetivos de control.
?
7.3 CRITERIOS OBJETIVO DE CONTROL PARA LA POLÍTICA DE SEGURIDAD
7.3.1 Marcado
El objetivo de control para el marcado es: "Los sistemas que están diseñados
para hacer cumplir una política de seguridad obligatoria deben almacenar y conservar la
integridad de clasificación u otro sensibilidad etiquetas para todos
información. Las etiquetas exportadas del sistema deben ser precisos
representaciones de las etiquetas de sensibilidad internos corresonding
siendo exportado ".
DoD 5220.22-M ", Manual de Seguridad Industrial para la protección de
Información Clasificada ", explica en el párrafo 11 de las razones de
marcando información:
"a. General. designación Clasificación por física
marcado, la notación u otros medios sirve para advertir y para
informar al titular qué grado de protección contra
la divulgación no autorizada se reqired para que la información
o material. "(14)
Requisitos de marcado se dan en una serie de declaraciones políticas.
Orden Ejecutiva 12356 (secciones 1.5.a y 1.5.a.1) requiere que
marcas de clasificación "se muestran en la cara de todos
documentos clasificados, o claramente asociados con otras formas de
información clasificada de una manera adecuada al medio
los involucrados. "[14]
DoD Reglamento 5200.1-R (Sección 1-500) requiere que: "...
información o material que requiere la protección contra
la divulgación no autorizada en interés de la seguridad nacional deberá
se clasificarán en una de las tres denominaciones, a saber: 'Top Secret'
"Secreto" o "Confidencial". [7] (Por extensión, para el uso en computadora
procesamiento, la designación no oficial "Sin clasificación" se utiliza para
indicar información que no cae bajo una de la otra
tres denominaciones de información clasificada.)
Reglamento DoD 5200.1-R (Sección 4-304b) requiere que: "ADP
sistemas y sistemas de procesamiento de textos que emplean tales medios deberán
prever clasificación interna que marca para asegurar que
información clasificada contenida en el mismo que se reproduce o
generado, se hará cargo de la clasificación aplicable y asociados
marcas ". (Este Reglamento establece la exención de determinadas
sistemas existentes donde "clasificación interna y aplicable
marcas asociadas no pueden aplicarse sin extenso sistema
modificaciones. "[7] Sin embargo, está claro que el futuro DoD ADP
sistemas deben ser capaces de proporcionar etiquetas aplicables y precisos para
clasificada y otra información sensible.)
DoD 5200.28-M Manual (Sección IV, 4-305d) requiere lo siguiente:
"Etiquetas de seguridad - Todo el material clasificado accesibles por o dentro
el sistema de ADP se identificará como a su seguridad
clasificación y de acceso o de difusión limitaciones, y todo
salida del sistema ADP deberá marcarse debidamente ". [9]
7.3.2 Obligatorio Seguridad
El objetivo de control de la seguridad obligatoria es: "Seguridad
políticas definidas para los sistemas que se utilizan para procesar clasifican
u otra información sensible categorizado específicamente debe
incluir disposiciones para la aplicación de control de acceso obligatorio
reglas. Es decir, deben incluir un conjunto de reglas para el control de
de acceso basado directamente en una comparación de los individuales de
autorización o autorización para la información y la
clasificación o sensibilidad designación de la información es
buscado, e indirectamente en consideraciones de física y otro
factores ambientales de control. El control de acceso obligatorio
reglas deben reflejar con precisión las leyes, reglamentos, y general
las políticas de las que se derivan ".
Hay una serie de declaraciones políticas que se relacionan con
seguridad obligatoria.
Orden Ejecutiva 12356 (sección 4.1.a) establece que "una persona es
elegibles para el acceso a la información clasificada a condición de que un
determinación de la confiabilidad ha sido hecha por los jefes de agencias o
designado funcionarios y siempre que dicho acceso es esencial
a la realización de Gobierno legal y autorizada
fines ". [14]
Reglamento DoD 5200.1-R (Capítulo I, Sección 3) define un Especial
Programa de Acceso como "cualquier programa de imponer la« necesidad de conocer »o acceso
controles más allá de las prestaciones realizadas normalmente por el acceso a
Información secreta confidencial, secreta o Superior. Tal programa
incluye, pero no se limita a, una autorización especial, adjudicación,
o requerimientos de investigación, la designación especial de funcionarios
listas autorizadas para determinar la "necesidad de conocer", o especiales de las personas
decidido a tener un 'know-a-necesidad.' "[7, párr. 1-328] Este
pasaje distingue entre una determinación 'discrecional' de
necesita-a-saber y que se implementa a través de necesidad-a-saber formales
Programas especiales de acceso. DoD Reglamento 5200.1-R, párrafo 7-100
describe los requisitos generales para la fiabilidad (depuración) y
necesita-a-saber, y afirma que la persona con la posesión,
conocimiento ni control de la información clasificada tiene definitiva
la responsabilidad de determinar si las condiciones de acceso han sido
reunió. Este reglamento establece además que "nadie tiene un derecho
a tener acceso a información clasificada únicamente en virtud de rango
o posición ". [7, párr. 7-100])
DoD 5200.28-M Manual (Sección II 2-100) afirma que, Personal "
que desarrollan, de prueba (depuración), mantener o utilizar programas que son
clasificadas o que se utilizará para acceder o desarrollar clasificado
material deberá tener una autorización de seguridad del personal y de un acceso
autorización (necesidad de saber), según corresponda a la más alta
categoría clasificada y más restrictivo de material clasificado
que van a acceder a virtud de las limitaciones del sistema ". [9]
DoD 5220.22-M Manual (3.a párrafo) define el acceso como "el
la capacidad y la oportunidad de obtener conocimiento del clasificado
información. Un individuo, de hecho, puede tener acceso a
información clasificada por estar en un lugar donde dicha información
se mantiene, si las medidas de seguridad que estén en vigor no lo hacen
le impidió ganar conocimiento del clasificado
información ". [11]
Lo anterior Orden Ejecutiva, Manual, Directivas y
Reglamento implica claramente que un sistema informático de confianza debe
aseguran que las etiquetas de clasificación asociados con sensibles
los datos no se pueden cambiar arbitrariamente, ya que esto podría permitir
las personas que carecen de la adecuada habilitación para el acceso
información clasificada. También implícita es el requisito de que un
sistema informático de confianza debe controlar el flujo de información a fin de
que los datos de una clasificación superior no puede ser colocado en una
almacenamiento de objetos de la clasificación más baja a menos que su "degradación"
ha sido autorizado.
7.3.3 Seguridad Discrecional
El término se refiere a la seguridad discrecional de un sistema informático
capacidad de controlar la información en una base individual. Se deriva
del hecho de que a pesar de que un individuo tiene todo lo formal
autorizaciones para el acceso a la información clasificada específica, cada uno
el acceso del individuo a la información debe basarse en un demostrado
necesito saber. Debido a esto, debe quedar claro que esta
requisito no es discrecional en un "lo tomas o lo dejas" sentido.
Las directivas y reglamentos son explícitos en afirmar que la
necesita-a-saber de prueba debe ser satisfecha antes de que pueda concederse el acceso
a la información clasificada. El objetivo de control para
seguridad discrecional es: "Las políticas de seguridad definida para los sistemas
que se utilizan para procesar información sensible clasificada u otro
debe incluir disposiciones para la aplicación de la discrecionalidad
reglas de control de acceso. Es decir, deben incluir un conjunto coherente
de reglas para controlar y limitar el acceso basado en identificado
individuos que se ha determinado que tienen una necesidad de conocer para el
información ".
DoD Reglamento 5200.1-R (Párrafo 7-100) Además de extractos
ya condición de que toque en la necesidad-to-know, esta sección de la
regulación destaca el principio de menor dominio a-saber cuando afirma "no
persona puede tener acceso a información clasificada a menos. . .
el acceso es necesario para el desempeño de funciones oficiales ". [7]
También, DoD 5220.22-M Manual (Sección III 20.a) establece que "una
se le permitirá individuo a tener acceso a clasificado
sólo información . . . cuando el contratista determina que el acceso
es necesaria en el desempeño de las tareas o servicios esenciales para
el cumplimiento de un contrato o programa, es decir, el individuo tiene
una necesidad de conocer ". [11]
?
7.4 CRITERIOS PARA LA RENDICIÓN DE CUENTAS OBJETIVO DE CONTROL
El objetivo de control para la rendición de cuentas es: "Los sistemas que se utilizan para procesar
o el tirador clasificado u otra información sensible debe asegurar individuo
la rendición de cuentas cada vez que sea una política de seguridad obligatoria o discrecional es
invocado. Además, para asegurar la rendición de cuentas de la capacidad debe existir para
un agente autorizado y competente para acceder y evaluar la rendición de cuentas
la información por un medio seguro, dentro de un tiempo razonable, y sin
dificultades excesivas ".
Este objetivo de control se apoya en las siguientes citas:
Directiva DoD 5200.28 (VI.A.1) afirma: "la identidad de cada usuario será
establecido positivamente, y su acceso al sistema, y su actividad en
el sistema (incluyendo material de acceso y medidas adoptadas) controlado y
abrir al escrutinio ". [8]
DoD 5200.28-M Manual (Sección V 5-100) afirma: "Un registro de auditoría o archivo
(manual, máquina, o una combinación de ambos) se mantendrán como
historia de la utilización del Sistema de ADP para permitir una revisión de seguridad regulares
de la actividad del sistema. (por ejemplo, el registro debe registrar la seguridad relacionada
transacciones, incluyendo una visita a un archivo clasificado y la naturaleza
de los accesos, por ejemplo, nombres de usuarios, la producción de cuentas clasificado
salidas, y la creación de nuevos archivos clasificados. Cada archivo clasificado
visitada éxito [con independencia del número de referencias individuales]
durante cada "trabajo" o "sesión interactiva también deben registrarse en el
registro de auditoría. Gran parte del material de este registro también se puede requerir a
asegurar que el sistema conserva la información confiada a él). "[9]
DoD 5200.28-M Manual (Sección 4-305f IV) declara: "Cuando sea necesario para asegurar
el control de acceso y la responsabilidad individual, cada usuario o específica
grupo de usuarios se identificará al Sistema ADP idóneas
administrativas o de hardware / software. Dicha identificación
medidas deben ser lo suficientemente detallada para permitir que el sistema de ADP para proporcionar
el usuario sólo que el material que está autorizado. "[9]
DoD 5200.28-M Manual (Sección I 1-102b) declara:
Autoridades "de componentes designados aprobar, o sus representantes
para este propósito . . . asegurará:
. . . . . . . . . . . . . . . . .
(4) El mantenimiento de la documentación de los sistemas operativos (O / S)
y todas las modificaciones a los mismos, y su retención por un
periodo de tiempo suficiente para habilitar el seguimiento de seguridad-
defectos relacionados a su punto de origen o su inclusión en el
sistema.
. . . . . . . . . . . . . . . . .
(6) El establecimiento de procedimientos para descubrir, recuperar,
manejar y disponer de material clasificado incorrectamente
dado a conocer a través de mal funcionamiento del sistema o el personal de la acción.
(7) la disposición adecuada y la corrección de la seguridad
deficiencias en los sistemas de ADP todos aprobados, y la efectiva
uso y disposición de los registros de limpieza del sistema o de auditoría,
registros de violaciónes de seguridad o sistema relacionado con la seguridad
mal funcionamiento, y los registros de las pruebas de las funciones de seguridad
de un Sistema de ADP. "[9]
Manual DoD 5220.22-M (Sección XIII 111) afirma: "Audit Trails
a. El requisito de seguridad general para cualquier auditoría del sistema ADP
sendero es que proporciona una historia documentada de la utilización de
el sistema. Una pista de auditoría aprobado permitirá la revisión de
la actividad del sistema clasificada y proporcionará una detallada
registro de actividad para facilitar la reconstrucción de eventos para
determinar la magnitud de compromiso (si existe) debe una
produce un mal funcionamiento de la seguridad. Para cumplir con este básico
requisito, los sistemas de seguimiento de auditoría, manual, automático o una
combinación de ambos debe documentar eventos importantes
que ocurre en las siguientes áreas de interés: (i) la preparación
de los datos de entrada y difusión de datos de salida (es decir,
interactividad reportable entre los usuarios y el apoyo del sistema
personal), (ii) la actividad implicada en un entorno ADP
(por ejemplo, ADP modificación personal de apoyo de la seguridad y
controles relacionados), y (iii) la actividad interna de la máquina.
b. La pista de auditoría para un sistema ADP aprobado para procesar
información clasificada debe basarse en los tres anteriores
áreas y pueden ser estilizadas al sistema particular. Todo
sistemas aprobados para el procesamiento clasificado deben contener
la mayoría, si no todos los registros de seguimiento de auditoría se enumeran a continuación. Los
documentación SPP del contratista deberá identificar y describir
las aplicables:
1. Acceso de Personal;
2. La entrada no autorizada y subrepticia en el
instalaciones ordenador central o áreas terminales remotas;
3. Hora de inicio / parada de procesamiento clasificada indicando
iniciación seguridad de los sistemas pertinentes y eventos de terminación
(por ejemplo, la actualización / acciones degradar conformidad con el párrafo
107);
4. Todas las funciones iniciados por la consola del sistema ADP
operadores;
5. Desconecta de terminales remotos y periféricos
dispositivos (párrafo 107C);
6. Iniciar sesión en y desconexión actividad de los usuarios;
7. Los intentos no autorizados de acceder a archivos o programas,
así como todos abrir, cerrar, crear y destruir archivos
acciones;
8. Programa aborta y anomalías incluyendo
información de identificación (es decir, el usuario / nombre del programa, el tiempo
y la ubicación del incidente, etc.);
9. hardware Sistema de adiciones, supresiones y mantenimiento
acciones;
10. Generaciones y modificaciones que afectan a la
características de seguridad del software del sistema.
c. El supervisor de la seguridad del sistema ADP o la persona designada
revisar los registros de seguimiento de auditoría al menos semanalmente para asegurar que
toda la actividad pertinente se registra correctamente y que
las medidas adecuadas se ha tomado para corregir cualquier anomalía.
La mayoría de los sistemas de ADP en uso hoy en día se puede desarrollar la auditoría
sistemas de senderos de acuerdo con lo anterior; sin embargo, especial
sistemas tales como armas, comunicaciones, comunicaciones
sistemas de seguridad y de intercambio de datos tácticos y de visualización,
puede no ser capaz de cumplir con todos los aspectos de lo anterior y
puedan exigir una atención individualizada por el consciente
Oficina de seguridad.
d. Los registros de seguimiento de auditoría se conservarán durante un período de un
ciclo de inspección. "[11]
?
7.5 CRITERIOS OBJETIVOS DE CONTROL DE ASEGURAMIENTO
El objetivo de control para la garantía es: "Los sistemas que se utilizan para procesar o
mango clasificado u otra información sensible debe estar diseñado para garantizar
interpretación correcta y precisa de la política de seguridad y no debe distorsionar
la intención de esta política. Aseguramiento de que el producto correcto
existe aplicación y el funcionamiento de la política en todo el sistema de
ciclo de la vida."
A base de este objetivo se puede encontrar en las siguientes secciones del Departamento de Defensa
Directiva 5200.28:
Directiva DoD 5200.28 (IV.B.1) estipula: "En general, la seguridad de un ADP
sistema es más eficaz y económica si el sistema está diseñado
originalmente para proporcionarla. Cada Departamento de Defensa de componentes
emprender el diseño de un sistema de ADP, que se espera para procesar, almacenar,
utilizar o producir material clasificado deberá: Desde el inicio de la
proceso de diseño, tener en cuenta las políticas de seguridad, conceptos y medidas
prescrito en la presente Directiva ". [8]
Directiva DoD 5200.28 (IV.C.5.a) afirma: "Se puede prever para permitir
el ajuste de área del sistema ADP controles para el nivel de protección
requerido para la categoría de clasificación y tipo (s) de material de hecho
siendo manejado por el sistema, se desarrollan procedimientos de cambio previstos y
implementado, lo que impide tanto el acceso no autorizado a los clasificados
material manipulado por el sistema y la manipulación no autorizada de la
sistema y sus componentes. Se prestará especial atención a la
la protección continua de las medidas de seguridad del sistema automatizado, técnicas
y procedimientos cuando el nivel de autorización de seguridad personal de los usuarios
tener acceso a los cambios en el sistema ". [8]
Directiva DoD 5200.28 (VI.A.2) afirma: "Control Ambiental La ADP.
Sistema estará protegido externamente para minimizar la probabilidad de
acceso no autorizado a los puntos de entrada del sistema, acceso a clasificado
información en el sistema, o daños en el sistema ". [8]
DoD 5200.28-M Manual (Sección I 1-102b) declara:
Autoridades "de componentes designados aprobar, o sus representantes
para este propósito . . . asegurará:
. . . . . . . . . . . . . . . . .
(5) La supervisión, monitoreo y pruebas, según proceda, de
cambios en un sistema de ADP aprobado que pudieran afectar a la
características de seguridad del sistema, por lo que un sistema seguro es
mantenido.
. . . . . . . . . . . . . . . . .
(7) la disposición adecuada y la corrección de la seguridad
deficiencias en los sistemas de ADP todos aprobados, y la efectiva
uso y disposición de los registros de limpieza del sistema o de auditoría,
registros de violaciónes de seguridad o sistema relacionado con la seguridad
mal funcionamiento, y los registros de las pruebas de las funciones de seguridad
de un Sistema de ADP.
(8) Realización de sistema competente ST & E, la revisión oportuna de
sistema de ST & E informes, y la corrección de las deficiencias necesarios
para apoyar la aprobación o desaprobación condicional o definitiva de
un Sistema de ADP para el procesamiento de la información clasificada.
(9) El establecimiento, en su caso, de un centro de ST & E
punto de coordinación para el mantenimiento de registros de
técnicas seleccionadas, procedimientos, estándares y pruebas utilizadas
en las pruebas y evaluación de las características de seguridad de ADP
Sistemas que pueden ser adecuados para la validación y el uso de
otra Departamento de Componentes de Defensa ". [9]
Manual DoD 5220.22-M (Sección XIII 103a) exige que: "la aprobación inicial,
por escrito, de la oficina de seguridad consciente antes de procesar cualquier
información clasificada en un sistema de ADP. Esta sección requiere
reaprobación por la oficina de seguridad consciente de los sistemas principales
modificaciones hechas con posterioridad a la aprobación inicial. Reapprovals serán
requerido por (i) cambios importantes en los requisitos de acceso de personal,
(ii) reubicación o modificación estructural de la computadora central
instalación, (iii) adiciones, supresiones o cambios de marco principal, almacenamiento o
dispositivos de entrada / salida, (iv) los cambios de software del sistema de seguridad impactando
características de protección, (v) cualquier cambio en el aclaramiento, desclasificación, la auditoría
camino o de hardware / software de los procedimientos de mantenimiento, y (vi) otros sistemas
cambios determinados por la oficina de seguridad consciente ". [11]
Un componente importante de la garantía, la garantía de ciclo de vida, como se describe en el Departamento de Defensa
7920.l Directiva, tiene que ver con los sistemas de pruebas de ADP, tanto en el
fase de desarrollo, así como durante el funcionamiento (17). Directiva DoD 5215.1
(Sección F.2.C. (2)) requiere "evaluaciones de la industria seleccionada y
gobierno-desarrollado sistemas informáticos de confianza en contra de estos criterios ". [10]
?
8.0 Una directriz sobre canales encubiertos
Un canal secreto es cualquier canal de comunicación que puede ser explotado por una
proceso para transferir información de una manera que viole el sistema de
politica de seguridad. Hay dos tipos de canales: canales encubiertos almacenamiento y
canales de distribución. Canales de almacenamiento Covert incluir todos los vehículos que lo haría
permitir que la escritura directa o indirecta de una ubicación de almacenamiento por un proceso y
la lectura directa o indirecta de la misma por otro. Canales de temporización Covert
incluir todos los vehículos que permitan un proceso a la señal de información a
otro proceso mediante la modulación de su propio uso de los recursos del sistema de tal manera
que el cambio en el tiempo de respuesta observado por el segundo proceso proporcionaría
información.
Desde una perspectiva de seguridad, canales encubiertos con anchos de banda bajos representan una
amenaza menor que aquellos con altos anchos de banda. Sin embargo, para muchos tipos de
canales encubiertos, las técnicas utilizadas para reducir el ancho de banda por debajo de una cierta tasa
(que depende del mecanismo de canal específico y la arquitectura del sistema)
también tienen el efecto de degradar el rendimiento proporcionado para legitimar
los usuarios del sistema. Por lo tanto, un equilibrio entre el rendimiento del sistema y encubierta
ancho de banda de canal se debe hacer. Debido a la amenaza de compromiso que
estaría presente en cualquier sistema informático multinivel contiene clasificada o
información sensible, tales sistemas no debe contener canales encubiertos con
altos anchos de banda. Esta guía tiene como objetivo proporcionar a los desarrolladores del sistema con
una idea de qué tan alto ancho de banda de un canal secreto "alta" es.
Un ancho de banda de canal encubierto que supera una velocidad de cien (100) bits por
segundo se considera "alta" porque 100 bits por segundo es la aproximada
velocidad a la que se ejecutan muchos terminales de ordenador. No parece apropiado
para llamar a un sistema informático "seguro" si la información se puede comprometer a un ritmo
igual a la velocidad de salida normal de algún dispositivo de uso común.
En cualquier sistema informático multinivel hay una serie de relativamente
bajo ancho de banda canales encubiertos cuya existencia está profundamente arraigado en la
diseño de sistemas. Ante el gran costo potencial de reducir los anchos de banda
de tales canales encubiertas, se considera que aquellos con anchos de banda máxima de menos
de un (1) bits por segundo son aceptables en la mayoría de entornos de aplicación.
Aunque mantiene un rendimiento aceptable en algunos sistemas puede hacer que sea
poco práctico para eliminar todos los canales encubiertas con anchos de banda de 1 o más bits
por segundo, es posible auditar su uso sin afectar adversamente
rendimiento de sistema. Esta capacidad de auditoría proporciona la administración del sistema
con un medio de detección - corrección y procesalmente - significativo
compromiso. Por lo tanto, una Base de Trusted Computing debe proporcionar, siempre que sea
posible, la capacidad de auditar el uso de mecanismos de canales encubiertos con
anchos de banda que pueden superar a razón de un (1) bits en diez (10) segundos.
El problema canal secreto ha sido tratado por varios autores. Los
lector interesado puede consultar las referencias [5], [6], [19], [21], [22], [23],
y [29].
?
9.0 una directriz sobre la configuración de funciones control de acceso obligatorio
El requisito de control de acceso obligatorio incluye una capacidad para apoyar una
número no especificado de las clasificaciones jerárquicas y un número no especificado
de categorías no jerárquicas en cada nivel jerárquico. Para fomentar
coherencia y la transferibilidad en el diseño y desarrollo de la National
Establecimiento de Seguridad de los sistemas informáticos de confianza, es deseable para todos tales
sistemas para ser capaz de soportar un número mínimo de niveles y categorías. Los
siguientes sugerencias se proporcionan para este propósito:
* El número de clasificaciones jerárquicas debe ser mayor o
igual a dieciséis (16).
* El número de categorías no jerárquicas debe ser mayor o
igual a sesenta y cuatro (64).
?
10.0 Una GUÍA SOBRE LAS PRUEBAS DE SEGURIDAD
Estas directrices se proporcionan para dar una indicación de la extensión y
sofisticación de la prueba llevada a cabo por el Centro de seguridad de computadoras del Departamento de Defensa
durante el proceso de evaluación formal del producto. Las organizaciones que deseen utilizar
"Departamento de Defensa Trusted Computer System Evaluation Criteria" para
realizar sus propias evaluaciones puede encontrar esta sección útil para la planificación
propósitos.
Como en la primera parte, el resaltado se utiliza para indicar los cambios en las pautas de
la categoría inmediatamente inferior.
?
10.1 ENSAYO DE LA DIVISIÓN C
10.1.1 Personal
El equipo de pruebas de seguridad estará integrado por al menos dos
individuos con una licenciatura en Ciencias de la Computación o la
equivalente. Los miembros del equipo deben ser capaces de seguir los planes de prueba
preparado por el desarrollador del sistema y sugerir adiciones, se
estar familiarizados con la "hipótesis de falla" o garantía equivalente
probar la metodología, y tendrán la programación a nivel de montaje
experiencia. Antes de que comience la prueba, los miembros del equipo tendrán
conocimiento funcional de, y habrá completado el sistema
Por supuesto internos del desarrollador para el sistema que se está evaluando.
10.1.2 Prueba
El equipo tendrá "manos" participación en una carrera independiente
de las pruebas utilizadas por el desarrollador del sistema. El equipo deberá
independientemente diseñar y poner en práctica específica del sistema por lo menos cinco
pruebas en un intento de eludir los mecanismos de seguridad de la
sistema. El tiempo transcurrido dedicado a las pruebas será de al menos
un mes y no necesita ser superior a tres meses. No habrá
menos de veinte práctica en horas pasadas realización de sistema
pruebas para desarrolladores definidos y pruebas de equipos definidos de prueba.
?
10.2 ENSAYO DE LA DIVISIÓN B
10.2.1 Personal
El equipo de pruebas de seguridad estará integrado por al menos dos
individuos con una licenciatura en Ciencias de la Computación o la
equivalente y al menos una persona con un grado de maestría en
Ciencia o equivalente ordenador. Los miembros del equipo deben ser capaces de
seguir los planes de pruebas preparados por el desarrollador del sistema y sugerir
adiciones, deberán estar familiarizados con la "hipótesis de falla" o
metodología de las pruebas de seguridad equivalente, deberá ser fluido en el
TCB lenguaje de implementación (s), y tendrá nivel de ensamblado
experiencia en programación. Antes de la prueba comienza, los miembros del equipo
tendrá conocimiento funcional de, y habrá completado la
Por supuesto internos del desarrollador del sistema para, siendo el sistema
evaluado. Al menos un miembro del equipo deberá tener previamente
completado una prueba de seguridad en otro sistema.
10.2.2 Prueba
El equipo tendrá "manos" participación en una carrera independiente
del paquete de prueba utilizado por el desarrollador del sistema para probar
hardware y software de seguridad pertinentes. El equipo deberá
independientemente diseñar e implementar por lo menos quince sistema-
pruebas específicas en un intento de eludir la seguridad
mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas
será como mínimo de dos meses y no tiene por qué ser superior a cuatro meses.
No habrá menos de treinta manos a la hora por equipo
miembro pasó la realización de pruebas para desarrolladores definidas por el sistema y
prueba de equipo define pruebas.
?
10.3 ENSAYO DE LA DIVISIÓN A
10.3.1 Personal
El equipo de pruebas de seguridad estará integrado por al menos un
persona con una licenciatura en Ciencias de la Computación o la
equivalente y al menos dos personas con grados de maestría en
Ciencia o equivalente ordenador. Los miembros del equipo deben ser capaces de
seguir los planes de pruebas preparados por el desarrollador del sistema y sugerir
adiciones, deberán estar familiarizados con la "hipótesis de falla" o
metodología de las pruebas de seguridad equivalente, deberá ser fluido en el
TCB lenguaje de implementación (s), y tendrá nivel de ensamblado
experiencia en programación. Antes de la prueba comienza, los miembros del equipo
tendrá conocimiento funcional de, y habrá completado la
Por supuesto internos del desarrollador del sistema para, siendo el sistema
evaluado. Al menos un miembro del equipo deberá ser lo suficientemente familiarizado
con el hardware del sistema para comprender el mantenimiento de diagnóstico
los programas y la documentación de soporte de hardware. Al menos dos
los miembros del equipo deberán haber realizado previamente una prueba de seguridad en
otro sistema. Al menos un miembro del equipo tendrá
competencia de programación a nivel de sistema demostrado en el sistema
bajo prueba a un nivel de complejidad equivalente a la adición de un dispositivo
controlador al sistema.
10.3.2 Prueba
El equipo tendrá "manos" participación en una carrera independiente
del paquete de prueba utilizado por el desarrollador del sistema para probar
hardware y software de seguridad pertinentes. El equipo deberá
independientemente diseñar e implementar al menos veinticinco sistema-
pruebas específicas en un intento de eludir la seguridad
mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas
será como mínimo de tres meses y no tiene por qué ser superior a seis meses.
No habrá menos de cincuenta manos a la hora por equipo
miembro pasó la realización de pruebas para desarrolladores definidas por el sistema y
prueba de equipo define pruebas.
?
APÉNDICE A
PROCESO DE EVALUACIÓN PRODUCTO COMERCIAL
"Departamento de Defensa Trusted Computer System Evaluation Criteria" forma la
base sobre la que el Centro de Seguridad Informática realizará el anuncio
proceso de evaluación de la seguridad informática. Este proceso se centra en el comercio
de propósito general productos producidos y apoyados sistema operativo que cumplen con la
necesidades de los departamentos y agencias gubernamentales. La evaluación formal se dirige
en "off-the-shelf" comercialmente apoyado productos y está completamente divorciado
de cualquier consideración de rendimiento general del sistema, las aplicaciones potenciales,
o entornos de procesamiento particulares. La evaluación proporciona un insumo clave para
una seguridad del sistema informático de aprobación / acreditación. Sin embargo, no lo hace
constituyen una evaluación completa seguridad del sistema informático. Un estudio completo
(por ejemplo, como en la referencia [18]) deben considerar factores adicionales tratar con el
sistema en su ambiente único, tal como se propone el modo de seguridad de
operación, usuarios específicos, aplicaciones, la sensibilidad de datos, física y
la seguridad personal, administrativo y de seguridad procesal, tempestad, y
seguridad de las comunicaciones.
El proceso de evaluación del producto realizado por el Centro de Seguridad Informática tiene
tres elementos distintos:
* Evaluación preliminar del producto - Un diálogo informal entre un vendedor
y el Centro en el que se intercambia información técnica para crear un
entendimiento común de producto del proveedor, los criterios y el
calificación que se puede esperar que el resultado de una evaluación formal del producto.
* Evaluación formal Producto - Una evaluación formal, por el Centro, de un
producto que está disponible para el Departamento de Defensa, y que da lugar a que el producto
y su calificación asignada se coloca en la Lista de Productos evaluadas.
* Lista evaluadas Productos - Una lista de los productos que han sido sometidos
para la evaluación del producto formal y sus calificaciones asignadas.
Evaluación Preliminar del producto
Puesto que es generalmente muy difícil añadir medidas de seguridad eficaces tarde
en el ciclo de vida de un producto, el Centro está interesado en trabajar con el sistema
vendedores en las primeras etapas de diseño de producto. Un producto preliminar
evaluación permite al Centro de consultar con los proveedores de equipo en equipo
los problemas de seguridad que se encuentran en productos que aún no se han anunciado formalmente.
Una evaluación preliminar se inicia típicamente por los vendedores de sistemas informáticos que
están planeando nuevos productos informáticos que cuentan con la seguridad o importante
actualizaciones relacionadas con la seguridad de los productos existentes. Después de una reunión inicial
entre el vendedor y el Centro, los acuerdos de confidencialidad adecuados
ejecutada que requieren el Centro a mantener la confidencialidad de cualquier
propiedad de la información revelada a él. Reuniones de intercambio técnicos siguen
en el que el vendedor ofrece detalles sobre el producto propuesto (en particular,
sus diseños internos y metas) y el Centro proporciona retroalimentación de expertos para la
vendedor en posibles puntos fuertes y débiles del proveedor de seguridad informática
diseñar opciones, así como la interpretación de los criterios relevantes. Los
evaluación preliminar se termina típicamente cuando se completa el producto
y listo para el lanzamiento de campo por el vendedor. Tras la rescisión, el Centro
prepara un informe de finalización para el vendedor y para la distribución interna dentro
el centro. Estos informes contienen información de propiedad no son
a disposición del público.
Durante la evaluación preliminar, el vendedor no tiene ninguna obligación de realidad
completar o comercializar el producto potencial. El Centro es, del mismo modo, no
comprometido a llevar a cabo una evaluación formal del producto. Una evaluación preliminar
podrá ser denunciado por cualquiera de Centro o el proveedor cuando se notifique a la
otra, por escrito, que ya no es ventajoso para continuar la
evaluación.
Evaluación del producto Formal
La evaluación formal producto proporciona un insumo clave para la certificación de un
sistema informático para su uso en aplicaciones nacionales de establecimientos de Seguridad y es
la única base para un producto que se coloca en la Lista de Productos evaluadas.
Una evaluación formal del producto comienza con una solicitud por un proveedor para el Centro
para evaluar un producto para el que el producto en sí y acompañar
la documentación necesaria para cumplir los requisitos definidos en la presente publicación son
completa. Acuerdos de no divulgación se ejecutan y un producto oficial
equipo de evaluación está formado por el Centro. Una primera reunión se celebró a continuación, con
el vendedor para trabajar el horario para la evaluación formal. Desde pruebas
del producto aplicado forma una parte importante del proceso de evaluación,
Acceso por el equipo de evaluación a una versión de trabajo del sistema se negocia
con el vendedor. El apoyo adicional requerido por parte del proveedor incluye
documentación completa de diseño, código fuente, y el acceso al personal de los proveedores que
puede responder a preguntas detalladas sobre partes específicas del producto. Los
equipo de evaluación pone a prueba el producto contra cada requisito, por lo que cualquier
interpretaciones necesarias de los criterios con respecto al producto de ser
evaluado.
El equipo de evaluación redacta un informe final sobre sus hallazgos sobre el sistema.
El informe está disponible al público (que no contiene propietaria o confidencial
información) y contiene la calificación global de clase asignado al sistema y
los detalles de los resultados del equipo del evalution al comparar el producto contra
los criterios de evaluación. Información detallada sobre vulnerabilidades encontradas
por el equipo de evaluación está amueblado a los desarrolladores de sistemas y diseñadores como
cada uno se encuentra para que el vendedor tiene la oportunidad de eliminar el mayor número de ellos como
posible antes de la finalización de la evaluación formal del producto.
Análisis de vulnerabilidad y otra información confidencial o sensible son
controlada dentro del Centro a través del Programa de Información y Vulnerabilidad
se distribuyen únicamente en el Gobierno de Estados Unidos en una necesidad de conocer-estricto y
no divulgación base, y para el vendedor.?
ANEXO B
RESUMEN DE LAS DIVISIONES criterios de evaluación
Las divisiones de los sistemas reconocidos en el sistema informático de confianza
criterios de evaluación son los siguientes. Cada división representa un importante
mejora en la confianza general se puede colocar en el sistema para proteger
información confidencial clasificada y otra.
División (D): Protección Mínimo
Esta división contiene una sola clase. Se reserva para aquellos sistemas que
han sido evaluados, pero que no cumplen con los requisitos para una mayor
clase de evaluación.
División (C): Protección Discrecional
Las clases de esta división prevén (necesidad de conocer) la protección discrecional
y, a través de la inclusión de mecanismos de auditoría, para la rendición de cuentas
temas y las acciones que inician.
División (B): Protección obligatoria
La noción de un TCB que preserve la integridad de las etiquetas de sensibilidad y
los utiliza para hacer cumplir una serie de reglas de control de acceso obligatorio es un importante
requisito en esta división. Sistemas de esta división deben llevar el
sensibilidad etiquetas con las principales estructuras de datos en el sistema. El sistema
desarrollador también ofrece el modelo de la política de seguridad en la que se basa la TCB
y proporciona una especificación de la TCB. La evidencia debe ser proporcionada a
demostrar que el concepto de monitor de referencia ha sido implementado.
División (A): Protección Verified
Esta división se caracteriza por el uso de la verificación de seguridad formal
métodos para asegurar que los controles de seguridad obligatorios y discrecionales
empleado en el sistema puede proteger eficazmente clasificado u otro sensible
información almacenada o procesada por el sistema. Amplia documentación es
requerida para demostrar que la TCB cumple con los requisitos de seguridad en todo
aspectos de diseño, desarrollo e implementación.
?
ANEXO C
RESUMEN DE LAS CLASES DE CRITERIOS DE EVALUACIÓN
Las clases de sistemas reconocidos en la evaluación del sistema informático de confianza
criterios son los siguientes. Se presentan en el orden creciente de
desirablity desde un punto de vista de la seguridad informática.
Clase (D): Protección Mínimo
Esta clase está reservada para aquellos sistemas que han sido evaluados, sino que
no cumplen con los requisitos para una clase de evaluación superior.
Clase (C1): Protección Seguridad Discrecional
La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente satisface
los requisitos de seguridad discrecionales al proporcionar separación de usuarios y
datos. Incorpora alguna forma de controles creíbles, capaces de hacer cumplir
limitaciones de acceso de forma individual, es decir, con el pretexto adecuado para
permitiendo a los usuarios para poder proteger a proyecto o información privada y
mantener a los demás usuarios de la lectura de forma accidental o la destrucción de sus datos. Los
Se espera que la clase (C1) el medio ambiente a ser uno de cooperar procesamiento usuarios
los datos en el mismo nivel (s) de la sensibilidad.
Clase (C2): Controlado Access Protection
Sistemas de esta clase hacen cumplir un acceso discrecional más de grano fino
usuarios de control de sistemas (C1), por lo que individualmente responsables de su
acciones a través de los procedimientos de acceso, la auditoría de los eventos relevantes para la seguridad, y
aislamiento de recursos.
Clase (B1): Etiquetado de Protección de la Seguridad
Sistemas (B1) Clase requieren todas las características requeridas para la clase (C2). En
Además, una declaración informal de la modelo de la política de seguridad, el etiquetado de datos,
y control de acceso obligatorio sobre los sujetos y objetos con nombre debe estar presente.
La capacidad debe existir para marcar con precisión la información exportada. Alguna
defectos identificados por pruebas deben ser removidos.
Clase (B2): Protección Estructurado
En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y documentado
modelo de política de seguridad formal que requiere el discrecional y obligatorio
la aplicación de control de acceso que se encuentra en los sistemas (B1) de clase se extenderá a todos
sujetos y objetos en el sistema de ADP. Además, los canales encubiertos son
abordarse. El TCB debe estructurarse con cuidado en la protección-crítico y
elementos de protección crítico no. La interfaz de TCB está bien definido y de la
Diseño e implementación TCB permiten que pueda ser sometido a más exhaustiva
pruebas y revisión más completa. Mecanismos de autenticación se fortalecen,
la gestión de instalaciones de confianza se proporciona en forma de soporte para el sistema
funciones de administrador y operador, y gestión de la configuración estrictas
se imponen controles. El sistema es relativamente resistente a la penetración.
Clase (B3): Dominios de Seguridad
La clase (B3) TCB debe satisfacer los requisitos del monitor de referencia que
mediar en todos los accesos de los sujetos a los objetos, será inviolable, y ser pequeño
suficiente para ser sometidos a análisis y pruebas. Para este fin, la TCB es
estructurado para excluir el código no es esencial para la aplicación de la política de seguridad, con
ingeniería de sistemas significativa durante el diseño y la aplicación dirigida TCB
para minimizar su complejidad. Un administrador de seguridad es compatible,
mecanismos de auditoría se expanden para señalar acontecimientos seguridad- pertinentes, y el sistema
se requieren procedimientos de recuperación. El sistema es altamente resistente a
penetración.
Clase (A1): Diseño Verified
Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3) en
que no se añaden características arquitectónicas adicionales o requisitos de la política.
La característica distintiva de los sistemas de esta clase es el análisis derivado
desde la especificación de diseño formal y técnicas de verificación y la resultante
alto grado de seguridad de que la TCB se implementa correctamente. Esta
aseguramiento del desarrollo es en la naturaleza, a partir de un modelo formal de la
la política de seguridad y una especificación de alto nivel formales (FTLs) del diseño. En
consonancia con el análisis extenso diseño y desarrollo de la TCB requerido
de los sistemas de la clase (A1), se requiere la administración de configuración más estricta
y se establezcan procedimientos para distribuir de forma segura el sistema a los sitios.
Un administrador de la seguridad del sistema es compatible.
?
APÉNDICE D
DIRECTORIO REQUISITO
Este apéndice enumera los requisitos definidos en el "Departamento de Defensa Trusted
Computer System Evaluation Criteria "alfabéticamente en lugar de por clase. It
se proporciona para ayudar en el seguimiento de la evolución de un requisito a través de la
clases. Para cada requisito, tres tipos de criterios pueden estar presentes. Cada
será precedida por la palabra: NUEVO, CAMBIO, o ADD para indicar lo siguiente:
NUEVO: Cualquier criterio que aparece en una clase inferior son reemplazadas
por los criterios que siguen.
CAMBIO: Los criterios que siguen han aparecido en una clase inferior
pero se cambian para esta clase. Se utiliza Resaltado
para indicar los cambios específicos ya se ha dicho
criterios.
ADD: Los criterios que siguen no han sido requeridos para cualquier
clase baja, y se añaden en esta clase a la
se ha indicado anteriormente los criterios para este requisito.
Las abreviaturas se utilizan de la siguiente manera:
NR: (No hay requisito) Este requisito no se incluye en
esta clase.
NAR: (No hay requisitos adicionales) Este requisito no se
cambiar de la clase anterior.
Se remite al lector a la Parte I de este documento al colocar nuevos criterios
para un requisito en el contexto completo para esa clase.
Figura 1 se presenta un resumen pictórico de la evolución de las necesidades a través de
las clases.
Auditoría
C1: NR.
C2: NUEVO: La TCB será capaz de crear, mantener y proteger de la
modificación o acceso no autorizado o la destrucción de una pista de auditoría de
accesos a los objetos que protege. Los datos de auditoría deberán ser
protegida por el TCB de manera que a ella se limita a aquellos acceso de lectura
que están autorizados para los datos de auditoría. El TCB deberá ser capaz de grabar
los siguientes tipos de eventos: uso de identificación y
mecanismos de autenticación, introducción de objetos en un usuario de
espacio de direcciones (por ejemplo, abrir el archivo, la iniciación del programa), la supresión de
objetos y acciones realizadas por operadores de computadoras y el sistema
administradores y / o funcionarios de seguridad del sistema y otra de seguridad
eventos relevantes. Para cada evento registrado, el registro de auditoría,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y el éxito
o el fracaso del evento. Para eventos de identificación / autenticación las
origen de la solicitud (por ejemplo, la terminal ID) se incluirá en la auditoría
récord. Para los eventos que introducen un objeto en la dirección de un usuario
espacio y para los eventos de deleción objeto el registro de auditoría deberá incluir
el nombre del objeto. El administrador del sistema ADP deberá ser capaz de
auditar de forma selectiva las medidas adoptadas por uno o más usuarios en función de
identidad individual.
B1: CAMBIO: Para los eventos que introducen un objeto en la dirección de un usuario
espacio y para los eventos de deleción objeto el registro de auditoría deberá incluir
el nombre del objeto y el nivel de seguridad del objeto. La ADP
el administrador del sistema deberá ser capaz de auditar selectivamente las acciones
de cualesquiera uno o más usuarios en base a la identidad y / o objeto individual
nivel de seguridad.
ADD: El TCB también podrá auditar cualquier anulación de
marcas de salida legibles.
B2: ADD: El TCB podrá auditar los eventos identificados que pueden ser
utilizado en la explotación de canales de almacenamiento encubiertas.
B3: ADD: El TCB deberá contener un mecanismo que es capaz de controlar la
aparición o acumulación de eventos auditables de seguridad que puedan
indicar una violación inminente de la política de seguridad. Este mecanismo
será capaz de notificar inmediatamente al administrador de seguridad cuando
umbrales se exceden, y, si la ocurrencia o la acumulación de
estos eventos relevantes de seguridad continúa, el sistema tomará la
arrendar acción disruptiva para terminar el evento.
A1: NAR.
Gestión de la Configuración
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: Durante el desarrollo y mantenimiento de la TCB, una configuración
sistema de gestión será en el lugar que mantiene el control de cambios
a la memoria descriptiva de nivel superior, otros datos de diseño,
documentación de la aplicación, el código fuente, la versión de funcionamiento de la
código objeto, y accesorios de la prueba y la documentación. La configuración
sistema de gestión deberá asegurar una correspondencia constante entre todos
documentación y código asociado con la versión actual de la TCB.
Herramientas se proporcionan para la generación de una nueva versión de la TCB
desde el código fuente. También disponible serán herramientas para la comparación de una
versión con la versión anterior TCB recién generado con el fin de
asegurarse de que sólo los cambios previstos se han hecho en el código
que realmente se utiliza como la nueva versión de la TCB.
B3: NAR.
A1: CAMBIO: Durante todo el ciclo de vida, es decir, durante el diseño,
desarrollo y mantenimiento de la TCB, una gestión de la configuración
sistema deberá estar en su lugar para que todos relevante para la seguridad de hardware, firmware,
y el software que mantiene el control de cambios en el modelo formal,
las especificaciones descriptivas y formales de nivel superior, otro diseño
de datos, documentación aplicación, código fuente, la versión que se ejecuta
del código objeto, y accesorios de la prueba y la documentación. También
disponibles serán herramientas, mantenidos bajo estricta configuración
control, para comparar una versión recién generado con el anterior
Versión TCB, a fin de asegurarse de que sólo los cambios previstos tienen
ha logrado en el código que realmente se utiliza como la nueva versión
del TCB.
ADD: Una combinación de técnicas, físicas y de procedimiento
se utilizará para proteger de la modificación no autorizada o
la destrucción de la copia maestra o copias de todo el material utilizado para
generar la TCB.
Análisis Canal Covert
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para encubierta
canales de almacenamiento y hacer una determinación (ya sea por real
medición o por estimación de ingeniería) del ancho de banda máximo de
cada canal identificado. (Vea la sección de Orientación Canales Covert.)
B3: CAMBIO: El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para
canales encubiertos y tomar una determinación (ya sea por real
medición o por estimación de ingeniería) del ancho de banda máximo
de cada canal identificado.
A1: ADD: métodos formales se utilizan en el análisis.
Diseño Documentación
C1: NUEVO: La documentación debe estar disponible que proporciona una descripción de
La filosofía de los fabricantes de protección y una explicación de cómo
esta filosofía se traduce en la TCB. Si el TCB se compone
de módulos distintos, las interfaces entre estos módulos serán
descrito.
C2: NAR.
B1: ADD: Una descripción informal o formal del modelo de la política de seguridad
forzada por la TCB estarán disponibles y una explicación proporcionada a
muestran que es suficiente para hacer cumplir la política de seguridad. Los
mecanismos específicos de protección TCB se identificarán y un
explicación dada para demostrar que satisfacen el modelo.
B2: CAMBIO: Las interfaces entre los módulos de TCB se describirán. LA
descripción formal del modelo de política de seguridad aplicada por el TCB
deberán estar disponibles y demostrado que es suficiente para cumplir la
politica de seguridad.
ADD: La especificación de alto nivel descriptivo (DTLS) se muestra a
ser una descripción exacta de la interfaz de TCB. Documentación
describen cómo la TCB implementa el concepto monitor de referencia y
dar una explicación de por qué se resistente a la manipulación, no puede ser anulada,
y se ha implementado correctamente. La documentación debe describir cómo el
TCB está estructurado para facilitar las pruebas y hacer cumplir menos
privilegio. Esta documentación deberá presentar también los resultados de la
análisis de canal encubierta y las compensaciones implicadas en la restricción de la
canales. Todos los eventos auditables que se pueden utilizar en la explotación
se identificarán los canales de almacenamiento encubiertas de conocidos. Las anchuras de banda
de canales de almacenamiento encubiertas conocidas, cuyo uso no es detectable
por los mecanismos de auditoría, se facilitará. (Vea el Covert
Sección de Orientación del canal.)
B3: ADD: La aplicación TCB (es decir, en el hardware, firmware y
software) se indicará de manera informal para ser coherente con los DTLS.
Los elementos de la DTLS se indicarán, utilizando técnicas informales,
para corresponder a los elementos de la TCB.
A1: CAMBIO: La aplicación TCB (es decir, en el hardware, firmware y
software) se indicará de manera informal para ser coherente con lo formal
especificación de nivel superior (FTLs). Los elementos de los FTLs serán
se muestra, usando técnicas informales, para corresponder a los elementos de
la TCB.
ADD: hardware, el firmware y los mecanismos de software no mencionadas en
el FTLs pero estrictamente interno a la TCB (por ejemplo, registros cartográficos,
Acceso directo a la memoria de E / S) se describirán con claridad.
Especificaciones de Diseño y Verificación
C1: NR.
C2: NR.
B1: NUEVO: Un modelo formal o informal de la política de seguridad con el apoyo de
la TCB se mantiene a lo largo del ciclo de vida del sistema ADP que
se demuestra que es coherente con sus axiomas.
B2: CAMBIO: Un modelo formal de la política de seguridad con el apoyo de la TCB
se mantendrán durante todo el ciclo de vida del sistema ADP que es
demostrado en consonancia con sus axiomas.
ADD: Una memoria descriptiva de nivel superior (DTLS) del TCB será
sostuvo que completa y precisa describe la TCB en términos
de excepciones, mensajes de error y efectos. Queda demostrado ser
una descripción exacta de la interfaz de TCB.
B3: ADD: Un argumento convincente se dará de que el DTLS es consistente
con el modelo.
A1: CAMBIO: Los FTLs se demuestra que es una descripción exacta de la
Interfaz de TCB. Un argumento convincente se dará de que el DTLS es
consistente con el modelo y una combinación de formal e informal
se emplearán técnicas para demostrar que el FTLs es consistente con la
modelo.
ADD: Una especificación de alto nivel formales (FTLs) del TCB será
sostenido que describe con precisión la TCB en términos de excepciones,
mensajes de error, y efectos. Los DTLS y FTLs incluirán las
componentes de la TCB que se implementan como hardware y / o
firmware si sus propiedades son visibles en la interfaz de TCB. Esta
pruebas de verificación deberá ser coherente con la prevista en
el estado-del-arte de lo particular Center- Seguridad Informática
especificación formal avalado y sistema de verificación utilizados. Manual
u otro mapeo de las FTLs al código fuente TCB será
realizado para proporcionar evidencia de la implementación correcta.
Las etiquetas de dispositivo
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB apoyará la asignación de mínimo y máximo
niveles de seguridad a todos los dispositivos físicos conectados. Estos seguridad
niveles serán utilizados por el TCB para hacer cumplir las limitaciones impuestas por
el entorno físico en el que se ubican los dispositivos.
B3: NAR.
A1: NAR.
Control de acceso discrecional
C1: NUEVO: La TCB definirá y control de acceso entre los usuarios con nombre y
objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP. Los
mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos, el acceso
listas de control) deberán permitir a los usuarios especificar y controlar el intercambio de
esos objetos por parte de personas con nombre o grupos definidos o ambos.
C2: CAMBIO: El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,
listas de control de acceso) se permitirá a los usuarios especificar y control
compartir de esos objetos por las personas nombradas, o grupos definidos de
individuos, o por ambos, y proporcionarán los controles para limitar
propagación de los derechos de acceso.
ADD: El mecanismo de control de acceso discrecional deberá, ya sea explícita
acción del usuario o por defecto, se establece que los objetos están protegidos de
Acceso no autorizado. Estos controles de acceso deberán ser capaces de
incluyendo o excluyendo el acceso a la granularidad de un único usuario.
El permiso de acceso a un objeto por los usuarios no ya poseen acceso
el permiso sólo se asignará por usuarios autorizados.
B1: NAR.
B2: NAR.
B3: CAMBIO: El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá
permitir que los usuarios especifiquen y compartir el control de esos objetos, y deberá
proporcionar controles para limitar la propagación de los derechos de acceso. Estas
controles de acceso deberán ser capaces de especificar, para cada llamada
objetar, una lista de personas con nombre y una lista de grupos de llamada
individuos con sus respectivos modos de acceso a ese objeto.
ADD: Por otra parte, respecto de cada objeto nombrado, será posible
especificar una lista de personas con nombre y una lista de grupos de llamada
individuos para los que no tienen acceso al objeto debe ser dado.
A1: NAR.
Exportación de información Etiquetada
C1: NR.
C2: NR.
B1: NUEVO: La TCB designará cada canal de comunicación y E / S
dispositivo, ya sea a nivel individual o de múltiples niveles. Cualquier cambio en esta
designación se realiza de forma manual y será auditable por el
TCB. El TCB mantendrá y ser capaz de auditar cualquier cambio en la
nivel de seguridad o los niveles asociados con un canal de comunicación o
Dispositivo de E / S.
B2: NAR.
B3: NAR.
A1: NAR.
Exportación a dispositivos multinivel
C1: NR.
C2: NR.
B1: NUEVO: Cuando la TCB exporta un objeto a un dispositivo de E / S de múltiples niveles, la
etiqueta de sensibilidad asociada a ese objeto también se exportará
y deberá residir en el mismo medio físico como el exportado
información y se hará de la misma forma (es decir, de lectura mecánica o
formato legible). Cuando las exportaciones o importaciones TCB un objeto más
un canal de comunicación de múltiples niveles, el protocolo utilizado en ese canal
deberán prever la vinculación inequívoca entre la sensibilidad
etiquetas y la información asociada que se envía o se recibe.
B2: NAR.
B3: NAR.
A1: NAR.
Exportación a solo nivel-Devices
C1: NR.
C2: NR.
B1: dispositivos S-nivel individual de E / y canales de comunicación a nivel individual: NUEVO
no están obligados a mantener las etiquetas de sensibilidad del
información que procesan. Sin embargo, la TCB deberá incluir un mecanismo
por el cual el TCB y un usuario autorizado a comunicar de forma confiable
designar el nivel de seguridad única de información importados o
exportado a través de los canales de comunicación de un solo nivel o dispositivos de E / S.
B2: NAR.
B3: NAR.
A1: NAR.
Identificación y autenticación
C1: NUEVO: La TCB exigirá a los usuarios que se identifiquen con él antes
comenzando a realizar cualquier otra acción que la TCB se espera que
mediar. Además, la TCB utilizará un mecanismo protegido (por ejemplo,
contraseñas) para autenticar la identidad del usuario. El TCB deberá
proteger los datos de autenticación de modo que no se puede acceder por cualquier
usuario no autorizado.
C2: ADD: El TCB será capaz de hacer cumplir la responsabilidad individual por
proporcionando la capacidad para identificar de forma única cada individuo ADP
usuario del sistema. El TCB también proporcionará la capacidad de
asociando esta identidad con todas las acciones que se pueden auditar tomadas por que
individual.
B1: CAMBIO: Además, la TCB mantendrá los datos de autenticación que
incluye información para la verificación de la identidad de los usuarios individuales
(por ejemplo, contraseñas), así como información para determinar la
autorización y autorizaciones de los usuarios individuales. Estos datos serán
utilizado por el TCB para autenticar la identidad del usuario y para asegurar
que las autorizaciones del nivel de seguridad y de los sujetos externos a
la TCB que se puede crear a actuar en nombre del usuario individual
están dominados por la liquidación y autorización de ese usuario.
B2: NAR.
B3: NAR.
A1: NAR.
Integridad Label
C1: NR.
C2: NR.
B1: NUEVO: etiquetas de sensibilidad deberá representar con precisión los niveles de seguridad de
los sujetos u objetos específicos con los que están asociados. Cuando
exportado por el TCB, etiquetas de sensibilidad y precisión deberá
inequívocamente representar las etiquetas internas y estará asociada
con que se exporta la información.
B2: NAR.
B3: NAR.
A1: NAR.
Salida etiquetado legible
C1: NR.
C2: NR.
B1: NUEVO: El administrador del sistema ADP podrá especificar el
nombres de las etiquetas imprimibles asociados con etiquetas de sensibilidad exportados.
El TCB deberá marcar el inicio y el final de todo legible,
paginado, salida de copia impresa (por ejemplo, la salida de impresora de líneas) con humanidad
etiquetas de sensibilidad legibles que correctamente * representan la sensibilidad
de la salida. El TCB será, por defecto, marque la parte superior e inferior de
cada página de salida legible, paginado, en papel (por ejemplo, la línea
salida de la impresora) con las etiquetas de sensibilidad legibles que
adecuadamente * representar la sensibilidad global de la salida o que
* representar adecuadamente la sensibilidad de la información de la página.
El TCB será, por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas, gráficos) con humanidad
etiquetas de sensibilidad legibles que correctamente * representan la sensibilidad
de la salida. Cualquier anulación de estos incumplimientos marcado será
auditable por el TCB.
B2: NAR.
B3: NAR.
A1: NAR.
______________________________
* El componente de clasificación jerárquica de la sensibilidad legible
etiquetas serán iguales a la mayor clasificación jerárquica de cualquiera de los
información en la salida que las etiquetas se refieren a; la no-jerárquica
componente categoría incluirá todas las categorías no jerárquicas de la
información en la salida de las etiquetas se refieren a, pero ningún otro no jerárquica
categorías.
Etiquetas
C1: NR.
C2: NR.
B1: NUEVO: etiquetas de sensibilidad asociados a cada tema y almacenamiento
objetar bajo su control (por ejemplo, proceso, archivo, segmento, dispositivo) se
ser mantenida por el TCB. Estas etiquetas se utilizan como base
para las decisiones de control de acceso obligatorios. Para importar no
datos etiquetados, la TCB deberán solicitar y recibir de una autorización
usuario el nivel de seguridad de los datos, y todas estas acciones serán
auditable por el TCB.
B2: CAMBIO: etiquetas de sensibilidad asociados a cada recurso del sistema ADP
(por ejemplo, tema, objeto de almacenamiento, ROM) que está directamente o indirectamente
accesible por temas externos a la TCB se mantendrá por
la TCB.
B3: NAR.
A1: NAR.
Control de Acceso Obligatorio
C1: NR.
C2: NR.
B1: NUEVO: La TCB deberá aplicar una política de control de acceso obligatorio sobre todos
sujetos y objetos de almacenamiento bajo su control (por ejemplo, los procesos,
archivos, segmentos, dispositivos). Estos sujetos y objetos serán
etiquetas de sensibilidad asignados que son una combinación de jerárquica
niveles de clasificación y categorías no jerárquicas y las etiquetas
se utilizará como base para las decisiones de control de acceso obligatorios.
El TCB deberá ser capaz de soportar dos o más de tales niveles de seguridad.
(Véanse las directrices de control de acceso obligatorios.) La siguiente
requisitos permanecerán en para todos los accesos entre sujetos y objetos
controlado por el TCB: Un sujeto puede leer un objeto sólo si el
clasificación jerárquica en el nivel de seguridad del sujeto es
mayor o igual a la clasificación jerárquica en el
nivel de seguridad del objeto y las categorías no jerárquicas en la
nivel de seguridad del sujeto incluye todas las categorías no jerárquicas
en el nivel de seguridad del objeto. Un sujeto puede escribir un objeto sólo
si la clasificación jerárquica en el nivel de seguridad del sujeto es
menos de o igual a la clasificación jerárquica en el objeto de
nivel de seguridad y todas las categorías no jerárquicas en la
nivel de seguridad del sujeto se incluyen en el no-jerárquica
categorías en el nivel de seguridad del objeto. Identificación y
datos de autenticación se utilizarán por el TCB para autenticar el
la identidad del usuario y para asegurar que el nivel de seguridad y autorización
zación de los sujetos externo a la TCB que pueden crearse para actuar
en nombre del usuario individual están dominadas por el despacho y
autorización de dicho usuario.
B2: CAMBIO: El TCB deberá aplicar una política de control de acceso obligatorio sobre
todos los recursos (por ejemplo, temas, objetos de almacenamiento, y dispositivos de E / S) que
son directa o indirectamente accesible por sujetos ajenos a la TCB.
Los siguientes requisitos deberán mantener durante todos los accesos entre todos
sujetos externos a la TCB y todos los objetos de forma directa o indirecta
accesible por estos temas:
B3: NAR.
A1: NAR.
Reutilización de objetos
C1: NR.
C2: NUEVO: Todas las autorizaciones a la información contenida dentro de un
objeto de almacenamiento será revocada antes de la asignación inicial,
la asignación o reasignación a un sujeto desde la piscina del TCB de
objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado
representaciones de información, producidos por un sujeto antes de
acciones es estar a disposición de cualquier objeto que obtiene acceso a
un objeto que ha sido puesto en libertad de nuevo al sistema.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Características de seguridad Guía del usuario
C1: NUEVA: Un solo resumen, capítulo, o manual en la documentación del usuario deberá
describir los mecanismos de protección proporcionados por la TCB, directrices sobre
su uso, y cómo interactúan entre sí.
C2: NAR.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Pruebas de seguridad
C1: NUEVO: Los mecanismos de seguridad del sistema de ADP se someterán a ensayo y
encontrado para trabajar como se reivindica en la documentación del sistema. Prueba deberá
por hacer para asegurar que no hay maneras obvias para una no autorizada
usuario para omitir o no derrotar a los mecanismos de protección de la seguridad
del TCB. (Véanse las directrices de Pruebas de Seguridad.)
C2: ADD: El ensayo debe incluir también una búsqueda de defectos obvios que
permitir la violación de aislamiento de recursos, o que permitiría
acceso no autorizado a los datos de auditoría o de autenticación.
B1: NUEVO: Los mecanismos de seguridad del sistema de ADP se someterán a ensayo y
encontrado para trabajar como se reivindica en la documentación del sistema. Un equipo de
personas que entienden a fondo la aplicación específica de
la TCB deberá someter su documentación de diseño, código fuente, y
código objeto de análisis y pruebas exhaustivas. Sus objetivos deberán
ser: para descubrir todos los defectos de diseño e implementación que permitan
un sujeto externo a la TCB para leer, cambiar o eliminar los datos
normalmente negado bajo la política de seguridad obligatoria o discrecional
forzada por la TCB; así como para asegurar que ningún objeto (sin
autorización para hacerlo) es capaz de hacer que el TCB para entrar en un estado
tal que es incapaz de responder a las comunicaciones iniciadas por
otros usuarios. Todos los defectos descubiertos serán removidos o neutralizados
y la TCB analizado de nuevo para demostrar que han sido eliminados
y que los nuevos defectos no se han introducido. (Vea la Seguridad
Directrices de prueba).
B2: CAMBIO: Todos los defectos descubiertos se corregirá y el TCB reexaminado
para demostrar que han sido eliminados y que las nuevas fallas tienen
no se han introducido.
ADD: El TCB se encuentra relativamente resistente a la penetración.
El ensayo debe demostrar que la aplicación TCB es consistente
con la memoria descriptiva de nivel superior.
B3: CAMBIO: La TCB se encontró resistente a la penetración.
ADD: No hay defectos de diseño y no más de unos pocos corregible
fallas de implementación se pueden encontrar durante las pruebas y no habrá
confianza razonable de que pocos permanecen.
A1: CAMBIO: El ensayo debe demostrar que la aplicación TCB es
consistente con la especificación formal de nivel superior.
ADD: mapeo manual u otra de las FTLs al código fuente puede formar
una base para las pruebas de penetración.
Asunto etiquetas de sensibilidad
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB notificará inmediatamente a un usuario del terminal de cada cambio
en el nivel de seguridad asociado a ese usuario durante un interactivo
sesión. Un usuario del terminal será capaz de consultar la TCB lo deseas
para una pantalla de etiqueta de sensibilidad completa del sujeto.
B3: NAR.
A1: NAR.
Arquitectura del Sistema
C1: NUEVO: La TCB mantendrá un dominio para su propia ejecución que
protege de interferencias externas o manipulación (por ejemplo,
modificación de sus códigos o estructuras de datos). Recursos controlados
por la TCB puede ser un subconjunto definido de los sujetos y objetos en
el sistema de ADP.
C2: ADD: El TCB aislará los recursos para protegerse de forma que
están sujetos al control de acceso y los requisitos de auditoría.
B1: ADD: El TCB deberá mantener el aislamiento de procesos a través de la prestación
de espacios de direcciones distintas bajo su control.
B2: NUEVO: La TCB mantendrá un dominio para su propia ejecución que
protege de interferencias externas o manipulación (por ejemplo,
modificación de sus códigos o estructuras de datos). El TCB mantendrá
aislamiento de procesos a través de la provisión de espacios de direcciones distintas
bajo su control. La TCB se estructurará internamente en bienestar
definidos módulos en gran medida independientes. Se hará un uso efectivo de
hardware disponible para separar aquellos elementos que son proteccionismo
crítico de aquellas que no lo son. Los módulos de TCB se diseñarán
de tal manera que el principio de privilegios mínimos se hace cumplir. Características en
hardware, como la segmentación, se utilizará para apoyar lógicamente
objetos de almacenamiento distintas con atributos diferentes (a saber: lectura,
grabable). La interfaz de usuario a la TCB será completamente
definido y todos los elementos de la TCB identificado.
B3: ADD: El TCB estará diseñado y estructurado para utilizar una solución completa,
mecanismo de protección conceptualmente simple con definido con precisión
semántica. Este mecanismo deberá desempeñar un papel central en la aplicación de la
estructuración interna de la TCB y el sistema. El TCB deberá
incorporar un uso significativo de la estratificación, la abstracción y la ocultación de datos.
Ingeniería de sistemas significativos deberá estar encaminada a minimizar
la complejidad de la TCB y se excluyen de los módulos de TCB que son
No protección crítica.
A1: NAR.
Integridad del sistema
C1: NUEVO: características de hardware y / o software se proporcionarán que puede ser
utilizado para validar periódicamente el funcionamiento correcto de la en el sitio
hardware y firmware elementos de la TCB.
C2: NAR.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Documentación de prueba
C1: NUEVO: El desarrollador del sistema proporcionará a los evaluadores un documento
que describe el plan de pruebas, procedimientos de prueba que muestran cómo el
mecanismos de seguridad fueron analizados y los resultados de la seguridad
pruebas funcionales mecanismos.
C2: NAR.
B1: NAR.
B2: ADD: Incluirá los resultados de las pruebas de la eficacia de la
métodos utilizados para reducir los anchos de banda de canal encubiertas.
B3: NAR.
A1: ADD: Los resultados de la correlación entre el nivel superior formales
Se dará especificación y el código fuente TCB.
Distribución de confianza
C1: NR.
C2: NR.
B1: NR.
B2: NR.
B3: NR.
A1: NUEVO: Un sistema de control de ADP de confianza y las instalaciones de distribución será
proporcionado para mantener la integridad de la asignación entre el
datos maestros describen la versión actual de la TCB y el en el sitio
copia maestra del código para la versión actual. Procedimientos (por ejemplo,
existirá la seguridad del sitio de pruebas de aceptación) para asegurar que el
TCB software, firmware y actualizaciones de hardware distribuido a un
al cliente están exactamente según lo especificado por las copias maestras.
Facility Management confiables
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB apoyará operador independiente y administrador
funciones.
B3: ADD: Las funciones desempeñadas en el papel de un administrador de seguridad
se identificarán. El personal administrativo del sistema ADP deberá
sólo será capaz de realizar las funciones de administrador de seguridad después de tomar
una acción auditable distinta a asumir la función de administrador de seguridad
en el sistema de ADP. Funciones no son de seguridad que se pueden realizar en
el papel administración de la seguridad se limitará estrictamente a los
esencial para la realización de la función de seguridad efectiva.
A1: NAR.
Manual de Instalación de confianza
C1: NUEVO: Un manual dirigido al administrador del sistema ADP presentará
advierte acerca de las funciones y privilegios que deben ser controlados
cuando se ejecuta una instalación segura.
C2: ADD: Los procedimientos de examen y el mantenimiento de los archivos de auditoría
así como la estructura de registro de auditoría detallado para cada tipo de auditoría
Se dará evento.
B1: ADD: El manual deberá describir el operador y administrador
funciones relacionadas con la seguridad, que incluyen el cambio de la
características de un usuario. Asimismo, proporcionará directrices sobre la
el uso coherente y eficaz de las funciones de protección de la
sistema, cómo interactúan, cómo generar de forma segura una nueva TCB, y
procedimientos de instalación, advertencias y privilegios que necesitan ser
controlado con el fin de operar la instalación de una manera segura.
B2: ADD: Los módulos de TCB que contienen el mecanismo de validación de referencia
se identificarán. Los procedimientos para la generación segura de un nuevo
TCB de la fuente después de la modificación de los módulos en el TCB deberá
se describirá.
B3: ADD: Incluirá los procedimientos para garantizar que el sistema es
comenzado inicialmente en una manera segura. Los procedimientos deberán ser también
incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en el sistema
operación.
A1: NAR.
Camino de confianza
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB apoyará una ruta de comunicación de confianza entre
en sí y el usuario de inicio de sesión inicial y la autenticación. Comunicaciones
a través de este camino se iniciará exclusivamente por un usuario.
B3: CAMBIO: El TCB apoyará una ruta de comunicación de confianza entre
en sí y los usuarios para su uso cuando una conexión positiva-TCB a usuario es
requerido (por ejemplo, inicio de sesión, sujeta nivel de seguridad del cambio).
Comunicaciones a través de este camino de confianza se activarán en exclusiva
por un usuario o de la TCB y deberá ser aislado de manera lógica y sin lugar a dudas
distinguible de otros caminos.
A1: NAR.
Recuperación de confianza
C1: NR.
C2: NR.
B1: NR.
B2: NR.
B3: NUEVO: Procedimientos y / o mecanismos se proporcionarán para asegurar que,
después de un fallo del sistema ADP u otra discontinuidad, la recuperación sin
se obtiene la protección de compromiso.
A1: NAR.
?
(esta página está reservada para la Figura 1)
?
GLOSARIO
Acceso - Un tipo específico de interacción entre un sujeto y un objeto
que resulta en el flujo de información de una a la otra.
Aprobado / Acreditación - La autorización oficial de que es
concedida a un sistema de ADP para procesar información sensible en
su entorno operativo, basado en la amplia
evaluación de seguridad de hardware, el firmware del sistema, y
diseño de software de seguridad, configuración y puesta en práctica
y del otro sistema procesal, administrativo,
, TEMPESTAD, personal y seguridad de las comunicaciones físicas
controles.
Audit Trail - Un conjunto de registros que proporcionan colectivamente
pruebas documentales de procesamiento utilizado para ayudar en la localización
de las operaciones originales con interés registros relacionados y
informes, y / o hacia atrás a partir de registros e informes a su
transacciones de origen de componentes.
Autenticar - Para establecer la validez de una identidad declarada.
Data Processing (ADP) Sistema automático - Una asamblea de equipo
hardware, firmware y software configurado para el propósito
de clasificar, ordenar, calcular, la informática,
resumiendo, la transmisión y recepción, almacenamiento y
la recuperación de datos con un mínimo de intervención humana.
Ancho de Banda - Una característica de un canal de comunicación que es
la cantidad de información que se puede pasar a través de ella en una
dada cantidad de tiempo, generalmente expresada en bits por segundo.
Modelo Bell-LaPadula - Un modelo de transición de estado formal de equipo
la política de seguridad que describe un conjunto de control de acceso
reglas. En este modelo formal, las entidades en un ordenador
sistema se divide en series abstractas de los sujetos y
objetos. La noción de un estado seguro se define y es
probado que cada transición de estado conserva la seguridad por
moviéndose de un estado seguro para asegurar el estado; Por lo tanto, inductivamente
demostrando que el sistema es seguro. Un estado del sistema es
define como "seguro" si la única permitida modos de acceso de
los sujetos a los objetos son de acuerdo con una específica
politica de seguridad. Con el fin de determinar si es o no una
se permite el modo de acceso específico, el pase de un sujeto
se compara con la clasificación del objeto y una
se efectúa la determinación de si el sujeto está
autorizado para el modo de acceso específica. Los
esquema de aclaramiento / clasificación se expresa en términos de una
celosía. Ver también: Cedazo, simple Propiedad Seguridad, * -
Propiedad.
Certificación - La evaluación técnica de seguridad de un sistema
características, realizados como parte de y en apoyo de la
/ proceso de acreditación de aprobación, que establece la medida
a la que el diseño de un sistema informático en particular y
aplicación cumple con un conjunto de seguridad especificado
requisitos.
Canal - Una ruta de transferencia de información dentro de un sistema. Pudiera también
consulte el mecanismo por el cual se efectúa el camino.
Canal encubierto - Un canal de comunicación que permite a un proceso
transferir información de una manera que viole el sistema de
politica de seguridad. Ver también: Covert Canal de almacenamiento, Covert
Timing Channel.
Covert Canal de almacenamiento - Un canal secreto que implica la
escritura directa o indirecta de una ubicación de almacenamiento por uno
proceso y la lectura directa o indirecta de almacenamiento
ubicación por otro proceso. Canales de almacenamiento Covert
suele implicar un recurso finito (por ejemplo, los sectores en un
disco) que es compartida por dos sujetos en diferentes seguridad
los niveles.
Canal Timing Covert - Un canal secreto en el que un solo proceso
señales de información a otro mediante la modulación de su propio uso de
los recursos del sistema (por ejemplo, tiempo de CPU) de tal manera que este
manipulación afecta el tiempo de respuesta real, observada por el
segundo proceso.
Datos - Información con una representación física específica.
Integridad de datos - El estado que existe cuando los datos informatizada es
el mismo que en los documentos de origen y no ha sido
expuesta a la alteración accidental o maliciosa o
destrucción.
Descriptivo de nivel superior Specification (DTLS) - Un alto nivel
especificación que está escrito en un lenguaje natural (por ejemplo,
Inglés), una notación de diseño del programa informal, o una
combinación de los dos.
Control de Acceso Discrecional - Un medio para restringir el acceso a
objetos en función de la identidad de los sujetos y / o grupos de
que pertenecen. Los controles son discrecionales en el
sentido de que un sujeto con un permiso de acceso es cierto
capaz de pasar ese permiso (quizás indirectamente) en
a cualquier otro sujeto (a no ser restringido por acceso obligatorio
control).
Dominio - El conjunto de objetos que un sujeto tiene la capacidad de
el acceso.
Dominar - Nivel de seguridad S1 se dice a dominar el nivel de seguridad
S2 si la clasificación jerárquica de S1 es mayor que
o igual a la de S2 y las categorías no jerárquicas
S1 de incluir a todos los de S2 como un subconjunto.
Canal explotable - Cualquier canal que es utilizable o detectable
por sujetos externos a la Trusted Computing Base.
Un error Hipótesis Metodología - Un análisis del sistema y la penetración
técnica donde las especificaciones y documentación para el
sistema se analizan y luego fallas en el sistema son
la hipótesis. La lista de defectos hipotéticos es entonces
priorizado sobre la base de la probabilidad estimada de que una
error de hecho existe y, suponiendo un defecto existe, en la
facilidad de explotación de la misma y sobre el grado de control o
comprometer proporcionaría. La lista de prioridades se utiliza
para dirigir la prueba real del sistema.
Defecto - Un error de comisión, omisión o descuido en un sistema
que permite a los mecanismos de protección al ser anuladas.
Prueba Formal - Un argumento matemático completo y convincente,
la presentación de la justificación lógica completa para cada prueba
paso, por la verdad de un teorema o conjunto de teoremas. Los
proceso de verificación formal utiliza pruebas formales para mostrar la
verdad de ciertas propiedades de la especificación formal y para
lo que demuestra que los programas de ordenador satisfacer sus especificaciones.
Seguridad Formal Modelo Política - Una declaración matemáticamente precisa
de una política de seguridad. Para ser adecuadamente precisa, tal
modelo debe representar el estado inicial de un sistema, la forma
en el que el sistema progresa desde un estado a otro,
y una definición de un estado "seguro" del sistema. Ser
aceptable como una base para un TCB, el modelo debe ser apoyado
por una prueba formal de que si el estado inicial del sistema
satisface la definición de un estado "seguro" y si todo
supuestos requeridos por el modelo de espera, a continuación, todos los futuros
estados del sistema estarán seguros. Algunos modelos formales
técnicas incluyen: modelos de transición de estados, lógica temporal
modelos, modelos semántica denotacional, algebraica
modelos de especificación. Un ejemplo es el modelo descrito por
Bell y LaPadula en la referencia [2]. Ver también: Bell-
LaPadula Modelo, Modelo de Política de Seguridad.
Formal Especificación de nivel superior (FTLs) - Una especificación de nivel superior
que está escrito en un lenguaje matemático formal para permitir
teoremas que muestran la correspondencia del sistema
especificación de sus requisitos formales para ser la hipótesis
y probado formalmente.
Verificación Formal - El proceso de utilización de pruebas formales de
demostrar la consistencia (verificación del diseño) entre un
especificación formal de un sistema y de una garantía formal,
modelo de política o (verificación de la implementación) entre el
especificación formal y su aplicación del programa.
Front-End Filtro de Seguridad - Un proceso que se invoca al proceso
datos accordint a una política de seguridad especificado antes de la
la liberación de los datos fuera del entorno de procesamiento o
al recibir los datos desde una fuente externa.
Pruebas funcionales - La parte de las pruebas de seguridad en la que el
características anunciados de un sistema se prueban para la correcta
operación.
Sistema de fines generales - Un sistema informático que está diseñado para
ayuda en la solución de una amplia variedad de problemas.
Granularidad - La finura relativa o tosquedad por el cual una
mecanismo se puede ajustar. La frase "la granularidad de
un solo usuario "se entiende el mecanismo de control de acceso puede ser
ajustado para incluir o excluir a cualquier usuario individual.
Entramado - Un conjunto parcialmente ordenado para el que cada par de
elementos tiene un extremo inferior y una cota superior mínima.
Privilegio mínimo - Este principio requiere que cada sujeto en un
sistema de concederse el conjunto más restrictivo de privilegios (o
aclaramiento más bajo) necesarios para el desempeño de autorizado
tareas. La aplicación de este principio limita el daño
que puede ser el resultado de un accidente, error o uso no autorizado.
Mandatory Access Control - Un medio para restringir el acceso a
objetos en función de la sensibilidad (representado por una etiqueta)
de la información contenida en los objetos y lo formal
autorización (es decir, la remoción) de temas para el acceso
información de tal sensibilidad.
Dispositivo multinivel - Un dispositivo que se utiliza de una manera que
lo permite procesar simultáneamente datos de dos o más
niveles de seguridad sin riesgo de compromiso. Para llevar a cabo
esta, etiquetas de sensibilidad normalmente se almacenan en el mismo
medio físico y de la misma forma (es decir, legible por máquina
o está procesando legible por humanos) que los datos.
Multinivel Secure - Una clase de sistema que contiene información con
diferentes sensibilidades que permite al mismo tiempo el acceso
los usuarios con diferentes permisos de seguridad y las necesidades-a-
saber, pero impide que los usuarios obtener acceso a
información por los que carecen de autorización.
Object - Un ente pasivo que contiene o recibe información.
El acceso a un objeto potencialmente implica el acceso a la
información que contiene. Ejemplos de objetos son: registros,
bloques, páginas, segmentos, archivos, directorios, directorio
árboles, y los programas, así como los bits, bytes, palabras, campos,
procesadores, pantallas de video, teclados, relojes, impresoras,
los nodos de red, etc.
Reutilización de objetos - La reasignación a algún tema de un medio
(por ejemplo, marco de página, sector de disco, cinta magnética) que
contenida uno o más objetos. Para ser reasignado de forma segura,
tales medios deben contener datos residuales de la anteriormente
objeto contenido (s).
Salida - La información que se ha exportado por un TCB.
Contraseña - Una cadena de caracteres privada que se utiliza para
autenticar una identidad.
Pruebas de Penetración - La parte de las pruebas de seguridad en el que
el intento de penetradores de eludir las medidas de seguridad
de un sistema. El penetradores se puede suponer que utilizar todos
diseño del sistema y la documentación aplicación, que puede
incluir los listados de código fuente del sistema, manuales, y el circuito
diagramas. El trabajo penetradores bajo ninguna restricciones otros
que los que se aplicaría a los usuarios normales.
Proceso - Un programa en ejecución. Está completamente caracterizada
por un único punto de ejecución actual (representado por la
estado de la máquina) y el espacio de direcciones.
Porciones de protección-crítico de la TCB - Las partes de la
TCB cuya función normal es tratar con el control de
acceso entre sujetos y objetos.
Protección Filosofía - Una descripción informal de la general
diseño de un sistema que delimita cada uno de la protección
mecanismos empleados. Una combinación (apropiada para el
clase de evaluación) de las técnicas formales e informales se utiliza
para mostrar que los mecanismos son adecuados para hacer cumplir la
politica de seguridad.
Leer - Una operación fundamental que los resultados sólo en el flujo de
información de un objeto a un sujeto.
Leer acceso - Permiso para leer la información.
Memoria de sólo lectura (ROM) - Un área de almacenamiento en la que el contenido puede
ser leído pero no alterado durante el proceso normal de ordenador.
Referencia monitor Concepto - Un concepto de control de acceso que se refiere
a una máquina abstracta que media en todos los accesos a los objetos
por los sujetos.
Recursos - Cualquier cosa utilizados o consumidos en el desempeño de una función.
Las categorías de recursos son: tiempo, información, objetos
(contenedores de información), o procesadores (la capacidad de utilizar
información). Ejemplos específicos son: tiempo de CPU; Terminal
tiempo de conexión; cantidad de memoria directamente direccionable; disco
el espacio; número de peticiones de E / S por minuto, etc.
Kernel de Seguridad - Las hardware, elementos de firmware y software
de una Base de Trusted Computing que implementan la referencia
monitorear concepto. Debe mediar en todos los accesos, ser protegidos
de modificación y ser verificables como correcta.
Nivel de seguridad - La combinación de una clasificación jerárquica
y un conjunto de categorías no jerárquicas que representa el
sensibilidad de la información.
Política de Seguridad - El conjunto de leyes, normas y prácticas que
regular cómo una organización gestiona, protege y
distribuye información sensible.
Modelo de Seguridad Política - Una presentación informal de un oficial
modelo de política de seguridad.
Seguridad Hecho Relevante - Cualquier evento que intenta cambiar la
estado de seguridad del sistema, (por ejemplo, cambiar discrecional
controles de acceso, cambie el nivel de seguridad del sujeto,
contraseña de usuario de cambio, etc.). También, cualquier evento que intenta
violar la política de seguridad del sistema, (por ejemplo, también
muchos intentos de inicio de sesión, los intentos de violar la obligatoria
límites de control de acceso de una defice, los intentos de rebajar un
archivo, etc.).
Pruebas de seguridad - Un proceso utilizado para determinar que la seguridad
características de un sistema se implementan como diseñado y que
que son adecuadas para un entorno de aplicación propuesto.
Este proceso incluye la práctica de pruebas funcionales,
pruebas de penetración, y la verificación. Ver también: Funcional
Pruebas, pruebas de penetración, Verificación.
Información Sensible - La información que, según lo determinado por un
autoridad competente, debe ser protegida porque su
divulgación no autorizada, alteración, pérdida o destrucción
será al menos causar daños perceptibles a alguien o
algo.
Sensibilidad etiqueta - Una pieza de información que representa el
nivel de seguridad de un objeto y que describe la
sensibilidad (por ejemplo, clasificación) de los datos en el
objeto. Etiquetas de sensibilidad son utilizados por el TCB como base
para las decisiones de control de acceso obligatorios.
Sencillo Estado de Seguridad - Una regla modelo de seguridad de Bell-LaPadula
permitiendo que un sujeto acceso de lectura a un objeto sólo si el
nivel de seguridad del sujeto domina el nivel de seguridad
del objeto.
Single-Level Device - Dispositivo que se utiliza para procesar los datos de un
nivel de seguridad solo en un momento dado. Puesto que el dispositivo
no tiene por qué ser de confianza para separar los datos de diferente seguridad
niveles, etiquetas de sensibilidad no tienen que ser almacenado con el
datos que se están procesando.
* -Property (Star Property) - Una regla modelo de seguridad de Bell-LaPadula
permitiendo un acceso por materias de escritura a un objeto sólo si el
nivel de seguridad del sujeto está dominado por la seguridad
nivel del objeto. También conocido como el confinamiento
Propiedad.
Object Storage - Un objeto que soporta tanto leer y escribir
accesos.
Asunto - una entidad activa, generalmente en la forma de una persona,
proceso o dispositivo que hace que la información fluya entre
objetos o cambia el estado del sistema. Técnicamente, un
proceso / par dominio.
Asunto Nivel de seguridad - el nivel de seguridad de un sujeto es igual a
el nivel de seguridad de los objetos a los que se ha leído tanto
y escritura. Nivel de seguridad de un objeto debe ser siempre
dominado por la liquidación de los usuarios el tema es
asociado con.
TEMPESTAD - El estudio y control de señales electrónicas espurias
emitida desde el equipo ADP.
De nivel superior Specification (TLS) - Una descripción no procesal de
el comportamiento del sistema en el nivel más abstracto. Normalmente, una
especificación funcional que omite todo implementación
detalles.
Trampa puerta - Un software oculto o mecanismo de hardware que permite
los mecanismos de protección del sistema para ser eludidas. Es
activado de alguna manera no aparente (por ejemplo, especial
secuencia de teclas "al azar" en un terminal).
Caballo de Troya - Un programa de ordenador con una apariencia o realidad
función útil que contiene las funciones adicionales (ocultos)
que subrepticiamente explotar las autorizaciones legítimas
del proceso de invocación en detrimento de la seguridad. Por
ejemplo, hacer una "copia oculta" de un archivo sensible para la
creador del caballo de Troya.
Trusted Computer System - Un sistema que emplea suficiente
medidas de hardware y de integridad de software para permitir su uso
para procesar simultáneamente una gama de sensible o
información clasificada.
Trusted Computing Base (TCB) - La totalidad de la protección
mecanismos dentro de un sistema informático - incluyendo hardware,
firmware y software - la combinación de las cuales es
responsable de hacer cumplir una política de seguridad. Un TCB consiste
de uno o más componentes que juntos hacer cumplir una unificado
política de seguridad sobre un producto o sistema. La capacidad de
una base informática de confianza para hacer cumplir correctamente un
política de seguridad depende únicamente de los mecanismos dentro de la
TCB y en la entrada correcta por sistema administrativo
personal de parámetros (por ejemplo, el despacho de un usuario) relacionada
a la política de seguridad.
Camino de confianza - Un mecanismo por el cual una persona en un terminal puede
comunicarse directamente con el Trusted Computing Base. Esta
mecanismo sólo puede ser activado por la persona o el fiables
Cálculo de la base y no puede ser imitado por el software que no se confía.
Software confiables - La parte de software de Trusted Computing
Base.
Usuario - Cualquier persona que interactúa directamente con un sistema informático.
Verificación - El proceso de comparar dos niveles de sistema
Especificación para la correspondencia adecuada (por ejemplo, la seguridad
modelo de política con la especificación de nivel superior, TLS con fuente
código o código fuente con código objeto). Este proceso puede o
no puede ser automatizado.
Write - Una operación fundamental que los resultados sólo en el flujo de
información de un sujeto a un objeto.
Escribe acceso - Permiso para escribir un objeto.
?
REFERENCIAS
1. Anderson, Planificación de Tecnología de Seguridad JP Computer
Estudio, ESD-TR-73 a 51, vol. Yo, ESD / AFSC, Hanscom AFB,
Bedford, Mass., 10 1972 (NTIS AD-758 206).
2. Bell, DE y LaPadula, LJ proteger los sistemas informáticos:
Exposición unificada y Multics Interpretación, MTR-2997
Rev. 1, MITRE Corp., Bedford, Mass., 03 1976.
3. Marca, SL "Un acercamiento a la identificación y Auditoría de
Vulnerabilidades y el Control de Sistemas de Aplicación ", en
Auditoría y Evaluación de Seguridad Informática II: Sistema
Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS
Publicación Especial # 500-57, MD78733, abril 1980.
4. Marca, SL "Proceso de Datos y A-123", en Actas de
Grupo 18 la evaluación del usuario rendimiento del equipo
Reuniones, CB Wilson, ed., NBS Publicación Especial
# 500-95, octubre 1982.
5. DCID l / l6, Seguridad de Inteligencia Extranjera de datos automatizada
Sistemas de Procesamiento y Redes (U), 04 de enero l983.
6. DIAM 50-4, Seguridad de Operaciones de la computadora con compartimientos (U),
24 junio de l980.
7. Denning, DE "Un modelo del enrejado de la información segura
Flow "en Communications of the ACM, vol. 19, núm. 5
(Mayo de 1976), pp. 236-243.
8. Denning, DE Secure Flujo de Información en Informática de Sistemas,
Ph.D. disertación, Purdue Univ., West Lafayette, Indiana.,
Mayo 1975.
9. Directiva DoD 5000.29, gestión de los recursos informáticos en la Major
Sistemas de Defensa, 26 de abril l976.
10. DoD 5200.1-R, Seguridad de la Información Reglamento del Programa,
08 1982.
11. Directiva del DoD 5200.28, Requisitos de seguridad para automático
Data Processing (ADP) Systems, revisó 04 1978.
Manual 12. DoD 5200.28-M, ADP Seguridad - Técnicas y
Procedimientos para la Ejecución, desactivación, pruebas y
La evaluación de seguro de Recursos Compartidos ADP Systems, revisada
06 1979.
13. Directiva del DoD 5215.1, Seguridad informática Centro de Evaluación,
25 de octubre 1982.
14. DoD 5220.22-M, Manual de Seguridad Industrial para la protección de
Información Clasificada, Marzo de 1984.
15. DoD 5220.22-R, el Reglamento de Seguridad Industrial, febrero 1984.
16. Directiva del DoD 5400.11 del Departamento de Defensa de Privacidad
Programa, 09 de junio 1982.
17. Directiva del DoD 7920.1, Life Cycle Management de Automated
Sistemas de Información (AIS), 17 de octubre 1978
18. Orden Ejecutiva 12356, Seguridad de la Información Nacional,
06 de abril 1982.
19. Faurer, LD "Mantener los Secretos secreto" en el Gobierno
Data Systems, noviembre-diciembre 1981, pp 14-17..
20. Federal Information Processing Standards Publicación (FIPS
PUB) 39, Glosario de Informática de Sistemas de Seguridad,
15 de febrero 1976.
21. Federal Information Processing Standards Publicación (FIPS
PUB) 73, Directrices para la Seguridad del ordenador
Aplicaciones, 30 de junio de 1980.
22. Federal Information Processing Standards Publicación (FIPS
PUB) 102, Guía para la Certificación de Seguridad Informática
y Acreditación.
23. Lampson, BW "Una nota sobre el problema Confinamiento", en
Comunicaciones de la ACM, vol. 16, no. 10 (octubre
1973), pp. 613 a 615.
24. Lee, TMP, et al. "Los procesadores, sistemas operativos y
Periféricos cercanas: Un informe de consenso ", en Auditoría y
Evaluación de la Seguridad Informática II: Sistema
Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS
Publicación Especial # 500-57, MD78733, abril 1980.
25. Lipner, SB Un comentario sobre el Problema Confinamiento, MITRE
Corp., Bedford, Mass.
26. Millen, JK "Un ejemplo de una Violación de flujo formal", en
Actas de la segunda IEEE Computer Society
Software Informática Internacional y Aplicaciones
Conferencia, noviembre de 1978, págs. 204 a 208.
27. Millen, JK "Seguridad del Kernel de validación en la práctica", en
Comunicaciones de la ACM, vol. 19, no. 5 (mayo de 1976),
. pp doscientos cuarenta y tres hasta doscientos cincuenta.
28. Nibaldi, GH Propuestos Criterios de Evaluación Técnica para
Trusted Computer Systems, MITRE Corp., Bedford, Mass.,
M79-225, AD-A108-832, 25 de octubre 1979.
29. Nibaldi, GH Especificación de A Computing Base confiables,
(TCB), MITRE Corp., Bedford, Mass., M79-228, AD-A108-
831, 30 de noviembre 1979.
30. OMB Circular A-71, Transmisión Memorando Nº 1, de Seguridad
Federal Automatizado Sistemas de Información, 27 de julio 1978.
31. OMB Circular A-123, Sistemas de Control Interno, 05 de noviembre
1,981.
32. Ruthberg, Z. y McKenzie, R., eds. Auditoría y Evaluación del
Seguridad Informática, en NBS Publicación Especial # 500-19,
10 1977.
33. Schaefer, M., Linde, RR, et al. "Programa de Confinamiento en
KVM / 370 ", en Actas de la ACM Nacional
Conferencia, octubre de 1977, en Seattle.
34. Schell, RR "Seguridad Núcleos: Un diseño metódico de
Sistema de seguridad ", en Documentos Técnicos, USO Inc. Primavera
Conferencia, 5-9 marzo de 1979, pp. 245-250.
35. Trotter, ET y Tasker, PS Industria Informática de confianza
Sistemas de Proceso de Evaluación, MITRE Corp., Bedford,
Mass., MTR-3931, 01 de mayo 1980.
36. Turno, R. Trusted Computer Systems: Necesidades y Incentivos para
Utilice en el gobierno y el sector privado, (AD # A103399),
Rand Corporation (R-28811-DR & E), junio 1981.
37. Walker, ST "El Advenimiento de Trusted Computer operativo
Sistemas ", en Actas de la Conferencia Nacional de Informática,
De mayo de 1980, pp. 655-665.
38. Ware, WH, ed, Controles de Seguridad de los Sistemas Informáticos.:
Informe del Consejo Científico de Defensa Grupo de Trabajo en Equipo
Seguridad, AD # A076617 / 0, Rand Corporation, Santa
Monica, Calif., 02 1970, reeditado 10 1979.