Importance of Defining Authoritative Sources

In a previous post, I covered The Importance of Defining Credential Types
and how you need to define what attributes you need to store in your IBoR

In this post, I want to cover Identity types and Authoritative Sources (AS). For any system, you need to ensure that you use a consistent source as accurate. What you don't want, is to use the network as a book of record.

Authoritative Sources, Identities and Credential mapping

For each identity type, there is usually one or more authoritative sources available. Each source contains different "characteristics" you may wish to store in your IBoR for identity verification. For example, HR system may be an authoritative source of employee information, but the inventory system maintains the workstation ID of the user. If you wish to use this workstation ID for identity verification, hook it in as you would any microservices API or centralized DB.

Make sure you cover all credential types. If no authoritative source exists, you need to create one. This is were intake systems and approvals become necessary.

This is usually the first step in building out identity governance and an Identity centric approach to security.

Something you know, something you have, something you are.

Most IAM people will repeat this phrase in a heartbeat. "Something you know, something you have, something you are". These are things than can be used to authenticate an identity. Put in a different way, these are things that can allow you to build the required trust to grant access.

Policy decision points use authenticate credentials based on the number of attributes available to them. A single attribute, like something you know (e.g a password secret), can give some minor level of trust. Each attribute may not have the same weighting for building trust. An 8 character secret is not as secure as a 2014-bit key, yet both may be vulnerable if poorly stored. Given the same level of trust, the number of attributes authenticated would be exponential. For example, 1 factor or attribute authenticated is 1x1=1 and 2FA is 2x2=4 times, 3FA would be 3x3 or 9 times the trust of 1FA.  

In the digital world, we often make binary decisions, if this, then that, when real life we have hundreds of attributes we take for granted and use as references for trusting someone is who they say they are. This I discussed in the post The "Identity Bottleneck. You are a sentry, and someone approaches and you challenge them " halt, who goes there", and the person responds with a password, is that enough? What if the person does not speak any of your languages, is wearing clothes of the enemy and you don't recognize them? Would you require a second proof of identity?  But in the digital world, how are these factors created, stored and used?

There is much hype around MFA, biometrics and policy decision points and the death of the password. What I wanted to highlight though was the trend towards contextual characteristics. In the real world, this would amount to identifying someone based on their relationship to something else. The first one, the one to the left, the one standing. Something marketing and advertising have lead with. Where did your connection come from, is the machine ID known, is there an existing cookie. 

Let's say you have an old application limited to 8 character passwords for authentication, could you use 1 of more contextual characteristics to improve identity trust? What is the IP, what is the machine ID, do they know the password...

Are you putting enough focus on IAM?

I wanted to create my own Identity Centric Security Framework as I  believe the industry has been slow to grasp the changes in security over the last 10+ years and security organizations are not yet focused on Identity and Access Management as they should. Thanks to the number of audit findings in the IAM space, some organizations are starting to look at IAM in a new way, but with IAM in a small box in a legacy framework, it often does not get the focus it should. The result is budgets are usually spread between "boxes" in the framework or given to the team that shouts the loudest.

This is somewhat surprising given the causes of breaches. If you have ever tried to recover a drive that book sector is corrupted beyond repair, you will realize that data has no use, unless you cannot access it. Identity is the starting point of every transaction and Access the ending point. Remember this next time you looking to secure a digital crown jewel in your organization and you will have half a project plan already. Nothing can lead to more confusion than starting in the middle with networking or some other random point, then grasping for what have we missed. In fact today I had a chat about a plan to move to identity based firewall for application layer segregation in a large financial organization and my first thought was I hope their identity system is up to scratch, else this project would have a net benefit of zero.

Even for those that don't want to embrace my logic the amount of research in the area is extensive. The identity defined security alliance recent post named "Identity-Centric Security: 10 Data Points from 10 Different Vendors". In the framework, I also pointed out proactive, real-time and reactive. Put a different way, would you rather prevent a breach or know sooner after it happened?


In no way am I suggesting you ignore the other security disciplines. What I am asking is how much of your security budget is going to IAM and is that approaches to the levels of risk it addresses? Then given the 4 pillars of IAM, does your organization have enough focus on IAM?

Mind The Gap - mystical authorities of obscurity

I blogged a satire piece about people in IAM but wanted to raise an issue in a more serious tone. Firstly, let me say, this is not unique to security or IAM, and I am sure it exists in many areas in and out of technology. Years ago, I was required to mandatory military service and served as a marine on a naval base. The base had about a dozen marines and over a thousand navy staff. As a Marine, we wore combat fatigues, carried weapons and stood apart, while the navy wore whites and most classroom weapons training only.  The average navy officer had no idea what we actually did. We shrugged off any naval policy and tradition we could and defined our own space as "mystical authorities of obscurity". Sorry navy officer, we can't because [pick and obscurity+ add some mysticism] for an excuse, then dodged as much work or responsibility as we could. Anyone read the book bullshit jobs?

Perhaps this can be attributed to a skills gap, or perhaps its leadership gap, recruiting gap or just industry hype, growth or a dozen causes. Professional certifications like ISC2 offers have done much to ensure recognition of the discipline and some level of base understanding. The problem is you can take a professional dishwasher and in a one-week executive crash course, prepare them to write their professional security designation with a significant success rate. Suddenly, with 1 week of training and a chunk of dollars, we have a "security professional", "audit professional", "risk professional", that never has looked at a log or provisioned a user, been audited or had to deal with risk other than for themselves on social media.  I have had to show "security professionals" how to book a room in outlook, and heard this same person recommending phishing training guidelines for outlook 30 minutes later. 

Perhaps is because so many companies consider IAM a regulatory or security cost vs considering the additional pillars of IAM. So, when a "security professional" is found, not demanding top dollar, they are snapped and added to the team of "defenders". Perhaps some recruiter (who has even less understanding of security than the newly minted "security professional") tries to screen candidates with questions like have you worked with "Zero Trust", "PIM", or "least privileged", discounting anyone that resume does not list these keywords in under 2 pages as lacking experience. Or have you deployed "CyberArk",  "SailPoint", "Okta" and nice to have "Venifi" in a financial organization of 100,000 or more people... in the last 6 months and have your CISSP and 5-10 years experience? If so, I have an excellent opportunity for $45,000 a year. It's a competitive market, and you get what you pay for. 

Only someone that knows little about deploying these products or has an integrity gap, would claim yes. Often the deployment "experience" turns out to be in a line of business, effected by the product deployment. Yet these jobs are soon filled and with the shortage in security, audit and compliance teams, no one seems the wiser. Next, you hear, the "security professional" was promoted to management and starts hiring their own team and finds more newly minted "security professionals" to work for them, that won't expose their limited industry knowledge. Soon the company has an entire team of "security professionals" setting policy, policing and driving corporate security strategy, with limited to no exposure to the technologies, they are attempting to protect.
 

As a contractor, I usually take time to interview for potential new contracts. You usually can spot these people 5-10 min into an interview, if not by their questions, by their vision or aspirations. "I am committed to fixing an audit finding in 5 months, that’s been open for 5 years"... and yet from experience I know that would take 2 years and significant resources to close. These are usually not the contracts you want.

Alternatively there "old security" personnel. These are people that spent many years in security and have nothing more to learn. Doing it like its 1999. They ignore emerging technologies as "security principals remain constant". They spend money on Active Directory tools, legacy firewalls and SIEMS while their organizations deploy SaaS, federated access, BI, AI and cloud-based services. Easy to find, since you notice controls in legacy environments are the focus, while the business continues to move ahead "unhindered".

IT and other technology teams soon realize that the mystical authorities of obscurity have little or no idea about their business and are seen only as roadblocks. "Security professionals" defend their standards, policies and controls as regulatory, or best practice by throwing more mysticism and obscurity around. There is usually a huge amount of hype words and jargon (often misused) that emerges. $45,000 a year solution, starts costs the company millions in other resources time and efforts, with little to show for it and all confidence, is lost.

One does not move all ones players to the defensive line, unless you lost already and just focused on trying not to bleed to death. So why put so much emphasis on second and 3rd lines of defense, at the expense of the first line. Information security needs people focused on securing systems proactively and if most of the security staff are simply reporting on the the state of security or writing a new policy (that those managing the systems will probably ignore).  We need forwards if we want to stand a chance of creating a winning team, but forwards are loved by their supporters and hated by the opposition and it can be dangerous to be noted. 

Sooner or later and executive has everyone telling them IAM folks don’t get it, and this starts looking bad on them. Management picks a project and gets IAM leadership to promise it in record time or "face the consequences". Left with little choice but quit, the project is soon kicked off often just buying time.  A vendor "partner chosen" as the scapegoat, the objectives are set. Limited timelines and resources, coupled with previous short cuts and lack of experience results in the project getting descoped repeatedly and more corners are cut. The result is usually foundational work is descoped for visible goals, like building data stores, stopping the bleeding, training, building to a point in time or ignoring life-cycles been dropped in favour of risk acceptance or bias checkbox assessment. If the deliverables can be spun as met, the security team may buy some temporary goodwill, at least until descoped issues come to the fore.

Now the IAM team cant raise additional funding to finish what they already claimed to have done, without admitting failure. In the meantime, IT and other technology teams are rolling their eyes and saying, "What did you expect" and life goes on, with the next project building on the missing foundations of the previous. Sinking more good money into new projects, that will be wasted when it all collapses.

Then they get a new CISO, spend a year doing a current state assessment with gaps and making a plan and then - start again – at the beginning. Usually resetting the company security maturity level in the process.

There are good IAM security professionals and organizations. Usually so busy plugging away that they are often overlooked. Medical specialists first need a medical base, engineers need basic engineering skills before specialization. Why then does the industry think you can have a security professional that has no experience with the technology they protecting? Security professionals need to be technology professionals first. In fact, they should be subject matter experts in a platform, area or system before specializing.

Perhaps we need a cultural change or need more collaboration and openness and less mysticism and obscurity. Perhaps if we dropped the jargon and hype words and focused on understanding and learning. Or perhaps we need rotation programs were security staff does IT work and IT staff does security work for a period. As an IAM professional though, I cannot encourage others enough to do a non-security course in technology areas your organization is adopting.

Data Stores - Entitlement Book of Record (EBoR)

Technologies and vendors come and go, and for this reason, I would like to keep this blog as vendor natural as possible. For example, SailPoint might call it your Identity cube and identify warehouse, I used the term keychain and IBoR.

For anyone that has designed any SOA based applications or database tables, this post may be obvious. For those that have not, though, there is an important intersection of IBoR and Entitlement Catalogue, I will use the term EBoR to describe. While and IBoR contains identities and credentials and the Entitlement Catalogue what is available for access (your identity service catalogue), your EBoR is who has access to what.

It's essentially a point in time report, connecting a user's identity to all their entitlements they have or an entitlement to all the users that have access to it. Who had access to this field 2 weeks ago, or what did bob have access to 2 weeks ago. Although its a point in time, the query needs to be able to run as needed, and not batched.

Depending on your decision on zero trust and network as the book of record, this should be a query from your identity management system as authoritative and not the endpoints. The reason datastores are so important for building trust.

This should also be what is certified as a 3rd lifecycle as part of the user's access lifecycle by their manager. If you pull from the endpoints, how do you know the access was gained legitimately? Rather your Moves Adds and Changes managed in your identity management system, will keep track of what access you should have and any discrepancies dealt with on the network side.

Your access request systems should be greatly simplified, for the identity of  Bay Li requesting role 123, with the workflow defined for the entitlement. The business description, technical description, need for a sperate credential, approval flow, through provisioning all defined already.  Role 123 could be a business role, IT role or application role.

So if you want to know who are your privileged users, today, how would you know? If a critical system has a known unpatched vulnerability, who has access?