Now that we understand the technical architecture, let’s look at the principal features seen across most File Activity Monitoring tools.
Entitlement (Permission/Rights) Analysis and Management
One of the most important features in most FAM products is entitlement (permission) analysis. The tool collects all the file and directory permissions for the repository, ties them back to users and groups via directory integration, and generates a variety of reports. Knowing that an IP address tried to access a file might be somewhat useful but practical usefulness requires that policies be able to account for users, roles, and their mappings to real-world contexts such as business units.
As we mentioned in the technical architecture section; all FAM products integrate with directory servers to gather user, group, and role information. This is the only way tools can gather sufficient context to support security requirements, such as tracing activity back to a real employee rather than just a username that might not indicate the person behind it. (Not that FAM is magic – if your directories don’t contain sufficient information for these mappings you still might have a lot of work to trace back identities).
At the most basic level a FAM tool uses this integration to perform at least some minimal analysis on users and groups. The most common is permission analysis – providing complete reports on which users and groups have rights to which directories/repositories/files. This is often a primary driver for buying the FAM tool in the first place, as such reports are often required for compliance.
Some tools include more advanced analysis to identify entitlement issues – especially rights conflicts. For example, you may be able to identify which users in accounting also have engineering rights. Or list users with multiple roles that violate conflict of interest policies. While useful for security, these capabilities can be crucial for finding and fixing compliance issues.
A typical rights analysis will collect existing rights, map them to users and groups, help identify excessive permissions, and identify unneeded rights. Some examples are:
- Determine which users outside engineering have rights to engineering documents.
- Find which users with access to healthcare records also have access to change privileges, but aren’t in an administrative group.
- Identify all files and repositories the accounting group has access to, and then which other groups also have access to those files.
- Identify dormant users in the directory who still have access to files.
Finally, the tool may allow you to manage permissions internally so you don’t have to manually connect to servers in order to make entitlement changes.
Secure Aggregation and Correlation
As useful as FAM is for a single repository, its real power becomes clear as you monitor larger swaths of your organization and can centrally manage permissions, activities, and policies.
FAM tools use a similar architecture to Database Activity Monitoring – with multiple sensors, of different types, sending data back to the central management server. This information is normalized, stored in a secure repository, and available for a variety of analyses and reports. As a real-time tool the information is also analyzed for policy violations and (possible) enforcement actions, which we will discuss later.
The tools don’t care if one server is a NAS, another a Windows server, and the last a supported document management system – it’s capable of reviewing all their contents consistently.
This aggregation also supports correlation – meaning you can build policies based on activities occurring across different repositories and users. For example, you can alert on unusual activity by a single user across multiple file servers, or on multiple user accounts all accessing a single file in one location.
Essentially, the FAM tool gives you a big picture view of all file activity across monitored repositories, with various ways of building alerts and analyzing the data, from a central management server. If your product supports multiple file protocols, it will present this in a consistent, activity-based format (e.g., open, delete, privilege change, etc.).
Activity Analysis
While understanding permissions and collecting activity are great, and may be all you need for a compliance project, the real power of FAM is its capability to monitor all file activity (at the repository level) in real time, and generate alerts, or block activity, based on security policies.
Going back to our technical architecture: activity is collected via network monitoring, software agent, or other application integration. The management server then analyzes this activity for policy violations/warnings such as:
- A user accessing a repository they have access to, but have not accessed within the past 180 days.
- A sales employee downloading more than 5 customer files in a single day.
- Any administrator account accessing files in a sensitive repository.
- A new user (or group) being given rights to a sensitive directory.
- Any user account copying an entire directory from an engineering server.
- A service account accessing files.
Some tools allow you to define policies based on a sensitivity tag for the repository and user groups (or business units), instead of having to manually build policies on a per-repository or per-directory level.
This analysis doesn’t necessarily need to happen in real time – it can also be done on a scheduled or ad hoc basis to support a specific requirement, such as an auditor who wants to know who accessed a file, or as part of an incident investigation. We’ll talk more about reporting later.
Data Owner Identification
Although every file has an ‘owner’, translating that to an actual person is often a herculean process. Another primary driver of File Activity Monitoring is to help organizations identify file owners.
This is typically done through a combination of privilege and activity analysis. Privileges might reveal a file owner, but activity may be more useful. You could build a report showing the users who most often access a file, then correlate that to who also has ownership permissions, and the odds are they will help quickly identify the file owner.
This is, of course, much simpler if the tool was already monitoring a repository and can identify who initially created the file.
Comments