Most of the blog so far has been focussed on Identity and broad structure, and I have used the term IBoR many times. In my attempts at an Identity Centric Security Framework, I have a large band titled "Data Stores and Books of Record". This section includes things like inventory systems, change management systems, application book of records and 3 core IAM systems I want to cover over the next 3 posts. The first post is about your corporate IBoR.
Back in the early 2000's the telecommunications companies wanted to focus on cross-selling services. For example, you may have used telco 1 for home phone, cable 1 for internet, and telco 3 for mobile. The first problem was a realization that each service offering for a given telco was on a different directory since the services had been created and launched at different times. So how does telco 1 know if you have more than 1 service with them already? For example, bli@homephone and bli@internet and bli@mobile needed to be linked. Massif projects were initialized to create IBoR's, linking each service directory to a master directory and keychaining credentials for different services to a single identity. Jump 20 years later, how many companies have a similar issue across directories, environments and cloud-based services? Do you know every credential for each person in your org? How about each shared or NPID?
Back in the early 2000's the telecommunications companies wanted to focus on cross-selling services. For example, you may have used telco 1 for home phone, cable 1 for internet, and telco 3 for mobile. The first problem was a realization that each service offering for a given telco was on a different directory since the services had been created and launched at different times. So how does telco 1 know if you have more than 1 service with them already? For example, bli@homephone and bli@internet and bli@mobile needed to be linked. Massif projects were initialized to create IBoR's, linking each service directory to a master directory and keychaining credentials for different services to a single identity. Jump 20 years later, how many companies have a similar issue across directories, environments and cloud-based services? Do you know every credential for each person in your org? How about each shared or NPID?
There is a difference between an Authoritative Source and an IBoR. An authoritative source provides input to the IBoR for certain identity types and attributes. While and authoritative source is authoritative (and therefore a BoR) for certain aspects of one or more identity types, it is not the source of record for all attributes and identity types and should not be used by downstream systems directly. For example, Bay Li is an employee and his manager, job code, cost center, status, and hire date attributes may all come from the authoritative source of the company HR system. The company also has partners and vendors with credentials, that are managed by procurement in a procurement system separate from the HR system. The procurement system would then be a different authoritative source for partners and vendors' identities and attributes.
Perhaps that covers off humans, but what then is your authoritative source for shared and NonPeople based identities? It's not really a BoR if it's not complete (or accurate) See The Importance of Defining Credential Types. For each identity type defined, you need to define an authoritative source. This is usually a request or intake process unless you are using the network as the book of record. The intake process ensuring the collection of attributes you need to manage the identity. Another challenge is the impermanence of the cloud.
Secret management and SSO using keychains is another huge benefit for an IBoR. Rather than Bay LI changing the password for bay.li@companyabc.com on every identity store, a master secret for Bay Li can be changed and replicated to the credentials that can share a secret. For example, bay.li@dev.abc.com should probably be forced to use a different secret than their production credential and therefor linked to Bay Li as an identity by not for sharing a secret.
An IBoR is not built to be static, but dynamic. Now if Bay Li's manager changes in the authoritative source, it should change in the IBoR. More on lifecycles and lifecycle management later. Changes to attributes stored in the IBoR could trigger an event in your identity management system, like requiring the new manager to certify the team's Bay Li's access. Now, what if the manager and cost center both changed? This could trigger a different workflow, as it would tend to imply a job change. What if Bay Li changed from Employee to terminated?
Your IBoR is therefor a foundational component of any Identity Centric or Zero Trust security strategy and your organizational authoritative source or BoR for what to trust. It's the system you verify against for trust relating to identity. Where else would your incident response, UEBA, PAM, Insider threat, Business Roles Based Access, secrets management, key management etc program source identity truth from?
As a final note, we speaking IBoR and hence we not referring to access levels. For this reason, I have avoided the use of the term "privileged ID" as privileged refers to the entitlement level granted to the identity.
No comments:
Post a Comment