Liens vers d'autres parties de l'étude
- (vous êtes ici)
Cet article complète la série de publications consacrées à assurer la sécurité des informations sur les paiements bancaires autres qu'en espèces. Nous examinerons ici les modèles de menace typiques mentionnés dans :
- .
- .
- .
- .
HABRO-ATTENTION !!! Chers Khabrovites, ce n’est pas un article divertissant.
Les plus de 40 pages de documents cachés sous la coupe sont destinées à aide au travail ou aux études des personnes spécialisées dans le domaine bancaire ou la sécurité de l'information. Ces documents sont le produit final de la recherche et sont rédigés sur un ton sec et formel. Essentiellement, il s'agit de blancs pour les documents internes sur la sécurité de l'information.Eh bien, traditionnel - "l'utilisation des informations de l'article à des fins illégales est punie par la loi". Lecture productive !
Informations destinées aux lecteurs qui se familiarisent avec l'étude à partir de cette publication.
De quoi parle l’étude ?
Vous lisez un guide destiné à un spécialiste chargé d'assurer la sécurité des informations sur les paiements dans une banque.
Logique de présentation
Au début dans и une description de l'objet protégé est donnée. Puis dans décrit comment créer un système de sécurité et parle de la nécessité de créer un modèle de menace. DANS parle des modèles de menace existants et de la manière dont ils sont formés. DANS и Une analyse d'attaques réelles est fournie. и contenir 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 RÉSEAU
Objet de protection pour lequel le modèle de menace (portée) est appliqué
L'objet de la protection sont 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.
Architecture
Description des éléments architecturaux :
- "Nœuds de fin" — nœuds échangeant des informations protégées.
- "Nœuds 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 finaux).
Menaces de sécurité de haut niveau
Décomposition
U1. Accès non autorisé aux données transmises.
U2. Modification non autorisée des données transmises.
U3. Violation de la paternité des données transmises.
U1. Accès non autorisé aux données transmises
Décomposition
U1.1. <…>, réalisé 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 hôtes :
U1.1.1.1. <…> en RAM.
Explications pour U1.1.1.1.
Par exemple, lors du traitement des données par la pile réseau de l'hôte.
U1.1.1.2. <…> en mémoire non volatile.
Explications pour 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ées 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 de l'hôte :
Explications pour U1.2.1.
La capture de tous les paquets s'effectue en basculant la carte réseau en mode promiscuité (mode promiscuité pour les adaptateurs filaires ou mode moniteur pour les adaptateurs Wi-Fi).
U1.2.2. <…> en effectuant des attaques de l'homme du milieu (MiTM), mais sans modifier les données transmises (sans compter les données du service de protocole réseau).
U1.2.2.1. Lien: .
U1.3. <…>, réalisée en raison de fuites d'informations via des canaux techniques (TKUI) à partir de nœuds physiques ou de lignes de communication.
U1.4. <…>, réalisée en installant des moyens techniques spéciaux (STS) sur les nœuds terminaux ou intermédiaires, destinés à la collecte secrète d'informations.
U2. Modification non autorisée des données transmises
Décomposition
U2.1. <…>, réalisé aux nœuds finaux ou intermédiaires :
U2.1.1. <…> en lisant et en modifiant les données alors qu'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ées sur des nœuds tiers du réseau de transmission de données :
U2.2.1. <…> en effectuant des attaques de type man-in-the-middle (MiTM) et en redirigeant le trafic vers le nœud des attaquants :
U2.2.1.1. La connexion physique des équipements des attaquants entraîne la rupture d’une 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. .
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 des routeurs.
U2.2.1.2.2.2. Annonce de fausses routes par des attaquants via des protocoles de routage dynamique.
U2.2.1.2.3. <…> configuration automatique :
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> adressage et résolution de nom :
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Apporter des modifications non autorisées aux fichiers de noms d'hôtes locaux (hosts, lmhosts, etc.)
U3. Violation du 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 des données :
U3.1.1. Modification des 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: .
U3.1.1.2. Neutralisation de la protection des droits d'auteur des données transmises, mise en œuvre à l'aide de codes de confirmation à usage unique :
U3.1.1.2.1. .
U3.1.2. Modification des informations sur la source des informations transmises :
U3.1.2.1. .
U3.1.2.2. .
MODÈLE DE MENACE TYPIQUE. SYSTÈME D'INFORMATION CONSTRUIT SUR LA BASE D'UNE ARCHITECTURE CLIENT-SERVEUR
Objet de protection pour lequel le modèle de menace (portée) est appliqué
L'objet de la protection est un système d'information construit sur la base d'une architecture client-serveur.
Architecture
Description des éléments architecturaux :
- "Client" – un appareil sur lequel opère la partie client du système d’information.
- "Serveur" – un appareil sur lequel opère la partie serveur du système d’information.
- "Magasin de données" — partie de l'infrastructure serveur d'un système d'information, conçue pour stocker les données traitées par le système d'information.
- "Connexion réseau" — un canal d'échange d'informations entre le Client et le Serveur passant par le réseau de données. Une description plus détaillée du modèle d'élément est donnée dans .
Restrictions
Lors de la modélisation d'un objet, les restrictions suivantes sont définies :
- L'utilisateur interagit avec le système d'information au cours de périodes de temps finies, appelées sessions de travail.
- Au début de chaque session de travail, l'utilisateur est identifié, authentifié et autorisé.
- 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. Effectuer des actions non autorisées par des attaquants 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. Effectuer des actions non autorisées par des attaquants au nom d'un utilisateur légitime
Explication
Généralement dans les systèmes d'information, les actions sont corrélées à l'utilisateur qui les a réalisées à l'aide de :
- journaux de fonctionnement du système (journaux).
- attributs spéciaux des objets de données contenant des informations sur l'utilisateur qui les a créés ou modifiés.
Par rapport à une séance de travail, cette menace peut se décomposer en :
- <…> effectué au cours de la session utilisateur.
- <…> exécuté en dehors de la session utilisateur.
Une session utilisateur peut être initiée :
- Par l'utilisateur lui-même.
- Malfaiteurs.
A ce stade, la décomposition intermédiaire de cette menace ressemblera à ceci :
U1.1. Des actions non autorisées ont été effectuées au cours d'une session utilisateur :
U1.1.1. <…> installé par l'utilisateur attaqué.
U1.1.2. <…> installé par des attaquants.
U1.2. Des actions non autorisées ont été effectuées en dehors de la session utilisateur.
Du point de vue des objets de l'infrastructure d'information pouvant être affectés par des attaquants, la décomposition des menaces intermédiaires ressemblera à ceci :
é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. Des actions non autorisées ont été effectuées au cours 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 outils standards d’accès au système d’information :
У1.1.1.1.1.1. Les attaquants ont utilisé les moyens physiques d’entrée/sortie du Client (clavier, souris, moniteur ou écran tactile d’un appareil mobile) :
U1.1.1.1.1.1.1. Les attaquants ont opéré pendant des périodes où la session était active, les installations d'E/S étaient disponibles et l'utilisateur n'était pas présent.
У1.1.1.1.1.2. Les attaquants ont utilisé des outils d'administration à distance (standards ou fournis par code malveillant) pour gérer le Client :
U1.1.1.1.1.2.1. Les attaquants ont opéré pendant des périodes où la session était active, les installations d'E/S étaient disponibles et l'utilisateur n'était pas présent.
У1.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 la connexion réseau entre le Client et le Serveur, en les modifiant de telle manière qu'elles ont été perçues comme les actions d'un utilisateur légitime :
U1.1.1.2.1. Lien: .
U1.1.1.3. Les attaquants ont forcé l’utilisateur à effectuer les actions spécifiées en utilisant des méthodes d’ingénierie sociale.
У1.1.2 <…> installé par des attaquants :
U1.1.2.1. Les attaquants ont agi depuis le Client (И):
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: .
У1.1.2.1.2. Les attaquants ont utilisé des outils standards d’accès aux systèmes d’information
U1.1.2.2. Les attaquants ont opéré à partir d'autres nœuds du réseau de données, à partir desquels une connexion réseau au serveur pouvait être établie (И):
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: .
U1.1.2.2.2. Les attaquants ont utilisé des moyens non standards pour accéder au système d'information.
Explications U1.1.2.2.2.
Les attaquants pourraient installer un client standard du système d'information sur un nœud tiers ou utiliser un logiciel non standard mettant en œuvre des 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 utilisateur.
U1.2.1 Les attaquants ont effectué des actions non autorisées, puis ont apporté des modifications non autorisées aux journaux d'exploitation 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 le font pour le compte d'un utilisateur légitime.
U2.1.1. Lien: .
U2.2. Les attaquants modifient les informations protégées en utilisant des mécanismes d'accès aux données non prévus par le fonctionnement normal du système d'information.
U2.2.1. Les attaquants modifient les 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 copie de 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 (И):
U2.2.2.1. Les attaquants neutralisent le système de contrôle d'accès du SGBD :
U2.2.2.1.1. Lien: .
U2.2.2.2. Les attaquants modifient les informations à l'aide d'interfaces SGBD standard pour accéder aux données.
U2.3. Les attaquants modifient les informations protégées en modifiant sans autorisation les algorithmes de fonctionnement du logiciel qui les traite.
U2.3.1. Le code source du logiciel est sujet à modification.
U2.3.1. Le code machine du logiciel est susceptible de modification.
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, un serveur de base de données et un serveur d'applications) :
U2.5.1. Lien: .
MODÈLE DE MENACE TYPIQUE. SYSTÈME DE CONTRÔLE D'ACCÈS
Objet de protection pour lequel le modèle de menace (portée) est appliqué
L'objet de protection pour lequel 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 construit sur une architecture client-serveur.
Dans ce modèle de menace, un système de contrôle d'accès des utilisateurs désigne un composant d'un système d'information qui met en œuvre les fonctions suivantes :
- Identification de l'utilisateur.
- Authentification d'utilisateur.
- Autorisations des utilisateurs.
- 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. Augmentation non autorisée des privilèges des utilisateurs dans un système d'information.
U1. Établissement non autorisé d'une session au nom d'un utilisateur légitime
Explication
La décomposition de cette menace dépendra généralement du type de systèmes d’identification et d’authentification des utilisateurs utilisés.
Dans ce modèle, seul un système d'identification et d'authentification de l'utilisateur utilisant un login texte et un mot de passe sera pris en compte. Dans ce cas, nous supposerons que la connexion de l'utilisateur est une information publiquement disponible et connue des attaquants.
Décomposition
U1.1. <…> en raison de 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 pourraient être écrites sur un pense-bête collé sur le moniteur.
U1.1.2. L'utilisateur a transmis accidentellement ou malicieusement les détails d'accès aux attaquants.
U1.1.2.1. L'utilisateur a prononcé les informations d'identification à haute voix lors de son entrée.
U1.1.2.2. L'utilisateur a intentionnellement partagé ses identifiants :
U1.1.2.2.1. <…> aux collègues de travail.
Explications U1.1.2.2.1.
Par exemple, pour pouvoir le remplacer en cas de maladie.
U1.1.2.2.2. <…> aux sous-traitants de l’employeur effectuant des travaux sur des objets d’infrastructure d’information.
U1.1.2.2.3. <…> à des tiers.
Explications U1.1.2.2.3.
L’utilisation de méthodes d’ingénierie sociale par les attaquants est une option, mais pas la seule, pour mettre en œuvre cette menace.
U1.1.3. Les attaquants ont sélectionné les informations d'identification en utilisant des méthodes de force brute :
U1.1.3.1. <…> en utilisant des mécanismes d'accès standard.
U1.1.3.2. <…> en utilisant des codes précédemment interceptés (par exemple, des hachages de mots de passe) pour stocker les informations d'identification.
U1.1.4. Les attaquants ont utilisé un 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: .
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 les frappes sur le clavier ont été enregistrées pendant le fonctionnement).
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 .
U1.1.7. Les attaquants ont compromis les informations d’identification des utilisateurs en raison de failles dans le processus de transmission.
Explications U1.1.7.
Par exemple, envoyer des mots de passe en texte clair par e-mail.
U1.1.8. Les attaquants ont obtenu des informations d'identification en surveillant la session d'un utilisateur à l'aide de systèmes d'administration à distance.
U1.1.9. Les attaquants ont obtenu des informations d’identification suite à leur fuite via des canaux techniques (TCUI) :
U1.1.9.1. Les attaquants ont observé comment l'utilisateur saisissait ses informations d'identification à partir du clavier :
U1.1.9.1.1 Les attaquants se trouvaient à proximité immédiate de l'utilisateur et ont vu de leurs propres yeux la saisie des informations d'identification.
Explications U1.1.9.1.1
De tels cas incluent les actions de collègues de travail ou le cas où le clavier de l'utilisateur est visible pour les visiteurs de l'organisation.
U1.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 l'entrée des informations d'identification à travers une fenêtre.
U1.1.9.2. Les attaquants ont extrait les informations d'identification des communications radio entre le clavier et l'unité système informatique lorsqu'ils étaient connectés via une interface radio (par exemple, Bluetooth).
U1.1.9.3. Les attaquants ont intercepté les informations d’identification en les divulguant via le canal des rayonnements et interférences électromagnétiques parasites (PEMIN).
Explications U1.1.9.3.
Exemples d'attaques и .
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 obtenir secrètement des informations.
Explications U1.1.9.4.
Exemples .
U1.1.9.5. Les attaquants ont intercepté la saisie des informations d'identification à partir du clavier en utilisant
analyse du signal Wi-Fi modulé par le processus de frappe de l'utilisateur.
Explications U1.1.9.5.
Exemple .
U1.1.9.6. Les attaquants ont intercepté la saisie des informations d'identification à partir du clavier en analysant les sons des frappes.
Explications U1.1.9.6.
Exemple .
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 .
U1.1.10. <…>, préalablement enregistré sur le Client.
Explications U1.1.10.
Par exemple, un utilisateur peut enregistrer un identifiant et un mot de passe dans le 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 des utilisateurs.
Explications U1.1.11.
Par exemple, après qu’un utilisateur ait été licencié, ses comptes sont restés débloqués.
U1.2. <…> en exploitant les vulnérabilités du système de contrôle d'accès.
U2. Élévation non autorisée des privilèges des utilisateurs dans un 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 <…> grâce à l'utilisation de 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 obtenu plus d'accès pour son travail que ce dont il avait besoin pour des raisons professionnelles.
Exemple 2 : après qu'un utilisateur a été transféré à 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 (portée) est appliqué
Un module d'intégration est un ensemble d'objets d'infrastructure d'information conçus pour organiser l'échange d'informations entre systèmes d'information.
Compte tenu du fait 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 de connexion entre les composants d'un même système d'information.
Architecture
Le schéma généralisé du module d'intégration ressemble à ceci :
Description des éléments architecturaux :
- "Serveur Exchange (SO)" – un 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.
- "Médiateur" – un nœud/service conçu pour organiser l'interaction entre les systèmes d'information, mais n'en faisant pas partie.
Des exemples "Intermédiaires" il peut y avoir des services de messagerie, des bus de services d'entreprise (architecture Enterprise Service Bus / SoA), des serveurs de fichiers tiers, etc. De manière générale, le module d'intégration ne peut pas contenir d'« Intermédiaires ». - "Logiciel de traitement de données" – un ensemble de programmes qui mettent en œuvre des protocoles d'échange de données et de conversion de format.
Par exemple, convertir des données du format UFEBS au format ABS, modifier l'état des messages pendant la transmission, etc. - "Connexion réseau" correspond à l’objet décrit dans le modèle de menace standard « Connexion réseau ». Certaines des connexions réseau illustrées dans le diagramme ci-dessus peuvent ne pas exister.
Exemples de modules d'intégration
Schéma 1. Intégration d'ABS et d'AWS KBR via un serveur de fichiers tiers
Pour exécuter les paiements, un employé de banque autorisé télécharge les documents de paiement électronique à partir du système bancaire central et les enregistre dans un fichier (dans son propre format, par exemple un dump SQL) dans un dossier réseau (...SHARE) sur un serveur de fichiers. Ensuite, ce fichier est converti à l'aide d'un script de conversion en un ensemble de fichiers au format UFEBS, qui sont ensuite lus par le poste CBD.
Après cela, l'employé autorisé - l'utilisateur du lieu de travail automatisé KBR - crypte et signe les fichiers reçus et les envoie au système de paiement de la Banque de Russie.
Lorsque des paiements sont reçus de la Banque de Russie, le poste de travail automatisé du KBR les décrypte et vérifie la signature électronique, après quoi il les enregistre sous la forme d'un ensemble de fichiers au format UFEBS sur un serveur de fichiers. Avant d'importer les documents de paiement dans l'ABS, ceux-ci sont convertis à l'aide d'un script de conversion du format UFEBS au format ABS.
Nous supposerons que dans ce schéma, l'ABS fonctionne sur un serveur physique, le poste de travail KBR fonctionne sur un ordinateur dédié et le script du convertisseur s'exécute sur un serveur de fichiers.
Correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
« Serveur Exchange du côté ABS » – Serveur ABS.
« Serveur Exchange du côté AWS KBR » – poste informatique KBR.
"Médiateur" – serveur de fichiers tiers.
"Logiciel de traitement de données" – script de conversion.
Schéma 2. Intégration d'ABS et d'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 aucun serveur de fichiers séparé n'est utilisé, mais un dossier réseau (...SHARE) contenant les documents de paiement électronique est placé sur un ordinateur avec un poste de travail de CBD. Le script du convertisseur fonctionne également sur le poste de travail CBD.
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 "Médiateur" non utilisé.
Schéma 3. Intégration de l'ABS et du poste de travail automatisé KBR-N via IBM WebSphera MQ et signature des documents électroniques « côté ABS »
ABS fonctionne sur une plateforme qui n'est pas prise en charge par la signature CIPF 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 les documents de paiement dans son propre format sur le serveur ES.
Le serveur ES, à l'aide d'un script de conversion, convertit le fichier en messages électroniques au format UFEBS, après quoi les messages électroniques sont signés et transmis à IBM WebSphere MQ.
Le poste de travail KBR-N accède à IBM WebSphere MQ et en reçoit des messages de paiement signés, après quoi un employé autorisé - un utilisateur du poste de travail KBR - les crypte et les envoie au système de paiement de la Banque de Russie.
Lorsque les paiements sont reçus de la Banque de Russie, le lieu de travail automatisé KBR-N les décrypte et vérifie la signature électronique. Les paiements traités avec succès sous la forme de messages électroniques déchiffrés et signés au format UFEBS sont transférés vers IBM WebSphere MQ, d'où ils sont reçus par le serveur de signature électronique.
Le serveur de signature électronique 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 de l'ABS - télécharge le fichier résultant sur l'ABS de la manière prescrite.
Correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
« Serveur Exchange du côté ABS » – Serveur ABS.
« Serveur Exchange du côté AWS KBR » — poste de travail informatique KBR.
"Médiateur" – Serveur ES et IBM WebSphere MQ.
"Logiciel de traitement de données" – convertisseur de script, CIPF SCAD Signature sur le serveur ES.
Schéma 4. Intégration du serveur RBS et du système bancaire central via l'API fournie par un serveur d'échange dédié
Nous supposerons que la banque utilise plusieurs systèmes de banque à distance (RBS) :
- « Client-Banque Internet » pour les particuliers (IKB FL) ;
- "Client-Banque Internet" pour les personnes morales (IKB LE).
Afin d'assurer la sécurité de l'information, toutes les interactions entre l'ABS et les systèmes de banque à distance s'effectuent via un serveur d'échange dédié fonctionnant dans le cadre du système d'information ABS.
Ensuite, nous considérerons le processus d'interaction entre le système RBS d'IKB LE et l'ABS.
Le serveur RBS, après avoir reçu un ordre de paiement dûment certifié du client, doit créer un document correspondant dans l'ABS sur cette base. Pour ce faire, à l'aide de l'API, il transmet des informations au serveur d'échange, qui, à son tour, saisit les données dans l'ABS.
Lorsque les soldes des comptes du client changent, l'ABS génère des notifications électroniques, qui sont transmises au serveur de banque à distance via le serveur d'échange.
Correspondance des objets du schéma considéré avec les éléments du modèle du module d'intégration :
"Serveur Exchange du côté RBS" – Serveur RBS de IKB YUL.
« Serveur Exchange du côté ABS » - serveur d'échange.
"Médiateur" - disparu.
"Logiciel de traitement de données" – Composants du serveur RBS responsables de l’utilisation de l’API du serveur d’échange, composants du serveur d’échange responsables de l’utilisation de l’API bancaire principale.
Menaces de sécurité de haut niveau
Décomposition
U1. Injection de fausses informations par des attaquants via le module d'intégration.
U1. Injection de fausses informations par des attaquants 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 :
Lien U1.1.1 : .
U1.2. Transmission de fausses données via des canaux de communication de la part d'un participant légitime à l'échange :
Lien U1.1.2 : .
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: .
U1.4. Création de fausses données sur les Serveurs Exchange ou Intermédiaire pour le compte d'un participant légitime à l'échange :
U1.4.1. Lien:
U1.5. Modification non autorisée des données lors d'un traitement à l'aide d'un logiciel de traitement de données :
U1.5.1. <…> en raison de modifications non autorisées apportées par des attaquants aux paramètres (configuration) du logiciel de traitement des données.
U1.5.2. <…> en raison de modifications non autorisées apportées par des attaquants aux fichiers exécutables d'un logiciel de traitement de données.
U1.5.3. <…> en raison du contrôle interactif du logiciel de traitement des données par des attaquants.
MODÈLE DE MENACE TYPIQUE. SYSTÈME DE PROTECTION DES INFORMATIONS CRYPTOGRAPHIQUES
Objet de protection pour lequel le modèle de menace (portée) est appliqué
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 qui implémente sa fonctionnalité cible.
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 cœurs cryptographiques.
Les primitives cryptographiques incluent 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 la fonction de hachage du bloc de données ;
- générer/charger/télécharger des informations clés ;
- etc.
La logique métier du logiciel d'application implémente des fonctionnalités de niveau supérieur à l'aide de primitives cryptographiques :
- chiffrer le fichier à l'aide des 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 ;
- et ainsi de suite.
L'interaction de la logique métier et du noyau crypto peut être réalisée :
- directement, par logique métier appelant des primitives cryptographiques issues des bibliothèques dynamiques du noyau crypto (.DLL pour Windows, .SO pour Linux) ;
- directement, via des interfaces cryptographiques - des wrappers, par exemple, MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. Dans ce cas, la logique métier accède à l'interface cryptographique et traduit l'appel au cœur cryptographique correspondant, qui dans ce cas est appelé fournisseur de cryptographie. L'utilisation d'interfaces cryptographiques permet aux logiciels d'application de s'éloigner des algorithmes cryptographiques spécifiques et d'être plus flexibles.
Il existe deux schémas typiques pour organiser le noyau crypto :
Schéma 1 – Noyau crypto monolithique
Schéma 2 – Noyau crypto divisé
Les éléments des diagrammes ci-dessus peuvent être soit des modules logiciels individuels exécutés sur un ordinateur, soit des services réseau interagissant au sein d'un réseau informatique.
Lors de l'utilisation de systèmes construits selon le schéma 1, le logiciel d'application et le noyau cryptographique fonctionnent dans un seul environnement d'exploitation pour l'outil cryptographique (SFC), par exemple sur le même ordinateur, exécutant le même système d'exploitation. En règle générale, l'utilisateur du système peut exécuter d'autres programmes, y compris ceux contenant du code malveillant, dans le même environnement d'exploitation. Dans de telles conditions, 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 :
- La première partie, ainsi que le logiciel d'application, fonctionnent dans un environnement non fiable où il existe un risque d'infection par un code malveillant. Nous appellerons cette partie la « partie logicielle ».
- La deuxième partie fonctionne dans un environnement de confiance sur un appareil dédié, qui contient un stockage de clé privée. Désormais, nous appellerons cette partie « matériel ».
La division du noyau cryptographique en parties logicielles et matérielles est très arbitraire. Il existe sur le marché des systèmes construits selon un schéma avec un noyau crypto divisé, mais dont la partie « matérielle » se présente sous la forme d'une image de machine virtuelle - HSM virtuel ().
L'interaction des deux parties du noyau cryptographique se produit de telle manière que les clés cryptographiques privées ne sont jamais transférées à la partie logicielle et, par conséquent, ne peuvent pas être volées à l'aide d'un code malveillant.
L'interface d'interaction (API) et l'ensemble des primitives cryptographiques fournies au logiciel d'application par le cœur 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, lors de l'utilisation d'un schéma à noyau crypto divisé, l'interaction du logiciel et du matériel s'effectue selon le principe suivant :
- Les primitives cryptographiques ne nécessitant pas l'utilisation de clé privée (par exemple, calcul d'une fonction de hachage, vérification d'une signature électronique, etc.) sont réalisées par le logiciel.
- Les primitives cryptographiques utilisant une clé privée (création d'une signature électronique, déchiffrement de données, etc.) sont réalisées par le matériel.
Illustrons le travail du noyau crypto divisé à l'aide de l'exemple de création d'une signature électronique :
- La partie logicielle calcule la fonction de hachage des données signées et transmet cette valeur au matériel via le canal d'échange entre cœurs crypto.
- La partie matérielle, à l'aide de la clé privée et du hachage, génère la valeur de la signature électronique et la transmet à la partie logicielle via un canal d'échange.
- La partie logicielle renvoie la valeur reçue au logiciel d'application.
Caractéristiques de vérification de l'exactitude d'une signature électronique
Lorsque le destinataire reçoit des données signées électroniquement, 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 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.
Contenu de la scène. La signature électronique des données est vérifiée à l'aide de l'algorithme cryptographique approprié. La réussite de cette étape indique que les données n'ont pas été modifiées depuis la signature, mais également que la signature a été réalisée avec une clé privée correspondant à la clé publique de vérification de la signature électronique.
Localisation de la scène : noyau cryptographique.
Étape 2. Contrôle de confiance dans la clé publique du signataire et contrôle de la durée de validité de la clé privée de la signature électronique.
Contenu de la scène. L'étape se compose de deux sous-étapes intermédiaires. La première consiste à déterminer si la clé publique de vérification de la signature électronique était fiable au moment de la signature des données. La seconde détermine si la clé privée de la signature électronique était valide au moment de la signature des données. En général, les périodes de validité de ces clés peuvent ne pas coïncider (par exemple pour les certificats qualifiés de clés de vérification de signature électronique). Les modalités d'établissement de la confiance dans la clé publique du signataire sont déterminées par les règles de gestion électronique des documents adoptées par les parties en interaction.
Localisation de la scène : logiciel d'application/noyau crypto.
Étape 3. Contrôle de l'autorité du signataire.
Contenu de la scène. Conformément aux règles établies de la gestion électronique des documents, il est vérifié si le signataire avait le droit de certifier les données protégées. A titre d'exemple, donnons une situation de violation d'autorité. Supposons qu'il existe une organisation où tous les employés possèdent une signature électronique. Le système de gestion électronique des documents interne reçoit une commande du gestionnaire, mais signée avec la signature électronique du responsable de l'entrepôt. En conséquence, un tel document ne peut être considéré comme légitime.
Localisation de la scène : logiciel d'application.
Hypothèses formulées lors de la description de l'objet de la protection
- Les canaux de transmission d'informations, à l'exception des canaux d'échange de clés, passent également par les logiciels d'application, les API et le noyau cryptographique.
- Les informations sur la confiance dans les clés publiques et (ou) les certificats, ainsi que les informations sur les pouvoirs des propriétaires de clés publiques, sont placées dans le magasin de clés publiques.
- Le logiciel d'application fonctionne avec le magasin de clés publiques via le noyau cryptographique.
Un exemple de système d'information protégé par CIPF
Pour illustrer les schémas présentés précédemment, considérons un système d’information hypothétique et mettons en évidence tous les éléments structurels qui le composent.
Description du système d'information
Les deux organisations ont décidé d'introduire entre elles une gestion électronique de documents (EDF) juridiquement significative. Pour ce faire, ils ont conclu un accord dans lequel ils stipulaient que les documents seraient transmis par courrier électronique, et en même temps ils devraient être cryptés et signés avec une signature électronique qualifiée. Les programmes Office du package Microsoft Office 2016 doivent être utilisés comme outils de création et de traitement de documents, et CIPF CryptoPRO et le logiciel de cryptage CryptoARM doivent être utilisés comme moyens de protection cryptographique.
Description de l'infrastructure de l'organisation 1
L'organisation 1 a décidé d'installer les logiciels CIPF CryptoPRO et 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 en mode clé récupérable. L'utilisateur préparera les documents électroniques localement sur son ordinateur, puis les cryptera, 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éplacer les fonctions de cryptage et de signature électronique vers 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 ». Les fichiers reçus de la contrepartie sous forme ouverte seront automatiquement placés dans le dossier réseau « …In ». Ces fichiers seront décryptés et la signature électronique sera vérifiée.
L'utilisateur placera les fichiers dans le dossier « …Out » 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, CIPF CryptoPRO, le logiciel CryptoARM et un client de messagerie sont installés sur la machine virtuelle. La gestion automatique de tous les éléments de la machine virtuelle sera effectuée à l'aide de scripts développés par les administrateurs système. Le travail des scripts est enregistré dans des fichiers journaux.
Les clés cryptographiques pour la signature électronique seront placées sur un token avec une clé JaCarta GOST non récupérable, 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 du poste de travail de l'utilisateur dans l'organisation 1 sera ajustée manuellement. L'horloge système de la machine virtuelle dédiée de l'organisation 2 sera synchronisée avec l'horloge système de l'hyperviseur, qui à son tour sera synchronisée sur Internet avec les serveurs de temps publics.
Identification des éléments structurels du FCPE
Sur la base de la description ci-dessus de l'infrastructure informatique, nous mettrons en évidence les éléments structurels du FCPE et les écrirons dans un tableau.
Tableau - Correspondance des éléments du modèle CIPF aux éléments du système d'information
Nom d'article
Organisation 1
Organisation 2
Logiciel d'application
Logiciel CryptoARM
Logiciel CryptoARM
Partie logicielle du noyau cryptographique
FCPE CryptoPRO CSP
FCPE CryptoPRO CSP
Matériel de base cryptographique
Non
Jacarta GOST
API
MS CryptoAPI
MS CryptoAPI
Magasin de clés publiques
Poste de travail de l'utilisateur :
- Disque dur ;
- magasin de certificats Windows standard.
Hyperviseur :
- Disque dur.
Machine virtuelle:
- Disque dur ;
- magasin de certificats Windows standard.
Stockage de clé privée
Porte-clés ruToken fonctionnant en mode clé récupérable
Porte-clés JaCarta GOST fonctionnant en mode clé non amovible
Canal d'échange de clé publique
Poste de travail de l'utilisateur :
- RAM.
Hyperviseur :
- RAM.
Machine virtuelle:
- RAM.
Canal d'échange de clé privée
Poste de travail de l'utilisateur :
— Bus USB ;
- RAM.
Non
Canal d'échange entre les cœurs cryptographiques
manquant (pas de matériel de base cryptographique)
Poste de travail de l'utilisateur :
— Bus USB ;
- RAM;
— module logiciel USB sur IP ;
- interface réseau.
Réseau d'entreprise de l'organisation 2.
Hyperviseur :
- RAM;
- interface réseau.
Machine virtuelle:
- interface réseau;
- RAM;
— Module logiciel USB sur IP.
Canal de données ouvert
Poste de travail de l'utilisateur :
— des moyens d'entrée-sortie ;
- RAM;
- Disque dur.
Poste de travail de l'utilisateur :
— des moyens d'entrée-sortie ;
- RAM;
- Disque dur ;
- interface réseau.
Réseau d'entreprise de l'organisation 2.
Hyperviseur :
- interface réseau;
- RAM;
- Disque dur.
Machine virtuelle:
- interface réseau;
- RAM;
- Disque dur.
Canal d'échange de données sécurisé
Internet.
Réseau d'entreprise de l'organisation 1.
Poste de travail de l'utilisateur :
- Disque dur ;
- RAM;
- interface réseau.
Internet.
Réseau d'entreprise de l'organisation 2.
Hyperviseur :
- interface réseau;
- RAM;
- Disque dur.
Machine virtuelle:
- interface réseau;
- RAM;
- Disque dur.
Canal horaire
Poste de travail de l'utilisateur :
— des moyens d'entrée-sortie ;
- RAM;
- minuterie système.
Internet.
Réseau d'entreprise de l'organisation 2,
Hyperviseur :
- interface réseau;
- RAM;
- minuterie système.
Machine virtuelle:
- RAM;
- minuterie système.
Canal de transmission des commandes de contrôle
Poste de travail de l'utilisateur :
— des moyens d'entrée-sortie ;
- RAM.
(Interface utilisateur graphique du logiciel CryptoARM)
Machine virtuelle:
- RAM;
- Disque dur.
(Scripts d'automatisation)
Canal de réception des résultats du travail
Poste de travail de l'utilisateur :
— des moyens d'entrée-sortie ;
- RAM.
(Interface utilisateur graphique du logiciel CryptoARM)
Machine virtuelle:
- RAM;
- Disque dur.
(Fichiers journaux des scripts d'automatisation)
Menaces de sécurité de haut niveau
Explication
Hypothèses formulées lors de la décomposition des menaces :
- Des algorithmes cryptographiques puissants sont utilisés.
- Les algorithmes cryptographiques sont utilisés de manière sécurisée dans les modes de fonctionnement appropriés (par ex. n'est pas utilisé pour chiffrer de gros volumes de données, la charge admissible sur la clé est prise en compte, etc.).
- Les attaquants connaissent tous les algorithmes, protocoles et clés publiques utilisés.
- Les attaquants peuvent lire toutes les données cryptées.
- Les attaquants sont capables de reproduire n'importe quel élément logiciel du système.
Décomposition
U1. Compromission de clés cryptographiques privées.
U2. Cryptage de fausses données au nom de l'expéditeur légitime.
U3. Décryptage des données crypté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 en vérifiant la signature électronique des données falsifiées.
U6. Acceptation erronée des documents électroniques pour exécution en raison de problèmes d'organisation de la gestion électronique des documents.
U7. Accès non autorisé aux données protégées lors de leur traitement par le CIPF.
U1. Compromission des clés cryptographiques privées
U1.1. Récupération de la clé privée du magasin de clés privées.
U1.2. Obtention d’une clé privée à partir d’objets dans l’environnement d’exploitation du crypto-outil, dans lequel il peut résider temporairement.
Explications U1.2.
Les objets pouvant stocker temporairement une clé privée incluent :
- RAM,
- fichiers temporaires,
- échanger des fichiers,
- fichiers d'hibernation,
- des fichiers instantanés de l'état « chaud » des machines virtuelles, y compris des fichiers du contenu de la RAM des machines virtuelles en pause.
U1.2.1. Extraire les clés privées de la RAM de travail en gelant les modules de RAM, en les supprimant puis en lisant les données (attaque par gel).
Explications U1.2.1.
Exemple .
U1.3. Obtention d'une clé privée à partir d'un canal d'échange de clé privée.
Explications U1.3.
Un exemple de mise en œuvre de cette menace sera donné .
U1.4. Modification non autorisée du noyau cryptographique, à la suite de laquelle les clés privées sont connues des attaquants.
U1.5. Compromission d'une clé privée suite à l'utilisation de canaux de fuite d'informations techniques (TCIL).
Explications U1.5.
Exemple .
U1.6. Compromission d'une clé privée suite à l'utilisation de moyens techniques spéciaux (STS) conçus pour récupérer secrètement des informations (« bugs »).
U1.7. Compromission des clés privées lors de leur stockage hors du CIPF.
Explications U1.7.
Par exemple, un utilisateur stocke ses clés multimédias dans un tiroir du bureau, à partir duquel elles peuvent facilement être récupérées par des attaquants.
U2. Cryptage de fausses données pour le compte d'un expéditeur légitime
Explication
Cette menace est prise en compte uniquement pour les systèmes de cryptage des données avec authentification de l'expéditeur. Des exemples de tels schémas sont indiqués dans les recommandations de normalisation . Pour les autres schémas cryptographiques, cette menace n’existe pas, puisque le chiffrement est effectué sur les clés publiques du destinataire, et celles-ci sont généralement connues des attaquants.
Décomposition
U2.1. Compromettre la clé privée de l'expéditeur :
U2.1.1. Lien: .
U2.2. Substitution des données d'entrée dans un canal d'échange de données ouvert.
Remarques U2.2.
Des exemples de mise en œuvre de cette menace sont donnés ci-dessous. и .
U3. Décryptage des données cryptées par des personnes qui ne sont pas des destinataires légitimes des données (attaquants)
Décomposition
U3.1. Compromission des clés privées du destinataire des données cryptées.
Lien U3.1.1 : .
U3.2. Substitution de données crypté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. Compromission des clés privées de la signature électronique d'un signataire légitime.
Lien U4.1.1 : .
U4.2. Substitution de données signées dans un canal d'échange de données ouvert.
Noter U4.2.
Des exemples de mise en œuvre de cette menace sont donnés ci-dessous. и .
U5. Obtention d'un résultat positif en vérifiant la signature électronique des données falsifiées
Décomposition
U5.1. Les attaquants interceptent un message dans le canal de transmission des résultats du travail concernant un résultat négatif de la vérification d'une signature électronique et le remplacent par un message avec un résultat positif.
U5.2. Les attaquants attaquent la confiance dans la signature des certificats (SCRIPT - tous les éléments sont requis):
U5.2.1. Les attaquants génèrent une clé publique et privée pour une signature électronique. Si le système utilise des certificats de clé de signature électronique, il génère alors un certificat de signature électronique aussi similaire que possible au certificat de l'expéditeur prévu des données dont il souhaite falsifier le message.
U5.2.2. Les attaquants apportent des modifications non autorisées au magasin de clés publiques, donnant à la clé publique qu'ils génèrent 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 préalablement générée et l'insèrent dans le canal d'échange de données sécurisé.
U5.3. Les attaquants mènent une attaque en utilisant les clés de signature électronique expirées d'un signataire légal (SCRIPT - tous les éléments sont requis):
U5.3.1. Les attaquants compromettent les clés privées expirées (actuellement non valides) de la signature électronique d'un expéditeur légitime.
U5.3.2. Les attaquants remplacent l’heure dans le canal de transmission temporelle par l’heure à laquelle les clés compromises étaient encore valides.
U5.3.3. Les attaquants signent de fausses données avec une clé de signature électronique précédemment compromise et les injectent dans le canal d'échange de données sécurisé.
U5.4. Les attaquants mènent une attaque en utilisant des clés de signature électronique compromises d'un signataire légal (SCRIPT - tous les éléments sont requis):
U5.4.1. L'attaquant fait 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égitimes. Il remarque la compromission, révoque les clés et les informations sur la révocation de la clé sont placées dans le magasin de clés publiques.
U5.4.3. Les attaquants remplacent le magasin de clés publiques par un magasin de clés précédemment copié.
U5.4.4. Les attaquants signent de fausses données avec une clé de signature électronique précédemment compromise et les 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 2ème et 3ème étapes de vérification de la signature électronique :
Explications U5.5.
Un exemple de mise en œuvre de cette menace est donné .
U5.5.1. Vérification de la confiance dans un certificat de clé de signature électronique uniquement par la présence de confiance dans le certificat avec lequel il est signé, sans contrôles CRL ou OCSP.
Explications U5.5.1.
Exemple de mise en œuvre .
U5.5.2. Lors de la construction d'une chaîne de confiance pour un certificat, les autorités de délivrance des certificats ne sont pas analysées
Explications U5.5.2.
Un exemple d'attaque contre les certificats SSL/TLS.
Les attaquants ont acheté un certificat légitime pour leur courrier électronique. Ils ont ensuite réalisé un certificat de site frauduleux et l'ont signé avec leur certificat. Si les informations d'identification ne sont pas vérifiées, lors de la vérification de la chaîne de confiance, elles s'avéreront correctes et, par conséquent, le certificat frauduleux sera également correct.
U5.5.3. Lors de la création d'une chaîne de confiance de certificat, la révocation des certificats intermédiaires n'est pas vérifiée.
U5.5.4. Les CRL sont mises à jour moins fréquemment qu'elles ne sont émises par l'autorité de certification.
U5.5.5. La décision de faire confiance à une signature électronique est prise avant la réception d'une réponse OCSP sur l'état du certificat, envoyée sur une demande faite après la génération de la signature ou avant la prochaine CRL après la génération de la signature.
Explications U5.5.5.
Dans les réglementations de la plupart des autorités de certification, l'heure de la révocation du certificat est considérée comme l'heure d'émission 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, le certificat appartenant à l'expéditeur n'est pas vérifié.
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 ne peut pas être vérifiée.
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, en son nom, ont envoyé des documents de paiement signés avec 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é, alors 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 d'organisation de la gestion électronique des documents.
Décomposition
U6.1. Le destinataire ne détecte pas la duplication des documents reçus.
Explications U6.1.
Exemple d'attaque. Les attaquants peuvent intercepter un document transmis à un destinataire, même s'il est protégé cryptographiquement, puis l'envoyer à plusieurs reprises via un canal de transmission de données sécurisé. Si le destinataire n'identifie pas les doublons, alors tous les documents reçus seront perçus et traités comme des documents différents.
U7. Accès non autorisé aux données protégées lors de leur traitement par le CIPF
Décomposition
U7.1. <…> en raison d'une fuite d'informations via des canaux secondaires (attaque par canal latéral).
Explications U7.1.
Exemple .
U7.2. <…> en raison de la neutralisation de la protection contre l'accès non autorisé aux informations traitées sur le CIPF :
U7.2.1. Fonctionnement du FCPE en violation 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. <…> moyens de protection contre les accès non autorisés.
U7.2.2.2. <…> FCPE lui-même.
U7.2.2.3. <…> l'environnement d'exploitation du crypto-outil.
Exemples d'attaques
Les scénarios décrits ci-dessous contiennent évidemment des erreurs de sécurité des informations et servent uniquement à illustrer d'éventuelles attaques.
Scénario 1. Un exemple de mise en œuvre des menaces U2.2 et U4.2.
Description de l'objet
Le logiciel AWS KBR et CIPF SCAD Signature sont installés sur un ordinateur physique qui n'est pas connecté au réseau informatique. FKN vdToken est utilisé comme support de clé dans le mode de travail avec une clé non amovible.
Les règles de règlement supposent que le spécialiste du règlement télécharge depuis son ordinateur de travail des messages électroniques en texte clair (schéma de l'ancien poste de travail KBR) à partir d'un serveur de fichiers sécurisé spécial, puis les écrit sur une clé USB transférable et les transfère sur le poste de travail KBR, où ils sont cryptés et signés. Après cela, le spécialiste transfère des messages électroniques sécurisés vers le support aliéné, puis, via son ordinateur de travail, les écrit sur un serveur de fichiers, d'où ils sont transmis à 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 des médias aliénés.
Attaque
Des attaquants non autorisés installent un système de contrôle à distance sur l’ordinateur de travail d’un spécialiste et, au moment de rédiger des ordres de paiement (messages électroniques) sur un support transférable, remplacent le contenu de l’un d’entre eux en texte clair. Le spécialiste transfère les ordres de paiement vers le poste de travail automatisé KBR, les signe et les crypte sans s'apercevoir de la substitution (par exemple, en raison d'un grand nombre d'ordres de paiement sur un vol, de fatigue, etc.). Après cela, le faux ordre de paiement, après avoir parcouru 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 l'objet
Un ordinateur avec un poste de travail KBR installé, SCAD Signature et un porte-clés connecté FKN vdToken fonctionne dans une salle dédiée sans accès du personnel.
Le spécialiste du calcul se connecte au poste de travail CBD en mode accès distant via le protocole RDP.
Attaque
Les attaquants interceptent les détails grâce auxquels le spécialiste des calculs se connecte et travaille avec le poste de travail CBD (par exemple, via un code malveillant sur son ordinateur). Ensuite, ils se connectent en son nom et envoient un faux ordre de paiement au système de paiement de la Banque de Russie.
Scénario 3. Exemple de mise en œuvre d'une menace U1.3.
Description de l'objet
Considérons l'une des options hypothétiques pour implémenter les modules d'intégration ABS-KBR pour un nouveau schéma (AWS KBR-N), dans lequel la signature électronique des documents sortants s'effectue du côté ABS. Dans ce cas, nous supposerons que l'ABS fonctionne sur la base d'un système d'exploitation qui n'est pas pris en charge par la signature CIPF SKAD et, par conséquent, la fonctionnalité cryptographique est transférée vers une machine virtuelle distincte - l'intégration « ABS-KBR ». module.
Un jeton USB ordinaire fonctionnant en mode clé récupérable est utilisé comme support de clé. 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 hub USB réseau et d'installer un client USB sur IP sur le virtuel. machine, qui communiquerait avec le hub.
Attaque
Les attaquants ont intercepté la clé privée de la signature électronique depuis le canal de communication entre le hub USB et l'hyperviseur (les données étaient transmises en texte clair). Disposant de la clé privée, les attaquants ont généré un faux ordre de paiement, l'ont signé avec une signature électronique et l'ont envoyé au poste de travail automatisé KBR-N pour exécution.
Scénario 4. Un exemple de mise en œuvre de menaces U5.5.
Description de l'objet
Considérons le même circuit que dans le scénario précédent. Nous supposerons que les messages électroniques provenant du poste de travail KBR-N se retrouvent dans le dossier …SHAREIn, et que ceux envoyés au poste de travail KBR-N et ensuite au système de paiement de la Banque de Russie vont 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 que lorsque les clés cryptographiques sont réémises, et également que les messages électroniques reçus dans le dossier …SHAREIn sont vérifiés uniquement pour le contrôle d'intégrité et le contrôle de confiance dans la clé publique du signature électronique.
Attaque
Les attaquants, 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 du client frauduleux et l'ont introduit dans le canal sécurisé d'échange de données. Puisqu'il n'y a aucune vérification que l'ordre de paiement a été signé par la Banque de Russie, il est accepté pour exécution.
Source: habr.com