Auditing and Securing High Risk Files on Windows Servers
With all of the administrators, security professionals, and auditors that I come in contact with, I seem to get similar questions from each. One question I constantly get is how to properly secure files that are high risk to the organization and track when someone accesses the file successfully and also unsuccessfully? Well, there are many ways to help protect the files that reside on a Windows server, as well as some amazing methods to track when users access the files. The good thing is that all of these security measures use the same security foundations that are built into Windows and if used correctly are very good.
Files are stored on Windows servers under volumes in folders. The folders, of course, can be nested creating a hierarchy of organization, security, or really any other concept that you want to use for accessing and organizing the data. Ideally the data that is stored should have a “common” security model, such that all files and folders under top level folders have the same security. This will allow for ease of configuration, as well as ease of troubleshooting access to these files.
Windows uses NT File System (NTFS) as the technology to store data. NTFS has security access control built directly into the technology, so there is not another layer of security and control beyond the file system. NTFS concepts include:
->ACL – access control list, which is a list of users, computers, and/or groups that have specified access to the data (Figure 1).
->Security Groups – these are groups which have security identifiers (SIDs) from either Active Directory or the local Windows server security accounts manager (SAM).
->SACL – security access control, which is the built-in auditing and tracking of access to data stored on Windows servers (Figure 2).
->Inheritance – the process of configuring access at a top level folder and all subfolders and files inherit these permissions down through the folder structure.
->Explicit permission – the concept that permissions can be placed directly on a folder/file anywhere in the folder structure, which can alter the inherited permissions from that point down.
Establishing the ACL
The ACL is the essential list of “who” has “what” access to the data. If the ACL is not correct there is a potential for a user, who should not have access to the data, to access the data. In order to control the ACL in an efficient and secure manner, the following rules should be utilized when possible.
->No user accounts, domain or local, should be placed on the ACL.
->Groups should be placed on ACLs, not user accounts.
->Computers should be placed into groups , and these groups placed on the ACL.
->Even if a single user needs access to a file, that user should be placed in a group, and this group placed on the ACL.
The ACL has some predefined permissions as you can see in Figure 3. These predefined permissions are really the sum of all or a portion of the detailed permissions which define the overall access to a folder/file, which can be seen in Figure 4.
Ideally only predefined permissions should be utilized to define permissions to a folder/file. This is to eliminate the need for the administrator to go into the detailed permissions to see what is defined and attempt to determine what the actual permissions are for any one user or group.
Tracking/Auditing Access to Files
Now that the permissions are established on the ACL of the folder/file, you might want to track when someone successfully or unsuccessfully accesses a file. This is important to track for high risk, important files for your organization.
Since the files are stored on a Windows server, the tracking of these files is a built-in technology. Above we defined SACL, which is the mechanism used to define “who” you want to track per folder/file and “what” access you want to track.
There is a bit of a trick to getting files audited, as there is a two step process for a Windows server. First, the server must be told that it can track file access. Then, the administrator/owner of the data must indicate directly on the data that it should be audited.
For step one, the server must be configured for Audit Object Access, either Success, Failure, or both. In order to configure this for the server either the local group policy or a Group Policy Object (GPO) from Active Directory needs to be configured. For local group policy access you would run the gpedit.msc command, and for Active Directory GPOs you would use the GPMC.
Once you have the group policy or GPO in the editor, you would expand Computer Configuration/Policies/Windows settings/Security Settings/Local Policy/Audit Policy to expose the Audit Object Access option
By double clicking on the Audit Object Access node you will see the ability to configure the policy and then set the Success and Failure options. After these are set you then need to run gpupdate on the Windows server that you want to track the files from.
Now that the server is notified it can audit, you now need to configure the data so that it knows to track when it is accessed. Here you will go to the DACL, shown in Figure 2, and list the user, group, and/or computer that you want to track, as well as the level of access. This is similar to the ACL, but here you want to know what access is attempted, not control the access allowed.
Viewing The Audit Results
Auditing of folders and files occurs on the server where the data resides. The audit trail is stored in the Event Viewer under the Security log. You can clearly see in Figure 6 that the Security log has tracked access to a file, which is a result of the two configurations above. Each individual item that you indicated on the SACL will generate an entry in the Security log, but each with a different event ID.
When you want to track the access to a file or folder, you must first understand the foundational concepts for setting up security controls to the data. Then, you can leverage the SACL to track when a user or computer accesses the data, at a very granular level. The key is understanding that the auditing is a 2 step process, combined with accessing the Event Viewer to see what was tracked.
Once you have everything setup and use the process a few times, it will come second nature and will allow you to track nearly any type of file/folder access for all of your Windows servers. I have used this method many times and find that administrators, auditors, and security professionals can leverage this information in a very powerful way.