Collegamenti ad altre parti della ricerca
- (Sei qui)
Questo articolo conclude un ciclo di pubblicazioni dedicate alla sicurezza informatica dei pagamenti monetari bancari. Qui esamineremo i modelli standard delle minacce, a cui si è fatto riferimento in :
- .
- .
- .
- .
HABRO-WARNING !!! Caro lettori di Habrahabr, questo non è un post di intrattenimento.
Nascosti sotto il 'leggi di più' ci sono oltre 40 pagine di materiali destinati a aiutare nel lavoro o nello studio persone specializzate nel settore bancario o nella sicurezza informatica. Questi materiali sono il prodotto finale della ricerca e sono scritti in uno stile ufficiale e asciutto. In sostanza, sono bozze per documenti interni sulla sicurezza informatica.E infine, il tradizionale — «l'uso delle informazioni contenute nell'articolo per scopi illegali è perseguito dalla legge». Buona lettura!
Informazioni per i lettori che si avvicinano alla ricerca partendo da questa pubblicazione.
Di cosa tratta la ricerca
Stai leggendo una guida per il professionista responsabile della sicurezza informatica dei pagamenti in banca.
Logica di esposizione
Inizialmente, in e viene fornita una descrizione dell'oggetto della protezione. Poi in si racconta come costruire un sistema di protezione e si parla della necessità di formare un modello di minacce. In si discute quali modelli di minacce ci sono e come vengono formulati. In e viene fornita un'analisi degli attacchi reali. e contengono la descrizione del modello di minaccia, costruito tenendo conto delle informazioni di tutte le parti precedenti.
MODELLO TIPO DI MINACCE. COLLEGAMENTO DI RETE
Oggetto di protezione, per il quale si applica il modello di minaccia (scope)
L'oggetto di protezione sono i dati trasmessi attraverso un collegamento di rete, funzionante in reti di trasmissione dati basate sullo stack TCP/IP.
Architettura
Descrizione degli elementi architettonici:
- «Nodi terminali» — nodi che scambiano informazioni protette.
- «Nodi intermedi» — elementi della rete di trasmissione dati: router, switch, server di accesso, server proxy e altro hardware, attraverso i quali viene trasmesso il traffico del collegamento di rete. Di norma, un collegamento di rete può funzionare senza nodi intermedi (direttamente tra nodi terminali).
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. , effettuato su nodi terminali o intermedi:
U1.1.1. mediante lettura dei dati durante la loro presenza nelle memorie del nodo:
U1.1.1.1. nella memoria volatile.
Chiarimenti su U1.1.1.1.
Ad esempio, durante il trattamento dei dati da parte dello stack di rete del nodo.
U1.1.1.2. nella memoria non volatile.
Chiarimenti su U1.1.1.2.
Ad esempio, durante la memorizzazione dei dati trasmessi nella cache, nei file temporanei o nei file di paging.
U1.2. , effettuato su nodi esterni della rete di trasmissione dati:
U1.2.1. mediante 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 attivando la scheda di rete in modalità promiscuo (modalità promiscuo per adattatori cablati o in modalità monitor per adattatori wi-fi).
U1.2.2. mediante attacchi di tipo «uomo in mezzo (MiTM)», ma senza modifica dei dati trasmessi (eccetto i dati di comando dei protocolli di rete).
U1.2.2.1. Riferimento: .
U1.3. , effettuato a causa della fuoriuscita di informazioni attraverso canali tecnici (ТКУИ) da nodi fisici o linee di comunicazione.
U1.4. , effettuato tramite l'installazione di mezzi tecnici speciali (СТС) su nodi finali o intermedi, destinati alla cattura non ufficiale di informazioni.
U2. Modifica non autorizzata dei dati trasmessi
Decomposizione
U2.1. , effettuata su nodi finali o intermedi:
U2.1.1. attraverso la lettura e la modifica dei dati durante la loro permanenza nei dispositivi di memoria dei nodi:
U2.1.1.1. nella memoria volatile:
U2.1.1.2. nella memoria non volatile:
U2.2. , effettuata su nodi esterni della rete di trasmissione dati:
U2.2.1. tramite attacchi di tipo «uomo del mezzo (MiTM)» e reindirizzamento del traffico verso nodi malevoli:
U2.2.1.1. Collegamento fisico dell'attrezzatura di attacco al punto di interruzione della connessione di rete.
U2.2.1.2. Attacchi ai 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 rotte false da parte di attaccanti attraverso 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. Modifiche non autorizzate ai file locali di nomi dei nodi (hosts, lmhosts, ecc.)
U3. Violazione dei diritti d'autore sui dati trasmessi
Decomposizione
U3.1. Neutralizzazione dei meccanismi di determinazione dell'autore delle informazioni mediante l'indicazione di dati falsi sull'autore o sulla fonte delle informazioni:
U3.1.1. Modifica delle informazioni sull'autore contenute nelle informazioni trasmesse.
U3.1.1.1. Neutralizzazione della protezione crittografica dell'integrità e dell'autore delle informazioni trasmesse:
U3.1.1.1.1. Riferimento: .
U3.1.1.2. Neutralizzazione della protezione del diritto d'autore dei dati trasferiti, 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 TIPOLOGICO DI MINACCE. SISTEMA INFORMATIVO BASATO SU ARCHITETTURA CLIENT-SERVER
Oggetto di protezione, per il quale si applica il modello di minaccia (scope)
L'oggetto della protezione è il sistema informativo costruito su architettura client-server.
Architettura
Descrizione degli elementi architettonici:
- «Cliente» – il dispositivo sul quale funziona la parte client del sistema informativo.
- «Server» – il dispositivo sul quale funziona la parte server del sistema informativo.
- «Archivio dati» – parte dell'infrastruttura server del sistema informativo, destinata alla memorizzazione dei dati elaborati dal sistema informativo.
- «Connessione di rete» – canale di scambio di informazioni tra il Cliente e il Server, che attraversa la rete di trasmissione dati. Una descrizione più dettagliata del modello dell'elemento è fornita in .
Limitazioni
Nella modellazione dell'oggetto sono stati stabiliti i seguenti limiti:
- L'utente interagisce con il sistema informativo entro intervalli di tempo definiti, chiamati sessioni di lavoro.
- All'inizio di ogni sessione di lavoro avviene l'identificazione, l'autenticazione e l'autorizzazione dell'utente.
- Tutte le informazioni protette sono memorizzate nella parte server del sistema informativo.
Minacce alla sicurezza di alto livello
Decomposizione
U1. Azioni non autorizzate svolte da 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. Azioni non autorizzate svolte da malintenzionati a nome di un utente legittimo
Chiarimenti
Di solito, nei sistemi informativi, la correlazione delle azioni con l'utente che le ha eseguite viene effettuata tramite:
- registri di sistema (logs).
- attributi speciali degli oggetti dati che contengono informazioni sull'utente che li ha creati o modificati.
In relazione alla sessione di lavoro, questa minaccia può essere decomposta in:
- eseguite nell'ambito della sessione di lavoro dell'utente.
- eseguite al di fuori della sessione di lavoro dell'utente.
La sessione di lavoro dell'utente può essere iniziata da:
- Dal medesimo utente.
- Da malintenzionati.
In questa fase, la decomposizione intermedia di questa minaccia apparirà come segue:
U1.1. Azioni non autorizzate eseguite durante la 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 sui quali possono agire i malintenzionati, 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 durante la sessione di lavoro dell'utente:
U1.1.1. , installato dall'utente attaccato:
U1.1.1.1. I malintenzionati hanno agito autonomamente dal Cliente:
U1.1.1.1.1 I malintenzionati hanno utilizzato strumenti standard di accesso al sistema informatico:
U1.1.1.1.1.1. I malintenzionati hanno utilizzato mezzi fisici di input/output del Cliente (tastiera, mouse, monitor o schermo touch di un dispositivo mobile):
U1.1.1.1.1.1.1. I malintenzionati hanno agito in periodi di tempo 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 (standard o forniti da codice dannoso) per controllare il Cliente:
U1.1.1.1.1.2.1. I malintenzionati hanno agito in periodi di tempo 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 utilizzato strumenti di amministrazione remota la cui operatività è invisibile per l'utente attaccato.
U1.1.1.2. I malintenzionati hanno sostituito i dati nella connessione di rete tra il Cliente e il Server, modificandoli in modo che venissero percepiti come azioni di un utente legittimo:
U1.1.1.2.1. Link: .
U1.1.1.3. I malintenzionati hanno costretto l'utente a eseguire le azioni da loro indicate, utilizzando tecniche di ingegneria sociale.
U1.1.2 installato dai malintenzionati:
U1.1.2.1. I malintenzionati hanno agito dal Cliente (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. Gli aggressori hanno utilizzato strumenti di accesso standard del sistema informativo
U1.1.2.2. Gli aggressori hanno agito da altri nodi della rete di trasmissione dati, da cui è possibile stabilire una connessione di rete con il Server (E):
U1.1.2.2.1. Gli aggressori hanno neutralizzato il sistema di controllo degli accessi del sistema informativo:
U1.1.2.2.1.1. Riferimento: .
U1.1.2.2.2. Gli aggressori hanno utilizzato strumenti di accesso non standard del sistema informativo.
Spiegazioni U1.1.2.2.2.
Gli aggressori potrebbero aver installato un client standard del sistema informativo su un nodo esterno oppure potrebbero aver utilizzato software non standard che implementa protocolli di scambio standard tra Cliente e Server.
U1.2 Le azioni non autorizzate sono state effettuate al di fuori della sessione di lavoro dell'utente.
U1.2.1 Gli aggressori hanno compiuto azioni non autorizzate e poi hanno apportato modifiche non autorizzate ai registri di lavoro del sistema informativo o a attributi speciali degli oggetti dati, indicando che le azioni da loro effettuate sono state compiute da un utente legittimo.
U2. Modifica non autorizzata di informazioni protette durante la loro elaborazione da parte della parte server del sistema informativo
Decomposizione
U2.1. Gli aggressori modificano informazioni protette utilizzando strumenti standard del sistema informativo, operando a nome di un utente legittimo.
U2.1.1. Riferimento: .
U2.2. Gli aggressori modificano informazioni protette utilizzando meccanismi di accesso ai dati non previsti dal funzionamento standard del sistema informativo.
U2.2.1. Gli aggressori modificano file contenenti informazioni protette:
U2.2.1.1. , utilizzando meccanismi di gestione dei file forniti dal sistema operativo.
U2.2.1.2. provocando il ripristino di file da un backup modificato senza autorizzazione.
U2.2.2. Gli aggressori modificano informazioni protette conservate nel database (E):
U2.2.2.1. Gli aggressori 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 interfacce standard del DBMS per accedere ai dati.
U2.3. Gli aggressori modificano informazioni protette attraverso la modifica non autorizzata degli algoritmi di funzionamento 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 informazioni protette sfruttando vulnerabilità nel software del sistema informatico.
U2.5. Gli aggressori modificano informazioni protette durante il loro trasferimento tra i componenti della parte server del sistema informatico (ad esempio, server di database e server delle applicazioni):
U2.5.1. Link: .
MODELLO TIPO DI MINACCE. SISTEMA DI CONTROLLO DEGLI ACCESSI
Oggetto di protezione, per il quale si applica il modello di minaccia (scope)
L'oggetto di protezione per il quale si applica questo modello di minacce corrisponde all'oggetto di protezione del modello di minacce: «Modello tipo di minacce. Sistema informatico basato sull'architettura client-server».
Con sistema di controllo degli accessi degli utenti in questo modello di minacce si intende un componente del sistema informatico che realizza le 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. Aumento non autorizzato dei privilegi degli utenti nel sistema informatico.
U1. Stabilire una sessione di lavoro non autorizzata a nome di un utente legittimo
Chiarimenti
La decomposizione di questa minaccia, in generale, dipenderà dal tipo di sistemi di identificazione e autenticazione degli utenti utilizzati.
In questo modello considereremo solo un sistema di identificazione e autenticazione degli utenti che utilizza un nome utente e una password testuali. In questo caso, considereremo che il nome utente sia un'informazione di pubblico accesso, nota agli aggressori.
Decomposizione
U1.1. a causa della compromissione dei dati di accesso:
U1.1.1. Gli aggressori hanno compromesso i dati di accesso dell'utente durante la loro conservazione.
Spiegazioni U1.1.1.
Ad esempio, i dati di accesso potrebbero essere stati scritti su un adesivo attaccato al monitor.
U1.1.2. L'utente ha accidentalmente o con malizia trasmesso i dati di accesso ai malintenzionati.
U1.1.2.1. L'utente ha pronunciato le credenziali ad alta voce durante l'inserimento.
U1.1.2.2. L'utente ha intenzionalmente trasmesso le proprie credenziali:
U1.1.2.2.1. ai colleghi di lavoro.
Chiarimenti 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 svolgono lavori sugli oggetti dell'infrastruttura informatica.
U1.1.2.2.3. a terze parti.
Chiarimenti U1.1.2.2.3.
Una delle, ma non l'unica, modalità di attuazione di questa minaccia è l'uso da parte dei malintenzionati di metodi di ingegneria sociale.
U1.1.3. I malintenzionati hanno indovinato le credenziali mediante tentativi:
U1.1.3.1. utilizzando meccanismi di accesso standard.
U1.1.3.2. mediante codici precedentemente intercettati (ad esempio, hash delle password) per la memorizzazione delle credenziali.
U1.1.4. I malintenzionati hanno utilizzato codice malevolo per intercettare le credenziali dell'utente.
U1.1.5. I malintenzionati hanno estratto le credenziali da una connessione di rete tra il Client e il Server:
U1.1.5.1. Riferimento: .
U1.1.6. I malintenzionati hanno estratto le credenziali da registrazioni di sistemi di monitoraggio delle attività:
U1.1.6.1. sistemi di videosorveglianza (nel caso in cui, durante il lavoro, fosse registrata la digitazione sulla tastiera).
U1.1.6.2. sistemi di controllo delle azioni dei dipendenti al computer
Chiarimenti U1.1.6.2.
Un esempio di tale sistema è — .
U1.1.7. I malintenzionati hanno compromesso le credenziali dell'utente a causa di difetti nel processo di trasmissione.
Chiarimenti U1.1.7.
Ad esempio, la trasmissione delle password in chiaro tramite email.
U1.1.8. I malintenzionati hanno appreso le credenziali osservando la sessione di lavoro dell'utente tramite sistemi di amministrazione remota.
U1.1.9. I malintenzionati hanno estratto le credenziali a seguito della loro fuga tramite canali tecnici (TCUI):
U1.1.9.1. I malintenzionati hanno spiateo come l'utente inserisce le credenziali dalla tastiera:
U1.1.9.1.1 I malintenzionati si trovavano a stretto contatto con l'utente e vedevano l'inserimento delle credenziali con i propri occhi.
Chiarimenti U1.1.9.1.1
A casi come questi si possono riferire le azioni dei colleghi di lavoro o la situazione in cui la tastiera dell'utente è visibile ai visitatori dell'organizzazione.
U1.1.9.1.2 Gli aggressori hanno utilizzato dispositivi tecnici aggiuntivi, come binocoli o droni, e hanno visto l'immissione dei dati di accesso attraverso una finestra.
U1.1.9.2. Gli aggressori hanno estratto i dati di accesso dalle comunicazioni radio tra la tastiera e l'unità centrale del computer, nel caso in cui fossero collegati tramite interfaccia radio (ad esempio, Bluetooth).
U1.1.9.3. Gli aggressori hanno intercettato i dati di accesso a causa della loro fuoriuscita tramite canali di radiazioni elettromagnetiche spurie e interferenze (PEMI).
Chiarimenti U1.1.9.3.
Esempi di attacco e .
U1.1.9.4. L'aggressore ha intercettato l'immissione dei dati di accesso dalla tastiera utilizzando dispositivi tecnici speciali (STS) destinati a raccogliere informazioni in modo occulto.
Chiarimenti U1.1.9.4.
Esempi .
U1.1.9.5. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera tramite
l'analisi del segnale Wi-Fi, modulato dal processo di pressione dei tasti da parte dell'utente.
Chiarimenti U1.1.9.5.
Esempio .
U1.1.9.6. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera attraverso l'analisi dei suoni di pressione dei tasti.
Chiarimenti U1.1.9.6.
Esempio .
U1.1.9.7. Gli aggressori hanno intercettato l'immissione dei dati di accesso dalla tastiera di un dispositivo mobile analizzando i dati dell'accelerometro.
Chiarimenti U1.1.9.7.
Esempio .
U1.1.10. , precedentemente salvati sul Client.
Chiarimenti U1.1.10.
Ad esempio, l'utente poteva salvare nel browser nome utente e password per accedere a un determinato sito web.
U1.1.11. Gli aggressori hanno compromesso i dati di accesso a causa di carenze nel processo di revoca degli accessi degli utenti.
Chiarimenti U1.1.11.
Ad esempio, dopo il licenziamento dell'utente, i suoi account sono rimasti attivi.
U1.2. a causa dell'utilizzo di vulnerabilità nel sistema di controllo degli accessi.
U2. Elevazione non autorizzata dei privilegi dell'utente nel sistema informatico
Decomposizione
U2.1 mediante modifiche non autorizzate ai dati che contengono informazioni sui privilegi dell'utente.
U2.2 a causa dell'utilizzo di vulnerabilità nel sistema di controllo degli accessi.
U2.3. a causa di carenze nel processo di gestione degli accessi degli utenti.
Spiegazione U2.3.
Esempio 1. All'utente è stato fornito un accesso maggiore rispetto a quello necessario per le sue esigenze lavorative.
Esempio 2. Dopo aver trasferito l'utente in un'altra posizione, i diritti di accesso precedentemente concessi non sono stati revocati.
MODULO STANDARD DI MINACCIA. MODULO DI INTEGRAZIONE
Oggetto di protezione, per il quale si applica il modello di minaccia (scope)
Il modulo di integrazione è un insieme di oggetti dell'infrastruttura informatica, destinati a organizzare lo scambio di informazioni tra i sistemi informativi.
Tenendo conto del fatto che nelle reti aziendali non è sempre possibile separare inequivocabilmente un sistema informativo da un altro, il modulo di integrazione può essere considerato anche come un collegamento tra i componenti all'interno di un singolo sistema informativo.
Architettura
Schema generale del modulo di integrazione:
Descrizione degli elementi architettonici:
- «Server di scambio (SS)» – nodo / servizio / componente del sistema informativo, che svolge la funzione di scambio dati con un altro sistema informativo.
- «Intermediario» – nodo / servizio, destinato a organizzare l'interazione tra i sistemi informativi, ma non facente parte di essi.
Esempi di «Intermediari» possono essere i servizi di posta elettronica, i bus di servizio aziendali (enterprise service bus / architettura SoA), i server di file di terzi, ecc. In generale, il modulo di integrazione può anche non contenere «Intermediari». - «SOFTWARE DI ELABORAZIONE DATI» – insieme di programmi che implementano i protocolli di scambio dati e la conversione dei formati.
Ad esempio, la conversione dei dati dal formato UFEBS al formato ABS, la modifica degli stati dei messaggi durante la trasmissione, ecc. - «Connessione di rete» corrisponde all'oggetto descritto nel modello standard di minacce «Connessione di rete». Potrebbe non esserci alcuni dei collegamenti di rete rappresentati nello schema sopra.
Esempi di moduli di integrazione
Schema 1. Integrazione ABS e ARM KBR tramite server di file di terzi
Per eseguire i pagamenti, l'impiegato autorizzato della banca estrae i documenti di pagamento elettronici dall'ABS e li salva in un file (di formato proprietario, ad esempio SQL dump) in una cartella di rete (…SHARE) del server di file. Successivamente, questo file viene convertito tramite uno script di conversione in un insieme di file nel formato UFEBS, che poi legge l'ARM KBR.
Dopo di ciò, l'operatore autorizzato — utente dell'ARM 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 decrittazione e verifica della firma elettronica, dopodiché li registra come un insieme di file nel formato UFBBS sul server file. Prima dell'importazione dei documenti di pagamento nell'ABS, vengono convertiti tramite uno script di conversione dal formato UFBBS al formato ABS.
Consideriamo che in questo schema l'ABS funzioni su un singolo server fisico, l'ARM KBR funzioni su un computer dedicato e lo script di conversione lavori su un server file.
Corrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:
«Server di scambio dall'ABS» – server ABS.
«Server di scambio dall'ARM KBR» – computer ARM KBR.
«Intermediario» – server file esterno.
«SOFTWARE DI ELABORAZIONE DATI» – script di conversione.
Schema 2. Integrazione dell'ABS e dell'ARM KBR tramite la creazione di una cartella di rete condivisa con i pagamenti sull'ARM KBR
Tutto come nello Schema 1, ma non viene utilizzato un server file separato; invece, la cartella di rete (…SHARE) con i documenti di pagamento elettronici è collocata sul computer con l'ARM KBR. Anche lo script di conversione funziona sull'ARM KBR.
Corrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:
Analogamente allo Schema 1, ma «Intermediario» non viene 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 dal sistema di protezione delle informazioni SKAD Signature. La firma dei documenti elettronici in uscita viene effettuata su un server speciale di firma elettronica (Server EP). Questo stesso server verifica la firma elettronica sui documenti in arrivo dalla Banca di Russia.
L'ABS scarica sul Server EP un file con i documenti di pagamento nel proprio formato.
Il Server EP, tramite lo script di conversione, converte 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 da lì i messaggi di pagamento firmati, dopo di ché l'operatore autorizzato — utente dell'ARM KBR — li cripta e li invia al sistema di pagamento della Banca di Russia.
Al ricevimento dei pagamenti dalla Banca di Russia, l'ARM KBR-N li decifra e verifica la firma elettronica. I pagamenti elaborati con successo, sotto forma di messaggi elettronici decifrati e firmati nel formato UFEB, vengono inviati a IBM WebSphere MQ, da dove vengono ricevuti dal Server EP.
Il Server EP verifica la firma elettronica dei pagamenti ricevuti e li salva in un file nel formato ABS. Successivamente, un lavoratore autorizzato — utente ABS — carica il file risultante nell'ABS secondo la procedura stabilita.
Corrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:
«Server di scambio dal lato ABS» – server ABS.
«Server di scambio dal lato ARM KBR» — computer ARM KBR.
«Intermediario» – Server EP e IBM WebSphere MQ.
«SOFTWARE DI ELABORAZIONE DATI» – script convertitore, SCZI SKAD Firma sul Server EP.
Schema 4. Integrazione del Server DBO e ABS tramite API fornito da un server di scambio dedicato
Supponiamo che la banca utilizzi diversi sistemi di banking a distanza (DBO):
- «Internet Client-Bank» per le persone fisiche (ICB PF);
- «Internet Client-Bank» per le persone giuridiche (ICB PJ).
Al fine di garantire la sicurezza informatica, tutta l'interazione tra ABS e i sistemi DBO avviene tramite un server di scambio dedicato, operante all'interno del sistema informativo «ABS».
Successivamente, esaminiamo il processo di interazione del sistema DBO ICB PJ con ABS.
Il Server DBO, ricevuto dal cliente l'ordine di pagamento debitamente certificato, deve crearne il corrispondente documento in ABS. A tal fine, invia le informazioni al server di scambio tramite API, che a sua volta inserisce i dati nell'ABS.
In caso di modifica dei saldi sul conto del cliente, ABS genera notifiche elettroniche che vengono trasmesse al server DBO tramite il server di scambio.
Corrispondenza degli oggetti dello schema esaminato agli elementi del modello del modulo di integrazione:
«Server di scambio dal lato DBO» – server DBO ICB PJ.
«Server di scambio dal lato ABS» – server di scambio.
«Intermediario» – assente.
«SOFTWARE DI ELABORAZIONE DATI» – componenti del Server DBO responsabili dell'utilizzo dell'API del server di scambio, componenti del server di scambio responsabili dell'utilizzo dell'API ABS.
Minacce alla sicurezza di alto livello
Decomposizione
U1. Introduzione di informazioni false da parte di attaccanti tramite il modulo di integrazione.
U1. Introduzione di informazioni false da parte di attaccanti 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 tramite canali di comunicazione a nome di un legittimo partecipante allo scambio:
U1.1.2 Riferimento: .
U1.3. Modifica non autorizzata di dati legittimi durante la loro elaborazione sui server di scambio o sul Mediatore:
U1.3.1. Riferimento: .
U1.4. Creazione di dati falsi sui server di scambio o sul Mediatore a nome di un partecipante legittimo allo scambio:
U1.4.1. Riferimento:
U1.5. Modifica non autorizzata di dati durante la loro elaborazione tramite software di elaborazione dati:
U1.5.1. a causa dell'introduzione di modifiche non autorizzate da parte di malintenzionati nelle impostazioni (configurazione) del software di elaborazione dati.
U1.5.2. a causa dell'introduzione di modifiche non autorizzate da parte di malintenzionati nei file eseguibili del software di elaborazione dati.
U1.5.3. a causa del controllo interattivo da parte di malintenzionati del funzionamento del software di elaborazione dati.
MODELLO STANDARD DI MINACCE. SISTEMA DI PROTEZIONE CRIPTOGRAFICA DELLE INFORMAZIONI
Oggetto di protezione, per il quale si applica il modello di minaccia (scope)
Oggetto della protezione è il sistema di protezione criptografica delle informazioni, utilizzato per garantire la sicurezza del sistema informativo.
Architettura
La base di qualsiasi sistema informativo è il software applicativo (SW), che realizza le sue funzionalità mirate.
La protezione crittografica viene solitamente attuata tramite la chiamata dalla logica di business del software applicativo a primitive crittografiche, che sono collocate in librerie specializzate - core crittografici.
Le primitive crittografiche 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 di business del software applicativo realizza tramite primitive crittografiche funzionalità a livello superiore:
- cifrare un file con le chiavi dei destinatari selezionati;
- impostare una connessione di rete sicura;
- informare sui risultati della verifica della firma elettronica;
- ecc.
L'interazione tra la logica di business e il nucleo crittografico può avvenire:
- direttamente, attraverso la chiamata da parte della logica di business ai primitivi crittografici da librerie dinamiche del nucleo crittografico (.DLL – per Windows, .SO – per Linux);
- indirettamente, tramite interfacce crittografiche - wrapper, ad esempio, MS Crypto API, Java Cryptography Architecture, PKCS#11, ecc. In questo caso, la logica di business si rivolge all'interfaccia crittografica, la quale traduce la chiamata al corrispondente nucleo crittografico, che in tal caso è chiamato fornitore di criptografia. L'uso delle interfacce crittografiche consente al software applicativo di astrarsi dagli algoritmi crittografici specifici 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 negli schemi presentati possono essere sia moduli software separati, che operano su un singolo computer, sia servizi di rete che interagiscono all'interno di una rete di calcolo.
Nell'uso di sistemi costruiti secondo lo schema 1, il software applicativo e il nucleo crittografico operano all'interno di un'unica ambiente di funzionamento del mezzo crittografico (SFC), ad esempio, sullo stesso computer, sotto la gestione dello stesso sistema operativo. L'utente del sistema, di solito, può avviare all'interno di questo stesso ambiente di funzionamento anche altri programmi, inclusi quelli contenenti codice dannoso. In tali condizioni esiste un serio rischio di perdita delle chiavi crittografiche riservate.
Per minimizzare il rischio si applica 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 il rischio di infezione da codice dannoso. Chiamiamo questa parte "parte software".
- La seconda parte opera in un ambiente fidato su un dispositivo dedicato, che contiene al suo interno un deposito di chiavi riservate. Chiamiamo questa parte "parte hardware".
La separazione del nucleo crittografico in parti software e hardware è piuttosto convenzionale. Nel mercato ci sono sistemi costruiti secondo uno schema con nucleo crittografico separato, ma la parte "hardware" è rappresentata da un'immagine di macchina virtuale — virtual HSM ().
L'interazione tra le due parti del nucleo crittografico avviene in modo tale che le chiavi crittografiche private non vengono mai trasferite nella parte software e, di conseguenza, non possono essere rubate mediante codice dannoso.
L'interfaccia di interazione (API) e il set di primitivi crittografici forniti al software applicativo dal nucleo crittografico sono identici in entrambi i casi. La differenza risiede nel modo in cui vengono implementati.
Pertanto, nell'utilizzare uno schema con nucleo crittografico separato, l'interazione tra la parte software e hardware avviene secondo il seguente principio:
- I primitivi crittografici che non richiedono l'uso di una chiave privata (ad esempio, il calcolo della funzione hash, la verifica della firma elettronica, ecc.) sono eseguiti dalla parte software.
- I primitivi crittografici che utilizzano una chiave privata (creazione di una firma elettronica, decrittazione dei dati, ecc.) sono eseguiti dalla parte hardware.
Illustriamo il funzionamento del nucleo crittografico separato con un esempio di creazione di una firma elettronica:
- La parte software calcola la funzione hash dei dati da firmare e trasmette questo valore alla parte hardware tramite il canale di scambio tra i nuclei crittografici.
- La parte hardware, utilizzando la chiave privata e l'hash, genera il valore della firma elettronica e lo trasmette alla parte software tramite il canale di scambio.
- La parte software restituisce il valore ottenuto al software 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 della verifica della firma elettronica viene raggiunto solo al termine di tutte le fasi di verifica.
Fase 1. Controllo dell'integrità dei dati e dell'autenticità dei dati.
Contenuto della fase. Viene effettuato un controllo della firma elettronica dei dati secondo il corrispondente algoritmo crittografico. Il superamento con successo di questa fase indica che i dati non sono stati modificati dal momento della loro firma, e inoltre che la firma è stata eseguita con una chiave privata corrispondente alla chiave pubblica per il controllo della firma elettronica.
Luogo di esecuzione della fase: nucleo crittografico.
Fase 2. Controllo della fiducia nella chiave pubblica del firmatario e verifica della validità della chiave privata di firma elettronica.
Contenuto della fase. La fase è composta da due sottofasi intermedie. Nella prima si stabilisce se la chiave pubblica per il controllo della firma elettronica fosse fidata al momento della firma dei dati. Nella seconda si verifica se la chiave privata di firma elettronica fosse valida al momento della firma dei dati. In linea generale, le scadenze di queste chiavi potrebbero non coincidere (ad esempio, per i certificati qualificati delle chiavi di controllo della firma elettronica). I metodi per stabilire la fiducia nella chiave pubblica del firmatario sono definiti dalle regole del documento elettronico adottate dalle parti coinvolte.
Luogo di esecuzione della fase: software applicativo / nucleo crittografico.
Fase 3. Controllo dei poteri del firmatario.
Contenuto della fase. In conformità alle regole stabilite per il commercio elettronico, si verifica se il firmatario avesse il diritto di attestare i dati protetti. Ad esempio, consideriamo una situazione di violazione dei poteri. Supponiamo che ci sia un’organizzazione in cui tutti i dipendenti hanno una firma elettronica. Un ordine del dirigente entra nel sistema interno di gestione dei documenti elettronici, ma è firmato con la firma elettronica del responsabile del magazzino. Di conseguenza, tale documento non può essere considerato legittimo.
Luogo di esecuzione della fase: software applicativo.
Assunzioni fatte nella descrizione dell'oggetto di protezione
- I canali di trasmissione delle informazioni, ad eccezione dei canali per lo scambio di chiavi, passano anche attraverso il software applicativo, l'API e il nucleo crittografico.
- Le informazioni sulla fiducia nelle chiavi pubbliche e/o nei certificati, così come le informazioni sui poteri dei detentori delle chiavi pubbliche, sono collocate nel deposito delle chiavi pubbliche.
- Il software applicativo interagisce con il deposito delle chiavi pubbliche attraverso il nucleo crittografico.
Esempio di un sistema informativo protetto mediante SKZI
Per illustrare gli schemi precedentemente presentati, consideriamo un ipotetico sistema informativo e evidenziamo tutti gli elementi strutturali in esso.
Descrizione del sistema informativo
Due organizzazioni hanno deciso di implementare un flusso documentale elettronico (FDE) legalmente valido tra di loro. A tal fine, hanno stipulato un accordo in cui è stato specificato che i documenti saranno trasmessi tramite email, e dovranno essere crittografati e firmati con una firma elettronica qualificata. Come strumenti per la creazione e l'elaborazione dei documenti, saranno utilizzati programmi per ufficio del pacchetto Microsoft Office 2016, mentre come mezzi di protezione crittografica saranno utilizzati il sistema di crittografia KryptoPRO e il software di crittografia KryptoARM.
Descrizione dell'infrastruttura dell'organizzazione 1
L'organizzazione 1 ha deciso di installare KryptoPRO e KryptoARM su un computer client fisico. Le chiavi di crittografia e di firma elettronica saranno conservate su un dispositivo di chiave ruToken, che opera in modalità chiave estraibile. L'utente preparerà i documenti elettronici localmente sul proprio computer, per poi crittografarli, firmarli e inviarli tramite un client di posta installato localmente.
Descrizione dell'infrastruttura dell'organizzazione 2
L'organizzazione 2 ha deciso di esternalizzare le funzioni di crittografia e firma elettronica su una macchina virtuale dedicata. Tutte le operazioni crittografiche saranno eseguite in modo automatico.
A tal fine, sono state organizzate due cartelle di rete sulla macchina virtuale dedicata: «…In», «…Out». Nella cartella di rete «…In» saranno automaticamente posizionati i file ricevuti dal contraente in chiaro. Questi file saranno decrittografati e verrà verificata la firma elettronica su di essi.
Nella cartella «…Out», l'utente posizionerà i file che devono essere crittografati, firmati e inviati al contraente. Gli stessi file saranno preparati dall'utente sul proprio computer client.
Per l'esecuzione delle funzioni di crittografia e firma elettronica, sulla macchina virtuale sono stati installati KryptoPRO, KryptoARM e un client di posta. La gestione automatica di tutti gli elementi della macchina virtuale sarà effettuata tramite script sviluppati dagli amministratori di sistema. Il funzionamento degli script sarà registrato in file di log.
Le chiavi crittografiche della firma elettronica saranno memorizzate su un token con chiave non rimovibile JaCarta ГОСТ, che l'utente collegherà al proprio computer locale.
Il token sarà passato a una macchina virtuale tramite software specializzati USB-over-IP installati sul posto di lavoro dell'utente e sulla macchina virtuale.
L'orologio di sistema sul posto di lavoro dell'utente nell'organizzazione 1 sarà regolato manualmente. L'orologio di sistema della macchina virtuale nell'organizzazione 2 sarà sincronizzato con l'orologio di sistema del hypervisor, che a sua volta sarà sincronizzato tramite Internet con server pubblici di riferimento temporale.
Identificazione degli elementi strutturali del SKZI
In base alla descrizione fornita dell'infrastruttura IT, identificheremo gli elementi strutturali del SKZI e li registreremo in una tabella.
Tabella — Corrispondenza degli elementi del modello SKZI con gli elementi dei sistemi informativi
Nome dell'elemento
Organizzazione 1
Organizzazione 2
Software applicativo
Software CryptoARM
Software CryptoARM
Parte software del nucleo crittografico
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP
Parte hardware del nucleo crittografico
è assente
JaCarta ГОСТ
API
MS CryptoAPI
MS CryptoAPI
Archivio delle chiavi pubbliche
Posto di lavoro dell'utente:
— disco rigido;
— archivio standard dei certificati di Windows.
Hypervisor:
— disco rigido.
Macchina virtuale:
— disco rigido;
— archivio standard dei certificati di Windows.
Archivio delle chiavi private
Dispositivo di crittografia ruToken, operante in modalità chiave rimovibile
Dispositivo di crittografia JaCarta ГОСТ, operante in modalità chiave non rimovibile
Canale di scambio delle chiavi pubbliche
Posto di lavoro dell'utente:
— memoria RAM.
Hypervisor:
— memoria RAM.
Macchina virtuale:
— memoria RAM.
Canale di scambio delle chiavi private
Posto di lavoro dell'utente:
— bus USB;
— memoria RAM.
è assente
Canale di scambio tra nuclei crittografici
assente (manca la parte hardware del nucleo crittografico)
Posto di lavoro dell'utente:
— bus USB;
— memoria RAM;
— modulo software USB-over-IP;
— interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Hypervisor:
— memoria RAM;
— interfaccia di rete.
Macchina virtuale:
— interfaccia di rete;
— memoria RAM;
— modulo software USB-over-IP.
Canale di scambio dei dati aperti
Posto di lavoro dell'utente:
— dispositivi di input-output;
— memoria RAM;
— disco rigido.
Posto di lavoro dell'utente:
— dispositivi di input-output;
— memoria RAM;
— disco rigido;
— interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Hypervisor:
— interfaccia di rete;
— memoria RAM;
— disco rigido.
Macchina virtuale:
— interfaccia di rete;
— memoria RAM;
— disco rigido.
Canale di scambio dei dati protetti
Internet.
Rete aziendale dell'organizzazione 1.
Posto di lavoro dell'utente:
— disco rigido;
— memoria RAM;
— interfaccia di rete.
Internet.
Rete aziendale dell'organizzazione 2.
Hypervisor:
— interfaccia di rete;
— memoria RAM;
— disco rigido.
Macchina virtuale:
— interfaccia di rete;
— memoria RAM;
— disco rigido.
Canale di trasmissione temporale
Posto di lavoro dell'utente:
— dispositivi di input-output;
— memoria RAM;
— timer di sistema.
Internet.
Rete aziendale dell'organizzazione 2,
Hypervisor:
— interfaccia di rete;
— memoria RAM;
— timer di sistema.
Macchina virtuale:
— memoria RAM;
— timer di sistema.
Canale di trasmissione dei comandi di controllo
Posto di lavoro dell'utente:
— dispositivi di input-output;
— memoria RAM.
(Interfaccia utente grafica del software CryptoARM)
Macchina virtuale:
— memoria RAM;
— disco rigido.
(Script di automazione)
Canale di ricezione dei risultati
Posto di lavoro dell'utente:
— dispositivi di input-output;
— memoria RAM.
(Interfaccia utente grafica del software CryptoARM)
Macchina virtuale:
— memoria RAM;
— disco rigido.
(File di log del lavoro degli script di automazione)
Minacce alla sicurezza di alto livello
Chiarimenti
Presupposti adottati durante la decomposizione delle minacce:
- Vengono utilizzati algoritmi crittografici robusti.
- Gli algoritmi crittografici vengono utilizzati in modo sicuro nelle corrette modalità di funzionamento (ad esempio, non è applicabile per la crittografia di grandi volumi di dati, si tiene conto del carico ammissibile sulla chiave, ecc.).
- Gli aggressori conoscono tutti gli algoritmi, i protocolli e le chiavi pubbliche utilizzati.
- Tutti i dati crittografati sono leggibili dagli aggressori.
- Gli aggressori possono riprodurre qualsiasi elemento software nel sistema.
Decomposizione
U1. Compromissione delle chiavi crittografiche segrete.
U2. Crittografia di dati falsi a nome di un mittente legittimo.
U3. Decifratura dei dati crittografati da parte di persone che non sono legittimi destinatari dei dati (aggressori).
U4. Creazione di una firma elettronica da parte di un firmatario legittimo su dati falsi.
U5. Ottenimento di un risultato positivo nel controllo della firma elettronica su dati falsi.
U6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso documentale elettronico.
U7. Consultazione non autorizzata di dati protetti durante il loro trattamento da parte della SCZI.
U1. Compromissione delle chiavi crittografiche segrete
U1.1. Ottenimento della chiave segreta dal deposito delle chiavi segrete.
U1.2. Ottenimento della chiave segreta da oggetti nell'ambiente di funzionamento del mezzo crittografico, in cui può trovarsi temporaneamente.
Chiarimenti U1.2.
Gli oggetti in cui può temporaneamente risiedere la chiave segreta includeranno:
- memoria operativa,
- file temporanei,
- file di paging,
- file di ibernazione,
- file degli snapshot dello stato 'caldo' delle macchine virtuali, inclusi i file del contenuto della memoria operativa delle macchine virtuali messe in pausa.
U1.2.1. Estrazione di chiavi segrete dalla memoria operativa in funzione mediante il congelamento dei moduli RAM, la loro estrazione e successiva lettura dei dati (freeze attack).
Chiarimenti U1.2.1.
Esempio .
U1.3. Ottenimento della chiave segreta da un canale di scambio di chiavi segrete.
Chiarimenti U1.3.
Un esempio di attuazione di questa minaccia sarà fornito .
U1.4. Modifica non autorizzata del nucleo crittografico, a seguito della quale le chiavi segrete diventano note agli aggressori.
U1.5. Compromissione della chiave segreta a causa dell'uso di canali tecnici di fuga di informazioni (TKUI).
Chiarimenti U1.5.
Esempio .
U1.6. Compromissione della chiave segreta a causa dell'uso di strumenti tecnici speciali (STS) destinati per la raccolta clandestina di informazioni ("microfoni").
U1.7. Compromissione delle chiavi segrete durante la loro conservazione al di fuori del SKZI.
Chiarimenti U1.7.
Ad esempio, l'utente conserva i propri supporti chiave in un cassetto della scrivania, da cui possono essere facilmente estratti dai malintenzionati.
U2. Crittografia di dati falsi a nome del mittente legittimo.
Chiarimenti
Questa minaccia è considerata solo per schemi di crittografia dei dati con autenticazione del mittente. Esempi di tali schemi sono indicati nelle raccomandazioni di standardizzazione. . Per gli altri schemi crittografici, questa minaccia non esiste, poiché la crittografia è effettuata sulle chiavi pubbliche del destinatario, che in generale sono note ai malintenzionati.
Decomposizione
U2.1. Compromissione della chiave segreta del mittente:
U2.1.1. Riferimento: .
U2.2. Sostituzione dei dati di ingresso nel canale di scambio di dati aperti.
Note U2.2.
Esempi di implementazione di questa minaccia sono forniti di seguito. e .
U3. Decrittazione dei dati crittografati da parte di soggetti che non sono destinatari legittimi dei dati (malintenzionati).
Decomposizione
U3.1. Compromissione delle chiavi segrete del destinatario dei dati crittografati.
U3.1.1 Riferimento: .
U3.2. Sostituzione dei dati criptati nel canale di scambio di dati protetti.
U4. Creazione di una firma elettronica da parte di un firmatario legittimo su dati falsi.
Decomposizione
U4.1. Compromissione delle chiavi segrete della firma elettronica del firmatario legittimo.
U4.1.1 Riferimento: .
U4.2. Sostituzione dei dati firmati nel canale di scambio di dati aperti.
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 sui dati falsi.
Decomposizione
U5.1. Gli attaccanti intercettano nel canale di trasmissione dei risultati di lavoro un messaggio riguardante un esito negativo della verifica della firma elettronica e lo sostituiscono con un messaggio con esito positivo.
U5.2. Gli attaccanti attuano un attacco alla fiducia nei certificati di firma (SCENARIO — tutti gli elementi sono obbligatori):
U5.2.1. Gli attaccanti generano una chiave pubblica e una chiave privata per la firma elettronica. Se nel sistema vengono utilizzati certificati per le chiavi di firma elettronica, generano un certificato di firma elettronica il più simile possibile al certificato del presunto mittente dei dati il cui messaggio intendono falsificare.
U5.2.2. Gli attaccanti apportano modifiche non autorizzate al repository delle chiavi pubbliche, attribuendo alla chiave pubblica che hanno generato il livello necessario di fiducia e autorizzazioni.
U5.2.3. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica precedentemente creata e li inseriscono nel canale di scambio di dati protetti.
U5.3. Gli attaccanti attuano un attacco utilizzando chiavi di firma elettronica scadute di un firmatario legittimo (SCENARIO — tutti gli elementi sono obbligatori):
U5.3.1. Gli attaccanti compromettono le chiavi private elettroniche scadute (non più valide al momento) del mittente legittimo.
U5.3.2. Gli attaccanti sostituiscono il tempo nel canale di trasmissione con un'ora in cui le chiavi compromesse erano ancora valide.
U5.3.3. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.
U5.4. Gli attaccanti attuano un attacco utilizzando chiavi di firma elettronica compromesse di un firmatario legittimo (SCENARIO — tutti gli elementi sono obbligatori):
U5.4.1. Gli attaccanti fanno una copia del repository delle chiavi pubbliche.
U5.4.2. Gli attaccanti compromettono le chiavi private di uno dei mittenti legittimi. Costui nota la compromissione, revoca le chiavi e le informazioni sulla revoca sono inserite nel repository delle chiavi pubbliche.
U5.4.3. Gli attaccanti sostituiscono il repository delle chiavi pubbliche con quello precedentemente copiato.
U5.4.4. Gli attaccanti firmano dati falsificati con la chiave di firma elettronica compromessa in precedenza e li inseriscono nel canale di scambio di dati protetti.
U5.5. a causa della presenza di errori nell'implementazione della 2ª e 3ª fase di verifica della firma elettronica:
Chiarimenti U5.5.
Un esempio di implementazione di questa minaccia è fornito .
U5.5.1. Verifica della fiducia nel certificato della chiave di firma elettronica solo sulla base della fiducia nel certificato con cui è stato firmato, senza verifiche CRL o OCSP.
Chiarimenti U5.5.1.
Esempio di implementazione .
U5.5.2. Nella costruzione della catena di fiducia per il certificato non vengono analizzate le autorizzazioni dei certificati emittenti.
Chiarimenti U5.5.2.
Esempio di attacco riguardante i certificati SSL/TLS.
I malintenzionati hanno acquistato un certificato legittimo per la propria e-mail. Poi hanno creato un certificato fraudolento per un sito e lo hanno firmato con il proprio certificato. Se non viene condotta alcuna verifica delle autorizzazioni, la catena di fiducia risulterà corretta, e di conseguenza il certificato fraudolento sarà considerato valido.
U5.5.3. Nella costruzione della catena di fiducia per il certificato non vengono verificate le revoche dei certificati intermedi.
U5.5.4. L'aggiornamento della CRL avviene meno frequentemente rispetto a quanto viene rilasciato dall'ente certificatore.
U5.5.5. La decisione di fiducia nella firma elettronica viene presa prima di ricevere la risposta OCSP sullo stato del certificato, inviata in seguito a una richiesta effettuata dopo il momento di formazione della firma o prima di ricevere la successiva CRL dopo la formazione della firma.
Chiarimenti U5.5.5.
Nei regolamenti della maggior parte degli enti certificatori, il momento della revoca del certificato è considerato il momento di rilascio della CRL più vicina contenente informazioni sulla revoca del certificato.
U5.5.6. Al ricevimento di dati firmati non viene verificata l'appartenenza del certificato al mittente.
Chiarimenti U5.5.6.
Esempio di attacco. In relazione ai certificati SSL: potrebbe non essere verificata la corrispondenza dell'indirizzo del server chiamato con il valore del campo CN nel certificato.
Esempio di attacco. I malintenzionati hanno compromesso le chiavi di firma elettronica di uno dei partecipanti al sistema di pagamento. Successivamente, hanno violato la rete di un altro partecipante e, a suo nome, hanno inviato al server di calcolo del sistema di pagamento documenti di pagamento firmati con chiavi compromesse. Se il server analizza solo la fiducia e non verifica la corrispondenza, i documenti fraudolenti saranno considerati legittimi.
U6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione del flusso documentale elettronico.
Decomposizione
U6.1. La parte ricevente non rileva la duplicazione dei documenti ricevuti.
Chiarimenti U6.1.
Esempio di attacco. I malintenzionati possono intercettare un documento inviato al destinatario, anche se crittograficamente protetto, e poi inoltrarlo ripetutamente attraverso il canale di trasmissione dei dati protetti. Se il destinatario non identifica i duplicati, tutti i documenti ricevuti saranno considerati e trattati come documenti diversi.
U7. Accesso non autorizzato ai dati protetti durante la loro elaborazione con SKZI
Decomposizione
U7.1. a causa di una fuga di informazioni attraverso canali esterni (attacco tramite canale laterale).
Chiarimenti U7.1.
Esempio .
U7.2. a causa della neutralizzazione della protezione contro l'accesso non autorizzato alle informazioni elaborate su SKZI:
U7.2.1. Utilizzo di SKZI in violazione dei requisiti descritti nella documentazione relativa a SKZI.
U7.2.2. , effettuata a causa della presenza 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 del mezzo crittografico.
Esempi di attacchi
Gli scenari discussi di seguito contengono volutamente errori nell'organizzazione della sicurezza delle informazioni e servono solo come illustrazione di possibili attacchi.
Scenario 1. Esempio di implementazione delle minacce U2.2 e U4.2.
Descrizione dell'oggetto
Il software APM KBR e SKZI SKAD firma sono installati su un computer fisico non connesso alla rete di calcolo. Il supporto chiave utilizzato è il FKN vdToken in modalità di lavoro con una chiave non estraibile.
Il regolamento per l'esecuzione delle transazioni prevede che il specialista dei calcoli scarichi i messaggi elettronici in chiaro (schema del vecchio APM KBR) da un server di file protetto speciale, poi li memorizzi su un supporto rimovibile USB e li trasferisca su APM KBR, dove vengono crittografati e firmati. Dopo di ciò, il specialista trasferisce i messaggi elettronici protetti su un supporto rimovibile, e poi tramite il proprio computer di lavoro li carica sul server di file, da dove vengono inviati all'UTA e oltre nel sistema di pagamento della Banca di Russia.
In questo caso, i canali di scambio di dati aperti e protetti includeranno: server di file, computer di lavoro del specialista e supporto rimovibile.
L'attacco
I malintenzionati installano senza autorizzazione un sistema di gestione remota sul computer di lavoro dello specialista e nel momento in cui registra su un dispositivo di memorizzazione trasferito gli ordini di pagamento (messaggi elettronici) in chiaro, sostituiscono il contenuto di uno di essi. Lo specialista trasferisce gli ordini di pagamento su AРМ КБР, li firma e li crittografa, senza accorgersi della sostituzione (ad esempio, a causa del gran numero di ordini di pagamento in transito, della stanchezza, ecc.). Successivamente, l'ordine di pagamento contraffatto, passando attraverso la catena tecnologica, arriva al sistema di pagamento della Banca di Russia.
Scenario 2. Esempio di attuazione delle minacce У2.2 e У4.2.
Descrizione dell'oggetto
Un computer con AРМ КБР, СКАД Сигнатура e un dispositivo di chiave FКН vdToken collegato funziona in uno spazio riservato senza accesso da parte del personale.
Lo specialista contabile si connette a AРМ КБР in modalità di accesso remoto tramite il protocollo RDP.
L'attacco
I malintenzionati intercettano le credenziali, utilizzate dalle quali lo specialista contabile effettua la connessione e lavora con AРМ КБР (ad esempio, a causa di codice malevolo sul suo computer). Poi si connettono a nome suo e inviano un ordine di pagamento contraffatto nel sistema di pagamento della Banca di Russia.
Scenario 3. Esempio di attuazione della minaccia У1.3.
Descrizione dell'oggetto
Esaminiamo uno dei possibili metodi di attuazione dei moduli di integrazione "АБС-КБР" per un nuovo schema (AРМ КБР-Н), dove la firma elettronica dei documenti in uscita avviene lato AБС. Consideriamo che AБС funzioni su un sistema operativo non supportato da СКЗИ СКАД Сигнатура e, pertanto, la funzionalità crittografica è stata spostata su una macchina virtuale separata: modulo di integrazione "АБС-КБР".
Come dispositivo di chiave viene utilizzato un comune token USB, funzionante in modalità chiave estraibile. Quando il dispositivo di chiave è stato collegato all'iperconcentratore, si è scoperto che nel sistema non c'erano porte USB disponibili, quindi è stato deciso di collegare il token USB tramite un concentratore USB di rete e installare un client USB-over-IP sulla macchina virtuale, che realizzerà la connessione con il concentratore.
L'attacco
I malintenzionati hanno intercettato la chiave privata della firma elettronica tramite il canale di comunicazione tra l'hub USB e l'ipercomprensore (i dati erano trasmessi in chiaro). Possedendo la chiave privata, i malintenzionati hanno generato un falso ordine di pagamento, lo hanno firmato digitalmente e lo hanno inviato all'ARM KBR-N per l'esecuzione.
Scenario 4. Esempio di implementazione delle minacce U5.5.
Descrizione dell'oggetto
Consideriamo lo stesso schema del precedente scenario. Assumiamo che i messaggi elettronici provenienti dall'ARM KBR-N arrivino nella cartella …SHAREIn, mentre quelli inviati all'ARM KBR-N e successivamente al sistema di pagamento della Banca di Russia, vadano in …SHAREout.
Assumiamo inoltre che, durante l'implementazione del modulo di integrazione, gli elenchi dei certificati revocati vengano aggiornati solo al momento del riemissione delle chiavi crittografiche, e che i messaggi elettronici ricevuti nella cartella …SHAREIn vengano verificati solo per il controllo dell'integrità e la verifica della fiducia nella chiave pubblica della firma elettronica.
L'attacco
I malintenzionati, avvalendosi delle chiavi rubate nel precedente scenario, hanno firmato un falso ordine di pagamento contenente informazioni sul trasferimento di denaro sul conto di un cliente truffatore e lo hanno inserito nel canale di scambio di dati protetti. Poiché non viene effettuato alcun controllo per verificare che l'ordine di pagamento sia firmato proprio dalla Banca di Russia, esso viene accettato per l'esecuzione.
Fonte: habr.com
