Collegamenti ad altre parti dello studio
- (tu sei qui)
Questo articolo completa la serie di pubblicazioni dedicate a garantire la sicurezza delle informazioni dei pagamenti bancari non in contanti. Qui esamineremo i tipici modelli di minaccia a cui si fa riferimento :
- .
- .
- .
- .
HABRO-ATTENZIONE!!! Cari Khabroviti, questo non è un post divertente.
Le oltre 40 pagine di materiali nascosti sotto il taglio sono destinate a questo aiuto nel lavoro o nello studio persone specializzate in sicurezza bancaria o informatica. Questi materiali sono il prodotto finale della ricerca e sono scritti con un tono asciutto e formale. In sostanza, si tratta di spazi vuoti per documenti interni sulla sicurezza delle informazioni.Beh, tradizionale... “l’uso delle informazioni contenute nell’articolo per scopi illegali è punibile dalla legge”. Lettura produttiva!
Informazioni per i lettori che acquisiscono familiarità con lo studio a partire da questa pubblicazione.
Di cosa tratta lo studio?
Stai leggendo una guida per uno specialista responsabile di garantire la sicurezza delle informazioni dei pagamenti in una banca.
Logica di presentazione
All'inizio dentro и viene fornita una descrizione dell'oggetto protetto. Poi dentro descrive come costruire un sistema di sicurezza e parla della necessità di creare un modello di minaccia. IN parla di quali modelli di minaccia esistono e di come si formano. IN и Viene fornita un'analisi degli attacchi reali. и contenere una descrizione del modello di minaccia, costruito tenendo conto delle informazioni di tutte le parti precedenti.
MODELLO DI MINACCIA TIPICO. CONNESSIONE DI RETE
Oggetto di protezione a cui viene applicato il modello di minaccia (ambito).
Oggetto della protezione sono i dati trasmessi attraverso una connessione di rete operante in reti di dati costruite sulla base dello stack TCP/IP.
Architettura
Descrizione degli elementi architettonici:
- "Nodi finali" — nodi che scambiano informazioni protette.
- "Nodi intermedi" — elementi di una rete di trasmissione dati: router, switch, server di accesso, server proxy e altre apparecchiature — attraverso i quali viene trasmesso il traffico di connessione di rete. In generale, una connessione di rete può funzionare senza nodi intermedi (direttamente tra i nodi finali).
Minacce alla sicurezza di primo 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. <…>, effettuata presso i nodi finali o intermedi:
U1.1.1. <…> leggendo i dati mentre si trovano nei dispositivi di archiviazione host:
U1.1.1.1. <…> nella RAM.
Spiegazioni per U1.1.1.1.
Ad esempio, durante l'elaborazione dei dati da parte dello stack di rete dell'host.
U1.1.1.2. <…> nella memoria non volatile.
Spiegazioni per U1.1.1.2.
Ad esempio, quando si memorizzano i dati trasmessi in una cache, file temporanei o file di scambio.
U1.2. <…>, effettuato su nodi terzi della rete dati:
U1.2.1. <…> con il metodo di acquisizione di tutti i pacchetti che arrivano all'interfaccia di rete dell'host:
Spiegazioni per U1.2.1.
L'acquisizione di tutti i pacchetti viene effettuata commutando la scheda di rete in modalità promiscua (modalità promiscua per adattatori cablati o modalità monitor per adattatori Wi-Fi).
U1.2.2. <…> effettuando attacchi man-in-the-middle (MiTM), ma senza modificare i dati trasmessi (senza contare i dati di servizio del protocollo di rete).
U1.2.2.1. Collegamento: .
U1.3. <…>, effettuato a causa della fuga di informazioni attraverso canali tecnici (TKUI) da nodi fisici o linee di comunicazione.
U1.4. <…>, effettuato mediante l'installazione di mezzi tecnici speciali (STS) sui nodi terminali o intermedi, destinati alla raccolta segreta di informazioni.
U2. Modifica non autorizzata dei dati trasmessi
Decomposizione
U2.1. <…>, effettuata presso i nodi finali o intermedi:
U2.1.1. <…> leggendo e apportando modifiche ai dati mentre si trovano nei dispositivi di archiviazione dei nodi:
U2.1.1.1. <…> nella RAM:
U2.1.1.2. <…> nella memoria non volatile:
U2.2. <…>, effettuato su nodi terzi della rete di trasmissione dati:
U2.2.1. <…> effettuando attacchi man-in-the-middle (MiTM) e reindirizzando il traffico al nodo degli aggressori:
U2.2.1.1. Il collegamento fisico delle apparecchiature degli aggressori provoca l'interruzione della connessione di rete.
U2.2.1.2. Effettuare 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 routing statiche dei router.
U2.2.1.2.2.2. Annuncio di falsi percorsi da parte degli aggressori attraverso protocolli di routing 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 dei nomi host locali (host, lmhosts, ecc.)
U3. Violazione del diritto d'autore sui dati trasmessi
Decomposizione
U3.1. Neutralizzazione dei meccanismi per determinare la paternità delle informazioni indicando false informazioni sull'autore o sulla fonte dei dati:
U3.1.1. Modifica delle informazioni sull'autore contenute nelle informazioni trasmesse.
U3.1.1.1. Neutralizzazione della protezione crittografica dell'integrità e della paternità dei dati trasmessi:
U3.1.1.1.1. Collegamento: .
U3.1.1.2. Neutralizzazione della protezione del copyright dei dati trasmessi, implementata utilizzando codici di conferma una tantum:
U3.1.1.2.1. .
U3.1.2. Modifica delle informazioni sulla fonte delle informazioni trasmesse:
U3.1.2.1. .
U3.1.2.2. .
MODELLO DI MINACCIA TIPICO. SISTEMA INFORMATIVO COSTRUITO SU ARCHITETTURA CLIENT-SERVER
Oggetto di protezione a cui viene applicato il modello di minaccia (ambito).
Oggetto della tutela è un sistema informativo realizzato sulla base di un'architettura client-server.
Architettura
Descrizione degli elementi architettonici:
- "Cliente" – un dispositivo su cui opera la parte client del sistema informativo.
- "Server" – un dispositivo sul quale opera la parte server del sistema informativo.
- "Archivio dati" — parte dell'infrastruttura server di un sistema informativo, progettata per archiviare i dati elaborati dal sistema informativo.
- "Connessione di rete" — un canale di scambio di informazioni tra il Client e il Server che passa attraverso la rete dati. Una descrizione più dettagliata del modello di elemento è fornita in .
Restrizioni
Quando si modella un oggetto, vengono impostate le seguenti restrizioni:
- L'utente interagisce con il sistema informativo entro periodi di tempo finiti, detti sessioni di lavoro.
- All'inizio di ogni sessione di lavoro l'utente viene identificato, autenticato e autorizzato.
- Tutte le informazioni protette sono archiviate nella parte server del sistema informativo.
Minacce alla sicurezza di primo livello
Decomposizione
U1. Esecuzione di azioni non autorizzate da parte di aggressori per conto di un utente legittimo.
U2. Modifica non autorizzata delle informazioni protette durante l'elaborazione da parte della parte server del sistema informativo.
U1. Esecuzione di azioni non autorizzate da parte di aggressori per conto di un utente legittimo
spiegazioni
Tipicamente nei sistemi informativi le azioni sono correlate all'utente che le ha eseguite utilizzando:
- registri delle operazioni di sistema (registri).
- attributi speciali di oggetti dati contenenti informazioni sull'utente che li ha creati o modificati.
In relazione ad una sessione di lavoro, questa minaccia può essere scomposta in:
- <…> eseguito all'interno della sessione utente.
- <…> eseguito al di fuori della sessione utente.
È possibile avviare una sessione utente:
- Dall'utente stesso.
- Malfattori.
In questa fase, la scomposizione intermedia di questa minaccia sarà simile alla seguente:
U1.1. Sono state eseguite azioni non autorizzate all'interno di una sessione utente:
U1.1.1. <…> installato dall'utente attaccato.
U1.1.2. <…> installato dagli aggressori.
U1.2. Sono state eseguite azioni non autorizzate al di fuori della sessione utente.
Dal punto di vista degli oggetti dell'infrastruttura informativa che possono essere colpiti dagli aggressori, la scomposizione delle minacce intermedie sarà simile a questa:
elementi
Decomposizione della minaccia
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. Sono state eseguite azioni non autorizzate all'interno di una sessione utente:
U1.1.1. <…> installato dall'utente attaccato:
U1.1.1.1. Gli aggressori hanno agito indipendentemente dal Cliente:
U1.1.1.1.1 Gli aggressori hanno utilizzato strumenti standard di accesso al sistema informativo:
U1.1.1.1.1.1. Gli aggressori hanno utilizzato i mezzi fisici di input/output del Cliente (tastiera, mouse, monitor o touch screen di un dispositivo mobile):
U1.1.1.1.1.1.1. Gli aggressori hanno operato durante periodi di tempo in cui la sessione era attiva, le strutture I/O erano disponibili e l'utente non era presente.
У1.1.1.1.1.2. Gli aggressori hanno utilizzato strumenti di amministrazione remota (standard o forniti da codice dannoso) per controllare il client:
U1.1.1.1.1.2.1. Gli aggressori hanno operato durante periodi di tempo in cui la sessione era attiva, le strutture I/O erano disponibili e l'utente non era presente.
U1.1.1.1.1.2.2. Gli aggressori hanno utilizzato strumenti di amministrazione remota, il cui funzionamento è invisibile all'utente aggredito.
U1.1.1.2. Gli aggressori hanno sostituito i dati nella connessione di rete tra Client e Server, modificandoli in modo tale che fossero percepiti come azioni di un utente legittimo:
U1.1.1.2.1. Collegamento: .
U1.1.1.3. Gli aggressori hanno costretto l'utente a eseguire le azioni specificate utilizzando metodi di ingegneria sociale.
У1.1.2 <…> installato dagli aggressori:
U1.1.2.1. Gli aggressori hanno agito dal Client (И):
U1.1.2.1.1. Gli aggressori hanno neutralizzato il sistema di controllo degli accessi del sistema informativo:
U1.1.2.1.1.1. Collegamento: .
U1.1.2.1.2. Gli aggressori hanno utilizzato strumenti standard di accesso al sistema informativo
U1.1.2.2. Gli aggressori operavano da altri nodi della rete dati, da cui poteva essere stabilita una connessione di rete al Server (И):
U1.1.2.2.1. Gli aggressori hanno neutralizzato il sistema di controllo degli accessi del sistema informativo:
U1.1.2.2.1.1. Collegamento: .
U1.1.2.2.2. Gli aggressori hanno utilizzato mezzi non standard per accedere al sistema informativo.
Spiegazioni U1.1.2.2.2.
Gli aggressori potrebbero installare un client standard del sistema informativo su un nodo di terze parti oppure potrebbero utilizzare software non standard che implementano protocolli di scambio standard tra il client e il server.
U1.2 Sono state eseguite azioni non autorizzate al di fuori della sessione utente.
U1.2.1 Gli aggressori hanno eseguito azioni non autorizzate e quindi hanno apportato modifiche non autorizzate ai registri delle operazioni del sistema informativo o agli attributi speciali degli oggetti dati, indicando che le azioni eseguite sono state eseguite da un utente legittimo.
U2. Modifica non autorizzata delle informazioni protette durante l'elaborazione da parte della parte server del sistema informativo
Decomposizione
U2.1. Gli aggressori modificano le informazioni protette utilizzando gli strumenti standard dei sistemi informativi e lo fanno per conto di un utente legittimo.
U2.1.1. Collegamento: .
U2.2. Gli aggressori modificano le informazioni protette utilizzando meccanismi di accesso ai dati non previsti dal normale funzionamento del sistema informativo.
U2.2.1. Gli aggressori modificano i file contenenti informazioni protette:
U2.2.1.1. <…>, utilizzando i meccanismi di gestione dei file forniti dal sistema operativo.
U2.2.1.2. <…> provocando il ripristino di file da una copia di backup modificata non autorizzata.
U2.2.2. Gli aggressori modificano le informazioni protette archiviate nel database (И):
U2.2.2.1. Gli aggressori neutralizzano il sistema di controllo degli accessi DBMS:
U2.2.2.1.1. Collegamento: .
U2.2.2.2. Gli aggressori modificano le informazioni utilizzando le interfacce DBMS standard per accedere ai dati.
U2.3. Gli aggressori modificano le informazioni protette modificando non autorizzate gli algoritmi operativi 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 sfruttando le vulnerabilità nel software del sistema informativo.
U2.5. Gli aggressori modificano le informazioni protette quando vengono trasferite tra componenti della parte server del sistema informativo (ad esempio, un server database e un server applicativo):
U2.5.1. Collegamento: .
MODELLO DI MINACCIA TIPICO. SISTEMA DI CONTROLLO ACCESSI
Oggetto di protezione a cui viene applicato il modello di minaccia (ambito).
L'oggetto di protezione per il quale viene applicato questo modello di minaccia corrisponde all'oggetto di protezione del modello di minaccia: “Modello di minaccia tipico. Un sistema informativo costruito su un’architettura client-server.”
In questo modello di minaccia, per sistema di controllo degli accessi degli utenti si intende un componente di un sistema informativo che implementa le seguenti funzioni:
- Identificazione dell'utente.
- Autenticazione utente.
- Autorizzazioni utente.
- Registrazione delle azioni dell'utente.
Minacce alla sicurezza di primo livello
Decomposizione
U1. Creazione non autorizzata di una sessione per conto di un utente legittimo.
U2. Aumento non autorizzato dei privilegi degli utenti in un sistema informativo.
U1. Creazione non autorizzata di una sessione per conto di un utente legittimo
spiegazioni
La scomposizione di questa minaccia dipenderà generalmente dal tipo di sistemi di identificazione e autenticazione dell'utente utilizzati.
In questo modello verrà considerato solo un sistema di identificazione e autenticazione dell'utente mediante login e password testuali. In questo caso, supporremo che l'accesso dell'utente sia un'informazione pubblicamente disponibile e nota agli aggressori.
Decomposizione
U1.1. <…> per compromissione delle credenziali:
U1.1.1. Gli aggressori hanno compromesso le credenziali dell'utente mentre le archiviavano.
Spiegazioni U1.1.1.
Ad esempio, le credenziali potrebbero essere scritte su un foglietto adesivo attaccato al monitor.
U1.1.2. L'utente ha trasmesso accidentalmente o intenzionalmente i dettagli di accesso agli aggressori.
U1.1.2.1. L'utente ha pronunciato le credenziali ad alta voce mentre entrava.
U1.1.2.2. L'utente ha condiviso intenzionalmente le sue credenziali:
U1.1.2.2.1. <…> ai colleghi di lavoro.
Spiegazioni U1.1.2.2.1.
Ad esempio, per poterlo sostituire durante la malattia.
U1.1.2.2.2. <…> agli appaltatori del datore di lavoro che eseguono lavori su oggetti dell'infrastruttura informatica.
U1.1.2.2.3. <…> a terzi.
Spiegazioni U1.1.2.2.3.
Una, ma non l’unica opzione per implementare questa minaccia è l’uso di metodi di ingegneria sociale da parte degli aggressori.
U1.1.3. Gli aggressori hanno selezionato le credenziali utilizzando metodi di forza bruta:
U1.1.3.1. <…> utilizzando meccanismi di accesso standard.
U1.1.3.2. <…> utilizzando codici precedentemente intercettati (ad esempio, hash delle password) per archiviare le credenziali.
U1.1.4. Gli aggressori hanno utilizzato codice dannoso per intercettare le credenziali degli utenti.
U1.1.5. Gli aggressori hanno estratto le credenziali dalla connessione di rete tra il Client e il Server:
U1.1.5.1. Collegamento: .
U1.1.6. Gli aggressori hanno estratto credenziali dai registri dei sistemi di monitoraggio del lavoro:
U1.1.6.1. <…> sistemi di videosorveglianza (se le battute sulla tastiera sono state registrate durante il funzionamento).
U1.1.6.2. <…> sistemi per monitorare le 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, inviando password in chiaro via e-mail.
U1.1.8. Gli aggressori hanno ottenuto le credenziali monitorando la sessione di un utente utilizzando sistemi di amministrazione remota.
U1.1.9. Gli aggressori hanno ottenuto le credenziali a seguito della loro fuga attraverso canali tecnici (TCUI):
U1.1.9.1. Gli aggressori hanno osservato come l'utente immetteva le credenziali dalla tastiera:
U1.1.9.1.1 Gli aggressori si sono posizionati nelle immediate vicinanze dell'utente e hanno visto con i propri occhi l'inserimento delle credenziali.
Spiegazioni U1.1.9.1.1
Tali casi includono le azioni dei colleghi di lavoro o il 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 un binocolo o un veicolo aereo senza pilota, e hanno visto l'inserimento delle credenziali attraverso una finestra.
U1.1.9.2. Gli aggressori hanno estratto credenziali dalla comunicazione radio tra la tastiera e il sistema informatico collegato tramite un'interfaccia radio (ad esempio Bluetooth).
U1.1.9.3. Gli aggressori hanno intercettato le credenziali facendole trapelare attraverso il canale di radiazioni e interferenze elettromagnetiche spurie (PEMIN).
Spiegazioni U1.1.9.3.
Esempi di attacchi и .
U1.1.9.4. L'aggressore ha intercettato l'inserimento delle credenziali da tastiera attraverso l'utilizzo di particolari mezzi tecnici (STS) atti ad ottenere informazioni di nascosto.
Spiegazioni U1.1.9.4.
Примеры .
U1.1.9.5. Gli aggressori hanno intercettato l'immissione delle credenziali dalla tastiera utilizzando
analisi del segnale Wi-Fi modulato dal processo di battitura dell'utente.
Spiegazioni U1.1.9.5.
esempio .
U1.1.9.6. Gli aggressori hanno intercettato l'inserimento delle credenziali dalla tastiera analizzando il suono dei tasti premuti.
Spiegazioni U1.1.9.6.
esempio .
U1.1.9.7. Gli aggressori hanno intercettato l'inserimento delle credenziali dalla tastiera di un dispositivo mobile analizzando le letture dell'accelerometro.
Spiegazioni U1.1.9.7.
esempio .
U1.1.10. <…>, precedentemente salvato sul Client.
Spiegazioni U1.1.10.
Ad esempio, un utente potrebbe salvare login e password nel browser per accedere a un sito specifico.
U1.1.11. Gli aggressori hanno compromesso le credenziali a causa di difetti nel processo di revoca dell'accesso degli utenti.
Spiegazioni U1.1.11.
Ad esempio, dopo che un utente è stato licenziato, i suoi account sono rimasti sbloccati.
U1.2. <…> sfruttando le vulnerabilità nel sistema di controllo degli accessi.
U2. Elevazione non autorizzata dei privilegi dell'utente in un sistema informativo
Decomposizione
U2.1 <…> apportando modifiche non autorizzate ai dati contenenti informazioni sui privilegi dell'utente.
U2.2 <…> attraverso l'utilizzo delle vulnerabilità nel sistema di controllo degli accessi.
U2.3. <…> a causa di carenze nel processo di gestione dell'accesso degli utenti.
Spiegazioni U2.3.
Esempio 1. A un utente è stato concesso un accesso maggiore per lavoro rispetto a quello richiesto per motivi aziendali.
Esempio 2: Dopo che un utente è stato trasferito ad un'altra posizione, i diritti di accesso precedentemente concessi non sono stati revocati.
MODELLO DI MINACCIA TIPICO. MODULO DI INTEGRAZIONE
Oggetto di protezione a cui viene applicato il modello di minaccia (ambito).
Un modulo di integrazione è un insieme di oggetti dell'infrastruttura informativa progettati per organizzare lo scambio di informazioni tra sistemi informativi.
Considerando il fatto che nelle reti aziendali non è sempre possibile separare in modo univoco un sistema informativo da un altro, il modulo di integrazione può essere considerato anche come un anello di congiunzione tra i componenti all'interno di un sistema informativo.
Architettura
Lo schema generalizzato del modulo di integrazione è simile al seguente:
Descrizione degli elementi architettonici:
- "Server Exchange (SO)" – un nodo/servizio/componente di un sistema informativo che svolge la funzione di scambiare dati con un altro sistema informativo.
- "Mediatore" – un nodo/servizio atto ad organizzare l'interazione tra sistemi informativi, ma non parte di essi.
esempi "Intermediari" potrebbero essere presenti servizi di posta elettronica, bus di servizi aziendali (bus di servizi aziendali/architettura SoA), file server di terze parti, ecc. In generale il modulo integrazione non può contenere “Intermediari”. - "Software di elaborazione dati" – un insieme di programmi che implementano protocolli di scambio dati e conversione di formato.
Ad esempio, la conversione dei dati dal formato UFEBS al formato ABS, la modifica dello stato dei messaggi durante la trasmissione, ecc. - "Connessione di rete" corrisponde all'oggetto descritto nel modello di minaccia standard "Connessione di rete". Alcune delle connessioni di rete mostrate nel diagramma precedente potrebbero non esistere.
Esempi di moduli di integrazione
Schema 1. Integrazione di ABS e AWS KBR tramite un file server di terze parti
Per eseguire i pagamenti, un impiegato della banca autorizzato scarica i documenti di pagamento elettronici dal sistema bancario principale e li salva in un file (nel suo formato, ad esempio un dump SQL) su una cartella di rete (...SHARE) su un file server. Quindi questo file viene convertito utilizzando uno script di conversione in una serie di file nel formato UFEBS, che vengono poi letti dalla workstation CBD.
Successivamente, il dipendente autorizzato, l'utente del posto di lavoro automatizzato KBR, crittografa e firma i file ricevuti e li invia al sistema di pagamento della Banca di Russia.
Quando i pagamenti vengono ricevuti dalla Banca di Russia, il posto di lavoro automatizzato della KBR li decodifica e controlla la firma elettronica, dopodiché li registra sotto forma di una serie di file in formato UFEBS su un file server. Prima di importare i documenti di pagamento nell'ABS, questi vengono convertiti utilizzando uno script di conversione dal formato UFEBS al formato ABS.
Assumeremo che in questo schema l'ABS operi su un server fisico, la workstation KBR operi su un computer dedicato e lo script del convertitore venga eseguito su un file server.
Corrispondenza degli oggetti del diagramma considerato agli elementi del modello del modulo di integrazione:
“Server di scambio dal lato ABS” – Server ABS.
“Server di scambio dal lato AWS KBR” – postazione computer KBR.
"Mediatore" – file server di terze parti.
"Software di elaborazione dati" – script del convertitore.
Schema 2. Integrazione di ABS e AWS KBR quando si inserisce una cartella di rete condivisa con pagamenti su AWS KBR
Tutto è simile allo schema 1, ma non viene utilizzato un file server separato, bensì una cartella di rete (...SHARE) con i documenti di pagamento elettronici viene posizionata su un computer con postazione di lavoro CBD. Lo script del convertitore funziona anche sulla workstation CBD.
Corrispondenza degli oggetti del diagramma considerato agli elementi del modello del modulo di integrazione:
Simile allo Schema 1, ma "Mediatore" non usato.
Schema 3. Integrazione di ABS e postazione di lavoro automatizzata KBR-N tramite IBM WebSphera MQ e firma di documenti elettronici “lato ABS”
ABS opera su una piattaforma che non è supportata dalla firma CIPF SCAD. La firma dei documenti elettronici in uscita viene effettuata su un apposito server di firma elettronica (ES Server). Lo stesso server controlla la firma elettronica sui documenti in arrivo dalla Banca di Russia.
ABS carica sul Server ES un file con i documenti di pagamento nel proprio formato.
Il server ES, utilizzando uno script di conversione, converte il file in messaggi elettronici nel formato UFEBS, dopodiché i messaggi elettronici vengono firmati e trasmessi a IBM WebSphere MQ.
La workstation KBR-N accede a IBM WebSphere MQ e da lì riceve messaggi di pagamento firmati, dopodiché un dipendente autorizzato - un utente della workstation KBR - li crittografa e li invia al sistema di pagamento della Banca di Russia.
Quando i pagamenti vengono ricevuti dalla Banca di Russia, il posto di lavoro automatizzato KBR-N li decodifica e verifica la firma elettronica. I pagamenti elaborati con successo sotto forma di messaggi elettronici decrittografati e firmati nel formato UFEBS vengono trasferiti a IBM WebSphere MQ, da dove vengono ricevuti dal server di firma elettronica.
Il server di firma elettronica verifica la firma elettronica dei pagamenti ricevuti e li salva in un file in formato ABS. Successivamente, il dipendente autorizzato, l'utente ABS, carica il file risultante nell'ABS nel modo prescritto.
Corrispondenza degli oggetti del diagramma considerato agli elementi del modello del modulo di integrazione:
“Server di scambio dal lato ABS” – Server ABS.
“Server di scambio dal lato AWS KBR” — postazione di lavoro informatica KBR.
"Mediatore" – Server ES e IBM WebSphere MQ.
"Software di elaborazione dati" – convertitore di script, firma CIPF SCAD sul server ES.
Schema 4. Integrazione del server RBS e del sistema bancario principale tramite l'API fornita da un server di scambio dedicato
Supponiamo che la banca utilizzi diversi sistemi bancari a distanza (RBS):
- "Banca Cliente Internet" per privati (IKB FL);
- "Banca cliente Internet" per persone giuridiche (IKB LE).
Al fine di garantire la sicurezza delle informazioni, tutte le interazioni tra ABS e sistemi bancari a distanza vengono effettuate tramite un server di scambio dedicato che opera nell'ambito del sistema informativo ABS.
Successivamente, considereremo il processo di interazione tra il sistema RBS di IKB LE e l'ABS.
Il server RBS, dopo aver ricevuto un ordine di pagamento debitamente certificato dal cliente, deve creare un documento corrispondente nell'ABS basato su di esso. Per fare ciò, utilizzando l'API, trasmette le informazioni al server di scambio, che a sua volta inserisce i dati nell'ABS.
Quando i saldi dei conti del cliente cambiano, l’ABS genera notifiche elettroniche, che vengono trasmesse al server bancario remoto utilizzando il server di scambio.
Corrispondenza degli oggetti del diagramma considerato agli elementi del modello del modulo di integrazione:
“Server Exchange dal lato RBS” – Server RBS di IKB YUL.
“Server di scambio dal lato ABS” – server di scambio.
"Mediatore" - mancante.
"Software di elaborazione dati" – Componenti del server RBS responsabili dell'utilizzo dell'API del server Exchange, componenti del server Exchange responsabili dell'utilizzo dell'API core banking.
Minacce alla sicurezza di primo livello
Decomposizione
U1. Iniezione di informazioni false da parte degli aggressori attraverso il modulo di integrazione.
U1. Iniezione di informazioni false da parte degli aggressori attraverso il modulo di integrazione
Decomposizione
U1.1. Modifica non autorizzata di dati legittimi trasmessi tramite connessioni di rete:
Collegamento U1.1.1: .
U1.2. Trasmissione di dati falsi attraverso canali di comunicazione per conto di un partecipante legittimo allo scambio:
Collegamento U1.1.2: .
U1.3. Modifica non autorizzata dei dati legittimi durante l'elaborazione sui server Exchange o sull'Intermediario:
U1.3.1. Collegamento: .
U1.4. Creazione di dati falsi sui server di scambio o sull'intermediario per conto di un partecipante legittimo allo scambio:
U1.4.1. Collegamento:
U1.5. Modifica non autorizzata dei dati durante l'elaborazione tramite software di elaborazione dati:
U1.5.1. <…> a causa di aggressori che apportano modifiche non autorizzate alle impostazioni (configurazione) del software di elaborazione dati.
U1.5.2. <…> a causa di aggressori che apportano modifiche non autorizzate ai file eseguibili del software di elaborazione dati.
U1.5.3. <…> a causa del controllo interattivo del software di elaborazione dati da parte degli aggressori.
MODELLO DI MINACCIA TIPICO. SISTEMA DI PROTEZIONE DELLE INFORMAZIONI CRITTOGRAFICHE
Oggetto di protezione a cui viene applicato il modello di minaccia (ambito).
L'oggetto della protezione è un sistema di protezione delle informazioni crittografiche utilizzato per garantire la sicurezza del sistema informativo.
Architettura
La base di qualsiasi sistema informativo è il software applicativo che ne implementa le funzionalità target.
La protezione crittografica viene solitamente implementata richiamando primitive crittografiche dalla logica aziendale del software applicativo, che si trovano in librerie specializzate: i crypto core.
Le primitive crittografiche includono funzioni crittografiche di basso livello, come:
- crittografare/decrittografare un blocco di dati;
- creare/verificare una firma elettronica di un blocco di dati;
- calcolare la funzione hash del blocco dati;
- generare/caricare/caricare informazioni chiave;
- eccetera
La logica aziendale del software applicativo implementa funzionalità di livello superiore utilizzando primitive crittografiche:
- crittografare il file utilizzando le chiavi dei destinatari selezionati;
- stabilire una connessione di rete sicura;
- informare sui risultati del controllo della firma elettronica;
- e così via.
L'interazione tra logica aziendale e crypto core può essere effettuata:
- direttamente, per logica di business richiamando le primitive crittografiche dalle librerie dinamiche del kernel crittografico (.DLL per Windows, .SO per Linux);
- direttamente, attraverso interfacce crittografiche - wrapper, ad esempio, MS Crypto API, Java Cryptography Architecture, PKCS#11, ecc. In questo caso, la logica aziendale accede all'interfaccia crittografica e traduce la chiamata al corrispondente core crittografico, che in questo caso è chiamato provider di crittografia. L'uso di interfacce crittografiche consente al software applicativo di astrarsi da specifici algoritmi crittografici ed essere più flessibile.
Esistono due schemi tipici per organizzare il crypto core:
Schema 1 – Nucleo crittografico monolitico
Schema 2 – Dividi il core crittografico
Gli elementi nei diagrammi precedenti possono essere singoli moduli software in esecuzione su un computer o servizi di rete che interagiscono all'interno di una rete di computer.
Quando si utilizzano sistemi costruiti secondo lo Schema 1, il software applicativo e il core crittografico operano all'interno di un unico ambiente operativo per lo strumento crittografico (SFC), ad esempio, sullo stesso computer, con lo stesso sistema operativo. L'utente del sistema, di norma, può eseguire altri programmi, compresi quelli contenenti codice dannoso, all'interno dello stesso ambiente operativo. In tali condizioni esiste il serio rischio di fuga di chiavi crittografiche private.
Per ridurre al minimo il rischio, viene utilizzato lo schema 2, in cui il crypto core è diviso in due parti:
- La prima parte, insieme al software applicativo, opera in un ambiente non affidabile dove esiste il rischio di infezione da codice dannoso. Chiameremo questa parte la “parte software”.
- La seconda parte funziona in un ambiente affidabile su un dispositivo dedicato, che contiene un archivio di chiave privata. D'ora in poi chiameremo questa parte “hardware”.
La divisione del core crittografico in parti software e hardware è molto arbitraria. Esistono sistemi sul mercato costruiti secondo uno schema con un core crittografico diviso, ma la cui parte "hardware" è presentata sotto forma di un'immagine di macchina virtuale - HSM virtuale ().
L'interazione di entrambe le parti del nucleo crittografico avviene in modo tale che le chiavi crittografiche private non vengono mai trasferite alla parte software e, di conseguenza, non possono essere rubate tramite codice dannoso.
L'interfaccia di interazione (API) e l'insieme di primitive crittografiche fornite al software applicativo dal crypto core sono gli stessi in entrambi i casi. La differenza sta nel modo in cui vengono implementati.
Pertanto, quando si utilizza uno schema con un nucleo crittografico diviso, l'interazione tra software e hardware viene eseguita secondo il seguente principio:
- Il software esegue le primitive crittografiche che non richiedono l'uso di una chiave privata (ad esempio, il calcolo di una funzione hash, la verifica di una firma elettronica, ecc.).
- Le primitive crittografiche che utilizzano una chiave privata (creazione di una firma elettronica, decrittografia dei dati, ecc.) vengono eseguite dall'hardware.
Illustriamo il lavoro del core crittografico diviso usando l'esempio della creazione di una firma elettronica:
- La parte software calcola la funzione hash dei dati firmati e trasmette questo valore all'hardware attraverso il canale di scambio tra crypto core.
- La parte hardware, utilizzando la chiave privata e l'hash, genera il valore della firma elettronica e lo trasmette alla parte software tramite un canale di scambio.
- La parte software restituisce il valore ricevuto al software applicativo.
Caratteristiche di controllo della correttezza di una firma elettronica
Quando la parte ricevente riceve dati firmati elettronicamente, deve effettuare diverse fasi di verifica. Un risultato positivo del controllo della firma elettronica si ottiene solo se tutte le fasi della verifica vengono completate con successo.
Fase 1. Controllo dell'integrità e della paternità dei dati.
Contenuto della scena. La firma elettronica dei dati viene verificata utilizzando l'apposito algoritmo crittografico. Il completamento con successo di questa fase indica che i dati non sono stati modificati dal momento della firma e che la firma è stata effettuata con una chiave privata corrispondente alla chiave pubblica per la verifica della firma elettronica.
Luogo del palco: nucleo crittografico.
Fase 2. Controllo della fiducia nella chiave pubblica del firmatario e controllo del periodo di validità della chiave privata della firma elettronica.
Contenuto della scena. La fase è composta da due sottofasi intermedi. Il primo è determinare se la chiave pubblica per la verifica della firma elettronica era attendibile al momento della firma dei dati. La seconda determina se la chiave privata della firma elettronica era valida al momento della firma dei dati. In generale, i periodi di validità di queste chiavi potrebbero non coincidere (ad esempio, per i certificati qualificati delle chiavi di verifica della firma elettronica). Le modalità per stabilire la fiducia nella chiave pubblica del firmatario sono determinate dalle regole di gestione elettronica dei documenti adottate dalle parti interagenti.
Luogo del palco: software applicativo/core crittografico.
Fase 3. Controllo dei poteri del firmatario.
Contenuto della scena. In conformità con le regole stabilite per la gestione elettronica dei documenti, viene verificato se il firmatario aveva il diritto di certificare i dati protetti. Ad esempio, diamo una situazione di violazione dell'autorità. Supponiamo che esista un'organizzazione in cui tutti i dipendenti dispongono di una firma elettronica. Il sistema di gestione elettronica dei documenti interni riceve un ordine dal responsabile, ma firmato con la firma elettronica del responsabile del magazzino. Di conseguenza, tale documento non può essere considerato legittimo.
Luogo del palco: software applicativo.
Ipotesi formulate nel descrivere l'oggetto della protezione
- I canali di trasmissione delle informazioni, ad eccezione dei canali di scambio delle chiavi, passano anche attraverso software applicativi, API e crypto core.
- Le informazioni sulla fiducia nelle chiavi pubbliche e (o) nei certificati, nonché le informazioni sui poteri dei proprietari delle chiavi pubbliche, vengono archiviate nell'archivio delle chiavi pubbliche.
- Il software applicativo funziona con l'archivio di chiavi pubbliche tramite il kernel crittografico.
Un esempio di sistema informativo protetto tramite CIPF
Per illustrare i diagrammi precedentemente presentati, consideriamo un ipotetico sistema informativo ed evidenziamo tutti gli elementi strutturali su di esso.
Descrizione del sistema informativo
Le due organizzazioni hanno deciso di introdurre tra loro la gestione elettronica dei documenti (EDF) giuridicamente rilevante. Per fare ciò, hanno stipulato un accordo in cui stabilivano che i documenti sarebbero stati trasmessi via e-mail e allo stesso tempo dovevano essere crittografati e firmati con una firma elettronica qualificata. Come strumenti per la creazione e l'elaborazione di documenti dovrebbero essere utilizzati i programmi Office del pacchetto Microsoft Office 2016, come mezzo di protezione crittografica dovrebbero essere utilizzati CIPF CryptoPRO e il software di crittografia CryptoARM.
Descrizione dell'infrastruttura dell'organizzazione 1
L'Organizzazione 1 ha deciso di installare il software CIPF CryptoPRO e CryptoARM sulla workstation dell'utente, un computer fisico. Le chiavi di crittografia e firma elettronica verranno archiviate sul supporto chiave ruToken, operando in modalità chiave recuperabile. L'utente preparerà i documenti elettronici localmente sul proprio computer, quindi li crittograferà, li firmerà e li invierà utilizzando 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. In questo caso, tutte le operazioni crittografiche verranno eseguite automaticamente.
Per fare ciò, sulla macchina virtuale dedicata vengono organizzate due cartelle di rete: “...In”, “...Out”. I file ricevuti dalla controparte in forma aperta verranno automaticamente inseriti nella cartella di rete “…In”. Questi file verranno decrittografati e la firma elettronica verrà verificata.
L'utente inserirà nella cartella “...Out” i file che dovranno essere crittografati, firmati e inviati alla controparte. L'utente preparerà lui stesso i file sulla sua postazione di lavoro.
Per eseguire le funzioni di crittografia e firma elettronica, sulla macchina virtuale sono installati CIPF CryptoPRO, il software CryptoARM e un client di posta elettronica. La gestione automatica di tutti gli elementi della macchina virtuale verrà effettuata utilizzando script sviluppati dagli amministratori di sistema. Il lavoro degli script viene registrato nei file di registro.
Le chiavi crittografiche per la firma elettronica verranno posizionate su un token con chiave GOST JaCarta non recuperabile, che l'utente collegherà al proprio computer locale.
Il token verrà inoltrato alla macchina virtuale utilizzando un software USB-over-IP specializzato installato sulla workstation dell'utente e sulla macchina virtuale.
L'orologio di sistema sulla workstation dell'utente nell'organizzazione 1 verrà regolato manualmente. L'orologio di sistema della macchina virtuale dedicata nell'Organizzazione 2 verrà sincronizzato con l'orologio di sistema dell'hypervisor, che a sua volta sarà sincronizzato su Internet con i server orari pubblici.
Individuazione degli elementi strutturali del CIPF
Sulla base della descrizione sopra dell'infrastruttura IT, evidenzieremo gli elementi strutturali del CIPF e li scriveremo in una tabella.
Tabella - Corrispondenza degli elementi del modello CIPF con gli elementi del sistema informativo
Nome dell'oggetto
Organizzazione 1
Organizzazione 2
Software applicativo
Software CryptoARM
Software CryptoARM
Parte software del core crittografico
CIPF CryptoPROCSP
CIPF CryptoPROCSP
Hardware principale crittografico
no
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Archivio chiavi pubbliche
Postazione di lavoro dell'utente:
- DISCO FISSO;
- Archivio certificati standard di Windows.
Hypervisor:
- DISCO FISSO.
Macchina virtuale:
- DISCO FISSO;
- Archivio certificati standard di Windows.
Archiviazione di chiavi private
Portachiavi ruToken funzionante in modalità chiave recuperabile
Portachiavi JaCarta GOST funzionante in modalità chiave non rimovibile
Canale di scambio di chiavi pubbliche
Postazione di lavoro dell'utente:
-RAM.
Hypervisor:
-RAM.
Macchina virtuale:
-RAM.
Canale di scambio di chiavi private
Postazione di lavoro dell'utente:
— bus USB;
-RAM.
no
Canale di scambio tra crypto core
mancante (nessun hardware crypto core)
Postazione di lavoro dell'utente:
— bus USB;
-RAM;
— modulo software USB-over-IP;
- interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Hypervisor:
-RAM;
- interfaccia di rete.
Macchina virtuale:
- interfaccia di rete;
-RAM;
— Modulo software USB su IP.
Apri canale dati
Postazione di lavoro dell'utente:
— mezzi di input-output;
-RAM;
- DISCO FISSO.
Postazione di lavoro dell'utente:
— mezzi di input-output;
-RAM;
- DISCO FISSO;
- interfaccia di rete.
Rete aziendale dell'organizzazione 2.
Hypervisor:
- interfaccia di rete;
-RAM;
- DISCO FISSO.
Macchina virtuale:
- interfaccia di rete;
-RAM;
- DISCO FISSO.
Canale di scambio dati sicuro
Internet.
Rete aziendale dell'organizzazione 1.
Postazione di lavoro dell'utente:
- DISCO FISSO;
-RAM;
- interfaccia di rete.
Internet.
Rete aziendale dell'organizzazione 2.
Hypervisor:
- interfaccia di rete;
-RAM;
- DISCO FISSO.
Macchina virtuale:
- interfaccia di rete;
-RAM;
- DISCO FISSO.
Canale temporale
Postazione di lavoro dell'utente:
— mezzi di input-output;
-RAM;
- timer di sistema.
Internet.
Rete aziendale dell'organizzazione 2,
Hypervisor:
- interfaccia di rete;
-RAM;
- timer di sistema.
Macchina virtuale:
-RAM;
- timer di sistema.
Canale di trasmissione del comando di controllo
Postazione di lavoro dell'utente:
— mezzi di input-output;
-RAM.
(Interfaccia utente grafica del software CryptoARM)
Macchina virtuale:
-RAM;
- DISCO FISSO.
(Script di automazione)
Canale per ricevere i risultati del lavoro
Postazione di lavoro dell'utente:
— mezzi di input-output;
-RAM.
(Interfaccia utente grafica del software CryptoARM)
Macchina virtuale:
-RAM;
- DISCO FISSO.
(File di registro degli script di automazione)
Minacce alla sicurezza di primo livello
spiegazioni
Ipotesi fatte durante la scomposizione delle minacce:
- Vengono utilizzati algoritmi crittografici avanzati.
- Gli algoritmi crittografici vengono utilizzati in modo sicuro nelle modalità operative corrette (ad es. non viene utilizzato per crittografare grandi volumi di dati, viene preso in considerazione il carico consentito sulla chiave, ecc.).
- Gli aggressori conoscono tutti gli algoritmi, i protocolli e le chiavi pubbliche utilizzate.
- Gli aggressori possono leggere tutti i dati crittografati.
- Gli aggressori sono in grado di riprodurre qualsiasi elemento software presente nel sistema.
Decomposizione
U1. Compromissione delle chiavi crittografiche private.
U2. Crittografia di dati falsi per conto del mittente legittimo.
U3. Decrittazione di dati crittografati da parte di persone che non sono legittimi destinatari dei dati (aggressori).
U4. Creazione di una firma elettronica di un firmatario legittimo con dati falsi.
U5. Ottenere un esito positivo dal controllo della firma elettronica dei dati contraffatti.
U6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione della gestione dei documenti elettronici.
U7. Accesso non autorizzato ai dati protetti durante il loro trattamento da parte del CIPF.
U1. Compromissione delle chiavi crittografiche private
U1.1. Recupero della chiave privata dall'archivio chiavi private.
U1.2. Ottenere una chiave privata da oggetti nell'ambiente operativo del cripto-strumento, in cui potrebbe risiedere temporaneamente.
Spiegazioni U1.2.
Gli oggetti che possono memorizzare temporaneamente una chiave privata includono:
- RAM,
- file temporanei,
- scambiare file,
- file di ibernazione,
- file snapshot dello stato “caldo” delle macchine virtuali, inclusi file del contenuto della RAM delle macchine virtuali in pausa.
U1.2.1. Estrazione delle chiavi private dalla RAM funzionante congelando i moduli RAM, rimuovendoli e quindi leggendo i dati (attacco di congelamento).
Spiegazioni U1.2.1.
esempio .
U1.3. Ottenere una chiave privata da un canale di scambio di chiavi private.
Spiegazioni U1.3.
Verrà fornito un esempio dell'implementazione di questa minaccia .
U1.4. Modifica non autorizzata del nucleo crittografico, in seguito alla quale le chiavi private diventano note agli aggressori.
U1.5. Compromissione di una chiave privata a seguito dell'uso di canali di perdita di informazioni tecniche (TCIL).
Spiegazioni U1.5.
esempio .
U1.6. Compromissione di una chiave privata a seguito dell'uso di mezzi tecnici speciali (STS) progettati per il recupero segreto di informazioni ("bug").
U1.7. Compromissione delle chiavi private durante la loro conservazione al di fuori del CIPF.
Spiegazioni U1.7.
Ad esempio, un utente memorizza i propri file multimediali chiave in un cassetto del desktop, dal quale possono essere facilmente recuperati dagli aggressori.
U2. Crittografia di dati falsi per conto di un mittente legittimo
spiegazioni
Questa minaccia è considerata solo per gli schemi di crittografia dei dati con autenticazione del mittente. Esempi di tali schemi sono indicati nelle raccomandazioni di standardizzazione . Per altri schemi crittografici questa minaccia non esiste, poiché la crittografia viene eseguita sulle chiavi pubbliche del destinatario e queste sono generalmente note agli aggressori.
Decomposizione
U2.1. Compromettere la chiave privata del mittente:
U2.1.1. Collegamento: .
U2.2. Sostituzione dei dati di input in un canale di scambio dati aperto.
Note U2.2.
Di seguito sono riportati esempi dell'implementazione di questa minaccia. и .
U3. Decriptazione di dati crittografati da parte di persone che non sono destinatari legittimi dei dati (aggressori)
Decomposizione
U3.1. Compromissione delle chiavi private del destinatario dei dati crittografati.
Collegamento U3.1.1: .
U3.2. Sostituzione dei dati crittografati in un canale di scambio dati sicuro.
U4. Creazione di una firma elettronica di un firmatario legittimo con dati falsi
Decomposizione
U4.1. Compromissione delle chiavi private della firma elettronica di un firmatario legittimo.
Collegamento U4.1.1: .
U4.2. Sostituzione dei dati firmati in un canale di scambio dati aperto.
Nota U4.2.
Di seguito sono riportati esempi dell'implementazione di questa minaccia. и .
U5. Ottenere un esito positivo dal controllo della firma elettronica dei dati contraffatti
Decomposizione
U5.1. Gli aggressori intercettano un messaggio nel canale di trasmissione dei risultati del lavoro relativo a un risultato negativo del controllo della firma elettronica e lo sostituiscono con un messaggio con un risultato positivo.
U5.2. Gli aggressori attaccano la fiducia nella firma dei certificati (SCRIPT: tutti gli elementi sono obbligatori):
U5.2.1. Gli aggressori generano una chiave pubblica e privata per una firma elettronica. Se il sistema utilizza certificati di chiavi di firma elettronica, genera un certificato di firma elettronica il più simile possibile al certificato del mittente previsto dei dati di cui si vuole falsificare il messaggio.
U5.2.2. Gli aggressori apportano modifiche non autorizzate all'archivio delle chiavi pubbliche, fornendo alla chiave pubblica da loro generata 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 dati sicuro.
U5.3. Gli aggressori effettuano un attacco utilizzando chiavi di firma elettronica scadute di un firmatario legale (SCRIPT: tutti gli elementi sono obbligatori):
U5.3.1. Gli aggressori compromettono le chiavi private scadute (non attualmente valide) della firma elettronica di un mittente legittimo.
U5.3.2. Gli aggressori sostituiscono l'ora nel canale di trasmissione dell'ora con l'ora in cui le chiavi compromesse erano ancora valide.
U5.3.3. Gli aggressori firmano dati falsi con una chiave di firma elettronica precedentemente compromessa e li inseriscono nel canale di scambio dati sicuro.
U5.4. Gli aggressori effettuano un attacco utilizzando chiavi di firma elettronica compromesse di un firmatario legale (SCRIPT: tutti gli elementi sono obbligatori):
U5.4.1. L'aggressore crea una copia dell'archivio delle chiavi pubbliche.
U5.4.2. Gli aggressori compromettono le chiavi private di uno dei mittenti legittimi. Si accorge della compromissione, revoca le chiavi e le informazioni sulla revoca delle chiavi vengono inserite nell'archivio delle chiavi pubbliche.
U5.4.3. Gli aggressori sostituiscono l'archivio delle chiavi pubbliche con uno precedentemente copiato.
U5.4.4. Gli aggressori firmano dati falsi con una chiave di firma elettronica precedentemente compromessa e li inseriscono nel canale di scambio dati sicuro.
U5.5. <…> a causa della presenza di errori nell'implementazione della 2a e 3a fase di verifica della firma elettronica:
Spiegazioni U5.5.
Viene fornito un esempio dell'implementazione di questa minaccia .
U5.5.1. Verifica dell'attendibilità in un certificato di chiave di firma elettronica solo mediante la presenza di attendibilità nel certificato con cui è firmato, senza controlli CRL o OCSP.
Spiegazioni U5.5.1.
Esempio di implementazione .
U5.5.2. Quando si crea una catena di fiducia per un certificato, le autorità che emettono i certificati non vengono analizzate
Spiegazioni U5.5.2.
Un esempio di attacco contro i certificati SSL/TLS.
Gli aggressori hanno acquistato un certificato legittimo per la loro posta elettronica. Hanno quindi creato un certificato del sito fraudolento e lo hanno firmato con il loro certificato. Se le credenziali non vengono controllate, durante il controllo della catena di fiducia risulterà corretta e, di conseguenza, anche il certificato fraudolento sarà corretto.
U5.5.3. Quando si crea una catena di attendibilità dei certificati, la revoca dei certificati intermedi non viene controllata.
U5.5.4. I CRL vengono aggiornati meno frequentemente di quanto vengono emessi dall'autorità di certificazione.
U5.5.5. La decisione di considerare attendibile una firma elettronica viene presa prima che venga ricevuta una risposta OCSP sullo stato del certificato, inviata su una richiesta effettuata successivamente al momento della generazione della firma o prima della successiva CRL successiva alla generazione della firma.
Spiegazioni U5.5.5.
Nella normativa della maggior parte delle CA, il momento della revoca del certificato è considerato il momento dell'emissione della CRL più vicina contenente le informazioni sulla revoca del certificato.
U5.5.6. Quando si ricevono dati firmati, il certificato appartiene al mittente non viene controllato.
Spiegazioni 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 presente nel certificato.
Esempio di attacco. Gli aggressori hanno compromesso le chiavi di firma elettronica di uno dei partecipanti al sistema di pagamento. Successivamente sono entrati nella rete di un altro partecipante e, per suo conto, hanno inviato documenti di pagamento firmati con chiavi compromesse al server di regolamento del sistema di pagamento. Se il server analizza solo la fiducia e non verifica la conformità, i documenti fraudolenti saranno considerati legittimi.
U6. Accettazione errata di documenti elettronici per l'esecuzione a causa di problemi nell'organizzazione della gestione dei documenti elettronici.
Decomposizione
U6.1. La parte ricevente non rileva la duplicazione dei documenti ricevuti.
Spiegazioni U6.1.
Esempio di attacco. Gli aggressori possono intercettare un documento trasmesso a un destinatario, anche se è protetto crittograficamente, e quindi inviarlo ripetutamente su un canale di trasmissione dati sicuro. Se il destinatario non identifica i duplicati, tutti i documenti ricevuti verranno percepiti ed elaborati come documenti diversi.
U7. Accesso non autorizzato ai dati protetti durante il loro trattamento da parte del CIPF
Decomposizione
U7.1. <…> a causa della fuga di informazioni attraverso i canali laterali (attacco del canale laterale).
Spiegazioni U7.1.
esempio .
U7.2. <…> a causa della neutralizzazione della protezione contro l'accesso non autorizzato alle informazioni elaborate su CIPF:
U7.2.1. Funzionamento del CIPF in violazione dei requisiti descritti nella documentazione del CIPF.
U7.2.2. <…>, effettuato a causa della presenza di vulnerabilità in:
U7.2.2.1. <…> mezzi di protezione contro l'accesso non autorizzato.
U7.2.2.2. <…> CIPF stesso.
U7.2.2.3. <…> l'ambiente operativo del cripto-strumento.
Esempi di attacchi
Gli scenari discussi di seguito contengono ovviamente errori di sicurezza delle informazioni e servono solo a illustrare possibili attacchi.
Scenario 1. Un esempio dell'implementazione delle minacce U2.2 e U4.2.
Descrizione dell'oggetto
Il software AWS KBR e la firma CIPF SCAD sono installati su un computer fisico non connesso alla rete di computer. FKN vdToken viene utilizzato come portachiavi nella modalità di funzionamento con una chiave non rimovibile.
Il regolamento di liquidazione presuppone che lo specialista di liquidazione scarichi dal suo computer di lavoro i messaggi elettronici in chiaro (schema della vecchia postazione di lavoro KBR) da uno speciale file server sicuro, poi li scriva su una chiavetta USB trasferibile e li trasferisca sulla postazione di lavoro KBR, dove sono crittografati e firmati. Successivamente, lo specialista trasferisce i messaggi elettronici sicuri al mezzo alienato e poi, tramite il suo computer di lavoro, li scrive su un file server, da dove vanno all'UTA e poi al sistema di pagamento della Banca di Russia.
In questo caso, i canali per lo scambio di dati aperti e protetti includeranno: un file server, il computer di lavoro di uno specialista e media alienati.
attacco
Gli aggressori non autorizzati installano un sistema di controllo remoto sul computer di lavoro di uno specialista e, al momento di scrivere ordini di pagamento (messaggi elettronici) su un supporto trasferibile, sostituiscono il contenuto di uno di essi in testo in chiaro. Lo specialista trasferisce gli ordini di pagamento alla postazione di lavoro automatizzata KBR, li firma e li crittografa senza accorgersi della sostituzione (ad esempio a causa dell'elevato numero di ordini di pagamento su un volo, stanchezza, ecc.). Successivamente, il falso ordine di pagamento, dopo aver attraversato la catena tecnologica, entra nel sistema di pagamento della Banca di Russia.
Scenario 2. Un esempio dell'implementazione delle minacce U2.2 e U4.2.
Descrizione dell'oggetto
In una stanza dedicata senza accesso da parte del personale opera un computer con installata una postazione di lavoro KBR, SCAD Signature e un portachiavi FKN vdToken collegato.
Lo specialista dei calcoli si collega alla postazione CBD in modalità di accesso remoto tramite il protocollo RDP.
attacco
Gli aggressori intercettano i dettagli con i quali lo specialista dei calcoli si connette e lavora con la workstation CBD (ad esempio tramite codice dannoso sul suo computer). Quindi si collegano per suo conto e inviano un falso ordine di pagamento al sistema di pagamento della Banca di Russia.
Scenario 3. Esempio di implementazione della minaccia U1.3.
Descrizione dell'oggetto
Consideriamo una delle ipotetiche opzioni per l'implementazione dei moduli di integrazione ABS-KBR per un nuovo schema (AWS KBR-N), in cui la firma elettronica dei documenti in uscita avviene sul lato ABS. In questo caso, supponiamo che l'ABS funzioni sulla base di un sistema operativo che non è supportato dalla firma CIPF SKAD e, di conseguenza, la funzionalità crittografica viene trasferita su una macchina virtuale separata - l'integrazione "ABS-KBR" modulo.
Come portachiavi viene utilizzato un normale token USB funzionante in modalità chiave recuperabile. Quando si collega il supporto chiave all'hypervisor, si scopre che non c'erano porte USB libere nel sistema, quindi si è deciso di connettere il token USB tramite un hub USB di rete e installare un client USB-over-IP sul virtuale macchina, che comunicherebbe con l'hub.
attacco
Gli aggressori hanno intercettato la chiave privata della firma elettronica dal canale di comunicazione tra l'hub USB e l'hypervisor (i dati sono stati trasmessi in chiaro). Avendo la chiave privata, gli aggressori hanno generato un falso ordine di pagamento, lo hanno firmato con una firma elettronica e lo hanno inviato alla postazione di lavoro automatizzata KBR-N per l'esecuzione.
Scenario 4. Un esempio di implementazione delle minacce U5.5.
Descrizione dell'oggetto
Consideriamo lo stesso circuito dello scenario precedente. Supponiamo che i messaggi elettronici provenienti dalla postazione di lavoro KBR-N finiscano nella cartella …SHAREIn, e quelli inviati alla postazione di lavoro KBR-N e successivamente al sistema di pagamento della Banca di Russia vadano in …SHAREout.
Assumeremo inoltre che durante l'implementazione del modulo di integrazione, gli elenchi dei certificati revocati vengano aggiornati solo quando le chiavi crittografiche vengono riemesse, e anche che i messaggi elettronici ricevuti nella cartella …SHAREIn vengano controllati solo per il controllo di integrità e di fiducia nella chiave pubblica del firma elettronica.
attacco
Gli aggressori, utilizzando le chiavi rubate nello scenario precedente, hanno firmato un falso ordine di pagamento contenente informazioni sulla ricezione del denaro sul conto del cliente fraudolento e lo hanno introdotto nel canale sicuro di scambio dati. Poiché non è possibile verificare che l'ordine di pagamento sia stato firmato dalla Banca di Russia, viene accettato per l'esecuzione.
Fonte: habr.com