In the first blog of this series, we discussed how changes to groups with extensive privilege within an Active Directory (AD) environment are the target for many hackers. However, this is just one of the problems with monitoring critical systems.
Challenge 2 – Group Policy Changes
Group Policies are used to control and manage settings across all computers joined to Active Directory. This includes critical security settings such as who has administrative access to systems and numerous others. A simple change to a Group Policy Object can have severe security impacts or cause production outages.
It seems logical that monitoring these changes is critical. However, Active Directory has no capabilities for logging the changes made to Group Policy settings. When a Group Policy is changed you will see an event such as the one shown in the image on the right.
This event provides some meaningful information such as who made the change and the identifier of the Group Policy Object. However, there is valuable information lacking from these events.
Group Policies support hundreds of out-of-the-box and custom settings. A change can range from setting a user’s browser homepage to providing the entire organization administrative control of a critical machine. These events provide no indication of the setting that was changed, and what it was changed to. Therefore, it is necessary to implement additional controls to keep track of GPO changes. Ultimately, the events generated provide little value outside of a prompt to launch an investigation into the change.
Source of Change
The event also does not display where the change came from. Similar to group changes, the source of a Group Policy change provides critical security context about the intent of the change. Most changes should be coming from a select few locations. Being able to identify and react to changes that come from abnormal locations is very important to quickly detect attacks.