L'esempio specifico che ho in mente qui è la violazione della RSA nel marzo 2011 dove gli attaccanti hanno ottenuto informazioni critiche che potrebbero essere le informazioni seme utilizzate per generare i numeri pseudo-casuali per i token RSA.
RSA ha tenuto molto tranquillo i dettagli reali, quindi se fossi responsabile della sicurezza di un'organizzazione, cosa potrei fare per assicurarmi contro lo scenario peggiore? Come potrei sapere anche quale potrebbe essere il caso peggiore?
Penso che il fatto che il tuo fornitore di sicurezza sia tutt'altro che trasparente, è già uno scenario piuttosto brutto.
Quando il venditore è riservato ai dettagli di sicurezza - siano essi specifici di un incidente o interni di sicurezza del prodotto stesso (o almeno prove di sicurezza, ad esempio cripto algos) - questo è un rischio intrinseco, per l'intera posizione di sicurezza di la tua organizzazione.
Ora, mentre in determinate circostanze è lecito accettare un rischio, tale rischio (se l'intera architettura di sicurezza fa affidamento su una terza parte, che può o non può essere considerata attendibile) dovrebbe non essere accettato alla leggera.
Quando un venditore inizia a dare la manciata di trattenere le informazioni critiche, invece di supportare i clienti nel fare scelte intelligenti, direi che la decisione sull'accettazione del rischio inizia ad essere un po 'torbida.
Di conseguenza, se fossi in quella posizione (e ignorando i vincoli come budget, tempo e politica), rivalutarei la mia relazione con TUTTI i fornitori che forniscono una parte fondamentale della mia infrastruttura. Si noti che questo è irrilevante per l'impatto reale: i difetti di alto impatto possono accadere a (quasi) chiunque: la parte importante è il modo in cui si sceglie di affrontarlo.
A mio parere, in questo caso il modo in cui lo hanno affrontato (o meno) dimostra che non comprendono la relazione di fiducia che deve essere in atto, affinché l'accettazione del rischio sopra descritta sia valida. Per lo meno, potrei considerare di cambiare le relazioni con i fornitori con uno di trasferimento di rischio anziché con l'accettazione, tramite SLA rigorosi con clausole penali.
E in questo caso specifico?
Beh, supponendo che l'eliminazione dell'intero meccanismo di autenticazione fino a quando questo accordo non venga risolto, non è davvero possibile, non molto altro da fare, eccetto attivare più logging sugli accessi, prestare particolare attenzione agli accessi anomali, guardare cosa fanno gli utenti e in generale provare per ridurre al minimo l'accesso per gli utenti ...
Se un venditore subisce un compromesso su un sistema che usi e rifiuta di fornirti dettagli soddisfacenti sull'impatto del compromesso sui tuoi sistemi, allora quello che dovresti cercare è ... un nuovo fornitore.
Lo scenario peggiore è la rottura completa di qualsiasi sistema di sicurezza utilizzato. Per esempio. in un sistema di autenticazione, gli hacker sanno abbastanza per autenticarsi in base all'identità falsa che desiderano e possono anche impedire agli utenti validi di autenticare o interrompere il loro processo di autenticazione in modo che il server li autentica in modo trasparente con l'ID sbagliato .
Questa domanda risale davvero alla gestione del rischio e non sto nemmeno parlando della gestione dei rischi derivata dalla gestione della sicurezza delle informazioni.
Sto parlando della gestione del rischio di gestione dei progetti. Molte aziende hanno un PMO (ufficio di gestione del progetto) ma meno esperti di rischio di progetto in esse.
Quando si scopre un progetto, come esternalizzare la gestione dell'identità al prodotto di un fornitore, come RSA SecurID, i gestori del rischio del progetto direbbero "quanto dovremmo mettere in questa soluzione di un singolo fornitore?" - non dal punto di vista della sicurezza, ma semplicemente dal punto di vista della "gestione aziendale".
Nella mia mente, quando una grande azienda acquista un prodotto e lo distribuisce (questo vale anche per l'outsourcing e il cloud computing, incluso SaaS), c'è l'idea di non mettere tutte le uova in un unico paniere. Se il tuo fornitore principale se ne va - com'è facile passare a un fornitore secondario o terziario?
Quando si pianifica - è facile guardare a ridurre fornitori / fornitori in percentuali e riempimenti eccessivi. Se si dispone di una soluzione che è al 100% in casa, considerando l'aggiunta di una soluzione esterna che colmerà un divario del 20 percento. Quindi, aggiungi un altro fornitore per un altro 20 percento: una soluzione esterna al 40 percento. Determinare quale fornitore sia il più vantaggioso dei due dopo l'analisi della performance (e probabilmente la contabilità finanziaria), così come le proprie performance di controllo interno e le metriche aziendali relative a detto prodotto.
Se una soluzione sporge - tocca un altro 20 percento, e se si comportano bene per un altro periodo di tempo (un ciclo, o iterazione, di sei sigma), aggiungi un 20 percento finale. Quindi hai due fornitori: uno al 20 percento, uno al 60 percento (e il 20 percento ancora in-house). Come ultima mossa, aggiungere una terza soluzione fornitore / fornitore al 20 percento (per una soluzione completamente esternalizzata). Tuttavia, mantieni la possibilità di ricorrere alla soluzione del 20 percento se necessario per un determinato periodo di tempo. Guarda come si esibiscono. Usando il tuo secondo e terzo fornitore - vedi se uno di loro può assumere un altro 20% (come ha fatto il tuo primo fornitore) durante le esecuzioni di prova. Se superano, eseguono scenari di errore in cui si riduce il provider principale al 40% e si consente al provider secondario o terziario di assumere tale ulteriore 20% per un periodo di tempo. Analizza utilizzando le tue metriche e gli strumenti Six Sigma su come funzionano i fornitori secondari e terziari e sposta i numeri se il tuo fornitore principale non ti soddisfa.
A lungo termine - sarai in grado di spostarti rapidamente da un punto di soluzione a un altro - e potenzialmente anche di tornare a una soluzione interna. Non si tratta solo di gestione della sicurezza delle informazioni, gestione dei rischi o operazioni di ripristino di emergenza / processi aziendali. È una buona pratica di gestione del progetto!
Qualcun altro avrà una risposta migliore, ne sono sicuro, ma nel peggiore dei casi penso che richieda la revoca immediata di tutti i token e una verifica di tutti i sistemi che i token sono stati usati per proteggere.
Penso che lo scenario peggiore dovrebbe essere definito dall'azienda, per azienda.
Leggi altre domande sui tag attacks incident-response