The OWASP Proactive Controls is one of the best-kept secrets of the OWASP universe. Everyone knows the OWASP Top Ten as the top application security risks, updated every few years. The OWASP Proactive Controls is the answer to the OWASP Top Ten. Proactive Controls is a catalog of available security controls that counter one or many of the top ten.
For example, Injection is a famous top ten item, having lived within the OWASP Top Ten since its inception. One still prevalent category of Injection is SQL Injection. The counter to SQL injection from the proactive controls is “C3: Secure Database Access” and other controls. C3 prescribes secure queries, configuration, authentication, and communication for database transactions. These techniques work together to prevent data loss due to SQL Injection.
Here is a map between the OWASP Top Ten 2021 and the Proactive Controls updated in 2018.
| OWASP Top Ten 2021 | Proactive Controls 2018 |
|---|---|
| A01:2021-Broken Access Control | C7: Enforce Access Controls |
| A02:2021-Cryptographic Failures | C2: Leverage Security Frameworks and Libraries C8: Protect Data Everywhere |
| A03:2021-Injection | C3: Secure Database Access C4: Encode and Escape Data C5: Validate All Inputs |
| A04:2021-Insecure Design | No mapping |
| A05:2021-Security Misconfiguration | No mapping |
| A06:2021-Vulnerable and Outdated Components | C2: Leverage Security Frameworks and Libraries |
| A07:2021-Identification and Authentication Failures | C6: Implement Digital Identity |
| A08:2021-Software and Data Integrity Failures | C2: Leverage Security Frameworks and Libraries C4: Encode and Escape Data C5: Validate All Inputs |
| A09:2021-Security Logging and Monitoring Failures | C9: Implement Security Logging and Monitoring C10: Handle all Errors and Exceptions |
| A10:2021-Server-Side Request Forgery | C5: Validate All Inputs |
Let’s explore each of the OWASP Top Ten, discussing how the pieces of the Proactive Controls mitigate the defined application security risk.
A01 Broken Access Control
Broken Access Control is when an application does not correctly implement a policy that controls what objects a given subject can access within the application. An object is a resource defined in terms of attributes it possesses, operations it performs or are performed on it, and its relationship with other objects. A subject is an individual, process, or device that causes information to flow among objects or change the system state. The access control or authorization policy mediates what subjects can access which objects. In the worst cases, authorization is forgotten and never implemented.
The Proactive Controls offer C7: Enforce Access Controls, which describes Discretionary, Mandatory, Role-based, and Attribute-based access control strategies. The document also provides a solid list of design principles for access control.
Action: Attribute-based access control (ABAC) is the most mature and capable of all the strategies. Use ABAC as your template, and apply the access control design principles.
A02 Cryptographic Failures
Cryptographic failures are breakdowns in the use of cryptography within an application, stemming from the use of broken or risky crypto algorithms, hard-coded (default) passwords, or insufficient entropy (randomness). A broken or risky crypto algorithm is one that has a coding flaw within the implementation of the algorithm that weakens the resulting encryption. A risky crypto algorithm may be one that was created years ago, and the speed of modern computing has caught up with the algorithm, making it possible to be broken using modern computing power. A hard-coded or default password is a single password, added to the source code, and deployed to wherever the application is executing. With a default password, if attackers learn of the password, they are able to access all running instances of the application. Insufficient entropy is when crypto algorithms do not have enough randomness as input into the algorithm, resulting in an encrypted output that could be weaker than intended.
Proactive Controls offer two solutions for cryptographic failures: C2: Leverage Security Frameworks and Libraries
and C8: Protect Data Everywhere. C2 prescribes the use of known good security frameworks and libraries. The same holds true for the source of cryptographic algorithms and implementations. Find a reliable, trusted source for your cryptographic functions, and rely upon that implementation to deliver your application’s cryptographic needs. C8 calls for data protection everywhere, in transit between your application and users and while resting in a database.
Action: Find a solid, trusted crypto library for your application and encrypt sensitive data in transit and at rest.
A03 Injection
An injection is when input not validated properly is sent to a command interpreter. The input is interpreted as a command, processed, and performs an action at the attacker’s control. The injection-style attacks come in many flavors, from the most popular SQL injection to command, LDAP, and ORM.
Proactive Controls has a plethora of options to deal with injection. C3: Secure Database Access was tailor-made to counter SQL injection. C3 includes securing the queries with prepared statements and using object-relational mapping libraries to isolate the raw creation of SQL queries. Secure configuration, authentication, and communication protect the database server and the database’s connection parameters. C4: Encode and Escape Data protects any data that is reflected back to the client, and C5: Validate All Inputs ensures that the input that comes inbound is validated using various rules.
Action: Validate all input, and avoid exposing any input directly to an interpreter.
A04 Insecure Design
An insecure design focuses on the design and architectural flaws. Many future vulnerabilities can be prevented by thinking about and designing for security earlier in the software development life cycle (SDLC).
There is no specific mapping from the Proactive Controls for Insecure Design. The Top Ten calls for more threat modeling, secure design patterns, and reference architectures. Threat modeling analyzes a system representation to mitigate security and privacy issues early in the life cycle. Secure design patterns and reference architectures provide a positive, secure pattern that developers can use to build new features.
Action: Threat model everything in sight and use secure design patterns and reference architectures as the foundation for anything new.
A05 Security Misconfiguration
Security misconfiguration is when an important step to secure an application or system is skipped intentionally or forgotten. Examples of security misconfiguration include missing appropriate security hardening, unnecessary features being enabled or installed, default accounts being enabled and unchanged, error handling bleeding information, disabling security features, or setting application frameworks to insecure settings.
There is no specific mapping from the Proactive Controls for Security Misconfiguration. The Top Ten calls for a repeatable hardening procedure as the foundation of how to counter security misconfiguration. C2: Leveraging Security Frameworks and Libraries could result in choosing frameworks with secure default configurations, which would counter various security misconfigurations.
Action: Harden everything within your environment, and look for frameworks with secure defaults.
A06 Vulnerable and Outdated Components
The world of software is made up of various libraries and frameworks. Developers write only a small amount of custom code, relying upon these open-source components to deliver the necessary functionality. Vulnerable and outdated components are older versions of those libraries and frameworks with known security vulnerabilities.
An application could have vulnerable and outdated components due to a lack of updating dependencies. A component, in this case, was added at some point in the past, and the developers do not have a mechanism to check for security problems and update their software components. Sometimes developers unwittingly download parts that come built-in with known security issues.
The Proactive Controls doesn’t have direct instructions to update dependencies often; there is a close match with C2: Leverage Security Frameworks and Libraries. The critical thing to remember is that when you use frameworks and libraries, you must instill a plan to check for known vulnerabilities and update those dependencies. Dependencies link to other dependencies, which results in an application relying upon thousands of packages with limited visibility to the developer of all those packages. Libraries and frameworks age like milk — they quickly curdle and need to be replaced with newer versions.
Action: If you use a framework or library, check for known vulns and update often!
A07 Identification and Authentication Failures
Identification and authentication failures occur when an application cannot correctly resolve the subject attempting to gain access to an information service or properly verify the proof presented as validation of the entity. This issue manifests as a lack of MFA, allowing brute force-style attacks, exposing session identifiers, and allowing weak or default passwords.
The Proactive Controls prescribes C6: Implement Digital Identity, which ties into the advanced authentication requirements presented in NIST 800-63b. Guidance is also provided about cookies, tokens, and the use of JWT.
Action: Implement the highest level you can support from NIST 800-63b.
A08 Software and Data Integrity Failures
Software and data integrity failures include issues that do not protect against integrity failures in software creation and runtime data exchange between entities. One example of a failure involves using untrusted software in a build pipeline to generate a software release. Another example is insecure deserialization, where an application receives an object from another entity and does not properly validate that object, resulting in an attack being loosed upon the application that received the object.
Use the Proactive Controls for validation and encoding (C4: Encode and Escape Data and C5: Validate All Inputs) to prevent insecure deserialization. Properly encode output and use JSON and other object-oriented binary styles. To protect the inputs in a build pipeline, rely upon C2: Leverage Security Frameworks and Libraries to ensure that you use the best possible components available, and enact methods to ensure that you have the released version of the software and not something that has been tampered with by an attacker.
Action: Enhance integrity by validating the software you use, and avoid serialization; instead, use JSON as a text format for inter-system data exchange.
A09 Security Logging and Monitoring Failures
Logging is storing a protected audit trail that allows an operator to reconstruct the actions of any subject or object that performs an action or has an action performed against it. Monitoring is reviewing security events generated by a system to detect if an attack has occurred or is currently occurring. A failure is when either of these actions is not performed correctly.
The Proactive Controls provide C9: Implement Security Logging and Monitoring, with direct guidance on tips and tricks for successful logging, avoiding other potential pitfalls that could result in attack conditions in the logging system. C10: Handling all Errors and Exceptions provides additional context for extending applications to reflect error conditions. The application has visibility into your logging and monitoring constructs.
Action: Just log and monitor; it may be near the bottom of the list, but it is the only way to know what steps have been performed against your system.
A10 Server Side Request Forgery (SSRF)
A Server Side Request Forgery (SSRF) is when an application is used as a proxy to access local or internal resources, bypassing the security controls that protect against external access.
While the Proactive Controls do not specifically address SSRF, C5: Validate All Inputs includes the validation of URL parameters, which are the root of most SSRF vulnerabilities.
Action: Validate any URLs allowed as input, and filter out any SSRF conditions.
Conclusion
While the current OWASP Proactive Controls do not match up perfectly with the OWASP Top Ten for 2021, they do a fair job of advising on controls to add to your applications to mitigate the dangers the Top Ten describes.
Ironically, the only Proactive Control that does not line up with one of the OWASP Top Ten 2021 items is C1: Define Security Requirements. C1 describes security requirements, points to the OWASP Application Security Verification Standard (ASVS) as a source, and describes a path for implementing security requirements. Proper security requirements can assist in limiting the blast radius of the OWASP Top Ten. Shifting left is a real thing, marketing term or not, and considering requirements early in the process of building something new lessens the impact of the OWASP Top Ten.
