Libro Naranja PDF

Vista General del Libro
Naranja
31 / Enero / 2000
Elaborado por:
Departamento de Control de
Calidad y Auditora
Informtica
Direccin General de Servicios de Cmputo Acadmico Subdireccin de Sistemas

Direccin de Sistema
Vista General del Libro Naranja
Contenido
VISTA GENERAL DEL LIBRO NARANJA
I. ANTES DE COMENZAR
II. INTRODUCCIN
III. REQUISITOS FUNDAMENTALES DE LA SEGURIDAD EN COMPUTO
1. Polticas de seguridad
2. Responsabilidad
3. Confianza
IV. CUL ES EL PROPOSITO DEL LIBRO NARANJA?
1. Medicin
2. Direccin
3. Adquisicin
V. D- PROTECCIN MNIMA
VI. C- PROTECCIN DISCERCIONAL
1. C1- Proteccin de seguridad discrecional
2. C2- Proteccin de acceso controlado
Subdireccin de Sistemas
2
VII. B- PROTECCIN OBLIGATORIA
1. B1- Proteccin de Seguridad por Etiquetas
2. B2- Proteccin Estructurada
3. B3- Proteccin por dominios
VIII. A- PROTECCIN VERIFICADA
1. A1- Diseo Verificado
2. A2- En adelante
IX. EVALUACIN DE CLASES Y EJEMPLO DE SISTEMAS
X. EL CONTROL DE ACCESO DISCRECIONAL
XI. REUTILIZACIN DE OBJETOS
XII. ETIQUETAS
XIII. INTEGRIDAD DE ETIQUETAS
XIV. EXPORTACIN DE INFORMACIN ETIQUETADA
XV. EXPORTACIN EN DISPOSITIVOS MULTINIVEL
XVI. EXPORTACIN EN DISPOSITIVOS DE NIVEL NICO
XVII. ETIQUETAS DE SALIDAS LEGIBLES A LA PERSONA
XVIII. ETIQUETAS SENSITIVAS DE EVENTOS
XIX. DIISPOSITIVOS ETIQUETADOS

3
XX. CONTROL DE ACCESO OBLIGATORIO
XXI. IDENTIFICACIN Y AUTENTIFICACIN
XXII. RUTAS SEGURAS
XXIII. AUDITORA
XXIV. ARQUITECTURA DEL SISTEMA
XXV. INTEGRIDAD DEL SISTEMA
XXVI. ANLISIS DE CANALES SECRETOS
XXVII. FCILIDAD DE ADMINISTRACIN DE LA SEGURIDAD
XXVIII. RECUPERACIN CONFIABLE
XXIX. DISEO DE ESPECIFICACIONES Y VERIFICACIN
XXX. PRUEBAS DE SEGURIDAD
XXXI. ADMINISTRACIN DE CONFIGURACIN
XXXII. DISTRIBUCIN CONFIABLE
XXXIII. GUA DEL USUARIO DE CARACTERSTICAS DE SEGURIDAD
XXXIV.FCILIDADES DEL MANUAL DE SEGURIDAD
4
XXXV. PRUEBAS DE DOCUMENTACIN
XXXVI.DISEO DE DOCUMENTACIN
XXXVII.GLOSARIO
XXXVIII.BIBLIOGRAFA
5
Antes de Comenzar
Vista general del Libro naranja (Orange Book).
Antes de entrar a fondo con el tema de seguridad, hay que tomar en
cuenta que existen diferentes organizaciones, con diferentes tipos de
informacin y por lo tanto con distintos requerimientos de seguridad.
La necesidad de evaluar la seguridad, o de tener una medicin confiable,

es el motivo principal al desarrollar este documento por el gobierno de
los E.E. U.U.
El documento original puede ser consultado en lnea en la direccin:
http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
Antes de
comenzar Y obtenerse en las siguientes versiones:
Versin Texto ASCII (txt)
Versin Postscript (ps)
Formato Adobe Portable Document (pdf)
Versin Gzipped Postscript en la direccin:
http://www.radium.ncsc.mil/tpep/library/rainbow/
Introduccin
El Libro Naranja es consecuencia de la creciente conciencia de la

seguridad por parte el gobierno de los Estados Unidos y de la industria,
ambos con la creciente necesidad de estandarizar el propsito y el uso
de las computadoras por el gobierno federal.
Introduccin
El Libro Naranja define cuatro extensas divisiones jerrquicas de
seguridad para la proteccin de la informacin. En orden creciente de
confiabilidad se tienen:
D Proteccin Mnima
C Proteccin Discrecional
B Proteccin Obligatoria
A Proteccin Controlada
6
Cada divisin consiste en una o ms clases numeradas, entre ms

grande sea el nmero se indica un mayor grado de seguridad.
La divisin C contiene dos distintas clases C1 y C2 (de acuerdo a la

nomenclatura adoptada: C2 ofrece una mayor seguridad que C1)
La divisin B contiene 3 clases B1, B2 y B3 (B3 ofrece mayor seguridad
que B2, y B2 ofrece ms seguridad que B1).
Introduccin La divisin A cuenta con solo una clase A1.
Cada clase se define con un grupo especfico de criterios que un

sistema debe cubrir, para ser certificado con la evaluacin en alguna
clase. Este criterio cae en 4 categoras generales: Polticas de
seguridad, Responsabilidad, Confianza y Documentacin.
Requisitos Fundamentales de la
Seguridad en Cmputo
Cualquier discusin sobre seguridad en cmputo necesariamente

empieza con una definicin de sus requisitos bsicos, es decir,
realmente qu significa el llamar a un sistema informtico "seguro".
En general, un sistema seguro controlar, a travs del uso de

caractersticas especficas de seguridad, el acceso a la informacin, de
forma tal, que solamente los individuos autorizados correctamente, o los
procesos que obtienen los permisos adecuados, tendrn acceso para
leer, escribir, crear, modificar o eliminar la informacin.
Requisitos
Se tienen seis requisitos fundamentales, los cuales se derivan de esta
declaracin bsica; cuatro de ellos parten de la necesidad de
proporcionar un control de acceso a la informacin y los dos restantes de
cmo puede obtenerse una seguridad demostrable, logrando as un
sistema informtico confiable.
1. Polticas de Seguridad.
Requisito 1 - POLTICA DE SEGURIDAD - Debe existir una poltica de

seguridad explcita y bien definida reforzada por el sistema. Identificados
los eventos y los objetos, debe haber un conjunto de reglas que son
utilizadas por el sistema para determinar si un evento dado se puede
permitir para acceder a un objeto especfico.
7
Los sistemas informticos de inters deben hacer cumplir una poltica

obligatoria de seguridad, en la cual puedan implementarse
eficientemente reglas del acceso para manejo de informacin sensitiva
(p.e. clasificaciones) estas reglas deben de incluir requisitos tales como:
Ninguna persona que carezca de los permisos apropiados obtendr el
acceso a la informacin clasificada. Adems, los controles de seguridad
discrecional se requieren para asegurar que solamente los usuarios o los
grupos seleccionados de usuarios puedan obtener el acceso a los
datos.(p.e., basarse en una necesidad de conocimientos especficos).
Requisito 2 - MARCAS - El control de acceso por etiquetas debe de estar

asociado a los objetos. Para controlar el acceso a la informacin
almacenada en una computadora, segn las reglas de una poltica
obligada de seguridad, debe de ser posible el marcar cada objeto con
uno una etiqueta que identifique confiablemente el nivel de la
sensibilidad del objeto (p.e., clasificacin), y/o los modos de obtener
acceso y acordar quien puede tener acceso potencial al objeto.
2. Responsabilidad
Requisitos
Requisito 3 - IDENTIFICACIN - los eventos individuales deben de ser
identificados. Cada acceso a la informacin debe ser registrado teniendo
como base quin est teniendo acceso a la informacin y qu
autorizacin posee para ocupar cierta clase de informacin. La
informacin de la identificacin y la autorizacin debe ser administrada
con seguridad por el sistema informtico y asociar cierta seguridad a
cada elemento activo que realice una cierta accin relevante en el
sistema.
Requisito 4 - RESPONSABILIDAD - Las auditorias de la informacin

deben ser selectivamente guardadas y protegidas de las acciones que
puedan afectar la seguridad y de testa forma poder rastrear al
responsable. Un sistema confiable debe tener la capacidad de registrar
la ocurrencia de acontecimientos relevantes sobre seguridad en una
bitacora auditable. Adems de poseer la capacidad de seleccionar los
eventos a auditar para ser registrados, es necesario para reducir al
mnimo el costo de la revisin y permitir un anlisis eficiente. Este tipo de
registros o bitcoras, deben de estar protegidos contra la modificacin y
la destruccin no autorizada, y deben permitir la deteccin y la
investigacin posterior de las violaciones de seguridad.
8
3. Confianza
Requisito 5 - ASEGURAMIENTO - el sistema informtico debe contener

los mecanismos de hardware/software que puedan ser evaluados
independientemente para proporcionar una seguridad suficiente que el
sistema haga cumplir los requisitos 1 a 4 mencionados anteriormente.
Para asegurar que los requisitos de poltica de seguridad, marcas,
identificacin, y responsabilidad de la seguridad son hechos cumplir por
un sistema de cmputo, deben ser identificados como una coleccin
unificada de hardware y software que controle y ejecute esas funciones.
Estos mecanismos son tpicamente incluidos en el sistema operativo y
se disean para realizar las tareas asignadas de una manera segura. La
base para confiar en tales mecanismos del sistema operativo, radica en
su configuracin operacional, la cual debe ser claramente documentada
Requisitos a fin de hacer posible el examinar independientemente los eventos para
su evaluacin.
Requisito 6 - PROTECCIN CONTINUA - los mecanismos de seguridad

que hacen cumplir estos requisitos bsicos, se deben de proteger
continuamente contra cambios no autorizados o modificaciones que
traten de alterarlos. Ningn sistema de cmputo puede ser considerado
verdaderamente seguro si los mecanismos que hacen cumplir las
polticas de seguridad, estn sujetos a modificaciones no autorizadas. El
requisito de proteccin continua tiene implicaciones directas a travs del
ciclo de vida de los sistemas.
Cual es el propsito del libro naranja
De acuerdo con el texto mismo, el criterio de evaluacin se desarrolla

con 3 objetivos bsicos:
1. Medicin
Propsito
Para proporcionar de elementos cuantificables al Departamento de
Defensa (DoD1) con los cuales poder evaluar el grado de confianza que
se puede tener en los sistemas informticos seguros, para el proceso de
clasificacin de informacin sensitiva.
1
Departament of Defense (Departamento de Defensa de los Estados Unidos).
9
El proveer a los usuarios con un criterio con el cual se evale la

confianza que se puede tener en un sistema de cmputo para el
procesamiento de la seguridad o clasificacin de informacin sensitiva.
Por ejemplo, un usuario puede confiar que un sistema B2 es ms
seguro que un sistema C2.
2. Direccin
Para proporcionar un estndar a los fabricantes en cuanto a las
caractersticas de seguridad que deben de implementar en sus
productos nuevos y planearla con anticipacin, para aplicarla en sus
productos comerciales y as ofrecer sistemas que satisfacen requisitos
de seguridad (con nfasis determinado en la prevencin del acceso de
datos) para las aplicaciones sensitivas.
3. Adquisicin
Propsito El proporcionar las bases para especificar los requerimientos de
seguridad en adquisiciones determinadas.
Ms que una especificacin de requerimientos de seguridad, y tener

vendedores que respondan con una gama de piezas. El libro naranja
proporciona una va clara de especificaciones en un juego coordinado de
funciones de seguridad. Un cliente puede estar seguro que el sistema
que va a adquirir fue realmente verificado para los distintos grados de
seguridad.
Las categoras de seguridad del DoD van desde D (Proteccin Mnima)

hasta A (Proteccin Verificada).
A continuacin se presenta un breve resumen las caractersticas de

cada una de estas categoras y los niveles que tiene cada una.
D- Proteccin Mnima.
Proteccin
Mnima
Esta divisin contiene solamente una clase. Esta reservada para los
sistemas que han sido evaluados que pero que no pueden cumplir los
requisitos para una clase ms alta de la evaluacin.
10
Cualquier sistema que no cumple con cualquier otra categora, o ha

dejado de recibir una clasificacin ms alta. El sistema DOS para PCs se
cae en esta categora.
C- Proteccin discrecional.
Las clases en esta divisin proporcionan una Proteccin discrecional

(necesidad de - identificacin) y, a travs de inclusin de capacidades
de auditoria, exige la responsabilidad de los usuarios de las acciones
que realiza.
La proteccin discrecional se aplica a una Base de Computadoras

Confiables (TCB2) con proteccin de objetos optativos (p.e. archivo,
directorio, dispositivos, etc.).
1. C1- Proteccin de Seguridad discrecional.
Las TCB de un sistema de la clase C1, deben cubrir los requisitos de

seguridad discrecional proporcionando la separacin de usuarios y de
datos. Incorporar algn mecanismo de control y acreditacin, as como la
capacidad de hacer cumplir las restricciones de acceso de una base
Proteccin individual, es decir, garantizar de una forma convincente a los usuarios
Discrecional de que sus proyectos o informacin privada esta protegida y evitar que
otros usuarios accidentalmente puedan leer o destruir sus datos. Se
supone que en el ambiente de la clase C1 existe cooperacin entre los
usuarios y adems todos ellos procesan datos en el mismo nivel(es) de
sensitividad.
1
Trusted Computers Bases (Computadora Confiable Base) en el resto del texto se
utilizan las iniciales TCB.
11
Los requisitos mnimos para los sistemas con asignacin de la clase C1

son:
Proteccin de archivos optativa, por ejemplo Control de Listas de

Acceso (ACL3s), Proteccin a Usuario/ Grupo/Pblico.
Usualmente para usuarios que estn todos en el mismo nivel de
seguridad.
Proteccin de la contrasea y banco de datos seguro de
autorizaciones (ADB4).
Proteccin del modo de operacin del sistema.
Verificacin de Integridad del TCB.
Documentacin de Seguridad del Usuario.
Documentacin de Seguridad del Administracin de Sistemas.
Documentacin para Comprobacin de la Seguridad.
Diseo de documentacin de TCB.
Tpicamente para usuarios en el mismo nivel de seguridad.
Ejemplo de estos sistemas son las primeras versiones de Unix.
2. C2- Proteccin de Acceso Controlado.

Proteccin
discrecional Los sistemas en esta clase hacen cumplir ms fielmente un control de
acceso discrecional ms fino que los sistemas C1, haciendo responsable
individualmente a los usuarios de sus acciones a travs de
procedimientos de conexin, revisin de eventos relevantes de
seguridad, y el aislamiento de recursos.
Los siguientes son requisitos mnimos para los sistemas con asignacin
de clase (C2):
La proteccin de objetos puede estar con base al usuario, ej. De un

ACL o una base de datos del administrador.
La autorizacin para accesar slo puede ser asignada por usuarios
autorizados.
Proteccin de reuso de objetos (p.e. para evitar reasignacin de
permisos de seguridad de objetos borrados).
Identificacin obligatoria y procedimientos de autorizacin para los
usuarios, p.e. contraseas.
Auditoria de eventos de seguridad.
Proteccin del modo de operacin del sistema.
Agrega proteccin para autorizaciones y auditora de datos.
1
Access Control List (Lista de Control de Acceso), en el resto del texto se utilizan las
iniciales ACL
1
Access Data Base (Base de datos de accesos), en el resto del document se utilizan las
iniciales ADB
12
Documentacin de la informacin como C1 plus al examinar la

auditora de la informacin.
Algunos sistemas tpicos son versiones posteriores de Unix, VMS.
B- Proteccin Obligatoria.
La divisin B especifica que el sistema de proteccin del TCB debe ser

obligatorio, no solo discrecional.
La nocin de un TCB que preserve la integridad de etiquetas de

sensibilidad de la informacin y se utilizan para hacer cumplir un
conjunto de reglas obligatorias del control de acceso, es un requisito
importante en esta divisin. Los sistemas en esta divisin deben llevar
las etiquetas de sensibilidad en las estructuras de datos importantes del
sistema. El desarrollador del sistema tambin debe proporcionar un
modelo de poltica de seguridad en el cual se basa el TCB y equipar por
medio de una serie de especificaciones al TCB. Evidentemente debe ser
proporcionada una demostracin que sirva para aclarar el concepto del
monitor de referencia y su forma de implementarlo.
1. B1- Proteccin de Seguridad por Etiquetas

Proteccin
Obligatoria Los sistemas de la clase B1 requieren todas las caractersticas
solicitadas para la clase C2. Adems una declaracin informal del
modelo de la poltica de seguridad, de las etiquetas de los datos, y del
control de acceso obligatorio sobre los eventos y objetos nombrados
debe estar presente. Debe existir la capacidad para etiquetar
exactamente la informacin exportada. Cualquier defecto identificado al
hacer las pruebas debe ser eliminado.
Los siguientes son los requisitos mnimos para los sistemas con
asignaron de grado de la clase B1:
Seguridad obligatoria y acceso por etiquetas a todos los objetos, ej.

archivos, procesos, dispositivos, etc.
Verificacin de la Integridad de las etiquetas.
Auditoria de objetos Etiquetados.
Control de acceso obligatorio.
Habilidad de especificar el nivel de seguridad impreso en salidas
legibles al humano (ej. impresiones.).
13
2. B2- Proteccin Estructurada
En los sistemas de clase B2, los TCB deben estar basados en una
documentacin formal clara y contar con un modelo de poltica de
seguridad bien definido que requiera un control de acceso discrecional y
obligatorio, las imposiciones a los sistemas encontradas en la clase B1,
se deben extender a todos los eventos y objetos en sistemas ADP5.
Adems, los canales secretos son direccionados. El TCB se debe estar
cuidadosamente estructurado en elementos de proteccin crticos y
elementos de proteccin no crticos. La interfaz de TCB deber estar
bien definida as como el diseo y la activacin de la implementacin del
TCB le permiten ser sujeto de prueba y revisin ms completa. Se
consolidan los mecanismos de autentificacin, el manejo de recursos
seguros se proporciona en forma de ayuda para las funciones del
administrador y del operador del sistema, y se imponen controles
rigurosos de la administracin de configuracin. El sistema es
relativamente resistente a la penetracin.
Los siguientes son requisitos mnimos para los sistemas con asignacin
de grado de la clase B2:
Proteccin
obligatoria Notificacin de cambios del nivel de seguridad que afecten
interactivamente a los usuarios.
Etiquetas de dispositivos jerrquicas.
Acceso obligatorio sobre todos los objetos y dispositivos.
Rutas Confiables de comunicaciones entre usuario y sistema.
Rastreo de los canales secretos de almacenamiento.
Modo de operacin del sistema ms firme en multinivel en unidades
independientes.
Anlisis de canales seguros.
Comprobacin de la seguridad mejorada.
Modelos formales de TCB.
Versin, actualizacin y anlisis de parches y auditoria.
Un ejemplo de estos sistemas operativos es el Honeywell Multics.
3. B3- Proteccin por Dominios
En la clase B3 los TCB debe satisfacer los requisitos de herramientas

de monitoreo como un monitor de referencia que Interviene en todos
los accesos de usuarios a los objetos, a fin de ser comprobada, y que
sea lo bastante pequea para ser sujeta al anlisis y pruebas.
1
Automatic Data Processing (Procesamiento automtico de datos), en el resto del texto
se utilizan las iniciales ADP
14
Al final, el TCB debe estar estructurado para excluir el cdigo no esencial

para aplicar la poltica de seguridad, mediante ingeniera de sistemas
durante el diseo y la implementacin del TCB, orientada hacia la
reduccin de su complejidad al mnimo. Debe de contar tambin con un
Administrador de Seguridad, los mecanismos de auditoria se amplan
para sealar acontecimientos relevantes de la seguridad, y se necesitan
procedimientos de recuperacin del sistema. El sistema es altamente
resistente a la penetracin.
Proteccin Los siguientes son requisitos mnimos para los sistemas con asignacin
Obligatoria de un grado de clase B3:
ACLs adicionales basado en grupos e identificadores.

Rutas de acceso confiables y autentificacin.
Anlisis automtico de la seguridad.
Modelos ms formales de TCB.
Auditora de eventos de seguridad.
Recuperacin confiable despus de baja del sistema y
documentacin relevante.
Cero defectos del diseo del TCB, y mnima ejecucin de errores.
A- Proteccin Verificada
Esta divisin se caracteriza por el uso de mtodos formales para la

verificacin de seguridad y as garantizar que los controles de seguridad
obligatoria y discrecional empleados en el sistema pueden proteger con
eficacia la informacin clasificada o sensitiva almacenada o procesada
por el sistema. Se requiere de amplia documentacin para demostrar
que el TCB resuelve los requisitos de seguridad en todos los aspectos
del diseo, desarrollo e implementacin
Proteccin
Verificada 1. A1- Diseo verificado
Se deben de cubrir todos los requisitos de B3 ms otros criterios

adicionales:
Los sistemas en la clase (A1) son funcionalmente equivalentes a los de

la clase B3 en que no se agrega ningunas caractersticas o requisitos
arquitectnicos adicionales de la poltica de seguridad. La caracterstica
que distingue los sistemas en esta clase es el anlisis derivado de
tcnicas formales de especificacin y la verificacin del diseo, y el alto
grado de confiabilidad que resulta de la correcta implementacin del
TCB.
15
Este garanta se desarrolla naturalmente, comenzando con un modelo

formal de la poltica de la seguridad y una especificacin formal de alto
nivel (FTLS6) del diseo. Independiente del lenguaje determinado de la
especificacin o sistema de la verificacin usado, hay cinco criterios
importantes para la verificacin del diseo de la clase (A1).
Un modelo formal de la poltica de seguridad debe ser claramente

identificado y documentar, incluyendo una prueba matemtica que el
modelo es constante con sus axiomas y es suficiente para soportar la
poltica de la seguridad.
Un FTLS debe ser proporcionado que incluya las definiciones

abstractas de las funciones que el TCB se realiza y de los
mecanismos de la dotacin fsica y/o de los firmwares que se utilizan
para utilizar dominios separados de la ejecucin.
Se debe demostrar que el FTLS del TCB es constante y consistente

con el modelo por tcnicas formales en lo posible (es decir, donde
Proteccin existen las herramientas de verificacin) y las informales de otra
manera.
verificada
La implementacin del TCB (p.e., en Hardware, firmware, y software)
debe mostrar informalmente que es consistente con el FTLS. Los
elementos del FTLS deben ser mostrados, usando tcnicas
informales, que correspondan a los elementos del TCB. El FTLS
debe expresar un mecanismo unificado de proteccin, necesario
para satisfacer la poltica de seguridad, y todos los elementos de
este mecanismo de proteccin deben estar asociados a los
elementos del TCB.
Deben de utilizarse tcnicas de anlisis formal para identificar y

analizar los canales secretos. Las tcnicas informales se pueden
utilizar para identificar los canales secretos de sincronizacin. La
continua existencia de canales secretos identificados en el sistema
debe ser justificada.
2. A2 en adelante
La Propuesta hecha para los ms altos niveles de seguridad se

denomina como A2, aunque sus requerimientos aun no han sido
definidos formalmente.
1
Formal Top Level Specification (Especificacin formal de alto nivel), en el texto se
utilizan las iniciales en ingles FTLS
16
Evaluacin de clases y ejemplo de

sistemas
Evaluacin
En la siguiente tabla se resumen los niveles de seguridad establecidos
por el Libro naranja, las clases que los integran, el nombre que recibe
cada una de estas clases as como ejemplo de algunos de los sistemas
han logrado ese grado.
Nivel Clase Nombre Ejemplo
D Proteccin Mnima
D Sistemas operativos bsicos: MS-DOS
C Proteccin Discrecional
IBM MVS/RACF
Proteccin de Seguridad Cualquier versin de UNIX ordinaria,
C1
discrecional que no ha sido enviada a una
evaluacin formal
Computer Associates International:

ACF/2/MVS
Proteccin de Acceso
C2 Digital Equipment Corporation:
Controlado
VAX/VMS 4.3
HP MPE V/E
B Proteccin Obligatoria
AT&T System V/MLS
Proteccin de seguridad UNISIS OS 1100
B1
por etiquetas SecuryWare: CMW+
IBM MVS/ESA
Honeywell Information System: Multics
B2 Proteccin Estructurada
Trusted Information System XENIX
B3 Proteccin por Dominios Honeywell Federal System XTS-200
A Proteccin Verificada
Honeywell Information System SCOMP

A1 Diseo verificado
Boeing Aerospace : SNS
17
La figura siguiente compara las clases de evaluacin del libro naranja,

mostrando las caractersticas requeridas para cada clase y en trminos
generales, como se incrementan los requerimientos de clase a clase.
Evaluacin Adicionalmente se presentan cuadros comparativos de cada criterio a

evaluar y los cambios ms importantes que se necesitan para pasar de
un nivel de seguridad u otro.
C1 C2 B1 B2 B3 A1
Polticas de seguridad
Control de acceso discrecional
Reutilizacin de Objetos
Etiquetas
Integridad de Etiquetas
Exportacin de informacin etiquetada
Exportacin de Dispositivos multinivel.
Exportacin de Dispositivos de nivel nico
Etiquetado de salidas legibles a la persona
Etiquetas sensitivas de eventos
Dispositivos etiquetados
Control de acceso obligatorio
Responsabilidad
Identificacin y autentificacin
Rutas seguras
Auditoria
Confianza
Arquitectura del sistema
Integridad del sistema
Pruebas de seguridad
Diseo de especificaciones y verificacin
Anlisis de canales secretos
Facilidad de administracin de la seguridad
Administracin de configuracin
Recuperacin confiable
Distribucin confiable
Documentacin
Gua del usuario sobre caractersticas de seguridad
Facilidades del manual de seguridad
Pruebas de documentacin
Diseo de documentacin
18
C1 C2 B1 B2 B3 A1
Significado de los claves

No requerido para esta clase.
Requerimiento nuevo o mejorado para esta clase
No se tienen requerimientos adicionales para esta clase
19
El Control de acceso discrecional

(DAC) es un mtodo de restringir el acceso a los archivos (y a otros objetos del sistema) basndose en la identidad de los usuarios y/o los
grupos a los que pertenecen. EL DAC es el ms comn de los mecanismos de control de acceso que se encuentra en los sistemas
C1 C2 B1 B2 B3 A1
Control de acceso discrecional
La TCB deber Requerimientos No se tienen No se tienen Requerimientos No se tienen
definirse y controlar el adicionales requerimientos requerimientos adicionales requerimientos
acceso entre usuarios Definicin de grupos adicionales adicionales El mecanismo de adicionales
registrados y objetos ms especficamente ejecucin debe de ser
registrados (por El mecanismo de accesado mediante
ejemplo, archivos y ejecucin debe listas de control
programas). En el proporcionar controles El control de acceso
sistema ADP para limitar la debe ser capaz de
El mecanismo de propagacin de especificar a cada
ejecucin (por ejemplo permisos de acceso objeto registrado, una
controles de usuario / El mecanismo de lista de nombres de
grupo / publico, control control de acceso personas con sus
de listas de acceso) discrecional deber respectivos modos de
deber permitirse a Permitir ya sea una acceso a ese objeto.
los usuarios el accin de un usuario Adems, para cada
especificar y controlar explcito o un default, uno de los objetos
el compartir ciertos proporciona que los registrados, de ser
objetos a individuos objetos sean posible especificar una
registrados o grupos protegidos de accesos lista de los individuos
definidos o ambos. no autorizados. registrados y una lista
Este control de acceso de los grupos o
debe ser capaz de personas registradas
incluir o excluir el con acceso denegado
acceso de usuarios. del grupo,
El permiso de acceso
de un objeto para
usuarios que ya no
poseen el permiso de
acceso deber ser
asignado slo por los
usuarios autorizados
20
Reutilizacin de objetos
La Reutilizacin de objetos requiere la proteccin de archivos, memoria y otros objetos en un sistema auditado de ser accesadas
accidentalmente por usuarios que no tienen acceso autorizado a ellos. Las caractersticas de control de acceso de u sistema
ordinario determina quien puede y quien no puede accesar archivos, dispositivos y otros objetos que han sido asignados a usuarios
especficos La reasignacin de objetos requiere las direcciones que aparecen en esos objetos sean reasignadas.
C1 C2 B1 B2 B3 A1
Reutilizacin de objetos
No se requiere Todas las No se tienen No se tienen No se tienen No se tienen
autorizaciones para la requerimientos requerimientos requerimientos requerimientos
informacin contenida adicionales adicionales adicionales adicionales
con un
almacenamiento de
objetos debern ser
revocadas
previamente o con una
asignacin inicial,
asignacin o
reasignacin del tema
desde el pool del TCB
de los objetos no
utilizados y
almacenados.
La informacin,
incluyendo la
representacin
encriptada de la
informacin, producida
por las aciones de un
evento previo debe de
estar disponible para
cualquier evento que
obtenga el acceso de
un objeto que ha sido
ya regresado al
sistema
21
Etiquetas
Las etiquetas y el control de acceso obligatorio son requerimientos separados de la poltica de seguridad, pero ambas funcionan
juntas. Al iniciar en el nivel B1, el libro naranja propone que cada sujeto (p.e. usuario, proceso) y un objeto almacenado (p.e.
archivos, directorios, ventanas, socket) tengan una etiqueta sensitiva asociada a l. Una etiqueta sensitiva de usuario especifica el
grado, o nivel de confianza, asociado con ese usuario, las etiquetas de usuario sensitivas es usualmente llamada como certificado
de paso "clearance". Una etiqueta sensitiva de archivo especifica el nivel de confianza que un usuario puede ser capaz de tener al
accesar ese archivo
C1 C2 B1 B2 B3 A1
Etiquetas
No se requiere No se requiere Etiquetas sensitivas Requerimientos No se tienen No se tienen
asociadas con cada adicionales requerimientos requerimientos
evento y objeto Las etiquetas adicionales adicionales
almacenado bajo su sensitivas asociadas
control (p.e. procesos, con cada recurso del
archivos, segmentos, sistema ADP (p.e.
dispositivos) deben ser eventos, objetos
mantenidos por el almacenados, ROM)
TCB. Estas etiquetas que son directamente
debern ser utilizadas o indirectamente
como las bases para accesados por
las decisiones del eventos externos a l
control del acceso TCB debe ser
obligatorio. En orden mantenido por el TCB
de importancia de
datos no etiquetados,
el TCB debe solicitar y
recibir de un usuario
autorizado el nivel de
seguridad de esos
datos, y todas las
acciones debern ser
auditadas por el TCB
22
Integridad de etiquetas
La integridad de etiquetas asegura que las etiquetas sensitivas asociadas con eventos y objetos tienen una representacin exacta
de los niveles de seguridad de estos eventos y objetos
As una etiqueta sensitiva como TOP SECRET [VENUS]
Deber estar asociado con un archivo TOP SECRET que contiene informacin acerca del planeta Venus
C1 C2 B1 B2 B3 A1
Integridad de etiquetas
No se requiere No se requiere Las Etiquetas No se tienen No se tienen No se tienen
sensitivas debern requerimientos requerimientos requerimientos
representar con adicionales adicionales adicionales
precisin los niveles
de los eventos
especficos u objetos
con los que estos
estn asociados
Cuando son
exportados por el
TCB, las etiquetas
sensitivas debern
precisar y representar
sin ambigedad las
etiquetas internas y
debern estar
asociadas con la
informacin que esta
siendo exportada.
23

Un sistema confiable debe de asegurar que la informacin es escrita por el sistema, que la informacin cuenta con mecanismos de
proteccin asociados a ella. Dos formas de exportar informacin son asignar un nivel de seguridad a los dispositivos de salida
escribir etiquetas sensitivas en los datos. Los sistemas valorados como B1 en adelante deben de proporcionar facilidades de
exportacin segura
Se definen dos tipos de dispositivos para exportar; multinivel y de nivel simple. Cada dispositivo de entrada / salida y canal de
comunicaciones en un sistema debe de ser designado de uno o de otro tipo. Cualquier cambio a estas designaciones de dispositivos
debe de ser capaz de ser auditado. Tpicamente un administrador de sistemas designa dispositivos durante la instalacin del sistema
o durante su configuracin
C1 C2 B1 B2 B3 A1
No se requiere No se requiere El TCB deber No se tienen No se tienen No se tienen
designar cada canal requerimientos requerimientos requerimientos
de comunicaciones y adicionales adicionales adicionales
dispositivo de entrada
/ salida, ya sea como
de un nivel sencillo o
de multinivel.
Cualquier cambio en
esta designacin
deber ser hecha
manualmente y deber
ser auditable por el
TCB. El TCB deber
mantener y ser capaz
de auditar cualquier
cambio en los niveles
de seguridad o
niveles asociados con
un canal de
comunicaciones o
/ salida
24
Exportacin en dispositivos multinivel

Un dispositivo multinivel o un canal de comunicaciones multinivel es uno con la capacidad de escribir informacin con un nmero
diferente de niveles de seguridad. El sistema debe soportar una variedad de especificaciones de niveles de seguridad, desde la ms
baja (SIN CLASIFICACIN) hasta la ms alta (ALTAMENTE SECRETA), permitiendo que un dato sea escrito en un dispositivo .
Cuando se escribe informacin en un dispositivo multinivel, se requiere que el sistema tenga alguna forma de asociar un nivel de
seguridad a l. Los mecanismos pueden diferir para los diferentes sistemas y los diferentes tipos de dispositivos. Los archivos
escritos a este dispositivos pueden tener etiquetas sensitivas agregadas a ellas (usualmente escritas en los encabezados del
registro precediendo los datos del archivo). Todo esto para prevenir que un usuario desve los controles del sistema con una simple
copia de un archivo sensitivo a otro de un sistema inseguro o dispositivo.
C1 C2 B1 B2 B3 A1
Exportacin en dispositivos mltinivel
No se requiere No se requiere Cuando el TCB exporta un No se tienen No se tienen No se tienen
objeto que es multinivel o un requerimientos requerimientos requerimientos
dispositivo de entrada / adicionales adicionales adicionales
salida, la etiqueta sensitiva
asociada con ese objeto
tambin deber ser
exportada y permanecer
residente en el mismo
medio fsico que la
informacin exportada y
deber estar en la misma
forma (p.e. de forma legible
a la mquina o en forma
legible a la persona).
Cuando el TCB exporta o
importa un objeto sobre un
canal de comunicacin
multinivel, el protocolo
usado en ese canal deber
proporcionar una paridad
que evite ambigedad entre
las etiquetas sensitivas y la
informacin asociada que se
esta enviando o recibiendo
25
Exportacin en dispositivos de nivel nico

Un dispositivo de nivel nico o un canal de comunicaciones de nivel nico es uno capaz de escribir informacin con slo un nivel
particular de seguridad. Usualmente las terminales, impresoras, dispositivos de cinta y puertos de comunicacin estn en la
categora de dispositivos de nivel nico. El nivel que se especifica para un dispositivo depende usualmente de su localizacin fsica o
de la seguridad inherente del tipo de dispositivo. Por ejemplo, la instalacin de una red contempla varias impresoras en un nmero
determinado de computadoras y oficinas. El administrador debe designar que esas impresoras tengan niveles sensitivos que
correspondan al personal que tiene acceso a dichas impresoras
C1 C2 B1 B2 B3 A1
Exportacin en dispositivos de nivel nico
No se requiere No se requiere Los dispositivos de No se tienen No se tienen No se tienen
niel nico de canales requerimientos requerimientos requerimientos
de comunicaciones de adicionales adicionales adicionales
entrada / salida no son
requeridas para
mantener las
etiquetas sensibles de
la informacin que
procesan
De cualquier modo, el
TCB debe incluir un
mecanismo para que
el TCB y un usuario
autorizado fiable
comunique y designe
el nivel nico de
seguridad de la
informacin importada
o exportada va canal
de comunicaciones de
nivel sencillo o
/ salida.
26
Etiquetado de salidas legibles a la persona
El libro naranja es muy claro en cuanto a los requerimientos de cmo deben de hacerse las etiquetas para las salidas legibles al
humano (salidas que las personas pueden ver). Estas incluyen pginas de salida impresa, mapas, grficas y otros indicadores. El
administrador del sistema debe de especificar la forma en que las etiquetas van a aparecer en la salida.
Por lo regular se requieren dos tipos de etiquetas: primero, cada salida distinta debe ser etiquetada, al principio y al final, con
etiquetas que representen una sensitividad general de la salida. S se est imprimiendo el contenido de un archivo Y tpicamente se
puede ver una pgina de un banner antes y despus del contenido del documento, mostrando claramente la etiqueta sensitiva del
archivo. Segundo, cada pgina de salida impresa debe ser etiquetada, e la parte superior y en la parte inferior, con etiquetas que
presenten ya sea una u otra, una sensitividad general de la salida o la sensitividad especfica de la informacin en esa pgina
C1 C2 B1 B2 B3 A1
Etiquetas de salida legibles al humano
No se requiere No se requiere El administrador del sistema ADP No se tienen No se tienen No se tienen
debe ser capaz de especificar los requerimientos requerimientos requerimientos
nombres de las etiquetas imprimibles adicionales adicionales adicionales
asociados con las etiquetas sensitivas
exportables
El TCB debe marcar el inicio y el fin
de todas las etiquetas sensitivas
legibles a la persona que representen
sensitivamente la salida. El TCB
deber, por omisin marcar el lmite
inferior y superior de cada pgina
legible al hombre, compaginada, de la
salida impresa (p.e. Salidas de la
impresora) con una etiqueta sensitiva
legible al hombre que represente
apropiadamente la sensitividad global
de la salida o que represente
apropiadamente la sensitividad de la
informacin de cada pgina.
Cualquier anulacin de estas marcas
por defecto deben ser auditables por
el TCB
27
Las etiquetas sensitivas de eventos requieren estados que el sistema pueda notificar a determinado usuario de algn cambio en el
nivel de seguridad asociado con un usuario durante una sesin interactiva. Este requerimiento se aplica de los sistemas evaluados
B2 en adelante.
La idea de las etiquetas sensitivas a eventos es que el usuario siempre conozca el nivel de seguridad en el que esta trabajando. Los
sistemas confiables tpicamente despliegan el "clearance" cuando se establece sesin y lo despliegan nuevamente si el nivel de
seguridad tiene algn cambio, o automticamente a peticin del usuario.
C1 C2 B1 B2 B3 A1
No se requiere No se requiere No se requiere El TCB debe notificar No se tienen No se tienen
inmediatamente a la requerimientos requerimientos
terminal del usuario de adicionales adicionales
cada cambio en el
nivel de seguridad
asociado con ese
usuario durante una
sesin interactiva. La
terminal de usuario
debe de ser capaz de
buscar el TCB cuando
lo desee para
desplegar en un
evento con etiqueta
sensitiva.
28
Dispositivos etiquetados
Los dispositivos etiquetados requieren estados que cada dispositivo fsico tenga adicionados en el sistema que definan niveles
mnimos y mximos de seguridad asociados a ellos, y todos estos son usados para "reforzar las restricciones impuestas por el medio
ambiente fsico en el cual el dispositivo esta localizado".
Para un dispositivo multinivel, se debe de especificar el nivel mnimo de la informacin que puede ser enviada a este dispositivo (el
mnimo para el dispositivo) y el nivel ms alto de informacin que puede ser enviada al dispositivo (el mximo del dispositivo). Para
un dispositivo de un nivel nico, el nivel mnimo es el mismo que el nivel mximo
C1 C2 B1 B2 B3 A1
Dispositivos Etiquetados
No se requiere No se requiere No se requiere El TCB debe soportar No se tienen No se tienen
la asignacin de un requerimientos requerimientos
nivel mnimo y mximo adicionales adicionales
para todo dispositivo
fsico adjunto. Estos
niveles de seguridad
deben de ser usados
por el TCB para
reforzar las
condiciones impuestas
por el medio ambiente
fsico en cada uno de
los dispositivos fsicos
localizados
29
El control de acceso obligatorio es el ltimo requerimiento de la poltica de seguridad, diferente del control de acceso discrecional,
que autoriza a los usuarios especficamente, con sus propias preferencias, quien puede y quin no puede accesar sus archivos, el
control de acceso obligatorio pone el control de todos los accesos como decisiones bajo el control del sistema
C1 C2 B1 B2 B3 A1
No se requiere No se requiere El TCB debe reforzar las Requerimientos No se tienen No se tienen
polticas del control de adicionales requerimientos requerimientos
acceso obligatorio de El TCB debe reforzar adicionales adicionales
todos los sujetos y las polticas del control
objetos almacenados de acceso obligatorio
(procesos, archivos, para todos los
dispositivos, etc.) A recursos(usuarios,
estos sujetos y objetos objetos almacenados,
debe ser asignado una dispositivos de entrada
etiqueta sensitiva que / salida) que sean
sean una combinacin e accesibles directa o
clasificacin por nivel indirectamente por
jerrquico y categoras usuarios externos al
no jerrquicas, y las TCB.
etiquetas debern ser Los requerimientos
usadas como la base de debern mantenerse
las decisiones para el para todos los accesos
control de acceso entre todos los
obligatorio usuarios externos a l
El TCB debe ser capaz TCB y todos los
de soportar dos o ms objetos accesibles
niveles de seguridad, los directa o
siguientes indirectamente por
requerimientos debern estos usuarios.
mantenerse para todos
los accesos entre
sujetos y objetos
controlados por el TCB.
30
C1 C2 B1 B2 B3 A1
Un sujeto puede leer un

objeto solamente si la
clasificacin jerrquica
del nivel de seguridad
del sujeto es menor o
igual que la clasificacin
jerrquica de los niveles
de seguridad del objeto y
la categora no
de seguridad que se
incluyen en todas las
categoras no jerrquicas
del objeto.
Un usuario puede
escribir en un objeto
solamente si la
clasificacin jerrquica
del sujeto es mayor o
igual que la clasificacin
de seguridad del objeto y
cumple con todas las
de los niveles de
seguridad que se
incluyen en todas las
del objeto.
31
La identificacin y la autentificacin es un requerimiento de un sistema de seguridad en todos los niveles. El libro naranja requiere que la
identificacin del usuario antes de ejecutar cualquier tarea que requiera interaccin con el TCB (p.e. correr un programa, leer un archivo o invocar
cualquier funcin que requiere que el sistema cheque los permisos de acceso). En la mayora de los sistemas multiusuario, la identificacin en el
sistema se hace a travs de algn tipo de nombre identificador (logn), seguido de un pasword.
El libro naranja establece que el password debe ser protegido, pero no dice como, existen dos publicaciones adicionales por el gobierno de los
Estados Unidos que proporcionan sugerencias concretas:
The Department of Defense Password Management Guideline (El Libro Verde)
FIPS PUB 112 - Password Usage,
El libro verde defiende tres caractersticas principales
1. Los usuarios deben ser capaces de cambiar sus passwords
2. Los passwords deben ser generados por la maquina ms el creado por el usuario
3. Seguridad en reportes de auditoria (fecha y hora del ltimo login) debe ser proporcionado por el sistema directamente al usuario.
C1 C2 B1 B2 B3 A1
El TCB debe solicitar Requerimientos Requerimientos adicionales No se tienen No se tienen No se tienen
la identificacin de los adicionales El TCB debe mantener los requerimientos requerimientos requerimientos
usuarios antes de El TCB debe ser datos de autentificacin que adicionales adicionales adicionales
empezar a ejecutar capaz de reforzar las incluyen la informacin para
cualquier accin que cuentas individuales verificar la identidad de los
el TCB deba de al proporcionar la usuarios (password) As
ejecutar. El TCB debe capacidad de como la informacin para
usar algn mecanismo identificacin nica a detectar la autorizacin de
de proteccin cada usuario usuarios individuales.
(passwords) para individual ADP. El Los datos deben ser usados
autentificar la TCB debe tambin por el TCB para autentificar la
identidad del usuario. proporcionar la identidad de los usuarios y
El TCB debe proteger capacidad de asociar asegurar que el nivel de
los datos de la identidad con toda seguridad y la autorizacin de
autentificacin de accin audible todos los usuarios externos al
manera que no elegida por esa TCB puedan ser creados
puedan ser accesados persona para actuar en nombre del
por usuarios no usuario individual que se
autorizados documenta por el pase y la
autorizacin del tipo de
usuario
32
Rutas Seguras
Una ruta segura proporciona un medio libre de errores, por el cual un usuario (tpicamente una terminal o un a estacin de trabajo)
puede comunicarse directamente con un TCB sin interactuar con el sistema a travs de aplicaciones inseguras (y posiblemente poco
fiables) y capas del sistema operativo. Una ruta segura es un requerimiento para sistemas clasificados como B2 en adelante
C1 C2 B1 B2 B3 A1
Rutas seguras
No se requiere No se requiere No se requiere El TCB debe soportar Requerimientos No se tienen
una ruta segura de adicionales requerimientos
comunicaciones entre El TCB debe soportar adicionales
l y un usuario para una ruta segura de
su identificacin y comunicaciones entre
autentificacin. La l y usuarios para
comunicacin va esta usarse cuando una
ruta deber ser conexin TCB a
iniciada usuario es requerida
exclusivamente por el (login, cambiar algn
usuario nivel de seguridad).
Las comunicaciones
va ruta segura deben
ser activadas
exclusivamente por el
usuario o el TCB y
deben ser aisladas y
libres de errores as
como distinguibles de
otras conexiones
33
Auditora
La auditora es el registro, examen y revisin de las actividades relacionadas con la seguridad en un sistema confiable. Una
actividad relacionada con la seguridad es cualquier accin relacionada con el acceso de usuarios, o acceso a objetos. En trminos
de auditoria, algunas actividades son llamadas frecuentemente eventos, y una auditoria interna se llama algunas veces eventos
logging.
Los eventos tpicos incluyen

Logins (exitosos o fallidos)
Logouts
Accesos a sistemas remotos
Operaciones de archivos, apertura, renombrar, eliminacin.
Cambios en los privilegios y atributos de seguridad (cambiar en un archivo la etiqueta sensitiva o el nivel del pase de un
usuario)
Porque auditar estos eventos? La principal razn es que hasta el sistema ms seguro es vulnerable a ser atacado, y la auditora
proporciona un excelente medio de determinar cuando y como un ataque puede ser efectuado.
La auditora permite os funciones muy tiles de seguridad: Inspeccin y reconstruccin. La supervisin es el monitoreo de la
actividad del usuario. Este tipo de auditora, puede prevenir de que violaciones de seguridad puedan ocurrir, esto solo porque los
usuarios saben que alguien los esta observando. La reconstruccin es la habilidad de poner junto, al evento de violacin de
seguridad, un registro de que sucedi, que necesita ser arreglado y Quien es el responsable.
Cada vez que un evento auditable ocurre, el sistema escribe al final la siguiente informacin (Ordenada por el Libro Naranja)
Fecha y hora de cada evento
Identificado ID nico del usuario que ejecuto el evento
Tipo de evento
Si el evento fue exitoso o no
Origen de la peticin (identificador de la terminal)
Nombre de los objetos involucrados (nombre de (ej. Nombre de los archivos a ser borrados)
Descripcin y modificacin a las bases de datos de seguridad
Niveles de seguridad de los usuarios y objetos (B1 en adelante)
La auditoria es una herramienta vital de administracin. Al observar patrones o actividad sospechosa (p.e. un gran nmero de login
fallados desde una terminal en particular o los repetitivos intentos de un usuario de leer archivos a los que l no tiene acceso).
Algunos proveedores proporcionan utilerias que permiten llevar la auditoria y realizar pistas para ser impresas para usuarios
particulares, para tipos especficos de eventos o para archivos particulares. Los eventos tpicos incluyen eventos del sistema,
eventos de archivos, y eventos de usuarios.
34
C1 C2 B1 B2 B3 A1
Auditora
No se requiere El TCB debe ser capaz Requerimientos Requerimientos Requerimientos No se tienen
de crear, mantener y adicionales adicionales adicionales requerimientos
proteger de El TCB tambin debe ser El TCB debe ser El TCB debe contar adicionales
modificaciones, o acceso capaz de auditar capaz de auditar los con un mecanismo
de usuarios no cualquier sustitucin de eventos identificados con la capacidad de
autorizados o marcas de salida legibles que pueden ser monitorear las
destruccin de pistas de al humano usados en la ocurrencias o
auditoria o accesos a Para eventos que explotacin o cubierta acumulacin de
objetos protegidos. La introducen un objeto de canales de eventos de seguridad
auditora de datos debe dentro del espacio almacenamiento auditable que pueden
ser protegida por el TCB direccionable del usuario indicar de una
de accesos de lectura o y para borrar eventos de inminente violacin a
limitar a quien esta objetos el registro de las polticas de
autorizado para auditar auditoria debe incluir el seguridad. Este
los datos. nombre de los objetos y mecanismo deber de
El TCB debe ser capaz el nivel de seguridad del ser capaz de notificar
de registrar los objeto. inmediatamente al
siguientes tipos de El administrador de administrador de
eventos: Uso de sistema ADP debe ser seguridad cuando se
mecanismos de capaz de auditar excede el umbral, y si
identificacin y selectivamente las la acumulacin de
autentificacin, acciones de algn o ocurrencias de
introduccin de objetos varios usuarios eventos relevantes de
en el espacio basndose en la seguridad continua, el
direccionable del usuario identidad individual y/o sistema deber tomar
(apertura de archivos, nivel de seguridad de los la ltima accin
inicializacin de objetos. disolvente que termine
programas), eliminacin con este evento
de objetos, acciones
tomadas por operadores
de la computadora y
administradores del
sistema
35
C1 C2 B1 B2 B3 A1
Auditora
y/o administradores de la
seguridad del sistema, y
otros eventos relevantes
del sistema. Para cada
evento registrado, el
registro de auditoria
deber identificar: fecha
y hora del evento, y si el
evento fue exitoso o fallo
el evento. La
identificacin /
autentificacin de
eventos que originan la
peticin (ID de la
terminal) debern ser
incluidos en el registro de
auditoria
El administrador de
sistema ADP, debe ser
capaz de seleccionar las
acciones a auditar de
uno o de varios usuarios
basndose en la
identidad individual
36

El requerimiento de arquitectura del sistema tiene el objeto de disear un sistema para hacerlo lo ms seguro posible, - sino
invulnerable.
As los sistemas de los niveles bajos (C1, B1 y hasta B2) no fueron necesariamente diseados especficamente para seguridad,
ellos soportan principios de diseo de hardware y sistema operativo, tan bien como la habilidad de soportar caractersticas
especficas que quizs son agregadas a estos sistemas. La mayora de los diseos modernos de multiprocesamiento, y sistemas
multi usuarios siguen las claves los principios de diseo necesarios para cumplir los requerimientos del libro naranja en los que
arquitectura del sistema se refiere al menos C2 y B1, s bien estos principios no estn necesariamente orientados a seguridad
C1 C2 B1 B2 B3 A1
EL TCB debe Requerimientos Requerimientos Nuevos Requerimientos No se tienen
mantener un adicionales adicionales Requerimientos para adicionales requerimientos
dominio para su El TCB debe aislar los El TCB debe mantener B2 El TCB debe disear adicionales
propia ejecucin recursos a ser protegidos procesos aislados as El TCB debe mantener y estructurar el uso
que lo proteja de de manera que los como proporcionar un dominio para su completo, de un
interferencia usuarios tengan control distintas direcciones de propia ejecucin de mecanismo de
externa o de acceso y espacio bajo su control protecciones de proteccin,
falsificaciones (Ej. requerimientos de interferencia externa o conceptualmente
Para modificacin auditora falsificaciones(Ej. Para simple con definicin
de su cdigo o modificacin de su semntica precisa.
estructura de cdigo o estructura de Este mecanismo debe
datos). Los datos). El TCB debe jugar un papel central
recursos mantener procesos en el reforzamiento de
controlados por el aislados as como la estructura interna
TCB pueden ser proporcionar direccin entre el TCB y el
definidos en un de espacios distintas sistema. El TCB debe
subgrupo as bajo su control. incorporar el uso
como los El TCB debe estar significativo de capas,
usuarios y objetos estructurado abstraccin y
en el sistema internamente dentro ocultamiento de datos.
ADP. de una bien definido
mdulo independiente.
37
C1 C2 B1 B2 B3 A1
El mdulo TCB debe Una aplicacin de
ser diseado bajo el ingeniera de sistemas
principio de que los significativa debe ser
privilegios sean directamente
reforzados, conducida
Caractersticas de minimizando la
hardware, as como complejidad del TCB y
segmentacin, debe excluyendo de los
ser usado para mdulos del TCB los
soportar lgicamente objetos que no
distinciones de objetos presentan proteccin
almacenados con crtica
atributos separados
(nombrar, leer y
escribir). La interfaz de
usuario del TCB debe
ser completamente
definida y todos los
elementos del TCB
identificados
38

La integridad del sistema significa que el hardware y el firmware debe trabajar y debe ser probado para asegurar que trabaje
adecuadamente, Para todos los niveles, el libro naranja establece las caractersticas de hardware y software que deben ser
proporcionadas para ser usadas y peridicamente validadas para la correcta operacin del hardware instalado y los elementos
firmware del TCB.
La integridad de sistema una meta de vital importancia para todos los desarrolladores de sistemas, y no solo desarrolladores de
sistemas seguros. Como ya se ha mencionado anteriormente, un elemento muy importante de un sistema de seguridad es la
habilidad de que el sistema funcione como se espera y permanecer en operacin
Muchos vendedores miden los requerimientos de integridad del sistema, al proveer de un juego de pruebas de integridad, EL ms
substancial diagnostico es hacer un programa calendarizado de periodos de mantenimiento preventivo
C1 C2 B1 B2 B3 A1
Las No se tienen No se tienen No se tienen No se tienen No se tienen
caractersticas del requerimientos requerimientos requerimientos requerimientos requerimientos
hardware y/o el adicionales adicionales adicionales adicionales adicionales
software deben
ser
proporcionadas
para ser usadas y
peridicamente
validadas su
correcta
operacin as
como los
elementos de
hardware y
firmware del TCB
39

Un canal secreto es una ruta de informacin que no se usa ordinariamente para comunicaciones en un sistema, por los mecanismos
normales de seguridad del sistema. Es una va secreta para transportar informacin a otra persona o programa El equivalente
computacional de un espa que porta un peridico como una contrasea.
En teora cada pieza de informacin almacenada o procesada por un sistema computacional seguro es un potencial canal secreto.
Existen dos tipos de canales secretos, canales de almacenamiento y canales de temporizacin. Los canales de almacenamiento
transportan informacin para cambiar datos almacenados en el sistema en alguna forma. Los canales de temporizacin transportan
informacin que afecte el desempeo o modifiquen de alguna forma el tiempo usado por los recursos del sistema en alguna forma
medible.
C1 C2 B1 B2 B3 A1
No se requiere No se requiere No se requiere El sistema Requerimientos Requerimientos
desarrollado deber adicionales adicionales
comportarse Bsqueda de todos los Mtodos formales
completamente, canales simulados deben de ser usados
buscando la (almacenamiento y en el anlisis
simulacin de canales temporizacin)
de almacenamiento y
haciendo
determinaciones (para
las mediciones
actuales o por
estimaciones de
ingeniera) o el
mximo ancho de
banda de cada canal
identificado
40

La facilidad de la administracin de seguridad es la asignacin de un individuo especfico para administrar las funciones relacionadas con la
seguridad de un sistema.
La facilidad de administracin de la seguridad es muy relacionada con el concepto de privilegio mnimo, un concepto tempranamente introducido
en trminos de arquitectura de sistemas. En el contexto de seguridad, el privilegio mnimo significa que el usuario de un sistema debe tener el
menor nmero de permisos y la menor cantidad de tiempo nicamente el necesario para desempear su trabajo. Tambin esta relacionado el
concepto de administracin con la separacin de obligaciones, la idea es que es mejor asignar piezas de seguridad relacionadas con tareas de
algunas personas especficas y que ningn usuario tenga el control total de los mecanismos de seguridad del sistema, para que de ninguna forma
un usuario pueda comprometer completamente al sistema.
C1 C2 B1 B2 B3 A1
No se requiere No se requiere No se requiere El TCB debe soportar Requerimientos No se tienen
separadamente las adicionales requerimientos
funciones de Las funciones ejecutadas adicionales
administrador y en el papel del
operador administrador de
seguridad deben ser
identificadas. El Personal
de Administracin del
sistema ADP, deber solo
ser capaz de ejecutar
funciones de administrador
de seguridad despus de
tomar una accin auditable
distinguible al asumir el
papel de administrador de
la seguridad en el sistema
ADP. Las funciones que
no son de seguridad que
pueden ser ejecutadas por
el papel de administrador
de seguridad debern
limitarse estrictamente a lo
ms esencial para ejecutar
la seguridad efectivamente
41
La recuperacin confiable asegura que la seguridad no ha sido violada cuando se cae un sistema o cuando cualquier otra falla del
sistema ocurre.
La recuperacin confiable actualmente involucra dos actividades: prepararse ante una falla del sistema y recuperar el sistema.
La principal responsabilidad en preparacin es respaldar todos los archivos del sistema crtico con una base regular. El
procedimiento de recuperacin puede ser con mucho, esforzarse por restaurar solo un da o dos de procesamiento de informacin.
Si una falla inesperada ocurre, como una falla de disco duro, o un corte de corriente elctrica, se debe recuperar el sistema de
acuerdo con ciertos procedimientos para asegurar la continuidad de la seguridad en el sistema. Este procedimiento tambin puede
ser requerido si se detecta un problema del sistema, como recursos perdidos, o una base de datos inconsistente o cualquier cosa
que comprometa el sistema.
C1 C2 B1 B2 B3 A1
No se requiere No se requiere No se requiere No se requiere Los procedimientos No se tienen
y/o mecanismos requerimientos
debern ser adicionales
proporcionados para
asegurar que, despus
de una falla del
sistema ADP u otra
discontinuidad, el
sistema se recupere
sin un obtener
compromiso de
proteccin
42

El diseo de especificaciones y la verificacin requiere una comprobacin de que la descripcin del diseo para el sistema sea
consistente con las polticas de seguridad del sistema.
A cada nivel de seguridad empezando desde el B1, el libro naranja. Requiere un incremento del modelo formal (precisamente
matemtico) de las polticas del sistema de seguridad que permite se incrementen las pruebas de que el diseo del sistema es
consistente con su modelo
Qu es una prueba formal? Es un argumento matemtico completo y convincente de que el sistema es seguro, o al menos de que
el diseo del sistema y lleva implementada una adecuada poltica de seguridad. Por ejemplo, si se demuestra matemticamente que
bajo condiciones existen ciertos sujetos (usuarios), que pueden accesar a cierto tipo de objetos (archivos) y se demuestra que los
usuarios no pueden engaar las condiciones de acceso.
C1 C2 B1 B2 B3 A1
No se requiere No se requiere Un modelo formal o Requerimientos Requerimientos Requerimientos
informal de las adicionales para B2 adicionales adicionales
polticas de seguridad Un modelo formal de la Un argumento Una especificacin formal
soportadas por el TCB poltica de seguridad convincente deber de alto nivel (FTLS) del
que deber ser soportada por el TCB ser proporcionado de TCB que deber ser
mantenido durante todo deber ser mantenida que el DTLS es mantenido y precisamente
el ciclo de vida del durante todo el ciclo de consistente con el descrito el TCB en
sistema ADP y vida del sistema ADP modelo trminos de excepciones,
demostracin de ser que deber proporcionar mensajes de error y
consistente con su consistencia con su efectos. EL DTLS y el
axioma axioma. Especificacin FTLS deber incluir los
descriptiva de alto nivel componentes del TCB que
(DTLS) del TCB en estn implementados como
trminos de excepciones, hardware y/o firmware si
mensajes de error y sus propiedades son
efectos. Este deber ser visibles para l la interfaz
mostrado de ser una del TCB. Una combinacin
descripcin exacta de la de tcnicas formales e
interfaz del TCB informales deber ser
usada para mostrar que el
FTLS es consistente con el
modelo.
43
El libro naranja tiene un substancial inters en probar las caractersticas de seguridad en los sistemas a evaluar. Las pruebas de
seguridad aseguran que los requerimientos estn relacionados con los requerimientos de pruebas de documentacin. El sistema
desarrollado ser probado para todas las caractersticas de seguridad, asegurando que el sistema trabaja como se describe en la
documentacin, y se documenten los resultados de las pruebas de estas caractersticas. El equipo de evaluacin del NTSC esta
comprometido con sus pruebas.
Estos son los dos tipos bsicos de pruebas de seguridad:

Prueba de mecanismos y
Prueba de interfaz.
La prueba de mecanismos significa probar los mecanismos de seguridad, estos mecanismos incluye control de acceso discrecional,
etiquetado, control de acceso obligatorio, Identificacin y autentificacin, prueba de rutas, y auditora.
La prueba de interfaz significa el probar todas las rutinas del usuario que involucren funciones de seguridad
C1 C2 B1 B2 B3 A1
Los mecanismos de Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos
seguridad del adicionales adicionales para B1 adicionales adicionales adicionales
sistema ADP deber Las pruebas Los mecanismos de El TCB deber ser El TCB deber ser Las pruebas debern
ser probado y debern tambin ser seguridad del sistema encontrado encontrado resistente demostrar que la
encontrado incluidas en la ADP debern ser relativamente a penetraciones, implementacin del
trabajando y exigido bsqueda de probados y encontrados resistente a Ninguna bandera de TCB es consistente
en la documentacin banderas obvias trabajando con la penetracin diseo y ninguna con la especificacin
del sistema. Las que puedan permitir documentacin del Al probar todo deber bandera de formal de alto nivel
pruebas debern ser una violacin de sistema. demostrarse que la implementacin sin El manual u otros
hechas para recursos aislados, o Un equipo de individuos implementacin del correcciones debe ser mapas del FTLS del
asegurar que no hay que puedan permitir que entiendan TCB es consistente encontrada durante las cdigo fuente pueden
caminos obvios para el acceso no completamente la con la descripcin de pruebas y debern ser formar bases para las
acceso de usuarios autorizado de implementacin especfica especificacin de alto razonablemente pruebas de
no autorizados o auditora o del TCB deber disear nivel. confidenciales las penetracin.
cualquier otra falla en autentificacin de documentacin, cdigo pocas que queden.
el mecanismo de datos fuente y cdigo objeto
proteccin de la para el anlisis completo y
44
C1 C2 B1 B2 B3 A1
seguridad del TCB Las pruebas.
Estos objetivos debern
descubrir todo el diseo y
la implementacin de
banderas que pudieran
permitir a un sujeto
externo al TCB el leer,
cambiar o borrare datos
normalmente denegados
bajo polticas de seguridad
discrecional u obligatorias
reforzadas por el TCB, as
como el asegurar que
ningn sujeto (sin
autorizacin para hacerlo)
sea capaz de causar que
el TCB entre en un estado
tal que sea incapaz de
responder a
comunicaciones iniciadas
por otros usuarios. Todas
las banderas descubiertas
debern ser removidas o
neutralizadas y el TCB
vuelto a probar para
demostrar que estas han
sido eliminadas y que
nuevas banderas no han
sido introducidas
45
La administracin de configuraciones protege un sistema seguro mientras esta siendo diseado, desarrollado, y mantenido.
Involucra el identificar, controlar, contabilizar y auditar todos los cambios hechos en los lineamientos de TCB, incluyendo hardware,
firmware y software, por ejemplo, cualquier cambio en el cdigo, durante las faces de diseo, desarrollo y mantenimiento as como la
documentacin, planes de pruebas, y otras herramientas del sistema relacionadas y sus facilidades.
La administracin de configuraciones tiene varias metas, primero, el control del mantenimiento del sistema durante su ciclo de vida,
asegurando que el sistema es usado de la forma correcta, implementando las polticas de seguridad adecuadas. El sistema
adecuado es el sistema que ha sido evaluado o que actualmente esta siendo evaluado En otras palabras la administracin de
configuraciones previene de usar versiones obsoletas 8 nuevas, que no han sido probadas en el sistema) o alguno de sus
componentes.
Segundo, hace posible el regresar a versiones previas del sistema. Esto es importante, si por ejemplo, un problema de seguridad es
encontrado en una versin del sistema que no tenan en una versin anterior.
Para cumplir los requerimientos de la administracin de configuracin se necesita
Asignar un identificador nico para cada elemento configurable
Desarrollar un plan de administracin de la configuracin
Registrar todos los cambios de elementos de configuracin (en lnea y fuera de lnea)
Establecer un tablero de control e configuraciones
C1 C2 B1 B2 B3 A1
No se requiere No se requiere No se requiere Durante el desarrollo y No se tienen Nuevos Requerimientos
mantenimiento del TCB, una requerimientos para A1
administracin de adicionales Durante el ciclo completo
configuraciones deber tomar de vida... durante el
lugar en el control de diseo, desarrollo, y
mantenimiento de los cambios mantenimiento del TCB,
en la especificacin una administracin de
descriptiva de alto nivel y otros configuraciones deber
datos de diseo, tener lugar para todos el
documentacin de hardware, firmware y
implementacin, cdigo software relacionado con
fuente, las versiones corridas la seguridad y debe de
del cdigo objeto y las mantenerse un control
pruebas de correcciones y formal de mantenimiento
documentacin. de todos los cambios al
46
C1 C2 B1 B2 B3 A1
La administracin de modelo formal las
configuraciones del sistema especificaciones
deber asegurar un mapeo descriptiva y formal de
consistente entre toda la alto nivel, otros datos de
documentacin y el cdigo diseo, documentacin e
asociado con las versiones implementacin, cdigo
actuales del TCB. Las fuente, la versin actual
herramientas debern tenerse del cdigo objeto, las
para generar una nueva pruebas de reparaciones y
versin del TCB desde el la documentacin. La
cdigo fuente. administracin de
Tambin debern estar configuraciones del
disponibles las herramientas sistema deber asegurar
para hacer comparaciones de un mapeo consistente
la nueva versin generada, entre toda la
con la versin previa del TCB documentacin y el cdigo
en orden a determinar que asociado con las
slo los cambios proyectados versiones actuales del
han sido hechos en el cdigo TCB. Las herramientas
que actualmente se esta debern tenerse para
usando como la nueva generar una nueva versin
versin del TCB del TCB desde el cdigo
fuente. Tambin las
herramientas debern ser
mantenidas bajo un
estricto control de
configuraciones para
comparar una versin
nueva generada desde el
TCB en orden a
determinar que slo los
cambios proyectados han
sido hechos en el cdigo
que actualmente se esta
usando.
47
Distribucin Confiable
La distribucin confiable protege un sistema seguro mientras el sistema es siendo transportado al sitio del cliente. Este requerimiento
solo se tiene para el nivel A1, este requerimiento tiene dos metas proteccin y validacin del lugar
La proteccin significa que el vendedor final (y durante el transporte del vendedor al cliente), se asegura que durante la distribucin,
el sistema llegue al lugar donde lo solicito el cliente, exactamente, como fue evaluado antes de transportarse por el vendedor, ya que
proporciona proteccin durante el empaque, transporte entre intermediarios hasta llegar al usuario final.
Validacin del lugar, significa que el cliente final, con la distribucin confiable puede detectar falsificaciones del sistema o
modificacin del sistema.
C1 C2 B1 B2 B3 A1
Distribucin Confiable
No se requiere No se requiere No se requiere No se requiere No se requiere Un sistema de control
ADP confiable y
facilidad de distribucin
deber ser
proporcionada para
mantener la integridad
del mapeo entre los
datos maestros que
describen la versin
actual del TCB y la
copia maestra en sitio
del cdigo del la
versin actual. Los
procedimientos (Prueba
de aceptacin de la
seguridad del sitio)
deber existir para
asegurar que el
software, firmware y
actualizacin del
hardware del TCB,
distribuido a los clientes
es exactamente como
se especifica en las
copias principales
48
Gua del usuario de caractersticas de seguridad
La gua del usuario de caractersticas de seguridad (SFUG) es un apunte ordinario, sin privilegios para todos los usuarios del
sistema. En el se encuentran cosas que es necesario saber acerca de las caractersticas del sistema de seguridad y de cmo es
que estn reforzadas. Los temas tpicos incluyen
Acceso al sistema seguro. Como se debe introducir el login y el password, con que frecuencia debe de cambiarse, que mensajes
deben de verse, cmo deben de usarse estos mensajes para reforzar la seguridad del sistema
Proteccin de archivos y otro tipo de informacin. Cmo se debe de especificar una lista de control de acceso (o protecciones
similares)
Importar y exportar archivos Como leer nuevos datos dentro del sistema confiable y como escribir datos de otros sistemas sin
arriesgar la seguridad
C1 C2 B1 B2 B3 A1
Gua del usuario de caractersticas de seguridad
Un resumen No se tienen No se tienen No se tienen No se tienen No se tienen
sencillo, captulo requerimientos requerimientos requerimientos requerimientos requerimientos
o manual en la adicionales adicionales adicionales adicionales adicionales
documentacin
del usuario que
describa los
mecanismos de
proteccin
proporcionados
por el TCB,
lineamientos
sobre su uso y
como interactuar
con otros.
49

Este documento es un apunte de administrador del sistema y/o administradores de seguridad. Habla sobre todas las cosas que se
necesita saber acerca de la configuracin del sistema para ser seguro, reforzando el sistema de seguridad, interactuando con
peticiones del usuario y haciendo que el sistema trabaje con las mejores ventajas. El Libro naranja requiere que este documento
contenga advertencias, acerca de las funciones y privilegios que deben ser controlados en sistemas seguros
C1 C2 B1 B2 B3 A1
Un direccionamiento Requerimientos Requerimientos Requerimientos Requerimientos No se tienen
manual por parte del adicionales adicionales adicionales adicionales requerimientos
administrador del Los procedimientos EL manual deber Los mdulos del Se debern incluir los adicionales
sistema ADP deber para examinar y describir las funciones TCBN que contienen procedimientos para
presentar avisos mantener los archivos del operador y del los mecanismos de asegurar que el
sobre sus funciones de auditora as como administrador relativas validacin de sistema es
y privilegios que las estructuras de los a la seguridad, al incluir referencias debern inicialmente arrancado
deber de controlar registros detallados de los cambios de las ser identificables. Los de una modo seguro,
cuando ejecuta una auditora para cada caractersticas de procedimientos para Los procedimientos
instalacin segura tipo de evento auditable seguridad para los una operacin segura debern tambin estar
debe ser proporcionado usuarios. Este deber de un nuevo TCB incluidos en el
proporcionar desde origen, despus compendio de
lineamientos para el de modificarse por operacin del sistema
uso consistente y cualquier mdulo en el de seguridad despus
efectivo de las TCB deber ser de cualquier lapso de
caractersticas de descrito operacin del sistema
proteccin del sistema,
como deber
interactuar, como
generar una nueva
TCB segura y los
procedimientos de
instalacin,
advertencias, y
privilegios que debern
ser controlados para
operar las instalaciones
de una manera segura
50
Pruebas de documentacin
Para el libro naranja, consiste en mostrar como los mecanismos de seguridad fueron probados, y los resultados de los mecanismos
de seguridad con pruebas funcionales.
El tener buena documentacin de pruebas es generalmente sencillo pero voluminoso. Es comn que la documentacin de pruebas
para los sistemas C1 y C2 consista en varios volmenes de descripcin de pruebas y resultados
C1 C2 B1 B2 B3 A1
Documentacin de pruebas
El desarrollador del No se tienen No se tienen Requerimientos No se tienen Requerimientos
sistema deber requerimientos requerimientos adicionales requerimientos adicionales
proporcionar a los adicionales adicionales Se deber incluir los adicionales Los resultados del
evaluadores un resultados de las mapeo ente las
documento que pruebas de falta de especificaciones
describa el plan de efectividad de los formales de alto nivel y
pruebas, mtodos usados para el cdigo fuente del
procedimientos de reducir los anchos de TCB debern ser
prueba que muestren banda de los canales proporcionadas
como los mecanismos secretos
son probados, y los
resultados de las
pruebas funcionales
de los mecanismos de
seguridad
51
Es un requerimiento formidable para todos los desarrolladores de sistemas. La idea de disear documentacin es documentar
internamente el sistema (o lo ms bsico del TCB) hardware, firmware y software. El objetivo del diseo de documentacin es que
la filosofa del fabricante sobre proteccin y... cmo esta filosofa es trasladada dentro del TCB Una tarea clave que define los
lmites del sistema y distingue claramente entre cuales porciones del sistema son relevantemente seguras y cuales no.
Las dos mayores metas del diseo de documentacin son: el probar al equipo de evaluacin que el sistema cumple con el criterio de
evaluacin y el auxiliar al equipo de diseo y desarrollo para ayudar a definir las polticas del sistema de seguridad y como hacer
que las polticas se lleven a cabo durante la implementacin.
C1 C2 B1 B2 B3 A1
La documentacin No se tienen Requerimientos Requerimientos Requerimientos Requerimientos
que proporcione requerimientos adicionales adicionales adicionales adicionales
una descripcin de adicionales Una descripcin formal o Las interfaces entre los La implementacin del La implementacin del
la filosofa del informal del modelo de mdulos del TCB TCB (hardware, TCB deber ser
fabricante sobre las polticas de seguridad debern ser descritos firmware y software) informalmente
proteccin deber reforzado por el TCB El modelos de polticas deber ser mostrada para ser
estar disponible, y deber estar disponible de seguridad deber ser informalmente consistente con la
una explicacin de para dar una explicacin formal y probado. mostrada y ser especificacin formal
cmo esta filosofa de que es suficiente el La especificacin consistente con el de alto nivel (FTLS).
es trasladada reforzar las polticas de descriptiva de alto nivel DTLS. Los elementos Los elementos del
dentro del TCB, s seguridad. El mecanismo (DTLS) deber ser del DTLS debern ser FTLS debern ser
el TCB es de proteccin especfica mostrada en una mostrados, usando mostrados, usando
compuesto por del TCB deber ser descripcin exacta de la tcnicas de tcnicas de
distintos mdulos, identificable y una interfaz del TCB. La informacin, con su informacin, con su
las interfaces entre explicacin que documentacin describir correspondiente correspondiente
estos mdulos demuestre cmo ste como el TCB implementa elemento del TCB elemento del TCB
deber ser descrita mecanismo satisface el el concepto de monitor Los mecanismos de
modelo. de referencia y dar una hardware, firmware y
explicacin de porque es software no
resistente a penetracin, compartidos con el
y no puede ser FTLS pero
traspasado, y es estrictamente internos
correctamente del TCB (mapeo de
implementado. . registros, acceso
52
C1 C2 B1 B2 B3 A1
La documentacin deber directo a memoria de
describir como el TCB se entrada/salida),
estructura para pruebas deber ser claramente
de instalacin y reforzar descrito.
los menores privilegios.
Esta documentacin
deber tambin
presentar los resultados
del anlisis de los
canales secretos y los
intercambios involucrados
al restringir los canales.
Todos los eventos
auditables que pueden
ser usados en la
explotacin de conocer
canales de almacenaje
secretos, debern ser
identificados
53
Glosario
ADP: Automatic Data Processing (Procesamiento automtico de

datos).
Aplicaciones sensitivas: Son todos aquellos programas y

sistemas desarrollados para la administracin de sistemas, como
pueden ser herramientas administracin, configuracin o
seguridad.
DoD: Departament of Defense (Departamento de Defensa de los

Estados Unidos).
Informacin sensitiva: Es toda aquella informacin que no esta

disponible a todos los usuarios por poseer un cierto grado de
confidencialidad.
Elemento activo: Son todos aquellos usuarios o procesos que

poseen la capacidad de crear, modificar, leer, escribir o borrar
informacin.
Etiqueta: son identificadores que se les asignan a los usuarios o

Glosario a los objetos dentro del sistema, se utilizan estos identificadores
para verificar los permisos que tiene el usuario o el objeto para
permitir o denegar las acciones.
Etiqueta Sensitiva de usuario: especfica el grado, o nivel de

confianza, asociado con ese usuario, las etiquetas de usuario
sensitivas es usualmente llamada como certificado de paso
"clearance".
Etiqueta sensitiva de archivo: especifica el nivel de confianza

que un usuario puede ser capaz de tener al tener acceso a ese
archivo.
Evento: Son todas las acciones generadas por un usuario o un

proceso que van a exigir una respuesta por parte de un objeto.
Firmware: Se define como hardware en software, es decir

memorias ROM que contienen instrucciones o datos necesarios
para el sistema, un ejemplo son los BIOS de la mayoria de las
computadoras.
Nivel de sensitividad: Es cuando toda la informacin

almacenada o todos los usuarios que tienen acceso a esa
informacin poseen exactamente los mismos permisos.
54
Objeto: Son todos los elementos identificables dentro del

sistema, cmomo son directorios, archivos, dispositivos, puertos,
etc.
TCB: Trusted Computers Bases (Computadora Confiable Base).
Bibliografa
URL: http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-
STD.html
Computer Security Basics,

Deborah Russell and G.T. Gangemi Sr.
Bibliografa OReilly & Associates, Inc.
55

Libro Naranja PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Naranja PDF

Cargado por

Copyright:

Formatos disponibles

Vista General del Libro

Direccin General de Servicios de Cmputo Acadmico Subdireccin de Sistemas

VISTA GENERAL DEL LIBRO NARANJA

III. REQUISITOS FUNDAMENTALES DE LA SEGURIDAD EN COMPUTO

IV. CUL ES EL PROPOSITO DEL LIBRO NARANJA?

VI. C- PROTECCIN DISCERCIONAL

1. C1- Proteccin de seguridad discrecional

2. C2- Proteccin de acceso controlado

VII. B- PROTECCIN OBLIGATORIA

1. B1- Proteccin de Seguridad por Etiquetas

2. B2- Proteccin Estructurada

3. B3- Proteccin por dominios

VIII. A- PROTECCIN VERIFICADA

1. A1- Diseo Verificado

IX. EVALUACIN DE CLASES Y EJEMPLO DE SISTEMAS

X. EL CONTROL DE ACCESO DISCRECIONAL

XI. REUTILIZACIN DE OBJETOS

XIII. INTEGRIDAD DE ETIQUETAS

XIV. EXPORTACIN DE INFORMACIN ETIQUETADA

XV. EXPORTACIN EN DISPOSITIVOS MULTINIVEL

XVI. EXPORTACIN EN DISPOSITIVOS DE NIVEL NICO

XVII. ETIQUETAS DE SALIDAS LEGIBLES A LA PERSONA

XVIII. ETIQUETAS SENSITIVAS DE EVENTOS

XIX. DIISPOSITIVOS ETIQUETADOS

XX. CONTROL DE ACCESO OBLIGATORIO

XXI. IDENTIFICACIN Y AUTENTIFICACIN

XXII. RUTAS SEGURAS

XXIV. ARQUITECTURA DEL SISTEMA

XXV. INTEGRIDAD DEL SISTEMA

XXVI. ANLISIS DE CANALES SECRETOS

XXVII. FCILIDAD DE ADMINISTRACIN DE LA SEGURIDAD

XXVIII. RECUPERACIN CONFIABLE

XXIX. DISEO DE ESPECIFICACIONES Y VERIFICACIN

XXX. PRUEBAS DE SEGURIDAD

XXXI. ADMINISTRACIN DE CONFIGURACIN

XXXII. DISTRIBUCIN CONFIABLE

XXXIII. GUA DEL USUARIO DE CARACTERSTICAS DE SEGURIDAD

XXXIV.FCILIDADES DEL MANUAL DE SEGURIDAD

XXXV. PRUEBAS DE DOCUMENTACIN

La necesidad de evaluar la seguridad, o de tener una medicin confiable,

El documento original puede ser consultado en lnea en la direccin:

El Libro Naranja es consecuencia de la creciente conciencia de la

Cada divisin consiste en una o ms clases numeradas, entre ms

La divisin C contiene dos distintas clases C1 y C2 (de acuerdo a la

Cada clase se define con un grupo especfico de criterios que un

Cualquier discusin sobre seguridad en cmputo necesariamente

En general, un sistema seguro controlar, a travs del uso de

Requisito 1 - POLTICA DE SEGURIDAD - Debe existir una poltica de

Los sistemas informticos de inters deben hacer cumplir una poltica

Requisito 2 - MARCAS - El control de acceso por etiquetas debe de estar

Requisito 4 - RESPONSABILIDAD - Las auditorias de la informacin

Requisito 5 - ASEGURAMIENTO - el sistema informtico debe contener

Requisito 6 - PROTECCIN CONTINUA - los mecanismos de seguridad

Cual es el propsito del libro naranja

De acuerdo con el texto mismo, el criterio de evaluacin se desarrolla

El proveer a los usuarios con un criterio con el cual se evale la

Ms que una especificacin de requerimientos de seguridad, y tener

Las categoras de seguridad del DoD van desde D (Proteccin Mnima)

A continuacin se presenta un breve resumen las caractersticas de

Cualquier sistema que no cumple con cualquier otra categora, o ha

Las clases en esta divisin proporcionan una Proteccin discrecional

La proteccin discrecional se aplica a una Base de Computadoras

1. C1- Proteccin de Seguridad discrecional.