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 EVALUACIÓN

CRITERIOS

Diciembre l985

?

26 de diciembre de l985

PRÓLOGO

Computer Esta publicación, DoD 5200.28-STD, "Departamento de Defensa de confianza

Criterios de evaluación del sistema ", se emite bajo la autoridad de un acuerdo

con la Directiva DoD 5200.28, "Requisitos de seguridad para Automatic Data

Procesamiento (ADP) Sistemas ", y en cumplimiento de las responsabilidades asignadas por

DoD Directiva 52l5.l, "Seguridad Informática Centro de evaluación." Su propósito es

proporcionar / / criterios técnicos de hardware de firmware y software de seguridad asociado

metodologías de evaluación técnica en apoyo del sistema de ADP general

la política de seguridad, evaluación y aprobación / responsabilidades de acreditación

promulgada por la Directiva DoD 5200.28.

Lo dispuesto en este documento se aplican a la Oficina del Secretario de Defensa

(ASD), los departamentos militares, la Organización de los Jefes del Estado Mayor Conjunto,

Unificado y especificado los comandos, las agencias y las actividades de Defensa

administrativamente apoyado por OSD (en lo sucesivo denominado "DoD Componentes").

Esta publicación es efectiva inmediatamente y es obligatorio para su uso por parte de todos del Departamento de Defensa

Componentes en la realización de actividades de evaluación de la seguridad técnica del sistema ADP

aplicable al tratamiento y almacenamiento de los clasificados y otra DoD sensibles

información y aplicaciones como se establece en el presente documento.

Se anima Recomendaciones para la revisión de esta publicación y serán

revisado cada dos años por el Centro Nacional de Seguridad Informática a través de un oficial

proceso de revisión. Dirección todas las propuestas de revisión a través apropiada

canales a: Centro Nacional de Seguridad Informática, Atención: Jefe, Computadora

Normas de Seguridad.

Componentes del DoD puede obtener copias de esta publicación a través de su propia

Publicaciones canales. Otras agencias federales y el público puede obtener copias

de: Oficina de Normas y Productos, Centro Nacional de Seguridad Informática,

Fort Meade, MD 20755-6000, Atención: Jefe, Estándares de Seguridad Informática.

_________________________________

Donald C. Latham

El subsecretario de Defensa

(Comando, Control, Comunicaciones e Inteligencia)

?

AGRADECIMIENTOS

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

Centro (NCSC), que integra la teoría, la política y la práctica en y dirigió

la producción de este documento.

Reconocimiento También se da por las contribuciones de: Gracia y Hammonds

Peter S. Tasker, el MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell,

ex Director Adjunto de NCSC, Marvin Schaefer, NCSC, y Theodore MP Lee,

Sperry Corp., que como arquitectos originales formulados y articulan la

problemas y soluciones técnicas que se presentan en este documento; Jeff Makey, anteriormente

NCSC, Warren F. Shadle, NCSC, y Carole S. Jordan, NCSC, quien colaboró en la

elaboración de este documento; James P. Anderson, James P. Anderson & Co.,

Steven B. Lipner, Digital Equipment Corp., Clark Weissman, Desarrollo de Sistemas

Corp., LTC Lawrence A. Noble, ex Fuerza Aérea de Estados Unidos, Stephen T. Walker,

antes del Departamento de Defensa, Eugene V. Epperly, del Departamento de Defensa, y James E. Studer, anteriormente Departamento de

el Ejército, que dio generosamente su tiempo y experiencia en la revisión y

crítica de este documento; y, finalmente, se dan gracias a la computadora

la industria y otros interesados en la computación de confianza por su entusiasta

asesoramiento y asistencia a través de este esfuerzo.

?

CONTENIDOS

PRÓLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .yo

AGRADECIMIENTOS. . . . . . . . . . . . . . . . . . . . . . . ii

PRÓLOGO. . . . . . . . . . . . . . . . . . . . . . . . . . . .v

INTRODUCCIÓN. . . . . . . . . . . . . . . . . . . . . . . . . 0.1

PARTE I: LOS CRITERIOS

1.0 DIVISIÓN D: protección mínima. . . . . . . . . . . . . 0.9

2.0 DIVISIÓN C: PROTECCIÓN DISCRECIONAL. . . . . . . . . . 11

2.1 Clase (C1): Discrecional Protección Seguridad. . 12

2.2 Clase (C2): Controlado de protección de acceso. . . . . 15

3.0 DIVISIÓN B: PROTECCIÓN OBLIGATORIA. . . . . . . . . . . . 19

3.1 Clase (B1): Etiquetado de Protección de Seguridad. . . . . 20

3.2 Clase (B2): Protección estructurado. . . . . . . . 26

3.3 Clase (B3): Dominios de Seguridad. . . . . . . . . . . 33

4.0 DIVISIÓN A: PROTECCIÓN VERIFICADO. . . . . . . . . . . . 41

4.1 Clase (A1): Diseño verificada. . . . . . . . . . . 42

4.2 Más allá de la Clase (A1). . . . . . . . . . . . . . . . . 51

PARTE II: JUSTIFICACIÓN Y DIRECTRICES

5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMÁTICOS DE CONFIANZA. . . . . 55

5.1 Una necesidad de consenso. . . . . . . . . . . . . . . 56

5.2 Definición y utilidad. . . . . . . . . . . . . 56

5.3 Criterios de control objetivo. . . . . . . . . . . . 56

6.0 JUSTIFICACIÓN DETRÁS DE LAS CLASES DE EVALUACIÓN. . . . . . . . . 63

6.1 El concepto de monitor de referencia. . . . . . . . . . . 64

6.2 Un modelo de Política de Seguridad formal. . . . . . . . . . 64

6.3 La Base de Trusted Computing. . . . . . . . . . . . sesenta y cinco

6.4 Aseguramiento. . . . . . . . . . . . . . . . . . . . . sesenta y cinco

6.5 Las Clases. . . . . . . . . . . . . . . . . . . . 66

7.0 LA RELACIÓN ENTRE LA POLÍTICA Y LOS CRITERIOS. . . . 69

7.1 establecido políticas federales. . . . . . . . . . . 70

7.2 Políticas del Departamento de Defensa. . . . . . . . . . . . . . . . . . . 70

7.3 Criterios de control objetivo para la Política de Seguridad. . 71

7.4 Criterios de control objetivo para la Rendición de Cuentas. . . 74

7.5 Criterios de control objetivo para la Garantía. . . . . 76

8.0 Una directriz sobre canales encubiertos. . . . . . . . . . . . . 79

9.0 A GUÍA sobre la configuración de control de acceso obligatorio

CARACTERÍSTICAS . . . . . . . . . . . . . . . . . . . . . . . . 81

10.0 Una GUÍA SOBRE LAS PRUEBAS DE SEGURIDAD. . . . . . . . . . . . 83

10.1 Pruebas de División C. . . . . . . . . . . . . . 84

10.2 Pruebas de División B. . . . . . . . . . . . . . 84

10.3 Las pruebas para la División A. . . . . . . . . . . . . . 85

ANEXO A: Proceso de evaluación comercial del producto. . . . . . 87

ANEXO B: Resumen de Evaluación Divisiones Criterios. . . . 89

ANEXO C: Sumario de las clases criterios de evaluación. . . . . . 91

APÉNDICE D: Directorio de los Menesteres. . . . . . . . . . . . . . 93

GLOSARIO. . . . . . . . . . . . . . . . . . . . . . . . . . 0,109

REFERENCIAS. . . . . . . . . . . . . . . . . . . . . . . . . 0,115

?

PRÓLOGO

Los criterios de evaluación del sistema informático de confianza definidos en este documento

clasificar los sistemas en cuatro grandes divisiones jerárquicas de seguridad mejorada

protección. Ellos proporcionan una base para la evaluación de la eficacia de

controles de seguridad integrados en productos automáticos del sistema de procesamiento de datos. Los

criterios se han desarrollado con tres objetivos en mente: (a) para proporcionar a los usuarios

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

en los sistemas informáticos para el procesamiento seguro de clasificado u otro sensibles

la información; (b) para proporcionar orientación a los fabricantes en cuanto a lo de construir en

sus nuevos productos comerciales, ampliamente disponibles confianza con el fin de satisfacer

requisitos fiduciarios para aplicaciones sensibles; y (c) proporcionar una base para

especificando los requisitos de seguridad en las especificaciones de adquisición. Dos tipos de

requisitos son delineados para el procesamiento seguro: (a) la seguridad específica

requisitos de características y (b) los requisitos de garantía. Algunos de estos últimos

requisitos permiten al personal de evaluación para determinar si las características requeridas

están presentes y funcionando según lo previsto. El ámbito de aplicación de estos criterios es ser

aplicada al conjunto de componentes que comprenden un sistema de confianza, y no es

necesariamente que debe aplicarse a cada componente del sistema individualmente. Por lo tanto, algunos

componentes de un sistema puede ser completamente no es de confianza, mientras que otros pueden ser

evaluado individualmente a una clase de evaluación más baja o más alta que la grande

producto considerado como un sistema completo. En los productos de confianza en el extremo superior de

la gama, la fuerza del monitor de referencia es tal que la mayoría de las

componentes pueden ser completamente confiable. Aunque los criterios se pretende que sean

independiente de la aplicación, los requisitos específicos de características de seguridad pueden tener que

interpretarse en la aplicación de los criterios a los sistemas específicos con su propia

requisitos funcionales, aplicaciones o entornos especiales (por ejemplo,

procesadores de comunicaciones, ordenadores de control de procesos y sistemas integrados en

general). Los requisitos de garantía subyacentes se pueden aplicar a través de la

todo el espectro de entornos de sistema ADP o procesamiento de aplicación sin

interpretación especial.

?

INTRODUCCIÓN

Perspectiva historica

En octubre de 1967, un grupo de trabajo se reunió bajo los auspicios de la Defensa

Science Board para hacer frente a las garantías de seguridad informática que protegerían

la información clasificada en el acceso remoto, sistemas informáticos de intercambio de recursos.

El informe del Grupo de Trabajo, "Controles de seguridad de sistemas informáticos", publicado en

02 1970, formuló una serie de recomendaciones de políticas y técnicas de

acciones que deben adoptarse para reducir la amenaza de compromiso del clasificado

información procesada en los sistemas informáticos de acceso remoto. [34] Departamento de

Defensa Directiva 5200.28 y su manual que acompaña DoD 5200.28-M, publicado

en 1972 y 1973 respectivamente, respondió a una de estas recomendaciones por

el establecimiento de la política del Departamento de Defensa uniforme, los requisitos de seguridad, administrativos

controles y medidas técnicas para proteger la información clasificada procesados

por los sistemas informáticos del Departamento de Defensa [8, 9]. La investigación y el desarrollo de los trabajos realizados por el

Fuerza Aérea, Advanced Research Projects Agency, y otros organismos de defensa de

los 70 principios y mediados desarrollados y solución demostrado enfoques para la

problemas técnicos asociados con el control del flujo de información en

intercambio de información y los sistemas informáticos de recursos. [1] El ordenador del Departamento de Defensa

Iniciativa de Seguridad se inició en 1977 bajo los auspicios del Bajo

Secretario de Defensa para la Investigación e Ingeniería para enfocar los esfuerzos del Departamento de Defensa

cuestiones abordar la seguridad informática. [33]

Paralelamente a los esfuerzos del Departamento de Defensa para abordar las cuestiones de seguridad informática, el trabajo era

iniciado bajo la dirección de la Oficina Nacional de Estándares (NBS) para definir

problemas y soluciones para la construcción, evaluación y auditoría informática segura

sistemas. [17] Como parte de este trabajo NBS celebró dos talleres de invitación en la

tema de la auditoría y la evaluación de la seguridad informática [20; 28]. El primero fue

celebrada en marzo de 1977, y la segunda en noviembre de 1978. Uno de los productos

del segundo taller fue un documento definitivo sobre los problemas relacionados con

proporcionar criterios para la evaluación de la seguridad del equipo técnico

eficacia. [20] Como consecuencia de las recomendaciones de este informe y, en

apoyo de la Iniciativa de Seguridad del Departamento de Defensa de computadoras, comenzó la Corporación MITRE

trabajar en un conjunto de criterios de evaluación de seguridad informática que podría ser usado para

evaluar el grado de confianza se podría colocar en un sistema informático para proteger

datos clasificada [24; 25; 31]. Los conceptos preliminares para la seguridad informática

Evaluación se define y se amplió en los talleres de invitación y

simposios cuyos participantes representaron experiencia en seguridad informática extrae de

industria y la academia, además del gobierno. Su trabajo tiene ya

sido objeto de mucha revisión por pares y la crítica técnica constructiva de

el Departamento de Defensa, las organizaciones de investigación industrial y de desarrollo, universidades, y

los fabricantes de ordenadores.

El Centro de Seguridad Informática del Departamento de Defensa (el Centro) se formó en enero de 1981 a

personal y ampliar la labor iniciada por el Departamento de Defensa Seguridad informática

Iniciativa. [15] Uno de los objetivos principales del Centro, tal como figura en su Carta del Departamento de Defensa es

alentar a la amplia disponibilidad de los sistemas informáticos de confianza para su uso por

los que procesan la información confidencial clasificada u otros. [10] Los criterios

presentada en este documento han evolucionado a partir de la NBS antes y MITRE

material de evaluación.

Alcance

Se aplican los criterios de evaluación del sistema informático de confianza definidos en este documento

principalmente a confianza procesamiento automático de datos disponible en el mercado (ADP)

sistemas. Ellos también son aplicables, como amplificada a continuación, la evaluación de

los sistemas existentes y la especificación de requisitos de seguridad para ADP

adquisición de sistemas. Se incluyen dos conjuntos distintos de requisitos: 1)

requisitos específicos de características de seguridad; y 2) los requisitos de garantía. Los

requisitos específicos incluyen abarcan las capacidades se encuentran típicamente en

sistemas de procesamiento de información que emplean sistemas operativos de propósito general que

son distintas de las aplicaciones de los programas que se apoyaban. Sin embargo, específica

requisitos de características de seguridad también pueden aplicarse a sistemas específicos con su propia

requisitos funcionales, aplicaciones o entornos especiales (por ejemplo,

procesadores de comunicaciones, ordenadores de control de procesos y sistemas integrados en

general). Los requisitos de garantía, por otro lado, se aplican a los sistemas que

cubrir toda la gama de entornos informáticos de los controladores dedicados a

sistemas de seguridad multinivel gama completa de intercambio de recursos.

Propósito

Como se señala en el prefacio, los criterios han sido developedto servir a un número

de fines previstos:

* Proporcionar un estándar para los fabricantes en cuanto a lo de seguridad

características para construir en su nueva y planificada, comercial

productos a fin de proporcionar sistemas ampliamente disponibles que

requisitos fiduciarios satisfacer (con especial énfasis en la prevención

la divulgación de datos) para aplicaciones sensibles.

* Proporcionar componentes del Departamento de Defensa con una métrica con la que evaluar

el grado de confianza que se puede colocar en los sistemas informáticos de

el procesamiento seguro de clasificada y otra sensible

información.

* Proporcionar una base para especificar los requisitos de seguridad en

especificaciones de adquisición.

Con respecto a la segunda propósito para el desarrollo de los criterios, es decir,

proporcionando componentes del Departamento de Defensa con una métrica de evaluación de seguridad, evaluaciones, puede ser

delineado en dos tipos: (a) una evaluación puede llevarse a cabo en un equipo

producto desde una perspectiva que excluye el entorno de aplicación; o, (b)

que se puede hacer para determinar si se han tomado las medidas de seguridad adecuadas

para permitir que el sistema que se utilizará operativamente en un entorno específico. Los

primer tipo de evaluación es realizada por el Centro de seguridad de la computadora a través de la

Comercial Proceso de evaluación del producto. Ese proceso se describe en el Apéndice

A.

Este último tipo de evaluación, es decir, los que hace con el propósito de evaluar la

atributos de seguridad del sistema con respecto a una misión operativo específico,

que se conoce como una evaluación de la certificación. Se debe entender que la

realización de una evaluación formal producto no constituye certificación o

acreditación del sistema a ser utilizado en cualquier aplicación específica

ambiente. Por el contrario, el informe de evaluación sólo proporciona una confianza

Valoración de la evaluación del sistema informático junto con los datos que apoyan la descripción de la

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

punto de vista. La certificación de la seguridad del sistema y lo formal de aprobación / acreditación

procedimiento, realizado de acuerdo con las políticas aplicables de la emisión

agencias, aún debe ser un sistema puede ser aprobado para su uso antes seguidos

procesamiento o manejo de información clasificada [8, 9]. Designado Aprobar

Autoridades (Daas) siguen siendo en última instancia responsable de especificar la seguridad de

sistemas que acreditan.

Los criterios de evaluación sistema informático de confianza se pueden utilizar directamente y

indirectamente en el proceso de certificación. Junto con la política aplicable,

se utilizarán directamente como orientación técnica para la evaluación del sistema total

y para especificar los requisitos de seguridad del sistema y de certificación para la nueva

adquisiciones. ¿Dónde está evaluando un sistema para la certificación emplea un

producto que ha sido objeto de una evaluación del producto comercial, informa de que

proceso se utiliza como entrada para la evaluación de la certificación. Datos técnicos

será proporcionada a los diseñadores, evaluadores y la Aprobando Designado

Autoridades para apoyar sus necesidades de toma de decisiones.

Fundamentales Requisitos de Seguridad Informática

Cualquier discusión sobre la seguridad informática comienza necesariamente de una declaración de

requisitos, es decir, lo que realmente significa para llamar a un sistema informático "seguro".

En general, los sistemas seguros controlarán, a través del uso de la seguridad específica

características, el acceso a la información de tal manera que sólo se autoriza correctamente

individuos o procesos que operan en su nombre, tendrá acceso a la lectura,

escribir, crear o eliminar información. Seis requisitos fundamentales son

derivada de esta declaración básica de objetivo: cuatro se refieren a lo que hay

proporcionarse para controlar el acceso a la información; y dos tratan de cómo se puede

obtener garantías creíbles de que esto se logra en un equipo de confianza

sistema.

Política

Requisito 1 - POLÍTICA DE SEGURIDAD - No debe ser una explícita y

así definidos por la política de seguridad impuesta por el sistema. Sujetos identificados Dadas

y los objetos, debe haber una serie de reglas que son utilizados por el sistema para

determinar si un sujeto dado se puede permitir para obtener acceso a una específica

objeto. Los sistemas informáticos de interés deben hacer cumplir una política de seguridad obligatoria

que puede implementar de manera efectiva las reglas de acceso para el manejo sensible (por ejemplo,

. información clasificada) [7] Estas normas incluyen requisitos tales como: No

persona que carece de espacio libre apropiado de seguridad personal deberá tener acceso a

clasificado

información. Además, se requiere que los controles de seguridad discrecionales para

garantizar que los usuarios o grupos de usuarios seleccionados sólo se puede obtener acceso a los datos

(por ejemplo, sobre la base de una necesidad de saber).

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

con los objetos. Con el fin de controlar el acceso a información almacenada en un ordenador,

de acuerdo a las reglas de una política de seguridad obligatoria, debe ser posible

marcar todos los objetos con una etiqueta que identifica de forma fiable el objeto de

nivel de sensibilidad (por ejemplo, la clasificación), y / o los modos de acceso concedidos

aquellos sujetos que potencialmente pueden acceder al objeto.

Rendición de cuentas

Requisito 3 - IDENTIFICACIÓN - sujetos individuales deben ser

identificados. Cada acceso a la información debe estar mediada basa en quién es

el acceso a la información y qué clases de información que están autorizados

lidiar con. Esta información de identificación y autorización debe ser

firmemente mantenida por el sistema de ordenador y estar asociada con cada activo

elemento que realiza alguna acción relevante para la seguridad en el sistema.

Requisito 4 - RESPONSABILIDAD - La información de auditoría debe ser

guardado y protegido para que las acciones que afectan a la seguridad se pueden rastrear selectivamente

a la parte responsable. Un sistema de confianza deberá ser capaz de registrar la

ocurrencias de eventos relevantes para la seguridad en un registro de auditoría. La capacidad de

seleccionar los eventos de auditoría para ser registrados es necesario minimizar el gasto de

auditoría y para permitir el análisis eficiente. Los datos de auditoría deben ser protegidos de

modificación y destrucción no autorizada para permitir la detección y

investigaciones después de los hechos de violaciónes de seguridad.

Aseguramiento

Requisito 5 - GARANTÍA - El sistema informático debe contener

mecanismos de hardware / software que pueden ser evaluados de forma independiente para proporcionar

garantías suficientes de que el sistema impone requisitos 1 a 4 anteriores.

Con el fin de asegurar que los cuatro requisitos de la Política de Seguridad, Marcado,

Identificación, y rendición de cuentas son impuestas por un sistema informático, no

Debe haber alguna identificados y colección unificada de hardware y software

controles que realizan esas funciones. Estos mecanismos son típicamente incorporados

en el sistema operativo y están diseñados para llevar a cabo las tareas asignadas en un

manera segura. La base para confiar en este tipo de mecanismos del sistema en su

entorno operativo debe estar claramente documentado de tal manera que es posible

examinar de forma independiente las pruebas para evaluar su suficiencia.

Requisito 6 - Protección continua - Los mecanismos de confianza que

hacer cumplir estos requisitos básicos se deben proteger de forma continua contra

manipulación y / o cambios no autorizados. Ningún sistema informático puede ser considerado

realmente segura si los mecanismos básicos de hardware y software que hacen cumplir la

política de seguridad son a su vez objeto de modificaciones no autorizadas o

subversión. El requisito de protección continua tiene implicaciones directas

a lo largo del ciclo de vida del sistema informático.

Estos requisitos fundamentales forman la base para la evaluación individual

criterios aplicables para cada división de la evaluación y de clase. El interesado

Remitimos al lector a la Sección 5 de este documento, "Objetivos de Control para

Trusted Computer Systems, "para una discusión más completa y más

amplificación de estos requisitos fundamentales que se aplican a

sistemas de procesamiento de información y la Sección 7 para uso general

la amplificación de la relación entre política y estos requisitos.

Estructura del documento

El resto de este documento se divide en dos partes, cuatro apéndices y

un glosario. Parte I (Secciones 1 a la 4) presenta los criterios detallados

derivado de los requisitos fundamentales descritos anteriormente y relevante para el

fundamentos y políticas extractos contenidos en la Parte II.

Parte II (artículos 5 a 10) ofrece una discusión de los objetivos básicos,

razón de ser, y la política nacional detrás del desarrollo de los criterios y

directrices para desarrolladores relacionados con: las reglas de control de acceso obligatorio

aplicación, el problema canal secreto, y las pruebas de seguridad. Es

dividido en seis secciones. Sección 5 discute el uso de objetivos de control

en general, y presenta los tres objetivos básicos de control de los criterios.

Sección 6 proporciona la base teórica detrás de los criterios. Sección 7 da

extractos de pertinente reglamentos, directivas, circulares de la OMB, y Ejecutivo

Órdenes que proporcionan la base para muchos requisitos fiduciarios para procesamiento

información a nivel nacional sensible y clasificada con los sistemas informáticos.

Sección 8 proporciona orientación a los desarrolladores de sistemas en las expectativas en el trato

el problema canal encubierto. Sección 9 proporciona directrices tratar con

seguridad obligatoria. Sección 10 proporciona directrices para las pruebas de seguridad.

Hay cuatro apéndices, incluyendo una descripción de la Informática de confianza

Sistema de Productos Comerciales de Evaluación de proceso (Apéndice A), resúmenes de la

divisiones de evaluación (Apéndice B) y clases (Apéndice C), y, finalmente, una

directorio de los requisitos ordenados alfabéticamente. Además, hay una

glosario.

Estructura de los Criterios

Los criterios se dividen en cuatro divisiones: D, C, B y A ordenaron en un

de manera jerárquica con la división más alta (A) está reservado para los sistemas

proporcionando la seguridad más completa. Cada división representa un importante

mejora en la confianza general se puede colocar en el sistema para la

protección de la información sensible. Dentro de las divisiones C y B hay un

número de subdivisiones conocidas como clases. Las clases también se ordenan en un

de manera jerárquica con sistemas representante de la división C e inferior

clases de división B se caracterizan por el conjunto de la seguridad informática

mecanismos que poseen. Aseguramiento del correcto diseño y completa y

la implementación de estos sistemas se consigue principalmente a través de la prueba del

partes pertinentes del sistema de seguridad-. Las partes relevantes para la seguridad de

un sistema se hace referencia a lo largo de este documento como la Computación Confiable

Base (TCB). Sistemas representante de las clases más altas en la división B y

Una división de derivar los atributos de su seguridad más de su diseño y

estructura de ejecución. El aumento de la seguridad de que las características requeridas son

operativa, correcta y manipulaciones en todas las circunstancias se gana a través de

análisis cada vez más riguroso durante el proceso de diseño.

Dentro de cada clase, se abordan cuatro grandes conjuntos de criterios. El primero de tres

representar características necesarias para satisfacer los objetivos generales de control de

Política de Seguridad, Responsabilidad y Seguridad de que se discuten en la Parte II,

Sección 5. El cuarto set, Documentación, describe el tipo de escrito

pruebas en forma de guías de usuario, manuales, y la prueba y diseño

la documentación requerida para cada clase.

Un lector utilizando esta publicación por primera vez puede que le resulte útil

lea primero la parte II, antes de continuar con la Parte I.

?

PARTE I: LOS CRITERIOS

Destacando (MAYÚSCULAS) se utiliza en la primera parte para indicar criterios no contenía

en una clase inferior o cambios y adiciones a la ya definida criterios. Dónde

no hay resaltado, los requisitos han sido prorrogados del menor

clases sin adición o modificación.

?

1.0 DIVISIÓN D: protección mínima

Esta división contiene una sola clase. Se reserva para aquellos sistemas que

han sido evaluados, pero que no cumplen con los requisitos para una mayor

clase de evaluación.

?

2.0 DIVISIÓN C: PROTECCIÓN DISCRECIONAL

Las clases de esta división prevén (necesidad de conocer) la protección discrecional

y, a través de la inclusión de mecanismos de auditoría, para la rendición de cuentas

temas y las acciones que inician.

?

2.1 CLASE (C1): PROTECCIÓN DE SEGURIDAD DISCRECIONAL

La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente satisface

los requisitos de seguridad discrecionales al proporcionar separación de usuarios y

datos. Incorpora alguna forma de controles creíbles, capaces de hacer cumplir

limitaciones de acceso de forma individual, es decir, con el pretexto adecuado para

permitiendo a los usuarios para poder proteger a proyecto o información privada y

mantener a los demás usuarios de la lectura de forma accidental o la destrucción de sus datos. Los

Se espera que la clase (C1) el medio ambiente a ser uno de cooperar procesamiento usuarios

los datos en el mismo nivel (s) de la sensibilidad. Los siguientes son mínimos

requisitos para los sistemas asignados a (C1) habilitación de clase:

2.1.1 Política de Seguridad

2.1.1.1 Control de Acceso Discrecional

El TCB debe definir y controlar el acceso entre los usuarios con nombre y

objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP. Los

mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos, el acceso

listas de control) deberán permitir a los usuarios especificar y compartir el control

de esos objetos por personas nombradas o grupos definidos o ambos.

2.1.2 Rendición de Cuentas

2.1.2.1 Identificación y autenticación

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

comenzando a realizar cualquier otra acción que se espera que la TCB

para mediar. Además, la TCB utilizará un protegida

mecanismo (por ejemplo, contraseñas) para autenticar la identidad del usuario.

El TCB deberá proteger los datos de autenticación de modo que no puede ser

visitada por cualquier usuario no autorizado.

2.1.3 Aseguramiento

2.1.3.1 Aseguramiento Operacional

2.1.3.1.1 Arquitectura del Sistema

El TCB mantendrá un dominio para su propia ejecución

protege de interferencias externas o manipulación

(por ejemplo, por modificación de sus código o datos strucutres).

Recursos controlados por el TCB puede ser un subconjunto definido

de los sujetos y objetos en el sistema de ADP.

2.1.3.1.2 Sistema de Integridad

Características de hardware y / o software serán siempre que

se puede utilizar para validar periódicamente el funcionamiento correcto

de los elementos de hardware y firmware en el sitio de la TCB.

2.1.3.2 Ciclo de Vida de Garantía

2.1.3.2.1 Pruebas de seguridad

Los mecanismos de seguridad del sistema de ADP se ensayarán

y encontrado para trabajar como se reivindica en la documentación del sistema.

Los ensayos deben realizarse para asegurar que no hay obvia

formas para que un usuario no autorizado a pasar por alto o de otra manera

derrotar a los mecanismos de protección de la seguridad de la TCB.

(Vea las líneas directrices de ensayo de seguridad.)

2.1.4 Documentación

2.1.4.1 Funciones de seguridad Guía del usuario

Un único resumen, capítulo, o manual en la documentación del usuario

deberá describir los mecanismos de protección proporcionados por la TCB,

directrices sobre su uso, y cómo interactúan unos con otros.

2.1.4.2 Manual de Instalación de confianza

Un manual dirigido al administrador del sistema ADP deberá

presentes advertencias acerca de las funciones y privilegios que deberían ser

controlada al ejecutar una instalación segura.

Documentación 2.1.4.3 Prueba

El desarrollador del sistema proporcionará a los evaluadores un documento

que describe el plan de pruebas, procedimientos de prueba que muestran cómo el

los mecanismos de seguridad se pusieron a prueba, y los resultados del

pruebas funcionales mecanismos de seguridad.

2.1.4.4 Diseño de documentación

La documentación debe estar disponible que proporciona una descripción de

La filosofía de los fabricantes de protección y una explicación

de cómo esta filosofía se traduce en la TCB. Si el TCB

se compone de módulos distintos, las interfaces entre ellas

módulos se describen.

?

2.2 CLASE (C2): PROTECCIÓN DE ACCESO CONTROLADO

Sistemas de esta clase hacen cumplir un acceso discrecional más de grano fino

usuarios de control de sistemas (C1), por lo que individualmente responsables de su

acciones a través de los procedimientos de acceso, la auditoría de los eventos relevantes para la seguridad, y

aislamiento de recursos. Los siguientes son los requisitos mínimos para los sistemas

asignado a (C2) habilitación de clase:






listas de control) deberán permitir a los usuarios especificar y compartir el control

de esos objetos por personas nombradas, o grupos de definido

individuos, o por ambos, y proporcionarán los controles para limitar

propagación de los derechos de acceso. El control de acceso discrecional

mecanismo deberá, ya sea por acción explícita del usuario o por defecto,

establecen que los objetos están protegidos contra el acceso no autorizado.

Estos controles de acceso deberán ser capaces de incluir o excluir

el acceso a la granularidad de un único usuario. Permiso de acceso

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

sólo podrán ser asignadas por los usuarios autorizados.

2.2.1.2 Objeto Reutilización

Todas las autorizaciones de la información contenida dentro de un

objeto de almacenamiento será revocada antes de la asignación inicial,

la asignación o reasignación a un sujeto desde la piscina del TCB

de objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado

representaciones de información, producidos por un sujeto antes de

acciones es estar a disposición de cualquier objeto que obtiene acceso

a un objeto que se ha lanzado de nuevo al sistema.





para mediar. Además, la TCB utilizará un protegida

mecanismo (por ejemplo, contraseñas) para autenticar la identidad del usuario.

El TCB deberá proteger los datos de autenticación de modo que no puede ser

visitada por cualquier usuario no autorizado. El TCB deberá ser capaz de

hacer cumplir la responsabilidad individual, proporcionando la capacidad de

identificar de forma única a cada usuario del sistema ADP individual. El TCB

facilitará también la capacidad de asociar esta identidad

con todas las acciones que se pueden auditar tomadas por ese individuo.

2.2.2.2 Auditoría

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

modificación o acceso no autorizado o la destrucción de una auditoría

rastro de accesos a los objetos que protege. Los datos de auditoría

estarán protegidos por la TCB para que el acceso de lectura a la misma es

limitado a aquellos que están autorizados para los datos de auditoría. El TCB

será capaz de registrar los siguientes tipos de eventos: el uso de

mecanismos de identificación y autenticación, introducción o

objetos en el espacio de direcciones de un usuario (por ejemplo, el archivo abierto, el programa

iniciación), la supresión de los objetos, y las medidas adoptadas por

operadores de computadoras y administradores de sistemas y / o sistema de

oficiales de seguridad, y otros eventos relevantes de seguridad. Por

cada evento registrado, el registro de auditoría deberá identificar: fecha y

hora del evento, el usuario, el tipo de evento, y el éxito o el fracaso

del evento. Para eventos de identificación / autenticación las

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

registro de auditoría. Para los eventos que introducen un objeto en un usuario de

espacio de direcciones y para los eventos de deleción objeto el registro de auditoría

deberá incluir el nombre del objeto. El sistema de ADP

administrador podrá auditar selectivamente las acciones de

cualquier uno o más usuarios basados en la identidad individual.

2.2.3 Aseguramiento




que lo protege de las interferencias externas o manipulación

(por ejemplo, por modificación de sus estructuras de código o datos).


de los sujetos y objetos en el sistema de ADP. El TCB

deberá aislar los recursos a ser protegidas de manera que

están sujetos al control de acceso y auditoría

requisitos.









Los ensayos deben realizarse para asegurar que no hay obvia

formas para que un usuario no autorizado a pasar por alto o de otra manera

derrotar a los mecanismos de protección de la seguridad de la TCB.

El ensayo debe incluir también una búsqueda de defectos obvios que

permitiría violación del aislamiento de los recursos, o que lo haría

permitir el acceso no autorizado a la auditoría o la autenticación

datos. (Véanse las directrices de Pruebas de Seguridad.)









controlada al ejecutar una instalación segura. Los procedimientos para

examinar y mantener los archivos de auditoría, así como la

estructura de registro de auditoría detallado para cada tipo de evento de auditoría

se le dará.




mecanismos de seguridad se pusieron a prueba, y los resultados de la seguridad

pruebas funcionales mecanismos.






módulos se describen.

?

3.0 DIVISIÓN B: PROTECCIÓN OBLIGATORIA

La noción de un TCB que preserve la integridad de las etiquetas de sensibilidad y

los utiliza para hacer cumplir una serie de reglas de control de acceso obligatorio es un importante

requisito en esta división. Sistemas de esta división deben llevar el

sensibilidad etiquetas con las principales estructuras de datos en el sistema. El sistema

desarrollador también ofrece el modelo de la política de seguridad en la que se basa la TCB

y proporciona una especificación de la TCB. La evidencia debe ser proporcionada a

demostrar que el concepto de monitor de referencia ha sido implementado.

?

3.1 CLASE (B1): PROTECCIÓN DE SEGURIDAD CON ETIQUETAS

Sistemas (B1) Clase requieren todas las características requeridas para la clase (C2). En

Además, una declaración informal de la modelo de la política de seguridad, el etiquetado de datos,

y control de acceso obligatorio sobre los sujetos y objetos con nombre debe estar presente.

La capacidad debe existir para marcar con precisión la información exportada. Alguna

defectos identificados por pruebas deben ser removidos. Los siguientes son mínimos

requisitos para los sistemas asignados a (B1) habilitación de clase:




objetos con nombre (por ejemplo, archivos y programas) en el sistema de ADP.

El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,

listas de control de acceso) se permitirá a los usuarios especificar y control

compartir de esos objetos por las personas nombradas, o grupos definidos

de los individuos, o por ambos, y le facilitará los controles para limitar

propagación de los derechos de acceso. El control de acceso discrecional

mecanismo deberá, ya sea por acción explícita del usuario o por defecto,

establecen que los objetos están protegidos contra el acceso no autorizado.

Estos controles de acceso deberán ser capaces de incluir o excluir

el acceso a la granularidad de un único usuario. Permiso de acceso

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

sólo podrán ser asignadas por los usuarios autorizados.









3.1.1.3 Las etiquetas

Etiquetas de sensibilidad asociados con cada tema y almacenamiento

objeto bajo su control (por ejemplo, proceso, archivo, segmento, dispositivo)

será mantenida por el TCB. Estas etiquetas se utilizan como

la base para las decisiones de control de acceso obligatorios. A fin de que

importar datos no etiquetados, la TCB deberá solicitar y recibir de

un usuario autorizado el nivel de seguridad de los datos, y toda esa

las acciones deberán ser auditables por el TCB.

3.1.1.3.1 Label Integridad

Etiquetas de sensibilidad deberán representar con precisión la seguridad

niveles de los sujetos u objetos específicos con los que se

están asociados. Cuando exportado por el TCB, la sensibilidad

la etiqueta incluirá la precisión y sin ambigüedades representar el

etiquetas internas y estará asociada a la

información que se exporta.

3.1.1.3.2 Exportación de Información Etiquetada

El TCB designará cada canal de comunicación y

Yo dispositivo de E / S, ya sea a nivel individual o miltilevel. Alguna

cambio en esta designación se realiza de forma manual y

será auditable por el TCB. El TCB mantendrá

y ser capaz de auditar a cualquier cambio en el nivel de seguridad

o los niveles asociados con un canal de comunicación o

Dispositivo de E / S.

3.1.1.3.2.1 La exportación a dispositivos multinivel

Cuando la TCB exporta un objeto a un multinivel I / O

dispositivo, la etiqueta sensibilidad asociada con ese

objeto también se exportará y deberá residir en

el mismo medio físico como el exportado

información y se hará de la misma forma

(es decir, legible por máquina o en forma legible).

Cuando la TCB exporta o importa un objeto durante un

canal de comunicación de múltiples niveles, el protocolo

utilizado en ese canal deberá prever la

vinculación inequívoca entre las etiquetas de sensibilidad

y la información asociada que se envía o

recibido.

3.1.1.3.2.2 Exportación a solo nivel-Devices

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

los canales de comunicación no están obligados a

mantener las etiquetas de sensibilidad de la información

que procesan. Sin embargo, la TCB incluirá una

mecanismo por el cual la TCB y un usuario autorizado

comunicar de forma confiable para designar la única

nivel de seguridad de la información importado o exportado

a través de los canales de comunicación de un solo nivel o de E / S

dispositivos.

3.1.1.3.2.3 salida etiquetado legible

El administrador del sistema ADP deberá ser capaz de

especificar los nombres de las etiquetas imprimibles asociados a

etiquetas de sensibilidad exportados. El TCB marcará

el principio y el fin de toda paginado legible,,

salida en papel (por ejemplo, la salida de impresora de líneas) con

etiquetas de sensibilidad legibles que correctamente *

representar la sensibilidad de la salida. El TCB

será, será por defecto, marque la parte superior e inferior de cada

página de la salida legible, paginado, en papel

(por ejemplo, impresora de línea de salida) con legible

etiquetas de sensibilidad que correctamente * representan la

sensibilidad global de la salida o que correctamente *

representar la sensibilidad de la información sobre la

página. El TCB deberá, por defecto y en un

de manera adecuada, marcar otras formas de humanidad

salida legible (por ejemplo, mapas, gráficos) con humanidad


representar la sensibilidad de la touput. Alguna

anulación de estos incumplimientos marcado será

auditable por el TCB.

3.1.1.4 Control de Acceso Obligatorio

El TCB deberá aplicar una política de control de acceso obligatorio sobre

todas las materias y objetos de almacenamiento bajo su control (por ejemplo,

procesos, archivos, segmentos, dispositivos). Estos temas y

objetos se les asignará etiquetas de sensibilidad que son un

combinación de niveles jerárquicos de clasificación y

categorías no jerárquica, y las etiquetas se utilizan como

la base para las decisiones de control de acceso obligatorios. El TCB

deberá ser capaz de soportar dos o más de tales niveles de seguridad.

(Vea las pautas para el control de acceso obligatorio). El siguiente

requisitos permanecerán en para todos los accesos entre sujetos y

objetos controlados por el TCB: un tema pueden leer un objeto

sólo si la clasificación jerárquica en el tema de

nivel de seguridad es mayor o igual a la jerárquica

clasificación en el nivel de seguridad del objeto y de la no-

categorías jerárquicas en el nivel de seguridad del sujeto incluyen

todas las categorías no jerárquicas en la seguridad del objeto

nivel. Un sujeto puede escribir un objeto sólo si el jerárquica

clasificación en el nivel de seguridad del sujeto es inferior o

igual a la clasificación jerárquica en el objeto de

nivel de seguridad y todas las categorías no jerárquicas en la

nivel de seguridad del sujeto se incluyen en el no-jerárquica

categorías en el nivel de seguridad del objeto. Identificación

y los datos de autenticación se utilizarán por el TCB para autenticarse

Cate la identidad del usuario y para asegurar que el nivel de seguridad

y la autorización de los sujetos externo a la TCB que puede ser

creado para actuar en nombre de cada usuario están dominadas

por la liquidación y la ordenación de ese usuario.





para mediar. Además, la TCB deberá mantener la autenticación

datos que incluye información para la verificación de la identidad de

los usuarios individuales (por ejemplo, contraseñas), así como información para

la determinación de la compensación y las autorizaciones o individuo

_____________________________

* El componente de clasificación jerárquica de la sensibilidad legible

etiquetas serán iguales a la mayor clasificación jerárquica o cualquiera de los

información en la salida que las etiquetas se refieren a; la no-jerárquica

componente categoría incluirá todas las categorías no jerárquicas de la

información en la salida de las etiquetas se refieren a, pero ningún otro no jerárquica

categorías.

usuarios. Estos datos podrán ser utilizados por la TCB para autenticar el

la identidad del usuario y para asegurar que el nivel de seguridad y

autorizaciones de sujetos externos a la TCB que puede ser


por la liquidación y la ordenación de ese usuario. El TCB deberá

proteger los datos de autenticación de modo que no se puede acceder por cualquier

usuario no autorizado. El TCB será capaz de hacer cumplir individuo

la rendición de cuentas, proporcionando la capacidad para identificar de forma única

cada usuario del sistema ADP individual. El TCB facilitará asimismo a la

capacidad de asociar esta identidad con toda auditable

medidas adoptadas por ese individuo.

3.1.2.2 Auditoría







mecanismos de identificación y autenticación, la introducción de


iniciación), la supresión de los objetos, y las medidas adoptadas por el ordenador

operadores y administradores de sistemas y / o la seguridad del sistema

oficiales y otros eventos relevantes de seguridad. El TCB deberá también

ser capaz de auditar cualquier anulación de las marcas de salida legibles.

Para cada evento registrado, el registro de auditoría deberá identificar: Fecha

y la hora del evento, el usuario, el tipo de evento, y el éxito o

fracaso del evento. Para eventos de identificación / autenticación

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

el registro de auditoría. Para los eventos que introducen un objeto en un

espacio de direcciones del usuario y para eventos de eliminación de objetos de la auditoría

expediente deberá incluir el nombre del objeto y el objeto de

nivel de seguridad. El administrador del sistema ADP deberá ser capaz de

auditar de forma selectiva las medidas adoptadas por uno o más usuarios en función de

identidad individual y / o el nivel de seguridad de objetos.

3.1.3 Aseguramiento







de los sujetos y objetos en el sistema de ADP. El TCB

deberá mantener el aislamiento de procesos a través de la provisión de

espacios de direcciones distintas bajo su control. El TCB deberá

aislar los recursos para estar protegidos de manera que sean

sujeto al control de acceso y los requisitos de auditoría.









Un equipo de personas que entienden a fondo la

aplicación específica de la TCB someterá su

documentación de diseño, código fuente y el código objeto para

análisis y pruebas exhaustivas. Sus objetivos serán:

para descubrir todos los defectos de diseño y de ejecución que

permitir que un objeto externo a la TCB para leer, cambiar o

delete normalmente datos negados bajo el obligatorio o

política de seguridad discrecional impuesta por la TCB; así como

que se asegure de que ningún objeto (sin autorización hacer

de modo) es capaz de hacer que el TCB para entrar en un estado tal que

es incapaz de responder a las comunicaciones iniciadas por

otros usuarios. Todos los defectos descubiertos serán removidos o

neutraliza y el TCB repetir la prueba para demostrar que

se han eliminado y que los nuevos defectos no han sido

introducido. (Vea las líneas directrices de ensayo de seguridad.)

3.1.3.2.2 Especificaciones de Diseño y Verificación

Un modelo formal o informal de la política de seguridad

el apoyo de la TCB se mantendrá durante la vida

ciclo del sistema ADP y ha demostrado ser consistente

con sus axiomas.












se le dará. El manual deberá describir el operador y

funciones de administrador relacionados con la seguridad, que incluyen el cambio

las características de seguridad de un usuario. Facilitará

directrices sobre el uso coherente y eficaz de la protección

características del sistema, cómo interactúan, la forma de forma segura

generar un nuevo TCB, y procedimientos de las instalaciones, las advertencias, y

privilegios que necesitan ser controladas con el fin de operar el

instalación de una manera segura.











módulos se describen. Una descripción informal o formal

del modelo de política de seguridad aplicada por el TCB será

disponibles y una explicación proporcionada a demostrar que es

suficiente para hacer cumplir la política de seguridad. El TCB específica

mecanismos de protección deben ser identificados y una explicación

dado para demostrar que satisfacen el modelo.

?

3.2 CLASE (B2): PROTECCIÓN ESTRUCTURADO

En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y documentado

modelo de política de seguridad formal que requiere el discrecional y obligatorio

la aplicación de control de acceso que se encuentra en los sistemas (B1) de clase se extenderá a todos

sujetos y objetos en el sistema de ADP. Además, los canales encubiertos son

abordarse. El TCB debe estructurarse con cuidado en la protección-crítico y

elementos de protección crítico no. La interfaz de TCB está bien definido y de la

Diseño e implementación TCB permiten que pueda ser sometido a más exhaustiva

pruebas y revisión más completa. Mecanismos de autenticación se fortalecen,

la gestión de instalaciones de confianza se proporciona en forma de soporte para el sistema

funciones de administrador y operador, y gestión de la configuración estrictas

se imponen controles. El sistema es relativamente resistente a la penetración. Los

siguientes son los requisitos mínimos para los sistemas asignados a (B2) habilitación de clase:





El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,


compartir de esos objetos por las personas nombradas, o definido

grupos de individuos, o por ambos, y proporcionarán los controles

para limitar la propagación de los derechos de acceso. El acceso discrecional

mecanismo de control deberá, ya sea por acción explícita del usuario o por

De forma predeterminada, se establece que los objetos están protegidos de la no autorizada

el acceso. Estos controles de acceso deberán ser capaces de incluir

o excluir el acceso a la granularidad de un único usuario.

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

permiso de acceso sólo podrá ser cedido por los usuarios autorizados.




la asignación o reasignación a un sujeto desde la piscina del TCB de

objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado





Etiquetas de sensibilidad asociados con cada recurso del sistema ADP

(por ejemplo, el asunto objeto de almacenamiento, ROM) que es directa o

indirectamente accesible por sujetos ajenos a la TCB será

mantenida por el TCB. Estas etiquetas se utilizan como base

para las decisiones de control de acceso obligatorios. Para importar

datos no etiquetados, la TCB deberán solicitar y recibir de un

usuario autorizado el nivel de seguridad de los datos, y toda esa




niveles de los temas específicos u objetos con los que

están asociados. Cuando exportado por el TCB,

etiquetas de sensibilidad deberá precisión y sin ambigüedades

representar las etiquetas internas y estará asociada

con que se exporta la información.



Yo dispositivo de E / S, ya sea a nivel individual o de múltiples niveles. Alguna











información y se hará de la misma forma (es decir,

legible por máquina o en forma legible). Cuando

la TCB exporta o importa un objeto durante un





recibido.




mantener las etiquetas de sensibilidad de la

información que procesan. Sin embargo, la TCB deberá

incluir un mecanismo por el cual el TCB y una

usuario autorizado comunicar de forma fiable para designar

el nivel de seguridad única de información importada

o exportados a través de la comunicación de un solo nivel

los canales o dispositivos de E / S.









será, por defecto, marque la parte superior e inferior de cada




sensibilidad global de la salida o que

* representar adecuadamente la sensibilidad de la

información en la página. El TCB, a más tardar

por defecto y de manera apropiada, marque otra

formas de salida legible por humanos (por ejemplo, mapas,

gráficos) con etiquetas de sensibilidad legibles

que adecuadamente * representan la sensibilidad de la

de salida. Cualquier anulación de estos incumplimientos marcado

será auditable por el TCB.

3.2.1.3.3 Asunto etiquetas de sensibilidad

El TCB notificará inmediatamente a un usuario del terminal de cada

cambio en el nivel de seguridad asociado a ese usuario

durante una sesión interactiva. Un usuario del terminal será

capaz de consultar la TCB como se desee para una visualización de la

etiqueta de sensibilidad completa del tema.

3.2.1.3.4 Las etiquetas de dispositivo

El TCB apoyará la asignación de mínima y

niveles de máxima seguridad a todos los dispositivos físicos conectados.

Estos niveles de seguridad deberán ser utilizados por el TCB para hacer cumplir

las restricciones impuestas por el entorno físico en el que

los dispositivos se encuentran.



todos los recursos (por ejemplo, temas, objetos de almacenamiento, y dispositivos de E / S

que estén directa o indirectamente accesible por temas externos

a la TCB. Estos sujetos y objetos se asignarán

etiquetas de sensibilidad que son una combinación de jerárquica

niveles de clasificación y categorías no jerárquicas, y la

etiquetas se utilizan como base para el control de acceso obligatorio

decisiones. El TCB deberá ser capaz de soportar dos o más de tales

los niveles de seguridad. (Véanse las directrices de control de acceso obligatorios.)

Los siguientes requisitos deberán mantener durante todos los accesos entre

Todos los sujetos externos a la TCB y todos los objetos directamente o

indirectamente accesible por estos temas: Un sujeto puede leer un

objetar sólo si la clasificación jerárquica en el tema de

nivel de seguridad es mayor o igual a la jerárquica

clasificación en el nivel de seguridad del objeto y de la no-

categorías jerárquicas en el nivel de seguridad del sujeto incluyen

todas las categorías no jerárquicas en la seguridad del objeto

nivel. Un sujeto puede escribir un objeto sólo si el jerárquica

clasificación en el nivel de seguridad del sujeto es inferior o

igual a la clasificación jerárquica en el objeto de



categorías en el nivel de seguridad del objeto. Identificación y

datos de autenticación se utilizarán por el TCB para autenticar


autorización de los sujetos externo a la TCB que puede ser


por la liquidación y la ordenación de ese usuario.








la determinación de la compensación y las autorizaciones de individuo




creado para actuar en nombre del usuario individual están dominadas por

la liquidación y autorización de ese usuario. El TCB deberá







3.2.2.1.1 Camino de confianza

El TCB apoyará una ruta de comunicación de confianza

entre él mismo y el usuario de inicio de sesión inicial y

autenticación. Comunicaciones a través de este camino serán

iniciado exclusivamente por un usuario.

3.2.2.2 Auditoría











oficiales y otros eventos relevantes de seguridad. El TCB deberá

También podrá auditar cualquier anulación de la salida legible

marcas. Para cada evento registrado, el registro de auditoría,

identificar: fecha y hora del evento, el usuario, el tipo de evento, y

éxito o el fracaso del evento. Para la identificación /

eventos de autenticación del origen de la solicitud (por ejemplo, la terminal de Identificación)

se incluirán en el registro de auditoría. Para los eventos que

introducir un objeto en el espacio de direcciones de un usuario y para el objeto

eventos de eliminación del registro de auditoría deberán incluir el nombre de la

objeto y nivel de seguridad del objeto. El sistema de ADP


cualquier uno o más usuarios en base a la identidad y / o objeto individual

nivel de seguridad. El TCB podrá auditar el identificada

eventos que se pueden utilizar en la explotación de almacenamiento encubierta

canales.

3.2.3 Aseguramiento






El TCB deberá mantener el aislamiento de procesos a través de la

provisión de espacios de direcciones distintas bajo su control.

La TCB se estructurará internamente en bien definido

módulos en gran medida independientes. Se hará uso efectivo

de hardware disponible para separar aquellos elementos que son

protección-crítico de los que no lo son. El TCB

módulos deberán estar diseñados de tal manera que el principio de mínima

privilegio se hace cumplir. Características de hardware, tales como

segmentación, se utilizará para apoyar lógicamente distinta

objetos de almacenamiento con atributos diferentes (a saber:

lectura, escritura). La interfaz de usuario a la TCB

deberá estar totalmente definido y todos los elementos de la TCB

identificados.



se puede utilizar para validar periódicamente el correcto

funcionamiento de los elementos de hardware y firmware en el sitio

del TCB.

3.2.3.1.3 Análisis Canal Covert

El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para

canales de almacenamiento encubiertas y tomar una determinación (ya sea

por medición real o por estimación de ingeniería) de

el máximo ancho de banda de cada canal identificado. (Véase

la sección encubierta canales guía.)

3.2.3.1.4 Gestión de Instalaciones de confianza

El TCB apoyará operador independiente y administrador

funciones.








análisis y pruebas exhaustivas. Sus objetivos serán:

para descubrir todos los defectos de diseño y de ejecución que

permitir que un objeto externo a la TCB para leer, cambiar o

delete normalmente datos negados bajo el obligatorio o

política de seguridad discrecional impuesta por la TCB; así como

que se asegure de que ningún objeto (sin autorización hacer

de modo) es capaz de hacer que el TCB para entrar en un estado tal que se

es incapaz de responder a las comunicaciones iniciadas por otra

usuarios. El TCB se encuentra relativamente resistentes a la

penetración. Todos los defectos detectados serán corregidos y

la TCB repetir la prueba para demostrar que han sido

eliminados y no se han introducido que los nuevos defectos.

El ensayo debe demostrar que la aplicación TCB es

consistente con la memoria descriptiva de nivel superior.

(Vea las líneas directrices de ensayo de seguridad.)


Un modelo formal de la política de seguridad con el apoyo de la

TCB se mantiene a lo largo del ciclo de vida de la ADP

sistema que se ha demostrado en consonancia con sus axiomas. LA

memoria descriptiva de nivel superior (DTLS) de la TCB

se sostuvo que completa y precisa

describe la TCB en términos de excepciones, mensajes de error,

y efectos. Queda demostrado ser un exacto

Descripción de la interfaz de TCB.

Gestión de la Configuración 3.2.3.2.3

Durante el desarrollo y mantenimiento de la TCB, una

sistema de gestión de la configuración será en el lugar que

mantiene el control de cambios en el nivel superior descriptiva

especificación, otros datos de diseño, implementación

documentación, código fuente, el funcionamiento del versiónde

código objeto, y accesorios de la prueba y la documentación. Los

sistema de gestión de la configuración deberá asegurar una coherente

mapeo entre toda la documentación y el código asociado con

la versión actual de la TCB. Herramientas se proporcionarán

para la generación de una nueva versión de la TCB de la fuente

código. También disponible serán herramientas para la comparación de una

versión recién generada con la versión anterior TCB en

Para asegurarse de que sólo los cambios previstos tienen

ha logrado en el código que realmente se utiliza como

nueva versión de la TCB.













funciones de administrador relacionados con la seguridad, que incluyen

el cambio de las características de seguridad de un usuario. Incluirá

proporcionar directrices sobre el uso coherente y eficaz de la

características de protección del sistema, cómo interactúan, cómo

segura de generar una nueva TCB, y procedimientos de las instalaciones, las advertencias,

y los privilegios que necesitan ser controlados con el fin de operar

la instalación de un modo seguro. Los módulos de TCB que contienen

deberá identificarse el mecanismo de validación de referencia. Los

procedimientos para la generación segura de un nuevo TCB de la fuente después

Se describirá la modificación de cualquiera de los módulos en el TCB.





pruebas funcionales mecanismos. Incluirá resultados de

probar la eficacia de los métodos utilizados para reducir encubierta

anchos de banda de canal.




de cómo esta filosofía se traduce en la TCB. Los

Se describirán las interfaces entre los módulos de TCB. LA

descripción formal del modelo de política de seguridad aplicada por el

TCB deberá estar disponible y demostrado que es suficiente para

hacer cumplir la política de seguridad. La protección específica TCB

mecanismos deberán ser identificados y una explicación dan para mostrar

que cumplan el modelo. El alto nivel descriptivo

especificación (DTLS) se muestra como una precisa

Descripción de la interfaz de TCB. La documentación debe describir

cómo el TCB implementa el concepto monitor de referencia y dar

una explicación por qué es resistente a la manipulación, no puede ser anulada,

y se ha implementado correctamente. La documentación debe describir cómo

la TCB está estructurado para facilitar las pruebas y hacer cumplir menos

privilegio. Esta documentación deberá presentar también los resultados

del análisis canal encubierto y las compensaciones involucradas en

restringiendo los canales. Todos los eventos auditables que pueden ser

utilizado en la explotación de canales de almacenamiento encubiertas conocidas deberá

ser identificado. Los anchos de banda de los canales de almacenamiento encubiertas conocidas

cuyo uso no es detectable por los mecanismos de auditoría,

se facilitará. (Vea la sección de Orientación del canal Covert.)

?

3.3 CLASE (B3): DOMINIOS DE SEGURIDAD

La clase (B3) TCB debe satisfacer los requisitos del monitor de referencia que

mediar en todos los accesos de los sujetos a los objetos, será inviolable, y ser pequeño

suficiente para ser sometidos a análisis y pruebas. Para este fin, la TCB es

estructurado para excluir el código no es esencial para la aplicación de la política de seguridad, con

ingeniería de sistemas significativa durante el diseño y la aplicación dirigida TCB

para minimizar su complejidad. Un administrador de seguridad es compatible,

mecanismos de auditoría se expanden para señalar acontecimientos seguridad- pertinentes, y el sistema

se requieren procedimientos de recuperación. El sistema es altamente resistente a

penetración. Los siguientes son los requisitos mínimos para los sistemas asignado un

clase (B3) Valoración:





El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá

permiten a los usuarios especificar y compartir el control de esos objetos,

y proporcionará controles para limitar la propagación de acceso

los derechos. El mecanismo de control de acceso discrecional deberá,

ya sea por acción explícita del usuario o por defecto, disponer que

objetos están protegidos contra el acceso no autorizado. Estos acceso

controles deberán ser capaces de especificar, para cada objeto nombrado,

una lista de personas con nombre y una lista de los grupos de llamada

individuos con sus respectivos modos de acceso a ese

objeto. Además, para cada uno de tales objeto nombrado, será

posible especificar una lista de personas con nombre y una lista de

grupos de individuos nombrados para la que no tiene acceso al objeto es

que debe darse. El permiso de acceso a un objeto no usuarios

ya que posee permiso de acceso sólo podrá ser cedido por

los usuarios autorizados.





de objetos de almacenamiento no utilizados. No hay información, incluyendo

representaciones cifrados de información, producidos por una previa

las acciones de los sujetos es estar a disposición de cualquier tema que obtiene

el acceso a un objeto que se ha lanzado de nuevo al sistema.





































recibido.










dispositivos.









todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S

dispositivos) que están directa o indirectamente accesible por temas

externo a la TCB. Estos sujetos y objetos serán

etiquetas de sensibilidad asignados que son una combinación de

niveles de clasificación jerárquica y no jerárquica

categorías y las etiquetas se utilizan como base para

las decisiones de control de acceso obligatorios. El TCB deberá ser capaz de

el apoyo de dos o tales niveles más seguridad. (Vea la obligatoria

______________________________


etiquetas serán iguales a la mayor clasificación jerárquica de cualquiera de los




categorías.

Directrices de control de acceso.) Las siguientes condiciones se

mantener durante todos los accesos entre todos los sujetos externos a la TCB

y todos los objetos directamente o indirectamente accesible por éstos

temas: Un sujeto puede leer un objeto sólo si el jerárquica

clasificación en el nivel de seguridad del sujeto es mayor que

o igual a la clasificación jerárquica en el objeto de

nivel de seguridad y las categorías no jerárquicas en la

nivel de seguridad del sujeto incluye todos los no-jerárquica

categorías en el nivel de seguridad del objeto. Un sujeto puede escribir

un objeto sólo si la clasificación jerárquica en el

nivel de seguridad del sujeto es inferior o igual a la

clasificación jerárquica en el nivel de seguridad del objeto y

todas las categorías no jerárquicas en la seguridad del sujeto

nivel se incluyen en las categorías jerárquicas no en el

nivel de seguridad del objeto. Identificación y autentificación

datos serán utilizados por el TCB para autenticar al usuario de

identidad y para asegurar que el nivel de seguridad y autorización

zación de los sujetos externos a la TCB que se puede crear

para actuar en nombre de cada usuario están dominadas por el

aclaramiento y la autorización de dicho usuario.











autorizaciones de subjectsexternal a la TCB que puede ser


por la liquidación y la ordenación de ese usuario. El TCB deberá









entre ella misma y los usuarios para el uso cuando un TCB-a-positivo

Se requiere conexión de usuario (por ejemplo, inicio de sesión, cambio de tema

nivel de seguridad). Comunicaciones a través de este camino de confianza

deberá ser activado exclusivamente por un usuario de la TCB y

deberán estar aislados de manera lógica y sin lugar a dudas

distinguible de otros caminos.

3.3.2.2 Auditoría











oficiales y otros eventos relevantes de seguridad. El TCB deberá también

ser capaz de auditar cualquier anulación de las marcas de salida legibles.

Para cada evento registrado, el registro de auditoría deberá identificar: Fecha

y la hora del evento, el usuario, el tipo de evento, y el éxito o

fracaso del evento. Para eventos de identificación / autenticación

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

el registro de auditoría. Para los eventos que introducen un objeto en un

espacio de direcciones del usuario y para eventos de eliminación de objetos de la auditoría

expediente deberá incluir el nombre del objeto y el objeto de

nivel de seguridad. El administrador del sistema ADP deberá ser capaz de


identidad individual y / o el nivel de seguridad de objetos. El TCB deberá

ser capaz de auditar los eventos identificados que se pueden utilizar en el

explotación de los canales de almacenamiento encubiertas. El TCB contendrá

un mecanismo que es capaz de monitorear la ocurrencia o

acumulación de eventos auditables de seguridad que puedan indicar una

inminente violación de la política de seguridad. Este mecanismo será

capaz de notificar inmediatamente al administrador de seguridad cuando

umbrales se superan, y si la aparición o acumulación

de estos eventos relevantes de seguridad continúa, el sistema deberá

tomar las medidas menos perjudiciales para dar por terminado el evento.

3.3.3 Aseguramiento












módulos deberán estar diseñados de tal manera que el principio de

privilegio menos se cumple. Características de hardware, tales

como la segmentación, se utilizarán para apoyar lógicamente

objetos de almacenamiento distintas con atributos diferentes (a saber:

lectura, escritura). La interfaz de usuario a la TCB deberá

ser totalmente definido y todos los elementos de la TCB

identificados. El TCB estará diseñado y estructurado para

utilizar un mecanismo de protección completa, conceptualmente simple

con semántica definida con precisión. Este mecanismo deberá

desempeñar un papel central en la aplicación de la estructuración interna

del TCB y el sistema. El TCB incorporará

uso significativo de la estratificación, la abstracción y la ocultación de datos.

Ingeniería de sistemas significativos se dirige hacia

minimizar la complejidad de la TCB y se excluyen de la

los módulos de TCB que no son de protección crítico.





del TCB.



canales encubiertos y tomar una determinación (ya sea por

medición real o por estimación de ingeniería) de la

máximo ancho de banda de cada canal identificado. (Vea el

Sección Orientación Canales Covert.)



funciones. Las funciones realizadas en el papel de una

se identificará administrador de seguridad. La ADP

personal administrativo del sistema sólo podrán

realizar funciones de administrador de seguridad después de tomar una

acción auditable distinta a asumir la seguridad

función de administrador en el sistema ADP. No la seguridad

funciones que se pueden realizar en la seguridad

rol de administración se limitará estrictamente a los

esencial para la realización de la función de seguridad efectiva.

3.3.3.1.5 Recuperación de confianza

Procedimientos y / o mecanismos se proporcionarán para asegurar

que, después de un fallo del sistema ADP u otra discontinuidad,

se obtiene la recuperación sin un compromiso de protección.








análisis y pruebas exhaustivas. Sus objetivos deberán

ser: para descubrir todos los defectos de diseño e implementación que

permitiría un sujeto externo a la TCB de leer,

cambiar o eliminar datos normalmente negados bajo el

política de seguridad obligatoria o discrecional impuesta por

la TCB; así como para asegurar que ningún objeto (sin

autorización para hacerlo) es capaz de hacer que el TCB para entrar

un estado tal que es incapaz de responder a

comunicaciones iniciadas por otros usuarios. El TCB deberá

se encuentran resistente a la penetración. Todos los defectos descubiertos

será corregido y el TCB vuelto a probar para demostrar

que han sido eliminados y que los nuevos defectos tener

no se han introducido. El ensayo debe demostrar que el

Aplicación TCB es consistente con la descriptiva

especificación de nivel superior. (Vea la Prueba de Seguridad

Lineamientos.) No hay defectos de diseño y no más de unos pocos

fallas de implementación corregibles pueden encontrarse en

probando y no habrá confianza razonable de que

pocos permanecen.








y efectos. Queda demostrado ser un exacto

Descripción de la interfaz de TCB. Un argumento convincente

habrá de darse que el DTLS es consistente con el modelo.


Durante el desarrollo y mantenimiento de la TCB, una

sistema de gestión de la configuración será en el lugar que

mantiene el control de cambios en el nivel superior descriptiva

especificación, otros datos de diseño, implementación

documentación, código fuente, la versión de funcionamiento de la

código objeto, y accesorios de la prueba y la documentación. Los

sistema de gestión de la configuración deberá asegurar una coherente

mapeo entre toda la documentación y el código asociado con

la versión actual de la TCB. Herramientas se proporcionarán

para la generación de una nueva versión de la TCB de la fuente

código. También disponible serán herramientas para la comparación de una

versión recién generada con la versión anterior TCB en

Para asegurarse de que sólo los cambios previstos tienen

ha logrado en el código que realmente se utiliza como

nueva versión de la TCB.






















Se describirá la modificación de cualquiera de los módulos en el TCB. Ello

incluirá los procedimientos para garantizar que el sistema es

comenzado inicialmente en una manera segura. Los procedimientos deberán ser también

incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en

operación del sistema.







anchos de banda de canal.










que cumplan el modelo. El alto nivel descriptivo

especificación (DTLS) se muestra como una precisa

Descripción de la interfaz de TCB. La documentación debe describir

cómo el TCB implementa el concepto monitor de referencia y dar

una explicación por qué es resistente a la manipulación, no puede ser anulada,

y se ha implementado correctamente. La implementación TCB (es decir, en

hardware, firmware y software) se muestran de manera informal a

ser coherente con los DTLS. Los elementos de la DTLS serán

se muestra, usando técnicas informales, para corresponder a los elementos

del TCB. La documentación debe describir cómo el TCB es

estructurado para facilitar las pruebas y hacer cumplir privilegios mínimos.

Esta documentación deberá presentar también los resultados de la encubierta

análisis de canal y las ventajas y desventajas implicadas en la restricción de la

canales. Todos los eventos auditables que se pueden utilizar en el

explotación de canales de almacenamiento encubiertas conocidas será

identificados. Los anchos de banda de los canales de almacenamiento encubiertas conocidas,



?

4.0 DIVISIÓN A: PROTECCIÓN VERIFICADO

Esta división se caracteriza por el uso de la verificación de seguridad formal

métodos para asegurar que los controles de seguridad obligatorios y discrecionales

empleado en el sistema puede proteger eficazmente clasificado u otro sensible

información almacenada o procesada por el sistema. Amplia documentación es

requerida para demostrar que la TCB cumple con los requisitos de seguridad en todo

aspectos de diseño, desarrollo e implementación.

?

4.1 CLASE (A1): DISEÑO VERIFICADO

Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3) en

que no se añaden características arquitectónicas adicionales o requisitos de la política.

La característica distintiva de los sistemas de esta clase es el análisis derivado

desde la especificación de diseño formal y técnicas de verificación y la resultante

alto grado de seguridad de que la TCB se implementa correctamente. Esta

aseguramiento del desarrollo es en la naturaleza, a partir de un modelo formal de la

la política de seguridad y una especificación de alto nivel formales (FTLs) del diseño.

Independiente del lenguaje de especificación en particular o sistema de verificación

utilizado, hay cinco criterios importantes para la clase (A1) la verificación del diseño:

* Un modelo formal de la política de seguridad debe ser claramente

identificado y documentado, incluyendo una prueba matemática

que el modelo es consistente con sus axiomas y es

suficiente para apoyar la política de seguridad.

* Un FTLs debe ser producido que incluye definiciones abstractas

de las funciones de la TCB realiza y del hardware y / o

mecanismos de firmware que se utilizan para apoyar separada

dominios de ejecución.

* Los FTLs de la TCB deben demostrarse que son consistentes con la

modelo mediante técnicas formales cuando sea posible (es decir, donde

herramientas de verificación de existir) y las informales de otra manera.

* La implementación TCB (es decir, en hardware, firmware, y

software) debe demostrar de manera informal para ser coherente con la

FTLs. Los elementos de los FTLs deben mostrarse, usando

técnicas informales, que corresponden a los elementos de la

TCB. Los FTLs deben expresar el mecanismo de protección unificada

necesario para satisfacer la política de seguridad, y es el

elementos de este mecanismo de protección que se asignan a la

elementos de la TCB.

* Técnicas de análisis formal se deben utilizar para identificar y

analizar los canales encubiertos. Técnicas informales pueden ser utilizados para

identificar los canales de temporización encubiertas. La persistencia de

canales encubiertos identificadas en el sistema deben estar justificadas.

De acuerdo con el análisis extenso de diseño y desarrollo de la TCB

requerida de los sistemas en la clase (A1), gestión de la configuración es más estricta

requeridos y se establezcan procedimientos para la distribución segura del sistema

a los sitios. Un administrador de la seguridad del sistema es compatible.

Los siguientes son los requisitos mínimos para los sistemas asignados a una clase (A1)

Puntuación:





El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá

permiten a los usuarios especificar y compartir el control de esos objetos,

y proporcionará controles para limitar la propagación de acceso

los derechos. El mecanismo de control de acceso discrecional deberá,

ya sea por acción explícita del usuario o por defecto, disponer que

objetos están protegidos contra el acceso no autorizado. Estos acceso

controles deberán ser capaces de especificar, para cada objeto nombrado,

una lista de personas con nombre y una lista de los grupos de llamada

individuos con sus respectivos modos de acceso a ese

objeto. Además, para cada uno de tales objeto nombrado, será

posible especificar una lista de personas con nombre y una lista de

grupos de individuos nombrados para la que no tiene acceso al objeto es

que debe darse. El permiso de acceso a un objeto no usuarios

ya que posee permiso de acceso sólo podrá ser cedido por

los usuarios autorizados.













































recibido.










dispositivos.




































todos los recursos (es decir, sujetos, objetos de almacenamiento y E / S

dispositivos) que están directa o indirectamente accesible por temas

externo a la TCB. Estos sujetos y objetos serán

etiquetas de sensibilidad asignados que son una combinación de

niveles de clasificación jerárquica y no jerárquica

categorías y las etiquetas se utilizan como base para

las decisiones de control de acceso obligatorios. El TCB deberá ser capaz de

el apoyo de dos o tales niveles más seguridad. (Vea la obligatoria

Directrices de control de acceso.) Las siguientes condiciones se

mantener durante todos los accesos entre todos los sujetos externos a la TCB

y todos los objetos directamente o indirectamente accesible por éstos

temas: Un sujeto puede leer un objeto sólo si el jerárquica

clasificación en el nivel de seguridad del sujeto es mayor que

o igual a la clasificación jerárquica en el objeto de

nivel de seguridad y las categorías no jerárquicas en la

nivel de seguridad del sujeto incluye todos los no-jerárquica

categorías en el nivel de seguridad del objeto. Un sujeto puede escribir

______________________________






categorías.

un objeto sólo si la clasificación jerárquica en el

nivel de seguridad del sujeto es inferior o igual a la

clasificación jerárquica en el nivel de seguridad del objeto y

todas las categorías no jerárquicas en la seguridad del sujeto

nivel se incluyen en las categorías jerárquicas no en el

nivel de seguridad del objeto. Identificación y autentificación

datos serán utilizados por el TCB para autenticar al usuario de

identidad y para asegurar que el nivel de seguridad y autorización

ción de los sujetos externo a la TCB que puede ser creado para

actuar en nombre de cada usuario están dominados por el

aclaramiento y la autorización de dicho usuario.












creado para actuar en nombre del usuario individual están dominadas por

la liquidación y autorización de ese usuario. El TCB deberá









entre ella misma y los usuarios para el uso cuando un TCB-a-positivo

Se requiere conexión de usuario (por ejemplo, inicio de sesión, cambio de tema

nivel de seguridad). Comunicaciones a través de este camino de confianza

deberá ser activado exclusivamente por un usuario o la TCB y

deberán estar aislados de manera lógica y sin lugar a dudas


4.1.2.2 Auditoría











oficiales y otros eventos relevantes de seguridad. El TCB deberá

También podrá auditar cualquier anulación de la salida legible

marcas. Para cada evento registrado, el registro de auditoría,

identificar: fecha y hora del evento, el usuario, el tipo de evento, y

éxito o el fracaso del evento. Para la identificación /

eventos de autenticación del origen de la solicitud (por ejemplo, la terminal de Identificación)

se incluirán en el registro de auditoría. Para los eventos que

introducir un objeto en el espacio de direcciones de un usuario y para el objeto

eventos de eliminación del registro de auditoría deberán incluir el nombre de la

objeto y nivel de seguridad del objeto. El sistema de ADP


cualquier uno o más usuarios en base a la identidad y / o objeto individual

nivel de seguridad. El TCB podrá auditar el identificada

eventos que se pueden utilizar en la explotación de almacenamiento encubierta

canales. El TCB deberá contener un mecanismo que es capaz de

supervisar la aparición o acumulación de seguridad auditable

hechos que pueden indicar una violación inminente de la seguridad

política. Este mecanismo será capaz de notificar inmediatamente a la

administrador de seguridad cuando los umbrales se superan, y, si es

la aparición o acumulación de éstos de seguridad pertinentes

acontecimientos continúa, el sistema tomará la menor disruptiva

acción para terminar el evento.

4.1.3 Aseguramiento












módulos deberán estar diseñados de tal manera que el principio de

privilegio menos se cumple. Características de hardware, tales

como la segmentación, se utilizarán para apoyar lógicamente

objetos de almacenamiento distintas con atributos diferentes (a saber:

lectura, escritura). La interfaz de usuario a la TCB

deberá estar totalmente definido y todos los elementos de la TCB

identificados. El TCB estará diseñado y estructurado para

utilizar un mecanismo de protección completa, conceptualmente simple

con semántica definida con precisión. Este mecanismo deberá

desempeñar un papel central en la aplicación de la estructuración interna

del TCB y el sistema. El TCB incorporará

uso significativo de la estratificación, la abstracción y la ocultación de datos.

Ingeniería de sistemas significativos se dirige hacia

minimizar la complejidad de la TCB y se excluyen de la

los módulos de TCB que no son de protección crítico.





del TCB.



canales encubiertos y tomar una determinación (ya sea por

medición real o por estimación de ingeniería) de la

máximo ancho de banda de cada canal identificado. (Vea el

Sección Orientación Canales Covert.) Los métodos formales deberá

ser utilizado en el análisis.



funciones. Las funciones realizadas en el papel de una

se identificará administrador de seguridad. La ADP

personal administrativo del sistema sólo podrán

realizar funciones de administrador de seguridad después de tomar una

acción auditable distinta a asumir la seguridad

función de administrador en el sistema ADP. No la seguridad

funciones que se pueden realizar en la seguridad

rol de administración se limitará estrictamente a los


4.1.3.1.5 Recuperación de confianza

Procedimientos y / o mecanismos se proporcionarán para asegurar

que, después de un fallo del sistema ADP u otra discontinuidad,

se obtiene la recuperación sin un compromiso de protección.








análisis y pruebas exhaustivas. Sus objetivos deberán

ser: para descubrir todos los defectos de diseño e implementación que

permitiría un sujeto externo a la TCB de leer,

cambiar o eliminar datos normalmente negados bajo el

política de seguridad obligatoria o discrecional impuesta por

la TCB; así como para asegurar que ningún objeto (sin

autorización para hacerlo) es capaz de hacer que el TCB para entrar

un estado tal que es incapaz de responder a

comunicaciones iniciadas por otros usuarios. El TCB deberá

se encuentran resistente a la penetración. Todos los defectos descubiertos

será corregido y el TCB vuelto a probar para demostrar

que han sido eliminados y que los nuevos defectos tener

no se han introducido. El ensayo debe demostrar que el

Aplicación TCB es coherente con las láminas superior formales

especificación de nivel. (Vea la Prueba de Seguridad

Lineamientos.) No hay defectos de diseño y no más de unos pocos

fallas de implementación corregibles pueden encontrarse en

probando y habrá una confianza razonable que pocos

permanecer. Mapeo manual u otra de las FTLs al

código fuente puede servir de base para las pruebas de penetración.








y efectos. Una especificación de alto nivel formales (FTLs) de

la TCB se mantendrá que describe con precisión la

TCB en términos de excepciones, mensajes de error y efectos.

Los DTLS y FTLs incluirán aquellos componentes de la

TCB que se implementa como hardware y / o firmware si

sus propiedades son visibles en la interfaz de TCB. Los

FTLs se mostraron ser una descripción exacta de la

Interfaz de TCB. Un argumento convincente se decidió que se

la DTLS es consistente con el modelo y una combinación de

Se utilizarán técnicas formales e informales para demostrar que

la FTLs es consistente con el modelo. Esta verificación

pruebas será compatible con la prevista en el

el estado de la técnica de la seguridad informática en particular

centro-endosado especificación formal y verificación

sistema utilizado. Mapeo manual u otra de las FTLs al

Se realizará el código fuente TCB para proporcionar evidencia de

aplicación correcta.


Durante todo el ciclo de vida, es decir, durante el diseño,

desarrollo y mantenimiento de la TCB, una configuración

sistema de dirección debe estar en su lugar para toda seguridad-

hardware correspondiente, firmware y software que mantiene

el control de cambios en el modelo formal, lo descriptivo

y las especificaciones de alto nivel formales, otros datos de diseño,

documentación de la aplicación, código fuente, el funcionamiento

versión del código objeto, y de prueba y accesorios

documentación. El sistema de gestión de la configuración deberá

asegurar una asignación consistente entre toda la documentación y

código asociado con la versión actual de la TCB.

Herramientas se proporcionan para la generación de una nueva versión

del TCB partir del código fuente. También disponible será

herramientas, mantenidos bajo control estricto de configuración, por

la comparación de una versión recién generado con la TCB anterior

versión a fin de determinar que sólo la intención

se han realizado cambios en el código que realmente será

utilizado como la nueva versión de la TCB. Una combinación de

y salvaguardas técnicas, físicas procedimental será

utilizado para proteger de la modificación no autorizada o

la destrucción de la copia maestra o copias de todo el material

utilizado para generar la TCB.

4.1.3.2.4 Distribución de confianza

Una instalación de control del sistema ADP y distribución de confianza

serán las previstas en el mantenimiento de la integridad de la

asignación entre los datos maestros que describen el actual

versión de la TCB y la copia maestra en el lugar del

código de la versión actual. Procedimientos (por ejemplo, el sitio

pruebas de aceptación de seguridad) deberá existir para asegurar

que el software TCb, actualizaciones de firmware y hardware

distribuido a un cliente son exactamente como se especifica en

las copias maestras.






















Se describirá la modificación de cualquiera de los módulos en el TCB. Ello

incluirá los procedimientos para garantizar que el sistema es


incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en

operación del sistema.







anchos de banda de canal. Los resultados de la asignación entre el

especificación de nivel superior formal y el código fuente TCB serán

dado.










que cumplan el modelo. El descriptiva especificado de nivel superior

ficación (DTLS) se demuestra que es una descripción exacta de

la interfaz de TCB. La documentación debe describir cómo el TCB

implementa el concepto de monitor de referencia y dar una explicación

la razón por la que es resistente a la manipulación, no se puede omitir, y

se ha implementado correctamente. La implementación TCB (es decir, en

hardware, firmware y software) se muestran de manera informal a

ser compatible con la especificación de alto nivel formales (FTLs).

Los elementos de las FTLs se indicarán, mediante informal

técnicas, para corresponder a los elementos de la TCB.

La documentación debe describir cómo el TCB está estructurado para

facilitar las pruebas y hacer cumplir privilegio menos. Esta

documentación deberá presentar también los resultados de la encubierta

análisis de canal y las ventajas y desventajas implicadas en la restricción de la

canales. Todos los eventos auditables que se pueden utilizar en el

explotación de canales de almacenamiento encubiertas conocidas será

identificados. Los anchos de banda de los canales de almacenamiento encubiertas conocidas,



Hardware, el firmware y los mecanismos de software no tratados en

los FTLs pero estrictamente interna a la TCB (por ejemplo, mapeo

registros, acceso directo a memoria de E / S) se describen claramente.

?

4.2 MÁS ALLÁ DE LA CLASE (A1)

La mayor parte de las mejoras de seguridad previsto para los sistemas que proporcionen

características y aseguramiento, además de que ya previstas por clase (Al)

sistemas están más allá de la tecnología actual. La discusión que sigue está destinado a

orientar la labor futura y se deriva de las actividades de investigación y desarrollo

ya en marcha, tanto en los sectores público y privado. A medida que más y mejor

técnicas de análisis se desarrollan, los requisitos para estos sistemas

ser más explícito. En el futuro, el uso de la verificación formal será

extendidos hasta el nivel de la fuente y los canales de temporización encubiertas serán más plenamente

abordarse. En este nivel el entorno de diseño se convertirá en importante y

prueba será ayudado por el análisis de la especificación formal de nivel superior.

Se tendrá en cuenta para la corrección de las herramientas utilizadas en el TCB

desarrollo (por ejemplo, los compiladores, ensambladores, cargadores) y para la correcta

funcionamiento del hardware / firmware en la que la TCB se ejecutará. Las áreas a ser

dirigida por los sistemas más allá de la clase (A1) incluyen:

* Arquitectura del Sistema

Una demostración (formal o no) se debe dar muestra

que los requisitos de auto-protección y la integridad de

monitores de referencia se han implementado en el TCB.

* Pruebas de seguridad

Aunque más allá del estado de la técnica actual, es

prevé que se hará alguna generación de pruebas de los casos

automáticamente de la especificación formal de nivel superior o

especificaciones formales de nivel inferior.

* Especificación formal y Verificación

El TCB debe ser verificada hasta el nivel de código fuente,

utilizando métodos de verificación formal cuando sea factible. Oficial

verificación del código fuente de la seguridad pertinente

partes de un sistema operativo ha demostrado ser una tarea difícil

tarea. Dos consideraciones importantes son la elección de una

lenguaje de alto nivel cuya semántica puede ser plena y

expresado formalmente, y un mapeo cuidadoso, a través de

etapas sucesivas, del diseño formal abstracta a un

formalización de la aplicación de bajo nivel

especificaciones. La experiencia ha demostrado que sólo cuando el

especificaciones de nivel más bajo se corresponden estrechamente a la actual

código puede codificar pruebas se realizó con éxito.

* Trusted Diseño para el Medio Ambiente

El TCB debe estar diseñado en un centro de confianza con solamente

confianza (liquidados) Personal.

PARTE II:

JUSTIFICACIÓN Y DIRECTRICES

?

5.0 OBJETIVOS DE CONTROL DE SISTEMAS INFORMÁTICOS DE CONFIANZA

Los criterios se dividen dentro de cada clase en grupos de requisitos. Estas

agrupaciones fueron desarrollados para asegurar que los tres objetivos básicos de control de

seguridad informática están satisfechos y sin vecinos. Estos objetivos de control

lidiar con:

* Politica de seguridad

* Rendición de cuentas

* Aseguramiento

En esta sección se ofrece un análisis de estos objetivos generales de control y

su implicación en términos de diseño de sistemas de confianza.

?

5.1 NECESIDAD DE CONSENSO

Un objetivo importante del Centro de Seguridad Informática del Departamento de Defensa es fomentar el ordenador

Industria para desarrollar sistemas informáticos fiables y productos, haciéndolos ampliamente

disponible en el mercado comercial. El logro de este objetivo

requiere el reconocimiento y articulación de los sectores público y privado de

la necesidad y la demanda de este tipo de productos.

Como se describe en la introducción de este documento, los esfuerzos para definir la

problemas y desarrollar soluciones asociados con el procesamiento a nivel nacional sensibles

información, así como otros datos sensibles, tales como financieros, médicos, y

información del personal utilizado por el Establecimiento de Seguridad Nacional, han sido

llevando a cabo para un número de años. Los criterios, tal como se describe en la Parte I,

representar la culminación de estos esfuerzos y describir los requisitos básicos para

edificio confiaba sistemas informáticos. Hasta la fecha, sin embargo, estos sistemas han sido

visto por muchos, ya que sólo la satisfacción de las necesidades de la seguridad nacional. Mientras esta

percepción continúa el consenso necesario para motivar fabricación de confianza

sistemas serán escasas.

El propósito de esta sección es describir en detalle el control fundamental

objetivos. Estos objetivos sentar las bases para los requisitos indicados

en los criterios. El objetivo es explicar las bases para que los que están fuera

el Establecimiento de Seguridad Nacional puede evaluar su universalidad y, por

extensión, la aplicabilidad universal de los requisitos de criterios de

procesamiento de todos los tipos de aplicaciones sensibles ya sean para Nacional

Seguridad o el sector privado.

?

5.2 DEFINICIÓN Y UTILIDAD

El término "controlar objetivo" se refiere a una declaración de intenciones con respecto a la

control sobre algún aspecto de los recursos de una organización, o procesos, o

ambos. En términos de un sistema informático, los objetivos de control proporcionan un marco

para el desarrollo de una estrategia para el cumplimiento de un conjunto de requisitos de seguridad para los

cualquier sistema dado. Desarrollado en respuesta a vulnerabilidades genéricas, tales como

la necesidad de gestionar y manejar datos sensibles con el fin de evitar el compromiso,

o la necesidad de proporcionar la rendición de cuentas con el fin de detectar el fraude, el control

objetivos han sido identificados como un método útil de la seguridad expresar

metas. [3]

Ejemplos de objetivos de control incluyen los tres requisitos básicos de diseño para

la aplicación del concepto monitor de referencia discutió en la Sección 6. Ellos son:

* El mecanismo de validación de referencia debe ser a prueba de manipulaciones.

* El mecanismo de validación de referencia siempre se debe invocar.

* El mecanismo de validación de referencia debe ser suficientemente pequeño para ser

sometido a análisis y pruebas, la integridad de los cuales puede

tener la seguridad. [1]

?

5.3 CRITERIOS OBJETIVOS DE CONTROL

Los tres objetivos básicos de control de los criterios tienen que ver con la seguridad

la política, la rendición de cuentas, y la garantía. El resto de esta sección se ofrece

una discusión de estos requisitos básicos.


En el sentido más general, la seguridad informática se refiere a

controlar la forma en la que un ordenador puede ser utilizado, es decir,

el control de cómo la información procesada por que se puede acceder y

manipulado. Sin embargo, en un examen más detallado, la seguridad informática

puede referirse a una serie de áreas. Un síntoma de esto, FIPS PUB 39,

Glosario para los sistemas informáticos de seguridad, no tiene una única

definición de la seguridad informática. [16] En su lugar hay once

definiciones separadas para la seguridad, que incluyen: sistemas de ADP

la seguridad, la seguridad administrativa, seguridad de datos, etc. Un común

hilo conductor de estas definiciones es la palabra "protección".

Otras declaraciones de los requisitos de protección se pueden encontrar en

Directiva DoD 5200.28, que describe un nivel aceptable de

protección para los datos clasificados como uno que "asegurar que

sistemas que procesan, almacenan o usan datos clasificados y producir

información clasificada hará, con fiabilidad razonable,

impedir: a. Acceso deliberada o inadvertida para clasificarse

material por parte de personas no autorizadas, y b. Unauthorized

manipulación de la computadora y su periférico asociado

dispositivos ". [8]

En resumen, los requisitos de protección deben definirse en términos de

las amenazas percibidas, riesgos y objetivos de una organización. Esta

a menudo se dice en términos de una política de seguridad. Ha sido

señalado en la literatura que se trata de leyes externas, reglas,

reglamentos, etc., que establecen lo que el acceso a la información es

se permitirá, independiente de la utilización de un ordenador. En particular,

un sistema dado sólo puede decirse que es seguro con respecto a su

la ejecución de alguna política específica. [30] Por lo tanto, el control

objetivo de la política de seguridad es:

OBJETIVO DE SEGURIDAD CONTROL DE POLÍTICA

Una declaración de intenciones en relación con el control sobre el acceso y la

difusión de la información, que se conocerá como la política de seguridad

debe ser precisamente definida e implementada para cada sistema que es

utilizado para procesar información sensible. La política de seguridad debe

reflejar con precisión las leyes, reglamentos y políticas generales

a partir del cual se deriva.

5.3.1.1 Política de Seguridad Obligatorio

Cuando se desarrolla una política de seguridad que se va a aplicar

para el control de clasificado u otro específicamente designado

información sensible, la política debe incluir detallada

reglas sobre la manera de manejar esa información durante todo su

ciclo de la vida. Estas reglas son una función de los distintos

sensibilidad designaciones que la información puede asumir

y las diversas formas de acceso soportados por el sistema.

Obligatorio Seguridad se refiere a la aplicación de un conjunto de

reglas de control de acceso que limita el acceso de un sujeto a

información sobre la base de una comparación de ese

despacho / autorización del individuo a la información,

la designación de clasificación / sensibilidad de la

la información y la forma de acceso están mediadas.

Políticas obligatorias o bien exigen o pueden ser satisfechas por

sistemas que pueden hacer cumplir una orden parcial de

designaciones, a saber, las designaciones deben formar lo que se

matemáticamente conocido como un "celosía". [5]

Una clara implicación de lo anterior es que el sistema debe

aseguran que las designaciones asociadas con datos sensibles

no se puede cambiar arbitrariamente, ya que esto podría permitir

las personas que no tienen la autorización apropiada para

acceso a la información sensible. También implícita es la

requisito de que el sistema de control de la circulación de la información

para que los datos no se puede almacenar con menor sensibilidad

ha sido autorizado designaciones a menos que su "degradación".

El objetivo de control es:

CONTROL DE SEGURIDAD OBLIGATORIO OBJETIVO

Las políticas de seguridad definidas para los sistemas que se utilizan para

proceso clasificado u otro clasifica específicamente

información sensible debe incluir disposiciones para la

aplicación de las normas de control de acceso obligatorios. Eso es,

deben incluir un conjunto de reglas para controlar el acceso

basada directamente en una comparación de los individuales de

autorización o autorización para la información y la

clasificación o designación de la sensibilidad

la información que se busca, e indirectamente en consideraciones

de los factores ambientales físicos y de otro tipo de control.

Las reglas de control de acceso obligatorios deben reflejar con precisión

las leyes, los reglamentos y las políticas generales de la que

se derivan.

5.3.1.2 Política de Seguridad Discrecional

Seguridad discrecional es el tipo principal de acceso

de control disponible en los sistemas informáticos en la actualidad. La base de

Este tipo de seguridad es que un usuario individual, o

programa operativo en su nombre, se le permite especificar

explícitamente los tipos de acceso a otros usuarios pueden tener que

la información bajo su control. Seguridad Discrecional

difiere de seguridad obligatorias en que implementa un

política de control de acceso sobre la base de un individuo de

necesita-a-saber en comparación con los controles obligatorios que son

impulsado por la clasificación o la sensibilidad designación de

la información.

Controles discrecionales no son un sustituto de obligatoria

controles. En un entorno en el que la información es

clasificado (como en el Departamento de Defensa) Seguridad discrecional ofrece

para una mayor granularidad de control dentro de la general

restricciones de la política obligatoria. El acceso a clasificado

información requiere la aplicación efectiva de ambos tipos

de los controles como condición previa para la concesión de ese acceso. En

general, ninguna persona puede tener acceso a la clasificada

información a menos que: (a) que la persona se ha determinado que

ser dignos de confianza, es decir, concedió una seguridad del personal

despacho - OBLIGATORIO, y (b) el acceso es necesario para la

desempeño de funciones oficiales, es decir, determinados a tener un

necesita-a-saber - DISCRECIONAL. En otras palabras,

controles discrecionales dan individuos discreción

decidir sobre cuál de los accesos permitidos en realidad

se le permita a la que los usuarios, de acuerdo con imperiosas

restricciones políticas obligatorias. El objetivo de control es:

CONTROL DE SEGURIDAD DISCRECIONAL OBJETIVO

Las políticas de seguridad definidas para los sistemas que se utilizan para

proceso clasificada u otra información sensible debe

incluir disposiciones para la aplicación de la discrecionalidad

reglas de control de acceso. Es decir, se deben incluir una

conjunto coherente de normas para el control y la limitación del acceso

basado en individuos identificados que han sido determinados

tienen una necesidad de conocer la información.

5.3.1.3 Marcado

Para llevar a cabo un conjunto de mecanismos que pondrán en vigor

una política de seguridad obligatorio, es necesario que el

información de marca de sistema con la clasificación correspondiente o

sensibilidad etiquetas y mantener estas marcas como el

la información se mueve a través del sistema. Una vez que la información es

comparaciones inalterable y marcadas con precisión, requeridos por

las reglas de control de acceso obligatorio pueden ser precisa y

consistentemente hecho. Un beneficio adicional de tener la

sistema de mantener la etiqueta de clasificación o la sensibilidad

internamente es la capacidad de generar de forma automática

adecuadamente "etiquetado" de salida. Las etiquetas, si con precisión y

integralmente mantenido por el sistema, siendo preciso cuando

salida del sistema. El objetivo de control es:

MARCADO OBJETIVO DE CONTROL

Los sistemas que están diseñados para hacer cumplir una fianza obligatoria

política debe almacenar y preservar la integridad de

clasificación u otras etiquetas de sensibilidad para todos

información. Las etiquetas exportadas del sistema deben ser

representaciones precisas de la interna correspondiente

etiquetas de sensibilidad que se exportan.


El segundo objetivo de control básico aborda uno de los

principios fundamentales de la seguridad, es decir, individuo

la rendición de cuentas. La responsabilidad individual es la clave para asegurar

y el control de cualquier sistema que procesa la información en nombre

de los individuos o grupos de individuos. Una serie de requisitos

se deben cumplir para satisfacer este objetivo.

El primer requisito es para la identificación del usuario individual.

En segundo lugar, hay una necesidad para la autenticación de la identificación.

La identificación es funcionalmente dependiente de autenticación.

Sin autenticación, identificación de usuario no tiene credibilidad.

Sin una identidad creíble, ni obligatorio ni discrecional

las políticas de seguridad se pueden invocar correctamente porque no hay

la garantía de que las autorizaciones adecuadas se pueden hacer.

El tercer requisito es para capacidades de auditoría confiables. Ese

Es decir, un sistema informático de confianza debe proporcionar personal autorizado

con la capacidad de auditar cualquier acción que potencialmente pueden causar

acceso, generación de, o efectuar la liberación de reservada o

información sensible. Los datos de auditoría serán selectivamente

adquiridos en base a las necesidades de auditoría de una instalación en particular

y / o aplicación. Sin embargo, debe haber suficiente granularidad

en los datos de auditoría para apoyar la localización de los eventos auditables a un

individuo específico que ha tomado las acciones o en cuyo nombre

se tomaron las acciones. El objetivo de control es:

OBJETIVO DE CONTROL DE RENDICIÓN DE CUENTAS

Los sistemas que se utilizan para procesar o manipular clasificada u otro

información sensible debe asegurar la responsabilidad individual

siempre que sea una política de seguridad obligatoria o discrecional es

invocado. Además, para asegurar la rendición de cuentas, la capacidad

debe existir para que un agente autorizado y competente para el acceso y

evaluar la información de rendición de cuentas por un medio seguro, dentro de un

tiempo razonable y sin excesiva dificultad.

5.3.3 Aseguramiento

El tercer objetivo de control básico se refiere a garantizar

o proporcionar confianza en que la política de seguridad ha sido

se aplica correctamente y que los elementos de protección pertinentes de

el sistema do, de hecho, mediar y hacer cumplir la intención precisa

de esa política. Por extensión, la garantía debe incluir una garantía

que la parte de confianza del sistema sólo funciona según lo previsto. A

lograr estos objetivos, se necesitan dos tipos de seguridad.

Son la garantía de ciclo de vida y seguridad operacional.

Aseguramiento del ciclo de vida se refiere a las medidas adoptadas por una organización para

asegúrese de que el sistema está diseñado, desarrollado y mantenido

utilizando formalizados y rigurosos controles y normas. [17]

Los sistemas informáticos que procesan y almacenan sensible o clasificada

información depende del hardware y software para proteger esa

información. De ello se desprende que el hardware y software a sí mismos

deben ser protegidos contra cambios no autorizados que podrían hacer

mecanismos de protección al mal funcionamiento o ser anuladas por completo.

Por esta razón, los sistemas informáticos de confianza deben ser cuidadosamente

evaluado y probado durante las fases de diseño y desarrollo y

reevaluados cada vez que se realizan cambios que podrían afectar a la

integridad de los mecanismos de protección. Sólo de esta manera puede

confianza estar previsto que el hardware y el software

interpretación de la política de seguridad se mantiene con precisión

y sin distorsión.

Mientras que la garantía de ciclo de vida tiene que ver con los procedimientos para

la gestión de diseño del sistema, el desarrollo y el mantenimiento; operacional

aseguramiento centra en las características y arquitectura del sistema se utilizan para

asegúrese de que la política de seguridad se aplica uncircumventably

durante el funcionamiento del sistema. Es decir, la política de seguridad debe haber

integrado en las características de hardware y software de protección de

el sistema. Los ejemplos de las medidas adoptadas para proporcionar este tipo de

confianza incluyen: métodos para probar el hardware operativa

y software para su correcto funcionamiento, el aislamiento de proteccionismo

código crítico, y el uso de hardware y software para proporcionar

dominios distintos. El objetivo de control es:

OBJETIVO DE CONTROL DE GARANTÍA

Los sistemas que se utilizan para procesar o manipular clasificada u otro

información sensible debe estar diseñado para garantizar la correcta y

interpretación precisa de la política de seguridad y no debe

distorsionar la intención de que la política. Aseguramiento debe proporcionarse

existe de que la aplicación correcta y el funcionamiento de la política

a lo largo del ciclo de vida del sistema.

?

6.0 JUSTIFICACIÓN DETRÁS DE LAS CLASES DE EVALUACIÓN

?

6.1 EL CONCEPTO DE MONITOR DE REFERENCIA

En octubre de 1972, el Estudio de Planificación de Tecnología de Seguridad Informática, realizó

por James P. Anderson & Co., elaboró un informe para los Sistemas Electrónicos

División (ESD) de la Fuerza Aérea de los Estados Unidos. [1] En ese informe, el concepto

de "un monitor de referencia que hace cumplir las relaciones de acceso autorizados

entre los sujetos y los objetos de un sistema "fue introducido. La referencia

Monitor concepto resultó ser un elemento esencial de cualquier sistema que lo haría

proporcionar multinivel instalaciones informáticas seguras y controles.

El informe Anderson pasó a definir el mecanismo de validación de referencia

"una aplicación del concepto de monitor de referencia... que valida

cada referencia a datos o programas por cualquier usuario (programa) con una lista de

tipos de referencia autorizado para ese usuario. "A continuación, aparece el diseño de tres

requisitos que deben ser cumplidos por un mecanismo de validación de referencia:

a. El mecanismo de validación de referencia debe ser a prueba de manipulaciones.

b. El mecanismo de validación de referencia siempre se debe invocar.

c. El mecanismo de validación de referencia debe ser suficientemente pequeño para ser

sujetos a análisis y pruebas, la integridad de los cuales puede

estar seguro. "[1]

Continuación de las actividades de investigación y desarrollo tienen una amplia revisión por pares y

sostenido la validez de las conclusiones del Comité Anderson. Los primeros ejemplos

del mecanismo de validación de referencia eran conocidos como granos de seguridad. Los

Anderson Informe describe el núcleo de seguridad como "esa combinación de hardware

y el software que implementa el concepto de monitor de referencia ". [1] En este orden de ideas,

se observará que el núcleo de seguridad debe ser compatible con los tres referencia

requisitos de monitor enumerados anteriormente.

?

6.2 A SEGURIDAD FORMAL POLÍTICA DE MODELO

Tras la publicación del informe de Anderson, una considerable investigación fue

iniciado en los modelos formales de requisitos de la política de seguridad y de la

mecanismos que aplicar y hacer cumplir esos modelos de política como la seguridad

kernel. Destacan entre estos esfuerzos fue el desarrollo ESD-patrocinado de

el modelo Bell y LaPadula, un tratamiento formal abstracta de seguridad del Departamento de Defensa

política. [2] El uso de las matemáticas y la teoría de conjuntos, el modelo define con precisión la

noción de estado seguro, modos fundamentales de acceso, y las reglas para

la concesión de los sujetos modos específicos de acceso a los objetos. Por último, un teorema es

probada para demostrar que las reglas son las operaciones de seguridad de preservación, por lo

que la aplicación de cualquier secuencia de las reglas a un sistema que está en una

estado seguro se traducirá en el sistema de entrar en un nuevo estado que es también

seguro. Este teorema es conocido como el Teorema de Seguridad Básica.

Un sujeto puede actuar en nombre de un usuario u otro objeto. El tema es

creado como un sustituto para el usuario autorizado y se le asigna un valor formal,

nivel en función de su clasificación. Las transiciones de estado e invariantes de

el modelo de política formal definir las relaciones invariantes que deben contener

entre el aclaramiento del usuario, el nivel de seguridad formal de cualquier proceso

que puede actuar en nombre del usuario y el nivel de seguridad formal de los dispositivos

y otros objetos a los que cualquier proceso pueden obtener modos específicos de acceso.

El modelo Bell y LaPadula, por ejemplo, define una relación entre lo formal

niveles de seguridad de sujetos y objetos, que ahora hace referencia como el "dominio

relación ". A partir de esta definición, los accesos permitidos entre los sujetos y

objetos se definen explícitamente los modos fundamentales de acceso, incluyendo

acceso de sólo lectura, lectura / escritura, y escribir-único acceso. El modelo define

el Estado de Seguridad simple para controlar la concesión de un sujeto acceso de lectura a un

objeto específico, y la * -Property (léase "Star Propiedad") para el control de la concesión

un acceso por materias de escritura a un objeto específico. Tanto la Seguridad simple

Condición y el * -Property incluyen disposiciones de seguridad obligatorias en función de la

relación de dominación entre los niveles de seguridad formales de los sujetos y objetos del

liquidación de la materia y la clasificación del objeto. Los

Discrecional Seguridad Propiedad también se define, y requiere que un determinado

sujetos autorizados para todo el modo particular de acceso requerido para el Estado

transición. En su tratamiento de temas (procesos que actúan en nombre de un

el usuario), el modelo distingue entre sujetos de confianza (es decir, no limitados

en el modelo por el * -Property) y los sujetos no confiables (los que son

limitada por la * -Property).

Desde el modelo Bell y LaPadula existe un modelo evolucionado del método de la prueba

requerida para demostrar formalmente que las secuencias de todo arbitrarias de Estado

transiciones son la seguridad de preservación. También se demostró que el * - Propiedad

es suficiente para evitar el compromiso de información por Caballo de Troya

ataques.

?

6.3 LA BASE Trusted Computing

Con el fin de fomentar la disponibilidad comercial generalizada de confianza

sistemas informáticos, estos criterios de evaluación han sido diseñados para abordar

aquellos sistemas en los que un núcleo de seguridad se ha implementado específicamente, así

como aquellos en los que un núcleo de seguridad no se ha aplicado. El último caso

incluye aquellos sistemas en los que el objetivo (c) no es totalmente compatible porque

del tamaño o complejidad del mecanismo de validación de referencia. Por

conveniencia, estos criterios de evaluación utilizan el término Trusted Computing Base para

consulte el mecanismo de validación de referencia, ya sea un kernel de seguridad,

filtro de seguridad para el usuario, o de todo el sistema informático de confianza.

El corazón de un sistema informático de confianza es la Trusted Computing Base (TCB)

que contiene todos los elementos del sistema responsables de apoyar

la política de seguridad y apoyar el aislamiento de objetos (código y datos) en

que la protección se basa. Los límites de la TCB equivalen a la "seguridad

perímetro "se hace referencia en alguna literatura seguridad informática. En interés

de la protección comprensible y mantenible, un TCB debería ser tan simple como

posible que sea compatible con las funciones que tiene que realizar. Por lo tanto, la TCB

incluye hardware, firmware y software crítico para la protección y debe ser

diseñado e implementado tales que los elementos del sistema excluidos de ella no tiene por qué

ser de confianza para mantener la protección. Identificación de la interfaz y

elementos de la TCB, junto con por lo tanto su funcionalidad correcta forma la

base para la evaluación.

Para los sistemas de propósito general, la TCB incluirá elementos clave de la

sistema operativo y puede incluir todo el sistema operativo. Para incrustado

sistemas, la política de seguridad pueden tratar con los objetos de una manera que es significativa

a nivel de aplicación en lugar de en el nivel del sistema operativo. Por lo tanto, la

política de protección se puede hacer cumplir en el software de la aplicación y no en

el sistema operativo subyacente. El TCB incluirá necesariamente todos aquellos

partes del sistema y software de aplicación que opera esenciales para la

apoyo a la política. Tenga en cuenta que, como la cantidad de código en los aumentos de TCB,

se hace más difícil estar seguro de que la TCB refuerza el monitor de referencia

requisitos en todas las circunstancias.

?

6.4 ASEGURAMIENTO

El objetivo de diseño tercer monitor de referencia se interpreta actualmente como

lo que significa que la TCB "debe ser de la organización lo suficientemente simple y

complejidad a ser sometido a análisis y pruebas, la integridad de los cuales

puede estar seguro ".

Claramente, como el grado percibido de riesgo aumenta (por ejemplo, la gama de

sensibilidad de los datos protegidos del sistema, junto con la gama de espacios libres

en poder de la población de usuarios del sistema) para un sistema particular de operativa

la aplicación y el medio ambiente, por lo que también deben las seguridades aumentarse a

corroborar el grado de confianza que se colocará en el sistema. Los

jerarquía de requisitos que se presentan para las clases de evaluación en el

criterios de evaluación del sistema informático de confianza reflejan la necesidad de que éstos

garantías.

Como se discutió en la Sección 5.3, los criterios de evaluación requieren un uniforme

declaración de la política de seguridad que se aplica por cada equipo de confianza

sistema. Además, se requiere que se presentará un argumento convincente

eso explica por qué el TCB satisface los dos primeros requisitos de diseño para un

monitor de referencia. No se espera que este argumento será totalmente

formal. Este argumento es necesario para cada sistema candidato con el fin de

satisfacer el objetivo de control de garantía.

Los sistemas a los que se han añadido los mecanismos de aplicación de seguridad, en lugar

de los objetivos de diseño fundamentales incorporadas, no son fácilmente susceptibles de

análisis amplio ya que carecen de la simplicidad conceptual requerido de un

kernel seguridad. Esto es porque su TCB se extiende para cubrir la mayor parte del

todo el sistema. Por lo tanto, su grado de confiabilidad mejor se pueda determinar

Sólo mediante la obtención de resultados de la prueba. Dado que ningún método de ensayo para algo tan

complejo como un sistema informático puede ser verdaderamente exhaustiva, siempre existe la

posibilidad de que un intento de penetración posterior podría tener éxito. Es para

esta razón que tales sistemas deben caer en las clases más bajas de evaluación.

Por otro lado, aquellos sistemas que están diseñados y creados para apoyar

los conceptos TCB son más susceptibles de análisis y pruebas estructurado. Oficial

métodos pueden ser utilizados para analizar la exactitud de su validación referencia

mecanismos para hacer cumplir la política de seguridad del sistema. Otros métodos,

incluyendo argumentos menos formales, se puede utilizar con el fin de fundamentar sus reclamaciones,

por la integridad de su mediación acceso y su grado de

manipulaciones resistencia. Más confianza se puede colocar en los resultados de este

análisis y en el rigor de la prueba estructurada que se puede colocar

en los resultados para sistemas menos estructurados de forma metódica. Por estas razones,

parece razonable concluir que estos sistemas podrían utilizarse en

entornos de alto riesgo. Implementaciones exitosas de tales sistemas serían

clasificado de la forma de evaluación más altas.

?

6.5 LAS CLASES

Es altamente deseable que exista sólo un pequeño número de evaluación global

clases. Tres divisiones principales se han identificado en la evaluación

criterios con una cuarta división reservada para aquellos sistemas que han sido

evaluado y encontrado para ofrecer protección de seguridad inaceptable. Dentro de cada

división principal de evaluación, se encontró que las clases "intermedias" de confianza

diseño y desarrollo del sistema de manera significativa podrían definirse. Estas

clases intermedias han sido designados en los criterios, ya que

identificar los sistemas que:

* Son vistos ofrecer significativamente mejor protección y garantía

sistemas de lo que sería que satisfagan los requisitos básicos para su

clase de evaluación; y

* No hay razón para creer que los sistemas de la intermedia

clases de evaluación eventualmente podrían evolucionado de tal manera que

satisfaga los requisitos para la próxima evaluación más alta

clase.

Excepto dentro de la división A que no se prevé que adicional "intermedia"

clases de evaluación que satisfagan las dos características descritas anteriormente serán

identificados.

Las distinciones en cuanto a la arquitectura del sistema, la aplicación de la política de seguridad, y

pruebas de credibilidad entre las clases de evaluación se han definido de manera que

el "salto" entre las clases de evaluación requeriría una inversión considerable

de esfuerzo por parte de los ejecutores. Correspondientemente, no se espera que

ser diferenciales significativos de riesgo a que los sistemas de la más alta

clases de evaluación serán expuestos.

?

7.0 LA RELACIÓN ENTRE LA POLÍTICA Y LOS CRITERIOS

Sección 1 presenta los requisitos de seguridad fundamentales ordenador y la sección 5

presenta los objetivos de control para sistemas informáticos de confianza. Ellos son

requisitos generales, útiles y necesarias, para el desarrollo de todo seguro

sistemas. Sin embargo, en el diseño de sistemas que se utilizarán para procesar

información confidencial clasificada u otra, los requisitos funcionales para la reunión

los Objetivos de Control se vuelven más específico. Hay un gran cuerpo de la política

establecido en forma de reglamentos, directivas, Ejecutivo Presidencial

Ordenes y Circulares de la OMB que forman la base de los procedimientos para la

manejo y procesamiento de información federal en general y clasificada

información específica. En esta sección se presenta extractos pertinentes de éstos

declaraciones de política y analiza su relación con los Objetivos de Control.

Estos extractos son ejemplos para ilustrar la relación de las políticas de

criterios y pueden no estar completos.

?

7.1 POLÍTICAS federal estableció

Un número importante de las políticas de seguridad informática y los requisitos asociados

se han promulgado por elementos del gobierno federal. El lector interesado

se refiere a la referencia [32] que analiza la necesidad de sistemas de confianza en

las agencias civiles del gobierno federal, así como en el estatal y local

los gobiernos y en el sector privado. Esta referencia también detalla una serie

de las leyes federales, las políticas y requisitos pertinentes no se trata más

a continuación.

Guía de seguridad para los sistemas de información automatizada federales es proporcionada por el

Oficina de Administración y Presupuesto. Dos Circulares específicamente aplicables tienen

ha emitido. OMB Circular No. A-71, Transmisión Memorando Nº 1, "Seguridad

de Federal de Sistemas de Información Automatizado, "[26] dirige cada agencia ejecutiva

para establecer y mantener un programa de seguridad informática. Esto hace que el jefe de

cada rama ejecutiva, departamento y organismo responsable "para asegurar una

nivel adecuado de seguridad para todos los datos de las agencias ya sean elaborados en la empresa o

comercialmente. Esto incluye la responsabilidad de la creación de bienestar físico,

salvaguardias administrativos y técnicos necesarios para proteger adecuadamente

datos confidenciales personales, de propiedad u otros que no están sujetos a la seguridad nacional

regulaciones, así como los datos de seguridad nacional ". [26, párr. 4 p. 2]

OMB Circular No. A-123, "Sistemas de Control Interno", [27] emitió para ayudar

eliminar el fraude, el despilfarro y el abuso en los programas de gobierno se requiere: (a) la agencia

cabezas para emitir directivas de control interno y asignar la responsabilidad, (b)

administradores para revisar los programas de la vulnerabilidad, y (c) los administradores a realizar

revisiones periódicas para evaluar las fortalezas y controles de actualización. Poco después

promulgación de la OMB Circular A-123, la relación de su control interno

requisitos para la construcción de sistemas informáticos seguros fue reconocido. [4] Aunque no

estipulando controles informáticos específicamente, la definición de Interior

Controles en A-123 deja claro que los sistemas informáticos se deben incluir:

"Controles internos - El plan de la organización y todos los métodos y

medidas adoptadas dentro de una agencia para salvaguardar sus recursos, asegurar la

exactitud y fiabilidad de la información, para asegurar la adherencia

leyes, reglamentos y políticas, y promover la operativa

economía y eficiencia. "[27, sec. 4.C]

El asunto de la información de seguridad nacional clasificada procesado por ADP

sistemas fue una de las primeras áreas dadas preocupación grave y extensa en

la seguridad informática. Los documentos de política de seguridad informática promulgadas como

resultado contiene requisitos generalmente más específicos y estructurados que la mayoría,

introducido a su vez a una base de autoridad que sí proporciona un lugar claramente

política de seguridad de la información articulada y estructurada. Esta base, Ejecutivo

Orden 12356, "Información de Seguridad Nacional", establece los requisitos para el

clasificación, desclasificación y la salvaguardia de la "seguridad nacional

información "en sí. [14]

?

7.2 POLÍTICAS DOD

Dentro del Departamento de Defensa, se implementan estos requisitos generales y

más indicado principalmente a través de dos vehículos: 1) El Reglamento DoD 5200.1-R

[7], que se aplica a todos los componentes del Departamento de Defensa, como tal, y 2) DoD 5220.22-M,

"Seguridad Industrial Manual para la protección de información clasificada" [11],

que se aplica a contratistas incluidos dentro de la Seguridad Industrial de Defensa

Programa. Tenga en cuenta que este último trasciende DoD como tal, ya que no se aplica

sólo para los contratistas manejan información clasificada para cualquier componente del Departamento de Defensa,

sino también a los contratistas de otras dieciocho organizaciones federales para los cuales

el Secretario de Defensa está autorizado para actuar en la prestación de la seguridad industrial

servicios. *

______________________________

* Es decir, de la NASA, el Departamento de Comercio, GSA, Departamento de Estado, la pequeña empresa

Administración, Fundación Nacional de Ciencias, Departamento del Tesoro,

Departamento de Transporte, Departamento del Interior, Departamento de Agricultura, EE.UU.

Agencia de Información, Departamento de Trabajo, Agencia de Protección del Medio Ambiente, Justicia

Departamento, US Control de Armas y Desarme Agencia Federal Emergency

Agencia de Gestión, Sistema de la Reserva Federal, y la Oficina de Contabilidad General.

Para los sistemas de ADP, estos requisitos de seguridad de información se amplifican aún más

y especificado en: 1) Directiva DoD 5200.28 [8] y DoD 5200.28-M Manual [9],

para los componentes del Departamento de Defensa; y 2) la Sección XIII del DoD 5220.22-M [11] para los contratistas.

Directiva DoD 5200.28, "Requisitos de seguridad para Automatic Data Processing

(ADP) Sistemas ", estipula:" El material clasificado contenida en un sistema de ADP

deberán tener protección por el empleo continuo de las funciones de protección en

hardware y software de diseño del sistema y la configuración. . . . "[8,

seg. IV] Además, se requiere que los sistemas de ADP que "procesar, almacenar,

o utilizar datos clasificados y producir información clasificada hará, con

fiabilidad razonable, prevenir:

a. Acceso deliberada o inadvertida de material clasificado por

personas no autorizadas, y

b. La manipulación no autorizada de la computadora y sus asociados

dispositivos periféricos ". [8, sec. I B.3]

Requisitos equivalentes a éstas aparecen dentro DoD 5200.28-M [9] y en el Departamento de Defensa

5220.22-M [11].

DoD 5200.28 Directove proporciona los requisitos de seguridad para los sistemas de ADP. Por

algunos tipos de información, como Sensible Información Compartmented (SCI),

Directiva DoD 5200.28 establece que los otros requisitos de seguridad mínimos también

aplicar. Estos mínimos se encuentran en DCID l / l6 (nuevo número de referencia 5), que es

implementado en DIAM 50-4 (nuevo número de referencia 6) para el Departamento de Defensa y el contratista del Departamento de Defensa

Sistemas de ADP.

A partir de los requisitos impuestos por estos reglamentos, directivas y circulares, la

tres componentes del Objetivo de Control de Política de Seguridad, es decir, obligatoria y

Seguridad discrecional y marcado, así como la rendición de cuentas y

Control de Aseguramiento de Objetivos, puede ser funcionalmente definido para el Departamento de Defensa

aplicaciones. La siguiente discusión proporciona más especificidad en la Política

para estos objetivos de control.

?

7.3 CRITERIOS OBJETIVO DE CONTROL PARA LA POLÍTICA DE SEGURIDAD

7.3.1 Marcado

El objetivo de control para el marcado es: "Los sistemas que están diseñados

para hacer cumplir una política de seguridad obligatoria deben almacenar y conservar la

integridad de clasificación u otro sensibilidad etiquetas para todos

información. Las etiquetas exportadas del sistema deben ser precisos

representaciones de las etiquetas de sensibilidad internos corresonding

siendo exportado ".

DoD 5220.22-M ", Manual de Seguridad Industrial para la protección de

Información Clasificada ", explica en el párrafo 11 de las razones de

marcando información:

"a. General. designación Clasificación por física

marcado, la notación u otros medios sirve para advertir y para

informar al titular qué grado de protección contra

la divulgación no autorizada se reqired para que la información

o material. "(14)

Requisitos de marcado se dan en una serie de declaraciones políticas.

Orden Ejecutiva 12356 (secciones 1.5.a y 1.5.a.1) requiere que

marcas de clasificación "se muestran en la cara de todos

documentos clasificados, o claramente asociados con otras formas de

información clasificada de una manera adecuada al medio

los involucrados. "[14]

DoD Reglamento 5200.1-R (Sección 1-500) requiere que: "...

información o material que requiere la protección contra

la divulgación no autorizada en interés de la seguridad nacional deberá

se clasificarán en una de las tres denominaciones, a saber: 'Top Secret'

"Secreto" o "Confidencial". [7] (Por extensión, para el uso en computadora

procesamiento, la designación no oficial "Sin clasificación" se utiliza para

indicar información que no cae bajo una de la otra

tres denominaciones de información clasificada.)

Reglamento DoD 5200.1-R (Sección 4-304b) requiere que: "ADP

sistemas y sistemas de procesamiento de textos que emplean tales medios deberán

prever clasificación interna que marca para asegurar que

información clasificada contenida en el mismo que se reproduce o

generado, se hará cargo de la clasificación aplicable y asociados

marcas ". (Este Reglamento establece la exención de determinadas

sistemas existentes donde "clasificación interna y aplicable

marcas asociadas no pueden aplicarse sin extenso sistema

modificaciones. "[7] Sin embargo, está claro que el futuro DoD ADP

sistemas deben ser capaces de proporcionar etiquetas aplicables y precisos para

clasificada y otra información sensible.)

DoD 5200.28-M Manual (Sección IV, 4-305d) requiere lo siguiente:

"Etiquetas de seguridad - Todo el material clasificado accesibles por o dentro

el sistema de ADP se identificará como a su seguridad

clasificación y de acceso o de difusión limitaciones, y todo

salida del sistema ADP deberá marcarse debidamente ". [9]

7.3.2 Obligatorio Seguridad

El objetivo de control de la seguridad obligatoria es: "Seguridad

políticas definidas para los sistemas que se utilizan para procesar clasifican

u otra información sensible categorizado específicamente debe

incluir disposiciones para la aplicación de control de acceso obligatorio

reglas. Es decir, deben incluir un conjunto de reglas para el control de

de acceso basado directamente en una comparación de los individuales de

autorización o autorización para la información y la

clasificación o sensibilidad designación de la información es

buscado, e indirectamente en consideraciones de física y otro

factores ambientales de control. El control de acceso obligatorio

reglas deben reflejar con precisión las leyes, reglamentos, y general

las políticas de las que se derivan ".

Hay una serie de declaraciones políticas que se relacionan con

seguridad obligatoria.

Orden Ejecutiva 12356 (sección 4.1.a) establece que "una persona es

elegibles para el acceso a la información clasificada a condición de que un

determinación de la confiabilidad ha sido hecha por los jefes de agencias o

designado funcionarios y siempre que dicho acceso es esencial

a la realización de Gobierno legal y autorizada

fines ". [14]

Reglamento DoD 5200.1-R (Capítulo I, Sección 3) define un Especial

Programa de Acceso como "cualquier programa de imponer la« necesidad de conocer »o acceso

controles más allá de las prestaciones realizadas normalmente por el acceso a

Información secreta confidencial, secreta o Superior. Tal programa

incluye, pero no se limita a, una autorización especial, adjudicación,

o requerimientos de investigación, la designación especial de funcionarios

listas autorizadas para determinar la "necesidad de conocer", o especiales de las personas

decidido a tener un 'know-a-necesidad.' "[7, párr. 1-328] Este

pasaje distingue entre una determinación 'discrecional' de

necesita-a-saber y que se implementa a través de necesidad-a-saber formales

Programas especiales de acceso. DoD Reglamento 5200.1-R, párrafo 7-100

describe los requisitos generales para la fiabilidad (depuración) y

necesita-a-saber, y afirma que la persona con la posesión,

conocimiento ni control de la información clasificada tiene definitiva

la responsabilidad de determinar si las condiciones de acceso han sido

reunió. Este reglamento establece además que "nadie tiene un derecho

a tener acceso a información clasificada únicamente en virtud de rango

o posición ". [7, párr. 7-100])

DoD 5200.28-M Manual (Sección II 2-100) afirma que, Personal "

que desarrollan, de prueba (depuración), mantener o utilizar programas que son

clasificadas o que se utilizará para acceder o desarrollar clasificado

material deberá tener una autorización de seguridad del personal y de un acceso

autorización (necesidad de saber), según corresponda a la más alta

categoría clasificada y más restrictivo de material clasificado

que van a acceder a virtud de las limitaciones del sistema ". [9]

DoD 5220.22-M Manual (3.a párrafo) define el acceso como "el

la capacidad y la oportunidad de obtener conocimiento del clasificado

información. Un individuo, de hecho, puede tener acceso a

información clasificada por estar en un lugar donde dicha información

se mantiene, si las medidas de seguridad que estén en vigor no lo hacen

le impidió ganar conocimiento del clasificado

información ". [11]

Lo anterior Orden Ejecutiva, Manual, Directivas y

Reglamento implica claramente que un sistema informático de confianza debe

aseguran que las etiquetas de clasificación asociados con sensibles

los datos no se pueden cambiar arbitrariamente, ya que esto podría permitir

las personas que carecen de la adecuada habilitación para el acceso

información clasificada. También implícita es el requisito de que un

sistema informático de confianza debe controlar el flujo de información a fin de

que los datos de una clasificación superior no puede ser colocado en una

almacenamiento de objetos de la clasificación más baja a menos que su "degradación"

ha sido autorizado.

7.3.3 Seguridad Discrecional

El término se refiere a la seguridad discrecional de un sistema informático

capacidad de controlar la información en una base individual. Se deriva

del hecho de que a pesar de que un individuo tiene todo lo formal

autorizaciones para el acceso a la información clasificada específica, cada uno

el acceso del individuo a la información debe basarse en un demostrado

necesito saber. Debido a esto, debe quedar claro que esta

requisito no es discrecional en un "lo tomas o lo dejas" sentido.

Las directivas y reglamentos son explícitos en afirmar que la

necesita-a-saber de prueba debe ser satisfecha antes de que pueda concederse el acceso

a la información clasificada. El objetivo de control para

seguridad discrecional es: "Las políticas de seguridad definida para los sistemas

que se utilizan para procesar información sensible clasificada u otro

debe incluir disposiciones para la aplicación de la discrecionalidad

reglas de control de acceso. Es decir, deben incluir un conjunto coherente

de reglas para controlar y limitar el acceso basado en identificado

individuos que se ha determinado que tienen una necesidad de conocer para el

información ".

DoD Reglamento 5200.1-R (Párrafo 7-100) Además de extractos

ya condición de que toque en la necesidad-to-know, esta sección de la

regulación destaca el principio de menor dominio a-saber cuando afirma "no

persona puede tener acceso a información clasificada a menos. . .

el acceso es necesario para el desempeño de funciones oficiales ". [7]

También, DoD 5220.22-M Manual (Sección III 20.a) establece que "una

se le permitirá individuo a tener acceso a clasificado

sólo información . . . cuando el contratista determina que el acceso

es necesaria en el desempeño de las tareas o servicios esenciales para

el cumplimiento de un contrato o programa, es decir, el individuo tiene

una necesidad de conocer ". [11]

?

7.4 CRITERIOS PARA LA RENDICIÓN DE CUENTAS OBJETIVO DE CONTROL

El objetivo de control para la rendición de cuentas es: "Los sistemas que se utilizan para procesar

o el tirador clasificado u otra información sensible debe asegurar individuo

la rendición de cuentas cada vez que sea una política de seguridad obligatoria o discrecional es

invocado. Además, para asegurar la rendición de cuentas de la capacidad debe existir para

un agente autorizado y competente para acceder y evaluar la rendición de cuentas

la información por un medio seguro, dentro de un tiempo razonable, y sin

dificultades excesivas ".

Este objetivo de control se apoya en las siguientes citas:

Directiva DoD 5200.28 (VI.A.1) afirma: "la identidad de cada usuario será

establecido positivamente, y su acceso al sistema, y su actividad en

el sistema (incluyendo material de acceso y medidas adoptadas) controlado y

abrir al escrutinio ". [8]

DoD 5200.28-M Manual (Sección V 5-100) afirma: "Un registro de auditoría o archivo

(manual, máquina, o una combinación de ambos) se mantendrán como

historia de la utilización del Sistema de ADP para permitir una revisión de seguridad regulares

de la actividad del sistema. (por ejemplo, el registro debe registrar la seguridad relacionada

transacciones, incluyendo una visita a un archivo clasificado y la naturaleza

de los accesos, por ejemplo, nombres de usuarios, la producción de cuentas clasificado

salidas, y la creación de nuevos archivos clasificados. Cada archivo clasificado

visitada éxito [con independencia del número de referencias individuales]

durante cada "trabajo" o "sesión interactiva también deben registrarse en el

registro de auditoría. Gran parte del material de este registro también se puede requerir a

asegurar que el sistema conserva la información confiada a él). "[9]

DoD 5200.28-M Manual (Sección 4-305f IV) declara: "Cuando sea necesario para asegurar

el control de acceso y la responsabilidad individual, cada usuario o específica

grupo de usuarios se identificará al Sistema ADP idóneas

administrativas o de hardware / software. Dicha identificación

medidas deben ser lo suficientemente detallada para permitir que el sistema de ADP para proporcionar

el usuario sólo que el material que está autorizado. "[9]

DoD 5200.28-M Manual (Sección I 1-102b) declara:

Autoridades "de componentes designados aprobar, o sus representantes

para este propósito . . . asegurará:

. . . . . . . . . . . . . . . . .

(4) El mantenimiento de la documentación de los sistemas operativos (O / S)

y todas las modificaciones a los mismos, y su retención por un

periodo de tiempo suficiente para habilitar el seguimiento de seguridad-

defectos relacionados a su punto de origen o su inclusión en el

sistema.

. . . . . . . . . . . . . . . . .

(6) El establecimiento de procedimientos para descubrir, recuperar,

manejar y disponer de material clasificado incorrectamente

dado a conocer a través de mal funcionamiento del sistema o el personal de la acción.

(7) la disposición adecuada y la corrección de la seguridad

deficiencias en los sistemas de ADP todos aprobados, y la efectiva

uso y disposición de los registros de limpieza del sistema o de auditoría,

registros de violaciónes de seguridad o sistema relacionado con la seguridad

mal funcionamiento, y los registros de las pruebas de las funciones de seguridad

de un Sistema de ADP. "[9]

Manual DoD 5220.22-M (Sección XIII 111) afirma: "Audit Trails

a. El requisito de seguridad general para cualquier auditoría del sistema ADP

sendero es que proporciona una historia documentada de la utilización de

el sistema. Una pista de auditoría aprobado permitirá la revisión de

la actividad del sistema clasificada y proporcionará una detallada

registro de actividad para facilitar la reconstrucción de eventos para

determinar la magnitud de compromiso (si existe) debe una

produce un mal funcionamiento de la seguridad. Para cumplir con este básico

requisito, los sistemas de seguimiento de auditoría, manual, automático o una

combinación de ambos debe documentar eventos importantes

que ocurre en las siguientes áreas de interés: (i) la preparación

de los datos de entrada y difusión de datos de salida (es decir,

interactividad reportable entre los usuarios y el apoyo del sistema

personal), (ii) la actividad implicada en un entorno ADP

(por ejemplo, ADP modificación personal de apoyo de la seguridad y

controles relacionados), y (iii) la actividad interna de la máquina.

b. La pista de auditoría para un sistema ADP aprobado para procesar

información clasificada debe basarse en los tres anteriores

áreas y pueden ser estilizadas al sistema particular. Todo

sistemas aprobados para el procesamiento clasificado deben contener

la mayoría, si no todos los registros de seguimiento de auditoría se enumeran a continuación. Los

documentación SPP del contratista deberá identificar y describir

las aplicables:

1. Acceso de Personal;

2. La entrada no autorizada y subrepticia en el

instalaciones ordenador central o áreas terminales remotas;

3. Hora de inicio / parada de procesamiento clasificada indicando

iniciación seguridad de los sistemas pertinentes y eventos de terminación

(por ejemplo, la actualización / acciones degradar conformidad con el párrafo

107);

4. Todas las funciones iniciados por la consola del sistema ADP

operadores;

5. Desconecta de terminales remotos y periféricos

dispositivos (párrafo 107C);

6. Iniciar sesión en y desconexión actividad de los usuarios;

7. Los intentos no autorizados de acceder a archivos o programas,

así como todos abrir, cerrar, crear y destruir archivos

acciones;

8. Programa aborta y anomalías incluyendo

información de identificación (es decir, el usuario / nombre del programa, el tiempo

y la ubicación del incidente, etc.);

9. hardware Sistema de adiciones, supresiones y mantenimiento

acciones;

10. Generaciones y modificaciones que afectan a la

características de seguridad del software del sistema.

c. El supervisor de la seguridad del sistema ADP o la persona designada

revisar los registros de seguimiento de auditoría al menos semanalmente para asegurar que

toda la actividad pertinente se registra correctamente y que

las medidas adecuadas se ha tomado para corregir cualquier anomalía.

La mayoría de los sistemas de ADP en uso hoy en día se puede desarrollar la auditoría

sistemas de senderos de acuerdo con lo anterior; sin embargo, especial

sistemas tales como armas, comunicaciones, comunicaciones

sistemas de seguridad y de intercambio de datos tácticos y de visualización,

puede no ser capaz de cumplir con todos los aspectos de lo anterior y

puedan exigir una atención individualizada por el consciente

Oficina de seguridad.

d. Los registros de seguimiento de auditoría se conservarán durante un período de un

ciclo de inspección. "[11]

?

7.5 CRITERIOS OBJETIVOS DE CONTROL DE ASEGURAMIENTO

El objetivo de control para la garantía es: "Los sistemas que se utilizan para procesar o

mango clasificado u otra información sensible debe estar diseñado para garantizar

interpretación correcta y precisa de la política de seguridad y no debe distorsionar

la intención de esta política. Aseguramiento de que el producto correcto

existe aplicación y el funcionamiento de la política en todo el sistema de

ciclo de la vida."

A base de este objetivo se puede encontrar en las siguientes secciones del Departamento de Defensa

Directiva 5200.28:

Directiva DoD 5200.28 (IV.B.1) estipula: "En general, la seguridad de un ADP

sistema es más eficaz y económica si el sistema está diseñado

originalmente para proporcionarla. Cada Departamento de Defensa de componentes

emprender el diseño de un sistema de ADP, que se espera para procesar, almacenar,

utilizar o producir material clasificado deberá: Desde el inicio de la

proceso de diseño, tener en cuenta las políticas de seguridad, conceptos y medidas

prescrito en la presente Directiva ". [8]

Directiva DoD 5200.28 (IV.C.5.a) afirma: "Se puede prever para permitir

el ajuste de área del sistema ADP controles para el nivel de protección

requerido para la categoría de clasificación y tipo (s) de material de hecho

siendo manejado por el sistema, se desarrollan procedimientos de cambio previstos y

implementado, lo que impide tanto el acceso no autorizado a los clasificados

material manipulado por el sistema y la manipulación no autorizada de la

sistema y sus componentes. Se prestará especial atención a la

la protección continua de las medidas de seguridad del sistema automatizado, técnicas

y procedimientos cuando el nivel de autorización de seguridad personal de los usuarios

tener acceso a los cambios en el sistema ". [8]

Directiva DoD 5200.28 (VI.A.2) afirma: "Control Ambiental La ADP.

Sistema estará protegido externamente para minimizar la probabilidad de

acceso no autorizado a los puntos de entrada del sistema, acceso a clasificado

información en el sistema, o daños en el sistema ". [8]

DoD 5200.28-M Manual (Sección I 1-102b) declara:

Autoridades "de componentes designados aprobar, o sus representantes

para este propósito . . . asegurará:

. . . . . . . . . . . . . . . . .

(5) La supervisión, monitoreo y pruebas, según proceda, de

cambios en un sistema de ADP aprobado que pudieran afectar a la

características de seguridad del sistema, por lo que un sistema seguro es

mantenido.

. . . . . . . . . . . . . . . . .

(7) la disposición adecuada y la corrección de la seguridad

deficiencias en los sistemas de ADP todos aprobados, y la efectiva

uso y disposición de los registros de limpieza del sistema o de auditoría,

registros de violaciónes de seguridad o sistema relacionado con la seguridad

mal funcionamiento, y los registros de las pruebas de las funciones de seguridad

de un Sistema de ADP.

(8) Realización de sistema competente ST & E, la revisión oportuna de

sistema de ST & E informes, y la corrección de las deficiencias necesarios

para apoyar la aprobación o desaprobación condicional o definitiva de

un Sistema de ADP para el procesamiento de la información clasificada.

(9) El establecimiento, en su caso, de un centro de ST & E

punto de coordinación para el mantenimiento de registros de

técnicas seleccionadas, procedimientos, estándares y pruebas utilizadas

en las pruebas y evaluación de las características de seguridad de ADP

Sistemas que pueden ser adecuados para la validación y el uso de

otra Departamento de Componentes de Defensa ". [9]

Manual DoD 5220.22-M (Sección XIII 103a) exige que: "la aprobación inicial,

por escrito, de la oficina de seguridad consciente antes de procesar cualquier

información clasificada en un sistema de ADP. Esta sección requiere

reaprobación por la oficina de seguridad consciente de los sistemas principales

modificaciones hechas con posterioridad a la aprobación inicial. Reapprovals serán

requerido por (i) cambios importantes en los requisitos de acceso de personal,

(ii) reubicación o modificación estructural de la computadora central

instalación, (iii) adiciones, supresiones o cambios de marco principal, almacenamiento o

dispositivos de entrada / salida, (iv) los cambios de software del sistema de seguridad impactando

características de protección, (v) cualquier cambio en el aclaramiento, desclasificación, la auditoría

camino o de hardware / software de los procedimientos de mantenimiento, y (vi) otros sistemas

cambios determinados por la oficina de seguridad consciente ". [11]

Un componente importante de la garantía, la garantía de ciclo de vida, como se describe en el Departamento de Defensa

7920.l Directiva, tiene que ver con los sistemas de pruebas de ADP, tanto en el

fase de desarrollo, así como durante el funcionamiento (17). Directiva DoD 5215.1

(Sección F.2.C. (2)) requiere "evaluaciones de la industria seleccionada y

gobierno-desarrollado sistemas informáticos de confianza en contra de estos criterios ". [10]

?

8.0 Una directriz sobre canales encubiertos

Un canal secreto es cualquier canal de comunicación que puede ser explotado por una

proceso para transferir información de una manera que viole el sistema de

politica de seguridad. Hay dos tipos de canales: canales encubiertos almacenamiento y

canales de distribución. Canales de almacenamiento Covert incluir todos los vehículos que lo haría

permitir que la escritura directa o indirecta de una ubicación de almacenamiento por un proceso y

la lectura directa o indirecta de la misma por otro. Canales de temporización Covert

incluir todos los vehículos que permitan un proceso a la señal de información a

otro proceso mediante la modulación de su propio uso de los recursos del sistema de tal manera

que el cambio en el tiempo de respuesta observado por el segundo proceso proporcionaría

información.

Desde una perspectiva de seguridad, canales encubiertos con anchos de banda bajos representan una

amenaza menor que aquellos con altos anchos de banda. Sin embargo, para muchos tipos de

canales encubiertos, las técnicas utilizadas para reducir el ancho de banda por debajo de una cierta tasa

(que depende del mecanismo de canal específico y la arquitectura del sistema)

también tienen el efecto de degradar el rendimiento proporcionado para legitimar

los usuarios del sistema. Por lo tanto, un equilibrio entre el rendimiento del sistema y encubierta

ancho de banda de canal se debe hacer. Debido a la amenaza de compromiso que

estaría presente en cualquier sistema informático multinivel contiene clasificada o

información sensible, tales sistemas no debe contener canales encubiertos con

altos anchos de banda. Esta guía tiene como objetivo proporcionar a los desarrolladores del sistema con

una idea de qué tan alto ancho de banda de un canal secreto "alta" es.

Un ancho de banda de canal encubierto que supera una velocidad de cien (100) bits por

segundo se considera "alta" porque 100 bits por segundo es la aproximada

velocidad a la que se ejecutan muchos terminales de ordenador. No parece apropiado

para llamar a un sistema informático "seguro" si la información se puede comprometer a un ritmo

igual a la velocidad de salida normal de algún dispositivo de uso común.

En cualquier sistema informático multinivel hay una serie de relativamente

bajo ancho de banda canales encubiertos cuya existencia está profundamente arraigado en la

diseño de sistemas. Ante el gran costo potencial de reducir los anchos de banda

de tales canales encubiertas, se considera que aquellos con anchos de banda máxima de menos

de un (1) bits por segundo son aceptables en la mayoría de entornos de aplicación.

Aunque mantiene un rendimiento aceptable en algunos sistemas puede hacer que sea

poco práctico para eliminar todos los canales encubiertas con anchos de banda de 1 o más bits

por segundo, es posible auditar su uso sin afectar adversamente

rendimiento de sistema. Esta capacidad de auditoría proporciona la administración del sistema

con un medio de detección - corrección y procesalmente - significativo

compromiso. Por lo tanto, una Base de Trusted Computing debe proporcionar, siempre que sea

posible, la capacidad de auditar el uso de mecanismos de canales encubiertos con

anchos de banda que pueden superar a razón de un (1) bits en diez (10) segundos.

El problema canal secreto ha sido tratado por varios autores. Los

lector interesado puede consultar las referencias [5], [6], [19], [21], [22], [23],

y [29].

?

9.0 una directriz sobre la configuración de funciones control de acceso obligatorio

El requisito de control de acceso obligatorio incluye una capacidad para apoyar una

número no especificado de las clasificaciones jerárquicas y un número no especificado

de categorías no jerárquicas en cada nivel jerárquico. Para fomentar

coherencia y la transferibilidad en el diseño y desarrollo de la National

Establecimiento de Seguridad de los sistemas informáticos de confianza, es deseable para todos tales

sistemas para ser capaz de soportar un número mínimo de niveles y categorías. Los

siguientes sugerencias se proporcionan para este propósito:

* El número de clasificaciones jerárquicas debe ser mayor o

igual a dieciséis (16).

* El número de categorías no jerárquicas debe ser mayor o

igual a sesenta y cuatro (64).

?

10.0 Una GUÍA SOBRE LAS PRUEBAS DE SEGURIDAD

Estas directrices se proporcionan para dar una indicación de la extensión y

sofisticación de la prueba llevada a cabo por el Centro de seguridad de computadoras del Departamento de Defensa

durante el proceso de evaluación formal del producto. Las organizaciones que deseen utilizar

"Departamento de Defensa Trusted Computer System Evaluation Criteria" para

realizar sus propias evaluaciones puede encontrar esta sección útil para la planificación

propósitos.

Como en la primera parte, el resaltado se utiliza para indicar los cambios en las pautas de

la categoría inmediatamente inferior.

?

10.1 ENSAYO DE LA DIVISIÓN C

10.1.1 Personal

El equipo de pruebas de seguridad estará integrado por al menos dos

individuos con una licenciatura en Ciencias de la Computación o la

equivalente. Los miembros del equipo deben ser capaces de seguir los planes de prueba

preparado por el desarrollador del sistema y sugerir adiciones, se

estar familiarizados con la "hipótesis de falla" o garantía equivalente

probar la metodología, y tendrán la programación a nivel de montaje

experiencia. Antes de que comience la prueba, los miembros del equipo tendrán

conocimiento funcional de, y habrá completado el sistema

Por supuesto internos del desarrollador para el sistema que se está evaluando.

10.1.2 Prueba

El equipo tendrá "manos" participación en una carrera independiente

de las pruebas utilizadas por el desarrollador del sistema. El equipo deberá

independientemente diseñar y poner en práctica específica del sistema por lo menos cinco

pruebas en un intento de eludir los mecanismos de seguridad de la

sistema. El tiempo transcurrido dedicado a las pruebas será de al menos

un mes y no necesita ser superior a tres meses. No habrá

menos de veinte práctica en horas pasadas realización de sistema

pruebas para desarrolladores definidos y pruebas de equipos definidos de prueba.

?

10.2 ENSAYO DE LA DIVISIÓN B

10.2.1 Personal

El equipo de pruebas de seguridad estará integrado por al menos dos

individuos con una licenciatura en Ciencias de la Computación o la

equivalente y al menos una persona con un grado de maestría en

Ciencia o equivalente ordenador. Los miembros del equipo deben ser capaces de

seguir los planes de pruebas preparados por el desarrollador del sistema y sugerir

adiciones, deberán estar familiarizados con la "hipótesis de falla" o

metodología de las pruebas de seguridad equivalente, deberá ser fluido en el

TCB lenguaje de implementación (s), y tendrá nivel de ensamblado

experiencia en programación. Antes de la prueba comienza, los miembros del equipo

tendrá conocimiento funcional de, y habrá completado la

Por supuesto internos del desarrollador del sistema para, siendo el sistema

evaluado. Al menos un miembro del equipo deberá tener previamente

completado una prueba de seguridad en otro sistema.

10.2.2 Prueba


del paquete de prueba utilizado por el desarrollador del sistema para probar

hardware y software de seguridad pertinentes. El equipo deberá

independientemente diseñar e implementar por lo menos quince sistema-

pruebas específicas en un intento de eludir la seguridad

mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas

será como mínimo de dos meses y no tiene por qué ser superior a cuatro meses.

No habrá menos de treinta manos a la hora por equipo

miembro pasó la realización de pruebas para desarrolladores definidas por el sistema y

prueba de equipo define pruebas.

?

10.3 ENSAYO DE LA DIVISIÓN A

10.3.1 Personal

El equipo de pruebas de seguridad estará integrado por al menos un

persona con una licenciatura en Ciencias de la Computación o la

equivalente y al menos dos personas con grados de maestría en

Ciencia o equivalente ordenador. Los miembros del equipo deben ser capaces de

seguir los planes de pruebas preparados por el desarrollador del sistema y sugerir

adiciones, deberán estar familiarizados con la "hipótesis de falla" o

metodología de las pruebas de seguridad equivalente, deberá ser fluido en el

TCB lenguaje de implementación (s), y tendrá nivel de ensamblado

experiencia en programación. Antes de la prueba comienza, los miembros del equipo

tendrá conocimiento funcional de, y habrá completado la

Por supuesto internos del desarrollador del sistema para, siendo el sistema

evaluado. Al menos un miembro del equipo deberá ser lo suficientemente familiarizado

con el hardware del sistema para comprender el mantenimiento de diagnóstico

los programas y la documentación de soporte de hardware. Al menos dos

los miembros del equipo deberán haber realizado previamente una prueba de seguridad en

otro sistema. Al menos un miembro del equipo tendrá

competencia de programación a nivel de sistema demostrado en el sistema

bajo prueba a un nivel de complejidad equivalente a la adición de un dispositivo

controlador al sistema.

10.3.2 Prueba


del paquete de prueba utilizado por el desarrollador del sistema para probar

hardware y software de seguridad pertinentes. El equipo deberá

independientemente diseñar e implementar al menos veinticinco sistema-

pruebas específicas en un intento de eludir la seguridad

mecanismos del sistema. El tiempo transcurrido dedicado a las pruebas

será como mínimo de tres meses y no tiene por qué ser superior a seis meses.

No habrá menos de cincuenta manos a la hora por equipo

miembro pasó la realización de pruebas para desarrolladores definidas por el sistema y

prueba de equipo define pruebas.

?

APÉNDICE A

PROCESO DE EVALUACIÓN PRODUCTO COMERCIAL

"Departamento de Defensa Trusted Computer System Evaluation Criteria" forma la

base sobre la que el Centro de Seguridad Informática realizará el anuncio

proceso de evaluación de la seguridad informática. Este proceso se centra en el comercio

de propósito general productos producidos y apoyados sistema operativo que cumplen con la

necesidades de los departamentos y agencias gubernamentales. La evaluación formal se dirige

en "off-the-shelf" comercialmente apoyado productos y está completamente divorciado

de cualquier consideración de rendimiento general del sistema, las aplicaciones potenciales,

o entornos de procesamiento particulares. La evaluación proporciona un insumo clave para

una seguridad del sistema informático de aprobación / acreditación. Sin embargo, no lo hace

constituyen una evaluación completa seguridad del sistema informático. Un estudio completo

(por ejemplo, como en la referencia [18]) deben considerar factores adicionales tratar con el

sistema en su ambiente único, tal como se propone el modo de seguridad de

operación, usuarios específicos, aplicaciones, la sensibilidad de datos, física y

la seguridad personal, administrativo y de seguridad procesal, tempestad, y

seguridad de las comunicaciones.

El proceso de evaluación del producto realizado por el Centro de Seguridad Informática tiene

tres elementos distintos:

* Evaluación preliminar del producto - Un diálogo informal entre un vendedor

y el Centro en el que se intercambia información técnica para crear un

entendimiento común de producto del proveedor, los criterios y el

calificación que se puede esperar que el resultado de una evaluación formal del producto.

* Evaluación formal Producto - Una evaluación formal, por el Centro, de un

producto que está disponible para el Departamento de Defensa, y que da lugar a que el producto

y su calificación asignada se coloca en la Lista de Productos evaluadas.

* Lista evaluadas Productos - Una lista de los productos que han sido sometidos

para la evaluación del producto formal y sus calificaciones asignadas.

Evaluación Preliminar del producto

Puesto que es generalmente muy difícil añadir medidas de seguridad eficaces tarde

en el ciclo de vida de un producto, el Centro está interesado en trabajar con el sistema

vendedores en las primeras etapas de diseño de producto. Un producto preliminar

evaluación permite al Centro de consultar con los proveedores de equipo en equipo

los problemas de seguridad que se encuentran en productos que aún no se han anunciado formalmente.

Una evaluación preliminar se inicia típicamente por los vendedores de sistemas informáticos que

están planeando nuevos productos informáticos que cuentan con la seguridad o importante

actualizaciones relacionadas con la seguridad de los productos existentes. Después de una reunión inicial

entre el vendedor y el Centro, los acuerdos de confidencialidad adecuados

ejecutada que requieren el Centro a mantener la confidencialidad de cualquier

propiedad de la información revelada a él. Reuniones de intercambio técnicos siguen

en el que el vendedor ofrece detalles sobre el producto propuesto (en particular,

sus diseños internos y metas) y el Centro proporciona retroalimentación de expertos para la

vendedor en posibles puntos fuertes y débiles del proveedor de seguridad informática

diseñar opciones, así como la interpretación de los criterios relevantes. Los

evaluación preliminar se termina típicamente cuando se completa el producto

y listo para el lanzamiento de campo por el vendedor. Tras la rescisión, el Centro

prepara un informe de finalización para el vendedor y para la distribución interna dentro

el centro. Estos informes contienen información de propiedad no son

a disposición del público.

Durante la evaluación preliminar, el vendedor no tiene ninguna obligación de realidad

completar o comercializar el producto potencial. El Centro es, del mismo modo, no

comprometido a llevar a cabo una evaluación formal del producto. Una evaluación preliminar

podrá ser denunciado por cualquiera de Centro o el proveedor cuando se notifique a la

otra, por escrito, que ya no es ventajoso para continuar la

evaluación.

Evaluación del producto Formal

La evaluación formal producto proporciona un insumo clave para la certificación de un

sistema informático para su uso en aplicaciones nacionales de establecimientos de Seguridad y es

la única base para un producto que se coloca en la Lista de Productos evaluadas.

Una evaluación formal del producto comienza con una solicitud por un proveedor para el Centro

para evaluar un producto para el que el producto en sí y acompañar

la documentación necesaria para cumplir los requisitos definidos en la presente publicación son

completa. Acuerdos de no divulgación se ejecutan y un producto oficial

equipo de evaluación está formado por el Centro. Una primera reunión se celebró a continuación, con

el vendedor para trabajar el horario para la evaluación formal. Desde pruebas

del producto aplicado forma una parte importante del proceso de evaluación,

Acceso por el equipo de evaluación a una versión de trabajo del sistema se negocia

con el vendedor. El apoyo adicional requerido por parte del proveedor incluye

documentación completa de diseño, código fuente, y el acceso al personal de los proveedores que

puede responder a preguntas detalladas sobre partes específicas del producto. Los

equipo de evaluación pone a prueba el producto contra cada requisito, por lo que cualquier

interpretaciones necesarias de los criterios con respecto al producto de ser

evaluado.

El equipo de evaluación redacta un informe final sobre sus hallazgos sobre el sistema.

El informe está disponible al público (que no contiene propietaria o confidencial

información) y contiene la calificación global de clase asignado al sistema y

los detalles de los resultados del equipo del evalution al comparar el producto contra

los criterios de evaluación. Información detallada sobre vulnerabilidades encontradas

por el equipo de evaluación está amueblado a los desarrolladores de sistemas y diseñadores como

cada uno se encuentra para que el vendedor tiene la oportunidad de eliminar el mayor número de ellos como

posible antes de la finalización de la evaluación formal del producto.

Análisis de vulnerabilidad y otra información confidencial o sensible son

controlada dentro del Centro a través del Programa de Información y Vulnerabilidad

se distribuyen únicamente en el Gobierno de Estados Unidos en una necesidad de conocer-estricto y

no divulgación base, y para el vendedor.?

ANEXO B

RESUMEN DE LAS DIVISIONES criterios de evaluación

Las divisiones de los sistemas reconocidos en el sistema informático de confianza

criterios de evaluación son los siguientes. Cada división representa un importante

mejora en la confianza general se puede colocar en el sistema para proteger

información confidencial clasificada y otra.

División (D): Protección Mínimo

Esta división contiene una sola clase. Se reserva para aquellos sistemas que

han sido evaluados, pero que no cumplen con los requisitos para una mayor

clase de evaluación.

División (C): Protección Discrecional

Las clases de esta división prevén (necesidad de conocer) la protección discrecional

y, a través de la inclusión de mecanismos de auditoría, para la rendición de cuentas

temas y las acciones que inician.

División (B): Protección obligatoria

La noción de un TCB que preserve la integridad de las etiquetas de sensibilidad y

los utiliza para hacer cumplir una serie de reglas de control de acceso obligatorio es un importante

requisito en esta división. Sistemas de esta división deben llevar el

sensibilidad etiquetas con las principales estructuras de datos en el sistema. El sistema

desarrollador también ofrece el modelo de la política de seguridad en la que se basa la TCB

y proporciona una especificación de la TCB. La evidencia debe ser proporcionada a

demostrar que el concepto de monitor de referencia ha sido implementado.

División (A): Protección Verified

Esta división se caracteriza por el uso de la verificación de seguridad formal

métodos para asegurar que los controles de seguridad obligatorios y discrecionales

empleado en el sistema puede proteger eficazmente clasificado u otro sensible

información almacenada o procesada por el sistema. Amplia documentación es

requerida para demostrar que la TCB cumple con los requisitos de seguridad en todo

aspectos de diseño, desarrollo e implementación.

?

ANEXO C

RESUMEN DE LAS CLASES DE CRITERIOS DE EVALUACIÓN

Las clases de sistemas reconocidos en la evaluación del sistema informático de confianza

criterios son los siguientes. Se presentan en el orden creciente de

desirablity desde un punto de vista de la seguridad informática.

Clase (D): Protección Mínimo

Esta clase está reservada para aquellos sistemas que han sido evaluados, sino que

no cumplen con los requisitos para una clase de evaluación superior.

Clase (C1): Protección Seguridad Discrecional

La Base de Trusted Computing (TCB) de una clase (C1) del sistema nominalmente satisface

los requisitos de seguridad discrecionales al proporcionar separación de usuarios y

datos. Incorpora alguna forma de controles creíbles, capaces de hacer cumplir

limitaciones de acceso de forma individual, es decir, con el pretexto adecuado para

permitiendo a los usuarios para poder proteger a proyecto o información privada y

mantener a los demás usuarios de la lectura de forma accidental o la destrucción de sus datos. Los

Se espera que la clase (C1) el medio ambiente a ser uno de cooperar procesamiento usuarios

los datos en el mismo nivel (s) de la sensibilidad.

Clase (C2): Controlado Access Protection

Sistemas de esta clase hacen cumplir un acceso discrecional más de grano fino

usuarios de control de sistemas (C1), por lo que individualmente responsables de su

acciones a través de los procedimientos de acceso, la auditoría de los eventos relevantes para la seguridad, y

aislamiento de recursos.

Clase (B1): Etiquetado de Protección de la Seguridad

Sistemas (B1) Clase requieren todas las características requeridas para la clase (C2). En

Además, una declaración informal de la modelo de la política de seguridad, el etiquetado de datos,

y control de acceso obligatorio sobre los sujetos y objetos con nombre debe estar presente.

La capacidad debe existir para marcar con precisión la información exportada. Alguna

defectos identificados por pruebas deben ser removidos.

Clase (B2): Protección Estructurado

En los sistemas de (B2) de clase, la TCB se basa en un claramente definido y documentado

modelo de política de seguridad formal que requiere el discrecional y obligatorio

la aplicación de control de acceso que se encuentra en los sistemas (B1) de clase se extenderá a todos

sujetos y objetos en el sistema de ADP. Además, los canales encubiertos son

abordarse. El TCB debe estructurarse con cuidado en la protección-crítico y

elementos de protección crítico no. La interfaz de TCB está bien definido y de la

Diseño e implementación TCB permiten que pueda ser sometido a más exhaustiva

pruebas y revisión más completa. Mecanismos de autenticación se fortalecen,

la gestión de instalaciones de confianza se proporciona en forma de soporte para el sistema

funciones de administrador y operador, y gestión de la configuración estrictas

se imponen controles. El sistema es relativamente resistente a la penetración.

Clase (B3): Dominios de Seguridad

La clase (B3) TCB debe satisfacer los requisitos del monitor de referencia que

mediar en todos los accesos de los sujetos a los objetos, será inviolable, y ser pequeño

suficiente para ser sometidos a análisis y pruebas. Para este fin, la TCB es

estructurado para excluir el código no es esencial para la aplicación de la política de seguridad, con

ingeniería de sistemas significativa durante el diseño y la aplicación dirigida TCB

para minimizar su complejidad. Un administrador de seguridad es compatible,

mecanismos de auditoría se expanden para señalar acontecimientos seguridad- pertinentes, y el sistema

se requieren procedimientos de recuperación. El sistema es altamente resistente a

penetración.

Clase (A1): Diseño Verified

Sistemas en la clase (A1) son funcionalmente equivalentes a los de la clase (B3) en

que no se añaden características arquitectónicas adicionales o requisitos de la política.

La característica distintiva de los sistemas de esta clase es el análisis derivado

desde la especificación de diseño formal y técnicas de verificación y la resultante

alto grado de seguridad de que la TCB se implementa correctamente. Esta

aseguramiento del desarrollo es en la naturaleza, a partir de un modelo formal de la

la política de seguridad y una especificación de alto nivel formales (FTLs) del diseño. En

consonancia con el análisis extenso diseño y desarrollo de la TCB requerido

de los sistemas de la clase (A1), se requiere la administración de configuración más estricta

y se establezcan procedimientos para distribuir de forma segura el sistema a los sitios.

Un administrador de la seguridad del sistema es compatible.

?

APÉNDICE D

DIRECTORIO REQUISITO

Este apéndice enumera los requisitos definidos en el "Departamento de Defensa Trusted

Computer System Evaluation Criteria "alfabéticamente en lugar de por clase. It

se proporciona para ayudar en el seguimiento de la evolución de un requisito a través de la

clases. Para cada requisito, tres tipos de criterios pueden estar presentes. Cada

será precedida por la palabra: NUEVO, CAMBIO, o ADD para indicar lo siguiente:

NUEVO: Cualquier criterio que aparece en una clase inferior son reemplazadas

por los criterios que siguen.

CAMBIO: Los criterios que siguen han aparecido en una clase inferior

pero se cambian para esta clase. Se utiliza Resaltado

para indicar los cambios específicos ya se ha dicho

criterios.

ADD: Los criterios que siguen no han sido requeridos para cualquier

clase baja, y se añaden en esta clase a la

se ha indicado anteriormente los criterios para este requisito.

Las abreviaturas se utilizan de la siguiente manera:

NR: (No hay requisito) Este requisito no se incluye en

esta clase.

NAR: (No hay requisitos adicionales) Este requisito no se

cambiar de la clase anterior.

Se remite al lector a la Parte I de este documento al colocar nuevos criterios

para un requisito en el contexto completo para esa clase.

Figura 1 se presenta un resumen pictórico de la evolución de las necesidades a través de

las clases.

Auditoría

C1: NR.

C2: NUEVO: La TCB será capaz de crear, mantener y proteger de la

modificación o acceso no autorizado o la destrucción de una pista de auditoría de

accesos a los objetos que protege. Los datos de auditoría deberán ser

protegida por el TCB de manera que a ella se limita a aquellos acceso de lectura

que están autorizados para los datos de auditoría. El TCB deberá ser capaz de grabar

los siguientes tipos de eventos: uso de identificación y

mecanismos de autenticación, introducción de objetos en un usuario de

espacio de direcciones (por ejemplo, abrir el archivo, la iniciación del programa), la supresión de

objetos y acciones realizadas por operadores de computadoras y el sistema

administradores y / o funcionarios de seguridad del sistema y otra de seguridad

eventos relevantes. Para cada evento registrado, el registro de auditoría,

identificar: fecha y hora del evento, el usuario, el tipo de evento, y el éxito

o el fracaso del evento. Para eventos de identificación / autenticación las

origen de la solicitud (por ejemplo, la terminal ID) se incluirá en la auditoría

récord. Para los eventos que introducen un objeto en la dirección de un usuario

espacio y para los eventos de deleción objeto el registro de auditoría deberá incluir

el nombre del objeto. El administrador del sistema ADP deberá ser capaz de


identidad individual.

B1: CAMBIO: Para los eventos que introducen un objeto en la dirección de un usuario

espacio y para los eventos de deleción objeto el registro de auditoría deberá incluir

el nombre del objeto y el nivel de seguridad del objeto. La ADP

el administrador del sistema deberá ser capaz de auditar selectivamente las acciones

de cualesquiera uno o más usuarios en base a la identidad y / o objeto individual

nivel de seguridad.

ADD: El TCB también podrá auditar cualquier anulación de

marcas de salida legibles.

B2: ADD: El TCB podrá auditar los eventos identificados que pueden ser

utilizado en la explotación de canales de almacenamiento encubiertas.

B3: ADD: El TCB deberá contener un mecanismo que es capaz de controlar la

aparición o acumulación de eventos auditables de seguridad que puedan

indicar una violación inminente de la política de seguridad. Este mecanismo

será capaz de notificar inmediatamente al administrador de seguridad cuando

umbrales se exceden, y, si la ocurrencia o la acumulación de

estos eventos relevantes de seguridad continúa, el sistema tomará la

arrendar acción disruptiva para terminar el evento.

A1: NAR.

Gestión de la Configuración

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: Durante el desarrollo y mantenimiento de la TCB, una configuración

sistema de gestión será en el lugar que mantiene el control de cambios

a la memoria descriptiva de nivel superior, otros datos de diseño,

documentación de la aplicación, el código fuente, la versión de funcionamiento de la

código objeto, y accesorios de la prueba y la documentación. La configuración

sistema de gestión deberá asegurar una correspondencia constante entre todos

documentación y código asociado con la versión actual de la TCB.

Herramientas se proporcionan para la generación de una nueva versión de la TCB

desde el código fuente. También disponible serán herramientas para la comparación de una

versión con la versión anterior TCB recién generado con el fin de

asegurarse de que sólo los cambios previstos se han hecho en el código

que realmente se utiliza como la nueva versión de la TCB.

B3: NAR.

A1: CAMBIO: Durante todo el ciclo de vida, es decir, durante el diseño,

desarrollo y mantenimiento de la TCB, una gestión de la configuración

sistema deberá estar en su lugar para que todos relevante para la seguridad de hardware, firmware,

y el software que mantiene el control de cambios en el modelo formal,

las especificaciones descriptivas y formales de nivel superior, otro diseño

de datos, documentación aplicación, código fuente, la versión que se ejecuta

del código objeto, y accesorios de la prueba y la documentación. También

disponibles serán herramientas, mantenidos bajo estricta configuración

control, para comparar una versión recién generado con el anterior

Versión TCB, a fin de asegurarse de que sólo los cambios previstos tienen

ha logrado en el código que realmente se utiliza como la nueva versión

del TCB.

ADD: Una combinación de técnicas, físicas y de procedimiento

se utilizará para proteger de la modificación no autorizada o

la destrucción de la copia maestra o copias de todo el material utilizado para

generar la TCB.

Análisis Canal Covert

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para encubierta

canales de almacenamiento y hacer una determinación (ya sea por real

medición o por estimación de ingeniería) del ancho de banda máximo de

cada canal identificado. (Vea la sección de Orientación Canales Covert.)

B3: CAMBIO: El desarrollador del sistema llevará a cabo una búsqueda exhaustiva para

canales encubiertos y tomar una determinación (ya sea por real

medición o por estimación de ingeniería) del ancho de banda máximo

de cada canal identificado.

A1: ADD: métodos formales se utilizan en el análisis.

Diseño Documentación

C1: NUEVO: La documentación debe estar disponible que proporciona una descripción de

La filosofía de los fabricantes de protección y una explicación de cómo

esta filosofía se traduce en la TCB. Si el TCB se compone

de módulos distintos, las interfaces entre estos módulos serán

descrito.

C2: NAR.

B1: ADD: Una descripción informal o formal del modelo de la política de seguridad

forzada por la TCB estarán disponibles y una explicación proporcionada a

muestran que es suficiente para hacer cumplir la política de seguridad. Los

mecanismos específicos de protección TCB se identificarán y un

explicación dada para demostrar que satisfacen el modelo.

B2: CAMBIO: Las interfaces entre los módulos de TCB se describirán. LA

descripción formal del modelo de política de seguridad aplicada por el TCB

deberán estar disponibles y demostrado que es suficiente para cumplir la

politica de seguridad.

ADD: La especificación de alto nivel descriptivo (DTLS) se muestra a

ser una descripción exacta de la interfaz de TCB. Documentación

describen cómo la TCB implementa el concepto monitor de referencia y

dar una explicación de por qué se resistente a la manipulación, no puede ser anulada,

y se ha implementado correctamente. La documentación debe describir cómo el

TCB está estructurado para facilitar las pruebas y hacer cumplir menos

privilegio. Esta documentación deberá presentar también los resultados de la

análisis de canal encubierta y las compensaciones implicadas en la restricción de la

canales. Todos los eventos auditables que se pueden utilizar en la explotación

se identificarán los canales de almacenamiento encubiertas de conocidos. Las anchuras de banda

de canales de almacenamiento encubiertas conocidas, cuyo uso no es detectable

por los mecanismos de auditoría, se facilitará. (Vea el Covert

Sección de Orientación del canal.)

B3: ADD: La aplicación TCB (es decir, en el hardware, firmware y

software) se indicará de manera informal para ser coherente con los DTLS.

Los elementos de la DTLS se indicarán, utilizando técnicas informales,

para corresponder a los elementos de la TCB.

A1: CAMBIO: La aplicación TCB (es decir, en el hardware, firmware y

software) se indicará de manera informal para ser coherente con lo formal

especificación de nivel superior (FTLs). Los elementos de los FTLs serán

se muestra, usando técnicas informales, para corresponder a los elementos de

la TCB.

ADD: hardware, el firmware y los mecanismos de software no mencionadas en

el FTLs pero estrictamente interno a la TCB (por ejemplo, registros cartográficos,

Acceso directo a la memoria de E / S) se describirán con claridad.

Especificaciones de Diseño y Verificación

C1: NR.

C2: NR.

B1: NUEVO: Un modelo formal o informal de la política de seguridad con el apoyo de

la TCB se mantiene a lo largo del ciclo de vida del sistema ADP que

se demuestra que es coherente con sus axiomas.

B2: CAMBIO: Un modelo formal de la política de seguridad con el apoyo de la TCB

se mantendrán durante todo el ciclo de vida del sistema ADP que es

demostrado en consonancia con sus axiomas.

ADD: Una memoria descriptiva de nivel superior (DTLS) del TCB será

sostuvo que completa y precisa describe la TCB en términos

de excepciones, mensajes de error y efectos. Queda demostrado ser

una descripción exacta de la interfaz de TCB.

B3: ADD: Un argumento convincente se dará de que el DTLS es consistente

con el modelo.

A1: CAMBIO: Los FTLs se demuestra que es una descripción exacta de la

Interfaz de TCB. Un argumento convincente se dará de que el DTLS es

consistente con el modelo y una combinación de formal e informal

se emplearán técnicas para demostrar que el FTLs es consistente con la

modelo.

ADD: Una especificación de alto nivel formales (FTLs) del TCB será

sostenido que describe con precisión la TCB en términos de excepciones,

mensajes de error, y efectos. Los DTLS y FTLs incluirán las

componentes de la TCB que se implementan como hardware y / o

firmware si sus propiedades son visibles en la interfaz de TCB. Esta

pruebas de verificación deberá ser coherente con la prevista en

el estado-del-arte de lo particular Center- Seguridad Informática

especificación formal avalado y sistema de verificación utilizados. Manual

u otro mapeo de las FTLs al código fuente TCB será

realizado para proporcionar evidencia de la implementación correcta.

Las etiquetas de dispositivo

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: La TCB apoyará la asignación de mínimo y máximo

niveles de seguridad a todos los dispositivos físicos conectados. Estos seguridad

niveles serán utilizados por el TCB para hacer cumplir las limitaciones impuestas por

el entorno físico en el que se ubican los dispositivos.

B3: NAR.

A1: NAR.

Control de acceso discrecional

C1: NUEVO: La TCB definirá y control de acceso entre los usuarios con nombre y



listas de control) deberán permitir a los usuarios especificar y controlar el intercambio de

esos objetos por parte de personas con nombre o grupos definidos o ambos.

C2: CAMBIO: El mecanismo de aplicación (por ejemplo, auto / grupo / controles públicos,


compartir de esos objetos por las personas nombradas, o grupos definidos de

individuos, o por ambos, y proporcionarán los controles para limitar

propagación de los derechos de acceso.

ADD: El mecanismo de control de acceso discrecional deberá, ya sea explícita

acción del usuario o por defecto, se establece que los objetos están protegidos de

Acceso no autorizado. Estos controles de acceso deberán ser capaces de

incluyendo o excluyendo el acceso a la granularidad de un único usuario.

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

el permiso sólo se asignará por usuarios autorizados.

B1: NAR.

B2: NAR.

B3: CAMBIO: El mecanismo de aplicación (por ejemplo, las listas de control de acceso) deberá

permitir que los usuarios especifiquen y compartir el control de esos objetos, y deberá

proporcionar controles para limitar la propagación de los derechos de acceso. Estas

controles de acceso deberán ser capaces de especificar, para cada llamada

objetar, una lista de personas con nombre y una lista de grupos de llamada

individuos con sus respectivos modos de acceso a ese objeto.

ADD: Por otra parte, respecto de cada objeto nombrado, será posible

especificar una lista de personas con nombre y una lista de grupos de llamada

individuos para los que no tienen acceso al objeto debe ser dado.

A1: NAR.

Exportación de información Etiquetada

C1: NR.

C2: NR.

B1: NUEVO: La TCB designará cada canal de comunicación y E / S

dispositivo, ya sea a nivel individual o de múltiples niveles. Cualquier cambio en esta

designación se realiza de forma manual y será auditable por el

TCB. El TCB mantendrá y ser capaz de auditar cualquier cambio en la

nivel de seguridad o los niveles asociados con un canal de comunicación o


B2: NAR.

B3: NAR.

A1: NAR.

Exportación a dispositivos multinivel

C1: NR.

C2: NR.

B1: NUEVO: Cuando la TCB exporta un objeto a un dispositivo de E / S de múltiples niveles, la

etiqueta de sensibilidad asociada a ese objeto también se exportará

y deberá residir en el mismo medio físico como el exportado

información y se hará de la misma forma (es decir, de lectura mecánica o

formato legible). Cuando las exportaciones o importaciones TCB un objeto más

un canal de comunicación de múltiples niveles, el protocolo utilizado en ese canal

deberán prever la vinculación inequívoca entre la sensibilidad

etiquetas y la información asociada que se envía o se recibe.

B2: NAR.

B3: NAR.

A1: NAR.

Exportación a solo nivel-Devices

C1: NR.

C2: NR.

B1: dispositivos S-nivel individual de E / y canales de comunicación a nivel individual: NUEVO

no están obligados a mantener las etiquetas de sensibilidad del

información que procesan. Sin embargo, la TCB deberá incluir un mecanismo

por el cual el TCB y un usuario autorizado a comunicar de forma confiable

designar el nivel de seguridad única de información importados o

exportado a través de los canales de comunicación de un solo nivel o dispositivos de E / S.

B2: NAR.

B3: NAR.

A1: NAR.

Identificación y autenticación

C1: NUEVO: La TCB exigirá a los usuarios que se identifiquen con él antes

comenzando a realizar cualquier otra acción que la TCB se espera que

mediar. Además, la TCB utilizará un mecanismo protegido (por ejemplo,

contraseñas) para autenticar la identidad del usuario. El TCB deberá


usuario no autorizado.

C2: ADD: El TCB será capaz de hacer cumplir la responsabilidad individual por

proporcionando la capacidad para identificar de forma única cada individuo ADP

usuario del sistema. El TCB también proporcionará la capacidad de

asociando esta identidad con todas las acciones que se pueden auditar tomadas por que

individual.

B1: CAMBIO: Además, la TCB mantendrá los datos de autenticación que

incluye información para la verificación de la identidad de los usuarios individuales

(por ejemplo, contraseñas), así como información para determinar la

autorización y autorizaciones de los usuarios individuales. Estos datos serán

utilizado por el TCB para autenticar la identidad del usuario y para asegurar

que las autorizaciones del nivel de seguridad y de los sujetos externos a

la TCB que se puede crear a actuar en nombre del usuario individual

están dominados por la liquidación y autorización de ese usuario.

B2: NAR.

B3: NAR.

A1: NAR.

Integridad Label

C1: NR.

C2: NR.

B1: NUEVO: etiquetas de sensibilidad deberá representar con precisión los niveles de seguridad de

los sujetos u objetos específicos con los que están asociados. Cuando

exportado por el TCB, etiquetas de sensibilidad y precisión deberá

inequívocamente representar las etiquetas internas y estará asociada


B2: NAR.

B3: NAR.

A1: NAR.

Salida etiquetado legible

C1: NR.

C2: NR.

B1: NUEVO: El administrador del sistema ADP podrá especificar el

nombres de las etiquetas imprimibles asociados con etiquetas de sensibilidad exportados.

El TCB deberá marcar el inicio y el final de todo legible,

paginado, salida de copia impresa (por ejemplo, la salida de impresora de líneas) con humanidad

etiquetas de sensibilidad legibles que correctamente * representan la sensibilidad

de la salida. El TCB será, por defecto, marque la parte superior e inferior de

cada página de salida legible, paginado, en papel (por ejemplo, la línea

salida de la impresora) con las etiquetas de sensibilidad legibles que

adecuadamente * representar la sensibilidad global de la salida o que

* representar adecuadamente la sensibilidad de la información de la página.

El TCB será, por defecto y de manera apropiada, marque otra

formas de salida legible por humanos (por ejemplo, mapas, gráficos) con humanidad

etiquetas de sensibilidad legibles que correctamente * representan la sensibilidad

de la salida. Cualquier anulación de estos incumplimientos marcado será


B2: NAR.

B3: NAR.

A1: NAR.

______________________________






categorías.

Etiquetas

C1: NR.

C2: NR.

B1: NUEVO: etiquetas de sensibilidad asociados a cada tema y almacenamiento

objetar bajo su control (por ejemplo, proceso, archivo, segmento, dispositivo) se

ser mantenida por el TCB. Estas etiquetas se utilizan como base

para las decisiones de control de acceso obligatorios. Para importar no

datos etiquetados, la TCB deberán solicitar y recibir de una autorización

usuario el nivel de seguridad de los datos, y todas estas acciones serán


B2: CAMBIO: etiquetas de sensibilidad asociados a cada recurso del sistema ADP

(por ejemplo, tema, objeto de almacenamiento, ROM) que está directamente o indirectamente

accesible por temas externos a la TCB se mantendrá por

la TCB.

B3: NAR.

A1: NAR.

Control de Acceso Obligatorio

C1: NR.

C2: NR.

B1: NUEVO: La TCB deberá aplicar una política de control de acceso obligatorio sobre todos

sujetos y objetos de almacenamiento bajo su control (por ejemplo, los procesos,

archivos, segmentos, dispositivos). Estos sujetos y objetos serán

etiquetas de sensibilidad asignados que son una combinación de jerárquica

niveles de clasificación y categorías no jerárquicas y las etiquetas

se utilizará como base para las decisiones de control de acceso obligatorios.

El TCB deberá ser capaz de soportar dos o más de tales niveles de seguridad.

(Véanse las directrices de control de acceso obligatorios.) La siguiente

requisitos permanecerán en para todos los accesos entre sujetos y objetos

controlado por el TCB: Un sujeto puede leer un objeto sólo si el

clasificación jerárquica en el nivel de seguridad del sujeto es

mayor o igual a la clasificación jerárquica en el

nivel de seguridad del objeto y las categorías no jerárquicas en la

nivel de seguridad del sujeto incluye todas las categorías no jerárquicas

en el nivel de seguridad del objeto. Un sujeto puede escribir un objeto sólo

si la clasificación jerárquica en el nivel de seguridad del sujeto es

menos de o igual a la clasificación jerárquica en el objeto de



categorías en el nivel de seguridad del objeto. Identificación y

datos de autenticación se utilizarán por el TCB para autenticar el

la identidad del usuario y para asegurar que el nivel de seguridad y autorización

zación de los sujetos externo a la TCB que pueden crearse para actuar

en nombre del usuario individual están dominadas por el despacho y

autorización de dicho usuario.

B2: CAMBIO: El TCB deberá aplicar una política de control de acceso obligatorio sobre

todos los recursos (por ejemplo, temas, objetos de almacenamiento, y dispositivos de E / S) que

son directa o indirectamente accesible por sujetos ajenos a la TCB.

Los siguientes requisitos deberán mantener durante todos los accesos entre todos

sujetos externos a la TCB y todos los objetos de forma directa o indirecta

accesible por estos temas:

B3: NAR.

A1: NAR.

Reutilización de objetos

C1: NR.

C2: NUEVO: Todas las autorizaciones a la información contenida dentro de un


la asignación o reasignación a un sujeto desde la piscina del TCB de

objetos de almacenamiento no utilizados. No hay información, incluyendo cifrado


acciones es estar a disposición de cualquier objeto que obtiene acceso a

un objeto que ha sido puesto en libertad de nuevo al sistema.

B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Características de seguridad Guía del usuario

C1: NUEVA: Un solo resumen, capítulo, o manual en la documentación del usuario deberá

describir los mecanismos de protección proporcionados por la TCB, directrices sobre

su uso, y cómo interactúan entre sí.

C2: NAR.

B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Pruebas de seguridad

C1: NUEVO: Los mecanismos de seguridad del sistema de ADP se someterán a ensayo y

encontrado para trabajar como se reivindica en la documentación del sistema. Prueba deberá

por hacer para asegurar que no hay maneras obvias para una no autorizada

usuario para omitir o no derrotar a los mecanismos de protección de la seguridad

del TCB. (Véanse las directrices de Pruebas de Seguridad.)

C2: ADD: El ensayo debe incluir también una búsqueda de defectos obvios que

permitir la violación de aislamiento de recursos, o que permitiría

acceso no autorizado a los datos de auditoría o de autenticación.

B1: NUEVO: Los mecanismos de seguridad del sistema de ADP se someterán a ensayo y

encontrado para trabajar como se reivindica en la documentación del sistema. Un equipo de

personas que entienden a fondo la aplicación específica de

la TCB deberá someter su documentación de diseño, código fuente, y

código objeto de análisis y pruebas exhaustivas. Sus objetivos deberán

ser: para descubrir todos los defectos de diseño e implementación que permitan

un sujeto externo a la TCB para leer, cambiar o eliminar los datos

normalmente negado bajo la política de seguridad obligatoria o discrecional

forzada por la TCB; así como para asegurar que ningún objeto (sin

autorización para hacerlo) es capaz de hacer que el TCB para entrar en un estado

tal que es incapaz de responder a las comunicaciones iniciadas por

otros usuarios. Todos los defectos descubiertos serán removidos o neutralizados

y la TCB analizado de nuevo para demostrar que han sido eliminados

y que los nuevos defectos no se han introducido. (Vea la Seguridad

Directrices de prueba).

B2: CAMBIO: Todos los defectos descubiertos se corregirá y el TCB reexaminado

para demostrar que han sido eliminados y que las nuevas fallas tienen

no se han introducido.

ADD: El TCB se encuentra relativamente resistente a la penetración.

El ensayo debe demostrar que la aplicación TCB es consistente

con la memoria descriptiva de nivel superior.

B3: CAMBIO: La TCB se encontró resistente a la penetración.

ADD: No hay defectos de diseño y no más de unos pocos corregible

fallas de implementación se pueden encontrar durante las pruebas y no habrá

confianza razonable de que pocos permanecen.

A1: CAMBIO: El ensayo debe demostrar que la aplicación TCB es

consistente con la especificación formal de nivel superior.

ADD: mapeo manual u otra de las FTLs al código fuente puede formar

una base para las pruebas de penetración.

Asunto etiquetas de sensibilidad

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: La TCB notificará inmediatamente a un usuario del terminal de cada cambio

en el nivel de seguridad asociado a ese usuario durante un interactivo

sesión. Un usuario del terminal será capaz de consultar la TCB lo deseas

para una pantalla de etiqueta de sensibilidad completa del sujeto.

B3: NAR.

A1: NAR.

Arquitectura del Sistema

C1: NUEVO: La TCB mantendrá un dominio para su propia ejecución que

protege de interferencias externas o manipulación (por ejemplo,

modificación de sus códigos o estructuras de datos). Recursos controlados

por la TCB puede ser un subconjunto definido de los sujetos y objetos en

el sistema de ADP.

C2: ADD: El TCB aislará los recursos para protegerse de forma que

están sujetos al control de acceso y los requisitos de auditoría.

B1: ADD: El TCB deberá mantener el aislamiento de procesos a través de la prestación

de espacios de direcciones distintas bajo su control.

B2: NUEVO: La TCB mantendrá un dominio para su propia ejecución que

protege de interferencias externas o manipulación (por ejemplo,

modificación de sus códigos o estructuras de datos). El TCB mantendrá

aislamiento de procesos a través de la provisión de espacios de direcciones distintas

bajo su control. La TCB se estructurará internamente en bienestar

definidos módulos en gran medida independientes. Se hará un uso efectivo de

hardware disponible para separar aquellos elementos que son proteccionismo

crítico de aquellas que no lo son. Los módulos de TCB se diseñarán

de tal manera que el principio de privilegios mínimos se hace cumplir. Características en

hardware, como la segmentación, se utilizará para apoyar lógicamente

objetos de almacenamiento distintas con atributos diferentes (a saber: lectura,

grabable). La interfaz de usuario a la TCB será completamente

definido y todos los elementos de la TCB identificado.

B3: ADD: El TCB estará diseñado y estructurado para utilizar una solución completa,

mecanismo de protección conceptualmente simple con definido con precisión

semántica. Este mecanismo deberá desempeñar un papel central en la aplicación de la

estructuración interna de la TCB y el sistema. El TCB deberá

incorporar un uso significativo de la estratificación, la abstracción y la ocultación de datos.

Ingeniería de sistemas significativos deberá estar encaminada a minimizar

la complejidad de la TCB y se excluyen de los módulos de TCB que son

No protección crítica.

A1: NAR.

Integridad del sistema

C1: NUEVO: características de hardware y / o software se proporcionarán que puede ser

utilizado para validar periódicamente el funcionamiento correcto de la en el sitio

hardware y firmware elementos de la TCB.

C2: NAR.

B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Documentación de prueba

C1: NUEVO: El desarrollador del sistema proporcionará a los evaluadores un documento


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

métodos utilizados para reducir los anchos de banda de canal encubiertas.

B3: NAR.

A1: ADD: Los resultados de la correlación entre el nivel superior formales

Se dará especificación y el código fuente TCB.

Distribución de confianza

C1: NR.

C2: NR.

B1: NR.

B2: NR.

B3: NR.

A1: NUEVO: Un sistema de control de ADP de confianza y las instalaciones de distribución será

proporcionado para mantener la integridad de la asignación entre el

datos maestros describen la versión actual de la TCB y el en el sitio

copia maestra del código para la versión actual. Procedimientos (por ejemplo,

existirá la seguridad del sitio de pruebas de aceptación) para asegurar que el

TCB software, firmware y actualizaciones de hardware distribuido a un

al cliente están exactamente según lo especificado por las copias maestras.

Facility Management confiables

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: La TCB apoyará operador independiente y administrador

funciones.

B3: ADD: Las funciones desempeñadas en el papel de un administrador de seguridad

se identificarán. El personal administrativo del sistema ADP deberá

sólo será capaz de realizar las funciones de administrador de seguridad después de tomar

una acción auditable distinta a asumir la función de administrador de seguridad

en el sistema de ADP. Funciones no son de seguridad que se pueden realizar en

el papel administración de la seguridad se limitará estrictamente a los


A1: NAR.

Manual de Instalación de confianza

C1: NUEVO: Un manual dirigido al administrador del sistema ADP presentará

advierte acerca de las funciones y privilegios que deben ser controlados

cuando se ejecuta una instalación segura.

C2: ADD: Los procedimientos de examen y el mantenimiento de los archivos de auditoría

así como la estructura de registro de auditoría detallado para cada tipo de auditoría

Se dará evento.

B1: ADD: El manual deberá describir el operador y administrador

funciones relacionadas con la seguridad, que incluyen el cambio de la

características de un usuario. Asimismo, proporcionará directrices sobre la

el uso coherente y eficaz de las funciones de protección de la

sistema, cómo interactúan, cómo generar de forma segura una nueva TCB, y

procedimientos de instalación, advertencias y privilegios que necesitan ser

controlado con el fin de operar la instalación de una manera segura.

B2: ADD: Los módulos de TCB que contienen el mecanismo de validación de referencia

se identificarán. Los procedimientos para la generación segura de un nuevo

TCB de la fuente después de la modificación de los módulos en el TCB deberá

se describirá.

B3: ADD: Incluirá los procedimientos para garantizar que el sistema es


incluido para reanudar el funcionamiento seguro del sistema después de cualquier interrupción en el sistema

operación.

A1: NAR.

Camino de confianza

C1: NR.

C2: NR.

B1: NR.

B2: NUEVO: La TCB apoyará una ruta de comunicación de confianza entre

en sí y el usuario de inicio de sesión inicial y la autenticación. Comunicaciones

a través de este camino se iniciará exclusivamente por un usuario.

B3: CAMBIO: El TCB apoyará una ruta de comunicación de confianza entre

en sí y los usuarios para su uso cuando una conexión positiva-TCB a usuario es

requerido (por ejemplo, inicio de sesión, sujeta nivel de seguridad del cambio).

Comunicaciones a través de este camino de confianza se activarán en exclusiva

por un usuario o de la TCB y deberá ser aislado de manera lógica y sin lugar a dudas


A1: NAR.

Recuperación de confianza

C1: NR.

C2: NR.

B1: NR.

B2: NR.

B3: NUEVO: Procedimientos y / o mecanismos se proporcionarán para asegurar que,

después de un fallo del sistema ADP u otra discontinuidad, la recuperación sin

se obtiene la protección de compromiso.

A1: NAR.

?

(esta página está reservada para la Figura 1)

?

GLOSARIO

Acceso - Un tipo específico de interacción entre un sujeto y un objeto

que resulta en el flujo de información de una a la otra.

Aprobado / Acreditación - La autorización oficial de que es

concedida a un sistema de ADP para procesar información sensible en

su entorno operativo, basado en la amplia

evaluación de seguridad de hardware, el firmware del sistema, y

diseño de software de seguridad, configuración y puesta en práctica

y del otro sistema procesal, administrativo,

, TEMPESTAD, personal y seguridad de las comunicaciones físicas

controles.

Audit Trail - Un conjunto de registros que proporcionan colectivamente

pruebas documentales de procesamiento utilizado para ayudar en la localización

de las operaciones originales con interés registros relacionados y

informes, y / o hacia atrás a partir de registros e informes a su

transacciones de origen de componentes.

Autenticar - Para establecer la validez de una identidad declarada.

Data Processing (ADP) Sistema automático - Una asamblea de equipo

hardware, firmware y software configurado para el propósito

de clasificar, ordenar, calcular, la informática,

resumiendo, la transmisión y recepción, almacenamiento y

la recuperación de datos con un mínimo de intervención humana.

Ancho de Banda - Una característica de un canal de comunicación que es

la cantidad de información que se puede pasar a través de ella en una

dada cantidad de tiempo, generalmente expresada en bits por segundo.

Modelo Bell-LaPadula - Un modelo de transición de estado formal de equipo

la política de seguridad que describe un conjunto de control de acceso

reglas. En este modelo formal, las entidades en un ordenador

sistema se divide en series abstractas de los sujetos y

objetos. La noción de un estado seguro se define y es

probado que cada transición de estado conserva la seguridad por

moviéndose de un estado seguro para asegurar el estado; Por lo tanto, inductivamente

demostrando que el sistema es seguro. Un estado del sistema es

define como "seguro" si la única permitida modos de acceso de

los sujetos a los objetos son de acuerdo con una específica

politica de seguridad. Con el fin de determinar si es o no una

se permite el modo de acceso específico, el pase de un sujeto

se compara con la clasificación del objeto y una

se efectúa la determinación de si el sujeto está

autorizado para el modo de acceso específica. Los

esquema de aclaramiento / clasificación se expresa en términos de una

celosía. Ver también: Cedazo, simple Propiedad Seguridad, * -

Propiedad.

Certificación - La evaluación técnica de seguridad de un sistema

características, realizados como parte de y en apoyo de la

/ proceso de acreditación de aprobación, que establece la medida

a la que el diseño de un sistema informático en particular y

aplicación cumple con un conjunto de seguridad especificado

requisitos.

Canal - Una ruta de transferencia de información dentro de un sistema. Pudiera también

consulte el mecanismo por el cual se efectúa el camino.

Canal encubierto - Un canal de comunicación que permite a un proceso

transferir información de una manera que viole el sistema de

politica de seguridad. Ver también: Covert Canal de almacenamiento, Covert

Timing Channel.

Covert Canal de almacenamiento - Un canal secreto que implica la

escritura directa o indirecta de una ubicación de almacenamiento por uno

proceso y la lectura directa o indirecta de almacenamiento

ubicación por otro proceso. Canales de almacenamiento Covert

suele implicar un recurso finito (por ejemplo, los sectores en un

disco) que es compartida por dos sujetos en diferentes seguridad

los niveles.

Canal Timing Covert - Un canal secreto en el que un solo proceso

señales de información a otro mediante la modulación de su propio uso de

los recursos del sistema (por ejemplo, tiempo de CPU) de tal manera que este

manipulación afecta el tiempo de respuesta real, observada por el

segundo proceso.

Datos - Información con una representación física específica.

Integridad de datos - El estado que existe cuando los datos informatizada es

el mismo que en los documentos de origen y no ha sido

expuesta a la alteración accidental o maliciosa o

destrucción.

Descriptivo de nivel superior Specification (DTLS) - Un alto nivel

especificación que está escrito en un lenguaje natural (por ejemplo,

Inglés), una notación de diseño del programa informal, o una

combinación de los dos.

Control de Acceso Discrecional - Un medio para restringir el acceso a

objetos en función de la identidad de los sujetos y / o grupos de

que pertenecen. Los controles son discrecionales en el

sentido de que un sujeto con un permiso de acceso es cierto

capaz de pasar ese permiso (quizás indirectamente) en

a cualquier otro sujeto (a no ser restringido por acceso obligatorio

control).

Dominio - El conjunto de objetos que un sujeto tiene la capacidad de

el acceso.

Dominar - Nivel de seguridad S1 se dice a dominar el nivel de seguridad

S2 si la clasificación jerárquica de S1 es mayor que

o igual a la de S2 y las categorías no jerárquicas

S1 de incluir a todos los de S2 como un subconjunto.

Canal explotable - Cualquier canal que es utilizable o detectable

por sujetos externos a la Trusted Computing Base.

Un error Hipótesis Metodología - Un análisis del sistema y la penetración

técnica donde las especificaciones y documentación para el

sistema se analizan y luego fallas en el sistema son

la hipótesis. La lista de defectos hipotéticos es entonces

priorizado sobre la base de la probabilidad estimada de que una

error de hecho existe y, suponiendo un defecto existe, en la

facilidad de explotación de la misma y sobre el grado de control o

comprometer proporcionaría. La lista de prioridades se utiliza

para dirigir la prueba real del sistema.

Defecto - Un error de comisión, omisión o descuido en un sistema

que permite a los mecanismos de protección al ser anuladas.

Prueba Formal - Un argumento matemático completo y convincente,

la presentación de la justificación lógica completa para cada prueba

paso, por la verdad de un teorema o conjunto de teoremas. Los

proceso de verificación formal utiliza pruebas formales para mostrar la

verdad de ciertas propiedades de la especificación formal y para

lo que demuestra que los programas de ordenador satisfacer sus especificaciones.

Seguridad Formal Modelo Política - Una declaración matemáticamente precisa

de una política de seguridad. Para ser adecuadamente precisa, tal

modelo debe representar el estado inicial de un sistema, la forma

en el que el sistema progresa desde un estado a otro,

y una definición de un estado "seguro" del sistema. Ser

aceptable como una base para un TCB, el modelo debe ser apoyado

por una prueba formal de que si el estado inicial del sistema

satisface la definición de un estado "seguro" y si todo

supuestos requeridos por el modelo de espera, a continuación, todos los futuros

estados del sistema estarán seguros. Algunos modelos formales

técnicas incluyen: modelos de transición de estados, lógica temporal

modelos, modelos semántica denotacional, algebraica

modelos de especificación. Un ejemplo es el modelo descrito por

Bell y LaPadula en la referencia [2]. Ver también: Bell-

LaPadula Modelo, Modelo de Política de Seguridad.

Formal Especificación de nivel superior (FTLs) - Una especificación de nivel superior

que está escrito en un lenguaje matemático formal para permitir

teoremas que muestran la correspondencia del sistema

especificación de sus requisitos formales para ser la hipótesis

y probado formalmente.

Verificación Formal - El proceso de utilización de pruebas formales de

demostrar la consistencia (verificación del diseño) entre un

especificación formal de un sistema y de una garantía formal,

modelo de política o (verificación de la implementación) entre el

especificación formal y su aplicación del programa.

Front-End Filtro de Seguridad - Un proceso que se invoca al proceso

datos accordint a una política de seguridad especificado antes de la

la liberación de los datos fuera del entorno de procesamiento o

al recibir los datos desde una fuente externa.

Pruebas funcionales - La parte de las pruebas de seguridad en la que el

características anunciados de un sistema se prueban para la correcta

operación.

Sistema de fines generales - Un sistema informático que está diseñado para

ayuda en la solución de una amplia variedad de problemas.

Granularidad - La finura relativa o tosquedad por el cual una

mecanismo se puede ajustar. La frase "la granularidad de

un solo usuario "se entiende el mecanismo de control de acceso puede ser

ajustado para incluir o excluir a cualquier usuario individual.

Entramado - Un conjunto parcialmente ordenado para el que cada par de

elementos tiene un extremo inferior y una cota superior mínima.

Privilegio mínimo - Este principio requiere que cada sujeto en un

sistema de concederse el conjunto más restrictivo de privilegios (o

aclaramiento más bajo) necesarios para el desempeño de autorizado

tareas. La aplicación de este principio limita el daño

que puede ser el resultado de un accidente, error o uso no autorizado.

Mandatory Access Control - Un medio para restringir el acceso a

objetos en función de la sensibilidad (representado por una etiqueta)

de la información contenida en los objetos y lo formal

autorización (es decir, la remoción) de temas para el acceso

información de tal sensibilidad.

Dispositivo multinivel - Un dispositivo que se utiliza de una manera que

lo permite procesar simultáneamente datos de dos o más

niveles de seguridad sin riesgo de compromiso. Para llevar a cabo

esta, etiquetas de sensibilidad normalmente se almacenan en el mismo

medio físico y de la misma forma (es decir, legible por máquina

o está procesando legible por humanos) que los datos.

Multinivel Secure - Una clase de sistema que contiene información con

diferentes sensibilidades que permite al mismo tiempo el acceso

los usuarios con diferentes permisos de seguridad y las necesidades-a-

saber, pero impide que los usuarios obtener acceso a

información por los que carecen de autorización.

Object - Un ente pasivo que contiene o recibe información.

El acceso a un objeto potencialmente implica el acceso a la

información que contiene. Ejemplos de objetos son: registros,

bloques, páginas, segmentos, archivos, directorios, directorio

árboles, y los programas, así como los bits, bytes, palabras, campos,

procesadores, pantallas de video, teclados, relojes, impresoras,

los nodos de red, etc.

Reutilización de objetos - La reasignación a algún tema de un medio

(por ejemplo, marco de página, sector de disco, cinta magnética) que

contenida uno o más objetos. Para ser reasignado de forma segura,

tales medios deben contener datos residuales de la anteriormente

objeto contenido (s).

Salida - La información que se ha exportado por un TCB.

Contraseña - Una cadena de caracteres privada que se utiliza para

autenticar una identidad.

Pruebas de Penetración - La parte de las pruebas de seguridad en el que

el intento de penetradores de eludir las medidas de seguridad

de un sistema. El penetradores se puede suponer que utilizar todos

diseño del sistema y la documentación aplicación, que puede

incluir los listados de código fuente del sistema, manuales, y el circuito

diagramas. El trabajo penetradores bajo ninguna restricciones otros

que los que se aplicaría a los usuarios normales.

Proceso - Un programa en ejecución. Está completamente caracterizada

por un único punto de ejecución actual (representado por la

estado de la máquina) y el espacio de direcciones.

Porciones de protección-crítico de la TCB - Las partes de la

TCB cuya función normal es tratar con el control de

acceso entre sujetos y objetos.

Protección Filosofía - Una descripción informal de la general

diseño de un sistema que delimita cada uno de la protección

mecanismos empleados. Una combinación (apropiada para el

clase de evaluación) de las técnicas formales e informales se utiliza

para mostrar que los mecanismos son adecuados para hacer cumplir la

politica de seguridad.

Leer - Una operación fundamental que los resultados sólo en el flujo de

información de un objeto a un sujeto.

Leer acceso - Permiso para leer la información.

Memoria de sólo lectura (ROM) - Un área de almacenamiento en la que el contenido puede

ser leído pero no alterado durante el proceso normal de ordenador.

Referencia monitor Concepto - Un concepto de control de acceso que se refiere

a una máquina abstracta que media en todos los accesos a los objetos

por los sujetos.

Recursos - Cualquier cosa utilizados o consumidos en el desempeño de una función.

Las categorías de recursos son: tiempo, información, objetos

(contenedores de información), o procesadores (la capacidad de utilizar

información). Ejemplos específicos son: tiempo de CPU; Terminal

tiempo de conexión; cantidad de memoria directamente direccionable; disco

el espacio; número de peticiones de E / S por minuto, etc.

Kernel de Seguridad - Las hardware, elementos de firmware y software

de una Base de Trusted Computing que implementan la referencia

monitorear concepto. Debe mediar en todos los accesos, ser protegidos

de modificación y ser verificables como correcta.

Nivel de seguridad - La combinación de una clasificación jerárquica

y un conjunto de categorías no jerárquicas que representa el

sensibilidad de la información.

Política de Seguridad - El conjunto de leyes, normas y prácticas que

regular cómo una organización gestiona, protege y

distribuye información sensible.

Modelo de Seguridad Política - Una presentación informal de un oficial

modelo de política de seguridad.

Seguridad Hecho Relevante - Cualquier evento que intenta cambiar la

estado de seguridad del sistema, (por ejemplo, cambiar discrecional

controles de acceso, cambie el nivel de seguridad del sujeto,

contraseña de usuario de cambio, etc.). También, cualquier evento que intenta

violar la política de seguridad del sistema, (por ejemplo, también

muchos intentos de inicio de sesión, los intentos de violar la obligatoria

límites de control de acceso de una defice, los intentos de rebajar un

archivo, etc.).

Pruebas de seguridad - Un proceso utilizado para determinar que la seguridad

características de un sistema se implementan como diseñado y que

que son adecuadas para un entorno de aplicación propuesto.

Este proceso incluye la práctica de pruebas funcionales,

pruebas de penetración, y la verificación. Ver también: Funcional

Pruebas, pruebas de penetración, Verificación.

Información Sensible - La información que, según lo determinado por un

autoridad competente, debe ser protegida porque su

divulgación no autorizada, alteración, pérdida o destrucción

será al menos causar daños perceptibles a alguien o

algo.

Sensibilidad etiqueta - Una pieza de información que representa el

nivel de seguridad de un objeto y que describe la

sensibilidad (por ejemplo, clasificación) de los datos en el

objeto. Etiquetas de sensibilidad son utilizados por el TCB como base

para las decisiones de control de acceso obligatorios.

Sencillo Estado de Seguridad - Una regla modelo de seguridad de Bell-LaPadula

permitiendo que un sujeto acceso de lectura a un objeto sólo si el

nivel de seguridad del sujeto domina el nivel de seguridad

del objeto.

Single-Level Device - Dispositivo que se utiliza para procesar los datos de un

nivel de seguridad solo en un momento dado. Puesto que el dispositivo

no tiene por qué ser de confianza para separar los datos de diferente seguridad

niveles, etiquetas de sensibilidad no tienen que ser almacenado con el

datos que se están procesando.

* -Property (Star Property) - Una regla modelo de seguridad de Bell-LaPadula

permitiendo un acceso por materias de escritura a un objeto sólo si el

nivel de seguridad del sujeto está dominado por la seguridad

nivel del objeto. También conocido como el confinamiento

Propiedad.

Object Storage - Un objeto que soporta tanto leer y escribir

accesos.

Asunto - una entidad activa, generalmente en la forma de una persona,

proceso o dispositivo que hace que la información fluya entre

objetos o cambia el estado del sistema. Técnicamente, un

proceso / par dominio.

Asunto Nivel de seguridad - el nivel de seguridad de un sujeto es igual a

el nivel de seguridad de los objetos a los que se ha leído tanto

y escritura. Nivel de seguridad de un objeto debe ser siempre

dominado por la liquidación de los usuarios el tema es

asociado con.

TEMPESTAD - El estudio y control de señales electrónicas espurias

emitida desde el equipo ADP.

De nivel superior Specification (TLS) - Una descripción no procesal de

el comportamiento del sistema en el nivel más abstracto. Normalmente, una

especificación funcional que omite todo implementación

detalles.

Trampa puerta - Un software oculto o mecanismo de hardware que permite

los mecanismos de protección del sistema para ser eludidas. Es

activado de alguna manera no aparente (por ejemplo, especial

secuencia de teclas "al azar" en un terminal).

Caballo de Troya - Un programa de ordenador con una apariencia o realidad

función útil que contiene las funciones adicionales (ocultos)

que subrepticiamente explotar las autorizaciones legítimas

del proceso de invocación en detrimento de la seguridad. Por

ejemplo, hacer una "copia oculta" de un archivo sensible para la

creador del caballo de Troya.

Trusted Computer System - Un sistema que emplea suficiente

medidas de hardware y de integridad de software para permitir su uso

para procesar simultáneamente una gama de sensible o

información clasificada.

Trusted Computing Base (TCB) - La totalidad de la protección

mecanismos dentro de un sistema informático - incluyendo hardware,

firmware y software - la combinación de las cuales es

responsable de hacer cumplir una política de seguridad. Un TCB consiste

de uno o más componentes que juntos hacer cumplir una unificado

política de seguridad sobre un producto o sistema. La capacidad de

una base informática de confianza para hacer cumplir correctamente un

política de seguridad depende únicamente de los mecanismos dentro de la

TCB y en la entrada correcta por sistema administrativo

personal de parámetros (por ejemplo, el despacho de un usuario) relacionada

a la política de seguridad.

Camino de confianza - Un mecanismo por el cual una persona en un terminal puede

comunicarse directamente con el Trusted Computing Base. Esta

mecanismo sólo puede ser activado por la persona o el fiables

Cálculo de la base y no puede ser imitado por el software que no se confía.

Software confiables - La parte de software de Trusted Computing

Base.

Usuario - Cualquier persona que interactúa directamente con un sistema informático.

Verificación - El proceso de comparar dos niveles de sistema

Especificación para la correspondencia adecuada (por ejemplo, la seguridad

modelo de política con la especificación de nivel superior, TLS con fuente

código o código fuente con código objeto). Este proceso puede o

no puede ser automatizado.

Write - Una operación fundamental que los resultados sólo en el flujo de

información de un sujeto a un objeto.

Escribe acceso - Permiso para escribir un objeto.

?

REFERENCIAS

1. Anderson, Planificación de Tecnología de Seguridad JP Computer

Estudio, ESD-TR-73 a 51, vol. Yo, ESD / AFSC, Hanscom AFB,

Bedford, Mass., 10 1972 (NTIS AD-758 206).

2. Bell, DE y LaPadula, LJ proteger los sistemas informáticos:

Exposición unificada y Multics Interpretación, MTR-2997

Rev. 1, MITRE Corp., Bedford, Mass., 03 1976.

3. Marca, SL "Un acercamiento a la identificación y Auditoría de

Vulnerabilidades y el Control de Sistemas de Aplicación ", en

Auditoría y Evaluación de Seguridad Informática II: Sistema

Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS

Publicación Especial # 500-57, MD78733, abril 1980.

4. Marca, SL "Proceso de Datos y A-123", en Actas de

Grupo 18 la evaluación del usuario rendimiento del equipo

Reuniones, CB Wilson, ed., NBS Publicación Especial

# 500-95, octubre 1982.

5. DCID l / l6, Seguridad de Inteligencia Extranjera de datos automatizada

Sistemas de Procesamiento y Redes (U), 04 de enero l983.

6. DIAM 50-4, Seguridad de Operaciones de la computadora con compartimientos (U),

24 junio de l980.

7. Denning, DE "Un modelo del enrejado de la información segura

Flow "en Communications of the ACM, vol. 19, núm. 5

(Mayo de 1976), pp. 236-243.

8. Denning, DE Secure Flujo de Información en Informática de Sistemas,

Ph.D. disertación, Purdue Univ., West Lafayette, Indiana.,

Mayo 1975.

9. Directiva DoD 5000.29, gestión de los recursos informáticos en la Major

Sistemas de Defensa, 26 de abril l976.

10. DoD 5200.1-R, Seguridad de la Información Reglamento del Programa,

08 1982.

11. Directiva del DoD 5200.28, Requisitos de seguridad para automático

Data Processing (ADP) Systems, revisó 04 1978.

Manual 12. DoD 5200.28-M, ADP Seguridad - Técnicas y

Procedimientos para la Ejecución, desactivación, pruebas y

La evaluación de seguro de Recursos Compartidos ADP Systems, revisada

06 1979.

13. Directiva del DoD 5215.1, Seguridad informática Centro de Evaluación,

25 de octubre 1982.

14. DoD 5220.22-M, Manual de Seguridad Industrial para la protección de

Información Clasificada, Marzo de 1984.

15. DoD 5220.22-R, el Reglamento de Seguridad Industrial, febrero 1984.

16. Directiva del DoD 5400.11 del Departamento de Defensa de Privacidad

Programa, 09 de junio 1982.

17. Directiva del DoD 7920.1, Life Cycle Management de Automated

Sistemas de Información (AIS), 17 de octubre 1978

18. Orden Ejecutiva 12356, Seguridad de la Información Nacional,

06 de abril 1982.

19. Faurer, LD "Mantener los Secretos secreto" en el Gobierno

Data Systems, noviembre-diciembre 1981, pp 14-17..

20. Federal Information Processing Standards Publicación (FIPS

PUB) 39, Glosario de Informática de Sistemas de Seguridad,

15 de febrero 1976.


PUB) 73, Directrices para la Seguridad del ordenador

Aplicaciones, 30 de junio de 1980.


PUB) 102, Guía para la Certificación de Seguridad Informática

y Acreditación.

23. Lampson, BW "Una nota sobre el problema Confinamiento", en

Comunicaciones de la ACM, vol. 16, no. 10 (octubre

1973), pp. 613 a 615.

24. Lee, TMP, et al. "Los procesadores, sistemas operativos y

Periféricos cercanas: Un informe de consenso ", en Auditoría y

Evaluación de la Seguridad Informática II: Sistema

Vulnerabilidades y Controles, Z. Ruthberg, ed., NBS

Publicación Especial # 500-57, MD78733, abril 1980.

25. Lipner, SB Un comentario sobre el Problema Confinamiento, MITRE

Corp., Bedford, Mass.

26. Millen, JK "Un ejemplo de una Violación de flujo formal", en

Actas de la segunda IEEE Computer Society

Software Informática Internacional y Aplicaciones

Conferencia, noviembre de 1978, págs. 204 a 208.

27. Millen, JK "Seguridad del Kernel de validación en la práctica", en

Comunicaciones de la ACM, vol. 19, no. 5 (mayo de 1976),

. pp doscientos cuarenta y tres hasta doscientos cincuenta.

28. Nibaldi, GH Propuestos Criterios de Evaluación Técnica para

Trusted Computer Systems, MITRE Corp., Bedford, Mass.,

M79-225, AD-A108-832, 25 de octubre 1979.

29. Nibaldi, GH Especificación de A Computing Base confiables,

(TCB), MITRE Corp., Bedford, Mass., M79-228, AD-A108-

831, 30 de noviembre 1979.

30. OMB Circular A-71, Transmisión Memorando Nº 1, de Seguridad

Federal Automatizado Sistemas de Información, 27 de julio 1978.

31. OMB Circular A-123, Sistemas de Control Interno, 05 de noviembre

1,981.

32. Ruthberg, Z. y McKenzie, R., eds. Auditoría y Evaluación del

Seguridad Informática, en NBS Publicación Especial # 500-19,

10 1977.

33. Schaefer, M., Linde, RR, et al. "Programa de Confinamiento en

KVM / 370 ", en Actas de la ACM Nacional

Conferencia, octubre de 1977, en Seattle.

34. Schell, RR "Seguridad Núcleos: Un diseño metódico de

Sistema de seguridad ", en Documentos Técnicos, USO Inc. Primavera

Conferencia, 5-9 marzo de 1979, pp. 245-250.

35. Trotter, ET y Tasker, PS Industria Informática de confianza

Sistemas de Proceso de Evaluación, MITRE Corp., Bedford,

Mass., MTR-3931, 01 de mayo 1980.

36. Turno, R. Trusted Computer Systems: Necesidades y Incentivos para

Utilice en el gobierno y el sector privado, (AD # A103399),

Rand Corporation (R-28811-DR & E), junio 1981.

37. Walker, ST "El Advenimiento de Trusted Computer operativo

Sistemas ", en Actas de la Conferencia Nacional de Informática,

De mayo de 1980, pp. 655-665.

38. Ware, WH, ed, Controles de Seguridad de los Sistemas Informáticos.:

Informe del Consejo Científico de Defensa Grupo de Trabajo en Equipo

Seguridad, AD # A076617 / 0, Rand Corporation, Santa

Monica, Calif., 02 1970, reeditado 10 1979.

standares de seguridad

Documents

Transcript of standares de seguridad