Reducing the Attack Surface with Group Policy
You should be constantly working to reduce your attack surface using reasonable low cost methods and your existing equipment. Reducing your attack surface, often referred to as hardening, is the most cost-effective way to increase your security. In this brief article, we will examine using Microsoft Active Directory (AD) and Group Policy (GP) to reduce the network attack surface. AD and GP are extremely common in network implementations, powerful, and customizable to your specific needs. Since you likely already likely have them, you should make the best use of them that you can. As always you should test any changes made to your network in a lab environment before implementing on a production network.
Before we start using GP to harden end points, we need to make sure that our AD is in order. In the industrial security world, ISA-62443-3-3 talks extensively about identification, authentication, and authorization enforcement, but a good place to start cleaning up your AD is to identify all human users and break them down into groups according to their required Privilege. At a minimum, your AD should be broken down into Administrators and Users. Going forward we’ll assume that your AD is as granular as it needs to be, inactive users are regularly removed, computer and user Organizational Units (OU) are separate, and that you avoid using the default containers and OUs generated by the operating system all together. These are simply best practices for utilizing AD. Once your AD is all in order you can move on to implementation of GP.
I want to look at a simple piece of GP for disabling PowerShell for all users who do not need to access PowerShell. It’s likely that most of your organization doesn’t use PowerShell. A fair number of users probably don’t even know what it is, but hackers love PowerShell. Command line tools are as popular as ever for initiating malicious downloads and altering settings on a specific device. The ability to use PowerShell to download and launch a custom python script that has been obfuscated in a PowerShell command, fit nicely into the Delivery stage of the Lockheed Martin Cyber Kill Chain Model for the simple reason that it’s not a new strategy. While Microsoft is working hard to reduce the potential for PowerShell to be used as a tool during hacks and increase the visibility of activities logged during the use of PowerShell, reducing PowerShell and PowerShell script access to only the users that absolutely require it can make a hacker’s life harder. You can do this using GP in about five minutes. Here’s an example of how I did it on a Server 2012 controlled network. This information can very from server version to server version and should be tested before implementation. While you should configure and test this in a lab, this will get you started:
- Open GP Management Console (GPMC) on your management server.
- In the left pane of GPMC, expand your AD forest, Domains, and then the domain in which you want to create the new GP Objects (GPO) if you have more than one to choose from.
- Under your domain, select the organizational unit you want to turn off PowerShell to and right click it, then select “create a new GPO in this domain and link it here” or “New” depending on your Server version.
- In the New GPO dialog, give the GPO a name and click OK.
- Expand the GPO container in the left pane, right click your new GPO and select Edit from the menu.
From here we’ll select User Configurations> policies> administrative template> system and modify “Don’t run Specific windows applications.” Enable the policy and add powershell.exe and powershell_ise.exe.
While we’re disabling the ability to use PowerShell we could also consider eliminating access to the command prompt for similar reasons, though most would argue it isn’t necessary to do so if you restrict local administrative rights. Your users aren’t local administrators, right? You can also use GP to reduce lateral movement within your network in case of a breach by restricting remote desktop protocol, but that is heavy handed if you are changing your local administrative account passwords regularly. Of course, you’ve done that right too? There’s more, a lot more, that you can do reduce your attack surface beyond password complexity restrictions, and I hope that I’ve shown you that GP can be a good place to start.