We don't need no stinking' badges - Nobody wants to be the "data police"

As I get engaged in projects to deploy our unstructured data governance solution, the most common push back the technologists get from their internal line of business data owners is, “we don’t want to be the ‘data police’.” That is, the business doesn’t want to go through the hassle of deciding who should have access to what data or not.

Their argument is valid in part because, first they don’t have the tools to make the correct decisions and second because the result of this activity is to take permissions away and taking permissions away from people can lead to some serious internal scuffles. People don’t like when their access is taking a way, even if they’re not using it; it’s a territorial instinct thing. From their perspective, they have their own jobs to worry about. Moreover, they think IT security should get of their ivory tower, roll up their sleeves and do the work themselves. That’s what they really think (remember: I am just the messenger).

Without taking sides, what the business people are really saying is there are too many folders, files and shares for them to decide who should have access to what. No one wants to wade through hundreds or thousands of files and have to decide who should have access to what.

IT security has a similar problem in that there is way too much data out there to go through in order to be practical. From their perspective, they do not want nor are they qualified to go through a 500 page report that details all access bob smith has to a share and decide if that access is “appropriate.”

The cure to this dilemma is to use governance policies to reduce the Data Attack Surface Area. By limiting the attack surface area, the task of determining who should have access to what is made dramatically easier because there are simply far fewer places to inspect.

In the example below you can see a policy that will dynamically show an IT security resource (without having to step down from the IT ivory tower, of course ;-)) key risk areas that need to be controlled. These risk areas relate to built-in security principals that are commonly used to grant access (the easy way) to a lot of people, e.g. Domain users, everyone group, etc.

The policy below lets the IT security resource know where domain users’ built-in security principal is being used to grant access to sensitive data “automagically.” From there, one can then drill down on each data end point that needs remediation and fix it from a central console in the One Identity manager Data Governance Edition – Data Governance Policies

Fig.1: In the example below, the IT security manager creates a dynamic policy that will let him know proactively via dashboard below when Built-in Corporate\Domain Users group is being used across the environment to grant access to sensitive shared data which will constitute a company data policy violation.

 

 

Fig.2: IT Security Manager then drills down into folders violating policy (PCI customer Data and Finance folders) and clicks on remove account to remove the corporate\domain users group from having accessed to the sensitive data.(from a central console).

 

Anonymous