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 sopra descritto è un attacco e si conosce l’ora in cui si è verificata l’infezione e come gli hacker sono riusciti a entrare, allora la risposta su cosa fare, a mio avviso, è ragionevolmente semplice. Si tratta di eseguire un backup di Active Directory del giorno precedente all’attacco e di effettuare un ripristino della foresta. (Affronterò la questione del rootkit tra un attimo). A questo punto l’unica domanda è: avete investito in una soluzione che automatizza il ripristino della foresta e la riporta operativa in un paio d’ore, oppure il vostro backup è più simile a un tradizionale backup dello stato del sistema di Active Directory, in cui non disponete di processi automatizzati specializzati per ripristinare Active Directory nella sua interezza? Se si tratta di quest’ultimo caso, dovrete prevedere un’interruzione di quattro o cinque giorni lavorativi per ricostruire manualmente la vostra foresta e riportarla alla piena operatività.
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.
Vi ricordate tutti il film “Die Hard”, in cui i cattivi sanno che, nelle situazioni di crisi con ostaggi, l’FBI interrompe l’alimentazione elettrica e che è proprio così che alla fine riescono a entrare nel caveau della banca? Qui vale lo stesso principio. Io so, e anche voi sapete, cosa serve per ripristinare un DC, ma il vero problema è che… lo sanno anche i cattivi. Conteranno sul fatto che tutti seguano la “procedura operativa standard” di Microsoft. Quale modo migliore per continuare a persistere?
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 “soluzione miracolosa”. Nessuno ce l’ha. Ma spero di aver offerto qualche nuovo spunto di riflessione su un problema molto complesso.
Se desiderate saperne di più sulla nostra tecnologia o se volete semplicemente discutere con me? Sentitevi liberi di contattarmi.
