PCI DSS 10.2 says, "Implement automated audit trails for all system components to reconstruct the following events:" and 10.2.2 continues, "All actions taken by any individual with root or administrative privileges."
I am struggling to make this happen on our Windows machines (Windows 7, 8 & 2008R2).
OSSEC can log changes to files and registry entries, but it is a poor fit for this requirement since it does not log who made the change.
I tried to use the built in audit policy in Windows, per this:
http://blog.jakeeliasz.com/2014/04/03/part-1-audit-trails-in-pci-dss-v3-0-logging-in-windows/
So I ran secpol.msc, went to "Local Policies" > "Audit Policy" and enabled Success and Failure for all entries.
Next, I picked a rarely touched data folder as a test: "Properties" > "Security" > "Advanced" > "Auditing" > "Add"
Select a principal: Administrators
Type: All
Access: Full control
Advanced Permissions: Only write, create and execute-related permissions checked.
This does log all access to files in the folder, but the problem is that the event log now gets flooded with entries from not only the explicit members of the Administrators group, but also seemingly from any process with admin privileges (such as the Anti Virus processes).
Also, note that the above is only for one rarely accessed folder – I will have to add logging for all system folders, etc. as well, which will make the log flooding much worse.
How can I log all activities taken by admin users (per 10.2.2 above) without all this extra noise?
Also, the above auditing covers file system changes, but how to audit key registry changes?
I would appreciate advice on how to comply with the above requirement (preferably w/o spending a lot of money on a commercial product).
Best Answer
The problem is that the default Administrators group implicitly includes the built-in 'NT Authority\SYSTEM' as well as potentially other built-in accounts.
If auditing is enabled on the default Administrators group the system will generate the desired events, alongside with tons of undesirable events relating to system activity, whether someone is logged on or not.
Solution is to create an Admins group and explicitly make administrative accounts that are owned by individuals members of that group. Then audit that group's activity.