Instalaciones informáticas. Protección contra el acceso no autorizado a la información.

Tecnología informática. Protección contra el acceso no autorizado a la información. Indicadores de seguridad frente al acceso no autorizado a la información. Documento guía.

Este documento guía establece una clasificación de los equipos informáticos según el nivel de seguridad contra el acceso no autorizado a la información en base a una lista de indicadores de seguridad y un conjunto de requisitos que los describen.

Se entiende por SVT un conjunto de software y elementos técnicos de sistemas de procesamiento de datos que pueden funcionar de forma independiente o como parte de otros sistemas.

Abreviaturas aceptadas

COMO — sistema automatizado
CD — documentación de diseño
KSZ — complejo de equipos de protección
NSD — acceso no autorizado
PRD — reglas de control de acceso
SVT — instalaciones informáticas

1. DISPOSICIONES GENERALES

1.1. Estos indicadores contienen los requisitos para la seguridad de la tecnología informática frente al acceso no autorizado a la información.

1.2. Los indicadores de seguridad de SVT se aplican al software y a los sistemas operativos de todo el sistema (teniendo en cuenta la arquitectura de la computadora).

Listas específicas de indicadores determinan las clases de seguridad de SVT.

No se permite reducir o cambiar la lista de indicadores correspondientes a una clase de seguridad específica de equipo.

Cada indicador se describe mediante un conjunto de requisitos.

Se analizan específicamente los requisitos adicionales para el indicador de seguridad SVT y el cumplimiento de estos requisitos adicionales.

1.3. Los requisitos para los indicadores se implementan mediante software y hardware.

La totalidad de todos los medios de protección constituye un conjunto de medios de protección.

La documentación de KPS debe ser una documentación de diseño de pieza integral para SVT.

1.4. Se establecen siete clases de seguridad SVT desde información no accesible hasta información. Clase más baja — séptimo, más alto — primero.

Las clases se dividen en cuatro grupos, que se diferencian en el nivel cualitativo de protección:

• el primer grupo contiene sólo una séptima clase;

• el segundo grupo se caracteriza por una protección discrecional y contiene las clases sexta y quinta;

• el tercer grupo se caracteriza por una protección obligatoria y contiene las clases cuarta, tercera y segunda;

• El cuarto grupo se caracteriza por una protección verificada y contiene solo la primera clase.

1.5. La elección de la clase de seguridad SVT para sistemas automatizados creados sobre la base de SVT seguro depende del grado de confidencialidad de la información procesada en el sistema automatizado, las condiciones de funcionamiento y la ubicación de los objetos del sistema.

1.6. El uso de herramientas de protección de información criptográfica en el conjunto SVT de acuerdo con GOST 28147-89 se puede utilizar para aumentar las garantías de calidad de protección.

2. REQUISITOS PARA INDICADORES DE SEGURIDAD

2.1. Indicadores de seguridad

2.1.1. La lista de indicadores para las clases de seguridad SVT se proporciona en la tabla.

Designación:

« — «— no hay requisitos para esta clase;
» + » — requisitos nuevos o adicionales
» = » — los requisitos coinciden con los requisitos para el SVT de la clase anterior.

2.1.2. Los conjuntos de requisitos para indicadores de cada clase dados en esta sección son los mínimos requeridos.

2.1.3. La séptima clase está asignada a los SVT, que estaban sujetos a requisitos de protección contra el acceso no autorizado a la información, pero durante la evaluación, la seguridad de los SVT resultó ser inferior al nivel de requisitos de la sexta clase.

2.2. Requisitos para indicadores de seguridad de sexta clase.

2.2.1. Principio discrecional de control de acceso.

KZS debe controlar el acceso de sujetos designados (usuarios) a objetos designados (archivos, programas, volúmenes, etc.).

Para cada par (sujeto y objeto) en el SVT, se debe especificar una lista explícita e inequívoca de los tipos de acceso permitidos (lectura, escritura, etc.), es decir. aquellos tipos de acceso que están autorizados para un determinado sujeto (individuo o grupo de individuos) a un determinado recurso (objeto) SVT.

KZZ debe contener un mecanismo que implemente reglas de control de acceso discrecionales .

El control de acceso debe ser aplicable a cada objeto y a cada sujeto (individuo o grupo de individuos iguales).

Un mecanismo que implemente el principio discrecional del control de acceso debe prever la posibilidad de que una persona autorizada cambio en el PRD, incluida la posibilidad de cambio autorizado de la lista de usuarios de SVT y la lista de objetos protegidos.

El derecho a cambiar el PRD debe otorgarse a los sujetos designados (administración, servicio de seguridad, etc.).

2.2.2. Identificación y autenticación.

La DPC debería exigir a los usuarios que se identifiquen cuando soliciten acceso. El CPS debe verificar la autenticidad de la identificación — realizar la autenticación. El CPS deberá disponer de los datos necesarios para su identificación y autenticación. El sistema de protección de seguridad debe impedir el acceso a recursos protegidos por parte de usuarios no identificados y de usuarios cuya autenticidad de identificación no haya sido confirmada durante la autenticación.

2.2.3. Pruebas.

En el SVT de sexta clase se debe probar lo siguiente:

implementación de PRD discrecional (intercepción de solicitudes explícitas y ocultas, reconocimiento correcto de accesos autorizados y no autorizados solicitudes, medios de protección de acceso al mecanismo de delimitación, cambios autorizados al PRD);

implementación exitosa de la identificación y autenticación, así como sus medios de protección.

2.2.4. Guía del usuario.

La documentación del SVT debe incluir un breve manual de usuario que describa cómo utilizar el SVT y su interfaz con el usuario.

2.2.5. Manual CSZ.

Este documento está dirigido al administrador de seguridad y debe contener:

• descripción de las funciones controladas ;

• guía para generar CVS;

• descripción del inicio del SVT y procedimientos para comprobar la corrección del inicio.

2.2.6. Documentación de prueba.

Se debe proporcionar una descripción de las pruebas y pruebas a las que se sometió el SVT (de acuerdo con la cláusula 2.2.3.) y los resultados de las pruebas.

2.2.7. Documentación de diseño (proyecto).

Debe contener una descripción general de los principios de funcionamiento del SVT, el diagrama general del KSZ, una descripción de las interfaces del KSZ con el usuario. y las interfaces de las partes KSZ entre sí, una descripción de los mecanismos de identificación y autenticación.

2.3. Requisitos para indicadores de la quinta clase de seguridad.

2.3.1. Principio discrecional del control de acceso.

Estos requisitos incluyen requisitos similares de sexta clase (cláusula 2.2.1).

Adicionalmente se debe proporcionar controles que limitan la distribución de los derechos de acceso.

2.3.2. Borrando memoria.

Al asignar inicialmente o al redistribuir la memoria externa, el SSC debe impedir que el sujeto acceda a información residual.

2.3.3. Identificación y autenticación.

Estos requisitos coinciden completamente con requisitos similares de la sexta clase (cláusula 2.2.2).

2.3.4 . Garantías de diseño.

En la etapa inicial de diseño de un SVT, se debe construir un modelo de protección. El modelo debe incluir reglas generales para objetos y reglas consistentes para cambiar las reglas generales.

2.3.5. Registro.

El CPS debe poder registrar los siguientes eventos:

• uso de un mecanismo de identificación y autenticación;

• solicitud de acceso a un recurso protegido (abrir un archivo, ejecutar un programa, etc.);

• crear y destruir un objeto ;

• acciones para cambiar las reglas de tráfico.

Para cada una de En estos eventos se deberá registrar la siguiente información:

• fecha y hora;

• sujeto que realiza la acción que se registra;

• tipo de evento (si se registra una solicitud de acceso, el objeto y el tipo de acceso deben tenga en cuenta) ;

• si el evento ocurrió exitosamente (la solicitud de acceso fue atendida o no).

KZZ debe contener medios de revisión selectiva de la información de registro.

2.3.6. Integridad de la KSZ.

Los SVT de quinta clase de seguridad deben proporcionar medios para el monitoreo periódico de la integridad del software y las partes de información del CSZ.

2.3.7. Pruebas.

En SVT de la quinta clase de seguridad se debe probar lo siguiente:

• implementación del control de tráfico ( interceptación de solicitudes de acceso explícitas y ocultas, reconocimiento correcto de solicitudes autorizadas y no autorizadas, medios de protección del mecanismo de control de acceso, cambios autorizados en el DPR);

• implementación exitosa de la identificación y autenticación, así como sus medios de protección;

• borrado de memoria de acuerdo con la cláusula 2.3.2;

• registro de eventos de acuerdo con la cláusula 2.3.5, medios para proteger la información de registro y la posibilidad de revisión autorizada de la misma;

• funcionamiento del mecanismo que monitorea la integridad de la KSZ.

2.3.8. Guía del usuario.

Este requisito coincide con el requisito similar del sexto grado (cláusula 2.2.4).

2.3.9. Manual CSZ.

Este documento está dirigido al administrador de seguridad y debe contener:

• descripción de las funciones controladas ;

• orientación para generar KSZ;

• descripciones del inicio del SVT, procedimientos para comprobar la corrección del inicio, procedimientos de trabajo con herramientas de registro.

2.3.10. Documentación de prueba.

Se debe proporcionar una descripción de las pruebas y pruebas a las que se sometió el SVT (de acuerdo con los requisitos de la cláusula 2.3.7) y los resultados de las pruebas.

2.3.11 . Documentación de diseño y proyecto.

Debe contener:

• descripción de los principios de funcionamiento del SVT;

• diagrama general de KSZ;

• descripción de las interfaces de KSZ con el usuario y interfaces de los módulos KSZ;

• modelo de protección;

• descripción de los mecanismos para monitorear la integridad del SSC, borrado de memoria, identificación y autenticación.

2.4. Requisitos para indicadores de la cuarta clase de seguridad.

2.4.1. Principio discrecional del control de acceso.

Estos requisitos incluyen requisitos similares de la quinta clase (cláusula 2.3.1).

Además, el CPS debe contener un mecanismo que implemente reglas de acción discrecionales, tanto para acciones explícitas del usuario como para acciones ocultas, garantizando así la protección de los objetos contra el acceso no autorizado (es decir, contra el acceso que no está permitido desde el punto de vista de una regla determinada). ). Por “explícito” nos referimos a acciones llevadas a cabo utilizando herramientas del sistema — macros del sistema, instrucciones de lenguaje de alto nivel, etc., y en “oculto” — otras acciones, incluido el uso de sus propios programas para trabajar con dispositivos.

Las reglas de tráfico discrecionales para sistemas de esta clase se suman a las reglas de tráfico obligatorias.

2.4.2. Principio obligatorio de control de acceso.

Para implementar este principio, se deben comparar las etiquetas de clasificación de cada sujeto y de cada objeto, reflejando su lugar en la jerarquía correspondiente. A través de estas etiquetas se deben asignar niveles de clasificación a sujetos y objetos (niveles de vulnerabilidad, categorías de privacidad, etc.), que son combinaciones de categorías jerárquicas y no jerárquicas. Estas etiquetas deben servir como base para el principio obligatorio de control de acceso.

Al ingresar nuevos datos al sistema, el CPS debe solicitar y recibir etiquetas de clasificación para estos datos del usuario autorizado. . Cuando se autoriza la adición de un nuevo sujeto a la lista de usuarios, se deben comparar las etiquetas de clasificación con él. Las etiquetas de clasificación externas (de sujetos, objetos) deben corresponder exactamente a las etiquetas internas (dentro del CSC).

El CPS debe implementar el principio obligatorio de control de acceso en relación con todos los objetos con acceso explícito y oculto por parte de cualquiera de los sujetos:

un sujeto puede leer un objeto sólo si la clasificación jerárquica en el nivel de clasificación del sujeto no es menor que la clasificación jerárquica en el nivel de clasificación de objetos, y las categorías no jerárquicas en el nivel de clasificación de sujetos incluyen todas las categorías jerárquicas en el nivel de clasificación de objetos;

un sujeto escribe en un objeto solo si el nivel de clasificación del sujeto en la clasificación jerárquica no es mayor que el nivel de clasificación del objeto en la clasificación jerárquica, y todas las categorías jerárquicas en el nivel de clasificación del sujeto están incluidas en categorías no jerárquicas en el nivel de clasificación del objeto .

La implementación de normas viales obligatorias debe prever la posibilidad de apoyo: cambios en los niveles de clasificación de objetos y objetos por parte de sujetos especialmente designados.

Se debe implementar un administrador de acceso en el SVT, es decir. una herramienta que intercepta todas las solicitudes de sujetos a objetos, así como el control de acceso de acuerdo con el principio de control de acceso especificado. Al mismo tiempo, solo se debe tomar una decisión sobre la autorización de una solicitud de acceso si está autorizada simultáneamente por los DRP discrecionales y obligatorios. Por tanto, no sólo se debe controlar un único acto de acceso, sino también los flujos de información.

2.4.3. Borrado de la memoria.

Cuando se asigna inicialmente o al redistribuir la memoria externa, el KSZ debería dificultar que el sujeto acceda a la información residual. Al redistribuir la RAM, el KSZ debe limpiarla.

2.4.4. Aislamiento de módulos.

Si hay multiprogramación en el SVT en el KSZ, debe haber un mecanismo de software y hardware que aísle los módulos de programa de un proceso (un sujeto) de los módulos de programa de otros procesos (otros sujetos) — aquellos. en la RAM del ordenador se deben proteger los programas de diferentes usuarios entre sí.

2.4.5. Marcado de documentos.

Al mostrar información protegida en un documento, se coloca el sello No. 1 al principio y al final y sus detalles se completan de acuerdo con la Instrucción No. 0126-87 ( cláusula 577).

2.4.6. Protección de entrada y salida a medios de almacenamiento físico enajenados.

El CPS debe distinguir cada dispositivo de entrada/salida y cada canal de comunicación como utilizados o identificados aleatoriamente (“etiquetados”). Al ingresar desde un dispositivo «etiquetado» (salida a un dispositivo «etiquetado»), el CPS debe garantizar la correspondencia entre la etiqueta del objeto de entrada (salida) (nivel de clasificación) y la etiqueta del dispositivo. Se debe garantizar el mismo cumplimiento cuando se trabaja con un canal de comunicación “etiquetado”.

Los cambios en el propósito y diseño de los dispositivos y canales deben realizarse únicamente bajo el control de la KSZ.

2.4.7. Relacionar un usuario con un dispositivo.

El KSZ debe proporcionar información de salida al dispositivo solicitado por el usuario, tanto para los dispositivos utilizados aleatoriamente como para los identificados (si las marcas coinciden).

El CPS identificado debe incluir un mecanismo mediante el cual un usuario autorizado esté asociado de manera confiable con un dispositivo dedicado.

2.4.8. Identificación y autenticación.

La CPS debe exigir a los usuarios que se identifiquen al realizar solicitudes de acceso, debe verificar la autenticidad del ID del sujeto — realizar la autenticación. El CPS debe disponer de los datos necesarios para la identificación y autenticación e impedir la entrada al SVT de un usuario no identificado o cuya autenticidad no ha sido confirmada.

El CSS debe poder asociar de manera confiable la identificación recibida con todas las acciones de un usuario determinado.

2.4.9. Garantías de diseño.

El diseño de la CSZ debe comenzar con la construcción de un modelo de protección que contenga:

PRD consistente;

reglas consistentes para cambiar las reglas de tráfico;

reglas para trabajar con dispositivos de entrada y salida y canales de comunicación.

2.4.10. Registro.

Estos requisitos incluyen requisitos similares de la quinta clase de seguridad (cláusula 2.3.5). Además, se debe proporcionar el registro de todos los intentos de acceso, todas las acciones del operador y de los usuarios designados (administradores de seguridad, etc.).

2.4.11. Integridad de la KSZ.

En el SVT de cuarta clase de seguridad, se debe realizar un control periódico de la integridad de la KSZ.

Los programas KSZ deben ejecutarse en una parte separada de la RAM

2.4.12. Pruebas.

En la cuarta clase de seguridad, se debe probar lo siguiente:

implementación de PRD (interceptación de solicitudes de acceso, reconocimiento correcto de solicitudes autorizadas y no autorizadas de acuerdo con reglas discrecionales y obligatorias, coincidencia correcta de etiquetas de sujetos y objetos, solicitud de etiquetas de información recién ingresada, medios de protección del mecanismo de control de acceso, cambio autorizado en el PRD);

imposibilidad para el sujeto de asignar nuevos derechos a sí mismo;

limpieza de RAM y memoria externa;

funcionamiento del mecanismo de aislamiento de procesos en RAM;

marcado de documentos;

protección de la salida y transferencia de información a medios físicos enajenados y la comparación de un usuario con un dispositivo;

identificación y autenticación, así como sus medios de protección;

prohibición de acceso por parte de un usuario no autorizado;

operación de un mecanismo que monitorea la integridad de los equipos electrónicos;

registro de los eventos descritos en la cláusula 2.4.10, medios para proteger la información de registro y la posibilidad de revisión autorizada de esta información.

2.4.13. Guía del usuario.

Este requisito coincide con el requisito similar de las clases sexta (cláusula 2.2.4) y quinta (cláusula 2.3.8).

2.4.14. Manual de KSZ.

Estos requisitos coinciden completamente con requisitos similares de la quinta clase (cláusula 2.3.9).

2.4.15. Documentación de prueba.

Se debe proporcionar una descripción de las pruebas y pruebas a las que se sometió el SVT (de acuerdo con la cláusula 2.4.12) y los resultados de las pruebas.

2.4.16. Documentación de diseño (proyecto).

Debe contener:

descripción general de los principios operativos del SVT;

diagrama general de KSZ;

descripción de las interfaces externas de KSZ e interfaces de los módulos KSZ;

descripción del modelo de protección;

descripción del administrador de acceso;

descripción del mecanismo para monitorear la integridad de la CSZ;

descripción del mecanismo de limpieza de memoria;

descripción del mecanismo para aislar programas en RAM;

descripción de los medios para proteger la entrada y la salida a medios de almacenamiento físico alienados y que relacionan al usuario con el dispositivo;

descripción del mecanismo de identificación y autenticación;

descripción de los medios de registro.

2.5. Requisitos para indicadores de la tercera clase de seguridad.

2.5.1. Principio discrecional del control de acceso.

Estos requisitos coinciden completamente con los requisitos de las clases quinta (cláusula 2.3.1) y cuarta (cláusula 2.4.1).

2.5.2. Principio obligatorio de control de acceso.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.2).

2.5 .3. Borrando memoria.

Para SVT de tercera clase de seguridad, el KSZ debe borrar la RAM y la memoria externa. La limpieza debe realizarse escribiendo información de enmascaramiento en la memoria cuando se libera (redistribuye).

2.5.4. Aislamiento de módulos.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.4).

2.5.5 . Marcado de documentos.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.5).

2.5.6. Protección de entrada y salida a medios de almacenamiento físico enajenados.

Estos requisitos coinciden plenamente con el requisito similar de la cuarta clase (cláusula 2.4.6).

2.5.7. Relacionar un usuario con un dispositivo.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.7).

2.5.8. Identificación y autenticación.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.8).

2.5.9. Garantías de diseño.

En la etapa inicial de diseño de la CSZ, se debe construir un modelo de seguridad que especifique el principio de control de acceso y el mecanismo de control de acceso. Este modelo debe contener:

reglas consistentes para cambiar el PRD;

reglas para trabajar con dispositivos de entrada y salida;

un modelo formal del mecanismo de control de acceso.

Se debería proponer una especificación de alto nivel de la parte de la CPS que implementa el mecanismo de control de acceso y sus interfaces. Se debe verificar que esta especificación cumpla con los principios de control de acceso especificados.

2.5.10. Registro.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.10).

2.5.11. Interacción del usuario con KSZ.

Para asegurar la posibilidad de estudio, análisis, verificación y modificación, la DPC debe estar bien estructurada, su estructura debe ser modular y claramente definida. Se debe definir la interfaz del usuario y el VAS (iniciar sesión en el sistema, solicitudes de usuario y el VAS, etc.). Debe garantizarse la fiabilidad de dicha interfaz. Cada interfaz de usuario y CPS debe estar lógicamente aislado de otras interfaces similares.

2.5.12. Recuperación confiable

Los procedimientos de recuperación después de fallas y fallas de los equipos deben garantizar la restauración completa de las propiedades de la CSZ.

2.5.13. Integridad del CVS.

Es necesario monitorear periódicamente la integridad del CVS.

Los programas deben ejecutarse en una parte separada del la RAM. Este requisito deberá ser verificado.

2.5.14. Pruebas.

El SVT debe someterse a las mismas pruebas que el SVT de cuarta clase (cláusula 2.4.12).

Adicionalmente, el Se debe probar lo siguiente:

borrado de memoria (cláusula 2.5.3);

funcionamiento del mecanismo de recuperación confiable.

2.5. 15 . Guía del usuario.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.4.13).

2.5.16. Guía CSZ.

El documento está dirigido al administrador de protección y debe contener:

descripción de las funciones controladas;

guía para generar KSZ;

descripción del inicio de SVT, procedimientos para verificar la corrección del inicio, procedimientos para trabajar con herramientas de registro;

guía de herramientas de recuperación confiables.

2.5.17. Documentación de pruebas

La documentación debe contener una descripción de las pruebas y ensayos a los que fue sometido el SVT (cláusula 2.5.14), así como los resultados de las pruebas.

2.5.18. Documentación de diseño (proyecto).

Se requiere la misma documentación que para la CVT de cuarta clase (cláusula 2.4.16). Además se requiere:

especificación de alto nivel de KSZ y sus interfaces;

verificación del cumplimiento de la especificación de alto nivel de KSZ con el modelo de protección.

2.6. Requisitos para indicadores de segunda clase de seguridad.

2.6.1. Principio discrecional del control de acceso.

Estos requisitos incluyen requisitos similares de la tercera clase (cláusula 2.5.1).

Además, se requiere que las reglas de control de acceso discrecional sean equivalentes a las reglas obligatorias (es decir, cualquier solicitud de acceso debe estar autorizada o no autorizada simultáneamente según las reglas discrecionales y el DRP obligatorio).

2.6.2. Principio obligatorio de control de acceso.

Estos requisitos coinciden completamente con el requisito similar de la tercera clase (cláusula 2.5.2).

2.6 .3. Borrando memoria.

Estos requisitos coinciden completamente con el requisito similar de la tercera clase (cláusula 2.5.3).

2.6.4. Aislamiento de módulos.

Si hay multiprogramación en el SVT en el KSZ, debe haber un mecanismo de software y hardware que aísle los módulos de programa de un proceso (un sujeto) de los módulos de programa de otros procesos (otros sujetos) — aquellos. En la RAM de la computadora, los programas de diferentes usuarios deben estar aislados entre sí. Las garantías de aislamiento deben basarse en la arquitectura SVT.

2.6.5. Marcado de documentos.

Estos requisitos coinciden completamente con el requisito similar de la cuarta clase (cláusula 2.5.5).

2.6.6 . Protección de entrada y salida a medios de almacenamiento físico enajenados.

Estos requisitos coinciden plenamente con el requisito similar de la tercera clase (cláusula 2.5.6).

2.6.7. Asignar un usuario a un dispositivo.

Estos requisitos coinciden completamente con requisitos similares de las clases cuarta (cláusula 2.4.7) y tercera (cláusula 2.5.7).

2.6.8. Identificación y autenticación.

El requisito coincide completamente con el requisito similar de la cuarta (cláusula 2.4.8) y tercera (cláusula 2.5.8) clases.

2.6.9. Garantías de diseño.

Estos requisitos incluyen requisitos similares de tercera clase (cláusula 2.5.9).

Además, se requiere que las especificaciones de alto nivel del SSC se mapeen secuencialmente en la especificación de uno o más niveles inferiores, hasta la implementación de la especificación de alto nivel del SSC en un lenguaje de programación de alto nivel. En este caso, se deben utilizar métodos de verificación para demostrar el cumplimiento de cada mapeo con especificaciones de alto nivel (superior para este mapeo). Este proceso puede implicar un mapeo único (una especificación de alto nivel: lenguaje de programación) o una secuencia de mapeos a especificaciones intermedias hasta un lenguaje de programación. Como resultado de verificar el cumplimiento de cada nivel con el anterior, se debe lograr el cumplimiento de la implementación de la especificación de alto nivel del modelo de protección mostrado en el dibujo (ver Fig. Diagrama del modelo de protección).

2.6.10. Registro.

Estos requisitos coinciden completamente con requisitos similares de la cuarta (cláusula 2.4.10) y tercera (cláusula 2.5.10) clases.

2.6.11. Interacción del usuario con la KSZ.

Estos requisitos coinciden completamente con el requisito similar de la tercera clase (cláusula 2.5.11).

2.6 .12. Recuperación confiable.

Estos requisitos coinciden completamente con el requisito similar de la tercera clase (cláusula 2.5.12).

2.6.13. Integridad de la KSZ.

Estos requisitos coinciden completamente con el requisito similar de la tercera clase (cláusula 2.5.13).

2.6. 14. Control de modificaciones.

Al diseñar, construir y mantener el SVT, se debe proporcionar gestión de la configuración del SVT, es decir. control de cambios en el modelo formal, especificaciones (a diferentes niveles), documentación, texto fuente, versiones de código objeto. Debe garantizarse la coherencia entre la documentación y los textos del programa. Las versiones generadas deben ser comparables. Se deben proteger los originales de los programas.

2.6.15. Control de distribución.

La precisión de la copia debe controlarse en el SVT al realizar copias de una muestra. Se debe garantizar que la copia producida repita la muestra.

2.6.16. Pruebas.

El SVT de segunda clase debe probarse de la misma manera que el SVT de tercera clase (cláusula 2.5.14).

Además, se deberá comprobar el control de distribución.

2.6.17. Guía del usuario.

Estos requisitos coinciden completamente con requisitos similares de las clases cuarta (cláusula 2.4.13) y tercera (cláusula 2.5.15).

2.6.18. Manual sobre KSZ.

Estos requisitos incluyen requisitos similares de tercera clase (cláusula 2.5.16).

Además, directrices sobre restauración confiable , sobre el trabajo con herramientas de control de modificación y distribución.

2.6.19. Documentación de prueba.

Se deberá proporcionar una descripción de las pruebas y ensayos a los que fue sometido el SVT (cláusula 2.6.16), así como los resultados de las pruebas.

2.6.20. Documentación de diseño (proyecto).

Se requiere la misma documentación que para el SVT de tercera clase (cláusula 2.5.18).

Adicionalmente la Se deben describir las garantías del proceso de diseño y la equivalencia de los DRP discrecionales (cláusula 2.6.1) y obligatorios (cláusula 2.6.2).

2.7. Requisitos para indicadores de primera clase de seguridad.

2.7.1. Principio discrecional del control de acceso.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.1).

2.7.2. Principio obligatorio de control de acceso.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.2).

2.7 .3. Borrar memoria.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.3).

2.7.4. Aislamiento de módulos.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.4).

2.7.5. Marcado de documentos.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.5).

2.7.6 . Protección de entrada y salida a medios de almacenamiento físico enajenados.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.6).

2.7.7. Asignar un usuario a un dispositivo.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.7).

2.7.8. Identificación y autenticación.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.8).

2.7.9 . Garantías de diseño.

Estos requisitos incluyen requisitos similares de segunda clase (cláusula 2.6.9).

Adicionalmente, la verificación del cumplimiento de las Se requiere código objeto con el texto KSZ en un lenguaje de alto nivel.

2.7.10. Registro.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.10).

2.7.11. Interacción del usuario con la KSZ.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.11).

2.7 .12. Recuperación confiable.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.12).

2.7.13. Integridad de la KSZ.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.13).

2.7.14. Control de modificaciones.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.14).

2.7.15. Control de distribución.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.15).

2.7.16. Garantías de arquitectura.

La CSZ debe tener un mecanismo que asegure que el administrador de acceso intercepte todas las solicitudes de sujetos a objetos.

2.7.17. Pruebas.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.16).

2.7.18. Manual de usuario.

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.17).

2.7.19. Manual sobre KSZ

Estos requisitos coinciden completamente con el requisito similar de la segunda clase (cláusula 2.6.18).

2.7.20. Documentación de prueba

Estos requisitos coinciden completamente con requisitos similares de la segunda clase (cláusula 2.6.19).

2.7.21. Documentación de diseño (proyecto)

Se requiere la misma documentación que para el SVT de segunda clase (cláusula 2.6.20).

En desarrollo adicional descripción de las garantías del proceso de diseño (cláusula 2.7.9).

3. EVALUACIÓN DE LA CLASE DE SEGURIDAD DE SVT (CERTIFICACIÓN DE SVT)

La evaluación de la clase de seguridad de SVT se lleva a cabo de acuerdo con el Reglamento sobre certificación de equipos informáticos y sistemas de comunicación de acuerdo con los requisitos de seguridad de la información, Reglamento Temporal sobre la organización del desarrollo, producción y operación de software y hardware para proteger la información del acceso no autorizado en sistemas automatizados y equipos informáticos y otros documentos.