The Identity Catechism: Questions every CISO should ask of their Identity program

The evolution is underway. Our infrastructures are borderless, our critical data is cloud-based, and our users work from anyplace on the globe – or 36,000 feet above it. Our legacy controls are as outdated as the conceptual hardened perimeter and our users are still human; and will still succumb to the (not so) well-crafted phish. While no one was looking, we have slowly evolved to relying on the user’s identity to make all critical decisions.

We need to stop thinking about trusted networks and presume everything is dirty. We need to accept that applications will fail when attacked and stop expecting our developers to build code that is impenetrable. We need to stop entrusting vendors to solve our problems and develop new approaches to protecting our infrastructures.

When we look at the current state of the cyber-world, one cannot help but wonder how we will ever win the war, much less the day-to-day battles we all continually fight. Our networks are ever-expanding, consuming eternal services much like a black hole consumes the most significant planetary objects in its path. Security budgets are constantly under pressure while free or inexpensive shared services are being sold to the business lines daily.

We need to adopt a new model.

If we take a step back and look at what we do as security professionals, it is almost always based on an identity. Do we know who that network connection is from? Can we verify who’s logged in to the application? Is the person sending a confidential email authorized to do so?

Everything, in some way, is based on how we associate an action to a person. It doesn’t matter what alert triggered or what vulnerability exists – the first question is almost always… Who?

In that light, I offer my first volley into the new model.

In a perimeter-less world, where anyone can access anything from anywhere, the first, and possibly only, line of defense we have is the Identity – that trusted moniker that validates access rights across the entire enterprise and provides a trustworthy foundation for risk-based decisions. Unfortunately, most organizations never look past the ‘account’ stage of an Identity, missing a major opportunity to develop an evolutionary program on which they can build their future program upon.

This series of 15 topics was developed to provide anyone in the C-suite a fundamental understanding of what a mature Identity Management program looks like, what questions to ask, and some of the reasoning behind the need. It is not intended to be all-encompassing, nor fit every situation, but rather a general approach of what I’ve seen be successful. They go from basic to advanced concepts, with later questions being the most mature practices.

Join me in leading the evolution.

The Identity Catechism:

1) Do you have an accurate inventory of your identities?

An ‘Identity’ is not an account, but rather a collection of user’s roles and access rights based on predefined policies. These permissions are used throughout the enterprise to associate specific user credentials and rights to a system account. Too often, ‘Identity’ and ‘Account’ are used interchangeably, but from a holistic Identity Management position, the two are very different.  

Q1: Do you know where your identities are stored in comparison to your accounts?

2) Do you understand the authentication process in your enterprise?

Mature infrastructures, after decades of managing accounts in a world of system and device sprawl, loose track of authoritative systems and account stores. While the vast majority of organizations have centralized on Active Directory for their Windows environments, significantly fewer have integrated network devices, applications, or Linux hosts to AD as well. Far too often, these types of systems leverage local accounts for authentication and have no association to a common, managed identity repository.  

Q2: Do you have an end-to-end understanding of how users authenticate to workstations, network devices, applications, or non-windows servers?

3) Do you understand the business processes around identity and/or account management?

Regardless of the maturity level of your Identity Management program, the process of managing credentials is fundamentally core to your success. While a manual process can be successful with enough rigor, automation is necessary to minimize human errors which inherently creep into any manual process. Auditability is key here. Could you randomly sample 10% of your accounts and have enough evidence to show each followed the documented process?  

Q3: Is your Identity/Account Management process well defined, repeatable, and automated?

4) Do you integrate with HR systems to validate and correlate employee access?

Thinking outside the box a bit (or inside, depending on your perspective), the ultimate system-of-record for employees is undoubtedly the Human Resources Information System (HRIS). Leveraging the HRIS system to track new employees, termination actions or job changes can provide a centralized workflow trigger for an automated identity workflow. In the event you don’t have a consolidated HRIS platform, you likely have a central database of employees somewhere. At a minimum, consider looking at the payroll or benefits platforms in lieu of an HRIS to track the on-boarding or off-boarding of employees. Also, do not overlook contractors or consultants. Some companies leverage the HRIS platform for tracking these resources as well, but many do not. Figure out how/where your contractors are on-boarded and treat this as its own HRIS platform.  

Q4: Does your identity management process activate with changes to the HRIS platform?

5) Do you perform regular attestation campaigns for business and technical owners?

Entitlement hoarding or credential stockpiling occurs when long-term employees amass credentials over time that are no longer needed for their day-to-day jobs. Appointments to special projects, lateral job moves, or company reorganizations are common reasons for the stockpiling of unnecessary access rights. Obviously, with unnecessary rights comes unnecessary risk, especially when the risk is layered over the ever-increasing threat of credential theft. Attestations that align with your regulatory or business requirements are a simple and effective way to ensure each user has the correct level of access for their role. Most modern Identity and Access Management solutions have some type of attestation feature in them, but be sure the workflow and functionality are compatible with your business process.  

Q5: Do you have an attestation process in place to identify and resolve accounts with unnecessary access rights?

6) Can you report on how much of the granted access rights are through standard role definition?

A good target for a mature Identity Management program should provide 70%-80% of access credentials via predefined ‘birthright’ roles. Obviously, your mileage may vary, but using this as a target should find a nice balance between the number of roles you have versus the level of effort in handling the exceptions. This same target percentage should be evaluated as part of an annual exception review process as well. If, say over the course of a year, an exception could be applied to the same percentage of users as the predefined roles are, then perhaps you should consider developing that role for continual use. This approach also lends itself to a stronger process-based Separation of Duties (SoD) practice, as both identity and SoD expectations should require a separate review and approval process.  

Q6: Are the majority of rights granted to users derived from predefined birthright roles rather than exceptions?

7) Do you regularly test and verify the strength of your passwords across all environments?

Too often, we trust the preventive controls we have in our environment, rarely, if ever, validating they are performing as expected. While the built-in password controls in Active Directory do a great job in mandating password requirements, there are several ways around the limits imposed by the Windows environment which would allow the user to create a weak password. This is especially true if you look at the capabilities Windows Admins have. Additionally, don’t forget about your non-AD Linux accounts, application users, or network devices – all of which have their own methods for mandating strength in access rights.  

Q7: Do you regularly test the validity of identity and user controls in all of your environments?

8) Do you manage your privileged accounts to a satisfactory level?

Arguably, a primary objective of any attacker who infiltrates your infrastructure is the acquisition of privileged accounts. Privileged accounts are those authoritative application, administrative or root accounts which provide elevated access to modify configurations, install software, or modify services in an environment. While most only think of the built-in ‘root’ or ‘Administrator’ server accounts, it should also include any account which provides a higher level of access than that of a normal user, such as Domain Admins, Database Admins, or accounts that have configuration-level access to networking devices. A well designed privileged access management program will limit the use of static passwords in favor of one-time passwords (OTP) or include multi-factor authentication (MFA) to limit account takeover opportunities. Additionally, activity logging – and even keystroke/session logging on critical devices – should be the norm for such accounts.  

Q8: Do you have a privileged accounts strategy that protects authoritative accounts against abuse or takeover and creates an auditable trail of activities?

9) Do you have real-time visibility into identity and account permission activities?

Once a malicious actor achieves access to your environment, they want to ensure they keep it. While attackers will set up new authoritative accounts if they need to, a common tactic to guarantee ongoing access to an environment is to manipulate access rights on existing accounts. A simple dump of the password file or a basic query to the Active Directory can provide an attacker with a list of long-dormant accounts that can be leveraged as a persistent backdoor into your environment. A mature identity program will monitor for permission changes to existing accounts, as well as the creation of new accounts, and use such alerts as an early indicator of malicious activity.  

Q9: Does your program monitor for permission changes on existing accounts as well as the creation of new accounts?

10) Do you monitor accounts for signs of abuse in real-time?

Account abuse could be just as damaging with a regular, non-privileged account as it could be with an authoritative account. Imagine that long-time employee that has been inadvertently collecting different access rights during their multi-year employment having their account taken over by a malicious insider or external attacker. Monitoring for account abuse indicators such as ‘machine-speed’ failed logins (multiple failed logins within seconds, rather than minutes), illogical logins (i.e. a login from another country after the user just badged-in to the local office), or unusual lateral logins that do not fit the user’s profile is critical to understanding how access is being exploited within your enterprise.

Q10: Are you actively monitoring user access activities for signs of abuse or takeover?

11) Do you have a clear understanding of which partners and third-parties have access – and how?

Not too long ago, one of the most newsworthy breaches of the time started with an HVAC vendor’s login credentials getting breached, resulting in unmonitored, unmitigated access for the attackers. While there have been countless articles around all of the events of the breach, at the end of the day, it was a trusted third-party whose access had been compromised. Third-party access to your environment isn’t just about how accounts are created, but more importantly, how they are maintained. Very few security executives have been able to solve the problem of maintaining accounts belonging to people who do not work for the company. While your legal team may alert you when a partner relationship is terminated, even with the most stringent contracts, getting a third-party partner to tell you about an employee who’s resigned or has been reassigned or fired is virtually impossible.  

Q11: Do you have a process in place to identify, track, and verify third-party users and contractors?

12) Are your cloud service credentials integrated with the rest of your Identities?

Cloud service providers and hosted service solutions typically avoid the normal account management process thanks to the ease of getting these services initially setup. Any employee with a credit card can fire up an AWS instance and have an entire stack running in an hour without the consent of Corporate IT, much less integrated with the approved access management process. While a solid shadow IT management process should be in place regardless, you should also consider making it as simple as possible for cloud services and external providers to integrate into your standard authentication infrastructure. A proactive SAML/OpenID/OAuth2/FIDO program, which enables service providers to easily connect and authenticate your users, would empower and encourage users to integrate into the standard authentication platform. Additionally, a Cloud Access Security Broker (CASB) can provide a lot of this functionality – along with a host of other features – that would enhance the integration process while enforcing your organization’s accepted controls.  

Q12: Does your identity program encourage integration between your authentication infrastructure and external providers via open standards or leading CASB services?

13) Do you manage your machine-to-machine credentials to the same degrees as user credentials?

SSH keys older than most high school kids, connection strings hardcoded in source code, or service accounts whose password is.. Null; weak, unmanaged machine credentials are arguable the second-largest bane to an Identity Management program. Inventorying and understanding the fundamental risk of machine credentials goes a long way in mitigating an often-overlooked risk inherent in most enterprises. Many of today’s product solutions can often manage most of these accounts to a point where you not only limit the potential of abuse, but you virtually eliminate the downtime associated with proper credential maintenance. Some additional thoughts on specific credential types to pay attention to:

• SSH Keys: Evolving programs manage SSH keys much the same way they manage passwords, revoking, and issuing new keys as employees leave or change roles. New key creation functionality is typically limited to very few individuals and monitored accordingly. Keys are typically given a short lifespan which encourages rotation.
• Connection Strings: Typically, ‘connection strings’ – i.e. shared secret keys – are used as a permission key which allows applications access to the databases which they rely on. It is extremely rare that these connection strings change over the course of an application’s life and, because they are typically stored in the clear, are prone to abuse. Manual practices involve changing such strings on every major release, however, there are viable solutions that can automate the rotation of, or even remove the need for, such constructs.
• Application Credentials: Intra-application credentials, those used to communicate to other applications in the infrastructure, will commonly use shared credentials. The challenge with maintaining such credentials is that any mandated password change would have the potential for a waterfall failure effect on all similar applications. Additionally, there is a concern of applications not needing the level of access that was granted with the shared account. Individual accounts should be set up for each application which would facilitate an automated rotation solution.

Q13: Do you maintain an inventory of application and machine-to-machine credentials and manage them under a standard process?

14) Do you associate physical access with logical access?

This is one we’ve all talked about for many years. Associating someone’s physical access with their logical access not only benefits the Identity Management program, but also the Physical Security program as well. Let’s face it, if someone badges in and then log in from someplace other than your corporate network, something is amiss. It could be a stolen credential, but it could also be a stolen access badge being used by a miscreant. Either way, understanding the dynamics of physical location and logical access is beneficial to several teams within the organization.  

Q14: Do you correlate logical access attempts to recent physical locations; alerting on discrepancies in both directions?

15) Are you capable of adjusting user access requirements based on behavior or risk?

Admittedly, this is the nirvana of access management. That being given, it is certainly achievable in today’s enterprise. Many of today’s access solutions can contextually evaluate risk scores and determine if additional secondary credentials are required during the login process. As more and more services move to the cloud, being able to make real-time decisions on the level of risk the attempted login introduces is critical to ensuring the ongoing soundness of the environment. Common Access Risk Indicators (ARI’s) are location-based, transaction-based, or deterministic activities based on time and date (Does the person usually log in at 2am? Does the person login to the finance system only three days after month-end?).

Another dimension to consider, albeit far less mature from a technology perspective, is Behavioral Biometrics. Behavioral Biometrics refers to the physical indicators that result as a person goes about their normal activities. These indicators can be how someone speaks, walks, or types on a keyboard. For example, how fast do they type, how they move a mouse around, or how they interact with the workstation or device can provide a level of confidence as to who the user actually is. The science behind such measurements points to the ability to predict, accurately enough, whether or not the person using the device is similar enough to the owner of the access credential. If so, the basic credentials may be enough to grant access, but if not, the system would require an additional form of authorization to validate the identity.

Q15: Are you able to make risk-based access decisions, in real-time for critical infrastructure, and require additional authentication if the risk is too great?

So there you have it. Fifteen questions that will give you some insight into the maturity of your Identity Management program. Where do you stand?

I have had several requests for additional information on measuring the maturity of one’s IAM program. To assist with those requests, I’ve put together an IAM Maturity Model Calculator that can be used to assess the level of maturity of your internal IAM program.  The download link is below, or you can visit the Resources page for a full description and the file hash.

For more on Identity and Access Management, view these articles.