Seguridad de la información de los pagos bancarios sin efectivo. Parte 8 - Modelos de amenaza típicos

¿De qué trata el estudio?


Este artículo completa la serie de publicaciones dedicadas a garantizar la seguridad de la información de los pagos bancarios sin efectivo. Aquí observamos los modelos de amenazas típicos a los que se hizo referencia en el modelo base :

• Un modelo de amenaza típico. Conexión de red .
• Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor .
• Un modelo de amenaza típico. Sistema de control de acceso .
• Un modelo de amenaza típico. Módulo de integración .
• Un modelo de amenaza típico. Sistema de seguridad de la información criptográfica.

ADVERTENCIA DE PUERTO !!! Queridos Khabrovites, esta no es una publicación de entretenimiento.
Oculto bajo el corte, más de 40 páginas de materiales están diseñadas para ayudar a las personas especializadas en banca o para garantizar la seguridad de la información en el trabajo o el estudio . Estos materiales son el producto final del estudio y están escritos en un tono oficial seco. En esencia, estos son espacios en blanco para documentos internos sobre seguridad de la información.

Bueno, el tradicional es "el uso de la información de un artículo con fines ilegales es punible por ley" . Lectura productiva!

Información para lectores que estén familiarizados con el estudio, comenzando con esta publicación.

¿De qué trata el estudio?

Está leyendo una guía para el especialista responsable de garantizar la seguridad de la información de los pagos en el banco.

Lógica de presentación

Al principio, la parte 1 y la parte 2 describen el objeto de protección. Luego, en la parte 3, describimos cómo construir un sistema de seguridad y analiza la necesidad de un modelo de amenaza. La Parte 4 discute qué modelos de amenaza existen y cómo se forman. La parte 5 y la parte 6 proporcionan un análisis de ataques reales. La Parte 7 y la Parte 8 contienen una descripción del modelo de amenaza, construido teniendo en cuenta la información de todas las partes anteriores.

MODELO DE AMENAZA TÍPICA. CONEXION DE RED

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

El objeto de protección son los datos transmitidos a través de una conexión de red que opera en redes de datos construidas sobre la base de la pila TCP / IP.

Arquitectura



Descripción de los elementos de la arquitectura:

• "Nodos finales" : nodos que intercambian información protegida.
• “Nodos intermedios” : elementos de una red de transmisión de datos: enrutadores, conmutadores, servidores de acceso, servidores proxy y otros equipos, a través de los cuales se transmite el tráfico de conexión de red. En general, una conexión de red puede funcionar sin nodos intermedios (directamente entre nodos finales).

Amenazas de seguridad de nivel superior

Descomposición

U1. Familiarización no autorizada con los datos transmitidos.
U2 Modificación no autorizada de los datos transmitidos.
U3 Violación de la autoría de los datos transmitidos.

U1. Familiarización no autorizada con los datos transmitidos.

Descomposición
U1.1. <...> realizado al final o nodos intermedios:
U1.1.1. <...> leyendo datos mientras está en los dispositivos de almacenamiento del nodo:
U1.1.1.1. <...> en RAM.
Explicaciones a U1.1.1.1.
Por ejemplo, durante el procesamiento de datos por la pila de red de un nodo.

U1.1.1.2. <...> en memoria no volátil.
Explicaciones a U1.1.1.2.
Por ejemplo, al almacenar datos transmitidos en un caché, archivos temporales o archivos de intercambio.

U1.2. <...> realizado en nodos de terceros de la red de datos:
U1.2.1. <...> por el método de capturar todos los paquetes que llegan a la interfaz de red del nodo:
Explicaciones a U1.2.1.
Todos los paquetes se capturan poniendo la tarjeta de red en modo promiscuo (modo promiscuo para adaptadores con cable o modo monitor para adaptadores wi-fi).

U1.2.2. <...> realizando ataques como "man in the middle (MiTM)", pero sin modificar los datos transmitidos (sin contar los datos de servicio de los protocolos de red).
U1.2.2.1. Enlace: “Un modelo de amenaza típico. Conexión de red. U2 Modificación no autorizada de los datos transmitidos " .

U1.3. <...>, realizado debido a la fuga de información a través de canales técnicos (TKUI) desde nodos físicos o líneas de comunicación.

U1.4. <...>, realizado para la instalación en el terminal o nodos intermedios de medios técnicos especiales (STS), destinados a la lectura secreta de información.

U2 Modificación no autorizada de los datos transmitidos.

Descomposición
U2.1. <...> realizado al final o nodos intermedios:
U2.1.1. <...> leyendo y haciendo cambios a los datos mientras están en los dispositivos de almacenamiento de los nodos:
U2.1.1.1. <...> en RAM:
U2.1.1.2. <...> en memoria no volátil:

U2.2. <...> realizado en nodos de terceros de la red de datos:
U2.2.1. <...> llevando a cabo ataques como "man in the middle (MiTM)" y redirigiendo el tráfico al sitio de intrusos:
U2.2.1.1. Conexión física del equipo intruso a una interrupción de la conexión de red.
U2.2.1.2. Implementación de ataques a protocolos de red:
U2.2.1.2.1. <...> gestión de red de área local virtual (VLAN):
U2.2.1.2.1.1. VLAN saltando .
U2.2.1.2.1.2. Modificación no autorizada de la configuración de VLAN en conmutadores o enrutadores.
U2.2.1.2.2. <...> enrutamiento de tráfico:
U2.2.1.2.2.1. Modificación no autorizada de las tablas de enrutamiento del enrutador estático.
U2.2.1.2.2.2. Anuncio por parte de estafadores de rutas falsas a través de protocolos de enrutamiento dinámico.
U2.2.1.2.3. <...> configuración automática:
U2.2.1.2.3.1. Rogue DHCP .
U2.2.1.2.3.2. Pícaro WPAD .
U2.2.1.2.4. <...> direccionamiento y resolución de nombres:
U2.2.1.2.4.1. Suplantación de ARP .
U2.2.1.2.4.2. Falsificación de DNS .
U2.2.1.2.4.3. Realizar cambios no autorizados en los archivos de nombres de host locales (hosts, lmhosts, etc.)

U3 Infracción de los derechos de autor de los datos transmitidos

Descomposición
U3.1. Neutralización de los mecanismos para determinar la autoría de la información al indicar información falsa sobre el autor o la fuente de datos:
U3.1.1. Cambio de información sobre el autor contenida en la información transmitida.
U3.1.1.1. Neutralización de la protección criptográfica de integridad y autoría de los datos transmitidos:
U3.1.1.1.1. Enlace: “Un modelo de amenaza típico. Sistema de seguridad de la información criptográfica.
U4. Creación de una firma electrónica de un firmante legítimo con datos falsos " .
U3.1.1.2. Neutralización de la protección de la autoría de los datos transmitidos implementados utilizando códigos de confirmación únicos:
U3.1.1.2.1. Intercambio de SIM .

U3.1.2. Cambio de información sobre la fuente de información transmitida:
U3.1.2.1. IP spoofing .
U3.1.2.2. Suplantación de identidad MAC .

---

MODELO DE AMENAZA TÍPICA. SISTEMA DE INFORMACIÓN CREADO SOBRE LA BASE DE LA ARQUITECTURA DEL SERVIDOR CLIENTE

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

El objeto de protección es un sistema de información construido sobre la base de la arquitectura cliente-servidor.

Arquitectura


Descripción de los elementos de la arquitectura:

• "Cliente" : un dispositivo en el que opera la parte del cliente del sistema de información.
• "Servidor" : un dispositivo en el que opera la parte del servidor del sistema de información.
• "Data Warehouse" es una parte de la infraestructura del servidor de un sistema de información diseñado para almacenar datos procesados ​​por un sistema de información.
• "Conexión de red" : un canal para el intercambio de información entre el Cliente y el Servidor, que pasa a través de una red de transmisión de datos. Se proporciona una descripción más detallada del modelo de elemento en el “Modelo de amenaza típico. Conexión de red " .

Limitaciones
Al modelar un objeto, se establecen las siguientes restricciones:

1. El usuario interactúa con el sistema de información dentro de intervalos de tiempo finitos, llamados sesiones de trabajo.
2. Al comienzo de cada sesión de trabajo, el usuario es identificado, autenticado y autorizado.
3. Toda la información protegida se almacena en el lado del servidor del sistema de información.

Amenazas de seguridad de nivel superior

Descomposición
U1. Los intrusos cometen acciones no autorizadas en nombre de un usuario legítimo.
U2 Modificación no autorizada de la información protegida durante su procesamiento por parte del servidor del sistema de información.

U1. La perpetración de acciones no autorizadas por parte de delincuentes en nombre de un usuario legítimo.

Explicaciones
Típicamente, en los sistemas de información, las acciones están asociadas con el usuario que las realizó usando:

1. registros de operación del sistema (registros).
2. atributos especiales de objetos de datos que contienen información sobre el usuario que los creó o cambió.

En relación con la sesión de trabajo, esta amenaza se puede descomponer en:

1. <...> realizado como parte de la sesión de trabajo del usuario.
2. <...> realizado fuera de la sesión de trabajo del usuario.

Se puede iniciar una sesión de usuario:

1. Por el usuario
2. Intrusos

En esta etapa, una descomposición intermedia de esta amenaza se verá así:
U1.1. Se realizaron acciones no autorizadas como parte de una sesión de usuario:
U1.1.1. <...> instalado por el usuario atacado.
U1.1.2. <...> instalado por los atacantes.
U1.2. Las acciones no autorizadas se realizan fuera de la sesión del usuario.

Desde el punto de vista de los objetos de infraestructura de información que pueden verse afectados por los atacantes, la descomposición de las amenazas intermedias se verá así:

Artículos	Descomposición de amenazas
	U1.1.1.	U1.1.2.	U1.2.
Cliente	U1.1.1.1.	U1.1.2.1.
Conexión de red	U1.1.1.2.
Servidor			U1.2.1.

Descomposición
U1.1. Se realizaron acciones no autorizadas como parte de una sesión de usuario:
U1.1.1. <...> instalado por el usuario atacado:
U1.1.1.1. Los atacantes actuaron independientemente del Cliente:
U1.1.1.1.1 Los atacantes utilizaron medios regulares de acceso al sistema de información:
U1.1.1.1.1.1. Los atacantes utilizaron la E / S física del cliente (teclado, mouse, monitor o pantalla táctil de un dispositivo móvil):
U1.1.1.1.1.1.1.1. Los atacantes actuaron en períodos de tiempo cuando la sesión está activa, las instalaciones de E / S están disponibles y el usuario no está en su lugar.
U1.1.1.1.1.2. Los atacantes utilizaron herramientas de administración remota (estándar o proporcionadas por código malicioso) para administrar el Cliente:
U1.1.1.1.1.2.1. Los atacantes actuaron en períodos de tiempo cuando la sesión está activa, las instalaciones de E / S están disponibles y el usuario no está en su lugar.
U1.1.1.1.1.2.2. Los atacantes utilizaron herramientas de administración remota, cuya operación es invisible para el usuario atacado.
U1.1.1.2. Los atacantes reemplazaron los datos en una conexión de red entre el Cliente y el Servidor, modificándolos para que fueran percibidos como acciones de un usuario legítimo:
U1.1.1.2.1. Enlace: “Un modelo de amenaza típico. Conexión de red. U2 Modificación no autorizada de los datos transmitidos " .
U1.1.1.3. Los atacantes obligaron al usuario a realizar las acciones indicadas por ellos utilizando métodos de ingeniería social.

U1.1.2 <...> establecido por los atacantes:
U1.1.2.1. Los atacantes actuaron desde el Cliente ( I ):
U1.1.2.1.1. Los atacantes neutralizaron el sistema de control de acceso del sistema de información:
U1.1.2.1.1.1. Enlace: “Un modelo de amenaza típico. Sistema de control de acceso. U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legal " .
U1.1.2.1.2. Los atacantes utilizaron herramientas estándar de acceso al sistema de información
U1.1.2.2. Los atacantes actuaron desde otros nodos de la red de datos desde los cuales puede establecer una conexión de red con el Servidor ( I ):
U1.1.2.2.1. Los atacantes neutralizaron el sistema de control de acceso del sistema de información:
U1.1.2.2.1.1. Enlace: “Un modelo de amenaza típico. Sistema de control de acceso. U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legal " .
U1.1.2.2.2. Los atacantes utilizaron herramientas de acceso al sistema de información anormales.
Explicaciones 1.1.1.2.2.2.
Los atacantes podrían instalar un cliente regular del sistema de información en un nodo de terceros o podrían utilizar un software anormal que implementa protocolos de intercambio estándar entre el Cliente y el Servidor.

U1.2 Las acciones no autorizadas se realizan fuera de la sesión del usuario.
D1.2.1 Los atacantes realizaron acciones no autorizadas y luego realizaron cambios no autorizados en los registros del sistema de información o atributos especiales de objetos de datos, lo que indica que las acciones que realizaron fueron realizadas por un usuario legítimo.

U2 Modificación no autorizada de la información protegida durante su procesamiento por parte del servidor del sistema de información

Descomposición
U2.1. Los atacantes modifican la información protegida utilizando las herramientas estándar del sistema de información y la llevan a cabo en nombre de un usuario legítimo.
U2.1.1. Enlace: “Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor. U1. La perpetración de acciones no autorizadas por delincuentes en nombre de un usuario legítimo " .

U2.2. Los atacantes modifican la información protegida mediante el uso de mecanismos de acceso a datos que no están previstos por el modo normal de funcionamiento del sistema de información.
U2.2.1. Los atacantes modifican archivos que contienen información protegida:
U2.2.1.1. <...> utilizando los mecanismos de manejo de archivos proporcionados por el sistema operativo.
U2.2.1.2. <...> provocando la restauración de archivos de una copia de seguridad modificada no autorizada.

U2.2.2. Los atacantes modifican la información protegida almacenada en la base de datos ( I ):
U2.2.2.1. Los atacantes neutralizan el sistema de control de acceso DBMS:
U2.2.2.1.1. Enlace: “Un modelo de amenaza típico. Sistema de control de acceso. U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legal " .
U2.2.2.2. Los atacantes modifican la información utilizando las interfaces DBMS estándar para acceder a los datos.

U2.3. Los atacantes modifican la información protegida mediante modificaciones no autorizadas de los algoritmos del software de procesamiento.
U2.3.1. Se realizan modificaciones al código fuente del software.
U2.3.1. Se realizan modificaciones al código de máquina del software.

U2.4. Los atacantes modifican la información protegida explotando vulnerabilidades en el software del sistema de información.

U2.5. Los atacantes modifican la información protegida durante su transferencia entre los componentes de la parte del servidor del sistema de información (por ejemplo, el servidor de la base de datos y el servidor de aplicaciones):
U2.5.1. Enlace: “Un modelo de amenaza típico. Conexión de red. U2 Modificación no autorizada de los datos transmitidos " .

---

MODELO DE AMENAZA TÍPICA. SISTEMA DE RESTRICCIÓN DE ACCESO

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

El objeto de protección para el cual se aplica este modelo de amenaza corresponde al objeto de protección del modelo de amenaza: “Modelo de amenaza típico. Un sistema de información basado en la arquitectura cliente-servidor ".

Bajo el sistema de restringir el acceso del usuario en este modelo de amenaza se entiende un componente del sistema de información que implementa las funciones:

1. Identificación del usuario
2. Autenticación de usuario.
3. Autorización de usuario.
4. Registro de acciones del usuario.

Amenazas de seguridad de nivel superior

Descomposición
U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legal.
U2 Escalada no autorizada de privilegios de usuario en el sistema de información.

U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legal

Explicaciones
La descomposición de esta amenaza en el caso general dependerá del tipo de identificación de usuario y sistema de autenticación utilizado.

En este modelo, solo se considerará un sistema de identificación y autenticación de usuario que utilice el inicio de sesión de texto y la contraseña. Al mismo tiempo, suponemos que el inicio de sesión del usuario es información pública conocida por los atacantes.

Descomposición
U1.1. <...> debido a credenciales comprometidas:
U1.1.1. Los atacantes comprometieron las credenciales del usuario durante el almacenamiento.
Explicaciones 1.1.1.1.
Por ejemplo, las credenciales podrían escribirse en una pegatina pegada al monitor.

U1.1.2. El usuario accidental o por intención maliciosa transfirió detalles de acceso a los atacantes.
U1.1.2.1. El usuario habló en voz alta las credenciales al ingresar.
U1.1.2.2. El usuario pasó intencionalmente sus credenciales:
U1.1.2.2.1. <...> a colegas.
Explicaciones U1.1.2.2.1.
Por ejemplo, para que puedan reemplazarlo con un período de enfermedad.

U1.1.2.2.2. <...> contrapartes patronales que realizan trabajos en instalaciones de infraestructura de información.
U1.1.2.2.3. <...> a terceros.
Explicaciones 1.1.1.2.2.3.
Una, pero no la única opción para implementar esta amenaza es el uso de métodos de ingeniería social por parte de los atacantes.

U1.1.3. Los atacantes obtuvieron credenciales por fuerza bruta:
U1.1.3.1. <...> utilizando mecanismos de acceso estándar.
U1.1.3.2. <...> por códigos previamente interceptados (por ejemplo, hash de contraseña) para almacenar credenciales.

U1.1.4.Los atacantes usaron código malicioso para interceptar las credenciales de los usuarios.

U1.1.5. Los atacantes extrajeron las credenciales de la conexión de red entre el Cliente y el Servidor:
U1.1.5.1. Enlace: “Un modelo de amenaza típico. Conexión de red. U1. Familiarización no autorizada con los datos transmitidos .

U1.1.6. Los atacantes extrajeron las credenciales de los registros de los sistemas de monitoreo del trabajo:
U1.1.6.1. <...> sistemas de videovigilancia (si durante la operación se grabaron las pulsaciones del teclado).
U1.1.6.2. <...> sistemas para monitorear las acciones de los empleados en la computadora
Explicaciones U1.1.6.2.
Un ejemplo de tal sistema es StuffCop .

U1.1.7. Los atacantes comprometieron las credenciales del usuario debido a fallas en el proceso de transferencia.
Explicaciones U1.1.7.
Por ejemplo, enviar contraseñas en texto claro por correo electrónico.

U1.1.8. Los atacantes aprendieron las credenciales al monitorear la sesión del usuario utilizando sistemas de administración remota.

U1.1.9. Los atacantes extrajeron las credenciales como resultado de su filtración a través de canales técnicos (TKUI):
1.1.9.1. Los atacantes vieron cómo el usuario ingresa las credenciales desde el teclado:
U1.1.9.1.1 Los atacantes se ubicaron muy cerca del usuario y vieron la entrada de credenciales con sus propios ojos.
Explicaciones U1.1.9.1.1
Tales casos incluyen las acciones de colegas en el trabajo o el caso en que el teclado del usuario es visible para los visitantes de la organización.

D1.1.9.1.2 Los atacantes utilizaron medios técnicos adicionales, como binoculares o un vehículo aéreo no tripulado, y vieron las credenciales ingresadas por la ventana.
U1.1.9.2. Los atacantes extrajeron las credenciales de los registros del intercambio de radio entre el teclado y la unidad del sistema de la computadora si estaban conectados a través de la interfaz de radio (por ejemplo, Bluetooth).
U1.1.9.3. Los atacantes interceptaron sus credenciales debido a su fuga a través del canal de radiación e interferencia electromagnética secundaria (PEMIN).
Explicaciones 1.1.1.3.
Ejemplos de ataques aquí y aquí .

U1.1.9.4. El atacante interceptó la entrada de credenciales desde el teclado mediante el uso de medios técnicos especiales (STS) diseñados para la recuperación de información tácita.
Explicaciones 1.1.1.4.
Ejemplos de dispositivos .

U1.1.9.5. Los atacantes interceptaron la entrada de credenciales desde el teclado
analizando la señal de Wi-Fi modulada por las pulsaciones de teclas del usuario.
Explicaciones U1.1.9.5.
Ejemplo ataque .

U1.1.9.6. Los atacantes interceptaron la entrada de credenciales desde el teclado mediante el análisis de los sonidos de las pulsaciones de teclas.
Explicaciones U1.1.9.6.
Ejemplo ataque .

U1.1.9.7. Los atacantes interceptaron la entrada de credenciales desde el teclado de un dispositivo móvil mediante el análisis de las lecturas del acelerómetro.
Explicaciones U1.1.9.7.
Ejemplo ataque .

U1.1.10. <...> previamente guardado en el Cliente.
Explicaciones U1.1.10.
Por ejemplo, un usuario podría guardar un nombre de usuario y contraseña en un navegador para acceder a un sitio específico.

U1.1.11. Los atacantes comprometieron sus credenciales debido a fallas en el proceso de revocación de acceso de usuarios.
Explicaciones 1.1.1.11.
Por ejemplo, después del despido del usuario, sus cuentas no fueron bloqueadas.

U1.2. <...> debido al uso de vulnerabilidades en el sistema de control de acceso.

U2 Escalada no autorizada de privilegios de usuario en el sistema de información

Descomponga
U2.1 <...> realizando cambios no autorizados en los datos que contienen información sobre los privilegios del usuario.

U2.2 <...> debido al uso de vulnerabilidades en el sistema de control de acceso.

U2.3. <...> debido a fallas en el proceso de control de acceso del usuario.
Explicaciones U2.3.
Ejemplo 1. Al usuario se le otorgó acceso al trabajo más de lo que necesitaba para las necesidades oficiales.
Ejemplo 2. Después de transferir a un usuario a otra posición, los derechos de acceso otorgados anteriormente no fueron revocados.

---

MODELO DE AMENAZA TÍPICA. MÓDULO DE INTEGRACIÓN

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

Módulo de integración: un conjunto de objetos de infraestructura de información diseñados para organizar el intercambio de información entre sistemas de información.

Dado que en las redes corporativas no siempre es posible separar inequívocamente un sistema de información de otro, el módulo de integración también puede considerarse como un enlace entre los componentes dentro del mismo sistema de información.

Arquitectura El
diagrama generalizado del módulo de integración es el siguiente:



Descripción de los elementos de la arquitectura:

• "Servidor de Exchange (CO)" : un nodo / servicio / componente de un sistema de información que realiza la función de intercambiar datos con otro sistema de información.
• «» – / , , .
  «» , (enterprise service bus / SoA-), .. «».
• « » – , .
  , , ..
• "Conexión de red" corresponde al objeto descrito en el modelo típico de amenaza de conexión de red. Algunas conexiones de red de las presentadas en el diagrama anterior pueden no existir.

Ejemplos de módulos de integración

Figura 1. Integración de ABS y AWS del CBD a través de un servidor de archivos de terceros

Para realizar pagos, un empleado bancario autorizado descarga documentos de pago electrónicos del ABS y los guarda en un archivo (de su propio formato, por ejemplo, volcado de SQL) en una carpeta de red (\\ ... \ COMPARTIR \) servidor de archivos. Luego, este archivo se convierte utilizando un convertidor de scripts en un conjunto de archivos del formato UFEBS, que luego son leídos por la estación de trabajo KBR.
Después de eso, un empleado autorizado, un usuario de AWS KBR, cifra y firma el archivo recibido y lo envía al sistema de pago del Banco de Rusia.

Al recibir los pagos del Banco de Rusia, AWS KBR los descifra y verifica la firma electrónica, y luego los escribe en forma de un conjunto de archivos en formato UFEBS en un servidor de archivos. Antes de importar documentos de pago al ABS, se convierten utilizando un convertidor de script del formato UFBS al formato ABS.

Asumimos que en este esquema el ABS opera en un servidor físico, el KBR AWS opera en una computadora dedicada y el convertidor de script se ejecuta en un servidor de archivos.



Correspondencia de los objetos del circuito considerado a los elementos del modelo de módulo de integración:
" Servidor de intercambio desde el lado ABS" - Servidor ABS.
"Exchange Server from AWP KBR" : computadora AWP KBR.
"Mediator" es un servidor de archivos de terceros.
"Software de procesamiento de datos"- convertidor de script.

Esquema 2. Integración de ABS y AWS KBR al colocar una carpeta de red compartida con pagos en AWS KBR

Todo es similar al Esquema 1, pero no se utiliza un servidor de archivos separado, en su lugar se encuentra una carpeta de red (\\ ... \ SHARE \) con documentos de pago electrónico computadora con AWS CBD. El convertidor de script también funciona en AWS KBR.



Correspondencia de los objetos del esquema considerado con los elementos del modelo del módulo de integración:
Similar al Esquema 1, pero no se utiliza el "Intermediario" .

Esquema 3. Integración de ABS y AWS KBR-N a través de IBM WebSphera MQ y firma de documentos electrónicos "en el lado del ABS"

ABS opera en una plataforma no compatible con la firma SKZI SCAD. La firma de los documentos electrónicos salientes se lleva a cabo en un servidor especial de firma electrónica (servidor ES). El mismo servidor verifica la firma electrónica de los documentos entrantes del Banco de Rusia.

ABS carga un archivo con documentos de pago en formato propietario en el servidor ES.
Usando el convertidor de script, el servidor ES convierte el archivo en mensajes electrónicos en formato UFBS, después de lo cual los mensajes electrónicos se firman y transmiten a IBM WebSphere MQ.

AWP KBR-N se pone en contacto con IBM WebSphere MQ y recibe mensajes de pago firmados desde allí, después de lo cual el empleado autorizado, usuario de AWP KBR, los cifra y los envía al sistema de pago del Banco de Rusia.

Al recibir los pagos del Banco de Rusia, AWP KBR-N los descifra y verifica la firma electrónica. Los pagos procesados ​​con éxito en forma de mensajes electrónicos descifrados y firmados en formato UFBS se transmiten a IBM WebSphere MQ, desde donde los recibe el servidor ES.

El servidor ES verifica la firma electrónica de los pagos recibidos y los guarda en un archivo de formato ABS. Después de eso, el empleado autorizado, el usuario del ABS, carga el archivo resultante en el ABS de la manera prescrita.



Correspondencia de los objetos del esquema considerado a los elementos del modelo de módulo de integración:
"Servidor Exchange desde el lado ABS" - Servidor ABS.
"Servidor de Exchange de AWP KBR" : computadora AWP KBR.
"Mediador" : servidor ES e IBM WebSphere MQ.
"Software de procesamiento de datos"- convertidor de script, firma SKZI SKAD en el servidor ES.

Esquema 4. Integración del servidor RBS y ABS a través de la API proporcionada por un servidor de intercambio dedicado.

Suponemos que el banco utiliza varios sistemas de servicios bancarios remotos (RBS):

• "Banco de clientes de Internet" para particulares (IKB FL);
• "Internet Client-Bank" para personas jurídicas (IKB YL).

Para garantizar la seguridad de la información, todas las interacciones de ABS con los sistemas bancarios remotos se llevan a cabo a través de un servidor de intercambio dedicado que opera dentro del marco del sistema de información de ABS.

A continuación, consideramos el proceso de interacción entre el sistema RB de IKB YuL y ABS.
El servidor RBS, después de haber recibido una orden de pago debidamente certificada del cliente, debe crear un documento apropiado en el ABS sobre la base. Para hacer esto, utilizando la API, transfiere información al servidor de intercambio y eso, a su vez, ingresa los datos en el ABS.

Cuando los saldos en la cuenta del cliente cambian, el ABS genera notificaciones electrónicas que se transmiten al servidor bancario remoto utilizando el servidor de intercambio.



Correspondencia de los objetos del circuito considerado a los elementos del modelo del módulo de integración:
"Servidor de Exchange por parte del sistema bancario remoto"- servidor DBO IKB YuL.
"Servidor de intercambio desde el lado del ABS" - servidor de intercambio.
"Intermediario" - está ausente.
"Software de procesamiento de datos" : componentes del servidor RBS responsables del uso de la API de Exchange Server, componentes del servidor de Exchange responsables del uso de la API ABS.

Amenazas de seguridad de nivel superior

Descomposición
U1. Los intrusos inyectan información fraudulenta a través de un módulo de integración.

U1. Atacar información fraudulenta a través de un módulo de integración

Descomposición
U1.1. Modificación no autorizada de datos legítimos cuando se transmite a través de conexiones de red:
U1.1.1 Enlace: "Modelo de amenaza típica. Conexión de red. U2 Modificación no autorizada de los datos transmitidos " .

U1.2. Transmisión de datos falsos a través de canales de comunicación en nombre de un participante de intercambio legítimo:
U1.1.2 Enlace: “Modelo de amenaza típico. Conexión de red. U3 Violación de la autoría de los datos transmitidos " .

U1.3. Modificación no autorizada de datos legítimos durante su procesamiento en los servidores de Exchange o el intermediario:
U1.3.1. Enlace:“Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor. U2 "Modificación no autorizada de la información protegida durante su procesamiento por parte del servidor del sistema de información" .

U1.4. Creación de datos falsificados en los servidores de Exchange o el intermediario en nombre de un participante de intercambio legítimo:
U1.4.1. Enlace: “Un modelo de amenaza típico. Un sistema de información construido sobre la base de la arquitectura cliente-servidor. U1. La perpetración de acciones no autorizadas por delincuentes en nombre de un usuario legítimo ".

U1.5. Modificación no autorizada de datos durante su procesamiento utilizando software de procesamiento de datos:
U1.5.1. <...> debido a cambios no autorizados en la configuración (configuración) del software de procesamiento de datos por parte de ciberdelincuentes.
U1.5.2. <...> debido a cambios no autorizados en archivos ejecutables de software de procesamiento de datos por parte de ciberdelincuentes.
U1.5.3. <...> debido al control interactivo por parte de los atacantes del software de procesamiento de datos.

---

MODELO DE AMENAZA TÍPICA. SISTEMA DE PROTECCIÓN CRIPTOGRÁFICA DE INFORMACIÓN

El objeto de protección para el cual se aplica el modelo de amenaza (alcance)

El objeto de protección es un sistema de protección de información criptográfica utilizado para garantizar la seguridad del sistema de información.

Arquitectura
La base de cualquier sistema de información es el software de aplicación (software) que implementa su funcionalidad objetivo.

En este caso, la protección criptográfica generalmente se implementa llamando primitivas criptográficas desde la lógica de negocios del software de la aplicación, que se encuentra en bibliotecas especializadas: núcleos criptográficos.

Las primitivas criptográficas incluyen funciones criptográficas de bajo nivel, tales como:

• cifrar / descifrar un bloque de datos;
• crear / verificar la firma electrónica del bloque de datos;
• calcular la función hash del bloque de datos;
• generar / cargar / descargar información clave;
• etc.

La lógica empresarial del software de aplicación que utiliza primitivas criptográficas implementa una funcionalidad de nivel superior:

• cifrar el archivo en las claves de los destinatarios seleccionados;
• establecer una conexión de red segura;
• informar sobre los resultados de la verificación de firmas electrónicas;
• etc.

La interacción de la lógica empresarial y el núcleo de cifrado se puede realizar:

• directamente, invocando primitivas criptográficas de las bibliotecas dinámicas de núcleo criptográfico mediante lógica empresarial (.DLL para Windows, .SO para Linux);
• , – (wrappers), , MS Crypto API, Java Cryptography Architecture, PKCS#11 . - , , . .

Se pueden distinguir dos esquemas típicos para organizar un cripto-núcleo:

Esquema 1 - Cripto-núcleo monolítico.


Esquema 2 - Cripto-núcleo separado. Los


elementos en los esquemas dados pueden ser módulos de software separados que se ejecutan en una computadora o servicios de red que interactúan dentro de una red informática.

Cuando se utilizan sistemas construidos de acuerdo con el esquema 1, el software de aplicación y el núcleo de cifrado funcionan en el marco de un entorno único para el funcionamiento de una instalación de cifrado (SFC), por ejemplo, en la misma computadora, bajo el control del mismo sistema operativo. Como regla general, un usuario del sistema puede ejecutar otros programas, incluidos los que contienen código malicioso, en el marco del mismo entorno de funcionamiento. En tales circunstancias, existe un grave riesgo de fuga de claves criptográficas privadas.

Para minimizar el riesgo, se utiliza el esquema 2, en el que el núcleo de cifrado se divide en dos partes:

1. La primera parte, junto con el software de la aplicación, funciona en un entorno no confiable donde existe el riesgo de infección con código malicioso. Llamaremos a esta parte la "parte del software".
2. La segunda parte funciona en un entorno confiable en un dispositivo dedicado que contiene un almacén de claves privadas. Además llamaremos a esta parte - "hardware".

La división del criptocore en software y hardware es muy arbitraria. Hay sistemas en el mercado que se construyen de acuerdo con el esquema con un criptocore dividido, pero la parte del "hardware" se presenta en forma de una imagen de máquina virtual: HSM virtual ( ejemplo ).

La interacción de ambas partes del núcleo criptográfico ocurre de tal manera que las claves criptográficas privadas nunca se transmiten a la parte del software y, en consecuencia, no pueden ser robadas usando código malicioso.

La interfaz de interacción (API) y el conjunto de primitivas criptográficas proporcionadas por el software de aplicación por el núcleo criptográfico son las mismas en ambos casos. La diferencia radica en la forma en que se implementan.

Entonces, cuando se usa un esquema con un núcleo criptográfico dividido, la interacción del software y el hardware se realiza de acuerdo con el siguiente principio:

1. La parte de software realiza primitivas criptográficas que no requieren el uso de una clave privada (por ejemplo, calcular una función hash, verificar firmas electrónicas, etc.).
2. El hardware realiza primitivas criptográficas utilizando una clave privada (creando una firma electrónica, descifrando datos, etc.).

Ilustraremos el trabajo de un criptocore dividido utilizando el ejemplo de creación de una firma electrónica:

1. La parte de software calcula la función hash de los datos firmados y transfiere este valor a la parte de hardware a través del canal de intercambio entre los núcleos de cifrado.
2. La parte del hardware, utilizando la clave privada y el hash, forma el valor de la firma electrónica y la transfiere a la parte del software a través del canal de intercambio.
3. La parte del software devuelve el valor recibido al software de la aplicación.

Peculiaridades de verificar la precisión de una firma electrónica

Cuando una parte receptora recibe datos firmados por una firma electrónica, debe realizar varias etapas de verificación. Un resultado positivo de la verificación de una firma electrónica se logra solo si todas las etapas de verificación se completan con éxito.

Etapa 1. Control de integridad de datos y autoría de datos.

El contenido del escenario. La firma electrónica de los datos se verifica utilizando el algoritmo criptográfico correspondiente. La finalización exitosa de esta etapa significa que los datos no se han modificado desde que se firmaron, y que la firma se realizó con una clave privada correspondiente a la clave pública de verificación de firma electrónica.
Lugar de ejecución de la etapa: cryptocore.

Etapa 2. Monitoreo de la confianza en la clave pública del firmante y monitoreo de la validez de la clave privada de la firma electrónica.
El contenido del escenario. La etapa consta de dos sub-etapas intermedias. El primero establece si la clave pública de la verificación de firma electrónica era confiable al momento de firmar los datos. El segundo establece si la clave privada de la firma electrónica era válida al momento de firmar los datos. En el caso general, los períodos de validez de estas claves pueden no coincidir (por ejemplo, para certificados de certificados calificados de claves de verificación de firma electrónica). Las formas de establecer la confianza en la clave pública del firmante están determinadas por las reglas de gestión de documentos electrónicos adoptadas por las partes interactuantes.
Lugar de ejecución de la etapa: software de aplicación / núcleo de cifrado.

Etapa 3. Control de los poderes del firmante.
El contenido del escenario. De acuerdo con las reglas establecidas de gestión de documentos electrónicos, se verifica si el firmante tenía derecho a certificar los datos protegidos. Por ejemplo, damos una situación de violación de la autoridad. Supongamos que hay una organización donde todos los empleados tienen una firma electrónica. El orden del jefe, pero firmado por la firma electrónica del gerente del almacén, ingresa al sistema interno de gestión electrónica de documentos. En consecuencia, dicho documento no puede considerarse legítimo.
Lugar de ejecución de la etapa: software de aplicación.

Suposiciones hechas al describir el objeto de protección

1. Los canales de transferencia de información, con la excepción de los canales de intercambio de claves, también pasan a través del software de aplicación, API y el núcleo de cifrado.
2. () , , .
3. .

,

Para ilustrar los esquemas presentados anteriormente, consideramos un sistema de información hipotético y seleccionamos todos los elementos estructurales en él.

Descripción del sistema de información



Dos organizaciones decidieron introducir una gestión de documentos electrónicos (EDF) legalmente significativa entre ellas. Para hacer esto, firmaron un acuerdo en el que prescribieron que los documentos se transmitirán por correo electrónico y, al mismo tiempo, deben ser encriptados y firmados por una firma electrónica calificada. Como medio para crear y procesar documentos, se deben usar programas de Office del paquete Microsoft Office 2016 y como medio de protección criptográfica: la herramienta de protección criptográfica CryptoPRO y el software de cifrado CryptoARM.

Descripción de la infraestructura de la organización 1

La Organización 1 decidió que instalaría el Sistema de protección de información criptográfica CryptoPRO y el software CryptoARM en la estación de trabajo del usuario, una computadora física. Las claves de cifrado y firma electrónica se almacenarán en el portador de claves ruToken que funciona en el modo de la clave extraída. El usuario preparará documentos electrónicos localmente en su computadora, después de lo cual serán encriptados, firmados y enviados utilizando un cliente de correo electrónico instalado localmente.

Descripción de la infraestructura de la organización 2 La

Organización 2 decidió transferir las funciones de cifrado y firma electrónica a una máquina virtual dedicada. En este caso, todas las operaciones criptográficas se realizarán automáticamente.

Para hacer esto, se organizan dos carpetas de red en la máquina virtual dedicada: "\\ ... \ In \", "\\ ... \ Out \". En la carpeta de red "\\ ... \ In \", los archivos recibidos de la contraparte en claro se colocarán automáticamente. Estos archivos serán descifrados y se verificará una firma electrónica en ellos.

En la carpeta "\\ ... \ Out \" el usuario colocará los archivos que necesitan ser encriptados, firmados y enviados a la contraparte. El usuario preparará los archivos por sí mismo en su estación de trabajo.
Para realizar las funciones de cifrado y firma electrónica en una máquina virtual, se instalan el software CryptoPro, el software cryptoarm y un cliente de correo electrónico. El control automático de todos los elementos de la máquina virtual se realizará mediante scripts desarrollados por los administradores del sistema.Las secuencias de comandos se registran en los archivos de registro.

Las claves criptográficas de la firma electrónica se colocarán en el token con la clave no extraíble JaCarta GOST, que el usuario conectará a su computadora local.

El token se enviará a la máquina virtual utilizando un software especializado de USB sobre IP instalado en la estación de trabajo del usuario y en la máquina virtual.

El reloj del sistema en la estación de trabajo del usuario en la organización 1 se ajustará manualmente. El reloj del sistema de una máquina virtual especializada en la organización 2 se sincronizará con el reloj del sistema del hipervisor, y estos, a su vez, se sincronizarán a través de Internet con servidores de hora públicos.

Aislamiento de elementos estructurales de protección de información criptográfica.
Con base en la descripción anterior de la infraestructura de TI, destacamos los elementos estructurales del sistema de protección de información criptográfica y los escribimos en la tabla.

Tabla - Correspondencia de elementos del modelo de protección de información criptográfica con elementos de sistemas de información

Nombre del artículo	Organización 1	Organización 2
Software de aplicación	Software CryptoARM	Software CryptoARM
El software crypto core	SKZI CryptoPro CSP	SKZI CryptoPro CSP
Hardware de criptomonedas	falta	JaCarta GOST
API	MS CryptoAPI	MS CryptoAPI
Tienda de clave pública	AWP del usuario: - disco duro - El almacén de certificados estándar de Windows.	Hipervisor: - disco duro Máquina virtual: - disco duro - El almacén de certificados estándar de Windows.
Bóveda de clave privada	El operador de claves ruToken funciona en modo de clave recuperable	Portador de claves JaCarta GOST que funciona en modo de clave no recuperable
Canal de intercambio de clave pública	AWP del usuario: - memoria de acceso aleatorio.	Hipervisor: - memoria de acceso aleatorio. Máquina virtual: - memoria de acceso aleatorio.
Canal de intercambio de clave privada	AWP del usuario: - bus USB; - memoria de acceso aleatorio.	falta
Canal de intercambio de criptomonedas	ausente (sin hardware de cripto núcleo)	AWP del usuario: - bus USB; - memoria de acceso aleatorio; - módulo de software USB sobre IP; - interfaz de red. Organización de la red corporativa 2. Hipervisor: - memoria de acceso aleatorio; - interfaz de red. Máquina virtual: - interfaz de red; - memoria de acceso aleatorio; - Módulo de software USB sobre IP.
Abrir canal de intercambio de datos	AWP del usuario: - medios de entrada-salida; - memoria de acceso aleatorio; - disco duro	AWP del usuario: - medios de entrada-salida; - memoria de acceso aleatorio; - disco duro - interfaz de red. Organización de la red corporativa 2. Hipervisor: - interfaz de red; - memoria de acceso aleatorio; - disco duro Máquina virtual: - interfaz de red; - memoria de acceso aleatorio; - disco duro
Canal de datos seguro	El internet. Organización de la red corporativa 1. AWP del usuario: - disco duro - memoria de acceso aleatorio; - interfaz de red.	El internet. Organización de la red corporativa 2. Hipervisor: - interfaz de red; - memoria de acceso aleatorio; - disco duro Máquina virtual: - interfaz de red; - memoria de acceso aleatorio; - disco duro
Canal de tiempo	AWP del usuario: - medios de entrada-salida; - memoria de acceso aleatorio; - temporizador del sistema.	El internet. Organización de red corporativa 2, Hipervisor: - interfaz de red; - memoria de acceso aleatorio; - temporizador del sistema. Máquina virtual: - memoria de acceso aleatorio; - temporizador del sistema.
Canal de transmisión de comando de control	AWP del usuario: - medios de entrada-salida; - memoria de acceso aleatorio. (Interfaz gráfica de usuario del software CryptoARM)	Máquina virtual: - memoria de acceso aleatorio; - disco duro (Scripts de automatización)
Canal para recibir los resultados del trabajo.	AWP del usuario: - medios de entrada-salida; - memoria de acceso aleatorio. (Interfaz gráfica de usuario del software CryptoARM)	Máquina virtual: - memoria de acceso aleatorio; - disco duro (Archivos de registro de script de automatización)

Amenazas de seguridad de nivel superior

Explicaciones

Suposiciones hechas durante la descomposición del peligro:

1. Se utilizan algoritmos criptográficos fuertes.
2. Los algoritmos criptográficos se utilizan de manera segura en los modos de operación correctos (por ejemplo, el BCE no se utiliza para cifrar grandes cantidades de datos, se tiene en cuenta la carga permitida en la clave, etc.).
3. Los atacantes conocen todos los algoritmos, protocolos y claves públicas aplicables.
4. Los atacantes pueden leer todos los datos cifrados.
5. Los atacantes pueden reproducir cualquier elemento del programa en el sistema.

Descomposición

U1. Compromiso de claves criptográficas privadas.
U2 Cifre datos fraudulentos en nombre de un remitente legítimo.
U3 Descifrado de datos cifrados por personas que no son destinatarios legítimos de datos (atacantes).
U4. Creación de una firma electrónica de un firmante legítimo con datos falsos.
U5. Obtención de un resultado positivo de la verificación de la firma electrónica de datos falsos.
Y6 Aceptación errónea de documentos electrónicos para su ejecución debido a problemas en la organización de la gestión de documentos electrónicos.
Y7 Familiarización no autorizada con los datos protegidos durante su procesamiento por el sistema de protección de información criptográfica.

U1. Compromiso de claves criptográficas privadas

U1.1. Obtener la clave privada del almacén de claves privadas.

U1.2. Obtención de una clave privada a partir de objetos del entorno del funcionamiento de la criptomoneda en la que puede ubicarse temporalmente.
Explicaciones U1.2.

Los objetos en los que la clave privada se puede almacenar temporalmente incluirán:

1. RAM
2. archivos temporales
3. intercambiar archivos
4. archivos de hibernación
5. archivos de instantáneas del estado "activo" de las máquinas virtuales, incluidos los archivos en pausa de los contenidos de RAM de las máquinas virtuales.

U1.2.1. Eliminar las claves privadas de la RAM en funcionamiento congelando los módulos de RAM, extrayéndolos y luego leyendo los datos (ataque de congelación).
Explicaciones U1.2.1.
Ejemplo de ataque

U1.3. Obtener una clave privada de un canal de intercambio de clave privada.
Explicaciones U1.3.
A continuación se dará un ejemplo de la implementación de esta amenaza.

U1.4. Modificación no autorizada del núcleo de cifrado, como resultado de lo cual los atacantes conocen las claves privadas.

U1.5. Compromiso de una clave privada como resultado del uso de canales técnicos de fuga de información (TKUI).
Explicaciones U1.5.
Ejemplo de ataque

U1.6. Compromiso de la clave privada como resultado del uso de medios técnicos especiales (STS) diseñados para la recuperación de información secreta ("errores").

U1.7. Compromiso de claves privadas durante el almacenamiento fuera del sistema de protección de información criptográfica.
Explicaciones U1.7.
Por ejemplo, un usuario almacena sus medios clave en un cajón de escritorio, desde donde los intrusos pueden extraerlos fácilmente.

U2 Cifrar datos fraudulentos en nombre de un remitente legítimo

Explicaciones
Esta amenaza se considera solo para los esquemas de cifrado de datos con autenticación de remitente. Ejemplos de tales esquemas se indican en las recomendaciones de estandarización R 1323565.1.004-2017 “Tecnología de la información. Seguridad de la información criptográfica. Esquemas de autenticación de clave pública basados ​​en clave pública " . Para otros esquemas criptográficos, esta amenaza no existe, ya que el cifrado se realiza en las claves públicas del destinatario, y generalmente son conocidos por los atacantes.

Descomposición
U2.1. Compromiso de la clave privada del remitente:
U2.1.1. Enlace: “Un modelo de amenaza típico. Sistema de protección de información criptográfica. U1. Compromiso de claves criptográficas privadas " .

U2.2. Sustitución de datos de entrada en el canal abierto de intercambio de datos.
Notas U2.2.
Los ejemplos de implementación de esta amenaza se dan a continuación aquí y aquí .

U3 Descifrado de datos cifrados por personas que no son destinatarios legítimos de datos (atacantes)

Descomposición
U3.1. Compromiso de claves privadas del destinatario de datos cifrados.
Y3.1.1 Enlace: “Modelo de amenaza típico. Sistema de seguridad de la información criptográfica. U1. Compromiso de claves criptográficas privadas " .

U3.2. Sustitución de datos cifrados en un canal seguro de intercambio de datos.

U4. Creación de una firma electrónica de un firmante legítimo con datos falsos.

Descomposición
U4.1. Compromiso de claves privadas de una firma electrónica de un firmante legítimo.
Y4.1.1 Enlace: “Modelo de amenaza típico. Sistema de seguridad de la información criptográfica. U1. Compromiso de claves criptográficas privadas " .

U4.2. Sustitución de datos firmados en el canal abierto de intercambio de datos.
Nota Y4.2.
Los ejemplos de implementación de esta amenaza se dan a continuación aquí y aquí .

U5. Obtener un resultado positivo de la verificación de la firma electrónica de datos falsos

Descomposición
U5.1. Los atacantes interceptan un mensaje sobre el resultado negativo de la verificación de la firma electrónica en el canal de transmisión de los resultados del trabajo y lo reemplazan con un mensaje con un resultado positivo.

U5.2. Los atacantes realizan un ataque a la confianza en los certificados de firma ( ESCENARIO: se requieren todos los elementos ):
U5.2.1. Los atacantes generan una firma electrónica de clave pública y privada. Si el sistema utiliza certificados de clave de firma electrónica, generan un certificado de firma electrónica que es lo más similar posible al certificado del remitente previsto de los datos cuyo mensaje desean falsificar.
U5.2.2. Los atacantes realizan cambios no autorizados en el almacén de claves públicas, proporcionando a la clave pública generada el nivel necesario de confianza y autoridad.
U5.2.3. Los atacantes firman datos falsos con una clave de firma electrónica generada previamente y la inyectan en el canal seguro de intercambio de datos.

U5.3. Los atacantes llevan a cabo un ataque utilizando claves caducadas de una firma electrónica de un firmante legal ( ESCENARIO: se requieren todos los elementos ):
U5.3.1. Los atacantes comprometen las claves privadas caducadas (actualmente no válidas) de la firma electrónica del remitente legítimo.
U5.3.2. Los atacantes reemplazan el tiempo en el canal de transmisión de tiempo con el tiempo en que las claves comprometidas todavía estaban activas.
U5.3.3. Los atacantes firman datos fraudulentos con una clave de firma electrónica previamente comprometida y la inyectan en el canal seguro de intercambio de datos.

U5.4. Los atacantes llevan a cabo un ataque utilizando las claves comprometidas de la firma electrónica de un firmante legal ( ESCENARIO: se requieren todos los elementos ):
U5.4.1. Los atacantes hacen una copia del almacén de claves públicas.
U5.4.2. Los atacantes comprometen las claves privadas de uno de los remitentes legales. Se da cuenta de un compromiso, revoca las claves, la información sobre la revocación de la clave se coloca en el almacén de claves públicas.
U5.4.3. Los atacantes reemplazan el almacén de claves públicas por uno previamente copiado.
U5.4.4. Los atacantes firman datos fraudulentos con una clave de firma electrónica previamente comprometida y la inyectan en el canal seguro de intercambio de datos.

U5.5. <...> debido a la presencia de errores en la implementación de la segunda y tercera etapa de verificación de firmas electrónicas:
Explicaciones U5.5.
A continuación se muestra un ejemplo de la implementación de esta amenaza.

U5.5.1. Verificar la confianza en el certificado de la clave de firma electrónica solo por la presencia de confianza en el certificado con el que está firmado, sin verificaciones de CRL u OCSP.
Explicaciones U.5.5.1.
Ejemplo de implementación de amenazas .

U5.5.2. Cuando se crea una cadena de confianza para un certificado, no se analiza la autoridad de emisión de certificados.
Explicaciones U.5.5.2.
Un ejemplo de ataque con respecto a los certificados SSL / TLS.
Los atacantes compraron un certificado legítimo para su correo electrónico. Luego hicieron un certificado de sitio web fraudulento y lo firmaron con su certificado. Si no se lleva a cabo la verificación de autorización, cuando se verifique la cadena de confianza, será correcta y, en consecuencia, un certificado fraudulento también será correcto.

U5.5.3. Al crear una cadena de confianza de certificados, los certificados de revocación intermedia no se verifican.

U5.5.4. La CRL se actualiza con menos frecuencia de lo que la autoridad de certificación los emite.

U5.5.5. La decisión sobre la confianza en la firma electrónica se toma antes de que se reciba la respuesta de OCSP sobre el estado del certificado, se envía a la solicitud hecha más tarde que el momento en que se generó la firma, o antes de la siguiente recibida después de la firma de la CRL.
Explicaciones U.5.5.5.
En las regulaciones de la mayoría de las AC, el tiempo de revocación del certificado se considera el momento de la emisión de la CRL más cercana que contiene información sobre la revocación del certificado.

U5.5.6. Al recibir los datos firmados, no se verifica la propiedad del certificado para el remitente.
Explicaciones U.5.5.6.
Ejemplo de ataque Con respecto a los certificados SSL: la dirección del servidor llamado no se puede verificar por el valor del campo CN en el certificado.
Ejemplo de ataque Los atacantes comprometieron las claves de firma electrónica de uno de los participantes en el sistema de pago. Después de eso, piratearon la red de otro participante y enviaron documentos de pago firmados por claves comprometidas al servidor de liquidación del sistema de pago en su nombre. Si el servidor analiza solo la confianza y no verifica el cumplimiento, los documentos fraudulentos se considerarán legítimos.

Y6 Aceptación errónea de documentos electrónicos para su ejecución debido a problemas en la organización de la gestión de documentos electrónicos.

Descomposición
U6.1. La parte receptora no detecta la duplicación de los documentos recibidos.
Explicaciones U6.1.
Ejemplo de ataque Los atacantes pueden interceptar el documento transmitido al destinatario, incluso si está protegido criptográficamente, y luego enviarlo repetidamente al canal seguro de transmisión de datos. Si el destinatario no identifica duplicados, todos los documentos recibidos serán percibidos y procesados ​​como varios documentos.

Y7 Familiarización no autorizada con los datos protegidos durante su procesamiento.

Descomposición

U7.1. <...> debido a la fuga de información en canales de terceros (ataque de canal lateral).
Explicaciones U7.1.
Ejemplo de ataque

U7.2. <...> debido a la neutralización de la protección contra el acceso no autorizado a la información procesada en CIPF:
U7.2.1. Operación de CIPF con violaciones de los requisitos descritos en la documentación para CIPF.

U7.2.2. <...> llevado a cabo debido a la presencia de vulnerabilidades en:
U7.2.2.1. <...> protección contra el acceso no autorizado.
U7.2.2.2. <...> CPSI en sí.
U7.2.2.3. <...> el entorno del funcionamiento de la instalación de cifrado.

Ejemplos de ataque

Los escenarios considerados a continuación obviamente contienen errores de organización de seguridad de la información y sirven solo para ilustrar posibles ataques.

Escenario 1. Un ejemplo de la implementación de las amenazas U2.2 y U4.2.

Descripción de la propiedad


Software ARM KBR y SKZI SKAD La firma se instala en una computadora física que no está conectada a una red informática. FCN vdToken se utiliza como portador de claves en el modo de clave no recuperable.

El procedimiento de cálculo supone que el especialista en cálculo descarga mensajes electrónicos en forma abierta (diagrama del antiguo KBR AWP) desde su computadora de trabajo desde un servidor de archivos seguro especial, luego los escribe en la memoria USB de medios alienados y los transfiere al KBR AWP, donde los encripta y se registra Después de eso, el especialista transfiere mensajes electrónicos protegidos al medio enajenado, y luego a través de su computadora de trabajo los escribe en un servidor de archivos, desde donde llegan a UTA y luego al sistema de pago del Banco de Rusia.

En este caso, los canales para el intercambio de datos abiertos y protegidos incluirán: un servidor de archivos, la computadora de trabajo de un especialista y un medio alienable.

Atacar
Los atacantes no autorizados instalan un sistema de control remoto en la computadora de trabajo del especialista y, al momento de escribir al medio enajenado, las órdenes de pago (mensajes electrónicos) reemplazan abiertamente el contenido de uno de ellos. El especialista transfiere las órdenes de pago a la estación de trabajo del CBD, las firma y las cifra sin notar la sustitución (por ejemplo, debido a la gran cantidad de órdenes de pago en el vuelo, fatiga, etc.). Después de eso, una orden de pago falsa, que pasa por la cadena tecnológica, ingresa al sistema de pago del Banco de Rusia.

Escenario 2. Un ejemplo de la implementación de las amenazas U2.2 y U4.2.

Descripción de la propiedad


Una computadora con KBR AWARD instalado, SCAD Signature y el proveedor de claves conectado FCN vdToken opera en una sala dedicada sin acceso del personal.
El especialista en cálculos está conectado al AWS del CBD en el modo de acceso remoto a través del protocolo RDP.

Atacar
Los atacantes interceptan detalles mediante los cuales el especialista en cálculo se conecta y trabaja con KBR AWS (por ejemplo, debido a un código malicioso en su computadora). Luego se establece una conexión en su nombre y se envía una orden de pago falsa al sistema de pago del Banco de Rusia.

Escenario 3. Ejemplo de implementación de la amenaza U1.3.

Descripción de la propiedad


Considere una de las opciones hipotéticas para implementar los módulos de integración ABS-KBR para el nuevo esquema (AWP KBR-N), en el que la firma electrónica de los documentos salientes se produce en el lado del ABS. Al mismo tiempo, suponemos que el ABS funciona sobre la base de un sistema operativo que no es compatible con la firma SCAD SKAD y, en consecuencia, la funcionalidad criptográfica se transfiere a una máquina virtual separada: el módulo de integración ABS-KBR.
Como medio clave, se utiliza un token USB normal, que funciona en el modo de una clave recuperable. Al conectar el medio clave al hipervisor, resultó que no había puertos USB libres en el sistema, por lo que se decidió conectar el token USB a través de un concentrador de red USB e instalar un cliente USB sobre IP en la máquina virtual que se comunicará con el concentrador.

Atacar
Los atacantes interceptaron la clave privada de la firma electrónica del canal de comunicación entre el concentrador USB y el hipervisor (los datos se transmitieron en forma abierta). Al tener una clave privada, los atacantes formaron una orden de pago falsa, la firmaron con una firma electrónica y la enviaron al KBR-N AWP para su ejecución.

Escenario 4. Un ejemplo de implementación de amenazas U5.5.

Descripción de la propiedad
Considere el mismo esquema que en el escenario anterior. Suponemos que los mensajes electrónicos recibidos del KBR-N AWP están en la carpeta \\ ... \ SHARE \ In, y los enviados al KBR-N AWP y luego al sistema de pago del Banco de Rusia se enviarán a \\. .. \ COMPARTIR \ fuera.
También asumiremos que durante la implementación del módulo de integración, las listas de certificados revocados se actualizan solo al volver a emitir claves criptográficas, y también que los mensajes electrónicos recibidos en la carpeta \\ ... \ SHARE \ In se verifican solo para el control de integridad y el control de confianza para abrir Clave de firma electrónica.

Atacar

Los atacantes, usando las llaves robadas en el escenario anterior, firmaron una orden de pago falsa que contenía información sobre el recibo de dinero en la cuenta de un cliente fraudulento y lo inyectaron en el canal seguro de intercambio de datos. Como la verificación de que la orden de pago fue firmada por el Banco de Rusia no se lleva a cabo, se acepta su ejecución.