ISAG Part 2: Access Governance 101
We will be posting excerpts from select Identity Strategy and Advisory Group (ISAG) briefings. Part 2 below is transcribed from a recent briefing that took place via conference call, which is why it takes a conversational tone.
Robert Block, Vice President of Identity and Access Management (IAM) Services
Based on your experience, what are the highest value/lowest risk cases that should be tactful as early quick wins in regards to access governance?
Response: I would say initially the most obvious use case where most everyone wants to start is manager or user recertification done by a direct reporting manager. So, let’s say I have some regulatory compliance that says I need a new periodic recertification of access, and we are going to have our direct reporting manager take care of that. That was often the first place we started.
However, I think what we are finding now is that there are probably a number of preliminary use cases that should be done in advance of that to gain a more effective “win” once manager recertification is being done, or in advance of even earlier “wins” prior to the managers doing their work who might not be used to certifying access to date. Some of those are starting with the use cases around user review, so I didn’t really call that recertification because I wouldn’t ask the user to certify what they have. But, having the user see what they have through an automated message allows you to get through some initial data clean-up.
Another use case could be starting with more security-intelligent folks, if the managers aren’t used to accesses (e.g., security coordinators). So, information security folks should have them go through a level of access governance prior to integration with the business.
The next phase of use cases that are useful in "quick wins” is done through the role management use case. This involves the business from a role management perspective when interviewing and showing them potential role models and getting them to accept it. It also involves creating a use case around the governance of the role model so that the business is involved in the continual management of the role model going forward.
Finally, the manager recertification use case is key, since that's probably the largest one across the organization. Ensuring that there is an automated way to govern user access at the direct-report level is often important from a regulatory compliance perspective. The use case is typically required to fulfill a specific business requirement.
Brent Starnes, Regional Director-South/Central
Can a simulated provisioning approach accelerate the roll out of an access governance solution?
The biggest thing about differentiating simulated from automated provisioning is that, with automated, you typically have an adaptor or connector that is directly connected into target systems. Therefore, the identity product can use anything that is done through that connector for auditing purposes. With simulated, the workflow sends the request to the user, but we aren’t actually pushing the permission through that instance. Instead, we are relying on the administrator for that system to create the provisions and the access that was requested.
To the question of how to simulate the provisioning that accelerates the roll out of access governance, in the normal first or second phase rollout, you are probably only going to connect your high-value systems like active directory. But, you still want to know what access users have to other end users to target systems. For instance, you might have financial or HR systems. Instead of taking the time to set up that connector to get the audit information into your identity system, you stand up the simulated provisioning. This allows you to go ahead and do all the workflows and get the auditing information so when you go in to do an access recertification, you can look at the user and say, “Ok. They have these AD groups, so let’s simulate it now,” and that will show up in the report as well. With that approach,you have another view that shows all the permissions and the simulated sources, as well as at the directory or the connected systems.
Stoddard Manikin, CISM, CISSP, Regional Director-Southeast
Can Segregation of Duty (SOD) policies be used to clean up excessive permissions first, i.e., Detective, paving the way for subsequent role out of access governance workflow?
Essentially, segregation of duties is a security principle that’s primarily objectified to prevent fraud or mistakes. What happens is that some set of tasks or access rights are separated out so that one user cannot have so many privileges such that they could perpetrate fraud or make a critical mistake to the organizations. In the real world, examples of this would include requiring two separate signatures on a paper check before that check can be issued or cashed. So, in the world of access governance, the idea is to manage a user’s access based on a segregation of duties, rules or policies. In terms of, "Can you use SOD to clean up the access?" Yes, you can.
Typically, what we recommend is that on initial clean-up of an entitlement, it really needs to be done with more of a traditional approach, like a manager review. A manager review of a user entitlement will simply look at, “Does this user really require the access that they have; Are they still in the same roll or job title that we granted them?” What we see usually is that an organization will clean up anywhere from 20-40% of its entitlements on that initial clean-up. The reason we recommend that you do that first is because it is incredibly time-consuming to identify SOD rules and policies and then apply those to your existing user access rights.
What we suggest is that you clean it up first, do those initial entitlements scrub, and then use SOD more as a preventive control going forward rather than that detective type of review. By that, I mean putting policies in place that say when a user requests a particular entitlement or access that it is checked by an SOD matrix or list of rules and policies, so that the access is not granted at all if it would violate an SOD rule. What we recommend is using SOD polices to avoid assigning inappropriate access and then you can use it deductively later, but it is much harder to do and much more complex.
Robert Block, Vice President of Strategy & Services
Based on your experience, please explain lessons learned in best practices for role out of access review/ recertification process.
I think we have found that one of the strongest lessons learned was to break out the recertification process itself into phases. This should be done prior to inundating an inexperienced business with the process of access-based recertification to some extent by self-reviews, information security or administrative reviews … and ultimately the manager’s reviews. There are another set of lessons learned that are very infrastructural and aren’t necessarily tied to a set of discrete use cases in that data readiness. There needs to be some upfront attention paid to proper data analysis from an IT systems perspective and an HR systems perspective. I don’t just mean modeling roles, even if you are going to do an access recertification review from an entitlement prospective and aren’t going to do roles in the first place.
A critical lesson is the importance of having an understanding of, “What elements are unique and which data elements we are going to certify again? How we are going to certify? What attributes are we going to use?”
Understanding the readiness of that data to support the recertification process upfront prohibits everyone from having to operate in crisis mode. Ultimately, from an access review and recertification process, if it’s going to be roles-based from a lessons-learned prospective, it’s over communication to the business having to certify that the role means something to the business world. Tying that back to the HR prospective, understanding the job title and job functions, we are seeing most often is that HR departments have started to go to generic terms to make the job title easier for us to manage in HR, not understanding that there is an impact to that from the IT prospective. In the last few months, we are seeing HR more willing to expand the amount of job titles they have, understanding that there are real ties and implications into the IT world from a compliance and automation prospective.
Steve Szewczyk, Director of PMO
What data elements from the HR system must be assessed and remediated prior to the launch of an access governance solution?
From our experience, there are numerous attributes that are available in HR or identity and access governance. You’ve got to go ahead and identify an individual user identity. And what we find is there are attributes such as last name, first name, date of birth, date of hire, employee ID, Global ID and email address. These can be used to identify a unique user. In addition, you need to define access requirements, and we found out that using location, division, apartment, job type and job title are successful to go ahead and identify access requirements. Lastly, for approval, we are looking for the existence for some type of organizational priority and manager ID. These will enable you to have an effective identity and access management strategy and solution.