Enlaces a otras partes del estudio.
- (usted está aquí)
Este artículo completa el ciclo de publicaciones dedicadas a garantizar la seguridad de la información de los pagos bancarios no monetarios. Aquí analizamos los modelos de amenazas genéricos a los que se hace referencia en :
- .
- .
- .
- .
HABR-ADVERTENCIA!!! Queridos Khabrovitas, esta no es una publicación entretenida.
Se recurre a más de 40 páginas de materiales ocultos debajo del corte. ayuda con el trabajo o estudio personas que se especializan en banca o seguridad de la información. Estos materiales son el producto final del estudio y están escritos en un tono formal seco. De hecho, se trata de espacios en blanco para documentos internos sobre seguridad de la información.Bueno, lo tradicional. “El uso de información del artículo con fines ilegales está penado por la ley”. ¡Lectura productiva!
Información para lectores que lean el estudio a partir de esta publicación.
Sobre que es el estudio
Estás leyendo una guía para un especialista responsable de garantizar la seguridad de la información de los pagos en un banco.
Lógica de presentación
Al principio en и se proporciona la descripción del objeto de protección. Luego en explica cómo construir un sistema de protección y habla sobre la necesidad de crear un modelo de amenaza. EN Habla sobre qué son los modelos de amenazas y cómo se forman. EN и Se ofrece un análisis de ataques reales. и contener una descripción del modelo de amenaza construido teniendo en cuenta la información de todas las partes anteriores.
MODELO DE AMENAZAS TÍPICAS. CONEXIÓN DE RED
El objeto de protección para el cual se aplica el modelo de amenaza (alcance)
El objeto de la 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 elementos arquitectónicos:
- "nodos finales" — nodos que intercambian información protegida.
- "Nodos intermedios" - elementos de la 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 alto nivel
Descomposición
U1. Acceso no autorizado a los datos transmitidos.
U2. Modificación no autorizada de los datos transmitidos.
U3. Violación de la autoría de los datos transmitidos.
U1. Acceso no autorizado a los datos transmitidos
Descomposición
U1.1. <...>, realizado en nodos finales o intermedios:
U1.1.1. <…> leyendo los datos mientras están en los dispositivos de almacenamiento del nodo:
U1.1.1.1. <…> en la RAM.
Explicaciones a V1.1.1.1.
Por ejemplo, durante el procesamiento de datos por parte de la pila de red del nodo.
U1.1.1.2. <…> en memoria no volátil.
Explicaciones a V1.1.1.2.
Por ejemplo, al almacenar datos transmitidos en el caché, archivos temporales o archivos de paginación.
Y1.2. <…> realizado en nodos de redes de datos de terceros:
U1.2.1. <...> capturando todos los paquetes que caen en la interfaz de red del nodo:
Explicaciones a V1.2.1.
Todos los paquetes se capturan cambiando la tarjeta de red al modo promiscuo (modo promiscuo para adaptadores con cable o modo monitor para adaptadores wi-fi).
U1.2.2. <…> realizando ataques man-in-the-middle (MiTM), pero sin modificar los datos transmitidos (sin contar los datos de servicio de los protocolos de red).
Y1.2.2.1. Enlace: .
Y1.3. <...>, realizado debido a la fuga de información a través de canales técnicos (TCUI) desde nodos físicos o líneas de comunicación.
U1.4. <...>, realizado para la instalación de medios técnicos especiales (STS) en los nodos finales o intermedios, destinados a la eliminación encubierta de información.
U2. Modificación no autorizada de los datos transmitidos
Descomposición
U2.1. <...>, realizado en nodos finales o intermedios:
Y2.1.1. <...> leyendo y modificando los datos mientras se encuentran en los dispositivos de almacenamiento de los nodos:
Y2.1.1.1. <...> en RAM:
Y2.1.1.2. <…> en memoria no volátil:
Y2.2. <...> realizado en nodos de redes de datos de terceros:
U2.2.1. <…> realizando ataques Man-in-the-Middle (MiTM) y redirigiendo el tráfico al host malicioso:
Y2.2.1.1. La conexión física del equipo de los atacantes para romper la conexión de red.
Y2.2.1.2. Implementación de ataques a protocolos de red:
Y2.2.1.2.1. <…> gestión de red de área local virtual (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Modificación no autorizada de la configuración de VLAN en conmutadores o enrutadores.
Y2.2.1.2.2. <…> enrutamiento del tráfico:
Y2.2.1.2.2.1. Modificación no autorizada de las tablas de enrutamiento estático de los routers.
Y2.2.1.2.2.2. Anuncio de rutas falsas por parte de atacantes mediante protocolos de enrutamiento dinámico.
Y2.2.1.2.3. <…> configuración automática:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> direccionamiento y resolución de nombres:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Realizar cambios no autorizados en los archivos de nombres de host locales (hosts, lmhosts, etc.)
U3. Violación de la autoría de los datos transmitidos.
Descomposición
Y3.1. Neutralización de mecanismos para determinar la autoría de la información mediante la indicación de información falsa sobre el autor o fuente de datos:
Y3.1.1. Cambiar la información sobre el autor contenida en la información transmitida.
Y3.1.1.1. Neutralización de la protección criptográfica de la integridad y autoría de los datos transmitidos:
Y3.1.1.1.1. Enlace: .
Y3.1.1.2. Neutralización de la protección de la autoría de los datos transmitidos, implementada mediante códigos de confirmación de un solo uso:
Y3.1.1.2.1. .
Y3.1.2. Cambiar información sobre la fuente de información transmitida:
Y3.1.2.1. .
Y3.1.2.2. .
MODELO DE AMENAZAS TÍPICAS. SISTEMA DE INFORMACIÓN CONSTRUIDO SOBRE LA BASE DE ARQUITECTURA CLIENTE-SERVIDOR
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 elementos arquitectónicos:
- "Cliente" - un dispositivo en el que opera la parte cliente del sistema de información.
- "Servidor" - un dispositivo en el que opera la parte del servidor del sistema de información.
- "Almacén de datos" - parte de la infraestructura del servidor del sistema de información, diseñada para almacenar datos procesados por el sistema de información.
- "Conexión de red" — un canal de intercambio de información entre el Cliente y el Servidor que pasa a través de la red de transmisión de datos. Para obtener una descripción más detallada del modelo de elementos, consulte .
restricciones
Al modelar un objeto, se establecen las siguientes restricciones:
- El usuario interactúa con el sistema de información en periodos de tiempo finitos, denominados sesiones de trabajo.
- Al inicio de cada sesión, el usuario es identificado, autenticado y autorizado.
- Toda la información protegida se almacena en la parte del servidor del sistema de información.
Amenazas de seguridad de alto nivel
Descomposición
U1. Atacantes que 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. Atacantes que cometen acciones no autorizadas en nombre de un usuario legítimo
Explicación
Habitualmente en los sistemas de información la correlación de acciones con el usuario que las realizó se realiza mediante:
- registros del sistema (registros).
- atributos especiales de objetos de datos que contienen información sobre el usuario que los creó o modificó.
En relación a una sesión de trabajo, esta amenaza se puede descomponer en:
- <…> realizado dentro de la sesión del usuario.
- <…> realizado fuera de la sesión del usuario.
Se puede iniciar una sesión de usuario:
- Por el propio usuario.
- Intrusos.
En esta etapa, la descomposición intermedia de esta amenaza quedará así:
U1.1. Acciones no autorizadas realizadas dentro de la sesión del usuario:
U1.1.1. <…> establecido por el usuario atacado.
U1.1.2. <…> instalado por atacantes.
Y1.2. Se realizaron acciones no autorizadas 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 intrusos, la descomposición de las amenazas intermedias se verá así:
Artículos
Descomposición de amenazas
Y1.1.1.
Y1.1.2.
Y1.2.
Cliente
Y1.1.1.1.
Y1.1.2.1.
conexión de red
Y1.1.1.2.
Servidor
Y1.2.1.
Descomposición
U1.1. Acciones no autorizadas realizadas dentro de la sesión del usuario:
U1.1.1. <…> establecido por el usuario atacado:
U1.1.1.1. Los atacantes actuaron independientemente del Cliente:
У1.1.1.1.1 Los atacantes utilizaron herramientas estándar de acceso al sistema de información:
Y1.1.1.1.1.1. Los atacantes utilizaron los medios físicos de entrada/salida del Cliente (teclado, ratón, monitor o pantalla táctil de un dispositivo móvil):
Y1.1.1.1.1.1.1. Los atacantes actuaron durante períodos de tiempo en los que la sesión está activa, las instalaciones de E/S están disponibles y el usuario está ausente.
Y1.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:
Y1.1.1.1.1.2.1. Los atacantes actuaron durante períodos de tiempo en los que la sesión está activa, las instalaciones de E/S están disponibles y el usuario está ausente.
Y1.1.1.1.1.2.2. Los atacantes utilizaron herramientas de administración remota, cuyo funcionamiento es invisible para el usuario atacado.
U1.1.1.2. Los atacantes falsificaron los datos de la conexión de red entre el Cliente y el Servidor, modificándolos de tal manera que fueron percibidos como acciones de un usuario legítimo:
Y1.1.1.2.1. Enlace: .
U1.1.1.3. Los atacantes obligaron al usuario a realizar las acciones que especificaron utilizando métodos de ingeniería social.
U1.1.2 <…> establecido por atacantes:
Y1.1.2.1. Los atacantes actuaron desde el Cliente (И):
Y1.1.2.1.1. Los atacantes neutralizaron el sistema de control de acceso del sistema de información:
Y1.1.2.1.1.1. Enlace: .
Y1.1.2.1.2. Los malhechores utilizaron medios regulares de acceso al sistema de información.
U1.1.2.2. Los atacantes actuaron desde otros nodos de la red de transmisión de datos, desde los cuales es posible establecer una conexión de red con el Servidor (И):
Y1.1.2.2.1. Los atacantes neutralizaron el sistema de control de acceso del sistema de información:
Y1.1.2.2.1.1. Enlace: .
Y1.1.2.2.2. Los atacantes utilizaron medios no estándar para acceder al sistema de información.
Explicaciones Y1.1.2.2.2.
Los atacantes podrían instalar un cliente de sistema de información normal en un nodo de terceros o utilizar software no estándar que implemente protocolos de intercambio estándar entre el Cliente y el Servidor.
P1.2 Acciones no autorizadas realizadas fuera de la sesión del usuario.
S1.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 los objetos de datos, lo que indica que las acciones que cometieron fueron realizadas por un usuario legítimo.
U2. Modificación no autorizada de 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 herramientas estándar del sistema de información y lo hacen en nombre de un usuario legítimo.
Y2.1.1. Enlace: .
Y2.2. Los atacantes modifican la información protegida utilizando mecanismos de acceso a los datos que no están previstos en el funcionamiento normal del sistema de información.
U2.2.1. Los atacantes modifican archivos que contienen información protegida:
Y2.2.1.1. <…> utilizando los mecanismos de manejo de archivos proporcionados por el sistema operativo.
Y2.2.1.2. <...> provocando la restauración de archivos a partir de una copia de seguridad modificada no autorizada.
U2.2.2. Los malhechores modifican la información protegida almacenada en la base de datos (И):
Y2.2.2.1. Los atacantes neutralizan el sistema de control de acceso DBMS:
Y2.2.2.1.1. Enlace: .
Y2.2.2.2. Los atacantes modifican la información utilizando interfaces DBMS estándar para acceder a los datos.
Y2.3. Los malhechores modifican la información protegida mediante la modificación no autorizada de los algoritmos de trabajo del software que la procesa.
Y2.3.1. Se realizan modificaciones en el código fuente del software.
Y2.3.1. Se realizan modificaciones en el código de máquina del software.
Y2.4. Los atacantes modifican la información protegida explotando vulnerabilidades en el software del sistema de información.
Y2.5. Los atacantes modifican la información protegida cuando se transfiere 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):
Y2.5.1. Enlace: .
MODELO DE AMENAZAS TÍPICAS. SISTEMA DE CONTROL DE ACCESO
El objeto de protección para el cual se aplica el modelo de amenaza (alcance)
El objeto de protección para el que 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 construido sobre la base de una arquitectura cliente-servidor.
El sistema de control de acceso de usuarios en este modelo de amenazas se entiende como un componente del sistema de información que implementa las siguientes funciones:
- Identificación de usuario.
- Autenticacion de usuario.
- Autorizaciones de usuarios.
- Registro de acciones del usuario.
Amenazas de seguridad de alto nivel
Descomposición
U1. Establecimiento no autorizado de una sesión por parte de un usuario legítimo.
U2. Elevación no autorizada de privilegios de usuarios en el sistema de información.
U1. Establecimiento de sesión no autorizado en nombre de un usuario legítimo
Explicación
La descomposición de esta amenaza en el caso general dependerá del tipo de sistemas de identificación y autenticación de usuarios utilizados.
En este modelo sólo se considerará el sistema de identificación y autenticación del usuario mediante login y contraseña de texto. En este caso, asumiremos que el inicio de sesión del usuario es información pública conocida por los atacantes.
Descomposición
U1.1. <…> comprometiendo las credenciales:
U1.1.1. Los atacantes comprometieron las credenciales del usuario mientras estaban almacenadas.
Explicaciones Y1.1.1.
Por ejemplo, las credenciales podrían escribirse en una nota adhesiva pegada al monitor.
U1.1.2. El usuario pasó accidental o maliciosamente detalles de acceso a los atacantes.
Y1.1.2.1. El usuario pronunció las credenciales en voz alta mientras ingresaba.
U1.1.2.2. El usuario pasó intencionalmente sus credenciales:
Y1.1.2.2.1. <…> compañeros de trabajo.
Explicaciones Y1.1.2.2.1.
Por ejemplo, para que puedan sustituirlo por un período de enfermedad.
Y1.1.2.2.2. <…> a las contrapartes del empleador que realizan trabajos en los objetos de la infraestructura de información.
Y1.1.2.2.3. <…> a terceros.
Explicaciones Y1.1.2.2.3.
Una forma, pero no la única, de implementar esta amenaza es utilizar métodos de ingeniería social por parte de los atacantes.
U1.1.3. Los atacantes forzaron bruscamente las credenciales:
Y1.1.3.1. <…> utilizando mecanismos de acceso habituales.
U1.1.3.2. <...> mediante códigos previamente interceptados (por ejemplo, hashes de contraseñas) para almacenar credenciales.
U1.1.4. Los atacantes utilizaron código malicioso para interceptar las credenciales del usuario.
U1.1.5. Los atacantes extrajeron credenciales de una conexión de red entre el Cliente y el Servidor:
Y1.1.5.1. Enlace: .
U1.1.6. Los atacantes extrajeron credenciales de registros de sistemas de seguimiento del trabajo:
U1.1.6.1. <…> sistemas de videovigilancia (en caso de que se registraran pulsaciones de teclas durante el funcionamiento).
U1.1.6.2. <…> sistemas para monitorear las acciones de los empleados en la computadora
Explicaciones Y1.1.6.2.
Un ejemplo de tal sistema es .
U1.1.7. Los atacantes comprometieron las credenciales del usuario debido a fallas en el proceso de transmisión.
Explicaciones Y1.1.7.
Por ejemplo, la transmisión de contraseñas en texto claro por correo electrónico.
U1.1.8. Los atacantes aprendieron las credenciales monitoreando la sesión del usuario mediante 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 (TCUE):
U1.1.9.1. Los atacantes observaron cómo el usuario ingresa las credenciales desde el teclado:
E1.1.9.1.1 Los atacantes se ubicaron muy cerca del usuario y vieron con sus propios ojos la entrada de las credenciales.
C1.1.9.1.1 Explicaciones
Estos 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.
E1.1.9.1.2 Los atacantes utilizaron medios técnicos adicionales, como unos prismáticos o un vehículo aéreo no tripulado, y vieron la entrada de credenciales a través de una 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 una interfaz de radio (por ejemplo, Bluetooth).
U1.1.9.3. Los atacantes interceptaron las credenciales filtrándolas a través del canal de captaciones y radiaciones electromagnéticas espurias (PEMIN).
Explicaciones Y1.1.9.3.
Ejemplos de ataques и .
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 eliminar información de forma encubierta.
Explicaciones Y1.1.9.4.
Примеры .
U1.1.9.5. Los atacantes interceptaron la entrada de credenciales desde el teclado usando
Análisis de la señal Wi-Fi modulada por el proceso de pulsación de teclas por parte del usuario.
Explicaciones Y1.1.9.5.
ejemplo .
U1.1.9.6. Los atacantes interceptaron la entrada de credenciales desde el teclado analizando el sonido de las pulsaciones de teclas.
Explicaciones Y1.1.9.6.
ejemplo .
U1.1.9.7. Los atacantes interceptaron la entrada de credenciales desde el teclado de un dispositivo móvil analizando las lecturas del acelerómetro.
Explicaciones Y1.1.9.7.
ejemplo .
U1.1.10. <...> previamente guardado en el Cliente.
Explicaciones Y1.1.10.
Por ejemplo, un usuario podría guardar un nombre de usuario y una contraseña en el navegador para acceder a un sitio en particular.
U1.1.11. Los atacantes comprometieron las credenciales debido a fallas en el proceso de revocación de acceso de los usuarios.
Explicaciones Y1.1.11.
Por ejemplo, después del despido de un usuario, sus cuentas no quedaron bloqueadas.
Y1.2. <…> explotando vulnerabilidades en el sistema de control de acceso.
U2. Elevación no autorizada de privilegios de usuarios en el sistema de información
Descomposición
P2.1 <...> realizando cambios no autorizados en los datos que contienen información sobre los privilegios del usuario.
U2.2 <…> explotando vulnerabilidades en el sistema de control de acceso.
Y2.3. <…> debido a fallas en el proceso de control de acceso de usuarios.
Explicaciones Y2.3.
Ejemplo 1. A un usuario se le dio más acceso al trabajo del que necesitaba debido a necesidades oficiales.
Ejemplo 2: Después de transferir un usuario a otra posición, los derechos de acceso previamente otorgados no fueron revocados.
MODELO DE AMENAZAS TÍPICAS. 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.
Teniendo en cuenta el hecho de 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 vínculo entre los componentes dentro de un sistema de información.
Arquitectura
El esquema generalizado del módulo de integración se ve así:
Descripción de elementos arquitectónicos:
- "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.
- "Intermediario" - un nodo / servicio diseñado para organizar la interacción entre sistemas de información, pero que no forma parte de ellos.
Por ejemplos "Intermediarios" pueden ser servicios de correo electrónico, bus de servicios empresariales/arquitectura SoA, servidores de archivos de terceros, etc. En el caso general, el módulo de integración no podrá contener "Intermediarios". - "Software de procesamiento de datos" - un conjunto de programas que implementa protocolos de intercambio de datos y conversión de formatos.
Por ejemplo, convertir datos del formato UFEBS al formato ABS, cambiar el estado de los mensajes durante la transmisión, etc. - "Conexión de red" Corresponde al objeto descrito en el modelo de amenaza típico "Conexión de red". Es posible que algunas conexiones de red de las presentadas en el diagrama anterior no lo sean.
Ejemplos de módulos de integración
Esquema 1. Integración de ABS y AWP KBR a través de un servidor de archivos de terceros
Para ejecutar los pagos, un empleado autorizado del banco carga los documentos de pago electrónicos desde el ABS y los guarda en un archivo (de su propio formato, por ejemplo, volcado SQL) en la carpeta de red (…SHARE) del servidor de archivos. Luego, este archivo se convierte en un conjunto de archivos en formato UFEBS utilizando un script convertidor, que luego el CBD AWP lee.
Después de eso, un empleado autorizado, un usuario de AWS CBD, 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, el AWP del CBR los descifra y verifica la firma electrónica, después de lo cual los escribe como un conjunto de archivos en formato UFEBS en el servidor de archivos. Antes de importar los documentos de pago al ABS, se convierten mediante un convertidor de script del formato UFEBS al formato ABS.
Supondremos que en este esquema, el ABS opera en un servidor físico, la estación de trabajo CBD opera en una computadora dedicada y el convertidor de scripts opera en un servidor de archivos.
Correspondencia de los objetos del esquema considerado con los elementos del modelo del módulo de integración:
"Servidores de Exchange desde el lado ABS" - Servidor ABS.
"Servidores Exchange desde el lado de AWP KBR" - estación de trabajo informática KBR.
"Intermediario" - servidor de archivos de terceros.
"Software de procesamiento de datos" - convertidor de guiones.
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, sino que en una computadora con AWS CBD se encuentra una carpeta de red (…SHARE) con documentos de pago electrónico. El convertidor de scripts también funciona en AWP CBD.
Correspondencia de los objetos del esquema considerado con los elementos del modelo del módulo de integración:
Similar al esquema 1, pero "Intermediario" no utilizado.
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 de ABS"
El ABS opera en una plataforma no compatible con CIPF SKAD Signature. Los documentos electrónicos salientes se firman en un servidor de firma electrónica especial (ES Server). El mismo servidor verifica la firma electrónica de los documentos recibidos del Banco de Rusia.
El ABS carga en el Servidor ES un archivo con los documentos de pago en su propio formato.
El servidor ES, utilizando un script convertidor, convierte el archivo en mensajes electrónicos en formato UFEBS, después de lo cual los mensajes electrónicos se firman y transmiten a IBM WebSphere MQ.
AWS KBR-N accede a IBM WebSphere MQ y recibe mensajes de pago firmados desde allí, después de lo cual un empleado autorizado, un usuario de AWS KBR, los cifra y los envía al sistema de pago del Banco de Rusia.
Al recibir 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 UFEBS se transfieren a IBM WebSphere MQ, desde donde son recibidos por el servidor ES.
El servidor ES verifica la firma electrónica de los pagos recibidos y los guarda en un archivo en formato ABS. Después de eso, un empleado autorizado, el usuario de ABS, carga el archivo resultante en ABS de la manera prescrita.
Correspondencia de los objetos del esquema considerado con los elementos del modelo del módulo de integración:
"Servidor de Exchange desde el lado ABS" - Servidor ABS.
"Servidor Exchange desde el lado de AWP KBR" - estación de trabajo informática KBR.
"Intermediario" – Servidor ES e IBM WebSphere MQ.
"Software de procesamiento de datos" – convertidor de script, firma CIPF SCAD 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 banca remota (RBS):
- "Cliente-Banco de Internet" para particulares (ICB FL);
- "Internet Cliente-Banco" para personas jurídicas (ICB LE).
Para garantizar la seguridad de la información, toda la interacción del ABS con los sistemas RB se lleva a cabo a través de un servidor de intercambio dedicado que opera dentro del sistema de información del ABS.
A continuación, consideraremos el proceso de interacción del sistema RBS del ICB LE con el ABS.
El servidor de RBS, habiendo recibido una orden de pago debidamente certificada del cliente, debe crear un documento apropiado en ABS en base a ella. Para hacer esto, utilizando la API, transfiere información al servidor de Exchange, que, a su vez, ingresa datos en el ABS.
Cuando cambian los saldos de la cuenta del cliente, el ABS genera notificaciones electrónicas, que se transmiten al servidor del RBS utilizando el servidor de intercambio.
Correspondencia de los objetos del esquema considerado con los elementos del modelo del módulo de integración:
"Servidor Exchange de RBS" – Servidor RBS IKB YUL.
"Servidor de Exchange desde el lado ABS" - servidor de intercambio.
"Intermediario" - perdido.
"Software de procesamiento de datos" – Componentes del servidor RB responsables de utilizar la API del servidor Exchange, componentes del servidor Exchange responsables de utilizar la API ABS.
Amenazas de seguridad de alto nivel
Descomposición
U1. La introducción de información falsa por parte de malhechores a través del módulo de integración.
U1. La introducción de información falsa por parte de atacantes a través del módulo de integración
Descomposición
U1.1. Modificación no autorizada de datos legítimos durante su transmisión a través de conexiones de red:
Enlace U1.1.1: .
Y1.2. Transferencia de datos falsos a través de canales de comunicación en nombre de un participante legítimo del intercambio:
Enlace U1.1.2: .
Y1.3. Modificación no autorizada de datos legítimos durante su procesamiento en los Servidores Exchange o el Intermediario:
Y1.3.1. Enlace: .
U1.4. Creación en los Servidores de Exchange o en el Intermediario de datos falsos en nombre de un participante legítimo del Exchange:
Y1.4.1. Enlace:
Y1.5. Modificación no autorizada de los datos durante su tratamiento mediante programas informáticos:
U1.5.1. <…> debido a la introducción de cambios no autorizados por parte de intrusos en la configuración (configuración) del software de procesamiento de datos.
U1.5.2. <…> debido a que los intrusos realizaron cambios no autorizados en los archivos ejecutables del software de procesamiento de datos.
U1.5.3. <...> debido al control interactivo del software de procesamiento de datos por parte de los atacantes.
MODELO DE AMENAZAS TÍPICAS. SISTEMA DE PROTECCIÓN DE INFORMACIÓN CRIPTOGRÁFICA
El objeto de protección para el cual se aplica el modelo de amenaza (alcance)
El objeto de protección es el sistema de protección de la 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.
La protección criptográfica en este caso generalmente se implementa llamando primitivas criptográficas desde la lógica comercial del software de la aplicación, que se encuentran en bibliotecas especializadas: criptokernels.
Las primitivas criptográficas incluyen funciones criptográficas de bajo nivel como:
- cifrar/descifrar bloque de datos;
- crear/verificar la firma electrónica del bloque de datos;
- calcular la función hash del bloque de datos;
- generar/cargar/cargar información clave;
- etcétera
La lógica empresarial del software de la aplicación, utilizando primitivas criptográficas, implementa una funcionalidad de nivel superior:
- cifrar el archivo con las claves de los destinatarios seleccionados;
- establecer una conexión de red segura;
- informar sobre los resultados de la verificación de la firma electrónica;
- y así sucesivamente
La interacción de la lógica empresarial y el criptonúcleo se puede realizar:
- directamente, llamando a las primitivas criptográficas desde las bibliotecas dinámicas del criptokernel (.DLL - para Windows, .SO - para Linux) mediante la lógica empresarial;
- directamente, a través de interfaces criptográficas: contenedores, por ejemplo, MS Crypto API, Java Cryptography Architecture, PKCS # 11, etc. En este caso, la lógica empresarial se refiere a la interfaz criptográfica y traduce la llamada al núcleo criptográfico correspondiente, que en este caso se llama proveedor de cifrado. El uso de interfaces criptográficas permite que el software de aplicación se abstraiga de algoritmos criptográficos específicos y sea más flexible.
Hay dos esquemas típicos para organizar un criptonúcleo:
Esquema 1: criptonúcleo monolítico
Esquema 2: Núcleo criptográfico dividido
Los elementos de los diagramas anteriores pueden ser módulos de software independientes que se ejecutan en la misma computadora o servicios de red que interactúan dentro de una red informática.
Cuando se utilizan sistemas construidos según el esquema 1, el software de aplicación y el criptonúcleo funcionan dentro de un único entorno para el funcionamiento de un criptomedio (CFC), por ejemplo, en la misma computadora que ejecuta el mismo sistema operativo. El usuario del sistema, por regla general, puede ejecutar otros programas dentro del mismo entorno operativo, incluidos los que contienen código malicioso. En tales condiciones, existe un grave riesgo de fuga de claves criptográficas privadas.
Para minimizar el riesgo se utiliza el esquema 2, en el que el criptonúcleo se divide en dos partes:
- La primera parte, junto con el software de la aplicación, se ejecuta en un entorno no confiable donde existe riesgo de infección de malware. A esta parte la llamaremos “parte de software”.
- La segunda parte funciona en un entorno confiable en un dispositivo dedicado que contiene un almacén de claves privadas. De ahora en adelante nos referiremos a esta parte como la “parte de hardware”.
La división del criptokernel en partes de software y hardware es muy condicional. Hay sistemas en el mercado construidos según el esquema con un núcleo criptográfico dividido, pero cuya parte de "hardware" se presenta en forma de una imagen de máquina virtual: HSM virtual ().
La interacción de ambas partes del criptonúcleo se produce de tal manera que las claves criptográficas privadas nunca se transfieren a la parte del software y, en consecuencia, no se pueden robar mediante código malicioso.
La interfaz de interacción (API) y el conjunto de primitivas criptográficas proporcionadas al software de la aplicación por el criptonúcleo son los mismos en ambos casos. La diferencia radica en la forma en que se implementan.
Entonces, cuando se utiliza un esquema con un criptonúcleo dividido, la interacción entre software y hardware se realiza de acuerdo con el siguiente principio:
- El software realiza primitivas criptográficas que no requieren el uso de una clave privada (por ejemplo, cálculo de una función hash, verificación de una firma electrónica, etc.).
- Las primitivas criptográficas que utilizan una clave privada (creación de una firma electrónica, descifrado de datos, etc.) las realiza el hardware.
Ilustremos el funcionamiento de un criptonúcleo dividido usando el ejemplo de creación de una firma electrónica:
- La parte de software calcula la función hash de los datos firmados y transmite este valor al hardware a través del canal de intercambio entre los criptonúcleos.
- La parte de hardware, utilizando la clave privada y el hash, genera el valor de la firma electrónica y lo transfiere a la parte de software a través del canal de intercambio.
- La parte del software devuelve el valor recibido al software de la aplicación.
Características de comprobar la exactitud de una firma electrónica.
Cuando el receptor recibe datos firmados con firma electrónica, debe realizar varias etapas de verificación. Se logra un resultado positivo de la verificación de una firma electrónica solo si se completan con éxito todas las etapas de la verificación.
Etapa 1. Control de la integridad de los datos y autoría de los datos.
Contenido escénico. La firma electrónica de los datos se verifica según el correspondiente algoritmo criptográfico. La finalización exitosa de esta etapa indica que los datos no han sido modificados desde que fueron firmados y que la firma se realizó con una clave privada correspondiente a la clave pública de verificación de la firma electrónica.
Ubicación del escenario: criptokernel.
Etapa 2. Control de confianza en la clave pública del firmante y control del período de validez de la clave privada de la firma electrónica.
Contenido escénico. La etapa consta de dos subetapas intermedias. El primero establece si la clave pública para verificar la 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 en el momento de firmar los datos. En el caso general, los períodos de validez de estas claves pueden no coincidir (por ejemplo, para certificados cualificados de claves de verificación de firma electrónica). Los métodos para establecer confianza en la clave pública del firmante están determinados por las reglas de gestión de documentos electrónicos adoptadas por las partes que interactúan.
Ubicación del escenario: software de aplicación / criptokernel.
Etapa 3. Control de la autoridad del firmante.
Contenido escénico. De acuerdo con las normas establecidas para la gestión de documentos electrónicos, se comprueba si el firmante tenía derecho a certificar los datos protegidos. Por ejemplo, consideremos la situación de violación de autoridad. Supongamos que existe una organización donde todos los empleados tienen firma electrónica. El sistema interno de gestión de documentos electrónicos recibe una orden del jefe, pero firmada con la firma electrónica del jefe de almacén. En consecuencia, dicho documento no puede considerarse legítimo.
Ubicación del escenario: Software de la aplicacion.
Supuestos hechos al describir el objeto de protección
- Los canales de transferencia de información, con excepción de los canales de intercambio de claves, también pasan a través de software de aplicación, API y cripto-core.
- La información sobre la confianza en las claves públicas y (o) los certificados, así como la información sobre la autoridad de los propietarios de las claves públicas, se almacena en el almacén de claves públicas.
- El software de la aplicación funciona con el almacenamiento de claves públicas a través del criptonúcleo.
Un ejemplo de un sistema de información protegido con CIPF
Para ilustrar los esquemas presentados anteriormente, considere un sistema de información hipotético y seleccione todos los elementos estructurales que contiene.
Descripción del sistema de información.
Las dos organizaciones decidieron introducir una gestión de documentos electrónicos (EDF) jurídicamente vinculante entre ellas. Para ello, firmaron un acuerdo en el que establecían que los documentos se transmitirían por correo electrónico, y al mismo tiempo debían estar cifrados y firmados con firma electrónica cualificada. Como medio para crear y procesar documentos, se deben utilizar programas de Office del paquete Microsoft Office 2016 y, como medio de protección criptográfica, CIPF CryptoPRO y el software de cifrado CryptoARM.
Descripción de la infraestructura de la organización 1
La Organización 1 decidió instalar el software CryptoPRO CIPF y 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 soporte de claves ruToken que funciona en modo de clave recuperable. El usuario preparará documentos electrónicos localmente en su computadora, después de lo cual serán cifrados, firmados y enviados utilizando un cliente de correo instalado localmente.
Descripción de la infraestructura de la organización 2
La Organización 2 decidió trasladar 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 de forma automática.
Para ello, se organizan dos carpetas de red en una máquina virtual dedicada: “…In”, “…Out”. Los archivos recibidos de la contraparte en formato abierto se colocarán automáticamente en la carpeta de red "...En". Estos archivos serán descifrados y en ellos se verificará la firma electrónica.
En la carpeta "...Out", el usuario colocará los archivos que deben cifrarse, firmarse y enviarse a la contraparte. El usuario preparará los archivos él mismo en su estación de trabajo.
Para realizar funciones de cifrado y firma electrónica, se instalan en la máquina virtual CryptoPRO CIPF, el software CryptoARM y un cliente de correo. La gestión automática de todos los elementos de la máquina virtual se realizará mediante scripts desarrollados por los administradores del sistema. El trabajo de los scripts se registra en archivos de registro (registros).
Las claves criptográficas de la firma electrónica se colocarán en un token con una clave no recuperable GOST de JaCarta, que el usuario conectará a su computadora local.
El token se reenviará a la máquina virtual mediante un software USB sobre IP especializado 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 la máquina virtual dedicada en la organización 2 se sincronizará con el reloj del sistema del hipervisor, que a su vez se sincronizará a través de Internet con los servidores de hora públicos.
Asignación de elementos estructurales del CIPF.
Basándonos en la descripción anterior de la infraestructura de TI, destacamos los elementos estructurales del CIPF y los anotamos en una tabla.
Tabla - Correspondencia de los elementos del modelo CIPF con los elementos de los sistemas de información
Nombre del artículo
Organización 1
Organización 2
Software de aplicación
Software criptoARM
Software criptoARM
La parte de software del criptokernel.
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
La parte de hardware del criptokernel.
No
JaCarta GOST
API
MS CriptoAPI
MS CriptoAPI
Almacenamiento de clave pública
Estación de trabajo del usuario:
- Disco duro;
- almacén de certificados estándar de Windows.
Hipervisor:
- Disco duro.
Máquina virtual:
- Disco duro;
- almacén de certificados estándar de Windows.
Almacenamiento de clave privada
El portador de claves ruToken opera en modo de clave extraíble
Portador de claves JaCarta GOST que funciona en modo de clave no recuperable
Canal de intercambio de clave pública
Estación de trabajo del usuario:
- RAM.
Hipervisor:
- RAM.
Máquina virtual:
- RAM.
Canal de intercambio de claves privadas
Estación de trabajo del usuario:
- autobús USB;
- RAM.
No
Canal de intercambio entre criptonúcleos
ausente (sin hardware criptocore)
Estación de trabajo del usuario:
- autobús USB;
- RAM;
- Módulo de software USB sobre IP;
- interfaz de red.
Red corporativa de la organización 2.
Hipervisor:
- RAM;
- interfaz de red.
Máquina virtual:
- interfaz de red;
- RAM;
- Módulo de software USB sobre IP.
Canal abierto de intercambio de datos.
Estación de trabajo del usuario:
- medios de entrada-salida;
- RAM;
- Disco duro.
Estación de trabajo del usuario:
- medios de entrada-salida;
- RAM;
- Disco duro;
- interfaz de red.
Red corporativa de la organización 2.
Hipervisor:
- interfaz de red;
- RAM;
- Disco duro.
Máquina virtual:
- interfaz de red;
- RAM;
- Disco duro.
Canal de intercambio de datos seguro
Internet.
Red corporativa de la organización 1.
Estación de trabajo del usuario:
- Disco duro;
- RAM;
- interfaz de red.
Internet.
Red corporativa de la organización 2.
Hipervisor:
- interfaz de red;
- RAM;
- Disco duro.
Máquina virtual:
- interfaz de red;
- RAM;
- Disco duro.
canal de tiempo
Estación de trabajo del usuario:
- medios de entrada-salida;
- RAM;
- temporizador del sistema.
Internet.
Red corporativa de la organización 2,
Hipervisor:
- interfaz de red;
- RAM;
- temporizador del sistema.
Máquina virtual:
- RAM;
- temporizador del sistema.
Canal de transmisión de comandos de control.
Estación de trabajo del usuario:
- medios de entrada-salida;
- RAM.
(GUI del software CryptoARM)
Máquina virtual:
- RAM;
- Disco duro.
(guiones de automatización)
Canal de recepción de resultados de trabajo.
Estación de trabajo del usuario:
- medios de entrada-salida;
- RAM.
(GUI del software CryptoARM)
Máquina virtual:
- RAM;
- Disco duro.
(Archivos de registro para scripts de automatización)
Amenazas de seguridad de alto nivel
Explicación
Supuestos hechos en la descomposición de amenazas:
- Se utilizan algoritmos criptográficos potentes.
- Los algoritmos criptográficos se utilizan de forma segura en los modos de operación correctos (por ejemplo, no se aplica al cifrado de grandes cantidades de datos, se tiene en cuenta la carga permitida en la clave, etc.).
- Los malhechores conocen todos los algoritmos, protocolos y claves públicas utilizados.
- Los atacantes tienen acceso a todos los datos cifrados.
- Los atacantes pueden reproducir cualquier elemento del programa en el sistema.
Descomposición
U1. Compromiso de claves criptográficas privadas.
U2. Cifrado de datos falsos en nombre de un remitente legítimo.
U3. Descifrado de datos cifrados por personas que no son destinatarios legítimos de los datos (intrusos).
U4. Creación de una firma electrónica de un firmante legítimo bajo datos falsos.
U5. Obtención de resultado positivo de la comprobación de la firma electrónica de datos falsos.
U6. Aceptación errónea de documentos electrónicos para su ejecución por problemas en la organización de la gestión de documentos electrónicos.
U7. Acceso no autorizado a datos protegidos durante su tratamiento por parte de CIPF.
U1. Compromiso de claves criptográficas privadas
U1.1. Obtenga la clave privada del almacén de claves privadas.
Y1.2. Obtener una clave privada de los objetos del entorno de funcionamiento de la herramienta criptográfica, en los que puede ubicarse temporalmente.
Explicaciones Y1.2.
Los objetos que pueden almacenar temporalmente una clave privada incluirían:
- RAM,
- archivos temporales,
- archivos de paginación,
- archivos de hibernación,
- archivos de instantáneas del estado "caliente" de las máquinas virtuales, incluidos archivos del contenido de la RAM de las máquinas virtuales que han sido pausadas.
U1.2.1. Recuperar claves privadas de la RAM de trabajo congelando módulos de RAM, extrayéndolos y luego leyendo los datos (ataque de congelación).
Explicaciones Y1.2.1.
ejemplo .
Y1.3. Obtención de una clave privada de un canal de intercambio de claves privadas.
Explicaciones Y1.3.
Se dará un ejemplo de la implementación de esta amenaza. .
U1.4. Modificación no autorizada del criptonúcleo, como resultado de lo cual los atacantes conocen las claves privadas.
Y1.5. Compromiso de la clave privada como consecuencia del uso de canales técnicos de fuga de información (TCLE).
Explicaciones Y1.5.
ejemplo .
U1.6. Compromiso de la clave privada como resultado del uso de medios técnicos especiales (STS) diseñados para la recuperación secreta de información ("bugs").
Y1.7. Compromiso de claves privadas durante su almacenamiento fuera del CIPF.
Explicaciones Y1.7.
Por ejemplo, un usuario guarda sus medios clave en un cajón del escritorio, del cual los intrusos pueden recuperarlos fácilmente.
U2. Cifrado de datos falsos en nombre de un remitente legítimo
Explicación
Esta amenaza sólo se considera para esquemas de cifrado de datos con autenticación del remitente. En las recomendaciones de normalización se indican ejemplos de tales sistemas. . Para otros esquemas criptográficos, esta amenaza no existe, ya que el cifrado se realiza en las claves públicas del destinatario y, en general, los atacantes las conocen.
Descomposición
Y2.1. Compromiso de la clave privada del remitente:
Y2.1.1. Enlace: .
Y2.2. Sustitución de datos de entrada en el canal abierto de intercambio de datos.
Notas U2.2.
A continuación se dan ejemplos de la implementación de esta amenaza. и .
U3. Descifrado de datos cifrados por personas que no son destinatarios legítimos de los datos (intrusos)
Descomposición
Y3.1. Compromiso de las claves privadas del destinatario de datos cifrados.
Enlace U3.1.1: .
Y3.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
Y4.1. Compromiso de claves privadas de la firma electrónica de un firmante legítimo.
Enlace U4.1.1: .
Y4.2. Sustitución de datos firmados en el canal abierto de intercambio de datos.
Nota U4.2.
A continuación se dan ejemplos de la implementación de esta amenaza. и .
U5. Obtención de un resultado positivo de la comprobación de la firma electrónica de datos falsos.
Descomposición
Y5.1. Los malhechores interceptan en el canal de transmisión de los resultados del trabajo el mensaje de resultado negativo de la verificación de la firma electrónica y lo reemplazan por el mensaje de resultado positivo.
Y5.2. Los atacantes atacan la confianza en la firma de certificados (ESCENARIO: se requieren todos los elementos):
Y5.2.1. Los atacantes generan una clave pública y privada para una firma electrónica. Si el sistema utiliza certificados de clave de firma electrónica, genera un certificado de firma electrónica lo más parecido posible al certificado del presunto remitente de los datos cuyo mensaje se quiere falsificar.
U5.2.2. Los atacantes realizan cambios no autorizados en el almacén de claves públicas, dotando a la clave pública generada por ellos del nivel necesario de confianza y autoridad.
Y5.2.3. Los atacantes firman datos falsos con una clave de firma electrónica generada previamente y los integran en un canal seguro de intercambio de datos.
Y5.3. Los atacantes llevan a cabo un ataque utilizando claves de firma electrónica caducadas de un firmante legal (ESCENARIO: se requieren todos los elementos):
Y5.3.1. Los atacantes comprometen las claves privadas caducadas (no válidas actualmente) de la firma electrónica del remitente legítimo.
Y5.3.2. Los atacantes reemplazan la hora en el canal de transmisión horaria con la hora en la que las claves comprometidas aún eran válidas.
Y5.3.3. Los atacantes firman datos falsos con una clave de firma electrónica previamente comprometida y los integran en un canal seguro de intercambio de datos.
Y5.4. Los atacantes llevan a cabo un ataque utilizando claves de firma electrónica comprometidas de un firmante legal (ESCENARIO: se requieren todos los elementos):
Y5.4.1. Los atacantes hacen una copia del almacén de claves públicas.
Y5.4.2. Los atacantes comprometen las claves privadas de uno de los remitentes legítimos. Se da cuenta del compromiso, revoca las claves, la información sobre la revocación de la clave se coloca en el almacén de claves públicas.
Y5.4.3. Los atacantes reemplazan el almacén de claves públicas por el previamente copiado.
Y5.4.4. Los atacantes firman datos falsos con una clave de firma electrónica previamente comprometida y los integran en un canal seguro de intercambio de datos.
U5.5. <...> debido a la presencia de errores en la implementación de la 2ª y 3ª etapa de verificación de firma electrónica:
Explicaciones Y5.5.
Se da un ejemplo de la implementación de esta amenaza. .
U5.5.1. Verificación de confianza en el certificado de la clave de firma electrónica únicamente por la presencia de confianza en el certificado con el que se firma, sin comprobaciones CRL ni OCSP.
Explicaciones Y5.5.1.
Ejemplo de implementación .
U5.5.2. Al construir una cadena de confianza para un certificado, no se analiza la autoridad de emisión de certificados.
Explicaciones Y5.5.2.
Un ejemplo de ataque contra certificados SSL/TLS.
Los atacantes compraron un certificado legítimo para su correo electrónico. Luego crearon un certificado de sitio web fraudulento y lo firmaron con su propio certificado. Si no se realiza la verificación de credenciales, al verificar la cadena de confianza resultará correcta y, en consecuencia, el certificado fraudulento también será correcto.
Y5.5.3. Al crear una cadena de confianza de certificados, no se comprueba la revocación de los certificados intermedios.
Y5.5.4. Las CRL se actualizan con menos frecuencia de la que las emite la autoridad certificadora.
U5.5.5. La decisión de confiar en la firma electrónica se toma antes de recibir la respuesta del OCSP sobre el estado del certificado, enviada en una solicitud realizada después del momento de generación de la firma o antes de la siguiente después de recibir la firma de la CRL.
Explicaciones Y5.5.5.
En las regulaciones de la mayoría de las CA, se considera que el momento de revocación del certificado es el momento de 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 por parte del remitente.
Explicaciones Y5.5.6.
Ejemplo de ataque. Para los certificados SSL, es posible que no verifique si la dirección del servidor llamado coincide con el valor del campo CN en el certificado.
Ejemplo de ataque. Los atacantes vulneraron las claves de firma electrónica de uno de los participantes del sistema de pago. Después de eso, piratearon la red de otro participante y, en su nombre, enviaron documentos de pago firmados con claves comprometidas al servidor de liquidación del sistema de pago. Si el servidor analiza únicamente la confianza y no comprueba el cumplimiento, los documentos fraudulentos se considerarán legítimos.
U6. Aceptación errónea de documentos electrónicos para su ejecución por problemas en la organización de la gestión de documentos electrónicos.
Descomposición
U6.1. La parte receptora no detecta duplicación de los documentos recibidos.
Explicaciones Y6.1.
Ejemplo de ataque. Los malhechores pueden interceptar el documento transferido al destinatario, incluso si está protegido criptográficamente, y luego enviarlo repetidamente al canal seguro de transmisión de datos. Si el destinatario no detecta duplicados, todos los documentos recibidos serán percibidos y procesados como documentos diferentes.
U7. Acceso no autorizado a datos protegidos durante su tratamiento por parte de CIPF
Descomposición
U7.1. <…> debido a la filtración de información a través de canales de terceros (ataque de canal lateral).
Explicaciones Y7.1.
ejemplo .
U7.2. <...> debido a la neutralización de la protección contra el acceso no autorizado a la información procesada en CIPF:
Y7.2.1. Operación de CIPF con violaciones a los requisitos descritos en la documentación de CIPF.
Y7.2.2. <…> implementado debido a la presencia de vulnerabilidades en:
Y7.2.2.1. <…> medios de protección contra el acceso no autorizado.
Y7.2.2.2. <…> el propio CIPF.
Y7.2.2.3. <...> el entorno para el funcionamiento de la herramienta criptográfica.
Ejemplos de ataques
Los escenarios que se analizan a continuación obviamente contienen errores en la organización de la seguridad de la información y sólo sirven para ilustrar posibles ataques.
Escenario 1. Un ejemplo de implementación de las amenazas U2.2 y U4.2.
Descripción del objeto.
El software ARM KBR y CIPF SCAD Signature se instalan en una computadora física que no está conectada a una red informática. El FKN vdToken se utiliza como portador de claves en el modo de funcionamiento con clave no recuperable.
El reglamento de liquidación supone que el especialista en liquidación descarga mensajes electrónicos en texto claro (el esquema del antiguo KBR AWS) desde su computadora de trabajo desde un servidor de archivos seguro especial, luego los escribe en una unidad flash USB extraíble y los transfiere al KBR AWP. , donde se cifran y firman. Después de eso, el especialista transfiere los mensajes electrónicos seguros a un medio transferible y luego, a través de su computadora de trabajo, los escribe en un servidor de archivos, desde donde llegan a la UTA y luego al sistema de pagos del Banco de Rusia.
En este caso, los canales para el intercambio de datos abiertos y seguros incluirán: un servidor de archivos, una computadora de trabajo de un especialista y un medio transferible.
Ataque
Atacantes no autorizados instalan un sistema de control remoto en el ordenador de trabajo del especialista y, en el momento de registrar las órdenes de pago (mensajes electrónicos) en el soporte transferible, reemplazan abiertamente el contenido de una de ellas. El especialista transfiere las órdenes de pago al AWS de la KBR, las firma y las cifra sin darse cuenta de la sustitución (por ejemplo, por la gran cantidad de órdenes de pago en el vuelo, fatiga, etc.). Después de eso, la orden de pago falsa, después de pasar por la cadena tecnológica, ingresa al sistema de pago del Banco de Rusia.
Escenario 2. Un ejemplo de implementación de las amenazas U2.2 y U4.2.
Descripción del objeto.
La computadora con AWS KBR, SKAD Signature instalado y el portador de claves FKN vdToken conectado funciona en una sala dedicada sin acceso del personal.
El especialista en liquidación se conecta a AWS de KBR en modo de acceso remoto a través del protocolo RDP.
Ataque
Los atacantes interceptan los detalles mediante los cuales el especialista en liquidación se conecta y trabaja con el lugar de trabajo automatizado de KBR (por ejemplo, debido a un código malicioso en su computadora). Luego se conectan en su nombre y envían una orden de pago falsa al sistema de pago del Banco de Rusia.
Escenario 3. Un ejemplo de implementación de la amenaza U1.3.
Descripción del objeto.
Consideremos una de las opciones hipotéticas para la implementación de los módulos de integración ABS-KBR para el nuevo esquema (ARM KBR-N), en el que la firma electrónica de los documentos salientes se realiza en el lado del ABS. En este caso, asumiremos que ABS funciona sobre la base de un sistema operativo que no es compatible con la firma CIPF SKAD y, en consecuencia, la funcionalidad criptográfica se coloca en una máquina virtual separada: el módulo de integración ABS-CBR.
Como portador de claves se utiliza un token USB normal que funciona en modo de llave extraíble. Cuando se conectó el portador de claves 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 USB de red e instalar un cliente USB sobre IP en el máquina virtual que se comunicará con el hub.
Ataque
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 texto claro). Al tener una clave privada, los atacantes generaron una orden de pago falsa, la firmaron con una firma electrónica y la enviaron al lugar de trabajo automatizado KBR-N para su ejecución.
Escenario 4. Un ejemplo de implementación de amenazas U5.5.
Descripción del objeto.
Considere el mismo circuito que en el escenario anterior. Supondremos que los correos electrónicos provenientes de la estación de trabajo KBR-N terminan en la carpeta …SHAREIn, y aquellos que se envían a la estación de trabajo KBR-N y luego al sistema de pago del Banco de Rusia van a …SHAREout.
También asumiremos que al implementar el módulo de integración, las listas de certificados revocados se actualizan solo cuando se reemiten las claves criptográficas, y también que los mensajes electrónicos recibidos en la carpeta …SHAREIn se verifican solo para control de integridad y control de confianza en la clave pública de la firma electrónica.
Ataque
Los atacantes, utilizando las claves robadas en el escenario anterior, firmaron una orden de pago falsa que contenía información sobre la recepción de dinero en la cuenta de un cliente fraudulento y la introdujeron en un canal seguro de intercambio de datos. Dado que no hay verificación de que la orden de pago esté firmada por el Banco de Rusia, se acepta para su ejecución.
Fuente: habr.com