Ciao,
Questa è la seconda parte di un blog che avevo scritto in precedenza. La premessa della prima parte era di capire meglio quali sono le opzioni che le aziende devono affrontare in caso di compromissione di Active Directory. Come possono tornare a funzionare il più rapidamente possibile? Come si può fare con la massima garanzia di non ripristinare il malware nell'istanza della foresta di Active Directory ripristinata?
Per comprendere appieno la seconda parte, vi invito a leggere la prima, che potete trovarequi.
Per coloro che hanno già letto la prima parte, grazie per l'ottimo feedback. Tutti ottimi punti e commenti.
Quindi, iniziamo a rivedere il caso d'uso che ho lasciato nella prima parte...
Tutto è criptato. I parcheggi sono vuoti. Le fabbriche sono silenziose e l'amministratore delegato è al telefono ogni 30 secondi per dire qualcosa di "colorito" sulla vostra ascendenza. Purtroppo, questo non è uno scenario che ho inventato. È una conversazione mensile e praticamente settimanale che ho. Fa parte dell'attività che svolgo e ultimamente è un dilemma molto duro e realistico.
I commenti che ho ricevuto alla prima parte del blog si sono divisi in due aree. Il primo suggeriva di utilizzare un sistema di gestione dei permessi più sicuro. È sempre una buona idea, ma in questo caso è troppo tardi. Tuttavia, possiamo considerare questo aspetto come parte del processo di recupero. Più avanti. Il secondo suggeriva la ricostruzione parziale di una foresta separata. Questa seconda foresta sarebbe stata essenzialmente una foresta "VIP" in cui avrebbero trovato posto tutti i beni e le informazioni importanti dell'azienda. Forse. Ma quanto tempo ci vorrebbe? L'azienda ha le risorse per riarchitettare un'intera foresta al volo? Tenete presente che devo essere operativo già da ieri.
Se lo scenario di cui sopra è un attacco e si conosce l'ora in cui è stato infettato e il modo in cui è entrato, allora la risposta a ciò che si deve fare, a mio avviso, è ragionevolmente semplice. Si tratta di fare un backup della Active Directory del giorno precedente l'attacco e di eseguire un ripristino di Forest. (Tra poco mi occuperò della sfida del rootkit). L'unica domanda da porsi è: avete investito in una soluzione che automatizzi il ripristino di Forest e lo riporti in un paio d'ore o il vostro backup è più un backup tradizionale di Active Directory a livello di sistema, in cui non disponete di processi automatizzati specializzati per ripristinare Active Directory nella sua interezza. Se si tratta di quest'ultimo caso, dovrete prevedere quattro o cinque giorni lavorativi di inattività per ricostruire manualmente la vostra foresta fino alla sua piena capacità.
In realtà, alcuni degli scenari di attacco sopra descritti potrebbero avere un rootkit incorporato. È un enigma interessante... con lo scenario di cui sopra, come si fa a rimuovere un rootkit da un controller di dominio. È difficile, perché per il ripristino è necessario riportare lo stato del sistema, dove si potrebbe reintrodurre l'aggressore. Ciò significa anche che un backuprestore bare metal non funzionerà, poiché il rischio è sempre lo stesso.
Ricordate tutti il film Die-Hard in cui i cattivi sanno che in situazioni di crisi con ostaggi, l'FBI toglie la corrente ed è così che riescono a entrare nel caveau della banca? È la stessa cosa. Io lo so e voi sapete cosa serve per ripristinare un CC, ma il vero problema è che lo sanno anche i cattivi. Faranno affidamento sul fatto che tutti seguano la "procedura operativa standard" di Microsoft. Quale modo migliore per essere persistenti?
OK. Quindi, cosa farei nello scenario in cui l'aggressore è nel vostro sistema da un po' di tempo o, come nella maggior parte dei casi, non siete sicuri di quando sia entrato, come sia entrato, ecc.
La prima parte consiste nel reimpostare tutte le password, o almeno tutti gli account privilegiati/sensibili. È un compito molto impegnativo, ma direi molto più semplice e veloce di una ricostruzione completa o parziale. Tenete presente che il tempo stringe. Naturalmente, dovrebbe essere ovvio che come parte del ripristino dei permessi si incorpori l'impostazione o, in questo caso, la reimpostazione dei permessi secondo le migliori pratiche.
Il passo successivo sarebbe quello di adottare una soluzione automatizzata di recupero delle foreste. Per essere chiari, questa soluzione deve essere già pronta prima che si verifichi tutto questo. Non è uno strumento che si può introdurre il giorno dopo. Il recupero di più giorni rispetto a quello di un paio d'ore parla da sé in termini di vantaggi. Un'altra considerazione di cui molti non si rendono conto è che per far funzionare molte delle altre soluzioni di DR è necessario che AD sia funzionante, perché spesso si basano su AD per l'autenticazione e l'autorizzazione per accedere alla soluzione di DR.
La soluzione Forest Recovery è la risposta al problema dei rootkit. Parte del nostro processo di ripristino della foresta è qualcosa che chiamiamo "ripristino pulito". Non mi dilungherò sul come (è un altro blog), ma il risultato è che ci assicuriamo che vengano ripristinate solo le porzioni AD dello stato del sistema, non il sistema operativo stesso. Ora è possibile prendere un nuovo server hardware, caricare una nuova ISO di Windows e ripristinare AD senza il rischio di reintrodurre il malware.
C'è anche un altro vantaggio incorporato nella soluzione Forest Recovery che vale la pena menzionare: la possibilità di essere agnostici dal punto di vista dell'hardware quando si ripristina l'AD su un controller di dominio. Prima di questa funzionalità, per ripristinare l'AD era necessario ripristinare l'AD sullo stesso hardware, lo stesso sistema operativo, gli stessi livelli di patch e gli stessi livelli di service pack. In caso contrario, è probabile che si verifichi una schermata blu durante il ripristino e che si debbano trascorrere alcune ore per individuare i driver mancanti e simili. Oggi, nell'ambito della nostra soluzione di ripristino forestale, non siamo interessati all'hardware, ai service pack o ai livelli di patch del controller di dominio interessato. L'unico elemento che deve corrispondere è che il ripristino deve avvenire con lo stesso numero di sistema operativo su cui è stato eseguito il backup.
Ciò comporta una maggiore flessibilità per scenari quali il ripristino da fisico a virtuale, la creazione di laboratori e il ripristino di AD nel cloud.
All'inizio dellaprimaparte ho accennato al fatto che volevo scrivere di questo argomento perché, sebbene esistano una certa documentazione e alcune "indicazioni" su cosa fare, le ho trovate lente, incomplete e in molti casi non realistiche. L'altra motivazione è stata la tempistica. Quando ho iniziato a occuparmi di questo argomento, qualche anno fa, si trattava più che altro di una discussione accademica o teorica. Un articolo qui o là. Ora, IMO, è passato da un interessante caso limite a una normale domanda di pianificazione di emergenza. Le organizzazioni iniziano a rendersi conto che se hanno investito in uno SLA, diciamo di un giorno, per la pianificazione del disaster recovery, potrebbero dover aggiungere molti altri giorni, poiché nulla funzionerà senza il servizio AD funzionante.
Infine, la posta in gioco non è mai stata così alta. È in gioco la sopravvivenza di intere aziende. Non fraintendetemi: non ho la "pallottola d'argento". Nessuno ce l'ha. Ma spero di aver aggiunto qualche nuova considerazione su un problema molto difficile.
Se desiderate saperne di più sulla nostra tecnologia o se volete semplicemente discutere con me? Sentitevi liberi di contattarmi.
