Challenges with Native File System Access Auditing

Note: This blog is the first in a 4 part series, followed by a webinar to review all the challenges with File System access auditing. Sign up now for the webinar “Challenges with Relying on Native File System Logging“. Register now.

An organization’s ability to efficiently and effectively capture file level access is paramount in order to not only proactively prevent data breaches or attacks, but to respond in the event your data has already been compromised. Often times, we focus on this concept of a cybercriminal external to your organization, but according to the 2018 Verizon Data Breach Incident Report, almost 1 in 5 breaches were due to user error. Regardless of how the compromise occurs, the forensic trail of “who did what and when?” can provide early signs of a compromise to security.

The focal point of this audit trail is data – the data that users are interacting with which also happens to be the data that attackers are after. With an estimated 80% of this data residing in unstructured data repositories, organizations struggle to maintain visibility over data access, and even the data itself. Large enterprises typically end up with several flavors of unstructured data, including varieties of file systems, document management systems, and blob storage solutions like SharePoint, which ultimately complicates matters further, forcing the security folks to govern each of these systems in a slightly different way. 

For the purpose of this blog series, we will be focusing on one of the most common unstructured data repositories used, and one of the most difficult to govern using native auditing functionality – file systems. In each of the following posts, we will take a deep dive into leveraging the native auditing technology for some of the most common file server platforms, including Windows, Netapp C-Mode, and EMC Isilon, exploring some of the unilateral challenges faced when attempting to leverage native auditing functionality.

Challenge 1: Configuring Native File Auditing

Each flavor of file system has a unique process to enable file level access auditing, making it extremely tedious for the administrator stuck with enabling this across the organization’s entire file server infrastructure. To complicate matters further, in some cases, there are multiple methods through which one can produce such an audit trail.

Regardless of operating system, there is a series of configuration steps required to enable file-level auditing on a file server that consists of creating and enabling the audit policy, configuring the SACL, and then reviewing the resultant log files, as displayed in the diagram below.

Challenge 2: Noise Events with Microsoft Office Documents

The largest challenge comes once auditing is enabled and you are expected to do something with the data provided. In most cases, it is difficult to understand what is actually happening due to the volume of events and amount of noise that is returned for common actions.

For example, if a user simply opens a Microsoft Word document, edits it, and then saves and closes it, the resultant audit log on a Windows File Server would contain over 200 related events, many of which can be discarded because they relate to temporary files created by Office.

According to the Cisco Annual Cybersecurity Report, Microsoft Office formats such as Word, PowerPoint and Excel make up 38 percent of the total of malicious file extensions which is the most prevalent group. If you have to correlate 200 events for a single update to one of these files, imagine correlating the events for a ransomware attack!

Challenge 3: Data Quality

Another major challenge with native file auditing technologies is the manual translation that needs to occur to actually understand common events.

Important events such as permissions changes, which are important to monitor especially when there is a possibility of putting sensitive data at risk, have varied output based on file system platform. In the best case scenario, these events will require manual translation from SDDL format to something meaningful, and in the worst case scenario, only tells you that a permission has changed without telling you anything about the permission itself!

Challenge 4: Limited Filtering Capabilities

Admins would benefit from the ability to limit what does and does not get monitored, to help manage the volume of events that they will ultimately end up with. While most file systems offer the ability to control which users to include for a given audit policy, or which file operations will be monitored, they lack the types of controls that would be more commonly used such as the ability to exclude service accounts that are responsible for running applications such as antivirus or backup, or the underlying processes themselves. Due to this lack of native functionality, admins are forced to collect large numbers of unwanted events produced from background processes and services, significantly impacting both the ability to effectively interpret this data, as well as the performance of the file server itself.

In the next post in this series, we will take a deep dive into configuring native file access auditing on a Windows File Server, and will take a closer look at these common challenges.