Enlaces a otras partes de la investigación
- (Estás aquí)
Este artículo concluye una serie de publicaciones dedicadas a la seguridad de la información de los pagos sin efectivo en los bancos. Aquí revisaremos los modelos de amenazas típicos a los que se ha hecho referencia en :
- .
- .
- .
- .
¡ATENCIÓN HABRÓ-WARNING!!! Estimados usuarios de Habra, este no es un post de entretenimiento.
Ocultos detrás de un spoiler, más de 40 páginas de materiales están destinados a ayudar en el trabajo o estudio a personas especializadas en banca o seguridad de la información. Estos materiales son el producto final de la investigación y están escritos en un tono oficial seco. Básicamente, son borradores para documentos internos sobre seguridad de la información.Y la tradicional declaración — «el uso de la información del artículo para fines ilegales está penado por la ley». ¡Lectura productiva!
Información para los lectores que se introducen en la investigación comenzando por esta publicación.
Sobre qué trata la investigación
Estás leyendo una guía para el especialista responsable de garantizar la seguridad de los pagos en el banco.
Lógica de presentación
Al principio en y se describe el objeto de protección. Luego en se describe cómo construir un sistema de protección y se menciona la necesidad de formar un modelo de amenazas. En se habla sobre los tipos de modelos de amenazas y cómo se forman. En y se presenta un análisis de ataques reales. y contienen una descripción del modelo de amenazas, construido con la información de todas las partes anteriores.
MODELO DE AMENAZAS TÍPICO. CONEXIÓN DE RED
Objeto de protección, para el cual se aplica el modelo de amenazas (scope)
El objeto de protección son los datos transmitidos a través de una conexión de red, que funciona en redes de transmisión de datos basadas en el stack TCP/IP.
Arquitectura
Descripción de los elementos de la arquitectura:
- «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 otro equipo, a través del cual se transmite el tráfico de la 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. mediante la lectura de datos mientras se encuentran en los dispositivos de almacenamiento del nodo:
U1.1.1.1. en la memoria RAM.
Explicaciones sobre U1.1.1.1.
Por ejemplo, durante el procesamiento de datos por el stack de red del nodo.
U1.1.1.2. en la memoria no volátil.
Explicaciones sobre U1.1.1.2.
Por ejemplo, al almacenar datos transmitidos en cachés, archivos temporales o archivos de intercambio.
U1.2. , realizado en nodos ajenos de la red de transmisión de datos:
U1.2.1. mediante la captura de todos los paquetes que llegan a la interfaz de red del nodo:
Explicaciones sobre U1.2.1.
La captura de todos los paquetes se lleva a cabo poniendo la tarjeta de red en modo promiscuo (modo promiscuo para adaptadores cableados o modo monitor para adaptadores wifi).
U1.2.2. mediante la realización de ataques tipo «hombre en el medio (MiTM)», pero sin modificar los datos transmitidos (excepto los datos de control de los protocolos de red).
U1.2.2.1. Enlace: .
U1.3. , realizada a través de la filtración de información por canales técnicos (TCPU) desde nodos físicos o líneas de comunicación.
U1.4. , realizada mediante la instalación en nodos finales o intermedios de medios técnicos especiales (MTE) destinados a la recolección encubierta de información.
U2. Modificación no autorizada de los datos transmitidos
Descomposición
U2.1. , llevada a cabo en nodos finales o intermedios:
U2.1.1. mediante la lectura y modificación de datos mientras se encuentran en los dispositivos de almacenamiento de los nodos:
U2.1.1.1. en la memoria RAM:
U2.1.1.2. en la memoria no volátil:
U2.2. , llevada a cabo en nodos externos de la red de transmisión de datos:
U2.2.1. mediante la realización de ataques tipo «hombre en el medio (MiTM)» y redirigiendo el tráfico hacia el nodo de los atacantes:
U2.2.1.1. Conexión física del equipo de los atacantes en el punto de interrupción de la conexión de red.
U2.2.1.2. Realización de ataques a protocolos de red:
U2.2.1.2.1. control de redes locales virtuales (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Modificación no autorizada de las configuraciones 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 tablas de enrutamiento estáticas en enrutadores.
U2.2.1.2.2.2. Anuncio por parte de los atacantes de rutas falsas a través de protocolos de enrutamiento dinámico.
U2.2.1.2.3. auto-configuración:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. direccionamiento y resolución de nombres:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Realización de modificaciones no autorizadas en archivos locales de nombres de host (hosts, lmhosts, etc.)
U3. Violación de la autoría de los datos transmitidos
Descomposición
U3.1. Neutralización de mecanismos de identificación de autoría de la información mediante la especificación de datos falsos sobre el autor o fuente de los datos:
U3.1.1. Modificación de los datos del autor contenidos en la información transmitida.
U3.1.1.1. Neutralización de la protección criptográfica de la integridad y autoría de los datos transmitidos:
U3.1.1.1.1. Enlace: .
U3.1.1.2. Neutralización de la protección por derechos de autor de los datos transmitidos, realizada mediante códigos de verificación de un solo uso:
U3.1.1.2.1. .
U3.1.2. Modificación de la información sobre la fuente de datos transmitidos:
U3.1.2.1. .
U3.1.2.2. .
MODELO TIPO DE AMENAZA. SISTEMA DE INFORMACIÓN BASADO EN ARQUITECTURA CLIENTE-SERVIDOR
Objeto de protección, para el cual se aplica el modelo de amenazas (scope)
El objeto de protección es un sistema de información construido sobre una arquitectura cliente-servidor.
Arquitectura
Descripción de los elementos de la arquitectura:
- «Cliente» – dispositivo en el que funciona la parte del cliente del sistema de información.
- «Servidor» – dispositivo en el que funciona la parte del servidor del sistema de información.
- «Almacenamiento de datos» – parte de la infraestructura del servidor del sistema de información destinada al almacenamiento de los datos procesados por el sistema de información.
- «Conexión de red» – 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. Una descripción más detallada del modelo del elemento se presenta en .
Limitaciones
Al modelar el objeto se establecen las siguientes restricciones:
- El usuario interactúa con el sistema de información dentro de intervalos de tiempo finitos, llamados sesiones de trabajo.
- Al comienzo de cada sesión de trabajo se lleva a cabo la identificación, autenticación y autorización del usuario.
- 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. Comportamientos no autorizados realizados por atacantes en nombre de un usuario legítimo.
U2. Modificación no autorizada de la información protegida durante su procesamiento por la parte del servidor del sistema de información.
U1. Comportamientos no autorizados realizados por atacantes en nombre de un usuario legítimo
Explicaciones
Generalmente, en los sistemas de información, la correlación de acciones con el usuario que las realizó se lleva a cabo mediante:
- registros del sistema (logs).
- atributos especiales de los objetos de datos que contienen información sobre el usuario que los creó o modificó.
En relación con la sesión de trabajo, esta amenaza puede descomponerse en:
- realizadas en el marco de la sesión de trabajo del usuario.
- realizadas fuera de la sesión de trabajo del usuario.
La sesión de trabajo del usuario puede ser iniciada:
- Por el propio usuario.
- Atacantes.
En esta etapa, la descomposición intermedia de esta amenaza se verá de la siguiente manera:
U1.1. Las acciones no autorizadas se realizaron dentro de la sesión de trabajo del usuario:
U1.1.1. <…>, instalado por el usuario atacado.
U1.1.2. <…>, instalado por los atacantes.
U1.2. Las acciones no autorizadas se realizaron fuera de la sesión de trabajo del usuario.
Desde el punto de vista de los objetos de la infraestructura de información que pueden ser afectados por los atacantes, la descomposición de amenazas intermedias se verá de la siguiente manera:
Los elementos
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. Las acciones no autorizadas se realizaron dentro de la sesión de trabajo del usuario:
U1.1.1. <…>, instalado por el usuario atacado:
U1.1.1.1. Los atacantes actuaron directamente desde el Cliente:
U1.1.1.1.1 Los atacantes utilizaron herramientas de acceso legítimas al sistema de información:
U1.1.1.1.1.1. Los atacantes utilizaron dispositivos de entrada/salida físicos del Cliente (teclado, ratón, monitor o pantalla táctil de un dispositivo móvil):
U1.1.1.1.1.1.1. Los atacantes actuaron en momentos en que la sesión estaba activa, los dispositivos de entrada/salida estaban disponibles y el usuario no estaba presente.
U1.1.1.1.1.2. Los atacantes utilizaron herramientas de administración remota (legítimas o proporcionadas por código malicioso) para controlar al Cliente:
U1.1.1.1.1.2.1. Los atacantes actuaron en momentos en que la sesión estaba activa, los dispositivos de entrada/salida estaban disponibles y el usuario no estaba presente.
U1.1.1.1.1.2.2. Los atacantes utilizaron herramientas de administración remota cuya operación no es detectada por el usuario atacado.
U1.1.1.2. Los atacantes reemplazaron datos en la conexión de red entre el Cliente y el Servidor, modificándolos de tal manera que fueran percibidos como acciones de un usuario legítimo:
U1.1.1.2.1. Enlace: .
U1.1.1.3. Los atacantes obligaron al usuario a realizar las acciones que indicaron, utilizando métodos de ingeniería social.
U1.1.2 <…> instalado por los atacantes:
U1.1.2.1. Los atacantes actuaron desde el Cliente (Y):
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: .
U1.1.2.1.2. Los atacantes utilizaron medios de acceso estándar del 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 se puede establecer una conexión de red con el Servidor (Y):
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: .
U1.1.2.2.2. Los atacantes utilizaron medios de acceso no autorizados del sistema de información.
Clarificaciones U1.1.2.2.2.
Los atacantes pudieron instalar el cliente estándar del sistema de información en un nodo externo o pudieron utilizar software no autorizado que implementa los protocolos estándar de intercambio entre el Cliente y el Servidor.
U1.2 Acciones no autorizadas llevadas a cabo fuera de la sesión de trabajo del usuario.
U1.2.1 Los atacantes realizaron acciones no autorizadas y luego hicieron cambios no autorizados en los registros de trabajo del sistema de información o atributos especiales de los objetos de datos, indicando que las acciones que realizaron fueron ejecutadas por un usuario legítimo.
U2. Modificación no autorizada de información protegida durante su procesamiento por la parte del servidor del sistema de información
Descomposición
U2.1. Los atacantes modifican información protegida utilizando medios estándar del sistema de información y realizan esto en nombre de un usuario legítimo.
U2.1.1. Enlace: .
U2.2. Los atacantes modifican información protegida mediante el uso de mecanismos de acceso a datos no previstos en el modo de funcionamiento estándar 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 recuperación de archivos de una copia de seguridad no autorizadamente modificada.
U2.2.2. Los atacantes modifican la información protegida almacenada en la base de datos (Y):
U2.2.2.1. Los atacantes neutralizan el sistema de control de acceso de la base de datos:
U2.2.2.1.1. Enlace: .
U2.2.2.2. Los atacantes modifican la información utilizando las interfaces estándar de la base de datos para acceder a los datos.
U2.3. Los atacantes modifican la información protegida mediante la modificación no autorizada de los algoritmos del software que la procesa.
U2.3.1. Se modifica el código fuente del software.
U2.3.1. Se modifica el código máquina del software.
U2.4. Los atacantes modifican la información protegida utilizando vulnerabilidades en el software del sistema de información.
U2.5. Los atacantes modifican la información protegida durante su transmisión entre los componentes del servidor del sistema de información (por ejemplo, entre el servidor de base de datos y el servidor de aplicaciones):
U2.5.1. Enlace: .
MODELO TÍPICO DE AMENAZAS. SISTEMA DE CONTROL DE ACCESO
Objeto de protección, para el cual se aplica el modelo de amenazas (scope)
El objeto de protección al que se aplica este modelo de amenazas corresponde al objeto de protección del modelo de amenazas: "Modelo Típico de Amenazas. Sistema de información basado en una arquitectura de cliente-servidor."
Por sistema de control de acceso de usuarios en este modelo de amenazas se entiende el componente del sistema de información que realiza funciones:
- Identificación de usuarios.
- Autenticación de usuarios.
- Autorización de usuarios.
- Registro de las acciones de los usuarios.
Amenazas de seguridad de alto nivel
Descomposición
U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legítimo.
U2. Elevación no autorizada de privilegios del usuario en el sistema de información.
U1. Establecimiento no autorizado de una sesión de trabajo en nombre de un usuario legítimo
Explicaciones
La descomposición de esta amenaza en general dependerá del tipo de sistemas de identificación y autenticación de usuarios utilizados.
En este modelo solo se considerará un sistema de identificación y autenticación de usuarios que utilice un nombre de usuario y una contraseña. Supondremos que el nombre de usuario es una información pública, conocida por los atacantes.
Descomposición
U1.1. mediante la comprometida de las credenciales:
U1.1.1. Los atacantes comprometieron las credenciales del usuario durante su almacenamiento.
Explicaciones U1.1.1.
Por ejemplo, las credenciales podrían haber sido escritas en una nota adhesiva pegada al monitor.
U1.1.2. El usuario, ya sea de manera accidental o maliciosa, transmitió los datos de acceso a los delincuentes.
U1.1.2.1. El usuario mencionó las credenciales en voz alta al ingresarlas.
U1.1.2.2. El usuario transmitió intencionadamente sus credenciales:
U1.1.2.2.1. a colegas de trabajo.
Explicaciones U1.1.2.2.1.
Por ejemplo, para que pudieran reemplazarlo durante su enfermedad.
U1.1.2.2.2. a contrapartes del empleador que trabajan en proyectos de infraestructura de información.
U1.1.2.2.3. a terceros.
Explicaciones U1.1.2.2.3.
Una de las posibles formas de implementar esta amenaza es el uso de métodos de ingeniería social por parte de los delincuentes.
U1.1.3. Los delincuentes adivinaron las credenciales mediante fuerza bruta:
U1.1.3.1. utilizando los mecanismos de acceso convencionales.
U1.1.3.2. a través de códigos interceptados previamente (por ejemplo, hashes de contraseñas) para el almacenamiento de credenciales.
U1.1.4. Los delincuentes utilizaron código malicioso para interceptar las credenciales del usuario.
U1.1.5. Los delincuentes extrajeron las credenciales de la conexión de red entre el Cliente y el Servidor:
U1.1.5.1. Enlace: .
U1.1.6. Los delincuentes extrajeron las credenciales de los registros de los sistemas de monitoreo de operaciones:
U1.1.6.1. de sistemas de videovigilancia (en caso de que se grabaran pulsaciones de teclas durante el trabajo).
U1.1.6.2. de sistemas de control de las acciones de los empleados en la computadora.
Explicaciones U1.1.6.2.
Un ejemplo de tal sistema es — .
U1.1.7. Los delincuentes comprometieron las credenciales del usuario debido a deficiencias en el proceso de transmisión.
Explicaciones U1.1.7.
Por ejemplo, la transmisión de contraseñas en texto plano por correo electrónico.
U1.1.8. Los delincuentes obtuvieron las credenciales observando la sesión de trabajo del usuario mediante sistemas de administración remota.
U1.1.9. Los delincuentes extrajeron las credenciales como resultado de su filtración a través de canales técnicos (TKUI):
U1.1.9.1. Los delincuentes observaron cómo el usuario ingresaba las credenciales desde el teclado:
U1.1.9.1.1 Los delincuentes se encontraban muy cerca del usuario y podían ver el ingreso de las credenciales con sus propios ojos.
Explicaciones U1.1.9.1.1
Estos casos pueden incluir acciones de colegas en el trabajo o situaciones en las que el teclado del usuario es visible para los visitantes de la organización.
U1.1.9.1.2 Los delincuentes utilizaron medios técnicos adicionales, como binoculares o drones, y vieron la introducción de credenciales a través de una ventana.
U1.1.9.2. Los delincuentes extrajeron las credenciales de las grabaciones de la radio entre el teclado y la unidad central de la computadora en caso de que estuvieran conectados a través de una interfaz de radio (por ejemplo, Bluetooth).
U1.1.9.3. Los delincuentes interceptaron las credenciales debido a su fuga a través de canales de emisiones electromagnéticas parásitas e influencias (PEMI).
Explicaciones U1.1.9.3.
Ejemplos de ataque y .
U1.1.9.4. El delincuente interceptó la entrada de las credenciales desde el teclado utilizando medios técnicos especiales (MTE), diseñados para la recolección secreta de información.
Explicaciones U1.1.9.4.
Ejemplos .
U1.1.9.5. Los delincuentes interceptaron la entrada de las credenciales desde el teclado a través del
análisis de la señal Wi-Fi modulada por el proceso de pulsación de teclas del usuario.
Explicaciones U1.1.9.5.
Ejemplo .
U1.1.9.6. Los delincuentes interceptaron la entrada de las credenciales desde el teclado mediante el análisis de los sonidos de las pulsaciones de las teclas.
Explicaciones U1.1.9.6.
Ejemplo .
U1.1.9.7. Los delincuentes interceptaron la entrada de las credenciales desde el teclado de un dispositivo móvil analizando las lecturas del acelerómetro.
Explicaciones U1.1.9.7.
Ejemplo .
U1.1.10. , previamente guardados en el Cliente.
Explicaciones U1.1.10.
Por ejemplo, el usuario pudo haber guardado en el navegador su nombre de usuario y contraseña para acceder a un sitio web específico.
U1.1.11. Los delincuentes comprometieron las credenciales debido a fallos en el proceso de revocación de accesos de los usuarios.
Explicaciones U1.1.11.
Por ejemplo, después de la despedida del usuario, sus cuentas permanecieron desbloqueadas.
U1.2. debido a la explotación de vulnerabilidades en el sistema de control de acceso.
U2. Elevación no autorizada de privilegios del usuario en el sistema de información.
Descomposición
U2.1 mediante la realización de cambios no autorizados en los datos que contienen información sobre los privilegios del usuario.
U2.2 mediante la explotación de vulnerabilidades en el sistema de control de acceso.
U2.3. debido a fallos en el proceso de gestión de accesos de los usuarios.
Explicaciones U2.3.
Ejemplo 1. Al usuario se le proporcionó acceso mayor del que necesitaba por razones laborales.
Ejemplo 2. Después de transferir al usuario a otro puesto, los derechos de acceso previamente otorgados no fueron revocados.
MODELO TIPO DE AMENAZA. MÓDULO DE INTEGRACIÓN
Objeto de protección, para el cual se aplica el modelo de amenazas (scope)
El módulo de integración es un conjunto de objetos de infraestructura de información, destinado a organizar el intercambio de información entre sistemas de información.
Teniendo en cuenta que en las redes corporativas no siempre es posible separar de manera inequívoca un sistema de información de otro, el módulo de integración también puede considerarse como un vínculo entre componentes dentro de un mismo sistema de información.
Arquitectura
El esquema general del módulo de integración es el siguiente:
Descripción de los elementos de la arquitectura:
- «Servidor de intercambio (SI)» – nodo / servicio / componente del sistema de información que realiza la función de intercambio de datos con otro sistema de información.
- «Intermediario» – nodo / servicio destinado a organizar la interacción entre sistemas de información, pero que no forma parte de ellos.
Ejemplos «Intermediarios» pueden ser servicios de correo electrónico, buses de servicio empresarial (enterprise service bus / arquitectura SoA), servidores de archivos externos, etc. En general, el módulo de integración puede no contener «Intermediarios». - «SO de procesamiento de datos» – conjunto de programas que implementan protocolos de intercambio de datos y transformación de formatos.
Por ejemplo, la transformación de datos del formato UFEB en el formato ABS, el cambio de estados de los mensajes durante la transmisión, etc. - «Conexión de red» corresponde al objeto descrito en el modelo tipo de amenazas «Conexión de red». Algunas conexiones de red de las que se presentan en el esquema anterior pueden no existir.
Ejemplos de módulos de integración
Esquema 1. Integración ABS y ARM KBR a través de un servidor de archivos externo
Para ejecutar pagos, un empleado autorizado del banco descarga desde ABS documentos de pago electrónicos y los guarda en un archivo (de formato propio, por ejemplo, un volcado SQL) en una carpeta de red (…SHARE) del servidor de archivos. Luego, este archivo se convierte mediante un script convertidor en un conjunto de archivos en formato UFEB, que luego lee ARM KBR.
Después de esto, el trabajador autorizado, que es el usuario del APM KBR, cifra y firma el archivo recibido y lo envía al sistema de pagos del Banco de Rusia.
Al recibir pagos del Banco de Rusia, el APM KBR realiza su descifrado y verifica la firma electrónica, luego registra en forma de un conjunto de archivos en formato UFEBS en el servidor de archivos. Antes de importar los documentos de pago en el ABS, se convierten utilizando un script convertidor del formato UFEBS al formato ABS.
Suponemos que en este esquema, el ABS funciona en un servidor físico, el APM KBR opera en una computadora dedicada, y el script convertidor trabaja en el servidor de archivos.
La correspondencia de los objetos en el esquema considerado con los elementos del modelo de módulo de integración:
«Servidores de intercambio del lado del ABS» – servidor ABS.
«Servidores de intercambio del lado del APM KBR» – computadora APM KBR.
«Intermediario» – servidor de archivos externo.
«SO de procesamiento de datos» – script convertidor.
Esquema 2. Integración del ABS y el APM KBR al colocar una carpeta de red compartida con pagos en el APM KBR
Todo es similar al Esquema 1, pero no se utiliza un servidor de archivos separado; en su lugar, la carpeta de red (…SHARE) con los documentos electrónicos de pago se coloca en la computadora con el APM KBR. El script convertidor también funciona en el APM KBR.
La correspondencia de los objetos en el esquema considerado con los elementos del modelo de módulo de integración:
Similar al Esquema 1, pero «Intermediario» no se utiliza.
Esquema 3. Integración del ABS y el APM KBR-N a través de IBM WebSphera MQ y realización de la firma de documentos electrónicos 'del lado del ABS'
El ABS funciona en una plataforma no soportada por el SKZI SKAD Signature. La firma de los documentos electrónicos que salen se realiza en un servidor especial de firma electrónica (Servidor EP). Este mismo servidor verifica la firma electrónica de los documentos que ingresan desde el Banco de Rusia.
El ABS descarga en el Servidor EP un archivo con los documentos de pago en su propio formato.
El Servidor EP, 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 se envían a IBM WebSphere MQ.
El APM KBR-N se conecta a IBM WebSphere MQ y recibe desde allí los mensajes de pago firmados, después de lo cual el trabajador autorizado, que es el usuario del APM KBR, los cifra y los envía al sistema de pagos del Banco de Rusia.
Al recibir los pagos del Banco de Rusia, el ARM 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 envían a IBM WebSphere MQ, desde donde los recibe el Servidor de EP.
El Servidor de EP verifica la firma electrónica de los pagos recibidos y los guarda en un archivo de formato ABS. Después, un trabajador autorizado — usuario de ABS — carga el archivo resultante en ABS de acuerdo con el procedimiento establecido.
La correspondencia de los objetos en el esquema considerado con los elementos del modelo de módulo de integración:
«Servidor de intercambio del lado de ABS» – servidor ABS.
«Servidor de intercambio del lado de ARM KBR» — computadora ARM KBR.
«Intermediario» – Servidor de EP e IBM WebSphere MQ.
«SO de procesamiento de datos» – script convertidor, SKZI SKAD Firma en el Servidor de EP.
Esquema 4. Integración del Servidor de DBO y ABS a través de la API, proporcionada por el servidor de intercambio dedicado
Asumiremos que el banco utiliza varios sistemas de banca a distancia (DBO):
- «Cliente-Banco por Internet» para personas físicas (IKB FL);
- «Cliente-Banco por Internet» para personas jurídicas (IKB UL).
Con el fin de garantizar la seguridad de la información, toda la interacción de ABS con los sistemas DBO se realiza a través de un servidor de intercambio dedicado, que opera dentro del sistema de información «ABS».
A continuación, examinaremos el proceso de interacción del sistema DBO IKB UL con ABS.
El Servidor de DBO, al recibir del cliente un pedido de pago debidamente autorizado, debe crear el documento correspondiente en ABS basado en ello. Para ello, utiliza la API para enviar la información al servidor de intercambio, el cual, a su vez, introduce los datos en ABS.
Al cambiar los saldos en la cuenta del cliente, ABS genera avisos electrónicos, que se envían al servidor DBO a través del servidor de intercambio.
La correspondencia de los objetos en el esquema considerado con los elementos del modelo de módulo de integración:
«Servidor de intercambio del lado de DBO» – servidor DBO IKB UL.
«Servidor de intercambio del lado de ABS» – servidor de intercambio.
«Intermediario» – no disponible.
«SO de procesamiento de datos» – componentes del Servidor de DBO responsables del uso de la API del servidor de intercambio, componentes del servidor de intercambio responsables del uso de la API de ABS.
Amenazas de seguridad de alto nivel
Descomposición
U1. Infiltración de información falsa por parte de atacantes a través del módulo de integración.
U1. Infiltració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:
U1.1.1 Enlace: .
U1.2. Transmisión a través de canales de comunicación de datos falsos en nombre de un participante legítimo en el intercambio:
U1.1.2 Enlace: .
U1.3. Modificación no autorizada de datos legítimos durante su procesamiento en Servidores de intercambio o Intermediario:
U1.3.1. Enlace: .
U1.4. Creación en Servidores de intercambio o Intermediario de datos falsos en nombre de un participante legítimo del intercambio:
U1.4.1. Enlace:
U1.5. Modificación no autorizada de los datos durante su procesamiento mediante software de procesamiento de datos:
U1.5.1. mediante la introducción por parte de los delincuentes de cambios no autorizados en la configuración del software de procesamiento de datos.
U1.5.2. mediante la introducción por parte de los delincuentes de cambios no autorizados en los archivos ejecutables del software de procesamiento de datos.
U1.5.3. mediante el control interactivo por parte de delincuentes del funcionamiento del software de procesamiento de datos.
MODELO TÍPICO DE AMENAZAS. SISTEMA DE PROTECCIÓN CRIPTOGRÁFICA DE LA INFORMACIÓN
Objeto de protección, para el cual se aplica el modelo de amenazas (scope)
El objeto de protección es un sistema de protección criptográfica de la información, 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 (SO), que implementa su funcionalidad objetivo.
La protección criptográfica se realiza normalmente mediante la invocación desde la lógica de negocio del software de aplicación de primitivas criptográficas, que se encuentran 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 de un bloque de datos;
- calcular la función hash de un bloque de datos;
- formar / cargar / descargar información clave;
- etc.
La lógica de negocio del software de aplicación implementa, mediante primitivas criptográficas, funcionalidades de nivel más alto:
- cifrar archivos 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 demás.
La interacción entre la lógica de negocio y el núcleo criptográfico puede realizarse:
- directamente, mediante la invocación de primitivas criptográficas de la lógica de negocio desde bibliotecas dinámicas del núcleo criptográfico (.DLL para Windows, .SO para Linux);
- de manera indirecta, a través de interfaces criptográficas: envolturas (wrappers), como MS Crypto API, Java Cryptography Architecture, PKCS#11, entre otros. En este caso, la lógica de negocio se dirige al criptointerfaz, que traduce la llamada al correspondiente núcleo criptográfico, denominado proveedor criptográfico en este contexto. El uso de interfaces criptográficas permite que el software de aplicación se abstraiga de los algoritmos criptográficos específicos y sea más flexible.
Se pueden distinguir dos esquemas típicos de organización del núcleo criptográfico:
Esquema 1 – Núcleo criptográfico monolítico
Esquema 2 – Núcleo criptográfico dividido
Los elementos en los esquemas presentados pueden ser tanto módulos de software separados que operan en una misma computadora, como servicios de red que interactúan dentro de una red de computación.
En el uso de sistemas organizados según el esquema 1, el software de aplicación y el núcleo criptográfico operan dentro de un entorno funcional unificado del medio criptográfico (SFC), por ejemplo, en la misma computadora, bajo el mismo sistema operativo. El usuario del sistema, por lo general, puede ejecutar en este mismo entorno funcional otros programas, incluidos aquellos que contienen código malicioso. En tales condiciones, existe un riesgo considerable de filtración de claves criptográficas privadas.
Para minimizar el riesgo, se utiliza el esquema 2, donde el núcleo criptográfico se divide en dos partes:
- La primera parte, junto con el software de aplicación, opera en un entorno no confiable, donde existe el riesgo de infección por código malicioso. Llamaremos a esta parte – 'parte de software'.
- La segunda parte opera en un entorno confiable en un dispositivo dedicado, que contiene un almacenamiento de claves privadas. Llamaremos a esta parte – 'parte de hardware'.
La separación del núcleo criptográfico en partes de software y hardware es bastante arbitraria. En el mercado hay sistemas construidos con un núcleo criptográfico dividido, pero cuya parte "hardware" está representada en forma de imagen de máquina virtual: virtual HSM ().
La interacción entre ambas partes del núcleo criptográfico se lleva a cabo de tal manera que las claves criptográficas secretas nunca se transfieren a la parte de software y, por lo tanto, no pueden ser robadas por medio de código malicioso.
La interfaz de interacción (API) y el conjunto de primitivas criptográficas proporcionadas al software de aplicación por el núcleo criptográfico son iguales en ambos casos. La diferencia radica en la forma en que se implementan.
Así, al utilizar un esquema con un núcleo criptográfico dividido, la interacción entre la parte de software y la parte de hardware se lleva a cabo según el siguiente principio:
- Las primitivas criptográficas que no requieren el uso de una clave secreta (por ejemplo, el cálculo de una función hash, la verificación de una firma electrónica, etc.) son ejecutadas por la parte de software.
- Las primitivas criptográficas que utilizan una clave secreta (creación de firma electrónica, descifrado de datos, etc.) son ejecutadas por la parte de hardware.
Ilustremos el funcionamiento del núcleo criptográfico dividido con el ejemplo de la creación de una firma electrónica:
- La parte de software calcula la función hash de los datos firmados y transmite este valor a la parte de hardware a través de un canal de intercambio entre núcleos criptográficos.
- La parte de hardware, utilizando la clave secreta y el hash, forma el valor de la firma electrónica y lo transmite a la parte de software a través del canal de intercambio.
- La parte de software devuelve el valor obtenido al software de aplicación.
Características de la verificación de la validez de la firma electrónica
Cuando la parte receptora recibe los datos firmados con una firma electrónica, debe llevar a cabo varias etapas de verificación. Un resultado positivo de la verificación de la firma electrónica se alcanza solo cuando se superan todas las etapas de verificación.
Etapa 1. Control de integridad de los datos y autoría de los datos.
Contenido de la etapa. Se realiza una verificación de la firma electrónica de los datos según el algoritmo criptográfico correspondiente. La superación exitosa de esta etapa indica que los datos no se han modificado desde su firma, así como que la firma fue realizada con la clave privada correspondiente a la clave pública de verificación de la firma electrónica.
Lugar de ejecución de la etapa: núcleo criptográfico.
Etapa 2. Control de confianza en la clave pública del firmante y control de la validez de la clave privada de la firma electrónica.
Contenido de la etapa. La etapa consta de dos subetapas intermedias. En la primera se determina si la clave pública de verificación de la firma electrónica era de confianza en el momento de la firma de los datos. En la segunda se verifica si la clave privada de la firma electrónica estaba activa en el momento de la firma de los datos. En general, los plazos de validez de estas claves pueden no coincidir (por ejemplo, para certificados cualificados de claves de verificación de firmas electrónicas). Los métodos para establecer la confianza en la clave pública del firmante se determinan por las reglas de intercambio electrónico de documentos adoptadas por las partes intervinientes.
Lugar de ejecución de la etapa: software de aplicación / núcleo criptográfico.
Etapa 3. Control de las facultades del firmante.
Contenido de la etapa. De acuerdo con las reglas establecidas de intercambio electrónico de documentos, se verifica si el firmante tenía derecho a certificar los datos protegidos. Por ejemplo, consideremos una situación de violación de facultades. Supongamos que hay una organización donde todos los empleados tienen una firma electrónica. Un mandato del director llega al sistema interno de intercambio electrónico de documentos, pero es firmado con la firma electrónica del encargado del almacén. En consecuencia, tal documento no puede considerarse legítimo.
Lugar de ejecución de la etapa: software de aplicación.
Suposiciones realizadas al describir el objeto de protección
- Los canales de transmisión de información, a excepción de los canales de intercambio de claves, también pasan a través del software de aplicación, API y núcleo criptográfico.
- La información sobre la confianza en las claves públicas y/o certificados, así como la información sobre las facultades de los propietarios de las claves públicas, se almacena en el repositorio de claves públicas.
- El software de aplicación trabaja con el repositorio de claves públicas a través del núcleo criptográfico.
Ejemplo de un sistema de información protegido mediante criptografía
Para ilustrar los esquemas presentados anteriormente, consideremos un sistema de información hipotético y destaquemos todos sus elementos estructurales.
Descripción del sistema de información
Dos organizaciones decidieron implementar entre sí un flujo de documentos electrónicos (FDE) legalmente vinculante. Para ello, firmaron un acuerdo que estipula que los documentos serán enviados por correo electrónico, debiendo ser encriptados y firmados con una firma electrónica calificada. Se utilizarán programas de oficina del paquete Microsoft Office 2016 para la creación y procesamiento de documentos, y para la protección criptográfica se emplearán el SCZI CryptoPro y el software de encriptación CryptoARM.
Descripción de la infraestructura de la organización 1
La organización 1 decidió que instalaría el SCZI CryptoPro y el software CryptoARM en el equipo del usuario — un ordenador físico. Las claves de encriptación y de firma electrónica se almacenarán en un dispositivo de clave ruToken, que funciona en modo de clave extraíble. El usuario preparará documentos electrónicos localmente en su ordenador, después los encriptará, firmará y enviará utilizando un cliente de correo electrónico instalado localmente.
Descripción de la infraestructura de la organización 2
La organización 2 decidió llevar a cabo las funciones de encriptación y firma electrónica en una máquina virtual dedicada. Todas las operaciones criptográficas se realizarán de manera automática.
Para ello, se configuraron dos carpetas de red en la máquina virtual dedicada: "…In", "…Out". Los archivos recibidos de los contrapartes se colocarán automáticamente en la carpeta de red "…In" en formato abierto. Estos archivos serán desencriptados y se verificará su firma electrónica.
En la carpeta "…Out", el usuario colocará los archivos que necesitan ser encriptados, firmados y enviados al contraparte. Los archivos los preparará el usuario en su equipo.
Para realizar las funciones de encriptación y firma electrónica, se instalaron el SCZI CryptoPro, el software CryptoARM y un cliente de correo electrónico en la máquina virtual. La gestión automática de todos los elementos de la máquina virtual se llevará a cabo mediante scripts desarrollados por los administradores de sistemas. El funcionamiento de los scripts se registra en archivos de logs.
Las claves criptográficas de la firma electrónica se almacenarán en un token con la clave no extraíble JaCarta ГОСТ, que el usuario conectará a su computadora local.
El token se transmitirá a la máquina virtual mediante herramientas de software especializadas USB-over-IP, instaladas en el puesto de trabajo del usuario y en la máquina virtual.
Los horarios del sistema en el puesto de trabajo del usuario en la organización 1 se ajustarán manualmente. Los horarios del sistema de la máquina virtual en la organización 2 se sincronizarán con los horarios del sistema del hipervisor, que a su vez se sincronizarán a través de Internet con servidores de tiempo públicos.
Identificación de los elementos estructurales del SKZI
Con base en la descripción anterior de la infraestructura de TI, identificaremos los elementos estructurales del SKZI y los registraremos en una tabla.
Tabla - Correspondencia de los elementos del modelo SKZI con los elementos de los sistemas de información
Nombre del elemento
Organización 1
Organización 2
Software de aplicación
Software KryptoARM
Software KryptoARM
Parte software del núcleo criptográfico
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP
Parte hardware del núcleo criptográfico
no está presente
JaCarta ГОСТ
API
MS CryptoAPI
MS CryptoAPI
Almacenamiento de claves públicas
Puesto de trabajo del usuario:
— disco duro;
— almacenamiento estándar de certificados de Windows.
Hipervisor:
— disco duro.
Máquina virtual:
— disco duro;
— almacenamiento estándar de certificados de Windows.
Almacenamiento de claves privadas
Dispositivo de clave ruToken, funcionando en modo de clave extraíble
Dispositivo de clave JaCarta ГОСТ, funcionando en modo de clave no extraíble
Canal de intercambio de claves públicas
Puesto de trabajo del usuario:
— memoria RAM.
Hipervisor:
— memoria RAM.
Máquina virtual:
— memoria RAM.
Canal de intercambio de claves privadas
Puesto de trabajo del usuario:
— bus USB;
— memoria RAM.
no está presente
Canal de intercambio entre núcleos criptográficos
no disponible (sin parte hardware del núcleo criptográfico)
Puesto de trabajo del usuario:
— bus USB;
— memoria RAM;
— módulo de software USB-over-IP;
— interfaz de red.
Red corporativa de la organización 2.
Hipervisor:
— memoria RAM;
— interfaz de red.
Máquina virtual:
— interfaz de red;
— memoria RAM;
— módulo de software USB-over-IP.
Canal de intercambio de datos abiertos
Puesto de trabajo del usuario:
— dispositivos de entrada/salida;
— memoria RAM;
— disco duro.
Puesto de trabajo del usuario:
— dispositivos de entrada/salida;
— memoria RAM;
— disco duro;
— interfaz de red.
Red corporativa de la organización 2.
Hipervisor:
— interfaz de red;
— memoria RAM;
— disco duro.
Máquina virtual:
— interfaz de red;
— memoria RAM;
— disco duro.
Canal de intercambio de datos protegidos
Internet.
Red corporativa de la organización 1.
Puesto de trabajo del usuario:
— disco duro;
— memoria RAM;
— interfaz de red.
Internet.
Red corporativa de la organización 2.
Hipervisor:
— interfaz de red;
— memoria RAM;
— disco duro.
Máquina virtual:
— interfaz de red;
— memoria RAM;
— disco duro.
Canal de transmisión de tiempo
Puesto de trabajo del usuario:
— dispositivos de entrada/salida;
— memoria RAM;
— temporizador del sistema.
Internet.
Red corporativa de la organización 2,
Hipervisor:
— interfaz de red;
— memoria RAM;
— temporizador del sistema.
Máquina virtual:
— memoria RAM;
— temporizador del sistema.
Canal de transmisión de comandos de control
Puesto de trabajo del usuario:
— dispositivos de entrada/salida;
— memoria RAM.
(Interfaz gráfica de usuario del software KryptoARM)
Máquina virtual:
— memoria RAM;
— disco duro.
(Scripts de automatización)
Canal de recepción de resultados de trabajo
Puesto de trabajo del usuario:
— dispositivos de entrada/salida;
— memoria RAM.
(Interfaz gráfica de usuario del software KryptoARM)
Máquina virtual:
— memoria RAM;
— disco duro.
(Archivos de registros de trabajo de los scripts de automatización)
Amenazas de seguridad de alto nivel
Explicaciones
Supuestos adoptados al descomponer las amenazas:
- Se utilizan algoritmos criptográficos robustos.
- Los algoritmos criptográficos se utilizan de manera segura en los modos de operación correctos (por ejemplo, no se aplica para cifrar grandes volúmenes de datos, teniendo en cuenta la carga admisible en la clave, etc.).
- Los atacantes conocen todos los algoritmos, protocolos y claves públicas utilizados.
- Todos los datos cifrados son accesibles para los atacantes.
- Los atacantes son capaces de reproducir cualquier elemento de software 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 los destinatarios legítimos de la información (atacantes).
U4. Creación de una firma electrónica por parte de un firmante legítimo sobre datos falsos.
U5. Obtención de un resultado positivo al verificar la firma electrónica sobre datos falsos.
U6. Aceptación errónea de documentos electrónicos para su ejecución debido a problemas en la organización del intercambio electrónico de documentos.
U7. Acceso no autorizado a datos protegidos durante su procesamiento en el Sistema de Criptografía.
U1. Compromiso de claves criptográficas privadas
U1.1. Obtención de la clave privada del almacén de claves privadas.
U1.2. Obtención de la clave privada de los objetos del entorno de operación de los medios criptográficos, donde puede encontrarse temporalmente.
Explicaciones U1.2.
Los objetos en los que la clave privada puede almacenarse temporalmente incluyen:
- memoria RAM,
- archivos temporales,
- archivos de intercambio,
- archivos de hibernación,
- archivos de instantáneas del estado 'en caliente' de máquinas virtuales, incluidos los archivos de contenido de la memoria RAM de máquinas virtuales que se han puesto en pausa.
U1.2.1. Extracción de claves privadas de la memoria RAM activa mediante la congelación de módulos de RAM, su extracción y posterior lectura de datos (ataque de congelación).
Explicaciones U1.2.1.
Ejemplo .
U1.3. Obtención de la clave privada del canal de intercambio de claves privadas.
Explicaciones U1.3.
Un ejemplo de la implementación de esta amenaza será proporcionado .
U1.4. Modificación no autorizada del núcleo criptográfico, como resultado de lo cual las claves privadas se vuelven conocidas para los atacantes.
U1.5. Compromiso de la clave privada como resultado del uso de canales técnicos de filtración de información (CTFI).
Explicaciones U1.5.
Ejemplo .
U1.6. Compromiso de la clave privada como resultado del uso de medios técnicos especiales (MTE), diseñados para la recolección encubierta de información (‘bugs’).
U1.7. Compromiso de las claves privadas durante su almacenamiento fuera de SKZI.
Explicaciones U1.7.
Por ejemplo, un usuario almacena sus soportes clave en un cajón de su escritorio, de donde pueden ser fácilmente extraídos por los atacantes.
U2. Encriptación de datos falsos en nombre de un remitente legítimo.
Explicaciones
Esta amenaza se considera solo para esquemas de cifrado de datos con autenticación del remitente. Ejemplos de tales esquemas se especifican en las recomendaciones de estandarización. . Para los demás esquemas criptográficos, esta amenaza no existe, ya que la encriptación se realiza con las claves públicas del destinatario, que en general son conocidas por los atacantes.
Descomposición
U2.1. Compromiso de la clave privada del remitente:
U2.1.1. Enlace: .
U2.2. Sustitución de los datos de entrada en el canal de intercambio de datos abiertos.
Notas U2.2.
Los ejemplos de implementación de esta amenaza se presentan a continuación. y .
U3. Descifrado de datos cifrados por personas que no son los destinatarios legítimos de los datos (atacantes).
Descomposición
U3.1. Compromiso de las claves privadas del destinatario de datos cifrados.
U3.1.1 Enlace: .
U3.2. Sustitución de los datos cifrados en el canal de intercambio de datos protegidos.
U4. Creación de la firma electrónica de un firmante legítimo sobre datos falsos.
Descomposición
U4.1. Compromiso de las claves privadas de la firma electrónica del firmante legítimo.
U4.1.1 Enlace: .
U4.2. Sustitución de los datos firmados en el canal de intercambio de datos abiertos.
Nota U4.2.
Los ejemplos de implementación de esta amenaza se presentan a continuación. y .
U5. Obtención de un resultado positivo de la verificación de la firma electrónica sobre datos falsos.
Descomposición
U5.1. Los atacantes interceptan en el canal de transmisión de resultados un mensaje sobre el resultado negativo de la verificación de la firma electrónica y lo reemplazan por un mensaje con un resultado positivo.
U5.2. Los atacantes llevan a cabo un ataque a la confianza en los certificados de firma (ESCENARIO — todos los elementos son obligatorios):
U5.2.1. Los atacantes generan una clave pública y una clave privada de firma electrónica. Si se utilizan certificados de claves de firma electrónica en el sistema, generan un certificado de firma electrónica que se asemeja lo más posible al certificado del supuesto remitente de los datos cuyo mensaje intentan falsificar.
U5.2.2. Los atacantes realizan cambios no autorizados en el almacenamiento de claves públicas, otorgando a la clave pública generada por ellos el nivel de confianza y las capacidades necesarias.
U5.2.3. Los atacantes firman datos falsos con la clave de firma electrónica previamente formada e inyectan estos datos en el canal de intercambio de datos protegidos.
U5.3. Los atacantes llevan a cabo un ataque utilizando claves de firma electrónica caducadas de un firmante legítimo (ESCENARIO — todos los elementos son obligatorios):
U5.3.1. Los atacantes comprometen las claves privadas caducadas (actualmente no válidas) de un remitente legítimo.
U5.3.2. Los atacantes sustituyen el tiempo en el canal de transmisión por un momento en el que las claves comprometidas todavía eran válidas.
U5.3.3. Los atacantes firman datos falsos con la clave de firma electrónica previamente comprometida e inyectan estos datos en el canal de intercambio de datos protegidos.
U5.4. Los atacantes llevan a cabo un ataque utilizando claves de firma electrónica comprometidas de un firmante legítimo (ESCENARIO — todos los elementos son obligatorios):
U5.4.1. Los atacantes hacen una copia del almacenamiento de claves públicas.
U5.4.2. Los atacantes comprometen las claves privadas de uno de los remitentes legales. Este nota la compromisión, revoca las claves, y la información sobre la revocación de la clave se coloca en el almacenamiento de claves públicas.
U5.4.3. Los atacantes reemplazan el almacenamiento de claves públicas por el que habían copiado anteriormente.
U5.4.4. Los atacantes firman datos falsos con la clave de firma electrónica previamente comprometida e inyectan estos datos en el canal de intercambio de datos protegidos.
U5.5. debido a errores en la implementación de la 2ª y 3ª etapa de verificación de la firma electrónica:
Explicaciones U5.5.
El ejemplo de implementación de esta amenaza es el siguiente .
U5.5.1. La verificación de confianza en el certificado de la clave de la firma electrónica se basa solo en la confianza en el certificado con el que fue firmado, sin verificaciones de CRL o OCSP.
Explicaciones U5.5.1.
Ejemplo de implementación .
U5.5.2. Al construir la cadena de confianza del certificado, no se analizan las competencias de los certificados emisores.
Explicaciones U5.5.2.
Ejemplo de ataque dirigido a certificados SSL/TLS.
Los atacantes compraron un certificado legítimo para su correo electrónico. Luego, crearon un certificado fraudulento para un sitio y lo firmaron con su propio certificado. Si no se realiza la verificación de competencias, la verificación de la cadena de confianza será correcta y, por lo tanto, el certificado fraudulento también será considerado válido.
U5.5.3. Al construir la cadena de confianza del certificado, no se verifican los certificados intermedios para su revocación.
U5.5.4. La actualización de CRL ocurre con menos frecuencia de la que emite la autoridad certificadora.
U5.5.5. La decisión sobre la confianza en la firma electrónica se toma antes de recibir la respuesta OCSP sobre el estado del certificado, que se envió en una solicitud hecha después del momento de formación de la firma, o antes de recibir el siguiente CRL posterior a la formación de la firma.
Explicaciones U5.5.5.
En la regulación de la mayoría de las AC, el tiempo de revocación del certificado se considera el tiempo de emisión del CRL más cercano, que contiene información sobre la revocación del certificado.
U5.5.6. Al recibir datos firmados, no se verifica la pertenencia del certificado al remitente.
Explicaciones U5.5.6.
Ejemplo de ataque. En el caso de los certificados SSL: puede no verificarse la coincidencia de la dirección del servidor llamado con 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. Luego, hackearon la red de otro participante y enviaron en su nombre documentos de pago al servidor de liquidación del sistema de pago, firmados con las claves comprometidas. Si el servidor analiza solo la confianza y no verifica la coincidencia, los documentos fraudulentos se considerarían legítimos.
U6. Aceptación errónea de documentos electrónicos para su ejecución debido a problemas en la organización del intercambio electrónico de documentos.
Descomposición
U6.1. La parte receptora no detecta duplicación en los documentos recibidos.
Explicaciones U6.1.
Ejemplo de ataque. Los atacantes pueden interceptar el documento que se envía al destinatario, incluso si está protegido criptográficamente, y luego enviarlo repetidamente a través del canal de transmisión de datos protegidos. Si el destinatario no detecta duplicados, todos los documentos recibidos se considerarán y procesarán como documentos distintos.
U7. Acceso no autorizado a datos protegidos durante su procesamiento por SKZI.
Descomposición
U7.1. como resultado de una fuga de información a través de canales externos (ataque de canal lateral).
Explicaciones U7.1.
Ejemplo .
U7.2. como resultado de la neutralización de la protección contra el acceso no autorizado a la información procesada en SKZI:
U7.2.1. Explotación de SKZI con violaciones de los requisitos descritos en la documentación de SKZI.
U7.2.2. , realizada debido a la existencia de vulnerabilidades en:
U7.2.2.1. medios de protección contra el acceso no autorizado.
U7.2.2.2. el propio SKZI.
U7.2.2.3. entorno de funcionamiento de la criptografía.
Ejemplos de ataques
Los escenarios descritos a continuación contienen errores evidentes en la organización de la seguridad de la información y sirven solo para ilustrar posibles ataques.
Escenario 1. Ejemplo de implementación de las amenazas U2.2 y U4.2.
Descripción del objeto
El software ARM KBR y SKZI SKAD está instalado en un ordenador físico, no conectado a la red de computación. Se utiliza un soporte clave FKN vdToken en modo de operación con clave no extraíble.
El reglamento para la realización de cálculos prevé que el especialista en cálculos descargue los mensajes electrónicos en abierto (esquema del antiguo ARM KBR) desde un servidor de archivos protegido, luego los copie a un dispositivo extraíble USB y los transfiera al ARM KBR, donde los cifra y los firma. Después, el especialista transfiere los mensajes electrónicos protegidos a un dispositivo extraíble, y luego a través de su computadora de trabajo los carga al servidor de archivos, desde donde llegan al UTA y luego al sistema de pagos del Banco de Rusia.
En este caso, los canales de intercambio de datos abiertos y protegidos incluirán: el servidor de archivos, la computadora de trabajo del especialista y el dispositivo extraíble.
Ataque
Los atacantes instalan sin autorización un sistema de control remoto en el ordenador de trabajo del especialista y, en el momento de grabar en el medio de transmisión los pagos (mensajes electrónicos), sustituyen el contenido de uno de ellos en texto abierto. El especialista transfiere los pagos al AРM KBR, los firma y cifra, sin notar el reemplazo (por ejemplo, debido a la gran cantidad de pagos en curso, fatiga, etc.). Después de eso, el pago falso, pasando por la cadena tecnológica, llega al sistema de pagos del Banco de Rusia.
Escenario 2. Ejemplo de implementación de las amenazas U2.2 y U4.2.
Descripción del objeto
Un ordenador con AРM KBR instalado, SCAD Signature y un dispositivo de clave FКN vdToken funciona en un espacio privado sin acceso por parte del personal.
El especialista en pagos se conecta al AРM KBR en modo de acceso remoto a través del protocolo RDP.
Ataque
Los atacantes interceptan los detalles que utiliza el especialista en pagos para conectarse y trabajar con el AРM KBR (por ejemplo, a través de un código malicioso en su ordenador). Luego se conectan en su nombre y envían un pago falso al sistema de pagos del Banco de Rusia.
Escenario 3. Ejemplo de implementación de la amenaza U1.3.
Descripción del objeto
Consideremos una de las opciones hipotéticas de implementación de los módulos de integración 'ABS-KBR' para un nuevo esquema (AРM KBR-N), donde la firma electrónica de los documentos salientes se realiza en el lado de ABS. Supondremos que ABS funciona en un sistema operativo que no es compatible con el esquema criptográfico SCAD Signature y, en consecuencia, la funcionalidad criptográfica se ha trasladado a una máquina virtual separada: el módulo de integración 'ABS-KBR'.
Como dispositivo clave se utiliza un token USB normal que opera en modo de clave extraíble. Al conectar el dispositivo clave al hipervisor, se encontró 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 en red, y en la máquina virtual se instaló un cliente USB-over-IP, que establecerá la conexión con el concentrador.
Ataque
Los delincuentes interceptaron la clave privada de la firma electrónica a través del canal de comunicación entre el concentrador USB y el hipervisor (los datos se transmitían en texto claro). Con la clave privada, los delincuentes formaron una orden de pago falsa, la firmaron con la firma electrónica y la enviaron al APM KBR-N para su ejecución.
Escenario 4. Ejemplo de implementación de las amenazas U5.5.
Descripción del objeto
Consideremos el mismo esquema que en el escenario anterior. Supongamos que los mensajes electrónicos que llegan del APM KBR-N se colocan en la carpeta …SHAREIn, y aquellos que se envían al APM KBR-N y luego al sistema de pagos del Banco de Rusia, se colocan en …SHAREout.
También asumiremos que al implementar el módulo de integración, las listas de certificados revocados solo se actualizan al reemitir claves criptográficas, y que los mensajes electrónicos que ingresan a la carpeta …SHAREIn se verifican únicamente en términos de control de integridad y control de confianza en la clave pública de la firma electrónica.
Ataque
Los delincuentes, aprovechando las claves robadas en el escenario anterior, firmaron una orden de pago falsa que contenía información sobre el ingreso de dinero en la cuenta de un cliente estafador e la introdujeron en el canal de intercambio de datos seguros. Dado que no se verifica que la orden de pago esté firmada precisamente por el Banco de Rusia, se acepta para su ejecución.
Fuente: habr.com
