{"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 dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia","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 dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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 lo studio<\/a><\/noindex><\/p>\n<p><b class=\"spoiler_title\">Collegamenti ad altre parti dello studio<\/b><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/344740\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 1 - Fondamenti economici.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/345194\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 2 - Infrastruttura IT tipica della banca.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 3 - 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 nei pagamenti bancari elettronici. Parte 4 - Panoramica degli standard di modellazione delle minacce.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 5 - 100+ link tematici su attacchi bancari.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 6 - Analisi dei crimini bancari.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Sicurezza informatica nei pagamenti bancari elettronici. Parte 7 - Modello base delle minacce.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\">Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia <\/a><\/noindex>(<b>Sei qui<\/b>)<\/li>\n<\/ul>\n<p>Questo articolo conclude un ciclo di pubblicazioni dedicate alla sicurezza informatica nei pagamenti bancari elettronici. Qui esploreremo i modelli di minacce tipici 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 di minacce tipico. Collegamento di rete<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUIS\">Modello di minacce tipico. Sistema informatico basato sull'architettura client-server<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRD\">Modello di minacce tipico. Sistema di controllo degli accessi<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUMI\">Modello di minacce tipico. Modulo di integrazione<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZI\">Modello di minacce tipico. Sistema di protezione crittografica delle informazioni.<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><b>HA\u0411\u0420\u041e-WARNING !!!<\/b> Cari hucraftiani, questo non \u00e8 un post di intrattenimento. <br \/>\nNascondendo sotto il tag 40+ pagine di materiali mirati a <b>aiutare nel lavoro o nello studio<\/b> persone specializzate in finanza o sicurezza informatica. Questi materiali sono il prodotto finale di una ricerca e sono scritti in uno stile ufficiale e asciutto. In effetti, sono preparati per documenti interni sulla sicurezza informatica. <\/p>\n<p>E la tradizionale \u2014 <b>\u00abl'uso delle informazioni contenute in questo articolo per fini illegali \u00e8 perseguibile 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 allo studio partendo da questa pubblicazione.<br \/>\n<noindex><a rel=\"nofollow\" name=\"ABOUT\"><\/a><\/noindex><\/p>\n<blockquote>\n<h2>Di cosa tratta lo studio<\/h2>\n<p>\nStai leggendo una guida per il professionista responsabile della sicurezza informatica nei pagamenti all'interno di una banca. <\/p>\n<p><b>Logica di presentazione<\/b><\/p>\n<p>Inizialmente, viene fornita una descrizione dell'oggetto di protezione. Successivamente, nella <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> parte 3 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">si discute come costruire un sistema di protezione e l'importanza di sviluppare un modello di minacce. Nella<\/a><\/noindex> parte 4 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/351326\/\">si tratta di quali modelli di minacce esistono e come vengono formulati. Nella<\/a><\/noindex> parte 5 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">e nella<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">parte 6<\/a><\/noindex> \u00e8 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> contiene una descrizione del modello di minacce elaborato tenendo conto delle informazioni presentate in tutte le parti precedenti.<\/p><\/blockquote>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUNC\"><\/a><\/noindex><\/p>\n<h2>MODELLO TIPO DI MINACCIA. COLLEGAMENTO DI RETE<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione al quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto di protezione \u00e8 costituito dai dati trasmessi attraverso un collegamento di rete che opera 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 dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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>\u00abNode finali\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 cui passa il traffico del collegamento di rete. In generale, un collegamento di rete pu\u00f2 funzionare senza nodi intermedi (direttamente tra nodi finali).<\/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 su nodi finali o intermediari:<br \/>\nU1.1.1.  mediante la lettura dei dati mentre sono presenti 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 l'elaborazione dei dati nel 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 l'archiviazione dei dati trasmessi nella cache, file temporanei o file di swap.<\/p>\n<p>U1.2. , effettuato su nodi esterni nella rete di trasmissione dati:<br \/>\nU1.2.1.  mediante la cattura di tutti i pacchetti che arrivano all'interfaccia di rete del nodo:<br \/>\n<i>Chiarimenti su U1.2.1.<\/i><br \/>\nLa cattura di tutti i pacchetti avviene portando la scheda di rete in modalit\u00e0 promiscuous (promiscuous mode per adattatori cablati o in modalit\u00e0 monitor per adattatori wi-fi).<\/p>\n<p>U1.2.2.  attraverso attacchi di tipo \"uomo in mezzo (MiTM)\", senza modifica dei dati trasmessi (esclusi i dati di protocollo di rete).<br \/>\nU1.2.2.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard delle minacce. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.3. , effettuato attraverso la fuga di informazioni tramite canali tecnici (TKUIs) da nodi fisici o linee di comunicazione.<\/p>\n<p>U1.4. , effettuato mediante l'installazione su nodi finali o intermediari di dispositivi tecnici speciali (STS) progettati per la 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. , effettuato su nodi finali o intermediari:<br \/>\nU2.1.1.  mediante la lettura e la modifica dei dati mentre sono presenti 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. , effettuato su nodi esterni nella rete di trasmissione dati:<br \/>\nU2.2.1.  mediante attacchi di tipo \"uomo in mezzo (MiTM)\" e la reindirizzamento del traffico verso il nodo degli aggressori:<br \/>\nU2.2.1.1. Collegamento fisico dell'attrezzatura malevola nell'interruzione della connessione di rete.<br \/>\nU2.2.1.2. Esecuzione di attacchi sui 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 percorsi falsi da parte di malintenzionati tramite 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. Apportare modifiche non autorizzate ai file locali dei nomi host (hosts, lmhosts, ecc.)<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU3\"><\/a><\/noindex><\/p>\n<h3>U3. Violazione del copyright dei dati trasmessi<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU3.1. Neutralizzazione dei meccanismi di determinazione dell'autore delle informazioni mediante indicazione di dati falsi sull'autore o sulla fonte delle informazioni:<br \/>\nU3.1.1. Modifica dei dati sull'autore contenuti nelle informazioni trasmesse.<br \/>\nU3.1.1.1. Neutralizzazione della protezione crittografica dell'integrit\u00e0 e dell'autore dei dati trasmessi:<br \/>\nU3.1.1.1.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU4\">\u00abModello standard delle minacce. Sistema di protezione crittografica delle informazioni.<br \/>\nU4. Creazione di una firma elettronica da parte di un sottoscrittore legittimo su dati falsi\u00bb<\/a><\/noindex>.<br \/>\nU3.1.1.2. Neutralizzazione della protezione del copyright delle informazioni trasmesse, realizzata tramite codici di conferma usa e getta:<br \/>\nU3.1.1.2.1. <noindex>SIM swap<\/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\">IP spoofing<\/a><\/noindex>.<br \/>\nU3.1.2.2. <noindex><a rel=\"nofollow\" href=\"http:\/\/xgu.ru\/wiki\/MAC-spoofing\">MAC spoofing<\/a><\/noindex>.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUIS\"><\/a><\/noindex><\/p>\n<h2>MODELLO STANDARD DELLE MINACCE. SISTEMA INFORMATIVO BASATO SULL'ARCHITETTURA CLIENT-SERVER<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione al quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto della protezione \u00e8 un sistema informativo basato sull'architettura client-server.<\/p>\n<p><b>Architettura<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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>\u00abClient\u00bb<\/i> \u2013 dispositivo su cui funziona la parte client del sistema informativo.<\/li>\n<li><i>\u00abServer\u00bb<\/i> \u2013 dispositivo su cui funziona la parte server del sistema informativo.<\/li>\n<li><i>\u00abStorage 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 delle informazioni tra il Client 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 standard delle minacce. Connessione di rete\u00bb<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\n<b>Limitazioni<\/b><br \/>\nDurante la modellazione dell'oggetto sono state stabilite le seguenti limitazioni:<\/p>\n<ol>\n<li>L'utente interagisce con il sistema informativo nell'ambito di intervalli temporali limitati, chiamati sessioni di lavoro.<\/li>\n<li>All'inizio di ogni sessione di lavoro, avvengono identificazione, autenticazione e 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. Comportamenti non autorizzati eseguiti dai 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. Comportamenti non autorizzati eseguiti dai malintenzionati a nome di un utente legittimo<\/h3>\n<p>\n<b>Spiegazioni<\/b><br \/>\nDi solito nei sistemi informativi, le azioni sono correlate all'utente che le ha eseguite tramite:<\/p>\n<ol>\n<li>registrazioni di lavoro del sistema (logs). <\/li>\n<li>specifici attributi degli oggetti dati che contengono informazioni sull'utente che le ha create o modificate.<\/li>\n<\/ol>\n<p>\nIn relazione alla sessione di lavoro, questa minaccia pu\u00f2 essere scomposta in:<\/p>\n<ol>\n<li>eseguiti nell'ambito della sessione dell'utente.<\/li>\n<li>eseguiti al di fuori della sessione dell'utente.<\/li>\n<\/ol>\n<p>\nLa sessione di lavoro dell'utente pu\u00f2 essere avviata:<\/p>\n<ol>\n<li>Dallo stesso utente.<\/li>\n<li>Da malintenzionati.<\/li>\n<\/ol>\n<p>\nA questo punto, la decomposizione intermedia di questa minaccia apparir\u00e0 come segue:<br \/>\nU1.1. Azioni non autorizzate eseguite all'interno di una 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 che i malintenzionati possono colpire, 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 all'interno di una sessione di lavoro dell'utente:<br \/>\nU1.1.1. , installato dall'utente attaccato:<br \/>\nU1.1.1.1. I malintenzionati hanno agito autonomamente dal Client:<br \/>\nU1.1.1.1.1 I malintenzionati hanno utilizzato mezzi normali per accedere al sistema informatico:<br \/>\nU1.1.1.1.1.1. I malintenzionati hanno utilizzato mezzi di input\/output fisici del Client (tastiera, mouse, monitor o touchscreen di un dispositivo mobile):<br \/>\nU1.1.1.1.1.1.1. I malintenzionati hanno agito nei periodi 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 (normali o forniti da codice malevolo) per controllare il Client:<br \/>\nU1.1.1.1.1.2.1. I malintenzionati hanno agito nei periodi 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 usato strumenti di amministrazione remota che operano in modo invisibile per l'utente attaccato.<br \/>\nU1.1.1.2. I malintenzionati hanno alterato i dati nella connessione di rete tra il Client e il Server, modificandoli in modo che apparissero 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 delle minacce. 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 compiere le azioni da loro indicate, utilizzando metodi di ingegneria sociale.<\/p>\n<p>U1.1.2  installato dagli aggressori:<br \/>\nU1.1.2.1. I malintenzionati hanno agito dal Client (<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 delle minacce. Sistema di controllo degli accessi. U1. Creazione di sessioni di lavoro non autorizzate a nome di un utente legittimo\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.1.2. I malintenzionati hanno utilizzato mezzi normali per accedere al sistema informatico<br \/>\nU1.1.2.2. I malintenzionati hanno agito da altri nodi della rete di trasmissione dei dati, da cui \u00e8 possibile stabilire una connessione di rete con il Server (<b>E<\/b>):<br \/>\nU1.1.2.2.1. I malintenzionati hanno neutralizzato il sistema di controllo degli accessi del sistema informatico:<br \/>\nU1.1.2.2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abModello standard delle minacce. Sistema di controllo degli accessi. U1. Creazione di sessioni di lavoro non autorizzate a nome di un utente legittimo\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.2.2. I malintenzionati hanno usato mezzi non autorizzati per accedere al sistema informatico.<br \/>\n<i>Spiegazioni U1.1.2.2.2.<\/i><br \/>\nI malintenzionati potrebbero aver installato un client standard del sistema informatico su un nodo esterno o potrebbero aver utilizzato software non autorizzato che implementa protocolli normali di scambio tra il Client e il Server.<\/p>\n<p>U1.2 Azioni non autorizzate eseguite al di fuori della sessione di lavoro dell'utente.<br \/>\nU1.2.1 I malintenzionati hanno eseguito azioni non autorizzate e poi hanno apportato modifiche non autorizzate ai registri di lavoro del sistema informatico o a specifici attributi degli oggetti dati, indicando che le loro azioni sono state eseguite da un utente legittimo.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUISU2\"><\/a><\/noindex><\/p>\n<h3>U2. Modifica non autorizzata delle informazioni protette durante il loro trattamento da parte del server del sistema informatico<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU2.1. I malintenzionati modificano informazioni protette utilizzando mezzi normali del sistema informatico e eseguendo ci\u00f2 a nome di un utente legittimo.<br \/>\nU2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU1\">\u00abModello standard delle minacce. Sistema informatico basato sull'architettura client-server. U1. Esecuzione di azioni non autorizzate da parte dei malintenzionati a nome di un utente legittimo\u00bb<\/a><\/noindex>.<\/p>\n<p>U2.2. I malintenzionati modificano informazioni protette usando meccanismi di accesso ai dati non previsti dal funzionamento normale del sistema informatico.<br \/>\nU2.2.1. I malintenzionati modificano file contenenti informazioni protette:<br \/>\nU2.2.1.1. , utilizzando meccanismi per la gestione dei file forniti dal sistema operativo.<br \/>\nU2.2.1.2.  mediante provocazione del ripristino di file da una copia di backup modificata non autorizzata.<\/p>\n<p>U2.2.2. I malintenzionati modificano informazioni protette memorizzate nel database (<b>E<\/b>):<br \/>\nU2.2.2.1. I malintenzionati 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 delle minacce. Sistema di controllo degli accessi. U1. Creazione di sessioni di lavoro non autorizzate a nome di un utente legittimo\u00bb<\/a><\/noindex>.<br \/>\nU2.2.2.2. Gli aggressori modificano le informazioni utilizzando le interfacce standard dei DBMS per accedere ai dati.<\/p>\n<p>U2.3. Gli aggressori modificano le informazioni protette attraverso la modifica non autorizzata degli algoritmi 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 le informazioni protette utilizzando vulnerabilit\u00e0 nel software del sistema informativo.<\/p>\n<p>U2.5. Gli aggressori modificano le informazioni protette durante la trasmissione tra i componenti del server del sistema informativo (ad esempio, tra il server dei database e il server delle applicazioni):<br \/>\nU2.5.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u00abModello standard delle minacce. 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 MINACCIA. SISTEMA DI CONTROLLO DEGLI ACCESSI<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione al quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto di protezione a cui si applica questo modello di minaccia corrisponde all'oggetto di protezione del modello di minaccia: \"Modello tipo di minaccia. Sistema informativo basato su architettura client-server\".<\/p>\n<p>Per sistema di controllo degli accessi degli utenti in questo modello di minaccia si intende il componente del sistema informativo che svolge 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. Elevazione non autorizzata dei privilegi dell'utente nel sistema informativo.<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>Spiegazioni<\/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 verr\u00e0 considerato solo il sistema di identificazione e autenticazione degli utenti che utilizza un login e una password testuali. Si presuppone che il login dell'utente sia un'informazione pubblica, nota agli aggressori.<\/p>\n<p><b>Decomposizione<\/b><br \/>\nU1.1.  a causa della compromissione delle credenziali:<br \/>\nU1.1.1. Gli aggressori hanno compromesso le credenziali dell'utente durante il loro storage.<br \/>\n<i>Spiegazioni U1.1.1.<\/i><br \/>\nAd esempio, le credenziali potrebbero essere state scritte su un post-it attaccato al monitor.<\/p>\n<p>U1.1.2. L'utente ha accidentalmente o intenzionalmente trasferito le credenziali di accesso agli aggressori.<br \/>\nU1.1.2.1. L'utente ha verbalizzato le credenziali ad alta voce durante l'immissione.<br \/>\nU1.1.2.2. L'utente ha deliberatamente trasferito le proprie credenziali:<br \/>\nU1.1.2.2.1.  ai colleghi di lavoro.<br \/>\n<i>Spiegazioni 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 lavorano su progetti riguardanti l'infrastruttura informativa.<br \/>\nU1.1.2.2.3.  a terzi.<br \/>\n<i>Spiegazioni U1.1.2.2.3.<\/i><br \/>\nUno, ma non l'unico, modo di attuare questa minaccia \u00e8 l'uso da parte degli aggressori di metodi di ingegneria sociale.<\/p>\n<p>U1.1.3. Gli aggressori hanno indovinato le credenziali attraverso tentativi sistematici:<br \/>\nU1.1.3.1.  utilizzando meccanismi di accesso standard.<br \/>\nU1.1.3.2.  utilizzando codici precedentemente catturati (ad esempio, hash delle password) per la memorizzazione delle credenziali.<\/p>\n<p>U1.1.4. Gli aggressori hanno utilizzato codice malevolo per intercettare le credenziali dell'utente.<\/p>\n<p>U1.1.5. Gli aggressori 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\">\"Modello tipo di minaccia. Connessione di rete. U1. Accesso non autorizzato ai dati trasmessi\"<\/a><\/noindex>.<\/p>\n<p>U1.1.6. Gli aggressori hanno estratto le credenziali dai log dei sistemi di monitoraggio delle attivit\u00e0:<br \/>\nU1.1.6.1.  sistemi di videosorveglianza (nel caso vengano registrate le pressione dei tasti sulla tastiera durante l'operazione).<br \/>\nU1.1.6.2.  sistemi di monitoraggio delle attivit\u00e0 degli dipendenti al computer. <br \/>\n<i>Spiegazioni U1.1.6.2.<\/i><br \/>\nUn esempio di tale sistema \u00e8: <noindex><a rel=\"nofollow\" href=\"https:\/\/www.staffcop.ru\">StuffCop<\/a><\/noindex>.<\/p>\n<p>U1.1.7. Gli aggressori hanno compromesso le credenziali dell'utente a causa di difetti nel processo di trasmissione.<br \/>\n<i>Spiegazioni U1.1.7.<\/i><br \/>\nAd esempio, la trasmissione di password in chiaro via e-mail.<\/p>\n<p>U1.1.8. Gli aggressori hanno appreso le credenziali osservando la sessione di lavoro dell'utente tramite sistemi di amministrazione remota.<\/p>\n<p>U1.1.9. Gli aggressori hanno estratto le credenziali a seguito della loro fuga tramite canali tecnici (T\u041a\u0423\u0418):<br \/>\nU1.1.9.1. Gli aggressori hanno osservato come l'utente immetteva le credenziali tramite la tastiera:<br \/>\nU1.1.9.1.1 Gli aggressori erano posti in prossimit\u00e0 dell'utente e vedevano l'immissione delle credenziali a occhio nudo. <br \/>\n<i>Spiegazioni U1.1.9.1.1<\/i><br \/>\nSituazioni simili possono includere azioni di colleghi o un caso in cui la tastiera dell'utente \u00e8 visibile ai visitatori dell'organizzazione.<\/p>\n<p>U1.1.9.1.2 Gli aggressori hanno utilizzato mezzi tecnici aggiuntivi, come binocoli o droni, per osservare l'inserimento delle credenziali attraverso una finestra. <br \/>\nU1.1.9.2. Gli aggressori hanno estratto le credenziali dalle registrazioni delle comunicazioni tra la tastiera e l'unit\u00e0 centrale del computer se connesse tramite interfaccia radio (ad esempio, Bluetooth).<br \/>\nU1.1.9.3. Gli aggressori hanno intercettato le credenziali grazie alla loro fuga attraverso il canale delle emissioni elettromagnetiche indesiderate e delle influenze (PEMI).<br \/>\n<i>Spiegazioni 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 delle credenziali dalla tastiera utilizzando mezzi tecnici speciali (STS) progettati per la raccolta clandestina delle informazioni.<br \/>\n<i>Spiegazioni U1.1.9.4.<\/i><br \/>\nEsempi <noindex>dispositivi<\/noindex>. <\/p>\n<p>U1.1.9.5. Gli aggressori hanno intercettato l'immissione delle credenziali dalla tastiera attraverso l'analisi del segnale Wi-Fi modulato dal processo di pressione dei tasti da parte dell'utente. <br \/>\nSpiegazioni U1.1.9.5.<br \/>\n<i>U1.1.9.6. Gli aggressori hanno intercettato l'immissione delle credenziali dalla tastiera tramite l'analisi dei suoni generati dalle pressione dei tasti.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/threatpost.com\/keystroke-recognition-uses-wi-fi-signals-to-snoop\/120135\/\">di attacco<\/a><\/noindex>.<\/p>\n<p>Spiegazioni U1.1.9.6.<br \/>\n<i>U1.1.9.7. Gli aggressori hanno intercettato l'immissione delle credenziali dalla tastiera di un dispositivo mobile grazie all'analisi delle letture dell'accelerometro.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/398545\/\">di attacco<\/a><\/noindex>.<\/p>\n<p>Spiegazioni U1.1.9.7.<br \/>\n<i>U1.1.10. , precedentemente salvati sul Cliente.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/126806\/\">di attacco<\/a><\/noindex>.<\/p>\n<p>U1.1.10. , precedentemente salvati sul Cliente.<br \/>\n<i>Ad esempio, un utente potrebbe aver salvato nel browser il login e la password per accedere a un determinato sito.<\/i><br \/>\nU1.1.11. Gli aggressori hanno compromesso le credenziali a causa di difetti nel processo di revoca degli accessi degli utenti.<\/p>\n<p>Spiegazioni U1.1.11.<br \/>\n<i>Ad esempio, dopo il licenziamento di un utente, i suoi account sono rimasti attivi.<\/i><br \/>\nU1.2.  grazie all'uso di vulnerabilit\u00e0 nel sistema di controllo degli accessi.<\/p>\n<p>U1.2.  a causa dell'utilizzo di vulnerabilit\u00e0 nel sistema di controllo degli accessi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSRDU2\"><\/a><\/noindex> <\/p>\n<h3>U2.1  mediante l'introduzione di modifiche non autorizzate ai dati contenenti informazioni sui privilegi dell'utente.<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU2.1  mediante modifiche non autorizzate ai dati contenenti informazioni sui privilegi dell'utente.<\/p>\n<p>U2.2  a causa dell'utilizzo di vulnerabilit\u00e0 nel sistema di controllo degli accessi.<\/p>\n<p>U2.3.  a causa di carenze nel processo di gestione degli accessi degli utenti.<br \/>\n<i>Esempio 1. All'utente \u00e8 stato fornito un accesso maggiore di quanto fosse necessario per le sue esigenze lavorative.<\/i><br \/>\nEsempio 2. Dopo il trasferimento dell'utente a un altro incarico, i diritti di accesso precedentemente concessi non sono stati revocati.<br \/>\nMODELLO TIPOLOGICO DI MINACCIA. MODULO DI INTEGRAZIONE<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUMI\"><\/a><\/noindex><\/p>\n<h2>Il modulo di integrazione \u00e8 un insieme di oggetti dell'infrastruttura informatica destinati all'organizzazione dello scambio di informazioni tra i sistemi informativi.<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione al quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nConsiderando il fatto che nelle reti aziendali non \u00e8 sempre possibile separare in modo chiaro un sistema informativo da un altro, il modulo di integrazione pu\u00f2 essere considerato anche come un legame tra i componenti all'interno di un unico sistema informativo.<\/p>\n<p>Uno schema generico del modulo di integrazione appare come segue:<\/p>\n<p><b>Architettura<\/b><br \/>\n\"Server di scambio (\u0421\u041e)\"<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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>\u2013 nodo \/ servizio \/ componente del sistema informativo che svolge la funzione di scambio dati con un altro sistema informativo.<\/i> \"Intermediario\"<\/li>\n<li><i>\u2013 nodo \/ servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme.<\/i> Esempi <br \/>\n\"Intermediari\" <i>possono includere servizi di posta elettronica, bus di servizio aziendale (enterprise service bus \/ architettura SoA), server di file esterni, ecc. In generale, il modulo di integrazione pu\u00f2 anche non contenere \"Intermediari\".<\/i> \"Software di elaborazione dati\"<\/li>\n<li><i>\u2013 insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati.<\/i> Ad esempio, la conversione dei dati dal formato UFBDS al formato ABS, la modifica degli stati dei messaggi durante la trasmissione, ecc. <br \/>\ncorrisponde all'oggetto descritto nel modello tipologico di minaccia \"Connessione di rete\". Alcune connessioni di rete tra quelle presentate nello schema sopra possono anche non essere disponibili.<\/li>\n<li><i>\u00abConnessione di rete\u00bb<\/i> Esempi di moduli di integrazione<\/li>\n<\/ul>\n<p><b>Schema 1. Integrazione ABS e ARM KBR tramite server di file esterno<\/b><\/p>\n<p><i>Per l'esecuzione dei pagamenti, l'impiegato autorizzato della banca estrae dai documenti elettronici di pagamento dall'ABS e li salva in un file (formato proprio, ad esempio, SQL dump) nella cartella di rete (\u2026SHARE) del server di file. Successivamente, questo file viene convertito da uno script di conversione in un insieme di file nel formato UFBDS, che poi legge l'ARM KBR.<\/i><\/p>\n<p>Per effettuare i pagamenti, un dipendente autorizzato della banca esporta dai A.B.S. documenti di pagamento elettronici e li salva in un file (in un formato proprietario, ad esempio SQL-dump) su una cartella di rete (\u2026SHARE) del server files. Successivamente, questo file viene convertito tramite uno script in un insieme di file nel formato UFEBS, che successivamente legge l'ARM KBR. <br \/>\nDopo di ci\u00f2, l'operatore autorizzato \u2014 utente del sistema 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 decodifica e verifica della firma elettronica, dopo di che vengono registrati come insieme di file nel formato UFBBS su un 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 unico server fisico, l'ARM KBR funzioni su un computer dedicato e lo script di conversione operi su un server file.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/bef53aaa1deaee5adeca620204345642.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio lato ABS\u00bb<\/i> \u2013 server ABS.<br \/>\n<i>\u00abServer di scambio lato ARM KBR\u00bb<\/i> \u2013 computer ARM KBR.<br \/>\n<i>\u2013 nodo \/ servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme.<\/i> \u2013 server file esterno.<br \/>\n<i>\u2013 insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati.<\/i> \u2013 script di conversione.<\/p>\n<p><i>Schema 2. Integrazione dell'ABS e dell'ARM KBR con la creazione di una cartella di rete condivisa con i pagamenti su ARM KBR<\/i><\/p>\n<p>Tutto simile allo Schema 1, ma non viene utilizzato un server di file separato, invece la cartella di rete (\u2026SHARE) con documenti di pagamento elettronici \u00e8 collocata sul computer con l'ARM KBR. Lo script del convertitore funziona anche sull'ARM KBR.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/7d3ecde6d78b2c45e1249236c7da925b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:<br \/>\nSimile allo Schema 1, ma <i>\u2013 nodo \/ servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme.<\/i> non \u00e8 utilizzato.<\/p>\n<p><i>Schema 3. Integrazione dell'ABS e dell'ARM KBR-N tramite IBM WebSphere MQ e firma dei documenti elettronici \u00ablato ABS\u00bb<\/i><\/p>\n<p>L'ABS opera su una piattaforma non supportata dalla crittografia SKZI SCAD Signature. La firma dei documenti elettronici in uscita \u00e8 effettuata su un server di firma elettronica (Server EP). Questo stesso server verifica la firma elettronica dei documenti in arrivo dalla Banca di Russia.<\/p>\n<p>L'ABS carica sul Server EP un file con i documenti di pagamento nel proprio formato.<br \/>\nIl Server EP, tramite uno script di conversione, trasforma 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 i messaggi di pagamento firmati, dopo di che un lavoratore autorizzato \u2014 utente dell'ARM KBR \u2014 li crittografa e li invia al sistema di pagamento della Banca di Russia.<\/p>\n<p>All'arrivo dei pagamenti dalla Banca di Russia, l'ARM KBR-N li decodifica e verifica la firma elettronica. I pagamenti elaborati con successo come messaggi elettronici decodificati e firmati nel formato UFBBS vengono inviati a IBM WebSphere MQ, da dove sono 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 dell'ABS \u2014 carica il file risultante nell'ABS secondo la procedura stabilita.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/b1bd9c224b18dc84cca5f8bdc7d69713.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio lato ABS\u00bb<\/i> \u2013 server ABS.<br \/>\n<i>\u00abServer di scambio lato ARM KBR\u00bb<\/i> \u2014 computer ARM KBR.<br \/>\n<i>\u2013 nodo \/ servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme.<\/i> \u2013 Server EP e IBM WebSphere MQ.<br \/>\n<i>\u2013 insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati.<\/i> \u2013 script di conversione, SKZI SCAD Signature sul Server EP.<\/p>\n<p><i>Schema 4. Integrazione del Server DBO e dell'ABS tramite API, fornita da un server di scambio dedicato<\/i><\/p>\n<p>Consideriamo che in banca siano utilizzati diversi sistemi di banking online (DBO): <\/p>\n<ul>\n<li>\u00abInternet Client-Bank\u00bb per persone fisiche (IKB FL);<\/li>\n<li>\u00abInternet Client-Bank\u00bb per persone giuridiche (IKB UL). <\/li>\n<\/ul>\n<p>\nPer garantire la sicurezza informatica, tutta l'interazione dell'ABS con i sistemi DBO avviene tramite un server di scambio dedicato, operante all'interno del sistema informatico \u00abABS\u00bb.<\/p>\n<p>Esaminiamo ora il processo di interazione del sistema DBO IKB UL con l'ABS.<br \/>\nIl server DBO, ricevendo dal cliente un ordine di pagamento debitamente autenticato, deve creare il documento corrispondente nell'ABS. Per farlo, trasmette le informazioni al server di scambio tramite API, e questo, a sua volta, inserisce i dati nell'ABS. <\/p>\n<p>Quando si modificano i saldi sul conto del cliente, l'ABS genera notifiche elettroniche, le quali vengono trasmesse al server DBO tramite il server di scambio.<\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/63f88ad151996e7ddaa883349a6d8e22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:<br \/>\n<i>\u00abServer di scambio lato DBO\u00bb<\/i> \u2013 server DBO IKB UL.<br \/>\n<i>\u00abServer di scambio lato ABS\u00bb<\/i> \u2013 server di scambio.<br \/>\n<i>\u2013 nodo \/ servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme.<\/i> \u2013 non presente.<br \/>\n<i>\u2013 insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati.<\/i> \u2013 componenti del Server DBO responsabili dell'uso delle API del server di scambio, componenti del server di scambio responsabili per l'uso dell'API dell'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 degli aggressori 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 degli aggressori 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 delle minacce. Connessione di rete. U2. Modifica non autorizzata dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.2. Trasmissione di dati falsi attraverso i canali di comunicazione a nome di un partecipante legittimo allo scambio:<br \/>\nU1.1.2 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU3\">\u00abModello standard delle minacce. Connessione di rete. U3. Violazione della propriet\u00e0 dei dati trasmessi\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.3. Modifica non autorizzata di dati legittimi durante il loro trattamento sui server di scambio o dal mediatore:<br \/>\nU1.3.1. Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU2\">\u00abModello tipico di minaccia. Sistema informativo basato su un'architettura client-server. U2. Modifica non autorizzata delle informazioni protette durante il loro trattamento da parte del server del sistema informativo\u00bb<\/a><\/noindex>.<\/p>\n<p>U1.4. Creazione su Server di scambio o Intermediario di dati falsi 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 tipico di minaccia. Sistema informativo basato su un'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 dei dati durante il loro trattamento tramite software di elaborazione dati:<br \/>\nU1.5.1.  a causa dell'applicazione di modifiche non autorizzate ai settori di configurazione del software di elaborazione dei dati da parte degli aggressori.<br \/>\nU1.5.2.  a causa dell'applicazione di modifiche non autorizzate ai file eseguibili del software di elaborazione dei dati da parte degli aggressori.<br \/>\nU1.5.3.  a causa del controllo interattivo degli aggressori sul lavoro del software di elaborazione dei dati.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZI\"><\/a><\/noindex><\/p>\n<h2>MODELLO TIPICO DI MINACCE. SISTEMA DI PROTEZIONE CRIPTOGRAFICA DELLE INFORMAZIONI<\/h2>\n<p><\/p>\n<h3>Oggetto di protezione al quale si applica il modello di minaccia (scope)<\/h3>\n<p>\nL'oggetto di protezione \u00e8 un sistema di protezione crittografica 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 implementa la sua funzionalit\u00e0 target. <\/p>\n<p>La protezione crittografica \u00e8 generalmente realizzata mediante chiamate dalla logica aziendale del software applicativo a primitivi crittografici, che sono collocati in librerie specializzate - nuclei crittografici.<\/p>\n<p>I primitivi crittografici 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 aziendale del software applicativo implementa funzionalit\u00e0 di livello pi\u00f9 alto mediante primitivi crittografici:<\/p>\n<ul>\n<li>cifrare un file con le chiavi dei destinatari scelti;<\/li>\n<li>stabilire 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 aziendale e il nucleo crittografico pu\u00f2 avvenire:<\/p>\n<ul>\n<li>direttamente, tramite chiamate della logica aziendale a primitivi crittografici da librerie dinamiche del nucleo crittografico (.DLL \u2013 per Windows, .SO \u2013 per Linux);<\/li>\n<li>indirettamente, attraverso interfacce crittografiche \u2013 wrapper, come MS Crypto API, Java Cryptography Architecture, PKCS#11 ecc. In questo caso, la logica aziendale si rivolge all'interfaccia crittografica, che quindi traduce la chiamata al corrispondente nucleo crittografico, che in questo caso \u00e8 chiamato fornitore crittografico. L'uso di interfacce crittografiche consente al software applicativo di astrarsi da specifici algoritmi crittografici 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 dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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 dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/9953d524fbee78d7e4eb917e9d56a38f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli elementi degli 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 singolo ambiente di funzionamento del mezzo crittografico (SFK), ad esempio, sullo stesso computer, sotto la gestione dello stesso sistema operativo. L'utente del sistema pu\u00f2 generalmente eseguire anche altri programmi all'interno di questo stesso ambiente operativo, compresi quelli con codice dannoso. In tali condizioni, esiste un serio rischio di fuoriuscita delle chiavi crittografiche chiuse.<\/p>\n<p>Per minimizzare il rischio, si utilizza 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 un rischio di infezione da codice dannoso. Questa parte sar\u00e0 chiamata \u2013 \u00abparte software\u00bb.<\/li>\n<li>La seconda parte opera in un ambiente fidato su un dispositivo dedicato, che contiene un archivio delle chiavi chiuse. Questa parte sar\u00e0 chiamata \u2013 \u00abparte hardware\u00bb.<\/li>\n<\/ol>\n<p>\nLa divisione del nucleo crittografico in parti software e hardware \u00e8 piuttosto convenzionale. Sul mercato ci sono sistemi costruiti secondo lo schema con nucleo crittografico separato, ma la cui parte \u00abhardware\u00bb \u00e8 presentata sotto forma di immagine di una macchina virtuale \u2014 virtual HSM (<noindex><a rel=\"nofollow\" href=\"https:\/\/www.unboundtech.com\/product\/unbound-key-control\/\">esempio<\/a><\/noindex>).<\/p>\n<p>L'interazione tra le due parti del nucleo crittografico avviene in modo tale che le chiavi crittografiche chiuse non vengono mai trasferite alla parte software e, di conseguenza, non possono essere rubate da codice dannoso.<\/p>\n<p>L'interfaccia di interazione (API) e il set di primitive crittografiche fornite all'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 quella hardware avviene secondo il seguente principio:<\/p>\n<ol>\n<li>Le primitive crittografiche che non richiedono l'uso di una chiave privata (ad esempio, il calcolo della funzione hash, la verifica della firma elettronica, ecc.) vengono eseguite dalla parte software.<\/li>\n<li>Le primitive crittografiche che utilizzano una chiave privata (creazione di firme elettroniche, decrittazione dei dati, ecc.) vengono eseguite dalla parte hardware.<\/li>\n<\/ol>\n<p>\nIllustriamo il funzionamento del nucleo crittografico separato con l'esempio della creazione di una firma elettronica:<\/p>\n<ol>\n<li>La parte software calcola la funzione hash dei dati da firmare e invia questo valore alla parte hardware attraverso un canale di comunicazione tra i nuclei crittografici.<\/li>\n<li>La parte hardware, utilizzando la chiave privata e la hash, genera il valore della firma elettronica e lo invia alla parte software attraverso il canale di scambio.<\/li>\n<li>La parte software restituisce il valore ottenuto all'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 nella verifica della firma elettronica si ottiene solo al superamento con successo di tutte le fasi di verifica.<\/p>\n<p><i>Fase 1. Controllo dell'integrit\u00e0 dei dati e della loro provenienza.<\/i><\/p>\n<p><u>Contenuto della fase.<\/u> Si verifica la firma elettronica dei dati secondo l'algoritmo crittografico appropriato. Il superamento con successo di questa fase indica che i dati non sono stati modificati dal momento della loro firma e che la firma \u00e8 stata generata dalla chiave privata corrispondente alla chiave pubblica di verifica 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 monitoraggio della validit\u00e0 della chiave privata della firma elettronica.<\/i><br \/>\n<u>Contenuto della fase.<\/u> La fase consiste in due sottofasi intermedie. Nella prima si stabilisce se la chiave pubblica di verifica della firma elettronica fosse considerata sicura al momento della firma dei dati. Nella seconda si verifica se la chiave privata di firma elettronica era valida al momento della firma dei dati. In generale, le validit\u00e0 di queste chiavi possono non coincidere (ad esempio, per certificati qualificati delle chiavi di verifica delle firme elettroniche). I modi per stabilire la fiducia nella chiave pubblica del firmatario sono definiti dalle regole di gestione documentale elettronica concordate dalle parti coinvolte.<br \/>\n<u>Luogo di esecuzione della fase:<\/u> applicativo \/ nucleo crittografico.<\/p>\n<p><i>Fase 3. Controllo dei poteri del firmatario.<\/i><br \/>\n<u>Contenuto della fase.<\/u> Secondo le regole stabilite della gestione documentale elettronica, si verifica se il firmatario avesse il diritto di certificare i dati protetti. Per esempio, consideriamo un caso di violazione dei poteri. Supponiamo che ci sia un'organizzazione in cui tutti i dipendenti hanno una firma elettronica. Un ordine del dirigente arriva nel sistema interno di gestione documentale elettronica, ma firmato con la firma elettronica del responsabile del magazzino. Pertanto, tale documento non pu\u00f2 essere considerato legittimo.<br \/>\n<u>Luogo di esecuzione della fase:<\/u> applicativo.<\/p>\n<p><b>Assunzioni fatte nella descrizione dell'oggetto della protezione<\/b><\/p>\n<ol>\n<li>I canali di trasferimento delle informazioni, ad eccezione dei canali di scambio delle chiavi, passano attraverso l'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 proprietari delle chiavi pubbliche, sono memorizzate in un archivio di chiavi pubbliche.<\/li>\n<li>L'applicativo lavora con l'archivio delle chiavi pubbliche tramite il nucleo crittografico.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Esempio di un sistema informatico protetto tramite SKEI<\/h3>\n<p>\nPer illustrare gli schemi presentati in precedenza, consideriamo un sistema informatico ipotetico e evidenziamo tutti i suoi elementi strutturali. <\/p>\n<p><b>Descrizione del sistema informatico<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" 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 giuridicamente significativo (EDE) tra di loro. A tal fine, hanno stipulato un accordo in cui \u00e8 specificato che i documenti saranno trasmessi via email, e devono essere criptati e firmati con una firma elettronica qualificata. Come strumenti per la creazione e l'elaborazione dei documenti devono essere utilizzati programmi per ufficio del pacchetto Microsoft Office 2016, mentre per la protezione crittografica si utilizzeranno SKEI CryptoPRO e il software di crittografia CryptoARM.<\/p>\n<p><b>Descrizione dell'infrastruttura dell'organizzazione 1<\/b><\/p>\n<p>L'organizzazione 1 ha deciso di installare il sistema crittografico CrittografiaPRO e il software CrittografiaARM su un computer fisico dell'utente. Le chiavi di crittografia e firma elettronica saranno conservate su un token ruToken, operante in modalit\u00e0 di chiave estraibile. L'utente preparer\u00e0 documenti elettronici localmente sul proprio computer, dopodich\u00e9 li crittografer\u00e0, firmer\u00e0 e invier\u00e0 tramite un client di posta elettronica installato localmente.<\/p>\n<p><b>Descrizione dell'infrastruttura dell'organizzazione 2<\/b><\/p>\n<p>L'organizzazione 2 ha deciso di spostare le funzioni di crittografia e firma elettronica su una macchina virtuale dedicata. Tutte le operazioni crittografiche saranno eseguite automaticamente. <\/p>\n<p>Per questo, sono stati organizzati due cartelle di rete on una macchina virtuale dedicata: \u00ab\u2026In\u00bb, \u00ab\u2026Out\u00bb. Nella cartella di rete \u00ab\u2026In\u00bb verranno automaticamente collocati i file ricevuti dai contraenti in chiaro. Questi file verranno decrittati e verr\u00e0 verificata la firma elettronica.<\/p>\n<p>Nella cartella &#171;&#8230;Out&#187; l'utente posizioner\u00e0 i file da crittografare, firmare e inviare al contraente. I file stessi saranno preparati sul proprio APM.<br \/>\nPer eseguire le funzioni di crittografia e firma elettronica, sulla macchina virtuale sono stati installati il sistema crittografico CrittografiaPRO, il software CrittografiaARM e un client di posta elettronica. La gestione automatica di tutti gli elementi della macchina virtuale avverr\u00e0 tramite script sviluppati dagli amministratori di sistema. L'esecuzione degli script sar\u00e0 registrata in file di log.<\/p>\n<p>Le chiavi crittografiche per la firma elettronica saranno memorizzate su un token con chiave non estraibile JaCarta GOST, che l'utente collegher\u00e0 al proprio computer locale.<\/p>\n<p>Il token sar\u00e0 trasferito sulla macchina virtuale tramite strumenti software specializzati USB-over-IP, installati sia sul computer dell'utente che sulla macchina virtuale.<\/p>\n<p>Gli orologi di sistema sul computer dell'utente nell'organizzazione 1 saranno corretti manualmente. Gli orologi di sistema della macchina virtuale dedicata nell'organizzazione 2 saranno sincronizzati con gli orologi di sistema dell'iperparavirtualizzatore, che a loro volta saranno sincronizzati tramite Internet con server di tempo pubblici.<\/p>\n<p><b>Distinzione degli elementi strutturali del sistema crittografico<\/b><br \/>\nSulla base della descrizione fornita dell'infrastruttura IT, identificheremo gli elementi strutturali del sistema crittografico e li registreremo in una tabella.<\/p>\n<p><i>Tabella \u2014 Corrispondenza degli elementi del modello del sistema crittografico 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 CrittografiaARM<br \/>\nSoftware CrittografiaARM<\/p>\n<p>Parte software del nucleo crittografico<br \/>\nSistema crittografico CrittografiaPRO CSP<br \/>\nSistema crittografico CrittografiaPRO CSP<\/p>\n<p>Parte hardware del nucleo crittografico<br \/>\n\u00e8 assente<br \/>\nJaCarta GOST<\/p>\n<p>API<br \/>\nMS CryptoAPI<br \/>\nMS CryptoAPI<\/p>\n<p>Magazzino chiavi pubbliche<br \/>\nComputer dell'utente:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 magazzino certificati standard di Windows.<br \/>\nIperparavirtualizzatore:<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 magazzino certificati standard di Windows.<\/p>\n<p>Magazzino chiavi private<br \/>\nToken ruToken, operante in modalit\u00e0 di chiave estraibile<br \/>\nToken JaCarta GOST, operante in modalit\u00e0 di chiave non estraibile<\/p>\n<p>Canale di scambio chiavi pubbliche<br \/>\nComputer dell'utente:<br \/>\n \u2014 memoria volatile.<\/p>\n<p>Iperparavirtualizzatore:<br \/>\n \u2014 memoria volatile.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria volatile.<\/p>\n<p>Canale di scambio chiavi private<br \/>\nComputer dell'utente:<br \/>\n \u2014 bus USB;<br \/>\n \u2014 memoria volatile.<br \/>\n\u00e8 assente<\/p>\n<p>Canale di scambio tra i nuclei crittografici<br \/>\nnon presente (assenza della parte hardware del nucleo crittografico)<br \/>\nComputer dell'utente:<br \/>\n \u2014 bus USB;<br \/>\n \u2014 memoria volatile;<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>Iperparavirtualizzatore:<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 interfaccia di rete;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 modulo software USB-over-IP.<\/p>\n<p>Canale di scambio dati pubblici<br \/>\nComputer dell'utente:<br \/>\n \u2014 dispositivi di input\/output;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<br \/>\nComputer dell'utente:<br \/>\n \u2014 dispositivi di input\/output;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Rete aziendale dell'organizzazione 2.<\/p>\n<p>Iperparavirtualizzatore:<br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale: <br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Canale di scambio dati protetti<br \/>\nInternet.<\/p>\n<p>Rete aziendale dell'organizzazione 1.<\/p>\n<p>Computer dell'utente:<br \/>\n \u2014 disco rigido;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 interfaccia di rete.<\/p>\n<p>Internet.<\/p>\n<p>Rete aziendale dell'organizzazione 2.<\/p>\n<p>Iperparavirtualizzatore:<br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Macchina virtuale: <br \/>\n \u2014 interfaccia di rete; <br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>Canale di trasmissione del tempo<br \/>\nComputer dell'utente:<br \/>\n \u2014 dispositivi di input\/output;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Internet. <br \/>\nRete aziendale dell'organizzazione 2,<\/p>\n<p>Iperparavirtualizzatore:<br \/>\n \u2014 interfaccia di rete;<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 timer di sistema.<\/p>\n<p>Canale di trasmissione comandi di controllo<br \/>\nComputer dell'utente:<br \/>\n \u2014 dispositivi di input\/output;<br \/>\n \u2014 memoria volatile.<\/p>\n<p>(Interfaccia utente grafica del software CrittografiaARM)<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>(Script di automazione)<\/p>\n<p>Canale di ricezione dei risultati di elaborazione<br \/>\nComputer dell'utente:<br \/>\n \u2014 dispositivi di input\/output;<br \/>\n \u2014 memoria volatile.<\/p>\n<p>(Interfaccia utente grafica del software CrittografiaARM)<\/p>\n<p>Macchina virtuale:<br \/>\n \u2014 memoria volatile;<br \/>\n \u2014 disco rigido.<\/p>\n<p>(File di log dell'esecuzione degli script di automazione)<\/p>\n<p><\/p>\n<h3>Minacce alla sicurezza di alto livello<\/h3>\n<p>\n<b>Spiegazioni<\/b><\/p>\n<p>Assunzioni fatte nella decomposizione delle minacce:<\/p>\n<ol>\n<li>Vengono utilizzati algoritmi crittografici robusti.<\/li>\n<li>Gli algoritmi crittografici sono 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 viene utilizzato per la crittografia di grandi volumi di dati, si tiene conto del carico consentito sulla chiave, ecc.).<\/li>\n<li>I malintenzionati conoscono tutti gli algoritmi, protocolli e chiavi pubbliche utilizzati.<\/li>\n<li>I malintenzionati possono leggere tutti i dati crittografati.<\/li>\n<li>I malintenzionati sono in grado di riprodurre qualsiasi elemento software nel sistema.<\/li>\n<\/ol>\n<p>\n<b>Decomposizione<\/b><\/p>\n<p>A1. Compromissione delle chiavi crittografiche private.<br \/>\nA2. Crittografia di dati falsi a nome di un mittente legittimo.<br \/>\nA3. Decrittografia di dati crittografati da parte di individui non legittimati a ricevere i dati (malintenzionati).<br \/>\nU4. Creazione di una firma elettronica da parte di un firmatario legittimo utilizzando dati contraffatti.<br \/>\nU5. Ottenimento di un risultato positivo nella verifica della firma elettronica su dati contraffatti.<br \/>\nU6. Accettazione erronea di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso di documentazione elettronica.<br \/>\nU7. Consultazione non autorizzata di dati protetti durante il loro trattamento con sistemi di crittografia.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU1\"><\/a><\/noindex><\/p>\n<h3>U1. Compromissione delle chiavi crittografiche private<\/h3>\n<p>\nU1.1. Ottenimento della chiave privata dal deposito delle chiavi private.<\/p>\n<p>U1.2. Ottenimento della chiave privata da oggetti nell'ambiente operativo dei dispositivi crittografici, dove essa pu\u00f2 trovarsi temporaneamente.<br \/>\n<i>Spiegazioni U1.2.<\/i><\/p>\n<p>Gli oggetti in cui pu\u00f2 essere temporaneamente conservata la chiave privata includeranno:<\/p>\n<ol>\n<li>memoria RAM, <\/li>\n<li>file temporanei, <\/li>\n<li>file di paging, <\/li>\n<li>file di ibernazione, <\/li>\n<li>file di snapshot dello stato 'caldo' delle macchine virtuali, inclusi i file del contenuto della memoria RAM delle macchine virtuali messe in pausa.<\/li>\n<\/ol>\n<p>\nU1.2.1. Estrazione di chiavi private dalla memoria RAM attiva congelando i moduli RAM, estraendoli e successivamente leggendo i dati (freeze attack).<br \/>\n<i>Spiegazioni U1.2.1.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.securitylab.ru\/analytics\/452899.php\">di attacco<\/a><\/noindex>. <\/p>\n<p>U1.3. Ottenimento della chiave privata tramite un canale di scambio di chiavi private.<br \/>\n<i>Spiegazioni U1.3.<\/i><br \/>\nUn esempio di implementazione di questa minaccia sar\u00e0 fornito <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA3\">pi\u00f9 in basso<\/a><\/noindex>.<\/p>\n<p>U1.4. Modifica non autorizzata del nucleo crittografico, a seguito della quale le chiavi private diventano note a malintenzionati.<\/p>\n<p>U1.5. Compromissione della chiave privata a causa dell'uso di canali tecnici di fuga di informazioni (TKUI).<br \/>\n<i>Spiegazioni U1.5.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.usenix.org\/system\/files\/conference\/usenixsecurity18\/sec18-alam.pdf\">di attacco<\/a><\/noindex>. <\/p>\n<p>U1.6. Compromissione della chiave privata a causa dell'uso di apparecchiature tecniche speciali (STS) destinate alla raccolta clandestina di informazioni ('sistemi di ascolto').<\/p>\n<p>U1.7. Compromissione delle chiavi private durante la loro conservazione al di fuori dei sistemi di crittografia.<br \/>\n<i>Spiegazioni U1.7.<\/i><br \/>\nAd esempio, un utente conserva i propri supporti crittografici nel cassetto della scrivania, da cui possono essere facilmente estratti da malintenzionati.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU2\"><\/a><\/noindex><\/p>\n<h3>U2. Crittografia di dati contraffatti a nome di un mittente legittimo<\/h3>\n<p>\n<b>Spiegazioni<\/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 per la 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 informativa. Protezione crittografica delle informazioni. Schemi per la generazione di chiavi comuni con autenticazione basata su chiave pubblica'<\/a><\/noindex>. Per gli altri schemi crittografici questa minaccia non esiste, poich\u00e9 la crittografia avviene con chiavi pubbliche del destinatario, le quali in generale sono conosciute dai malintenzionati.<\/p>\n<p><b>Decomposizione<\/b><br \/>\nU2.1. Compromissione della chiave privata del mittente:<br \/>\nU2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">'Modello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche private'<\/a><\/noindex>.<\/p>\n<p>U2.2. Sostituzione dei dati di input nel canale di scambio di dati pubblici.<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 persone non legittimate a ricevere tali dati (malintenzionati)<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU3.1. Compromissione delle chiavi private del destinatario dei dati crittografati. <br \/>\nU3.1.1 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">'Modello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche private'<\/a><\/noindex>.<\/p>\n<p>U3.2. Sostituzione dei dati crittografati 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 utilizzando dati contraffatti.<br \/>\n<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU4.1. Compromissione delle chiavi private della firma elettronica del firmatario legittimo. <br \/>\nU4.1.1 Riferimento: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">'Modello tipico di minaccia. Sistema di protezione crittografica delle informazioni. U1. Compromissione delle chiavi crittografiche private'<\/a><\/noindex>.<\/p>\n<p>U4.2. Sostituzione dei dati firmati nel canale di scambio di dati pubblici.<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 su dati contraffatti.<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU5.1. I malintenzionati intercettano nel canale di trasmissione dei risultati un messaggio con un risultato negativo della verifica della firma elettronica e lo sostituiscono con un messaggio con un risultato positivo.<\/p>\n<p>U5.2. I malintenzionati attaccano la fiducia verso i certificati di firma (<b>SCENARIO \u2014 tutti gli elementi sono obbligatori<\/b>):<br \/>\nU5.2.1. I malintenzionati generano una chiave pubblica e una chiave privata per la firma elettronica. Se nel sistema vengono utilizzati certificati di chiavi di firma elettronica, generano un certificato di firma elettronica il pi\u00f9 simile possibile a quello del presunto mittente dei dati, il cui messaggio intendono falsificare.<br \/>\nU5.2.2. I malintenzionati apportano modifiche non autorizzate nel deposito delle chiavi pubbliche, conferendo alla chiave pubblica generata da loro il necessario livello di fiducia e autorit\u00e0.<br \/>\nU5.2.3. Gli aggressori firmano dati falsi con una chiave di firma elettronica precedentemente generata e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.3. Gli aggressori conducono 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 aggressori compromettono chiavi private di firma elettronica scadute (non attualmente valide) di un mittente legittimo.<br \/>\nU5.3.2. Gli aggressori sostituiscono il tempo nel canale di trasmissione del tempo con un momento in cui le chiavi compromesse erano ancora valide.<br \/>\nU5.3.3. Gli aggressori firmano dati falsi utilizzando una chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.4. Gli aggressori conducono 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 aggressori fanno una copia del repository delle chiavi pubbliche.<br \/>\nU5.4.2. Gli aggressori compromettono le chiavi private di uno dei mittenti legittimi. Questi si accorgono della compromissione, revocano le chiavi e le informazioni sulla revoca vengono inserite nel repository delle chiavi pubbliche.<br \/>\nU5.4.3. Gli aggressori sostituiscono il repository delle chiavi pubbliche con quello precedentemente copiato.<br \/>\nU5.4.4. Gli aggressori firmano dati falsi con una chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.<\/p>\n<p>U5.5. &lt;&#8230;&gt; a causa della presenza di errori nell'implementazione della 2\u00aa e 3\u00aa fase di verifica della firma elettronica:<br \/>\n<i>Spiegazione U5.5.<\/i><br \/>\nUn esempio di implementazione di questa minaccia \u00e8 fornito <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA4\">pi\u00f9 in basso<\/a><\/noindex>.<\/p>\n<p>U5.5.1. La verifica della fiducia nel certificato della chiave di firma elettronica avviene solo sulla base della fiducia nel certificato con cui \u00e8 stata firmata, senza controlli CRL o OCSP.<br \/>\n<i>Spiegazione 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 del certificato non vengono analizzate le autorit\u00e0 dei certificati emittenti.<br \/>\n<i>Spiegazione U5.5.2.<\/i><br \/>\nEsempio di attacco contro i certificati SSL\/TLS. <br \/>\nGli aggressori hanno acquistato un certificato legittimo per la loro e-mail. Successivamente, hanno creato un certificato fraudolento per un sito e lo hanno firmato con il proprio certificato. Se non viene effettuato un controllo delle autorit\u00e0, la verifica della catena di fiducia risulter\u00e0 corretta, e quindi anche il certificato fraudolento risulter\u00e0 valido.<\/p>\n<p>U5.5.3. Nella costruzione della catena di fiducia del certificato non vengono controllati i certificati intermedi per la revoca.<\/p>\n<p>U5.5.4. L'aggiornamento della CRL avviene con meno frequenza rispetto alla loro emissione da parte dell'autorit\u00e0 di certificazione.<\/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 su richiesta fatta dopo il tempo di generazione della firma, oppure prima di ricevere la CRL successiva alla generazione della firma. <br \/>\n<i>Spiegazione U5.5.5.<\/i><br \/>\nNelle regolazioni della maggior parte degli AC, il tempo di revoca del certificato \u00e8 considerato il tempo di emissione della CRL pi\u00f9 vicina contenente informazioni sulla revoca del certificato.<\/p>\n<p>U5.5.6. Quando si ricevono dati firmati, non viene verificata l'appartenenza del certificato al mittente. <br \/>\n<i>Spiegazione U5.5.6.<\/i><br \/>\nEsempio di attacco. Riguardo 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. Gli aggressori 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 nome suo, 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 verranno considerati legittimi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU6\"><\/a><\/noindex><\/p>\n<h3>U6. Accettazione erronea di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso di documentazione elettronica.<\/h3>\n<p>\n<b>Decomposizione<\/b><br \/>\nU6.1. Il destinatario non individua la duplicazione dei documenti ricevuti.<br \/>\n<i>Spiegazione U6.1.<\/i><br \/>\nEsempio di attacco. Gli aggressori possono intercettare il documento inviato al destinatario, anche se protetto crittograficamente, e poi inviarlo molte volte nel canale di trasmissione dei dati protetti. Se il destinatario non rileva le duplicazioni, tutti i documenti ricevuti verranno percepiti e trattati come documenti distinti.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU7\"><\/a><\/noindex><\/p>\n<h3>U7. Accesso non autorizzato ai dati protetti durante l'elaborazione di SKZI <\/h3>\n<p>\n<b>Decomposizione<\/b><\/p>\n<p>U7.1. &lt;&#8230;&gt; a seguito di una fuga di informazioni tramite canali esterni (side channel attack).<br \/>\n<i>Spiegazione U7.1.<\/i><br \/>\nEsempio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cs.tau.ac.il\/~tromer\/synesthesia\/synesthesia.pdf\">di attacco<\/a><\/noindex>. <\/p>\n<p>U7.2. &lt;&#8230;&gt; a causa della neutralizzazione della protezione da accessi non autorizzati alle informazioni elaborate su SKZI:<br \/>\nU7.2.1. Sfruttamento di SKZI in violazione dei requisiti descritti nella documentazione su SKZI.<\/p>\n<p>U7.2.2. &lt;&#8230;&gt;, effettuata a causa della presenza di vulnerabilit\u00e0 in:<br \/>\nU7.2.2.1. &lt;&#8230;&gt; mezzi di protezione contro accessi non autorizzati.<br \/>\nU7.2.2.2. &lt;&#8230;&gt; lo stesso SKZI.<br \/>\nU7.2.2.3. &lt;&#8230;&gt; l'ambiente di funzionamento del mezzo crittografico.<\/p>\n<h3>Esempi di attacchi<\/h3>\n<p>\nGli scenari di seguito riportati contengono intenzionalmente errori nell'organizzazione della sicurezza informatica e servono solo a illustrare possibili attacchi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA1\"><\/a><\/noindex><\/p>\n<h4>Scenario 1. Esempio di realizzazione delle minacce U2.2 e U4.2.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/77d51167720552df4eb9c2bafbce6765.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl software ARM KBR e il sistema di crittografia SKAD Signature sono installati su un computer fisico, non connesso alla rete computazionale. Un token FKN vdToken viene utilizzato come supporto chiave in modalit\u00e0 di chiave non estraibile.<\/p>\n<p>Il regolamento per l'effettuazione dei pagamenti prevede che il specialista dei pagamenti scarichi i messaggi elettronici in chiaro dal proprio computer di lavoro (schema del vecchio ARM KBR) da un apposito server di file protetto, quindi li salvi su un supporto rimovibile USB e li trasferisca all'ARM KBR, dove vengono crittografati e firmati. Successivamente, il specialista trasferisce i messaggi elettronici protetti su un supporto rimovibile, per poi, tramite il proprio computer di lavoro, caricarli sul server di file, da dove giungono all'UTA e poi 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>Attacco<\/b><br \/>\nGli aggressori installano senza autorizzazione un sistema di controllo remoto sul computer di lavoro del specialista e nel momento in cui vengono registrati i pagamenti (messaggi elettronici) in chiaro, sostituiscono il contenuto di uno di essi. Il specialista trasferisce le disposizioni di pagamento all'ARM KBR, le firma e le crittografa, senza accorgersi della sostituzione (ad esempio, a causa del numero elevato di disposizioni di pagamento in elaborazione, di stanchezza, ecc.). Successivamente, l'ordine di pagamento falso, passando attraverso la catena tecnologica, arriva nel sistema di pagamento della Banca di Russia.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA2\"><\/a><\/noindex><\/p>\n<h4>Scenario 2. Esempio di realizzazione delle minacce U2.2 e U4.2.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/b4489290d665b359323ec6b58dde1139.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn computer con ARM KBR, SKAD Signature e un supporto chiave FKN vdToken connesso opera in un ambiente dedicato senza accesso da parte del personale.<br \/>\nIl specialista dei pagamenti si connette all'ARM KBR in modalit\u00e0 remota tramite protocollo RDP.<\/p>\n<p><b>Attacco<\/b><br \/>\nGli aggressori intercettano i dati di accesso utilizzati dal specialista dei pagamenti per connettersi e lavorare con l'ARM KBR (ad esempio, tramite codice malevolo sul suo computer). Poi si connettono a nome suo e inviano un ordine di pagamento falso 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 realizzazione della minaccia U1.3. <\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\n<img decoding=\"async\" alt=\"Sicurezza informatica dei pagamenti bancari senza contante. Parte 8 \u2014 Modelli tipici di minaccia\" src=\"\/wp-content\/uploads\/2019\/04\/988a97dd75247780556d388566d771f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConsideriamo uno dei possibili scenari di realizzazione dei moduli di integrazione \"ABS-KBR\" per un nuovo schema (ARM KBR-N), in cui la firma elettronica dei documenti in uscita avviene lato ABS. Supponiamo inoltre che l'ABS operi su un sistema operativo non supportato da SKAD Signature e, di conseguenza, la funzionalit\u00e0 crittografica sia eseguita su una macchina virtuale separata \u2014 modulo di integrazione \"ABS-KBR\".<br \/>\nCome supporto chiave, si utilizza un token USB standard, che opera in modalit\u00e0 chiave estraibile. Quando si \u00e8 tentato di connettere il supporto chiave all'iperconvergenza, si \u00e8 scoperto che non c'erano porte USB disponibili nel sistema, quindi si \u00e8 deciso di collegare il token USB tramite un hub USB di rete e installare un client USB-over-IP sulla macchina virtuale, che avrebbe stabilito la connessione con l'hub.<\/p>\n<p><b>Attacco<\/b><br \/>\nGli aggressori hanno intercettato la chiave privata della firma elettronica dal canale di comunicazione tra l'hub USB e l'iperconvergenza (i dati venivano trasmessi in chiaro). Possedendo la chiave privata, gli aggressori hanno formato un ordine di pagamento falso, lo hanno firmato con la firma elettronica e l'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 realizzazione della minaccia U5.5.<\/h4>\n<p>\n<b>Descrizione dell'oggetto<\/b><br \/>\nPrendiamo in considerazione lo stesso schema del precedente scenario. Supponiamo che i messaggi elettronici provenienti dall'APM KBR-N vengano inviati nella cartella &#8230;SHAREIn, mentre quelli inviati all'APM KBR-N e poi al sistema di pagamento della Banca di Russia vadano in &#8230;SHAREout.<br \/>\nInoltre, supponiamo che, durante l'implementazione del modulo di integrazione, le liste dei certificati revocati vengano aggiornate solo durante il riemissione delle chiavi crittografiche e che i messaggi elettronici ricevuti nella cartella &#8230;SHAREIn vengano verificati solo per il controllo dell'integrit\u00e0 e la fiducia nella chiave pubblica della firma elettronica.<\/p>\n<p><b>Attacco<\/b><\/p>\n<p>I criminali, approfittando delle chiavi rubate nel precedente scenario, hanno firmato un bonifico falso contenente informazioni sul trasferimento di denaro a un cliente truffatore e lo hanno introdotto nel canale di scambio di dati protetti. Poich\u00e9 non viene effettuato alcun controllo per verificare che il bonifico sia effettivamente firmato 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.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\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\" \/>\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.0.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:description\" content=\"\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\" \/>\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 informatica nei pagamenti bancari senza contante. Parte 8 \u2014 Modelli di minacce tipici | ProHoster","description":"Di cosa tratta la ricerca Riferimenti ad altre parti della ricerca Sicurezza informatica nei pagamenti bancari senza contante. Parte 1 \u2014 Fondamenti economici. Sicurezza informatica nei pagamenti bancari senza contante. Parte 2 \u2014 Infrastruttura IT tipica di una banca. Sicurezza informatica nei pagamenti bancari senza contante. Parte 3 \u2014 Formulazione dei requisiti per il sistema di protezione. Sicurezza informatica nei pagamenti bancari senza contante. Parte 4 \u2014 Panoramica degli standard di modellazione delle minacce. Sicurezza informatica nei pagamenti bancari senza contante.","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:description":"\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","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}]}}