Ligazóns a outras partes do estudo
- (Estás aquí)
Este artigo completa a serie de publicacións dedicadas a garantir a seguridade da información dos pagamentos bancarios non en efectivo. Aquí veremos os modelos de ameaza típicos aos que se refire :
- .
- .
- .
- .
HABRO-ADVERTENCIA!!! Queridos Khabrovites, esta non é unha publicación entretida.
As máis de 40 páxinas de materiais escondidos baixo o corte están destinadas a axuda no traballo ou no estudo persoas especializadas en banca ou seguridade da información. Estes materiais son o produto final da investigación e están escritos nun ton seco e formal. En esencia, estes son espazos en branco para documentos internos de seguridade da información.Ben, tradicional - "O uso da información do artigo con fins ilegais está sancionado pola lei". Lectura produtiva!
Información para lectores que se familiaricen co estudo que comeza con esta publicación.
De que trata o estudo?
Estás lendo unha guía para un especialista responsable de garantir a seguridade da información dos pagos nun banco.
Lóxica da presentación
Ao comezo en и ofrécese unha descrición do obxecto protexido. Despois en describe como construír un sistema de seguridade e fala da necesidade de crear un modelo de ameazas. EN fala de que modelos de ameaza existen e como se forman. EN и Ofrécese unha análise de ataques reais. и conteñen unha descrición do modelo de ameaza, construído tendo en conta a información de todas as partes anteriores.
MODELO TÍPICO DE AMEAZA. CONEXIÓN A REDE
Obxecto de protección para o que se aplica o modelo de ameaza (ámbito).
O obxecto da protección son os datos transmitidos a través dunha conexión de rede que opera en redes de datos construídas sobre a base da pila TCP/IP.
Arquitectura
Descrición dos elementos arquitectónicos:
- "Nodos finais" — nodos que intercambian información protexida.
- "Nodos intermedios" — elementos dunha rede de transmisión de datos: enrutadores, conmutadores, servidores de acceso, servidores proxy e outros equipos — a través dos cales se transmite o tráfico de conexión de rede. En xeral, unha conexión de rede pode funcionar sen nós intermedios (directamente entre os nodos finais).
Ameazas de seguridade de primeiro nivel
Descomposición
U1. Acceso non autorizado aos datos transmitidos.
U2. Modificación non autorizada dos datos transmitidos.
U3. Infracción da autoría dos datos transmitidos.
U1. Acceso non autorizado aos datos transmitidos
Descomposición
U1.1. <…>, realizada nos nodos finais ou intermedios:
U1.1.1. <…> lendo os datos mentres están nos dispositivos de almacenamento do host:
U1.1.1.1. <…> en RAM.
Explicacións para U1.1.1.1.
Por exemplo, durante o procesamento de datos pola pila de rede do host.
U1.1.1.2. <…> en memoria non volátil.
Explicacións para U1.1.1.2.
Por exemplo, cando se almacenan datos transmitidos nunha caché, ficheiros temporais ou ficheiros de intercambio.
U1.2. <…>, realizado en nodos de terceiros da rede de datos:
U1.2.1. <...> polo método de capturar todos os paquetes que chegan á interface de rede do host:
Explicacións para U1.2.1.
A captura de todos os paquetes realízase cambiando a tarxeta de rede ao modo promiscuo (modo promiscuo para adaptadores con cable ou modo monitor para adaptadores wi-fi).
U1.2.2. <…> realizando ataques man-in-the-middle (MiTM), pero sen modificar os datos transmitidos (sen contar os datos do servizo do protocolo de rede).
U1.2.2.1. Ligazón: .
U1.3. <…>, realizada por fuga de información por vías técnicas (TKUI) desde nodos físicos ou liñas de comunicación.
U1.4. <…>, realizada mediante a instalación de medios técnicos especiais (STS) nos nodos finais ou intermedios, destinados á recollida secreta de información.
U2. Modificación non autorizada dos datos transmitidos
Descomposición
U2.1. <…>, realizada nos nodos finais ou intermedios:
U2.1.1. <…> lendo e facendo cambios nos datos mentres están nos dispositivos de almacenamento dos nodos:
U2.1.1.1. <...> en RAM:
U2.1.1.2. <…> en memoria non volátil:
U2.2. <…>, realizada en nodos de terceiros da rede de transmisión de datos:
U2.2.1. <…> levando a cabo ataques man-in-the-middle (MiTM) e redirixindo o tráfico ao nodo dos atacantes:
U2.2.1.1. A conexión física dos equipos dos atacantes fai que a conexión de rede se rompa.
U2.2.1.2. Realizar ataques a protocolos de rede:
U2.2.1.2.1. <…> xestión de redes locais virtuais (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Modificación non autorizada da configuración da VLAN en conmutadores ou enrutadores.
U2.2.1.2.2. <…> ruta de tráfico:
U2.2.1.2.2.1. Modificación non autorizada das táboas de enrutamento estáticas dos enrutadores.
U2.2.1.2.2.2. Anuncio de rutas falsas por parte dos atacantes mediante protocolos de enrutamento dinámico.
U2.2.1.2.3. <…> configuración automática:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> enderezo e resolución de nomes:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Realizar cambios non autorizados nos ficheiros de nomes de host locais (hosts, lmhosts, etc.)
U3. Infracción dos dereitos de autor dos datos transmitidos
Descomposición
U3.1. Neutralización dos mecanismos para determinar a autoría da información mediante a indicación de información falsa sobre o autor ou fonte de datos:
U3.1.1. Modificación da información sobre o autor contida na información transmitida.
U3.1.1.1. Neutralización da protección criptográfica da integridade e autoría dos datos transmitidos:
U3.1.1.1.1. Ligazón: .
U3.1.1.2. Neutralización da protección dos dereitos de autor dos datos transmitidos, implementada mediante códigos de confirmación únicos:
U3.1.1.2.1. .
U3.1.2. Modificación da información sobre a fonte da información transmitida:
U3.1.2.1. .
U3.1.2.2. .
MODELO TÍPICO DE AMEAZA. SISTEMA DE INFORMACIÓN CONSTRUIDO A BASE DA ARQUITECTURA CLIENTE-SERVIDOR
Obxecto de protección para o que se aplica o modelo de ameaza (ámbito).
O obxecto da protección é un sistema de información construído sobre a base dunha arquitectura cliente-servidor.
Arquitectura
Descrición dos elementos arquitectónicos:
- "Clienta" – un dispositivo no que opera a parte cliente do sistema de información.
- "Servidor" – un dispositivo no que funciona a parte servidor do sistema de información.
- "Almacenamento de datos" — parte da infraestrutura de servidores dun sistema de información, deseñada para almacenar datos procesados polo sistema de información.
- "Conexión de rede" — unha canle de intercambio de información entre o Cliente e o Servidor que pasa pola rede de datos. Encontrarase unha descrición máis detallada do modelo de elementos .
Restricións
Ao modelar un obxecto, establécense as seguintes restricións:
- O usuario interactúa co sistema de información en períodos finitos de tempo, denominados sesións de traballo.
- Ao comezo de cada sesión de traballo, o usuario é identificado, autenticado e autorizado.
- Toda a información protexida almacénase na parte do servidor do sistema de información.
Ameazas de seguridade de primeiro nivel
Descomposición
U1. Realización de accións non autorizadas por parte dos atacantes en nome dun usuario lexítimo.
U2. Modificación non autorizada da información protexida durante o seu tratamento pola parte servidor do sistema de información.
U1. Realización de accións non autorizadas por parte dos atacantes en nome dun usuario lexítimo
Explicacións
Normalmente, nos sistemas de información, as accións están correlacionadas co usuario que as realizou mediante:
- rexistros de operacións do sistema (logs).
- atributos especiais dos obxectos de datos que conteñen información sobre o usuario que os creou ou modificou.
En relación a unha sesión de traballo, esta ameaza pódese descompoñer en:
- <…> realizado dentro da sesión do usuario.
- <…> executado fóra da sesión do usuario.
Pódese iniciar unha sesión de usuario:
- Polo propio usuario.
- Malfeitores.
Nesta fase, a descomposición intermedia desta ameaza terá o seguinte aspecto:
U1.1. Realizáronse accións non autorizadas nunha sesión de usuario:
U1.1.1. <…> instalado polo usuario atacado.
U1.1.2. <…> instalado por atacantes.
U1.2. Realizáronse accións non autorizadas fóra da sesión do usuario.
Desde o punto de vista dos obxectos de infraestrutura de información que poden verse afectados por atacantes, a descomposición das ameazas intermedias terá o seguinte aspecto:
Elementos
Descomposición da ameaza
U1.1.1.
U1.1.2.
U1.2.
Cliente
U1.1.1.1.
U1.1.2.1.
Conexión de rede
U1.1.1.2.
Servidor
U1.2.1.
Descomposición
U1.1. Realizáronse accións non autorizadas nunha sesión de usuario:
U1.1.1. <…> instalado polo usuario atacado:
U1.1.1.1. Os atacantes actuaron independentemente do Cliente:
U1.1.1.1.1 Os atacantes utilizaron ferramentas estándar de acceso ao sistema de información:
U1.1.1.1.1.1. Os atacantes utilizaron os medios físicos de entrada/saída do Cliente (teclado, rato, monitor ou pantalla táctil dun dispositivo móbil):
U1.1.1.1.1.1.1. Os atacantes operaron durante períodos de tempo nos que a sesión estaba activa, as instalacións de E/S estaban dispoñibles e o usuario non estaba presente.
У1.1.1.1.1.2. Os atacantes utilizaron ferramentas de administración remota (estándar ou proporcionadas por código malicioso) para xestionar o Cliente:
U1.1.1.1.1.2.1. Os atacantes operaron durante períodos de tempo nos que a sesión estaba activa, as instalacións de E/S estaban dispoñibles e o usuario non estaba presente.
U1.1.1.1.1.2.2. Os atacantes utilizaron ferramentas de administración remota, cuxo funcionamento é invisible para o usuario atacado.
U1.1.1.2. Os atacantes substituíron os datos da conexión de rede entre o Cliente e o Servidor, modificándoos de tal xeito que se percibían como accións dun usuario lexítimo:
U1.1.1.2.1. Ligazón: .
U1.1.1.3. Os atacantes obrigaron ao usuario a realizar as accións que especificaron mediante métodos de enxeñería social.
У1.1.2 <...> instalado por atacantes:
U1.1.2.1. Os atacantes actuaron dende o Cliente (И):
U1.1.2.1.1. Os atacantes neutralizaron o sistema de control de acceso do sistema de información:
U1.1.2.1.1.1. Ligazón: .
У1.1.2.1.2. Os atacantes utilizaron ferramentas estándar de acceso ao sistema de información
U1.1.2.2. Os atacantes operaban desde outros nodos da rede de datos, desde os que se podía establecer unha conexión de rede co servidor (И):
U1.1.2.2.1. Os atacantes neutralizaron o sistema de control de acceso do sistema de información:
U1.1.2.2.1.1. Ligazón: .
U1.1.2.2.2. Os atacantes utilizaron medios non estándar para acceder ao sistema de información.
Explicacións U1.1.2.2.2.
Os atacantes poderían instalar un cliente estándar do sistema de información nun nodo de terceiros ou poderían utilizar software non estándar que implemente protocolos de intercambio estándar entre o Cliente e o Servidor.
U1.2 Realizáronse accións non autorizadas fóra da sesión do usuario.
U1.2.1 Os atacantes realizaron accións non autorizadas e despois realizaron cambios non autorizados nos rexistros de operacións do sistema de información ou nos atributos especiais dos obxectos de datos, indicando que as accións que realizaron foron realizadas por un usuario lexítimo.
U2. Modificación non autorizada da información protexida durante o seu tratamento pola parte servidor do sistema de información
Descomposición
U2.1. Os atacantes modifican a información protexida mediante ferramentas estándar do sistema de información e fano en nome dun usuario lexítimo.
U2.1.1. Ligazón: .
U2.2. Os atacantes modifican a información protexida mediante mecanismos de acceso a datos non previstos polo funcionamento normal do sistema de información.
U2.2.1. Os atacantes modifican ficheiros que conteñen información protexida:
U2.2.1.1. <…>, utilizando os mecanismos de manexo de ficheiros proporcionados polo sistema operativo.
U2.2.1.2. <…> provocando a restauración de ficheiros desde unha copia de seguranza modificada non autorizada.
U2.2.2. Os atacantes modifican a información protexida almacenada na base de datos (И):
U2.2.2.1. Os atacantes neutralizan o sistema de control de acceso ao DBMS:
U2.2.2.1.1. Ligazón: .
U2.2.2.2. Os atacantes modifican a información usando interfaces de DBMS estándar para acceder aos datos.
U2.3. Os atacantes modifican a información protexida mediante a modificación non autorizada dos algoritmos operativos do software que a procesa.
U2.3.1. O código fonte do software está suxeito a modificación.
U2.3.1. O código de máquina do software está suxeito a modificación.
U2.4. Os atacantes modifican a información protexida explotando vulnerabilidades do software do sistema de información.
U2.5. Os atacantes modifican a información protexida cando se transfire entre compoñentes da parte do servidor do sistema de información (por exemplo, un servidor de bases de datos e un servidor de aplicacións):
U2.5.1. Ligazón: .
MODELO TÍPICO DE AMEAZA. SISTEMA DE CONTROL DE ACCESO
Obxecto de protección para o que se aplica o modelo de ameaza (ámbito).
O obxecto de protección para o que se aplica este modelo de ameaza correspóndese co obxecto de protección do modelo de ameaza: “Modelo de ameaza típico. Un sistema de información construído sobre unha arquitectura cliente-servidor”.
Neste modelo de ameaza, un sistema de control de acceso de usuarios significa un compoñente dun sistema de información que implementa as seguintes funcións:
- Identificación do usuario.
- Autenticación de usuario.
- Autorizacións de usuarios.
- Rexistro de accións do usuario.
Ameazas de seguridade de primeiro nivel
Descomposición
U1. Establecemento non autorizado dunha sesión en nome dun usuario lexítimo.
U2. Aumento non autorizado dos privilexios dos usuarios nun sistema de información.
U1. Establecemento non autorizado dunha sesión en nome dun usuario lexítimo
Explicacións
A descomposición desta ameaza dependerá, en xeral, do tipo de sistemas de identificación e autenticación de usuarios utilizados.
Neste modelo, só se considerará un sistema de identificación e autenticación de usuarios mediante o inicio de sesión de texto e o contrasinal. Neste caso, asumiremos que o inicio de sesión do usuario é información dispoñible publicamente coñecida polos atacantes.
Descomposición
U1.1. <…> debido ao compromiso de credenciais:
U1.1.1. Os atacantes comprometeron as credenciais do usuario mentres as almacenaban.
Explicacións U1.1.1.
Por exemplo, as credenciais poderían escribirse nunha nota adhesiva pegada ao monitor.
U1.1.2. O usuario pasou de forma accidental ou maliciosa os datos de acceso aos atacantes.
U1.1.2.1. O usuario falou as credenciais en voz alta mentres entraba.
U1.1.2.2. O usuario compartiu intencionadamente as súas credenciais:
U1.1.2.2.1. <…> aos compañeiros de traballo.
Explicacións U1.1.2.2.1.
Por exemplo, para que poidan substituílo durante a enfermidade.
U1.1.2.2.2. <…> aos contratistas do empresario que realicen traballos en obxectos de infraestrutura de información.
U1.1.2.2.3. <...> a terceiros.
Explicacións U1.1.2.2.3.
Unha, pero non a única opción para implementar esta ameaza é o uso de métodos de enxeñería social por parte dos atacantes.
U1.1.3. Os atacantes seleccionaron as credenciais mediante métodos de forza bruta:
U1.1.3.1. <…> utilizando mecanismos de acceso estándar.
U1.1.3.2. <…> usando códigos interceptados previamente (por exemplo, hash de contrasinais) para almacenar as credenciais.
U1.1.4. Os atacantes utilizaron código malicioso para interceptar as credenciais dos usuarios.
U1.1.5. Os atacantes extraeron as credenciais da conexión de rede entre o cliente e o servidor:
U1.1.5.1. Ligazón: .
U1.1.6. Os atacantes extraeron as credenciais dos rexistros dos sistemas de seguimento do traballo:
U1.1.6.1. <…> sistemas de videovixilancia (se as pulsacións do teclado foron gravadas durante o funcionamento).
U1.1.6.2. <…> sistemas de seguimento das accións dos empregados no ordenador
Explicacións U1.1.6.2.
Un exemplo deste sistema é .
U1.1.7. Os atacantes comprometeron as credenciais dos usuarios debido a fallos no proceso de transmisión.
Explicacións U1.1.7.
Por exemplo, enviar contrasinais en texto claro por correo electrónico.
U1.1.8. Os atacantes obtiveron credenciais supervisando a sesión dun usuario mediante sistemas de administración remota.
U1.1.9. Os atacantes obtiveron credenciais como resultado da súa filtración a través de canles técnicas (TCUI):
U1.1.9.1. Os atacantes observaron como o usuario introducía as credenciais desde o teclado:
U1.1.9.1.1 Os atacantes localizáronse moi preto do usuario e viron a entrada das credenciais cos seus propios ollos.
Explicacións U1.1.9.1.1
Estes casos inclúen as accións dos compañeiros de traballo ou o caso en que o teclado do usuario é visible para os visitantes da organización.
U1.1.9.1.2 Os atacantes utilizaron medios técnicos adicionais, como prismáticos ou un vehículo aéreo non tripulado, e viron a entrada das credenciais por unha fiestra.
U1.1.9.2. Os atacantes extraeron as credenciais das comunicacións de radio entre o teclado e a unidade do sistema informático cando estaban conectados a través dunha interface de radio (por exemplo, Bluetooth).
U1.1.9.3. Os atacantes interceptaron as credenciais filtrandoas pola canle de interferencias e radiacións electromagnéticas espurias (PEMIN).
Explicacións U1.1.9.3.
Exemplos de ataques и .
U1.1.9.4. O atacante interceptou a entrada de credenciais desde o teclado mediante o uso de medios técnicos especiais (STS) deseñados para obter información secretamente.
Explicacións U1.1.9.4.
Exemplos .
U1.1.9.5. Os atacantes interceptaron a entrada de credenciais desde o teclado usando
análise do sinal Wi-Fi modulado polo proceso de pulsación da tecla do usuario.
Explicacións U1.1.9.5.
Exemplo .
U1.1.9.6. Os atacantes interceptaron a entrada de credenciais desde o teclado analizando os sons das pulsacións de teclas.
Explicacións U1.1.9.6.
Exemplo .
U1.1.9.7. Os atacantes interceptaron a entrada de credenciais desde o teclado dun dispositivo móbil mediante a análise das lecturas do acelerómetro.
Explicacións U1.1.9.7.
Exemplo .
U1.1.10. <…>, previamente gardado no Cliente.
Explicacións U1.1.10.
Por exemplo, un usuario pode gardar un inicio de sesión e un contrasinal no navegador para acceder a un sitio específico.
U1.1.11. Os atacantes comprometeron as credenciais debido a fallos no proceso de revogación do acceso dos usuarios.
Explicacións U1.1.11.
Por exemplo, despois de que un usuario fose despedido, as súas contas permaneceron desbloqueadas.
U1.2. <…> explotando vulnerabilidades no sistema de control de acceso.
U2. Elevación non autorizada de privilexios de usuario nun sistema de información
Descomposición
U2.1 <...> facendo cambios non autorizados nos datos que conteñan información sobre privilexios de usuario.
U2.2 <…> mediante o uso de vulnerabilidades no sistema de control de acceso.
U2.3. <…> debido a deficiencias no proceso de xestión de acceso de usuarios.
Explicacións U2.3.
Exemplo 1. Un usuario recibiu máis acceso por motivos de traballo do que necesitaba por motivos comerciais.
Exemplo 2: despois de que un usuario fose transferido a outra posición, os dereitos de acceso concedidos anteriormente non foron revogados.
MODELO TÍPICO DE AMEAZA. MÓDULO DE INTEGRACIÓN
Obxecto de protección para o que se aplica o modelo de ameaza (ámbito).
Un módulo de integración é un conxunto de obxectos de infraestrutura de información deseñados para organizar o intercambio de información entre sistemas de información.
Tendo en conta o feito de que nas redes corporativas non sempre é posible separar sen ambigüidades un sistema de información doutro, o módulo de integración tamén se pode considerar como un vínculo de conexión entre os compoñentes dun sistema de información.
Arquitectura
O diagrama xeralizado do módulo de integración ten o seguinte aspecto:
Descrición dos elementos arquitectónicos:
- "Servidor de intercambio (SO)" – un nodo/servizo/compoñente dun sistema de información que realiza a función de intercambiar datos con outro sistema de información.
- "Mediador" – un nodo/servizo deseñado para organizar a interacción entre sistemas de información, pero non parte deles.
Exemplos "Intermediarios" pode haber servizos de correo electrónico, buses de servizos empresariais (bus de servizos empresariais / arquitectura SoA), servidores de ficheiros de terceiros, etc. En xeral, o módulo de integración pode non conter "Intermediarios". - "Software de procesamento de datos" – un conxunto de programas que implementan protocolos de intercambio de datos e conversión de formatos.
Por exemplo, converter datos do formato UFEBS ao formato ABS, cambiar o estado das mensaxes durante a transmisión, etc. - "Conexión de rede" corresponde ao obxecto descrito no modelo de ameaza estándar "Conexión de rede". Algunhas das conexións de rede que se mostran no diagrama anterior poden non existir.
Exemplos de módulos de integración
Esquema 1. Integración de ABS e AWS KBR a través dun servidor de ficheiros de terceiros
Para executar pagos, un empregado bancario autorizado descarga documentos de pago electrónico do sistema bancario principal e gárdaos nun ficheiro (no seu propio formato, por exemplo un volcado SQL) nun cartafol de rede (...COMPARTIR) nun servidor de ficheiros. A continuación, este ficheiro convértese mediante un script de conversión nun conxunto de ficheiros no formato UFEBS, que despois son lidos pola estación de traballo CBD.
Despois diso, o empregado autorizado - o usuario do lugar de traballo automatizado KBR - cifra e asina os ficheiros recibidos e envíaos ao sistema de pago do Banco de Rusia.
Cando se reciben pagos do Banco de Rusia, o lugar de traballo automatizado do KBR descifra e verifica a sinatura electrónica, despois de que os rexistre en forma de conxunto de ficheiros en formato UFEBS nun servidor de ficheiros. Antes de importar documentos de pago no ABS, convértense mediante un script de conversión do formato UFEBS ao formato ABS.
Asumiremos que neste esquema, o ABS funciona nun servidor físico, a estación de traballo KBR funciona nun ordenador dedicado e o script do conversor execútase nun servidor de ficheiros.
Correspondencia dos obxectos do diagrama considerado cos elementos do modelo de módulo de integración:
"Servidor de intercambio desde o lado ABS" - Servidor ABS.
"Servidor de intercambio desde o lado de AWS KBR" – estación de traballo informática KBR.
"Mediador" - Servidor de ficheiros de terceiros.
"Software de procesamento de datos" - script convertidor.
Esquema 2. Integración de ABS e AWS KBR ao colocar un cartafol de rede compartida con pagos no AWS KBR
Todo é semellante ao Esquema 1, pero non se utiliza un servidor de ficheiros separado; no seu lugar, un cartafol de rede (...COMPARTIR) con documentos de pago electrónico colócase nun ordenador cunha estación de traballo de CBD. O script do conversor tamén funciona na estación de traballo CBD.
Correspondencia dos obxectos do diagrama considerado cos elementos do modelo de módulo de integración:
Similar ao esquema 1, pero "Mediador" non utilizados.
Esquema 3. Integración de ABS e posto de traballo automatizado KBR-N a través de IBM WebSphera MQ e sinatura de documentos electrónicos "no lado ABS"
ABS funciona nunha plataforma que non é compatible coa sinatura CIPF SCAD. A sinatura dos documentos electrónicos de saída realízase nun servidor especial de sinatura electrónica (ES Server). O mesmo servidor verifica a sinatura electrónica dos documentos que chegan do Banco de Rusia.
ABS carga un ficheiro cos documentos de pago no seu propio formato ao servidor ES.
O servidor ES, mediante un script conversor, converte o ficheiro en mensaxes electrónicas no formato UFEBS, despois de que as mensaxes electrónicas asínanse e transmítense a IBM WebSphere MQ.
A estación de traballo KBR-N accede a IBM WebSphere MQ e recibe desde alí as mensaxes de pago asinadas, despois de que un empregado autorizado, un usuario da estación de traballo KBR, as cifra e envíaas ao sistema de pago do Banco de Rusia.
Cando se reciben pagos do Banco de Rusia, o lugar de traballo automatizado KBR-N descifra e verifica a sinatura electrónica. Os pagos procesados correctamente en forma de mensaxes electrónicas descifradas e asinadas no formato UFEBS transfírense a IBM WebSphere MQ, desde onde os recibe o Servidor de sinatura electrónica.
O servidor de sinatura electrónica verifica a sinatura electrónica dos pagamentos recibidos e gárdaos nun ficheiro en formato ABS. Despois diso, o empregado autorizado -o usuario de ABS- carga o ficheiro resultante no ABS da forma prescrita.
Correspondencia dos obxectos do diagrama considerado cos elementos do modelo de módulo de integración:
"Servidor de intercambio do lado ABS" - Servidor ABS.
"Servidor de intercambio desde o lado de AWS KBR" — Estación de traballo informática KBR.
"Mediador" – Servidor ES e IBM WebSphere MQ.
"Software de procesamento de datos" – conversor de guións, sinatura CIPF SCAD no servidor ES.
Esquema 4. Integración do servidor RBS e do sistema bancario central a través da API proporcionada por un servidor de intercambio dedicado
Asumiremos que o banco usa varios sistemas bancarios remotos (RBS):
- "Internet Client-Bank" para particulares (IKB FL);
- "Internet Cliente-Bank" para persoas xurídicas (IKB LE).
Co fin de garantir a seguridade da información, toda a interacción entre o ABS e os sistemas bancarios remotos realízase a través dun servidor de intercambio dedicado que funciona no marco do sistema de información ABS.
A continuación, consideraremos o proceso de interacción entre o sistema RBS de IKB LE e o ABS.
O servidor de RBS, recibindo unha orde de pago debidamente certificada do cliente, deberá crear un documento correspondente no ABS a partir del. Para iso, mediante a API, transmite información ao servidor de intercambio que, á súa vez, introduce os datos no ABS.
Cando os saldos da conta do cliente cambian, o ABS xera notificacións electrónicas, que se transmiten ao servidor bancario remoto mediante o servidor de intercambio.
Correspondencia dos obxectos do diagrama considerado cos elementos do modelo de módulo de integración:
"Servidor de intercambio desde o lado RBS" – Servidor RBS de IKB YUL.
"Servidor de intercambio do lado ABS" - Servidor de intercambio.
"Mediador" - ausente.
"Software de procesamento de datos" – Compoñentes do servidor RBS responsables de usar a API do servidor de intercambio, compoñentes do servidor de intercambio responsables do uso da API de banca central.
Ameazas de seguridade de primeiro nivel
Descomposición
U1. Inxección de información falsa por parte dos atacantes a través do módulo de integración.
U1. Inxección de información falsa por parte dos atacantes a través do módulo de integración
Descomposición
U1.1. Modificación non autorizada de datos lexítimos cando se transmiten a través de conexións de rede:
Ligazón U1.1.1: .
U1.2. Transmisión de datos falsos a través de canles de comunicación en nome dun participante lexítimo no intercambio:
Ligazón U1.1.2: .
U1.3. Modificación non autorizada de datos lexítimos durante o seu tratamento en Servidores de Exchange ou no Intermediario:
U1.3.1. Ligazón: .
U1.4. Creación de datos falsos nos servidores ou intermediarios de Exchange en nome dun participante lexítimo de intercambio:
U1.4.1. Ligazón:
U1.5. Modificación non autorizada de datos cando se procesan mediante software de tratamento de datos:
U1.5.1. <…> debido a que os atacantes realizan cambios non autorizados na configuración (configuración) do software de procesamento de datos.
U1.5.2. <…> debido a que os atacantes realizan cambios non autorizados nos ficheiros executables do software de procesamento de datos.
U1.5.3. <…> debido ao control interactivo do software de procesamento de datos por parte dos atacantes.
MODELO TÍPICO DE AMEAZA. SISTEMA DE PROTECCIÓN DA INFORMACIÓN CRIPTOGRÁFICA
Obxecto de protección para o que se aplica o modelo de ameaza (ámbito).
O obxecto da protección é un sistema de protección de información criptográfica utilizado para garantir a seguridade do sistema de información.
Arquitectura
A base de calquera sistema de información é o software de aplicación que implementa a súa funcionalidade de destino.
A protección criptográfica adoita implementarse chamando a primitivas criptográficas desde a lóxica empresarial do software de aplicación, que se atopan en bibliotecas especializadas: núcleos criptográficos.
As primitivas criptográficas inclúen funcións criptográficas de baixo nivel, como:
- cifrar/descifrar un bloque de datos;
- crear/verificar unha sinatura electrónica dun bloque de datos;
- calcular a función hash do bloque de datos;
- xerar / cargar / cargar información clave;
- etc
A lóxica empresarial do software de aplicación implementa unha funcionalidade de nivel superior usando primitivas criptográficas:
- cifrar o ficheiro usando as claves dos destinatarios seleccionados;
- establecer unha conexión de rede segura;
- informar sobre os resultados da comprobación da sinatura electrónica;
- e así por diante.
A interacción da lóxica empresarial e do núcleo criptográfico pódese levar a cabo:
- directamente, mediante a lóxica empresarial chamando a primitivas criptográficas desde bibliotecas dinámicas do núcleo criptográfico (.DLL para Windows, .SO para Linux);
- directamente, a través de interfaces criptográficas - envoltorios, por exemplo, MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. Neste caso, a lóxica empresarial accede á interface criptográfica e traduce a chamada ao núcleo criptográfico correspondente, que en este caso chámase provedor criptográfico. O uso de interfaces criptográficas permite que o software de aplicación abstraga de algoritmos criptográficos específicos e sexa máis flexible.
Hai dous esquemas típicos para organizar o núcleo criptográfico:
Esquema 1 – Núcleo criptográfico monolítico
Esquema 2: dividir o núcleo criptográfico
Os elementos dos diagramas anteriores poden ser módulos de software individuais que se executan nun ordenador ou servizos de rede que interactúan dentro dunha rede informática.
Cando se usan sistemas construídos segundo o Esquema 1, o software da aplicación e o núcleo criptográfico funcionan nun único ambiente operativo para a ferramenta criptográfica (SFC), por exemplo, no mesmo ordenador, que executa o mesmo sistema operativo. O usuario do sistema, por regra xeral, pode executar outros programas, incluídos aqueles que conteñan código malicioso, dentro do mesmo ambiente operativo. En tales condicións, existe un serio risco de fuga de claves criptográficas privadas.
Para minimizar o risco, úsase o esquema 2, no que o núcleo criptográfico divídese en dúas partes:
- A primeira parte, xunto co software da aplicación, funciona nun ambiente non fiable onde existe o risco de infección por código malicioso. Chamaremos a esta parte "parte de software".
- A segunda parte funciona nun ambiente de confianza nun dispositivo dedicado, que contén un almacenamento de clave privada. A partir de agora chamaremos a esta parte "hardware".
A división do núcleo criptográfico en partes de software e hardware é moi arbitraria. Hai sistemas no mercado construídos segundo un esquema cun núcleo criptográfico dividido, pero a parte "hardware" do cal se presenta en forma de imaxe de máquina virtual: HSM virtual ().
A interacción de ambas as partes do núcleo criptográfico prodúcese de tal xeito que as claves criptográficas privadas nunca se transfiren á parte do software e, en consecuencia, non se poden roubar mediante código malicioso.
A interface de interacción (API) e o conxunto de primitivas criptográficas proporcionadas ao software da aplicación polo núcleo criptográfico son os mesmos en ambos os casos. A diferenza reside na forma en que se implementan.
Así, cando se usa un esquema cun núcleo criptográfico dividido, a interacción de software e hardware realízase segundo o seguinte principio:
- As primitivas criptográficas que non requiren o uso dunha clave privada (por exemplo, o cálculo dunha función hash, a verificación dunha sinatura electrónica, etc.) son realizadas polo software.
- As primitivas criptográficas que utilizan unha clave privada (creación dunha sinatura electrónica, descifrado de datos, etc.) realízanse por hardware.
Ilustremos o traballo do núcleo criptográfico dividido usando o exemplo de creación dunha sinatura electrónica:
- A parte de software calcula a función hash dos datos asinados e transmite este valor ao hardware a través da canle de intercambio entre núcleos criptográficos.
- A parte de hardware, mediante a clave privada e o hash, xera o valor da sinatura electrónica e transmíteo á parte de software a través dunha canle de intercambio.
- A parte de software devolve o valor recibido ao software da aplicación.
Características de comprobación da corrección dunha sinatura electrónica
Cando a parte receptora reciba datos asinados electrónicamente, deberá realizar varios pasos de verificación. Un resultado positivo da comprobación dunha sinatura electrónica só se consegue se todas as fases da verificación se completan con éxito.
Fase 1. Control da integridade dos datos e da autoría dos datos.
Contidos da etapa. Verifícase a sinatura electrónica dos datos mediante o algoritmo criptográfico adecuado. A superación satisfactoria desta etapa indica que os datos non foron modificados dende o momento da súa sinatura, así como que a sinatura se realizou cunha clave privada correspondente á clave pública de verificación da sinatura electrónica.
Localización do escenario: núcleo criptográfico.
Fase 2. Control da confianza na clave pública do asinante e control do período de vixencia da clave privada da sinatura electrónica.
Contidos da etapa. A etapa consta de dúas subetapas intermedias. O primeiro é determinar se a clave pública para verificar a sinatura electrónica era de confianza no momento da sinatura dos datos. O segundo determina se a clave privada da sinatura electrónica era válida no momento da sinatura dos datos. En xeral, os períodos de validez destas claves poden non coincidir (por exemplo, para certificados cualificados de claves de verificación de sinatura electrónica). Os métodos para establecer a confianza na clave pública do asinante vense determinados polas normas de xestión electrónica de documentos adoptadas polas partes en interacción.
Localización do escenario: software de aplicación/núcleo criptográfico.
Fase 3. Control da autoridade do asinante.
Contidos da etapa. De acordo coas normas establecidas de xestión de documentos electrónicos, compróbase se o asinante tiña dereito a certificar os datos protexidos. Poñamos como exemplo unha situación de vulneración da autoridade. Supoñamos que hai unha organización na que todos os empregados teñen sinatura electrónica. O sistema de xestión electrónica interna de documentos recibe un pedido do xestor, pero asinado coa sinatura electrónica do xestor do almacén. En consecuencia, tal documento non pode considerarse lexítimo.
Localización do escenario: software de aplicación.
Suposicións formuladas á hora de describir o obxecto de protección
- As canles de transmisión de información, con excepción das canles de intercambio de claves, tamén pasan por software de aplicación, API e núcleo criptográfico.
- A información sobre a confianza nas claves públicas e (ou) certificados, así como a información sobre os poderes dos propietarios das chaves públicas, atópase no almacén de claves públicas.
- O software da aplicación funciona co almacén de claves públicas a través do núcleo criptográfico.
Un exemplo de sistema de información protexido mediante CIPF
Para ilustrar os diagramas presentados anteriormente, consideremos un sistema de información hipotético e destaquemos todos os elementos estruturais del.
Descrición do sistema de información
As dúas organizacións decidiron introducir unha xestión de documentos electrónicos (EDF) de importancia legal entre elas. Para iso, asinaron un acordo no que estipulaban que os documentos se transmitirían por correo electrónico, e ao mesmo tempo deberán estar encriptados e asinados cunha sinatura electrónica cualificada. Os programas de Office do paquete Microsoft Office 2016 deben utilizarse como ferramentas para crear e procesar documentos, e CIPF CryptoPRO e o software de cifrado CryptoARM deben utilizarse como medios de protección criptográfica.
Descrición da infraestrutura da organización 1
A organización 1 decidiu que instalaría o software CIPF CryptoPRO e CryptoARM na estación de traballo do usuario: unha computadora física. As claves de cifrado e de sinatura electrónica almacenaranse no soporte de clave ruToken, funcionando en modo de clave recuperable. O usuario preparará os documentos electrónicos localmente no seu ordenador, despois encriptará, asinará e enviará mediante un cliente de correo electrónico instalado localmente.
Descrición da infraestrutura da organización 2
A organización 2 decidiu trasladar as funcións de cifrado e sinatura electrónica a unha máquina virtual dedicada. Neste caso, todas as operacións criptográficas realizaranse automaticamente.
Para iso, organízanse dous cartafoles de rede na máquina virtual dedicada: “...In”, “...Out”. Os ficheiros recibidos da contraparte en forma aberta colocaranse automaticamente no cartafol de rede “…En”. Estes ficheiros serán descifrados e verificarase a sinatura electrónica.
O usuario colocará ficheiros no cartafol "...Fóra" que deben ser cifrados, asinados e enviados á contraparte. O usuario preparará eles mesmos os ficheiros na súa estación de traballo.
Para realizar funcións de cifrado e sinatura electrónica, instálanse na máquina virtual CIPF CryptoPRO, o software CryptoARM e un cliente de correo electrónico. A xestión automática de todos os elementos da máquina virtual realizarase mediante scripts desenvolvidos polos administradores do sistema. O traballo dos scripts está rexistrado nos ficheiros de rexistro.
As claves criptográficas para a sinatura electrónica colocaranse nun token cunha clave JaCarta GOST non recuperable, que o usuario conectará ao seu ordenador local.
O token enviarase á máquina virtual mediante un software especializado USB sobre IP instalado na estación de traballo do usuario e na máquina virtual.
O reloxo do sistema na estación de traballo do usuario na organización 1 axustarase manualmente. O reloxo do sistema da máquina virtual dedicada na Organización 2 sincronizarase co reloxo do sistema hipervisor, que á súa vez se sincronizará a través de Internet con servidores de tempo público.
Identificación de elementos estruturais do CIPF
Partindo da descrición anterior da infraestrutura informática, destacaremos os elementos estruturais do CIPF e escribiémolos nunha táboa.
Táboa - Correspondencia dos elementos do modelo CIPF cos elementos do sistema de información
Nome do elemento
Organización 1
Organización 2
Software de aplicación
Software CryptoARM
Software CryptoARM
Parte do software do núcleo criptográfico
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardware de núcleo criptográfico
ningunha
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Tenda de chaves públicas
Estación de traballo do 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.
Almacenamento de chave privada
O portador de chaves ruToken funciona no modo de chave recuperable
O portador de chaves JaCarta GOST funciona en modo de chave non extraíble
Canle de intercambio de chaves públicas
Estación de traballo do usuario:
- RAM.
Hipervisor:
- RAM.
Máquina virtual:
- RAM.
Canle de intercambio de chaves privadas
Estación de traballo do usuario:
- Bus USB;
- RAM.
ningunha
Canle de intercambio entre núcleos criptográficos
falta (sen hardware de núcleo criptográfico)
Estación de traballo do usuario:
- Bus USB;
- RAM;
— Módulo de software USB sobre IP;
- interface de rede.
Rede corporativa da organización 2.
Hipervisor:
- RAM;
- interface de rede.
Máquina virtual:
- interface de rede;
- RAM;
— Módulo de software USB sobre IP.
Canle de datos abertos
Estación de traballo do usuario:
- medios de entrada-saída;
- RAM;
- Disco duro.
Estación de traballo do usuario:
- medios de entrada-saída;
- RAM;
- Disco duro;
- interface de rede.
Rede corporativa da organización 2.
Hipervisor:
- interface de rede;
- RAM;
- Disco duro.
Máquina virtual:
- interface de rede;
- RAM;
- Disco duro.
Canle de intercambio de datos seguro
Internet.
Rede corporativa da organización 1.
Estación de traballo do usuario:
- Disco duro;
- RAM;
- interface de rede.
Internet.
Rede corporativa da organización 2.
Hipervisor:
- interface de rede;
- RAM;
- Disco duro.
Máquina virtual:
- interface de rede;
- RAM;
- Disco duro.
Canle do tempo
Estación de traballo do usuario:
- medios de entrada-saída;
- RAM;
- Temporizador do sistema.
Internet.
Rede corporativa de organización 2,
Hipervisor:
- interface de rede;
- RAM;
- Temporizador do sistema.
Máquina virtual:
- RAM;
- Temporizador do sistema.
Canle de transmisión de comandos de control
Estación de traballo do usuario:
- medios de entrada-saída;
- RAM.
(Interfaz gráfica de usuario do software CryptoARM)
Máquina virtual:
- RAM;
- Disco duro.
(Guións de automatización)
Canle para recibir resultados do traballo
Estación de traballo do usuario:
- medios de entrada-saída;
- RAM.
(Interfaz gráfica de usuario do software CryptoARM)
Máquina virtual:
- RAM;
- Disco duro.
(Arquivos de rexistro de scripts de automatización)
Ameazas de seguridade de primeiro nivel
Explicacións
Suposicións realizadas ao descompoñer as ameazas:
- Utilízanse algoritmos criptográficos fortes.
- Os algoritmos criptográficos úsanse de forma segura nos modos de operación correctos (p. non se utiliza para cifrar grandes volumes de datos, tense en conta a carga permitida na chave, etc.).
- Os atacantes coñecen todos os algoritmos, protocolos e claves públicas empregados.
- Os atacantes poden ler todos os datos cifrados.
- Os atacantes poden reproducir calquera elemento de software do sistema.
Descomposición
U1. Compromiso de claves criptográficas privadas.
U2. Cifrar datos falsos en nome do remitente lexítimo.
U3. Descifrado de datos cifrados por persoas que non son destinatarias lexítimas dos datos (atacantes).
U4. Creación dunha sinatura electrónica dun asinante lexítimo baixo datos falsos.
U5. Obtención de resultado positivo da comprobación da sinatura electrónica de datos falsificados.
U6. Aceptación errónea de documentos electrónicos para a súa execución por problemas na organización da xestión documental electrónica.
U7. Acceso non autorizado a datos protexidos durante o seu tratamento polo CIPF.
U1. Compromiso de claves criptográficas privadas
U1.1. Recuperando a clave privada do almacén de chaves privadas.
U1.2. Obtención dunha clave privada de obxectos no contorno operativo da ferramenta criptográfica, no que pode residir temporalmente.
Explicacións U1.2.
Os obxectos que poden almacenar temporalmente unha clave privada incluirían:
- RAM,
- ficheiros temporais,
- intercambiar ficheiros,
- ficheiros de hibernación,
- ficheiros de instantáneas do estado "quente" das máquinas virtuais, incluíndo ficheiros do contido da memoria RAM das máquinas virtuais en pausa.
U1.2.1. Extraer claves privadas da memoria RAM en funcionamento conxelando os módulos RAM, eliminándoos e despois lendo os datos (ataque conxelado).
Explicacións U1.2.1.
Exemplo .
U1.3. Obtención dunha clave privada dunha canle de intercambio de chave privada.
Explicacións U1.3.
Darase un exemplo da implementación desta ameaza .
U1.4. Modificación non autorizada do núcleo criptográfico, como resultado da cal as claves privadas son coñecidas polos atacantes.
U1.5. Compromiso dunha clave privada como resultado do uso de canles de fuga de información técnica (TCIL).
Explicacións U1.5.
Exemplo .
U1.6. Compromiso dunha clave privada como resultado do uso de medios técnicos especiais (STS) deseñados para recuperar información en segredo ("errors").
U1.7. Compromiso das claves privadas durante o seu almacenamento fóra do CIPF.
Explicacións U1.7.
Por exemplo, un usuario almacena os seus medios clave nun caixón do escritorio, do que os atacantes poden recuperar facilmente.
U2. Cifrar datos falsos en nome dun remitente lexítimo
Explicacións
Esta ameaza só se considera para esquemas de cifrado de datos con autenticación de remitente. Exemplos deste tipo de esquemas indícanse nas recomendacións de normalización . Para outros esquemas criptográficos, esta ameaza non existe, xa que o cifrado realízase nas claves públicas do destinatario, e xeralmente son coñecidos polos atacantes.
Descomposición
U2.1. Comprometendo a clave privada do remitente:
U2.1.1. Ligazón: .
U2.2. Substitución de datos de entrada nunha canle de intercambio de datos aberta.
Notas U2.2.
A continuación móstranse exemplos da implementación desta ameaza. и .
U3. Descifrado de datos cifrados por persoas que non son destinatarias lexítimas dos datos (atacantes)
Descomposición
U3.1. Compromiso das claves privadas do destinatario dos datos cifrados.
Ligazón U3.1.1: .
U3.2. Substitución de datos cifrados nunha canle de intercambio de datos segura.
U4. Creación dunha sinatura electrónica dun asinante lexítimo baixo datos falsos
Descomposición
U4.1. Compromiso das claves privadas da sinatura electrónica dun asinante lexítimo.
Ligazón U4.1.1: .
U4.2. Substitución de datos asinados nunha canle de intercambio de datos aberta.
Nota U4.2.
A continuación móstranse exemplos da implementación desta ameaza. и .
U5. Obtención de resultado positivo da comprobación da sinatura electrónica de datos falsificados
Descomposición
U5.1. Os atacantes interceptan unha mensaxe na canle para transmitir os resultados do traballo sobre un resultado negativo da comprobación dunha sinatura electrónica e substitúeno por unha mensaxe cun resultado positivo.
U5.2. Os atacantes atacan a confianza ao asinar certificados (Script: todos os elementos son necesarios):
U5.2.1. Os atacantes xeran unha clave pública e privada para unha sinatura electrónica. Se o sistema utiliza certificados de clave de sinatura electrónica, xeran un certificado de sinatura electrónica o máis semellante posible ao certificado do remitente previsto dos datos cuxa mensaxe quere falsificar.
U5.2.2. Os atacantes fan cambios non autorizados no almacén de chaves públicas, dándolle á chave pública que xeran o nivel necesario de confianza e autoridade.
U5.2.3. Os atacantes asinan datos falsos cunha clave de sinatura electrónica xerada previamente e insírense na canle de intercambio de datos segura.
U5.3. Os atacantes realizan un ataque utilizando claves de sinatura electrónica caducadas dun asinante legal (Script: todos os elementos son necesarios):
U5.3.1. Os atacantes comprometen as claves privadas caducadas (non válidas actualmente) da sinatura electrónica dun remitente lexítimo.
U5.3.2. Os atacantes substitúen a hora na canle de transmisión de tempo pola hora na que as claves comprometidas aínda eran válidas.
U5.3.3. Os atacantes asinan datos falsos cunha clave de sinatura electrónica previamente comprometida e inxéctanos na canle de intercambio de datos segura.
U5.4. Os atacantes realizan un ataque utilizando claves de sinatura electrónica comprometidas dun asinante legal (Script: todos os elementos son necesarios):
U5.4.1. O atacante fai unha copia do almacén de chaves públicas.
U5.4.2. Os atacantes comprometen as claves privadas dun dos remitentes lexítimos. Observa o compromiso, revoga as chaves e a información sobre a revogación de chaves colócase no almacén de chaves públicas.
U5.4.3. Os atacantes substitúen o almacén de chaves públicas por un copiado previamente.
U5.4.4. Os atacantes asinan datos falsos cunha clave de sinatura electrónica previamente comprometida e inxéctanos na canle de intercambio de datos segura.
U5.5. <…> debido á presenza de erros na implementación das fases 2a e 3a de verificación da sinatura electrónica:
Explicacións U5.5.
Dáse un exemplo da implementación desta ameaza .
U5.5.1. Comprobación da confianza nun certificado de clave de sinatura electrónica só pola presenza de confianza no certificado co que está asinado, sen comprobacións CRL ou OCSP.
Explicacións U5.5.1.
Exemplo de implantación .
U5.5.2. Ao construír unha cadea de confianza para un certificado, non se analizan as autoridades de emisión de certificados
Explicacións U5.5.2.
Un exemplo de ataque contra certificados SSL/TLS.
Os atacantes compraron un certificado lexítimo para o seu correo electrónico. Despois fixeron un certificado de sitio fraudulento e asinárono co seu certificado. Se non se verifican as credenciais, ao comprobar a cadea de confianza resultará correcta e, en consecuencia, o certificado fraudulento tamén será correcto.
U5.5.3. Cando se crea unha cadea de confianza de certificados, non se verifica a revogación dos certificados intermedios.
U5.5.4. As CRL actualízanse con menos frecuencia que as emitidas pola autoridade de certificación.
U5.5.5. A decisión de confiar nunha sinatura electrónica tómase antes de que se reciba unha resposta de OCSP sobre o estado do certificado, enviada nunha solicitude realizada máis tarde do momento en que se xerou a sinatura ou antes da seguinte CRL despois de xerar a sinatura.
Explicacións U5.5.5.
Na normativa da maioría das CA, o momento da revogación do certificado considérase como o momento da emisión do CRL máis próximo que contén información sobre a revogación do certificado.
U5.5.6. Ao recibir datos asinados, o certificado pertence ao remitente non se verifica.
Explicacións U5.5.6.
Exemplo de ataque. En relación cos certificados SSL: non se pode comprobar a correspondencia do enderezo do servidor chamado co valor do campo CN do certificado.
Exemplo de ataque. Os atacantes comprometeron as claves de sinatura electrónica dun dos participantes do sistema de pago. Despois diso, piratearon a rede doutro participante e, no seu nome, enviaron documentos de pago asinados con claves comprometidas ao servidor de liquidación do sistema de pago. Se o servidor só analiza a confianza e non verifica o cumprimento, os documentos fraudulentos consideraranse lexítimos.
U6. Aceptación errónea de documentos electrónicos para a súa execución por problemas na organización da xestión documental electrónica.
Descomposición
U6.1. A parte receptora non detecta duplicidades dos documentos recibidos.
Explicacións U6.1.
Exemplo de ataque. Os atacantes poden interceptar un documento que se transmite a un destinatario, aínda que estea protexido criptográficamente, e despois envialo repetidamente a través dunha canle de transmisión de datos segura. Se o destinatario non identifica duplicados, todos os documentos recibidos serán percibidos e procesados como documentos diferentes.
U7. Acceso non autorizado a datos protexidos durante o seu tratamento polo CIPF
Descomposición
U7.1. <…> debido á fuga de información a través de canles laterais (ataque de canles laterales).
Explicacións U7.1.
Exemplo .
U7.2. <…> debido á neutralización da protección contra o acceso non autorizado á información tratada no CIPF:
U7.2.1. Funcionamento do CIPF incumprindo os requisitos descritos na documentación do CIPF.
U7.2.2. <…>, realizada pola presenza de vulnerabilidades en:
U7.2.2.1. <…> medios de protección contra accesos non autorizados.
U7.2.2.2. <…> O propio CIPF.
U7.2.2.3. <…> o contorno operativo da ferramenta criptográfica.
Exemplos de ataques
Os escenarios que se comentan a continuación conteñen obviamente erros de seguridade da información e serven só para ilustrar posibles ataques.
Escenario 1. Un exemplo de implantación das ameazas U2.2 e U4.2.
Descrición do obxecto
O software AWS KBR e CIPF SCAD Signature están instalados nun ordenador físico que non está conectado á rede informática. FKN vdToken úsase como portador de chaves no modo de traballar cunha chave non extraíble.
As normas de liquidación asume que o especialista en liquidacións desde o seu ordenador de traballo descarga mensaxes electrónicas en texto claro (esquema da antiga estación de traballo KBR) desde un servidor de ficheiros seguro especial, despois escríbeas nunha unidade flash USB transferible e transfire á estación de traballo KBR. onde están cifrados e asinados. Despois diso, o especialista transfire mensaxes electrónicas seguras ao medio alienado e despois, a través do seu ordenador de traballo, escríbeas nun servidor de ficheiros, desde onde van a UTA e despois ao sistema de pago do Banco de Rusia.
Neste caso, as canles para o intercambio de datos abertos e protexidos incluirán: un servidor de ficheiros, o ordenador de traballo dun especialista e medios alleos.
Ataque
Os atacantes non autorizados instalan un sistema de control remoto no ordenador de traballo dun especialista e, no momento de escribir ordes de pago (mensaxes electrónicas) nun medio transferible, substitúen o contido dun deles en texto claro. O especialista transfire ordes de pago ao lugar de traballo automatizado de KBR, asínaas e encriptaas sen notar a substitución (por exemplo, debido a un gran número de ordes de pago nun voo, fatiga, etc.). Despois diso, a orde de pago falsa, tras pasar pola cadea tecnolóxica, entra no sistema de pago do Banco de Rusia.
Escenario 2. Un exemplo de implantación das ameazas U2.2 e U4.2.
Descrición do obxecto
Un ordenador cunha estación de traballo instalada KBR, SCAD Signature e un operador de chaves conectado FKN vdToken funciona nunha sala dedicada sen acceso do persoal.
O especialista en cálculo conéctase á estación de traballo CBD en modo de acceso remoto mediante o protocolo RDP.
Ataque
Os atacantes interceptan os detalles, cos que o especialista en cálculo se conecta e traballa coa estación de traballo CBD (por exemplo, a través de código malicioso no seu ordenador). Despois conéctanse no seu nome e envían unha orde de pago falsa ao sistema de pago do Banco de Rusia.
Escenario 3. Exemplo de implementación de ameazas U1.3.
Descrición do obxecto
Consideremos unha das opcións hipotéticas para implementar os módulos de integración ABS-KBR para un novo esquema (AWS KBR-N), no que a sinatura electrónica dos documentos de saída ocorre no lado ABS. Neste caso, asumiremos que o ABS funciona en base a un sistema operativo que non é compatible coa sinatura CIPF SKAD e, en consecuencia, a funcionalidade criptográfica transfírese a unha máquina virtual separada: a integración "ABS-KBR". módulo.
Un token USB normal que funciona no modo de chave recuperable utilízase como portador de chaves. Ao conectar os medios clave ao hipervisor, resultou que non había portos USB libres no sistema, polo que se decidiu conectar o token USB a través dun concentrador USB de rede e instalar un cliente USB sobre IP na rede virtual. máquina, que se comunicaría co concentrador.
Ataque
Os atacantes interceptaron a clave privada da sinatura electrónica desde a canle de comunicación entre o concentrador USB e o hipervisor (os datos transmitíronse en texto claro). Ao ter a clave privada, os atacantes xeraron unha orde de pago falsa, asinárona cunha sinatura electrónica e enviárona ao lugar de traballo automatizado KBR-N para a súa execución.
Escenario 4. Un exemplo de implantación de ameazas U5.5.
Descrición do obxecto
Consideremos o mesmo circuíto que no escenario anterior. Asumiremos que as mensaxes electrónicas procedentes da estación de traballo KBR-N acaban no cartafol …SHAREIn, e as enviadas á estación de traballo KBR-N e, ademais, ao sistema de pago do Banco de Rusia van a …SHAREout.
Tamén asumiremos que ao implementar o módulo de integración, as listas de certificados revogados se actualizan só cando se reemiten as claves criptográficas, e tamén que as mensaxes electrónicas recibidas no cartafol …SHAREIn só se verifican para o control de integridade e de confianza na clave pública do Sinatura electrónica.
Ataque
Os atacantes, utilizando as claves roubadas no escenario anterior, asinaron unha orde de pago falsa que contiña información sobre a recepción de diñeiro na conta do cliente fraudulento e introducírono na canle segura de intercambio de datos. Dado que non hai verificación de que a orde de pago fose asinada polo Banco de Rusia, acéptase para a súa execución.
Fonte: www.habr.com