A lot of companies who are considering solving IAM issues, immediately start looking at the product to purchase ignoring what is really required for solution to work and deliver required results.
I guess this approach is not really that different from how a lot of companies acquire technology products, but IAM issues are far more dependant on the existing environment and processes as compared to other typical technology solutions.
Identity management is an enabler technology which is required for successful implementation of cloud solutions, internal application authentication and authorization, services security and pretty much anything else which require protection from anonymous access.
In my experience implementing IAM solutions, a lot can and should be done prior to product acquisition to better understand data quality, pain points, compliance requirements to support a decision to acquire vendor product and to improve security posture without creating yet another solution without clear benefits.
Days of excitement about IAM in the enterprise space are pretty much over, companies now understand how complex it can be to solve IAM issues and, in many cases, are just afraid to get into it after hearing and witnessing numerous horror stories of failed implementations.
In this blog I would like to provide my perspective on what is important to understand before making any serious product and implementation investment in IAM and how to get good start even before product decision is made.
Below are critical items worth considering:
- What is the problem to be solved?
This one is absolutely key to building working architecture. It is necessary to listen to pain points, but understanding a big picture. Very often problem is stated as provisioning automation, i.e. application endpoint connectors. Connectors will provide an improvement in management of end systems, but only when there is a clear knowledge of what needs to be provisioned, when and why. In most of the cases, automatic provisioning can consume significant project resources, be very complex to implement and support and, at best, will provide some benefits to access provisioning team. usually the problem is in lack of organizational processes and knowledge to understand who need what access and why. Good start is to understand how IAM processes work and try to improve them and not dealing with endpoint connectors especially for legacy systems.
- Data quality
In order to be successful with IAM implementation, data quality must be maintained for all applications and systems in scope. Authoritative sources of data are almost never reside within IAM, they are usually withing HR or other recruitment systems. This data will serve as a source of global identity which will link all logical and physical assets back to single employee or contractor. Authoritative data must exist not only for employees, but for all other identities like contractors, partners, vendors etc. which IAM system will be managing.
- Global identity and managed endpoints
Global identity of a user is a unique key which will allow systems to link all logical access back to a user. Without correct global identity it is impossible to architect working IAM system. Global identity must remain unchanged for the lifetime of a user. One of the biggest and time consuming requirements of implementing IAM is to identify endpoint accounts and map them to global identity. Global identity must reside within user object at the end system or there should be a process which will allow to reliably map any account to appropriate global identity. For example, legacy system may not contain global identity directly within user object, but accounts will always be the same as Active Directory users so there is a straightforward way to map them.
- Role based access
Access roles are providing excellent way to simplify access requests, map system and physical access to job functions and significantly reduce or even eliminate requirements for periodic access reviews and approvals. But before roles can be implemented, they need to be engineered and tested based on existing production requirements. Roles can be designed and tested without a need to purchase and install additional software. I already discussed simple method of creating and validating roles in this blog post. Engineered and tested roles will provide great sales tool for IAM system purchase and implementation because they will demonstrate effectiveness of approach prior to significant project investment.