FYI I love acronyms: acronym soup, acronyms al dente, acronym au jus… Acronyms FTW. So, when I started working on a new article for this newsletter, it only felt natural to tackle OWASP and IAM. O’ What, you ask? Let’s dive right in.

What’s IAM?

Most of the readership here is familiar with IAM: Identity & Access Management. I’ll refer back to IDPro’s book of knowledge for definitions. Turn to the terminology section for the following:

Access management: The process and techniques used to control access to resources. This capability works together with identity management and the Relying Party to achieve this goal. The model shows access management as a conceptual grouping consisting of the Access Governance function and the shared authorization component. However, access management impacts local authorization as well (through the governance function).
Identity management: A set of policies, procedures, technology, and other resources for maintaining identity information. The IDM contains information about principals/subjects, including credentials. It also includes other data such as metadata to enable interoperability with other components. The IDM is shown with a dotted line to indicate that it is a conceptual grouping of components, not a full-fledged system in itself.

In short, Identity & Access Management (IAM) manages the identification, authentication, authorization, and access control of users and devices in an organization. It ensures the right people have access to the right resources at the right time, and that their actions are auditable.

Notably, I’d like to highlight the fact that IAM is not specific to any particular technology or stack. As a matter of fact, although we tend to think of IAM in the context of IT, it also applies to the physical world (think access cards, drivers’ licenses…)

And what about OWASP?

Overview

The Open Worldwide Application Security Project (OWASP) is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the field of web application security. (source: owasp.org) What’s worth highlighting here is the focus on web applications.

Is there any overlap then between IAM, a discipline, and OWASP, a community? Both firmly belong to the realm of cybersecurity. OWASP focuses on a particular layer of the technology stack (think OSI model) whereas IAM focuses on the identity & access elements of all (or any of) those layers.

Let’s take a look at OWASP’s most popular project: the OWASP Top Ten. The aim of the project is to help web app developers identify, understand, and avoid critical security risks for web applications. OWASP Top Ten is updated on a regular basis. The following diagram shows the evolution of the threats’ prevalence between 2017 and 2021.

While some risks are not tied to IAM, a few are direct consequences of insufficiently planned IAM designs in a web application. In particular, it’s worth calling out:

Let’s dive into each one individually.

A01:2021-Broken Access Control

According to OWASP, 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.

Some of you may have heard of things like BOLA or IDOR. Generally speaking, broken access control relates to the fact that the wrong clients, users, or services have access to the wrong set of processes or data. There are different ways to address this issue. In the realm of IAM, it boils down to verifying a caller’s identity and entitlements. This may be done through the use of access tokens or in combination with externalized authorization frameworks (either policy-based or graph – see A Taxonomy of Modern Authorization Models).

The best way to address Broken Access Control is to systematically think “who can access this? Who can run this process?”

A03:2021-Injection

Injection is somewhat broader than IAM. It tends to relate to the types of attacks where input is sent to the server and is not validated. It could be content that changes the behavior beyond the owner’s intent (e.g. changing a product’s price) or lower-level attacks e.g. SQL injections. Randall Munroe has the perfect illustration of this phenomenon. Again, though, assuming all interactions are authenticated and authorized, injection becomes a much lesser threat as the access control checks part of authorization generally also validate the data input. Again, let’s be paranoid here and stick with the notorious Zero Trust ‘mantra’: ‘Never Trust, Always Verify’.

A04:2021-Insecure Design

Insecure Design is broader than IAM of course, but IAM is the perfect sound first step to adopting the principles of Secure by Design. Notable CWEs (CWEs) include

CWE-256: Unprotected Storage of Credentials,
CWE-501: Trust Boundary Violation, and
CWE-522: Insufficiently Protected Credentials.

This is where application developers need to work hand in hand with their IAM teams to leverage the right IAM tools (framework, vendor solutions) and avoid common identity-related mistakes. No one should ever have to implement a username-password database ever again. No one should have to wonder how to store passwords. I mean, do you ever wonder whether you should implement your own database protocol? Of course you don’t.

A07:2021-Identification and Authentication Failures

On paper, this is the one area in OWASP’s Top Ten that aligns the most with the field of IAM alongside A01:2021-Broken Access Control. Previously known as Broken Authentication, it includes Common Weakness Enumerations (CWEs) related to identification failures such as

CWE-287: Improper Authentication, and
CWE-384: Session Fixation.

IAM tooling and frameworks alone are not enough here but the patterns and best practices we provide at IDPro go a long way to help you avoid common mistakes. The OAuth 2.0 Security BCP also helps avoid authentication failures.

A09:2021-Security Logging and Monitoring Failures

This top ten includes the following CWEs:

CWE-778 Insufficient Logging
CWE-117 Improper Output Neutralization for Logs,
CWE-223 Omission of Security-relevant Information, and
CWE-532 Insertion of Sensitive Information into Log File.

Logging is perhaps one of the most overlooked aspects of an application or use of an IAM framework. When utilizing IAM frameworks and best practices, we can in fact turn logs into an asset. Delegating user management, authentication, or authorization to a third-party system leads to the generation of framework-specific logs (for instance authentication logs, failed attempts, authorization checks, load metrics, etc). This data alone is pivotal in determining whether the application is functioning correctly or is possibly either misconfigured or under attack.

Conclusion

This article provided a brief overview of the overlap between IAM and OWASP, in particular the Top 10. It highlights how a correct implementation of IAM frameworks and processes can help mitigate the risks that come with developing web applications. At its simplest, application developers should fully delegate user management and authentication to a third-party system. Developers should never think of implementing their own means of storing passwords or their own authentication protocols. Standards exist for a reason: they’ve been carefully designed to avoid security pitfalls. Frameworks (be it open-source or vendor products) exist to guarantee. Look into authentication standards such as SAML, OAuth, and OpenID Connect. OAuth, as previously mentioned, also comes with BCPs (best current practices) that highlight how to best implement authentication. Also consider externalized authorization.