Apr 30, 2024

Resources

Authn and Authz: Two Sides of the IAM Coin

Authn and Authz: Two Sides of the IAM Coin

Authn and Authz: Two Sides of the IAM Coin

Authn and Authz: Two Sides of the IAM Coin

You're standing in line at a concert venue, ticket in hand, getting ready to see your favorite band take the stage. When you get to the gate, a security guard asks to see your ID, compares it to the information on your ticket, and waves you through. You're in. Congratulations, you've just been authenticated.

Authentication (Authn in infosec parlance) and its first cousin, Authorization (Authz), comprise two foundational parts of the security discipline known as Identity and Access Management (IAM).  IAM is a crucial part of a sound security strategy, so getting arms around the concepts of Authn and Authz is vitally important for security practitioners at every level.

In this article, we'll explore Authn and Authz with an eye toward understanding their key differences, their common methods, their primary use cases, and emerging trends. We'll also take a look at what happens when Authn and Authz fail, a cautionary tale that highlights the importance of these two core security controls.


Similarities and Relationships in Authn & Authz

Back to our concert. Getting inside the venue is a good first step, but there's still a bunch of questions that need to be resolved. Where will you sit? What other parts of the concert hall do you have access to? How do you get back in if you have to step outside?

While you're contemplating all this, an usher steps up, checks your ticket, and guides you to your assigned seat. Seeing that your ticket also includes access to a VIP concessions area and admittance to a backstage meet-and-greet, they give you a hand stamp and a multi-color wristband. Enjoy the show! You have now been authenticated and authorized.

Putting all of this in the context of information security:

Authentication (Authn): Verification of the identity of a user or entity attempting to access a digital system. It ensures that the user is who they claim to be, typically through using credentials such as usernames, passwords, tokens, certificates, or biometrics.

Authorization (Authz):  The granting (or denying) of access rights and permissions to an authenticated user. It determines what actions a user can take and what resources they are allowed to access based on their authenticated identity and the organization's pre-defined policies.

Defenders rely on Authn and Authz to:

  • Secure systems: Proper authentication and authorization prevent unauthorized access, e-mail protecting sensitive data and resources from malicious actors.

  • Mitigate risk: Authn and Authz help mitigate risks associated with data breaches, identity theft, and other unauthorized, malicious, or accidental activities.

  • Maintain regulatory compliance: Organizations in many industries must comply with legal and regulatory requirements; Authn and Authz are critical for meeting those standards.

  • Adhere to governance, auditing, and accountability policies: Proper Authn/Authz practices ensure that all actions and systems access can be traced back to specific users at specific times, aiding in forensic investigations and accountability.

So, lemon-lime, salted caramel, chocolate, and peanut butter; pick your favorite. The concept of two different, complimentary flavors working in harmony explains the relationship between Authn and Authz pretty well. From the perspective of IAM, one without the other isn't very useful or effective for defending digital assets and systems.


Digging Deeper on Authn

One important thing to remember: Authn isn't just identification.

Identification happens when a user claims an identity with a name, account name, e-mail address, or some other identifier. Authentication occurs when a system accepts a user's proof that they are who they say they are. This act of "identity proofing" culminates in a set of verified credentials and generally requires a user to submit one or more of the following — in addition to their name or account moniker — in order to pass muster:

Passwords (something you know)

Sometimes called knowledge-based authentication, this might be some secret word or phrase or a personal identification number (PIN). Passwords are the most common and also the most easily abused of the authentication factors. Purloined passwords are at the heart of many of the largest data breaches in history. An attacker with access to a working password has all of the access — and all of the privileges — of the user they are now impersonating. As a result, much security policy is dedicated to managing the risks associated with weak, mismanaged, shared, reused, unchanged, and otherwise lousy passwords. If a password is the only access requirement other than a username, the system should not be considered very secure. And password-only Authn is wholly insufficient for high-value and mission-critical assets.

Multifactor authentication (something you have)

MFA, which includes the increasingly common two-factor authentication (2FA), improves security posture over passwords by adding a requirement for an additional authentication factor. These might be code numbers sent to a user via a separate channel — e-mail or SMS text, for example — or using tokens, key fobs, smart cards, or one-time password platforms. As long as attackers haven't compromised the alternate channel, it remains a solid option for improving security posture over passwords alone. It’s important to note, however, that while multifactor authentication is a step up from traditional passwords, not all MFA techniques are created equal. Tokens, fobs, and hardware keys offer a higher level of security and reliability compared to SMS text or email-based MFA for several reasons including:

  • Inherent Physical Attributes: Tokens and hardware keys must be physically possessed to be used, making unauthorized access much harder without stealing the physical device.

  • Reduced Phishing Vulnerability: Unlike SMS or emails, which can be intercepted or redirected via phishing attacks, hardware-based factors are generally immune to such remote exploits.

  • Offline Functionality: Hardware-based MFA can generate required authentication codes offline, reducing the risk of man-in-the-middle (MitM) attacks frequently associated with SMS-based systems.

  • No Dependence on Network Providers: SMS-based codes can be delayed or blocked by network issues, a vulnerability not shared by token or hardware key-based methods.

  • Advanced Encryption: Hardware keys often employ sophisticated encryption protocols, making them resilient against attempts to clone or emulate them.

Biometrics (something you are)

Raises the bar a bit higher, relying less on easily compromised secrets and more on Authn factors unique to the user. Biometrics are among the most difficult for an attacker to falsify. They include: Fingerprints, palm scans, retina and iris scans, finger geometry, vein patterns, voice recognition, and other physical attributes.

Geolocation (somewhere you are)

As the name implies, this factor allows the system to determine where a user is located so that it can grant or deny authentication accordingly. Geolocated Authn factors can include GPS coordinates, IP addresses or MAC addresses of specific devices on the network.

Behavioral Authentication (something you do)

Behavioral authentication takes note of the unique user activity and movement characteristics as the determining factors for identity proofing. Handwriting, signature, typing speed, key pressure, speech patterns, hand gestures, swiping idiosyncrasies, and even walking speed are just a few of the elements behavioral Authn can consider.

Regardless of the factor in use, authentication usually requires client-server communications using one or more of the following Authn protocols or services:

  • Kerberos

  • LDAP (Lightweight Directory Access Protocol) and Secure LDAP

  • SSO (Single sign-on)

  • SAML (Security Assertion Markup Language)

  • PAP (Password Authentication Protocol)

  • CHAP (Challenge Handshake Authentication Protocol)

  • Extensible Authentication Protocol (EAP)

  • RADIUS (Remote Authentication Dial-in User Service)

  • SSL/TLS


Authz in More Depth

Once a user is confirmed to be who they claim to be, IAM focus switches to determining what they are allowed to do and where in the system they are allowed to go. In the example of our concert from earlier, the credential included access to a specific seat, a VIP area and a backstage after-party. The permissions don’t include access to dressing rooms, security offices, or the sound and lighting control panels, however.

Similarly, when a hospital clerical worker logs into their work system, they might have access to patient appointment calendars, prescription and insurance records, and physician's notes in a particular department. It's unlikely, however, that they'd be able to access all patient medical histories or the hospital's accounting and financial documents.

To be effective, Authz must based on sound security policies, the kind only possible in organizations that have a comprehensive understanding — and a detailed inventory — of their total asset environment, a well-thought-out data classification schema, and diligent controls around account provisioning, de-provisioning, and user directory hygiene.

With that baseline knowledge of the environment in hand, the organization controls the Authz porting of the IAM controls through the application of various access control definitions and methodologies. The most common are:

Role-Based Access Control (RBAC)

RBACs take into account groups of users along with the roles they serve and the actions they must take to successfully do their jobs. A user covered by an RBAC can only perform actions and access systems pre-determined to be connected to their work and cannot change their assigned access level.

Rule-Based Access Control

Similar to RBACs but defined based on conditions rather than individual account holders or the work groups they inhabit. Administrators typically set rules-based access according to the time of day or locations where network, systems, and data activity is normally expected.

Attribute-Based Access Control (ABAC)

ABACs evaluate attributes rather than roles in order to protect data, network devices, and IT resources from unauthorized users and unallowed activity. More complicated to set up and manage than RBACs, attribute-based controls are typically reserved for large, mature organizations or those using comprehensive IAM platforms to manage access.

Discretionary Access Control (DAC)

Common on SaaS platforms that allow sharing and collaboration, DAC models allow the data owner to control and grant access by assigning permissions to specific users. Administrators using discretionary controls should keep in mind that, unless expressly prohibited, a user granted access to a system via DAC is often empowered to grant access to other users as they deem fit.

Mandatory Access Control (MAC)

MACs limit access to resources based on the sensitivity of the data that a resource contains. Admins define and label resources by security level. Users are then assigned to groups, each with the ability to access only resources tagged with certain labels applicable to their group.

Emergency Access Control

Sometimes referred to as the "break glass" control, this approach allows for rapidly provisioning an emergency account that circumvents normal permissions. Common in the wake of a ransomware attack or other system compromise, such emergency authorization turns over control of an account to a user not normally authorized to access it.


When Authn/Authz Goes Wrong

There's an almost endless parade of examples to demonstrate how poorly managed authentication and authorization access controls lead to disaster. One cautionary tale stands out both for its magnitude and its irony.

In 2017, Big Four accounting firm Deloitte, a firm with $65 billion in revenues and a major global cybersecurity consulting practice, found itself on the wrong end of a worldwide data breach. Attackers compromised an e-mail administrator's account — protected only with a single password—  and found it had unrestricted access to Deloitte's entire network. From that simple point of weakness, the hackers reportedly hunkered down in Deloitte's systems for nearly six months, stealing sensitive information, including e-mails, passwords, business architectural diagrams, IP addresses, and more.

Some of the high-profile public-sector organizations caught up in the Deloitte breach included the U.S. Department of Defense, the U.S. Department of Homeland Security, the U.S. State Department, the U.S. Department of Energy, mortgage companies Fannie Mae and Freddie Mac, the National Institutes of Health (NIH), and the U.S. Postal Service.

Deloitte has never disclosed how much the breach cost them in lost data, remediation, or reputational damage. It's safe to assume it was a lot. So what might have helped them avoid it or at least, limit the damage?

The lack of MFA is an obvious shortcoming. The attackers had to compromise just one account and a single password in order to gain nearly unfettered access. Poorly controlled RBAC permissions related to the administrator whose credentials were stolen offer another hard lesson. The attackers should not have been allowed to pivot so easily toward more valuable targets within the system. The authorization levels assigned to the e-mail admins' identity were well beyond what was necessary for the role.

Other factors that might have helped include attribute- and/or behavioral-based controls that would have kept the criminals from accomplishing most of their mayhem. At the very least, these more advanced Authz controls, if dutifully integrated into Deloitte's security operations, would have sounded an alarm for unexpected activity much earlier in the six-month timeline of the hack.


The Performance That Never Ends

Earlier, we talked about authentication and authorization in the context of admission to a concert. Tickets, admission, access. It's an apt comparison. But in the enterprise, there's one big difference. Here, it's always showtime.

Authn and Authz bring a lot to the IAM table. Two sturdy, indisposable legs, in fact. Understanding the various capabilities, benefits, best practices, and limitations of each is crucial to the design of secure systems and the protection of an organization's most valuable digital assets. In simplest terms, Authn works to verify the identity of users, while Authz controls their access rights. Together, they form the foundation of modern cybersecurity strategy, enabling organizations to defend against threats, mitigate risks, and ensure data integrity.

As technology advances, authentication and authorization mechanisms continue to evolve, with emerging trends like adaptive authentication, just-in-time (JIT) access, continuous authentication, and contextual authorization. Staying informed about such advancements is essential for implementing robust security practices.

By prioritizing strong Authn and Authz, organizations can create a secure environment, protect sensitive data, and maintain user trust. Remember, infosec never sleeps; continuously improving Authn and Authz methods and practices is key to staying one step ahead of potential threats.

Keep learning, keep adapting, and keep safeguarding your digital realms by controlling who gets in, where they can go, and what they can do. On with the show!

Ready to see how Opal can help you achieve and maintain least privilege access?

Ready to see how Opal can help you achieve and maintain least privilege access?

Ready to see how Opal can help you achieve and maintain least privilege access?