8. Control Access with Minimal Drag on the Business

Many businesses possess IAM tools such as directory services and identity administration systems and think the tools in themselves will provide a state-of-the-art IAM solution. But unless the business also has mature processes for access management, the tools can be ineffective and the business vulnerable to the risks of inappropriate access. To manage access in a logical and scalable way, identity administration systems need to route access approval requests to data owners or data stewards of sensitive information.

Most businesses have at least rudimentary information classification in that they’ve defined levels of data sensitivity and identified which types of data belong at which sensitivity level. For example, pricing information may be confidential (available on a need-to-know basis) and customer records restricted (need to know with the highest level of control). However, most businesses tend to suffer from information sprawl and cannot enumerate all the repositories or systems where each type of sensitive data does (or should) reside. Nor can they programmatically identify the data owners for all the many instances or aggregations of sensitive data.

My colleagues and I have done many IAM consulting projects and have put together an IAM resources page for readers.¹ We typically find directories and identity administration systems in place that meet some of the business needs. Every business has password-based authentication, but many still lack stronger MFA capabilities, even for critical systems. Generally, the business can identify some of its critical assets and the names of the responsible business owners. However, unofficial copies of sensitive data or other critical assets tend to proliferate and lack clear ownership.

We usually find a deprovisioning capability to remove access for employees leaving the business, but it rarely does a good job of handling contractor or partner access removal. And although it may handle staff terminations, the deprovisioning process rarely cleans up account access rights that aren’t required after a user transfers to a new department. The policy data – roles, groups, and rules – that would be required for such precision in access management are rarely rationalized. Cleaning them up would be onerous, requiring the aid of specialized identity governance and administration (IGA) tools.

IGA systems without well-defined processes, access policies, and models tend to operate in an ad hoc manner. Users are overprivileged with too few roles and groups in place or with too many and no one in charge. Access once granted is rarely removed when users transfer assignments or positions. On IAM consulting engagements, it is not uncommon for us to find businesses with more groups than users in the directory.

Finally, despite being included in the SANS Critical Controls lists and in the control baseline recommendation for this book, user account monitoring is often absent.

Most in-place IAM deployments are outdated and don’t scale to current volumes of people, data, and things. Poor identity data quality, silos in IT, infrastructure and business changes, and the proliferation of incompatible systems multiply IAM challenges.

Prior to the growing popularity of cloud deployments, many businesses consolidated their in-house directory and authentication services to the Microsoft Active Directory during the early 2000s. Over a decade later, cloud computing began to undo that consolidation, and by now many businesses are back to square one. IAM’s gyrations from a mature, consolidated state (on-premises) back to once again straining to support too many directories and user sign-ons (in the cloud) suggest that rationalizing and simplifying IAM (and IT) is not a one-time fix, but a generational challenge the industry experiences each time new infrastructure platforms, applications, and use cases appear.

Businesses are still adapting IAM to more loosely coupled and decentralized models necessary to support the hybrid multicloud environment. Fortunately, most cloud services consume Security Assertion Markup Language (SAML) assertions as well as other standard IAM protocols. (SAML is an identity federation (aka federated identity) standard that, very simply put, can signal to cloud-based applications “Hey, I’ve already authenticated my user, log him in!”) Federated identity reduces the need to maintain complex, integrated directory services as well as multiple sign-on burdens on users.

There is also a generational shift from the Baby Boomers and Generation X workforce to Millennials. Millennials have grown up immersed in, and more comfortable with, consumer technology. Consumer mobile devices are more intuitive and easier to use than business workstations. Millennial workers and many older ones who caught onto consumer technology expect to use consumer-grade devices at work, to be empowered with enough access to be effective, and to keep growing in their understanding and mastery of the technology. Recognizing this, the concept of people-centric security began to emerge about 5 years ago.^2,3

At the same time, international privacy and data residency rules are becoming more stringent. Few businesses are fully adapted yet to the notion that in many jurisdictions it is a legal requirement to obtain customers’ informed consent for using their personal data and to provide other privacy rights. Businesses face increased risks of consequences from privacy breaches due to regulations such as the European General Data Protection Regulation (GDPR). However, stricter controls on how to access identity information and share it between applications and partners – if implemented – create a drag on the business.

As if all this wasn’t enough, the COVID-19 pandemic in 2020 forced many businesses to institute sweeping work from home programs, massively increase remote access to premise-based applications, or move those applications to the cloud. But work from home breaks the trust model for many businesses that have required staff to physically be in a building in order to access sensitive resources. These businesses must now pivot to acquire, deploy, and test logical, identity-based controls such as multi-factor authentication (MFA).

For a critical security control domain, IAM is unusually cross-functional and business enabling. IAM architectures can be highly complex and subject to disruption from IT, regulatory, and business changes. You’d think IAM would fall under the security organization, but I’ve often seen IAM teams under IT, business units, or other parts of client organizations. It’s common to find an IAM working group promoting cross-functional engagement at the grassroots level. Unfortunately, these teams often don’t have an executive sponsor engaged with them.

Identity is not just a set of controls, it is a key part of the way the business manages its relationships with users both on-premise and in the cloud. These relationships are increasingly – in many cases entirely – digital.

Digital relationships that staff, partners, business customers, suppliers, and consumers have with the business are enacted through applications with user interfaces (UIs) and/or via application program interface (API)–based services. All require identity to authenticate, authorize, and personalize the user experience (UX) and functionality or do the same for APIs under the covers.

Digital business can be highly innovative, ranging far ahead of any IT strategy crafted even just a year or two ago. IAM is often “tip of the spear” in developing customer- or partner-facing digital business relationships. To understand the business’s forward-looking requirements, security leaders should join with the IAM team to engage with IT and business unit planners and developers on their IAM use cases early and often. These use cases may introduce new capability or scaling requirements such as support for dynamic secrets management in a microservices environment, consumer IOT device authentication support, or new workflow approval processes for partner onboarding.

The recommendations in Chapter 7’s sections “Help Develop a Strategy to Consolidate and Simplify IT” and “Align with the Evolution from IT-as-Provider to IT-as-Broker” suggest another key to business alignment.

As critical as managing digital relationships with people is for IAM, it is also an area of great challenge. Both traditional IAM systems and consumer IAM (CIAM) systems sold to businesses expressly to manage consumer identity must increasingly take account of privacy regulations that, in some jurisdictions, give consumers a great deal of choice about whether their data can be stored, how it can be used, who it can be shared with, and how long it can be retained.

This creates marketing technology dilemmas for businesses, which are highly dependent on the ability to ingest a great deal of personally identifying information (PII) and put it through machine learning and business intelligence systems to gather critical data for sales, support, and new product or service development. Businesses may also get a little extra revenue or tit-for-tat advantages by selling or sharing personal data to partners. Traditionally, consumers have received little information about or choice in the sharing or analytics processes. Today such PII-fueled business models are under regulatory pressure.

Marketing technology (martech or adtech) is beyond the scope of this book, so I won’t opine on the optimal marketing approaches. But it is within our scope to say that IAM or CIAM will need to have the right capabilities to support privacy protection and that such processes and controls must be aligned with business models’ assumptions about how personal information should be used. For example, customer consent for storing or using PII must be obtained through the UI or UX, which could be a shared IAM service or part of an application. Disclosing how customer data will be used in a transparent manner is good for compliance and can also be part of an engaging UI.

According to the third “Cisco Cybersecurity Series 2020 Data Privacy Benchmark Study,”⁴ increasing numbers of organizations have been achieving positive return on investment from privacy programs. A common path to such gains has been to obtain privacy certifications such as ISO 27701 (a privacy extension for ISO 27001), EU/Swiss-US Privacy Shield, APEC Cross-Border Privacy Rules, and EU Binding Corporate Rules. These certifications can demonstrate compliance with European, Asian, or other privacy frameworks and provide legal cover for cross-border data transfers. For the average company in the study, the ratio of benefits to spend was 2.7, meaning that for every dollar of investment, the company received $2.70 worth of benefit. Companies reported positive results from building customer loyalty or trust, reducing sales delays, mitigating losses from data breaches, and other benefits.

Consider privacy-enhancing technologies such as tokenization, private pairwise identifiers in federated identity connections, and zero-knowledge proofs. Businesses can also monitor decentralized identity, or so-called self-sovereign identity models. A number of startups are developing decentralized identity solutions using blockchains as registries for users’ core decentralized identifiers (DIDs) which then link to verified claims⁵ (essentially, digitally signed attributes) or zero-knowledge proofs.

Guess what, key security initiatives (such as zero trust perimeter security and API security) and key IT initiatives (such as container-based compute services) could all depend on identity interoperability.

SAML and OpenID Connect for authentication and single sign-on, OAuth 2.0 for authorizing API-based access to resources, and Structured Cross-Domain Identity Management (SCIM) for provisioning accounts or permissions are all federated identity interoperability standards that work across business domains. They can facilitate single sign-on, distributed authorization, API security, and ease of use to speed the process of forming secure digital relationships. Creating consistent IAM services for LOB cloud and Internet use cases enables the business to simultaneously move forward and reduce risk by avoiding ad hoc LOB solutions.

As business’s IAM environments encompass more and more externalized, cloud-based systems, it will become increasingly important to also move identity functions to the cloud by leveraging standards-compliant identity-as-a-service (IDaaS) solutions such as Azure Active Directory, Okta, and OneLogin. IDaaS systems extend federated authentication and provisioning to hundreds or thousands of SaaS solutions.

Modern users are also highly mobile, pushing businesses to develop secure strategies for bring your own device (BYOD) access, at least to everyday email, collaboration, and similar tools. Fortunately, many IDaaS solutions provide lightweight mobile device management (MDM), adaptive risk-aware authentication, and highly scalable and extensible directory services. These tools can help protect mobile/cloud users and businesses against brute-force attacks on user passwords, rogue apps, and other threats in the open cloud.

To increase IAM flexibility to operate in a distributed, yet still secure, manner, businesses should set identity interoperability requirements for purchased applications or services and reference the industry standards in third-party assessments. Encourage or require

Also, specify the standards in the business’s software development lifecycle (SDLC) standards for developers and provide guidance on leveraging standards implementations from strategic vendor or service provider platforms and related APIs.

Finally, businesses must also bring modern IAM fully into their development environments to make both more agile without sacrificing assurance. Enable IAM in microservices and container environments to support DevSecOps initiatives for IaaS or private clouds.

The IGA discipline is the most complicated part of IAM and requires a bit of explanation. IGA has its roots in “provisioning” tools that perform directory synchronization and automated account creation. These tools evolved into IGA suites.

Advanced provisioning tools once differentiated themselves primarily by supporting dozens of connectors for consolidating directory information into centralized systems such as Microsoft Active Directory and synchronizing identity information with other OS or application user account repositories. Today, literally thousands of connectors are integrated into IDaaS tools to enable single sign-on with numerous SaaS services. Besides provisioning, other important IGA suite capabilities include

Powerful administrator accounts – such as the Amazon Web Services (AWS) root user, the Active Directory Domain Administrator, Azure Global Administrator, and Linux server root accounts – are called privileged accounts. PAM tools can be used to manage these accounts and gain additional control over them.

Privilege in IT is required to set up and administer servers, cloud systems, and applications. However, the same IT administrators who create security settings or access controls can easily change them, as could an external cyberattacker compromising the administrators’ accounts.

As shown in Figure 8-6, PAM systems manage privileged account registration, credential issuance, revocation, and rotation. PAM systems can also provide runtime capabilities such as credential check-in/checkout, session monitoring, and privileged user analytics. The original PAM vendors such as BeyondTrust, CA, Centrify, and CyberArk centered their implementations around a password, or credentials, vault.

Today, privileged accounts are scattered through the hybrid multicloud environment, and businesses are increasingly using Just-in-Time (JIT) PAM capabilities that require a runtime assignment of a role to a privileged account. Because role assignment is usually an IGA function, PAM and IGA tools are starting to converge with some vendors, such as Saviynt, specializing in IGA-enabled “cloud PAM.” Regardless of how it is deployed, PAM is critical to reducing the probability that a bad actor compromising a user account somewhere in the business will be able to move laterally, escalate privilege levels, and cause a breach.

Modern digital businesses (and IAM vendors) have been much quicker to enable digital relationships with innovative use of identity interoperability protocols than they have been to also extend their back office IGA and PAM systems to the cloud. However, as balance of business activity and value shifts heavily into cloud and mobile environments, businesses must develop a hybrid IGA and PAM architecture to cover them as well.

The diagram in Figure 8-6 is adapted from a “to be” IAM architecture we developed for a large North American SaaS vendor’s hybrid cloud deployment in 2019 and is representative of what this client and similar companies are deploying as of 2020. Note the following features of the diagram:

The IGA, PAM, and runtime IAM systems must often support billions of access control scenarios – just imagine how big a matrix showing all the combinations of hundreds of rules, thousands of users, and millions of resources (potentially comprising every field or button on every form of every web application) would need to be. The complete solution must therefore

IGA systems manage access control by defining access policies in the form of roles for users and business rules that refer to roles, groups, or collections of users. These access policies must be managed and aligned at both the business and IT levels of abstraction.

Figure 8-7 illustrates how a business can map job functions (aka business role such as “Accountant”) to the IT roles (such as a user account in the finance system which is a member of the system’s local “Accountants” group) and then to the actual IT system and application or database permissions required for the work.

All users, and other active entities such as machines and services, should have defined digital profiles in the business’s directory service(s). Changes to a profile trigger changes to access via the IT roles, such as security group memberships. Access managers or the users themselves can request access changes. Depending on business rules, the IGA system may perform automated provisioning, or it may orchestrate a workflow seeking approval for the change.

When a new user joins the business, the business roles and user attributes in the profile trigger the IGA system to initiate the new accounts, group memberships, and permissions that comprise the “birthright” entitlements for the user. When the user’s business roles or attributes change, the IGA system adjusts IT roles and permissions. When the user’s entry is removed or suspended, the IGA system removes or disables access.

Finally, the IGA system continuously reviews user access rights against the business rules or signals from IAM monitoring systems, and it may periodically orchestrate access certification campaigns requesting (for example) managers to certify an employee should continue to have certain access rights or that a contractor is still engaged with the business.

Businesses and their identity operations teams need to risk-inform the IGA function. Otherwise, the business is likely to have high levels of inappropriate access or experience “drag” from excessive rigor and delays for users requesting necessary access.

Sometimes both risk and drag run rampant across an IT environment that doesn’t have a well-defined and well-managed role model or role-specific training for users. During the discovery phase of one IAM assessment, we discovered that IT administrators could easily reset information classified by the business as “Strictly Confidential” to a lower level without data owner involvement. Yet, in the same organization, business users who didn’t know the access rules for certain situations held back from sharing information with customers even when they knew it would cost them a deal.

The IGA processes and role models must be appropriate to the business’s security culture. Returning to our earlier discussion of people-centric security and accountability, it is probably neither possible nor desirable to completely automate all access assignments. An automated role-based access management system is beneficial when many identical or similar roles can be assigned, such as to users of manufacturing resource management systems in a large factory environment. In other cases, at least some role assignments or access grants must be orchestrated through workflows. Workflows give managers or resource owners constrained discretion over access decisions. Sometimes it’s expedient to allow delegated administration of IT roles; that is, appoint an application owner or a business partner to be the owner of a group that controls who can access to an externally facing application.

Excessive access privileges are often granted when managers rubber-stamp access requests or reviews because they’re working under deadlines and perhaps don’t understand the applications’ access model or the full extent of access granted by a privilege when multiple systems are integrated together. Often the unwelcome chore of access certification (aka access review) gets handed off to compliance; we heard of one case where a compliance officer was tasked to certify 20,000 accounts in just two weeks! But, with the right tools, the compliance officer’s mission could be accomplished without gross errors. Here’s how: Advanced IGA tools can run analytics or respond to clever queries such as “Which users have been granted access to critical systems in the recent review period? What are all the changes to critical systems’ access? Which users are outliers with more access than anyone else on their team?” The compliance officer can then investigate or ask for manager approvals on just those cases.