“Secure by Default” and Hardening Your Windows Configurations

I had a good email conversation last week with someone on the PowerShell team at Microsoft, in the wake of the release of our Desired State Configuration CSE. The gist of his question was around how users could protect the configuration information held within the DSC documents that got deployed via Group Policy. He mentioned that “Secure by Default” should be the mantra for all things related to Windows management these days. This led to an interesting discussion about protecting configuration information–whether it be security hardening-related or just application configurations deployed via DSC or Group Policy. As I’ve written before, DSC natively supports both pushing and pulling of configuration documents. These configuration documents take the form of Managed Object Format (MOF) files that are simply clear-text representations of the “things” you’re trying to configure. These could be application settings for a web server you want to configure, or they could be operating system security settings. So what’s the risk here?

Seeing is Knowing

The substance of the conversation relates to the risks of being able to “know” the security posture of my Windows desktops or servers. Specifically, does a would-be “bad guy” gain any advantage in being able to read the security or application settings that are being applied to my Windows systems, even if they cannot change those settings? Of course, the answer is “yes”–in this case, knowledge really IS power, because an attacker that can see your system configurations can know where to target their attacks. Knowing which components you’ve installed (or not installed) and which knobs and switches you’ve turned in the OS configuration can help focus an attacker’s efforts in a way that is not terribly good for you. In addition, if your configurations are applied equally across most or all of your machines, then a compromise on one machine is likely to work on all.

It’s Just Configuration Information–Who Cares?

This whole question around protecting DSC information came up in a blog posting around DSC configurations in a pull server environment, and how you should treat the GUIDs that are associated with a given MOF file. The same question comes up when you are distributing those MOF files using our DSC CSE freeware via GP, and interestingly, though it’s been the case for a long time, the very same question should be raised when you are using GP itself to distribute GP settings configuration–and especially security hardening configuration. This was brought home most publicly recently by the fix that Microsoft issued for Group Policy Preferences password support that was commonly used to set local account passwords on masses of Windows machines. The problem was essentially that a) the encryption key for the password that was stored in the GPO’s SYSVOL portion was publicly published by Microsoft and b) simple read access to the GPO was enough to get the encrypted password and decrypt it, thus potentially exposing local account passwords on any machines that received that policy.

So what’s the issue with GP? Well, as you know, by default, when you create a GPO, Windows grants that GPO Read and Apply Group Policy permissions for the Authenticated Users group on the GPO (as shown below).

 

 

 

 

 

 

 

 

Authenticated Users includes any computer (yes, computers!) or user accounts that fall within the GPO’s targeting (e.g. within the domain or OU where the GPO is linked). A computer or user account has to be able to read a GPO in order to process it–that’s by design in the GP engine. In fact, read access is required to process a GPO AND to edit it.   But if a computer or user account can read a GPO, then they can read the settings contained in that GPO. So for example, if you had a GPO linked to your domain that delivers basic hardening to all of your Windows desktops and servers, and you left the default security filtering in place (Authenticated Users, Read and Apply Group Policy) then all users (and I mean all users, including both your server admins and your folks working in the mailroom) would be able to read the security posture that you’ve deployed to your systems. This may have been OK in the old days, when GP was first built. It’s not so ok now. So, regardless of whether you’re deploying DSC settings via our GP CSE or GP settings via GP, configuration details and especially security posture should be shown on a “need to know” basis, because you never know who may be looking! OK, so what do we do about it in GP-land, where the default is not “secure by default”, but rather, “open to everyone”

Best Practices for Getting to Secure Configurations

GP’s own security model and targeting paradigm holds the answer to the above question. And the answer applies equally well to protecting DSC configurations using our Client Side Extension. Namely, sensitive configuration can and should be shown on a “need to know” basis. And who needs to know? Only the servers receiving those GPO-based configurations and the few privileged admins that need to edit them. So how do we do that?

Often, when you deploy a computer-based GPO to a set of servers (or workstations), you will link that GPO to an OU containing those computer objects and call it a day, as shown here:

 

 

 

 

 

 

 

Note that the security filtering for that GPO is set to the default–Authenticated Users–which includes all computer objects in the OU(s) where it’s linked. Let’s assume that GPO contains security settings. If that GPO is linked to multiple OUs, then computers in all of those OUs will be able to read those settings, and, thus, anyone that has control over those computers (legitimately or otherwise) will also be able to read those settings. And of course, because all of those computers that process those security settings will have the same security posture, any weakness in that posture that is discovered by someone on one computer, will apply to every computer that has those settings. Great! Well, no, not really. In fact, not so great. You can extrapolate this scenario to settings other than basic security, to application configuration settings or even user settings.

The goal, then, is to compartmentalize what any given server or group of servers knows about other servers’ configurations. So instead of just linking your sensitive GPOs to an OU and calling it a day, I’m suggesting that you start modifying the default security filtering for every GPO that contains such configurations, such that only those computers that need to process that GPO, have permissions to read it.

How do you do that? Easy! From GPMC, with your sensitive GPO selected, as shown in the figure above, simply select “Authenticated Users” under the Security Filtering section and press the “Remove” button. Then, press the “Add” button and browse to the security group containing the computers that will process that GPO, as shown here:

 

 

 

 

 

 

You will have to ensure that you maintain the membership of that security group, so that if you add new servers to the domain, they are also added to that group. But this approach ensures that only the servers that must process this GPO, will be able to read it. Of course, you do still need to contend with other delegated rights on the GPO. You can see this by selecting the “Delegation” tab  in GPMC with the GPO selected, as shown here:

 

 

 

 

 

 

 

Just as with GPO processing, you should limit the users and groups that can read and edit a GPO to only those who really need to.  Windows will grant Domain Admins, Enterprise Admins and the “Enterprise Domain Controllers” group permissions on GPOs by default. But you can also add other discretionary groups to GPO delegation. My recommendation is to only do that for the groups that are truly responsible for managing those GPOs. Remember–the key here is to reduce the visibility of critical, security or application related GPOs to only those that need to access that information for GPO processing or management.

I’ll make a final comment on this point. An administrator needs read permissions on a GPO in order to link that GPO. So it’s just as important to manage who can link GPOs as it is to manage who can read them. These rights should not be given out widely.

A Note About RSOP

Resultant Set of Policy (RSoP) is the mechanism by which administrators can collect what GPO settings have been deployed to a target system. The ability to collect RSoP data is delegated within GPMC at the domain or OU levels. This ability should also be controlled. If an administrator can collect RSOP data from a target, it’s just as good as being able to read the GPO that delivered that data! Unfortunately, RSoP delegation is all or nothing–an administrator can either report on RSoP against a given computer in a given OU or they can’t. You can’t restrict the GPOs that they can see within RSoP reporting.

 

How Does This Help DSC?

Circling back around on the original topic of my conversation with Microsoft, if you are using our DSC Client Side Extension, then you should considering filtering the GPO that delivers those DSC settings just as you would filter sensitive GPO settings. Using security filtering, you can limit a given DSC configuration to only those computers that need to process that configuration and no others. Thus you create “firewalls” between configurations that help limit the damage if a bad guy happens to get onto a server and use it’s configuration metadata to take advantage of it.

 

Darren