Patrick Foley

Building an Access Review Compliance Framework

One of the major selling points for IDM vendors is that their tools will simplify your access review process. In my experience and from what I have seen offered by several of the major IDM vendors, the significant investment you would make in IDM technology, you might likely do nothing more than automate bad processes. The result is that you end up only reviewing your primary directory and comforting yourself with “closing the doors” while hoping to get to a more thorough access housekeeping at some point. You now face a danger not so much from the terminated associate as from current staff that could use that old account to effectively undermine the integrity of your data and the non-repudiation of your transactions.

Several key components are required for an effective compliance framework. While technology solutions can assist in scaling access reviews for a large or complex organization, your foundation must rest on a solid and consistent set of policies, standards and procedures. Technology security policy, provided by your CISO, approved by senior management, and universally available to staff provides a platform for communicating the criticality of each actor’s role in access reviews, and affirms to all staff the unacceptability of using shared or generic accounts or the id of another current or former associate. Standards, then must at least define how source systems, such as Staffing, HR, and Contractor Management tools; directories, like AD and LDAP; provisioning systems or access containers throughout the organization should manage identity, authentication, authorization, and access reviews. Finally, procedures would define the access lifecycle. Without this foundation, you can never measure the effectiveness of your access compliance and control because there will be too many exceptions to set an accurate baseline. Your audit findings will be deficient and you will be assuming known but unquantifiable risk.

Once the policies, standards, and procedures are defined, there are several specific components to include in your framework:

  • Bind all users to a single identity – ideally a technology control makes this manageable once your enterprise is larger than a few hundred users or if you have a heterogeneous access environment. I will describe in a future installment a homegrown approach that could be significantly less costly and more effective than a vendor solution.
  • Establish a distributed access review infrastructure – once again, small and simple environments can probably rely on manual controls to manage the reviews, but even a hybrid approach of manual process and system-generated reports can be used effectively by large, complex organizations if you have implemented the foundation discussed above. A distributed access review infrastructure includes identifying key organizational owners for data producers, data consumers, and data delivery. I will describe in a future installment the roles and responsibilities of each role and some approaches that allow Security to concern itself with moderating the interaction and negotiation of these stakeholders while placing the risk where it is most appropriate.
  • The final component of the framework is to establish effective reporting, both to conduct the reviews themselves and to allow expedited action on exceptions. If all your access containers have adhered to the standards for identity that you established, the exercise, while never easy, becomes manageable. In fact, an effective deployment of Roles-Based Access, which I will also review in a future installment, could reduce the reviews to only the access that is highly risky or truly exceptional.

We will have a chance to examine each of the components of an access review compliance framework in more detail over the coming weeks. I welcome your comments and feedback and I will attempt to answer in future articles your questions, particularly on the practical implementation of what I have described.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*