Orange Book

Subdirección de Sistemas1

Dirección General de Servicios de Cómputo Académico Dirección General de Servicios de Cómputo Académico Subdirección de Sistemas Subdirección de Sistemas Dirección de Sistema Dirección de Sistema

Marzo, 2000Marzo, 2000

Elaborado por:Elaborado por:Departamento de Control deDepartamento de Control de

Calidad y Auditoría InformáticaCalidad y Auditoría Informática

Vista General del Libro NaranjaVista General del Libro Naranja(Orange Book)(Orange Book)

Subdirección de Sistemas

2

ContenidoContenido

Vista General del Libro Naranja (Orange Book)Vista General del Libro Naranja (Orange Book)

IntroducciónIntroducción

Requisitos Fundamentales de la Seguridad en CómputoRequisitos Fundamentales de la Seguridad en CómputoPolíticas de Seguridad.Políticas de Seguridad.ResponsabilidadResponsabilidadConfianzaConfianza

Cual es el Propósito del Libro Naranja.Cual es el Propósito del Libro Naranja.MediciónMediciónDirecciónDirecciónAdquisiciónAdquisición

D- Protección MínimaD- Protección Mínima

C- Protección Discrecional.C- Protección Discrecional.C1- Protección de Seguridad discrecional.C1- Protección de Seguridad discrecional.C2- Protección de Acceso ControladoC2- Protección de Acceso Controlado

B- Protección Obligatoria.B- Protección Obligatoria.B1- Protección de Seguridad por EtiquetasB1- Protección de Seguridad por EtiquetasB2- Protección EstructuradaB2- Protección EstructuradaB3- Protección por DominiosB3- Protección por Dominios

Protección VerificadaProtección VerificadaA1- Diseño verificadoA1- Diseño verificadoA2- En AdelanteA2- En Adelante

Evaluación de Clases y Ejemplo de SistemasEvaluación de Clases y Ejemplo de Sistemas

Control de Acceso DiscrecionalControl de Acceso Discrecional

Reutilización de ObjetosReutilización de Objetos

EtiquetasEtiquetas

Integridad de EtiquetasIntegridad de Etiquetas

Exportación de Información EtiquetadaExportación de Información Etiquetada

Exportación en Dispositivos MultinivelExportación en Dispositivos Multinivel



3

Exportación en Dispositivos de Nivel ÚnicoExportación en Dispositivos de Nivel Único

Etiquetado de Salidas Legibles a la PersonaEtiquetado de Salidas Legibles a la Persona

Etiquetas Sensitivas de EventosEtiquetas Sensitivas de Eventos

Dispositivos EtiquetadosDispositivos Etiquetados

Control de Acceso ObligatorioControl de Acceso Obligatorio

Identificación y AutentificaciónIdentificación y Autentificación

Rutas SegurasRutas Seguras

AuditoríaAuditoría

Arquitectura del SistemaArquitectura del Sistema

Integridad del SistemaIntegridad del Sistema

Análisis de Canales SecretosAnálisis de Canales Secretos

Facilidad de Administración de la SeguridadFacilidad de Administración de la Seguridad

Recuperación ConfiableRecuperación Confiable

Diseño de Especificaciones y VerificaciónDiseño de Especificaciones y Verificación

Pruebas de SeguridadPruebas de Seguridad

Administración de ConfiguraciónAdministración de Configuración

Distribución ConfiableDistribución Confiable

Guía del Usuario de Características de SeguridadGuía del Usuario de Características de Seguridad

Facilidades del Manual de SeguridadFacilidades del Manual de Seguridad

Pruebas de DocumentaciónPruebas de Documentación

Documentación de PruebasDocumentación de Pruebas

Diseño de DocumentaciónDiseño de Documentación

Glosario de Términos.Glosario de Términos.

BibliografiaBibliografia



4


Antes de entrar a fondo con el tema de seguridad, hay que tomar encuenta que existen diferentes organizaciones, con diferentes tipos deinformación y por lo tanto con distintos requerimientos de seguridad.

La necesidad de evaluar la seguridad, o de tener una mediciónconfiable, es el motivo principal al desarrollar este documento por elgobierno de los E.E. U.U.

El documento original puede ser consultado en línea en la dirección:

http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.htmlhttp://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html

Y obtenerse en las siguientes versiones:Versión Texto ASCII (txt)Versión Postscript (ps)Formato Adobe Portable Document (pdf)Versión Gzipped Postscript en la dirección:

http://www.radium.ncsc.mil/tpep/library/rainbow/http://www.radium.ncsc.mil/tpep/library/rainbow/

IntroducciónIntroducción

El Libro Naranja es consecuencia de la creciente conciencia de laseguridad por parte el gobierno de los Estados Unidos y de la industria,ambos con la creciente necesidad de estandarizar el propósito y el usode las computadoras por el gobierno federal.

El Libro Naranja define cuatro extensas divisiones jerárquicas deseguridad para la protección de la información. En orden creciente deconfiabilidad se tienen:

D Protección MínimaC Protección DiscrecionalB Protección ObligatoriaA Protección Controlada



5

Cada división consiste en una o más clases numeradas, entre másgrande sea el número se indica un mayor grado de seguridad.

La división C contiene dos distintas clases C1 y C2 (de acuerdo a lanomenclatura adoptada: C2 ofrece una mayor seguridad que C1)La división B contiene 3 clases B1, B2 y B3 (B3 ofrece mayor seguridadque B2, y B2 ofrece más seguridad que B1).La división A cuenta con solo una clase A1.

Cada clase se define con un grupo específico de criterios que unsistema debe cubrir, para ser certificado con la evaluación en algunaclase. Este criterio cae en 4 categorías generales: Políticas deseguridad, Responsabilidad, Confianza y Documentación.

Requisitos Fundamentales de la SeguridadRequisitos Fundamentales de la Seguridaden Cómputoen Cómputo

Cualquier discusión sobre seguridad en cómputo necesariamenteempieza con una definición de sus requisitos básicos, es decir,realmente qué significa el llamar a un sistema informático "seguro".

En general, un sistema seguro controlará, a través del uso decaracterísticas específicas de seguridad, el acceso a la información, deforma tal, que solamente los individuos autorizados correctamente, o losprocesos que obtienen los permisos adecuados, tendrán acceso paraleer, escribir, crear, modificar o eliminar la información.

Se tienen seis requisitos fundamentales, los cuales se derivan de estadeclaración básica; cuatro de ellos parten de la necesidad deproporcionar un control de acceso a la información y los dos restantesde cómo puede obtenerse una seguridad demostrable, logrando así unsistema informático confiable.

Políticas de SeguridadPolíticas de Seguridad.

Requisito 1 - POLÍTICA DE SEGURIDAD - Debe existir una política deseguridad explícita y bien definida reforzada por el sistema.Identificados los eventos y los objetos, debe haber un conjunto dereglas que son utilizadas por el sistema para determinar si un eventodado se puede permitir para acceder a un objeto específico.

Requisito 1Requisito 1



6

Los sistemas informáticos de interés deben hacer cumplir una políticaobligatoria de seguridad, en la cual puedan implementarseeficientemente reglas del acceso para manejo de información sensitiva(p.e. clasificaciones) estas reglas deben de incluir requisitos talescomo: Ninguna persona que carezca de los permisos apropiadosobtendrá el acceso a la información clasificada. Además, los controlesde seguridad discrecional se requieren para asegurar que solamente losusuarios o los grupos seleccionados de usuarios puedan obtener elacceso a los datos.(p.e., basarse en una necesidad de conocimientosespecíficos).

Requisito 2 - MARCAS - El control de acceso por etiquetas debe deestar asociado a los objetos. Para controlar el acceso a la informaciónalmacenada en una computadora, según las reglas de una políticaobligada de seguridad, debe de ser posible el marcar cada objeto conuno una etiqueta que identifique confiablemente el nivel de lasensibilidad del objeto (p.e., clasificación), y/o los modos de obteneracceso y acordar quien puede tener acceso potencial al objeto.

ResponsabilidadResponsabilidad

Requisito 3 - IDENTIFICACIÓN - los eventos individuales deben de seridentificados. Cada acceso a la información debe ser registradoteniendo como base quién está teniendo acceso a la información y quéautorización posee para ocupar cierta clase de información. Lainformación de la identificación y la autorización debe ser administradacon seguridad por el sistema informático y asociar cierta seguridad acada elemento activo que realice una cierta acción relevante en elsistema.

Requisito 4 - RESPONSABILIDAD - Las auditorias de la informacióndeben ser selectivamente guardadas y protegidas de las acciones quepuedan afectar la seguridad y de testa forma poder rastrear alresponsable. Un sistema confiable debe tener la capacidad de registrarla ocurrencia de acontecimientos relevantes sobre seguridad en unabitacora auditable. Además de poseer la capacidad de seleccionar loseventos a auditar para ser registrados, es necesario para reducir almínimo el costo de la revisión y permitir un análisis eficiente. Este tipode registros o bitácoras, deben de estar protegidos contra lamodificación y la destrucción no autorizada, y deben permitir ladetección y la investigación posterior de las violaciones de seguridad.






7

ConfianzaConfianzaRequisito 5 - ASEGURAMIENTO - el sistema informático debe contenerlos mecanismos de hardware/software que puedan ser evaluadosindependientemente para proporcionar una seguridad suficiente que elsistema haga cumplir los requisitos 1 a 4 mencionados anteriormente.Para asegurar que los requisitos de política de seguridad, marcas,identificación, y responsabilidad de la seguridad son hechos cumplir porun sistema de cómputo, deben ser identificados como una colecciónunificada de hardware y software que controle y ejecute esasfunciones. Estos mecanismos son típicamente incluidos en el sistemaoperativo y se diseñan para realizar las tareas asignadas de unamanera segura. La base para confiar en tales mecanismos del sistemaoperativo, radica en su configuración operacional, la cual debe serclaramente documentada a fin de hacer posible el examinarindependientemente los eventos para su evaluación.

Requisito 6 - PROTECCIÓN CONTINUA - los mecanismos de seguridadque hacen cumplir estos requisitos básicos, se deben de protegercontinuamente contra cambios no autorizados o modificaciones quetraten de alterarlos. Ningún sistema de cómputo puede ser consideradoverdaderamente seguro si los mecanismos que hacen cumplir laspolíticas de seguridad, están sujetos a modificaciones no autorizadas. Elrequisito de protección continua tiene implicaciones directas a través delciclo de vida de los sistemas.

Cuál es el Propósito del Libro Naranja.Cuál es el Propósito del Libro Naranja.

De acuerdo con el texto mismo, el criterio de evaluación se desarrollacon 3 objetivos básicos:

Para proporcionar de elementos cuantificables al Departamento deDefensa (DoD) con los cuales poder evaluar el grado de confianza quese puede tener en los sistemas informáticos seguros, para el proceso declasificación de información sensitiva.

El proveer a los usuarios con un criterio con el cual se evalúe laconfianza que se puede tener en un sistema de cómputo para elprocesamiento de la seguridad o clasificación de información sensitiva.Por ejemplo, un usuario puede confiar que un sistema B2 es másseguro que un sistema C2.



MediciónMedición



8

Para proporcionar un estándar a los fabricantes en cuanto a lascaracterísticas de seguridad que deben de implementar en susproductos nuevos y planearla con anticipación, para aplicarla en susproductos comerciales y así ofrecer sistemas que satisfacen requisitosde seguridad (con énfasis determinado en la prevención del acceso dedatos) para las aplicaciones sensitivas.

AdquisiciónEl proporcionar las bases para especificar los requerimientos deseguridad en adquisiciones determinadas.

Más que una especificación de requerimientos de seguridad, y tenervendedores que respondan con una gama de piezas. El libro naranjaproporciona una vía clara de especificaciones en un juego coordinadode funciones de seguridad. Un cliente puede estar seguro que elsistema que va a adquirir fue realmente verificado para los distintosgrados de seguridad.

Las categorías de seguridad del DoD van desde D (Protección Mínima)hasta A (Protección Verificada).

A continuación se presenta un breve resumen las características decada una de estas categorías y los niveles que tiene cada una.

D- Protección MínimaD- Protección Mínima

Esta división contiene solamente una clase. Esta reservada para lossistemas que han sido evaluados que pero que no pueden cumplir losrequisitos para una clase más alta de la evaluación.

Cualquier sistema que no cumple con cualquier otra categoría, o hadejado de recibir una clasificación más alta. El sistema DOS para PCsse cae en esta categoría.

C- Protección DiscrecionalC- Protección DiscrecionalLas clases en esta división proporcionan una Protección discrecional(necesidad – de - identificación) y, a través de inclusión de capacidadesde auditoria, exige la responsabilidad de los usuarios de las accionesque realiza.

DirecciónDirección

AdquisiciónAdquisición



9

La protección discrecional se aplica a una Base de ComputadorasConfiables (TCB) con protección de objetos optativos (p.e. archivo,directorio, dispositivos, etc.).

C1- Protección de Seguridad discrecionalC1- Protección de Seguridad discrecional..

Las TCB de un sistema de la clase C1, deben cubrir los requisitos deseguridad discrecional proporcionando la separación de usuarios y dedatos. Incorporar algún mecanismo de control y acreditación, así comola capacidad de hacer cumplir las restricciones de acceso de una baseindividual, es decir, garantizar de una forma convincente a los usuariosde que sus proyectos o información privada esta protegida y evitar queotros usuarios accidentalmente puedan leer o destruir sus datos. Sesupone que en el ambiente de la clase C1 existe cooperación entre losusuarios y además todos ellos procesan datos en el mismo nivel(es) desensitividad.Los requisitos mínimos para los sistemas con asignación de la clase C1son:

• Protección de archivos optativa, por ejemplo Control de Listas deAcceso (ACLs), Protección a Usuario/ Grupo/Público.

• Usualmente para usuarios que están todos en el mismo nivel deseguridad.

• Protección de la contraseña y banco de datos seguro deautorizaciones (ADB).

• Protección del modo de operación del sistema.• Verificación de Integridad del TCB.• Documentación de Seguridad del Usuario.• Documentación de Seguridad del Administración de Sistemas.• Documentación para Comprobación de la Seguridad.• Diseño de documentación de TCB.• Típicamente para usuarios en el mismo nivel de seguridad.Ejemplo de estos sistemas son las primeras versiones de

C2- Protección de Acceso ControladoC2- Protección de Acceso Controlado..

Los sistemas en esta clase hacen cumplir más fielmente un control deacceso discrecional más fino que los sistemas C1, haciendoresponsable individualmente a los usuarios de sus acciones a través deprocedimientos de conexión, revisión de eventos relevantes deseguridad, y el aislamiento de recursos.

Los siguientes son requisitos mínimos para los sistemas con asignaciónde clase (C2):

C1C1

C2C2



10

• La protección de objetos puede estar con base al usuario, ej. De unACL o una base de datos del administrador.

• La autorización para accesar sólo puede ser asignada por usuariosautorizados.

• Protección de reuso de objetos (p.e. para evitar reasignación depermisos de seguridad de objetos borrados).

• Identificación obligatoria y procedimientos de autorización para losusuarios, p.e. contraseñas.

• Auditoria de eventos de seguridad.• Protección del modo de operación del sistema.• Agrega protección para autorizaciones y auditoría de datos.• Documentación de la información como C1 plus al examinar la

auditoría de la información.

Algunos sistemas típicos son versiones posteriores de Unix, VMS.

B- Protección ObligatoriaB- Protección Obligatoria

La división B especifica que el sistema de protección del TCB debe serobligatorio, no solo discrecional.

La noción de un TCB que preserve la integridad de etiquetas desensibilidad de la información y se utilizan para hacer cumplir unconjunto de reglas obligatorias del control de acceso, es un requisitoimportante en esta división. Los sistemas en esta división deben llevarlas etiquetas de sensibilidad en las estructuras de datos importantes delsistema. El desarrollador del sistema también debe proporcionar unmodelo de política de seguridad en el cual se basa el TCB y equiparpor medio de una serie de especificaciones al TCB. Evidentementedebe ser proporcionada una demostración que sirva para aclarar elconcepto del monitor de referencia y su forma de implementarlo.

B1- Protección de Seguridad por EtiquetasB1- Protección de Seguridad por Etiquetas

Los sistemas de la clase B1 requieren todas las característicassolicitadas para la clase C2. Además una declaración informal delmodelo de la política de seguridad, de las etiquetas de los datos, y delcontrol de acceso obligatorio sobre los eventos y objetos nombradosdebe estar presente. Debe existir la capacidad para etiquetarexactamente la información exportada. Cualquier defecto identificado alhacer las pruebas debe ser eliminado.

Los siguientes son los requisitos mínimos para los sistemas conasignaron de grado de la clase B1:

B1B1



11

• Seguridad obligatoria y acceso por etiquetas a todos los objetos, ej.archivos, procesos, dispositivos, etc.

• Verificación 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.).

B2- Protección EstructuradaB2- Protección Estructurada

En los sistemas de clase B2, los TCB deben estar basados en unadocumentación formal clara y contar con un modelo de política deseguridad bien definido que requiera un control de acceso discrecionaly obligatorio, las imposiciones a los sistemas encontradas en la claseB1, se deben extender a todos los eventos y objetos en sistemas ADP.Además, los canales secretos son direccionados. El TCB se debe estarcuidadosamente estructurado en elementos de protección críticos yelementos de protección no críticos. La interfaz de TCB deberá estarbien definida así como el diseño y la activación de la implementación delTCB le permiten ser sujeto de prueba y revisión más completa. Seconsolidan los mecanismos de autentificación, el manejo de recursosseguros se proporciona en forma de ayuda para las funciones deladministrador y del operador del sistema, y se imponen controlesrigurosos de la administración de configuración. El sistema esrelativamente resistente a la penetración.Los siguientes son requisitos mínimos para los sistemas con asignaciónde grado de la clase B2:

• Notificación de cambios del nivel de seguridad que afecteninteractivamente a los usuarios.

• Etiquetas de dispositivos jerárquicas.• 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 operación del sistema más firme en multinivel en unidades

independientes.• Análisis de canales seguros.• Comprobación de la seguridad mejorada.• Modelos formales de TCB.• Versión, actualización y análisis de parches y auditoria.Un ejemplo de estos sistemas operativos es el Honeywell Multics.

B2B2



12

B3- Protección por DominiosB3- Protección por Dominios

En la clase B3 los TCB debe satisfacer los requisitos de herramientasde monitoreo como un “monitor de referencia” que Interviene en todoslos accesos de usuarios a los objetos, a fin de ser comprobada, y quesea lo bastante pequeña para ser sujeta al análisis y pruebas. Al final, elTCB debe estar estructurado para excluir el código no esencial paraaplicar la política de seguridad, mediante ingeniería de sistemas duranteel diseño y la implementación del TCB, orientada hacia la reducción desu complejidad al mínimo.

Debe de contar también con un Administrador de Seguridad, losmecanismos de auditoria se amplían para señalar acontecimientosrelevantes de la seguridad, y se necesitan procedimientos derecuperación del sistema. El sistema es altamente resistente a lapenetración.Los siguientes son requisitos mínimos para los sistemas con asignaciónde un grado de clase B3:

§ ACL’s adicionales basado en grupos e identificadores.§ Rutas de acceso confiables y autentificación.§ Análisis automático de la seguridad.§ Modelos más formales de TCB.§ Auditoría de eventos de seguridad.§ Recuperación confiable después de baja del sistema y

documentación relevante.§ Cero defectos del diseño del TCB, y mínima ejecución de errores.

Protección VerificadaProtección Verificada

Esta división se caracteriza por el uso de métodos formales para laverificación de seguridad y así garantizar que los controles de seguridadobligatoria y discrecional empleados en el sistema pueden proteger coneficacia la información clasificada o sensitiva almacenada o procesadapor el sistema. Se requiere de amplia documentación para demostrarque el TCB resuelve los requisitos de seguridad en todos los aspectosdel diseño, desarrollo e implementación.

Se deben de cubrir todos los requisitos de B3 más otros criteriosadicionales:

B3B3



13

Los sistemas en la clase (A1) son funcionalmente equivalentes a los dela clase B3 en que no se agrega ningunas características o requisitosarquitectónicos adicionales de la política de seguridad. La característicaque distingue los sistemas en esta clase es el análisis derivado detécnicas formales de especificación y la verificación del diseño, y el altogrado de confiabilidad que resulta de la correcta implementación delTCB. Este garantia se desarrolla naturalmente, comenzando con unmodelo formal de la política de la seguridad y una especificación formalde alto nivel (FTLS Especificación Normal de Alto Nivel) del diseño.Independiente del lenguaje determinado de la especificación o sistemade la verificación usado, hay cinco criterios importantes para laverificación del diseño de la clase (A1).

• Un modelo formal de la política de seguridad debe ser claramenteidentificado y documentar, incluyendo una prueba matemática que elmodelo es constante con sus axiomas y es suficiente para soportarla política de la seguridad.

• Un FTLS debe ser proporcionado que incluya las definicionesabstractas de las funciones que el TCB se realiza y de losmecanismos de la dotación física y/o de los firmwares que se utilizanpara utilizar dominios separados de la ejecución.

• Se debe demostrar que el FTLS del TCB es constante y consistentecon el modelo por técnicas formales en lo posible (es decir, dondeexisten las herramientas de verificación) y las informales de otramanera.

• La implementación del TCB (p.e., en Hardware, firmware, ysoftware) debe mostrar informalmente que es consistente con elFTLS. Los elementos del FTLS deben ser mostrados, usandotécnicas informales, que correspondan a los elementos del TCB. ElFTLS debe expresar un mecanismo unificado de protección,necesario para satisfacer la política de seguridad, y todos loselementos de este mecanismo de protección deben estar asociadosa los elementos del TCB.

• Deben de utilizarse técnicas de análisis formal para identificar yanalizar los canales secretos. Las técnicas informales se puedenutilizar para identificar los canales secretos de sincronización. Lacontinua existencia de canales secretos identificados en el sistemadebe ser justificada.

A2 en adelanteA2 en adelanteLa Propuesta hecha para los más altos niveles de seguridad sedenomina como A2, aunque sus requerimientos aun no han sidodefinidos formalmente.

A1- DiseñoA1- Diseñoverificadoverificado



14

Evaluación de Clases y Ejemplo deEvaluación de Clases y Ejemplo deSistemasSistemas

En la siguiente tabla se resumen los niveles de seguridad establecidospor el Libro naranja, las clases que los integran, el nombre que recibecada una de estas clases así como ejemplo de algunos de los sistemashan logrado ese grado.

NivelNivel ClaseClase NombreNombre EjemploEjemplo

DD Protección MínimaProtección Mínima

D Sistemas operativos básicos: MS-DOS

CC Protección DiscrecionalProtección Discrecional

C1 Protección de Seguridaddiscrecional

IBM MVS/RACFCualquier versión de UNIX ordinaria, que no hasido enviada a una evaluación formal

C2 Protección de AccesoControlado

Computer Associates International: ACF/2/MVSDigital Equipment Corporation: VAX/VMS 4.3HP MPE V/E

BB Protección ObligatoriaProtección Obligatoria

B1 Protección de seguridadpor etiquetas

AT&T System V/MLSUNISIS OS 1100SecuryWare: CMW+IBM MVS/ESA

B2 Protección Estructurada Honeywell Information System: MulticsTrusted Information System XENIX

B3 Protección por Dominios Honeywell Federal System XTS-200

AA Protección VerificadaProtección Verificada

A1 Diseño verificado Honeywell Information System SCOMPBoeing Aerospace : SNS



15

La figura siguiente compara las clases de evaluación del libro naranja,mostrando las características requeridas para cada clase y en términosgenerales, como se incrementan los requerimientos de clase a clase.Adicionalmente se presentan cuadros comparativos de cada criterio aevaluar y los cambios más importantes que se necesitan para pasar deun nivel de seguridad u otro.

C1 C2 B1 B2 B3 A1

Políticas de seguridadPolíticas de seguridad

Control de acceso discrecionalReutilización de ObjetosEtiquetasIntegridad de EtiquetasExportación de información etiquetadaExportación de Dispositivos multinivel.Exportación de Dispositivos de nivel únicoEtiquetado de salidas legibles a la personaEtiquetas sensitivas de eventosDispositivos etiquetadosControl de acceso obligatorio

ResponsabilidadResponsabilidad

Identificación y autentificaciónRutas segurasAuditoria

ConfianzaConfianza

Arquitectura del sistemaIntegridad del sistemaPruebas de seguridadDiseño de especificaciones y verificaciónAnálisis de canales secretosFacilidad de administración de la seguridadAdministración de configuraciónRecuperación confiableDistribución confiable

DocumentaciónDocumentación

Guía del usuario sobre características de seguridadFacilidades del manual de seguridadPruebas de documentaciónDiseño de documentación

C1 C2 B1 B2 B3 A1



16

Significado de los clavesNo requerido para esta clase.Requerimiento nuevo o mejorado para esta claseNo se tienen requerimientos adicionales para esta clase

Control de Acceso DiscrecionalControl de Acceso Discrecional

El Control de Acceso Discrecional (DAC) es un método de restringir elacceso a los archivos (y a otros objetos del sistema) basándose en laidentidad de los usuarios y/o los grupos a los que pertenecen. EL DACes el más común de los mecanismos de control de acceso que seencuentra en los sistemas


C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Control de acceso discrecionalControl de acceso discrecional

La TCB deberádefinirse y controlarel acceso entreusuarios registradosy objetos registrados(por ejemplo,archivos yprogramas). En elsistema ADPEl mecanismo deejecución (porejemplo controles deusuario / grupo /publico, control delistas de acceso)deberá permitirse alos usuarios elespecificar ycontrolar elcompartir ciertosobjetos a individuosregistrados o gruposdefinidos o ambos.

RequerimientosRequerimientosadicionalesadicionalesDefinición de gruposmásespecíficamenteEl mecanismo deejecución debeproporcionarcontroles para limitarla propagación depermisos de accesoEl mecanismo decontrol de accesodiscrecional deberáPermitir ya sea unaacción de un usuarioexplícito o undefault, proporcionaque los objetos seanprotegidos deaccesos noautorizados.Este control deacceso debe sercapaz de incluir oexcluir el acceso deusuarios.El permiso deacceso de un objetopara usuarios queya no poseen elpermiso de accesodeberá ser asignadosólo por los usuariosautorizados

No se tienenrequerimientosadicionales


RequerimientosRequerimientosadicionalesadicionalesEl mecanismo deejecución debe deser accesadomediante listas decontrolEl control de accesodebe ser capaz deespecificar a cadaobjeto registrado,una lista de nombresde personas con susrespectivos modosde acceso a eseobjeto. Además,para cada uno delos objetosregistrados, de serposible especificaruna lista de losindividuosregistrados y unalista de los grupos opersonasregistradas conacceso denegadodel grupo,




Reutilización de ObjetosReutilización de Objetos

La reutilización de Objetos requiere la protección de archivos, memoria y otros objetosen un sistema auditado de ser accesadas accidentalmente por usuarios que no tienenacceso autorizado a ellos. Las características de control de acceso de u sistemaordinario determina quien puede y quien no puede accesar archivos, dispositivos yotros objetos que han sido asignados a usuarios específicos La reasignación deobjetos requiere las direcciones que aparecen en esos objetos sean reasignadas.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Reutilización de objetosReutilización de objetos

No se requiere Todas las autorizacionespara la informacióncontenida con unalmacenamiento de objetosdeberán ser revocadaspreviamente o con unaasignación inicial,asignación o reasignacióndel tema desde el pool delTCB de los objetos noutilizados y almacenados.La información, incluyendola representación encriptadade la información, producidapor las aciones de un eventoprevio debe de estardisponible para cualquierevento que obtenga elacceso de un objeto que hasido ya regresado al sistema







EtiquetasEtiquetas

Las etiquetas y el control de acceso obligatorio son requerimientos separados de lapolítica de seguridad, pero ambas funcionan juntas. Al iniciar en el nivel B1, el libronaranja 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 conese usuario, las etiquetas de usuario sensitivas es usualmente llamada comocertificado de paso ó "clearance". Una etiqueta sensitiva de archivo especifica el nivelde confianza que un usuario puede ser capaz de tener al accesar ese archivo.

C1C1 C2 B1 B2 B3 A1

EtiquetasEtiquetasNo se requiere No se requiere Etiquetas sensitivas

asociadas con cada eventoy objeto almacenado bajosu control (p.e. procesos,archivos, segmentos,dispositivos) deben sermantenidos por el TCB.Estas etiquetas deberánser utilizadas como lasbases para las decisionesdel control del accesoobligatorio. En orden deimportancia de datos noetiquetados, el TCB debesolicitar y recibir de unusuario autorizado el nivelde seguridad de esosdatos, y todas las accionesdeberán ser auditadas porel TCB

RequerimientosRequerimientosadicionalesadicionalesLas etiquetassensitivas asociadascon cada recurso delsistema ADP (p.e.eventos, objetosalmacenados, ROM)que sondirectamente oindirectamenteaccesados poreventos externos aél TCB debe sermantenido por elTCB





Integridad de EtiquetasIntegridad de Etiquetas

La integridad de etiquetas asegura que las etiquetas sensitivas asociadas con eventosy objetos tienen una representación exacta de los niveles de seguridad de estoseventos y objetosAsí una etiqueta sensitiva como TOP SECRET [VENUS] deberá estar asociado conun archivo TOP SECRET que contiene información acerca del planeta Venus

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Integridad de etiquetasIntegridad de etiquetas

No se requiere No se requiere Las Etiquetassensitivas deberánrepresentar conprecisión los nivelesde los eventosespecíficos uobjetos con los queestos estánasociadosCuando sonexportados por elTCB, las etiquetassensitivas deberánprecisar yrepresentar sinambigüedad lasetiquetas internas ydeberán estarasociadas con lainformación que estasiendo exportada.






Exportación de Información EtiquetadaExportación de Información Etiquetada

Un sistema confiable debe de asegurar que la información es escrita por el sistema,que la información cuenta con mecanismos de protección asociados a ella. Dos formasde exportar información son asignar un nivel de seguridad a los dispositivos de salidaó escribir etiquetas sensitivas en los datos. Los sistemas valorados como B1 enadelante deben de proporcionar facilidades de exportación seguraSe definen dos tipos de dispositivos para exportar; multinivel y de nivel simple. Cadadispositivo de entrada / salida y canal de comunicaciones en un sistema debe de serdesignado de uno o de otro tipo. Cualquier cambio a estas designaciones dedispositivos debe de ser capaz de ser auditado. Típicamente un administrador desistemas designa dispositivos durante la instalación del sistema o durante suconfiguración

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Exportación de información etiquetadaExportación de información etiquetada

No se requiere No se requiere El TCB deberá designar cadacanal de comunicaciones ydispositivo de entrada / salida,ya sea como de un nivelsencillo o de multinivel.Cualquier cambio en estadesignación deberá ser hechamanualmente y deberá serauditable por el TCB. El TCBdeberá mantener y ser capazde auditar cualquier cambio enlos niveles de seguridad oniveles asociados con un canalde comunicaciones odispositivo de entrada / salida






Dispositivo MultinivelDispositivo Multinivel

Un dispositivo multinivel o un canal de comunicaciones multinivel es uno con lacapacidad de escribir información con un número diferente de niveles de seguridad. Elsistema debe soportar una variedad de especificaciones de niveles de seguridad,desde la más baja (SIN CLASIFICACIÓN) hasta la más alta (ALTAMENTESECRETA), permitiendo que un dato sea escrito en un dispositivoCuando se escribe información en un dispositivo multinivel, se requiere que el sistematenga alguna forma de asociar un nivel de seguridad a él. Los mecanismos puedendiferir para los diferentes sistemas y los diferentes tipos de dispositivos. Los archivosescritos a este dispositivos pueden tener etiquetas sensitivas agregadas a ellas(usualmente escritas en los encabezados del registro precediendo los datos delarchivo). Todo esto para prevenir que un usuario desvíe los controles del sistema conuna simple copia de un archivo sensitivo a otro de un sistema inseguro o dispositivo.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Exportación en dispositivos múltinivelExportación en dispositivos múltinivel

No se requiere No se requiere Cuando el TCB exporta un objeto que esmultinivel o un dispositivo de entrada /salida, la etiqueta sensitiva asociada conese objeto también deberá ser exportada ypermanecer residente en el mismo mediofísico que la información exportada y deberáestar en la misma forma (p.e. de formalegible a la máquina o en forma legible a lapersona). Cuando el TCB exporta o importaun objeto sobre un canal de comunicaciónmultinivel, el protocolo usado en ese canaldeberá proporcionar una paridad que eviteambigüedad entre las etiquetas sensitivas yla información asociada que se estaenviando o recibiendo

No se tienenrequerimientos adicionales





Dispositivo de Nivel UnicoDispositivo de Nivel Unico

Un dispositivo de nivel único o un canal de comunicaciones de nivel único es unocapaz de escribir información con sólo un nivel particular de seguridad. Usualmente lasterminales, impresoras, dispositivos de cinta y puertos de comunicación están en lacategoría de dispositivos de nivel único. El nivel que se especifica para un dispositivodepende usualmente de su localización física o de la seguridad inherente del tipo dedispositivo. Por ejemplo, la instalación de una red contempla varias impresoras en unnúmero determinado de computadoras y oficinas. El administrador debe designar queesas impresoras tengan niveles sensitivos que correspondan al personal que tieneacceso a dichas impresoras.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Exportación en dispositivos de nivel únicoExportación en dispositivos de nivel único

No se requiere No se requiere Los dispositivos de nielúnico de canales decomunicaciones de entrada /salida no son requeridaspara mantener las etiquetassensibles de la informaciónque procesanDe cualquier modo, el TCBdebe incluir un mecanismopara que el TCB y unusuario autorizado fiablecomunique y designe elnivel único de seguridad dela información importada oexportada vía canal decomunicaciones de nivelsencillo o dispositivo deentrada / salida.






Etiquetado de Salidas Legibles a la PersonaEtiquetado de Salidas Legibles a la Persona

El libro naranja es muy claro en cuanto a los requerimientos de cómo deben dehacerse las etiquetas para las salidas legibles al humano (salidas que las personaspueden ver). Estas incluyen páginas de salida impresa, mapas, gráficas y otrosindicadores. El administrador del sistema debe de especificar la forma en que lasetiquetas van a aparecer en la salida.Por lo regular se requieren dos tipos de etiquetas: primero, cada salida distinta debeser etiquetada, al principio y al final, con etiquetas que representen una sensitividadgeneral de la salida. Sí se está imprimiendo el contenido de un archivo Y típicamentese puede ver una página de un banner antes y después del contenido del documento,mostrando claramente la etiqueta sensitiva del archivo. Segundo, cada página desalida impresa debe ser etiquetada, e la parte superior y en la parte inferior, conetiquetas que presenten ya sea una u otra, una sensitividad general de la salida o lasensitividad específica de la información en esa página.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Etiquetas de salida legibles al humanoEtiquetas de salida legibles al humano

No se requiere No serequiere

El administrador del sistema ADP debe sercapaz de especificar los nombres de lasetiquetas imprimibles asociados con lasetiquetas sensitivas exportablesEl TCB debe marcar el inicio y el fin de todas lasetiquetas sensitivas legibles a la persona querepresenten sensitivamente la salida. El TCBdeberá, por omisión marcar el límite inferior ysuperior de cada página legible al hombre,compaginada, de la salida impresa (p.e. Salidasde la impresora) con una etiqueta sensitivalegible al hombre que representeapropiadamente la sensitividad global de lasalida o que represente apropiadamente lasensitividad de la información de cada página.Cualquier anulación de estas marcas por defectodeben ser auditables por el TCB






Etiquetas Sensitivas de EventosEtiquetas Sensitivas de Eventos

Las etiquetas sensitivas de eventos requieren estados que el sistema pueda notificara determinado usuario de algún cambio en el nivel de seguridad asociado con unusuario durante una sesión interactiva. Este requerimiento se aplica de los sistemasevaluados B2 en adelante.La idea de las etiquetas sensitivas a eventos es que el usuario siempre conozca elnivel de seguridad en el que esta trabajando. Los sistemas confiables típicamentedespliegan el "clearance" cuando se establece sesión y lo despliegan nuevamente siel nivel de seguridad tiene algún cambio, o automáticamente a petición del usuario.

C1C1 C2 B1 B2 B3 A1

Etiquetas sensitivas de eventosEtiquetas sensitivas de eventosNo se requiere No se requiere No se requiere El TCB debe

notificarinmediatamente a laterminal del usuariode cada cambio enel nivel de seguridadasociado con eseusuario durante unasesión interactiva.La terminal deusuario debe de sercapaz de buscar elTCB cuando lodesee paradesplegar en unevento con etiquetasensitiva.





Dispositivos EtiquetadosDispositivos Etiquetados

Los dispositivos etiquetados requieren estados que cada dispositivo físico tengaadicionados en el sistema que definan niveles mínimos y máximos de seguridadasociados a ellos, y todos estos son usados para "reforzar las restricciones impuestaspor el medio ambiente físico en el cual el dispositivo esta localizado".Para un dispositivo multinivel, se debe de especificar el nivel mínimo de la informaciónque puede ser enviada a este dispositivo (el mínimo para el dispositivo) y el nivel másalto de información que puede ser enviada al dispositivo (el máximo del dispositivo).Para un dispositivo de un nivel único, el nivel mínimo es el mismo que el nivel máximo

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Dispositivos EtiquetadosDispositivos Etiquetados

No se requiere No se requiere No se requiere El TCB debesoportar laasignación de unnivel mínimo ymáximo para tododispositivo físicoadjunto. Estosniveles de seguridaddeben de serusados por el TCBpara reforzar lascondicionesimpuestas por elmedio ambientefísico en cada unode los dispositivosfísicos localizados





Control de Acceso ObligatorioControl de Acceso Obligatorio

El control de acceso obligatorio es el último requerimiento de la política de seguridad,diferente del control de acceso discrecional, que autoriza a los usuariosespecíficamente, con sus propias preferencias, quien puede y quién no puede accesarsus archivos, el control de acceso obligatorio pone el control de todos los accesoscomo decisiones bajo el control del sistema

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Control de acceso obligatorioControl de acceso obligatorio

No se requiere No se requiere El TCB debe reforzar laspolíticas del control de accesoobligatorio de todos lossujetos y objetosalmacenados (procesos,archivos, dispositivos, etc.) Aestos sujetos y objetos debeser asignado una etiquetasensitiva que sean unacombinación e clasificaciónpor nivel jerárquico ycategorías no jerárquicas, ylas etiquetas deberán serusadas como la base de lasdecisiones para el control deacceso obligatorioEl TCB debe ser capaz desoportar dos o más niveles deseguridad, los siguientesrequerimientos deberánmantenerse para todos losaccesos entre sujetos yobjetos controlados por elTCB.

RequerimientosRequerimientosadicionalesadicionalesEl TCB debe reforzarlas políticas del controlde acceso obligatoriopara todos losrecursos(usuarios,objetos almacenados,dispositivos de entrada/ salida) que seanaccesibles directa oindirectamente porusuarios externos alTCB.Los requerimientosdeberán mantenersepara todos los accesosentre todos losusuarios externos a élTCB y todos losobjetos accesiblesdirecta oindirectamente porestos usuarios.





C1C1 C2C2 B1B1 B2B2 B3B3 A1A1

Un sujeto puede leer unobjeto solamente si laclasificación jerárquica delnivel de seguridad delsujeto es menor o igualque la clasificaciónjerárquica de los nivelesde seguridad del objeto yla categoría no jerárquicade los niveles de seguridadque se incluyen en todaslas categorías nojerárquicas del nivel deseguridad del objeto.Un usuario puede escribiren un objeto solamente sila clasificación jerárquicadel nivel de seguridad delsujeto es mayor o igualque la clasificaciónjerárquica de los nivelesde seguridad del objeto ycumple con todas lascategorías no jerárquicasde los niveles de seguridadque se incluyen en todaslas categorías nojerárquicas del nivel deseguridad del objeto.



Identificación y AutentificaciónIdentificación y Autentificación

La identificación y la autentificación es un requerimiento de un sistema de seguridaden todos los niveles. El libro naranja requiere que la identificación del usuario antes deejecutar cualquier tarea que requiera interacción con el TCB (p.e. correr un programa,leer un archivo o invocar cualquier función que requiere que el sistema cheque lospermisos de acceso). En la mayoría de los sistemas multiusuario, la identificación en elsistema se hace a través de algún tipo de nombre identificador (logín), seguido de unpasword.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 queproporcionan sugerencias concretas:

• The Department of Defense Password Management Guideline (El Libro Verde)• FIPS PUB 112 - Password Usage,

El libro verde defiende tres características principales1. Los usuarios deben ser capaces de cambiar sus passwords2. Los passwords deben ser generados por la maquina más el creado por el

usuario3.3. Seguridad en reportes de auditoria (fecha y hora del último login) debe ser

proporcionado por el sistema directamente al usuario.



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Identificación y autentificaciónIdentificación y autentificación

El TCB debesolicitar laidentificación de losusuarios antes deempezar a ejecutarcualquier acciónque el TCB deba deejecutar.El TCB debe usaralgún mecanismo deprotección(passwords) paraautentificar laidentidad delusuario.El TCB debeproteger los datosde autentificación demanera que nopuedan seraccesados porusuarios noautorizados

RequerimientosRequerimientosadicionalesadicionalesEl TCB debe ser capazde reforzar las cuentasindividuales alproporcionar lacapacidad deidentificación única acada usuario individualADP.El TCB debe tambiénproporcionar lacapacidad de asociarla identidad con todaacción audible elegidapor esa persona.

RequerimientosRequerimientosadicionalesadicionalesEl TCB debe mantenerlos datos deautentificación queincluyen la informaciónpara verificar laidentidad de losusuarios (password)Así como la informaciónpara detectar laautorización de usuariosindividuales. Los datosdeben ser usados por elTCB para autentificar laidentidad de losusuarios y asegurar queel nivel de seguridad yla autorización de todoslos usuarios externos alTCB puedan sercreados para actuar ennombre del usuarioindividual que sedocumenta por el pase yla autorización del tipode usuario






Rutas SegurasRutas Seguras

Una ruta segura proporciona un medio libre de errores, por el cual un usuario(típicamente una terminal o un a estación de trabajo) puede comunicarse directamentecon un TCB sin interactuar con el sistema a través de aplicaciones inseguras (yposiblemente poco fiables) y capas del sistema operativo. Una ruta segura es unrequerimiento para sistemas clasificados como B2 en adelante.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Rutas segurasRutas seguras

No se requiere No se requiere No se requiere El TCB debesoportar una rutasegura decomunicacionesentre él y un usuariopara suidentificación yautentificación. Lacomunicación víaesta ruta deberá seriniciadaexclusivamente porel usuario

RequerimientosadicionalesEl TCB debesoportar una rutasegura decomunicacionesentre él y usuariospara usarse cuandouna conexión TCB ausuario es requerida(login, cambiar algúnnivel de seguridad).Las comunicacionesvía ruta seguradeben ser activadasexclusivamente porel usuario o el TCB ydeben ser aisladas ylibres de errores asícomo distinguiblesde otras conexiones



AuditoríaAuditoría

La auditoría es el registro, examen y revisión de las actividadesrelacionadas con la seguridad en un sistema confiable. Una actividadrelacionada con la seguridad es cualquier acción relacionada con elacceso de usuarios, o acceso a objetos. En términos de auditoria,algunas actividades son llamadas frecuentemente eventos, y unaauditoria interna se llama algunas veces eventos logging.

Los eventos típicos incluyen• Logins (exitosos o fallidos)• Logouts• Accesos a sistemas remotos• Operaciones de archivos, apertura, renombrar, eliminación.• 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 razón es que hasta elsistema más seguro es vulnerable a ser atacado, y la auditoríaproporciona un excelente medio de determinar cuando y como unataque puede ser efectuado.

La auditoría permite funciones muy útiles de seguridad: Inspección yreconstrucción. La supervisión es el monitoreo de la actividad delusuario. Este tipo de auditoría, puede prevenir de que violaciones deseguridad puedan ocurrir, esto solo porque los usuarios saben quealguien los esta observando. La reconstrucción es la habilidad de ponerjunto, al evento de violación 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 lasiguiente información (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 petición (identificador de la terminal)• Nombre de los objetos involucrados (nombre de (ej. Nombre de

los archivos a ser borrados)• Descripción y modificación a las bases de datos de seguridad• Niveles de seguridad de los usuarios y objetos (B1 en adelante)

EventosEventosTípicosTípicos



33

La auditoria es una herramienta vital de administración. Al observarpatrones o actividad sospechosa (p.e. un gran número de login falladosdesde una terminal en particular o los repetitivos intentos de un usuariode leer archivos a los que él no tiene acceso).Algunos proveedores proporcionan utilerias que permiten llevar laauditoria y realizar pistas para ser impresas para usuarios particulares,para tipos específicos de eventos o para archivos particulares. Loseventos típicos incluyen eventos del sistema, eventos de archivos, yeventos de usuarios.


C1C1 C2C2 B1B1 B2B2 B3B3 A1A1AuditoríaAuditoría

No se requiere El TCB debe ser capazde crear, mantener yproteger demodificaciones, o accesode usuarios noautorizados o destrucciónde pistas de auditoria oaccesos a objetosprotegidos. La auditoríade datos debe serprotegida por el TCB deaccesos de lectura olimitar a quien estaautorizado para auditarlos datos.El TCB debe ser capazde registrar los siguientestipos de eventos: Uso demecanismos deidentificación yautentificación,introducción de objetosen el espaciodireccionable del usuario(apertura de archivos,inicialización deprogramas), eliminaciónde objetos, accionestomadas por operadoresde la computadora yadministradores delsistema

RequerimientosRequerimientosadicionalesadicionalesEl TCB también debeser capaz de auditarcualquier sustituciónde marcas de salidalegibles al humanoPara eventos queintroducen un objetodentro del espaciodireccionable delusuario y para borrareventos de objetos elregistro de auditoriadebe incluir elnombre de losobjetos y el nivel deseguridad del objeto.El administrador desistema ADP debeser capaz de auditarselectivamente lasacciones de algún ovarios usuariosbasándose en laidentidad individualy/o nivel deseguridad de losobjetos.

RequerimientosRequerimientosadicionalesadicionalesEl TCB debe sercapaz de auditar loseventosidentificados quepueden ser usadosen la explotación ocubierta de canalesde almacenamiento

RequerimientosRequerimientosadicionalesadicionalesEl TCB debe contarcon un mecanismocon la capacidad demonitorear lasocurrencias oacumulación deeventos deseguridad auditableque pueden indicarde una inminenteviolación a laspolíticas deseguridad. Estemecanismo deberáde ser capaz denotificarinmediatamente aladministrador deseguridad cuando seexcede el umbral, ysi la acumulación deocurrencias deeventos relevantesde seguridadcontinua, el sistemadeberá tomar laúltima accióndisolvente quetermine con esteevento




C1C1 C2C2 B1B1 B2B2 B3B3 A1A1AuditoríaAuditoría

y/o administradores dela seguridad delsistema, y otroseventos relevantes delsistema. Para cadaevento registrado, elregistro de auditoriadeberá identificar:fecha y hora delevento, y si el eventofue exitoso o fallo elevento. Laidentificación /autentificación deeventos que originanla petición (ID de laterminal) deberán serincluidos en el registrode auditoriaEl administrador desistema ADP, debeser capaz deseleccionar lasacciones a auditar deuno o de variosusuarios basándoseen la identidadindividual



Arquitectura del SistemaArquitectura del Sistema

El requerimiento de arquitectura del sistema tiene el objeto de diseñar un sistemapara hacerlo lo más seguro posible, - sino invulnerable.Así los sistemas de los niveles bajos (C1, B1 y hasta B2) no fueron necesariamentediseñados específicamente para seguridad, ellos soportan principios de diseño dehardware y sistema operativo, tan bien como la habilidad de soportar característicasespecíficas que quizás son agregadas a estos sistemas. La mayoría de los diseñosmodernos de multiprocesamiento, y sistemas multi usuarios siguen las claves losprincipios de diseño necesarios para cumplir los requerimientos del libro naranja en losque arquitectura del sistema se refiere al menos C2 y B1, sí bien estos principios noestán necesariamente orientados a seguridad

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Arquitectura del sistemaArquitectura del sistema

EL TCB debemantener undominio para supropia ejecuciónque lo protejade interferenciaexterna ofalsificaciones(Ej. Paramodificación desu código oestructura dedatos).

Requerimientosadicionales:El TCB debe aislar losrecursos a serprotegidos de maneraque los usuariostengan control deacceso yrequerimientos deauditoría

RequerimientosadicionalesEl TCB debemantener procesosaislados así comoproporcionar distintasdirecciones de espaciobajo su control

NuevosRequerimientos paraB2El TCB debemantener undominio para supropia ejecución deprotecciones deinterferencia externao falsificaciones(Ej.Para modificaciónde su código oestructura de datos).

RequerimientosadicionalesEl TCB debe diseñary estructurar el usocompleto, de unmecanismo deprotección,conceptualmentesimple con definiciónsemántica precisa.Este mecanismo debejugar un papel centralen el reforzamiento dela estructura internaentre el TCB y elsistema.




C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Arquitectura del sistemaArquitectura del sistema

Los recursoscontrolados porel TCB puedenser definidos enun subgrupo asícomo losusuarios yobjetos en elsistema ADP.

El TCB debe mantenerprocesos aislados asícomo proporcionardirección de espaciosdistintas bajo su control.El TCB debe estarestructurado internamentedentro de una biendefinido móduloindependiente.El módulo TCB debe serdiseñado bajo el principiode que los privilegios seanreforzados,Características dehardware, así comosegmentación, debe serusado para soportarlógicamente distincionesde objetos almacenadoscon atributos separados(nombrar, leer y escribir).La interfaz de usuario delTCB debe sercompletamente definida ytodos los elementos delTCB identificados

El TCB debeincorporar el usosignificativo decapas, abstracción yocultamiento dedatos.

Una aplicación deingeniería desistemassignificativa debeser directamenteconducidaminimizando lacomplejidad del TCBy excluyendo de losmódulos del TCB losobjetos que nopresentanprotección crítica




Integridad del SistemaIntegridad del Sistema

La integridad del sistema significa que el hardware y el firmware debe trabajar y debeser probado para asegurar que trabaje adecuadamente, Para todos los niveles, el libronaranja establece “las características de hardware y software que deben serproporcionadas para ser usadas y periódicamente validadas para la correcta operacióndel hardware instalado y los elementos firmware del TCBLa integridad de sistema una meta de vital importancia para todos los desarrolladoresde sistemas, y no solo desarrolladores de sistemas seguros. Como ya se hamencionado anteriormente, un elemento muy importante de un sistema de seguridad esla habilidad de que el sistema funcione como se espera y permanecer en operaciónMuchos vendedores miden los requerimientos de integridad del sistema, al proveer deun juego de pruebas de integridad, EL más substancial diagnostico es hacer unprograma calendarizado de periodos de mantenimiento preventivo.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Integridad del sistemaIntegridad del sistema

Las característicasdel hardware y/o elsoftware deben serproporcionadas paraser usadas yperiódicamentevalidadas sucorrecta operaciónasí como loselementos dehardware y firmwaredel TCB








Análisis de Canales SecretosAnálisis de Canales Secretos

Un canal secreto es una ruta de información que no se usa ordinariamente paracomunicaciones en un sistema, por los mecanismos normales de seguridad delsistema. Es una vía secreta para transportar información a otra persona o programa –El equivalente computacional de un espía que porta un periódico como unacontraseña.En teoría cada pieza de información almacenada o procesada por un sistemacomputacional seguro es un potencial canal secreto.Existen dos tipos de canales secretos, canales de almacenamiento y canales detemporización. Los canales de almacenamiento transportan información para cambiardatos almacenados en el sistema en alguna forma. Los canales de temporizacióntransportan información que afecte el desempeño o modifiquen de alguna forma eltiempo usado por los recursos del sistema en alguna forma medible.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Análisis de canales secretosAnálisis de canales secretos

No se requiere No se requiere No se requiere El sistema desarrolladodeberá comportarsecompletamente, buscando lasimulación de canales dealmacenamiento y haciendodeterminaciones (para lasmediciones actuales o porestimaciones de ingeniería) oel máximo ancho de banda decada canal identificado

RequerimientosRequerimientosadicionales:adicionales:Búsqueda de todoslos canalessimulados(almacenamiento ytemporización)

RequerimientosRequerimientosadicionales:adicionales:Métodos formalesdeben de serusados en el análisis



Administración de SeguridadAdministración de Seguridad

La facilidad de la administración de seguridad es la asignación de un individuoespecífico para administrar las funciones relacionadas con la seguridad de un sistema.La facilidad de administración de la seguridad es muy relacionada con el concepto deprivilegio mínimo, un concepto tempranamente introducido en términos de arquitecturade sistemas. En el contexto de seguridad, el privilegio mínimo significa que el usuario deun sistema debe tener el menor número de permisos y la menor cantidad de tiempo –únicamente el necesario para desempeñar su trabajo. También esta relacionado elconcepto de administración con la separación de obligaciones, la idea es que es mejorasignar piezas de seguridad relacionadas con tareas de algunas personas específicas yque ningún usuario tenga el control total de los mecanismos de seguridad del sistema,para que de ninguna forma un usuario pueda comprometer completamente al sistema

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Facilidad de administración de la seguridadFacilidad de administración de la seguridad

No se requiere No se requiere No se requiere El TCB debesoportarseparadamentelas funciones deadministrador yoperador

Requerimientos adicionalesRequerimientos adicionalesLas funciones ejecutadas enel papel del administrador deseguridad deben seridentificadas. El Personal deAdministración del sistemaADP, deberá solo ser capazde ejecutar funciones deadministrador de seguridad




C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Facilidad de administración de la seguridadFacilidad de administración de la seguridad

No se requiere No se requiere No se requiere El TCB debe soportarseparadamente lasfunciones deadministrador yoperador

después de tomar unaacción auditabledistinguible al asumir elpapel de administradorde la seguridad en elsistema ADP. Lasfunciones que no son deseguridad que puedenser ejecutadas por elpapel de administradorde seguridad deberánlimitarse estrictamente alo más esencial paraejecutar la seguridadefectivamente




Recuperación ConfiableRecuperación Confiable

La recuperación confiable asegura que la seguridad no ha sido violada cuando se caeun sistema o cuando cualquier otra falla del sistema ocurreLa recuperación confiable actualmente involucra dos actividades: prepararse ante unafalla del sistema y recuperar el sistema.La principal responsabilidad en preparación es respaldar todos los archivos delsistema crítico con una base regular. El procedimiento de recuperación puede ser conmucho, esforzarse por restaurar solo un día o dos de procesamiento de información.

Si una falla inesperada ocurre, como una falla de disco duro, o un corte de corrienteeléctrica, se debe recuperar el sistema de acuerdo con ciertos procedimientos paraasegurar la continuidad de la seguridad en el sistema. Este procedimiento tambiénpuede ser requerido si se detecta un problema del sistema, como recursos perdidos, ouna base de datos inconsistente o cualquier cosa que comprometa el sistema

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Recuperación confiableRecuperación confiable

No se requiere No se requiere No se requiere No se requiere Los procedimientos y/omecanismos deberánser proporcionadospara asegurar que,después de una falladel sistema ADP u otradiscontinuidad, elsistema se recupere sinun obtener compromisode protección




Diseño de Especificaciones yDiseño de Especificaciones yVerificaciónVerificación

El diseño de especificaciones y la verificación requiere una comprobación de que ladescripción del diseño para el sistema sea consistente con las políticas de seguridaddel sistema.A cada nivel de seguridad empezando desde el B1, el libro naranja. Requiere unincremento del modelo formal (precisamente matemático) de las políticas del sistemade seguridad que permite se incrementen las pruebas de que el diseño del sistema esconsistente con su modelo

¿Qué es una prueba formal? Es un argumento matemático completo y convincente deque el sistema es seguro, o al menos de que el diseño del sistema y llevaimplementada una adecuada política de seguridad. Por ejemplo, si se demuestramatemáticamente que bajo condiciones existen ciertos sujetos (usuarios), que puedenaccesar a cierto tipo de objetos (archivos) y se demuestra que los usuarios no puedenengañar las condiciones de acceso.



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Diseño de especificaciones y verificaciónDiseño de especificaciones y verificación

No se requiere No se requiere Un modelo formal oinformal de laspolíticas deseguridad soportadaspor el TCB quedeberá sermantenido durantetodo el ciclo de vidadel sistema ADP ydemostración de serconsistente con suaxioma

Requerimientosadicionales para B2Un modelo formal dela política de seguridadsoportada por el TCBdeberá ser mantenidadurante todo el ciclode vida del sistemaADP que deberáproporcionarconsistencia con suaxioma. Especificacióndescriptiva de altonivel (DTLS) del TCBen términos deexcepciones,mensajes de error yefectos. Este deberáser mostrado de seruna descripción exactade la interfaz del TCB

RequerimientosadicionalesUn argumentoconvincente deberáser proporcionadode que el DTLS esconsistente con elmodelo

RequerimientosadicionalesUna especificaciónformal de alto nivel(FTLS) del TCB quedeberá ser mantenido yprecisamente descrito elTCB en términos deexcepciones, mensajesde error y efectos. ELDTLS y el FTLS deberáincluir los componentesdel TCB que estánimplementados comohardware y/o firmware sisus propiedades sonvisibles para él lainterfaz del TCB. Unacombinación de técnicasformales e informalesdeberá ser usada paramostrar que el FTLS esconsistente con elmodelo.



Pruebas de SeguridadPruebas de Seguridad

El libro naranja tiene un substancial interés en probar las características de seguridaden los sistemas a evaluar. Las pruebas de seguridad aseguran que los requerimientosestán relacionados con los requerimientos de pruebas de documentación. El sistemadesarrollado será probado para todas las características de seguridad, asegurandoque el sistema trabaja como se describe en la documentación, y se documenten losresultados de las pruebas de estas características. El equipo de evaluación del NTSCesta comprometido con sus pruebas.

Estos son los dos tipos básicos de pruebas de seguridad: • Prueba de mecanismos y• Prueba de interfaz.

La prueba de mecanismos significa probar los mecanismos de seguridad, estosmecanismos incluye control de acceso discrecional, etiquetado, control de accesoobligatorio, Identificación y autentificación, prueba de rutas, y auditoría.La prueba de interfaz significa el probar todas las rutinas del usuario que involucrenfunciones de seguridad



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Pruebas de seguridadPruebas de seguridad

Los mecanismosde seguridad delsistema ADPdeberá serprobado yencontradotrabajando yexigido en ladocumentación delsistema. Laspruebas deberánser hechas paraasegurar que nohay caminosobvios para accesode usuarios noautorizados ocualquier otra fallaen el mecanismode protección de laseguridad del TCB

RequerimientosadicionalesLas pruebasdeberán tambiénser incluidas en labúsqueda debanderas obviasque puedanpermitir unaviolación derecursos aislados,o que puedanpermitir el accesono autorizado deauditoría oautentificación dedatos

Requerimientosadicionales para B1Los mecanismos deseguridad del sistemaADP deberán serprobados y encontradostrabajando con ladocumentación delsistema.Un equipo deindividuos queentiendancompletamente laimplementaciónespecífica del TCBdeberá diseñardocumentación, códigofuente y código objetopara el análisiscompleto y Laspruebas.Estos objetivos deberándescubrir todo eldiseño y laimplementación debanderas que pudieranpermitir a un sujetoexterno al TCB el leer,cambiar o borrare datosnormalmentedenegados bajopolíticas de seguridaddiscrecional u

RequerimientosadicionalesEl TCB deberá serencontradorelativamenteresistente apenetraciónAl probar tododeberá demostrarseque laimplementación delTCB es consistentecon la descripciónde especificación dealto nivel.

RequerimientosadicionalesEl TCB deberá serencontradoresistente apenetraciones,Ninguna bandera dediseño y ningunabandera deimplementación sincorrecciones debeser encontradadurante las pruebasy deberán serrazonablementeconfidenciales laspocas que queden.

RequerimientosadicionalesLas pruebasdeberán demostrarque laimplementación delTCB es consistentecon la especificaciónformal de alto nivelEl manual u otrosmapas del FTLS delcódigo fuentepueden formarbases para laspruebas depenetración.



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Pruebas de seguridadPruebas de seguridad

obligatorias reforzadaspor el TCB, así como elasegurar que ningúnsujeto (sin autorizaciónpara hacerlo) sea capazde causar que el TCBentre en un estado talque sea incapaz deresponder acomunicacionesiniciadas por otrosusuarios. Todas lasbanderas descubiertasdeberán ser removidaso neutralizadas y elTCB vuelto a probarpara demostrar queestas han sidoeliminadas y quenuevas banderas nohan sido introducidas



Administración de ConfiguraciónAdministración de Configuración

La administración de configuraciones protege un sistema seguro mientras esta siendodiseñado, desarrollado, y mantenido. Involucra el identificar, controlar, contabilizar yauditar todos los cambios hechos en los lineamientos de TCB, incluyendo hardware,firmware y software, por ejemplo, cualquier cambio en el código, durante las faces dediseño, desarrollo y mantenimiento así como la documentación, planes de pruebas, yotras herramientas del sistema relacionadas y sus facilidades.La administración de configuraciones tiene varias metas, primero, el control delmantenimiento del sistema durante su ciclo de vida, asegurando que el sistema esusado de la forma correcta, implementando las políticas de seguridad adecuadas. El“sistema adecuado” es el sistema que ha sido evaluado o que actualmente esta siendoevaluado En otras palabras la administración de configuraciones previene de usarversiones obsoletas 8º nuevas, que no han sido probadas en el sistema) o alguno desus 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 versión del sistemaque no tenían en una versión anterior.Para cumplir los requerimientos de la administración de configuración se se necesita:• Asignar un identificador único para cada elemento configurable• Desarrollar un plan de administración de la configuración• Registrar todos los cambios de elementos de configuración (en línea y fuera de

línea)• Establecer un tablero de control e configuraciones



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Administración de configuraciónAdministración de configuración

No se requiere No se requiere No se requiere Durante el desarrollo ymantenimiento del TCB,una administración deconfiguraciones deberátomar lugar en el control demantenimiento de loscambios en laespecificación descriptivade alto nivel y otros datosde diseño, documentaciónde implementación, códigofuente, las versionescorridas del código objeto ylas pruebas decorrecciones ydocumentación.


Nuevos Requerimientospara A1Durante el ciclocompleto de vida...durante el diseño,desarrollo, ymantenimiento del TCB,una administración deconfiguraciones deberátener lugar para todos elhardware, firmware ysoftware relacionadocon la seguridad y debede mantenerse uncontrol formal demantenimiento de todoslos cambios al



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Administración de configuraciónAdministración de configuración

La administración deconfiguraciones del sistemadeberá asegurar un mapeoconsistente entre toda ladocumentación y el códigoasociado con las versionesactuales del TCB. Lasherramientas deberán tenersepara generar una nueva versióndel TCB desde el código fuente.También deberán estardisponibles las herramientaspara hacer comparaciones de lanueva versión generada, con laversión previa del TCB en ordena determinar que sólo loscambios proyectados han sidohechos en el código queactualmente se esta usandocomo la nueva versión del TCB

modelo formal lasespecificaciones descriptiva yformal de alto nivel, otrosdatos de diseño,documentación eimplementación, códigofuente, la versión actual delcódigo objeto, las pruebas dereparaciones y ladocumentación. Laadministración deconfiguraciones del sistemadeberá asegurar un mapeoconsistente entre toda ladocumentación y el códigoasociado con las versionesactuales del TCB. Lasherramientas deberán tenersepara generar una nuevaversión del TCB desde elcódigo fuente. También lasherramientas deberán sermantenidas bajo un estrictocontrol de configuracionespara comparar una versiónnueva generada desde elTCB en orden a determinarque sólo los cambiosproyectados han sido hechosen el código que actualmentese esta usando.



Distribución ConfiableDistribución Confiable

La distribución confiable protege un sistema seguro mientras el sistema es siendotransportado al sitio del cliente. Este requerimiento solo se tiene para el nivel A1, esterequerimiento tiene dos metas protección y validación del lugarLa protección significa que el vendedor final (y durante el transporte del vendedor alcliente), se asegura que durante la distribución, el sistema llegue al lugar donde losolicito el cliente, exactamente, como fue evaluado antes de transportarse por elvendedor, ya que proporciona protección durante el empaque, transporte entreintermediarios hasta llegar al usuario final.Validación del lugar, significa que el cliente final, con la distribución confiable puededetectar falsificaciones del sistema o modificación del sistema.



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Distribución ConfiableDistribución Confiable

No se requiere No se requiere No se requiere No se requiere No se requiere Un sistema de controlADP confiable yfacilidad de distribucióndeberá serproporcionada paramantener la integridaddel mapeo entre losdatos maestros quedescriben la versiónactual del TCB y lacopia maestra en sitiodel código del laversión actual. Losprocedimientos (Pruebade aceptación de laseguridad del sitio)deberá existir paraasegurar que elsoftware, firmware yactualización delhardware del TCB,distribuido a los clienteses exactamente comose especifica en lascopias principales.



Guía del Usuario deGuía del Usuario deCaracterísticas de SeguridadCaracterísticas de Seguridad

La guía del usuario de características de seguridad (SFUG) es un apunte ordinario, sinprivilegios para todos los usuarios del sistema. En el se encuentran cosas que esnecesario saber acerca de las características del sistema de seguridad y de cómo esque están reforzadas. Los temas típicos incluyen:

• Acceso al sistema seguro. Como se debe introducir el login y el password, con quefrecuencia debe de cambiarse, que mensajes deben de verse, cómo deben deusarse estos mensajes para reforzar la seguridad del sistema

• Protección de archivos y otro tipo de información. Cómo se debe de especificar unalista de control de acceso (o protecciones similares)

• Importar y exportar archivos Como leer nuevos datos dentro del sistema confiable ycomo escribir datos de otros sistemas sin arriesgar la seguridad

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Guía del usuario de características de seguridadGuía del usuario de características de seguridad

Un resumen sencillo,capítulo o manual enla documentación delusuario que describalos mecanismos deprotecciónproporcionados por elTCB, lineamientossobre su uso y comointeractuar con otros.








Facilidades del Manual de SeguridadFacilidades del Manual de Seguridad

Este documento es un apunte de administrador del sistema y/o administradores deseguridad. Habla sobre todas las cosas que se necesita saber acerca de laconfiguración del sistema para ser seguro, reforzando el sistema de seguridad,interactuando con peticiones del usuario y haciendo que el sistema trabaje con lasmejores ventajas. EL Libro naranja requiere que este documento contengaadvertencias, acerca de las funciones y privilegios que deben ser controlados ensistemas seguros

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Facilidades del manual de seguridadFacilidades del manual de seguridad

Undireccionamientomanual por partedel administradordel sistema ADPdeberá presentaravisos sobre susfunciones yprivilegios quedeberá de controlarcuando ejecutauna instalaciónsegura

RequerimientosRequerimientosadicionalesadicionalesLos procedimientospara examinar ymantener losarchivos de auditoríaasí como lasestructuras de losregistros detalladosde auditoría paracada tipo de eventoauditable debe serproporcionado

RequerimientosRequerimientosadicionalesadicionalesEL manual deberádescribir lasfunciones deloperador y deladministradorrelativas a laseguridad, al incluirlos cambios de lascaracterísticas deseguridad para losusuarios.

RequerimientosRequerimientosadicionalesadicionalesLos módulos delTCBN que contienenlos mecanismos devalidación dereferencias deberánser identificables.Los procedimientospara una operaciónsegura de un nuevoTCB desde origen,después demodificarse porcualquier módulo enel TCB deberá serdescrito

RequerimientosRequerimientosadicionalesadicionalesSe deberán incluirlos procedimientospara asegurar que elsistema esinicialmentearrancado de unamodo seguro, Losprocedimientosdeberán tambiénestar incluidos en elcompendio deoperación delsistema deseguridad despuésde cualquier lapsode operación delsistema




C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Facilidades del manual de seguridadFacilidades del manual de seguridad

Este deberáproporcionarlineamientos para eluso consistente yefectivo de lascaracterísticas deprotección delsistema, comodeberá interactuar,como generar unanueva TCB segura ylos procedimientosde instalación,advertencias, yprivilegios quedeberán sercontrolados paraoperar lasinstalaciones de unamanera segura



Documentación de PruebasDocumentación de Pruebas

Para el libro naranja, consiste en mostrar como los mecanismos de seguridad fueronprobados, y los resultados de los mecanismos de seguridad con pruebas funcionalesEl tener buena documentación de pruebas es generalmente sencillo pero voluminoso.Es común que la documentación de pruebas para los sistemas C1 y C2 consista envarios volúmenes de descripción de pruebas y resultados

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Documentación de pruebasDocumentación de pruebas

El desarrollador delsistema deberáproporcionar a losevaluadores undocumento quedescriba el plan depruebas,procedimientos deprueba quemuestren como losmecanismos sonprobados, y losresultados de laspruebas funcionalesde los mecanismosde seguridad



RequerimientosRequerimientosadicionalesadicionalesSe deberá incluir losresultados de laspruebas de falta deefectividad de losmétodos usados parareducir los anchos debanda de los canalessecretos


RequerimientosRequerimientosadicionalesadicionalesLos resultados delmapeo ente lasespecificacionesformales de altonivel y el códigofuente del TCBdeberán serproporcionadas



Diseño de DocumentaciónDiseño de Documentación

Es un requerimiento formidable para todos los desarrolladores de sistemas. La ideade diseñar documentación es documentar internamente el sistema (o lo más básicodel TCB) hardware, firmware y software. El objetivo del diseño de documentación esque “la filosofía del fabricante sobre protección y... cómo esta filosofía es trasladadadentro del TCB” Una tarea clave que define los límites del sistema y distingueclaramente entre cuales porciones del sistema son relevantemente seguras y cualesno.

Las dos mayores metas del diseño de documentación son: el probar al equipo deevaluación que el sistema cumple con el criterio de evaluación y el auxiliar al equipode diseño y desarrollo para ayudar a definir las políticas del sistema de seguridad ycomo hacer que las políticas se lleven a cabo durante la implementación.

C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Diseño de documentaciónDiseño de documentación

Ladocumentaciónque proporcioneuna descripciónde la filosofía delfabricante sobreprotección deberáestar disponible,y una explicaciónde cómo estafilosofía estrasladadadentro,


RequerimientosRequerimientosadicionalesadicionalesUna descripción formalo informal del modelode las políticas deseguridad reforzadopor el TCB deberáestar disponible paradar una explicación deque es suficiente elreforzar las políticasde seguridad.

RequerimientosRequerimientosadicionalesadicionalesLas interfaces entre losmódulos del TCBdeberán ser descritosEl modelos depolíticas de seguridaddeberá ser formal yprobado.La especificacióndescriptiva de alto nivel(DTLS) deberá sermostrada en unadescripción exacta dela interfaz del TCB. .

RequerimientosRequerimientosadicionalesadicionalesLa implementacióndel TCB (hardware,firmware y software)deberá serinformalmentemostrada y serconsistente con elDTLS. Loselementos del DTLSdeberán sermostrados, usandotécnicas

RequerimientosRequerimientosadicionalesadicionalesLa implementacióndel TCB deberá serinformalmentemostrada para serconsistente con laespecificaciónformal de alto nivel(FTLS).Los elementos delFTLS deberán sermostrados, usandotécnicas



C1C1 C2C2 B1B1 B2B2 B3B3 A1A1Diseño de documentaciónDiseño de documentación

del TCB, sí elTCB escompuesto pordistintos móduloslas interfacesentre estosmódulos deberáser descrita.

El mecanismo deprotección específicadel TCB deberá seridentificable y unaexplicación quedemuestre cómo éstemecanismo satisfaceel modelo.

La documentacióndescribirá como el TCBimplementa elconcepto de monitorde referencia y daruna explicación deporque es resistente apenetración, y nopuede ser traspasado,y es correctamenteimplementado.La documentacióndeberá describir comoel TCB se estructurapara pruebas deinstalación y reforzarlos menores privilegios.Esta documentacióndeberá tambiénpresentar losresultados del análisisde los canalessecretos y losintercambiosinvolucrados alrestringir los canales.Todos los eventosauditables que puedenser usados en laexplotación de conocercanales de almacenajesecretos, deberán seridentificados

de información, consu correspondienteelemento del TCB

de información, consu correspondienteelemento del TCBLos mecanismos dehardware, firmwarey software nocompartidos con elFTLS peroestrictamenteinternos del TCB(mapeo de registros,acceso directo amemoria deentrada/salida),deberá serclaramente descrito.


Glosario de TérminosGlosario de Términos

ADP.ADP.Automatic Data Processing (Procesamiento automático dedatos).

Aplicaciones sensitivas.Aplicaciones sensitivas.Son todos aquellos programas y sistemas desarrollados parala administración de sistemas, como pueden serherramientas administración, configuración o seguridad.

DODDOD Departament of Defense (Departamento de Defensa de losEstados Unidos).

Información sensitivaInformación sensitivaEs toda aquella información que no esta disponible a todoslos usuarios por poseer un cierto grado de confidencialidad.

Elemento ActivoElemento ActivoSon todos aquellos usuarios o procesos que poseen lacapacidad de crear, modificar, leer, escribir o borrarinformación

EtiquetaEtiqueta

Son identificadores que se les asignan a los usuarios o a losobjetos dentro del sistema, se utilizan estos identificadorespara verificar los permisos que tiene el usuario o el objetopara permitir o denegar las acciones.

Etiqueta Sensitiva de UsuarioEtiqueta Sensitiva de Usuario

Específica el grado, o nivel de confianza, asociado con eseusuario, las etiquetas de usuario sensitivas es usualmentellamada como certificado de paso ó "clearance".

Etiqueta Sensitiva de ArchivoEtiqueta Sensitiva de ArchivoEspecifica el nivel de confianza que un usuario puede sercapaz de tener al tener acceso a ese archivo.

EventoEventoSon todas las acciones generadas por un usuario o unproceso que van a exigir una respuesta por parte de unobjeto.

FirmwareFirmware

Se define como hardware en software, es decir memoriasROM que contienen instrucciones o datos necesarios para elsistema, un ejemplo son los BIOS de la mayoria de lascomputadoras.



60

Nivel de SensitividadNivel de Sensitividad

Es cuando toda la información almacenada o todos losusuarios que tienen acceso a esa información poseenexactamente los mismos permisos.

ObjetoObjetoSon todos los elementos identificables dentro del sistema,cmomo son directorios, archivos, dispositivos, puertos, etc.

TCBTCB Trusted Computers Bases (Computadora Confiable Base).

BibliografíaBibliografía

URL: http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html

Computer Security Basics,Deborah Russell and G.T. Gangemi Sr.O’Reilly & Associates, Inc.

Documents

Orange Book