Criterio account amministratori di dominio (dopo il controllo PCI)

Uno dei nostri clienti è una società PCI di livello 1 e i loro revisori hanno formulato un suggerimento in merito a noi come amministratori di sistema e ai nostri diritti di accesso.

Amministriamo la loro infrastruttura interamente basata su Windows di circa 700 desktop / 80 server / 10 controller di dominio.

Stanno suggerendo di passare a un sistema in cui abbiamo tre account separati:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Dove WS è l'account che accede solo a WorkStation, è un amministratore locale su Workstation
• Dove SRV è l'account che accede solo ai server non DC, è l'amministratore locale dei server
• Dove DC è l'account che accede solo ai controller di dominio, in realtà un account amministratore di dominio

Sono quindi in atto criteri per impedire l'accesso al tipo di sistema errato dall'account sbagliato (che include la rimozione dell'accesso interattivo per gli account dell'amministratore di dominio su macchine non DC)

Questo serve a prevenire la situazione in cui una workstation compromessa può esporre un token di accesso degli amministratori di dominio e riutilizzarlo contro il controller di dominio.

Questa sembra essere non solo una politica molto invadente per le nostre operazioni quotidiane, ma anche una notevole mole di lavoro, per affrontare quello che è un attacco / exploit relativamente improbabile (questa è la mia comprensione comunque, forse fraintendo la fattibilità di questo exploit) .

Sono interessato a conoscere le opinioni di altri amministratori, in particolare quelli qui che sono stati coinvolti in una società registrata PCI e tu hai esperienze con raccomandazioni simili. Quali sono le vostre politiche relative agli accessi degli amministratori.

Per la cronaca, al momento disponiamo di un account utente di dominio che utilizziamo normalmente, con un account amministratore di dominio che eleviamo anche quando abbiamo bisogno dei diritti aggiuntivi. In tutta onestà siamo tutti un po 'pigri e spesso utilizziamo semplicemente l'account Domain Admin per le operazioni quotidiane, anche se questo è tecnicamente contrario alle nostre politiche aziendali (sono sicuro che capisci!).

Sono a un fornitore PCI di livello 1. Abbiamo qualcosa di simile a posto, con alcune differenze.

I revisori stanno effettivamente cercando di descrivere un problema molto reale, ma stanno facendo un lavoro incredibilmente scarso spiegando le implicazioni e l'analisi dei bisogni.

Ora è più efficace compromettere un sistema usando un hash di una password o un token esistente. In parole povere, il tuo aggressore non ha più bisogno del tuo nome utente e password. Ora ci sono modi più semplici per attaccare un sistema. In nessuna circostanza dovresti assumere o concludere che questo tipo di attacco è improbabile. Gli attacchi di hash sono ora il vettore di attacco defacto .

Gli attacchi hash sono in realtà peggiori con gli account di smart card, il che è ironico, perché la maggior parte delle persone si aspetta che l'implementazione di smart card aumenti la sicurezza di un sistema.

Se un account viene compromesso a causa di un attacco "passa l'hash", la solita risposta è quella di cambiare la password dell'account. Ciò modifica l'hash utilizzato per l'autenticazione. Inoltre, una normale scadenza / modifica della password può far emergere un'incursione, poiché l'hash dell'attaccante potrebbe non riuscire. Tuttavia, con le smart card, la password è "gestita dal sistema" (l'utente non immette mai la password per l'autenticazione), quindi l'hash non cambia mai. Ciò significa che con gli account di smart card, un'incursione può passare inosservata per molto più tempo rispetto a un account che utilizza una password.

Ecco alcune mitigazioni che prenderei in considerazione:

• Per gli account abilitati per smart card, utilizzati da molte grandi aziende per account con privilegi elevati, modificare la password dell'account a intervalli frequenti. Questo cambia l'hash. È inoltre possibile modificare l'hash abilitando l'account tramite una-smart card, quindi abilitandola nuovamente. Microsoft lo fa ogni 24 ore, ma è necessario valutare il potenziale impatto che ciò può causare nel proprio ambiente e stabilire una pianificazione sana in modo da non creare ulteriori problemi.

• Per le stazioni di lavoro, non utilizzerei affatto gli account di dominio a fini di amministrazione, se possibile. Abbiamo un account locale che può essere utilizzato per elevare per operazioni di tipo UAC. Ciò soddisfa il 99,9% della maggior parte dei requisiti di elevazione. Le workstation tendono ad essere vettori di attacchi caldi, a causa della mancanza di un controllo delle modifiche irreversibile e dell'esistenza di Java JRE e Flash.

  Questo approccio funziona per noi in quanto disponiamo di un meccanismo formale per la gestione e l'applicazione della password per gli account locali e che la password è univoca su ciascun sistema e che esiste un metodo sicuro per richiedere la password. Esistono anche applicazioni commerciali che possono eseguire questa funzione.

• Se non è possibile fornire una soluzione di account locale per le workstation, sì, è necessario utilizzare un account di dominio separato per l'accesso amministrativo alle workstation e tale account non deve essere utilizzato per l'accesso amministrativo ai server. Un'altra opzione potrebbe essere quella di utilizzare strumenti di gestione del supporto remoti e non interattivi che utilizzano LocalSystem per eseguire attività e un meccanismo di autenticazione separato da Windows.

• Per gli account con privilegi più alti (Enterprise Admin, Domain Admin, ecc.), Utilizzare solo un server jump. Questo server sarebbe soggetto alla sicurezza più restrittiva, controllo delle modifiche e controllo. Per tutti gli altri tipi di funzioni di tipo amministrativo, considerare di avere un account amministrativo separato. Il server di salto deve essere riavviato ogni giorno per riavviare i token di processo dal processo LSA.

• Non eseguire attività amministrative dalla workstation. Utilizzare un server rinforzato o un server jump.

• Prendi in considerazione l'idea di ripristinare facilmente le VM come jump box, che possono essere ripristinate per cancellare la memoria dopo ogni sessione.

Ulteriori letture:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Rapporto Microsoft Security Intelligence, Volume 13, gennaio - giugno 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Leggi la sezione: "Difesa dagli attacchi Pass-the-Hash".

Sconfiggi temuti attacchi pass-the-hash
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753