Sécurité de l'information des paiements bancaires sans espèces. Partie 8 - Modèles de menaces typiques

Sur quoi porte l'étude


Cet article complète la série de publications consacrées à assurer la sécurité de l'information des paiements bancaires sans espèces. Nous examinons ici les modèles de menace typiques référencés dans le modèle de base :

• Un modèle de menace typique. Connexion réseau .
• Un modèle de menace typique. Un système d'information construit sur la base d'une architecture client-serveur .
• Un modèle de menace typique. Système de contrôle d'accès .
• Un modèle de menace typique. Module d'intégration .
• Un modèle de menace typique. Système de sécurité des informations cryptographiques.

AVERTISSEMENT DE PORT !!! Cher Khabrovites, ce n'est pas un poste de divertissement.
Caché sous la coupe, plus de 40 pages de documents sont conçues pour aider les personnes spécialisées dans la banque ou assurer la sécurité de l'information au travail ou aux études . Ces documents sont le produit final de l'étude et sont écrits sur un ton officiel sec. Il s'agit essentiellement de blancs pour les documents internes sur la sécurité de l'information.

Eh bien, le traditionnel est «l'utilisation des informations d'un article à des fins illégales est punissable par la loi» . Lecture productive!

Informations pour les lecteurs qui connaissent l'étude, à commencer par cette publication.

Sur quoi porte l'étude

Vous lisez un guide pour le spécialiste chargé d'assurer la sécurité de l'information des paiements à la banque.

Logique de présentation

Au début, les parties 1 et 2 décrivent l'objet de la protection. Ensuite, dans la partie 3, nous décrivons comment construire un système de sécurité et discutons de la nécessité d'un modèle de menace. La partie 4 examine les modèles de menace existants et leur forme. Les parties 5 et 6 fournissent une analyse des attaques réelles. Les parties 7 et 8 contiennent une description du modèle de menace, construit en tenant compte des informations de toutes les parties précédentes.

MODÈLE DE MENACE TYPIQUE. CONNEXION AU RÉSEAU

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

L'objet de la protection est les données transmises via une connexion réseau fonctionnant dans des réseaux de données construits sur la base de la pile TCP / IP.

L'architecture



Description des éléments d'architecture:

• «Noeuds finaux» - noeuds échangeant des informations protégées.
• «Noeuds intermédiaires» - éléments d'un réseau de transmission de données: routeurs, commutateurs, serveurs d'accès, serveurs proxy et autres équipements - par lesquels le trafic de connexion réseau est transmis. En général, une connexion réseau peut fonctionner sans nœuds intermédiaires (directement entre les nœuds d'extrémité).

Menaces de sécurité de niveau supérieur

Décomposition

U1. Familiarisation non autorisée avec les données transmises.
U2. Modification non autorisée des données transmises.
U3. Violation de la paternité des données transmises.

U1. Familiarisation non autorisée avec les données transmises

Décomposition
U1.1. <...> réalisée aux nœuds finaux ou intermédiaires:
U1.1.1. <...> en lisant les données alors qu'elles se trouvent dans les périphériques de stockage du nœud:
U1.1.1.1. <...> en RAM.
Explications de U1.1.1.1.
Par exemple, lors du traitement des données par la pile réseau d'un nœud.

U1.1.1.2. <...> en mémoire non volatile.
Explications de U1.1.1.2.
Par exemple, lors du stockage des données transmises dans un cache, des fichiers temporaires ou des fichiers d'échange.

U1.2. <...> réalisée sur des nœuds tiers du réseau de données:
U1.2.1. <...> par la méthode de capture de tous les paquets arrivant à l'interface réseau du nœud:
Explications de U1.2.1.
Tous les paquets sont capturés en mettant la carte réseau en mode promiscuous (mode promiscuous pour les adaptateurs filaires ou mode moniteur pour les adaptateurs wi-fi).

U1.2.2. <...> en effectuant des attaques telles que "l'homme au milieu (MiTM)", mais sans modifier les données transmises (sans compter les données de service des protocoles réseau).
U1.2.2.1. Lien: «Un modèle de menace typique. Connexion réseau. U2. Modification non autorisée des données transmises . "

U1.3. <...>, réalisée en raison d'une fuite d'informations via des canaux techniques (TKUI) à partir de nœuds physiques ou de lignes de communication.

U1.4. <...>, réalisée pour l'installation sur le terminal ou les nœuds intermédiaires de moyens techniques spéciaux (STS), destinés à la lecture secrète d'informations.

U2. Modification non autorisée des données transmises

Décomposition
U2.1. <...> réalisée aux nœuds finaux ou intermédiaires:
U2.1.1. <...> en lisant et en modifiant les données lorsqu'elles se trouvent dans les périphériques de stockage des nœuds:
U2.1.1.1. <...> en RAM:
U2.1.1.2. <...> en mémoire non volatile:

U2.2. <...> réalisée sur des nœuds tiers du réseau de données:
U2.2.1. <...> en effectuant des attaques telles que "l'homme au milieu (MiTM)" et en redirigeant le trafic vers le site des intrus:
U2.2.1.1. Connexion physique de l'équipement intrus à une interruption de connexion réseau.
U2.2.1.2. Implémentation d'attaques sur les protocoles réseau:
U2.2.1.2.1. <...> gestion de réseau local virtuel (VLAN):
U2.2.1.2.1.1. Saut de VLAN .
U2.2.1.2.1.2. Modification non autorisée des paramètres VLAN sur les commutateurs ou les routeurs.
U2.2.1.2.2. <...> acheminement du trafic:
U2.2.1.2.2.1. Modification non autorisée des tables de routage statiques du routeur.
U2.2.1.2.2.2. Annonce par des fraudeurs de fausses routes via des protocoles de routage dynamiques.
U2.2.1.2.3. <...> configuration automatique:
U2.2.1.2.3.1. DHCP escroc .
U2.2.1.2.3.2. Rogue WPAD .
U2.2.1.2.4. <...> adressage et résolution de nom:
U2.2.1.2.4.1. Usurpation ARP .
U2.2.1.2.4.2. Usurpation DNS .
U2.2.1.2.4.3. Apporter des modifications non autorisées aux fichiers de noms d'hôte locaux (hôtes, lmhosts, etc.)

U3. Atteinte au droit d'auteur sur les données transmises

Décomposition
U3.1. Neutralisation des mécanismes de détermination de la paternité des informations en indiquant de fausses informations sur l'auteur ou la source de données:
U3.1.1. Changement d'informations sur l'auteur contenues dans les informations transmises.
U3.1.1.1. Neutralisation de la protection cryptographique de l'intégrité et de la paternité des données transmises:
U3.1.1.1.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 . »
U3.1.1.2. Neutralisation de la protection de la paternité des données transmises mise en œuvre à l'aide de codes de confirmation uniques:
U3.1.1.2.1. Échange de carte SIM .

U3.1.2. Changement d'informations sur la source des informations transmises:
U3.1.2.1. Usurpation d'adresse IP .
U3.1.2.2. Usurpation d'adresse MAC .

---

MODÈLE DE MENACE TYPIQUE. SYSTÈME D'INFORMATION CONSTRUIT SUR LA BASE DE L'ARCHITECTURE DU SERVEUR CLIENT

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

L'objet de la protection est un système d'information construit sur la base d'une architecture client-serveur.

L'architecture


Description des éléments d'architecture:

• «Client» - un appareil sur lequel la partie client du système d'information fonctionne.
• «Serveur» - un appareil sur lequel la partie serveur du système d'information fonctionne.
• «Data Warehouse» fait partie de l'infrastructure serveur d'un système d'information conçu pour stocker des données traitées par un système d'information.
• «Connexion réseau» - un canal pour échanger des informations entre le client et le serveur, en passant par un réseau de transmission de données. Une description plus détaillée du modèle d'élément est donnée dans le «Modèle de menace typique. Connexion réseau . "

Limitations
Lors de la modélisation d'un objet, les restrictions suivantes sont établies:

1. L'utilisateur interagit avec le système d'information dans des intervalles de temps finis, appelés sessions de travail.
2. Au début de chaque session de travail, l'utilisateur est identifié, authentifié et autorisé.
3. Toutes les informations protégées sont stockées côté serveur du système d'information.

Menaces de sécurité de niveau supérieur

Décomposition
U1. Les intrus commettent des actions non autorisées au nom d'un utilisateur légitime.
U2. Modification non autorisée des informations protégées lors de leur traitement par la partie serveur du système d'information.

U1. Perpétration d'actions non autorisées par des criminels au nom d'un utilisateur légitime

Explications
En règle générale, dans les systèmes d'information, les actions sont associées à l'utilisateur qui les a effectuées en utilisant:

1. journaux de fonctionnement du système (journaux).
2. attributs spéciaux d'objets de données contenant des informations sur l'utilisateur qui les a créés ou modifiés.

En relation avec la session de travail, cette menace peut se décomposer en:

1. <...> effectué dans le cadre de la session de travail de l'utilisateur.
2. <...> effectué en dehors de la session de travail de l'utilisateur.

Une session utilisateur peut être lancée:

1. Par l'utilisateur.
2. Intrus.

À ce stade, une décomposition intermédiaire de cette menace ressemblera à ceci:
U1.1. Des actions non autorisées ont été effectuées dans le cadre d'une session utilisateur:
U1.1.1. <...> installé par l'utilisateur attaqué.
U1.1.2. <...> installé par des attaquants.
U1.2. Les actions non autorisées sont effectuées en dehors de la session de l'utilisateur.

Du point de vue des objets de l'infrastructure d'information qui peuvent être affectés par des attaquants, la décomposition des menaces intermédiaires ressemblera à ceci:

Articles	Décomposition des menaces
	U1.1.1.	U1.1.2.	U1.2.
Client	U1.1.1.1.	U1.1.2.1.
Connexion réseau	U1.1.1.2.
Serveur			U1.2.1.

Décomposition
U1.1. Des actions non autorisées ont été effectuées dans le cadre d'une session utilisateur:
U1.1.1. <...> installé par l'utilisateur attaqué:
U1.1.1.1. Les attaquants ont agi indépendamment du client:
U1.1.1.1.1 Les attaquants ont utilisé des moyens d'accès réguliers au système d'information:
U1.1.1.1.1.1. Les attaquants ont utilisé les E / S physiques du client (clavier, souris, moniteur ou écran tactile d'un appareil mobile):
U1.1.1.1.1.1.1.1. Les attaquants ont agi pendant des périodes où la session est active, les fonctionnalités d'E / S sont disponibles et l'utilisateur n'est pas en place.
U1.1.1.1.1.2. Les attaquants ont utilisé des outils d'administration à distance (standard ou fournis par un code malveillant) pour gérer le client:
U1.1.1.1.1.2.1. Les attaquants ont agi pendant des périodes où la session est active, les fonctionnalités d'E / S sont disponibles et l'utilisateur n'est pas en place.
U1.1.1.1.1.2.2. Les attaquants ont utilisé des outils d'administration à distance, dont le fonctionnement est invisible pour l'utilisateur attaqué.
U1.1.1.2. Les attaquants ont remplacé les données dans une connexion réseau entre le client et le serveur, en les modifiant afin qu'elles soient perçues comme des actions d'un utilisateur légitime:
U1.1.1.2.1. Lien: «Un modèle de menace typique. Connexion réseau. U2. Modification non autorisée des données transmises . "
U1.1.1.3. Les attaquants ont forcé l'utilisateur à effectuer les actions indiquées par lui en utilisant des méthodes d'ingénierie sociale.

U1.1.2 <...> établi par les attaquants:
U1.1.2.1. Les attaquants ont agi à partir du client ( I ):
U1.1.2.1.1. Les attaquants ont neutralisé le système de contrôle d'accès du système d'information:
U1.1.2.1.1.1. Lien: «Un modèle de menace typique. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légal . "
U1.1.2.1.2. Les attaquants ont utilisé des outils standard d'accès au système d'information
U1.1.2.2. Les attaquants ont agi à partir d'autres nœuds du réseau de données à partir desquels vous pouvez établir une connexion réseau avec le serveur ( I ):
U1.1.2.2.1. Les attaquants ont neutralisé le système de contrôle d'accès du système d'information:
U1.1.2.2.1.1. Lien: «Un modèle de menace typique. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légal . "
U1.1.2.2.2. Les attaquants ont utilisé des outils d'accès anormaux au système d'information.
Explications 1.1.1.2.2.2.
Les attaquants pourraient installer un client régulier du système d'information sur un nœud tiers ou utiliser un logiciel anormal qui implémente des protocoles d'échange standard entre le client et le serveur.

U1.2 Les actions non autorisées sont effectuées en dehors de la session de l'utilisateur.
D1.2.1 Les attaquants ont effectué des actions non autorisées, puis ont apporté des modifications non autorisées aux journaux du système d'information ou aux attributs spéciaux des objets de données, indiquant que les actions qu'ils ont effectuées ont été effectuées par un utilisateur légitime.

U2. Modification non autorisée des informations protégées lors de leur traitement par la partie serveur du système d'information

Décomposition
U2.1. Les attaquants modifient les informations protégées à l'aide des outils standards du système d'information et les exécutent pour le compte d'un utilisateur légitime.
U2.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.2. Les attaquants modifient les informations protégées en utilisant des mécanismes d'accès aux données qui ne sont pas prévus par le mode de fonctionnement normal du système d'information.
U2.2.1. Les attaquants modifient des fichiers contenant des informations protégées:
U2.2.1.1. <...> en utilisant les mécanismes de gestion de fichiers fournis par le système d'exploitation.
U2.2.1.2. <...> en provoquant la restauration de fichiers à partir d'une sauvegarde modifiée non autorisée.

U2.2.2. Les attaquants modifient les informations protégées stockées dans la base de données ( I ):
U2.2.2.1. Les attaquants neutralisent le système de contrôle d'accès au SGBD:
U2.2.2.1.1. Lien: «Un modèle de menace typique. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légal . "
U2.2.2.2. Les attaquants modifient les informations à l'aide des interfaces SGBD standard pour accéder aux données.

U2.3. Les attaquants modifient les informations protégées par une modification non autorisée des algorithmes du logiciel de traitement.
U2.3.1. Des modifications sont apportées au code source du logiciel.
U2.3.1. Des modifications sont apportées au code machine du logiciel.

U2.4. Les attaquants modifient les informations protégées en exploitant les vulnérabilités des logiciels du système d'information.

U2.5. Les attaquants modifient les informations protégées lors de leur transfert entre les composants de la partie serveur du système d'information (par exemple, le serveur de base de données et le serveur d'applications):
U2.5.1. Lien: «Un modèle de menace typique. Connexion réseau. U2. Modification non autorisée des données transmises . "

---

MODÈLE DE MENACE TYPIQUE. SYSTÈME DE RESTRICTION D'ACCÈS

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

L'objet de protection auquel ce modèle de menace est appliqué correspond à l'objet de protection du modèle de menace: «Modèle de menace typique. Un système d'information basé sur une architecture client-serveur. »

Dans le cadre du système de restriction de l'accès des utilisateurs dans ce modèle de menace, on entend un composant du système d'information qui met en œuvre les fonctions:

1. Identification de l'utilisateur.
2. Authentification utilisateur.
3. Autorisation utilisateur.
4. Journalisation des actions des utilisateurs.

Menaces de sécurité de niveau supérieur

Décomposition
U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légal.
U2. Escalade non autorisée des privilèges des utilisateurs dans le système d'information.

U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légal

Explications
La décomposition de cette menace dans le cas général dépendra du type de système d'identification et d'authentification des utilisateurs utilisé.

Dans ce modèle, seul un système d'identification et d'authentification des utilisateurs utilisant une connexion texte et un mot de passe sera pris en compte. Dans le même temps, nous supposons que la connexion de l'utilisateur est une information connue du public connue des attaquants.

Décomposition
U1.1. <...> en raison d'informations d'identification compromises:
U1.1.1. Les attaquants ont compromis les informations d'identification de l'utilisateur pendant le stockage.
Explications 1.1.1.1.
Par exemple, les informations d'identification peuvent être inscrites sur un autocollant collé sur le moniteur.

U1.1.2. L'utilisateur a accidentellement ou par intention malveillante transféré les détails d'accès aux attaquants.
U1.1.2.1. L'utilisateur a prononcé les informations d'identification à haute voix lors de la saisie.
U1.1.2.2. L'utilisateur a intentionnellement transmis ses informations d'identification:
U1.1.2.2.1. <...> à mes collègues.
Explications U1.1.2.2.1.
Par exemple, afin qu'ils puissent le remplacer par une période de maladie.

U1.1.2.2.2. <...> contreparties patronales effectuant des travaux sur les infrastructures d’information.
U1.1.2.2.3. <...> à des tiers.
Explications 1.1.1.2.2.3.
Une, mais pas la seule option pour mettre en œuvre cette menace est l'utilisation de méthodes d'ingénierie sociale par les attaquants.

U1.1.3. Les attaquants ont récupéré les informations d'identification par force brute:
U1.1.3.1. <...> en utilisant des mécanismes d'accès standard.
U1.1.3.2. <...> par des codes précédemment interceptés (par exemple, des hachages de mot de passe) pour stocker les informations d'identification.

U1.1.4.Les attaquants ont utilisé du code malveillant pour intercepter les informations d'identification des utilisateurs.

U1.1.5. Les attaquants ont extrait les informations d'identification de la connexion réseau entre le client et le serveur:
U1.1.5.1. Lien: «Un modèle de menace typique. Connexion réseau. U1. Familiarisation non autorisée avec les données transmises . »

U1.1.6. Les attaquants ont extrait les informations d'identification des enregistrements des systèmes de surveillance du travail:
U1.1.6.1. <...> systèmes de vidéosurveillance (si pendant le fonctionnement les frappes sur le clavier ont été enregistrées).
U1.1.6.2. <...> systèmes de surveillance des actions des employés sur l'ordinateur
Explications U1.1.6.2.
Un exemple d'un tel système est StuffCop .

U1.1.7. Les attaquants ont compromis les informations d'identification de l'utilisateur en raison de failles dans le processus de transfert.
Explications U1.1.7.
Par exemple, envoyer des mots de passe en texte clair par e-mail.

U1.1.8. Les attaquants ont appris les informations d'identification en surveillant la session de l'utilisateur à l'aide de systèmes d'administration à distance.

U1.1.9. Les attaquants ont extrait les informations d'identification à la suite de leur fuite via les canaux techniques (TKUI):
1.1.9.1. Les attaquants ont espionné la façon dont l'utilisateur saisit les informations d'identification à partir du clavier:
U1.1.9.1.1 Les attaquants se trouvaient à proximité de l'utilisateur et ont vu la saisie des informations d'identification de leurs propres yeux.
Explications U1.1.9.1.1
Ces cas incluent les actions de collègues au travail ou le cas où le clavier de l'utilisateur est visible par les visiteurs de l'organisation.

D1.1.9.1.2 Les attaquants ont utilisé des moyens techniques supplémentaires, tels que des jumelles ou un véhicule aérien sans pilote, et ont vu les informations d'identification entrées par la fenêtre.
U1.1.9.2. Les attaquants ont extrait les informations d'identification des enregistrements de l'échange radio entre le clavier et l'unité centrale de l'ordinateur s'ils étaient connectés via l'interface radio (par exemple, Bluetooth).
U1.1.9.3. Les attaquants ont intercepté les informations d'identification en raison de leur fuite à travers le canal du rayonnement électromagnétique secondaire et des interférences (PEMIN).
Explications 1.1.1.3.
Exemples d'attaques ici et ici .

U1.1.9.4. L'attaquant a intercepté la saisie des informations d'identification à partir du clavier grâce à l'utilisation de moyens techniques spéciaux (STS) conçus pour la récupération tacite d'informations.
Explications 1.1.1.4.
Exemples d' appareils .

U1.1.9.5. Les attaquants ont intercepté la saisie des informations d'identification à partir du clavier en
analysant le signal Wi-Fi modulé par les frappes de l'utilisateur.
Explications U1.1.9.5.
Exemple d' attaque .

U1.1.9.6. Les attaquants ont intercepté la saisie des informations d'identification du clavier en analysant les sons des frappes.
Explications U1.1.9.6.
Exemple d' attaque .

U1.1.9.7. Les attaquants ont intercepté la saisie des informations d'identification à partir du clavier d'un appareil mobile en analysant les lectures de l'accéléromètre.
Explications U1.1.9.7.
Exemple d' attaque .

U1.1.10. <...> précédemment enregistré sur le client.
Explications U1.1.10.
Par exemple, un utilisateur peut enregistrer un nom d'utilisateur et un mot de passe dans un navigateur pour accéder à un site spécifique.

U1.1.11. Les attaquants ont compromis les informations d'identification en raison de failles dans le processus de révocation de l'accès utilisateur.
Explications 1.1.1.11.
Par exemple, après le licenciement de l'utilisateur, ses comptes n'ont pas été bloqués.

U1.2. <...> en raison de l'utilisation de vulnérabilités dans le système de contrôle d'accès.

U2. Escalade non autorisée des privilèges des utilisateurs dans le système d'information

Décomposition
U2.1 <...> en apportant des modifications non autorisées aux données contenant des informations sur les privilèges des utilisateurs.

U2.2 <...> en raison de l'utilisation de vulnérabilités dans le système de contrôle d'accès.

U2.3. <...> en raison de failles dans le processus de contrôle d'accès des utilisateurs.
Explications U2.3.
Exemple 1. L'utilisateur a été autorisé à travailler plus qu'il n'en avait besoin pour les besoins officiels.
Exemple 2. Après avoir transféré un utilisateur vers un autre poste, les droits d'accès précédemment accordés n'ont pas été révoqués.

---

MODÈLE DE MENACE TYPIQUE. MODULE D'INTÉGRATION

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

Module d'intégration - un ensemble d'objets d'infrastructure d'information conçus pour organiser l'échange d'informations entre les systèmes d'information.

Étant donné que dans les réseaux d'entreprise, il n'est pas toujours possible de séparer sans ambiguïté un système d'information d'un autre, le module d'intégration peut également être considéré comme un lien entre les composants d'un même système d'information.

Architecture Le
schéma général du module d'intégration est le suivant:



Description des éléments d'architecture:

• «Serveur d'échange (CO)» - nœud / service / composant d'un système d'information qui remplit la fonction d'échange de données avec un autre système d'information.
• «» – / , , .
  «» , (enterprise service bus / SoA-), .. «».
• « » – , .
  , , ..
• "Connexion réseau" correspond à l'objet décrit dans le modèle de menace de connexion réseau typique. Certaines connexions réseau de celles présentées dans le diagramme ci-dessus peuvent ne pas exister.

Exemples de modules d'intégration

Diagramme 1. Intégration d'ABS et d'AWS du CBD via un serveur de fichiers tiers

Pour effectuer des paiements, un employé de banque autorisé télécharge des documents de paiement électronique depuis l'ABS et les enregistre dans un fichier (de son propre format, par exemple, SQL dump) sur un dossier réseau (\\ ... Serveur de fichiers \ SHARE \). Ensuite, ce fichier est converti à l'aide d'un convertisseur de script en un ensemble de fichiers au format UFEBS, qui sont ensuite lus par le poste de travail KBR.
Après cela, un employé autorisé - un utilisateur d'AWS KBR - chiffre et signe le fichier reçu et l'envoie au système de paiement de la Banque de Russie.

Dès réception des paiements de la Banque de Russie, AWS KBR les déchiffre et vérifie la signature électronique, puis les écrit sous la forme d'un ensemble de fichiers au format UFEBS sur un serveur de fichiers. Avant d'importer des documents de paiement dans l'ABS, ils sont convertis à l'aide d'un convertisseur de script du format UFBS au format ABS.

Nous supposons que dans ce schéma, l'ABS fonctionne sur un serveur physique, le KBR AWS fonctionne sur un ordinateur dédié et le convertisseur de script s'exécute sur un serveur de fichiers.



Correspondance des objets du circuit considéré aux éléments du modèle de module d'intégration:
« Serveur d' échange côté ABS» - Serveur ABS.
"Exchange Server à partir d'AWP KBR" - ordinateur AWP KBR.
"Mediator" est un serveur de fichiers tiers.
"Logiciel de traitement de données"- convertisseur de script.

Schéma 2. Intégration d'ABS et AWS KBR lors du placement d'un dossier réseau partagé avec des paiements sur AWS KBR

Tout est similaire au schéma 1, mais un serveur de fichiers distinct n'est pas utilisé, mais un dossier réseau (\\ ... \ SHARE \) avec des documents de paiement électronique se trouve sur ordinateur avec AWS CBD. Le convertisseur de script fonctionne également sur AWS KBR.



Correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration:
Similaire au schéma 1, mais l ' "intermédiaire" n'est pas utilisé.

Schéma 3. Intégration d'ABS et AWS KBR-N via IBM WebSphera MQ et signature de documents électroniques «côté ABS»

ABS fonctionne sur une plate-forme non prise en charge par la signature SKZI SCAD. La signature des documents électroniques sortants s'effectue sur un serveur de signature électronique spécial (ES Server). Le même serveur vérifie la signature électronique des documents provenant de la Banque de Russie.

ABS télécharge un fichier contenant des documents de paiement au format propriétaire sur le serveur ES.
À l'aide du convertisseur de script, le serveur ES convertit le fichier en messages électroniques au format UFBS, après quoi les messages électroniques sont signés et transmis à IBM WebSphere MQ.

AWP KBR-N contacte IBM WebSphere MQ et reçoit des messages de paiement signés à partir de là, après quoi l'employé autorisé - utilisateur AWP KBR - les chiffre et les envoie au système de paiement de la Banque de Russie.

Dès réception des paiements de la Banque de Russie, AWP KBR-N les déchiffre et vérifie la signature électronique. Les paiements traités avec succès sous forme de messages électroniques déchiffrés et signés au format UFBS sont transmis à IBM WebSphere MQ, d'où ils sont reçus par le serveur ES.

Le serveur ES vérifie la signature électronique des paiements reçus et les enregistre dans un fichier au format ABS. Après cela, l'employé autorisé - l'utilisateur ABS - télécharge le fichier résultant vers l'ABS de la manière prescrite.



Correspondance des objets du schéma considéré avec les éléments du modèle de module d'intégration:
«Serveur d'échange côté ABS» - Serveur ABS.
«Serveur Exchange à partir d'AWP KBR» - ordinateur AWP KBR.
"Mediator" - serveur ES et IBM WebSphere MQ.
"Logiciel de traitement de données"- convertisseur de script, SKZI SKAD Signature sur le serveur ES.

Schéma 4. Intégration du serveur RBS et ABS via l'API fournie par un serveur d'échange dédié

Nous supposons que la banque utilise plusieurs systèmes de services bancaires à distance (RBS):

• «Internet Client-Bank» pour les particuliers (IKB FL);
• "Internet Client-Bank" pour les personnes morales (IKB YL).

Afin d'assurer la sécurité de l'information, toutes les interactions d'ABS avec les systèmes bancaires à distance sont effectuées via un serveur d'échange dédié fonctionnant dans le cadre du système d'information ABS.

Ensuite, nous considérons le processus d'interaction entre le système RB de l'IKB YuL et ABS.
Le serveur RBS, ayant reçu un ordre de paiement dûment certifié du client, doit créer un document approprié dans l'ABS sur sa base. Pour ce faire, à l'aide de l'API, il transfère des informations au serveur d'échange, et qui, à son tour, entre les données dans l'ABS.

Lorsque les soldes sur le compte du client changent, l'ABS génère des notifications électroniques qui sont transmises au serveur de banque à distance à l'aide du serveur d'échange.



Correspondance des objets du circuit considéré aux éléments du modèle du module d'intégration:
«Serveur d'échange de la part du système de banque à distance»- serveur DBO IKB YuL.
«Serveur d'échange du côté ABS» - serveur d'échange.
"Intermédiaire" - est absent.
«Logiciel de traitement des données» - composants du serveur RBS responsable de l'utilisation de l'API Exchange Server, composants du serveur Exchange responsable de l'utilisation de l'API ABS.

Menaces de sécurité de niveau supérieur

Décomposition
U1. Les intrus injectent des informations frauduleuses via un module d'intégration.

U1. Attaquer des informations frauduleuses via un module d'intégration

Décomposition
U1.1. Modification non autorisée de données légitimes lors de la transmission via des connexions réseau:
U1.1.1 Lien: «Modèle de menace typique. Connexion réseau. U2. Modification non autorisée des données transmises . "

U1.2. Transmission de fausses données via des canaux de communication pour le compte d'un participant légitime à l'échange:
U1.1.2 Lien: «Modèle de menace typique. Connexion réseau. U3. Violation de la paternité des données transmises . "

U1.3. Modification non autorisée de données légitimes lors de leur traitement sur les Serveurs Exchange ou l'Intermédiaire:
U1.3.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 . "

U1.4. Création de données falsifiées sur les serveurs Exchange ou l'intermédiaire pour le compte d'un participant légitime à l'échange:
U1.4.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. »

U1.5. Modification non autorisée de données lors de leur traitement à l'aide d'un logiciel de traitement de données:
U1.5.1. <...> en raison de modifications non autorisées des paramètres (configuration) du logiciel de traitement de données par des cybercriminels.
U1.5.2. <...> en raison de modifications non autorisées apportées aux fichiers exécutables des logiciels de traitement de données par des cybercriminels.
U1.5.3. <...> en raison du contrôle interactif par les attaquants du logiciel de traitement des données.

---

MODÈLE DE MENACE TYPIQUE. SYSTÈME DE PROTECTION CRYPTOGRAPHIQUE D'INFORMATIONS

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

L'objet de la protection est un système de protection des informations cryptographiques utilisé pour assurer la sécurité du système d'information.

Architecture
La base de tout système d'information est un logiciel d'application (logiciel) qui met en œuvre sa fonctionnalité cible.

Dans ce cas, la protection cryptographique est généralement mise en œuvre en appelant des primitives cryptographiques à partir de la logique métier du logiciel d'application, qui se trouvent dans des bibliothèques spécialisées - les noyaux cryptographiques.

Les primitives cryptographiques incluent des fonctions cryptographiques de bas niveau, telles que:

• crypter / décrypter un bloc de données;
• créer / vérifier la signature électronique du bloc de données;
• calculer la fonction de hachage du bloc de données;
• générer / télécharger / télécharger des informations clés;
• etc.

La logique métier d'un logiciel d'application utilisant des primitives cryptographiques implémente une fonctionnalité de niveau supérieur:

• crypter le fichier sur les clés des destinataires sélectionnés;
• établir une connexion réseau sécurisée;
• informer sur les résultats de la vérification des signatures électroniques;
• etc.

L'interaction de la logique métier et du cœur de chiffrement peut être réalisée:

• directement, en appelant la logique métier des primitives cryptographiques à partir des bibliothèques dynamiques du noyau cryptographique (.DLL - pour Windows, .SO - pour Linux);
• , – (wrappers), , MS Crypto API, Java Cryptography Architecture, PKCS#11 . - , , . .

On peut distinguer deux schémas types d'organisation d'un cryptonucleus:

Schéma 1 - Cryptonucleus monolithique.


Schéma 2 - Cryptonucleus divisé. Les


éléments des schémas ci-dessus peuvent être soit des modules logiciels distincts fonctionnant sur un ordinateur, soit des services réseau interagissant au sein d'un réseau informatique.

Lorsque vous utilisez des systèmes construits selon le schéma 1, le logiciel d'application et le cœur de chiffrement fonctionnent dans le cadre d'un environnement unique pour le fonctionnement d'une installation de chiffrement (SFC), par exemple, sur le même ordinateur, sous le contrôle du même système d'exploitation. En règle générale, un utilisateur système peut exécuter d'autres programmes, y compris ceux contenant du code malveillant, dans le cadre du même environnement de fonctionnement. Dans de telles circonstances, il existe un risque sérieux de fuite de clés cryptographiques privées.

Pour minimiser le risque, le schéma 2 est utilisé, dans lequel le noyau cryptographique est divisé en deux parties:

1. La première partie, avec le logiciel d'application, fonctionne dans un environnement non fiable où il existe un risque d'infection par un code malveillant. Nous appellerons cette partie la «partie logicielle».
2. La deuxième partie fonctionne dans un environnement sécurisé sur un appareil dédié qui contient un magasin de clés privées. De plus, nous appellerons cette partie «matériel».

La division du cryptocore en logiciel et matériel est très arbitraire. Il existe sur le marché des systèmes qui sont construits selon le schéma avec un cryptocore divisé, mais dont la partie «matérielle» est présentée sous la forme d'une image de machine virtuelle - HSM virtuelle ( exemple ).

L'interaction des deux parties du noyau cryptographique se produit de telle manière que les clés cryptographiques privées ne sont jamais transmises à la partie logicielle et, par conséquent, ne peuvent pas être volées à l'aide de code malveillant.

L'interface d'interaction (API) et l'ensemble de primitives cryptographiques fournies par le logiciel d'application par le noyau cryptographique sont les mêmes dans les deux cas. La différence réside dans la manière dont ils sont mis en œuvre.

Ainsi, lorsque vous utilisez un schéma avec un cœur de chiffrement divisé, l'interaction du logiciel et du matériel est effectuée selon le principe suivant:

1. Les primitives cryptographiques qui ne nécessitent pas l'utilisation d'une clé privée (par exemple, le calcul d'une fonction de hachage, la vérification des signatures électroniques, etc.) sont effectuées par la partie logicielle.
2. Les primitives cryptographiques utilisant une clé privée (création d'une signature électronique, décryptage des données, etc.) sont effectuées par le matériel.

Nous illustrerons le travail d'un cryptocore divisé en utilisant l'exemple de création d'une signature électronique:

1. La partie logicielle calcule la fonction de hachage des données signées et transfère cette valeur à la partie matérielle via le canal d'échange entre les noyaux cryptographiques.
2. La partie matérielle, à l'aide de la clé privée et du hachage, forme la valeur de la signature électronique et la transfère à la partie logicielle via le canal d'échange.
3. La partie logicielle renvoie la valeur reçue au logiciel d'application.

Particularités de la vérification de l'exactitude d'une signature électronique

Lorsqu'un destinataire reçoit des données signées par une signature électronique, il doit effectuer plusieurs étapes de vérification. Un résultat positif de la vérification d'une signature électronique n'est obtenu que si toutes les étapes de la vérification sont terminées avec succès.

Étape 1. Contrôle de l'intégrité des données et de la paternité des données.

Le contenu de la scène. La signature électronique des données est vérifiée à l'aide de l'algorithme cryptographique correspondant. La réussite de cette étape signifie que les données n'ont pas été modifiées depuis leur signature et que la signature a été effectuée avec une clé privée correspondant à la clé publique de vérification de signature électronique.
Lieu d'exécution de la scène: cryptocore.

Étape 2. Contrôle de la confiance dans la clé publique du signataire et contrôle de la validité de la clé privée de la signature électronique.
Le contenu de la scène. L'étape se compose de deux sous-étapes intermédiaires. Le premier établit si la clé publique de la vérification de la signature électronique était fiable au moment de la signature des données. La seconde définit si la clé privée de la signature électronique était valide au moment de la signature des données. Dans le cas général, les périodes de validité de ces clés peuvent ne pas coïncider (par exemple, pour les certificats de certificat qualifiés de clés de vérification de signature électronique). Les moyens d'établir la confiance dans la clé publique du signataire sont déterminés par les règles de gestion électronique des documents adoptées par les parties en interaction.
Lieu d'exécution de la scène: logiciel d'application / noyau cryptographique.

Étape 3. Contrôle des pouvoirs du signataire.
Le contenu de la scène. Conformément aux règles établies de gestion électronique des documents, il est vérifié si le signataire avait le droit de certifier les données protégées. Par exemple, nous donnons une situation de violation de l'autorité. Supposons qu'il existe une organisation où tous les employés ont une signature électronique. L'ordre du chef, mais signé par la signature électronique du responsable de l'entrepôt, entre dans le système interne de gestion électronique des documents. En conséquence, un tel document ne peut être considéré comme légitime.
Lieu d'exécution de la scène: logiciel d'application.

Hypothèses formulées lors de la description de l'objet de la protection

1. Les canaux de transfert d'informations, à l'exception des canaux d'échange de clés, passent également par le logiciel d'application, l'API et le noyau cryptographique.
2. () , , .
3. .

,

Pour illustrer les schémas présentés précédemment, nous considérons un système d'information hypothétique et sélectionnons tous les éléments structurels sur celui-ci.

Description du système d'information



Deux organisations ont décidé d'introduire entre elles une gestion électronique des documents (EDF) juridiquement significative. Pour ce faire, ils ont conclu un accord dans lequel ils prescrivent que les documents seront transmis par e-mail, et en même temps ils doivent être cryptés et signés par une signature électronique qualifiée. Pour créer et traiter des documents, les programmes Office du package Microsoft Office 2016 doivent être utilisés et comme moyen de protection cryptographique - CryptoPRO Cryptographic Protection Tool et CryptoARM encryption software.

Description de l'infrastructure de l'organisation 1

L'organisation 1 a décidé d'installer le système de protection des informations cryptographiques CryptoPRO et le logiciel CryptoARM sur le poste de travail de l'utilisateur - un ordinateur physique. Les clés de cryptage et de signature électronique seront stockées sur le support de clé ruToken fonctionnant dans le mode de la clé extraite. L'utilisateur préparera les documents électroniques localement sur son ordinateur, après quoi ils seront cryptés, signés et envoyés à l'aide d'un client de messagerie installé localement.

Description de l’infrastructure de l’organisation 2 L’

organisation 2 a décidé de transférer les fonctions de chiffrement et de signature électronique sur une machine virtuelle dédiée. Dans ce cas, toutes les opérations cryptographiques seront effectuées automatiquement.

Pour ce faire, deux dossiers réseau sont organisés sur la machine virtuelle dédiée: "\\ ... \ In \", "\\ ... \ Out \". Dans le dossier réseau "\\ ... \ In \", les fichiers reçus de la contrepartie en clair seront automatiquement placés. Ces fichiers seront décryptés et une signature électronique y sera vérifiée.

Dans le dossier "\\ ... \ Out \", l'utilisateur placera les fichiers qui doivent être cryptés, signés et envoyés à la contrepartie. L'utilisateur préparera lui-même les fichiers sur son poste de travail.
Pour exécuter les fonctions de cryptage et de signature électronique sur une machine virtuelle, le logiciel CryptoPro, le logiciel de cryptoarm et un client de messagerie sont installés. Le contrôle automatique de tous les éléments de la machine virtuelle sera effectué à l'aide de scripts développés par les administrateurs système.Les scripts sont enregistrés dans les fichiers journaux.

Les clés cryptographiques de la signature électronique seront placées sur le jeton avec la clé non extractible Ga JaCarta, que l'utilisateur connectera à son ordinateur local.

Le jeton sera transmis à la machine virtuelle à l'aide d'un logiciel USB-sur-IP spécialisé installé sur le poste de travail de l'utilisateur et sur la machine virtuelle.

L'horloge système sur le poste de travail de l'utilisateur dans l'organisation 1 sera ajustée manuellement. L'horloge système d'une machine virtuelle spécialisée dans l'organisation 2 sera synchronisée avec l'horloge système de l'hyperviseur, et celles-ci, à leur tour, seront synchronisées via Internet avec des serveurs de temps publics.

Isolement des éléments structurels de la protection des informations cryptographiques
Sur la base de la description ci-dessus de l'infrastructure informatique, nous mettons en évidence les éléments structurels du système de protection des informations cryptographiques et les écrivons dans le tableau.

Tableau - Correspondance des éléments du modèle de protection des informations cryptographiques avec les éléments des systèmes d'information

Nom de l'article	Organisation 1	Organisation 2
Logiciels d'application	Logiciel CryptoARM	Logiciel CryptoARM
Le logiciel crypto core	SKZI CryptoPro CSP	SKZI CryptoPro CSP
Matériel de crypto-monnaie	est manquant	JaCarta GOST
API	MS CryptoAPI	MS CryptoAPI
Magasin de clés publiques	AWP de l'utilisateur: - disque dur; - Le magasin de certificats Windows standard.	Hyperviseur: - disque dur. Machine virtuelle: - disque dur; - Le magasin de certificats Windows standard.
Coffre à clés privé	Porte-clés ruToken fonctionnant en mode clé récupérable	Porte-clés JaCarta GOST fonctionnant en mode clé non récupérable
Canal d'échange de clés publiques	AWP de l'utilisateur: - mémoire à accès aléatoire.	Hyperviseur: - mémoire à accès aléatoire. Machine virtuelle: - mémoire à accès aléatoire.
Canal d'échange de clés privées	AWP de l'utilisateur: - Bus USB; - mémoire à accès aléatoire.	est manquant
Canal d'échange de crypto-monnaie	absent (pas de matériel crypto core)	AWP de l'utilisateur: - Bus USB; - mémoire à accès aléatoire; - module logiciel USB-sur-IP; - interface réseau. Réseau d'entreprise de l'organisation 2. Hyperviseur: - mémoire à accès aléatoire; - interface réseau. Machine virtuelle: - interface réseau; - mémoire à accès aléatoire; - Module logiciel USB sur IP.
Canal d'échange de données ouvert	AWP de l'utilisateur: - des moyens d'entrée-sortie; - mémoire à accès aléatoire; - disque dur.	AWP de l'utilisateur: - des moyens d'entrée-sortie; - mémoire à accès aléatoire; - disque dur; - interface réseau. Réseau d'entreprise de l'organisation 2. Hyperviseur: - interface réseau; - mémoire à accès aléatoire; - disque dur. Machine virtuelle: - interface réseau; - mémoire à accès aléatoire; - disque dur.
Canal de données sécurisé	Internet. Réseau d'entreprise de l'organisation 1. AWP de l'utilisateur: - disque dur; - mémoire à accès aléatoire; - interface réseau.	Internet. Réseau d'entreprise de l'organisation 2. Hyperviseur: - interface réseau; - mémoire à accès aléatoire; - disque dur. Machine virtuelle: - interface réseau; - mémoire à accès aléatoire; - disque dur.
Canal horaire	AWP de l'utilisateur: - des moyens d'entrée-sortie; - mémoire à accès aléatoire; - minuterie système.	Internet. Organisation du réseau d'entreprise 2, Hyperviseur: - interface réseau; - mémoire à accès aléatoire; - minuterie système. Machine virtuelle: - mémoire à accès aléatoire; - minuterie système.
Canal de transmission de commande de contrôle	AWP de l'utilisateur: - des moyens d'entrée-sortie; - mémoire à accès aléatoire. (Interface utilisateur graphique du logiciel CryptoARM)	Machine virtuelle: - mémoire à accès aléatoire; - disque dur. (Scripts d'automatisation)
Canal pour recevoir les résultats du travail	AWP de l'utilisateur: - des moyens d'entrée-sortie; - mémoire à accès aléatoire. (Interface utilisateur graphique du logiciel CryptoARM)	Machine virtuelle: - mémoire à accès aléatoire; - disque dur. (Fichiers journaux de script d'automatisation)

Menaces de sécurité de niveau supérieur

Explications

Hypothèses formulées lors de la décomposition du danger:

1. Des algorithmes cryptographiques puissants sont utilisés.
2. Les algorithmes cryptographiques sont utilisés de manière sûre dans les modes de fonctionnement corrects (par exemple, la BCE n'est pas utilisée pour crypter de grandes quantités de données, la charge autorisée sur la clé est prise en compte, etc.).
3. Les attaquants connaissent tous les algorithmes, protocoles et clés publiques applicables.
4. Les attaquants peuvent lire toutes les données chiffrées.
5. Les attaquants sont capables de reproduire tous les éléments du programme dans le système.

Décomposition

U1. Compromis de clés cryptographiques privées.
U2. Chiffrez les données frauduleuses au nom d'un expéditeur légitime.
U3. Déchiffrement des données chiffrées par des personnes qui ne sont pas des destinataires légitimes des données (attaquants).
U4. Création d'une signature électronique d'un signataire légitime sous de fausses données.
U5. Obtention d'un résultat positif de vérification de la signature électronique de fausses données.
Y6. Acceptation erronée de documents électroniques pour exécution en raison de problèmes d'organisation de la gestion électronique des documents.
Y7. Familiarisation non autorisée avec les données protégées lors de leur traitement par le système de protection des informations cryptographiques.

U1. Compromis de clés cryptographiques privées

U1.1. Obtention de la clé privée à partir du magasin de clés privées.

U1.2. Obtention d'une clé privée à partir d'objets de l'environnement du fonctionnement de la crypto-monnaie dans laquelle elle peut être temporairement située.
Explications U1.2.

Les objets dans lesquels la clé privée peut être temporairement stockée comprendront:

1. RAM
2. fichiers temporaires
3. échanger des fichiers
4. fichiers d'hibernation
5. fichiers d'instantanés de l'état «chaud» des machines virtuelles, y compris les fichiers en pause du contenu de la RAM des machines virtuelles.

U1.2.1. Suppression des clés privées de la RAM de travail en gelant les modules de RAM, en les extrayant, puis en lisant les données (gel de l'attaque).
Explications U1.2.1.
Exemple d' attaque .

U1.3. Obtention d'une clé privée à partir d'un canal d'échange de clés privées.
Explications U1.3.
Un exemple de la mise en œuvre de cette menace sera donné ci-dessous .

U1.4. Modification non autorisée du noyau cryptographique, à la suite de laquelle les clés privées deviennent connues des attaquants.

U1.5. Compromis d'une clé privée suite à l'utilisation de canaux techniques de fuite d'informations (TKUI).
Explications U1.5.
Exemple d' attaque .

U1.6. Compromis de la clé privée résultant de l'utilisation de moyens techniques spéciaux (STS) conçus pour la recherche d'informations secrètes ("bugs").

U1.7. Compromis de clés privées lors du stockage en dehors du système de protection des informations cryptographiques.
Explications U1.7.
Par exemple, un utilisateur stocke ses principaux médias dans un tiroir de bureau, d'où ils peuvent facilement être extraits par des intrus.

U2. Chiffrer les données frauduleuses au nom d'un expéditeur légitime

Explications
Cette menace n'est prise en compte que pour les schémas de chiffrement des données avec authentification de l'expéditeur. Des exemples de tels schémas sont indiqués dans les recommandations de normalisation R 1323565.1.004-2017 «Technologies de l'information. Sécurité des informations cryptographiques. Schémas d'authentification à clé publique basés sur la clé publique . » Pour d'autres schémas cryptographiques, cette menace n'existe pas, car le cryptage est effectué sur les clés publiques du destinataire, et elles sont généralement connues des attaquants.

Décomposition
U2.1. Compromis de la clé privée de l'expéditeur:
U2.1.1. Lien: «Un modèle de menace typique. Système de protection des informations cryptographiques U1. Compromis de clés cryptographiques privées . "

U2.2. Substitution des données d'entrée dans le canal d'échange de données ouvert.
Notes U2.2.
Des exemples de mise en œuvre de cette menace sont donnés ci-dessous ici et ici .

U3. Déchiffrement des données chiffrées par des personnes qui ne sont pas des destinataires légitimes des données (attaquants)

Décomposition
U3.1. Compromis de clés privées du destinataire des données cryptées.
Y3.1.1 Lien: «Modèle de menace typique. Système de sécurité des informations cryptographiques. U1. Compromis de clés cryptographiques privées . "

U3.2. Remplacement des données chiffrées dans un canal d'échange de données sécurisé.

U4. Création d'une signature électronique d'un signataire légitime sous de fausses données

Décomposition
U4.1. Compromis de clés privées d'une signature électronique d'un signataire légitime.
Y4.1.1 Lien: «Modèle de menace typique. Système de sécurité des informations cryptographiques. U1. Compromis de clés cryptographiques privées . "

U4.2. Substitution des données signées dans le canal d'échange de données ouvert.
Remarque Y4.2.
Des exemples de mise en œuvre de cette menace sont donnés ci-dessous ici et ici .

U5. Obtention d'un résultat positif de la vérification de la signature électronique de fausses données

Décomposition
U5.1. Les attaquants interceptent un message sur le résultat négatif de la vérification de la signature électronique dans le canal de transmission des résultats du travail et le remplacent par un message avec un résultat positif.

U5.2. Les attaquants mènent une attaque contre la confiance dans les certificats de signature ( SCÉNARIO - tous les éléments sont requis ):
U5.2.1. Les attaquants génèrent une signature électronique de clé publique et privée. Si le système utilise des certificats de clé de signature électronique, ils génèrent un certificat de signature électronique qui est aussi similaire que possible au certificat de l'expéditeur prévu des données dont ils veulent simuler le message.
U5.2.2. Les attaquants apportent des modifications non autorisées à la banque de clés publiques, fournissant à la clé publique générée le niveau de confiance et d'autorité nécessaire.
U5.2.3. Les attaquants signent de fausses données avec une clé de signature électronique générée précédemment et l'injectent dans le canal d'échange de données sécurisé.

U5.3. Les attaquants effectuent une attaque en utilisant les clés expirées d'une signature électronique d'un signataire légal ( SCÉNARIO - tous les éléments sont requis ):
U5.3.1. Les attaquants compromettent les clés privées expirées (non valides actuellement) de la signature électronique de l'expéditeur légitime.
U5.3.2. Les attaquants remplacent l'heure dans le canal de transmission de l'heure par l'heure à laquelle les clés compromises étaient toujours actives.
U5.3.3. Les attaquants signent des données frauduleuses avec une clé de signature électronique précédemment compromise et l'injectent dans le canal d'échange de données sécurisé.

U5.4. Les attaquants effectuent une attaque en utilisant les clés compromises de la signature électronique d'un signataire légal ( SCÉNARIO - tous les éléments sont requis ):
U5.4.1. Les attaquants font une copie du magasin de clés publiques.
U5.4.2. Les attaquants compromettent les clés privées de l'un des expéditeurs légaux. Il remarque un compromis, révoque les clés, des informations sur la révocation de la clé sont placées dans le magasin de clés publiques.
U5.4.3. Les attaquants remplacent la banque de clés publiques par une autre précédemment copiée.
U5.4.4. Les attaquants signent des données frauduleuses avec une clé de signature électronique précédemment compromise et l'injectent dans le canal d'échange de données sécurisé.

U5.5. <...> en raison de la présence d'erreurs dans la mise en œuvre des 2e et 3e étapes de vérification des signatures électroniques:
Explications U5.5.
Un exemple de la mise en œuvre de cette menace est donné ci-dessous .

U5.5.1. Vérification de la confiance dans le certificat de la clé de signature électronique uniquement par la présence de confiance dans le certificat avec lequel elle est signée, sans contrôles CRL ou OCSP.
Explications U.5.5.1.
Exemple de mise en œuvre d'une menace .

U5.5.2. Lors de la création d'une chaîne de confiance pour un certificat, l'autorité de délivrance des certificats n'est pas analysée
Explications U.5.5.2.
Un exemple d'attaque par rapport aux certificats SSL / TLS.
Les attaquants ont acheté un certificat légitime pour leur e-mail. Ensuite, ils ont créé un certificat de site Web frauduleux et l'ont signé avec leur certificat. Si le contrôle d'autorisation n'est pas effectué, alors lors de la vérification de la chaîne de confiance, il sera correct et, par conséquent, un certificat frauduleux sera également correct.

U5.5.3. Lors de la création d'une chaîne d'approbation de certificat, les certificats de révocation intermédiaires ne sont pas vérifiés.

U5.5.4. La liste de révocation de certificats est mise à jour moins fréquemment que l'autorité de certification ne les émet.

U5.5.5. La décision de faire confiance à la signature électronique est prise avant la réception de la réponse OCSP sur le statut du certificat, envoyée à la demande faite plus tard que le temps de générer la signature ou plus tôt que la suivante reçue après la formation de la signature CRL.
Explications U.5.5.5.
Dans la réglementation de la plupart des autorités de certification, l'heure de révocation du certificat est considérée comme l'heure d'émission de la liste de révocation de certificats la plus proche contenant des informations sur la révocation du certificat.

U5.5.6. À la réception des données signées, la propriété du certificat à l'expéditeur n'est pas vérifiée.
Explications U.5.5.6.
Exemple d'attaque. En ce qui concerne les certificats SSL: l'adresse du serveur appelé peut ne pas être vérifiée pour la valeur du champ CN dans le certificat.
Exemple d'attaque. Les attaquants ont compromis les clés de signature électronique de l'un des participants au système de paiement. Après cela, ils ont piraté le réseau d'un autre participant et envoyé en son nom des documents de paiement signés par des clés compromises au serveur de règlement du système de paiement. Si le serveur analyse uniquement la confiance et ne vérifie pas la conformité, les documents frauduleux seront considérés comme légitimes.

Y6. Acceptation erronée de documents électroniques pour exécution en raison de problèmes d'organisation de la gestion électronique des documents.

Décomposition
U6.1. La partie réceptrice ne détecte pas la duplication des documents reçus.
Explications U6.1.
Exemple d'attaque. Les attaquants peuvent intercepter le document transmis au destinataire, même s'il est protégé cryptographiquement, puis l'envoyer à plusieurs reprises vers le canal de transmission de données sécurisé. Si le destinataire n'identifie pas les doublons, tous les documents reçus seront perçus et traités comme des documents divers.

Y7. Familiarisation non autorisée avec les données protégées lors de leur traitement

Décomposition

U7.1. <...> en raison d'une fuite d'informations sur des canaux tiers (attaque par canal latéral).
Explications U7.1.
Exemple d' attaque .

U7.2. <...> en raison de la neutralisation de la protection contre l'accès non autorisé aux informations traitées au CIPF:
U7.2.1. Fonctionnement du FCPE avec des violations des exigences décrites dans la documentation du FCPE.

U7.2.2. <...> réalisée en raison de la présence de vulnérabilités dans:
U7.2.2.1. <...> protection contre les accès non autorisés.
U7.2.2.2. <...> l'ICSP lui-même.
U7.2.2.3. <...> l'environnement de l'installation de cryptographie

Exemples d'attaque

Les scénarios considérés ci-dessous contiennent évidemment des erreurs d'organisation de la sécurité de l'information et ne servent qu'à illustrer des attaques possibles.

Scénario 1. Un exemple de mise en œuvre des menaces U2.2 et U4.2.

Description de la propriété


Logiciel ARM KBR et SKZI SKAD La signature est installée sur un ordinateur physique qui n'est pas connecté à un réseau informatique. FCN vdToken est utilisé comme support de clé dans le mode de clé non récupérable.

La procédure de calcul suppose que le spécialiste du calcul télécharge les messages électroniques sous forme ouverte (schéma de l'ancien KBR AWP) depuis son ordinateur de travail à partir d'un serveur de fichiers sécurisé spécial, puis les écrit sur la clé USB du support aliéné et les transfère sur le KBR AWP, où il les chiffre et s'inscrit. Après cela, le spécialiste transfère les messages électroniques protégés vers le support aliéné, puis via leur ordinateur de travail, les écrit sur un serveur de fichiers, d'où ils arrivent à UTA puis au système de paiement de la Banque de Russie.

Dans ce cas, les canaux d'échange de données ouvertes et protégées comprendront: un serveur de fichiers, un ordinateur de travail spécialisé et un support aliénable.

Attaque
Les attaquants non autorisés installent un système de télécommande sur l'ordinateur de travail du spécialiste et, au moment d'écrire sur le support aliéné, les ordres de paiement (messages électroniques) remplacent ouvertement le contenu de l'un d'eux. Le spécialiste transfère les ordres de paiement au poste de travail du CBD, les signe et les chiffre sans remarquer la substitution (par exemple, en raison du grand nombre d'ordres de paiement en vol, de la fatigue, etc.). Après cela, un faux ordre de paiement, passant par la chaîne technologique, entre dans le système de paiement de la Banque de Russie.

Scénario 2. Un exemple de mise en œuvre des menaces U2.2 et U4.2.

Description de la propriété


Un ordinateur avec KBR AWARD installé, SCAD Signature et le porte-clés connecté FCN vdToken fonctionne dans une salle dédiée sans accès du personnel.
Le spécialiste des calculs est connecté à l'AWS du CBD en mode d'accès à distance via le protocole RDP.

Attaque
Les attaquants interceptent les détails à l'aide desquels le spécialiste du calcul se connecte et travaille avec KBR AWS (par exemple, en raison d'un code malveillant sur son ordinateur). Une connexion est alors établie en son nom et un faux ordre de paiement est envoyé au système de paiement de la Banque de Russie.

Scénario 3. Exemple d'implémentation de la menace U1.3.

Description de la propriété


Considérez l'une des options hypothétiques pour la mise en œuvre des modules d'intégration ABS-KBR pour le nouveau schéma (AWP KBR-N), dans lequel la signature électronique des documents sortants se produit du côté ABS. Dans le même temps, nous supposons que l'ABS fonctionne sur la base d'un système d'exploitation qui n'est pas pris en charge par la signature SCAD SKAD et, par conséquent, la fonctionnalité cryptographique est transférée vers une machine virtuelle distincte - le module d'intégration ABS-KBR.
En tant que support de clé, un jeton USB standard est utilisé, fonctionnant en mode de clé récupérable. Lors de la connexion du support clé à l'hyperviseur, il s'est avéré qu'il n'y avait pas de ports USB libres dans le système, il a donc été décidé de connecter le jeton USB via un concentrateur réseau USB et d'installer un client USB sur IP sur la machine virtuelle qui communiquera avec le concentrateur.

Attaque
Les attaquants ont intercepté la clé privée de la signature électronique du canal de communication entre le concentrateur USB et l'hyperviseur (les données ont été transmises sous forme ouverte). Possédant une clé privée, les attaquants ont formé un faux ordre de paiement, l'ont signé avec une signature électronique et l'ont envoyé au KBR-N AWP pour exécution.

Scénario 4. Un exemple de mise en œuvre des menaces U5.5.

Description de la propriété
Considérez le même schéma que dans le scénario précédent. Nous considérerons que les messages électroniques reçus du KBR-N AWP iront dans le dossier \\ ... \ SHARE \ In, et ceux envoyés au KBR-N AWP et ensuite au système de paiement de la Banque de Russie iront au \\. .. \ PARTAGER \ sortir.
Nous supposerons également que lors de la mise en œuvre du module d'intégration, les listes de certificats révoqués sont mises à jour uniquement lors de la réémission de clés cryptographiques, et également que les messages électroniques reçus dans le dossier \\ ... \ SHARE \ In sont vérifiés uniquement pour le contrôle d'intégrité et le contrôle de confiance pour l'ouverture clé de signature électronique.

Attaque

Les attaquants, en utilisant les clés volées dans le scénario précédent, ont signé un faux ordre de paiement contenant des informations sur la réception d'argent sur le compte d'un client frauduleux et l'ont injecté dans le canal d'échange de données sécurisé. Étant donné que la vérification que l'ordre de paiement a été signé par la Banque de Russie n'est pas effectuée, il est accepté pour exécution.