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

À propos de l'étude

Liens vers d'autres parties de l'étude

• Sécurité de l'information des paiements bancaires sans espèces. Partie 1 — Fondements économiques.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 2 — Infrastructure informatique standard d'une banque.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 3 — Élaboration des exigences pour le système de protection.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 4 — Revue des normes de modélisation des menaces.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 5 — Plus de 100 liens thématiques sur les piratages bancaires.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 6 — Analyse des crimes bancaires.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 7 — Modèle de menaces de base.
• Sécurité de l'information des paiements bancaires sans espèces. Partie 8 — Modèles typiques de menaces (Vous êtes ici)

Cet article conclut le cycle de publications consacré à la sécurité de l'information des paiements bancaires sans espèces. Ici, nous examinerons les modèles de menaces standards auxquels il a été fait référence dans le modèle de base:

• Modèle standard de menaces. Connexion réseau.
• Modèle standard de menaces. Système d'information basé sur une architecture client-serveur.
• Modèle standard de menaces. Système de contrôle d'accès.
• Modèle standard de menaces. Module d'intégration.
• Modèle standard de menaces. Système de protection cryptographique de l'information.

HABRO-AVERTISSEMENT !!! Chers utilisateurs de Habr, ce n'est pas un post de divertissement.
Cachées dans le texte, plus de 40 pages de matériel sont destinées à aider dans le travail ou les études pour les personnes spécialisées dans le secteur bancaire ou la sécurité de l'information. Ces documents sont le produit final de l'étude et écrits dans un ton formel et neutre. En fait, ce sont des gabarits pour des documents internes sur la sécurité de l'information.

Et la traditionnelle - « l'utilisation des informations de cet article à des fins illégales est punie par la loi ». Bonne lecture !

Informations pour les lecteurs qui découvrent l'étude en commençant par cette publication.

À propos de l'étude

Vous lisez un guide destiné à la personne responsable de la sécurité des paiements dans la banque.

Logique de présentation

Au début, dans partie 1 et la partie 2 une description de l'objet de protection est fournie. Ensuite, dans partie 3 Il est expliqué comment construire un système de protection et la nécessité de former un modèle de menaces. Dans la partie 4 il est discuté des différents types de modèles de menaces et de leur élaboration. Dans la partie 5 et la partie 6 une analyse des attaques réelles est présentée. Partie 7 et la partie 8 contient une description du modèle de menaces construit en tenant compte des informations des parties précédentes.

MODÈLE TYPIQUE DE MENACE. CONNEXION RÉSEAU

L'objet de protection pour lequel le modèle de menace est applicable (scope)

L'objet de protection concerne les données transmises via une connexion réseau fonctionnant dans des réseaux de transmission de données basés sur la pile TCP/IP.

Architecture

Description des éléments de l'architecture :

• «Nœuds finaux» — nœuds échangeant des informations protégées.
• «Nœuds intermédiaires» — éléments du réseau de transmission de données : routeurs, commutateurs, serveurs d'accès, serveurs proxy et autre matériel par lequel le trafic de la 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 finaux).

Menaces de sécurité de haut niveau

Décomposition

U1. Consultation non autorisée des données transmises.
U2. Modification non autorisée des données transmises.
U3. Violation du droit d'auteur des données transmises.

U1. Consultation non autorisée des données transmises

Décomposition
U1.1. , réalisé sur des nœuds finaux ou intermédiaires :
U1.1.1. par la lecture des données pendant leur séjour dans les dispositifs de stockage du nœud :
U1.1.1.1. dans la mémoire vive.
Explications pour U1.1.1.1.
Par exemple, lors du traitement des données par la pile réseau du nœud.

U1.1.1.2. dans la mémoire non volatile.
Explications pour U1.1.1.2.
Par exemple, lors du stockage des données transmises dans le cache, les fichiers temporaires ou les fichiers d'échange.

U1.2. , réalisé sur des nœuds tiers du réseau de transmission de données :
U1.2.1. par la capture de tous les paquets arrivant sur l'interface réseau du nœud :
Explications pour U1.2.1.
La capture de tous les paquets est effectuée en mettant la carte réseau en mode indifférent (mode promiscuous pour les adaptateurs filaires ou en mode moniteur pour les adaptateurs wi-fi).

U1.2.2. en réalisant des attaques de type «homme du milieu (MiTM)», mais sans modification des données transmises (à l'exception des données de contrôle des protocoles réseau).
U1.2.2.1. Lien : «Modèle typique de menaces. Connexion réseau. U2. Modification non autorisée des données transmises».

U1.3. , réalisée par le biais de fuites d'informations via des canaux techniques (TKUI) depuis des nœuds physiques ou des lignes de communication.

U1.4. , réalisée par l'installation sur des nœuds finaux ou intermédiaires de moyens techniques spéciaux (STS) destinés à la capture secrète d'informations.

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

Décomposition
U2.1. , réalisée sur des nœuds finaux ou intermédiaires :
U2.1.1. par la lecture et la modification des données pendant leur présence dans les dispositifs de mémoire des nœuds :
U2.1.1.1. dans la mémoire vive :
U2.1.1.2. dans la mémoire non volatile :

U2.2. , réalisée sur des nœuds tiers du réseau de transmission de données :
U2.2.1. par la mise en œuvre d'attaques de type « homme du milieu (MiTM) » et le détournement de trafic vers le nœud des attaquants :
U2.2.1.1. Connexion physique de l'équipement des attaquants dans la rupture de la connexion réseau.
U2.2.1.2. Réalisation d'attaques sur les protocoles réseau :
U2.2.1.2.1. gestion des réseaux locaux virtuels (VLAN) :
U2.2.1.2.1.1. VLAN hopping.
U2.2.1.2.1.2. Modification non autorisée des paramètres VLAN sur les commutateurs ou routeurs.
U2.2.1.2.2. routage du trafic :
U2.2.1.2.2.1. Modification non autorisée des tables de routage statiques des routeurs.
U2.2.1.2.2.2. Annonce par les attaquants de chemins frauduleux via des protocoles de routage dynamique.
U2.2.1.2.3. configuration automatique :
U2.2.1.2.3.1. Rogue DHCP.
U2.2.1.2.3.2. Rogue WPAD.
U2.2.1.2.4. adressage et résolution des noms :
U2.2.1.2.4.1. Spoofing ARP.
U2.2.1.2.4.2. Spoofing DNS.
U2.2.1.2.4.3. Modifications non autorisées des fichiers locaux de noms d'hôtes (hosts, lmhosts, etc.)

U3. Violation des droits d'auteur des données transmises

Décomposition
U3.1. Neutralisation des mécanismes de détermination de la paternité de l'information en fournissant des informations frauduleuses sur l'auteur ou la source des données :
U3.1.1. Modification des informations sur l'auteur contenues dans les données 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. Référence : «Modèle typique de menaces. Système de protection cryptographique de l'information.
U4. Création d'une signature électronique d'un signataire légitime sous des données frauduleuses».
U3.1.1.2. Neutralisation de la protection des droits d'auteur des données transmises, mise en œuvre par des codes de confirmation à usage unique :
U3.1.1.2.1. SIM swap.

U3.1.2. Modification des informations sur la source des données transmises :
U3.1.2.1. IP spoofing.
U3.1.2.2. MAC spoofing.

MODÈLE TYPE DE MENACE. SYSTÈME D'INFORMATION CONSTRUIT SUR UNE ARCHITECTURE CLIENT-SERVEUR

L'objet de protection pour lequel le modèle de menace est applicable (scope)

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

Architecture


Description des éléments de l'architecture :

• « Client » – dispositif sur lequel fonctionne la partie client du système d'information.
• « Serveur » – dispositif sur lequel fonctionne la partie serveur du système d'information.
• « Stockage de données » – partie de l'infrastructure serveur du système d'information, destinée à stocker les données traitées par le système d'information.
• « Connexion réseau » – canal d'échange d'informations entre le Client et le Serveur, passant par le réseau de transmission des données. Une description plus détaillée du modèle d'élément est fournie dans « Modèle type de menaces. Connexion réseau ».

Restrictions
Lors de la modélisation de l'objet, les limitations suivantes ont été établies :

1. L'utilisateur interagit avec le système d'information dans des intervalles de temps définis, appelés sessions de travail.
2. Au début de chaque session de travail, l'identification, l'authentification et l'autorisation de l'utilisateur ont lieu.
3. Toutes les informations protégées sont stockées sur la partie serveur du système d'information.

Menaces de sécurité de haut niveau

Décomposition
U1. Actions non autorisées réalisées par des malfaiteurs au nom d'un utilisateur légitime.
U2. Modification non autorisée des informations protégées pendant leur traitement par la partie serveur du système d'information.

U1. Actions non autorisées réalisées par des malfaiteurs au nom d'un utilisateur légitime

Explications
En général, dans les systèmes d'information, l'association des actions à l'utilisateur ayant effectué celles-ci est réalisée par :

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

En ce qui concerne la session de travail, cette menace peut être décomposée en :

1. exécutées dans le cadre de la session de travail de l'utilisateur.
2. exécutées en dehors de la session de travail de l'utilisateur.

La session de travail de l'utilisateur peut être initiée par :

1. L'utilisateur lui-même.
2. Des malfaiteurs.

À ce stade, la décomposition intermédiaire de cette menace apparaîtra comme suit :
U1.1. Actions non autorisées effectuées dans le cadre de la session de travail de l'utilisateur :
U1.1.1. , installé par l'utilisateur attaqué.
U1.1.2. , installé par des malfaiteurs.
U1.2. Actions non autorisées effectuées en dehors de la session de travail de l'utilisateur.

Du point de vue des objets de l'infrastructure d'information sur lesquels les malfaiteurs peuvent agir, la décomposition des menaces intermédiaires apparaîtra comme suit :

Éléments
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. Actions non autorisées effectuées dans le cadre de la session de travail de l'utilisateur :
U1.1.1. , installé par l'utilisateur attaqué :
U1.1.1.1. Les malfaiteurs ont agi directement à partir du Client :
U1.1.1.1.1 Les malfaiteurs ont utilisé les moyens d'accès standards du système d'information :
U1.1.1.1.1.1. Les malfaiteurs ont utilisé les dispositifs d'entrée/sortie physiques du Client (clavier, souris, moniteur ou écran tactile d'un appareil mobile) :
U1.1.1.1.1.1.1. Les malfaiteurs ont agi pendant les périodes où la session est active, les dispositifs d'entrée/sortie sont accessibles, et l'utilisateur n'est pas présent.
U1.1.1.1.1.2. Les malfaiteurs ont utilisé des outils d'administration distante (standards ou fournis par des logiciels malveillants) pour contrôler le Client :
U1.1.1.1.1.2.1. Les malfaiteurs ont agi pendant les périodes où la session est active, les dispositifs d'entrée/sortie sont accessibles, et l'utilisateur n'est pas présent.
U1.1.1.1.1.2.2. Les malfaiteurs ont utilisé des outils d'administration distante dont le fonctionnement est imperceptible pour l'utilisateur attaqué.
U1.1.1.2. Les malfaiteurs ont modifié les données dans la connexion réseau entre le Client et le Serveur, en les modifiant de manière à ce qu'elles soient perçues comme des actions d'un utilisateur légitime :
U1.1.1.2.1. Lien : «Modèle typique de menaces. Connexion réseau. U2. Modification non autorisée des données transmises».
U1.1.1.3. Les malfaiteurs ont contraint l'utilisateur à exécuter les actions qu'ils avaient spécifiées en utilisant des méthodes d'ingénierie sociale.

U1.1.2 installé par des malfaiteurs :
U1.1.2.1. Les malfaiteurs ont agi à partir du Client (Et):
U1.1.2.1.1. Les malfaiteurs ont neutralisé le système de contrôle d'accès du système d'information :
U1.1.2.1.1.1. Lien : «Modèle standard de menaces. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légitime».
U1.1.2.1.2. Des cybercriminels ont utilisé des moyens d'accès standards au système d'information
U1.1.2.2. Des cybercriminels ont agi à partir d'autres nœuds du réseau de transmission de données, à partir desquels une connexion réseau avec le Serveur peut être établie (Et):
U1.1.2.2.1. Des cybercriminels ont neutralisé le système de contrôle d'accès du système d'information :
U1.1.2.2.1.1. Lien : «Modèle standard de menaces. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légitime».
U1.1.2.2.2. Des cybercriminels ont utilisé des moyens d'accès non standards au système d'information.
Explications U1.1.2.2.2.
Des cybercriminels ont pu installer un client standard du système d'information sur un nœud externe ou ont pu utiliser un logiciel non standard réalisant les protocoles d'échange standards entre le Client et le Serveur.

U1.2 Des actions non autorisées ont été effectuées en dehors de la session de travail de l'utilisateur.
U1.2.1 Des cybercriminels ont effectué des actions non autorisées, puis ont apporté des modifications non autorisées aux journaux de fonctionnement du système d'information ou aux attributs spéciaux des objets de données, indiquant que leurs actions avaient été effectuées par un utilisateur légitime.

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

Décomposition
U2.1. Des cybercriminels modifient des informations protégées en utilisant des moyens standards du système d'information et effectuent cela au nom d'un utilisateur légitime.
U2.1.1. Lien : «Modèle standard de menaces. Système d'information basé sur une architecture client-serveur. U1. Actions non autorisées effectuées par des cybercriminels au nom d'un utilisateur légitime».

U2.2. Des cybercriminels modifient des informations protégées en utilisant des mécanismes d'accès aux données non prévus par le mode de fonctionnement standard du système d'information.
U2.2.1. Des cybercriminels 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. par la provocation de la restauration de fichiers à partir d'une sauvegarde modifiée sans autorisation.

U2.2.2. Des cybercriminels modifient des informations protégées stockées dans la base de données (Et):
U2.2.2.1. Les attaquants neutralisent le système de contrôle d'accès de la SGBD :
U2.2.2.1.1. Lien : «Modèle standard de menaces. Système de contrôle d'accès. U1. Établissement non autorisé d'une session de travail au nom d'un utilisateur légitime».
U2.2.2.2. Les attaquants modifient les informations en utilisant les interfaces standard de la SGBD pour accéder aux données.

U2.3. Les attaquants modifient les informations protégées par la modification non autorisée des algorithmes de fonctionnement du logiciel qui les traite.
U2.3.1. Le code source du logiciel est modifié.
U2.3.1. Le code machine du logiciel est modifié.

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

U2.5. Les attaquants modifient les informations protégées lors de leur transmission 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 : «Modèle typique de menaces. Connexion réseau. U2. Modification non autorisée des données transmises».

MODÈLE TYPE DE MENACE. SYSTÈME DE CONTRÔLE D'ACCÈS

L'objet de protection pour lequel le modèle de menace est applicable (scope)

L'objet de protection auquel ce modèle de menace s'applique correspond à l'objet de protection du modèle de menace : « Modèle type de menace. Système d'information basé sur une architecture client-serveur ».

Le système de contrôle d'accès des utilisateurs dans ce modèle de menace fait référence à un composant du système d'information qui réalise les fonctions suivantes :

1. Identification des utilisateurs.
2. Authentification des utilisateurs.
3. Autorisation des utilisateurs.
4. Journalisation des actions des utilisateurs.

Menaces de sécurité de haut niveau

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

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

Explications
La décomposition de cette menace dépendra en général du type de systèmes d'identification et d'authentification des utilisateurs utilisés.

Dans ce modèle, seul le système d'identification et d'authentification des utilisateurs utilisant un login et un mot de passe textuels sera examiné. Nous considérerons que le login de l'utilisateur est une information publique, connue des attaquants.

Décomposition
U1.1. par la compromission des informations d'identification :
U1.1.1. Les attaquants ont compromis les informations d'identification de l'utilisateur lors de leur stockage.
Explications U1.1.1.
Par exemple, les informations d'identification auraient pu être écrites sur un post-it collé au moniteur.

U1.1.2. L'utilisateur a accidentellement ou intentionnellement transmis ses identifiants d'accès à des tiers malveillants.
U1.1.2.1. L'utilisateur a prononcé à haute voix ses identifiants lors de leur saisie.
U1.1.2.2. L'utilisateur a volontairement transmis ses identifiants :
U1.1.2.2.1. à ses collègues de travail.
Explications U1.1.2.2.1.
Par exemple, pour qu'ils puissent le remplacer pendant son absence pour maladie.

U1.1.2.2.2. à des tiers liés à l'employeur, exécutant des travaux sur des infrastructures d'information.
U1.1.2.2.3. à des tiers.
Explications U1.1.2.2.3.
Une des aberrations, mais pas la seule, de cette menace est l'utilisation des techniques d'ingénierie sociale par les malfaiteurs.

U1.1.3. Les malfaiteurs ont deviné les identifiants par force brute :
U1.1.3.1. en utilisant des mécanismes d'accès standards.
U1.1.3.2. à partir de codes précédemment interceptés (par exemple, des hachages de mots de passe) de stockage d'identifiants.

U1.1.4. Les malfaiteurs ont utilisé un code malveillant pour intercepter les identifiants de l'utilisateur.

U1.1.5. Les malfaiteurs ont extrait les identifiants d'une connexion réseau entre le Client et le Serveur :
U1.1.5.1. Lien : «Modèle de menace typique. Connexion réseau. U1. Accès non autorisé aux données transmises».

U1.1.6. Les malfaiteurs ont extrait les identifiants à partir des enregistrements des systèmes de surveillance du travail :
U1.1.6.1. des systèmes de surveillance vidéo (si, pendant le travail, les frappes sur le clavier étaient enregistrées).
U1.1.6.2. des systèmes de contrôle des actions des employés sur les ordinateurs.
Explications U1.1.6.2.
Un exemple de ce type de système est — StuffCop.

U1.1.7. Les malfaiteurs ont compromis les identifiants de l'utilisateur en raison de lacunes dans leur processus de transmission.
Explications U1.1.7.
Par exemple, la transmission de mots de passe en texte clair par e-mail.

U1.1.8. Les malfaiteurs ont découvert les identifiants en observant la session de travail de l'utilisateur via des systèmes d'administration à distance.

U1.1.9. Les malfaiteurs ont extrait les identifiants à la suite de leur fuite par voies techniques (TCLI) :
U1.1.9.1. Les malfaiteurs ont observé comment l'utilisateur saisissait les identifiants via le clavier :
U1.1.9.1.1 Les malfaiteurs se trouvaient à proximité de l'utilisateur et ont vu la saisie des identifiants de leurs propres yeux.
Explications U1.1.9.1.1
Les actions des collègues au travail ou le cas où le clavier de l'utilisateur est visible aux visiteurs de l'organisation peuvent être considérés comme de tels cas.

U1.1.9.1.2 Les cybercriminels ont utilisé des moyens techniques supplémentaires, tels qu'une jumelle ou un drone, et ont observé la saisie des identifiants à travers une fenêtre.
U1.1.9.2. Les cybercriminels ont extrait des informations d'identification à partir des enregistrements de radio communication entre le clavier et l'unité centrale de l'ordinateur en se connectant via un interface radio (par exemple, Bluetooth).
U1.1.9.3. Les cybercriminels ont intercepté des informations d'identification grâce à leur fuite par le biais de canaux d'émissions électromagnétiques secondaires et d'interférences (PEM).
Explications U1.1.9.3.
Exemples d'attaque ici et ici.

U1.1.9.4. Le cybercriminel a intercepté la saisie des informations d'identification à partir du clavier en utilisant des dispositifs techniques spéciaux (DTS) conçus pour la collecte clandestine d'informations.
Explications U1.1.9.4.
Exemples dispositifs.

U1.1.9.5. Les cybercriminels ont intercepté la saisie des informations d'identification à partir du clavier grâce à
l'analyse du signal Wi-Fi modulé par le processus de frappe des touches par l'utilisateur.
Explications U1.1.9.5.
Exemple les attaques.

U1.1.9.6. Les cybercriminels ont intercepté la saisie des informations d'identification à partir du clavier en analysant les sons des frappes sur les touches.
Explications U1.1.9.6.
Exemple les attaques.

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

U1.1.10. , préalablement sauvegardées chez le Client.
Explications U1.1.10.
Par exemple, l'utilisateur a pu sauvegarder dans le navigateur un identifiant et un mot de passe pour accéder à un site spécifique.

U1.1.11. Les cybercriminels ont compromis les informations d'identification en raison de lacunes dans le processus de révocation des accès des utilisateurs.
Explications U1.1.11.
Par exemple, après le départ d'un utilisateur, ses comptes sont restés déverrouillés.

U1.2. grâce à l'exploitation des vulnérabilités dans le système de contrôle d'accès.

U2. Élévation de privilèges non autorisée d'un utilisateur dans le système d'information.

Décomposition
U2.1 en effectuant des modifications non autorisées dans les données contenant des informations sur les privilèges de l'utilisateur.

U2.2 grâce à l'exploitation des vulnérabilités dans le système de contrôle d'accès.

U2.3. en raison de lacunes dans le processus de gestion des accès des utilisateurs.
Explications U2.3.
Exemple 1. Un utilisateur a eu accès à plus que ce qui était nécessaire pour ses fonctions professionnelles.
Exemple 2. Après le transfert d'un utilisateur à un autre poste, les droits d'accès précédemment accordés n'ont pas été révoqués.

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

L'objet de protection pour lequel le modèle de menace est applicable (scope)

Le module d'intégration est un ensemble d'objets d'infrastructure d'information destiné à 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 clairement un système d'information d'un autre, le module d'intégration peut également être considéré comme un lien entre les composants au sein d'un même système d'information.

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

Description des éléments de l'architecture :

• «Serveur d'échange (SE)» – nœud / service / composant d'un système d'information, effectuant la fonction d'échange de données avec un autre système d'information.
• «Intermédiaire» – nœud / service, destiné à organiser l'interaction entre les systèmes d'information, mais ne faisant pas partie de ceux-ci.
  Des exemples «Intermédiaires» peuvent inclure des services de messagerie électronique, des bus de services d'entreprise (enterprise service bus / architecture SoA), des serveurs de fichiers tiers, etc. En général, le module d'intégration peut ne pas contenir d'«Intermédiaires».
• «Logiciel de traitement des données» – ensemble de programmes réalisant des protocoles d'échange de données et la transformation de formats.
  Par exemple, transformation des données du format UFEBS en format ABS, modification des statuts des messages au cours du transfert, etc.
• « Connexion réseau » correspond à l'objet décrit dans le modèle typique de menace «Connexion réseau». Certaines connexions réseau figurant sur le schéma ci-dessus peuvent ne pas exister.

Exemples de modules d'intégration

Schéma 1. Intégration ABS et ARM KBR via un serveur de fichiers tiers

Pour exécuter les paiements, un employé autorisé de la banque extrait des documents de paiement électroniques d'ABS et les enregistre dans un fichier (dans un format propre, par exemple, un dump SQL) sur un dossier réseau (…SHARE) du serveur de fichiers. Ce fichier est ensuite transformé en un ensemble de fichiers au format UFEBS à l'aide d'un script de conversion, qui est ensuite lu par l'ARM KBR.
Après cela, l'employé autorisé — utilisateur de l'ARM KBR — crypte et signe le fichier reçu et l'envoie au système de paiement de la Banque de Russie.

Lors de la réception des paiements de la Banque de Russie, l'ARM KBR effectue le décryptage et la vérification de la signature électronique, puis enregistre sous forme d'un ensemble de fichiers au format UFÉBS sur le serveur de fichiers. Avant l'importation des documents de paiement dans l'ABS, ils sont convertis à l'aide d'un script de conversion du format UFÉBS au format ABS.

Considérons que dans ce schéma, l'ABS fonctionne sur un serveur physique, l'ARM KBR fonctionne sur un ordinateur dédié, et le script de conversion fonctionne sur le serveur de fichiers.

La correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
« Serveurs d'échange côté ABS » – serveur ABS.
« Serveurs d'échange côté ARM KBR » – ordinateur ARM KBR.
«Intermédiaire» – serveur de fichiers tiers.
«Logiciel de traitement des données» – script de conversion.

Schéma 2. Intégration de l'ABS et de l'ARM KBR lors de la mise en place d'un dossier réseau commun avec les paiements sur l'ARM KBR

Tout est similaire au Schéma 1, mais un serveur de fichiers distinct n'est pas utilisé, à la place, un dossier réseau (…SHARE) contenant des documents de paiement électroniques est placé sur l'ordinateur de l'ARM KBR. Le script de conversion fonctionne également sur l'ARM KBR.

La 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 «Intermédiaire» n'est pas utilisé.

Schéma 3. Intégration de l'ABS et de l'ARM KBR-N via IBM WebSphere MQ et signature des documents électroniques « côté ABS »

L'ABS fonctionne sur une plateforme non supportée par le SKZI SKAD Signature. La signature des documents électroniques sortants est effectuée sur un serveur de signature électronique spécial (Serveur EP). Ce même serveur vérifie la signature électronique des documents entrants de la Banque de Russie.

L'ABS télécharge sur le Serveur EP un fichier contenant des documents de paiement dans son format propre.
Le Serveur EP, à l'aide d'un script de conversion, transforme le fichier en messages électroniques au format UFÉBS, après quoi les messages électroniques sont signés et transmis à IBM WebSphere MQ.

L'ARM KBR-N se connecte à IBM WebSphere MQ et reçoit de là des messages de paiement signés, après quoi l'employé autorisé — utilisateur de l'ARM KBR — les crypte et les envoie au système de paiement de la Banque de Russie.

Lors de la réception des paiements de la Banque de Russie, l'ARM 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 UFEBS sont transmis à IBM WebSphere MQ, d'où le Serveur EP les reçoit.

Le Serveur EP vérifie la signature électronique des paiements reçus et les enregistre dans un fichier au format ABS. Ensuite, un employé autorisé — utilisateur de l'ABS — télécharge le fichier obtenu dans l'ABS selon la procédure établie.

La correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
«Serveur d'échange côté ABS» – serveur ABS.
«Serveur d'échange côté ARM KBR» — ordinateur ARM KBR.
«Intermédiaire» – Serveur EP et IBM WebSphere MQ.
«Logiciel de traitement des données» – script de conversion, SKZI SKAD Signature sur le Serveur EP.

Schéma 4. Intégration du Serveur DBO et de l'ABS via l'API fournie par le serveur d'échange dédié

Considérons que plusieurs systèmes de services bancaires à distance (DBO) sont utilisés à la banque :

• «Client-Banque Internet» pour les particuliers (IKB FL);
• «Client-Banque Internet» pour les personnes morales (IKB UL).

Afin d'assurer la sécurité de l'information, toute interaction de l'ABS avec les systèmes DBO se fait via un serveur d'échange dédié, fonctionnant dans le cadre du système d'information «ABS».

Examinons ensuite le processus d'interaction entre le système DBO IKB UL et l'ABS.
Le Serveur DBO, ayant reçu de la part du client une commande de paiement dûment certifiée, doit créer le document correspondant dans l'ABS sur cette base. Pour cela, il transmet les informations au serveur d'échange via l'API, et celui-ci, à son tour, intègre les données dans l'ABS.

Lors de la modification des soldes sur le compte du client, l'ABS génère des notifications électroniques, qui sont transférées au serveur DBO via le serveur d'échange.

La correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
«Serveur d'échange côté DBO» – serveur DBO IKB UL.
«Serveur d'échange côté ABS» – serveur d'échange.
«Intermédiaire» – absent.
«Logiciel de traitement des données» – composants du Serveur DBO, responsables de l'utilisation de l'API du serveur d'échange, composants du serveur d'échange, responsables de l'utilisation de l'API de l'ABS.

Menaces de sécurité de haut niveau

Décomposition
U1. Introduction de fausses informations par des malfaiteurs via le module d'intégration.

U1. Introduction de fausses informations par des malfaiteurs via le module d'intégration

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

U1.2. Transmission via des canaux de communication de fausses données au nom d'un participant légitime à l'échange :
U1.1.2 Lien : «Modèle standard de menace. Connexion réseau. U3. Violation des droits d'auteur des données transmises».

U1.3. Modification non autorisée de données légitimes lors de leur traitement sur les serveurs d'échange ou par l'intermédiaire :
U1.3.1. Lien : «Modèle standard de menace. Système d'information basé sur une architecture client-serveur. U2. Modification non autorisée d'informations protégées pendant leur traitement par la partie serveur du système d'information».

U1.4. Création de données fictives sur les serveurs d'échange ou par l'intermédiaire au nom d'un participant légitime à l'échange :
U1.4.1. Lien : «Modèle standard de menace. Système d'information basé sur une architecture client-serveur. U1. Actions non autorisées effectuées par des malfaiteurs au nom d'un utilisateur légitime».

U1.5. Modification non autorisée des données lors de leur traitement à l'aide de logiciels de traitement de données :
U1.5.1. par des modifications non autorisées apportées par des malfaiteurs aux paramètres (configuration) des logiciels de traitement de données.
U1.5.2. par des modifications non autorisées apportées par des malfaiteurs aux fichiers exécutables des logiciels de traitement de données.
U1.5.3. par la gestion interactive des logiciels de traitement des données par des malfaiteurs.

MODÈLE STANDARD DE MENACE. SYSTÈME DE PROTECTION CRYPTOGRAPHIQUE DE L'INFORMATION

L'objet de protection pour lequel le modèle de menace est applicable (scope)

L'objet de protection est le système de protection cryptographique de l'information, utilisé pour assurer la sécurité d'un système d'information.

Architecture
La base de tout système d'information est le logiciel applicatif (SA) qui réalise sa fonctionnalité ciblée.

La protection cryptographique est généralement mise en œuvre par l'appel, depuis la logique métier du logiciel applicatif, de primitives cryptographiques qui sont placées dans des bibliothèques spécialisées – noyaux cryptographiques.

Les primitives cryptographiques comprennent des fonctions cryptographiques de bas niveau telles que :

• chiffrer/déchiffrer un bloc de données ;
• créer/vérifier une signature électronique d'un bloc de données ;
• calculer une fonction de hachage pour un bloc de données ;
• former/télécharger/exporter des informations clés ;
• etc.

La logique métier du logiciel applicatif utilise des primitives cryptographiques pour réaliser une fonctionnalité de niveau supérieur :

• chiffrer un fichier avec les clés des destinataires sélectionnés ;
• établir une connexion réseau sécurisée;
• informer des résultats de la vérification de la signature électronique;
• etc.

L'interaction entre la logique métier et le noyau cryptographique peut se faire :

• directement, en appelant les primitives cryptographiques du noyau cryptographique à partir de bibliothèques dynamiques (.DLL pour Windows, .SO pour Linux);
• indirectement, via des interfaces cryptographiques – des wrappers, par exemple, MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. Dans ce cas, la logique métier s'adresse à l'interface cryptographique, qui traduit l'appel vers le noyau cryptographique correspondant, qui est alors appelé fournisseur cryptographique. L'utilisation d'interfaces cryptographiques permet aux logiciels d'application de s'abstraire des algorithmes cryptographiques spécifiques et d'être plus flexibles.

On peut distinguer deux schémas types d'organisation du noyau cryptographique :

Schéma 1 – Noyau cryptographique monolithique


Schéma 2 – Noyau cryptographique partitionné


Les éléments des schémas présentés peuvent être soit des modules logiciels séparés fonctionnant sur un même ordinateur, soit des services réseau interagissant au sein d'un réseau de calcul.

Dans les systèmes construits selon le schéma 1, le logiciel d'application et le noyau cryptographique fonctionnent dans un cadre unique de fonctionnement des moyens cryptographiques (SFC), par exemple, sur le même ordinateur, sous la même système d'exploitation. L'utilisateur du système peut généralement exécuter dans ce même cadre de fonctionnement d'autres programmes, y compris ceux contenant un code malveillant. Dans de telles conditions, il existe un risque sérieux de fuite de clés cryptographiques secrètes.

Pour minimiser le risque, on utilise le schéma 2, où le noyau cryptographique est divisé en deux parties :

1. La première partie fonctionne avec le logiciel d'application dans un environnement non fiable, où existe un risque d'infection par un code malveillant. Appelons cette partie – « partie logicielle ».
2. La deuxième partie fonctionne dans un environnement de confiance sur un appareil dédié, qui contient un stockage des clés secrètes. Appelons cette partie – « partie matérielle ».

La séparation du cœur cryptographique en parties logicielle et matérielle est très conditionnelle. Sur le marché, il existe des systèmes construits selon un schéma avec cœur cryptographique séparé, mais dont la partie « matérielle » est représentée sous la forme d'une image de machine virtuelle — virtual HSM (exemple).

L'interaction entre les deux parties du cœur cryptographique se fait 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 par du code malveillant.

L'interface d'interaction (API) et l'ensemble des primitives cryptographiques fournies au logiciel applicatif par le cœur cryptographique sont identiques dans les deux cas. La différence réside dans leur mode de mise en œuvre.

Ainsi, lors de l'utilisation d'un schéma avec cœur cryptographique séparé, l'interaction entre la partie logicielle et la partie matérielle se fait selon le principe suivant :

1. Les primitives cryptographiques ne nécessitant pas l'utilisation de la clé privée (par exemple, le calcul de la fonction de hachage, la vérification de la signature électronique, etc.) sont exécutées par la partie logicielle.
2. Les primitives cryptographiques utilisant la clé privée (création de la signature électronique, déchiffrement des données, etc.) sont exécutées par la partie matérielle.

Illustrons le fonctionnement du cœur cryptographique séparé par exemple de la création d'une signature électronique :

1. La partie logicielle calcule la fonction de hachage des données à signer et transmet cette valeur à la partie matérielle via un canal d'échange entre les cœurs cryptographiques.
2. La partie matérielle, en utilisant la clé privée et le hachage, forme la valeur de la signature électronique et la transmet à la partie logicielle via le canal d'échange.
3. La partie logicielle retourne la valeur obtenue au logiciel applicatif.

Caractéristiques de la vérification de l'exactitude de la signature électronique

Lorsque la partie réceptrice reçoit des données signées par une signature électronique, elle doit passer par plusieurs étapes de vérification. Un résultat positif de la vérification de la signature électronique n'est atteint qu'après le passage réussi de toutes les étapes de vérification.

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

Contenu de l'étape. Une vérification de la signature électronique des données est effectuée selon l'algorithme cryptographique correspondant. Le succès de cette étape indique que les données n'ont pas été modifiées depuis leur signature et que la signature a été effectuée avec la clé privée correspondante à la clé publique de vérification de la signature électronique.
Lieu d'exécution de l'étape : noyau cryptographique.

É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 signature électronique.
Contenu de l'étape. L'étape consiste en deux sous-étapes intermédiaires. La première vérifie si la clé publique de vérification de la signature électronique était de confiance au moment de la signature des données. La seconde vérifie si la clé privée de signature électronique était valide au moment de la signature des données. En général, les durées de validité de ces clés peuvent ne pas coïncider (par exemple, pour les certificats qualifiés des clés de vérification de signature électronique). Les méthodes d'établissement de la confiance dans la clé publique du signataire sont déterminées par les règles de la circulation électronique des documents adoptées par les parties en interaction.
Lieu d'exécution de l'étape : logiciel applicatif / noyau cryptographique.

Étape 3. Contrôle des pouvoirs du signataire.
Contenu de l'étape. Conformément aux règles établies de la circulation électronique des documents, il est vérifié si le signataire avait le droit de certifier les données protégées. Prenons par exemple une situation de violation des pouvoirs. Supposons qu'il existe une organisation où tous les employés ont une signature électronique. Un ordre du directeur, signé avec la signature électronique du responsable de l'entrepôt, arrive dans le système interne de circulation électronique des documents. En conséquence, un tel document ne peut pas être considéré comme légitime.
Lieu d'exécution de l'étape : logiciel applicatif.

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

1. Les canaux de transmission d'informations, à l'exception des canaux d'échange de clés, passent notamment par le logiciel applicatif, l'API et le noyau cryptographique.
2. Les informations sur la confiance dans les clés publiques et (ou) les certificats, ainsi que les informations sur les pouvoirs des propriétaires des clés publiques, sont stockées dans un dépôt de clés publiques.
3. Le logiciel applicatif interagit avec le dépôt de clés publiques à travers le noyau cryptographique.

Exemple d'un système d'information protégé par un Systèmes de Cryptographie à Clé Publique (SKZI).

Pour illustrer les schémas présentés précédemment, examinons un système d'information hypothétique et mettons en évidence tous ses éléments structuraux.

Description du système d'information

Deux organisations ont décidé de mettre en place un échange de documents électroniques (EDE) juridiquement significatif entre elles. Pour ce faire, elles ont conclu un accord stipulant que les documents seront transmis par e-mail, et qu'ils devront être cryptés et signés avec une signature électronique qualifiée. Les programmes de bureau du pack Microsoft Office 2016 seront utilisés pour la création et le traitement des documents, tandis que les moyens de protection cryptographique seront fournis par le système de protection de l'information CryptPro et le logiciel de chiffrement CryptoARM.

Description de l'infrastructure de l'organisation 1

L'organisation 1 a décidé d'installer le système de protection de l'information CryptPro et le logiciel CryptoARM sur le poste de travail de l'utilisateur — un ordinateur physique. Les clés de chiffrement et de signature électronique seront stockées sur un support clé ruToken, fonctionnant en mode clé amovible. L'utilisateur préparera les documents électroniques localement sur son ordinateur, puis les chiffrera, les signera et les enverra à l'aide d'un client de messagerie installé localement.

Description de l'infrastructure de l'organisation 2

L'organisation 2 a décidé de déporter les fonctions de chiffrement et de signature électronique sur une machine virtuelle dédiée. Toutes les opérations cryptographiques seront effectuées automatiquement.

Pour cela, deux dossiers réseau ont été organisés sur la machine virtuelle dédiée : «…In», «…Out». Les fichiers reçus du partenaire commercial seront automatiquement placés dans le dossier réseau «…In» sous leur forme ouverte. Ces fichiers seront déchiffrés et leur signature électronique sera vérifiée.

Dans le dossier «…Out», l'utilisateur placera les fichiers qui doivent être chiffrés, signés et envoyés au partenaire commercial. Les fichiers eux-mêmes seront préparés sur le poste de travail de l'utilisateur.
Pour effectuer les fonctions de chiffrement et de signature électronique, le système de protection de l'information CryptPro, le logiciel CryptoARM et le client de messagerie ont été installés sur la machine virtuelle. La gestion automatique de tous les éléments de la machine virtuelle sera assurée par des scripts développés par les administrateurs système. Le fonctionnement des scripts est enregistré dans des fichiers journaux (logs).

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

Le jeton sera transféré sur la machine virtuelle à l'aide de logiciels spécialisés USB-over-IP, installés sur le poste de travail de l'utilisateur et sur la machine virtuelle.

Les horloges système sur le poste de travail de l'utilisateur dans l'organisation 1 seront ajustées manuellement. Les horloges système de la machine virtuelle dans l'organisation 2 seront synchronisées avec les horloges système de l'hyperviseur, elles-mêmes synchronisées via Internet avec des serveurs de temps publics.

Identification des éléments structurels du SKZI
Sur la base de la description ci-dessus de l'infrastructure IT, identifions les éléments structurels du SKZI et consignons-les dans un tableau.

Tableau - Correspondance entre les éléments du modèle SKZI et les éléments des systèmes d'information

Nom de l'élément
Organisation 1
Organisation 2

Logiciel applicatif
Logiciel CryptoARM
Logiciel CryptoARM

Partie logicielle du noyau cryptographique
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP

Partie matérielle du noyau cryptographique
absente
JaCarta GOST

API
MS CryptoAPI
MS CryptoAPI

Dépôt de clés publiques
Poste de travail de l'utilisateur:
— disque dur;
— dépôt standard de certificats Windows.
Hyperviseur:
— disque dur.

Machine virtuelle:
— disque dur;
— dépôt standard de certificats Windows.

Dépôt de clés privées
Support de clé ruToken, fonctionnant en mode de clé extractible
Support de clé JaCarta GOST, fonctionnant en mode de clé non extractible

Canal d'échange de clés publiques
Poste de travail de l'utilisateur:
— mémoire vive.

Hyperviseur:
— mémoire vive.

Machine virtuelle:
— mémoire vive.

Canal d'échange de clés privées
Poste de travail de l'utilisateur:
— bus USB;
— mémoire vive.
absente

Canal d'échange entre les noyaux cryptographiques
absent (pas de partie matérielle du noyau cryptographique)
Poste de travail de l'utilisateur:
— bus USB;
— mémoire vive;
— module logiciel USB-over-IP;
— interface réseau.

Réseau d'entreprise de l'organisation 2.

Hyperviseur:
— mémoire vive;
— interface réseau.

Machine virtuelle:
— interface réseau;
— mémoire vive;
— module logiciel USB-over-IP.

Canal d'échange de données publiques
Poste de travail de l'utilisateur:
— moyens d'entrée-sortie;
— mémoire vive;
— disque dur.
Poste de travail de l'utilisateur:
— moyens d'entrée-sortie;
— mémoire vive;
— disque dur;
— interface réseau.

Réseau d'entreprise de l'organisation 2.

Hyperviseur:
— interface réseau;
— mémoire vive;
— disque dur.

Machine virtuelle:
— interface réseau;
— mémoire vive;
— disque dur.

Canal d'échange de données protégées
Internet.

Réseau d'entreprise de l'organisation 1.

Poste de travail de l'utilisateur:
— disque dur;
— mémoire vive;
— interface réseau.

Internet.

Réseau d'entreprise de l'organisation 2.

Hyperviseur:
— interface réseau;
— mémoire vive;
— disque dur.

Machine virtuelle:
— interface réseau;
— mémoire vive;
— disque dur.

Canal de transmission de temps
Poste de travail de l'utilisateur:
— moyens d'entrée-sortie;
— mémoire vive;
— temporisateur système.

Internet.
Réseau d'entreprise de l'organisation 2,

Hyperviseur:
— interface réseau;
— mémoire vive;
— temporisateur système.

Machine virtuelle:
— mémoire vive;
— temporisateur système.

Canal de transmission de commandes de contrôle
Poste de travail de l'utilisateur:
— moyens d'entrée-sortie;
— mémoire vive.

(Interface utilisateur graphique du logiciel CryptoARM)

Machine virtuelle:
— mémoire vive;
— disque dur.

(Scripts d'automatisation)

Canal de réception des résultats de travail
Poste de travail de l'utilisateur:
— moyens d'entrée-sortie;
— mémoire vive.

(Interface utilisateur graphique du logiciel CryptoARM)

Machine virtuelle:
— mémoire vive;
— disque dur.

(Fichiers journaux du travail des scripts d'automatisation)

Menaces de sécurité de haut niveau

Explications

Hypothèses prises lors de la décomposition des menaces :

1. Des algorithmes cryptographiques robustes sont utilisés.
2. Les algorithmes cryptographiques sont utilisés de manière sécurisée dans des modes de fonctionnement appropriés (par exemple, ECB ne doit pas être utilisé pour chiffrer de grandes quantités de données, et la charge admissible sur la clé est prise en compte, etc.).
3. Les attaquants connaissent tous les algorithmes, protocoles et clés publiques utilisés.
4. Les attaquants peuvent lire toutes les données chiffrées.
5. Les attaquants peuvent reproduire n'importe quel élément logiciel dans le système.

Décomposition

U1. Compromission des clés cryptographiques privées.
U2. Chiffrement de données falsifiées 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 (les attaquants).
U4. Création d'une signature électronique d'un signataire légitime sur des données falsifiées.
U5. Obtention d'un résultat positif pour la vérification de la signature électronique sur des données falsifiées.
U6. Acceptation erronée des documents électroniques pour exécution en raison de problèmes dans l'organisation du flux documentaire électronique.
U7. Consultation non autorisée des données protégées pendant leur traitement par le système de cryptographie.

U1. Compromission des clés cryptographiques privées

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

U1.2. Obtention de la clé privée à partir des objets de l'environnement de fonctionnement du moyen cryptographique, où elle peut se trouver temporairement.
Explications U1.2.

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

1. mémoire vive,
2. fichiers temporaires,
3. fichiers d'échange,
4. fichiers d'hibernation,
5. fichiers de snapshots de l'état « chaud » des machines virtuelles, y compris les fichiers du contenu de la mémoire vive des machines virtuelles mises en pause.

U1.2.1. Extraction de clés privées à partir de la mémoire vive en gelant les modules de RAM, les extrayant et lisant ensuite les données (attaque par gel).
Explications U1.2.1.
Exemple les attaques.

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

U1.4. Modification non autorisée du noyau cryptographique, rendant les clés privées accessibles aux attaquants.

U1.5. Compromission de la clé privée en raison de l'utilisation de canaux techniques de fuite d'informations (CTLI).
Explications U1.5.
Exemple les attaques.

U1.6. Compromission de la clé privée en raison de l'utilisation de moyens techniques spéciaux (MTS) destinés à l'extraction discrète d'informations (« micros »).

U1.7. Compromission des clés privées lors de leur stockage en dehors du SKZI.
Explications U1.7.
Par exemple, un utilisateur stocke ses supports de clés dans le tiroir de son bureau, où ils peuvent facilement être extraits par des malfaiteurs.

U2. Chiffrement de données sous faux nom au nom d'un expéditeur légitime.

Explications
Cette menace n'est envisagée que pour les schémas de chiffrement de 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 « Technologie de l'information. Protection cryptographique des informations. Schémas de génération de clé commune avec authentification basée sur la clé publique ».. Pour les autres schémas cryptographiques, cette menace n'existe pas, car le chiffrement est effectué sur les clés publiques du destinataire, qui sont en général connues des malfaiteurs.

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

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

U3. Déchiffrement de données chiffrées par des personnes ne faisant pas partie des destinataires légitimes des données (malfaiteurs).

Décomposition
U3.1. Compromission des clés privées du destinataire des données chiffrées.
U3.1.1 Référence : « Modèle typique de menace. Système de protection cryptographique des informations. U1. Compromission des clés cryptographiques privées ».

U3.2. Substitution des données chiffrées dans le canal d'échange de données protégées.

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

Décomposition
U4.1. Compromission des clés privées de la signature électronique d'un signataire légitime.
U4.1.1 Référence : « Modèle typique de menace. Système de protection cryptographique des informations. U1. Compromission des clés cryptographiques privées ».

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

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

Décomposition
U5.1. Les attaquants interceptent dans le canal de transmission des résultats un message décrivant un échec de la vérification de la signature électronique et le remplacent par un message indiquant un succès.

U5.2. Les attaquants lancent une attaque contre la confiance dans les certificats de signature (SCÉNARIO — tous les éléments sont obligatoires):
U5.2.1. Les attaquants génèrent une clé publique et une clé privée pour la signature électronique. Si des certificats de clés de signature électronique sont utilisés dans le système, ils génèrent un certificat de signature électronique très similaire au certificat du supposé expéditeur des données dont ils souhaitent falsifier le message.
U5.2.2. Les attaquants apportent des modifications non autorisées au stockage des clés publiques, conférant à la clé publique qu'ils ont générée le niveau de confiance et les autorisations nécessaires.
U5.2.3. Les attaquants signent des données falsifiées avec la clé de signature électronique précédemment formée et les injectent dans le canal d'échange de données protégées.

U5.3. Les attaquants lancent une attaque en utilisant des clés de signature électronique expirées du signataire légitime (SCÉNARIO — tous les éléments sont obligatoires):
U5.3.1. Les attaquants compromettent les clés privées de signature électronique expirées (qui ne sont plus valides) du véritable expéditeur.
U5.3.2. Les attaquants remplacent l'heure dans le canal de transmission par celle où les clés compromises étaient encore valides.
U5.3.3. Les attaquants signent des données falsifiées avec une clé de signature électronique compromise antérieurement et les injectent dans le canal d'échange de données protégées.

U5.4. Les attaquants lancent une attaque utilisant des clés de signature électronique compromises du signataire légitime (SCÉNARIO — tous les éléments sont obligatoires):
U5.4.1. Les attaquants font une copie du stockage des clés publiques.
U5.4.2. Les attaquants compromettent les clés privées de l'un des expéditeurs légaux. Celui-ci remarque la compromission, révoque les clés, et les informations sur la révocation des clés sont placées dans le stockage des clés publiques.
U5.4.3. Les attaquants remplacent le stockage des clés publiques par celui qu'ils ont précédemment copié.
U5.4.4. Les attaquants signent des données falsifiées avec une clé de signature électronique compromise précédemment et les injectent dans le canal d'échange de données protégées.

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

U5.5.1. Vérification de la confiance envers le certificat de clé de signature électronique uniquement sur la base de la confiance envers le certificat par lequel il a été signé, sans vérifications CRL ou OCSP.
Explications U5.5.1.
Exemple de mise en œuvre menace.

U5.5.2. Lors de la construction d'une chaîne de confiance envers le certificat, les attributions des certificats émetteurs ne sont pas analysées
Explications U5.5.2.
Exemple d'attaque concernant les certificats SSL/TLS.
Les cybercriminels ont acheté un certificat légitime pour leur e-mail. Ensuite, ils ont créé un certificat frauduleux pour un site et l'ont signé avec leur certificat. Si aucune vérification des attributions n'est effectuée, lors de la vérification de la chaîne de confiance, celle-ci apparaîtra correcte, et par conséquent, le certificat frauduleux sera également valide.

U5.5.3. Lors de la construction d'une chaîne de confiance envers le certificat, les certificats intermédiaires ne sont pas vérifiés pour révocation.

U5.5.4. La mise à jour de la CRL se produit moins souvent que celle émise par l'autorité de certification.

U5.5.5. La décision de faire confiance à la signature électronique est prise avant la réception de la réponse OCSP concernant le statut du certificat, envoyée suite à une demande faite après le moment de formation de la signature ou avant que la CRL suivante ne soit obtenue après la formation de la signature.
Explications U5.5.5.
Dans la plupart des règlements des AC, le moment de révocation du certificat est considéré comme le moment de publication de la CRL la plus proche contenant des informations sur la révocation du certificat.

U5.5.6. Lors de la réception de données signées, l'appartenance du certificat à l'expéditeur n'est pas vérifiée.
Explications U5.5.6.
Exemple d'attaque. Concernant les certificats SSL : la correspondance de l'adresse du serveur appelé avec la valeur du champ CN dans le certificat peut ne pas être vérifiée.
Exemple d'attaque. Les cybercriminels ont compromis les clés de signature électronique de l'un des participants à un système de paiement. Ils ont ensuite piraté le réseau d'un autre participant et, en son nom, ont envoyé au serveur de règlement du système de paiement des documents de paiement signés avec les clés compromises. Si le serveur n'analyse que la confiance et ne vérifie pas la conformité, les documents frauduleux seront considérés comme légitimes.

U6. Acceptation erronée des documents électroniques pour exécution en raison de problèmes dans l'organisation du flux documentaire électronique.

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

U7. Accès non autorisé aux données protégées lors de leur traitement par le SKZI.

Décomposition

U7.1. en raison d'une fuite d'informations par des canaux externes (side channel attack).
Explications U7.1.
Exemple les attaques.

U7.2. en raison de la neutralisation de la protection contre l'accès non autorisé aux informations traitées sur le SKZI :
U7.2.1. Exploitation du SKZI en violation des exigences décrites dans la documentation du SKZI.

U7.2.2. , réalisée grâce à des vulnérabilités dans :
U7.2.2.1. les moyens de protection contre l'accès non autorisé.
U7.2.2.2. le SKZI lui-même.
U7.2.2.3. l'environnement de fonctionnement des moyens cryptographiques.

Exemples d'attaques

Les scénarios décrits ci-dessous contiennent délibérément des erreurs dans l'organisation de la sécurité de l'information et servent uniquement à illustrer les attaques possibles.

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

Description de l'objet


Le logiciel ARM KBR et SKZI SKAD Signature est installé sur un ordinateur physique, non connecté à un réseau informatique. Le porte-clés utilisé est le FKN vdToken en mode de fonctionnement avec une clé non extractible.

Le règlement sur la réalisation des calculs suppose qu'un spécialiste télécharge des messages électroniques en clair (schéma de l'ancien ARM KBR) depuis un serveur de fichiers protégé, ensuite il les enregistre sur un support amovible USB et les transfère sur l'ARM KBR, où ils sont chiffrés et signés. Après cela, le spécialiste transfère les messages électroniques protégés sur le support amovible, puis via son ordinateur de travail, il les enregistre sur le serveur de fichiers, d'où ils parviennent à l'UTA et ensuite dans le 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 : le serveur de fichiers, l'ordinateur de travail du spécialiste et le support amovible.

L'attaque
Des acteurs malveillants installent sans autorisation un système de contrôle à distance sur l'ordinateur de travail d'un spécialiste et, au moment de l'enregistrement des mandats de paiement (messages électroniques) sur un support utilisé, remplacent en clair le contenu de l'un d'eux. Le spécialiste transfère les mandats de paiement sur l'ARM KBR, les signe et les crypte, sans remarquer l'échange (par exemple, en raison du grand nombre de mandats de paiement en cours, de la fatigue, etc.). Après cela, le mandat de paiement falsifié, ayant traversé la chaîne technologique, aboutit dans le système de paiement de la Banque de Russie.

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

Description de l'objet


Un ordinateur avec ARM KBR installé, SKAD Signature et un porte-clé FKN vdToken connecté fonctionne dans un espace dédié sans accès par le personnel.
Le spécialiste des paiements se connecte à l'ARM KBR en mode accès distant via le protocole RDP.

L'attaque
Des acteurs malveillants interceptent les identifiants que le spécialiste des paiements utilise pour se connecter et travailler avec l'ARM KBR (par exemple, grâce à un code malveillant sur son ordinateur). Ils procèdent ensuite à la connexion en son nom et envoient à la Banque de Russie un mandat de paiement falsifié.

Scénario 3. Exemple de réalisation de la menace U1.3.

Description de l'objet


Considérons l'un des scénarios hypothétiques de mise en œuvre des modules d'intégration « ABS-KBR » pour un nouveau schéma (ARM KBR-N), où la signature électronique des documents sortants se fait du côté de l'ABS. Nous allons supposer que l'ABS fonctionne sur un système d'exploitation non pris en charge par le SKZI SKAD Signature, et par conséquent, la fonctionnalité cryptographique est transférée sur une machine virtuelle distincte — module d'intégration « ABS-KBR ».
Un porte-clé USB classique, fonctionnant en tant que clé amovible, est utilisé comme porte-clé. Lors de la connexion du porte-clé à l'hyperviseur, il s'est avéré qu'il n'y avait pas de ports USB libres dans le système, c'est pourquoi il a été décidé de connecter le porte-clé USB via un concentrateur USB réseau, et d'installer un client USB-over-IP sur la machine virtuelle, qui assurera la communication avec le concentrateur.

L'attaque
Des cybercriminels ont intercepté la clé secrète de signature électronique lors de la transmission entre le concentrateur USB et l'hyperviseur (les données ont été transmises en clair). Avec la clé secrète, les cybercriminels ont créé un faux ordre de paiement, l'ont signé avec la signature électronique et l'ont envoyé à l'ARM KBR-N pour exécution.

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

Description de l'objet
Considérons le même schéma que dans le scénario précédent. Supposons que les messages électroniques provenant de l'ARM KBR-N se retrouvent dans le dossier …SHAREIn, tandis que ceux envoyés vers l'ARM KBR-N et ensuite vers le système de paiement de la Banque de Russie se trouvent dans …SHAREout.
Nous supposerons également que lors de la mise en œuvre du module d'intégration, les listes de certificats révoqués ne sont mises à jour qu'en cas de renouvellement des clés cryptographiques, et que les messages électroniques reçus dans le dossier …SHAREIn ne sont vérifiés que pour l'intégrité et la confiance accordée à la clé publique de signature électronique.

L'attaque

Les cybercriminels, ayant utilisé les clés volées dans le scénario précédent, ont signé un faux ordre de paiement contenant des informations sur l'arrivée de fonds sur le compte d'un client-fraudeur et l'ont injecté dans le canal d'échange de données sécurisées. Étant donné qu'aucun contrôle n'est effectué pour vérifier que l'ordre de paiement est bien signé par la Banque de Russie, il est accepté pour exécution.

Source : habr.com