Organizations are facing an explosion of identities – employees, contractors, customers, partners, machine identities…you get the picture. In the first blog in the IAM Best Practices Blog series, I talked about identity ownership and with that making sure to consider ALL identities in your organization. This blog will focus on ensuring uniqueness of identities, specifically corporate personnel, internal users, and 3rd parties. We’ll save the identity uniqueness viewpoints as it relates to customers for another blog…for now, let’s focus on the not as cool, meat and potatoes of identity in the corporate world!
First, establish what is your DNA at the organization, and then ensure it can be unique. Assign it once, and only once, to your human personnel. It can be a KerberosID, GUID, SSO ID, employee number, or any other unique identifier that your organization uses to establish “this is who Tom is” in the logical access world in your organization. Give it out only once and keep it forever and ever for Tom. So, if Tom leaves to go out on a world tour with Lady Gaga for a bit, when he finally regains sanity and comes back – he gets back the same DNA he had before. Not necessarily the same access, but the same DNA.
Ideally, this unique identity process applies to all contractors and those converters as well. So, if you become an employee, you still keep the same DNA you had as a contractor. Establishing this uniqueness is good hygiene and ensures you can trace back activity over long spans of time, and across all logical asset types, as well. You never want to reuse DNA, so establish an algorithm that ensures uniqueness and can scale. This primary DNA applies to all users of your assets – so contractors, employees, and 3rd parties who are on your network and use your assets (whether regularly, or just occasionally). There are no free passes for anyone – stick to your process and policies, even if an individual only requires access for a short period of time. If you have physical access tied to your IAM system – same rules apply – DNA is required for any physical access, as well.
Second, ensure your downstream application teams that use local identifiers (maltat, Tom_Malta, TMalta123), or those secondary accounts used by your data base administrators, system administrators, etc. can also be correlated back to the primary human owner’s DNA. Local users managed within an app still have corporate DNA, but the app team chose to do local authentication and use a secondary identifier. This is less than ideal, but a reality. If you use a virtual directory structure (VDS), you can take all those local and secondary accounts and associate them back to the primary DNA of the owner. Good business processes to stay current and regular reconciliations are key.
Once you have this in place, it is now easy for you to associate all those other identities back to their primary “parent” human identity, or unique DNA of the person who holds them all. Wherever possible, if you can tie the provisioning processes for the secondary accounts to the correlation process, you can capture the correlation at time of creation – that is the ideal scenario.
Last, remember all those non-human accounts that are so hard to manage in your environment? Do you have service accounts on your DMZ but you don’t know who owns them and you are afraid to kill them because you don’t want to cause a business outage? Sound familiar? Well, this blog won’t solve that problem for you! But…once you do know the human owner of those non-human accounts, you can associate the identity of those accounts back using the correlation methods noted above.
Again, good provisioning and reconciliation processes are required to make this all work well, but the investment will pay big dividends, especially if you are investing the time to clean up your identities across the organization. So, once it is clean – enforce the good hygiene and put business processes in place to keep it clean.
Hey Tom, this is all great, but you haven’t told us what this gives us? How can this linkage for just identities help us establish good identity best practices?
- You now have a single identity identifier that is unique for each person in your organization, which becomes their Identity DNA. They keep it forever and ever and it is immune to job changes. It is also used as a trace identifier across all logical assets back to that individual.
- You now have a source to create a comprehensive view of access for every person in your organization, including what secondary accounts and non-human accounts they hold and the privileges that go with them. You can provide that comprehensive view of access from one system of record (SoR) of identity. Your SoR for Identity (e.g. VDS) does not need to hold entitlement information, roles, nor specific fine-grained authentication or authorization data. Instead, it acts as the pointer back to your access provisioning tools such that you can retrieve and report all those underlying details and marry the specific access back to a single human owner.
- You now can tie transfer and termination events to your identity SoR so your de-provisioning processes (whether manual or automated) can utilize this directory store to do a very comprehensive removal of ALL access, for not just the primary account, but all those secondary accounts as well. Additionally, it gives you a great reconciliation point to ensure that access has been removed, from all associated identities, when key identity events are triggers.
- You now can spawn workflow to the manager of a terminated or transferred employee to ensure a new owner gets tagged for all those non-human accounts she owned as they depart the organization or the role. You would use workflow/business process to re-associate them to their new owner(s), and invoke another good hygiene tip at the same time: change all of the service account passwords as well when you initiate the transfer of ownership.
- Your periodic access reviews can now be even more comprehensive. It enables you to link all the identities, and their associated entitlements, to a single owner. The manager gets a complete picture when reviewing access (e.g. as he/she would normally be required to do – for a transfer event). Or, you can break that access into any subset if you chose to split up the certification events by account type, or other uniqueness properties that you would capture in your VDS and associate to each identity (e.g. the head DBA might want to do an access review of just the DBA secondary accounts which are privileged in nature). A few extra attributes when creating the correlations will go a long way later when you look to leverage the identity system of record.
Establishing policies and processes that ensure the uniqueness of identities in your organization is not just good IAM hygiene, but essential to providing the long-term controls and visibility that protect your critical assets. I hope some of these tips help you on your IAM journey…I’ll be back with a future blog when I return from my world tour.
About the Author: Tom Malta, SVP, Head of EAM Access Controls at Wells Fargo, has led many successful IAM Programs over the last 20 years utilizing custom built as well as off the shelf technology supporting internal, external, and 3rd party/cloud identities alike. His recent passions include emerging technologies such as biometrics, AI, and next generation customer authentication solutions such as blockchain. Tom is a member of the IDSA Customer Advisory Board.
