Both of these constructs are to return the SACL entries for registry or file objects where they have been defined. These are somewhat related to the regkeyeffectiverights53 and fileeffectiverights53 constructs in that the item structure looks similar, though in these cases we are dealing with the effective rights or permissions of the registry or file object. The reason I bring up the effectiverights constructs is that they have a specific scope of entries that are returned when performing a pattern match (i.e., ‘.*’) on the object. For the effectiverights constructs, they do not return every user and group on the system. Instead, they only return the users and groups who have effective rights or permissions on the registry or file object being targeted. This works for the effectiverights constructs.
The auditedpermissions constructs are supposed to be pulling back the contents of the SACL (or the audit entries) for a targeted registry of file object. Based on the effectiverights constructs, you would think that the returned list would be those accounts and their audit settings that are currently within the SACL when performing a pattern match operation. However, it seems that the currently returned list of accounts is limited/scoped to the same accounts who have effective rights or permissions (the same user and/or group accounts returned with the effectiverights constructs using a pattern match). What this means is that if I create an auditing entry for an account that does not have effective rights or permissions to a registry or file object, I cannot get the audit settings for that account using a pattern match. If you use an equals operation and target the specific SID for the same account, the audit settings for that account will be returned appropriately.
I believe that the pattern match scope that is currently used is incorrect. The pattern match scope should instead be the acounts listed in the SACL. In most cases this will be empty by default.
One common example to highlight the above issue is that some configuration guidance suggests using the Everyone special user when setting some registry and file auditing SACLs. Generally, the Everyone group is not used in DACLs (permissions). This would result in the above described scenario. I also noticed that this occurs on our default MITRE installations. On my laptop, the audit settings have been defined for some of the executables in the Windows directory (e.g., notepad.exe and regedit.exe). The SACL on my system for these files contains the Everyone group, while the DACL does not contain the Everyone group.
I attached an OVAL object that uses a pattern match = .* to collect the SACL on HKLM\SOFTWARE.