Orangeb - PDF - Desconocido

Table of Contents
Inicio
Contenido
I. Antes de Comenzar
II. Introduccin
III. Requisitos Fundamentales de la
1. Polticas de Seguridad.
2. Responsabilidad
3. Confianza
2. Responsabilidad
3. Confianza
IV. Cual es el propsito del libro naranja?
1. Medicin
2. Direccin
3. Adquisicin
1. Medicin
2. Direccin
3. Adquisicin
V. D- Proteccin Mnima.
VI. C- Proteccin discrecional.
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
2. A2 en adelante
2. A2 en adelante
XIX. Evaluacin de clases y ejemplo de
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. Etiquetado de salidas legibles a la persona
XVIII. Etiquetas sensitivas de eventos
XIX. Dispositivos etiquetados
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. Facilidad 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. Facilidades del manual de seguridad
XXXV. Pruebas de documentacin
XXXVI. Diseo de documentacin
XXXVII. Glosario
XXXVIII. Bibliografa
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
Vista General del Libro Naranja
VII. B- PROTECCIN OBLIGATORIA
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

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
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
Y obtenerse en las siguientes versiones:
comenzar
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:
Proteccin Mnima
Proteccin Discrecional
Proteccin Obligatoria
Proteccin Controlada
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.
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.

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).
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.).

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.
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 Obligatori a.
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.
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
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
Notificaci n 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.
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.
Los siguientes son requisitos mnimos para los sistemas con asignacin Proteccin
de un grado de clase B3:
Obligatoria
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
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 existen las herramientas de verificacin) y
las informales de otra Proteccin
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
Proteccin Mnima
D
Sistemas operativos bsicos: MS-DOS
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
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
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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja Exportacin de informacin etiquetada
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
Exportacin de informacin etiquetada
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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja Etiquetas sensitivas de eventos
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
Etiquetas sensitivas de eventos
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
Vista General del Libro Naranja 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
Vista General del Libro Naranja Control de acceso obligatorio
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
Control de acceso obligatorio
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
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
Vista General del Libro Naranja Identificacin y autentificacin
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
Identificacin y autentificacin
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
Vista General del Libro Naranja 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
Requerimientos
No se tienen
una ruta segura de
adicionales
requerimientos
comunicaciones entre
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
Vista General del Libro Naranja 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
C2
B1
B2
B3
A1
Auditora
No se requiere
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 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
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
Vista General del Libro Naranja Arquitectura del sistema
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
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
Vista General del Libro Naranja Integridad del sistema
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
Integridad del sistema
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
Vista General del Libro Naranja Anlisis de canales secretos
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
Anlisis de canales secretos

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
Vista General del Libro Naranja Facilidad de administracin de la seguridad
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
Facilidad de administracin de la seguridad
No se requiere
No se requiere
No se requiere

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
Vista General del Libro Naranja Recuperacin confiable
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
Recuperacin confiable
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
Vista General del Libro Naranja Diseo de especificaciones y verificacin
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
Diseo de especificaciones y verificacin
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
Vista General del Libro Naranja Pruebas de seguridad
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
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
Vista General del Libro Naranja Administracin de configuracin

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
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
Vista General del Libro Naranja 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
Vista General del Libro Naranja 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
Vista General del Libro Naranja Facilidades del manual de seguridad
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
Facilidades del manual de seguridad
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
Vista General del Libro Naranja 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
Vista General del Libro Naranja Diseo de documentacin
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
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
Document Outline
Inicio
Contenido
I. Antes de Comenzar
II. Introduccin
III. Requisitos Fundamentales de la
o 1. Polticas de Seguridad.
o 2. Responsabilidad
o 3. Confianza
IV. Cual es el propsito del libro naranja?
o 1. Medicin
o 2. Direccin
o 3. Adquisicin
V. D- Proteccin Mnima.
VI. C- Proteccin discrecional.
o 1. C1- Proteccin de Seguridad discrecional.
o 2. C2- Proteccin de Acceso Controlado.
VII. B- Proteccin Obligatoria.
o 1. B1- Proteccin de Seguridad por Etiquetas
o 2. B2- Proteccin Estructurada
o 3. B3- Proteccin por Dominios
VIII. A- Proteccin Verificada
o 1. A1- Diseo verificado
o 2. A2 en adelante
XIX. Evaluacin de clases y ejemplo de
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. Etiquetado de salidas legibles a la persona
XVIII. Etiquetas sensitivas de eventos
XIX. Dispositivos etiquetados
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. Facilidad 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. Facilidades del manual de seguridad
XXXV. Pruebas de documentacin
XXXVI. Diseo de documentacin
XXXVII. Glosario
XXXVIII. Bibliografa

Orangeb - PDF - Desconocido

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

Orangeb - PDF - Desconocido

Cargado por

Copyright:

Formatos disponibles

Table of Contents

III. Requisitos Fundamentales de la

IV. Cual es el propsito del libro naranja?

VI. C- Proteccin discrecional.

1. C1- Proteccin de Seguridad discrecional.

2. C2- Proteccin de Acceso Controlado.

1. C1- Proteccin de Seguridad discrecional.

VII. B- Proteccin Obligatoria.

1. B1- Proteccin de Seguridad por Etiquetas

2. B2- Proteccin Estructurada

3. B3- Proteccin por Dominios

1. B1- Proteccin de Seguridad por Etiquetas

2. B2- Proteccin Estructurada

3. B3- Proteccin por Dominios

VIII. A- Proteccin Verificada

1. A1- Diseo verificado

1. A1- Diseo verificado

XIX. Evaluacin de clases y ejemplo de

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. Etiquetado de salidas legibles a la persona

XVIII. Etiquetas sensitivas de eventos

XIX. Dispositivos etiquetados

XX. Control de acceso obligatorio

XXII. Rutas Seguras

XXIV. Arquitectura del sistema

XXV. Integridad del sistema

XXVI. Anlisis de canales secretos

XXVII. Facilidad 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. Facilidades del manual de seguridad

XXXV. Pruebas de documentacin

XXXVI. Diseo de documentacin

Direccin General de Servicios de Cmputo Acadmico

Vista General del Libro Naranja Contenido

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

Vista General del Libro Naranja

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