Security, et al

Unstructured data access governance is a big compliance concern. Unstructured data is difficult to secure because there’s so much of it, it’s growing so fast and it is user created so it doesn’t automatically get categorized and controlled like structured data in databases. Moreover unstructured data is usually a treasure trove of sensitive and confidential information in a format that bad guys can consume and understand without reverse engineering the relationship of tables in a relational database.

 

Most of this unstructured data is still to be found on file shares throughout the network and file system permissions are the main control over this information. Therefore knowing when permissions change n unstructured is critical to governance and control. File permissions should normally be fairly static but end-users are by default the owner of files and subfolders they create and can therefore change permissions on those files. And of course administrators can change permissions on any object. Either way you need to know when this happens and I’m going to show you how with the Windows Security Log.

 

First we need to enable the File System audit subcategory. You’ll find this policy in any group policy object under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access. Enable File System for success. (By the way, make sure you also enable Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings to override audit policy category settings to make sure your audit policy takes effect. Now you need to enable object level auditing on the root folders containing your unstructured data. For instance if you have a shared folder called c:\files, go to that folder in Windows Explorer, open the security tab of the folders properties, click Advanced and select the Auditing tab. Now add an entry for Everyone that enables successful use of the Change permissions as shown below.

 

 

At this point Windows will begin generating 2 events each time you change permissions on this folder or any of its subfolders or files.  One event is the standard event ID 4663, “An attempt was made to access an object”, which is logged for any kind of audited file access like read, write, delete, etc.  That event will show WRITE_DAC under the Access Request Information but it doesn’t tell you what the actual permission change was.  So instead, use event ID 4670, “Permissions on an object were changed”, which provides the before and after permissions of the object under Permissions Change as shown in the example below.

 

 

I know what you are thinking. “What does D:AI(A;ID;FA;;;AU)(A;ID;FA;;;WD)(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU) mean?” That my gentle reader is the original access control list of asdf.txt but in the very cryptic Security Descriptor Definition Language (SDDL). SDDL definitely isn’t something you want to manually parse and translate on a regular basis. But you can when necessary.

 

Look for the “D:” which is close to the beginning of the string or even the very beginning in this case. “D:” means Discretionary Access Control List (DACL) which are the actual permissions on the object as opposed to other things that show up in a security descriptor – like owner, primary group and the audit policy (aka SACL). Until you hit another letter-colon combination like “S:” you are looking at the object’s permissions. An ACL is made up of Access Control Entries which correspond to each item in the list you see in the Permissions tab of an object’s properties dialog. But in SDDL before listing the ACEs comprising the ACL you will see any flags that affect the entire ACL as a whole. In the example above you see AI as the first element after D:. AI stands for SDDL_AUTO_INHERITED which means permissions on parent objects are allowed to propagate down to this object.

 

Now come the ACEs. In SDDL, each ACE is surrounded by parenthesis and the fields within it delimited by semicolons.  The first ACE in the event above is (A;ID;FA;;;AU). The first field tells you what type of ACE it is – either A for allow or D for deny. The next field lists any ACE flags that specify whether this ACE is an inherited ACE prorogated down from a parent object and if and how this ACE should propagate down to child objects. The only flag in this ACE is ID which means the ACE is in fact inherited. The next field lists the permissions this ACE allows or denies.  In this example FA stands for all file access rights.  The next 2 fields, Object Type and Inherited Object Type, are always blank on file system permissions (hence the 3 semicolons in a row); they are only used places like Active Directory where there are different types of objects (user, group, computer, etc) that you can define permissions for. Finally, the last field is Trustee and identifies the user, group or special principal begin allowed or denied access. Here you will either see the SID of the user or group if the ACE applies to a so-called “well-known” SID you’ll the corresponding acronym. In this example AU stands for Authenticated Users.

 

Event ID 4670 does a great job of alerting you when permissions change on an object and telling you which object was affected and who did it. To go further and understand what permissions where actually changed you have to dive into SDDL. I recommend Ned Pyle’s 2-part TechNet blog, The Security Descriptor Definition Language of Love for more information on SDDL.