The information security landscape is constantly changing. New threats develop daily and those threats may bring novel attack vectors and risks that will compromise organizational security. Top of those novel attack vectors are compromised access controls. Their compromise rate is so prolific that broken access control is the #1 critical web application risk. Per OWASP, 94% of tested applications had some form of broken access control

It's downright reckless to ignore critical vulnerabilities, yet this issue seems to be prolific.In this article, I’ll highlight how broken access control can lead to ransomware and other major attacks. I’ll also provide some suggestions for how to integrate access control considerations into the secure development lifecycle and third-party software risk evaluations. I’ll then address some mechanisms for monitoring and enforcing access controls.

Background

Broken Access Controls represent a series of vulnerabilities that allow individuals to exceed their granted and intended permissions. That can occur either because of a change in identity or privileges on a web application.

Those changes may permit vertical and lateral movement within an application. Someone who ought not have access to databases and other resources may be able to leverage misconfigured access, or “fail open” access, to gain access to those resources, or any other resource.

When a threat actor is able to gain such broad access to an environment, their use of vertical movement allows privilege escalation. That privilege escalation can allow them to commandeer the ability to control resources and assets. That control allows free access to information, which allows exfiltration of that data. It also permits the deployment of encryption algorithms which are the core of ransomware attacks.

Most ransomware actors use both tactics in conjunction to maximize organizational damage. It’s incumbent on organizations to put in place secure development practices to secure assets from attack.

How to Secure Assets

Securing assets can be a straightforward proposition. Oftentimes, that requires collaboration between security departments and developers. Organizations with a “shift left” approach to secure development place the onus on developers. That doesn’t mean developers must act in a vacuum—there’s always the ability to talk to a security or architecture organization—but it places the onus on developers to code securely.

The primary way to secure web applications is to fail safe, fail closed, or deny by default. Where the fail open model is permissive with further access, the deny by default model means cutting access when unexpected inputs are delivered or unexpected behavior is taken. That halts vertical and lateral movement in its tracks and enforces the principle of least privilege. This principle is a core security concept, where users are provided only the access needed for their job duties.

Deny by default can’t be applied to all resources.  But organizations should be judicious where they don’t use it and document the rationale why, including implemented mitigations.

Another method of securing assets is to include stateful session identifiers. Stateless session identifiers potentially allow for the capture of cached session information which could be stolen and used by a threat actor to gain unwanted access to resources. Stateful session identifiers expire and thus limit subsequent use.

Yet another method to secure assets is to use a consistent mechanism for authorization decisions. Using and reusing one canonical set of authorization policies means that specific authorization behavior is expected throughout the asset in question. Even better: reusing access control policies consistently between assets to improve the uniformity of expected behaviors and simplify managing access control across applications and services.

Finally, you can secure assets in a way that assists with monitoring and mitigation of threats. The mechanism to do that is logging access decisions. Whenever a call is made to the access control engine, the decision to permit or deny should be logged. Doing so will allow correlation with other events in, say, a centralized monitoring platform.

Third-Party Risk Considerations

Sometimes, you’ll need to purchase or leverage external assets. Some of those assets may be curated by an organization as a closed-source program. Others may be open-source and community-driven.

Some security practitioners suggest open-source software should be used judiciously, because of the potential for threat actors to infiltrate the code pipeline to inject malicious code and identify vulnerabilities. As seen by critical breaches at SolarWinds, Microsoft, and GoDaddy, that also happens with major closed-source assets. The main difference seems to be the lack of visibility into those closed-source assets.

When considering third-party risk, organizations should think about where their data resides. If it’s sitting in a SaaS or PaaS offering, the more control the organization has over its data and its security the better. Once that control is relinquished, the organization relies on the integrity of the third-party’s security controls. While those controls can be assessed—and there are many services and vendors that do so—changes or misconfiguration can modify that without the organization’s knowledge.

Organizations should also consider whether their authentication and authorization policies can be used with third-party resources. Where those policies cannot be reused, there’s potential for unexpected behavior in the handoff between systems. That unexpected behavior may result in a fail open instead of a deny by default access model. That becomes less of a consideration where those third-party resources exist independently of organizational systems and aren’t integrated.

Monitoring and Enforcement

There are a few key ways to monitor and enforce access control to avoid novel threats. One method, alluded to above, is by robustly logging access decisions and routing those logs to a central monitoring platform. Correlating with other information from firewalls, IDS/IPS, and detection and response tools will provide a robust picture of what’s happening with your assets. That correlation is key for early detection of a threat actor in your environment.

You can also monitor by having assets deploy alerts when too many access failures occur. Even without central logging, those alerts can inform staff that something is awry and needs to be addressed. You can also combine enforcement to minimize persistent failures. Rate limiting rejected access and including cool-off periods between groups of failed access can minimize the potential of an attack.

A deny by default access posture also goes a long way to stop improper access. If a threat actor can’t force a system to provide access, then their likelihood of gaining improper access is substantially minimized.

Finally, forcing all requests to go through access control checks prior to providing access is critical to ensuring system integrity. If the propriety of access is assumed, as is the case when permissions are baked into tokens as OAuth2 scopes, then a threat actor can bypass potentially critical access controls. Where those access control checks are based on a consistent underlying policy, then the result of all access requests should be predictable: deny unless expressly allowed.

Conclusion

Broken Access Controls are the most common reason for application security failures. It’s #1 on the OWASP top 10 list for good reason. Broken access expands an organization’s attack surface and can allow the easy execution of novel attacks. Those novel attacks may include crippling ransomware or data exfiltration events, or other events that significantly impact service delivery.

Mitigating those threats requires the implementation of secure development practices, third-party risk management, and robust monitoring and enforcement. That’s not an easy proposition by any means, but it’s a critical investment of time and effort to keep operations running effectively.