Simple Question: Is this access correct?
Correct...
What is correct?
- Is the data in the warehouse up to date?
- Are the accounts correlated correctly to their owners?
- How do you know?
- What about the accounts that can't be correlated to an actual person?
- Are they system accounts (used by applications)?
- Are they privileged accounts, used by IT administrators (bad!.. no shared passwords)?
- Are they accounts that were once owned by employees, contractors or partners who no longer have a relationship with the business?
- Is each person's access correct based on least privilege? (only access needed to perform their job)
- What is least privilege for Suzy? Bob?
- Does any of the current access represent a risk?
- Does anyone have the ability to perform an unwanted transaction (or set of transactions)?
- Who has privileged access to applications and data?
To properly answer these questions, you have to ask the people who would know... The Business. If you ask the IT department, they might be able to tell you when the access what granted, and maybe even how... but it is unlikely that they can tell you why... and even more unlikely that they know if it is still needed.
The business also knows if the current, static access of each person is correct. If there is anyone in the company that knows what access Bob or Suzy actually needs, it's their manager or possibly the application owners on which they have accounts. The business owners need to review each individuals' exact access, down to the entitlement level and make a determination of appropriateness. This is the process of access certification.
Additionally, the business should be engaged to decide what entitlements, when granted to the same individual, constitute a Separation of Duties violation. These SoD policies can typically span the entire enterprise, and all applications should be considered during the evaluation cycle. For example, your vendor management (for creating vendor records) could be in an operational application, like a fulfillment or inventory solution, while your vendor payment process may rely on the records in your accounting application. In this scenario, if someone had the ability to create a vendor in the inventory solution, and then pay the vendor in the accounting solution, this would constitute a SoD violation, or a "Toxic Combination" of access. This is why the ability to define and enforce SoD policies across enterprise applications is critical.
Simple Answer: Once you've build an identity warehouse, execute an SoD evaluation an complete and access certification. Once they are complete, you truly have "Identity Gold"... all nice and shiny.
....next question: How the heck are managers supposed to know if access is correct?
