Links para outras partes do estudo
- (Voce esta aqui)
Este artigo completa a série de publicações dedicadas a garantir a segurança da informação dos pagamentos bancários que não sejam em dinheiro. Aqui veremos os modelos de ameaças típicos mencionados em :
- .
- .
- .
- .
HABRO-AVISO!!! Caros Khabrovitas, esta não é uma postagem divertida.
As mais de 40 páginas de materiais escondidas sob o corte destinam-se a ajudar no trabalho ou estudo pessoas especializadas em segurança bancária ou da informação. Esses materiais são o produto final da pesquisa e estão escritos em tom seco e formal. Em essência, estes são espaços em branco para documentos internos de segurança da informação.Bem, tradicional - “a utilização das informações do artigo para fins ilegais é punível por lei”. Leitura produtiva!
Informações para leitores que se familiarizarem com o estudo a partir desta publicação.
Sobre o que é o estudo?
Você está lendo um guia de um especialista responsável por garantir a segurança da informação nos pagamentos em um banco.
Lógica de apresentação
No início em и é fornecida uma descrição do objeto protegido. Então em descreve como construir um sistema de segurança e fala sobre a necessidade de criar um modelo de ameaça. EM fala sobre quais modelos de ameaças existem e como eles são formados. EM и É fornecida uma análise de ataques reais. и 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 TÍPICO DE AMEAÇA. CONEXÃO DE REDE
Objeto de proteção ao qual o modelo de ameaça (escopo) é aplicado
O objeto da proteção são os dados transmitidos através de uma conexão de rede operando em redes de dados construídas com base na pilha TCP/IP.
Arquitetura
Descrição dos elementos arquitetônicos:
- "Nós finais" — nós que trocam informações protegidas.
- "Nós intermediários" — elementos de uma rede de transmissão de dados: routers, switches, servidores de acesso, servidores proxy e outros equipamentos — através dos quais é transmitido o tráfego de ligação à rede. Em geral, uma conexão de rede pode funcionar sem nós intermediários (diretamente entre os nós finais).
Ameaças à segurança de alto nível
Decomposição
U1. Acesso não autorizado aos dados transmitidos.
U2. Modificação não autorizada dos dados transmitidos.
U3. Violação da autoria dos dados transmitidos.
U1. Acesso não autorizado aos dados transmitidos
Decomposição
U1.1. <…>, realizado nos nós finais ou intermediários:
U1.1.1. <…> lendo dados enquanto eles estão nos dispositivos de armazenamento host:
U1.1.1.1. <…> na RAM.
Explicações para U1.1.1.1.
Por exemplo, durante o processamento de dados pela pilha de rede do host.
U1.1.1.2. <…> em 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 host:
Explicações para U1.2.1.
A captura de todos os pacotes é realizada alternando a placa de rede para o modo promíscuo (modo promíscuo para adaptadores com fio ou modo monitor para adaptadores wi-fi).
U1.2.2. <…> realizando ataques man-in-the-middle (MiTM), mas sem modificar os dados transmitidos (sem contar os dados do serviço de protocolo de rede).
U1.2.2.1. Link: .
U1.3. <…>, realizada devido ao vazamento de informações através de canais técnicos (TKUI) de nós físicos ou linhas de comunicação.
U1.4. <…>, efectuada através da instalação de meios técnicos especiais (STS) nos nós finais ou intermédios, destinados à recolha secreta de informação.
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 eles estão nos dispositivos de armazenamento dos nós:
U2.1.1.1. <…> na RAM:
U2.1.1.2. <…> em memória não volátil:
U2.2. <…>, realizado em nós de terceiros da rede de transmissão de dados:
U2.2.1. <…> realizando ataques man-in-the-middle (MiTM) e redirecionando o tráfego para o nó do invasor:
U2.2.1.1. A conexão física do equipamento do invasor causa a interrupção da conexão de rede.
U2.2.1.2. Realizando ataques a protocolos de rede:
U2.2.1.2.1. <…> gerenciamento de redes locais virtuais (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Modificação não autorizada de 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 estáticas de roteadores.
U2.2.1.2.2.2. Anúncio de rotas falsas por invasores através de protocolos de roteamento dinâmico.
U2.2.1.2.3. <…> configuração automática:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> endereçamento e resolução de nomes:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Fazer alterações não autorizadas em arquivos de nomes de host locais (hosts, lmhosts, etc.)
U3. Violação de direitos autorais de dados transmitidos
Decomposição
U3.1. Neutralização dos mecanismos de determinação da autoria da informação através da indicação de informações falsas sobre o autor ou fonte dos 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: .
U3.1.1.2. Neutralização da proteção de direitos autorais dos dados transmitidos, implementada por meio de códigos de confirmação únicos:
U3.1.1.2.1. .
U3.1.2. Alterando informações sobre a fonte das informações transmitidas:
U3.1.2.1. .
U3.1.2.2. .
MODELO TÍPICO DE AMEAÇA. SISTEMA DE INFORMAÇÃO CONSTRUÍDO COM BASE NA ARQUITETURA CLIENTE-SERVIDOR
Objeto de proteção ao qual o modelo de ameaça (escopo) é aplicado
O objeto de proteção é um sistema de informação construído com base em uma arquitetura cliente-servidor.
Arquitetura
Descrição dos elementos arquitetônicos:
- "Cliente" – um dispositivo no qual opera a parte cliente do sistema de informação.
- "Servidor" – um dispositivo no qual opera a parte servidor do sistema de informação.
- "Banco de dados" — parte da infra-estrutura de servidores de um sistema de informação, concebida para armazenar dados processados pelo sistema de informação.
- "Conexão de rede" — um canal de troca de informações entre o Cliente e o Servidor que passa pela rede de dados. Uma descrição mais detalhada do modelo de elemento é fornecida em .
Restrições
Ao modelar um objeto, as seguintes restrições são definidas:
- O usuário interage com o sistema de informação dentro de períodos de tempo finitos, chamados sessões de trabalho.
- No início de cada sessão de trabalho o usuário é identificado, autenticado e autorizado.
- Todas as informações protegidas são armazenadas na parte do servidor do sistema de informação.
Ameaças à segurança de alto nível
Decomposição
U1. Realizar ações não autorizadas por invasores em nome de um usuário legítimo.
U2. Modificação não autorizada de informações protegidas durante o seu processamento pela parte servidora do sistema de informação.
U1. Executar ações não autorizadas por invasores em nome de um usuário legítimo
Explicações
Normalmente em sistemas de informação, as ações são correlacionadas com o usuário que as executou usando:
- logs de operação do sistema (logs).
- atributos especiais de objetos de dados contendo informações sobre o usuário que os criou ou modificou.
Em relação a uma sessão de trabalho, esta ameaça pode ser decomposta em:
- <…> realizado dentro da sessão do usuário.
- <…> executado fora da sessão do usuário.
Uma sessão de usuário pode ser iniciada:
- Pelo próprio usuário.
- Malfeitores.
Nesta fase, a decomposição intermediária desta ameaça será semelhante a esta:
U1.1. Ações não autorizadas foram executadas em uma sessão de usuário:
U1.1.1. <…> instalado pelo usuário atacado.
U1.1.2. <…> instalado por invasores.
U1.2. Ações não autorizadas foram executadas fora da sessão do usuário.
Do ponto de vista dos objetos da infraestrutura de informação que podem ser afetados por invasores, a decomposição das ameaças intermediárias será semelhante a esta:
elementos
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 em uma sessão de usuário:
U1.1.1. <…> instalado pelo usuário atacado:
U1.1.1.1. Os invasores agiram de forma independente do Cliente:
U1.1.1.1.1 Os invasores usaram ferramentas padrão de acesso ao sistema de informação:
Ó1.1.1.1.1.1. Os invasores utilizaram meios físicos de entrada/saída do Cliente (teclado, mouse, monitor ou tela sensível ao toque de um dispositivo móvel):
U1.1.1.1.1.1.1. Os invasores operaram durante períodos em que a sessão estava ativa, os recursos de E/S estavam disponíveis e o usuário não estava presente.
Ó1.1.1.1.1.2. Os invasores usaram ferramentas de administração remota (padrão ou fornecidas por código malicioso) para controlar o Cliente:
U1.1.1.1.1.2.1. Os invasores operaram durante períodos em que a sessão estava ativa, os recursos de E/S estavam disponíveis e o usuário não estava presente.
U1.1.1.1.1.2.2. Os invasores utilizaram ferramentas de administração remota, cujo funcionamento é invisível para o usuário atacado.
U1.1.1.2. Os invasores substituíram os dados na conexão de rede entre o Cliente e o Servidor, modificando-os de forma que fossem percebidos como ações de um usuário legítimo:
U1.1.1.2.1. Link: .
U1.1.1.3. Os invasores forçaram o usuário a realizar as ações especificadas usando métodos de engenharia social.
У1.1.2 <…> instalado por invasores:
U1.1.2.1. Os invasores agiram a partir do Cliente (И):
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: .
Ó1.1.2.1.2. Os invasores usaram ferramentas padrão de acesso ao sistema de informação
U1.1.2.2. Os invasores operavam a partir de outros nós da rede de dados, a partir dos quais uma conexão de rede com o Servidor poderia ser estabelecida (И):
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: .
U1.1.2.2.2. Os invasores usaram meios não padronizados de acesso ao sistema de informação.
Explicações U1.1.2.2.2.
Os invasores podem instalar um cliente padrão do sistema de informação em um nó de terceiros ou usar software não padrão que implemente protocolos de troca padrão entre o Cliente e o Servidor.
U1.2 Ações não autorizadas foram executadas fora da sessão do usuário.
U1.2.1 Os invasores realizaram ações não autorizadas e, em seguida, fizeram alterações não autorizadas nos logs de operação do sistema de informação ou nos atributos especiais dos objetos de dados, indicando que as ações que executaram foram realizadas por um usuário legítimo.
U2. Modificação não autorizada de informações protegidas durante seu processamento pela parte servidora do sistema de informação
Decomposição
U2.1. Os invasores modificam informações protegidas usando ferramentas padrão do sistema de informação e fazem isso em nome de um usuário legítimo.
U2.1.1. Link: .
U2.2. Os invasores modificam informações protegidas usando mecanismos de acesso a dados não previstos pelo funcionamento normal do sistema de informação.
U2.2.1. Os invasores modificam arquivos contendo 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 de uma cópia de backup modificada não autorizada.
U2.2.2. Os invasores modificam as informações protegidas armazenadas no banco de dados (И):
U2.2.2.1. Os invasores neutralizam o sistema de controle de acesso do DBMS:
U2.2.2.1.1. Link: .
U2.2.2.2. Os invasores modificam as informações usando interfaces DBMS padrão para acessar os dados.
U2.3. Os invasores modificam as informações protegidas por meio de modificações não autorizadas dos algoritmos operacionais do software que as processa.
U2.3.1. O código fonte do software está sujeito a modificações.
U2.3.1. O código de máquina do software está sujeito a modificações.
U2.4. Os invasores modificam informações protegidas explorando vulnerabilidades no software do sistema de informação.
U2.5. Os invasores modificam as informações protegidas quando elas são transferidas entre componentes da parte servidora do sistema de informação (por exemplo, um servidor de banco de dados e um servidor de aplicativos):
U2.5.1. Link: .
MODELO TÍPICO DE AMEAÇA. SISTEMA DE CONTROLE DE ACESSO
Objeto de proteção ao qual o modelo de ameaça (escopo) é aplicado
O objeto de proteção ao qual este 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 construído sobre uma arquitetura cliente-servidor.”
Neste modelo de ameaça, um sistema de controle de acesso de usuário significa um componente de um sistema de informação que implementa as seguintes funções:
- Identificação do usuário.
- Autenticação de usuário.
- Autorizações de usuário.
- Registrando ações do usuário.
Ameaças à segurança de alto nível
Decomposição
U1. Estabelecimento não autorizado de uma sessão em nome de um usuário legítimo.
U2. Aumento não autorizado de privilégios de usuário em um sistema de informação.
U1. Estabelecimento não autorizado de uma sessão em nome de um usuário legítimo
Explicações
A decomposição desta ameaça dependerá geralmente do tipo de sistemas de identificação e autenticação de utilizadores utilizados.
Neste modelo será considerado apenas um sistema de identificação e autenticação do usuário utilizando login e senha de texto. Nesse caso, assumiremos que o login do usuário é uma informação publicamente disponível e conhecida pelos invasores.
Decomposição
U1.1. <…> devido ao comprometimento de credenciais:
U1.1.1. Os invasores comprometeram as credenciais do usuário ao armazená-las.
Explicações U1.1.1.
Por exemplo, as credenciais podem ser escritas em um post-it colado no monitor.
U1.1.2. O usuário transmitiu acidental ou maliciosamente 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 compartilhou intencionalmente suas credenciais:
U1.1.2.2.1. <…> para colegas de trabalho.
Explicações U1.1.2.2.1.
Por exemplo, para que possam substituí-lo durante uma doença.
U1.1.2.2.2. <…> aos empreiteiros do empregador que realizam trabalhos em objetos de infraestrutura de informação.
U1.1.2.2.3. <…> a terceiros.
Explicações U1.1.2.2.3.
Uma, mas não a única opção para implementar esta ameaça é a utilização de métodos de engenharia social pelos atacantes.
U1.1.3. Os invasores selecionaram credenciais usando métodos de força bruta:
U1.1.3.1. <…> usando mecanismos de acesso padrão.
U1.1.3.2. <…> usando códigos interceptados anteriormente (por exemplo, hashes de senha) para armazenar credenciais.
U1.1.4. Os invasores usaram código malicioso para interceptar credenciais de usuários.
U1.1.5. Os invasores extraíram credenciais da conexão de rede entre o Cliente e o Servidor:
U1.1.5.1. Link: .
U1.1.6. Os invasores extraíram credenciais de registros de sistemas de monitoramento de trabalho:
U1.1.6.1. <…> sistemas de vigilância por vídeo (se as teclas digitadas no teclado foram gravadas durante a operação).
U1.1.6.2. <…> sistemas para monitorar as ações dos funcionários no computador
Explicações U1.1.6.2.
Um exemplo de tal sistema é .
U1.1.7. Os invasores comprometeram as credenciais dos usuários devido a falhas no processo de transmissão.
Explicações U1.1.7.
Por exemplo, enviar senhas em texto não criptografado por e-mail.
U1.1.8. Os invasores obtiveram credenciais monitorando a sessão de um usuário usando sistemas de administração remota.
U1.1.9. Os invasores obtiveram credenciais como resultado do vazamento por meio de canais técnicos (TCUI):
U1.1.9.1. Os invasores observaram como o usuário inseriu credenciais no teclado:
U1.1.9.1.1 Os invasores estavam localizados próximos ao usuário e viram a entrada de credenciais com seus próprios olhos.
Explicações U1.1.9.1.1
Tais casos incluem as ações de colegas de trabalho ou o caso em que o teclado do usuário fica visível para os visitantes da organização.
U1.1.9.1.2 Os atacantes utilizaram meios técnicos adicionais, como binóculos ou veículo aéreo não tripulado, e viram a entrada de credenciais através de uma janela.
U1.1.9.2. Os invasores extraíram credenciais de comunicações de rádio entre o teclado e a unidade do sistema do computador quando estavam conectados por meio de uma interface de rádio (por exemplo, Bluetooth).
U1.1.9.3. Os invasores interceptaram credenciais vazando-as através do canal de radiação e interferência eletromagnética espúria (PEMIN).
Explicações U1.1.9.3.
Exemplos de ataques и .
U1.1.9.4. O invasor interceptou a entrada de credenciais do teclado por meio de meios técnicos especiais (STS) projetados para obter informações secretamente.
Explicações U1.1.9.4.
Примеры .
U1.1.9.5. Os invasores interceptaram a entrada de credenciais do teclado usando
análise do sinal Wi-Fi modulado pelo processo de digitação do usuário.
Explicações U1.1.9.5.
Exemplo .
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 .
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 .
U1.1.10. <…>, previamente salvo no Cliente.
Explicações U1.1.10.
Por exemplo, um usuário poderia salvar um login e senha no 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 U1.1.11.
Por exemplo, depois que um usuário foi demitido, suas contas permaneceram desbloqueadas.
U1.2. <…> explorando vulnerabilidades no sistema de controle de acesso.
U2. Elevação não autorizada de privilégios de usuário em um sistema de informação
Decomposição
U2.1 <…> fazendo alterações não autorizadas em dados contendo informações sobre privilégios de usuário.
U2.2 <…> através do uso de vulnerabilidades no sistema de controle de acesso.
U2.3. <…> devido a deficiências no processo de gerenciamento de acesso de usuários.
Explicações U2.3.
Exemplo 1. Um usuário recebeu mais acesso para trabalho do que precisava por motivos comerciais.
Exemplo 2: Depois que um usuário foi transferido para outra posição, os direitos de acesso concedidos anteriormente não foram revogados.
MODELO TÍPICO DE AMEAÇA. MÓDULO DE INTEGRAÇÃO
Objeto de proteção ao qual o modelo de ameaça (escopo) é aplicado
Um módulo de integração é um conjunto de objetos de infraestrutura de informação projetados para organizar a troca de informações entre sistemas de informação.
Considerando 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 elo de ligação entre os componentes de um sistema de informação.
Arquitetura
O diagrama generalizado do módulo de integração é assim:
Descrição dos elementos arquitetônicos:
- "Servidor Exchange (SO)" – um nó/serviço/componente de um sistema de informação que desempenha a função de troca de dados com outro sistema de informação.
- "Mediador" – um nó/serviço concebido para organizar a interação entre sistemas de informação, mas não faz parte deles.
Exemplos "Intermediários" pode haver serviços de e-mail, barramentos de serviços corporativos (barramento de serviços corporativos/arquitetura SoA), servidores de arquivos de terceiros, etc. Em geral, o módulo de integração não pode conter “Intermediários”. - "Software de processamento de dados" – um conjunto de programas que implementam protocolos de troca de dados e conversão de formato.
Por exemplo, converter dados do formato UFEBS para o formato ABS, alterar o status das mensagens durante a transmissão, etc. - "Conexão de rede" corresponde ao objeto descrito no modelo de ameaça padrão “Conexão de rede”. Algumas das conexões de rede mostradas no diagrama acima podem não existir.
Exemplos de módulos de integração
Esquema 1. Integração de ABS e AWS KBR por meio de um servidor de arquivos de terceiros
Para executar pagamentos, um funcionário do banco autorizado baixa documentos de pagamento eletrônico do sistema bancário central e os salva em um arquivo (em seu próprio formato, por exemplo, um dump SQL) em uma pasta de rede (...SHARE) em um servidor de arquivos. Em seguida, esse arquivo é convertido por meio de um script conversor em um conjunto de arquivos no formato UFEBS, que são lidos pela estação de trabalho CBD.
Depois disso, o funcionário autorizado - o usuário do local de trabalho automatizado KBR - criptografa e assina os arquivos recebidos e os envia para o sistema de pagamento do Banco da Rússia.
Quando os pagamentos são recebidos do Banco da Rússia, o local de trabalho automatizado do KBR os descriptografa e verifica a assinatura eletrônica, após o que os registra na forma de um conjunto de arquivos no formato UFEBS em um servidor de arquivos. Antes de importar os documentos de pagamento para o ABS, eles são convertidos por meio de um script conversor do formato UFEBS para o formato ABS.
Assumiremos que neste esquema o ABS opera em um servidor físico, a estação de trabalho KBR opera em um computador dedicado e o script conversor é executado em um servidor de arquivos.
Correspondência dos objetos do diagrama considerado com os elementos do modelo do módulo de integração:
“Servidor Exchange do lado ABS” – Servidor ABS.
“Servidor Exchange do lado AWS KBR” – estação de trabalho de computador KBR.
"Mediador" – servidor de arquivos de terceiros.
"Software de processamento de dados" – script conversor.
Esquema 2. Integração de ABS e AWS KBR ao colocar uma pasta de rede compartilhada com pagamentos no AWS KBR
Tudo é semelhante ao Esquema 1, mas não é utilizado um servidor de arquivos separado, em vez disso, uma pasta de rede (...SHARE) com documentos de pagamento eletrônico é colocada em um computador com uma estação de trabalho da CBD. O script conversor também funciona na estação de trabalho CBD.
Correspondência dos objetos do diagrama considerado com os elementos do modelo do módulo de integração:
Semelhante ao Esquema 1, mas "Mediador" não usado.
Esquema 3. Integração de ABS e local de trabalho automatizado KBR-N via IBM WebSphera MQ e assinatura de documentos eletrônicos “no lado ABS”
O ABS opera em uma plataforma que não é suportada pela assinatura CIPF SCAD. A assinatura dos documentos eletrônicos de saída é realizada em um servidor especial de assinatura eletrônica (ES Server). O mesmo servidor verifica a assinatura eletrônica dos documentos recebidos do Banco da Rússia.
O ABS carrega um arquivo com os documentos de pagamento em formato próprio para o ES Server.
O servidor ES, utilizando um script conversor, converte o arquivo em mensagens eletrônicas no formato UFEBS, após o qual as mensagens eletrônicas são assinadas e transmitidas para o IBM WebSphere MQ.
A estação de trabalho KBR-N acessa o IBM WebSphere MQ e recebe mensagens de pagamento assinadas de lá, após o que um funcionário autorizado - um usuário da estação de trabalho KBR - as criptografa e as envia para o sistema de pagamento do Banco da Rússia.
Quando os pagamentos são recebidos do Banco da Rússia, o local de trabalho automatizado KBR-N os descriptografa e verifica a assinatura eletrônica. Os pagamentos processados com sucesso na forma de mensagens eletrônicas descriptografadas e assinadas no formato UFEBS são transferidos para o IBM WebSphere MQ, de onde são recebidos pelo Servidor de Assinatura Eletrônica.
O servidor de assinatura eletrônica 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 diagrama considerado com os elementos do modelo do módulo de integração:
“Servidor Exchange do lado ABS” – Servidor ABS.
“Servidor Exchange do lado AWS KBR” — estação de trabalho informática KBR.
"Mediador" – Servidor ES e IBM WebSphere MQ.
"Software de processamento de dados" – conversor de script, assinatura CIPF SCAD no ES Server.
Esquema 4. Integração do Servidor RBS e do sistema bancário central através da API fornecida por um servidor Exchange dedicado
Assumiremos que o banco utiliza vários sistemas bancários remotos (RBS):
- “Internet Client-Bank” para pessoas físicas (IKB FL);
- “Internet Client-Bank” para pessoas jurídicas (IKB LE).
Para garantir a segurança da informação, toda a interação entre o ABS e os sistemas bancários remotos é realizada através de um servidor de câmbio dedicado que opera no âmbito do sistema de informação ABS.
A seguir, consideraremos o processo de interação entre o sistema RBS do IKB LE e o ABS.
O servidor RBS, tendo recebido uma ordem de pagamento devidamente certificada do cliente, deverá criar um documento correspondente no ABS com base na mesma. Para isso, por meio da API, ele transmite as informações ao servidor exchange, que, por sua vez, insere os dados no ABS.
Quando os saldos das contas do cliente mudam, o ABS gera notificações eletrônicas, que são transmitidas ao servidor bancário remoto por meio do servidor exchange.
Correspondência dos objetos do diagrama considerado com os elementos do modelo do módulo de integração:
“Servidor Exchange do lado RBS” – Servidor RBS do IKB YUL.
“Servidor Exchange do lado ABS” – servidor de troca.
"Mediador" - ausência de.
"Software de processamento de dados" – Componentes do servidor RBS responsáveis pelo uso da API do servidor Exchange, componentes do servidor Exchange responsáveis pelo uso da API do core banking.
Ameaças à segurança de alto nível
Decomposição
U1. Injeção de informações falsas por invasores através do módulo de integração.
U1. Injeção de informações falsas por invasores através do módulo de integração
Decomposição
U1.1. Modificação não autorizada de dados legítimos quando transmitidos através de conexões de rede:
Ligação U1.1.1: .
U1.2. Transmissão de dados falsos através de canais de comunicação em nome de um participante legítimo da bolsa:
Ligação U1.1.2: .
U1.3. Modificação não autorizada de dados legítimos durante o seu processamento em Servidores Exchange ou no Intermediário:
U1.3.1. Link: .
U1.4. Criação de dados falsos nos Servidores Exchange ou Intermediário em nome de um participante legítimo da bolsa:
U1.4.1. Link:
U1.5. Modificação não autorizada de dados quando processados usando software de processamento de dados:
U1.5.1. <…> devido a invasores que fazem alterações não autorizadas nas configurações (configuração) do software de processamento de dados.
U1.5.2. <…> devido a invasores que fazem alterações não autorizadas em arquivos executáveis de software de processamento de dados.
U1.5.3. <…> devido ao controle interativo do software de processamento de dados por invasores.
MODELO TÍPICO DE AMEAÇA. SISTEMA DE PROTEÇÃO DE INFORMAÇÕES CRIPTOGRÁFICAS
Objeto de proteção ao qual o modelo de ameaça (escopo) é aplicado
O objeto da proteção é um sistema criptográfico de proteção da informação utilizado para garantir a segurança do sistema de informação.
Arquitetura
A base de qualquer sistema de informação é o software aplicativo que implementa sua funcionalidade alvo.
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 - núcleos criptográficos.
As primitivas criptográficas incluem funções criptográficas de baixo nível, como:
- criptografar/descriptografar um bloco de dados;
- criar/verificar uma assinatura eletrônica de um bloco de dados;
- calcular a função hash do bloco de dados;
- gerar/carregar/fazer upload de informações importantes;
- и т.д.
A lógica de negócios do software aplicativo implementa funcionalidades de nível superior usando primitivas criptográficas:
- criptografar o arquivo usando as chaves dos destinatários selecionados;
- estabelecer uma conexão de rede segura;
- informar sobre o resultado da verificação da assinatura eletrônica;
- e assim por diante.
A interação da lógica de negócios e do núcleo criptográfico pode ser realizada:
- diretamente, pela lógica de negócios, chamando primitivas criptográficas de bibliotecas dinâmicas do kernel criptográfico (.DLL para Windows, .SO para Linux);
- diretamente, através de interfaces criptográficas - wrappers, por exemplo, MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. Neste caso, a lógica de negócio acessa a interface criptográfica, e traduz a chamada para o núcleo criptográfico correspondente, que em este caso é chamado de provedor de criptografia. O uso de interfaces criptográficas permite que o software aplicativo abstraia algoritmos criptográficos específicos e seja mais flexível.
Existem dois esquemas típicos para organizar o núcleo criptográfico:
Esquema 1 – Núcleo criptográfico monolítico
Esquema 2 – Núcleo criptográfico dividido
Os elementos nos diagramas acima podem ser módulos de software individuais executados em um computador ou serviços de rede interagindo dentro de uma rede de computadores.
Ao utilizar sistemas construídos de acordo com o Esquema 1, o software aplicativo e o núcleo criptográfico operam dentro de um único ambiente operacional para a ferramenta criptográfica (SFC), por exemplo, no mesmo computador, executando o mesmo sistema operacional. O usuário do sistema, via de regra, pode executar outros programas, inclusive aqueles que contenham código malicioso, dentro do mesmo ambiente operacional. Sob tais condições, existe um sério risco de vazamento de chaves criptográficas privadas.
Para minimizar o risco, utiliza-se o esquema 2, no qual o crypto core é dividido em duas partes:
- A primeira parte, juntamente com o software aplicativo, opera em um ambiente não confiável onde existe risco de infecção por código malicioso. Chamaremos esta parte de “parte do software”.
- A segunda parte funciona em um ambiente confiável em um dispositivo dedicado, que contém um armazenamento de chave privada. A partir de agora chamaremos esta parte de “hardware”.
A divisão do núcleo criptográfico em partes de software e hardware é muito arbitrária. Existem no mercado sistemas construídos segundo um esquema com núcleo criptográfico dividido, mas cuja parte “hardware” se apresenta na forma de uma imagem de máquina virtual - HSM virtual ().
A interação de ambas as partes do núcleo criptográfico ocorre de tal forma que as chaves criptográficas privadas nunca são transferidas para a parte do software e, portanto, não podem ser roubadas por meio de código malicioso.
A interface de interação (API) e o conjunto de primitivas criptográficas fornecidas ao software aplicativo pelo núcleo criptográfico são os mesmos em ambos os casos. A diferença está na forma como são implementados.
Assim, ao utilizar um esquema com núcleo criptográfico dividido, a interação de software e hardware é realizada de acordo com o seguinte princípio:
- Primitivas criptográficas que não requerem o uso de chave privada (por exemplo, cálculo de função hash, verificação de assinatura eletrônica, etc.) são realizadas pelo software.
- As primitivas criptográficas que utilizam uma chave privada (criação de assinatura eletrônica, descriptografia de dados, etc.) são realizadas por hardware.
Vamos ilustrar o trabalho do crypto core dividido usando o exemplo de criação de uma assinatura eletrônica:
- A parte do software calcula a função hash dos dados assinados e transmite esse valor ao hardware através do canal de troca entre núcleos criptográficos.
- A parte de hardware, utilizando a chave privada e o hash, gera o valor da assinatura eletrônica e o transmite para a parte de software por meio de um canal de troca.
- A parte de software retorna o valor recebido ao software aplicativo.
Recursos para verificar a exatidão de uma assinatura eletrônica
Quando a parte receptora recebe dados assinados eletronicamente, deve realizar diversas etapas de verificação. Um resultado positivo na verificação de uma assinatura eletrônica só é alcançado se todas as etapas da verificação forem concluídas com êxito.
Etapa 1. Controle da integridade e autoria dos dados.
Conteúdo do palco. A assinatura eletrônica dos dados é verificada utilizando o algoritmo criptográfico apropriado. A conclusão bem-sucedida desta etapa indica que os dados não foram modificados desde o momento em que foram assinados, e também que a assinatura foi feita com uma chave privada correspondente à chave pública de verificação da assinatura eletrónica.
Localização do palco: núcleo criptográfico.
Etapa 2. Controle de confiança na chave pública do signatário e controle do prazo de validade da chave privada da assinatura eletrônica.
Conteúdo do palco. O estágio consiste em dois subestágios intermediários. A primeira é determinar se a chave pública para verificação da assinatura eletrônica era confiável no momento da assinatura dos dados. A segunda determina se a chave privada da assinatura eletrônica era válida no momento da assinatura dos dados. Em geral, os períodos de validade destas chaves podem não coincidir (por exemplo, para certificados qualificados de chaves de verificação de assinatura eletrónica). Os métodos para estabelecer confiança na chave pública do signatário são determinados pelas regras de gerenciamento eletrônico de documentos adotadas pelas partes interagentes.
Localização do palco: software aplicativo/núcleo criptográfico.
Etapa 3. Controle da autoridade do signatário.
Conteúdo do palco. De acordo com as regras estabelecidas para a gestão eletrónica de documentos, verifica-se se o signatário tinha o direito de certificar os dados protegidos. Como exemplo, tomemos uma situação de violação de autoridade. Suponha que exista uma organização onde todos os funcionários tenham uma assinatura eletrônica. O sistema interno de gerenciamento eletrônico de documentos recebe um pedido do gerente, mas assinado com a assinatura eletrônica do gerente do armazém. Consequentemente, tal documento não pode ser considerado legítimo.
Localização do palco: software aplicativo.
Suposições feitas ao descrever o objeto de proteção
- Os canais de transmissão de informações, com exceção dos canais de troca de chaves, também passam por software aplicativo, API e núcleo criptográfico.
- As informações sobre a confiança nas chaves públicas e (ou) certificados, bem como as informações sobre os poderes dos proprietários das chaves públicas, são colocadas no armazenamento de chaves públicas.
- O software aplicativo funciona com o armazenamento de chaves públicas por meio do kernel criptográfico.
Um exemplo de sistema de informação protegido por CIPF
Para ilustrar os diagramas apresentados anteriormente, vamos considerar um sistema de informação hipotético e destacar todos os elementos estruturais nele contidos.
Descrição do sistema de informação
As duas organizações decidiram introduzir entre si o gerenciamento eletrônico de documentos (EDF) juridicamente significativo. Para isso, firmaram um acordo no qual estipulavam que os documentos seriam transmitidos por e-mail, devendo ao mesmo tempo ser criptografados e assinados com assinatura eletrônica qualificada. Os programas Office do pacote Microsoft Office 2016 devem ser usados como ferramentas para criação e processamento de documentos, e o CIPF CryptoPRO e o software de criptografia CryptoARM devem ser usados como meios de proteção criptográfica.
Descrição da infraestrutura da organização 1
A Organização 1 decidiu instalar o software CIPF CryptoPRO 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 na mídia da chave ruToken, operando no modo de chave recuperável. O usuário irá preparar documentos eletrônicos localmente em seu computador, depois criptografá-los, assiná-los e enviá-los usando um cliente de e-mail instalado localmente.
Descrição da infraestrutura da organização 2
A Organização 2 decidiu migrar as funções de criptografia e assinatura eletrônica para uma máquina virtual dedicada. Neste caso, todas as operações criptográficas serão realizadas automaticamente.
Para fazer isso, duas pastas de rede são organizadas na máquina virtual dedicada: “...In”, “...Out”. Os arquivos recebidos da contraparte em formato aberto serão automaticamente colocados na pasta da rede “…In”. Esses arquivos serão descriptografados e a assinatura eletrônica será verificada.
O usuário colocará na pasta “…Out” os arquivos que precisam ser criptografados, assinados e enviados à contraparte. O próprio usuário preparará os arquivos em sua estação de trabalho.
Para executar as funções de criptografia e assinatura eletrônica, o software CIPF CryptoPRO, o software CryptoARM e um cliente de e-mail são instalados na máquina virtual. O gerenciamento automático de todos os elementos da máquina virtual será realizado por meio de scripts desenvolvidos pelos administradores do sistema. O trabalho dos scripts é registrado em arquivos de log.
As chaves criptográficas para a assinatura eletrônica serão colocadas em um token com uma chave JaCarta GOST não recuperável, que o usuário conectará ao seu computador local.
O token será encaminhado para a máquina virtual usando software USB sobre IP especializado 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 da máquina virtual dedicada na Organização 2 será sincronizado com o relógio do sistema do hipervisor, que por sua vez será sincronizado pela Internet com servidores de horário públicos.
Identificação de elementos estruturais do CIPF
Com base na descrição acima da infraestrutura de TI, iremos destacar os elementos estruturais do CIPF e escrevê-los em uma tabela.
Tabela - Correspondência dos elementos do modelo CIPF com os elementos do sistema de informação
Nome do item
Organização 1
Organização 2
Software de Aplicação
Software CryptoARM
Software CryptoARM
Parte de software do núcleo criptográfico
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardware de núcleo criptográfico
Não
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Armazenamento de chaves públicas
Estação de trabalho do usuário:
- HDD;
- armazenamento de certificados padrão do Windows.
Hipervisor:
- Disco rígido.
Máquina virtual:
- HDD;
- armazenamento de certificados padrão do Windows.
Armazenamento de chave privada
Porta-chaves ruToken operando no modo de chave recuperável
Porta-chaves JaCarta GOST operando em modo de chave não removível
Canal de troca de chave pública
Estação de trabalho do usuário:
- BATER.
Hipervisor:
- BATER.
Máquina virtual:
- BATER.
Canal de troca de chave privada
Estação de trabalho do usuário:
— Barramento USB;
- BATER.
Não
Canal de troca entre núcleos criptográficos
ausente (sem hardware criptográfico)
Estação de trabalho do usuário:
— Barramento USB;
- BATER;
— Módulo de software USB sobre IP;
- interface de rede.
Rede corporativa da organização 2.
Hipervisor:
- BATER;
- interface de rede.
Máquina virtual:
— interface de rede;
- BATER;
— Módulo de software USB sobre IP.
Canal de dados aberto
Estação de trabalho do usuário:
— meios de entrada-saída;
- BATER;
- Disco rígido.
Estação de trabalho do usuário:
— meios de entrada-saída;
- BATER;
- HDD;
- interface de rede.
Rede corporativa da organização 2.
Hipervisor:
— interface de rede;
- BATER;
- Disco rígido.
Máquina virtual:
— interface de rede;
- BATER;
- Disco rígido.
Canal seguro de troca de dados
Internet.
Rede corporativa da organização 1.
Estação de trabalho do usuário:
- HDD;
- BATER;
- interface de rede.
Internet.
Rede corporativa da organização 2.
Hipervisor:
— interface de rede;
- BATER;
- Disco rígido.
Máquina virtual:
— interface de rede;
- BATER;
- Disco rígido.
Canal de tempo
Estação de trabalho do usuário:
— meios de entrada-saída;
- BATER;
- temporizador do sistema.
Internet.
Rede corporativa da organização 2,
Hipervisor:
— interface de rede;
- BATER;
- temporizador do sistema.
Máquina virtual:
- BATER;
- temporizador do sistema.
Canal de transmissão de comando de controle
Estação de trabalho do usuário:
— meios de entrada-saída;
- BATER.
(Interface gráfica do usuário do software CryptoARM)
Máquina virtual:
- BATER;
- Disco rígido.
(Scripts de automação)
Canal para recebimento de resultados de trabalho
Estação de trabalho do usuário:
— meios de entrada-saída;
- BATER.
(Interface gráfica do usuário do software CryptoARM)
Máquina virtual:
- BATER;
- Disco rígido.
(Arquivos de log de scripts de automação)
Ameaças à segurança de alto nível
Explicações
Suposições feitas ao decompor ameaças:
- Algoritmos criptográficos fortes são usados.
- Algoritmos criptográficos são usados com segurança nos modos corretos de operação (por exemplo, não é usado para criptografar grandes volumes de dados, a carga permitida na chave é levada em consideração, etc.).
- Os invasores conhecem todos os algoritmos, protocolos e chaves públicas utilizadas.
- Os invasores podem ler todos os dados criptografados.
- Os invasores são capazes de reproduzir quaisquer elementos de software no sistema.
Decomposição
U1. Comprometimento de chaves criptográficas privadas.
U2. Criptografar dados falsos em nome do remetente legítimo.
U3. Descriptografia de dados criptografados por pessoas que não são destinatários legítimos dos dados (invasores).
U4. Criação de assinatura eletrônica de signatário legítimo com dados falsos.
U5. Obtenção de resultado positivo na verificação da assinatura eletrônica de dados falsificados.
U6. Aceitação errônea de documentos eletrônicos para execução devido a problemas na organização da gestão eletrônica de documentos.
U7. Acesso não autorizado a dados protegidos durante o seu processamento pelo CIPF.
U1. Comprometimento de chaves criptográficas privadas
U1.1. Recuperando a chave privada do armazenamento de chaves privadas.
U1.2. Obtenção de uma chave privada de objetos no ambiente operacional da ferramenta criptográfica, no qual ela pode residir temporariamente.
Explicações U1.2.
Os objetos que podem armazenar temporariamente uma chave privada incluem:
- BATER,
- arquivos temporários,
- trocar arquivos,
- arquivos de hibernação,
- arquivos de instantâneo do estado “quente” das máquinas virtuais, incluindo arquivos do conteúdo da RAM das máquinas virtuais pausadas.
U1.2.1. Extrair chaves privadas da RAM de trabalho congelando módulos de RAM, removendo-os e depois lendo os dados (ataque de congelamento).
Explicações U1.2.1.
Exemplo .
U1.3. Obtenção de uma chave privada de um canal de troca de chaves privadas.
Explicações U1.3.
Um exemplo da implementação desta ameaça será dado .
U1.4. Modificação não autorizada do núcleo criptográfico, como resultado da qual as chaves privadas se tornam conhecidas pelos invasores.
U1.5. Comprometimento de chave privada em decorrência da utilização de canais de vazamento de informações técnicas (TCIL).
Explicações U1.5.
Exemplo .
U1.6. Comprometimento de uma chave privada como resultado do uso de meios técnicos especiais (STS) projetados para recuperar informações secretamente (“bugs”).
U1.7. Comprometimento de chaves privadas durante seu armazenamento fora do CIPF.
Explicações U1.7.
Por exemplo, um usuário armazena suas principais mídias em uma gaveta da área de trabalho, de onde elas podem ser facilmente recuperadas por invasores.
U2. Criptografando dados falsos em nome de um remetente legítimo
Explicações
Esta ameaça é considerada apenas para esquemas de criptografia de dados com autenticação de remetente. Exemplos de tais esquemas são indicados nas recomendações de padronização . Para outros esquemas criptográficos, esta ameaça não existe, uma vez que a criptografia é realizada nas chaves públicas do destinatário e geralmente são conhecidas pelos invasores.
Decomposição
U2.1. Comprometer a chave privada do remetente:
U2.1.1. Link: .
U2.2. Substituição de dados de entrada em um canal aberto de troca de dados.
Notas U2.2.
Exemplos da implementação desta ameaça são apresentados abaixo. и .
U3. Descriptografia de dados criptografados por pessoas que não são destinatários legítimos dos dados (invasores)
Decomposição
U3.1. Comprometimento das chaves privadas do destinatário dos dados criptografados.
Ligação U3.1.1: .
U3.2. Substituição de dados criptografados em um canal seguro de troca de dados.
U4. Criação de uma assinatura eletrônica de um signatário legítimo com dados falsos
Decomposição
U4.1. Comprometimento das chaves privadas da assinatura eletrônica de um signatário legítimo.
Ligação U4.1.1: .
U4.2. Substituição de dados assinados em um canal aberto de troca de dados.
Nota U4.2.
Exemplos da implementação desta ameaça são apresentados abaixo. и .
U5. Obtenção de resultado positivo na verificação da assinatura eletrônica de dados falsificados
Decomposição
U5.1. Os invasores interceptam uma mensagem no canal de transmissão de resultados de trabalho sobre resultado negativo de verificação de assinatura eletrônica e a substituem por uma mensagem com resultado positivo.
U5.2. Os invasores atacam a confiança na assinatura de certificados (SCRIPT - todos os elementos são obrigatórios):
U5.2.1. Os invasores geram uma chave pública e privada para uma assinatura eletrônica. Se o sistema utilizar certificados de chave de assinatura eletrônica, eles geram um certificado de assinatura eletrônica que é o mais semelhante possível ao certificado do remetente pretendido dos dados cuja mensagem desejam falsificar.
U5.2.2. Os invasores fazem alterações não autorizadas no armazenamento de chaves públicas, fornecendo à chave pública que geram 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 inserem no canal seguro de troca de dados.
U5.3. Os invasores realizam um ataque usando chaves de assinatura eletrônica expiradas de um signatário legal (SCRIPT - todos os elementos são obrigatórios):
U5.3.1. Os invasores comprometem chaves privadas expiradas (atualmente não válidas) da assinatura eletrônica de um remetente legítimo.
U5.3.2. Os invasores substituem a hora no canal de transmissão pela hora em que as chaves comprometidas ainda eram válidas.
U5.3.3. Os invasores assinam dados falsos com uma chave de assinatura eletrônica previamente comprometida e os injetam no canal seguro de troca de dados.
U5.4. Os invasores realizam um ataque usando chaves de assinatura eletrônica comprometidas de um signatário legal (SCRIPT - todos os elementos são obrigatórios):
U5.4.1. O invasor faz uma cópia do armazenamento de chaves públicas.
U5.4.2. Os invasores comprometem as chaves privadas de um dos remetentes legítimos. Ele percebe o comprometimento, revoga as chaves e as 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 previamente copiado.
U5.4.4. Os invasores assinam dados falsos 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 da 2ª e 3ª etapas de verificação de assinatura eletrônica:
Explicações U5.5.
Um exemplo da implementação desta ameaça é dado .
U5.5.1. Verificar a confiança em um certificado de chave de assinatura eletrônica apenas pela presença de confiança no certificado com o qual está assinado, sem verificações de CRL ou OCSP.
Explicações U5.5.1.
Exemplo de implementação .
U5.5.2. Ao construir uma cadeia de confiança para um certificado, as autoridades emissoras de certificados não são analisadas
Explicações U5.5.2.
Um exemplo de ataque contra certificados SSL/TLS.
Os invasores compraram um certificado legítimo para seu e-mail. Eles então criaram um certificado de site fraudulento e o assinaram com seu certificado. Se as credenciais não forem verificadas, ao verificar a cadeia de confiança ela estará correta e, consequentemente, o certificado fraudulento também estará correto.
U5.5.3. Ao construir uma cadeia confiável de certificados, os certificados intermediários não são verificados quanto à revogação.
U5.5.4. As CRLs são atualizadas com menos frequência do que são emitidas pela autoridade de certificação.
U5.5.5. A decisão de confiar em uma assinatura eletrônica é tomada antes do recebimento de uma resposta OCSP sobre o status do certificado, enviada em uma solicitação feita posteriormente ao momento em que a assinatura foi gerada ou antes da próxima CRL após a geração da assinatura.
Explicações U5.5.5.
Nos regulamentos da maioria das CAs, o momento da revogação do certificado é considerado o momento da emissão da LCR mais próxima contendo informações sobre a revogação do certificado.
U5.5.6. Ao receber dados assinados, o certificado pertencente ao remetente não é verificado.
Explicações U5.5.6.
Exemplo de ataque. Em relação aos certificados SSL: a correspondência do endereço do servidor chamado com o valor do campo CN do certificado não pode ser verificada.
Exemplo de ataque. Os invasores comprometeram as chaves de assinatura eletrônica de um dos participantes do sistema de pagamento. Depois disso, invadiram a rede de outro participante e, em seu nome, enviaram documentos de pagamento assinados com chaves comprometidas para o servidor de liquidação do sistema de pagamento. Se o servidor apenas analisar a confiança e não verificar a conformidade, os documentos fraudulentos serão considerados legítimos.
U6. Aceitação errônea de documentos eletrônicos para execução devido a problemas na organização da gestão eletrônica de documentos.
Decomposição
U6.1. A parte receptora não detecta duplicação dos documentos recebidos.
Explicações U6.1.
Exemplo de ataque. Os invasores podem interceptar um documento transmitido a um destinatário, mesmo que esteja protegido criptograficamente, e depois enviá-lo repetidamente por um 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 documentos diferentes.
U7. Acesso não autorizado a dados protegidos durante o seu processamento pelo CIPF
Decomposição
U7.1. <…> devido ao vazamento de informações através de canais laterais (ataque de canal lateral).
Explicações U7.1.
Exemplo .
U7.2. <…> devido à neutralização da proteção contra acesso não autorizado às informações processadas no CIPF:
U7.2.1. Operação do CIPF em desacordo com os requisitos descritos na documentação do CIPF.
U7.2.2. <…>, realizado devido à presença de vulnerabilidades em:
U7.2.2.1. <…> meios de proteção contra acesso não autorizado.
U7.2.2.2. <…> CIPF em si.
U7.2.2.3. <…> o ambiente operacional da ferramenta criptográfica.
Exemplos de ataque
Os cenários discutidos abaixo obviamente contêm erros de segurança da informação e servem apenas para ilustrar possíveis ataques.
Cenário 1. Um exemplo de implementação das ameaças U2.2 e U4.2.
Descrição do objeto
O software AWS KBR e a assinatura CIPF SCAD são instalados em um computador físico que não está conectado à rede de computadores. FKN vdToken é usado como portador de chave no modo de trabalhar com uma chave não removível.
Os regulamentos de liquidação pressupõem que o especialista em liquidação de seu computador de trabalho baixe mensagens eletrônicas em texto não criptografado (esquema da antiga estação de trabalho KBR) de um servidor de arquivos seguro especial, depois as grave em uma unidade flash USB transferível e as transfira para a estação de trabalho KBR, onde eles são criptografados e assinados. Depois disso, o especialista transfere mensagens eletrônicas seguras para o meio alienado e, em seguida, por meio de seu computador de trabalho, as grava em um servidor de arquivos, de onde vão para a UTA e depois para o sistema de pagamento do Banco da Rússia.
Nesse caso, os canais de troca de dados abertos e protegidos incluirão: servidor de arquivos, computador de trabalho de especialista e mídia alienada.
Ataque
Atacantes não autorizados instalam um sistema de controle remoto no computador de trabalho de um especialista e, no momento de redigir ordens de pagamento (mensagens eletrônicas) em um meio transferível, substituem o conteúdo de uma delas por texto não criptografado. O especialista transfere as ordens de pagamento para o local de trabalho automatizado da KBR, assina-as e criptografa-as sem perceber a substituição (por exemplo, devido a um grande número de ordens de pagamento em um voo, cansaço, etc.). Depois disso, a ordem de pagamento falsa, tendo passado pela cadeia tecnológica, entra no sistema de pagamento do Banco da Rússia.
Cenário 2. Um exemplo de implementação das ameaças U2.2 e U4.2.
Descrição do objeto
Um computador com uma estação de trabalho KBR instalada, SCAD Signature e um porta-chaves conectado FKN vdToken opera em uma sala dedicada sem acesso do pessoal.
O especialista em cálculo conecta-se à estação de trabalho CBD em modo de acesso remoto através do protocolo RDP.
Ataque
Os invasores interceptam os detalhes, com os quais o especialista em cálculo se conecta e trabalha com a estação de trabalho CBD (por exemplo, por meio de código malicioso em seu computador). Em seguida, eles se conectam em seu nome e enviam uma ordem de pagamento falsa ao sistema de pagamento do Banco da Rússia.
Cenário 3. Exemplo de implementação de ameaças U1.3.
Descrição do objeto
Consideremos uma das opções hipotéticas para implementação dos módulos de integração ABS-KBR para um novo esquema (AWS KBR-N), em que a assinatura eletrônica dos documentos de saída ocorre do lado do ABS. Neste caso, assumiremos que o ABS opera com base em um sistema operacional que não é suportado pela assinatura CIPF SKAD e, consequentemente, a funcionalidade criptográfica é transferida para uma máquina virtual separada - a integração “ABS-KBR” módulo.
Um token USB normal operando no modo de chave recuperável é usado como porta-chaves. Ao conectar a mídia principal ao hipervisor, descobriu-se que não havia portas USB livres no sistema, então foi decidido conectar o token USB por meio de um hub USB de rede e instalar um cliente USB sobre IP no virtual máquina, que se comunicaria 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 texto não criptografado). De posse da chave privada, os invasores geraram uma ordem de pagamento falsa, assinaram-na com assinatura eletrônica e enviaram-na ao local de trabalho automatizado KBR-N para execução.
Cenário 4. Um exemplo de implementação de ameaças U5.5.
Descrição do objeto
Vamos considerar o mesmo circuito do cenário anterior. Assumiremos que as mensagens eletrônicas provenientes da estação de trabalho KBR-N terminam na pasta…SHAREIn, e aquelas enviadas para a estação de trabalho KBR-N e posteriormente para o sistema de pagamento do Banco da Rússia vão para…SHAREout.
Assumiremos também que na implementação do módulo de integração, as listas de revogação de certificados sejam atualizadas apenas quando as chaves criptográficas forem reemitidas, e também que as mensagens eletrônicas recebidas na pasta…SHAREIn sejam verificadas apenas quanto ao controle de integridade e controle de confiança na chave pública da assinatura eletrônica.
Ataque
Os invasores, utilizando as chaves roubadas no cenário anterior, assinaram uma ordem de pagamento falsa contendo informações sobre o recebimento de dinheiro na conta do cliente fraudulento e a introduziram no canal seguro de troca de dados. Como não há verificação de que a ordem de pagamento foi assinada pelo Banco da Rússia, ela é aceita para execução.
Fonte: habr.com