Segurança da informação de pagamentos bancários sem dinheiro. Parte 8 - Modelos típicos de ameaças

Sobre o que é o estudo


Este artigo conclui a série de publicações dedicadas a garantir a segurança das informações dos pagamentos bancários sem dinheiro. Aqui, examinamos os modelos de ameaças típicos que foram referenciados no modelo base :

• Um modelo de ameaça típico. Conexão de rede .
• Um modelo de ameaça típico. Um sistema de informações construído com base na arquitetura cliente-servidor .
• Um modelo de ameaça típico. Sistema de controle de acesso .
• Um modelo de ameaça típico. Módulo de integração .
• Um modelo de ameaça típico. Sistema de segurança de informações criptográficas.

AVISO DE PORTO !!! Caros Khabrovites, este não é um posto de entretenimento.
Escondido sob o corte Mais de 40 páginas de materiais foram projetadas para ajudar pessoas especializadas em serviços bancários ou garantir a segurança das informações no trabalho ou estudo . Esses materiais são o produto final do estudo e são escritos em tom oficial seco. Em essência, são espaços em branco para documentos internos sobre segurança da informação.

Bem, o tradicional é "o uso de informações de um artigo para fins ilegais é punível por lei" . Leitura produtiva!

Informações para leitores familiarizados com o estudo, começando com esta publicação.

Sobre o que é o estudo

Você está lendo um guia do especialista responsável por garantir a segurança das informações nos pagamentos no banco.

Lógica de apresentação

No início, as partes 1 e 2 descrevem o objeto de proteção. Em seguida, na parte 3, descrevemos como construir um sistema de segurança e discutimos a necessidade de um modelo de ameaça. A parte 4 discute quais modelos de ameaças existem e como eles se formam. As partes 5 e 6 fornecem uma análise de ataques reais. As partes 7 e 8 contêm uma descrição do modelo de ameaça, construído levando em consideração as informações de todas as partes anteriores.

MODELO DE AMEAÇA TÍPICA. CONEXÃO DE REDE

O objeto de proteção ao qual o modelo de ameaça é aplicado (escopo)

O objetivo da proteção são os dados transmitidos por meio de uma conexão de rede operando em redes de dados construídas com base na pilha TCP / IP.

Arquitetura



Descrição dos elementos da arquitetura:

• "Nós finais" - nós que trocam informações protegidas.
• “Nós intermediários” - elementos de uma rede de transmissão de dados: roteadores, comutadores, servidores de acesso, servidores proxy e outros equipamentos - através dos quais o tráfego de conexão de rede é transmitido. Em geral, uma conexão de rede pode funcionar sem nós intermediários (diretamente entre os nós finais).

Ameaças de segurança de nível superior

Decomposição

U1 Familiarização não autorizada com os dados transmitidos.
U2 Modificação não autorizada dos dados transmitidos.
U3 Violação de autoria dos dados transmitidos.

U1 Familiarização não autorizada com os dados transmitidos

Decomposição
U1.1 <...> realizado nos nós finais ou intermediários:
U1.1.1 <...> lendo os dados enquanto estão nos dispositivos de armazenamento do nó:
U1.1.1.1. <...> na RAM.
Explicações para U1.1.1.1.
Por exemplo, durante o processamento de dados pela pilha de rede de um nó.

U1.1.1.2 <...> na memória não volátil.
Explicações para U1.1.1.2.
Por exemplo, ao armazenar dados transmitidos em um cache, arquivos temporários ou arquivos de troca.

U1.2 <...> realizado em nós de terceiros da rede de dados:
U1.2.1 <...> pelo método de captura de todos os pacotes que chegam à interface de rede do nó:
Explicações para U1.2.1.
Todos os pacotes são capturados colocando a placa de rede no modo ininteligível (modo promíscuo para adaptadores com fio ou modo de monitor para adaptadores wi-fi).

U1.2.2 <...> realizando ataques como "homem no meio (MiTM)", mas sem modificar os dados transmitidos (sem contar os dados de serviço dos protocolos de rede).
U1.2.2.1 Link: “Um modelo de ameaça típico. Conexão de rede. U2 Modificação não autorizada dos dados transmitidos . "

U1.3 <...>, realizada devido a vazamento de informações através de canais técnicos (TKUI) de nós físicos ou linhas de comunicação.

U1.4 <...>, realizado para instalação nos terminais ou nós intermediários de meios técnicos especiais (STS), destinados à leitura secreta de informações.

U2 Modificação não autorizada de dados transmitidos

Decomposição
U2.1 <...> realizado nos nós finais ou intermediários:
U2.1.1 <...> lendo e fazendo alterações nos dados enquanto estão nos dispositivos de armazenamento dos nós:
U2.1.1.1. <...> na RAM:
U2.1.1.2. <...> na memória não volátil:

U2.2 <...> realizado em nós de terceiros da rede de dados:
U2.2.1 <...> realizando ataques como "man in the middle (MiTM)" e redirecionando o tráfego para o site dos invasores:
U2.2.1.1 Conexão física do equipamento intruso a uma quebra de conexão de rede.
U2.2.1.2 Implementação de ataques a protocolos de rede:
U2.2.1.2.1. <...> gerenciamento de rede local virtual (VLAN):
U2.2.1.2.1.1. Salto de VLAN .
U2.2.1.2.1.2. Modificação não autorizada das configurações de VLAN em switches ou roteadores.
U2.2.1.2.2. <...> roteamento de tráfego:
U2.2.1.2.2.1. Modificação não autorizada de tabelas de roteamento de roteador estático.
U2.2.1.2.2.2. Anúncio por fraudadores de rotas falsas através de protocolos de roteamento dinâmico.
U2.2.1.2.3. <...> configuração automática:
U2.2.1.2.3.1. DHCP não autorizado .
U2.2.1.2.3.2. WPAD desonesto .
U2.2.1.2.4. <...> endereçamento e resolução de nomes:
U2.2.1.2.4.1. Falsificação de ARP .
U2.2.1.2.4.2. Falsificação de DNS .
U2.2.1.2.4.3. Fazendo alterações não autorizadas nos arquivos de nome do host local (hosts, lmhosts etc.)

U3 Violação de direitos autorais dos dados transmitidos

Decomposição
U3.1 Neutralização de mecanismos para determinar a autoria das informações, indicando informações falsas sobre o autor ou fonte de dados:
U3.1.1 Alteração de informações sobre o autor contidas nas informações transmitidas.
U3.1.1.1. Neutralização da proteção criptográfica da integridade e autoria dos dados transmitidos:
U3.1.1.1.1. Link: “Um modelo de ameaça típico. Sistema de segurança de informações criptográficas.
U4 Criação de uma assinatura eletrônica de um signatário legítimo sob dados falsos . ”
U3.1.1.2 Neutralização da proteção da autoria dos dados transmitidos implementada usando códigos de confirmação únicos:
U3.1.1.2.1. Troca de SIM .

U3.1.2 Mudança de informação sobre a fonte de informação transmitida:
U3.1.2.1 Falsificação de IP .
U3.1.2.2 Falsificação de MAC .

---

MODELO DE AMEAÇA TÍPICA. SISTEMA DE INFORMAÇÃO CONSTRUÍDO COM BASE NA ARQUITETURA DO SERVIDOR DE CLIENTE

O objeto de proteção ao qual o modelo de ameaça é aplicado (escopo)

O objeto de proteção é um sistema de informações construído com base na arquitetura cliente-servidor.

Arquitetura


Descrição dos elementos da arquitetura:

• "Cliente" - um dispositivo no qual a parte do cliente do sistema de informações opera.
• "Servidor" - um dispositivo no qual a parte do servidor do sistema de informações opera.
• "Data Warehouse" é uma parte da infraestrutura do servidor de um sistema de informação projetado para armazenar dados processados ​​por um sistema de informação.
• “Conexão de Rede” - um canal para troca de informações entre o Cliente e o Servidor, passando por uma rede de transmissão de dados. Uma descrição mais detalhada do modelo de elemento é fornecida no “Modelo de ameaça típico. Conexão de rede " .

Limitações
Ao modelar um objeto, as seguintes restrições são estabelecidas:

1. O usuário interage com o sistema de informações em intervalos de tempo finitos, chamados sessões de trabalho.
2. No início de cada sessão de trabalho, o usuário é identificado, autenticado e autorizado.
3. Todas as informações protegidas são armazenadas no lado do servidor do sistema de informações.

Ameaças de segurança de nível superior

Decomposição
U1 Os invasores cometem ações não autorizadas em nome de um usuário legítimo.
U2 Modificação não autorizada das informações protegidas durante seu processamento pela parte do servidor do sistema de informações.

U1 Violação de ações não autorizadas por criminosos em nome de um usuário legítimo

Explicações
Normalmente, nos sistemas de informação, as ações são associadas ao usuário que as executou usando:

1. logs de operação do sistema (logs).
2. atributos especiais de objetos de dados que contêm informações sobre o usuário que os criou ou alterou.

Em relação à sessão de trabalho, essa ameaça pode ser decomposta em:

1. <...> realizado como parte da sessão de trabalho do usuário.
2. <...> realizado fora da sessão de trabalho do usuário.

Uma sessão do usuário pode ser iniciada:

1. Pelo usuário.
2. Intrusos.

Nesta fase, uma decomposição intermediária dessa ameaça será semelhante a esta:
U1.1 Ações não autorizadas foram executadas como parte de uma sessão do usuário:
U1.1.1 <...> instalado pelo usuário atacado.
U1.1.2 <...> instalado por atacantes.
U1.2 Ações não autorizadas são executadas fora da sessão do usuário.

Do ponto de vista dos objetos da infraestrutura de informações que podem ser afetados pelos invasores, a decomposição de ameaças intermediárias será semelhante a esta:

Itens	Decomposição de ameaças
	U1.1.1	U1.1.2	U1.2
Cliente	U1.1.1.1.	U1.1.2.1.
Conexão de rede	U1.1.1.2
Servidor			U1.2.1

Decomposição
U1.1 Ações não autorizadas foram executadas como parte de uma sessão do usuário:
U1.1.1 <...> instalado pelo usuário atacado:
U1.1.1.1. Os atacantes agiram independentemente do Cliente:
U1.1.1.1.1 Os atacantes usavam meios regulares de acesso ao sistema de informação:
U1.1.1.1.1.1. Os invasores usavam as E / S físicas do Cliente (teclado, mouse, monitor ou tela sensível ao toque de um dispositivo móvel):
U1.1.1.1.1.1.1.1. Os invasores agiram em períodos de tempo em que a sessão está ativa, instalações de E / S estão disponíveis e o usuário não está no local.
U1.1.1.1.1.2. Os invasores usavam ferramentas de administração remota (padrão ou fornecidas por código malicioso) para gerenciar o Cliente:
U1.1.1.1.1.2.1. Os invasores agiram em períodos de tempo em que a sessão está ativa, instalações de E / S estão disponíveis e o usuário não está no local.
U1.1.1.1.1.2.2. Os invasores usavam ferramentas de administração remota, cuja operação é invisível para o usuário atacado.
U1.1.1.2 Os invasores substituíram os dados em uma conexão de rede entre o Cliente e o Servidor, modificando-os para que fossem percebidos como ações de um usuário legítimo:
U1.1.1.2.1. Link: “Um modelo de ameaça típico. Conexão de rede. U2 Modificação não autorizada dos dados transmitidos . "
U1.1.1.3 Os atacantes forçaram o usuário a executar as ações indicadas por eles usando métodos de engenharia social.

U1.1.2 <...> estabelecido pelos atacantes:
U1.1.2.1. Os atacantes agiram a partir do cliente ( I ):
U1.1.2.1.1. Os invasores neutralizaram o sistema de controle de acesso do sistema de informação:
U1.1.2.1.1.1. Link: “Um modelo de ameaça típico. Sistema de controle de acesso. U1 Estabelecimento não autorizado de uma sessão de trabalho em nome de um usuário legal . ”
U1.1.2.1.2. Os invasores usavam ferramentas padrão de acesso ao sistema de informação
U1.1.2.2 Os invasores agiram de outros nós da rede de dados a partir dos quais você pode estabelecer uma conexão de rede com o servidor ( I ):
U1.1.2.2.1. Os invasores neutralizaram o sistema de controle de acesso do sistema de informação:
U1.1.2.2.1.1. Link: “Um modelo de ameaça típico. Sistema de controle de acesso. U1 Estabelecimento não autorizado de uma sessão de trabalho em nome de um usuário legal . ”
U1.1.2.2.2. Os invasores usaram ferramentas de acesso anormais ao sistema de informações.
Explicações 1.1.1.2.2.2.
Os invasores podem instalar um cliente regular do sistema de informações em um nó de terceiros ou podem usar software anormal que implementa protocolos de troca padrão entre o Cliente e o Servidor.

U1.2 Ações não autorizadas são executadas fora da sessão do usuário.
D1.2.1 Os invasores executaram ações não autorizadas e, em seguida, fizeram alterações não autorizadas nos logs de operação do sistema de informações ou nos atributos especiais dos objetos de dados, indicando que as ações cometidas por eles foram executadas por um usuário legítimo.

U2 Modificação não autorizada das informações protegidas durante seu processamento pela parte do servidor do sistema de informações

Decomposição
U2.1 Os invasores modificam as informações protegidas usando as ferramentas padrão do sistema de informações e as realizam em nome de um usuário legítimo.
U2.1.1 Link: “Um modelo de ameaça típico. Um sistema de informações construído com base na arquitetura cliente-servidor. U1 Perpetração de ações não autorizadas por criminosos em nome de um usuário legítimo . ”

U2.2 Os invasores modificam as informações protegidas usando mecanismos de acesso a dados que não são fornecidos pelo modo regular de funcionamento do sistema de informações.
U2.2.1 Os invasores modificam arquivos que contêm informações protegidas:
U2.2.1.1 <...> usando os mecanismos de manipulação de arquivos fornecidos pelo sistema operacional.
U2.2.1.2 <...> provocando a restauração de arquivos a partir de um backup modificado não autorizado.

U2.2.2 Os invasores modificam as informações protegidas armazenadas no banco de dados ( I ):
U2.2.2.1 Os invasores neutralizam o sistema de controle de acesso do DBMS:
U2.2.2.1.1. Link: “Um modelo de ameaça típico. Sistema de controle de acesso. U1 Estabelecimento não autorizado de uma sessão de trabalho em nome de um usuário legal . ”
U2.2.2.2 Os invasores modificam as informações usando as interfaces DBMS padrão para acessar dados.

U2.3 Os invasores modificam as informações protegidas por modificação não autorizada dos algoritmos do software de processamento.
U2.3.1 Modificações são feitas no código fonte do software.
U2.3.1 Modificações são feitas no código da máquina do software.

U2.4 Os invasores modificam as informações protegidas explorando vulnerabilidades no software do sistema de informações.

U2.5 Os invasores modificam as informações protegidas durante sua transferência entre os componentes da parte do servidor do sistema de informações (por exemplo, o servidor de banco de dados e o servidor de aplicativos):
U2.5.1 Link: “Um modelo de ameaça típico. Conexão de rede. U2 Modificação não autorizada dos dados transmitidos . "

---

MODELO DE AMEAÇA TÍPICA. SISTEMA DE RESTRIÇÃO DE ACESSO

O objeto de proteção ao qual o modelo de ameaça é aplicado (escopo)

O objeto de proteção ao qual esse modelo de ameaça é aplicado corresponde ao objeto de proteção do modelo de ameaça: “Modelo de ameaça típico. Um sistema de informação baseado na arquitetura cliente-servidor. ”

Sob o sistema de restrição de acesso do usuário nesse modelo de ameaça, entende-se um componente do sistema de informações que implementa as funções:

1. Identificação do usuário.
2. Autenticação de Usuário.
3. Autorização do usuário.
4. Registrando ações do usuário.

Ameaças de segurança de nível superior

Decomposição
U1 Estabelecimento não autorizado de uma sessão de trabalho em nome de um usuário legal.
U2 Escalada não autorizada de privilégios de usuário no sistema de informações.

U1 Estabelecimento não autorizado de uma sessão de trabalho em nome de um usuário legal

Explicações
A decomposição dessa ameaça no caso geral dependerá do tipo de sistema de identificação e autenticação de usuário usado.

Nesse modelo, apenas um sistema de identificação e autenticação de usuário usando login e senha de texto será considerado. Ao mesmo tempo, assumimos que o logon do usuário é uma informação publicamente conhecida pelos invasores.

Decomposição
U1.1 <...> devido a credenciais comprometidas:
U1.1.1 Os invasores comprometeram as credenciais do usuário durante o armazenamento.
Explicações 1.1.1.1.
Por exemplo, as credenciais podem ser gravadas em um adesivo colado no monitor.

U1.1.2 O usuário acidentalmente ou por intenção maliciosa transferiu os detalhes de acesso aos invasores.
U1.1.2.1. O usuário falou as credenciais em voz alta ao entrar.
U1.1.2.2 O usuário passou intencionalmente suas credenciais:
U1.1.2.2.1. <...> para colegas.
Explicações U1.1.2.2.1.
Por exemplo, para que eles possam substituí-lo por um período de doença.

U1.1.2.2.2. <...> contrapartes de empregadores executando trabalhos em instalações de infraestrutura de informações.
U1.1.2.2.3. <...> para terceiros.
Explicações 1.1.1.2.2.3.
Uma, mas não a única opção para implementar essa ameaça, é o uso de métodos de engenharia social pelos invasores.

U1.1.3 Os atacantes pegaram credenciais por força bruta:
U1.1.3.1 <...> usando mecanismos de acesso padrão.
U1.1.3.2 <...> por códigos interceptados anteriormente (por exemplo, hashes de senha) para armazenar credenciais.

U1.1.4Os invasores usavam códigos maliciosos para interceptar credenciais do usuário.

U1.1.5 Os invasores extraíram as credenciais da conexão de rede entre o Cliente e o Servidor:
U1.1.5.1. Link: “Um modelo de ameaça típico. Conexão de rede. U1 Familiarização não autorizada com os dados transmitidos . ”

U1.1.6 Os invasores extraíram as credenciais dos registros dos sistemas de monitoramento de trabalho:
U1.1.6.1. <...> sistemas de vigilância por vídeo (se durante a operação as teclas digitadas no teclado foram gravadas).
U1.1.6.2 <...> sistemas para monitorar as ações dos funcionários no computador
Explicações U1.1.6.2.
Um exemplo desse sistema é o StuffCop .

U1.1.7 Os invasores comprometeram as credenciais do usuário devido a falhas no processo de transferência.
Explicações U1.1.7.
Por exemplo, enviando senhas em texto não criptografado por email.

U1.1.8 Os invasores aprenderam as credenciais monitorando a sessão do usuário usando sistemas de administração remota.

U1.1.9 Os invasores extraíram as credenciais como resultado de seu vazamento pelos canais técnicos (TKUI):
.11.1.9.1. Os invasores espionaram como o usuário digita credenciais a partir do teclado:
U1.1.9.1.1 Os invasores estavam localizados muito próximos ao usuário e viam a entrada de credenciais com seus próprios olhos.
Explicações U1.1.9.1.1
Esses casos incluem as ações dos colegas de trabalho ou o caso em que o teclado do usuário é visível para os visitantes da organização.

D1.1.9.1.2 Os atacantes usaram meios técnicos adicionais, como binóculos ou veículo aéreo não tripulado, e viram as credenciais inseridas pela janela.
U1.1.9.2 Os invasores extraíram as credenciais dos registros das trocas de rádio entre o teclado e a unidade de sistema do computador se eles estivessem conectados via interface de rádio (por exemplo, Bluetooth).
U1.1.9.3 Os invasores interceptaram credenciais devido a seu vazamento através do canal de radiação e interferência eletromagnética secundária (PEMIN).
Explicações 1.1.1.3.
Exemplos de ataques aqui e aqui .

U1.1.9.4 O invasor interceptou a entrada de credenciais do teclado através do uso de meios técnicos especiais (STS) projetados para recuperação de informações tácitas.
Explicações 1.1.1.4.
Exemplos de dispositivos .

U1.1.9.5 Os invasores interceptaram a entrada de credenciais do teclado
analisando o sinal Wi-Fi modulado pelas teclas do usuário.
Explicações U1.1.9.5.
Exemplo de ataque .

U1.1.9.6 Os invasores interceptaram a entrada de credenciais do teclado analisando os sons das teclas digitadas.
Explicações U1.1.9.6.
Exemplo de ataque .

U1.1.9.7 Os invasores interceptaram a entrada de credenciais do teclado de um dispositivo móvel, analisando as leituras do acelerômetro.
Explicações U1.1.9.7.
Exemplo de ataque .

U1.1.10 <...> salvo anteriormente no cliente.
Explicações U1.1.10.
Por exemplo, um usuário pode salvar um nome de usuário e senha em um navegador para acessar um site específico.

U1.1.11 Os invasores comprometeram as credenciais devido a falhas no processo de revogação do acesso do usuário.
Explicações 1.1.1.11.
Por exemplo, após a demissão do usuário, suas contas não foram bloqueadas.

U1.2 <...> devido ao uso de vulnerabilidades no sistema de controle de acesso.

U2 Escalada não autorizada de privilégios de usuário no sistema de informações

Decomponha
U2.1 <...> fazendo alterações não autorizadas nos dados que contêm informações sobre os privilégios do usuário.

U2.2 <...> devido ao uso de vulnerabilidades no sistema de controle de acesso.

U2.3 <...> devido a falhas no processo de controle de acesso do usuário.
Explicações U2.3.
Exemplo 1. O usuário recebeu acesso ao trabalho mais do que o necessário para as necessidades oficiais.
Exemplo 2. Depois de transferir um usuário para outra posição, os direitos de acesso concedidos anteriormente não foram revogados.

---

MODELO DE AMEAÇA TÍPICA. MÓDULO DE INTEGRAÇÃO

O objeto de proteção ao qual o modelo de ameaça é aplicado (escopo)

Módulo de integração - um conjunto de objetos de infraestrutura de informações projetados para organizar a troca de informações entre sistemas de informação.

Dado que nas redes corporativas nem sempre é possível separar de forma inequívoca um sistema de informação de outro, o módulo de integração também pode ser considerado como um link entre os componentes dentro do mesmo sistema de informação.

Arquitetura O
diagrama generalizado do módulo de integração é o seguinte:



Descrição dos elementos da arquitetura:

• “Exchange server (CO)” - um nó / serviço / componente de um sistema de informação que executa a função de trocar dados com outro sistema de informação.
• «» – / , , .
  «» , (enterprise service bus / SoA-), .. «».
• « » – , .
  , , ..
• "Conexão de rede" corresponde ao objeto descrito no modelo típico de ameaça de conexão de rede. Algumas conexões de rede daquelas apresentadas no diagrama acima podem não existir.

Exemplos de módulos de integração

Figura 1. Integração do ABS e da AWS do CBD por meio de um servidor de arquivos de terceiros

Para efetuar pagamentos, um funcionário do banco autorizado baixa documentos de pagamento eletrônico do ABS e os salva em um arquivo (de seu próprio formato, por exemplo, dump SQL) em uma pasta de rede (\\ ... \ SHARE \) servidor de arquivos. Em seguida, esse arquivo é convertido usando um conversor de script em um conjunto de arquivos no formato UFEBS, que são lidos pela estação de trabalho KBR.
Depois disso, um funcionário autorizado - um usuário do AWS KBR - criptografa e assina o arquivo recebido e os envia ao sistema de pagamento do Banco da Rússia.

Após o recebimento dos pagamentos do Banco da Rússia, o AWS KBR os descriptografa e verifica a assinatura eletrônica e os grava na forma de um conjunto de arquivos do formato UFEBS em um servidor de arquivos. Antes de importar documentos de pagamento para o ABS, eles são convertidos usando um conversor de scripts do formato UFBS para o formato ABS.

Assumimos que, nesse esquema, o ABS opere em um servidor físico, o KBR AWS opere em um computador dedicado e o conversor de scripts execute em um servidor de arquivos.



Correspondência dos objetos do circuito considerado com os elementos do modelo do módulo de integração:
“ Servidor Exchange do lado ABS” - Servidor ABS.
"Exchange Server do AWP KBR" - computador AWP KBR.
"Mediador" é um servidor de arquivos de terceiros.
"Software de processamento de dados"- conversor de scripts.

Esquema 2. Integração do ABS e do AWS KBR ao colocar uma pasta de rede compartilhada com pagamentos no AWS KBR

Tudo é semelhante ao Esquema 1, mas um servidor de arquivos separado não é usado. Em vez disso, uma pasta de rede (\\ ... \ SHARE \) com documentos de pagamento eletrônico está localizada em computador com o AWS CBD. O conversor de script também funciona no AWS KBR.



Correspondência dos objetos do esquema considerado com os elementos do modelo do módulo de integração:
Semelhante ao Esquema 1, mas o "Intermediário" não é usado.

Esquema 3. Integração do ABS e AWS KBR-N através do IBM WebSphera MQ e assinatura de documentos eletrônicos "no lado do ABS"

O ABS opera em uma plataforma não suportada pela assinatura SKZI SCAD. A assinatura de documentos eletrônicos de saída é realizada em um servidor de assinatura eletrônica especial (ES Server). O mesmo servidor verifica a assinatura eletrônica dos documentos recebidos do Banco da Rússia.

O ABS carrega um arquivo com documentos de pagamento no formato proprietário para o ES Server.
Usando o conversor de script, o servidor ES converte o arquivo em mensagens eletrônicas no formato UFBS, após o qual as mensagens eletrônicas são assinadas e transmitidas ao IBM WebSphere MQ.

O AWP KBR-N entra em contato com o IBM WebSphere MQ e recebe mensagens de pagamento assinadas a partir daí, após as quais o funcionário autorizado - usuário do AWP KBR - os criptografa e envia para o sistema de pagamento do Banco da Rússia.

Após o recebimento dos pagamentos do Banco da Rússia, o AWP KBR-N os descriptografa e verifica a assinatura eletrônica. Os pagamentos processados ​​com êxito na forma de mensagens eletrônicas descriptografadas e assinadas no formato UFBS são transmitidos ao IBM WebSphere MQ, de onde são recebidos pelo ES Server.

O servidor ES verifica a assinatura eletrônica dos pagamentos recebidos e os salva em um arquivo no formato ABS. Depois disso, o funcionário autorizado - o usuário do ABS - carrega o arquivo resultante no ABS da maneira prescrita.



Correspondência dos objetos do esquema considerado com os elementos do modelo do módulo de integração:
“Servidor Exchange do lado do ABS” - Servidor ABS.
“Servidor Exchange do AWP KBR” - computador AWP KBR.
"Mediador" - servidor ES e IBM WebSphere MQ.
"Software de processamento de dados"- conversor de scripts, assinatura SKZI SKAD no ES Server.

Esquema 4. Integração do servidor RBS e ABS por meio da API fornecida por um servidor de troca dedicado,

assumindo que o banco utiliza vários sistemas de serviços bancários remotos (RBS):

• “Internet Client-Bank” para pessoas físicas (IKB FL);
• "Internet Client-Bank" para pessoas jurídicas (IKB YL).

Para garantir a segurança das informações, todas as interações do ABS com sistemas bancários remotos são realizadas por meio de um servidor de troca dedicado, operando dentro da estrutura do sistema de informações do ABS.

A seguir, consideramos o processo de interação entre o sistema RB do IKB YuL e o ABS.
O servidor RBS, depois de receber uma ordem de pagamento devidamente certificada do cliente, deve criar um documento apropriado no ABS com base. Para fazer isso, usando a API, ele transfere informações para o servidor de troca e, por sua vez, insere os dados no ABS.

Quando os saldos na conta do cliente mudam, o ABS gera notificações eletrônicas que são transmitidas ao servidor de banco remoto usando o servidor de câmbio.



Correspondência dos objetos do circuito considerado com os elementos do modelo do módulo de integração:
“Servidor Exchange por parte do sistema bancário remoto”- servidor DBO IKB YuL.
"Servidor de troca do lado do ABS" - servidor de troca.
"Intermediário" - está ausente.
“Software de processamento de dados” - componentes do servidor RBS responsáveis ​​pelo uso da API do Exchange Server, componentes do servidor de câmbio responsáveis ​​pelo uso da API do ABS.

Ameaças de segurança de nível superior

Decomposição
U1. Os invasores injetam informações fraudulentas por meio de um módulo de integração.

U1 Atacando informações fraudulentas por meio de um módulo de integração

Decomposição
U1.1. Modificação não autorizada de dados legítimos ao transmitir através de conexões de rede:
U1.1.1 Link: “Modelo de ameaça típico. Conexão de rede. U2 Modificação não autorizada dos dados transmitidos . "

U1.2 Transmissão de dados falsos por meio de canais de comunicação em nome de um participante legítimo do intercâmbio:
U1.1.2 Link: “Modelo de ameaça típico. Conexão de rede. U3 Violação de autoria dos dados transmitidos " .

U1.3 Modificação não autorizada de dados legítimos durante seu processamento nos Exchange Servers ou no Intermediário:
U1.3.1. Link:“Um modelo de ameaça típico. Um sistema de informações construído com base na arquitetura cliente-servidor. U2 "Modificação não autorizada das informações protegidas durante seu processamento pela parte do servidor do sistema de informações . "

U1.4 Criação de dados forjados nos Exchange Servers ou no Intermediário em nome de um participante legítimo do Exchange:
U1.4.1. Link: “Um modelo de ameaça típico. Um sistema de informações construído com base na arquitetura cliente-servidor. U1 Perpetração de ações não autorizadas por criminosos em nome de um usuário legítimo. ”

U1.5 Modificação não autorizada de dados durante seu processamento usando o software de processamento de dados:
U1.5.1. <...> devido a alterações não autorizadas nas definições (configuração) do software de processamento de dados por cibercriminosos.
U1.5.2 <...> devido a alterações não autorizadas nos arquivos executáveis ​​do software de processamento de dados por cibercriminosos.
U1.5.3 <...> devido ao controle interativo dos invasores do software de processamento de dados.

---

MODELO DE AMEAÇA TÍPICA. SISTEMA DE PROTEÇÃO CRIPTOGRÁFICA DA INFORMAÇÃO

O objeto de proteção ao qual o modelo de ameaça é aplicado (escopo)

O objeto da proteção é um sistema de proteção de informações criptográficas usado para garantir a segurança do sistema de informações.

Arquitetura
A base de qualquer sistema de informação é o software aplicativo (software) que implementa sua funcionalidade de destino.

Nesse caso, a proteção criptográfica geralmente é implementada chamando primitivas criptográficas da lógica de negócios do software aplicativo, que estão localizadas em bibliotecas especializadas - kernels criptográficos.

As primitivas criptográficas incluem funções criptográficas de baixo nível, como:

• criptografar / descriptografar um bloco de dados;
• criar / verificar a assinatura eletrônica do bloco de dados;
• calcular a função hash do bloco de dados;
• gerar / carregar / baixar as principais informações;
• etc.

A lógica de negócios do software aplicativo usando primitivas criptográficas implementa uma funcionalidade de nível superior:

• criptografar o arquivo nas chaves dos destinatários selecionados;
• estabelecer uma conexão de rede segura;
• informar sobre os resultados da verificação de assinaturas eletrônicas;
• etc.

A interação da lógica de negócios e o núcleo criptográfico pode ser realizada:

• diretamente, invocando primitivas criptográficas das bibliotecas dinâmicas de núcleo criptográfico pela lógica de negócios (.DLL para Windows, .SO para Linux);
• , – (wrappers), , MS Crypto API, Java Cryptography Architecture, PKCS#11 . - , , . .

Podem ser distinguidos dois esquemas típicos para organizar um cryptonucleus:

Esquema 1 - Cryptonucleus monolítico


Esquema 2 - Cryptonucleus dividido Os


elementos dos diagramas fornecidos podem ser módulos de software separados trabalhando em um computador ou serviços de rede interagindo em uma rede de computadores.

Ao usar sistemas construídos de acordo com o esquema 1, o software de aplicativo e o núcleo de criptografia funcionam na estrutura de um único ambiente para a operação de uma instalação de criptografia (SFC), por exemplo, no mesmo computador, sob o controle do mesmo sistema operacional. Como regra, um usuário do sistema pode executar outros programas, incluindo aqueles que contêm código malicioso, dentro da estrutura do mesmo ambiente de funcionamento. Em tais circunstâncias, existe um sério risco de vazamento de chaves criptográficas privadas.

Para minimizar o risco, é usado o esquema 2, no qual o núcleo criptográfico é dividido em duas partes:

1. A primeira parte, junto com o software do aplicativo, funciona em um ambiente não confiável, onde há risco de infecção por código malicioso. Vamos chamar essa parte de "parte do software".
2. A segunda parte funciona em um ambiente confiável em um dispositivo dedicado que contém um armazenamento de chaves privadas. Além disso, chamaremos essa parte - "hardware".

A divisão do criptocore em software e hardware é muito arbitrária. Existem sistemas no mercado que são construídos de acordo com o esquema com um núcleo criptográfico dividido, mas a parte “hardware” é apresentada como uma imagem de uma máquina virtual - HSM virtual ( exemplo ).

A interação de ambas as partes do núcleo criptográfico ocorre de forma que as chaves criptográficas privadas nunca são transmitidas para a parte do software e, portanto, não podem ser roubadas usando código malicioso.

A interface de interação (API) e o conjunto de primitivas criptográficas fornecidas pelo software aplicativo pelo núcleo criptográfico são iguais nos dois casos. A diferença está na maneira como são implementadas.

Portanto, ao usar um esquema com um núcleo criptográfico dividido, a interação do software e do hardware é realizada de acordo com o seguinte princípio:

1. Primitivas criptográficas que não requerem o uso de uma chave privada (por exemplo, cálculo de uma função hash, verificação de assinaturas eletrônicas etc.) são executadas pela parte do software.
2. Primitivas criptográficas usando uma chave privada (criando uma assinatura eletrônica, descriptografando dados etc.) são executadas pelo hardware.

Ilustraremos o trabalho de um criptocore dividido usando o exemplo da criação de uma assinatura eletrônica:

1. A parte do software calcula a função de hash dos dados assinados e transfere esse valor para a parte do hardware através do canal de troca entre os kernels criptográficos.
2. A parte do hardware, usando a chave privada e o hash, forma o valor da assinatura eletrônica e a transfere para a parte do software através do canal de troca.
3. A parte do software retorna o valor recebido para o software aplicativo.

Peculiaridades da verificação da precisão de uma assinatura eletrônica

Quando uma parte receptora recebe dados assinados por uma assinatura eletrônica, deve realizar vários estágios de verificação. Um resultado positivo da verificação de uma assinatura eletrônica é alcançado apenas se todas as etapas da verificação forem concluídas com êxito.

Etapa 1. Controle da integridade e autoria dos dados.

O conteúdo do palco. A assinatura eletrônica dos dados é verificada usando o algoritmo criptográfico correspondente. A conclusão bem-sucedida desse estágio significa que os dados não foram modificados desde que foram assinados e que a assinatura foi feita com uma chave privada correspondente à chave pública da verificação de assinatura eletrônica.
Local de execução do palco: criptocore.

Etapa 2. Monitorando a confiança na chave pública do signatário e monitorando a validade da chave privada da assinatura eletrônica.
O conteúdo do palco. O estágio consiste em dois subestágios intermediários. O primeiro estabelece se a chave pública da verificação de assinatura eletrônica era confiável no momento da assinatura dos dados. O segundo define se a chave privada da assinatura eletrônica era válida no momento da assinatura dos dados. No caso geral, os períodos de validade dessas chaves podem não coincidir (por exemplo, para certificados de certificado qualificados de chaves de verificação de assinatura eletrônica). As formas de estabelecer confiança na chave pública do signatário são determinadas pelas regras de gerenciamento de documentos eletrônicos adotadas pelas partes que interagem.
Local de execução da etapa: software aplicativo / núcleo criptográfico.

Etapa 3. Controle dos poderes do signatário.
O conteúdo do palco. De acordo com as regras estabelecidas de gerenciamento eletrônico de documentos, é verificado se o signatário tinha o direito de certificar os dados protegidos. Por exemplo, apresentamos uma situação de violação de autoridade. Suponha que exista uma organização em que todos os funcionários tenham uma assinatura eletrônica. A ordem do chefe, mas assinada pela assinatura eletrônica do gerente de armazém, entra no sistema interno de gerenciamento de documentos eletrônicos. Por conseguinte, esse documento não pode ser considerado legítimo.
Local de execução da etapa: software aplicativo.

Suposições feitas ao descrever o objeto de proteção

1. Os canais de transferência de informações, com exceção dos principais canais de troca, também passam pelo software aplicativo, pela API e pelo núcleo de criptografia.
2. () , , .
3. .

,

Para ilustrar os esquemas apresentados anteriormente, consideramos um sistema de informação hipotético e selecionamos todos os elementos estruturais nele.

Descrição do sistema de informações



Duas organizações decidiram introduzir um gerenciamento eletrônico de documentos (FED) legalmente significativo entre si. Para isso, firmaram um acordo no qual determinavam que os documentos seriam transmitidos por e-mail e, ao mesmo tempo, deveriam ser criptografados e assinados por uma assinatura eletrônica qualificada. Como meio de criação e processamento de documentos, devem ser usados ​​programas de escritório do pacote Microsoft Office 2016 e como meio de proteção criptográfica - CryptoPRO Cryptographic Protection Tool e CryptoARM.

Descrição da infraestrutura da organização 1

A organização 1 decidiu instalar o software CryptoPRO Cryptographic Information Protection System e CryptoARM na estação de trabalho do usuário - um computador físico. As chaves de criptografia e assinatura eletrônica serão armazenadas no portador de chave do ruToken, operando no modo da chave extraída. O usuário preparará documentos eletrônicos localmente em seu computador, após o qual serão criptografados, assinados e enviados usando um cliente de email instalado localmente.

Descrição da infraestrutura da organização 2 A

Organização 2 decidiu transferir as funções de criptografia e assinatura eletrônica para uma máquina virtual dedicada. Nesse caso, todas as operações criptográficas serão executadas automaticamente.

Para fazer isso, duas pastas de rede são organizadas na máquina virtual dedicada: "\\ ... \ In \", "\\ ... \ Out \". Na pasta de rede "\\ ... \ In \", os arquivos recebidos da contraparte no espaço livre serão automaticamente colocados. Esses arquivos serão descriptografados e uma assinatura eletrônica será verificada neles.

Na pasta "\\ ... \ Out \", o usuário colocará os arquivos que precisam ser criptografados, assinados e enviados à contraparte. O usuário preparará os arquivos em sua estação de trabalho.
Para executar as funções de criptografia e assinatura eletrônica em uma máquina virtual, o software CryptoPro, o software de criptografia e um cliente de email são instalados. O controle automático de todos os elementos da máquina virtual será realizado usando scripts desenvolvidos pelos administradores do sistema.Os scripts são registrados nos arquivos de log.

As chaves criptográficas da assinatura eletrônica serão colocadas no token com a chave não extraível JaCarta GOST, que o usuário conectará ao seu computador local.

O token será encaminhado para a máquina virtual usando um software USB sobre IP instalado na estação de trabalho do usuário e na máquina virtual.

O relógio do sistema na estação de trabalho do usuário na organização 1 será ajustado manualmente. O relógio do sistema de uma máquina virtual especializada na organização 2 será sincronizado com o relógio do sistema do hipervisor e esses, por sua vez, serão sincronizados via Internet com servidores de horário público.

Isolamento de elementos estruturais da proteção de informações criptográficas
Com base na descrição acima da infraestrutura de TI, destacamos os elementos estruturais do sistema de proteção de informações criptográficas e os escrevemos na tabela.

Tabela - Correspondência de elementos do modelo de proteção de informações criptográficas com elementos de sistemas de informação

Nome do item	Organização 1	Organização 2
Software de aplicação	Software CryptoARM	Software CryptoARM
O software de núcleo criptográfico	SKZI CryptoPro CSP	SKZI CryptoPro CSP
Hardware de criptomoeda	está faltando	JaCarta GOST
API	MS CryptoAPI	MS CryptoAPI
Armazenamento de chaves públicas	AWP do usuário: - disco rígido; - O armazenamento de certificados padrão do Windows.	Hipervisor: - disco rígido. Máquina virtual: - disco rígido; - O armazenamento de certificados padrão do Windows.
Cofre de Chaves Privadas	Porta-chaves ruToken operando no modo de chave recuperável	Porta-chaves JaCarta GOST operando no modo de chave não recuperável
Canal de Troca de Chave Pública	AWP do usuário: - memória de acesso aleatório.	Hipervisor: - memória de acesso aleatório. Máquina virtual: - memória de acesso aleatório.
Canal de troca de chave privada	AWP do usuário: - barramento USB; - memória de acesso aleatório.	está faltando
Canal de troca de criptomoedas	ausente (sem hardware de núcleo criptográfico)	AWP do usuário: - barramento USB; - memória de acesso aleatório; - módulo de software USB-over-IP; - interface de rede. Rede corporativa da organização 2. Hipervisor: - memória de acesso aleatório; - interface de rede. Máquina virtual: - interface de rede; - memória de acesso aleatório; - Módulo de software USB sobre IP.
Canal aberto de troca de dados	AWP do usuário: - meios de entrada-saída; - memória de acesso aleatório; - disco rígido.	AWP do usuário: - meios de entrada-saída; - memória de acesso aleatório; - disco rígido; - interface de rede. Rede corporativa da organização 2. Hipervisor: - interface de rede; - memória de acesso aleatório; - disco rígido. Máquina virtual: - interface de rede; - memória de acesso aleatório; - disco rígido.
Canal de dados seguro	A internet Rede corporativa da organização 1. AWP do usuário: - disco rígido; - memória de acesso aleatório; - interface de rede.	A internet Rede corporativa da organização 2. Hipervisor: - interface de rede; - memória de acesso aleatório; - disco rígido. Máquina virtual: - interface de rede; - memória de acesso aleatório; - disco rígido.
Canal de tempo	AWP do usuário: - meios de entrada-saída; - memória de acesso aleatório; - temporizador do sistema.	A internet Organização de rede corporativa 2, Hipervisor: - interface de rede; - memória de acesso aleatório; - temporizador do sistema. Máquina virtual: - memória de acesso aleatório; - temporizador do sistema.
Canal de Transmissão de Comando de Controle	AWP do usuário: - meios de entrada-saída; - memória de acesso aleatório. (Interface gráfica do usuário do software CryptoARM)	Máquina virtual: - memória de acesso aleatório; - disco rígido. (Scripts de automação)
Canal para receber os resultados do trabalho	AWP do usuário: - meios de entrada-saída; - memória de acesso aleatório. (Interface gráfica do usuário do software CryptoARM)	Máquina virtual: - memória de acesso aleatório; - disco rígido. (Arquivos de log de script de automação)

Ameaças de segurança de nível superior

Explicações

Pressupostos feitos durante a decomposição do perigo:

1. Algoritmos criptográficos fortes são usados.
2. Os algoritmos criptográficos são usados ​​de maneira segura nos modos de operação corretos (por exemplo, o BCE não é usado para criptografar grandes quantidades de dados, a carga permitida na chave é levada em consideração etc.).
3. Os invasores estão cientes de todos os algoritmos, protocolos e chaves públicas aplicáveis.
4. Os invasores podem ler todos os dados criptografados.
5. Os atacantes são capazes de reproduzir qualquer elemento do programa no sistema.

Decomposição

U1 Compromisso de chaves criptográficas privadas.
U2 Criptografe dados fraudulentos em nome de um remetente legítimo.
U3 Descriptografia de dados criptografados por pessoas que não são destinatários legítimos de dados (invasores).
U4 Criação de uma assinatura eletrônica de um signatário legítimo sob dados falsos.
U5 Obtenção de um resultado positivo da verificação da assinatura eletrônica de dados falsos.
Y6 Aceitação incorreta de documentos eletrônicos para execução devido a problemas na organização do gerenciamento de documentos eletrônicos.
Y7 Familiarização não autorizada com os dados protegidos durante o processamento pelo sistema de proteção de informações criptográficas.

U1 Compromisso de chaves criptográficas privadas

U1.1 Obtendo a chave privada do armazenamento de chaves privadas.

U1.2 Obtenção de uma chave privada de objetos do ambiente do funcionamento da criptomoeda na qual ela pode estar temporariamente localizada.
Explicações U1.2.

Os objetos nos quais a chave privada pode ser temporariamente armazenada incluirão:

1. RAM
2. arquivos temporários
3. trocar arquivos
4. arquivos de hibernação
5. arquivos de instantâneos do estado "quente" de máquinas virtuais, incluindo arquivos pausados ​​do conteúdo da RAM de máquinas virtuais.

U1.2.1 Removendo chaves privadas da RAM funcionando, congelando os módulos de RAM, extraindo-os e lendo os dados (ataque de congelamento).
Explicações U1.2.1.
Exemplo de ataque .

U1.3 Obtendo uma chave privada de um canal de troca de chaves privada.
Explicações U1.3.
Um exemplo da implementação desta ameaça será dado abaixo .

U1.4 Modificação não autorizada do núcleo de criptografia, como resultado do qual as chaves privadas se tornam conhecidas pelos atacantes.

U1.5 Compromisso de uma chave privada como resultado do uso de canais técnicos de vazamento de informações (TKUI).
Explicações U1.5.
Exemplo de ataque .

U1.6 Compromisso da chave privada como resultado do uso de meios técnicos especiais (STS) projetados para recuperação de informações secretas ("bugs").

U1.7 Compromisso de chaves privadas durante o armazenamento fora do sistema de proteção de informações criptográficas.
Explicações U1.7.
Por exemplo, um usuário armazena suas principais mídias em uma gaveta da área de trabalho, da qual elas podem ser facilmente extraídas por intrusos.

U2 Criptografar dados fraudulentos em nome de um remetente legítimo

Explicações
Essa ameaça é considerada apenas para esquemas de criptografia de dados com autenticação por remetente. Exemplos de tais esquemas são indicados nas recomendações de padronização R 1323565.1.004-2017 “Tecnologia da Informação. Segurança da informação criptográfica. Esquemas de autenticação de chave pública baseados em chave pública . ” Para outros esquemas criptográficos, essa ameaça não existe, pois a criptografia é realizada nas chaves públicas do destinatário e elas geralmente são conhecidas pelos atacantes.

Decomposição
U2.1 Compromisso da chave privada do remetente:
U2.1.1 Link: “Um modelo de ameaça típico. Sistema de proteção de informações criptográficas U1. Compromisso de chaves criptográficas privadas . ”

U2.2 Substituição de dados de entrada no canal aberto de troca de dados.
Notas U2.2.
Exemplos de implementação dessa ameaça são fornecidos abaixo aqui e aqui .

U3 Descriptografia de dados criptografados por pessoas que não são destinatários legítimos de dados (invasores)

Decomposição
U3.1 Compromisso de chaves privadas do destinatário de dados criptografados.
Y3.1.1 Link: “Modelo de ameaça típico. Sistema de segurança de informações criptográficas. U1 Compromisso de chaves criptográficas privadas . ”

U3.2 Substituindo dados criptografados em um canal seguro de troca de dados.

U4 Criação de uma assinatura eletrônica de um signatário legítimo sob dados falsos

Decomposição
U4.1 Compromisso de chaves privadas de uma assinatura eletrônica de um signatário legítimo.
Y4.1.1 Link: “Modelo de ameaça típico. Sistema de segurança de informações criptográficas. U1 Compromisso de chaves criptográficas privadas . ”

U4.2 Substituição de dados assinados no canal aberto de troca de dados.
Nota Y4.2.
Exemplos de implementação dessa ameaça são fornecidos abaixo aqui e aqui .

U5 Obtenção de um resultado positivo da verificação da assinatura eletrônica de dados falsos

Decomposição
U5.1 Os invasores interceptam uma mensagem no resultado negativo da verificação da assinatura eletrônica no canal de transmissão dos resultados do trabalho e a substituem por uma mensagem com um resultado positivo.

U5.2 Os invasores realizam um ataque à confiança nos certificados de assinatura ( CENÁRIO - todos os elementos são necessários ):
U5.2.1 Os invasores geram uma assinatura eletrônica de chave pública e privada. Se o sistema usar certificados de chave de assinatura eletrônica, eles gerarão um certificado de assinatura eletrônica o mais semelhante possível ao certificado do remetente pretendido dos dados cuja mensagem eles desejam falsificar.
U5.2.2 Os invasores fazem alterações não autorizadas no armazenamento de chaves públicas, fornecendo à chave pública gerada o nível necessário de confiança e autoridade.
U5.2.3 Os invasores assinam dados falsos com uma chave de assinatura eletrônica gerada anteriormente e os injetam no canal seguro de troca de dados.

U5.3 Os atacantes realizam um ataque usando chaves expiradas de uma assinatura eletrônica de um signatário legal ( CENÁRIO - todos os elementos são necessários ):
U5.3.1 Os invasores comprometem as chaves privadas expiradas (atualmente não válidas) da assinatura eletrônica do remetente legítimo.
U5.3.2 Os invasores substituem o horário no canal de transmissão de horário pelo horário em que as chaves comprometidas ainda estavam ativas.
U5.3.3 Os invasores assinam dados fraudulentos com uma chave de assinatura eletrônica previamente comprometida e os injetam no canal seguro de troca de dados.

U5.4 Os atacantes realizam um ataque usando as chaves comprometidas da assinatura eletrônica de um signatário legal ( CENÁRIO - todos os elementos são necessários ):
U5.4.1 Os invasores fazem uma cópia do armazenamento de chaves públicas.
U5.4.2 Os invasores comprometem as chaves privadas de um dos remetentes legais. Ele percebe um compromisso, revoga as chaves, informações sobre a revogação da chave são colocadas no armazenamento de chaves públicas.
U5.4.3 Os invasores substituem o armazenamento de chaves públicas por um anteriormente copiado.
U5.4.4 Os invasores assinam dados fraudulentos com uma chave de assinatura eletrônica previamente comprometida e os injetam no canal seguro de troca de dados.

U5.5 <...> devido à presença de erros na implementação das 2ª e 3ª etapa de verificação de assinaturas eletrônicas:
Explicações U5.5.
Um exemplo da implementação desta ameaça é dado abaixo .

U5.5.1 Verificando a confiança no certificado da chave de assinatura eletrônica apenas pela presença de confiança no certificado com o qual é assinado, sem verificações de CRL ou OCSP.
Explicações U.5.5.1.
Exemplo de implementação de ameaças .

U5.5.2 Ao criar uma cadeia de confiança para um certificado, a autoridade de emissão de certificados não é analisada
Explicações U.5.5.2.
Um exemplo de ataque em relação aos certificados SSL / TLS.
Os invasores compraram um certificado legítimo por e-mail. Em seguida, eles criaram um certificado de site fraudulento e o assinaram com seu certificado. Se a verificação de autorização não for realizada, ao verificar a cadeia de confiança, ela estará correta e, portanto, um certificado fraudulento também estará correto.

U5.5.3 Ao criar uma cadeia confiável de certificados, os certificados de revogação intermediária não são verificados.

U5.5.4 A CRL é atualizada com menos frequência do que a autoridade de certificação os emite.

U5.5.5 A decisão sobre a confiança na assinatura eletrônica é tomada antes que a resposta do OCSP sobre o status do certificado seja recebida, enviada na solicitação feita posteriormente à hora em que a assinatura foi gerada ou anterior à próxima após a assinatura da CRL.
Explicações U.5.5.5.
Nos regulamentos da maioria das CAs, o tempo de revogação de certificado é considerado o tempo de emissão da CRL mais próxima que contém informações sobre a revogação de certificado.

U5.5.6 Após o recebimento dos dados assinados, a propriedade do certificado para o remetente não é verificada.
Explicações U.5.5.6.
Exemplo de ataque. No que diz respeito aos certificados SSL: o endereço do servidor chamado não pode ser verificado quanto ao valor do campo CN no certificado.
Exemplo de ataque. Os invasores comprometeram as chaves de assinatura eletrônica de um dos participantes no sistema de pagamento. Depois disso, eles invadiram a rede de outro participante e enviaram documentos de pagamento assinados por chaves comprometidas ao servidor de liquidação do sistema de pagamento em seu nome. Se o servidor analisar apenas a confiança e não verificar a conformidade, os documentos fraudulentos serão considerados legítimos.

Y6 Aceitação incorreta de documentos eletrônicos para execução devido a problemas na organização do gerenciamento de documentos eletrônicos.

Decomposição
U6.1 A parte receptora não detecta a duplicação dos documentos recebidos.
Explicações U6.1.
Exemplo de ataque. Os invasores podem interceptar o documento transmitido ao destinatário, mesmo que ele esteja protegido criptograficamente e enviá-lo repetidamente para o canal seguro de transmissão de dados. Se o destinatário não identificar duplicatas, todos os documentos recebidos serão percebidos e processados ​​como vários documentos.

Y7 Familiarização não autorizada com os dados protegidos durante o processamento

Decomposição

U7.1 <...> devido a vazamento de informações em canais de terceiros (ataque de canal lateral).
Explicações U7.1.
Exemplo de ataque .

U7.2 <...> devido à neutralização da proteção contra acesso não autorizado a informações processadas no CIPF:
U7.2.1 Operação do CIPF com violações dos requisitos descritos na documentação do CIPF.

U7.2.2 <...> realizado devido à presença de vulnerabilidades em:
U7.2.2.1 <...> proteção contra acesso não autorizado.
U7.2.2.2 <...> o próprio CPSI.
U7.2.2.3 <...> o ambiente do funcionamento da instalação de criptografia.

Exemplos de ataque

Os cenários considerados abaixo obviamente contêm erros de organização de segurança da informação e servem apenas para ilustrar possíveis ataques.

Cenário 1. Um exemplo da implementação das ameaças U2.2 e U4.2.

Descrição da propriedade


Software ARM KBR e SKZI SKAD A assinatura é instalada em um computador físico que não está conectado a uma rede de computadores. O FCN vdToken é usado como portador de chave no modo de chave não recuperável.

O procedimento de cálculo supõe que o especialista em cálculo faça o download de mensagens eletrônicas em formato aberto (diagrama do antigo KBR AWP) de seu computador de trabalho de um servidor de arquivos seguro especial, depois as grava no pen drive de mídia alienada e as transfere para o KBR AWP, onde ele as criptografa e inscreve-se. Depois disso, o especialista transfere mensagens eletrônicas protegidas para o meio alienado e, em seguida, através do computador em funcionamento, as grava em um servidor de arquivos, de onde eles chegam à UTA e depois ao sistema de pagamento do Banco da Rússia.

Nesse caso, os canais para troca de dados abertos e protegidos incluirão: um servidor de arquivos, o computador de trabalho de um especialista e uma mídia alienável.

Ataque
Os atacantes não autorizados instalam um sistema de controle remoto no computador de trabalho do especialista e, no momento em que escrevemos no meio alienado, as ordens de pagamento (mensagens eletrônicas) substituem abertamente o conteúdo de um deles. O especialista transfere as ordens de pagamento para a estação de trabalho da CBD, assina e criptografa-as sem perceber a substituição (por exemplo, devido ao grande número de ordens de pagamento no voo, fadiga etc.). Depois disso, uma ordem de pagamento falsa, passando pela cadeia tecnológica, entra no sistema de pagamento do Banco da Rússia.

Cenário 2. Um exemplo da implementação das ameaças U2.2 e U4.2.

Descrição da propriedade


Um computador com o KBR AWARD instalado, a assinatura SCAD e o portador de chave conectado FCN vdToken opera em uma sala dedicada sem acesso do pessoal.
O especialista em cálculos está conectado à AWS do CBD no modo de acesso remoto via protocolo RDP.

Ataque
Os invasores interceptam detalhes usando os quais o especialista em cálculo se conecta e trabalha com o KBR AWS (por exemplo, devido a códigos maliciosos em seu computador). Em seguida, é feita uma conexão em seu nome e uma ordem de pagamento falsa é enviada ao sistema de pagamento do Banco da Rússia.

Cenário 3. Exemplo de implementação da ameaça U1.3.

Descrição da propriedade


Considere uma das opções hipotéticas para implementar os módulos de integração ABS-KBR para o novo esquema (AWP KBR-N), no qual a assinatura eletrônica dos documentos de saída ocorre no lado do ABS. Ao mesmo tempo, assumimos que o ABS opera com base em um sistema operacional que não é suportado pela assinatura SCAD SKAD e, portanto, a funcionalidade criptográfica é transferida para uma máquina virtual separada - o módulo de integração ABS-KBR.
Como meio de chave, é usado um token USB comum, operando no modo de uma chave recuperável. Ao conectar a mídia da chave ao hipervisor, verificou-se que não havia portas USB livres no sistema, por isso foi decidido conectar o token USB através de um hub de rede USB e instalar um cliente USB sobre IP na máquina virtual que se comunicará com o hub.

Ataque
Os invasores interceptaram a chave privada da assinatura eletrônica do canal de comunicação entre o hub USB e o hipervisor (os dados foram transmitidos em formato aberto). Com uma chave privada, os atacantes formaram uma ordem de pagamento falsa, assinaram com uma assinatura eletrônica e a enviaram ao KBR-N AWP para execução.

Cenário 4. Um exemplo da implementação de ameaças U5.5.

Descrição da propriedade
Considere o mesmo esquema que no cenário anterior. Assumimos que as mensagens eletrônicas recebidas do KBR-N AWP estão na pasta \\ ... \ SHARE \ In, e as enviadas para o KBR-N AWP e para o sistema de pagamento do Banco da Rússia serão enviadas para \\. .. \ SHARE \ out.
Também assumimos que, durante a implementação do módulo de integração, as listas de certificados revogados são atualizadas somente mediante reemissão de chaves criptográficas e também que as mensagens eletrônicas recebidas na pasta \\ ... \ SHARE \ In são verificadas apenas para controle de integridade e controle de confiança para abrir chave de assinatura eletrônica.

Ataque

Os atacantes, usando as chaves roubadas no cenário anterior, assinaram uma ordem de pagamento falsa contendo informações sobre o recebimento de dinheiro na conta de um cliente fraudulento e o injetaram no canal seguro de troca de dados. Como a verificação de que a ordem de pagamento foi assinada pelo Banco da Rússia não é realizada, ela é aceita para execução.