Tracking Group Policy Changes: Part 3

This is the final part of the series on tracking group policy changes. As I have mentioned a couple of times, one thing that makes monitoring group policy changes difficult is the fact that Microsoft logs the GUID of the group policy that has been affected, rather than the name of it. For example:

Now I don’t know about you, but I don’t generally keep GUIDs in my head. And while I now know that something has changed, I have no idea which group policy has actually been affected.

However, there is a nice little function available in PowerShell that will enable us to find out what that group policy actually is by querying the GUID:

(([adsisearcher]CN={6AC1786C-016F-11D2-945F-00C04FB984F9}).findone()).properties.displayname

This will return the textual description “Default Domain Controllers Policy.” So far so good. But I don’t want to have to manually run that every time I look at a GPO change log. Also (and this is a big “also”), if the earlier log had been a GPO-deleted log (EventID 5141), the lookup wouldn’t work because the object would have already been deleted. I would only know that something had been deleted, but I wouldn’t be able to find out the name easily.

So, how do we solve for this? We should create a SmartResponse rule that automatically looks up the GUID for us and returns it in an easily consumable format.

First, let’s create a rule that looks for this log type (e.g., where the EventID is 5136 and the object field contains a string that stats with CN = and is followed by a GUID pattern).

AI Engine Rule: Detect GPO GUID:

We can then configure a new SmartResponse “SRGetCNGUID.” This looks up Group Policy Object names based on GUIDs:

This SmartResponse takes the Object field, which contains “CN=[6AC1786C-016F-11D2-945F-00C04FB984F9],CN=Policies,CN=System,CN=Demo,CN=Local” and retrieves the textual description of the group policy.

The Alarm triggers when a change is made to a policy:

Here is the SmartResponse:

And the output of the SmartResponse—both GUID and description:

This can be consumed as an informational message for reference, and it provides us with the mapping of the GUID to its real name in an automated fashion.

LogRhythm offers a Data Masking feature that enables information within a log message to be transformed into a more usable format (or masked to hide sensitive or regulated data). The GUID in this case is a classic example of where the information could do with being transformed into a more usable format.

Now that we have the GUID and description, we can manually place the information into a Data Masking Rule to populate all future logs containing this GUID with the actual name of the GPO.

You can do this in Tools > Administration > Data Masking Rule Manager. The Help file has a section on how to do this. Just search for “data masking.”

More Automation

Alternatively, we can use the ability to pass parameters between SmartResponse plug-ins to allow us to now pass the GUID and description to a second SmartResponse that will update a Data Masking rule automatically.

Let’s configure a second SmartResponse on the Detect GPO GUID AI Engine Rule:

Ensure the “Run Actions” setting above is set to “In the order listed.”

I have created a Data Masking rule that is designed to convert GUIDs in the Windows Security logs into the matching textual description. As you can see, at the moment the rule is enabled, but it has no patterns configured.

Once again, the alarm triggers when a change is made to the policy:

Two SmartResponse Rules are executed:

First, the SRGetCNGUID:

And second, the SRCNDataMasking, which will grab the output of the previous rule and writes it into the Data Masking Rule:

And now here is the updated Data Masking Rule:

Now LogRhythm will use the Data Masking Rule against all new logs that are generated by the GPO audit settings. It will automatically replace the GUID with a textual description:

The original “Detect GPO GUID” AI Engine rule we started with is looking in the Object field for a RegEx pattern that reflects the format of the CN GUID of the GPO. Once it has found a match for the first time and the SmartResponse has done its update to the Data Masking Rule, this match will no longer happen on that GUID. The rule will never trigger again for this GPO.

As you can see below, my initial GPO change triggered the “Detect GPO GUID” Rule and the “Active Directory: Group Policy Change” Rule, but the subsequent two changes shown below to the same group policy only trigger the “Active Directory: Group Policy Change” Rule. The alarm now contains the actual name of the GPO when it fires:

Solution

It’s always about visibility!

The SmartResponse rule enables us to automatically interpret the GPO GUID and turn it into something that is readable by a human. Having visibility of significant activities around group policies in the enterprise is important from both an audit and security perspective. It’s also important from an operational viewpoint.

With these simple rules, we immediately gain visibility into the activities of interest.

When it’s not about visibility, it’s about automation! These two rules working together will keep your Data Masking Rule up to date with new group policies that are being created in the environment. They will also give you a clear audit trail when a group policy is deleted.