Pianificazione del compromesso

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Legge Numero Uno: Nessuno crede che nulla di male possa accadere a sé fino a quando non succede. - 10 leggi immutabili dell'amministrazione della sicurezza

I piani di ripristino di emergenza in molte organizzazioni si concentrano sul ripristino da emergenze o errori a livello di area che causano la perdita dei servizi di elaborazione. Tuttavia, quando si lavora con clienti che hanno subito compromissioni del sistema, spesso si scopre che il ripristino da compromissione intenzionale era assente nei piani di ripristino di emergenza. Ciò è particolarmente vero quando la compromissione comporta il furto di proprietà intellettuale o di distruzione di dati intenzionale che sfrutta i limiti logici (ad esempio la distruzione di tutti i domini di Active Directory o di tutti i server) anziché i limiti fisici (ad esempio la distruzione di un data center). Sebbene un'organizzazione possa avere piani di risposta agli eventi imprevisti, che definiscono le attività iniziali da intraprendere quando viene individuata una compromissione, tali piani spesso omettono passaggi per il ripristino da una compromissione che influisce sull'intera infrastruttura di elaborazione.

Poiché Active Directory offre funzionalità avanzate di gestione delle identità e degli accessi per utenti, server, workstation e applicazioni, è inevitabilmente attenzionata da utenti malintenzionati. Se un utente malintenzionato ottiene l'accesso con privilegi elevati a un dominio o a un controller di dominio di Active Directory, tale accesso può essere sfruttato per accedere, controllare o persino distruggere l'intera foresta di Active Directory.

Questo documento ha preso in esame alcuni degli attacchi più comuni contro Windows e Active Directory e delle contromisure che è possibile implementare per ridurre la superficie di attacco, ma l'unico modo sicuro per il ripristino in caso di una compromissione completa di Active Directory è prepararsi prima che si verifichi. Questa sezione è incentrata meno sui dettagli dell'implementazione tecnica rispetto alle sezioni precedenti di del documento e più sulle raccomandazioni di alto livello che è possibile utilizzare al fine di creare un approccio olistico e completo per proteggere e gestire gli asset aziendali e IT critici dell'organizzazione.

Indipendentemente dal fatto che l'infrastruttura non sia mai stata attaccata, abbia resistito a violazioni o abbia dovuto soccombere agli attacchi e sia stata completamente compromessa, è consigliabile pianificare l'inevitabile realtà, ovvero che sarà costretta a subire degli attacchi. Non è possibile prevenire gli attacchi, ma può invece essere possibile prevenire violazioni significative o compromissioni generiche. Ogni organizzazione deve valutare attentamente i programmi di gestione dei rischi in essere e apportare le modifiche necessarie per ridurre il livello complessivo di vulnerabilità, effettuando investimenti equilibrati in prevenzione, rilevamento, contenimento e ripristino.

Per creare difese efficaci mentre si stanno fornendo servizi agli utenti e alle aziende che dipendono dalla sua infrastruttura e dalle sue applicazioni, potrebbe essere necessario prendere in considerazione nuovi modi di prevenire, rilevare e contenere le compromissioni nell'ambiente e quindi di ripristinare il sistema. Gli approcci e le raccomandazioni riportati nel presente documento potrebbero non aiutare a ripristinare un'installazione compromessa di Active Directory, ma possono essere utili per proteggere quella successiva.

Le raccomandazioni per il ripristino di una foresta Active Directory sono presentate in Ripristino foresta Active Directory - Passaggi per il ripristino della foresta. È possibile impedire che il nuovo ambiente venga completamente compromesso; tuttavia, anche se ciò non è possibile, si avranno strumenti per ripristinarlo e riprenderne il controllo.

Ripensamento dell'approccio

Legge Numero 8: la difficoltà di difendere una rete è direttamente proporzionale alla sua complessità. - 10 leggi immutabili dell'amministrazione della sicurezza

È ormai riconosciuto che se un utente malintenzionato ha ottenuto l'accesso SYSTEM, Administrator, root o equivalente a un computer, indipendentemente dal sistema operativo, tale computer non può più essere considerato affidabile, indipendentemente da quanti tentativi vengano effettuati per "pulire" il sistema. Per Active Directory il discorso non cambia. Se un utente malintenzionato ha ottenuto l'accesso con privilegi a un controller di dominio o a un account con privilegi elevati in Active Directory, a meno che non si disponga di un record di ogni modifica eseguita dall'utente malintenzionato o di un backup valido, non è mai possibile ripristinare la directory a uno stato che sia completamente affidabile.

Quando un server membro o una workstation vengono compromessi e alterati da un utente malintenzionato, il computer non è più affidabile, tuttavia i server e le workstation adiacenti non compromessi possono comunque essere considerati affidabili. La compromissione di un computer non implica che tutti i computer risultino compromessi.

Tuttavia, in un dominio di Active Directory, tutti i controller di dominio ospitano repliche dello stesso database di Active Directory Domain Services. Se un singolo controller di dominio viene compromesso e un utente malintenzionato modifica il database di Active Directory Domain Services, tali modifiche vengono replicate in ogni altro controller di dominio all’interno del dominio e, a seconda della partizione in cui vengono apportate le modifiche, della foresta. Anche se si reinstalla ogni controller di dominio nella foresta, non si fa altro che reinstallare gli host in cui risiede il database di Active Directory Domain Services. Le modifiche dannose ad Active Directory verranno replicate nei controller di dominio appena installati, così come nei controller di dominio in esecuzione da anni.

Quando si effettua una valutazione degli ambienti compromessi, si scopre in genere che ciò che si ritiene essere il primo "evento" di violazione è stato in realtà attivato dopo settimane, mesi o persino anni che gli utenti malintenzionati avevano iniziato la loro opera di violazione dell'ambiente. Generalmente, i malintenzionati hanno ottenuto le credenziali per gli account con privilegi elevati prima del rilevamento di una violazione e hanno sfruttato tali account per compromettere la directory, i controller di dominio, i server membri, le workstation e persino i sistemi non Windows connessi.

Questi risultati sono coerenti con diversi risultati presenti nel Report di indagini sulla violazione dei dati di Verizon del 2012, in cui si afferma che:

• il 98% delle violazioni dei dati sono derivati da agenti esterni

• l'85% delle violazioni dei dati ha richiesto settimane o più per essere scoperto

• il 92% degli incidenti è stato scoperto da terze parti e

• il 97% delle violazioni sarebbe stato evitabile con controlli semplici o intermedi.

Una compromissione del livello descritto in precedenza è effettivamente irreparabile e i consigli standard per "flatten and rebuild" (ripulire e ricostruire) ogni sistema compromesso semplicemente non è fattibile o addirittura non è possibile se Active Directory è stato compromesso o distrutto. Anche il ripristino a uno stato valido noto non elimina le falle che hanno consentito la compromissione iniziale dell'ambiente.

Sebbene sia necessario difendere ogni aspetto dell'infrastruttura, a un utente malintenzionato basta trovare solo alcune falle nelle difese per raggiungere il suo obiettivo. Se l'ambiente ha una struttura relativamente semplice, risulta intatto ed è storicamente ben gestito, l'implementazione delle raccomandazioni fornite in precedenza nel presente documento può essere abbastanza lineare.

Tuttavia, abbiamo scoperto che quanto più l'ambiente è datato, grande e complesso, tanto più è probabile che le raccomandazioni contenute in questo documento siano inapplicabili o persino impossibili da implementare. È molto più difficile proteggere un'infrastruttura dopo una compromissione di quanto non sia iniziare da zero e costruire un ambiente resistente ad attacchi e compromissioni. Tuttavia, come accennato in precedenza, ricompilare un’intera foresta di Active Directory non è impresa da poco. Per questi motivi, è consigliabile adottare un approccio più mirato per proteggere le foreste di Active Directory.

Invece di concentrarsi su tutte le cose che sono state danneggiate e cercare di ripararle, è bene prendere in considerazione un approccio che assegni le priorità in base a ciò che è più importante per l'azienda e all’interno dell'infrastruttura. Invece di provare a correggere un ambiente pieno di sistemi e applicazioni obsoleti e non configurati correttamente, è consigliabile creare un nuovo ambiente piccolo e sicuro,all’interno del quale sia possibile trasferire in modo sicuro gli utenti, i sistemi e le informazioni più importanti per l'azienda.

In questa sezione viene descritto un approccio tramite il quale è possibile creare una foresta di Active Directory Domain Services incontaminata che funge da "scialuppa di salvataggio" o "cella di sicurezza" per l'infrastruttura aziendale principale. Una foresta incontaminata è semplicemente una foresta Active Directory appena installata, generalmente limitata in dimensioni e ambito, e che viene compilata utilizzando i sistemi operativi, le applicazioni correnti e i principi descritti in Riduzione della superficie di attacco di Active Directory.

Implementando le impostazioni di configurazione consigliate in una foresta appena compilata, è possibile creare un'installazione di Active Directory Domain Services da zero con impostazioni e procedure sicure ed è possibile ridurre le sfide associate al supporto di sistemi e applicazioni legacy. Anche se le istruzioni dettagliate per la progettazione e l'implementazione di un'installazione di Active Directory Domain Services non rientrano nell'ambito del presente documento, è consigliabile seguire alcuni principi e linee guida generali per creare una "cella di sicurezza" in cui è possibile ospitare gli asset più critici. Queste linee guida sono le seguenti:

1. Identificare i principi per la separazione e la protezione di asset critici.

2. Definire un piano di migrazione limitato basato sul rischio.

3. Utilizzare migrazioni "nonmigratorie", se necessario.

4. Implementare la "distruzione creativa".

5. Isolare i sistemi e le applicazioni legacy.

6. Semplificare la sicurezza per gli utenti finali.

Identificare i principi per la separazione e la protezione di asset critici

Le caratteristiche dell'ambiente incontaminato creato per ospitare asset critici possono variare notevolmente. Ad esempio, è possibile scegliere di creare una foresta incontaminata in cui si esegue la migrazione solo di utenti VIP e dati sensibili a cui possono accedere unicamente quegli utenti. È possibile creare una foresta pulita in cui si esegue la migrazione non solo di utenti VIP, ma che si implementa come foresta amministrativa, implementando i principi descritti in Riduzione della superficie di attacco di Active Directory per creare account amministrativi e host sicuri che possono essere usati per gestire le foreste legacy dalla foresta pulita. È possibile implementare una foresta "appositamente creata" che ospita account VIP, account con privilegi e sistemi che richiedono sicurezza aggiuntiva, ad esempio i server che eseguono Servizi certificati Active Directory (AD CS) con l'unico obiettivo di separarli da foreste meno sicure. Infine, è possibile implementare una foresta incontaminata che diventa de facto la posizione per tutti i nuovi utenti, sistemi, applicazioni e dati, consentendo di rimuovere definitivamente la foresta legacy tramite l'attrito.

Indipendentemente dal fatto che la foresta incontaminata contenga solo una piccola quantità di utenti e sistemi piuttosto che costituisca la base per una migrazione più aggressiva, durante la pianificazione è necessario seguire questi principi:

1. Si supponga che le foreste legacy siano state compromesse.

2. Non configurare un ambiente incontaminato per considerare attendibile una foresta legacy, anche se è possibile configurare un ambiente legacy in modo che consideri attendibile una foresta incontaminata.

3. Non eseguire la migrazione di account utente o gruppi da una foresta legacy a un ambiente incontaminato se esiste una possibilità che le appartenenze ai gruppi degli account, la cronologia SID o altri attributi siano stati modificati in modo maligno. Usare invece approcci "nonmigratori" per popolare una foresta incontaminata. Gli approcci nonmigratori sono descritti più avanti in questa sezione.

4. Non eseguire la migrazione di computer da foreste legacy a foreste incontaminate. Implementare server appena installati nella foresta incontaminata, installare applicazioni nei server appena installati ed eseguire la migrazione dei dati dell'applicazione ai sistemi appena installati. Per i file server, copiare i dati in server appena installati, impostare ACL usando utenti e gruppi nella nuova foresta e quindi creare server di stampa in modo analogo.

5. Non consentire l'installazione di sistemi operativi o applicazioni legacy nella foresta incontaminata. Se un'applicazione non può essere aggiornata e venire nuovamente installata, lasciarla nella foresta legacy e prendere in considerazione la distruzione creativa per sostituire la funzionalità dell'applicazione.

Definire un piano di migrazione limitato basato sul rischio

La creazione di un piano di migrazione limitato e basato sul rischio implica semplicemente che quando si decide quali utenti, applicazioni e dati migrare nella foresta incontaminata, è necessario identificare le destinazioni di migrazione in base al grado di rischio a cui l'organizzazione viene esposta se uno degli utenti o dei sistemi viene compromesso. Gli utenti VIP, i cui account sono più probabile oggetto di attacco da parte di utenti malintenzionati, devono essere ospitati nella foresta incontaminata. Le applicazioni che forniscono funzioni aziendali vitali devono essere installate in server appena compilati nella foresta incontaminata e i dati altamente sensibili devono essere spostati in server protetti al suo interno.

Se non si ha già un quadro chiaro degli utenti, dei sistemi, delle applicazioni e dei dati più critici per l'azienda nell'ambiente Active Directory, collaborare con le business unit per identificarli. Tutte le applicazioni indispensabili per il funzionamento dell'azienda devono essere identificate, come devono essere archiviati tutti i server in cui vengono archiviate le applicazioni o i dati critici. Identificando gli utenti e le risorse indispensabili per il funzionamento dell'organizzazione, si crea una raccolta di asset con priorità naturale su cui concentrare gli sforzi.

Usare le migrazioni "nonmigratorie"

Indipendentemente dal fatto che l'ambiente sia stato compromesso, si sospetti che sia stato compromesso o che semplicemente si preferisca non eseguire la migrazione di oggetti e dati legacy da un'installazione legacy di Active Directory a un nuovo ambiente, prendere in considerazione gli approcci di migrazione che non eseguono tecnicamente la "migrazione".

User Accounts

In una migrazione tradizionale di Active Directory da una foresta a un'altra, l'attributo SIDHistory (cronologia SID) sugli oggetti utente viene usato per archiviare il SID degli utenti e i SID di gruppi di cui gli utenti erano membri nella foresta legacy. Se gli account utente vengono migrati in una nuova foresta e accedono alle risorse nella foresta legacy, i SID nella cronologia SID vengono usati per creare un token di accesso che consente agli utenti di accedere alle risorse a cui hanno avuto accesso prima della migrazione degli account.

Il mantenimento della cronologia SID, tuttavia, ha dimostrato problemi in alcuni ambienti perché il popolamento dei token di accesso degli utenti con i SID correnti e quelli storici può comportare un eccessivo dimensionamento (bloat) del token. Il bloat del token è un problema che si verifica quando il numero di SID che devono essere archiviati nel token di accesso di un utente usa o supera la quantità di spazio disponibile nel token.

Anche se le dimensioni dei token possono essere aumentate, in misura limitata, la soluzione finale per il token bloat consiste nel ridurre il numero di SID associati agli account utente, razionalizzando le appartenenze ai gruppi, eliminando la cronologia SID o una combinazione di entrambe le soluzioni. Per altre informazioni sul bloat dei token, vedere MaxTokenSize e token bloat di Kerberos.

Invece di eseguire la migrazione degli utenti da un ambiente legacy (in particolare uno in cui le appartenenze ai gruppi e le cronologie SID possono essere compromesse) utilizzando la cronologia SID, è consigliabile sfruttare le applicazioni di metadirectory per "eseguire la migrazione" degli utenti, senza portare cronologie SID nella nuova foresta. Quando vengono creati account utente nella nuova foresta, è possibile utilizzare un'applicazione metadirectory per eseguire il mapping degli account ai rispettivi account nella foresta legacy.

Per fornire ai nuovi account utente l'accesso alle risorse nella foresta legacy, è possibile utilizzare gli strumenti di metadirectory per identificare i gruppi di risorse all’interno dei quali sono stati concessi gli accessi agli account legacy degli utenti e quindi aggiungere i nuovi account degli utenti a tali gruppi. A seconda della strategia di gruppo nella foresta legacy, potrebbe essere necessario creare gruppi locali di dominio per l'accesso alle risorse oppure convertire i gruppi esistenti in gruppi locali di dominio per consentire l'aggiunta dei nuovi account ai gruppi di risorse. Concentrandosi prima sulle applicazioni e i dati più critici e sulla migrazione al nuovo ambiente (con o senza cronologia SID), è possibile limitare la quantità di lavoro speso nell'ambiente legacy.

Server e workstation

In una migrazione tradizionale da una foresta Active Directory a un'altra, la migrazione dei computer è spesso relativamente semplice rispetto alla migrazione di utenti, gruppi e applicazioni. A seconda del ruolo del computer, la migrazione a una nuova foresta può essere semplice così come separare un dominio precedente e aggiungerne uno nuovo. Tuttavia, la migrazione di account computer intatti in una foresta incontaminata sconfigge lo scopo di creare un ambiente nuovo. Invece di eseguire la migrazione di account computer (potenzialmente compromessi, non configurati correttamente oppure obsoleti) in una nuova foresta, è consigliabile installare server e workstation nel nuovo ambiente. È possibile eseguire la migrazione dei dati dai sistemi nella foresta legacy ai sistemi nella foresta incontaminata, ma non dei sistemi che ospitano i dati.

Applicazioni

Le applicazioni possono presentare la sfida più significativa in qualsiasi migrazione da una foresta a un'altra, ma nel caso di una migrazione "nonmigratoria", uno dei principi più fondamentali da applicare è che le applicazioni nella foresta incontaminata devono essere aggiornate, supportate e installate di recente. È possibile eseguire la migrazione dei dati dalle istanze dell'applicazione nella foresta precedente, se possibile. Nelle situazioni in cui un'applicazione non può essere "ricreata" nella foresta incontaminata, è consigliabile prendere in considerazione approcci come la distruzione creativa o l'isolamento delle applicazioni legacy, come descritto nella sezione seguente.

Implementare la distruzione creativa

La distruzione creativa è un termine preso in prestito dal linguaggio economico che descrive lo sviluppo economico creato dalla distruzione di un ordine precedente. Negli ultimi anni, il termine è stato applicato alla tecnologia dell'informazione. In genere si riferisce a meccanismi attraverso i quali l'infrastruttura precedente viene eliminata, non aggiornandola, ma sostituendola con qualcosa di completamente nuovo. Il Gartner Symposium ITXPO del 2011 riservato a CIO e dirigenti IT senior ha presentato la distruzione creativa come uno dei suoi temi chiave per la riduzione dei costi e l'aumento dell'efficienza. I miglioramenti della sicurezza sono possibili come crescita naturale del processo.

Ad esempio, un'organizzazione può essere costituita da più business unit che utilizzano un'applicazione diversa che esegue funzionalità simili, con diversi gradi di modernità e supporto fornitore. Storicamente, l'IT potrebbe essere responsabile della gestione separata dell'applicazione di ogni business unit e gli sforzi di consolidamento consistono nel tentare di individuare quale applicazione offre le migliori funzionalità e quindi eseguire la migrazione dei dati in tale applicazione rispetto ad altre.

Nella distruzione creativa, invece di mantenere applicazioni obsolete o ridondanti, si implementano applicazioni completamente nuove per sostituire i dati precedenti, eseguire la migrazione dei dati nelle nuove applicazioni e rimuovere le applicazioni precedenti e i sistemi in cui vengono eseguiti. In alcuni casi, è possibile implementare la distruzione creativa delle applicazioni legacy distribuendo una nuova applicazione nella propria infrastruttura, ma, ove possibile, è consigliabile convertire l'applicazione in una soluzione basata sul cloud.

Distribuendo applicazioni basate sul cloud per sostituire le applicazioni interne legacy, non solo si riducono le attività di manutenzione e i costi, ma si riduce la superficie di attacco dell'organizzazione eliminando i sistemi legacy e le applicazioni che presentano vulnerabilità per gli utenti malintenzionati da sfruttare. Questo approccio offre a un’organizzazione un modo più rapido di ottenere le funzionalità desiderate eliminando simultaneamente le destinazioni legacy nell'infrastruttura. Anche se il principio della distruzione creativa non si applica a tutti gli asset IT, offre spesso un'opzione praticabile per eliminare i sistemi e le applicazioni legacy, distribuendo contemporaneamente applicazioni affidabili e sicure basate sul cloud.

Isolamento di sistemi e applicazioni legacy

Un aumento naturale della migrazione di utenti e sistemi critici per l'azienda a un ambiente incontaminato e sicuro è che la foresta legacy conterrà informazioni e sistemi meno preziosi. Anche se i sistemi e le applicazioni legacy che rimangono nell'ambiente meno sicuro possono presentare un elevato rischio di compromissione, rappresentano anche una gravità ridotta di compromissione. Attraverso il ri-homing e la modernizzazione degli asset aziendali critici, è possibile concentrarsi sulla distribuzione di una gestione e un monitoraggio efficaci, senza dover gestire le impostazioni e i protocolli legacy.

Rimuovendo tali sistemi dai domini in cui hanno forzato l'implementazione delle impostazioni legacy, è possibile aumentare successivamente la sicurezza dei domini configurandoli per supportare solo i sistemi operativi e le applicazioni correnti. Tuttavia, quando possibile è preferibile rimuovere le autorizzazioni di applicazioni e sistemi legacy. Se la rimozione delle autorizzazioni non è semplicemente fattibile per un piccolo segmento della popolazione legacy, segregarla in un dominio separato (o foresta) consente di eseguire miglioramenti incrementali nel resto dell'installazione legacy.

Semplificazione della sicurezza per gli utenti finali

Nella maggior parte delle organizzazioni, gli utenti che hanno accesso alle informazioni più sensibili a causa della natura dei loro ruoli nell'organizzazione hanno spesso il minor tempo necessario per apprendere restrizioni e controlli di accesso complessi. Anche se è necessario avere un programma di formazione sulla sicurezza completo per tutti gli utenti dell'organizzazione, è necessario concentrarsi anche su un uso quanto più intuitivo possibile dei sistemi di sicurezza implementando controlli trasparenti e semplificando i principi a cui gli utenti si rifanno.

Ad esempio, è possibile definire un criterio in cui i dirigenti e altri VIP devono utilizzare workstation sicure per accedere a dati e sistemi sensibili, consentendo loro di utilizzare gli altri dispositivi per accedere a dati meno sensibili. Si tratta di un principio semplice che gli utenti devono ricordare, ma è possibile implementare un certo numero di controlli back-end per applicare tale approccio.

È possibile usare Authentication Mechanism Assurance per consentire agli utenti di accedere ai dati sensibili solo se hanno eseguito l'accesso ai propri sistemi sicuri usando le smart card, e possono utilizzare le restrizioni IPsec e dei diritti utente per controllare i sistemi da cui possono connettersi ai repository di dati sensibili. È possibile implementare il controllo dinamico degli accessi per limitare l'accesso ai dati in base alle caratteristiche di un tentativo di accesso, convertendo le regole aziendali in controlli tecnici.

Dal punto di vista dell'utente, l'accesso ai dati sensibili da un sistema protetto "si limita a funzionare" e il tentativo di farlo da un sistema non sicuro "si limita a non funzionare". Tuttavia, dal punto di vista del monitoraggio e della gestione dell'ambiente, si contribuisce a creare modelli identificabili nel modo in cui gli utenti accedono a dati e sistemi sensibili, semplificando il rilevamento di tentativi di accesso anomali.

Negli ambienti in cui la resistenza degli utenti a lunghe password complesse ha causato criteri di password insufficienti, in particolare per gli utenti VIP, considerare approcci alternativi all'autenticazione. Gli approcci alternativi includono smart card (che sono disponibili in diversi fattori di forma e con funzionalità aggiuntive per rafforzare l'autenticazione), controlli biometrici come lettori a scorrimento rapido delle dita o anche dati di autenticazione protetti da chip TPM (Trusted Platform Module) nei computer degli utenti. L'autenticazione a più fattori non impedisce attacchi con furto di credenziali nel caso un computer sia già compromesso. Tuttavia, offrendo agli utenti controlli di autenticazione facili da usare, è possibile assegnare password più affidabili agli account di utenti per i quali i controlli tradizionali di nome utente e password sono difficili da utilizzare.