Collegamenti ad altre parti dello studio
- (Sei qui)
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 è fatto riferimento in :
- .
- .
- .
- .
HAБРО-WARNING !!! Cari hucraftiani, questo non è un post di intrattenimento.
Nascondendo sotto il tag 40+ pagine di materiali mirati a aiutare nel lavoro o nello studio 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.E la tradizionale — «l'uso delle informazioni contenute in questo articolo per fini illegali è perseguibile dalla legge». Buona lettura!
Informazioni per i lettori che si avvicinano allo studio partendo da questa pubblicazione.
Di cosa tratta lo studio
Stai leggendo una guida per il professionista responsabile della sicurezza informatica nei pagamenti all'interno di una banca.
Logica di presentazione
Inizialmente, viene fornita una descrizione dell'oggetto di protezione. Successivamente, nella e parte 3 parte 4 parte 5 e è fornita un'analisi degli attacchi reali. e contiene una descrizione del modello di minacce elaborato tenendo conto delle informazioni presentate in tutte le parti precedenti.
MODELLO TIPO DI MINACCIA. COLLEGAMENTO DI RETE
Oggetto di protezione al quale si applica il modello di minaccia (scope)
L'oggetto di protezione è costituito dai dati trasmessi attraverso un collegamento di rete che opera in reti di trasmissione dati basate sullo stack TCP/IP.
Architettura
Descrizione degli elementi architettonici:
- «Node finali» — nodi che scambiano informazioni protette.
- «Nodi intermedi» — 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ò funzionare senza nodi intermedi (direttamente tra nodi finali).
Minacce alla sicurezza di alto livello
Decomposizione
U1. Accesso non autorizzato ai dati trasmessi.
U2. Modifica non autorizzata dei dati trasmessi.
U3. Violazione della paternità dei dati trasmessi.
U1. Accesso non autorizzato ai dati trasmessi
Decomposizione
U1.1. , che avviene su nodi finali o intermedi:
U1.1.1. attraverso la lettura dei dati mentre si trovano nella memoria del nodo:
U1.1.1.1. nella memoria volatile.
Chiarimenti su U1.1.1.1.
Ad esempio, durante l'elaborazione dei dati nel stack di rete del nodo.
U1.1.1.2. nella memoria non volatile.
Chiarimenti su U1.1.1.2.
Ad esempio, durante l'archiviazione dei dati trasmessi nella cache, file temporanei o file di swap.
U1.2. , che avviene su nodi esterni nella rete di trasmissione dati:
U1.2.1. attraverso la cattura di tutti i pacchetti che raggiungono l'interfaccia di rete del nodo:
Chiarimenti su U1.2.1.
La cattura di tutti i pacchetti avviene portando la scheda di rete in modalità promiscuous (promiscuous mode per adattatori cablati o in modalità monitor per adattatori wi-fi).
U1.2.2. mediante attacchi di tipo 'uomo nel mezzo (MiTM)', senza però modificare i dati trasmessi (eccetto i dati di servizio dei protocolli di rete).
U1.2.2.1. Link: .
U1.3. , effettuata tramite fuga di informazioni attraverso canali tecnici (TCUI) da nodi fisici o linee di comunicazione.
U1.4. , effettuata tramite l'installazione su nodi terminali o intermedi di dispositivi tecnici speciali (STS), destinati alla registrazione clandestina delle informazioni.
U2. Modifica non autorizzata dei dati trasmessi
Decomposizione
U2.1. , eseguita su nodi finali o intermedi:
U2.1.1. leggendo e apportando modifiche ai dati mentre si trovano nei dispositivi di memorizzazione dei nodi:
U2.1.1.1. nella memoria volatile:
U2.1.1.2. nella memoria non volatile:
U2.2. , eseguita su nodi terzi di una rete di trasmissione dati:
U2.2.1. attraverso attacchi di tipo «uomo in mezzo (MiTM)» e reindirizzamento del traffico a nodi malevoli:
U2.2.1.1. Collegamento fisico dell'attrezzatura malevola nell'interruzione della connessione di rete.
U2.2.1.2. Esecuzione di attacchi sui protocolli di rete:
U2.2.1.2.1. gestione delle reti locali virtuali (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Modifica non autorizzata delle impostazioni VLAN su switch o router.
U2.2.1.2.2. instradamento del traffico:
U2.2.1.2.2.1. Modifica non autorizzata delle tabelle di instradamento statico dei router.
U2.2.1.2.2.2. Annuncio di percorsi falsi da parte di malintenzionati tramite protocolli di instradamento dinamico.
U2.2.1.2.3. configurazione automatica:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. indirizzamento e risoluzione dei nomi:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Apportare modifiche non autorizzate ai file locali dei nomi host (hosts, lmhosts, ecc.)
U3. Violazione del copyright dei dati trasmessi
Decomposizione
U3.1. Neutralizzazione dei meccanismi di determinazione dell'autore delle informazioni mediante indicazione di dati falsi sull'autore o sulla fonte delle informazioni:
U3.1.1. Modifica dei dati sull'autore contenuti nelle informazioni trasmesse.
U3.1.1.1. Neutralizzazione della protezione crittografica dell'integrità e dell'autore dei dati trasmessi:
U3.1.1.1.1. Riferimento: .
U3.1.1.2. Neutralizzazione della protezione del copyright delle informazioni trasmesse, realizzata tramite codici di conferma usa e getta:
U3.1.1.2.1. .
U3.1.2. Modifica delle informazioni sulla fonte dei dati trasmessi:
U3.1.2.1. .
U3.1.2.2. .
MODELLO STANDARD DELLE MINACCE. SISTEMA INFORMATIVO BASATO SULL'ARCHITETTURA CLIENT-SERVER
Oggetto di protezione al quale si applica il modello di minaccia (scope)
L'oggetto della protezione è un sistema informativo basato sull'architettura client-server.
Architettura
Descrizione degli elementi architettonici:
- «Client» – dispositivo su cui funziona la parte client del sistema informativo.
- «Server» – dispositivo su cui funziona la parte server del sistema informativo.
- «Storage dati» – parte dell'infrastruttura server del sistema informativo destinata alla memorizzazione dei dati elaborati dal sistema informativo.
- «Connessione di rete» – canale di scambio delle informazioni tra il Client e il Server, che attraversa la rete di trasmissione dati. Una descrizione più dettagliata del modello dell'elemento è fornita in .
Limitazioni
Durante la modellazione dell'oggetto sono state stabilite le seguenti limitazioni:
- L'utente interagisce con il sistema informativo nell'ambito di intervalli temporali limitati, chiamati sessioni di lavoro.
- All'inizio di ogni sessione di lavoro, avvengono identificazione, autenticazione e autorizzazione dell'utente.
- Tutte le informazioni protette sono memorizzate nella parte server del sistema informativo.
Minacce alla sicurezza di alto livello
Decomposizione
U1. Comportamenti non autorizzati eseguiti dai malintenzionati a nome di un utente legittimo.
U2. Modifica non autorizzata delle informazioni protette durante il loro trattamento da parte della parte server del sistema informativo.
U1. Comportamenti non autorizzati eseguiti dai malintenzionati a nome di un utente legittimo
Spiegazioni
Di solito nei sistemi informativi, le azioni sono correlate all'utente che le ha eseguite tramite:
- registrazioni di lavoro del sistema (logs).
- specifici attributi degli oggetti dati che contengono informazioni sull'utente che le ha create o modificate.
In relazione alla sessione di lavoro, questa minaccia può essere scomposta in:
- azioni compiute nel contesto della sessione di lavoro dell'utente.
- azioni compiute al di fuori della sessione di lavoro dell'utente.
La sessione di lavoro dell'utente può essere avviata:
- Dallo stesso utente.
- Da malintenzionati.
A questo punto, la decomposizione intermedia di questa minaccia apparirà come segue:
U1.1. Azioni non autorizzate eseguite all'interno di una sessione di lavoro dell'utente:
U1.1.1. , installato dall'utente attaccato.
U1.1.2. , installato dai malintenzionati.
U1.2. Azioni non autorizzate eseguite al di fuori della sessione di lavoro dell'utente.
Dal punto di vista degli oggetti dell'infrastruttura informatica che i malintenzionati possono colpire, la decomposizione delle minacce intermedie apparirà come segue:
Elementi
Decomposizione delle minacce
U1.1.1.
U1.1.2.
U1.2.
Cliente
U1.1.1.1.
U1.1.2.1.
Connessione di rete
U1.1.1.2.
Server
U1.2.1.
Decomposizione
U1.1. Azioni non autorizzate eseguite all'interno di una sessione di lavoro dell'utente:
U1.1.1. , installato dall'utente attaccato:
U1.1.1.1. I malintenzionati hanno agito autonomamente dal Client:
U1.1.1.1.1 I malintenzionati hanno utilizzato mezzi normali per accedere al sistema informatico:
U1.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):
U1.1.1.1.1.1.1. I malintenzionati hanno agito nei periodi in cui la sessione è attiva, i mezzi di input/output sono disponibili e l'utente non è presente.
U1.1.1.1.1.2. I malintenzionati hanno utilizzato strumenti di amministrazione remota (normali o forniti da codice malevolo) per controllare il Client:
U1.1.1.1.1.2.1. I malintenzionati hanno agito nei periodi in cui la sessione è attiva, i mezzi di input/output sono disponibili e l'utente non è presente.
U1.1.1.1.1.2.2. I malintenzionati hanno usato strumenti di amministrazione remota che operano in modo invisibile per l'utente attaccato.
U1.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:
U1.1.1.2.1. Link: .
U1.1.1.3. I malintenzionati hanno costretto l'utente a compiere le azioni da loro indicate, utilizzando metodi di ingegneria sociale.
U1.1.2 installato dai malintenzionati:
U1.1.2.1. I malintenzionati hanno agito dal Client (E):
U1.1.2.1.1. I malintenzionati hanno neutralizzato il sistema di controllo degli accessi del sistema informatico:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. I malintenzionati hanno utilizzato mezzi normali per accedere al sistema informatico
U1.1.2.2. I malintenzionati hanno agito da altri nodi della rete di trasmissione dei dati, da cui è possibile stabilire una connessione di rete con il Server (E):
U1.1.2.2.1. I malintenzionati hanno neutralizzato il sistema di controllo degli accessi del sistema informatico:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. I malintenzionati hanno usato mezzi non autorizzati per accedere al sistema informatico.
Spiegazioni U1.1.2.2.2.
I 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.
U1.2 Azioni non autorizzate eseguite al di fuori della sessione di lavoro dell'utente.
U1.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.
U2. Modifica non autorizzata delle informazioni protette durante il loro trattamento da parte del server del sistema informatico
Decomposizione
U2.1. I malintenzionati modificano informazioni protette utilizzando mezzi normali del sistema informatico e eseguendo ciò a nome di un utente legittimo.
U2.1.1. Link: .
U2.2. I malintenzionati modificano informazioni protette usando meccanismi di accesso ai dati non previsti dal funzionamento normale del sistema informatico.
U2.2.1. I malintenzionati modificano file contenenti informazioni protette:
U2.2.1.1. , utilizzando meccanismi di lavoro con i file forniti dal sistema operativo.
U2.2.1.2. tramite la provocazione del ripristino di file da un backup non autorizzato.
U2.2.2. I malintenzionati modificano informazioni protette memorizzate nel database (E):
U2.2.2.1. I malintenzionati neutralizzano il sistema di controllo degli accessi del DBMS:
U2.2.2.1.1. Link: .
U2.2.2.2. Gli aggressori modificano le informazioni utilizzando le interfacce standard dei DBMS per accedere ai dati.
U2.3. Gli aggressori modificano le informazioni protette attraverso la modifica non autorizzata degli algoritmi del software che le elabora.
U2.3.1. Il codice sorgente del software è soggetto a modifiche.
U2.3.1. Il codice macchina del software è soggetto a modifiche.
U2.4. Gli aggressori modificano le informazioni protette utilizzando vulnerabilità nel software del sistema informativo.
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):
U2.5.1. Riferimento: .
MODELLO TIPO DI MINACCIA. SISTEMA DI CONTROLLO DEGLI ACCESSI
Oggetto di protezione al quale si applica il modello di minaccia (scope)
L'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".
Per sistema di controllo degli accessi degli utenti in questo modello di minaccia si intende il componente del sistema informativo che svolge funzioni:
- Identificazione degli utenti.
- Autenticazione degli utenti.
- Autorizzazione degli utenti.
- Registrazione delle azioni degli utenti.
Minacce alla sicurezza di alto livello
Decomposizione
U1. Stabilire una sessione di lavoro non autorizzata a nome di un utente legittimo.
U2. Elevazione non autorizzata dei privilegi dell'utente nel sistema informativo.
U1. Stabilire una sessione di lavoro non autorizzata a nome di un utente legittimo
Spiegazioni
La decomposizione di questa minaccia, in generale, dipenderà dal tipo di sistemi di identificazione e autenticazione degli utenti utilizzati.
In questo modello verrà 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.
Decomposizione
U1.1. a causa della compromissione delle credenziali:
U1.1.1. Gli aggressori hanno compromesso le credenziali dell'utente durante il loro storage.
Spiegazioni U1.1.1.
Ad esempio, le credenziali potrebbero essere state scritte su un post-it attaccato al monitor.
U1.1.2. L'utente ha accidentalmente o intenzionalmente trasferito le credenziali di accesso agli aggressori.
U1.1.2.1. L'utente ha verbalizzato le credenziali ad alta voce durante l'immissione.
U1.1.2.2. L'utente ha deliberatamente trasferito le proprie credenziali:
U1.1.2.2.1. ai colleghi.
Spiegazioni U1.1.2.2.1.
Ad esempio, affinché possano sostituirlo durante un periodo di malattia.
U1.1.2.2.2. ai contraenti del datore di lavoro che lavorano sugli oggetti dell'infrastruttura informatica.
U1.1.2.2.3. a terzi.
Spiegazioni U1.1.2.2.3.
Uno, ma non l'unico, modo di attuare questa minaccia è l'uso da parte degli aggressori di metodi di ingegneria sociale.
U1.1.3. Gli aggressori hanno indovinato le credenziali attraverso tentativi sistematici:
U1.1.3.1. utilizzando i meccanismi di accesso standard.
U1.1.3.2. in base a codici precedentemente intercettati (ad esempio, hash delle password) per lo storage delle credenziali.
U1.1.4. Gli aggressori hanno utilizzato codice malevolo per intercettare le credenziali dell'utente.
U1.1.5. Gli aggressori hanno estratto le credenziali da una connessione di rete tra il Client e il Server:
U1.1.5.1. Riferimento: .
U1.1.6. Gli aggressori hanno estratto le credenziali dai log dei sistemi di monitoraggio delle attività:
U1.1.6.1. dai sistemi di video sorveglianza (nel caso in cui durante il lavoro venissero registrate le digitazioni sulla tastiera).
U1.1.6.2. dai sistemi di controllo delle azioni dei dipendenti al computer
Spiegazioni U1.1.6.2.
Un esempio di tale sistema è: .
U1.1.7. Gli aggressori hanno compromesso le credenziali dell'utente a causa di difetti nel processo di trasmissione.
Spiegazioni U1.1.7.
Ad esempio, la trasmissione di password in chiaro via e-mail.
U1.1.8. Gli aggressori hanno appreso le credenziali osservando la sessione di lavoro dell'utente tramite sistemi di amministrazione remota.
U1.1.9. Gli aggressori hanno estratto le credenziali a seguito della loro fuga tramite canali tecnici (TКУИ):
U1.1.9.1. Gli aggressori hanno osservato come l'utente immetteva le credenziali tramite la tastiera:
U1.1.9.1.1 Gli aggressori erano posti in prossimità dell'utente e vedevano l'immissione delle credenziali a occhio nudo.
Spiegazioni U1.1.9.1.1
Situazioni simili possono includere azioni di colleghi o un caso in cui la tastiera dell'utente è visibile ai visitatori dell'organizzazione.
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.
U1.1.9.2. Gli aggressori hanno estratto le credenziali dalle registrazioni delle comunicazioni tra la tastiera e l'unità centrale del computer se connesse tramite interfaccia radio (ad esempio, Bluetooth).
U1.1.9.3. Gli aggressori hanno intercettato le credenziali grazie alla loro fuga attraverso il canale delle emissioni elettromagnetiche indesiderate e delle influenze (PEMI).
Spiegazioni U1.1.9.3.
Esempi di attacco e .
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.
Spiegazioni U1.1.9.4.
Esempi .
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.
Spiegazioni U1.1.9.5.
U1.1.9.6. Gli aggressori hanno intercettato l'immissione delle credenziali dalla tastiera tramite l'analisi dei suoni generati dalle pressione dei tasti.
Esempio .
Spiegazioni U1.1.9.6.
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.
Esempio .
Spiegazioni U1.1.9.7.
U1.1.10. , precedentemente salvati sul Cliente.
Esempio .
Spiegazioni U1.1.10.
Ad esempio, un utente potrebbe aver salvato nel browser il login e la password per accedere a un determinato sito.
U1.1.11. Gli aggressori hanno compromesso le credenziali a causa di difetti nel processo di revoca degli accessi degli utenti.
Spiegazioni U1.1.11.
Ad esempio, dopo il licenziamento di un utente, i suoi account sono rimasti attivi.
U1.2. grazie all'uso di vulnerabilità nel sistema di controllo degli accessi.
U2. Elevazione non autorizzata dei privilegi dell'utente nel sistema informativo
U2.1 mediante l'introduzione di modifiche non autorizzate ai dati contenenti informazioni sui privilegi dell'utente.
Decomposizione
U2.2 grazie all'uso di vulnerabilità nel sistema di controllo degli accessi.
U2.3. a causa di difetti del processo di gestione degli accessi degli utenti.
Spiegazioni U2.3.
Esempio 1. All'utente è stato fornito un accesso maggiore di quanto fosse necessario per le sue esigenze lavorative.
Esempio 2. Dopo il trasferimento dell'utente a un altro incarico, i diritti di accesso precedentemente concessi non sono stati revocati.
MODELLO TIPOLOGICO DI MINACCIA. MODULO DI INTEGRAZIONE
Il modulo di integrazione è un insieme di oggetti dell'infrastruttura informatica destinati all'organizzazione dello scambio di informazioni tra i sistemi informativi.
Oggetto di protezione al quale si applica il modello di minaccia (scope)
Considerando il fatto che nelle reti aziendali non è sempre possibile separare in modo chiaro un sistema informativo da un altro, il modulo di integrazione può essere considerato anche come un legame tra i componenti all'interno di un unico sistema informativo.
Uno schema generico del modulo di integrazione appare come segue:
Architettura
"Server di scambio (СО)"
Descrizione degli elementi architettonici:
- – nodo / servizio / componente del sistema informativo che svolge la funzione di scambio dati con un altro sistema informativo. "Intermediario"
- – nodo / servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme. Esempi
"Intermediari" 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ò anche non contenere "Intermediari". "Software di elaborazione dati" - – insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati. Ad esempio, la conversione dei dati dal formato UFBDS al formato ABS, la modifica degli stati dei messaggi durante la trasmissione, ecc.
corrisponde 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. - «Connessione di rete» Esempi di moduli di integrazione
Schema 1. Integrazione ABS e ARM KBR tramite server di file esterno
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 (…SHARE) 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.
Dopo di ciò, l'impiegato autorizzato — utente dell'ARM KBR — cripta e firma il file ricevuto e lo invia nel sistema di pagamento della Banca di Russia.
Dopo di ciò, l'operatore autorizzato — utente del sistema KBR — cripta e firma il file ricevuto e lo invia al sistema di pagamento della Banca di Russia.
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.
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.
Corrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:
«Server di scambio lato ABS» – server ABS.
«Server di scambio lato ARM KBR» – computer ARM KBR.
– nodo / servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme. – server file esterno.
– insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati. – script di conversione.
Schema 2. Integrazione dell'ABS e dell'ARM KBR con la creazione di una cartella di rete condivisa con i pagamenti su ARM KBR
Tutto è simile allo Schema 1, ma il server file separato non è utilizzato; invece, una cartella di rete (…SHARE) con documenti di pagamento elettronico è collocata sul computer con l'ARM KBR. Lo script di conversione lavora anche su ARM KBR.
Corrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:
Simile allo Schema 1, ma – nodo / servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme. non è utilizzato.
Schema 3. Integrazione dell'ABS e dell'ARM KBR-N tramite IBM WebSphere MQ e firma dei documenti elettronici «lato ABS»
L'ABS opera su una piattaforma non supportata dalla crittografia SKZI SCAD Signature. La firma dei documenti elettronici in uscita è effettuata su un server di firma elettronica (Server EP). Questo stesso server verifica la firma elettronica dei documenti in arrivo dalla Banca di Russia.
L'ABS carica sul Server EP un file con i documenti di pagamento nel proprio formato.
Il Server EP, tramite uno script di conversione, trasforma il file in messaggi elettronici nel formato UFBBS, dopodiché i messaggi elettronici vengono firmati e inviati a IBM WebSphere MQ.
L'ARM KBR-N accede a IBM WebSphere MQ e riceve i messaggi di pagamento firmati, dopo di che un lavoratore autorizzato — utente dell'ARM KBR — li crittografa e li invia al sistema di pagamento della Banca di Russia.
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.
Il Server EP verifica la firma elettronica dei pagamenti ricevuti e li salva in un file nel formato ABS. Successivamente, un lavoratore autorizzato — utente dell'ABS — carica il file risultante nell'ABS secondo la procedura stabilita.
Corrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:
«Server di scambio lato ABS» – server ABS.
«Server di scambio lato ARM KBR» — computer ARM KBR.
– nodo / servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme. – Server EP e IBM WebSphere MQ.
– insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati. – script di conversione, SKZI SCAD Signature sul Server EP.
Schema 4. Integrazione del Server DBO e dell'ABS tramite API, fornita da un server di scambio dedicato
Consideriamo che in banca siano utilizzati diversi sistemi di banking online (DBO):
- «Internet Client-Bank» per persone fisiche (IKB FL);
- «Internet Client-Bank» per persone giuridiche (IKB UL).
Per 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 «ABS».
Esaminiamo ora il processo di interazione del sistema DBO IKB UL con l'ABS.
Il 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.
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.
Corrispondenza degli oggetti dello schema considerato agli elementi del modello del modulo di integrazione:
«Server di scambio lato DBO» – server DBO IKB UL.
«Server di scambio lato ABS» – server di scambio.
– nodo / servizio designato per organizzare l'interazione tra i sistemi informativi, ma non parte del loro insieme. – non presente.
– insieme di programmi che implementano protocolli di scambio di dati e conversione dei formati. – 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.
Minacce alla sicurezza di alto livello
Decomposizione
U1. Introduzione di informazioni false da parte degli aggressori tramite il modulo di integrazione.
U1. Introduzione di informazioni false da parte degli aggressori tramite il modulo di integrazione
Decomposizione
U1.1. Modifica non autorizzata di dati legittimi durante la loro trasmissione tramite connessioni di rete:
U1.1.1 Riferimento: .
U1.2. Trasmissione di dati falsi attraverso i canali di comunicazione a nome di un partecipante legittimo allo scambio:
U1.1.2 Riferimento: .
U1.3. Modifica non autorizzata di dati legittimi durante il loro trattamento sui server di scambio o dal mediatore:
U1.3.1. Riferimento: .
U1.4. Creazione su Server di scambio o Intermediario di dati falsi a nome di un partecipante legittimo allo scambio:
U1.4.1. Riferimento:
U1.5. Modifica non autorizzata dei dati durante il loro trattamento tramite software di elaborazione dati:
U1.5.1. mediante modifiche non autorizzate ai parametri (configurazione) del software di elaborazione dati da parte di malintenzionati.
U1.5.2. mediante modifiche non autorizzate ai file eseguibili del software di elaborazione dati da parte di malintenzionati.
U1.5.3. mediante controllo interattivo del funzionamento del software di elaborazione dati da parte di malintenzionati.
MODELLO TIPICO DI MINACCE. SISTEMA DI PROTEZIONE CRIPTOGRAFICA DELLE INFORMAZIONI
Oggetto di protezione al quale si applica il modello di minaccia (scope)
L'oggetto di protezione è un sistema di protezione crittografica delle informazioni, utilizzato per garantire la sicurezza del sistema informativo.
Architettura
La base di qualsiasi sistema informativo è il software applicativo (SW) che implementa la sua funzionalità target.
La protezione crittografica è generalmente realizzata mediante chiamate dalla logica aziendale del software applicativo a primitivi crittografici, che sono collocati in librerie specializzate - nuclei crittografici.
I primitivi crittografici includono funzioni crittografiche a basso livello, come:
- cifrare / decifrare un blocco di dati;
- creare / verificare una firma elettronica di un blocco di dati;
- calcolare la funzione hash di un blocco di dati;
- formare / caricare / scaricare informazioni chiave;
- ecc.
La logica aziendale del software applicativo implementa funzionalità di livello più alto mediante primitivi crittografici:
- cifrare un file con le chiavi dei destinatari scelti;
- stabilire una connessione di rete sicura;
- informare sui risultati della verifica della firma elettronica;
- ecc.
L'interazione tra la logica aziendale e il nucleo crittografico può avvenire:
- direttamente, tramite chiamate della logica aziendale a primitivi crittografici da librerie dinamiche del nucleo crittografico (.DLL – per Windows, .SO – per Linux);
- indirettamente, attraverso interfacce crittografiche – 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 è chiamato fornitore crittografico. L'uso di interfacce crittografiche consente al software applicativo di astrarsi da specifici algoritmi crittografici e di essere più flessibile.
Si possono identificare due schemi tipici di organizzazione del nucleo crittografico:
Schema 1 – Nucleo crittografico monolitico
Schema 2 – Nucleo crittografico separato
Gli 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.
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ò 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.
Per minimizzare il rischio, si utilizza lo schema 2, in cui il nucleo crittografico è diviso in due parti:
- 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à chiamata – «parte software».
- La seconda parte opera in un ambiente fidato su un dispositivo dedicato, che contiene un archivio delle chiavi chiuse. Questa parte sarà chiamata – «parte hardware».
La divisione del nucleo crittografico in parti software e hardware è piuttosto convenzionale. Sul mercato ci sono sistemi costruiti secondo lo schema con nucleo crittografico separato, ma la cui parte «hardware» è presentata sotto forma di immagine di una macchina virtuale — virtual HSM ().
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.
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.
Pertanto, nell'utilizzare uno schema con nucleo crittografico separato, l'interazione tra la parte software e quella hardware avviene secondo il seguente principio:
- 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.
- Le primitive crittografiche che utilizzano una chiave privata (creazione di firme elettroniche, decrittazione dei dati, ecc.) vengono eseguite dalla parte hardware.
Illustriamo il funzionamento del nucleo crittografico separato con l'esempio della creazione di una firma elettronica:
- 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.
- 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.
- La parte software restituisce il valore ottenuto all'applicativo.
Caratteristiche della verifica della correttezza della firma elettronica
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.
Fase 1. Controllo dell'integrità dei dati e della loro provenienza.
Contenuto della fase. 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 è stata generata dalla chiave privata corrispondente alla chiave pubblica di verifica della firma elettronica.
Luogo di esecuzione della fase: nucleo crittografico.
Fase 2. Controllo della fiducia nella chiave pubblica del firmatario e monitoraggio della validità della chiave privata della firma elettronica.
Contenuto della fase. 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à 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.
Luogo di esecuzione della fase: applicativo / nucleo crittografico.
Fase 3. Controllo dei poteri del firmatario.
Contenuto della fase. 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ò essere considerato legittimo.
Luogo di esecuzione della fase: applicativo.
Assunzioni fatte nella descrizione dell'oggetto della protezione
- I canali di trasferimento delle informazioni, ad eccezione dei canali di scambio delle chiavi, passano attraverso l'applicativo, l'API e il nucleo crittografico.
- Le informazioni sulla fiducia nelle chiavi pubbliche e/o nei certificati, così come le informazioni sui poteri dei proprietari delle chiavi pubbliche, sono memorizzate in un archivio di chiavi pubbliche.
- L'applicativo lavora con l'archivio delle chiavi pubbliche tramite il nucleo crittografico.
Esempio di un sistema informatico protetto tramite SKEI
Per illustrare gli schemi presentati in precedenza, consideriamo un sistema informatico ipotetico e evidenziamo tutti i suoi elementi strutturali.
Descrizione del sistema informatico
Due organizzazioni hanno deciso di implementare un flusso documentale elettronico giuridicamente significativo (EDE) tra di loro. A tal fine, hanno stipulato un accordo in cui è 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.
Descrizione dell'infrastruttura dell'organizzazione 1
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à di chiave estraibile. L'utente preparerà documenti elettronici localmente sul proprio computer, dopodiché li crittograferà, firmerà e invierà tramite un client di posta elettronica installato localmente.
Descrizione dell'infrastruttura dell'organizzazione 2
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.
A tale scopo, sono state organizzate due cartelle di rete sulla macchina virtuale dedicata: «…In», «…Out». I file ricevuti dai partner saranno automaticamente inseriti nella cartella di rete «…In» in chiaro. Questi file verranno decrittografati e verrà verificata la loro firma elettronica.
Nella cartella «…Out», l'utente posizionerà i file da crittografare, firmare e inviare al partner. Gli stessi file saranno preparati sul computer dell'utente.
Per 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à tramite script sviluppati dagli amministratori di sistema. L'esecuzione degli script sarà registrata in file di log.
Le chiavi crittografiche per la firma elettronica saranno memorizzate su un token con chiave non estraibile JaCarta GOST, che l'utente collegherà al proprio computer locale.
Il token sarà trasferito sulla macchina virtuale tramite strumenti software specializzati USB-over-IP, installati sia sul computer dell'utente che sulla macchina virtuale.
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.
Distinzione degli elementi strutturali del sistema crittografico
Sulla base della descrizione fornita dell'infrastruttura IT, identificheremo gli elementi strutturali del sistema crittografico e li registreremo in una tabella.
Tabella — Corrispondenza degli elementi del modello del sistema crittografico con gli elementi dei sistemi informativi
Nome dell'elemento
Organizzazione 1
Organizzazione 2
Software applicativo
Software CrittografiaARM
Software CrittografiaARM
Parte software del nucleo crittografico
Sistema crittografico CrittografiaPRO CSP
Sistema crittografico CrittografiaPRO CSP
Parte hardware del nucleo crittografico
è assente
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Magazzino chiavi pubbliche
Computer dell'utente:
— disco rigido;
— magazzino certificati standard di Windows.
Iperparavirtualizzatore:
— disco rigido.
Macchina virtuale:
— disco rigido;
— magazzino certificati standard di Windows.
Magazzino chiavi private
Token ruToken, operante in modalità di chiave estraibile
Token JaCarta GOST, operante in modalità di chiave non estraibile
Canale di scambio chiavi pubbliche
Computer dell'utente:
— memoria volatile.
Iperparavirtualizzatore:
— memoria volatile.
Macchina virtuale:
— memoria volatile.
Canale di scambio chiavi private
Computer dell'utente:
— bus USB;
— memoria volatile.
è assente
Canale di scambio tra i nuclei crittografici
non presente (assenza della parte hardware del nucleo crittografico)
Computer dell'utente:
— bus USB;
— memoria volatile;
— modulo software USB-over-IP;
— interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Iperparavirtualizzatore:
— memoria volatile;
— interfaccia di rete.
Macchina virtuale:
— interfaccia di rete;
— memoria volatile;
— modulo software USB-over-IP.
Canale di scambio dati pubblici
Computer dell'utente:
— dispositivi di input/output;
— memoria volatile;
— disco rigido.
Computer dell'utente:
— dispositivi di input/output;
— memoria volatile;
— disco rigido;
— interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Iperparavirtualizzatore:
— interfaccia di rete;
— memoria volatile;
— disco rigido.
Macchina virtuale:
— interfaccia di rete;
— memoria volatile;
— disco rigido.
Canale di scambio dati protetti
Internet.
Rete aziendale dell'organizzazione 1.
Computer dell'utente:
— disco rigido;
— memoria volatile;
— interfaccia di rete.
Internet.
Rete aziendale dell'organizzazione 2.
Iperparavirtualizzatore:
— interfaccia di rete;
— memoria volatile;
— disco rigido.
Macchina virtuale:
— interfaccia di rete;
— memoria volatile;
— disco rigido.
Canale di trasmissione del tempo
Computer dell'utente:
— dispositivi di input/output;
— memoria volatile;
— timer di sistema.
Internet.
Rete aziendale dell'organizzazione 2,
Iperparavirtualizzatore:
— interfaccia di rete;
— memoria volatile;
— timer di sistema.
Macchina virtuale:
— memoria volatile;
— timer di sistema.
Canale di trasmissione comandi di controllo
Computer dell'utente:
— dispositivi di input/output;
— memoria volatile.
(Interfaccia utente grafica del software CrittografiaARM)
Macchina virtuale:
— memoria volatile;
— disco rigido.
(Script di automazione)
Canale di ricezione dei risultati di elaborazione
Computer dell'utente:
— dispositivi di input/output;
— memoria volatile.
(Interfaccia utente grafica del software CrittografiaARM)
Macchina virtuale:
— memoria volatile;
— disco rigido.
(File di log dell'esecuzione degli script di automazione)
Minacce alla sicurezza di alto livello
Spiegazioni
Assunzioni fatte nella decomposizione delle minacce:
- Vengono utilizzati algoritmi crittografici robusti.
- Gli algoritmi crittografici sono utilizzati in modo sicuro nelle corrette modalità di funzionamento (ad esempio, non viene utilizzato per la crittografia di grandi volumi di dati, si tiene conto del carico consentito sulla chiave, ecc.).
- I malintenzionati conoscono tutti gli algoritmi, protocolli e chiavi pubbliche utilizzati.
- I malintenzionati possono leggere tutti i dati crittografati.
- I malintenzionati sono in grado di riprodurre qualsiasi elemento software nel sistema.
Decomposizione
A1. Compromissione delle chiavi crittografiche private.
A2. Crittografia di dati falsi a nome di un mittente legittimo.
A3. Decrittografia di dati crittografati da parte di individui non legittimati a ricevere i dati (malintenzionati).
U4. Creazione di una firma elettronica da parte di un firmatario legittimo utilizzando dati contraffatti.
U5. Ottenimento di un risultato positivo nella verifica della firma elettronica su dati contraffatti.
U6. Accettazione erronea di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso di documentazione elettronica.
U7. Consultazione non autorizzata di dati protetti durante il loro trattamento con sistemi di crittografia.
U1. Compromissione delle chiavi crittografiche private
U1.1. Ottenimento della chiave privata dal deposito delle chiavi private.
U1.2. Ottenimento della chiave privata da oggetti nell'ambiente operativo dei dispositivi crittografici, dove essa può trovarsi temporaneamente.
Spiegazioni U1.2.
Gli oggetti in cui può essere temporaneamente conservata la chiave privata includeranno:
- memoria RAM,
- file temporanei,
- file di paging,
- file di ibernazione,
- file di snapshot dello stato 'caldo' delle macchine virtuali, inclusi i file del contenuto della memoria RAM delle macchine virtuali messe in pausa.
U1.2.1. Estrazione di chiavi private dalla memoria RAM attiva congelando i moduli RAM, estraendoli e successivamente leggendo i dati (freeze attack).
Spiegazioni U1.2.1.
Esempio .
U1.3. Ottenimento della chiave privata tramite un canale di scambio di chiavi private.
Spiegazioni U1.3.
Un esempio di implementazione di questa minaccia sarà fornito .
U1.4. Modifica non autorizzata del nucleo crittografico, a seguito della quale le chiavi private diventano note a malintenzionati.
U1.5. Compromissione della chiave privata a causa dell'uso di canali tecnici di fuga di informazioni (TKUI).
Spiegazioni U1.5.
Esempio .
U1.6. Compromissione della chiave privata a causa dell'uso di apparecchiature tecniche speciali (STS) destinate alla raccolta clandestina di informazioni ('sistemi di ascolto').
U1.7. Compromissione delle chiavi private durante la loro conservazione al di fuori dei sistemi di crittografia.
Spiegazioni U1.7.
Ad esempio, un utente conserva i propri supporti crittografici nel cassetto della scrivania, da cui possono essere facilmente estratti da malintenzionati.
U2. Crittografia di dati contraffatti a nome di un mittente legittimo
Spiegazioni
Questa minaccia è considerata solo per schemi di crittografia dei dati con autenticazione del mittente. Esempi di tali schemi sono indicati nelle raccomandazioni per la standardizzazione . Per gli altri schemi crittografici questa minaccia non esiste, poiché la crittografia avviene con chiavi pubbliche del destinatario, le quali in generale sono conosciute dai malintenzionati.
Decomposizione
U2.1. Compromissione della chiave privata del mittente:
U2.1.1. Link: .
U2.2. Sostituzione dei dati di input nel canale di scambio di dati pubblici.
Note U2.2.
Esempi di implementazione di questa minaccia sono forniti di seguito e .
U3. Decrittazione dei dati crittografati da parte di persone non legittimate a ricevere tali dati (malintenzionati)
Decomposizione
U3.1. Compromissione delle chiavi private del destinatario dei dati crittografati.
U3.1.1 Riferimento: .
U3.2. Sostituzione dei dati crittografati nel canale di scambio di dati protetti.
U4. Creazione di una firma elettronica da parte di un firmatario legittimo utilizzando dati contraffatti.
Decomposizione
U4.1. Compromissione delle chiavi private della firma elettronica del firmatario legittimo.
U4.1.1 Riferimento: .
U4.2. Sostituzione dei dati firmati nel canale di scambio di dati pubblici.
Nota U4.2.
Esempi di implementazione di questa minaccia sono forniti di seguito e .
U5. Ottenimento di un risultato positivo nella verifica della firma elettronica su dati contraffatti.
Decomposizione
U5.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.
U5.2. I malintenzionati attaccano la fiducia verso i certificati di firma (SCENARIO — tutti gli elementi sono obbligatori):
U5.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ù simile possibile a quello del presunto mittente dei dati, il cui messaggio intendono falsificare.
U5.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à.
U5.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.
U5.3. Gli aggressori conducono un attacco utilizzando chiavi di firma elettronica scadute di un firmatario legittimo (SCENARIO — tutti gli elementi sono obbligatori):
U5.3.1. Gli aggressori compromettono chiavi private di firma elettronica scadute (non attualmente valide) di un mittente legittimo.
U5.3.2. Gli aggressori sostituiscono il tempo nel canale di trasmissione del tempo con un momento in cui le chiavi compromesse erano ancora valide.
U5.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.
U5.4. Gli aggressori conducono un attacco utilizzando chiavi di firma elettronica compromesse di un firmatario legittimo (SCENARIO — tutti gli elementi sono obbligatori):
U5.4.1. Gli aggressori fanno una copia del repository delle chiavi pubbliche.
U5.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.
U5.4.3. Gli aggressori sostituiscono il repository delle chiavi pubbliche con quello precedentemente copiato.
U5.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.
U5.5. a causa di errori nell'implementazione della seconda e della terza fase di verifica della firma elettronica:
Spiegazione U5.5.
Un esempio di implementazione di questa minaccia è fornito .
U5.5.1. La verifica della fiducia nel certificato della chiave di firma elettronica avviene solo sulla base della fiducia nel certificato con cui è stata firmata, senza controlli CRL o OCSP.
Spiegazione U5.5.1.
Esempio di implementazione .
U5.5.2. Nella costruzione della catena di fiducia del certificato non vengono analizzate le autorità dei certificati emittenti.
Spiegazione U5.5.2.
Esempio di attacco contro i certificati SSL/TLS.
Gli 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à, la verifica della catena di fiducia risulterà corretta, e quindi anche il certificato fraudolento risulterà valido.
U5.5.3. Nella costruzione della catena di fiducia del certificato non vengono controllati i certificati intermedi per la revoca.
U5.5.4. L'aggiornamento della CRL avviene con meno frequenza rispetto alla loro emissione da parte dell'autorità di certificazione.
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.
Spiegazione U5.5.5.
Nelle regolazioni della maggior parte degli AC, il tempo di revoca del certificato è considerato il tempo di emissione della CRL più vicina contenente informazioni sulla revoca del certificato.
U5.5.6. Quando si ricevono dati firmati, non viene verificata l'appartenenza del certificato al mittente.
Spiegazione U5.5.6.
Esempio 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.
Esempio 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.
U6. Accettazione erronea di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso di documentazione elettronica.
Decomposizione
U6.1. Il destinatario non individua la duplicazione dei documenti ricevuti.
Spiegazione U6.1.
Esempio 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.
U7. Accesso non autorizzato ai dati protetti durante l'elaborazione di SKZI
Decomposizione
U7.1. a causa di una perdita di informazioni tramite canali esterni (attacco laterale).
Spiegazione U7.1.
Esempio .
U7.2. a causa della neutralizzazione della protezione contro l'accesso non autorizzato alle informazioni trattate su SKZI:
U7.2.1. Sfruttamento di SKZI in violazione dei requisiti descritti nella documentazione su SKZI.
U7.2.2. , realizzato a causa di vulnerabilità in:
U7.2.2.1. mezzi di protezione contro l'accesso non autorizzato.
U7.2.2.2. lo stesso SKZI.
U7.2.2.3. ambiente di funzionamento dei mezzi crittografici.
Esempi di attacchi
Gli scenari di seguito riportati contengono intenzionalmente errori nell'organizzazione della sicurezza informatica e servono solo a illustrare possibili attacchi.
Scenario 1. Esempio di realizzazione delle minacce U2.2 e U4.2.
Descrizione dell'oggetto
Il 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à di chiave non estraibile.
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.
In questo caso, i canali di scambio di dati aperti e protetti includeranno: server di file, computer di lavoro del specialista e supporto rimovibile.
Attacco
Gli 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.
Scenario 2. Esempio di realizzazione delle minacce U2.2 e U4.2.
Descrizione dell'oggetto
Un computer con ARM KBR, SKAD Signature e un supporto chiave FKN vdToken connesso opera in un ambiente dedicato senza accesso da parte del personale.
Il specialista dei pagamenti si connette all'ARM KBR in modalità remota tramite protocollo RDP.
Attacco
Gli 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.
Scenario 3. Esempio di realizzazione della minaccia U1.3.
Descrizione dell'oggetto
Consideriamo 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à crittografica sia eseguita su una macchina virtuale separata — modulo di integrazione "ABS-KBR".
Come supporto chiave, si utilizza un token USB standard, che opera in modalità chiave estraibile. Quando si è tentato di connettere il supporto chiave all'iperconvergenza, si è scoperto che non c'erano porte USB disponibili nel sistema, quindi si è 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.
Attacco
Gli 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.
Scenario 4. Esempio di realizzazione della minaccia U5.5.
Descrizione dell'oggetto
Prendiamo in considerazione lo stesso schema del precedente scenario. Consideriamo che i messaggi elettronici provenienti da ARM KBR-N giungano nella cartella …SHAREIn, mentre quelli inviati a ARM KBR-N e successivamente nel sistema di pagamento della Banca di Russia finiscano in …SHAREout.
Inoltre, consideriamo che durante l'implementazione del modulo di integrazione, le liste dei certificati revocati vengano aggiornate solo durante il rinnovo delle chiavi crittografiche e che i messaggi elettronici pervenuti nella cartella …SHAREIn vengano verificati solo per il controllo dell'integrità e della fiducia nella chiave pubblica della firma elettronica.
Attacco
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é non viene effettuato alcun controllo per verificare che il bonifico sia effettivamente firmato dalla Banca di Russia, esso viene accettato per l'esecuzione.
Fonte: habr.com
