El guardia de seguridad aprende OUD. Aplicación de EUD en sistemas automatizados de control de procesos. Parte 1 (Asignación de seguridad)

1. ¿Por qué?

Artículo (posteriormente una serie de artículos) está dedicado al desarrollo gradual y la aplicación del desarrollo seguro en el campo de los sistemas automatizados de control de procesos. Esta parte habla de la proyección de la metodología para desarrollar una especificación de seguridad (Serie GOST 15 408) para un área donde rara vez (todavía) se usa (saco una conclusión sobre su rareza basándose en mi participación en las pruebas de una amplia gama de productos para sistemas industriales).

OUD se ha vuelto muy popular en la infraestructura del ámbito de actividad del Regulador Bancario y el procedimiento para la certificación de medios de seguridad de la información del FSTEC de Rusia. La probabilidad de su aplicación en el campo de la CII y los sistemas automatizados de control de procesos aumenta cada año y, tarde o temprano, este tema se volverá relevante para los desarrolladores de sistemas de automatización industrial y sistemas de control automatizados.

Según GOST 15 408-3, la fase de OUD implica comenzar con el desarrollo de la documentación para el software en estudio, pero como ha demostrado nuestra práctica, no hay nada de esto. Por lo tanto, pasamos involuntariamente a la etapa de preparación para las pruebas de software, que implica preparar una tarea de seguridad.

Intentaré no cargar con toda la exposición de todo el proceso a la vez (da mucho miedo allí). Por ahora, comencemos sólo con la etapa “Asignación de seguridad”. Las etapas restantes las consideraremos más adelante….. Acompañaré las etapas correspondientes con los resultados obtenidos en base al ejemplo abstracto que se está estudiando.

2. Hoja de ruta

Primero, creemos una hoja de ruta para la etapa que estamos considerando.

3. Examen

El examen es la parte más difícil. Si tiene que trabajar en varias iteraciones, como en la figura anterior, prepárese para el hecho de que la obtención de datos se realizará en varias iteraciones, y tener un especialista que sepa chatear (entrevistar a los desarrolladores) será una gran ventaja. Luego de recibir los primeros datos iniciales sobre el sistema, es necesario comenzar inmediatamente a identificar los siguientes paradigmas para determinar el objeto de evaluación:

Parte 1.

1. ¿Por qué necesita una OO (debe comprender el significado de su investigación)?

2. Definición de módulos (microservicios o procesos individuales);

3. Determinación de componentes de software (clientes, aplicaciones móviles, portales web, paquetes de software, SO). Conviene denotar esto por subsistemas;

4. Las herramientas necesarias para desarrollar y soportar la OO, esto también puede incluir sistemas operativos y paquetes de software;

5. Definir modelos a seguir de usuarios y cuentas técnicas;

6. Determinar la naturaleza de los datos transmitidos (PDN, datos tecnológicos, secretos comerciales, etc.) y protocolos de transmisión de datos;

Nos limpiamos el sudor, tomamos unas pastillas para los nervios y fuimos a dibujar un diagrama estructural, registrando lo siguiente:

Parte 2.

1. Designamos funciones de gestión;

2. Designamos funciones de seguimiento;

3. Posibilidad de transmisión/recopilación de datos y dirección de transmisión/recopilación;

4. Capacidad para procesar datos;

5. Descripción de los SFR existentes.

Para todas las funciones implementadas, solicitamos inmediatamente a los desarrolladores que demuestren de forma explícita el funcionamiento de los componentes.

Ejemplo

Parte 1.

1. El servidor instalado en el sistema automatizado de control de procesos LAN recopila datos tecnológicos en las instalaciones de CII.

2. Microservicios: PSQL15, nginx, frontend-service (desarrollo propio del cliente en python). FreeOpcUa es un servicio independiente instalado en el servidor OO, un conjunto de bibliotecas para el trabajo OPC. La conexión del usuario se realiza a través de un navegador WEB. Recogida de datos tecnológicos mediante SNMP/OPC UA.

3. Clientes (fuentes de datos tecnológicos), Usuarios que utilizan el portal WEB, el propio Servidor. Servidor de autorización de usuario, servidor de seguimiento del cliente (el seguimiento se realiza mediante SNMP/PING).

4. El lenguaje utilizado es Python, lo que implica la presencia de bibliotecas apropiadas en OO. El sistema operativo utilizado es Astra Linux SE/CE versión 1.6 y superior. Un navegador web para acceder al TOE desde el lado del usuario. El administrador del sistema operativo ejerce el control mediante SSH y la interfaz GUI del sistema operativo, la administración del paquete de software se lleva a cabo localmente (físicamente),

5. Operador de sistema de control de procesos automatizado; ingeniero de sistemas de control industrial; Auditor de SI.

6. Datos tecnológicos de sistemas automatizados de control de procesos, OPC UA.

Parte 2.

Mostramos los datos obtenidos de los puntos 1-4 de la Parte No. 2.

5.A continuación es necesario describir todos los SFR, pero por ejemplo indicaré solo dos:

4. Declaración de conformidad

Decidimos los GOST que se utilizarán, aprobamos el perfil de seguridad utilizado o, más simplemente, decidimos por qué indicadores nos esforzamos y qué conjunto de documentos generaremos realmente. Además, en Internet se encontró un PERFIL DE PROTECCIÓN para FIREWALLS TIPO “D” DE LA SEXTA CLASE DE PROTECCIÓN de 2016, que probablemente utilizó la FSTEC de Rusia para la certificación, a pesar de que allí se presentó OUD.1, se decidió ir según OUD.4 de -debido a la popularidad de este nivel y debido a las peculiaridades de la política regulatoria en el campo de las ICI y el cliente.

Ejemplo:

El objeto de evaluación y el ST se desarrollan de acuerdo con:

– GOST R ISO/IEC 15408-2;
– GOST R ISO/IEC 15408-3;
– Orden FSTEC nº 239;
– Requisitos internos del cliente.

Los requisitos de confianza se presentan en forma de nivel de confianza estimado (EAL4).

5. Identificación de amenazas

Los colegas del sector bancario utilizan activamente las amenazas del perfil de protección según el documento metodológico “Perfil de protección de software de aplicaciones de sistemas automatizados y aplicaciones de instituciones de crédito e instituciones financieras sin crédito”. Pero la metodología utilizada no es cercana a nosotros, por lo que intentamos formar amenazas del FSTEC BDU y, en base al modelo generado, determinar las medidas de protección propuestas.

Se decidió tomar un camino un poco más “moderno” para crear amenazas, así como las medidas de protección utilizadas fueron determinadas por Recurso FSTEC.

Ejemplo:

En total, recibí una lista de medidas (enumeré solo algunas de ellas para mayor claridad):
AVZ.1.5 Verificar, casi en tiempo real, objetos (archivos) de fuentes externas (medios de almacenamiento de computadora extraíbles, conexiones de red, incluidas redes públicas y otras fuentes externas) al cargar, abrir o ejecutar dichos archivos;
AVZ.2.1 Aplicación de herramientas de protección antivirus en servidores proxy, gateways de correo, servidores de correo y otros puntos de acceso al sistema de información que sean susceptibles de introducción (infección) por programas informáticos maliciosos (virus) a través de medios de almacenamiento informáticos extraíbles o conexiones de red. , incluidas las redes de uso público (archivos adjuntos de correo electrónico, servicios web y otros servicios de red);
AVZ.3.1 Verificación en una escala de tiempo cercana al tiempo real de objetos (archivos) archivados, ejecutables y cifrados al cargar, abrir o ejecutar dichos archivos;
…………………….

UPD.4.1 Separación de poderes (roles) de los usuarios, administradores y personas que aseguran el funcionamiento del sistema de información de acuerdo con sus responsabilidades (funciones) laborales. Definición en documentos organizativos y administrativos sobre protección de la información (documentación) de las competencias (roles) de los usuarios, administradores y personas que aseguran el funcionamiento del sistema de información”.

6. Obtenemos el pliego de especificaciones técnicas definitivo

Comparamos el TSF real con las medidas de seguridad alcanzables y listo, obtenemos el conjunto final de TSF. (No olvides agregar el tuyo propio)

Ejemplo (enumeré solo algunos):

7. Conclusión

Recibí la conclusión final del FTB requerida para su implementación. Conclusiones básicas que se extrajeron:

1. GOST 15 408 es algo complejo, incomprensible, turbio, pero genial… no es sabroso, pero lo recomiendo.

2. Las amenazas y los objetivos de seguridad del perfil de protección pueden equipararse fácilmente a las amenazas y medidas del FSTEC.

3. Necesita agregar su FTB debido a las peculiaridades del sistema de control automatizado de procesos (algunas de ellas):

• FTB_001: Requisitos reforzados para la compatibilidad con SIEM (syslog cef);

• FTB_002: Requisito de compatibilidad con un sistema operativo certificado;

• FTB_003: Disponibilidad de soporte técnico para la solución;

• FTB_004: Compatibilidad con soluciones ACS Anti-Virus.

8. Lista de términos y abreviaturas

Bibliografía