In the first two parts of this series, we discussed why permissions management, the traditional approach to file security, no longer works and introduced a new approach to file security that leverages machine learning to build dynamic peer groups based on how users actually access files. In this final installment, we look at three real-life examples derived from validation testing of our dynamic peer group algorithms. By automatically identifying groups based on behavior, file access permissions can be accurately defined and dynamically removed for each user based on changes in user interaction with files over time.

For our validation testing, several Imperva customers allowed us to leverage production data from their SecureSphere audit logs. Containing highly granular data access activity, the log data provided full visibility into which files users accessed over a given duration. Based on the dynamic peer group analysis algorithm, incidents were identified in each of the customer environments.

Weâve highlighted three incidents below. In each case, users had valid permissions to access the files and folders.

An engineering manager accessed a sensitive financial file

The first case focuses on an engineering department manager who was part of an engineering peer group comprised of others who work on similar projects. This managerâs close peer groups were also comprised of engineering department employees.

Because the folder was not associated with the managerâs peer group nor its close clusters, the algorithm identified the engineering managerâs inappropriate file access.

A finance employee accessed an HR file

Another case involves an employee in finance. Clustered in a peer group with six others working on a specific project, this employee attempted access to personal data stored in an HR folder regarding another employee. But the folder is not associated with the userâs cluster, nor with those close by. Rather, it is associated with a peer group containing HR personal from a different location within the organization.

A researcher accessed a software classification file not related to his work

A researcher was clustered into a peer group with twelve others, in addition to R&D employees. The researcher attempted to open a software specification document that is regularly accessed by a specific R&D team. But the folder containing the file was not associated with the researcherâs peer group nor its close clusters. This is the type of incident for which we can alert the SOC team.

All three beg the question…

All three of these incidents raise a common question: âWhy did the employee have access to the directory in the first place?â There are three explanations:

An oversight – The employee shouldnât have had access at all.

Course-grained granularity – To ease administrative burden, in many cases permissions are defined with fairly course granularity. The result of this is âcreepâ that results in users receiving overly broad access.

Lack of revocation – An employee was granted access to a directory for a specific project, but once completed, access was never revoked.

These three causes are not mutually exclusive. They amplify each other. In fact, the explosion in unstructured data and the number of people that create it (and in many cases the creator de facto sets the permissions) and use it exacerbates the impact of these three issues.