Security Compliance checking with PowerShell
This is just a quick intro to a number of short articles that I will post in this blog over the coming months where I will show you some examples on how to check Security Compliance using PowerShell scripts. The main focus will be on the different roles offered by Windows Server 2008 R2 (DNS, DHCP, IIS, etc) and how to check if they are configured in a secure way (using PowerShell scripts).
Quick note: I work as a Microsoft consultant with many large organizations to help them improve their security and the last couple of years I've been mainly working with NATO's Computer Incident Response Center (NCIRC). Although the security best-practices outlined in these posts are pulled from the Security Compliance Manager documents, the rest of the information you will find in these posts is not directly endorsed by the Solution Accelerators team (although, through my work at NCIRC, I have a very good working relationship with that team).
Have you already seen the Security Compliance Manager?
For anybody who is involved in defining and creating security policies for large organizations, this is THE tool for you:
"The Microsoft Security Compliance Manager (SCM) tool is the next evolution of the Microsoft Security Compliance Management Toolkit (SCMT) Series. We've taken our extensive guidance and documentation and incorporated it into this new tool, enabling you to access and automate all of your organization's security baselines in one centralized location."
SCM incorporates all the data and documents of the former Microsoft security guides and Group Policies into a single database, which can be accessed and managed through the SCM user-interface. The tool allows you to import settings, customize them, create multiple versions and export them into different formats, such as Group Policies, System Center Configuration Manager Desired Configuration Management (SCCM/DCM) packs and others. Do you want to learn more about it? Follow the link above...
So, for 90% of the security guidance, SCM helps you with defining, implementing (GPO) and checking compliance (SCCM/DCM) with your security policies. The remaining 10% is documented as best-practices in the security documents that are part of the security baselines in SCM.
This 10% is however becoming increasingly important. The Windows platform, as well as the most of the server-applications (Exchange, Office, SQL, ...) are designed to be secure by default. Way back in time, during the Windows NT4 prehistoric times, configuring security policies was a number 1 priority for anybody in IT Security. There were lots of settings that could be set to a stricter value (given that you wanted to sacrifice some application or network compatibility (e.g. with Windows 95)).
This has however dramatically evolved. When comparing nowadays, the most strict settings (so called SSLF: Specialized Security, Limited Functionality) with the default (out-of-the-box) settings, you will see a decreasing difference going from Windows 2000 to Windows 2008 R2 or Windows 7.
Does this imply, that you no longer have to define security policies?
Of course not! It's not because the initial installation of your system is secure, that it will stay secure over time. Admins might "temporary" change some settings for testing purposes (but forget to reset it); a system might have been upgraded from an old OS version and this might have left some old (less secure) settings in place; an application or installation package might have changed some of the settings, etc ... Through GPOs (defined in SCM), you can ensure that your systems stay secure.
So, what to do with the remaining 10% of the security best-practices that cannot be automatically enforced through GPO or other means?
Well, that's what I try to tackle in this blog in the coming months. Most of the best-practices documented in SCM are either architectural guidance for a specific role (e.g. how to separate your external from your internal DNS) or specific role configurations (e.g. how to configure a server to avoid DNS cache poisoning). The focus in this blog will be on automating the compliancy checks on the role configurations using PowerShell scripts...
For those not familiar with PowerShell, well, there's tons of information out there. Some links you can find in near future in a separate post. One book I liked particular myself (certainly if you have to start from scratch with PowerShell) is "Windows PowerShell 2.0 Administrator's Pocket Consultant" by William Stanek.
So, stay tuned ... next post will be: validating security of a DNS configuration using PowerShell scripts.