After reading my last post Tracking Group Policy Changes: Part 1, you may wonder what LogRhythm can do with the GPO change logs?
Let’s take a look at how this is presented within LogRhythm. As I mentioned previously, LogRhythm has built-in processing policies for almost every log imaginable in Windows, and we go to a very deep level of parsing for each log. Here is the Windows Event ID 5136 log (GPO modified) that was generated earlier:
We immediately see the user who made the modification, the domain in which the modification took place, and the CommonName of the Object that was updated. As discussed earlier, we need to convert this into a human readable format, which we can do with some PowerShell at the command line. Or we could also use LogRhythm’s Data Masking feature to replace the GUID with the appropriate Group Policy Name on the fly should that be desirable. (See Part 3 of this blog for details of how to do this.)
The log is automatically classified as “Access Success” with a Common Event of “Object Modified.”
And here is the Windows Event ID 5137 log (new GPO created) seen within LogRhythm’s console:
So what can we do with this? Well, editing Group Policy is a highly privileged operation within an enterprise, and any unauthorized changes made in a Group Policy linked to the whole domain could have significant impact. So we could raise an alert where a) any changes are made to group policies, b) brand new ones are created, or c) any policy is deleted.
Because we have already done the hard work of parsing out the metadata fields in these log types, it’s trivial to create an AI Engine rule to look for these sort of behaviors and raise an alarm when a new policy is created or an existing one modified.
Here is a rule looking for an existing policy being modified:
Editing the Minimum Password Length as I did earlier then produces an alarm in the console:
We should also create an AI Engine rule looking for GPOs being linked:
And finally, we should also create an AI Engine rule to look for GPOs being deleted:
With these simple rules, we immediately gain visibility of the most significant activities around our Group Policies, and we can keep track on who is making changes—when and where. This is really useful, both from an audit and security perspective, as well as from the operational perspective. We can notify the appropriate persons when changes are made, and we can report for audit purposes on these activities on an ongoing basis.
The final part of this blog post will cover using LogRhythm’s Data Masking feature to replace the GUID with the appropriate Group Policy Name on the fly. This will help us particularly when policies are deleted, because you can no longer look up a GUID once the policy has been deleted, making it difficult to find out what it was that was removed.