I Criteri di gruppo di Windows controllano molti aspetti diversi di una macchina in esecuzione. Non sono sicuro che ci potrebbe essere un unico modo per testare l'ampiezza di ciò che una politica potrebbe coprire.
Il mio approccio è definire un test per ciascun componente della politica (che può essere testato) e utilizzare qualsiasi strumento sia appropriato per eseguire quel test. A volte questo strumento può essere uno script (Powershell, Python, ecc.), Uno strumento pacchettizzato (Nexpose, metasploit, ecc.) O un test manuale (clicca qui e poi lì, ecc.).
L'idea è di trattare la politica di sicurezza come un progetto di sviluppo software e di utilizzare il concetto di "unit test". Ogni nuova "funzione" deve essere testata per il comportamento previsto (fa ciò che sto chiedendo di fare?) E per un comportamento inaspettato (cosa succede quando modifico gli input che controlla?). Questi test sono documentati e i risultati salvati. Quando apporto una modifica alla politica, rieseguo i test e aggiungo i nuovi test appropriati. In questo modo, posso dimostrare che la politica è efficace e ho prove per Change Management e Auditor (quando applicabile). Mi riposo facilmente sapendo che non sto "sperando per il meglio" quando imposto una politica.
Avere questo processo di test documentato significa anche che quando si verifica un incidente di sicurezza, posso escludere il comportamento dimostrato delle politiche e cercare i modi in cui l'incidente si è verificato nonostante il buon esito della politica (in altre parole, posso chiedere , "se tutto ha funzionato, come è potuto accadere?"). O so dove una politica può fallire e posso progettare i processi di mitigazione per sopperire ai punti deboli della politica.
A proposito, utilizzo la stessa procedura per le regole del firewall.