Loading ...
Roles-Based Access Control is so basic a security control, like keeping your anti-virus definitions updated, that it hardly seems worth discussing. Even the least security-minded among us are unlikely to question the motherhood and apple pie concept of only giving associates those tools required to do their jobs. Yet, few security professionals seem very satisfied with the state of their RBAC and there is little agreement about what constitutes success. Some successful programs control nearly every system object a user touches – applications, databases, file stores, printers – while other organizations cannot get beyond creating some coarse-grained Active Directory groups. The first approach adds significant operational overhead while the latter introduces potentially crippling risk. Our challenge is to seek the appropriate balance.
There are plenty of vendors peddling tools promising turnkey RBAC solutions and for the “roll your own” aficionados, organizations like NIST offer extensive documentation. Yet, effective solutions remain elusive because:
- The resources you are attempting to secure do not lend themselves well to context-sensitive controls.
- Security or compliance teams are often the ones trying to build the roles, and they lack the business understanding necessary determine the smallest collection of privileges a user needs for a given job.
- The various operational departments fixate on the exceptions to the rule and hedge their concerns a by seeking excessive privileges to ensure adequate flexibility for meeting business demands.
- The environment changes too quickly and too often as reorganizations; new systems; and mergers, acquisitions, and divestitures reshape the resource landscape.
- Many of the major ERP systems allow a dizzyingly amount of fine-grained control but it tends to be enabled in a binary fashion leading to in many cases more roles than you have associates filling them.
Given these challenges, many security or compliance team either limit their focus to the most critical roles (e.g., those related to SOX compliance) or they react to audit findings and clean up evident issues in the breach.
Fortunately, there are enough success stories to provide both hope and direction for those aspiring to RBAC nirvana. The path to that success requires a distributed ownership model for access governance; some good, old-fashioned analysis of the data and resources you are seeking to secure; and a manageable way to track the metadata about those resources and compliance of your stakeholders.
Success begins with the security and compliance teams getting out of the business of creating roles. As with any effective exercise in separation of duties, the security and compliance teams should not be reviewing their own work, and those groups are much better positioned to validate effective controls than to make implementation decisions for which they often lack full comprehension of the context. Further, decision-making regarding what entitlements to include in each role rests with those benefiting from the access. One model that works uses a data ownership framework to identify the stakeholders as data producers, data consumers, and data deliverers. Limit your scope to those data that are not intended for general distribution within your organization – there is no sense protecting what everyone needs to see anyway. Security and compliance can act as facilitators for implementing the access control environment but the stakeholders actually make the decisions
Producers are your data owners. Each in-scope data element should have a single source – if you have multiple sources for, say, customer data, stop now and reconcile the issues of overlapping ownership, since that shortcoming will undermine more than just access control. That single source needs to be an individual senior executive – the person with the most to lose if their data are misused is the right person. Successful ownership cannot occur by committee. These owners create the rules regarding the use of and access to their data. They are accountable for affirming that they understand how their data are being consumed and by whom. They can always delegate the actual implementation as long as the custodial tasks and responsibilities are clearly communicated.
Consumers represent the data users; they actually own the roles as a mechanism for their users to gain access. The same individual might own specific data elements and some of the roles that access it, but the overlap is rarely complete since if it was your organization would not likely have access control issues. The challenges emerge where production and consumption diverge. Role owners advocate for their users to have the broadest access they believe necessary by declaring and documenting how they plan to apply the data they access. The data owners should review these claims with some skepticism until they are convinced business value of allowing access exceeds risk of inappropriate exposure.
The data deliverers are the technical teams that serve up the data in applications, file stores, databases and other tools. Often they may serve as a proxy for the data owners by executing the controls over data access, but this custodial relationship requires clear documentation of responsibilities. Business owners too frequently cede control over the data to technical teams and effectively forgo their ownership responsibilities. That failure often puts security and compliance at odds with technical teams who argue that they are acting on behalf of the business but without transparency to their customers of the risk they are creating. An access control environment that relies too heavily on the technical teams for implementation will fail.
The primary responsibility for the data delivery role is to deliver systems that allow for appropriate controls, either designed into proprietary applications or documented as a requirement in vendor products. Security needs to actively participate early in the systems delivery lifecycle to ensure that the data owners articulate and the developers document the control environment that addresses the risk of inadequately protecting the sensitive data.
Now that we have some clarity of the stakeholders, next time we will examine the execution of access control that will stand compliance scrutiny and be reasonably self-maintaining.
