Standares de Seguridad

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 EVALUACIN
CRITERIOS
Diciembre l985
?
26 de diciembre de l985
PRLOGO
Computer Esta publicacin, DoD 5200.28-STD, "Departamento de Defensa de

confianza
Criterios de evaluacin 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 Informtica Centro de evaluacin." Su propsito
es
proporcionar / / criterios tcnicos de hardware de firmware y software de
seguridad asociado
metodologas de evaluacin tcnica en apoyo del sistema de ADP general
la poltica de seguridad, evaluacin y aprobacin / responsabilidades de

acreditacin
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 Organizacin 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 publicacin es efectiva inmediatamente y es obligatorio para su uso por
parte de todos del Departamento de Defensa
Componentes en la realizacin de actividades de evaluacin de la seguridad
tcnica del sistema ADP
aplicable al tratamiento y almacenamiento de los clasificados y otra DoD
sensibles
informacin y aplicaciones como se establece en el presente documento.
Se anima Recomendaciones para la revisin de esta publicacin y sern
revisado cada dos aos por el Centro Nacional de Seguridad Informtica a travs
de un oficial
proceso de revisin. Direccin todas las propuestas de revisin a travs
apropiada
canales a: Centro Nacional de Seguridad Informtica, Atencin: Jefe,
Computadora
Normas de Seguridad.
Componentes del DoD puede obtener copias de esta publicacin a travs de su
propia
Publicaciones canales. Otras agencias federales y el pblico puede obtener
copias
de: Oficina de Normas y Productos, Centro Nacional de Seguridad Informtica,
Fort Meade, MD 20755-6000, Atencin: Jefe, Estndares de Seguridad
Informtica.
_________________________________
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

Informtica
Centro (NCSC), que integra la teora, la poltica y la prctica en y dirigi
la produccin de este documento.
Reconocimiento Tambin 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 tcnicas que se presentan en este documento; Jeff
Makey, anteriormente
NCSC, Warren F. Shadle, NCSC, y Carole S. Jordan, NCSC, quien colabor en la
elaboracin 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 Area 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 Ejrcito, que dio generosamente su tiempo y experiencia en la revisin y

crtica de este documento; y, finalmente, se dan gracias a la computadora
la industria y otros interesados en la computacin de confianza por su entusiasta
asesoramiento y asistencia a travs de este esfuerzo.
?
CONTENIDOS
PRLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .yo
AGRADECIMIENTOS. . . . . . . . . . . . . . . . . . . . . . . ii
PRLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .v
INTRODUCCIN. . . . . . . . . . . . . . . . . . . . . . . . . 0.1
PARTE I: LOS CRITERIOS

1.0 DIVISIN D: proteccin mnima. . . . . . . . . . . . . 0.9
2.0 DIVISIN C: PROTECCIN DISCRECIONAL. . . . . . . . . . 11
2.1 Clase (C1): Discrecional Proteccin Seguridad. . 12
2.2 Clase (C2): Controlado de proteccin de acceso. . . . . 15
3.0 DIVISIN B: PROTECCIN OBLIGATORIA. . . . . . . . . . . . 19
3.1 Clase (B1): Etiquetado de Proteccin de Seguridad. . . . . 20
3.2 Clase (B2): Proteccin estructurado. . . . . . . . 26
3.3 Clase (B3): Dominios de Seguridad. . . . . . . . . . . 33
4.0 DIVISIN A: PROTECCIN VERIFICADO. . . . . . . . . . . . 41
4.1 Clase (A1): Diseo verificada. . . . . . . . . . . 42

4.2 Ms all de la Clase (A1). . . . . . . . . . . . . . . . . 51
PARTE II: JUSTIFICACIN Y DIRECTRICES

5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMTICOS DE CONFIANZA. .
. . . 55
5.1 Una necesidad de consenso. . . . . . . . . . . . . . . 56
5.2 Definicin y utilidad. . . . . . . . . . . . . 56
5.3 Criterios de control objetivo. . . . . . . . . . . . 56
6.0 JUSTIFICACIN DETRS DE LAS CLASES DE EVALUACIN. . . . . . . . . 63
6.1 El concepto de monitor de referencia. . . . . . . . . . . 64
6.2 Un modelo de Poltica 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 RELACIN ENTRE LA POLTICA Y LOS CRITERIOS. . . . 69
7.1 establecido polticas federales. . . . . . . . . . . 70
7.2 Polticas del Departamento de Defensa. . . . . . . . . . . . . . . . . . . 70
7.3 Criterios de control objetivo para la Poltica de Seguridad. . 71
7.4 Criterios de control objetivo para la Rendicin de Cuentas. . . 74
7.5 Criterios de control objetivo para la Garanta. . . . . 76
8.0 Una directriz sobre canales encubiertos. . . . . . . . . . . . . 79
9.0 A GUA sobre la configuracin de control de acceso obligatorio

CARACTERSTICAS . . . . . . . . . . . . . . . . . . . . . . . . 81
10.0 Una GUA SOBRE LAS PRUEBAS DE SEGURIDAD. . . . . . . . . . . . 83

10.1 Pruebas de Divisin C. . . . . . . . . . . . . . 84
10.2 Pruebas de Divisin B. . . . . . . . . . . . . . 84
10.3 Las pruebas para la Divisin A. . . . . . . . . . . . . . 85
ANEXO A: Proceso de evaluacin comercial del producto. . . . . . 87

ANEXO B: Resumen de Evaluacin Divisiones Criterios. . . . 89
ANEXO C: Sumario de las clases criterios de evaluacin. . . . . . 91

APNDICE D: Directorio de los Menesteres. . . . . . . . . . . . . . 93
GLOSARIO. . . . . . . . . . . . . . . . . . . . . . . . . . 0,109
REFERENCIAS. . . . . . . . . . . . . . . . . . . . . . . . . 0,115
?
PRLOGO
Los criterios de evaluacin del sistema informtico de confianza definidos en este

documento
clasificar los sistemas en cuatro grandes divisiones jerrquicas de seguridad
mejorada
proteccin. Ellos proporcionan una base para la evaluacin de la eficacia de
controles de seguridad integrados en productos automticos 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 informticos para el procesamiento seguro de clasificado u otro
sensibles
la informacin; (b) para proporcionar orientacin 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 adquisicin.
Dos tipos de
requisitos son delineados para el procesamiento seguro: (a) la seguridad
especfica
requisitos de caractersticas y (b) los requisitos de garanta. Algunos de estos
ltimos
requisitos permiten al personal de evaluacin para determinar si las
caractersticas requeridas
estn presentes y funcionando segn lo previsto. El mbito de aplicacin 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 evaluacin ms baja o ms 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 mayora de las
componentes pueden ser completamente confiable. Aunque los criterios se
pretende que sean
independiente de la aplicacin, los requisitos especficos de caractersticas de
seguridad pueden tener que
interpretarse en la aplicacin de los criterios a los sistemas especficos 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 garanta subyacentes se pueden aplicar a travs de la
todo el espectro de entornos de sistema ADP o procesamiento de aplicacin sin
interpretacin especial.
?
INTRODUCCIN
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 garantas de seguridad informtica que
protegeran
la informacin clasificada en el acceso remoto, sistemas informticos de
intercambio de recursos.
El informe del Grupo de Trabajo, "Controles de seguridad de sistemas
informticos", publicado en
02 1970, formul una serie de recomendaciones de polticas y tcnicas de
acciones que deben adoptarse para reducir la amenaza de compromiso del
clasificado
informacin procesada en los sistemas informticos de acceso remoto. [34]
Departamento de
Defensa Directiva 5200.28 y su manual que acompaa DoD 5200.28-M, publicado
en 1972 y 1973 respectivamente, respondi a una de estas recomendaciones por
el establecimiento de la poltica del Departamento de Defensa uniforme, los
requisitos de seguridad, administrativos
controles y medidas tcnicas para proteger la informacin clasificada procesados
por los sistemas informticos del Departamento de Defensa [8, 9]. La
investigacin y el desarrollo de los trabajos realizados por el
Fuerza Area, Advanced Research Projects Agency, y otros organismos de

defensa de
los 70 principios y mediados desarrollados y solucin demostrado enfoques para
la
problemas tcnicos asociados con el control del flujo de informacin en
intercambio de informacin y los sistemas informticos 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 Investigacin e Ingeniera para enfocar los
esfuerzos del Departamento de Defensa
cuestiones abordar la seguridad informtica. [33]
Paralelamente a los esfuerzos del Departamento de Defensa para abordar las
cuestiones de seguridad informtica, el trabajo era
iniciado bajo la direccin de la Oficina Nacional de Estndares (NBS) para definir
problemas y soluciones para la construccin, evaluacin y auditora informtica
segura
sistemas. [17] Como parte de este trabajo NBS celebr dos talleres de invitacin
en la
tema de la auditora y la evaluacin de la seguridad informtica [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 evaluacin de la seguridad del equipo tcnico
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 Corporacin MITRE
trabajar en un conjunto de criterios de evaluacin de seguridad informtica que
podra ser usado para
evaluar el grado de confianza se podra colocar en un sistema informtico para
proteger
datos clasificada [24; 25; 31]. Los conceptos preliminares para la seguridad
informtica
Evaluacin se define y se ampli en los talleres de invitacin y
simposios cuyos participantes representaron experiencia en seguridad
informtica extrae de
industria y la academia, adems del gobierno. Su trabajo tiene ya
sido objeto de mucha revisin por pares y la crtica tcnica constructiva de
el Departamento de Defensa, las organizaciones de investigacin industrial y de
desarrollo, universidades, y
los fabricantes de ordenadores.
El Centro de Seguridad Informtica 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
informtica
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 informticos de confianza para
su uso por
los que procesan la informacin confidencial clasificada u otros. [10] Los criterios
presentada en este documento han evolucionado a partir de la NBS antes y
MITRE
material de evaluacin.
Alcance
Se aplican los criterios de evaluacin del sistema informtico de confianza
definidos en este documento
principalmente a confianza procesamiento automtico de datos disponible en el
mercado (ADP)
sistemas. Ellos tambin son aplicables, como amplificada a continuacin, la
evaluacin de
los sistemas existentes y la especificacin de requisitos de seguridad para ADP
adquisicin de sistemas. Se incluyen dos conjuntos distintos de requisitos: 1)
requisitos especficos de caractersticas de seguridad; y 2) los requisitos de

garanta. Los
requisitos especficos incluyen abarcan las capacidades se encuentran
tpicamente en
sistemas de procesamiento de informacin que emplean sistemas operativos de
propsito general que
son distintas de las aplicaciones de los programas que se apoyaban. Sin
embargo, especfica
requisitos de caractersticas de seguridad tambin pueden aplicarse a sistemas
especficos 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 garanta, por otro lado, se aplican a los sistemas que
cubrir toda la gama de entornos informticos de los controladores dedicados a
sistemas de seguridad multinivel gama completa de intercambio de recursos.
Propsito
Como se seala en el prefacio, los criterios han sido developedto servir a un
nmero
de fines previstos:
* Proporcionar un estndar para los fabricantes en cuanto a lo de
seguridad
caractersticas 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 prevencin
la divulgacin de datos) para aplicaciones sensibles.
* Proporcionar componentes del Departamento de Defensa con una
mtrica con la que evaluar
el grado de confianza que se puede colocar en los sistemas informticos

de
el procesamiento seguro de clasificada y otra sensible
informacin.
* Proporcionar una base para especificar los requisitos de seguridad en
especificaciones de adquisicin.
Con respecto a la segunda propsito para el desarrollo de los criterios, es decir,
proporcionando componentes del Departamento de Defensa con una mtrica de
evaluacin de seguridad, evaluaciones, puede ser
delineado en dos tipos: (a) una evaluacin puede llevarse a cabo en un equipo
producto desde una perspectiva que excluye el entorno de aplicacin; 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
especfico. Los
primer tipo de evaluacin es realizada por el Centro de seguridad de la
computadora a travs de la
Comercial Proceso de evaluacin del producto. Ese proceso se describe en el
Apndice
A.
Este ltimo tipo de evaluacin, es decir, los que hace con el propsito de evaluar
la
atributos de seguridad del sistema con respecto a una misin operativo
especfico,
que se conoce como una evaluacin de la certificacin. Se debe entender que la
realizacin de una evaluacin formal producto no constituye certificacin o
acreditacin del sistema a ser utilizado en cualquier aplicacin especfica
ambiente. Por el contrario, el informe de evaluacin slo proporciona una
confianza
Valoracin de la evaluacin del sistema informtico junto con los datos que
apoyan la descripcin de la
fortalezas del sistema de productos y debilidades desde el punto de la seguridad

informtica
punto de vista. La certificacin de la seguridad del sistema y lo formal de
aprobacin / acreditacin
procedimiento, realizado de acuerdo con las polticas aplicables de la emisin
agencias, an debe ser un sistema puede ser aprobado para su uso antes
seguidos
procesamiento o manejo de informacin clasificada [8, 9]. Designado Aprobar
Autoridades (Daas) siguen siendo en ltima instancia responsable de especificar
la seguridad de
sistemas que acreditan.
Los criterios de evaluacin sistema informtico de confianza se pueden utilizar
directamente y
indirectamente en el proceso de certificacin. Junto con la poltica aplicable,
se utilizarn directamente como orientacin tcnica para la evaluacin del
sistema total
y para especificar los requisitos de seguridad del sistema y de certificacin para
la nueva
adquisiciones. Dnde est evaluando un sistema para la certificacin emplea un
producto que ha sido objeto de una evaluacin del producto comercial, informa
de que
proceso se utiliza como entrada para la evaluacin de la certificacin. Datos
tcnicos
ser proporcionada a los diseadores, evaluadores y la Aprobando Designado
Autoridades para apoyar sus necesidades de toma de decisiones.
Fundamentales Requisitos de Seguridad Informtica

Cualquier discusin sobre la seguridad informtica comienza necesariamente de
una declaracin de
requisitos, es decir, lo que realmente significa para llamar a un sistema
informtico "seguro".
En general, los sistemas seguros controlarn, a travs del uso de la seguridad

especfica
caractersticas, el acceso a la informacin de tal manera que slo se autoriza
correctamente
individuos o procesos que operan en su nombre, tendr acceso a la lectura,
escribir, crear o eliminar informacin. Seis requisitos fundamentales son
derivada de esta declaracin bsica de objetivo: cuatro se refieren a lo que hay
proporcionarse para controlar el acceso a la informacin; y dos tratan de cmo se
puede
obtener garantas crebles de que esto se logra en un equipo de confianza
sistema.
Poltica
Requisito 1 - POLTICA DE SEGURIDAD - No debe ser una explcita y
as definidos por la poltica 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
especfica
objeto. Los sistemas informticos de inters deben hacer cumplir una poltica de
seguridad obligatoria
que puede implementar de manera efectiva las reglas de acceso para el manejo
sensible (por ejemplo,
. informacin clasificada) [7] Estas normas incluyen requisitos tales como: No
persona que carece de espacio libre apropiado de seguridad personal deber
tener acceso a
clasificado
informacin. Adems, se requiere que los controles de seguridad discrecionales
para
garantizar que los usuarios o grupos de usuarios seleccionados slo 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 informacin almacenada en un
ordenador,
de acuerdo a las reglas de una poltica 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 clasificacin), y / o los modos de acceso
concedidos
aquellos sujetos que potencialmente pueden acceder al objeto.
Rendicin de cuentas
Requisito 3 - IDENTIFICACIN - sujetos individuales deben ser
identificados. Cada acceso a la informacin debe estar mediada basa en quin es
el acceso a la informacin y qu clases de informacin que estn autorizados
lidiar con. Esta informacin de identificacin y autorizacin debe ser
firmemente mantenida por el sistema de ordenador y estar asociada con cada
activo
elemento que realiza alguna accin relevante para la seguridad en el sistema.
Requisito 4 - RESPONSABILIDAD - La informacin de auditora 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 auditora.
La capacidad de
seleccionar los eventos de auditora para ser registrados es necesario minimizar
el gasto de
auditora y para permitir el anlisis eficiente. Los datos de auditora deben ser
protegidos de
modificacin y destruccin no autorizada para permitir la deteccin y
investigaciones despus de los hechos de violacines de seguridad.
Aseguramiento
Requisito 5 - GARANTA - El sistema informtico debe contener
mecanismos de hardware / software que pueden ser evaluados de forma
independiente para proporcionar
garantas suficientes de que el sistema impone requisitos 1 a 4 anteriores.
Con el fin de asegurar que los cuatro requisitos de la Poltica de Seguridad,
Marcado,
Identificacin, y rendicin de cuentas son impuestas por un sistema informtico,
no
Debe haber alguna identificados y coleccin unificada de hardware y software
controles que realizan esas funciones. Estos mecanismos son tpicamente
incorporados
en el sistema operativo y estn diseados 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 - Proteccin continua - Los mecanismos de confianza que
hacer cumplir estos requisitos bsicos se deben proteger de forma continua
contra
manipulacin y / o cambios no autorizados. Ningn sistema informtico puede ser
considerado
realmente segura si los mecanismos bsicos de hardware y software que hacen
cumplir la
poltica de seguridad son a su vez objeto de modificaciones no autorizadas o
subversin. El requisito de proteccin continua tiene implicaciones directas
a lo largo del ciclo de vida del sistema informtico.
Estos requisitos fundamentales forman la base para la evaluacin individual
criterios aplicables para cada divisin de la evaluacin y de clase. El interesado

Remitimos al lector a la Seccin 5 de este documento, "Objetivos de Control para
Trusted Computer Systems, "para una discusin ms completa y ms
amplificacin de estos requisitos fundamentales que se aplican a
sistemas de procesamiento de informacin y la Seccin 7 para uso general
la amplificacin de la relacin entre poltica y estos requisitos.
Estructura del documento

El resto de este documento se divide en dos partes, cuatro apndices 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 polticas extractos contenidos en la Parte II.
Parte II (artculos 5 a 10) ofrece una discusin de los objetivos bsicos,
razn de ser, y la poltica nacional detrs del desarrollo de los criterios y
directrices para desarrolladores relacionados con: las reglas de control de acceso
obligatorio
aplicacin, el problema canal secreto, y las pruebas de seguridad. Es
dividido en seis secciones. Seccin 5 discute el uso de objetivos de control
en general, y presenta los tres objetivos bsicos de control de los criterios.
Seccin 6 proporciona la base terica detrs de los criterios. Seccin 7 da
extractos de pertinente reglamentos, directivas, circulares de la OMB, y Ejecutivo
rdenes que proporcionan la base para muchos requisitos fiduciarios para
procesamiento
informacin a nivel nacional sensible y clasificada con los sistemas informticos.
Seccin 8 proporciona orientacin a los desarrolladores de sistemas en las
expectativas en el trato
el problema canal encubierto. Seccin 9 proporciona directrices tratar con
seguridad obligatoria. Seccin 10 proporciona directrices para las pruebas de

seguridad.
Hay cuatro apndices, incluyendo una descripcin de la Informtica de confianza
Sistema de Productos Comerciales de Evaluacin de proceso (Apndice A),
resmenes de la
divisiones de evaluacin (Apndice B) y clases (Apndice C), y, finalmente, una
directorio de los requisitos ordenados alfabticamente. Adems, hay una
glosario.
Estructura de los Criterios

Los criterios se dividen en cuatro divisiones: D, C, B y A ordenaron en un
de manera jerrquica con la divisin ms alta (A) est reservado para los
sistemas
proporcionando la seguridad ms completa. Cada divisin representa un
importante
mejora en la confianza general se puede colocar en el sistema para la
proteccin de la informacin sensible. Dentro de las divisiones C y B hay un
nmero de subdivisiones conocidas como clases. Las clases tambin se ordenan
en un
de manera jerrquica con sistemas representante de la divisin C e inferior
clases de divisin B se caracterizan por el conjunto de la seguridad informtica
mecanismos que poseen. Aseguramiento del correcto diseo y completa y
la implementacin de estos sistemas se consigue principalmente a travs 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
Computacin Confiable
Base (TCB). Sistemas representante de las clases ms altas en la divisin B y
Una divisin de derivar los atributos de su seguridad ms de su diseo y
estructura de ejecucin. El aumento de la seguridad de que las caractersticas

requeridas son
operativa, correcta y manipulaciones en todas las circunstancias se gana a travs
de
anlisis cada vez ms riguroso durante el proceso de diseo.
Dentro de cada clase, se abordan cuatro grandes conjuntos de criterios. El
primero de tres
representar caractersticas necesarias para satisfacer los objetivos generales de
control de
Poltica de Seguridad, Responsabilidad y Seguridad de que se discuten en la Parte
II,
Seccin 5. El cuarto set, Documentacin, describe el tipo de escrito
pruebas en forma de guas de usuario, manuales, y la prueba y diseo
la documentacin requerida para cada clase.
Un lector utilizando esta publicacin 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 (MAYSCULAS) se utiliza en la primera parte para indicar criterios no

contena
en una clase inferior o cambios y adiciones a la ya definida criterios. Dnde
no hay resaltado, los requisitos han sido prorrogados del menor
clases sin adicin o modificacin.
?
1.0 DIVISIN D: proteccin mnima
Esta divisin 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 evaluacin.
?
2.0 DIVISIN C: PROTECCIN DISCRECIONAL
Las clases de esta divisin prevn (necesidad de conocer) la proteccin

discrecional
y, a travs de la inclusin de mecanismos de auditora, para la rendicin de
cuentas
temas y las acciones que inician.
?
2.1 CLASE (C1): PROTECCIN DE SEGURIDAD DISCRECIONAL
La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente
satisface
los requisitos de seguridad discrecionales al proporcionar separacin de usuarios
y
datos. Incorpora alguna forma de controles crebles, 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 informacin privada
y
mantener a los dems usuarios de la lectura de forma accidental o la destruccin
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 mnimos
requisitos para los sistemas asignados a (C1) habilitacin de clase:
2.1.1 Poltica 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 aplicacin (por ejemplo, auto / grupo / controles
pblicos, el acceso
listas de control) debern permitir a los usuarios especificar y compartir
el control
de esos objetos por personas nombradas o grupos definidos o ambos.
2.1.2 Rendicin de Cuentas
2.1.2.1 Identificacin y autenticacin
El TCB exigir a los usuarios que se identifiquen con l antes
comenzando a realizar cualquier otra accin que se espera que la TCB
para mediar. Adems, la TCB utilizar un protegida
mecanismo (por ejemplo, contraseas) para autenticar la identidad del
usuario.
El TCB deber proteger los datos de autenticacin 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 ejecucin
protege de interferencias externas o manipulacin
(por ejemplo, por modificacin de sus cdigo 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
Caractersticas de hardware y / o software sern siempre que
se puede utilizar para validar peridicamente el funcionamiento
correcto
de los elementos de hardware y firmware en el sitio de la TCB.
2.1.3.2 Ciclo de Vida de Garanta
2.1.3.2.1 Pruebas de seguridad
Los mecanismos de seguridad del sistema de ADP se ensayarn
y encontrado para trabajar como se reivindica en la documentacin
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 proteccin de la seguridad de la TCB.
(Vea las lneas directrices de ensayo de seguridad.)
2.1.4 Documentacin
2.1.4.1 Funciones de seguridad Gua del usuario
Un nico resumen, captulo, o manual en la documentacin del usuario
deber describir los mecanismos de proteccin proporcionados por la

TCB,
directrices sobre su uso, y cmo interactan unos con otros.
2.1.4.2 Manual de Instalacin de confianza
Un manual dirigido al administrador del sistema ADP deber
presentes advertencias acerca de las funciones y privilegios que
deberan ser
controlada al ejecutar una instalacin segura.
Documentacin 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 cmo el
los mecanismos de seguridad se pusieron a prueba, y los resultados del
pruebas funcionales mecanismos de seguridad.
2.1.4.4 Diseo de documentacin
La documentacin debe estar disponible que proporciona una
descripcin de
La filosofa de los fabricantes de proteccin y una explicacin
de cmo esta filosofa se traduce en la TCB. Si el TCB
se compone de mdulos distintos, las interfaces entre ellas
mdulos se describen.
?
2.2 CLASE (C2): PROTECCIN DE ACCESO CONTROLADO
Sistemas de esta clase hacen cumplir un acceso discrecional ms de grano fino

usuarios de control de sistemas (C1), por lo que individualmente responsables de
su
acciones a travs de los procedimientos de acceso, la auditora de los eventos
relevantes para la seguridad, y
aislamiento de recursos. Los siguientes son los requisitos mnimos para los
sistemas
asignado a (C2) habilitacin de clase:
y
de ADP. Los
mecanismo de aplicacin (por ejemplo, auto / grupo / controles
pblicos, el acceso
listas de control) debern permitir a los usuarios especificar y compartir
el control
de esos objetos por personas nombradas, o grupos de definido
individuos, o por ambos, y proporcionarn los controles para limitar
propagacin de los derechos de acceso. El control de acceso
discrecional
mecanismo deber, ya sea por accin explcita del usuario o por
defecto,
establecen que los objetos estn protegidos contra el acceso no
autorizado.
Estos controles de acceso debern 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
slo podrn ser asignadas por los usuarios autorizados.
2.2.1.2 Objeto Reutilizacin

Todas las autorizaciones de la informacin contenida dentro de un
objeto de almacenamiento ser revocada antes de la asignacin inicial,
la asignacin o reasignacin a un sujeto desde la piscina del TCB
de objetos de almacenamiento no utilizados. No hay informacin,
incluyendo cifrado
representaciones de informacin, producidos por un sujeto antes de
acciones es estar a disposicin de cualquier objeto que obtiene acceso
a un objeto que se ha lanzado de nuevo al sistema.
para mediar. Adems, la TCB utilizar un protegida
mecanismo (por ejemplo, contraseas) para autenticar la identidad del
usuario.
El TCB deber proteger los datos de autenticacin 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 tambin la capacidad de asociar esta identidad
con todas las acciones que se pueden auditar tomadas por ese
individuo.
2.2.2.2 Auditora
El TCB ser capaz de crear, mantener y proteger de la

modificacin o acceso no autorizado o la destruccin de una auditora
rastro de accesos a los objetos que protege. Los datos de auditora
estarn protegidos por la TCB para que el acceso de lectura a la misma
es
limitado a aquellos que estn autorizados para los datos de auditora. El
TCB
ser capaz de registrar los siguientes tipos de eventos: el uso de
mecanismos de identificacin y autenticacin, introduccin o
objetos en el espacio de direcciones de un usuario (por ejemplo, el
archivo abierto, el programa
iniciacin), la supresin 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 auditora deber identificar: fecha
y
hora del evento, el usuario, el tipo de evento, y el xito o el fracaso
del evento. Para eventos de identificacin / autenticacin las
origen de la solicitud (por ejemplo, el terminal ID) se incluir en el
registro de auditora. Para los eventos que introducen un objeto en un
usuario de
espacio de direcciones y para los eventos de delecin objeto el registro
de auditora
deber incluir el nombre del objeto. El sistema de ADP
administrador podr auditar selectivamente las acciones de
cualquier uno o ms usuarios basados en la identidad individual.
2.2.3 Aseguramiento

que lo protege de las interferencias externas o manipulacin
(por ejemplo, por modificacin de sus estructuras de cdigo o
datos).
de los sujetos y objetos en el sistema de ADP. El TCB
deber aislar los recursos a ser protegidas de manera que
estn sujetos al control de acceso y auditora
requisitos.
correcto
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 proteccin de la seguridad de la TCB.
El ensayo debe incluir tambin una bsqueda de defectos obvios
que
permitira violacin del aislamiento de los recursos, o que lo hara

permitir el acceso no autorizado a la auditora o la autenticacin
datos. (Vanse las directrices de Pruebas de Seguridad.)
2.2.4 Documentacin
TCB,
deberan ser
controlada al ejecutar una instalacin segura. Los procedimientos para
examinar y mantener los archivos de auditora, as como la
estructura de registro de auditora detallado para cada tipo de evento
de auditora
se le dar.

documento
muestran cmo el
mecanismos de seguridad se pusieron a prueba, y los resultados de la
seguridad
pruebas funcionales mecanismos.

descripcin de
mdulos se describen.
?
3.0 DIVISIN B: PROTECCIN OBLIGATORIA
La nocin 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 divisin. Sistemas de esta divisin deben llevar el
sensibilidad etiquetas con las principales estructuras de datos en el sistema. El
sistema
desarrollador tambin ofrece el modelo de la poltica de seguridad en la que se
basa la TCB
y proporciona una especificacin de la TCB. La evidencia debe ser proporcionada
a
demostrar que el concepto de monitor de referencia ha sido implementado.
?
3.1 CLASE (B1): PROTECCIN DE SEGURIDAD CON ETIQUETAS
Sistemas (B1) Clase requieren todas las caractersticas requeridas para la clase
(C2). En
Adems, una declaracin informal de la modelo de la poltica 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 precisin la informacin exportada.
Alguna
defectos identificados por pruebas deben ser removidos. Los siguientes son
mnimos
requisitos para los sistemas asignados a (B1) habilitacin de clase:
y
de ADP.
El mecanismo de aplicacin (por ejemplo, auto / grupo / controles
pblicos,
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
propagacin de los derechos de acceso. El control de acceso
discrecional
mecanismo deber, ya sea por accin explcita del usuario o por
defecto,
establecen que los objetos estn protegidos contra el acceso no
autorizado.
Estos controles de acceso debern 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
slo podrn ser asignadas por los usuarios autorizados.

incluyendo cifrado
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 debern ser auditables por el TCB.
3.1.1.3.1 Label Integridad
Etiquetas de sensibilidad debern representar con precisin la
seguridad
niveles de los sujetos u objetos especficos con los que se
estn asociados. Cuando exportado por el TCB, la sensibilidad
la etiqueta incluir la precisin y sin ambigedades representar el
etiquetas internas y estar asociada a la

informacin que se exporta.
3.1.1.3.2 Exportacin de Informacin Etiquetada
El TCB designar cada canal de comunicacin y
Yo dispositivo de E / S, ya sea a nivel individual o miltilevel. Alguna
cambio en esta designacin 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 comunicacin o
Dispositivo de E / S.
3.1.1.3.2.1 La exportacin a dispositivos multinivel
Cuando la TCB exporta un objeto a un multinivel I / O
dispositivo, la etiqueta sensibilidad asociada con ese
objeto tambin se exportar y deber residir en
el mismo medio fsico como el exportado
informacin y se har de la misma forma
(es decir, legible por mquina o en forma legible).
Cuando la TCB exporta o importa un objeto durante un
canal de comunicacin de mltiples niveles, el protocolo
utilizado en ese canal deber prever la
vinculacin inequvoca entre las etiquetas de sensibilidad
y la informacin asociada que se enva o
recibido.
3.1.1.3.2.2 Exportacin a solo nivel-Devices
Dispositivos S-nivel individual de E / y de un solo nivel
los canales de comunicacin no estn obligados a

mantener las etiquetas de sensibilidad de la informacin
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 informacin importado o exportado
a travs de los canales de comunicacin 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 lneas)
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
pgina de la salida legible, paginado, en papel
(por ejemplo, impresora de lnea de salida) con legible
etiquetas de sensibilidad que correctamente * representan la
sensibilidad global de la salida o que correctamente *
representar la sensibilidad de la informacin sobre la
pgina. El TCB deber, por defecto y en un
de manera adecuada, marcar otras formas de humanidad
salida legible (por ejemplo, mapas, grficos) con humanidad

representar la sensibilidad de la touput. Alguna
anulacin de estos incumplimientos marcado ser
auditable por el TCB.
3.1.1.4 Control de Acceso Obligatorio
El TCB deber aplicar una poltica 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
combinacin de niveles jerrquicos de clasificacin y
categoras no jerrquica, 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 ms de tales niveles de seguridad.
(Vea las pautas para el control de acceso obligatorio). El siguiente
requisitos permanecern en para todos los accesos entre sujetos y
objetos controlados por el TCB: un tema pueden leer un objeto
slo si la clasificacin jerrquica en el tema de
nivel de seguridad es mayor o igual a la jerrquica
clasificacin en el nivel de seguridad del objeto y de la nocategoras jerrquicas en el nivel de seguridad del sujeto incluyen
todas las categoras no jerrquicas en la seguridad del objeto
nivel. Un sujeto puede escribir un objeto slo si el jerrquica
clasificacin en el nivel de seguridad del sujeto es inferior o
igual a la clasificacin jerrquica en el objeto de
nivel de seguridad y todas las categoras no jerrquicas en la
nivel de seguridad del sujeto se incluyen en el no-jerrquica
categoras en el nivel de seguridad del objeto. Identificacin
y los datos de autenticacin se utilizarn por el TCB para autenticarse

Cate la identidad del usuario y para asegurar que el nivel de seguridad
y la autorizacin de los sujetos externo a la TCB que puede ser
creado para actuar en nombre de cada usuario estn dominadas
por la liquidacin y la ordenacin de ese usuario.
para mediar. Adems, la TCB deber mantener la autenticacin
datos que incluye informacin para la verificacin de la identidad de
los usuarios individuales (por ejemplo, contraseas), as como
informacin para
la determinacin de la compensacin y las autorizaciones o individuo
_____________________________
* El componente de clasificacin jerrquica de la sensibilidad legible
etiquetas sern iguales a la mayor clasificacin jerrquica o cualquiera de los
informacin en la salida que las etiquetas se refieren a; la no-jerrquica
componente categora incluir todas las categoras no jerrquicas de la
informacin en la salida de las etiquetas se refieren a, pero ningn otro no
jerrquica
categoras.
usuarios. Estos datos podrn 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
por la liquidacin y la ordenacin de ese usuario. El TCB deber
proteger los datos de autenticacin de modo que no se puede acceder

por cualquier
usuario no autorizado. El TCB ser capaz de hacer cumplir individuo
la rendicin 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 Auditora
es
TCB
mecanismos de identificacin y autenticacin, la introduccin de
iniciacin), la supresin 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
tambin
ser capaz de auditar cualquier anulacin de las marcas de salida
legibles.
Para cada evento registrado, el registro de auditora deber identificar:
Fecha
y la hora del evento, el usuario, el tipo de evento, y el xito o
fracaso del evento. Para eventos de identificacin / autenticacin
el origen de la solicitud (por ejemplo, la terminal ID) se incluye en

el registro de auditora. Para los eventos que introducen un objeto en un
espacio de direcciones del usuario y para eventos de eliminacin de
objetos de la auditora
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 ms
usuarios en funcin de
identidad individual y / o el nivel de seguridad de objetos.
3.1.3 Aseguramiento
datos).
de los sujetos y objetos en el sistema de ADP. El TCB
deber mantener el aislamiento de procesos a travs de la provisin
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 auditora.

correcto
del sistema.
Un equipo de personas que entienden a fondo la
aplicacin especfica de la TCB someter su
documentacin de diseo, cdigo fuente y el cdigo objeto para
anlisis y pruebas exhaustivas. Sus objetivos sern:
para descubrir todos los defectos de diseo y de ejecucin que
permitir que un objeto externo a la TCB para leer, cambiar o
delete normalmente datos negados bajo el obligatorio o
poltica de seguridad discrecional impuesta por la TCB; as como
que se asegure de que ningn objeto (sin autorizacin 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 sern 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 lneas directrices de ensayo de seguridad.)
3.1.3.2.2 Especificaciones de Diseo y Verificacin
Un modelo formal o informal de la poltica 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 Documentacin
TCB,
deberan ser
de auditora
se le dar. El manual deber describir el operador y
funciones de administrador relacionados con la seguridad, que incluyen
el cambio
las caractersticas de seguridad de un usuario. Facilitar
directrices sobre el uso coherente y eficaz de la proteccin
caractersticas del sistema, cmo interactan, 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
instalacin de una manera segura.

documento
muestran cmo el
seguridad
descripcin de
mdulos se describen. Una descripcin informal o formal
del modelo de poltica de seguridad aplicada por el TCB ser
disponibles y una explicacin proporcionada a demostrar que es
suficiente para hacer cumplir la poltica de seguridad. El TCB especfica
mecanismos de proteccin deben ser identificados y una explicacin
dado para demostrar que satisfacen el modelo.
?
3.2 CLASE (B2): PROTECCIN ESTRUCTURADO
En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y
documentado
modelo de poltica de seguridad formal que requiere el discrecional y obligatorio
la aplicacin 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. Adems, los canales encubiertos son
abordarse. El TCB debe estructurarse con cuidado en la proteccin-crtico y
elementos de proteccin crtico no. La interfaz de TCB est bien definido y de la

Diseo e implementacin TCB permiten que pueda ser sometido a ms
exhaustiva
pruebas y revisin ms completa. Mecanismos de autenticacin se fortalecen,
la gestin de instalaciones de confianza se proporciona en forma de soporte para
el sistema
funciones de administrador y operador, y gestin de la configuracin estrictas
se imponen controles. El sistema es relativamente resistente a la penetracin.
Los
siguientes son los requisitos mnimos para los sistemas asignados a (B2)
habilitacin de clase:
y
de ADP.
El mecanismo de aplicacin (por ejemplo, auto / grupo / controles
pblicos,
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 proporcionarn los controles
para limitar la propagacin de los derechos de acceso. El acceso
discrecional
mecanismo de control deber, ya sea por accin explcita del usuario o
por
De forma predeterminada, se establece que los objetos estn
protegidos de la no autorizada
el acceso. Estos controles de acceso debern 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 slo podr ser cedido por los usuarios autorizados.
la asignacin o reasignacin a un sujeto desde la piscina del TCB de
objetos de almacenamiento no utilizados. No hay informacin,
incluyendo cifrado
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 debern solicitar y recibir de un
usuario autorizado el nivel de seguridad de los datos, y toda esa
seguridad
niveles de los temas especficos u objetos con los que
estn asociados. Cuando exportado por el TCB,
etiquetas de sensibilidad deber precisin y sin ambigedades

representar las etiquetas internas y estar asociada
con que se exporta la informacin.
Yo dispositivo de E / S, ya sea a nivel individual o de mltiples
niveles. Alguna
informacin y se har de la misma forma (es decir,
legible por mquina o en forma legible). Cuando
la TCB exporta o importa un objeto durante un
recibido.

mantener las etiquetas de sensibilidad de la
informacin 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 informacin importada
o exportados a travs de la comunicacin de un solo nivel
los canales o dispositivos de E / S.
especificar los nombres de las etiquetas imprimibles asociados a
con
ser, por defecto, marque la parte superior e inferior de cada
sensibilidad global de la salida o que
* representar adecuadamente la sensibilidad de la
informacin en la pgina. El TCB, a ms tardar
por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas,
grficos) con etiquetas de sensibilidad legibles

que adecuadamente * representan la sensibilidad de la
de salida. Cualquier anulacin 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 sesin interactiva. Un usuario del terminal ser
capaz de consultar la TCB como se desee para una visualizacin de
la
etiqueta de sensibilidad completa del tema.
3.2.1.3.4 Las etiquetas de dispositivo
El TCB apoyar la asignacin de mnima y
niveles de mxima seguridad a todos los dispositivos fsicos
conectados.
Estos niveles de seguridad debern ser utilizados por el TCB para
hacer cumplir
las restricciones impuestas por el entorno fsico en el que
los dispositivos se encuentran.
todos los recursos (por ejemplo, temas, objetos de almacenamiento, y
dispositivos de E / S
que estn directa o indirectamente accesible por temas externos
a la TCB. Estos sujetos y objetos se asignarn
etiquetas de sensibilidad que son una combinacin de jerrquica
niveles de clasificacin y categoras no jerrquicas, y la

etiquetas se utilizan como base para el control de acceso obligatorio
decisiones. El TCB deber ser capaz de soportar dos o ms de tales
los niveles de seguridad. (Vanse las directrices de control de acceso
obligatorios.)
Los siguientes requisitos debern 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 slo si la clasificacin jerrquica en el tema de
nivel de seguridad es mayor o igual a la jerrquica
clasificacin en el nivel de seguridad del objeto y de la nocategoras jerrquicas en el nivel de seguridad del sujeto incluyen
todas las categoras no jerrquicas en la seguridad del objeto
nivel. Un sujeto puede escribir un objeto slo si el jerrquica
clasificacin en el nivel de seguridad del sujeto es inferior o
igual a la clasificacin jerrquica en el objeto de
categoras en el nivel de seguridad del objeto. Identificacin y
datos de autenticacin se utilizarn por el TCB para autenticar
autorizacin de los sujetos externo a la TCB que puede ser
por la liquidacin y la ordenacin de ese usuario.

informacin para
la determinacin de la compensacin y las autorizaciones de individuo
creado para actuar en nombre del usuario individual estn dominadas
por
la liquidacin y autorizacin de ese usuario. El TCB deber
por cualquier
forma nica
3.2.2.1.1 Camino de confianza
El TCB apoyar una ruta de comunicacin de confianza
entre l mismo y el usuario de inicio de sesin inicial y
autenticacin. Comunicaciones a travs de este camino sern
iniciado exclusivamente por un usuario.
3.2.2.2 Auditora

es
TCB
ordenador
Tambin podr auditar cualquier anulacin de la salida legible
marcas. Para cada evento registrado, el registro de auditora,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y
xito o el fracaso del evento. Para la identificacin /
eventos de autenticacin del origen de la solicitud (por ejemplo, la
terminal de Identificacin)
se incluirn en el registro de auditora. Para los eventos que
introducir un objeto en el espacio de direcciones de un usuario y para el
objeto
eventos de eliminacin del registro de auditora debern incluir el
nombre de la
objeto y nivel de seguridad del objeto. El sistema de ADP
cualquier uno o ms 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 explotacin de almacenamiento

encubierta
canales.
3.2.3 Aseguramiento
datos).
El TCB deber mantener el aislamiento de procesos a travs de la
provisin de espacios de direcciones distintas bajo su control.
La TCB se estructurar internamente en bien definido
mdulos en gran medida independientes. Se har uso efectivo
de hardware disponible para separar aquellos elementos que son
proteccin-crtico de los que no lo son. El TCB
mdulos debern estar diseados de tal manera que el principio de
mnima
privilegio se hace cumplir. Caractersticas de hardware, tales como
segmentacin, se utilizar para apoyar lgicamente 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.
se puede utilizar para validar peridicamente el correcto

funcionamiento de los elementos de hardware y firmware en el sitio
del TCB.
3.2.3.1.3 Anlisis Canal Covert
El desarrollador del sistema llevar a cabo una bsqueda exhaustiva
para
canales de almacenamiento encubiertas y tomar una determinacin
(ya sea
por medicin real o por estimacin de ingeniera) de
el mximo ancho de banda de cada canal identificado. (Vase
la seccin encubierta canales gua.)
3.2.3.1.4 Gestin de Instalaciones de confianza
El TCB apoyar operador independiente y administrador
funciones.
del sistema.
anlisis y pruebas exhaustivas. Sus objetivos sern:
para descubrir todos los defectos de diseo y de ejecucin que
permitir que un objeto externo a la TCB para leer, cambiar o
delete normalmente datos negados bajo el obligatorio o

poltica de seguridad discrecional impuesta por la TCB; as como
que se asegure de que ningn objeto (sin autorizacin 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
penetracin. Todos los defectos detectados sern 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 aplicacin TCB es
consistente con la memoria descriptiva de nivel superior.
(Vea las lneas directrices de ensayo de seguridad.)
Un modelo formal de la poltica 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 trminos de excepciones, mensajes de error,
y efectos. Queda demostrado ser un exacto
Descripcin de la interfaz de TCB.
Gestin de la Configuracin 3.2.3.2.3
Durante el desarrollo y mantenimiento de la TCB, una
sistema de gestin de la configuracin ser en el lugar que
mantiene el control de cambios en el nivel superior descriptiva
especificacin, otros datos de diseo, implementacin

documentacin, cdigo fuente, el funcionamiento del versinde
cdigo objeto, y accesorios de la prueba y la documentacin. Los
sistema de gestin de la configuracin deber asegurar una
coherente
mapeo entre toda la documentacin y el cdigo asociado con
la versin actual de la TCB. Herramientas se proporcionarn
para la generacin de una nueva versin de la TCB de la fuente
cdigo. Tambin disponible sern herramientas para la comparacin
de una
versin recin generada con la versin anterior TCB en
Para asegurarse de que slo los cambios previstos tienen
ha logrado en el cdigo que realmente se utiliza como
nueva versin de la TCB.
3.2.4 Documentacin
TCB,
deberan ser

de auditora
el cambio de las caractersticas de seguridad de un usuario. Incluir
proporcionar directrices sobre el uso coherente y eficaz de la
caractersticas de proteccin del sistema, cmo interactan, cmo
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 instalacin de un modo seguro. Los mdulos de TCB que contienen
deber identificarse el mecanismo de validacin de referencia. Los
procedimientos para la generacin segura de un nuevo TCB de la fuente
despus
Se describir la modificacin de cualquiera de los mdulos en el TCB.
documento
muestran cmo el
seguridad
pruebas funcionales mecanismos. Incluir resultados de
probar la eficacia de los mtodos utilizados para reducir encubierta
anchos de banda de canal.
descripcin de
de cmo esta filosofa se traduce en la TCB. Los

Se describirn las interfaces entre los mdulos de TCB. LA
descripcin formal del modelo de poltica de seguridad aplicada por el
TCB deber estar disponible y demostrado que es suficiente para
hacer cumplir la poltica de seguridad. La proteccin especfica TCB
mecanismos debern ser identificados y una explicacin dan para
mostrar
que cumplan el modelo. El alto nivel descriptivo
especificacin (DTLS) se muestra como una precisa
Descripcin de la interfaz de TCB. La documentacin debe describir
cmo el TCB implementa el concepto monitor de referencia y dar
una explicacin por qu es resistente a la manipulacin, no puede ser
anulada,
y se ha implementado correctamente. La documentacin debe describir
cmo
la TCB est estructurado para facilitar las pruebas y hacer cumplir
menos
privilegio. Esta documentacin deber presentar tambin los resultados
del anlisis canal encubierto y las compensaciones involucradas en
restringiendo los canales. Todos los eventos auditables que pueden ser
utilizado en la explotacin 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 auditora,
se facilitar. (Vea la seccin de Orientacin 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
pequeo
suficiente para ser sometidos a anlisis y pruebas. Para este fin, la TCB es
estructurado para excluir el cdigo no es esencial para la aplicacin de la poltica
de seguridad, con
ingeniera de sistemas significativa durante el diseo y la aplicacin dirigida TCB
para minimizar su complejidad. Un administrador de seguridad es compatible,
mecanismos de auditora se expanden para sealar acontecimientos seguridadpertinentes, y el sistema
se requieren procedimientos de recuperacin. El sistema es altamente resistente
a
penetracin. Los siguientes son los requisitos mnimos para los sistemas
asignado un
clase (B3) Valoracin:
y
de ADP.
El mecanismo de aplicacin (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 propagacin de acceso
los derechos. El mecanismo de control de acceso discrecional deber,
ya sea por accin explcita del usuario o por defecto, disponer que
objetos estn protegidos contra el acceso no autorizado. Estos acceso
controles debern 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. Adems, 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 slo podr ser cedido por
los usuarios autorizados.
incluyendo
representaciones cifrados de informacin, producidos por una previa
las acciones de los sujetos es estar a disposicin de cualquier tema que
obtiene
el acceso a un objeto que se ha lanzado de nuevo al sistema.
o

seguridad
niveles. Alguna

recibido.
a travs de los canales de comunicacin de un solo nivel o de
E/S
dispositivos.
especificar los nombres de las etiquetas imprimibles asociados
a
con

de salida. Cualquier anulacin de estos incumplimientos
marcado
la
conectados.
hacer cumplir

todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S
dispositivos) que estn directa o indirectamente accesible por temas
externo a la TCB. Estos sujetos y objetos sern
etiquetas de sensibilidad asignados que son una combinacin de
niveles de clasificacin jerrquica y no jerrquica
categoras 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 ms seguridad. (Vea la obligatoria
______________________________
etiquetas sern iguales a la mayor clasificacin jerrquica de cualquiera de los
jerrquica
categoras.
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 slo si el jerrquica
clasificacin en el nivel de seguridad del sujeto es mayor que
o igual a la clasificacin jerrquica en el objeto de
nivel de seguridad y las categoras no jerrquicas en la
nivel de seguridad del sujeto incluye todos los no-jerrquica
categoras en el nivel de seguridad del objeto. Un sujeto puede escribir

un objeto slo si la clasificacin jerrquica en el
nivel de seguridad del sujeto es inferior o igual a la
clasificacin jerrquica en el nivel de seguridad del objeto y
todas las categoras no jerrquicas en la seguridad del sujeto
nivel se incluyen en las categoras jerrquicas no en el
nivel de seguridad del objeto. Identificacin y autentificacin
datos sern utilizados por el TCB para autenticar al usuario de
identidad y para asegurar que el nivel de seguridad y autorizacin
zacin de los sujetos externos a la TCB que se puede crear
para actuar en nombre de cada usuario estn dominadas por el
aclaramiento y la autorizacin de dicho usuario.
informacin para
autorizaciones de subjectsexternal a la TCB que puede ser
por la liquidacin y la ordenacin de ese usuario. El TCB deber

por cualquier
forma nica
entre ella misma y los usuarios para el uso cuando un TCB-apositivo
Se requiere conexin de usuario (por ejemplo, inicio de sesin,
cambio de tema
nivel de seguridad). Comunicaciones a travs de este camino de
confianza
deber ser activado exclusivamente por un usuario de la TCB y
debern estar aislados de manera lgica y sin lugar a dudas
distinguible de otros caminos.
3.3.2.2 Auditora
es
TCB

ordenador
tambin
ser capaz de auditar cualquier anulacin de las marcas de salida
legibles.
Para cada evento registrado, el registro de auditora deber identificar:
Fecha
y la hora del evento, el usuario, el tipo de evento, y el xito o
fracaso del evento. Para eventos de identificacin / autenticacin
el origen de la solicitud (por ejemplo, la terminal ID) se incluye en
el registro de auditora. Para los eventos que introducen un objeto en un
espacio de direcciones del usuario y para eventos de eliminacin de
objetos de la auditora
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 ms
usuarios en funcin 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
explotacin de los canales de almacenamiento encubiertas. El TCB
contendr
un mecanismo que es capaz de monitorear la ocurrencia o
acumulacin de eventos auditables de seguridad que puedan indicar
una
inminente violacin de la poltica de seguridad. Este mecanismo ser
capaz de notificar inmediatamente al administrador de seguridad
cuando
umbrales se superan, y si la aparicin o acumulacin

de estos eventos relevantes de seguridad contina, el sistema deber
tomar las medidas menos perjudiciales para dar por terminado el
evento.
3.3.3 Aseguramiento
datos).
privilegio menos se cumple. Caractersticas de hardware, tales
como la segmentacin, se utilizarn para apoyar lgicamente
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 diseado y estructurado para
utilizar un mecanismo de proteccin completa, conceptualmente
simple
con semntica definida con precisin. Este mecanismo deber
desempear un papel central en la aplicacin de la estructuracin

interna
del TCB y el sistema. El TCB incorporar
uso significativo de la estratificacin, la abstraccin y la ocultacin
de datos.
Ingeniera de sistemas significativos se dirige hacia
minimizar la complejidad de la TCB y se excluyen de la
los mdulos de TCB que no son de proteccin crtico.
del TCB.
para
canales encubiertos y tomar una determinacin (ya sea por
medicin real o por estimacin de ingeniera) de la
mximo ancho de banda de cada canal identificado. (Vea el
Seccin Orientacin Canales Covert.)
funciones. Las funciones realizadas en el papel de una
se identificar administrador de seguridad. La ADP
personal administrativo del sistema slo podrn
realizar funciones de administrador de seguridad despus de tomar

una
accin auditable distinta a asumir la seguridad
funcin de administrador en el sistema ADP. No la seguridad
funciones que se pueden realizar en la seguridad
rol de administracin se limitar estrictamente a los
esencial para la realizacin de la funcin de seguridad efectiva.
3.3.3.1.5 Recuperacin de confianza
Procedimientos y / o mecanismos se proporcionarn para asegurar
que, despus de un fallo del sistema ADP u otra discontinuidad,
se obtiene la recuperacin sin un compromiso de proteccin.
del sistema.
anlisis y pruebas exhaustivas. Sus objetivos debern
ser: para descubrir todos los defectos de diseo e implementacin
que
permitira un sujeto externo a la TCB de leer,
cambiar o eliminar datos normalmente negados bajo el
poltica de seguridad obligatoria o discrecional impuesta por
la TCB; as como para asegurar que ningn objeto (sin
autorizacin 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 penetracin. 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
Aplicacin TCB es consistente con la descriptiva
especificacin de nivel superior. (Vea la Prueba de Seguridad
Lineamientos.) No hay defectos de diseo y no ms de unos pocos
fallas de implementacin corregibles pueden encontrarse en
probando y no habr confianza razonable de que
pocos permanecen.
y efectos. Queda demostrado ser un exacto
Descripcin de la interfaz de TCB. Un argumento convincente
habr de darse que el DTLS es consistente con el modelo.
Durante el desarrollo y mantenimiento de la TCB, una
sistema de gestin de la configuracin ser en el lugar que
mantiene el control de cambios en el nivel superior descriptiva

especificacin, otros datos de diseo, implementacin
documentacin, cdigo fuente, la versin de funcionamiento de la
cdigo objeto, y accesorios de la prueba y la documentacin. Los
sistema de gestin de la configuracin deber asegurar una
coherente
mapeo entre toda la documentacin y el cdigo asociado con
la versin actual de la TCB. Herramientas se proporcionarn
para la generacin de una nueva versin de la TCB de la fuente
cdigo. Tambin disponible sern herramientas para la comparacin
de una
versin recin generada con la versin anterior TCB en
Para asegurarse de que slo los cambios previstos tienen
ha logrado en el cdigo que realmente se utiliza como
nueva versin de la TCB.
3.3.4 Documentacin
TCB,
deberan ser

de auditora
despus
Ello
incluir los procedimientos para garantizar que el sistema es
comenzado inicialmente en una manera segura. Los procedimientos
debern ser tambin
incluido para reanudar el funcionamiento seguro del sistema despus
de cualquier interrupcin en
operacin del sistema.
documento
muestran cmo el
seguridad
anchos de banda de canal.

descripcin de
mostrar
que cumplan el modelo. El alto nivel descriptivo
especificacin (DTLS) se muestra como una precisa
Descripcin de la interfaz de TCB. La documentacin debe describir
cmo el TCB implementa el concepto monitor de referencia y dar
una explicacin por qu es resistente a la manipulacin, no puede ser
anulada,
y se ha implementado correctamente. La implementacin TCB (es decir,
en
hardware, firmware y software) se muestran de manera informal a
ser coherente con los DTLS. Los elementos de la DTLS sern
se muestra, usando tcnicas informales, para corresponder a los
elementos
del TCB. La documentacin debe describir cmo el TCB es
estructurado para facilitar las pruebas y hacer cumplir privilegios
mnimos.
Esta documentacin deber presentar tambin los resultados de la
encubierta
anlisis de canal y las ventajas y desventajas implicadas en la

restriccin de la
canales. Todos los eventos auditables que se pueden utilizar en el
explotacin de canales de almacenamiento encubiertas conocidas ser
identificados. Los anchos de banda de los canales de almacenamiento
encubiertas conocidas,
?
4.0 DIVISIN A: PROTECCIN VERIFICADO
Esta divisin se caracteriza por el uso de la verificacin de seguridad formal
mtodos para asegurar que los controles de seguridad obligatorios y
discrecionales
empleado en el sistema puede proteger eficazmente clasificado u otro sensible
informacin almacenada o procesada por el sistema. Amplia documentacin es
requerida para demostrar que la TCB cumple con los requisitos de seguridad en
todo
aspectos de diseo, desarrollo e implementacin.
?
4.1 CLASE (A1): DISEO VERIFICADO
Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3)
en
que no se aaden caractersticas arquitectnicas adicionales o requisitos de la
poltica.
La caracterstica distintiva de los sistemas de esta clase es el anlisis derivado
desde la especificacin de diseo formal y tcnicas de verificacin 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 poltica de seguridad y una especificacin de alto nivel formales (FTLs) del
diseo.
Independiente del lenguaje de especificacin en particular o sistema de
verificacin
utilizado, hay cinco criterios importantes para la clase (A1) la verificacin del
diseo:
* Un modelo formal de la poltica de seguridad debe ser claramente
identificado y documentado, incluyendo una prueba matemtica
que el modelo es consistente con sus axiomas y es
suficiente para apoyar la poltica 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 ejecucin.
* Los FTLs de la TCB deben demostrarse que son consistentes con la
modelo mediante tcnicas formales cuando sea posible (es decir, donde
herramientas de verificacin de existir) y las informales de otra manera.
* La implementacin 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
tcnicas informales, que corresponden a los elementos de la
TCB. Los FTLs deben expresar el mecanismo de proteccin unificada
necesario para satisfacer la poltica de seguridad, y es el
elementos de este mecanismo de proteccin que se asignan a la
elementos de la TCB.
* Tcnicas de anlisis formal se deben utilizar para identificar y

analizar los canales encubiertos. Tcnicas informales pueden ser utilizados
para
identificar los canales de temporizacin encubiertas. La persistencia de
canales encubiertos identificadas en el sistema deben estar justificadas.
De acuerdo con el anlisis extenso de diseo y desarrollo de la TCB
requerida de los sistemas en la clase (A1), gestin de la configuracin es ms
estricta
requeridos y se establezcan procedimientos para la distribucin segura del
sistema
a los sitios. Un administrador de la seguridad del sistema es compatible.
Los siguientes son los requisitos mnimos para los sistemas asignados a una clase
(A1)
Puntuacin:
y
de ADP.
El mecanismo de aplicacin (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 propagacin de acceso
los derechos. El mecanismo de control de acceso discrecional deber,
ya sea por accin explcita del usuario o por defecto, disponer que
objetos estn protegidos contra el acceso no autorizado. Estos acceso
controles debern 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. Adems, 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 slo podr ser cedido por
los usuarios autorizados.
incluyendo cifrado
o

seguridad
niveles. Alguna

recibido.
a travs de los canales de comunicacin de un solo nivel o de
E/S
dispositivos.
especificar los nombres de las etiquetas imprimibles asociados
a
con

de salida. Cualquier anulacin de estos incumplimientos
marcado
la
conectados.
hacer cumplir

todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S
dispositivos) que estn directa o indirectamente accesible por temas
externo a la TCB. Estos sujetos y objetos sern
etiquetas de sensibilidad asignados que son una combinacin de
niveles de clasificacin jerrquica y no jerrquica
categoras 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 ms 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 slo si el jerrquica
clasificacin en el nivel de seguridad del sujeto es mayor que
o igual a la clasificacin jerrquica en el objeto de
nivel de seguridad y las categoras no jerrquicas en la
nivel de seguridad del sujeto incluye todos los no-jerrquica
categoras en el nivel de seguridad del objeto. Un sujeto puede escribir
______________________________

jerrquica
categoras.
un objeto slo si la clasificacin jerrquica en el
nivel de seguridad del sujeto es inferior o igual a la
clasificacin jerrquica en el nivel de seguridad del objeto y
todas las categoras no jerrquicas en la seguridad del sujeto
nivel se incluyen en las categoras jerrquicas no en el
nivel de seguridad del objeto. Identificacin y autentificacin
datos sern utilizados por el TCB para autenticar al usuario de
identidad y para asegurar que el nivel de seguridad y autorizacin
cin de los sujetos externo a la TCB que puede ser creado para
actuar en nombre de cada usuario estn dominados por el
aclaramiento y la autorizacin de dicho usuario.
informacin para
creado para actuar en nombre del usuario individual estn dominadas

por
la liquidacin y autorizacin de ese usuario. El TCB deber
por cualquier
forma nica
entre ella misma y los usuarios para el uso cuando un TCB-apositivo
Se requiere conexin de usuario (por ejemplo, inicio de sesin,
cambio de tema
nivel de seguridad). Comunicaciones a travs de este camino de
confianza
deber ser activado exclusivamente por un usuario o la TCB y
debern estar aislados de manera lgica y sin lugar a dudas
4.1.2.2 Auditora
es

TCB
ordenador
Tambin podr auditar cualquier anulacin de la salida legible
marcas. Para cada evento registrado, el registro de auditora,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y
xito o el fracaso del evento. Para la identificacin /
eventos de autenticacin del origen de la solicitud (por ejemplo, la
terminal de Identificacin)
se incluirn en el registro de auditora. Para los eventos que
introducir un objeto en el espacio de direcciones de un usuario y para el
objeto
eventos de eliminacin del registro de auditora debern incluir el
nombre de la
objeto y nivel de seguridad del objeto. El sistema de ADP
cualquier uno o ms 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 explotacin de almacenamiento
encubierta
canales. El TCB deber contener un mecanismo que es capaz de
supervisar la aparicin o acumulacin de seguridad auditable
hechos que pueden indicar una violacin inminente de la seguridad
poltica. Este mecanismo ser capaz de notificar inmediatamente a la
administrador de seguridad cuando los umbrales se superan, y, si es

la aparicin o acumulacin de stos de seguridad pertinentes
acontecimientos contina, el sistema tomar la menor disruptiva
accin para terminar el evento.
4.1.3 Aseguramiento

datos).
privilegio menos se cumple. Caractersticas de hardware, tales
como la segmentacin, se utilizarn para apoyar lgicamente
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 diseado y estructurado para
utilizar un mecanismo de proteccin completa, conceptualmente

simple
con semntica definida con precisin. Este mecanismo deber
desempear un papel central en la aplicacin de la estructuracin
interna
del TCB y el sistema. El TCB incorporar
uso significativo de la estratificacin, la abstraccin y la ocultacin
de datos.
Ingeniera de sistemas significativos se dirige hacia
minimizar la complejidad de la TCB y se excluyen de la
los mdulos de TCB que no son de proteccin crtico.
del TCB.
para
canales encubiertos y tomar una determinacin (ya sea por
medicin real o por estimacin de ingeniera) de la
mximo ancho de banda de cada canal identificado. (Vea el
Seccin Orientacin Canales Covert.) Los mtodos formales deber
ser utilizado en el anlisis.
funciones. Las funciones realizadas en el papel de una

se identificar administrador de seguridad. La ADP
personal administrativo del sistema slo podrn
realizar funciones de administrador de seguridad despus de tomar
una
accin auditable distinta a asumir la seguridad
funcin de administrador en el sistema ADP. No la seguridad
funciones que se pueden realizar en la seguridad
rol de administracin se limitar estrictamente a los
4.1.3.1.5 Recuperacin de confianza
Procedimientos y / o mecanismos se proporcionarn para asegurar
que, despus de un fallo del sistema ADP u otra discontinuidad,
se obtiene la recuperacin sin un compromiso de proteccin.
del sistema.
anlisis y pruebas exhaustivas. Sus objetivos debern
ser: para descubrir todos los defectos de diseo e implementacin
que
permitira un sujeto externo a la TCB de leer,
cambiar o eliminar datos normalmente negados bajo el
poltica de seguridad obligatoria o discrecional impuesta por

la TCB; as como para asegurar que ningn objeto (sin
autorizacin 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 penetracin. 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
Aplicacin TCB es coherente con las lminas superior formales
especificacin de nivel. (Vea la Prueba de Seguridad
Lineamientos.) No hay defectos de diseo y no ms de unos pocos
fallas de implementacin corregibles pueden encontrarse en
probando y habr una confianza razonable que pocos
permanecer. Mapeo manual u otra de las FTLs al
cdigo fuente puede servir de base para las pruebas de
penetracin.
y efectos. Una especificacin de alto nivel formales (FTLs) de
la TCB se mantendr que describe con precisin la
TCB en trminos de excepciones, mensajes de error y efectos.
Los DTLS y FTLs incluirn 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 descripcin exacta de la
Interfaz de TCB. Un argumento convincente se decidi que se
la DTLS es consistente con el modelo y una combinacin de
Se utilizarn tcnicas formales e informales para demostrar que
la FTLs es consistente con el modelo. Esta verificacin
pruebas ser compatible con la prevista en el
el estado de la tcnica de la seguridad informtica en particular
centro-endosado especificacin formal y verificacin
sistema utilizado. Mapeo manual u otra de las FTLs al
Se realizar el cdigo fuente TCB para proporcionar evidencia de
aplicacin correcta.
Durante todo el ciclo de vida, es decir, durante el diseo,
desarrollo y mantenimiento de la TCB, una configuracin
sistema de direccin debe estar en su lugar para toda seguridadhardware 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 diseo,
documentacin de la aplicacin, cdigo fuente, el funcionamiento
versin del cdigo objeto, y de prueba y accesorios
documentacin. El sistema de gestin de la configuracin deber
asegurar una asignacin consistente entre toda la documentacin y
cdigo asociado con la versin actual de la TCB.
Herramientas se proporcionan para la generacin de una nueva
versin
del TCB partir del cdigo fuente. Tambin disponible ser

herramientas, mantenidos bajo control estricto de configuracin, por
la comparacin de una versin recin generado con la TCB anterior
versin a fin de determinar que slo la intencin
se han realizado cambios en el cdigo que realmente ser
utilizado como la nueva versin de la TCB. Una combinacin de
y salvaguardas tcnicas, fsicas procedimental ser
utilizado para proteger de la modificacin no autorizada o
la destruccin de la copia maestra o copias de todo el material
utilizado para generar la TCB.
4.1.3.2.4 Distribucin de confianza
Una instalacin de control del sistema ADP y distribucin de
confianza
sern las previstas en el mantenimiento de la integridad de la
asignacin entre los datos maestros que describen el actual
versin de la TCB y la copia maestra en el lugar del
cdigo de la versin actual. Procedimientos (por ejemplo, el sitio
pruebas de aceptacin 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 Documentacin
TCB,

deberan ser
de auditora
despus
Ello
incluir los procedimientos para garantizar que el sistema es
debern ser tambin
incluido para reanudar el funcionamiento seguro del sistema despus
de cualquier interrupcin en
operacin del sistema.

documento
muestran cmo el
seguridad
anchos de banda de canal. Los resultados de la asignacin entre el
especificacin de nivel superior formal y el cdigo fuente TCB sern
dado.
descripcin de
mostrar
que cumplan el modelo. El descriptiva especificado de nivel superior
ficacin (DTLS) se demuestra que es una descripcin exacta de
la interfaz de TCB. La documentacin debe describir cmo el TCB
implementa el concepto de monitor de referencia y dar una explicacin
la razn por la que es resistente a la manipulacin, no se puede omitir,

y
se ha implementado correctamente. La implementacin TCB (es decir,
en
hardware, firmware y software) se muestran de manera informal a
ser compatible con la especificacin de alto nivel formales (FTLs).
Los elementos de las FTLs se indicarn, mediante informal
tcnicas, para corresponder a los elementos de la TCB.
La documentacin debe describir cmo el TCB est estructurado para
facilitar las pruebas y hacer cumplir privilegio menos. Esta
documentacin deber presentar tambin los resultados de la
encubierta
anlisis de canal y las ventajas y desventajas implicadas en la
restriccin de la
canales. Todos los eventos auditables que se pueden utilizar en el
explotacin de canales de almacenamiento encubiertas conocidas ser
identificados. Los anchos de banda de los canales de almacenamiento
encubiertas conocidas,
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 MS ALL DE LA CLASE (A1)
La mayor parte de las mejoras de seguridad previsto para los sistemas que
proporcionen
caractersticas y aseguramiento, adems de que ya previstas por clase (Al)
sistemas estn ms all de la tecnologa actual. La discusin que sigue est
destinado a
orientar la labor futura y se deriva de las actividades de investigacin y

desarrollo
ya en marcha, tanto en los sectores pblico y privado. A medida que ms y mejor
tcnicas de anlisis se desarrollan, los requisitos para estos sistemas
ser ms explcito. En el futuro, el uso de la verificacin formal ser
extendidos hasta el nivel de la fuente y los canales de temporizacin encubiertas
sern ms plenamente
abordarse. En este nivel el entorno de diseo se convertir en importante y
prueba ser ayudado por el anlisis de la especificacin formal de nivel superior.
Se tendr en cuenta para la correccin 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 ms all de la clase (A1) incluyen:
* Arquitectura del Sistema
Una demostracin (formal o no) se debe dar muestra
que los requisitos de auto-proteccin y la integridad de
monitores de referencia se han implementado en el TCB.
* Pruebas de seguridad
Aunque ms all del estado de la tcnica actual, es
prev que se har alguna generacin de pruebas de los casos
automticamente de la especificacin formal de nivel superior o
especificaciones formales de nivel inferior.
* Especificacin formal y Verificacin
El TCB debe ser verificada hasta el nivel de cdigo fuente,
utilizando mtodos de verificacin formal cuando sea factible. Oficial

verificacin del cdigo fuente de la seguridad pertinente
partes de un sistema operativo ha demostrado ser una tarea difcil
tarea. Dos consideraciones importantes son la eleccin de una
lenguaje de alto nivel cuya semntica puede ser plena y
expresado formalmente, y un mapeo cuidadoso, a travs de
etapas sucesivas, del diseo formal abstracta a un
formalizacin de la aplicacin de bajo nivel
especificaciones. La experiencia ha demostrado que slo cuando el
especificaciones de nivel ms bajo se corresponden estrechamente a la
actual
cdigo puede codificar pruebas se realiz con xito.
* Trusted Diseo para el Medio Ambiente
El TCB debe estar diseado en un centro de confianza con solamente
confianza (liquidados) Personal.
PARTE II:
JUSTIFICACIN Y DIRECTRICES
?
5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMTICOS DE
CONFIANZA
Los criterios se dividen dentro de cada clase en grupos de requisitos. Estas
agrupaciones fueron desarrollados para asegurar que los tres objetivos bsicos
de control de
seguridad informtica estn satisfechos y sin vecinos. Estos objetivos de control
lidiar con:
* Politica de seguridad
* Rendicin de cuentas
* Aseguramiento
En esta seccin se ofrece un anlisis de estos objetivos generales de control y
su implicacin en trminos de diseo de sistemas de confianza.
?
5.1 NECESIDAD DE CONSENSO
Un objetivo importante del Centro de Seguridad Informtica del Departamento de
Defensa es fomentar el ordenador
Industria para desarrollar sistemas informticos fiables y productos, hacindolos
ampliamente
disponible en el mercado comercial. El logro de este objetivo
requiere el reconocimiento y articulacin de los sectores pblico y privado de
la necesidad y la demanda de este tipo de productos.
Como se describe en la introduccin de este documento, los esfuerzos para
definir la
problemas y desarrollar soluciones asociados con el procesamiento a nivel
nacional sensibles
informacin, as como otros datos sensibles, tales como financieros, mdicos, y
informacin del personal utilizado por el Establecimiento de Seguridad Nacional,
han sido
llevando a cabo para un nmero de aos. Los criterios, tal como se describe en la
Parte I,
representar la culminacin de estos esfuerzos y describir los requisitos bsicos
para
edificio confiaba sistemas informticos. Hasta la fecha, sin embargo, estos

sistemas han sido
visto por muchos, ya que slo la satisfaccin de las necesidades de la seguridad
nacional. Mientras esta
percepcin contina el consenso necesario para motivar fabricacin de confianza
sistemas sern escasas.
El propsito de esta seccin 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 estn fuera
el Establecimiento de Seguridad Nacional puede evaluar su universalidad y, por
extensin, 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 DEFINICIN Y UTILIDAD
El trmino "controlar objetivo" se refiere a una declaracin de intenciones con
respecto a la
control sobre algn aspecto de los recursos de una organizacin, o procesos, o
ambos. En trminos de un sistema informtico, 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 genricas,
tales como
la necesidad de gestionar y manejar datos sensibles con el fin de evitar el
compromiso,
o la necesidad de proporcionar la rendicin de cuentas con el fin de detectar el
fraude, el control
objetivos han sido identificados como un mtodo til de la seguridad expresar
metas. [3]
Ejemplos de objetivos de control incluyen los tres requisitos bsicos de diseo

para
la aplicacin del concepto monitor de referencia discuti en la Seccin 6. Ellos
son:
* El mecanismo de validacin de referencia debe ser a prueba de
manipulaciones.
* El mecanismo de validacin de referencia siempre se debe invocar.
* El mecanismo de validacin de referencia debe ser suficientemente pequeo
para ser
sometido a anlisis y pruebas, la integridad de los cuales puede
tener la seguridad. [1]
?
5.3 CRITERIOS OBJETIVOS DE CONTROL
Los tres objetivos bsicos de control de los criterios tienen que ver con la
seguridad
la poltica, la rendicin de cuentas, y la garanta. El resto de esta seccin se
ofrece
una discusin de estos requisitos bsicos.
En el sentido ms general, la seguridad informtica se refiere a
controlar la forma en la que un ordenador puede ser utilizado, es decir,
el control de cmo la informacin procesada por que se puede acceder y
manipulado. Sin embargo, en un examen ms detallado, la seguridad
informtica
puede referirse a una serie de reas. Un sntoma de esto, FIPS PUB 39,
Glosario para los sistemas informticos de seguridad, no tiene una nica
definicin de la seguridad informtica. [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 comn
hilo conductor de estas definiciones es la palabra "proteccin".
Otras declaraciones de los requisitos de proteccin se pueden encontrar en
Directiva DoD 5200.28, que describe un nivel aceptable de
proteccin para los datos clasificados como uno que "asegurar que
sistemas que procesan, almacenan o usan datos clasificados y producir
informacin clasificada har, con fiabilidad razonable,
impedir: a. Acceso deliberada o inadvertida para clasificarse
material por parte de personas no autorizadas, y b. Unauthorized
manipulacin de la computadora y su perifrico asociado
dispositivos ". [8]
En resumen, los requisitos de proteccin deben definirse en trminos de
las amenazas percibidas, riesgos y objetivos de una organizacin. Esta
a menudo se dice en trminos de una poltica de seguridad. Ha sido
sealado en la literatura que se trata de leyes externas, reglas,
reglamentos, etc., que establecen lo que el acceso a la informacin es
se permitir, independiente de la utilizacin de un ordenador. En particular,
un sistema dado slo puede decirse que es seguro con respecto a su
la ejecucin de alguna poltica especfica. [30] Por lo tanto, el control
objetivo de la poltica de seguridad es:
OBJETIVO DE SEGURIDAD CONTROL DE POLTICA
Una declaracin de intenciones en relacin con el control sobre el acceso y la
difusin de la informacin, que se conocer como la poltica de seguridad
debe ser precisamente definida e implementada para cada sistema que es
utilizado para procesar informacin sensible. La poltica de seguridad debe
reflejar con precisin las leyes, reglamentos y polticas generales

a partir del cual se deriva.
5.3.1.1 Poltica de Seguridad Obligatorio
Cuando se desarrolla una poltica de seguridad que se va a aplicar

para el control de clasificado u otro especficamente designado
informacin sensible, la poltica debe incluir detallada
reglas sobre la manera de manejar esa informacin durante todo su
ciclo de la vida. Estas reglas son una funcin de los distintos
sensibilidad designaciones que la informacin puede asumir
y las diversas formas de acceso soportados por el sistema.
Obligatorio Seguridad se refiere a la aplicacin de un conjunto de
reglas de control de acceso que limita el acceso de un sujeto a
informacin sobre la base de una comparacin de ese
despacho / autorizacin del individuo a la informacin,
la designacin de clasificacin / sensibilidad de la
la informacin y la forma de acceso estn mediadas.
Polticas 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
matemticamente conocido como un "celosa". [5]
Una clara implicacin de lo anterior es que el sistema debe

aseguran que las designaciones asociadas con datos sensibles
no se puede cambiar arbitrariamente, ya que esto podra permitir
las personas que no tienen la autorizacin apropiada para
acceso a la informacin sensible. Tambin implcita es la
requisito de que el sistema de control de la circulacin de la informacin
para que los datos no se puede almacenar con menor sensibilidad

ha sido autorizado designaciones a menos que su "degradacin".
El objetivo de control es:
CONTROL DE SEGURIDAD OBLIGATORIO OBJETIVO
Las polticas de seguridad definidas para los sistemas que se utilizan
para
proceso clasificado u otro clasifica especficamente
informacin sensible debe incluir disposiciones para la
aplicacin de las normas de control de acceso obligatorios. Eso es,
deben incluir un conjunto de reglas para controlar el acceso
basada directamente en una comparacin de los individuales de
autorizacin o autorizacin para la informacin y la
clasificacin o designacin de la sensibilidad
la informacin que se busca, e indirectamente en consideraciones
de los factores ambientales fsicos y de otro tipo de control.
Las reglas de control de acceso obligatorios deben reflejar con precisin
las leyes, los reglamentos y las polticas generales de la que
se derivan.
5.3.1.2 Poltica de Seguridad Discrecional
Seguridad discrecional es el tipo principal de acceso
de control disponible en los sistemas informticos 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
explcitamente los tipos de acceso a otros usuarios pueden tener que
la informacin bajo su control. Seguridad Discrecional
difiere de seguridad obligatorias en que implementa un
poltica de control de acceso sobre la base de un individuo de

necesita-a-saber en comparacin con los controles obligatorios que son
impulsado por la clasificacin o la sensibilidad designacin de
la informacin.
Controles discrecionales no son un sustituto de obligatoria
controles. En un entorno en el que la informacin es
clasificado (como en el Departamento de Defensa) Seguridad
discrecional ofrece
para una mayor granularidad de control dentro de la general
restricciones de la poltica obligatoria. El acceso a clasificado
informacin requiere la aplicacin efectiva de ambos tipos
de los controles como condicin previa para la concesin de ese acceso.
En
general, ninguna persona puede tener acceso a la clasificada
informacin 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
desempeo de funciones oficiales, es decir, determinados a tener un
necesita-a-saber - DISCRECIONAL. En otras palabras,
controles discrecionales dan individuos discrecin
decidir sobre cul de los accesos permitidos en realidad
se le permita a la que los usuarios, de acuerdo con imperiosas
restricciones polticas obligatorias. El objetivo de control es:
CONTROL DE SEGURIDAD DISCRECIONAL OBJETIVO
Las polticas de seguridad definidas para los sistemas que se utilizan
para
proceso clasificada u otra informacin sensible debe
incluir disposiciones para la aplicacin de la discrecionalidad
reglas de control de acceso. Es decir, se deben incluir una

conjunto coherente de normas para el control y la limitacin del acceso
basado en individuos identificados que han sido determinados
tienen una necesidad de conocer la informacin.
5.3.1.3 Marcado
Para llevar a cabo un conjunto de mecanismos que pondrn en vigor
una poltica de seguridad obligatorio, es necesario que el
informacin de marca de sistema con la clasificacin correspondiente o
sensibilidad etiquetas y mantener estas marcas como el
la informacin se mueve a travs del sistema. Una vez que la
informacin es
comparaciones inalterable y marcadas con precisin, 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 clasificacin o la sensibilidad
internamente es la capacidad de generar de forma automtica
adecuadamente "etiquetado" de salida. Las etiquetas, si con precisin y
integralmente mantenido por el sistema, siendo preciso cuando
salida del sistema. El objetivo de control es:
MARCADO OBJETIVO DE CONTROL
Los sistemas que estn diseados para hacer cumplir una fianza
obligatoria
poltica debe almacenar y preservar la integridad de
clasificacin u otras etiquetas de sensibilidad para todos
informacin. Las etiquetas exportadas del sistema deben ser
representaciones precisas de la interna correspondiente
etiquetas de sensibilidad que se exportan.

El segundo objetivo de control bsico aborda uno de los
principios fundamentales de la seguridad, es decir, individuo
la rendicin de cuentas. La responsabilidad individual es la clave para
asegurar
y el control de cualquier sistema que procesa la informacin 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 identificacin del usuario individual.
En segundo lugar, hay una necesidad para la autenticacin de la
identificacin.
La identificacin es funcionalmente dependiente de autenticacin.
Sin autenticacin, identificacin de usuario no tiene credibilidad.
Sin una identidad creble, ni obligatorio ni discrecional
las polticas de seguridad se pueden invocar correctamente porque no hay
la garanta de que las autorizaciones adecuadas se pueden hacer.
El tercer requisito es para capacidades de auditora confiables. Ese
Es decir, un sistema informtico de confianza debe proporcionar personal
autorizado
con la capacidad de auditar cualquier accin que potencialmente pueden
causar
acceso, generacin de, o efectuar la liberacin de reservada o
informacin sensible. Los datos de auditora sern selectivamente
adquiridos en base a las necesidades de auditora de una instalacin en
particular
y / o aplicacin. Sin embargo, debe haber suficiente granularidad
en los datos de auditora para apoyar la localizacin de los eventos
auditables a un
individuo especfico que ha tomado las acciones o en cuyo nombre

se tomaron las acciones. El objetivo de control es:
OBJETIVO DE CONTROL DE RENDICIN DE CUENTAS
Los sistemas que se utilizan para procesar o manipular clasificada u otro
informacin sensible debe asegurar la responsabilidad individual
siempre que sea una poltica de seguridad obligatoria o discrecional es
invocado. Adems, para asegurar la rendicin de cuentas, la capacidad
debe existir para que un agente autorizado y competente para el acceso y
evaluar la informacin de rendicin de cuentas por un medio seguro, dentro
de un
tiempo razonable y sin excesiva dificultad.
5.3.3 Aseguramiento
El tercer objetivo de control bsico se refiere a garantizar
o proporcionar confianza en que la poltica de seguridad ha sido
se aplica correctamente y que los elementos de proteccin pertinentes de
el sistema do, de hecho, mediar y hacer cumplir la intencin precisa
de esa poltica. Por extensin, la garanta debe incluir una garanta
que la parte de confianza del sistema slo funciona segn lo previsto. A
lograr estos objetivos, se necesitan dos tipos de seguridad.
Son la garanta de ciclo de vida y seguridad operacional.
Aseguramiento del ciclo de vida se refiere a las medidas adoptadas por una
organizacin para
asegrese de que el sistema est diseado, desarrollado y mantenido
utilizando formalizados y rigurosos controles y normas. [17]
Los sistemas informticos que procesan y almacenan sensible o clasificada
informacin depende del hardware y software para proteger esa
informacin. De ello se desprende que el hardware y software a s mismos

deben ser protegidos contra cambios no autorizados que podran hacer
mecanismos de proteccin al mal funcionamiento o ser anuladas por
completo.
Por esta razn, los sistemas informticos de confianza deben ser
cuidadosamente
evaluado y probado durante las fases de diseo y desarrollo y
reevaluados cada vez que se realizan cambios que podran afectar a la
integridad de los mecanismos de proteccin. Slo de esta manera puede
confianza estar previsto que el hardware y el software
interpretacin de la poltica de seguridad se mantiene con precisin
y sin distorsin.
Mientras que la garanta de ciclo de vida tiene que ver con los
procedimientos para
la gestin de diseo del sistema, el desarrollo y el mantenimiento;
operacional
aseguramiento centra en las caractersticas y arquitectura del sistema se
utilizan para
asegrese de que la poltica de seguridad se aplica uncircumventably
durante el funcionamiento del sistema. Es decir, la poltica de seguridad
debe haber
integrado en las caractersticas de hardware y software de proteccin de
el sistema. Los ejemplos de las medidas adoptadas para proporcionar este
tipo de
confianza incluyen: mtodos para probar el hardware operativa
y software para su correcto funcionamiento, el aislamiento de
proteccionismo
cdigo crtico, y el uso de hardware y software para proporcionar
dominios distintos. El objetivo de control es:
OBJETIVO DE CONTROL DE GARANTA
Los sistemas que se utilizan para procesar o manipular clasificada u otro

informacin sensible debe estar diseado para garantizar la correcta y
interpretacin precisa de la poltica de seguridad y no debe
distorsionar la intencin de que la poltica. Aseguramiento debe
proporcionarse
existe de que la aplicacin correcta y el funcionamiento de la poltica
a lo largo del ciclo de vida del sistema.
?
6.0 JUSTIFICACIN DETRS DE LAS CLASES DE EVALUACIN
?
6.1 EL CONCEPTO DE MONITOR DE REFERENCIA
En octubre de 1972, el Estudio de Planificacin de Tecnologa de Seguridad
Informtica, realiz
por James P. Anderson & Co., elabor un informe para los Sistemas Electrnicos
Divisin (ESD) de la Fuerza Area 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
hara
proporcionar multinivel instalaciones informticas seguras y controles.
El informe Anderson pas a definir el mecanismo de validacin de referencia
"una aplicacin 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 continuacin, aparece el

diseo de tres
requisitos que deben ser cumplidos por un mecanismo de validacin de
referencia:
a. El mecanismo de validacin de referencia debe ser a prueba de
manipulaciones.
b. El mecanismo de validacin de referencia siempre se debe invocar.
c. El mecanismo de validacin de referencia debe ser suficientemente
pequeo para ser
sujetos a anlisis y pruebas, la integridad de los cuales puede
estar seguro. "[1]
Continuacin de las actividades de investigacin y desarrollo tienen una amplia
revisin por pares y
sostenido la validez de las conclusiones del Comit Anderson. Los primeros
ejemplos
del mecanismo de validacin de referencia eran conocidos como granos de
seguridad. Los
Anderson Informe describe el ncleo de seguridad como "esa combinacin de
hardware
y el software que implementa el concepto de monitor de referencia ". [1] En este
orden de ideas,
se observar que el ncleo de seguridad debe ser compatible con los tres
referencia
requisitos de monitor enumerados anteriormente.
?
6.2 A SEGURIDAD FORMAL POLTICA DE MODELO
Tras la publicacin del informe de Anderson, una considerable investigacin fue
iniciado en los modelos formales de requisitos de la poltica de seguridad y de la
mecanismos que aplicar y hacer cumplir esos modelos de poltica 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
poltica. [2] El uso de las matemticas y la teora de conjuntos, el modelo define
con precisin la
nocin de estado seguro, modos fundamentales de acceso, y las reglas para
la concesin de los sujetos modos especficos de acceso a los objetos. Por ltimo,
un teorema es
probada para demostrar que las reglas son las operaciones de seguridad de
preservacin, por lo
que la aplicacin 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
tambin
seguro. Este teorema es conocido como el Teorema de Seguridad Bsica.
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 funcin de su clasificacin. Las transiciones de estado e invariantes de
el modelo de poltica 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 especficos de
acceso.
El modelo Bell y LaPadula, por ejemplo, define una relacin entre lo formal
niveles de seguridad de sujetos y objetos, que ahora hace referencia como el
"dominio
relacin ". A partir de esta definicin, los accesos permitidos entre los sujetos y
objetos se definen explcitamente los modos fundamentales de acceso,

incluyendo
acceso de slo lectura, lectura / escritura, y escribir-nico acceso. El modelo
define
el Estado de Seguridad simple para controlar la concesin de un sujeto acceso de
lectura a un
objeto especfico, y la * -Property (lase "Star Propiedad") para el control de la
concesin
un acceso por materias de escritura a un objeto especfico. Tanto la Seguridad
simple
Condicin y el * -Property incluyen disposiciones de seguridad obligatorias en
funcin de la
relacin de dominacin entre los niveles de seguridad formales de los sujetos y
objetos del
liquidacin de la materia y la clasificacin del objeto. Los
Discrecional Seguridad Propiedad tambin se define, y requiere que un
determinado
sujetos autorizados para todo el modo particular de acceso requerido para el
Estado
transicin. En su tratamiento de temas (procesos que actan 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 mtodo de la
prueba
requerida para demostrar formalmente que las secuencias de todo arbitrarias de
Estado
transiciones son la seguridad de preservacin. Tambin se demostr que el * Propiedad
es suficiente para evitar el compromiso de informacin por Caballo de Troya
ataques.
?
6.3 LA BASE Trusted Computing

Con el fin de fomentar la disponibilidad comercial generalizada de confianza
sistemas informticos, estos criterios de evaluacin han sido diseados para
abordar
aquellos sistemas en los que un ncleo de seguridad se ha implementado
especficamente, as
como aquellos en los que un ncleo de seguridad no se ha aplicado. El ltimo
caso
incluye aquellos sistemas en los que el objetivo (c) no es totalmente compatible
porque
del tamao o complejidad del mecanismo de validacin de referencia. Por
conveniencia, estos criterios de evaluacin utilizan el trmino Trusted Computing
Base para
consulte el mecanismo de validacin de referencia, ya sea un kernel de
seguridad,
filtro de seguridad para el usuario, o de todo el sistema informtico de confianza.
El corazn de un sistema informtico de confianza es la Trusted Computing Base
(TCB)
que contiene todos los elementos del sistema responsables de apoyar
la poltica de seguridad y apoyar el aislamiento de objetos (cdigo y datos) en
que la proteccin se basa. Los lmites de la TCB equivalen a la "seguridad
permetro "se hace referencia en alguna literatura seguridad informtica. En
inters
de la proteccin comprensible y mantenible, un TCB debera 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 crtico para la proteccin y debe ser
diseado e implementado tales que los elementos del sistema excluidos de ella
no tiene por qu
ser de confianza para mantener la proteccin. Identificacin de la interfaz y
elementos de la TCB, junto con por lo tanto su funcionalidad correcta forma la
base para la evaluacin.

Para los sistemas de propsito general, la TCB incluir elementos clave de la
sistema operativo y puede incluir todo el sistema operativo. Para incrustado
sistemas, la poltica de seguridad pueden tratar con los objetos de una manera
que es significativa
a nivel de aplicacin en lugar de en el nivel del sistema operativo. Por lo tanto, la
poltica de proteccin se puede hacer cumplir en el software de la aplicacin y no
en
el sistema operativo subyacente. El TCB incluir necesariamente todos aquellos
partes del sistema y software de aplicacin que opera esenciales para la
apoyo a la poltica. Tenga en cuenta que, como la cantidad de cdigo en los
aumentos de TCB,
se hace ms difcil estar seguro de que la TCB refuerza el monitor de referencia
requisitos en todas las circunstancias.
?
6.4 ASEGURAMIENTO
El objetivo de diseo tercer monitor de referencia se interpreta actualmente
como
lo que significa que la TCB "debe ser de la organizacin lo suficientemente simple
y
complejidad a ser sometido a anlisis 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 poblacin de usuarios del sistema) para un sistema particular de
operativa
la aplicacin y el medio ambiente, por lo que tambin deben las seguridades
aumentarse a
corroborar el grado de confianza que se colocar en el sistema. Los

jerarqua de requisitos que se presentan para las clases de evaluacin en el
criterios de evaluacin del sistema informtico de confianza reflejan la necesidad
de que stos
garantas.
Como se discuti en la Seccin 5.3, los criterios de evaluacin requieren un
uniforme
declaracin de la poltica de seguridad que se aplica por cada equipo de
confianza
sistema. Adems, se requiere que se presentar un argumento convincente
eso explica por qu el TCB satisface los dos primeros requisitos de diseo 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 garanta.
Los sistemas a los que se han aadido los mecanismos de aplicacin de
seguridad, en lugar
de los objetivos de diseo fundamentales incorporadas, no son fcilmente
susceptibles de
anlisis 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
Slo mediante la obtencin de resultados de la prueba. Dado que ningn mtodo
de ensayo para algo tan
complejo como un sistema informtico puede ser verdaderamente exhaustiva,
siempre existe la
posibilidad de que un intento de penetracin posterior podra tener xito. Es para
esta razn que tales sistemas deben caer en las clases ms bajas de evaluacin.
Por otro lado, aquellos sistemas que estn diseados y creados para apoyar
los conceptos TCB son ms susceptibles de anlisis y pruebas estructurado.

Oficial
mtodos pueden ser utilizados para analizar la exactitud de su validacin
referencia
mecanismos para hacer cumplir la poltica de seguridad del sistema. Otros
mtodos,
incluyendo argumentos menos formales, se puede utilizar con el fin de
fundamentar sus reclamaciones,
por la integridad de su mediacin acceso y su grado de
manipulaciones resistencia. Ms confianza se puede colocar en los resultados de
este
anlisis y en el rigor de la prueba estructurada que se puede colocar
en los resultados para sistemas menos estructurados de forma metdica. Por
estas razones,
parece razonable concluir que estos sistemas podran utilizarse en
entornos de alto riesgo. Implementaciones exitosas de tales sistemas seran
clasificado de la forma de evaluacin ms altas.
?
6.5 LAS CLASES
Es altamente deseable que exista slo un pequeo nmero de evaluacin global
clases. Tres divisiones principales se han identificado en la evaluacin
criterios con una cuarta divisin reservada para aquellos sistemas que han sido
evaluado y encontrado para ofrecer proteccin de seguridad inaceptable. Dentro
de cada
divisin principal de evaluacin, se encontr que las clases "intermedias" de
confianza
diseo y desarrollo del sistema de manera significativa podran definirse. Estas
clases intermedias han sido designados en los criterios, ya que
identificar los sistemas que:
* Son vistos ofrecer significativamente mejor proteccin y garanta
sistemas de lo que sera que satisfagan los requisitos bsicos para su

clase de evaluacin; y
* No hay razn para creer que los sistemas de la intermedia
clases de evaluacin eventualmente podran evolucionado de tal manera que
satisfaga los requisitos para la prxima evaluacin ms alta
clase.
Excepto dentro de la divisin A que no se prev que adicional "intermedia"
clases de evaluacin que satisfagan las dos caractersticas descritas
anteriormente sern
identificados.
Las distinciones en cuanto a la arquitectura del sistema, la aplicacin de la
poltica de seguridad, y
pruebas de credibilidad entre las clases de evaluacin se han definido de manera
que
el "salto" entre las clases de evaluacin requerira una inversin considerable
de esfuerzo por parte de los ejecutores. Correspondientemente, no se espera que
ser diferenciales significativos de riesgo a que los sistemas de la ms alta
clases de evaluacin sern expuestos.
?
7.0 LA RELACIN ENTRE LA POLTICA Y LOS CRITERIOS
Seccin 1 presenta los requisitos de seguridad fundamentales ordenador y la

seccin 5
presenta los objetivos de control para sistemas informticos de confianza. Ellos
son
requisitos generales, tiles y necesarias, para el desarrollo de todo seguro
sistemas. Sin embargo, en el diseo de sistemas que se utilizarn para procesar
informacin confidencial clasificada u otra, los requisitos funcionales para la

reunin
los Objetivos de Control se vuelven ms especfico. Hay un gran cuerpo de la
poltica
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 informacin federal en general y clasificada
informacin especfica. En esta seccin se presenta extractos pertinentes de
stos
declaraciones de poltica y analiza su relacin con los Objetivos de Control.
Estos extractos son ejemplos para ilustrar la relacin de las polticas de
criterios y pueden no estar completos.
?
7.1 POLTICAS federal estableci
Un nmero importante de las polticas de seguridad informtica 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 tambin detalla una serie
de las leyes federales, las polticas y requisitos pertinentes no se trata ms
a continuacin.
Gua de seguridad para los sistemas de informacin automatizada federales es
proporcionada por el
Oficina de Administracin y Presupuesto. Dos Circulares especficamente
aplicables tienen
ha emitido. OMB Circular No. A-71, Transmisin Memorando N 1, "Seguridad
de Federal de Sistemas de Informacin Automatizado, "[26] dirige cada agencia
ejecutiva
para establecer y mantener un programa de seguridad informtica. 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 creacin de bienestar
fsico,
salvaguardias administrativos y tcnicos necesarios para proteger
adecuadamente
datos confidenciales personales, de propiedad u otros que no estn sujetos a la
seguridad nacional
regulaciones, as como los datos de seguridad nacional ". [26, prr. 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 peridicas para evaluar las fortalezas y controles de actualizacin.
Poco despus
promulgacin de la OMB Circular A-123, la relacin de su control interno
requisitos para la construccin de sistemas informticos seguros fue reconocido.
[4] Aunque no
estipulando controles informticos especficamente, la definicin de Interior
Controles en A-123 deja claro que los sistemas informticos se deben incluir:
"Controles internos - El plan de la organizacin y todos los mtodos y
medidas adoptadas dentro de una agencia para salvaguardar sus recursos,
asegurar la
exactitud y fiabilidad de la informacin, para asegurar la adherencia
leyes, reglamentos y polticas, y promover la operativa
economa y eficiencia. "[27, sec. 4.C]
El asunto de la informacin de seguridad nacional clasificada procesado por ADP

sistemas fue una de las primeras reas dadas preocupacin grave y extensa en
la seguridad informtica. Los documentos de poltica de seguridad informtica
promulgadas como
resultado contiene requisitos generalmente ms especficos y estructurados que
la mayora,
introducido a su vez a una base de autoridad que s proporciona un lugar
claramente
poltica de seguridad de la informacin articulada y estructurada. Esta base,
Ejecutivo
Orden 12356, "Informacin de Seguridad Nacional", establece los requisitos para
el
clasificacin, desclasificacin y la salvaguardia de la "seguridad nacional
informacin "en s. [14]
?
7.2 POLTICAS DOD
Dentro del Departamento de Defensa, se implementan estos requisitos generales
y
ms indicado principalmente a travs de dos vehculos: 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 proteccin de informacin 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
slo para los contratistas manejan informacin clasificada para cualquier
componente del Departamento de Defensa,
sino tambin a los contratistas de otras dieciocho organizaciones federales para
los cuales
el Secretario de Defensa est autorizado para actuar en la prestacin de la

seguridad industrial
servicios. *
______________________________
* Es decir, de la NASA, el Departamento de Comercio, GSA, Departamento de
Estado, la pequea empresa
Administracin, Fundacin Nacional de Ciencias, Departamento del Tesoro,
Departamento de Transporte, Departamento del Interior, Departamento de
Agricultura, EE.UU.
Agencia de Informacin, Departamento de Trabajo, Agencia de Proteccin del
Medio Ambiente, Justicia
Departamento, US Control de Armas y Desarme Agencia Federal Emergency
Agencia de Gestin, Sistema de la Reserva Federal, y la Oficina de Contabilidad
General.
Para los sistemas de ADP, estos requisitos de seguridad de informacin se
amplifican an ms
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 Seccin 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
debern tener proteccin por el empleo continuo de las funciones de proteccin
en
hardware y software de diseo del sistema y la configuracin. . . . "[8,
seg. IV] Adems, se requiere que los sistemas de ADP que "procesar, almacenar,
o utilizar datos clasificados y producir informacin clasificada har, con
fiabilidad razonable, prevenir:
a. Acceso deliberada o inadvertida de material clasificado por
personas no autorizadas, y
b. La manipulacin no autorizada de la computadora y sus asociados

dispositivos perifricos ". [8, sec. I B.3]
Requisitos equivalentes a stas aparecen dentro DoD 5200.28-M [9] y en el
5220.22-M [11].
DoD 5200.28 Directove proporciona los requisitos de seguridad para los sistemas
de ADP. Por
algunos tipos de informacin, como Sensible Informacin Compartmented (SCI),
Directiva DoD 5200.28 establece que los otros requisitos de seguridad mnimos
tambin
aplicar. Estos mnimos se encuentran en DCID l / l6 (nuevo nmero de referencia
5), que es
implementado en DIAM 50-4 (nuevo nmero 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 Poltica de Seguridad, es decir,
obligatoria y
Seguridad discrecional y marcado, as como la rendicin de cuentas y
Control de Aseguramiento de Objetivos, puede ser funcionalmente definido para
el Departamento de Defensa
aplicaciones. La siguiente discusin proporciona ms especificidad en la Poltica
para estos objetivos de control.
?
7.3 CRITERIOS OBJETIVO DE CONTROL PARA LA POLTICA DE SEGURIDAD
7.3.1 Marcado
El objetivo de control para el marcado es: "Los sistemas que estn diseados
para hacer cumplir una poltica de seguridad obligatoria deben almacenar y
conservar la
integridad de clasificacin u otro sensibilidad etiquetas para todos
informacin. 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 proteccin de
Informacin Clasificada ", explica en el prrafo 11 de las razones de
marcando informacin:
"a. General. designacin Clasificacin por fsica
marcado, la notacin u otros medios sirve para advertir y para
informar al titular qu grado de proteccin contra
la divulgacin no autorizada se reqired para que la informacin
o material. "(14)
Requisitos de marcado se dan en una serie de declaraciones polticas.
Orden Ejecutiva 12356 (secciones 1.5.a y 1.5.a.1) requiere que
marcas de clasificacin "se muestran en la cara de todos
documentos clasificados, o claramente asociados con otras formas de
informacin clasificada de una manera adecuada al medio
los involucrados. "[14]
DoD Reglamento 5200.1-R (Seccin 1-500) requiere que: "...
informacin o material que requiere la proteccin contra
la divulgacin no autorizada en inters de la seguridad nacional deber
se clasificarn en una de las tres denominaciones, a saber: 'Top Secret'
"Secreto" o "Confidencial". [7] (Por extensin, para el uso en computadora

procesamiento, la designacin no oficial "Sin clasificacin" se utiliza para
indicar informacin que no cae bajo una de la otra
tres denominaciones de informacin clasificada.)
Reglamento DoD 5200.1-R (Seccin 4-304b) requiere que: "ADP
sistemas y sistemas de procesamiento de textos que emplean tales medios
debern
prever clasificacin interna que marca para asegurar que
informacin clasificada contenida en el mismo que se reproduce o
generado, se har cargo de la clasificacin aplicable y asociados
marcas ". (Este Reglamento establece la exencin de determinadas
sistemas existentes donde "clasificacin 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 informacin sensible.)
DoD 5200.28-M Manual (Seccin 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
clasificacin y de acceso o de difusin 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
polticas definidas para los sistemas que se utilizan para procesar clasifican
u otra informacin sensible categorizado especficamente debe
incluir disposiciones para la aplicacin de control de acceso obligatorio
reglas. Es decir, deben incluir un conjunto de reglas para el control de

de acceso basado directamente en una comparacin de los individuales de
autorizacin o autorizacin para la informacin y la
clasificacin o sensibilidad designacin de la informacin es
buscado, e indirectamente en consideraciones de fsica y otro
factores ambientales de control. El control de acceso obligatorio
reglas deben reflejar con precisin las leyes, reglamentos, y general
las polticas de las que se derivan ".
Hay una serie de declaraciones polticas que se relacionan con
seguridad obligatoria.
Orden Ejecutiva 12356 (seccin 4.1.a) establece que "una persona es
elegibles para el acceso a la informacin clasificada a condicin de que un
determinacin de la confiabilidad ha sido hecha por los jefes de agencias o
designado funcionarios y siempre que dicho acceso es esencial
a la realizacin de Gobierno legal y autorizada
fines ". [14]
Reglamento DoD 5200.1-R (Captulo I, Seccin 3) define un Especial
Programa de Acceso como "cualquier programa de imponer la necesidad de
conocer o acceso
controles ms all de las prestaciones realizadas normalmente por el acceso
a
Informacin secreta confidencial, secreta o Superior. Tal programa
incluye, pero no se limita a, una autorizacin especial, adjudicacin,
o requerimientos de investigacin, la designacin especial de funcionarios
listas autorizadas para determinar la "necesidad de conocer", o especiales
de las personas
decidido a tener un 'know-a-necesidad.' "[7, prr. 1-328] Este
pasaje distingue entre una determinacin 'discrecional' de
necesita-a-saber y que se implementa a travs de necesidad-a-saber

formales
Programas especiales de acceso. DoD Reglamento 5200.1-R, prrafo 7-100
describe los requisitos generales para la fiabilidad (depuracin) y
necesita-a-saber, y afirma que la persona con la posesin,
conocimiento ni control de la informacin clasificada tiene definitiva
la responsabilidad de determinar si las condiciones de acceso han sido
reuni. Este reglamento establece adems que "nadie tiene un derecho
a tener acceso a informacin clasificada nicamente en virtud de rango
o posicin ". [7, prr. 7-100])
DoD 5200.28-M Manual (Seccin II 2-100) afirma que, Personal "
que desarrollan, de prueba (depuracin), mantener o utilizar programas que
son
clasificadas o que se utilizar para acceder o desarrollar clasificado
material deber tener una autorizacin de seguridad del personal y de un
acceso
autorizacin (necesidad de saber), segn corresponda a la ms alta
categora clasificada y ms restrictivo de material clasificado
que van a acceder a virtud de las limitaciones del sistema ". [9]
DoD 5220.22-M Manual (3.a prrafo) define el acceso como "el
la capacidad y la oportunidad de obtener conocimiento del clasificado
informacin. Un individuo, de hecho, puede tener acceso a
informacin clasificada por estar en un lugar donde dicha informacin
se mantiene, si las medidas de seguridad que estn en vigor no lo hacen
le impidi ganar conocimiento del clasificado
informacin ". [11]
Lo anterior Orden Ejecutiva, Manual, Directivas y
Reglamento implica claramente que un sistema informtico de confianza

debe
aseguran que las etiquetas de clasificacin asociados con sensibles
los datos no se pueden cambiar arbitrariamente, ya que esto podra permitir
las personas que carecen de la adecuada habilitacin para el acceso
informacin clasificada. Tambin implcita es el requisito de que un
sistema informtico de confianza debe controlar el flujo de informacin a fin
de
que los datos de una clasificacin superior no puede ser colocado en una
almacenamiento de objetos de la clasificacin ms baja a menos que su
"degradacin"
ha sido autorizado.
7.3.3 Seguridad Discrecional
El trmino se refiere a la seguridad discrecional de un sistema informtico
capacidad de controlar la informacin 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 informacin clasificada especfica, cada
uno
el acceso del individuo a la informacin 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 explcitos en afirmar que la
necesita-a-saber de prueba debe ser satisfecha antes de que pueda
concederse el acceso
a la informacin clasificada. El objetivo de control para
seguridad discrecional es: "Las polticas de seguridad definida para los
sistemas
que se utilizan para procesar informacin sensible clasificada u otro
debe incluir disposiciones para la aplicacin 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
informacin ".
DoD Reglamento 5200.1-R (Prrafo 7-100) Adems de extractos
ya condicin de que toque en la necesidad-to-know, esta seccin de la
regulacin destaca el principio de menor dominio a-saber cuando afirma "no
persona puede tener acceso a informacin clasificada a menos. . .
el acceso es necesario para el desempeo de funciones oficiales ". [7]
Tambin, DoD 5220.22-M Manual (Seccin III 20.a) establece que "una
se le permitir individuo a tener acceso a clasificado
slo informacin . . . cuando el contratista determina que el acceso
es necesaria en el desempeo 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 RENDICIN DE CUENTAS OBJETIVO DE CONTROL
El objetivo de control para la rendicin de cuentas es: "Los sistemas que se
utilizan para procesar
o el tirador clasificado u otra informacin sensible debe asegurar individuo
la rendicin de cuentas cada vez que sea una poltica de seguridad obligatoria o
discrecional es
invocado. Adems, para asegurar la rendicin de cuentas de la capacidad debe
existir para
un agente autorizado y competente para acceder y evaluar la rendicin de
cuentas
la informacin 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 (Seccin V 5-100) afirma: "Un registro de auditora o
archivo
(manual, mquina, o una combinacin de ambos) se mantendrn como
historia de la utilizacin del Sistema de ADP para permitir una revisin 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 produccin de cuentas
clasificado
salidas, y la creacin de nuevos archivos clasificados. Cada archivo clasificado
visitada xito [con independencia del nmero de referencias individuales]
durante cada "trabajo" o "sesin interactiva tambin deben registrarse en el
registro de auditora. Gran parte del material de este registro tambin se
puede requerir a
asegurar que el sistema conserva la informacin confiada a l). "[9]
DoD 5200.28-M Manual (Seccin 4-305f IV) declara: "Cuando sea necesario
para asegurar
el control de acceso y la responsabilidad individual, cada usuario o especfica
grupo de usuarios se identificar al Sistema ADP idneas
administrativas o de hardware / software. Dicha identificacin
medidas deben ser lo suficientemente detallada para permitir que el sistema
de ADP para proporcionar
el usuario slo que el material que est autorizado. "[9]
DoD 5200.28-M Manual (Seccin I 1-102b) declara:

Autoridades "de componentes designados aprobar, o sus representantes
para este propsito . . . asegurar:
.................
(4) El mantenimiento de la documentacin de los sistemas operativos (O /
S)
y todas las modificaciones a los mismos, y su retencin por un
periodo de tiempo suficiente para habilitar el seguimiento de seguridaddefectos relacionados a su punto de origen o su inclusin en el
sistema.
.................
(6) El establecimiento de procedimientos para descubrir, recuperar,
manejar y disponer de material clasificado incorrectamente
dado a conocer a travs de mal funcionamiento del sistema o el personal
de la accin.
(7) la disposicin adecuada y la correccin de la seguridad
deficiencias en los sistemas de ADP todos aprobados, y la efectiva
uso y disposicin de los registros de limpieza del sistema o de auditora,
registros de violacines 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 (Seccin XIII 111) afirma: "Audit Trails
a. El requisito de seguridad general para cualquier auditora del sistema

ADP
sendero es que proporciona una historia documentada de la utilizacin de
el sistema. Una pista de auditora aprobado permitir la revisin de
la actividad del sistema clasificada y proporcionar una detallada
registro de actividad para facilitar la reconstruccin de eventos para
determinar la magnitud de compromiso (si existe) debe una
produce un mal funcionamiento de la seguridad. Para cumplir con este
bsico
requisito, los sistemas de seguimiento de auditora, manual, automtico o
una
combinacin de ambos debe documentar eventos importantes
que ocurre en las siguientes reas de inters: (i) la preparacin
de los datos de entrada y difusin 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 modificacin personal de apoyo de la seguridad y
controles relacionados), y (iii) la actividad interna de la mquina.
b. La pista de auditora para un sistema ADP aprobado para procesar
informacin 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 mayora, si no todos los registros de seguimiento de auditora se
enumeran a continuacin. Los
documentacin 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
iniciacin seguridad de los sistemas pertinentes y eventos de terminacin
(por ejemplo, la actualizacin / acciones degradar conformidad con el
prrafo
107);
4. Todas las funciones iniciados por la consola del sistema ADP
operadores;
5. Desconecta de terminales remotos y perifricos
dispositivos (prrafo 107C);
6. Iniciar sesin en y desconexin 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 anomalas incluyendo
informacin de identificacin (es decir, el usuario / nombre del programa,
el tiempo
y la ubicacin del incidente, etc.);
9. hardware Sistema de adiciones, supresiones y mantenimiento
acciones;
10. Generaciones y modificaciones que afectan a la
caractersticas 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 auditora al menos semanalmente

para asegurar que
toda la actividad pertinente se registra correctamente y que
las medidas adecuadas se ha tomado para corregir cualquier anomala.
La mayora de los sistemas de ADP en uso hoy en da se puede desarrollar
la auditora
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 tcticos y de
visualizacin,
puede no ser capaz de cumplir con todos los aspectos de lo anterior y
puedan exigir una atencin individualizada por el consciente
Oficina de seguridad.
d. Los registros de seguimiento de auditora se conservarn durante un
perodo de un
ciclo de inspeccin. "[11]
?
7.5 CRITERIOS OBJETIVOS DE CONTROL DE ASEGURAMIENTO
El objetivo de control para la garanta es: "Los sistemas que se utilizan para
procesar o
mango clasificado u otra informacin sensible debe estar diseado para
garantizar
interpretacin correcta y precisa de la poltica de seguridad y no debe
distorsionar
la intencin de esta poltica. Aseguramiento de que el producto correcto
existe aplicacin y el funcionamiento de la poltica en todo el sistema de
ciclo de la vida."
A base de este objetivo se puede encontrar en las siguientes secciones del
Directiva 5200.28:
Directiva DoD 5200.28 (IV.B.1) estipula: "En general, la seguridad de un ADP
sistema es ms eficaz y econmica si el sistema est diseado
originalmente para proporcionarla. Cada Departamento de Defensa de
componentes
emprender el diseo de un sistema de ADP, que se espera para procesar,
almacenar,
utilizar o producir material clasificado deber: Desde el inicio de la
proceso de diseo, tener en cuenta las polticas 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 proteccin
requerido para la categora de clasificacin 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 manipulacin no autorizada de la
sistema y sus componentes. Se prestar especial atencin a la
la proteccin continua de las medidas de seguridad del sistema automatizado,
tcnicas
y procedimientos cuando el nivel de autorizacin 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
informacin en el sistema, o daos en el sistema ". [8]
DoD 5200.28-M Manual (Seccin I 1-102b) declara:

Autoridades "de componentes designados aprobar, o sus representantes
para este propsito . . . asegurar:
.................
(5) La supervisin, monitoreo y pruebas, segn proceda, de
cambios en un sistema de ADP aprobado que pudieran afectar a la
caractersticas de seguridad del sistema, por lo que un sistema seguro es
mantenido.
.................
(7) la disposicin adecuada y la correccin de la seguridad
deficiencias en los sistemas de ADP todos aprobados, y la efectiva
uso y disposicin de los registros de limpieza del sistema o de auditora,
registros de violacines 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) Realizacin de sistema competente ST & E, la revisin oportuna de
sistema de ST & E informes, y la correccin de las deficiencias necesarios
para apoyar la aprobacin o desaprobacin condicional o definitiva de
un Sistema de ADP para el procesamiento de la informacin clasificada.
(9) El establecimiento, en su caso, de un centro de ST & E
punto de coordinacin para el mantenimiento de registros de
tcnicas seleccionadas, procedimientos, estndares y pruebas utilizadas
en las pruebas y evaluacin de las caractersticas de seguridad de ADP

Sistemas que pueden ser adecuados para la validacin y el uso de
otra Departamento de Componentes de Defensa ". [9]
Manual DoD 5220.22-M (Seccin XIII 103a) exige que: "la aprobacin inicial,
por escrito, de la oficina de seguridad consciente antes de procesar cualquier
informacin clasificada en un sistema de ADP. Esta seccin requiere
reaprobacin por la oficina de seguridad consciente de los sistemas
principales
modificaciones hechas con posterioridad a la aprobacin inicial. Reapprovals
sern
requerido por (i) cambios importantes en los requisitos de acceso de personal,
(ii) reubicacin o modificacin estructural de la computadora central
instalacin, (iii) adiciones, supresiones o cambios de marco principal,
almacenamiento o
dispositivos de entrada / salida, (iv) los cambios de software del sistema de
seguridad impactando
caractersticas de proteccin, (v) cualquier cambio en el aclaramiento,
desclasificacin, la auditora
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 garanta, la garanta 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
(Seccin F.2.C. (2)) requiere "evaluaciones de la industria seleccionada y
gobierno-desarrollado sistemas informticos de confianza en contra de estos
criterios ". [10]
?
8.0 Una directriz sobre canales encubiertos
Un canal secreto es cualquier canal de comunicacin que puede ser explotado

por una
proceso para transferir informacin de una manera que viole el sistema de
politica de seguridad. Hay dos tipos de canales: canales encubiertos
almacenamiento y
canales de distribucin. Canales de almacenamiento Covert incluir todos los
vehculos que lo hara
permitir que la escritura directa o indirecta de una ubicacin de almacenamiento
por un proceso y
la lectura directa o indirecta de la misma por otro. Canales de temporizacin
Covert
incluir todos los vehculos que permitan un proceso a la seal de informacin a
otro proceso mediante la modulacin 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
proporcionara
informacin.
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 tcnicas utilizadas para reducir el ancho de banda por
debajo de una cierta tasa
(que depende del mecanismo de canal especfico y la arquitectura del sistema)
tambin 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
estara presente en cualquier sistema informtico multinivel contiene clasificada

o
informacin sensible, tales sistemas no debe contener canales encubiertos con
altos anchos de banda. Esta gua 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 informtico "seguro" si la informacin se puede
comprometer a un ritmo
igual a la velocidad de salida normal de algn dispositivo de uso comn.
En cualquier sistema informtico multinivel hay una serie de relativamente
bajo ancho de banda canales encubiertos cuya existencia est profundamente
arraigado en la
diseo 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
mxima de menos
de un (1) bits por segundo son aceptables en la mayora de entornos de
aplicacin.
Aunque mantiene un rendimiento aceptable en algunos sistemas puede hacer
que sea
poco prctico para eliminar todos los canales encubiertas con anchos de banda
de 1 o ms bits
por segundo, es posible auditar su uso sin afectar adversamente
rendimiento de sistema. Esta capacidad de auditora proporciona la
administracin del sistema
con un medio de deteccin - correccin 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 razn 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 configuracin de funciones control de acceso
obligatorio
El requisito de control de acceso obligatorio incluye una capacidad para apoyar

una
nmero no especificado de las clasificaciones jerrquicas y un nmero no
especificado
de categoras no jerrquicas en cada nivel jerrquico. Para fomentar
coherencia y la transferibilidad en el diseo y desarrollo de la National
Establecimiento de Seguridad de los sistemas informticos de confianza, es
deseable para todos tales
sistemas para ser capaz de soportar un nmero mnimo de niveles y categoras.
Los
siguientes sugerencias se proporcionan para este propsito:
* El nmero de clasificaciones jerrquicas debe ser mayor o
igual a diecisis (16).
* El nmero de categoras no jerrquicas debe ser mayor o
igual a sesenta y cuatro (64).
?
10.0 Una GUA SOBRE LAS PRUEBAS DE SEGURIDAD
Estas directrices se proporcionan para dar una indicacin de la extensin y

sofisticacin de la prueba llevada a cabo por el Centro de seguridad de
computadoras del Departamento de Defensa
durante el proceso de evaluacin formal del producto. Las organizaciones que
deseen utilizar
"Departamento de Defensa Trusted Computer System Evaluation Criteria" para
realizar sus propias evaluaciones puede encontrar esta seccin til para la
planificacin
propsitos.
Como en la primera parte, el resaltado se utiliza para indicar los cambios en las
pautas de
la categora inmediatamente inferior.
?
10.1 ENSAYO DE LA DIVISIN 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 Computacin 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 "hiptesis de falla" o garanta equivalente
probar la metodologa, y tendrn la programacin a nivel de montaje
experiencia. Antes de que comience la prueba, los miembros del equipo
tendrn
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" participacin en una carrera independiente
de las pruebas utilizadas por el desarrollador del sistema. El equipo deber
independientemente disear y poner en prctica especfica 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 prctica en horas pasadas realizacin de sistema
pruebas para desarrolladores definidos y pruebas de equipos definidos de
prueba.
?
10.2 ENSAYO DE LA DIVISIN 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 Computacin o la
equivalente y al menos una persona con un grado de maestra 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, debern estar familiarizados con la "hiptesis de falla" o
metodologa de las pruebas de seguridad equivalente, deber ser fluido en
el
TCB lenguaje de implementacin (s), y tendr nivel de ensamblado
experiencia en programacin. 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
del paquete de prueba utilizado por el desarrollador del sistema para probar
hardware y software de seguridad pertinentes. El equipo deber
independientemente disear e implementar por lo menos quince sistemapruebas especficas en un intento de eludir la seguridad
mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas
ser como mnimo 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 realizacin de pruebas para desarrolladores definidas por
el sistema y
prueba de equipo define pruebas.
?
10.3 ENSAYO DE LA DIVISIN 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 Computacin o la
equivalente y al menos dos personas con grados de maestra 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, debern estar familiarizados con la "hiptesis de falla" o
metodologa de las pruebas de seguridad equivalente, deber ser fluido en
el
TCB lenguaje de implementacin (s), y tendr nivel de ensamblado
experiencia en programacin. 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
diagnstico
los programas y la documentacin de soporte de hardware. Al menos dos
los miembros del equipo debern haber realizado previamente una prueba
de seguridad en
otro sistema. Al menos un miembro del equipo tendr
competencia de programacin a nivel de sistema demostrado en el sistema
bajo prueba a un nivel de complejidad equivalente a la adicin de un
dispositivo
controlador al sistema.
10.3.2 Prueba
del paquete de prueba utilizado por el desarrollador del sistema para probar
hardware y software de seguridad pertinentes. El equipo deber
independientemente disear e implementar al menos veinticinco sistemapruebas especficas en un intento de eludir la seguridad
mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas
ser como mnimo 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 realizacin de pruebas para desarrolladores definidas por
el sistema y
prueba de equipo define pruebas.
?
APNDICE A
PROCESO DE EVALUACIN PRODUCTO COMERCIAL
"Departamento de Defensa Trusted Computer System Evaluation Criteria" forma

la
base sobre la que el Centro de Seguridad Informtica realizar el anuncio
proceso de evaluacin de la seguridad informtica. Este proceso se centra en el
comercio
de propsito general productos producidos y apoyados sistema operativo que
cumplen con la
necesidades de los departamentos y agencias gubernamentales. La evaluacin
formal se dirige
en "off-the-shelf" comercialmente apoyado productos y est completamente
divorciado
de cualquier consideracin de rendimiento general del sistema, las aplicaciones
potenciales,
o entornos de procesamiento particulares. La evaluacin proporciona un insumo
clave para
una seguridad del sistema informtico de aprobacin / acreditacin. Sin embargo,
no lo hace
constituyen una evaluacin completa seguridad del sistema informtico. 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

operacin, usuarios especficos, aplicaciones, la sensibilidad de datos, fsica y
la seguridad personal, administrativo y de seguridad procesal, tempestad, y
seguridad de las comunicaciones.
El proceso de evaluacin del producto realizado por el Centro de Seguridad
Informtica tiene
tres elementos distintos:
* Evaluacin preliminar del producto - Un dilogo informal entre un vendedor
y el Centro en el que se intercambia informacin tcnica para crear un
entendimiento comn de producto del proveedor, los criterios y el
calificacin que se puede esperar que el resultado de una evaluacin formal
del producto.
* Evaluacin formal Producto - Una evaluacin 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 calificacin asignada se coloca en la Lista de Productos evaluadas.
* Lista evaluadas Productos - Una lista de los productos que han sido
sometidos
para la evaluacin del producto formal y sus calificaciones asignadas.
Evaluacin Preliminar del producto

Puesto que es generalmente muy difcil aadir 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 diseo de producto. Un producto
preliminar
evaluacin permite al Centro de consultar con los proveedores de equipo en

equipo
los problemas de seguridad que se encuentran en productos que an no se han
anunciado formalmente.
Una evaluacin preliminar se inicia tpicamente por los vendedores de sistemas
informticos que
estn planeando nuevos productos informticos que cuentan con la seguridad o
importante
actualizaciones relacionadas con la seguridad de los productos existentes.
Despus de una reunin 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 informacin revelada a l. Reuniones de intercambio tcnicos
siguen
en el que el vendedor ofrece detalles sobre el producto propuesto (en particular,
sus diseos internos y metas) y el Centro proporciona retroalimentacin de
expertos para la
vendedor en posibles puntos fuertes y dbiles del proveedor de seguridad
informtica
disear opciones, as como la interpretacin de los criterios relevantes. Los
evaluacin preliminar se termina tpicamente cuando se completa el producto
y listo para el lanzamiento de campo por el vendedor. Tras la rescisin, el Centro
prepara un informe de finalizacin para el vendedor y para la distribucin interna
dentro
el centro. Estos informes contienen informacin de propiedad no son
a disposicin del pblico.
Durante la evaluacin preliminar, el vendedor no tiene ninguna obligacin de
realidad
completar o comercializar el producto potencial. El Centro es, del mismo modo,
no
comprometido a llevar a cabo una evaluacin formal del producto. Una
evaluacin 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
evaluacin.
Evaluacin del producto Formal

La evaluacin formal producto proporciona un insumo clave para la certificacin
de un
sistema informtico 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 evaluacin 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 acompaar
la documentacin necesaria para cumplir los requisitos definidos en la presente
publicacin son
completa. Acuerdos de no divulgacin se ejecutan y un producto oficial
equipo de evaluacin est formado por el Centro. Una primera reunin se celebr
a continuacin, con
el vendedor para trabajar el horario para la evaluacin formal. Desde pruebas
del producto aplicado forma una parte importante del proceso de evaluacin,
Acceso por el equipo de evaluacin a una versin de trabajo del sistema se
negocia
con el vendedor. El apoyo adicional requerido por parte del proveedor incluye
documentacin completa de diseo, cdigo fuente, y el acceso al personal de los
proveedores que
puede responder a preguntas detalladas sobre partes especficas del producto.
Los
equipo de evaluacin 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 evaluacin redacta un informe final sobre sus hallazgos sobre el
sistema.
El informe est disponible al pblico (que no contiene propietaria o confidencial
informacin) y contiene la calificacin global de clase asignado al sistema y
los detalles de los resultados del equipo del evalution al comparar el producto
contra
los criterios de evaluacin. Informacin detallada sobre vulnerabilidades
encontradas
por el equipo de evaluacin est amueblado a los desarrolladores de sistemas y
diseadores como
cada uno se encuentra para que el vendedor tiene la oportunidad de eliminar el
mayor nmero de ellos como
posible antes de la finalizacin de la evaluacin formal del producto.
Anlisis de vulnerabilidad y otra informacin confidencial o sensible son
controlada dentro del Centro a travs del Programa de Informacin y
Vulnerabilidad
se distribuyen nicamente en el Gobierno de Estados Unidos en una necesidad
de conocer-estricto y
no divulgacin base, y para el vendedor.?
ANEXO B
RESUMEN DE LAS DIVISIONES criterios de evaluacin
Las divisiones de los sistemas reconocidos en el sistema informtico de confianza

criterios de evaluacin son los siguientes. Cada divisin representa un importante
mejora en la confianza general se puede colocar en el sistema para proteger
informacin confidencial clasificada y otra.
Divisin (D): Proteccin Mnimo
Esta divisin 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 evaluacin.
Divisin (C): Proteccin Discrecional
Las clases de esta divisin prevn (necesidad de conocer) la proteccin
discrecional
y, a travs de la inclusin de mecanismos de auditora, para la rendicin de
cuentas
temas y las acciones que inician.
Divisin (B): Proteccin obligatoria
La nocin 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 divisin. Sistemas de esta divisin deben llevar el
sensibilidad etiquetas con las principales estructuras de datos en el sistema. El
sistema
desarrollador tambin ofrece el modelo de la poltica de seguridad en la que se
basa la TCB
y proporciona una especificacin de la TCB. La evidencia debe ser proporcionada
a
demostrar que el concepto de monitor de referencia ha sido implementado.
Divisin (A): Proteccin Verified
Esta divisin se caracteriza por el uso de la verificacin de seguridad formal
mtodos para asegurar que los controles de seguridad obligatorios y
discrecionales
empleado en el sistema puede proteger eficazmente clasificado u otro sensible
informacin almacenada o procesada por el sistema. Amplia documentacin es
requerida para demostrar que la TCB cumple con los requisitos de seguridad en
todo
aspectos de diseo, desarrollo e implementacin.
?
ANEXO C
RESUMEN DE LAS CLASES DE CRITERIOS DE EVALUACIN
Las clases de sistemas reconocidos en la evaluacin del sistema informtico de

confianza
criterios son los siguientes. Se presentan en el orden creciente de
desirablity desde un punto de vista de la seguridad informtica.
Clase (D): Proteccin Mnimo
Esta clase est reservada para aquellos sistemas que han sido evaluados, sino
que
no cumplen con los requisitos para una clase de evaluacin superior.
Clase (C1): Proteccin Seguridad Discrecional
La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente
satisface
los requisitos de seguridad discrecionales al proporcionar separacin de usuarios
y
datos. Incorpora alguna forma de controles crebles, 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 informacin privada
y
mantener a los dems usuarios de la lectura de forma accidental o la destruccin
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 ms de grano fino
usuarios de control de sistemas (C1), por lo que individualmente responsables de
su
acciones a travs de los procedimientos de acceso, la auditora de los eventos
relevantes para la seguridad, y
aislamiento de recursos.
Clase (B1): Etiquetado de Proteccin de la Seguridad
Sistemas (B1) Clase requieren todas las caractersticas requeridas para la clase
(C2). En
Adems, una declaracin informal de la modelo de la poltica 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 precisin la informacin exportada.
Alguna
defectos identificados por pruebas deben ser removidos.
Clase (B2): Proteccin Estructurado
En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y
documentado
modelo de poltica de seguridad formal que requiere el discrecional y obligatorio
la aplicacin 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. Adems, los canales encubiertos son
abordarse. El TCB debe estructurarse con cuidado en la proteccin-crtico y
elementos de proteccin crtico no. La interfaz de TCB est bien definido y de la

Diseo e implementacin TCB permiten que pueda ser sometido a ms
exhaustiva
pruebas y revisin ms completa. Mecanismos de autenticacin se fortalecen,
la gestin de instalaciones de confianza se proporciona en forma de soporte para
el sistema
funciones de administrador y operador, y gestin de la configuracin estrictas
se imponen controles. El sistema es relativamente resistente a la penetracin.
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
pequeo
suficiente para ser sometidos a anlisis y pruebas. Para este fin, la TCB es
estructurado para excluir el cdigo no es esencial para la aplicacin de la poltica
de seguridad, con
ingeniera de sistemas significativa durante el diseo y la aplicacin dirigida TCB
para minimizar su complejidad. Un administrador de seguridad es compatible,
mecanismos de auditora se expanden para sealar acontecimientos seguridadpertinentes, y el sistema
se requieren procedimientos de recuperacin. El sistema es altamente resistente
a
penetracin.
Clase (A1): Diseo Verified
Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3)
en
que no se aaden caractersticas arquitectnicas adicionales o requisitos de la
poltica.
La caracterstica distintiva de los sistemas de esta clase es el anlisis derivado
desde la especificacin de diseo formal y tcnicas de verificacin 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 poltica de seguridad y una especificacin de alto nivel formales (FTLs) del
diseo. En
consonancia con el anlisis extenso diseo y desarrollo de la TCB requerido
de los sistemas de la clase (A1), se requiere la administracin de configuracin
ms estricta
y se establezcan procedimientos para distribuir de forma segura el sistema a los
sitios.
Un administrador de la seguridad del sistema es compatible.
?
APNDICE D
DIRECTORIO REQUISITO
Este apndice enumera los requisitos definidos en el "Departamento de Defensa

Trusted
Computer System Evaluation Criteria "alfabticamente en lugar de por clase. It
se proporciona para ayudar en el seguimiento de la evolucin de un requisito a
travs 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 especficos ya se ha dicho
criterios.
ADD: Los criterios que siguen no han sido requeridos para cualquier
clase baja, y se aaden 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 pictrico de la evolucin de las necesidades a
travs de
las clases.
Auditora
C1: NR.
C2: NUEVO: La TCB ser capaz de crear, mantener y proteger de la
modificacin o acceso no autorizado o la destruccin de una pista de
auditora de
accesos a los objetos que protege. Los datos de auditora debern ser
protegida por el TCB de manera que a ella se limita a aquellos acceso de
lectura
que estn autorizados para los datos de auditora. El TCB deber ser capaz
de grabar
los siguientes tipos de eventos: uso de identificacin y

mecanismos de autenticacin, introduccin de objetos en un usuario de
espacio de direcciones (por ejemplo, abrir el archivo, la iniciacin del
programa), la supresin 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 auditora,
identificar: fecha y hora del evento, el usuario, el tipo de evento, y el xito
o el fracaso del evento. Para eventos de identificacin / autenticacin las
origen de la solicitud (por ejemplo, la terminal ID) se incluir en la auditora
rcord. Para los eventos que introducen un objeto en la direccin de un
usuario
espacio y para los eventos de delecin objeto el registro de auditora
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 ms usuarios
en funcin de
identidad individual.
B1: CAMBIO: Para los eventos que introducen un objeto en la direccin de un
usuario
espacio y para los eventos de delecin objeto el registro de auditora
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 ms usuarios en base a la identidad y / o objeto
individual
nivel de seguridad.
ADD: El TCB tambin podr auditar cualquier anulacin de
marcas de salida legibles.
B2: ADD: El TCB podr auditar los eventos identificados que pueden ser
utilizado en la explotacin de canales de almacenamiento encubiertas.
B3: ADD: El TCB deber contener un mecanismo que es capaz de controlar la
aparicin o acumulacin de eventos auditables de seguridad que puedan
indicar una violacin inminente de la poltica de seguridad. Este mecanismo
ser capaz de notificar inmediatamente al administrador de seguridad
cuando
umbrales se exceden, y, si la ocurrencia o la acumulacin de
estos eventos relevantes de seguridad contina, el sistema tomar la
arrendar accin disruptiva para terminar el evento.
A1: NAR.
Gestin de la Configuracin
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: Durante el desarrollo y mantenimiento de la TCB, una
configuracin
sistema de gestin ser en el lugar que mantiene el control de cambios
a la memoria descriptiva de nivel superior, otros datos de diseo,
documentacin de la aplicacin, el cdigo fuente, la versin de
funcionamiento de la
cdigo objeto, y accesorios de la prueba y la documentacin. La
configuracin
sistema de gestin deber asegurar una correspondencia constante entre
todos
documentacin y cdigo asociado con la versin actual de la TCB.
Herramientas se proporcionan para la generacin de una nueva versin de

la TCB
desde el cdigo fuente. Tambin disponible sern herramientas para la
comparacin de una
versin con la versin anterior TCB recin generado con el fin de
asegurarse de que slo los cambios previstos se han hecho en el cdigo
que realmente se utiliza como la nueva versin de la TCB.
B3: NAR.
A1: CAMBIO: Durante todo el ciclo de vida, es decir, durante el diseo,
desarrollo y mantenimiento de la TCB, una gestin de la configuracin
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 diseo
de datos, documentacin aplicacin, cdigo fuente, la versin que se
ejecuta
del cdigo objeto, y accesorios de la prueba y la documentacin. Tambin
disponibles sern herramientas, mantenidos bajo estricta configuracin
control, para comparar una versin recin generado con el anterior
Versin TCB, a fin de asegurarse de que slo los cambios previstos tienen
ha logrado en el cdigo que realmente se utiliza como la nueva versin
del TCB.
ADD: Una combinacin de tcnicas, fsicas y de procedimiento
se utilizar para proteger de la modificacin no autorizada o
la destruccin de la copia maestra o copias de todo el material utilizado
para
generar la TCB.
Anlisis Canal Covert
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: El desarrollador del sistema llevar a cabo una bsqueda
exhaustiva para encubierta
canales de almacenamiento y hacer una determinacin (ya sea por real
medicin o por estimacin de ingeniera) del ancho de banda mximo de
cada canal identificado. (Vea la seccin de Orientacin Canales Covert.)
B3: CAMBIO: El desarrollador del sistema llevar a cabo una bsqueda
exhaustiva para
canales encubiertos y tomar una determinacin (ya sea por real
medicin o por estimacin de ingeniera) del ancho de banda mximo
de cada canal identificado.
A1: ADD: mtodos formales se utilizan en el anlisis.
Diseo Documentacin
C1: NUEVO: La documentacin debe estar disponible que proporciona una
descripcin de
La filosofa de los fabricantes de proteccin y una explicacin de cmo
esta filosofa se traduce en la TCB. Si el TCB se compone
de mdulos distintos, las interfaces entre estos mdulos sern
descrito.
C2: NAR.
B1: ADD: Una descripcin informal o formal del modelo de la poltica de
seguridad
forzada por la TCB estarn disponibles y una explicacin proporcionada a

muestran que es suficiente para hacer cumplir la poltica de seguridad. Los
mecanismos especficos de proteccin TCB se identificarn y un
explicacin dada para demostrar que satisfacen el modelo.
B2: CAMBIO: Las interfaces entre los mdulos de TCB se describirn. LA
descripcin formal del modelo de poltica de seguridad aplicada por el TCB
debern estar disponibles y demostrado que es suficiente para cumplir la
politica de seguridad.
ADD: La especificacin de alto nivel descriptivo (DTLS) se muestra a
ser una descripcin exacta de la interfaz de TCB. Documentacin
describen cmo la TCB implementa el concepto monitor de referencia y
dar una explicacin de por qu se resistente a la manipulacin, no puede
ser anulada,
y se ha implementado correctamente. La documentacin debe describir
cmo el
TCB est estructurado para facilitar las pruebas y hacer cumplir menos
privilegio. Esta documentacin deber presentar tambin los resultados de
la
anlisis de canal encubierta y las compensaciones implicadas en la
restriccin de la
canales. Todos los eventos auditables que se pueden utilizar en la
explotacin
se identificarn 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 auditora, se facilitar. (Vea el Covert
Seccin de Orientacin del canal.)
B3: ADD: La aplicacin 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 indicarn, utilizando tcnicas informales,
para corresponder a los elementos de la TCB.
A1: CAMBIO: La aplicacin TCB (es decir, en el hardware, firmware y
software) se indicar de manera informal para ser coherente con lo formal
especificacin de nivel superior (FTLs). Los elementos de los FTLs sern
se muestra, usando tcnicas 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
cartogrficos,
Acceso directo a la memoria de E / S) se describirn con claridad.
Especificaciones de Diseo y Verificacin
C1: NR.
C2: NR.
B1: NUEVO: Un modelo formal o informal de la poltica 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 poltica de seguridad con el apoyo de la
TCB
se mantendrn 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 trminos

de excepciones, mensajes de error y efectos. Queda demostrado ser
una descripcin 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 descripcin exacta de la
Interfaz de TCB. Un argumento convincente se dar de que el DTLS es
consistente con el modelo y una combinacin de formal e informal
se emplearn tcnicas para demostrar que el FTLs es consistente con la
modelo.
ADD: Una especificacin de alto nivel formales (FTLs) del TCB ser
sostenido que describe con precisin la TCB en trminos de excepciones,
mensajes de error, y efectos. Los DTLS y FTLs incluirn 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 verificacin deber ser coherente con la prevista en
el estado-del-arte de lo particular Center- Seguridad Informtica
especificacin formal avalado y sistema de verificacin utilizados. Manual
u otro mapeo de las FTLs al cdigo fuente TCB ser
realizado para proporcionar evidencia de la implementacin correcta.
Las etiquetas de dispositivo
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB apoyar la asignacin de mnimo y mximo

niveles de seguridad a todos los dispositivos fsicos conectados. Estos
seguridad
niveles sern utilizados por el TCB para hacer cumplir las limitaciones
impuestas por
el entorno fsico 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 aplicacin (por ejemplo, auto / grupo / controles pblicos, el
acceso
listas de control) debern 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 aplicacin (por ejemplo, auto / grupo / controles
pblicos,
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 proporcionarn los controles para limitar
propagacin de los derechos de acceso.
ADD: El mecanismo de control de acceso discrecional deber, ya sea explcita
accin del usuario o por defecto, se establece que los objetos estn
protegidos de
Acceso no autorizado. Estos controles de acceso debern 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 slo se asignar por usuarios autorizados.
B1: NAR.
B2: NAR.
B3: CAMBIO: El mecanismo de aplicacin (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 propagacin de los derechos de
acceso. Estas
controles de acceso debern 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.
Exportacin de informacin Etiquetada
C1: NR.
C2: NR.
B1: NUEVO: La TCB designar cada canal de comunicacin y E / S

dispositivo, ya sea a nivel individual o de mltiples niveles. Cualquier
cambio en esta
designacin 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 comunicacin o
B2: NAR.
B3: NAR.
A1: NAR.
Exportacin a dispositivos multinivel
C1: NR.
C2: NR.
B1: NUEVO: Cuando la TCB exporta un objeto a un dispositivo de E / S de
mltiples niveles, la
etiqueta de sensibilidad asociada a ese objeto tambin se exportar
y deber residir en el mismo medio fsico como el exportado
informacin y se har de la misma forma (es decir, de lectura mecnica o
formato legible). Cuando las exportaciones o importaciones TCB un objeto
ms
un canal de comunicacin de mltiples niveles, el protocolo utilizado en ese
canal
debern prever la vinculacin inequvoca entre la sensibilidad
etiquetas y la informacin asociada que se enva o se recibe.
B2: NAR.
B3: NAR.
A1: NAR.
Exportacin a solo nivel-Devices
C1: NR.
C2: NR.
B1: dispositivos S-nivel individual de E / y canales de comunicacin a nivel
individual: NUEVO
no estn obligados a mantener las etiquetas de sensibilidad del
informacin 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 informacin importados o
exportado a travs de los canales de comunicacin de un solo nivel o
dispositivos de E / S.
B2: NAR.
B3: NAR.
A1: NAR.
Identificacin y autenticacin
C1: NUEVO: La TCB exigir a los usuarios que se identifiquen con l antes
comenzando a realizar cualquier otra accin que la TCB se espera que
mediar. Adems, la TCB utilizar un mecanismo protegido (por ejemplo,
contraseas) para autenticar la identidad del usuario. El TCB deber
proteger los datos de autenticacin 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 tambin proporcionar la capacidad de
asociando esta identidad con todas las acciones que se pueden auditar
tomadas por que
individual.
B1: CAMBIO: Adems, la TCB mantendr los datos de autenticacin que
incluye informacin para la verificacin de la identidad de los usuarios
individuales
(por ejemplo, contraseas), as como informacin para determinar la
autorizacin y autorizaciones de los usuarios individuales. Estos datos sern
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
estn dominados por la liquidacin y autorizacin de ese usuario.
B2: NAR.
B3: NAR.
A1: NAR.
Integridad Label
C1: NR.
C2: NR.
B1: NUEVO: etiquetas de sensibilidad deber representar con precisin los
niveles de seguridad de
los sujetos u objetos especficos con los que estn asociados. Cuando
exportado por el TCB, etiquetas de sensibilidad y precisin deber
inequvocamente representar las etiquetas internas y estar asociada
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
lneas) 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 pgina de salida legible, paginado, en papel (por ejemplo, la lnea
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 informacin de la

pgina.
El TCB ser, por defecto y de manera apropiada, marque otra
formas de salida legible por humanos (por ejemplo, mapas, grficos) con
humanidad
etiquetas de sensibilidad legibles que correctamente * representan la
sensibilidad
de la salida. Cualquier anulacin de estos incumplimientos marcado ser
B2: NAR.
B3: NAR.
A1: NAR.
______________________________
jerrquica
categoras.
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 debern solicitar y recibir de una autorizacin
usuario el nivel de seguridad de los datos, y todas estas acciones sern
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 poltica 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 sern
etiquetas de sensibilidad asignados que son una combinacin de jerrquica
niveles de clasificacin y categoras no jerrquicas y las etiquetas
se utilizar como base para las decisiones de control de acceso obligatorios.
El TCB deber ser capaz de soportar dos o ms de tales niveles de

seguridad.
(Vanse las directrices de control de acceso obligatorios.) La siguiente
requisitos permanecern en para todos los accesos entre sujetos y objetos
controlado por el TCB: Un sujeto puede leer un objeto slo si el
clasificacin jerrquica en el nivel de seguridad del sujeto es
mayor o igual a la clasificacin jerrquica en el
nivel de seguridad del objeto y las categoras no jerrquicas en la
nivel de seguridad del sujeto incluye todas las categoras no jerrquicas
en el nivel de seguridad del objeto. Un sujeto puede escribir un objeto slo
si la clasificacin jerrquica en el nivel de seguridad del sujeto es
menos de o igual a la clasificacin jerrquica en el objeto de
categoras en el nivel de seguridad del objeto. Identificacin y
datos de autenticacin se utilizarn por el TCB para autenticar el
autorizacin
zacin de los sujetos externo a la TCB que pueden crearse para actuar
en nombre del usuario individual estn dominadas por el despacho y
autorizacin de dicho usuario.
B2: CAMBIO: El TCB deber aplicar una poltica 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 debern 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.
Reutilizacin de objetos
C1: NR.
C2: NUEVO: Todas las autorizaciones a la informacin contenida dentro de un
la asignacin o reasignacin a un sujeto desde la piscina del TCB de
objetos de almacenamiento no utilizados. No hay informacin, incluyendo
cifrado
acciones es estar a disposicin 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.
Caractersticas de seguridad Gua del usuario
C1: NUEVA: Un solo resumen, captulo, o manual en la documentacin del
usuario deber
describir los mecanismos de proteccin proporcionados por la TCB,
directrices sobre
su uso, y cmo interactan 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 sometern a
ensayo y
encontrado para trabajar como se reivindica en la documentacin 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 proteccin de la
seguridad
del TCB. (Vanse las directrices de Pruebas de Seguridad.)
C2: ADD: El ensayo debe incluir tambin una bsqueda de defectos obvios
que
permitir la violacin de aislamiento de recursos, o que permitira
acceso no autorizado a los datos de auditora o de autenticacin.
B1: NUEVO: Los mecanismos de seguridad del sistema de ADP se sometern a
ensayo y
encontrado para trabajar como se reivindica en la documentacin del
sistema. Un equipo de
personas que entienden a fondo la aplicacin especfica de
la TCB deber someter su documentacin de diseo, cdigo fuente, y
cdigo objeto de anlisis y pruebas exhaustivas. Sus objetivos debern
ser: para descubrir todos los defectos de diseo e implementacin que

permitan
un sujeto externo a la TCB para leer, cambiar o eliminar los datos
normalmente negado bajo la poltica de seguridad obligatoria o discrecional
forzada por la TCB; as como para asegurar que ningn objeto (sin
autorizacin 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 sern 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 penetracin.
El ensayo debe demostrar que la aplicacin TCB es consistente
con la memoria descriptiva de nivel superior.
B3: CAMBIO: La TCB se encontr resistente a la penetracin.
ADD: No hay defectos de diseo y no ms de unos pocos corregible
fallas de implementacin se pueden encontrar durante las pruebas y no
habr
confianza razonable de que pocos permanecen.
A1: CAMBIO: El ensayo debe demostrar que la aplicacin TCB es
consistente con la especificacin formal de nivel superior.
ADD: mapeo manual u otra de las FTLs al cdigo fuente puede formar
una base para las pruebas de penetracin.
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
sesin. 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 ejecucin que
protege de interferencias externas o manipulacin (por ejemplo,
modificacin de sus cdigos 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
estn sujetos al control de acceso y los requisitos de auditora.
B1: ADD: El TCB deber mantener el aislamiento de procesos a travs de la

prestacin
de espacios de direcciones distintas bajo su control.
B2: NUEVO: La TCB mantendr un dominio para su propia ejecucin que
protege de interferencias externas o manipulacin (por ejemplo,
modificacin de sus cdigos o estructuras de datos). El TCB mantendr
aislamiento de procesos a travs de la provisin de espacios de direcciones
distintas
bajo su control. La TCB se estructurar internamente en bienestar
definidos mdulos en gran medida independientes. Se har un uso efectivo
de
hardware disponible para separar aquellos elementos que son
proteccionismo
crtico de aquellas que no lo son. Los mdulos de TCB se disearn
de tal manera que el principio de privilegios mnimos se hace cumplir.
Caractersticas en
hardware, como la segmentacin, se utilizar para apoyar lgicamente
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 diseado y estructurado para utilizar una solucin
completa,
mecanismo de proteccin conceptualmente simple con definido con
precisin
semntica. Este mecanismo deber desempear un papel central en la
aplicacin de la
estructuracin interna de la TCB y el sistema. El TCB deber
incorporar un uso significativo de la estratificacin, la abstraccin y la
ocultacin de datos.
Ingeniera de sistemas significativos deber estar encaminada a minimizar
la complejidad de la TCB y se excluyen de los mdulos de TCB que son

No proteccin crtica.
A1: NAR.
Integridad del sistema
C1: NUEVO: caractersticas de hardware y / o software se proporcionarn que
puede ser
utilizado para validar peridicamente 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.
Documentacin 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
cmo el
mecanismos de seguridad fueron analizados y los resultados de la
seguridad
C2: NAR.
B1: NAR.
B2: ADD: Incluir los resultados de las pruebas de la eficacia de la
mtodos utilizados para reducir los anchos de banda de canal encubiertas.
B3: NAR.
A1: ADD: Los resultados de la correlacin entre el nivel superior formales
Se dar especificacin y el cdigo fuente TCB.
Distribucin 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
distribucin ser
proporcionado para mantener la integridad de la asignacin entre el
datos maestros describen la versin actual de la TCB y el en el sitio
copia maestra del cdigo para la versin actual. Procedimientos (por
ejemplo,
existir la seguridad del sitio de pruebas de aceptacin) para asegurar que
el
TCB software, firmware y actualizaciones de hardware distribuido a un
al cliente estn exactamente segn 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 desempeadas en el papel de un administrador de
seguridad
se identificarn. El personal administrativo del sistema ADP deber
slo ser capaz de realizar las funciones de administrador de seguridad
despus de tomar
una accin auditable distinta a asumir la funcin de administrador de
seguridad
en el sistema de ADP. Funciones no son de seguridad que se pueden
realizar en
el papel administracin de la seguridad se limitar estrictamente a los
A1: NAR.
Manual de Instalacin 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 instalacin segura.
C2: ADD: Los procedimientos de examen y el mantenimiento de los archivos
de auditora
as como la estructura de registro de auditora detallado para cada tipo de

auditora
Se dar evento.
B1: ADD: El manual deber describir el operador y administrador
funciones relacionadas con la seguridad, que incluyen el cambio de la
caractersticas de un usuario. Asimismo, proporcionar directrices sobre la
el uso coherente y eficaz de las funciones de proteccin de la
sistema, cmo interactan, cmo generar de forma segura una nueva TCB,
y
procedimientos de instalacin, advertencias y privilegios que necesitan ser
controlado con el fin de operar la instalacin de una manera segura.
B2: ADD: Los mdulos de TCB que contienen el mecanismo de validacin de
referencia
se identificarn. Los procedimientos para la generacin segura de un nuevo
TCB de la fuente despus de la modificacin de los mdulos en el TCB
deber
se describir.
B3: ADD: Incluir los procedimientos para garantizar que el sistema es
debern ser tambin
incluido para reanudar el funcionamiento seguro del sistema despus de
cualquier interrupcin en el sistema
operacin.
A1: NAR.
Camino de confianza
C1: NR.
C2: NR.
B1: NR.
B2: NUEVO: La TCB apoyar una ruta de comunicacin de confianza entre
en s y el usuario de inicio de sesin inicial y la autenticacin.
Comunicaciones
a travs de este camino se iniciar exclusivamente por un usuario.
B3: CAMBIO: El TCB apoyar una ruta de comunicacin de confianza entre
en s y los usuarios para su uso cuando una conexin positiva-TCB a usuario
es
requerido (por ejemplo, inicio de sesin, sujeta nivel de seguridad del
cambio).
Comunicaciones a travs de este camino de confianza se activarn en
exclusiva
por un usuario o de la TCB y deber ser aislado de manera lgica y sin lugar
a dudas
A1: NAR.
Recuperacin de confianza
C1: NR.
C2: NR.
B1: NR.
B2: NR.
B3: NUEVO: Procedimientos y / o mecanismos se proporcionarn para
asegurar que,
despus de un fallo del sistema ADP u otra discontinuidad, la recuperacin
sin
se obtiene la proteccin de compromiso.

A1: NAR.
?
(esta pgina est reservada para la Figura 1)

?
GLOSARIO
Acceso - Un tipo especfico de interaccin entre un sujeto y un objeto

que resulta en el flujo de informacin de una a la otra.
Aprobado / Acreditacin - La autorizacin oficial de que es
concedida a un sistema de ADP para procesar informacin sensible en
su entorno operativo, basado en la amplia
evaluacin de seguridad de hardware, el firmware del sistema, y
diseo de software de seguridad, configuracin y puesta en prctica
y del otro sistema procesal, administrativo,
, TEMPESTAD, personal y seguridad de las comunicaciones fsicas
controles.
Audit Trail - Un conjunto de registros que proporcionan colectivamente
pruebas documentales de procesamiento utilizado para ayudar en la
localizacin
de las operaciones originales con inters registros relacionados y
informes, y / o hacia atrs 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 automtico - Una asamblea de equipo
hardware, firmware y software configurado para el propsito
de clasificar, ordenar, calcular, la informtica,
resumiendo, la transmisin y recepcin, almacenamiento y
la recuperacin de datos con un mnimo de intervencin humana.
Ancho de Banda - Una caracterstica de un canal de comunicacin que es
la cantidad de informacin que se puede pasar a travs de ella en una
dada cantidad de tiempo, generalmente expresada en bits por segundo.
Modelo Bell-LaPadula - Un modelo de transicin de estado formal de equipo
la poltica 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 nocin de un estado seguro se define y es
probado que cada transicin de estado conserva la seguridad por
movindose 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 especfica
politica de seguridad. Con el fin de determinar si es o no una
se permite el modo de acceso especfico, el pase de un sujeto
se compara con la clasificacin del objeto y una
se efecta la determinacin de si el sujeto est
autorizado para el modo de acceso especfica. Los
esquema de aclaramiento / clasificacin se expresa en trminos de una

celosa. Ver tambin: Cedazo, simple Propiedad Seguridad, * Propiedad.
Certificacin - La evaluacin tcnica de seguridad de un sistema
caractersticas, realizados como parte de y en apoyo de la
/ proceso de acreditacin de aprobacin, que establece la medida
a la que el diseo de un sistema informtico en particular y
aplicacin cumple con un conjunto de seguridad especificado
requisitos.
Canal - Una ruta de transferencia de informacin dentro de un sistema. Pudiera
tambin
consulte el mecanismo por el cual se efecta el camino.
Canal encubierto - Un canal de comunicacin que permite a un proceso
transferir informacin de una manera que viole el sistema de
politica de seguridad. Ver tambin: Covert Canal de almacenamiento, Covert
Timing Channel.
Covert Canal de almacenamiento - Un canal secreto que implica la
escritura directa o indirecta de una ubicacin de almacenamiento por uno
proceso y la lectura directa o indirecta de almacenamiento
ubicacin 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
seales de informacin a otro mediante la modulacin de su propio uso de
los recursos del sistema (por ejemplo, tiempo de CPU) de tal manera que este
manipulacin afecta el tiempo de respuesta real, observada por el

segundo proceso.
Datos - Informacin con una representacin fsica especfica.
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 alteracin accidental o maliciosa o
destruccin.
Descriptivo de nivel superior Specification (DTLS) - Un alto nivel
especificacin que est escrito en un lenguaje natural (por ejemplo,
Ingls), una notacin de diseo del programa informal, o una
combinacin de los dos.
Control de Acceso Discrecional - Un medio para restringir el acceso a
objetos en funcin 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 (quizs 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 clasificacin jerrquica de S1 es mayor que
o igual a la de S2 y las categoras no jerrquicas
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 Hiptesis Metodologa - Un anlisis del sistema y la penetracin
tcnica donde las especificaciones y documentacin para el
sistema se analizan y luego fallas en el sistema son
la hiptesis. La lista de defectos hipotticos 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 explotacin de la misma y sobre el grado de control o
comprometer proporcionara. La lista de prioridades se utiliza
para dirigir la prueba real del sistema.
Defecto - Un error de comisin, omisin o descuido en un sistema
que permite a los mecanismos de proteccin al ser anuladas.
Prueba Formal - Un argumento matemtico completo y convincente,
la presentacin de la justificacin lgica completa para cada prueba
paso, por la verdad de un teorema o conjunto de teoremas. Los
proceso de verificacin formal utiliza pruebas formales para mostrar la
verdad de ciertas propiedades de la especificacin formal y para
lo que demuestra que los programas de ordenador satisfacer sus
especificaciones.
Seguridad Formal Modelo Poltica - Una declaracin matemticamente precisa
de una poltica 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 definicin 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 definicin de un estado "seguro" y si todo
supuestos requeridos por el modelo de espera, a continuacin, todos los
futuros
estados del sistema estarn seguros. Algunos modelos formales
tcnicas incluyen: modelos de transicin de estados, lgica temporal
modelos, modelos semntica denotacional, algebraica
modelos de especificacin. Un ejemplo es el modelo descrito por
Bell y LaPadula en la referencia [2]. Ver tambin: BellLaPadula Modelo, Modelo de Poltica de Seguridad.
Formal Especificacin de nivel superior (FTLs) - Una especificacin de nivel
superior
que est escrito en un lenguaje matemtico formal para permitir
teoremas que muestran la correspondencia del sistema
especificacin de sus requisitos formales para ser la hiptesis
y probado formalmente.
Verificacin Formal - El proceso de utilizacin de pruebas formales de
demostrar la consistencia (verificacin del diseo) entre un
especificacin formal de un sistema y de una garanta formal,
modelo de poltica o (verificacin de la implementacin) entre el
especificacin formal y su aplicacin del programa.
Front-End Filtro de Seguridad - Un proceso que se invoca al proceso
datos accordint a una poltica de seguridad especificado antes de la
la liberacin 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
caractersticas anunciados de un sistema se prueban para la correcta
operacin.
Sistema de fines generales - Un sistema informtico que est diseado para
ayuda en la solucin 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 mnima.
Privilegio mnimo - Este principio requiere que cada sujeto en un
sistema de concederse el conjunto ms restrictivo de privilegios (o
aclaramiento ms bajo) necesarios para el desempeo de autorizado
tareas. La aplicacin de este principio limita el dao
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 funcin de la sensibilidad (representado por una etiqueta)
de la informacin contenida en los objetos y lo formal
autorizacin (es decir, la remocin) de temas para el acceso
informacin de tal sensibilidad.
Dispositivo multinivel - Un dispositivo que se utiliza de una manera que
lo permite procesar simultneamente datos de dos o ms
niveles de seguridad sin riesgo de compromiso. Para llevar a cabo
esta, etiquetas de sensibilidad normalmente se almacenan en el mismo
medio fsico y de la misma forma (es decir, legible por mquina
o est procesando legible por humanos) que los datos.
Multinivel Secure - Una clase de sistema que contiene informacin con

diferentes sensibilidades que permite al mismo tiempo el acceso
los usuarios con diferentes permisos de seguridad y las necesidades-asaber, pero impide que los usuarios obtener acceso a
informacin por los que carecen de autorizacin.
Object - Un ente pasivo que contiene o recibe informacin.
El acceso a un objeto potencialmente implica el acceso a la
informacin que contiene. Ejemplos de objetos son: registros,
bloques, pginas, 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.
Reutilizacin de objetos - La reasignacin a algn tema de un medio
(por ejemplo, marco de pgina, sector de disco, cinta magntica) que
contenida uno o ms objetos. Para ser reasignado de forma segura,
tales medios deben contener datos residuales de la anteriormente
objeto contenido (s).
Salida - La informacin que se ha exportado por un TCB.
Contrasea - Una cadena de caracteres privada que se utiliza para
autenticar una identidad.
Pruebas de Penetracin - 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
diseo del sistema y la documentacin aplicacin, que puede
incluir los listados de cdigo fuente del sistema, manuales, y el circuito
diagramas. El trabajo penetradores bajo ninguna restricciones otros

que los que se aplicara a los usuarios normales.
Proceso - Un programa en ejecucin. Est completamente caracterizada
por un nico punto de ejecucin actual (representado por la
estado de la mquina) y el espacio de direcciones.
Porciones de proteccin-crtico de la TCB - Las partes de la
TCB cuya funcin normal es tratar con el control de
acceso entre sujetos y objetos.
Proteccin Filosofa - Una descripcin informal de la general
diseo de un sistema que delimita cada uno de la proteccin
mecanismos empleados. Una combinacin (apropiada para el
clase de evaluacin) de las tcnicas formales e informales se utiliza
para mostrar que los mecanismos son adecuados para hacer cumplir la
politica de seguridad.
Leer - Una operacin fundamental que los resultados slo en el flujo de
informacin de un objeto a un sujeto.
Leer acceso - Permiso para leer la informacin.
Memoria de slo lectura (ROM) - Un rea de almacenamiento en la que el
contenido puede
ser ledo pero no alterado durante el proceso normal de ordenador.
Referencia monitor Concepto - Un concepto de control de acceso que se refiere
a una mquina abstracta que media en todos los accesos a los objetos
por los sujetos.
Recursos - Cualquier cosa utilizados o consumidos en el desempeo de una

funcin.
Las categoras de recursos son: tiempo, informacin, objetos
(contenedores de informacin), o procesadores (la capacidad de utilizar
informacin). Ejemplos especficos son: tiempo de CPU; Terminal
tiempo de conexin; cantidad de memoria directamente direccionable; disco
el espacio; nmero 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 modificacin y ser verificables como correcta.
Nivel de seguridad - La combinacin de una clasificacin jerrquica
y un conjunto de categoras no jerrquicas que representa el
sensibilidad de la informacin.
Poltica de Seguridad - El conjunto de leyes, normas y prcticas que
regular cmo una organizacin gestiona, protege y
distribuye informacin sensible.
Modelo de Seguridad Poltica - Una presentacin informal de un oficial
modelo de poltica 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,
contrasea de usuario de cambio, etc.). Tambin, cualquier evento que intenta
violar la poltica de seguridad del sistema, (por ejemplo, tambin
muchos intentos de inicio de sesin, los intentos de violar la obligatoria
lmites 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
caractersticas de un sistema se implementan como diseado y que
que son adecuadas para un entorno de aplicacin propuesto.
Este proceso incluye la prctica de pruebas funcionales,
pruebas de penetracin, y la verificacin. Ver tambin: Funcional
Pruebas, pruebas de penetracin, Verificacin.
Informacin Sensible - La informacin que, segn lo determinado por un
autoridad competente, debe ser protegida porque su
divulgacin no autorizada, alteracin, prdida o destruccin
ser al menos causar daos perceptibles a alguien o
algo.
Sensibilidad etiqueta - Una pieza de informacin que representa el
nivel de seguridad de un objeto y que describe la
sensibilidad (por ejemplo, clasificacin) 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 slo 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 estn procesando.
* -Property (Star Property) - Una regla modelo de seguridad de Bell-LaPadula
permitiendo un acceso por materias de escritura a un objeto slo si el
nivel de seguridad del sujeto est dominado por la seguridad
nivel del objeto. Tambin 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 informacin fluya entre
objetos o cambia el estado del sistema. Tcnicamente, 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 ledo tanto
y escritura. Nivel de seguridad de un objeto debe ser siempre
dominado por la liquidacin de los usuarios el tema es
asociado con.
TEMPESTAD - El estudio y control de seales electrnicas espurias
emitida desde el equipo ADP.
De nivel superior Specification (TLS) - Una descripcin no procesal de
el comportamiento del sistema en el nivel ms abstracto. Normalmente, una
especificacin funcional que omite todo implementacin
detalles.
Trampa puerta - Un software oculto o mecanismo de hardware que permite

los mecanismos de proteccin 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
funcin til que contiene las funciones adicionales (ocultos)
que subrepticiamente explotar las autorizaciones legtimas
del proceso de invocacin 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 simultneamente una gama de sensible o
informacin clasificada.
Trusted Computing Base (TCB) - La totalidad de la proteccin
mecanismos dentro de un sistema informtico - incluyendo hardware,
firmware y software - la combinacin de las cuales es
responsable de hacer cumplir una poltica de seguridad. Un TCB consiste
de uno o ms componentes que juntos hacer cumplir una unificado
poltica de seguridad sobre un producto o sistema. La capacidad de
una base informtica de confianza para hacer cumplir correctamente un
poltica de seguridad depende nicamente de los mecanismos dentro de la
TCB y en la entrada correcta por sistema administrativo
personal de parmetros (por ejemplo, el despacho de un usuario) relacionada
a la poltica 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 slo puede ser activado por la persona o el fiables
Clculo de la base y no puede ser imitado por el software que no se confa.
Software confiables - La parte de software de Trusted Computing
Base.
Usuario - Cualquier persona que interacta directamente con un sistema
informtico.
Verificacin - El proceso de comparar dos niveles de sistema
Especificacin para la correspondencia adecuada (por ejemplo, la seguridad
modelo de poltica con la especificacin de nivel superior, TLS con fuente
cdigo o cdigo fuente con cdigo objeto). Este proceso puede o
no puede ser automatizado.
Write - Una operacin fundamental que los resultados slo en el flujo de
informacin de un sujeto a un objeto.
Escribe acceso - Permiso para escribir un objeto.
?
REFERENCIAS
1. Anderson, Planificacin de Tecnologa 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 informticos:
Exposicin unificada y Multics Interpretacin, MTR-2997

Rev. 1, MITRE Corp., Bedford, Mass., 03 1976.
3. Marca, SL "Un acercamiento a la identificacin y Auditora de
Vulnerabilidades y el Control de Sistemas de Aplicacin ", en
Auditora y Evaluacin de Seguridad Informtica II: Sistema
Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS
Publicacin Especial # 500-57, MD78733, abril 1980.
4. Marca, SL "Proceso de Datos y A-123", en Actas de
Grupo 18 la evaluacin del usuario rendimiento del equipo
Reuniones, CB Wilson, ed., NBS Publicacin 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 informacin segura
Flow "en Communications of the ACM, vol. 19, nm. 5
(Mayo de 1976), pp. 236-243.
8. Denning, DE Secure Flujo de Informacin en Informtica de Sistemas,
Ph.D. disertacin, Purdue Univ., West Lafayette, Indiana.,
Mayo 1975.
9. Directiva DoD 5000.29, gestin de los recursos informticos en la Major
Sistemas de Defensa, 26 de abril l976.
10. DoD 5200.1-R, Seguridad de la Informacin Reglamento del Programa,

08 1982.
11. Directiva del DoD 5200.28, Requisitos de seguridad para automtico
Data Processing (ADP) Systems, revis 04 1978.
Manual 12. DoD 5200.28-M, ADP Seguridad - Tcnicas y
Procedimientos para la Ejecucin, desactivacin, pruebas y
La evaluacin de seguro de Recursos Compartidos ADP Systems, revisada
06 1979.
13. Directiva del DoD 5215.1, Seguridad informtica Centro de Evaluacin,
25 de octubre 1982.
14. DoD 5220.22-M, Manual de Seguridad Industrial para la proteccin de
Informacin 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 Informacin (AIS), 17 de octubre 1978
18. Orden Ejecutiva 12356, Seguridad de la Informacin 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 Publicacin (FIPS
PUB) 39, Glosario de Informtica de Sistemas de Seguridad,

15 de febrero 1976.
PUB) 73, Directrices para la Seguridad del ordenador
Aplicaciones, 30 de junio de 1980.
PUB) 102, Gua para la Certificacin de Seguridad Informtica
y Acreditacin.
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
Perifricos cercanas: Un informe de consenso ", en Auditora y
Evaluacin de la Seguridad Informtica II: Sistema
Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS
Publicacin 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 Violacin de flujo formal", en
Actas de la segunda IEEE Computer Society
Software Informtica Internacional y Aplicaciones
Conferencia, noviembre de 1978, pgs. 204 a 208.
27. Millen, JK "Seguridad del Kernel de validacin en la prctica", 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 Evaluacin Tcnica para
Trusted Computer Systems, MITRE Corp., Bedford, Mass.,
M79-225, AD-A108-832, 25 de octubre 1979.
29. Nibaldi, GH Especificacin de A Computing Base confiables,
(TCB), MITRE Corp., Bedford, Mass., M79-228, AD-A108831, 30 de noviembre 1979.
30. OMB Circular A-71, Transmisin Memorando N 1, de Seguridad
Federal Automatizado Sistemas de Informacin, 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. Auditora y Evaluacin del
Seguridad Informtica, en NBS Publicacin 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 Ncleos: Un diseo metdico de
Sistema de seguridad ", en Documentos Tcnicos, USO Inc. Primavera
Conferencia, 5-9 marzo de 1979, pp. 245-250.
35. Trotter, ET y Tasker, PS Industria Informtica de confianza
Sistemas de Proceso de Evaluacin, 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 Informtica,
De mayo de 1980, pp. 655-665.
38. Ware, WH, ed, Controles de Seguridad de los Sistemas Informticos.:
Informe del Consejo Cientfico de Defensa Grupo de Trabajo en Equipo
Seguridad, AD # A076617 / 0, Rand Corporation, Santa
Monica, Calif., 02 1970, reeditado 10 1979.

Standares de Seguridad

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Standares de Seguridad

Uploaded by

Copyright:

Available Formats

DoD 5200.

DEPARTAMENTO DE DEFENSA STANDARD

Computer Esta publicacin, DoD 5200.28-STD, "Departamento de Defensa de

la poltica de seguridad, evaluacin y aprobacin / responsabilidades de

Un reconocimiento especial se extiende a Sheila L. Marca, Seguridad Nacional de

el Ejrcito, que dio generosamente su tiempo y experiencia en la revisin y

PARTE I: LOS CRITERIOS

4.1 Clase (A1): Diseo verificada. . . . . . . . . . . 42

PARTE II: JUSTIFICACIN Y DIRECTRICES

9.0 A GUA sobre la configuracin de control de acceso obligatorio

10.0 Una GUA SOBRE LAS PRUEBAS DE SEGURIDAD. . . . . . . . . . . . 83

ANEXO A: Proceso de evaluacin comercial del producto. . . . . . 87

ANEXO C: Sumario de las clases criterios de evaluacin. . . . . . 91

Los criterios de evaluacin del sistema informtico de confianza definidos en este

con un punto de referencia con el que evaluar el grado de confianza que se

interpretarse en la aplicacin de los criterios a los sistemas especficos con su

Fuerza Area, Advanced Research Projects Agency, y otros organismos de

requisitos especficos de caractersticas de seguridad; y 2) los requisitos de

el grado de confianza que se puede colocar en los sistemas informticos

fortalezas del sistema de productos y debilidades desde el punto de la seguridad

Fundamentales Requisitos de Seguridad Informtica

En general, los sistemas seguros controlarn, a travs del uso de la seguridad

Requisito 2 - MARCADO - etiquetas de control de acceso deben estar

criterios aplicables para cada divisin de la evaluacin y de clase. El interesado

Estructura del documento

seguridad obligatoria. Seccin 10 proporciona directrices para las pruebas de

Estructura de los Criterios

estructura de ejecucin. El aumento de la seguridad de que las caractersticas

Destacando (MAYSCULAS) se utiliza en la primera parte para indicar criterios no

Las clases de esta divisin prevn (necesidad de conocer) la proteccin

2.1.3.1.1 Arquitectura del Sistema

deber describir los mecanismos de proteccin proporcionados por la

Sistemas de esta clase hacen cumplir un acceso discrecional ms de grano fino

2.2.1.2 Objeto Reutilizacin

El TCB ser capaz de crear, mantener y proteger de la

2.2.3.1.1 Arquitectura del Sistema

permitira violacin del aislamiento de los recursos, o que lo hara

Documentacin 2.2.4.3 Prueba

2.2.4.4 Diseo de documentacin

La nocin de un TCB que preserve la integridad de las etiquetas de sensibilidad y

Adems, una declaracin informal de la modelo de la poltica de seguridad, el

slo podrn ser asignadas por los usuarios autorizados.

etiquetas internas y estar asociada a la

los canales de comunicacin no estn obligados a

etiquetas de sensibilidad legibles que correctamente *

y los datos de autenticacin se utilizarn por el TCB para autenticarse

proteger los datos de autenticacin de modo que no se puede acceder

el origen de la solicitud (por ejemplo, la terminal ID) se incluye en

se puede utilizar para validar peridicamente el funcionamiento

ciclo del sistema ADP y ha demostrado ser consistente

El desarrollador del sistema proporcionar a los evaluadores un

elementos de proteccin crtico no. La interfaz de TCB est bien definido y de la

El permiso de acceso a un objeto por los usuarios no ya que posee

etiquetas de sensibilidad deber precisin y sin ambigedades

Dispositivos S-nivel individual de E / y de un solo nivel

grficos) con etiquetas de sensibilidad legibles

niveles de clasificacin y categoras no jerrquicas, y la

El TCB exigir a los usuarios que se identifiquen con l antes

El TCB ser capaz de crear, mantener y proteger de la

eventos que se pueden utilizar en la explotacin de almacenamiento

se puede utilizar para validar peridicamente el correcto

delete normalmente datos negados bajo el obligatorio o

especificacin, otros datos de diseo, implementacin