{"id":31627,"date":"2019-10-31T21:42:14","date_gmt":"2019-10-31T18:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\/"},"modified":"2019-10-31T21:42:14","modified_gmt":"2019-10-31T18:42:14","slug":"informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","title":{"rendered":"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\"><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/acac26db4761c25a5215f37ef9e8cb5b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#ABOUT\">Di cosa tratta la ricerca<\/a><\/noindex><\/p>\n<p><b class=\"spoiler_title\">Collegamenti ad altre parti della ricerca<\/b><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/344740\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 1 \u2014 Fondamenti economici.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/345194\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 2 \u2014 Infrastruttura IT standard di una banca.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 3 \u2014 Formulazione dei requisiti per il sistema di protezione.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/351326\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 4 \u2014 Panoramica degli standard di modellazione delle minacce.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 5 \u2014 100+ link tematici su attacchi bancari.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 6 \u2014 Analisi dei crimini bancari.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Sicurezza informatica dei pagamenti monetari bancari. Parte 7 \u2014 Modello base delle minacce.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\">Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard <\/a><\/noindex>(<b>Sei qui<\/b>)<\/li>\n<\/ul>\n<p>Questo articolo conclude un ciclo di pubblicazioni dedicate alla sicurezza informatica dei pagamenti monetari bancari. Qui esamineremo i modelli standard delle minacce, a cui si \u00e8 fatto riferimento in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">modello base<\/a><\/noindex>:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNC\">Modello standard delle minacce. Connessione di rete<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUIS\">Modello standard delle minacce. Sistema informatico basato su architettura client-server<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRD\">Modello standard delle minacce. Sistema di gestione degli accessi<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUMI\">Modello standard delle minacce. Modulo di integrazione<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZI\">Modello standard delle minacce. Sistema di protezione crittografica delle informazioni.<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><b>HABRO-WARNING !!!<\/b> Caro lettori di Habrahabr, questo non \u00e8 un post di intrattenimento. <br \/>\nNascosti sotto il 'leggi di pi\u00f9' ci sono oltre 40 pagine di materiali destinati a <b>aiutare nel lavoro o nello studio<\/b> persone specializzate nel settore bancario o nella sicurezza informatica. Questi materiali sono il prodotto finale della ricerca e sono scritti in uno stile ufficiale e asciutto. In sostanza, sono bozze per documenti interni sulla sicurezza informatica. <\/p>\n<p>E infine, il tradizionale \u2014 <b>\u00abl'uso delle informazioni contenute nell'articolo per scopi illegali \u00e8 perseguito dalla legge\u00bb<\/b>. Buona lettura!\n<\/p><\/blockquote>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nInformazioni per i lettori che si avvicinano alla ricerca partendo da questa pubblicazione.<br \/>\n<noindex><a rel=\"nofollow\" name=\"ABOUT\"><\/a><\/noindex><\/p>\n<blockquote>\n<h2>Di cosa tratta la ricerca<\/h2>\n<p>\nStai leggendo una guida per il professionista responsabile della sicurezza informatica dei pagamenti in banca. <\/p>\n<p><b>Logica di esposizione<\/b><\/p>\n<p>Inizialmente, in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/344740\/\">parte 1<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/345194\/\">parte 2<\/a><\/noindex> viene fornita una descrizione dell'oggetto della protezione. Poi in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">parte 3<\/a><\/noindex> si racconta come costruire un sistema di protezione e si parla della necessit\u00e0 di formare un modello di minacce. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/351326\/\">parte 4<\/a><\/noindex> si discute quali modelli di minacce ci sono e come vengono formulati. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">parte 5<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">parte 6<\/a><\/noindex> viene fornita un'analisi degli attacchi reali. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Parte 7<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\">parte 8<\/a><\/noindex> contengono la descrizione del modello di minaccia, costruito tenendo conto delle informazioni di tutte le parti precedenti.<\/p><\/blockquote>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUNC\"><\/a><\/noindex><\/p>\n<h2>MODELLO TIPO DI MINACCE. COLLEGAMENTO DI RETE<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione, per il quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto di protezione sono i dati trasmessi attraverso un collegamento di rete, funzionante in reti di trasmissione dati basate sullo stack TCP\/IP.<\/p>\n<p><b>Architettura<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/7fec6dc479280db22a581595ae7fc493.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDescrizione degli elementi architettonici:<\/p>\n<ul>\n<li><i>\u00abNodi terminali\u00bb<\/i> \u2014 nodi che scambiano informazioni protette.<\/li>\n<li><i>\u00abNodi intermedi\u00bb<\/i> \u2014 elementi della rete di trasmissione dati: router, switch, server di accesso, server proxy e altro hardware, attraverso i quali viene trasmesso il traffico del collegamento di rete. Di norma, un collegamento di rete pu\u00f2 funzionare senza nodi intermedi (direttamente tra nodi terminali).<\/li>\n<\/ul>\n<p><\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Decomposizione<\/b><\/p>\n<p>U1. Accesso non autorizzato ai dati trasmessi.<br \/>\nU2. Modifica non autorizzata dei dati trasmessi.<br \/>\nU3. Violazione della paternit\u00e0 dei dati trasmessi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU1\"><\/a><\/noindex><\/p>\n<h3>U1. Accesso non autorizzato ai dati trasmessi<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU1.1. , effettuato sui nodi finali o intermedi:<br \/>\nU1.1.1.  tramite la lettura dei dati mentre si trovano nei dispositivi di memorizzazione del nodo:<br \/>\nU1.1.1.1.  nella memoria volatile.<br \/>\n<i>Chiarimenti su U1.1.1.1.<\/i><br \/>\nAd esempio, durante il trattamento dei dati da parte dello stack di rete del nodo.<\/p>\n<p>U1.1.1.2.  nella memoria non volatile.<br \/>\n<i>Chiarimenti su U1.1.1.2.<\/i><br \/>\nAd esempio, durante la memorizzazione dei dati trasmessi nella cache, nei file temporanei o nei file di paging.<\/p>\n<p>U1.2. , effettuato su nodi esterni della rete di trasmissione dei dati:<br \/>\nU1.2.1.  tramite la cattura di tutti i pacchetti che raggiungono l'interfaccia di rete del nodo:<br \/>\n<i>Chiarimenti su U1.2.1.<\/i><br \/>\nLa cattura di tutti i pacchetti avviene attivando la scheda di rete in modalit\u00e0 promiscuo (modalit\u00e0 promiscuo per adattatori cablati o in modalit\u00e0 monitor per adattatori wi-fi).<\/p>\n<p>U1.2.2.  mediante attacchi di tipo 'uomo nel mezzo (MiTM)', ma senza modificare i dati trasmessi (esclusi i dati di servizio dei protocolli di rete).<br \/>\nU1.2.2.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard di minaccia. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.3. , effettuato tramite la fuga di informazioni attraverso canali tecnici (TKUI) da nodi fisici o linee di comunicazione.<\/p>\n<p>U1.4. , effettuato installando su nodi finali o intermedi strumenti tecnici specializzati (STS) destinati alla raccolta clandestina di informazioni.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU2\"><\/a><\/noindex><\/p>\n<h3>U2. Modifica non autorizzata dei dati trasmessi<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU2.1. , effettuata su nodi finali o intermedi:<br \/>\nU2.1.1.  tramite la lettura e la modifica dei dati mentre si trovano nei dispositivi di memorizzazione dei nodi:<br \/>\nU2.1.1.1.  nella memoria volatile:<br \/>\nU2.1.1.2.  nella memoria non volatile:<\/p>\n<p>U2.2. , effettuata su nodi esterni della rete di trasmissione dei dati:<br \/>\nU2.2.1.  tramite attacchi di tipo 'uomo nel mezzo (MiTM)' e reindirizzamento del traffico al nodo degli aggressori:<br \/>\nU2.2.1.1. Collegamento fisico dell'attrezzatura di attacco al punto di interruzione della connessione di rete.<br \/>\nU2.2.1.2. Attacchi ai protocolli di rete:<br \/>\nU2.2.1.2.1.  gestione delle reti locali virtuali (VLAN):<br \/>\nU2.2.1.2.1.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/VLAN_hopping\">VLAN hopping<\/a><\/noindex>.<br \/>\nU2.2.1.2.1.2. Modifica non autorizzata delle impostazioni VLAN su switch o router.<br \/>\nU2.2.1.2.2.  instradamento del traffico:<br \/>\nU2.2.1.2.2.1. Modifica non autorizzata delle tabelle di instradamento statico dei router.<br \/>\nU2.2.1.2.2.2. Annuncio di rotte false da parte di attaccanti attraverso protocolli di instradamento dinamico.<br \/>\nU2.2.1.2.3.  configurazione automatica:<br \/>\nU2.2.1.2.3.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Rogue_DHCP\">Rogue DHCP<\/a><\/noindex>.<br \/>\nU2.2.1.2.3.2. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.securitylab.ru\/analytics\/379619.php\">Rogue WPAD<\/a><\/noindex>.<br \/>\nU2.2.1.2.4.  indirizzamento e risoluzione dei nomi:<br \/>\nU2.2.1.2.4.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ARP-spoofing\">ARP spoofing<\/a><\/noindex>.<br \/>\nU2.2.1.2.4.2. <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/DNS_spoofing\">DNS spoofing<\/a><\/noindex>.<br \/>\nU2.2.1.2.4.3. Modifiche non autorizzate ai file locali di nomi dei nodi (hosts, lmhosts, ecc.)<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU3\"><\/a><\/noindex><\/p>\n<h3>U3. Violazione dei diritti d'autore sui dati trasmessi<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU3.1. Neutralizzazione dei meccanismi di determinazione dell'autore delle informazioni mediante l'indicazione di dati falsi sull'autore o sulla fonte delle informazioni:<br \/>\nU3.1.1. Modifica delle informazioni sull'autore contenute nelle informazioni trasmesse.<br \/>\nU3.1.1.1. Neutralizzazione della protezione crittografica dell'integrit\u00e0 e dell'autore delle informazioni trasmesse:<br \/>\nU3.1.1.1.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU4\">\u00abModello standard di minaccia. Sistema di protezione crittografica delle informazioni.<br \/>\nU4. Creazione di una firma elettronica da parte di un firmatario legittimo su dati falsi\u00bb<\/a><\/noindex>.<br \/>\nU3.1.1.2. Neutralizzazione della protezione del diritto d'autore dei dati trasferiti, realizzata tramite codici di conferma usa e getta:<br \/>\nU3.1.1.2.1. <noindex>Cambio SIM<\/noindex>.<\/p>\n<p>U3.1.2. Modifica delle informazioni sulla fonte dei dati trasmessi:<br \/>\nU3.1.2.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/IP_address_spoofing\">Spoofing IP<\/a><\/noindex>.<br \/>\nU3.1.2.2. <noindex><a rel=\"nofollow\" href=\"http:\/\/xgu.ru\/wiki\/MAC-spoofing\">Spoofing MAC<\/a><\/noindex>.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUIS\"><\/a><\/noindex><\/p>\n<h2>MODELLO TIPOLOGICO DI MINACCE. SISTEMA INFORMATIVO BASATO SU ARCHITETTURA CLIENT-SERVER<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione, per il quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto della protezione \u00e8 il sistema informativo costruito su architettura client-server.<\/p>\n<p><b>Architettura<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/f18c9c6c1e3d5372932d8c2a331284cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDescrizione degli elementi architettonici:<\/p>\n<ul>\n<li><i>\u00abCliente\u00bb<\/i> \u2013 il dispositivo sul quale funziona la parte client del sistema informativo.<\/li>\n<li><i>\u00abServer\u00bb<\/i> \u2013 il dispositivo sul quale funziona la parte server del sistema informativo.<\/li>\n<li><i>\u00abArchivio dati\u00bb<\/i> \u2013 parte dell'infrastruttura server del sistema informativo, destinata alla memorizzazione dei dati elaborati dal sistema informativo.<\/li>\n<li><i>\u00abConnessione di rete\u00bb<\/i> \u2013 canale di scambio di informazioni tra il Cliente e il Server, che attraversa la rete di trasmissione dati. Una descrizione pi\u00f9 dettagliata del modello dell'elemento \u00e8 fornita in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNC\">\u00abModello tipologico di minacce. Connessione di rete\u00bb<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\n<b>Limitazioni<\/b><br \/>\nNella modellazione dell'oggetto sono stati stabiliti i seguenti limiti:<\/p>\n<ol>\n<li>L'utente interagisce con il sistema informativo entro intervalli di tempo definiti, chiamati sessioni di lavoro.<\/li>\n<li>All'inizio di ogni sessione di lavoro avviene l'identificazione, l'autenticazione e l'autorizzazione dell'utente.<\/li>\n<li>Tutte le informazioni protette sono memorizzate nella parte server del sistema informativo.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU1. Azioni non autorizzate svolte da malintenzionati a nome di un utente legittimo.<br \/>\nU2. Modifica non autorizzata delle informazioni protette durante il loro trattamento da parte della parte server del sistema informativo.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUISU1\"><\/a><\/noindex><\/p>\n<h3>U1. Azioni non autorizzate svolte da malintenzionati a nome di un utente legittimo<\/h3>\n<p>\n<b>Chiarimenti<\/b><br \/>\nDi solito, nei sistemi informativi, la correlazione delle azioni con l'utente che le ha eseguite viene effettuata tramite:<\/p>\n<ol>\n<li>registri di sistema (logs). <\/li>\n<li>attributi speciali degli oggetti dati che contengono informazioni sull'utente che li ha creati o modificati.<\/li>\n<\/ol>\n<p>\nIn relazione alla sessione di lavoro, questa minaccia pu\u00f2 essere decomposta in:<\/p>\n<ol>\n<li>eseguiti nell'ambito della sessione di lavoro dell'utente.<\/li>\n<li>eseguiti al di fuori della sessione di lavoro dell'utente.<\/li>\n<\/ol>\n<p>\nLa sessione di lavoro dell'utente pu\u00f2 essere iniziata da:<\/p>\n<ol>\n<li>Dal medesimo utente.<\/li>\n<li>Da malintenzionati.<\/li>\n<\/ol>\n<p>\nIn questa fase, la decomposizione intermedia di questa minaccia apparir\u00e0 come segue:<br \/>\nU1.1. Azioni non autorizzate eseguite durante la sessione di lavoro dell'utente:<br \/>\nU1.1.1. , installato dall'utente attaccato.<br \/>\nU1.1.2. , installato dagli aggressori.<br \/>\nU1.2. Azioni non autorizzate eseguite al di fuori della sessione di lavoro dell'utente.<\/p>\n<p>Dal punto di vista degli oggetti dell'infrastruttura informatica sui quali possono agire i malintenzionati, la decomposizione delle minacce intermedie apparir\u00e0 come segue:<\/p>\n<p>Elementi<br \/>\nDecomposizione delle minacce<\/p>\n<p><b>U1.1.1.<\/b><br \/>\n<b>U1.1.2.<\/b><br \/>\n<b>U1.2.<\/b><\/p>\n<p>Cliente<br \/>\nU1.1.1.1.<br \/>\nU1.1.2.1.<\/p>\n<p>Connessione di rete<br \/>\nU1.1.1.2.<\/p>\n<p>Server<\/p>\n<p>U1.2.1.<\/p>\n<p>\n<b>Decomposizione<\/b><br \/>\nU1.1. Azioni non autorizzate eseguite durante la sessione di lavoro dell'utente:<br \/>\nU1.1.1. , installato dall'utente attaccato:<br \/>\nU1.1.1.1. I malintenzionati hanno agito autonomamente dal Cliente:<br \/>\nU1.1.1.1.1 I malintenzionati hanno utilizzato strumenti standard di accesso al sistema informatico:<br \/>\nU1.1.1.1.1.1. I malintenzionati hanno utilizzato mezzi fisici di input\/output del Cliente (tastiera, mouse, monitor o schermo touch di un dispositivo mobile):<br \/>\nU1.1.1.1.1.1.1. I malintenzionati hanno agito in periodi di tempo in cui la sessione \u00e8 attiva, i mezzi di input\/output sono disponibili e l'utente non \u00e8 presente.<br \/>\nU1.1.1.1.1.2. I malintenzionati hanno utilizzato strumenti di amministrazione remota (standard o forniti da codice dannoso) per controllare il Cliente:<br \/>\nU1.1.1.1.1.2.1. I malintenzionati hanno agito in periodi di tempo in cui la sessione \u00e8 attiva, i mezzi di input\/output sono disponibili e l'utente non \u00e8 presente.<br \/>\nU1.1.1.1.1.2.2. I malintenzionati hanno utilizzato strumenti di amministrazione remota la cui operativit\u00e0 \u00e8 invisibile per l'utente attaccato.<br \/>\nU1.1.1.2. I malintenzionati hanno sostituito i dati nella connessione di rete tra il Cliente e il Server, modificandoli in modo che venissero percepiti come azioni di un utente legittimo:<br \/>\nU1.1.1.2.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard di minaccia. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<br \/>\nU1.1.1.3. I malintenzionati hanno costretto l'utente a eseguire le azioni da loro indicate, utilizzando tecniche di ingegneria sociale.<\/p>\n<p>U1.1.2  installato dagli aggressori:<br \/>\nU1.1.2.1. I malintenzionati hanno agito dal Cliente (<b>E<\/b>):<br \/>\nU1.1.2.1.1. I malintenzionati hanno neutralizzato il sistema di controllo degli accessi del sistema informatico:<br \/>\nU1.1.2.1.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abModello standard di minacce. Sistema di controllo degli accessi. U1. Stabilirsi non autorizzatamente una sessione di lavoro a nome di un utente legittimo\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.1.2. Gli aggressori hanno utilizzato strumenti di accesso standard del sistema informativo<br \/>\nU1.1.2.2. Gli aggressori hanno agito da altri nodi della rete di trasmissione dati, da cui \u00e8 possibile stabilire una connessione di rete con il Server (<b>E<\/b>):<br \/>\nU1.1.2.2.1. Gli aggressori hanno neutralizzato il sistema di controllo degli accessi del sistema informativo:<br \/>\nU1.1.2.2.1.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abModello standard di minacce. Sistema di controllo degli accessi. U1. Stabilirsi non autorizzatamente una sessione di lavoro a nome di un utente legittimo\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.2.2. Gli aggressori hanno utilizzato strumenti di accesso non standard del sistema informativo.<br \/>\n<i>Spiegazioni U1.1.2.2.2.<\/i><br \/>\nGli aggressori potrebbero aver installato un client standard del sistema informativo su un nodo esterno oppure potrebbero aver utilizzato software non standard che implementa protocolli di scambio standard tra Cliente e Server.<\/p>\n<p>U1.2 Le azioni non autorizzate sono state effettuate al di fuori della sessione di lavoro dell'utente.<br \/>\nU1.2.1 Gli aggressori hanno compiuto azioni non autorizzate e poi hanno apportato modifiche non autorizzate ai registri di lavoro del sistema informativo o a attributi speciali degli oggetti dati, indicando che le azioni da loro effettuate sono state compiute da un utente legittimo.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUISU2\"><\/a><\/noindex><\/p>\n<h3>U2. Modifica non autorizzata di informazioni protette durante la loro elaborazione da parte della parte server del sistema informativo<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU2.1. Gli aggressori modificano informazioni protette utilizzando strumenti standard del sistema informativo, operando a nome di un utente legittimo.<br \/>\nU2.1.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU1\">\u00abModello standard di minacce. Sistema informativo basato su architettura client-server. U1. Esecuzione di azioni non autorizzate da parte degli aggressori a nome di un utente legittimo\u00bb<\/a><\/noindex>.<\/p>\n<p>U2.2. Gli aggressori modificano informazioni protette utilizzando meccanismi di accesso ai dati non previsti dal funzionamento standard del sistema informativo.<br \/>\nU2.2.1. Gli aggressori modificano file contenenti informazioni protette:<br \/>\nU2.2.1.1. , utilizzando i meccanismi di gestione dei file forniti dal sistema operativo.<br \/>\nU2.2.1.2.  provocando il ripristino dei file da una copia di backup non autorizzatamente modificata.<\/p>\n<p>U2.2.2. Gli aggressori modificano informazioni protette conservate nel database (<b>E<\/b>):<br \/>\nU2.2.2.1. Gli aggressori neutralizzano il sistema di controllo degli accessi del DBMS:<br \/>\nU2.2.2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abModello standard di minacce. Sistema di controllo degli accessi. U1. Stabilirsi non autorizzatamente una sessione di lavoro a nome di un utente legittimo\u00bb<\/a><\/noindex>.<br \/>\nU2.2.2.2. Gli aggressori modificano le informazioni utilizzando interfacce standard del DBMS per accedere ai dati.<\/p>\n<p>U2.3. Gli aggressori modificano informazioni protette attraverso la modifica non autorizzata degli algoritmi di funzionamento del software che le elabora.<br \/>\nU2.3.1. Il codice sorgente del software \u00e8 soggetto a modifiche.<br \/>\nU2.3.1. Il codice macchina del software \u00e8 soggetto a modifiche.<\/p>\n<p>U2.4. Gli aggressori modificano informazioni protette sfruttando vulnerabilit\u00e0 nel software del sistema informatico.<\/p>\n<p>U2.5. Gli aggressori modificano informazioni protette durante il loro trasferimento tra i componenti della parte server del sistema informatico (ad esempio, server di database e server delle applicazioni):<br \/>\nU2.5.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard di minaccia. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUSRD\"><\/a><\/noindex><\/p>\n<h2>MODELLO TIPO DI MINACCE. SISTEMA DI CONTROLLO DEGLI ACCESSI<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione, per il quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto di protezione per il quale si applica questo modello di minacce corrisponde all'oggetto di protezione del modello di minacce: \u00abModello tipo di minacce. Sistema informatico basato sull'architettura client-server\u00bb.<\/p>\n<p>Con sistema di controllo degli accessi degli utenti in questo modello di minacce si intende un componente del sistema informatico che realizza le funzioni:<\/p>\n<ol>\n<li>Identificazione degli utenti.<\/li>\n<li>Autenticazione degli utenti.<\/li>\n<li>Autorizzazione degli utenti.<\/li>\n<li>Registrazione delle azioni degli utenti.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU1. Stabilire una sessione di lavoro non autorizzata a nome di un utente legittimo. <br \/>\nU2. Aumento non autorizzato dei privilegi degli utenti nel sistema informatico.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSRDU1\"><\/a><\/noindex> <\/p>\n<h3>U1. Stabilire una sessione di lavoro non autorizzata a nome di un utente legittimo <\/h3>\n<p>\n<b>Chiarimenti<\/b><br \/>\nLa decomposizione di questa minaccia, in generale, dipender\u00e0 dal tipo di sistemi di identificazione e autenticazione degli utenti utilizzati. <\/p>\n<p>In questo modello considereremo solo un sistema di identificazione e autenticazione degli utenti che utilizza un nome utente e una password testuali. In questo caso, considereremo che il nome utente sia un'informazione di pubblico accesso, nota agli aggressori.<\/p>\n<p><b>Decomposizione<\/b><br \/>\nU1.1.  attraverso la compromissione delle credenziali:<br \/>\nU1.1.1. Gli aggressori hanno compromesso i dati di accesso dell'utente durante la loro conservazione.<br \/>\n<i>Spiegazioni U1.1.1.<\/i><br \/>\nAd esempio, i dati di accesso potrebbero essere stati scritti su un adesivo attaccato al monitor.<\/p>\n<p>U1.1.2. L'utente ha accidentalmente o con malizia trasmesso i dati di accesso ai malintenzionati.<br \/>\nU1.1.2.1. L'utente ha pronunciato le credenziali ad alta voce durante l'inserimento.<br \/>\nU1.1.2.2. L'utente ha intenzionalmente trasmesso le proprie credenziali:<br \/>\nU1.1.2.2.1.  ai colleghi di lavoro.<br \/>\n<i>Chiarimenti U1.1.2.2.1.<\/i><br \/>\nAd esempio, affinch\u00e9 possano sostituirlo durante un periodo di malattia.<\/p>\n<p>U1.1.2.2.2.  ai contraenti del datore di lavoro che svolgono lavori su oggetti delle infrastrutture informative.<br \/>\nU1.1.2.2.3.  a terzi.<br \/>\n<i>Chiarimenti U1.1.2.2.3.<\/i><br \/>\nUna delle, ma non l'unica, modalit\u00e0 di attuazione di questa minaccia \u00e8 l'uso da parte dei malintenzionati di metodi di ingegneria sociale.<\/p>\n<p>U1.1.3. I malintenzionati hanno indovinato le credenziali mediante tentativi:<br \/>\nU1.1.3.1.  utilizzando meccanismi di accesso standard.<br \/>\nU1.1.3.2.  tramite codici precedentemente intercettati (ad esempio, hash delle password) per la memorizzazione delle credenziali.<\/p>\n<p>U1.1.4. I malintenzionati hanno utilizzato codice malevolo per intercettare le credenziali dell'utente.<\/p>\n<p>U1.1.5. I malintenzionati hanno estratto le credenziali da una connessione di rete tra il Client e il Server:<br \/>\nU1.1.5.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU1\">\u00abModello esemplare di minaccia. Connessione di rete. U1. Accesso non autorizzato ai dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.1.6. I malintenzionati hanno estratto le credenziali da registrazioni di sistemi di monitoraggio delle attivit\u00e0:<br \/>\nU1.1.6.1.  sistemi di videosorveglianza (nel caso in cui durante il lavoro siano stati registrati i tasti premuti sulla tastiera).<br \/>\nU1.1.6.2.  sistemi di controllo delle azioni dei dipendenti al computer. <br \/>\n<i>Chiarimenti U1.1.6.2.<\/i><br \/>\nUn esempio di tale sistema \u00e8 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.staffcop.ru\">StuffCop<\/a><\/noindex>.<\/p>\n<p>U1.1.7. I malintenzionati hanno compromesso le credenziali dell'utente a causa di difetti nel processo di trasmissione.<br \/>\n<i>Chiarimenti U1.1.7.<\/i><br \/>\nAd esempio, la trasmissione delle password in chiaro tramite email.<\/p>\n<p>U1.1.8. I malintenzionati hanno appreso le credenziali osservando la sessione di lavoro dell'utente tramite sistemi di amministrazione remota.<\/p>\n<p>U1.1.9. I malintenzionati hanno estratto le credenziali a seguito della loro fuga tramite canali tecnici (TCUI):<br \/>\nU1.1.9.1. I malintenzionati hanno spiateo come l'utente inserisce le credenziali dalla tastiera:<br \/>\nU1.1.9.1.1 I malintenzionati si trovavano a stretto contatto con l'utente e vedevano l'inserimento delle credenziali con i propri occhi. <br \/>\n<i>Chiarimenti U1.1.9.1.1<\/i><br \/>\nA casi come questi si possono riferire le azioni dei colleghi di lavoro o la situazione in cui la tastiera dell'utente \u00e8 visibile ai visitatori dell'organizzazione.<\/p>\n<p>U1.1.9.1.2 Gli aggressori hanno utilizzato dispositivi tecnici aggiuntivi, come binocoli o droni, e hanno visto l'immissione dei dati di accesso attraverso una finestra. <br \/>\nU1.1.9.2. Gli aggressori hanno estratto i dati di accesso dalle comunicazioni radio tra la tastiera e l'unit\u00e0 centrale del computer, nel caso in cui fossero collegati tramite interfaccia radio (ad esempio, Bluetooth).<br \/>\nU1.1.9.3. Gli aggressori hanno intercettato i dati di accesso a causa della loro fuoriuscita tramite canali di radiazioni elettromagnetiche spurie e interferenze (PEMI).<br \/>\n<i>Chiarimenti U1.1.9.3.<\/i><br \/>\nEsempi di attacco <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=tMSglPLIDYU\">qui<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cl.cam.ac.uk\/~mgk25\/pet2004-fpd.pdf\">qui<\/a><\/noindex>. <\/p>\n<p>U1.1.9.4. L'aggressore ha intercettato l'immissione dei dati di accesso dalla tastiera utilizzando dispositivi tecnici speciali (STS) destinati a raccogliere informazioni in modo occulto.<br \/>\n<i>Chiarimenti U1.1.9.4.<\/i><br \/>\nEsempi <noindex>dispositivi<\/noindex>. <\/p>\n<p>U1.1.9.5. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera tramite <br \/>\nl'analisi del segnale Wi-Fi, modulato dal processo di pressione dei tasti da parte dell'utente.<br \/>\n<i>Chiarimenti U1.1.9.5.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/threatpost.com\/keystroke-recognition-uses-wi-fi-signals-to-snoop\/120135\/\">attacchi<\/a><\/noindex>.<\/p>\n<p>U1.1.9.6. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera attraverso l'analisi dei suoni di pressione dei tasti.<br \/>\n<i>Chiarimenti U1.1.9.6.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/398545\/\">attacchi<\/a><\/noindex>.<\/p>\n<p>U1.1.9.7. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera di un dispositivo mobile analizzando i dati dell'accelerometro.<br \/>\n<i>Chiarimenti U1.1.9.7.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/126806\/\">attacchi<\/a><\/noindex>.<\/p>\n<p>U1.1.10. , precedentemente salvati sul Cliente.<br \/>\n<i>Chiarimenti U1.1.10.<\/i><br \/>\nAd esempio, l'utente poteva salvare nel browser nome utente e password per accedere a un determinato sito web.<\/p>\n<p>U1.1.11. Gli aggressori hanno compromesso i dati di accesso a causa di carenze nel processo di revoca degli accessi degli utenti.<br \/>\n<i>Chiarimenti U1.1.11.<\/i><br \/>\nAd esempio, dopo il licenziamento dell'utente, i suoi account sono rimasti attivi.<\/p>\n<p>U1.2.  a causa dell'uso di vulnerabilit\u00e0 nel sistema di separazione degli accessi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSRDU2\"><\/a><\/noindex> <\/p>\n<h3>U2. Elevazione non autorizzata dei privilegi dell'utente nel sistema informatico<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU2.1  attraverso modifiche non autorizzate ai dati contenenti informazioni sui privilegi dell'utente.<\/p>\n<p>U2.2  a causa dell'uso di vulnerabilit\u00e0 nel sistema di separazione degli accessi.<\/p>\n<p>U2.3.  a causa di difetti nel processo di gestione degli accessi agli utenti.<br \/>\n<i>Spiegazione U2.3.<\/i><br \/>\nEsempio 1. All'utente \u00e8 stato fornito un accesso maggiore rispetto a quello necessario per le sue esigenze lavorative.<br \/>\nEsempio 2. Dopo aver trasferito l'utente in un'altra posizione, i diritti di accesso precedentemente concessi non sono stati revocati.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUMI\"><\/a><\/noindex><\/p>\n<h2>MODULO STANDARD DI MINACCIA. MODULO DI INTEGRAZIONE<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione, per il quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nIl modulo di integrazione \u00e8 un insieme di oggetti dell'infrastruttura informatica, destinati a organizzare lo scambio di informazioni tra i sistemi informativi.<\/p>\n<p>Tenendo conto del fatto che nelle reti aziendali non \u00e8 sempre possibile separare inequivocabilmente un sistema informativo da un altro, il modulo di integrazione pu\u00f2 essere considerato anche come un collegamento tra i componenti all'interno di un singolo sistema informativo.<\/p>\n<p><b>Architettura<\/b><br \/>\nSchema generale del modulo di integrazione:<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/6b91d59698b761a14aef7f1c4fbec325.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDescrizione degli elementi architettonici:<\/p>\n<ul>\n<li><i>\u00abServer di scambio (SS)\u00bb<\/i> \u2013 nodo \/ servizio \/ componente del sistema informativo, che svolge la funzione di scambio dati con un altro sistema informativo.<\/li>\n<li><i>\u00abIntermediario\u00bb<\/i> \u2013 nodo \/ servizio, destinato a organizzare l'interazione tra i sistemi informativi, ma non facente parte di essi. <br \/>\nEsempi di <i>\u00abIntermediari\u00bb<\/i> possono essere i servizi di posta elettronica, i bus di servizio aziendali (enterprise service bus \/ architettura SoA), i server di file di terzi, ecc. In generale, il modulo di integrazione pu\u00f2 anche non contenere \u00abIntermediari\u00bb.<\/li>\n<li><i>\u00abSOFTWARE DI ELABORAZIONE DATI\u00bb<\/i> \u2013 insieme di programmi che implementano i protocolli di scambio dati e la conversione dei formati. <br \/>\nAd esempio, la conversione dei dati dal formato UFEBS al formato ABS, la modifica degli stati dei messaggi durante la trasmissione, ecc.<\/li>\n<li><i>\u00abConnessione di rete\u00bb<\/i> corrisponde all'oggetto descritto nel modello standard di minacce \u00abConnessione di rete\u00bb. Potrebbe non esserci alcuni dei collegamenti di rete rappresentati nello schema sopra.<\/li>\n<\/ul>\n<p><b>Esempi di moduli di integrazione<\/b><\/p>\n<p><i>Schema 1. Integrazione ABS e ARM KBR tramite server di file di terzi<\/i><\/p>\n<p>Per eseguire i pagamenti, il dipendente autorizzato della banca estrae dai documenti di pagamento elettronici ABS e li salva in un file (di formato proprio, ad esempio SQL-dump) sulla cartella di rete (\u2026SHARE) del server di file. Successivamente, questo file viene convertito in un insieme di file nel formato UFEBS tramite uno script di conversione, che viene quindi letto dall'ARM KBR. <br \/>\nDopo di ci\u00f2, l'operatore autorizzato \u2014 utente dell'ARM KBR \u2014 cripta e firma il file ricevuto e lo invia al sistema di pagamento della Banca di Russia.<\/p>\n<p>All'arrivo dei pagamenti dalla Banca di Russia, l'ARM KBR procede alla loro decrittazione e verifica della firma elettronica, dopodich\u00e9 li registra come un insieme di file nel formato UFBBS sul server file. Prima dell'importazione dei documenti di pagamento nell'ABS, vengono convertiti tramite uno script di conversione dal formato UFBBS al formato ABS. <\/p>\n<p>Consideriamo che in questo schema l'ABS funzioni su un singolo server fisico, l'ARM KBR funzioni su un computer dedicato e lo script di conversione lavori su un server file.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/bef53aaa1deaee5adeca620204345642.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio dall'ABS\u00bb<\/i> \u2013 server ABS.<br \/>\n<i>\u00abServer di scambio dall'ARM KBR\u00bb<\/i> \u2013 computer ARM KBR.<br \/>\n<i>\u00abIntermediario\u00bb<\/i> \u2013 server file esterno.<br \/>\n<i>\u00abSOFTWARE DI ELABORAZIONE DATI\u00bb<\/i> \u2013 script di conversione.<\/p>\n<p><i>Schema 2. Integrazione dell'ABS e dell'ARM KBR tramite la creazione di una cartella di rete condivisa con i pagamenti sull'ARM KBR<\/i><\/p>\n<p>Tutto come nello Schema 1, ma non viene utilizzato un server di file separato; invece, la cartella di rete (\u2026SHARE) con i documenti di pagamento elettronici si trova sul computer con ARM KBR. Lo script di conversione funziona anche su ARM KBR.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/7d3ecde6d78b2c45e1249236c7da925b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:<br \/>\nAnalogamente allo Schema 1, ma <i>\u00abIntermediario\u00bb<\/i> non viene utilizzato.<\/p>\n<p><i>Schema 3. Integrazione dell'ABS e dell'ARM KBR-N tramite IBM WebSphere MQ e firma dei documenti elettronici \"lato ABS\".<\/i><\/p>\n<p>L'ABS opera su una piattaforma non supportata dal sistema di protezione delle informazioni SKAD Signature. La firma dei documenti elettronici in uscita viene effettuata su un server speciale di firma elettronica (Server EP). Questo stesso server verifica la firma elettronica sui documenti in arrivo dalla Banca di Russia.<\/p>\n<p>L'ABS scarica sul Server EP un file con i documenti di pagamento nel proprio formato.<br \/>\nIl Server EP, tramite lo script di conversione, converte il file in messaggi elettronici nel formato UFBBS, dopodich\u00e9 i messaggi elettronici vengono firmati e inviati a IBM WebSphere MQ.<\/p>\n<p>L'ARM KBR-N accede a IBM WebSphere MQ e riceve da l\u00ec i messaggi di pagamento firmati, dopo di ch\u00e9 l'operatore autorizzato \u2014 utente dell'ARM KBR \u2014 li cripta e li invia al sistema di pagamento della Banca di Russia.<\/p>\n<p>Al ricevimento dei pagamenti dalla Banca di Russia, l'ARM KBR-N li decifra e verifica la firma elettronica. I pagamenti elaborati con successo, sotto forma di messaggi elettronici decifrati e firmati nel formato UFEB, vengono inviati a IBM WebSphere MQ, da dove vengono ricevuti dal Server EP.<\/p>\n<p>Il Server EP verifica la firma elettronica dei pagamenti ricevuti e li salva in un file nel formato ABS. Successivamente, un lavoratore autorizzato \u2014 utente ABS \u2014 carica il file risultante nell'ABS secondo la procedura stabilita.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/b1bd9c224b18dc84cca5f8bdc7d69713.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio dal lato ABS\u00bb<\/i> \u2013 server ABS.<br \/>\n<i>\u00abServer di scambio dal lato ARM KBR\u00bb<\/i> \u2014 computer ARM KBR.<br \/>\n<i>\u00abIntermediario\u00bb<\/i> \u2013 Server EP e IBM WebSphere MQ.<br \/>\n<i>\u00abSOFTWARE DI ELABORAZIONE DATI\u00bb<\/i> \u2013 script convertitore, SCZI SKAD Firma sul Server EP.<\/p>\n<p><i>Schema 4. Integrazione del Server DBO e ABS tramite API fornito da un server di scambio dedicato<\/i><\/p>\n<p>Supponiamo che la banca utilizzi diversi sistemi di banking a distanza (DBO): <\/p>\n<ul>\n<li>\u00abInternet Client-Bank\u00bb per le persone fisiche (ICB PF);<\/li>\n<li>\u00abInternet Client-Bank\u00bb per le persone giuridiche (ICB PJ). <\/li>\n<\/ul>\n<p>\nAl fine di garantire la sicurezza informatica, tutta l'interazione tra ABS e i sistemi DBO avviene tramite un server di scambio dedicato, operante all'interno del sistema informativo \u00abABS\u00bb.<\/p>\n<p>Successivamente, esaminiamo il processo di interazione del sistema DBO ICB PJ con ABS.<br \/>\nIl Server DBO, ricevuto dal cliente l'ordine di pagamento debitamente certificato, deve crearne il corrispondente documento in ABS. A tal fine, invia le informazioni al server di scambio tramite API, che a sua volta inserisce i dati nell'ABS. <\/p>\n<p>In caso di modifica dei saldi sul conto del cliente, ABS genera notifiche elettroniche che vengono trasmesse al server DBO tramite il server di scambio.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/63f88ad151996e7ddaa883349a6d8e22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio dal lato DBO\u00bb<\/i> \u2013 server DBO ICB PJ.<br \/>\n<i>\u00abServer di scambio dal lato ABS\u00bb<\/i> \u2013 server di scambio.<br \/>\n<i>\u00abIntermediario\u00bb<\/i> \u2013 assente.<br \/>\n<i>\u00abSOFTWARE DI ELABORAZIONE DATI\u00bb<\/i> \u2013 componenti del Server DBO responsabili dell'utilizzo dell'API del server di scambio, componenti del server di scambio responsabili dell'utilizzo dell'API ABS.<\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU1. Introduzione di informazioni false da parte di attaccanti tramite il modulo di integrazione. <br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUMIU1\"><\/a><\/noindex><\/p>\n<h3>U1. Introduzione di informazioni false da parte di attaccanti tramite il modulo di integrazione <\/h3>\n<p><b>Decomposizione<\/b><br \/>\nU1.1. Modifica non autorizzata di dati legittimi durante la loro trasmissione tramite connessioni di rete:<br \/>\nU1.1.1 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard di minaccia. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.2. Trasmissione di dati falsi tramite canali di comunicazione a nome di un legittimo partecipante allo scambio:<br \/>\nU1.1.2 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU3\">\u00abModello standard di minacce. Connessione di rete. U3. Violazione della paternit\u00e0 dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.3. Modifica non autorizzata di dati legittimi durante la loro elaborazione sui server di scambio o sul Mediatore:<br \/>\nU1.3.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU2\">\u00abModello standard di minacce. Sistema informativo basato su architettura client-server. U2. Modifica non autorizzata di informazioni protette durante la loro elaborazione dalla parte server del sistema informativo\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.4. Creazione di dati falsi sui server di scambio o sul Mediatore a nome di un partecipante legittimo allo scambio:<br \/>\nU1.4.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU1\">\u00abModello standard di minacce. Sistema informativo basato su architettura client-server. U1. Esecuzione di azioni non autorizzate da parte di malintenzionati a nome di un utente legittimo\u00bb.<\/a><\/noindex><\/p>\n<p>U1.5. Modifica non autorizzata di dati durante la loro elaborazione tramite software di elaborazione dati:<br \/>\nU1.5.1.  a causa delle modifiche non autorizzate apportate dagli attaccanti alle impostazioni (configurazioni) del software di elaborazione dei dati.<br \/>\nU1.5.2.  a causa delle modifiche non autorizzate apportate dagli attaccanti ai file eseguibili del software di elaborazione dei dati.<br \/>\nU1.5.3.  a causa del controllo interattivo degli attaccanti del funzionamento del software di elaborazione dei dati.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZI\"><\/a><\/noindex><\/p>\n<h2>MODELLO STANDARD DI MINACCE. SISTEMA DI PROTEZIONE CRIPTOGRAFICA DELLE INFORMAZIONI<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione, per il quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nOggetto della protezione \u00e8 il sistema di protezione criptografica delle informazioni, utilizzato per garantire la sicurezza del sistema informativo.<\/p>\n<p><b>Architettura<\/b><br \/>\nLa base di qualsiasi sistema informativo \u00e8 il software applicativo (SW), che realizza le sue funzionalit\u00e0 mirate. <\/p>\n<p>La protezione crittografica viene solitamente attuata tramite la chiamata dalla logica di business del software applicativo a primitive crittografiche, che sono collocate in librerie specializzate - core crittografici.<\/p>\n<p>Le primitive crittografiche includono funzioni crittografiche a basso livello, come:<\/p>\n<ul>\n<li>cifrare \/ decifrare un blocco di dati;<\/li>\n<li>creare \/ verificare una firma elettronica di un blocco di dati;<\/li>\n<li>calcolare la funzione hash di un blocco di dati;<\/li>\n<li>formare \/ caricare \/ scaricare informazioni chiave;<\/li>\n<li>ecc.<\/li>\n<\/ul>\n<p>\nLa logica di business del software applicativo realizza tramite primitive crittografiche funzionalit\u00e0 a livello superiore:<\/p>\n<ul>\n<li>cifrare un file con le chiavi dei destinatari selezionati;<\/li>\n<li>impostare una connessione di rete sicura;<\/li>\n<li>informare sui risultati della verifica della firma elettronica;<\/li>\n<li>ecc.<\/li>\n<\/ul>\n<p>\nL'interazione tra la logica di business e il nucleo crittografico pu\u00f2 avvenire:<\/p>\n<ul>\n<li>direttamente, attraverso la chiamata da parte della logica di business ai primitivi crittografici da librerie dinamiche del nucleo crittografico (.DLL \u2013 per Windows, .SO \u2013 per Linux);<\/li>\n<li>indirettamente, tramite interfacce crittografiche - wrapper, ad esempio, MS Crypto API, Java Cryptography Architecture, PKCS#11, ecc. In questo caso, la logica di business si rivolge all'interfaccia crittografica, la quale traduce la chiamata al corrispondente nucleo crittografico, che in tal caso \u00e8 chiamato fornitore di criptografia. L'uso delle interfacce crittografiche consente al software applicativo di astrarsi dagli algoritmi crittografici specifici e di essere pi\u00f9 flessibile.<\/li>\n<\/ul>\n<p>\nSi possono identificare due schemi tipici di organizzazione del nucleo crittografico:<\/p>\n<p><i>Schema 1 \u2013 Nucleo crittografico monolitico<\/i><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/e5186d11e4e0e9ad9361f3935228bc30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Schema 2 \u2013 Nucleo crittografico separato<\/i><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/9953d524fbee78d7e4eb917e9d56a38f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli elementi negli schemi presentati possono essere sia moduli software separati, che operano su un singolo computer, sia servizi di rete che interagiscono all'interno di una rete di calcolo.<\/p>\n<p>Nell'uso di sistemi costruiti secondo lo schema 1, il software applicativo e il nucleo crittografico operano all'interno di un'unica ambiente di funzionamento del mezzo crittografico (SFC), ad esempio, sullo stesso computer, sotto la gestione dello stesso sistema operativo. L'utente del sistema, di solito, pu\u00f2 avviare all'interno di questo stesso ambiente di funzionamento anche altri programmi, inclusi quelli contenenti codice dannoso. In tali condizioni esiste un serio rischio di perdita delle chiavi crittografiche riservate.<\/p>\n<p>Per minimizzare il rischio si applica lo schema 2, in cui il nucleo crittografico \u00e8 diviso in due parti:<\/p>\n<ol>\n<li>La prima parte, insieme al software applicativo, opera in un ambiente non fidato, dove esiste il rischio di infezione da codice dannoso. Chiamiamo questa parte \"parte software\".<\/li>\n<li>La seconda parte opera in un ambiente fidato su un dispositivo dedicato, che contiene al suo interno un deposito di chiavi riservate. Chiamiamo questa parte \"parte hardware\".<\/li>\n<\/ol>\n<p>\nLa separazione del nucleo crittografico in parti software e hardware \u00e8 piuttosto convenzionale. Nel mercato ci sono sistemi costruiti secondo uno schema con nucleo crittografico separato, ma la parte \"hardware\" \u00e8 rappresentata da un'immagine di macchina virtuale \u2014 virtual HSM (<noindex><a rel=\"nofollow\" href=\"https:\/\/www.unboundtech.com\/product\/unbound-key-control\/\">un esempio<\/a><\/noindex>).<\/p>\n<p>L'interazione tra le due parti del nucleo crittografico avviene in modo tale che le chiavi crittografiche private non vengono mai trasferite nella parte software e, di conseguenza, non possono essere rubate mediante codice dannoso.<\/p>\n<p>L'interfaccia di interazione (API) e il set di primitivi crittografici forniti al software applicativo dal nucleo crittografico sono identici in entrambi i casi. La differenza risiede nel modo in cui vengono implementati.<\/p>\n<p>Pertanto, nell'utilizzare uno schema con nucleo crittografico separato, l'interazione tra la parte software e hardware avviene secondo il seguente principio:<\/p>\n<ol>\n<li>I primitivi crittografici che non richiedono l'uso di una chiave privata (ad esempio, il calcolo della funzione hash, la verifica della firma elettronica, ecc.) sono eseguiti dalla parte software.<\/li>\n<li>I primitivi crittografici che utilizzano una chiave privata (creazione di una firma elettronica, decrittazione dei dati, ecc.) sono eseguiti dalla parte hardware.<\/li>\n<\/ol>\n<p>\nIllustriamo il funzionamento del nucleo crittografico separato con un esempio di creazione di una firma elettronica:<\/p>\n<ol>\n<li>La parte software calcola la funzione hash dei dati da firmare e trasmette questo valore alla parte hardware tramite il canale di scambio tra i nuclei crittografici.<\/li>\n<li>La parte hardware, utilizzando la chiave privata e l'hash, genera il valore della firma elettronica e lo trasmette alla parte software tramite il canale di scambio.<\/li>\n<li>La parte software restituisce il valore ottenuto al software applicativo.<\/li>\n<\/ol>\n<p>\n<b>Caratteristiche della verifica della correttezza della firma elettronica<\/b><\/p>\n<p>Quando la parte ricevente riceve dati firmati con una firma elettronica, deve eseguire diverse fasi di verifica. Un risultato positivo della verifica della firma elettronica viene raggiunto solo al termine di tutte le fasi di verifica.<\/p>\n<p><i>Fase 1. Controllo dell'integrit\u00e0 dei dati e dell'autenticit\u00e0 dei dati.<\/i><\/p>\n<p><u>Contenuto della fase.<\/u> Viene effettuato un controllo della firma elettronica dei dati secondo il corrispondente algoritmo crittografico. Il superamento con successo di questa fase indica che i dati non sono stati modificati dal momento della loro firma, e inoltre che la firma \u00e8 stata eseguita con una chiave privata corrispondente alla chiave pubblica per il controllo della firma elettronica.<br \/>\n<u>Luogo di esecuzione della fase:<\/u> nucleo crittografico.<\/p>\n<p><i>Fase 2. Controllo della fiducia nella chiave pubblica del firmatario e verifica della validit\u00e0 della chiave privata di firma elettronica.<\/i><br \/>\n<u>Contenuto della fase.<\/u> La fase \u00e8 composta da due sottofasi intermedie. Nella prima si stabilisce se la chiave pubblica per il controllo della firma elettronica fosse fidata al momento della firma dei dati. Nella seconda si verifica se la chiave privata di firma elettronica fosse valida al momento della firma dei dati. In linea generale, le scadenze di queste chiavi potrebbero non coincidere (ad esempio, per i certificati qualificati delle chiavi di controllo della firma elettronica). I metodi per stabilire la fiducia nella chiave pubblica del firmatario sono definiti dalle regole del documento elettronico adottate dalle parti coinvolte.<br \/>\n<u>Luogo di esecuzione della fase:<\/u> software applicativo \/ nucleo crittografico.<\/p>\n<p><i>Fase 3. Controllo dei poteri del firmatario.<\/i><br \/>\n<u>Contenuto della fase.<\/u> In conformit\u00e0 alle regole stabilite per il commercio elettronico, si verifica se il firmatario avesse il diritto di attestare i dati protetti. Ad esempio, consideriamo una situazione di violazione dei poteri. Supponiamo che ci sia un\u2019organizzazione in cui tutti i dipendenti hanno una firma elettronica. Un ordine del dirigente entra nel sistema interno di gestione dei documenti elettronici, ma \u00e8 firmato con la firma elettronica del responsabile del magazzino. Di conseguenza, tale documento non pu\u00f2 essere considerato legittimo.<br \/>\n<u>Luogo di esecuzione della fase:<\/u> software applicativo.<\/p>\n<p><b>Assunzioni fatte nella descrizione dell'oggetto di protezione<\/b><\/p>\n<ol>\n<li>I canali di trasmissione delle informazioni, ad eccezione dei canali per lo scambio di chiavi, passano anche attraverso il software applicativo, l'API e il nucleo crittografico.<\/li>\n<li>Le informazioni sulla fiducia nelle chiavi pubbliche e\/o nei certificati, cos\u00ec come le informazioni sui poteri dei detentori delle chiavi pubbliche, sono collocate nel deposito delle chiavi pubbliche.<\/li>\n<li>Il software applicativo interagisce con il deposito delle chiavi pubbliche attraverso il nucleo crittografico.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Esempio di un sistema informativo protetto mediante SKZI<\/h3>\n<p>\nPer illustrare gli schemi precedentemente presentati, consideriamo un ipotetico sistema informativo e evidenziamo tutti gli elementi strutturali in esso. <\/p>\n<p><b>Descrizione del sistema informativo<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/74f3e2fd669ed97f50253fbb4b348f6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDue organizzazioni hanno deciso di implementare un flusso documentale elettronico (FDE) legalmente valido tra di loro. A tal fine, hanno stipulato un accordo in cui \u00e8 stato specificato che i documenti saranno trasmessi tramite email, e dovranno essere crittografati e firmati con una firma elettronica qualificata. Come strumenti per la creazione e l'elaborazione dei documenti, saranno utilizzati programmi per ufficio del pacchetto Microsoft Office 2016, mentre come mezzi di protezione crittografica saranno utilizzati il sistema di crittografia KryptoPRO e il software di crittografia KryptoARM.<\/p>\n<p><b>Descrizione dell'infrastruttura dell'organizzazione 1<\/b><\/p>\n<p>L'organizzazione 1 ha deciso di installare KryptoPRO e KryptoARM su un computer client fisico. Le chiavi di crittografia e di firma elettronica saranno conservate su un dispositivo di chiave ruToken, che opera in modalit\u00e0 chiave estraibile. L'utente preparer\u00e0 i documenti elettronici localmente sul proprio computer, per poi crittografarli, firmarli e inviarli tramite un client di posta installato localmente.<\/p>\n<p><b>Descrizione dell'infrastruttura dell'organizzazione 2<\/b><\/p>\n<p>L'organizzazione 2 ha deciso di esternalizzare le funzioni di crittografia e firma elettronica su una macchina virtuale dedicata. Tutte le operazioni crittografiche saranno eseguite in modo automatico. <\/p>\n<p>Per questo, su una macchina virtuale dedicata sono state organizzate due cartelle di rete: \u00ab\u2026In\u00bb, \u00ab\u2026Out\u00bb. Nella cartella di rete \u00ab\u2026In\u00bb verranno automaticamente inseriti i file ricevuti dal contraente in chiaro. Questi file verranno decrittografati e sar\u00e0 verificata la firma elettronica.<\/p>\n<p>Nella cartella &laquo;&hellip;Out&raquo; l'utente posizioner\u00e0 i file da crittografare, firmare e inviare al contraente. I file stessi saranno preparati dal proprio workstation.<br \/>\nPer l'esecuzione delle funzioni di crittografia e firma elettronica, sulla macchina virtuale sono stati installati KryptoPRO, KryptoARM e un client di posta. La gestione automatica di tutti gli elementi della macchina virtuale sar\u00e0 effettuata tramite script sviluppati dagli amministratori di sistema. Il funzionamento degli script sar\u00e0 registrato in file di log.<\/p>\n<p>Le chiavi crittografiche della firma elettronica saranno memorizzate su un token con chiave non rimovibile JaCarta \u0413\u041e\u0421\u0422, che l'utente collegher\u00e0 al proprio computer locale.<\/p>\n<p>Il token sar\u00e0 passato a una macchina virtuale tramite software specializzati USB-over-IP installati sul posto di lavoro dell'utente e sulla macchina virtuale.<\/p>\n<p>L'orologio di sistema sul posto di lavoro dell'utente nell'organizzazione 1 sar\u00e0 regolato manualmente. L'orologio di sistema della macchina virtuale nell'organizzazione 2 sar\u00e0 sincronizzato con l'orologio di sistema del hypervisor, che a sua volta sar\u00e0 sincronizzato tramite Internet con server pubblici di riferimento temporale.<\/p>\n<p><b>Identificazione degli elementi strutturali del SKZI<\/b><br \/>\nIn base alla descrizione fornita dell'infrastruttura IT, identificheremo gli elementi strutturali del SKZI e li registreremo in una tabella.<\/p>\n<p><i>Tabella \u2014 Corrispondenza degli elementi del modello SKZI con gli elementi dei sistemi informativi<\/i> <\/p>\n<p><b>Nome dell'elemento<\/b><br \/>\n<b>Organizzazione 1<\/b><br \/>\n<b>Organizzazione 2<\/b><\/p>\n<p>Software applicativo<br \/>\nSoftware CryptoARM<br \/>\nSoftware CryptoARM<\/p>\n<p>Parte software del nucleo crittografico<br \/>\nSKZI CryptoPRO CSP<br \/>\nSKZI CryptoPRO CSP<\/p>\n<p>Parte hardware del nucleo crittografico<br \/>\n\u00e8 assente<br \/>\nJaCarta \u0413\u041e\u0421\u0422<\/p>\n<p>API<br \/>\nMS CryptoAPI<br \/>\nMS CryptoAPI<\/p>\n<p>Archivio delle chiavi pubbliche<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 archivio standard dei certificati di Windows.<br \/>\nHypervisor:<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 archivio standard dei certificati di Windows.<\/p>\n<p>Archivio delle chiavi private<br \/>\nDispositivo di crittografia ruToken, operante in modalit\u00e0 chiave rimovibile<br \/>\nDispositivo di crittografia JaCarta \u0413\u041e\u0421\u0422, operante in modalit\u00e0 chiave non rimovibile<\/p>\n<p>Canale di scambio delle chiavi pubbliche<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 memoria RAM.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 memoria RAM.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria RAM.<\/p>\n<p>Canale di scambio delle chiavi private<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 bus USB;<br \/>\n \u2014 memoria RAM.<br \/>\n\u00e8 assente<\/p>\n<p>Canale di scambio tra nuclei crittografici<br \/>\nassente (manca la parte hardware del nucleo crittografico)<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 bus USB;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 modulo software USB-over-IP;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Rete aziendale dell'organizzazione 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 interfaccia di rete;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 modulo software USB-over-IP.<\/p>\n<p>Canale di scambio dei dati aperti<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 dispositivi di input-output;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 dispositivi di input-output;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Rete aziendale dell'organizzazione 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale: <br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Canale di scambio dei dati protetti<br \/>\nInternet.<\/p>\n<p>Rete aziendale dell'organizzazione 1.<\/p>\n<p>Posto di lavoro dell'utente:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Internet.<\/p>\n<p>Rete aziendale dell'organizzazione 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale: <br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Canale di trasmissione temporale<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 dispositivi di input-output;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Internet. <br \/>\nRete aziendale dell'organizzazione 2,<\/p>\n<p>Hypervisor:<br \/>\n \u2014 interfaccia di rete;<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Canale di trasmissione dei comandi di controllo<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 dispositivi di input-output;<br \/>\n \u2014 memoria RAM.<\/p>\n<p>(Interfaccia utente grafica del software CryptoARM)<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>(Script di automazione)<\/p>\n<p>Canale di ricezione dei risultati<br \/>\nPosto di lavoro dell'utente:<br \/>\n \u2014 dispositivi di input-output;<br \/>\n \u2014 memoria RAM.<\/p>\n<p>(Interfaccia utente grafica del software CryptoARM)<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria RAM;<br \/>\n \u2014 disco rigido.<\/p>\n<p>(File di log del lavoro degli script di automazione)<\/p>\n<p><\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Chiarimenti<\/b><\/p>\n<p>Presupposti adottati durante la decomposizione delle minacce:<\/p>\n<ol>\n<li>Vengono utilizzati algoritmi crittografici robusti.<\/li>\n<li>Gli algoritmi crittografici vengono utilizzati in modo sicuro nelle corrette modalit\u00e0 di funzionamento (ad esempio, <noindex><a rel=\"nofollow\" href=\"http:\/\/cryptowiki.net\/index.php?title=Electronic_Code_Book\">ECB<\/a><\/noindex> non \u00e8 applicabile per la crittografia di grandi volumi di dati, si tiene conto del carico ammissibile sulla chiave, ecc.).<\/li>\n<li>Gli aggressori conoscono tutti gli algoritmi, i protocolli e le chiavi pubbliche utilizzati.<\/li>\n<li>Tutti i dati crittografati sono leggibili dagli aggressori.<\/li>\n<li>Gli aggressori possono riprodurre qualsiasi elemento software nel sistema.<\/li>\n<\/ol>\n<p>\n<b>Decomposizione<\/b><\/p>\n<p>U1. Compromissione delle chiavi crittografiche segrete.<br \/>\nU2. Crittografia di dati falsi a nome di un mittente legittimo.<br \/>\nU3. Decifratura dei dati crittografati da parte di persone che non sono legittimi destinatari dei dati (aggressori).<br \/>\nU4. Creazione di una firma elettronica da parte di un firmatario legittimo su dati falsi.<br \/>\nU5. Ottenimento di un risultato positivo nel controllo della firma elettronica su dati falsi.<br \/>\nU6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso documentale elettronico.<br \/>\nU7. Consultazione non autorizzata di dati protetti durante il loro trattamento da parte della SCZI.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU1\"><\/a><\/noindex><\/p>\n<h3>U1. Compromissione delle chiavi crittografiche segrete<\/h3>\n<p>\nU1.1. Ottenimento della chiave segreta dal deposito delle chiavi segrete.<\/p>\n<p>U1.2. Ottenimento della chiave segreta da oggetti nell'ambiente di funzionamento del mezzo crittografico, in cui pu\u00f2 trovarsi temporaneamente.<br \/>\n<i>Chiarimenti U1.2.<\/i><\/p>\n<p>Gli oggetti in cui pu\u00f2 temporaneamente risiedere la chiave segreta includeranno:<\/p>\n<ol>\n<li>memoria operativa, <\/li>\n<li>file temporanei, <\/li>\n<li>file di paging, <\/li>\n<li>file di ibernazione, <\/li>\n<li>file degli snapshot dello stato 'caldo' delle macchine virtuali, inclusi i file del contenuto della memoria operativa delle macchine virtuali messe in pausa.<\/li>\n<\/ol>\n<p>\nU1.2.1. Estrazione di chiavi segrete dalla memoria operativa in funzione mediante il congelamento dei moduli RAM, la loro estrazione e successiva lettura dei dati (freeze attack).<br \/>\n<i>Chiarimenti U1.2.1.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.securitylab.ru\/analytics\/452899.php\">attacchi<\/a><\/noindex>. <\/p>\n<p>U1.3. Ottenimento della chiave segreta da un canale di scambio di chiavi segrete.<br \/>\n<i>Chiarimenti U1.3.<\/i><br \/>\nUn esempio di attuazione di questa minaccia sar\u00e0 fornito <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA3\">di seguito<\/a><\/noindex>.<\/p>\n<p>U1.4. Modifica non autorizzata del nucleo crittografico, a seguito della quale le chiavi segrete diventano note agli aggressori.<\/p>\n<p>U1.5. Compromissione della chiave segreta a causa dell'uso di canali tecnici di fuga di informazioni (TKUI).<br \/>\n<i>Chiarimenti U1.5.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.usenix.org\/system\/files\/conference\/usenixsecurity18\/sec18-alam.pdf\">attacchi<\/a><\/noindex>. <\/p>\n<p>U1.6. Compromissione della chiave segreta a causa dell'uso di strumenti tecnici speciali (STS) destinati per la raccolta clandestina di informazioni (\"microfoni\").<\/p>\n<p>U1.7. Compromissione delle chiavi segrete durante la loro conservazione al di fuori del SKZI.<br \/>\n<i>Chiarimenti U1.7.<\/i><br \/>\nAd esempio, l'utente conserva i propri supporti chiave in un cassetto della scrivania, da cui possono essere facilmente estratti dai malintenzionati.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU2\"><\/a><\/noindex><\/p>\n<h3>U2. Crittografia di dati falsi a nome del mittente legittimo.<\/h3>\n<p>\n<b>Chiarimenti<\/b><br \/>\nQuesta minaccia \u00e8 considerata solo per schemi di crittografia dei dati con autenticazione del mittente. Esempi di tali schemi sono indicati nelle raccomandazioni di standardizzazione. <noindex><a rel=\"nofollow\" href=\"https:\/\/tc26.ru\/standarts\/rekomendatsii-po-standartizatsii\/r-1323565-1-004-2017-informatsionnaya-tekhnologiya-kriptograficheskaya-zashchita-informatsii-skhemy-vyrabotki-obshchego-klyucha-s-autentifikatsiey-na-osnove-otkrytogo-klyucha.html\">R 1323565.1.004-2017 \"Tecnologia dell'informazione. Protezione crittografica delle informazioni. Schemi di generazione della chiave comune con autenticazione basata su chiave pubblica\".<\/a><\/noindex>. Per gli altri schemi crittografici, questa minaccia non esiste, poich\u00e9 la crittografia \u00e8 effettuata sulle chiavi pubbliche del destinatario, che in generale sono note ai malintenzionati.<\/p>\n<p><b>Decomposizione<\/b><br \/>\nU2.1. Compromissione della chiave segreta del mittente:<br \/>\nU2.1.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u00abModello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche segrete\u00bb<\/a><\/noindex>.<\/p>\n<p>U2.2. Sostituzione dei dati di ingresso nel canale di scambio di dati aperti.<br \/>\n<i>Note U2.2.<\/i><br \/>\nEsempi di implementazione di questa minaccia sono forniti di seguito. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA1\">qui<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA2\">qui<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU3\"><\/a><\/noindex><\/p>\n<h3>U3. Decrittazione dei dati crittografati da parte di soggetti che non sono destinatari legittimi dei dati (malintenzionati).<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU3.1. Compromissione delle chiavi segrete del destinatario dei dati crittografati. <br \/>\nU3.1.1 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u00abModello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche segrete\u00bb<\/a><\/noindex>.<\/p>\n<p>U3.2. Sostituzione dei dati criptati nel canale di scambio di dati protetti.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU4\"><\/a><\/noindex><\/p>\n<h3>U4. Creazione di una firma elettronica da parte di un firmatario legittimo su dati falsi.<br \/>\n<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU4.1. Compromissione delle chiavi segrete della firma elettronica del firmatario legittimo. <br \/>\nU4.1.1 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u00abModello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche segrete\u00bb<\/a><\/noindex>.<\/p>\n<p>U4.2. Sostituzione dei dati firmati nel canale di scambio di dati aperti.<br \/>\n<i>Nota U4.2.<\/i><br \/>\nEsempi di implementazione di questa minaccia sono forniti di seguito. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA1\">qui<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA2\">qui<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU5\"><\/a><\/noindex><\/p>\n<h3>U5. Ottenimento di un risultato positivo nella verifica della firma elettronica sui dati falsi.<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU5.1. Gli attaccanti intercettano nel canale di trasmissione dei risultati di lavoro un messaggio riguardante un esito negativo della verifica della firma elettronica e lo sostituiscono con un messaggio con esito positivo.<\/p>\n<p>U5.2. Gli attaccanti attuano un attacco alla fiducia nei certificati di firma (<b>SCENARIO \u2014 tutti gli elementi sono obbligatori<\/b>):<br \/>\nU5.2.1. Gli attaccanti generano una chiave pubblica e una chiave privata per la firma elettronica. Se nel sistema vengono utilizzati certificati per le chiavi di firma elettronica, generano un certificato di firma elettronica il pi\u00f9 simile possibile al certificato del presunto mittente dei dati il cui messaggio intendono falsificare.<br \/>\nU5.2.2. Gli attaccanti apportano modifiche non autorizzate al repository delle chiavi pubbliche, attribuendo alla chiave pubblica che hanno generato il livello necessario di fiducia e autorizzazioni.<br \/>\nU5.2.3. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica precedentemente creata e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.3. Gli attaccanti attuano un attacco utilizzando chiavi di firma elettronica scadute di un firmatario legittimo (<b>SCENARIO \u2014 tutti gli elementi sono obbligatori<\/b>):<br \/>\nU5.3.1. Gli attaccanti compromettono le chiavi private elettroniche scadute (non pi\u00f9 valide al momento) del mittente legittimo.<br \/>\nU5.3.2. Gli attaccanti sostituiscono il tempo nel canale di trasmissione con un'ora in cui le chiavi compromesse erano ancora valide.<br \/>\nU5.3.3. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.4. Gli attaccanti attuano un attacco utilizzando chiavi di firma elettronica compromesse di un firmatario legittimo (<b>SCENARIO \u2014 tutti gli elementi sono obbligatori<\/b>):<br \/>\nU5.4.1. Gli attaccanti fanno una copia del repository delle chiavi pubbliche.<br \/>\nU5.4.2. Gli attaccanti compromettono le chiavi private di uno dei mittenti legittimi. Costui nota la compromissione, revoca le chiavi e le informazioni sulla revoca sono inserite nel repository delle chiavi pubbliche.<br \/>\nU5.4.3. Gli attaccanti sostituiscono il repository delle chiavi pubbliche con quello precedentemente copiato.<br \/>\nU5.4.4. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.5. &lt;&hellip;&gt; a causa della presenza di errori nell'implementazione della 2\u00aa e 3\u00aa fase della verifica della firma elettronica:<br \/>\n<i>Chiarimenti U5.5.<\/i><br \/>\nUn esempio di implementazione di questa minaccia \u00e8 fornito <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA4\">di seguito<\/a><\/noindex>.<\/p>\n<p>U5.5.1. Verifica della fiducia nel certificato della chiave di firma elettronica solo sulla base della fiducia nel certificato con cui \u00e8 stato firmato, senza verifiche CRL o OCSP.<br \/>\n<i>Chiarimenti U5.5.1.<\/i><br \/>\nEsempio di implementazione <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/332730\/\">minacce<\/a><\/noindex>. <\/p>\n<p>U5.5.2. Nella costruzione della catena di fiducia per il certificato non vengono analizzate le autorizzazioni dei certificati emittenti.<br \/>\n<i>Chiarimenti U5.5.2.<\/i><br \/>\nEsempio di attacco riguardante i certificati SSL\/TLS. <br \/>\nI malintenzionati hanno acquistato un certificato legittimo per la propria e-mail. Poi hanno creato un certificato fraudolento per un sito e lo hanno firmato con il proprio certificato. Se non viene condotta alcuna verifica delle autorizzazioni, la catena di fiducia risulter\u00e0 corretta, e di conseguenza il certificato fraudolento sar\u00e0 considerato valido.<\/p>\n<p>U5.5.3. Nella costruzione della catena di fiducia per il certificato non vengono verificate le revoche dei certificati intermedi.<\/p>\n<p>U5.5.4. L'aggiornamento della CRL avviene meno frequentemente rispetto a quanto viene rilasciato dall'ente certificatore.<\/p>\n<p>U5.5.5. La decisione di fiducia nella firma elettronica viene presa prima di ricevere la risposta OCSP sullo stato del certificato, inviata in seguito a una richiesta effettuata dopo il momento di formazione della firma o prima di ricevere la successiva CRL dopo la formazione della firma. <br \/>\n<i>Chiarimenti U5.5.5.<\/i><br \/>\nNei regolamenti della maggior parte degli enti certificatori, il momento della revoca del certificato \u00e8 considerato il momento di rilascio della CRL pi\u00f9 vicina contenente informazioni sulla revoca del certificato.<\/p>\n<p>U5.5.6. Al ricevimento di dati firmati non viene verificata l'appartenenza del certificato al mittente. <br \/>\n<i>Chiarimenti U5.5.6.<\/i><br \/>\nEsempio di attacco. In relazione ai certificati SSL: potrebbe non essere verificata la corrispondenza dell'indirizzo del server chiamato con il valore del campo CN nel certificato.<br \/>\nEsempio di attacco. I malintenzionati hanno compromesso le chiavi di firma elettronica di uno dei partecipanti al sistema di pagamento. Successivamente, hanno violato la rete di un altro partecipante e, a suo nome, hanno inviato al server di calcolo del sistema di pagamento documenti di pagamento firmati con chiavi compromesse. Se il server analizza solo la fiducia e non verifica la corrispondenza, i documenti fraudolenti saranno considerati legittimi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU6\"><\/a><\/noindex><\/p>\n<h3>U6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso documentale elettronico.<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU6.1. La parte ricevente non rileva la duplicazione dei documenti ricevuti.<br \/>\n<i>Chiarimenti U6.1.<\/i><br \/>\nEsempio di attacco. I malintenzionati possono intercettare un documento inviato al destinatario, anche se crittograficamente protetto, e poi inoltrarlo ripetutamente attraverso il canale di trasmissione dei dati protetti. Se il destinatario non identifica i duplicati, tutti i documenti ricevuti saranno considerati e trattati come documenti diversi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU7\"><\/a><\/noindex><\/p>\n<h3>U7. Accesso non autorizzato ai dati protetti durante la loro elaborazione con SKZI <\/h3>\n<p>\n<b>Decomposizione<\/b><\/p>\n<p>U7.1. &lt;&hellip;&gt; a seguito di una fuga di informazioni attraverso canali esterni (attacco side channel).<br \/>\n<i>Chiarimenti U7.1.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cs.tau.ac.il\/~tromer\/synesthesia\/synesthesia.pdf\">attacchi<\/a><\/noindex>. <\/p>\n<p>U7.2. &lt;&hellip;&gt; a causa della neutralizzazione della protezione contro accessi non autorizzati alle informazioni elaborate sulla SKZI:<br \/>\nU7.2.1. Utilizzo di SKZI in violazione dei requisiti descritti nella documentazione relativa a SKZI.<\/p>\n<p>U7.2.2. &lt;&hellip;&gt;, effettuata a causa della presenza di vulnerabilit\u00e0 in:<br \/>\nU7.2.2.1. &lt;&hellip;&gt; strumenti di protezione contro accessi non autorizzati.<br \/>\nU7.2.2.2. &lt;&hellip;&gt; la stessa SKZI.<br \/>\nU7.2.2.3. &lt;&hellip;&gt; ambiente operativo del mezzo crittografico.<\/p>\n<h3>Esempi di attacchi<\/h3>\n<p>\nGli scenari discussi di seguito contengono volutamente errori nell'organizzazione della sicurezza delle informazioni e servono solo come illustrazione di possibili attacchi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA1\"><\/a><\/noindex><\/p>\n<h4>Scenario 1. Esempio di implementazione delle minacce U2.2 e U4.2.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/77d51167720552df4eb9c2bafbce6765.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl software APM KBR e SKZI SKAD firma sono installati su un computer fisico non connesso alla rete di calcolo. Il supporto chiave utilizzato \u00e8 il FKN vdToken in modalit\u00e0 di lavoro con una chiave non estraibile.<\/p>\n<p>Il regolamento per l'esecuzione delle transazioni prevede che il specialista dei calcoli scarichi i messaggi elettronici in chiaro (schema del vecchio APM KBR) da un server di file protetto speciale, poi li memorizzi su un supporto rimovibile USB e li trasferisca su APM KBR, dove vengono crittografati e firmati. Dopo di ci\u00f2, il specialista trasferisce i messaggi elettronici protetti su un supporto rimovibile, e poi tramite il proprio computer di lavoro li carica sul server di file, da dove vengono inviati all'UTA e oltre nel sistema di pagamento della Banca di Russia.<\/p>\n<p>In questo caso, i canali di scambio di dati aperti e protetti includeranno: server di file, computer di lavoro del specialista e supporto rimovibile.<\/p>\n<p><b>L'attacco<\/b><br \/>\nI malintenzionati installano senza autorizzazione un sistema di gestione remota sul computer di lavoro dello specialista e nel momento in cui registra su un dispositivo di memorizzazione trasferito gli ordini di pagamento (messaggi elettronici) in chiaro, sostituiscono il contenuto di uno di essi. Lo specialista trasferisce gli ordini di pagamento su A\u0420\u041c \u041a\u0411\u0420, li firma e li crittografa, senza accorgersi della sostituzione (ad esempio, a causa del gran numero di ordini di pagamento in transito, della stanchezza, ecc.). Successivamente, l'ordine di pagamento contraffatto, passando attraverso la catena tecnologica, arriva al sistema di pagamento della Banca di Russia.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA2\"><\/a><\/noindex><\/p>\n<h4>Scenario 2. Esempio di attuazione delle minacce \u04232.2 e \u04234.2.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/b4489290d665b359323ec6b58dde1139.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn computer con A\u0420\u041c \u041a\u0411\u0420, \u0421\u041a\u0410\u0414 \u0421\u0438\u0433\u043d\u0430\u0442\u0443\u0440\u0430 e un dispositivo di chiave F\u041a\u041d vdToken collegato funziona in uno spazio riservato senza accesso da parte del personale.<br \/>\nLo specialista contabile si connette a A\u0420\u041c \u041a\u0411\u0420 in modalit\u00e0 di accesso remoto tramite il protocollo RDP.<\/p>\n<p><b>L'attacco<\/b><br \/>\nI malintenzionati intercettano le credenziali, utilizzate dalle quali lo specialista contabile effettua la connessione e lavora con A\u0420\u041c \u041a\u0411\u0420 (ad esempio, a causa di codice malevolo sul suo computer). Poi si connettono a nome suo e inviano un ordine di pagamento contraffatto nel sistema di pagamento della Banca di Russia.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA3\"><\/a><\/noindex><\/p>\n<h4>Scenario 3. Esempio di attuazione della minaccia \u04231.3. <\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli di minaccia standard\" src=\"\/wp-content\/uploads\/2019\/04\/988a97dd75247780556d388566d771f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsaminiamo uno dei possibili metodi di attuazione dei moduli di integrazione \"\u0410\u0411\u0421-\u041a\u0411\u0420\" per un nuovo schema (A\u0420\u041c \u041a\u0411\u0420-\u041d), dove la firma elettronica dei documenti in uscita avviene lato A\u0411\u0421. Consideriamo che A\u0411\u0421 funzioni su un sistema operativo non supportato da \u0421\u041a\u0417\u0418 \u0421\u041a\u0410\u0414 \u0421\u0438\u0433\u043d\u0430\u0442\u0443\u0440\u0430 e, pertanto, la funzionalit\u00e0 crittografica \u00e8 stata spostata su una macchina virtuale separata: modulo di integrazione \"\u0410\u0411\u0421-\u041a\u0411\u0420\".<br \/>\nCome dispositivo di chiave viene utilizzato un comune token USB, funzionante in modalit\u00e0 chiave estraibile. Quando il dispositivo di chiave \u00e8 stato collegato all'iperconcentratore, si \u00e8 scoperto che nel sistema non c'erano porte USB disponibili, quindi \u00e8 stato deciso di collegare il token USB tramite un concentratore USB di rete e installare un client USB-over-IP sulla macchina virtuale, che realizzer\u00e0 la connessione con il concentratore.<\/p>\n<p><b>L'attacco<\/b><br \/>\nI malintenzionati hanno intercettato la chiave privata della firma elettronica tramite il canale di comunicazione tra l'hub USB e l'ipercomprensore (i dati erano trasmessi in chiaro). Possedendo la chiave privata, i malintenzionati hanno generato un falso ordine di pagamento, lo hanno firmato digitalmente e lo hanno inviato all'ARM KBR-N per l'esecuzione.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA4\"><\/a><\/noindex><\/p>\n<h4>Scenario 4. Esempio di implementazione delle minacce U5.5.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\nConsideriamo lo stesso schema di quello precedente. Supponiamo che i messaggi elettronici provenienti dal workstation KBR-N finiscano nella cartella &hellip;SHAREIn, mentre quelli inviati al workstation KBR-N e poi al sistema di pagamento della Banca di Russia vadano in &hellip;SHAREout.<br \/>\nSupponiamo anche che, nell'implementazione del modulo di integrazione, le liste dei certificati revocati vengano aggiornate solo in caso di riemissione delle chiavi crittografiche, e che i messaggi elettronici ricevuti nella cartella &hellip;SHAREIn vengano verificati solo per il controllo dell'integrit\u00e0 e per il controllo della fiducia nella chiave pubblica della firma elettronica.<\/p>\n<p><b>L'attacco<\/b><\/p>\n<p>I malintenzionati, avvalendosi delle chiavi rubate nel precedente scenario, hanno firmato un falso ordine di pagamento contenente informazioni sul trasferimento di denaro sul conto di un cliente truffatore e lo hanno inserito nel canale di scambio di dati protetti. Poich\u00e9 non viene effettuato alcun controllo per verificare che l'ordine di pagamento sia firmato proprio dalla Banca di Russia, esso viene accettato per l'esecuzione.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/422329\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e \u0447\u0435\u043c \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0435 \u0421\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0434\u0440\u0443\u0433\u0438\u0435 \u0447\u0430\u0441\u0442\u0438 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 1 \u2014 \u042d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u043e\u0441\u043d\u043e\u0432\u044b. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 \u2014 \u0422\u0438\u043f\u043e\u0432\u0430\u044f IT-\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u043d\u043a\u0430. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 3 \u2014 \u0424\u043e\u0440\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u043a \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u0437\u0430\u0449\u0438\u0442\u044b. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 4 \u2014 \u041e\u0431\u0437\u043e\u0440 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043e\u0432 \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0443\u0433\u0440\u043e\u0437. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31627","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 8 \u2014 \u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043c\u043e\u0434\u0435\u043b\u0438 \u0443\u0433\u0440\u043e\u0437 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:42:14+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:42:14+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sicurezza delle informazioni nei pagamenti elettronici bancari. Parte 8 \u2014 Modelli standard di minacce | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 8 \u2014 \u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043c\u043e\u0434\u0435\u043b\u0438 \u0443\u0433\u0440\u043e\u0437 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:42:14+00:00","article:modified_time":"2019-10-31T18:42:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31627","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 07:04:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:13:29","updated":"2026-01-21 07:04:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31627","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31627"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31627\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}