Inutile 2FA in caso di attaccante interno

Question

Inutile 2FA in caso di attaccante interno

#1 da (3 voti)
#2 da (2 voti)

3

Supponiamo uno scenario di firma sul lato server, in cui le chiavi utente vengono generate in un HSM ed esportate in un database, crittografate con una chiave simmetrica derivata da una password utente e la chiave master di HSM.

Per firmare, gli utenti devono fornire la password indicata e un fattore aggiuntivo, ad esempio un OTP, ad esempio. L'OTP non può essere utilizzato per proteggere la chiave perché è un valore dinamico, quindi è solo usato come barriera di autorizzazione. La trasmissione dei due fattori avviene tramite SSL.

Ora immagina che un malintenzionato all'interno di un utente malintenzionato cambi il codice dell'applicazione, quindi le password inviate dagli utenti vengono registrate in un file.

Sebbene l'operazione di firma tramite l'applicazione richieda 2 fattori, evitando in qualche modo attacchi da parte di aggressori esterni, cosa si può fare per impedire che un aggressore interno acceda direttamente all'HSM e decrittografa una chiave di firma con la password e utilizzandola per firmare i documenti per conto dell'utente?

In genere, l'accesso fisico agli HSM è protetto da un doppio controllo, ma gli utenti possono avere accesso logico a HSM se hanno la password per accedere da remoto.

Che tipo di misure di sicurezza posso implementare per prevenire questo tipo di attacco interno?

authentication digital-signature hsm

posta wolvz 13.06.2016 - 18:37

fonte

2 risposte

2

Forse stai pensando troppo a questo. Quando dici:

Now imagine a malicious inside attacker changes the application code...

Quindi stai cercando di indovinare a cosa verrà modificato il codice dell'applicazione e stai cercando di trovare una soluzione per quel particolare cambiamento. Il problema è che, se possono cambiare il codice in primo luogo, possono cambiarlo per fare anche molte altre cose, la maggior parte delle quali non è possibile prevedere. Quindi, anche se proteggi contro una modifica, probabilmente non proteggerà da una modifica diversa.

Le misure di sicurezza che prendi per proteggere da un attacco interno sono limitare chi ha accesso a modificare il codice dell'applicazione in primo luogo e mettere un sistema di notifica in atto in modo da sapere immediatamente se è stato modificato e da chi.

risposta data 13.06.2016 - 20:43

fonte

Leggi altre domande sui tag authentication digital-signature hsm

Come aumentare una chiave per la massima fiducia su un'altra macchina? L'NSA elabora la crittografia e come potrei proteggermi da questo tipo di attacchi? [chiuso]

score 3 · Accepted Answer

Il controllo e la segnalazione sono l'approccio generale alle minacce interne.

Se ti assicuri che l'attività sui sistemi sensibili sia pesantemente registrata e monitorata, aumenti drasticamente la difficoltà di sovvertire tali sistemi. In genere, si registra e si avvisa su ogni accesso e si mantiene un registro di controllo di tutte le azioni eseguite sul sistema. Per proteggere questi registri da manomissioni, li invii a supporti di sola scrittura o a un altro sistema a cui gli utenti del sistema sensibile non hanno accesso.

Un altro approccio efficace e relativamente economico al problema è il principio dei quattro occhi (che richiede a due persone di sorvegliare una determinata azione).

Infine, se sei preoccupato dell'integrità del tuo codice (o di altri file), puoi sempre utilizzare la firma del codice. Se si collega una firma crittografica a qualsiasi cosa si teme di essere modificati, si otterrà un grado molto elevato di certezza che il codice non viene modificato senza autorizzazione (presupponendo, ovviamente, che l'IPK per la configurazione del sistema di firma sia corretta) .