Sécurité de l'information des paiements bancaires sans espèces. Partie 7 - Modèle de menace de base



Sur quoi porte l'étude

Cet article présente un modèle de base des menaces à la sécurité des informations sur les virements bancaires effectués via le système de paiement de la Banque de Russie.

Les menaces présentées ici sont vraies pour presque toutes les banques de la Fédération de Russie, ainsi que pour toute autre organisation qui utilise des clients lourds pour effectuer des paiements avec confirmation cryptographique des paiements.

Ce modèle de menace est destiné à assurer la sécurité pratique et la formation de la documentation interne des banques conformément aux exigences des règlements de la Banque de Russie n ° 552-P du 24 août 2016 et n ° 382-P du 9 juin 2012.
L'utilisation d'informations provenant d'un article à des fins illégales est punie par la loi .



Technique de modélisation


Structure du modèle de menace


L'une des méthodes les plus efficaces pour modéliser les attaques informatiques aujourd'hui est la chaîne Kill . Cette méthode représente une attaque informatique comme une séquence d'étapes effectuées par des attaquants pour atteindre leurs objectifs.

La plupart des étapes sont décrites dans MITRE ATT & CK Matrix , mais il n'y a pas de décodage des actions finales - «Actions» (la dernière étape de la chaîne Kill), pour lesquelles les attaquants ont mené l'attaque et qui, en substance, sont des vols d'argent à la banque. Un autre problème lié à l'utilisation de la chaîne Kill classique pour la modélisation des menaces est le manque de description des menaces associées à l'accessibilité.

Ce modèle de menace est conçu pour compenser ces lacunes. Pour cela, il se composera formellement de deux parties:

  • Le premier décrira les problèmes d'accessibilité.
  • La seconde, qui est une chaîne Kill classique avec la dernière étape décryptée, décrira le vol "informatique" d'argent de la banque.



Méthodologie de création d'un modèle de menace


Les principales exigences du modèle de menace créé étaient les suivantes:

  • maintenir la compacité et minimiser les doublons,
  • exhaustivité de l'identification des menaces et facilité de perfectionnement du modèle,
  • offrant la possibilité de travailler avec le modèle pour les professionnels et les techniciens.

Pour mettre en œuvre l'ensemble des tâches, le modèle a été construit sur la base de la méthodologie de «l'arbre des menaces» , dans laquelle des améliorations mineures ont été apportées:

  1. Les menaces ont été décrites, à partir du niveau de l'entreprise, et progressivement décomposées en composants techniques.
  2. Les menaces inhérentes à des éléments typiques de l'infrastructure d'information (par exemple, les connexions réseau, les systèmes de protection des informations cryptographiques, ...) ont été regroupées en modèles de menaces standard.
  3. De plus, lors de la modélisation des menaces inhérentes à des éléments typiques de l'infrastructure d'information, au lieu de reproduire la description des menaces, une référence a été faite au modèle standard correspondant.

La procédure pour appliquer ce modèle de menace à des objets réels


L'application de ce modèle de menace aux objets réels devrait commencer par clarifier la description de l'infrastructure d'information, puis, si nécessaire, procéder à une décomposition plus détaillée des menaces.

La procédure de mise à jour des menaces décrites dans le modèle doit être effectuée conformément aux documents internes de l'organisation. En l'absence de tels documents, ils peuvent être développés sur la base des techniques discutées dans l' article de recherche précédent .

Caractéristiques de conception du modèle de menace


Dans ce modèle de menace, les règles d'apurement suivantes sont adoptées:

  1. Le modèle de menace est un arbre de menace. L'arbre des menaces est écrit sous la forme d'une liste hiérarchique, où chaque élément de la liste correspond à un nœud d'arbre et, par conséquent, à une menace spécifique.
  2. Le nom de la menace commence par l'identifiant de la menace, qui a la forme:

    U <Code de menace>

    où «Y» est l'abréviation de la menace, «Threat Code» est le numéro de la menace dans la liste hiérarchique (arbre des menaces).
  3. La description de la menace peut contenir deux blocs:
    • Les explications fournissent des explications sur la menace décrite. Des exemples de réalisation de menace, une explication des décisions prises pendant la décomposition, des restrictions de modélisation et d'autres informations peuvent être donnés ici.
    • La décomposition contient une liste hiérarchique des menaces enfants.

  4. Lors de la décomposition des menaces, par défaut, il est considéré que la mise en œuvre d'au moins une menace enfant conduit à la mise en œuvre de la menace parent. Si l'implémentation de la menace parent dépend de l'implémentation des menaces enfant d'une autre manière, alors lors de la décomposition à la fin de la ligne décrivant l'élément parent, le type de dépendance est indiqué:

    • ( I ) - la mise en œuvre de la menace parentale ne se produit qu'avec la mise en œuvre de toutes les menaces enfants.
    • ( Scénario ) - la mise en œuvre de la menace parentale se produit avec un scénario ou un algorithme spécifique pour la mise en œuvre des menaces enfants.

  5. Les liens vers les menaces décrites dans le même modèle ou dans d'autres modèles de menace sont établis selon le modèle: Lien: "<Nom du modèle de menace>. <Nom de la menace> ".
  6. Si le nom de la menace enfant commence par <...>, cela signifie que lors de la lecture, au lieu de <...>, vous devez insérer complètement le nom de la menace parent.

Le modèle de base des menaces à la sécurité de l'information des paiements bancaires sans espèces


Objet de protection pour lequel le modèle de menace est appliqué (étendue)


La portée de ce modèle de menace s'étend au processus de transfert de fonds sans espèces via le système de paiement de la Banque de Russie.

L'architecture
La gamme du modèle comprend l'infrastructure d'information suivante:



Ici:

«Section du système de paiement de la Banque de Russie (PS BR)» - une section de l'infrastructure d'information soumise aux exigences du règlement de la Banque de Russie du 24 août 2016 n ° 552-P. Le critère de classification de l'infrastructure d'information en tant que partie du poste BR est le traitement des messages électroniques au format UFEBS dans les installations d' infrastructure d'information.

Un "canal de transfert de messages électroniques" comprend un canal de communication de la banque avec la Banque centrale de la Fédération de Russie, construit par un opérateur de télécommunications spécialisé ou une connexion par modem, ainsi qu'un mécanisme de messagerie électronique qui fonctionne à l'aide d'un service de messagerie et de supports de stockage informatiques jetables (OMNI).

La liste des locaux inclus dans la zone de couverture du modèle de menace est déterminée par le critère de présence des infrastructures d’information impliquées dans le transfert de fonds.

Limitations du modèle
Ce modèle de menace s'étend uniquement à la possibilité d'organiser une infrastructure de paiement avec KBR AWP , combinant des fonctions de chiffrement et de signature électronique, et ne considère pas l'utilisation de KBR-N AWP , où la signature électronique est effectuée «du côté de l'ABS».

Menaces de sécurité de niveau supérieur


Décomposition

U1. Résiliation du système de virements sans numéraire.
U2. Vol de fonds pendant le fonctionnement du système de transferts sans numéraire.

U1. Résiliation du système de transfert sans numéraire


Explications

Les dommages potentiels liés à la mise en œuvre de cette menace peuvent être évalués sur la base des hypothèses suivantes:

  • Dans les accords de gestion de comptes bancaires conclus entre les clients et la banque, en règle générale, il y a une marque sur la durée pendant laquelle la banque est tenue d'effectuer le paiement. La violation des conditions spécifiées dans le contrat entraînera la responsabilité de la banque envers le client.
  • Si la banque cesse soudainement d'effectuer des paiements, cela soulèvera des questions sur sa stabilité financière et, par conséquent, peut provoquer une sortie massive de dépôts.
  • La continuité des paiements est l'une des conditions du maintien d'une licence bancaire. Les défaillances et dysfonctionnements systématiques peuvent soulever de sérieuses questions pour la banque auprès de la Banque centrale de la Fédération de Russie et conduire à la révocation de l'agrément.

Dans le cas général, le retard maximum autorisé dans l'exécution du paiement peut être considéré comme un vol par jour opérationnel. Une nouvelle augmentation du retard entraînera de plus en plus de dommages à la banque.

Lors de la décomposition de cette menace, les documents suivants ont été pris en compte:


Décomposition

U1.1. Problèmes avec l'équipement ou les supports de stockage utilisés pour la traduction:
U1.1.1. Échecs et échecs.
U1.1.2. Le vol
U1.1.3. Perte.
U1.2. Destruction des programmes ou des données nécessaires pour effectuer des transferts.
U1.3. Attaques par déni de service (DoS, DDoS) par des moyens techniques et des canaux de communication utilisés pour effectuer des transferts par des cybercriminels.
U1.4. Incapacité à échanger des messages électroniques avec le système de paiement de la Banque centrale de la Fédération de Russie ( I ):
U1.4.1. <...> via des connexions réseau:
U1.4.1.1. Inopérabilité des canaux de communication avec la Banque centrale de la Fédération de Russie ( I ):
U1.4.1.1.1. <...> assuré par un opérateur télécom spécialisé.
U1.4.1.1.2. <...> organisé comme une connexion modem.
U1.4.1.2. Résiliation des informations utilisées pour authentifier une connexion réseau avec la Banque centrale de la Fédération de Russie.
U1.4.2. <...>, réalisée avec l'aide d'un coursier sur des supports de données machine aliénés (OMNI):
U1.4.2.1. Manque de documents correctement exécutés:
U1.4.2.1.1 <...>, confirmant l'autorité du courrier.
U1.4.2.1.2 <...> paiements d'accompagnement à l'OMNI.
U1.5. Résiliation des clés cryptographiques utilisées pour protéger les messages électroniques:
U1.5.1. Expiration des clés cryptographiques.
U1.5.2. Compromis de clés cryptographiques.
U1.5.3. La provocation par des attaquants du centre de certification de la Banque centrale de la Fédération de Russie pour bloquer l'action des clés cryptographiques de la banque.
U1.6. Manque de personnes impliquées dans la mise en œuvre des paiements sans numéraire sur le lieu de travail.
U1.7. Utilisation de versions obsolètes du logiciel utilisé pour effectuer des virements électroniques.
U1.8. Survenance dans les locaux de conditions dans lesquelles le fonctionnement normal des équipements techniques, des canaux de communication et du personnel impliqué dans les transferts est impossible:
U1.8.1. Manque de puissance.
U1.8.2. Violations importantes du régime de température (surchauffe, hypothermie).
U1.8.3. Le feu.
U1.8.4. Inondation de la pièce.
U1.8.5. Effondrement ou menace d'effondrement de locaux.
U1.8.6. Attaque armée.
U1.8.7. Contamination radioactive ou chimique.
U1.8.8. Forte interférence électromagnétique.
U1.8.9. Épidémies.
U1.9. Résiliation administrative de l'accès aux bâtiments ou locaux dans lesquels se trouve l'infrastructure d'information utilisée pour effectuer les paiements:
U1.9.1. Bloquer l'accès des autorités:
U1.9.1.1. Effectuer des perquisitions ou d'autres mesures d'enquête opérationnelles.
U1.9.1.2. Organiser des événements culturels, des fêtes religieuses, etc.
U1.9.2. Bloquer l'accès du propriétaire:
U1.9.2.1. Conflit d'entités commerciales.
U1.10. Circonstances de force majeure (catastrophes naturelles, catastrophes, émeutes, attaques terroristes, opérations militaires, apocalypse zombie, ...).

U2. Vol de fonds pendant le fonctionnement du système de transfert sans numéraire


Explications

Le vol de fonds pendant le fonctionnement du système de transfert sans numéraire est le vol de fonds non monétaires avec leur retrait ultérieur ou simultané de la banque victime.

Le vol de fonds non monétaires est une modification non autorisée du solde du client ou du compte bancaire. Ces changements peuvent survenir à la suite de:

  • les modifications éventuelles du solde du compte;
  • virement interbancaire ou interbancaire non autorisé.

Un changement anormal du solde du compte sera appelé actions qui ne sont pas réglementées par la documentation interne de la banque, ce qui a entraîné une diminution ou une augmentation non autorisée du solde du compte bancaire. Des exemples de telles actions peuvent être: la réalisation d'une transaction bancaire fictive, la modification directe du solde sur le lieu de stockage (par exemple, dans la base de données) et d'autres actions.

Un changement anormal du solde du compte s'accompagne généralement d'opérations régulières sur la dépense des fonds volés. Ces opérations comprennent:

  • retrait d'espèces aux distributeurs automatiques de la banque victime,
  • les transferts d'argent vers des comptes ouverts auprès d'autres banques,
  • achats en ligne
  • etc.

Un transfert de fonds non autorisé est un transfert effectué sans le consentement de personnes autorisées à disposer des fonds et, en règle générale, commises par la banque exécutant un faux ordre de transfert de fonds.

De faux ordres de virement peuvent être générés à la fois par la faute des clients et par la faute de la banque. Dans ce modèle de menace, seules les menaces dans la zone de responsabilité de la banque seront prises en compte. Dans ce modèle, seuls les ordres de paiement seront considérés comme des ordres de virement .

Dans le cas général, on peut considérer que le traitement des virements intra-bancaires par une banque est un cas particulier du traitement des virements interbancaires, donc, pour préserver la compacité du modèle, seuls les virements interbancaires seront considérés ci-dessous.

Le vol de fonds sans numéraire peut être effectué à la fois lors de l'exécution des ordres de paiement sortants et lors de l'exécution des ordres de paiement entrants. Dans ce cas, l'ordre de paiement sortant sera appelé l'ordre de paiement envoyé par la banque au système de paiement de la Banque de Russie, et l'entrée sera appelée l'ordre de paiement reçu par la banque du système de paiement de la Banque de Russie.

Décomposition

U2.1. Exécution bancaire de faux ordres de paiement sortants.
U2.2. Exécution bancaire de faux ordres de paiement entrants.
U2.3. Variation anormale des soldes des comptes.

U2.1. Exécution bancaire de faux ordres de paiement sortants


Explications

La principale raison pour laquelle une banque peut exécuter un faux ordre de paiement est son introduction par des criminels dans le processus opérationnel de traitement des paiements.

Décomposition

U2.1.1. Intrus injectant un faux ordre de paiement sortant dans le processus commercial de traitement des paiements.

U2.1.1. Intrus introduisant un faux ordre de paiement sortant dans le processus opérationnel de traitement des paiements


Explications

Cette menace sera décomposée en fonction des éléments de l'infrastructure d'information dans lesquels l'introduction d'un faux ordre de paiement peut se produire.
ArticlesDécomposition de la menace "2.1.1. Intrus introduisant un faux ordre de paiement sortant dans le processus opérationnel de traitement des paiements »
Opérateur bancaireU2.1.1.1.
Serveur RBSU2.1.1.2.
Module d'intégration DBO-ABSU2.1.1.3.
ABSU2.1.1.4.
Module d'intégration ABS-CBDU2.1.1.5.
AWP CBDU2.1.1.6.
Module d'intégration CBD-UTAU2.1.1.7.
UTAU2.1.1.8.
Canal de messagerieU2.1.1.9.

Décomposition

U2.1.1.1. <...> dans l'élément "Opérateur bancaire".
U2.1.1.2. <...> dans l'élément "RBS Server".
U2.1.1.3. <...> dans l'élément "Module d'intégration DBO-ABS".
U2.1.1.4. <...> dans l'élément ABS.
U2.1.1.5. <...> dans l'élément "Module d'intégration ABS-CBD".
Y2.1.1.6. <...> dans l'élément "AWP KBR".
U2.1.1.7. <...> dans l'élément "CBD-UTA Integration Module".
U2.1.1.8. <...> dans l'élément UTA.
U2.1.1.9. <...> dans l'élément "Canal de messagerie électronique".

U2.1.1.1. <...> dans l'élément "Opérateur bancaire"


Explications

Lors de l'acceptation d'un ordre de paiement papier du client, l'opérateur saisit sur sa base un document électronique dans l'ABS. La grande majorité des ABS modernes sont basés sur une architecture client-serveur, ce qui permet d'analyser cette menace sur la base d'un modèle de menace typique des systèmes d'information client-serveur.

Décomposition

U2.1.1.1.1. L'opératrice bancaire a accepté de la part de l'attaquant, qui s'est présenté comme un client de la banque, un faux ordre de paiement sur papier.
U2.1.1.1.2. Au nom de l'opérateur de la banque, un faux ordre de paiement électronique a été soumis à l'ABS.
U2.1.1.1.2.1. Le greffier a agi avec malveillance ou a commis une erreur involontaire.
U2.1.1.1.2.2. Au nom de l'opérateur, les assaillants ont agi:
U2.1.1.1.2.2.1. Lien: «Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur. U1. Perpétration d'actions non autorisées par des criminels au nom d'un utilisateur légitime . »

Remarque Les modèles de menaces typiques seront abordés dans les articles suivants.

U2.1.1.2. <...> dans l'élément "RBS Server"


Décomposition

U2.1.1.2.1. Le serveur RBS a accepté au nom du client un ordre de paiement dûment certifié, mais établi par des attaquants sans le consentement du client:
U2.1.1.2.1.1. Lien: «Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur. U1. Perpétration d'actions non autorisées par des criminels au nom d'un utilisateur légitime . »
U2.1.1.2.2. Les attaquants ont introduit un faux ordre de paiement sur le serveur RBS:
U2.1.1.2.2.1. Lien: «Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur. U2. "Modification non autorisée des informations protégées lors de leur traitement par la partie serveur du système d'information . "

U2.1.1.3. <...> dans l'élément "Module d'intégration DBO-ABS"


Décomposition

U2.1.1.3.1. Lien: «Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.1.1.4. <...> dans l'élément ABS


Décomposition

U2.1.1.4.1. Lien: «Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur. U2. "Modification non autorisée des informations protégées lors de leur traitement par la partie serveur du système d'information . "

U2.1.1.5. <...> dans l'élément "Module d'intégration ABS-CBD"


Décomposition

U2.1.1.5.1. Lien: «Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.1.1.6. <...> dans l'élément "AWS KBR"


Explications

La fonction principale du CBD AWP en termes de sécurité de l'information est la protection cryptographique des messages électroniques échangés par la banque avec le système de paiement de la Banque de Russie. Tous les documents de paiement sortants sont cryptés sur les clés publiques de la Banque de Russie et les clés privées de la signature électronique de la banque.

Décomposition (I):

U2.1.1.6.1. Cryptage d'un faux ordre de paiement sur les clés publiques de la Banque de Russie:
U2.1.1.6.1.1. Lien: «Un modèle de menace typique. Système de sécurité des informations cryptographiques. U2. Chiffrez les données frauduleuses au nom d'un expéditeur légitime . "
U2.1.1.6.2. Signature électronique d'un faux ordre de paiement sur les clés privées de la banque:
2.1.1.6.2.1. Lien:«Un modèle de menace typique. Système de sécurité des informations cryptographiques. U4. Création d'une signature électronique d'un signataire légitime sous de fausses données . »

U2.1.1.7. <...> dans l'élément "CBD-UTA Integration Module"


Explications

Conformément au processus technologique de traitement des paiements, les messages électroniques sur la section poste de travail du CBD - CBR sont signés et cryptés électroniquement. En conséquence, l'introduction d'un faux ordre de paiement à ce stade n'est possible que si les attaquants ont réussi à chiffrer et à signer un faux ordre de paiement en contournant la procédure de protection cryptographique standard.

Décomposition (I):

U2.1.1.7.1. Lien: «Le modèle de menace actuel. U2.1.1.6. <...> dans l'élément "AWS KBR" .
U2.1.1.7.2. Lien: «Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.1.1.8. <...> dans l'élément UTA


Explications

UTA est, en fait, un robot d'information qui échange des messages électroniques protégés par cryptographie avec la Banque centrale de la Fédération de Russie. Les menaces à la sécurité de l'information de cet élément correspondent aux menaces des modules d'intégration.

Décomposition (I):

U2.1.1.8.1. Lien: «Le modèle de menace actuel. U2.1.1.6. <...> dans l'élément "AWS KBR" .
U2.1.1.8.2. Lien: «Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.1.1.9. <...> dans l'élément "Canal de messagerie électronique"


Décomposition (I):

U2.1.1.9.1. Lien: «Le modèle de menace actuel. U2.1.1.6. <...> dans l'élément "AWS KBR" .
U2.1.1.9.2. Transfert par les attaquants d'un faux ordre de paiement à la Banque de Russie:
2.1.1.9.2.1. <...> lors d'une session de communication avec la Banque de Russie établie au nom de la banque.
U2.1.1.9.2.2. <...> en utilisant le courrier à OMNI.

U2.2. Exécution bancaire d'un faux ordre de paiement entrant


Décomposition

U2.2.1. Intrus injectant un faux ordre de paiement entrant dans le processus commercial de traitement des paiements.

U2.2.1. Intrus introduisant un faux ordre de paiement entrant dans le processus opérationnel de traitement des paiements


Explications

Dans la section AWP KBR - Système de paiement de la Banque de Russie, les ordres de paiement sont cryptés et signés électroniquement. Dans la section AWP KBR - ABS, les ordres de paiement ne sont généralement pas protégés par cryptographie.

Les ordres de paiement reçus par la banque sont cryptés sur les clés publiques de la banque et signés par les clés privées de la Banque de Russie. Le système de protection cryptographique des clés est basé sur une infrastructure à clé publique privée (PKI privée) mise en œuvre sur la base de la signature SKAD SCAD et comprend: un centre de certification de la Banque de Russie et des utilisateurs - des organismes de crédit. Tous les participants à l'infrastructure à clé publique font confiance aux certificats délivrés par le centre de certification de la Banque centrale de la Fédération de Russie.

Ainsi, afin d'introduire un faux ordre de paiement entrant, les attaquants doivent compromettre les clés de chiffrement publiques et les clés de signature électronique du destinataire, dont les certificats sont approuvés par la banque destinataire.

Cette menace sera décomposée sur la base des éléments d'infrastructure dans lesquels l'introduction de faux ordres de paiement entrants peut se produire
ArticlesDécomposition de la menace "U2.2.1. Intrus introduisant un faux ordre de paiement entrant dans le processus opérationnel de traitement des paiements »
ABSU2.2.1.1.
Module d'intégration ABS-CBDU2.2.1.2.
AWP CBDU2.2.1.3.
Module d'intégration CBD-UTAU2.2.1.4.
UTAU2.2.1.5.
Canal de messagerieU2.2.1.6.

Décomposition

U2.2.1.1. <...> dans l'élément ABS.
U2.2.1.2. <...> dans l'élément "Module d'intégration ABS-CBD".
Y2.2.1.3. <...> dans l'élément "AWP KBR".
U2.2.1.4. <...> dans l'élément "CBD-UTA Integration Module".
U2.2.1.5. <...> dans l'élément UTA.
U2.2.1.6. <...> dans l'élément "Canal de messagerie électronique".

U2.2.1.1. <...> dans l'élément ABS


Décomposition

U2.2.1.1.1. Lien: «Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur. U2. "Modification non autorisée des informations protégées lors de leur traitement par la partie serveur du système d'information . "

U2.2.1.2. <...> dans l'élément "Module d'intégration ABS-CBD"


Décomposition

U2.2.1.2.1. Lien: «Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.2.1.3. <...> dans l'élément "AWS KBR"


Explications

Lors du traitement des documents de paiement entrants, le KBR AWP est la dernière ligne de défense dont la tâche est de décrypter et de vérifier l'intégrité des messages électroniques entrants protégés par cryptographie. La protection de cette étape sera neutralisée si le KBR AWP, ayant reçu un faux ordre de paiement, vous informe que la signature électronique en dessous est correcte.

Décomposition

U2.2.1.3.1. Vérification réussie de la signature électronique d'un faux ordre de paiement entrant:
U2.2.1.3.1.1 Lien: «Modèle de menace typique. Système de sécurité des informations cryptographiques. U5. Obtenir un résultat positif de la vérification de la signature électronique des fausses données . "

U2.2.1.4. <...> dans l'élément "CBD-UTA Integration Module"


Explications

À partir de cet élément et jusqu'au système de paiement de la Banque de Russie, les attaquants perdent la possibilité d'influence non autorisée sur le système de protection des informations cryptographiques (CIP), donc toutes les données provenant du module d'intégration dans l'AWS du CBD doivent être correctement cryptées et signées. Pour le chiffrement, les attaquants doivent utiliser les clés publiques de la banque et les clés privées de signature électronique, dont les certificats font confiance à la banque.

Décomposition (I):

U2.2.1.4.1. Neutralisation de la protection cryptographique des messages électroniques entrants ( I ):
U2.2.1.4.1.1. Cryptage d'un faux ordre de paiement sur les clés publiques de la banque:
U2.2.1.4.1.1.1. Lien: «Un modèle de menace typique. Système de sécurité des informations cryptographiques. U2. Chiffrez les données frauduleuses au nom d'un expéditeur légitime . "
U2.2.1.4.1.2. Signature électronique d'un faux ordre de paiement sur clés privées, certificats dont la banque fait confiance:
U2.2.1.4.1.2.1. Lien: «Un modèle de menace typique. Système de sécurité des informations cryptographiques. U4. Création d'une signature électronique d'un signataire légitime sous de fausses données . »
U2.2.1.4.2. Lien:«Un modèle de menace typique. Module d'intégration. U1. Les intrus introduisent de fausses informations via le module d'intégration . »

U2.2.1.5. <...> dans l'élément UTA


Décomposition:

U2.2.1.5.1. Lien: «Le modèle de menace actuel. U2.2.1.4. <...> dans l'élément "CBD-UTA Integration Module" .

U2.2.1.6. <...> dans l'élément "Canal de messagerie électronique"


Décomposition (I):

U2.2.1.6.1. Lien: «Le modèle de menace actuel. U.2.2.1.4.1. La neutralisation de la protection cryptographique des messages électroniques entrants . "
U2.2.1.6.2. Réception d'un faux ordre de paiement de la Banque centrale de la Fédération de Russie:
U2.2.1.6.2.1. <...> lors d'une session de communication avec la Banque de Russie établie au nom de la banque.
U2.2.1.6.2.2. <...> en utilisant le courrier à OMNI.

Conclusion


Le prochain article de la série examinera les modèles de menace typiques:

Source: https://habr.com/ru/post/fr421161/


All Articles