Mantenimento di un ambiente più protetto
Legge numero dieci: La tecnologia non è una panacea. - 10 leggi immutabili dell'amministrazione della sicurezza
Dopo aver creato un ambiente gestibile e sicuro per le risorse aziendali critiche, è essenziale garantire che sia mantenuto sicuro. Sebbene siano stati implementati specifici controlli tecnici per potenziare la sicurezza delle installazioni AD DS, la tecnologia da sola non può assicurare la protezione di un ambiente, a meno che il reparto IT non collabori attivamente con l'azienda per mantenere un'infrastruttura sicura e utilizzabile. Le raccomandazioni generali presentate in questa sezione sono concepite come linee guida da adottare non solo per sviluppare una sicurezza efficace, ma anche per gestire in maniera ottimale il ciclo di vita.
In alcuni casi, il reparto IT potrebbe già godere di un rapporto di collaborazione stretto con le unità aziendali, il che faciliterebbe l'implementazione di questi consigli. Nelle organizzazioni in cui il reparto IT e le unità aziendali non sono strettamente connesse, potrebbe essere necessario ottenere prima il patrocinio esecutivo per gli sforzi volti a stabilire una relazione più solida tra l'IT e le unità aziendali. Il riepilogo esecutivo è concepito per essere un documento utilizzabile autonomamente, adatto per la revisione da parte dei dirigenti, e può essere distribuito ai responsabili delle decisioni all'interno dell'organizzazione.
Creazione di procedure di sicurezza incentrate sull'azienda per Active Directory
In passato, la tecnologia dell'informazione all'interno di molte organizzazioni era vista come una struttura di supporto e un centro di costo. I reparti IT erano spesso isolati dagli utenti aziendali, con interazioni limitate a un modello di richiesta-risposta in cui l'azienda richiedeva risorse e l'IT provvedeva a rispondere.
Con l'evoluzione e la proliferazione della tecnologia, la visione di “un computer su ogni scrivania” si è effettivamente concretizzata in gran parte del mondo, ed è stata addirittura superata dall'ampia gamma di tecnologie oggi disponibili e facilmente accessibili. La tecnologia dell'informazione non è più una funzione di supporto, ma una funzione aziendale fondamentale. Se l'organizzazione non può operare senza servizi IT, allora si affida, almeno in parte, alla tecnologia dell'informazione.
Per sviluppare piani di ripristino efficaci, i servizi IT devono collaborare strettamente con le unità aziendali per identificare non solo gli elementi più critici dell'infrastruttura IT, ma anche le funzionalità aziendali essenziali. Identificando ciò che è fondamentale per l'organizzazione, è possibile concentrarsi sulla protezione dei componenti di maggiore valore. Questo non è un consiglio per trascurare la sicurezza dei sistemi e dei dati di minore valore. Piuttosto, similmente a come si stabiliscono i livelli di servizio per la disponibilità del sistema, si devono definire i livelli di controllo e monitoraggio della sicurezza basandosi sull'importanza delle risorse.
Dopo aver investito nella creazione di un ambiente aggiornato, sicuro e gestibile, l'attenzione può essere rivolta verso una gestione efficace dello stesso, assicurando processi di gestione del ciclo di vita che siano efficaci e guidati non solo dall'IT, ma anche dalle esigenze aziendali. Per raggiungere questo obiettivo, è necessario non solo collaborare con l'azienda, ma investire l'azienda nella "proprietà" dei dati e dei sistemi in Active Directory.
Quando i dati e i sistemi sono aggiunti ad Active Directory senza assegnare i proprietari, sia dal lato aziendale che da quello IT, non esiste una catena di responsabilità definita per il provisioning, la gestione, il monitoraggio, l’aggiornamento e, infine, la rimozione del sistema. Questo comporta infrastrutture dove i sistemi espongono l'organizzazione a rischi, ma non possono essere rimossi poiché non è chiara la titolarità. Per gestire con efficacia il ciclo di vita di utenti, dati, applicazioni e sistemi all'interno dell'installazione di Active Directory, è essenziale aderire ai principi illustrati in questa sezione.
Assegnare un proprietario aziendale ai dati di Active Directory
I dati in Active Directory devono avere un proprietario aziendale designato, cioè un dipartimento o un utente specifico, che funga da punto di contatto per le decisioni relative al ciclo di vita delle risorse. In alcuni casi, il proprietario di un componente di Active Directory sarà un reparto o un utente IT. I componenti dell'infrastruttura, come i controller di dominio, i server DHCP e DNS e Active Directory, saranno probabilmente "di proprietà" dell'IT. Per i dati aggiunti ad AD DS a supporto dell'azienda (ad esempio, nuovi dipendenti, nuove applicazioni e nuovi database di informazioni), deve essere associata un'unità aziendale o un utente specificato.
Indipendentemente dal fatto che si utilizzi Active Directory per registrare la proprietà dei dati direttamente o che si impieghi un database separato per tenere traccia delle risorse IT, nessun account utente deve essere creato, nessun server o workstation dovrebbe essere installato, e nessuna applicazione dovrebbe essere distribuita senza un proprietario chiaramente designato. Cercare di stabilire la titolarità dei sistemi dopo che sono stati distribuiti in produzione può essere complicato nella migliore delle ipotesi e, in alcune situazioni, addirittura impossibile. Pertanto, la titolarità deve essere stabilita al momento dell'introduzione dei dati in Active Directory.
Implementare una gestione del ciclo di vita orientata al business
La gestione del ciclo di vita deve essere implementata per tutti i dati di Active Directory. Ad esempio, quando una nuova applicazione viene introdotta in un dominio di Active Directory, il proprietario dell'applicazione deve attestare, a intervalli regolari, l'uso continuo dell'applicazione. Quando viene rilasciata una nuova versione di un'applicazione, il proprietario dell'applicazione deve essere informato e deve decidere se e quando implementarla.
Se il proprietario aziendale decide di non approvare l'implementazione di una nuova versione di un'applicazione, deve anche essere informato riguardo alla data in cui il supporto per la versione attuale terminerà. Inoltre, deve assumersi la responsabilità di decidere se l'applicazione verrà rimossa o sostituita. Continuare a utilizzare applicazioni legacy non supportate non dovrebbe essere considerata un'opzione.
Quando vengono creati account utente in Active Directory, i relativi manager di riferimento devono essere notificati al momento della creazione dell'oggetto e sono tenuti a confermare la validità dell'account a intervalli regolari. Implementando un ciclo di vita guidato dall'azienda e confermando regolarmente la validità dei dati, le persone più adatte a identificare le anomalie nei dati sono quelle che li esaminano.
Ad esempio, gli utenti malintenzionati potrebbero creare account utente che appaiono legittimi, aderendo alle convenzioni di denominazione e posizionamento degli oggetti dell'organizzazione. Per individuare le creazioni di account, è possibile stabilire una procedura quotidiana che identifichi tutti gli oggetti utente senza un proprietario aziendale assegnato, facilitando così ulteriori indagini sugli account. Se gli utenti malintenzionati creano account e assegnano un proprietario aziendale, l'implementazione di un'attività che notifica la creazione di nuovi oggetti al proprietario aziendale designato può consentire a quest'ultimo di verificare rapidamente la legittimità dell'account.
È consigliabile implementare approcci simili ai gruppi di sicurezza e distribuzione. Anche se alcuni gruppi potrebbero essere gruppi funzionali stabiliti dall'IT, assegnando un proprietario a ogni gruppo, è possibile recuperare tutti i gruppi di proprietà un utente designato e chiedere all’utente di confermare la legittimità delle sua appartenenza. Analogamente all'approccio utilizzato per la creazione degli account utente, le modifiche possono essere attivate nei gruppi di report per determinati proprietari aziendali. Più frequentemente un proprietario aziendale conferma la correttezza dei dati in Active Directory, maggiore è la capacità di identificare anomalie, che potrebbero possono indicare delle mancanze nei processi o delle compromissioni effettive.
Classificare tutti i dati di Active Directory
Oltre a registrare un proprietario aziendale per tutti i dati di Active Directory nel momento in cui vengono aggiunti alla directory, è necessario richiedere ai proprietari aziendali di fornire una classificazione per i dati. Ad esempio, se un'applicazione archivia dati critici per l'azienda, il proprietario dell'azienda deve etichettare l'applicazione come tale, in conformità con l'infrastruttura di classificazione dell'organizzazione.
Alcune organizzazioni applicano criteri di classificazione dei dati, etichettandoli in base al potenziale danno che potrebbe derivare da un loro furto o esposizione. Altre organizzazioni implementano una classificazione dei dati in base alla criticità, ai requisiti di accesso e alla conservazione. Qualunque sia il metodo di classificazione dati utilizzato dall'organizzazione, è essenziale che possa essere applicato non solo ai dati contenuti nei file, ma anche a quelli presenti in Active Directory. Se un account utente è considerato VIP, deve essere segnalato nel database di classificazione delle risorse. Questo può avvenire sia utilizzando attributi negli oggetti all'interno di AD DS, sia tramite l'uso di database di classificazione delle risorse separati.
Il modello di classificazione dei dati deve includere una classificazione dei dati di AD DS come la seguente.
Sistemi
Non è consigliabile classificare solo i dati, ma anche i relativi popolamenti del server. Per ogni server, è necessario sapere quale sistema operativo è installato, quali ruoli generali svolge il server, quali applicazioni sono in esecuzione nel server, il proprietario IT di riferimento e il proprietario aziendale di riferimento, se applicabile. Tutti i dati o le applicazioni in un server devono avere una classificazione, e il server stesso deve essere protetto secondo i requisiti dei carichi di lavoro che supporta e le classificazioni applicate ai dati e ai sistemi. È anche possibile raggruppare i server in base alla classificazione dei carichi di lavoro, in modo da identificare rapidamente i server che devono essere i più monitorati e configurati in modo più rigoroso.
Applicazioni
È consigliabile classificare le applicazioni in base alle funzionalità (operazioni eseguite), alla base utenti (che usano le applicazioni) e al sistema operativo in cui vengono eseguite. È consigliabile mantenere i record che contengono informazioni sulla versione, lo stato della patch e qualsiasi altra informazione pertinente. È anche consigliabile classificare le applicazioni in base ai tipi di dati gestiti, come descritto in precedenza.
Utenti
Indipendentemente dal fatto che vengano chiamati utenti "VIP", account critici o che si utilizzi un'etichetta diversa, gli account delle installazioni di Active Directory che hanno maggiori probabilità di essere presi di mira dagli utenti malintenzionati devono essere etichettati e monitorati. Nella maggior parte delle organizzazioni, non è possibile monitorare tutte le attività di tutti gli utenti. Tuttavia, se è possibile identificare gli account critici nell'installazione di Active Directory, è possibile monitorare tali account per verificarne le modifiche, come descritto in precedenza in questo documento.
Inoltre, è possibile iniziare a creare un database di "comportamenti previsti" per questi account, man mano che si procede con le verifiche. Per esempio, se un dirigente accede abitualmente a dati cruciali dell'azienda utilizzando la sua workstation sicura sia dall'ufficio che da casa, ma raramente da altre località, e se si rilevano tentativi di accesso ai suoi dati da un computer non autorizzato o da una località distante, dove sappiamo che il dirigente non si trova attualmente, è possibile identificare e indagare in modo più celere su questo comportamento anomalo.
Integrando le informazioni aziendali con l'infrastruttura, è possibile utilizzare tali informazioni per identificare i falsi positivi. Ad esempio, se i viaggi dei dirigenti sono registrati in un calendario accessibile al personale IT responsabile del monitoraggio dell'ambiente, è possibile confrontare i tentativi di connessione con le posizioni note dei dirigenti.
Immaginiamo che il dirigente A, solitamente ubicato a Chicago, utilizzi una workstation sicura per accedere a dati aziendali sensibili dal suo ufficio, si genera un evento quando un tentativo fallito di accesso ai dati avviene da una workstation non protetta situata ad Atlanta. Quando è confermato che il dirigente si trova ad Atlanta, l'evento può essere gestito contattando il dirigente o il suo assistente per determinare se il tentativo di accesso fallito è dovuto al fatto che il dirigente ha dimenticato di utilizzare la workstation protetta per accedere ai dati. Implementando un programma che sfrutta le strategie descritte nella sezione Pianificazione della Compromissione, è possibile iniziare a sviluppare un database dei comportamenti previsti per gli account più “importanti” nell'installazione di Active Directory. Ciò può agevolare un rilevamento e una risposta più rapidi agli attacchi.