2

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).

Zek
  • 568
  • 3
  • 10
  • 24
  • Can you create a GPO scoped to the Admin user group/s within your domain? The group would have to exclude desktop service accounts (like anti virus) – xXhRQ8sD2L7Z Sep 07 '15 at 03:17
  • @ST8Z6FR57ABE6A8RE9UF These are all stand-alone machines (no AD). Also, the Principal I selected in the Audit Policy is the "Administrators" group, which only includes the actual admin users, so shouldn't that be the same thing in effect? – Zek Sep 07 '15 at 03:31
  • Under what account are the services running? It could be caused by builtin accounts inheriting permissions of the Administrators group. See http://superuser.com/questions/554760/to-what-group-nt-authority-system-user-belongs-to – xXhRQ8sD2L7Z Sep 07 '15 at 04:31
  • I think the question itself is administrative technical detailsey enough to not migrate but also check out our sister site [security.se] where a number of similar PCI-DSS questions have been handled. – Scott Pack Sep 07 '15 at 15:26
  • @ST8Z6FR57ABE6A8RE9UF It (ESET) is logging in as Local System, which based on your link is an implicit member of the local Adminstrators group. But I do not see how an AV service could run properly without the highest access, since it needs to intercept calls to privileged objects, etc. Any suggestions for how to solve this dilemma? – Zek Sep 07 '15 at 23:15
  • As a test, create a group locally implicitly containing users that you want audit trails for and use that as the principal in your policy. How does it go? – xXhRQ8sD2L7Z Sep 08 '15 at 04:14

1 Answers1

0

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.

Guest
  • 1