Whether you’ve developed an application in-house or are simply using software-as-a-service apps, it is beneficial to know the standards that govern application security so you can ensure that you do not accidentally end up out of compliance with them, which in addition to potentially being a regulatory liability, would put you at risk of a data breach.
There are several standards that address application security, with the Open Web Application Security Project (OWASP) ASVS standard perhaps being the most applicable (no pun intended) because of its focus on applications specifically. Other organizations that also provide standards, such as NIST, ISO, and CIS, offer their appsec controls as part of a larger schema, governing IT security as a whole. This approach can be beneficial, however, if you are looking for uniformity across the entire organization. These standards are ultimately similar in the best practices they promote, so complying with one will put you on the path towards compliance with all. Which you choose to implement will be based on your organization’s goals for using the standard and the depth of your application development.
Application Security Verification Standard (ASVS)
OWASP, the Open Web Application Security Project, is a nonprofit foundation dedicated to promoting software security. They provide numerous resources for developers and security teams, including their OWASP Top 10 which enumerates the top web application security risks at a given time. OWASP also provides the Application Security Verification Standard (ASVS), a document that includes 14 requirements and their respective subsections, detailing web application security best practices. These include:
- Architecture, Design, and Threat Modeling
- Authentication
- Session Management
- Access Control
- Validation, Sanitization, and Encoding
- Stored Cryptography
- Error Handling and Logging
- Data Protection
- Communication
- Malicious Code
- Business Logic
- Files and Resources
- API and Web Service
- Configuration
The OWASP ASVS is used to “define, build, test, and verify secure applications.” The ASVS is currently on version 4.0. The most significant update in this version is changing their suggested authentication controls to align with the NIST 800-63-3 Digital Identity Guidelines, which promote “modern, evidence-based, and advanced authentication controls.” In describing this change, they cite their desire to have industry standards be compatible with one another, so organizations are not attempting to comply with competing standards.
Within each of the 14 requirements, there are items that serve as a checklist to ensure that key actions within that requirement are completed. For example, under Architecture, Design, and Threat Modeling, a checklist item is, “Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk
responses, and guide security testing.” Next to each checklist item are indications of the level they need to be performed for. The ASVS defines three levels:
- ASVS Level 1 is for low assurance levels and is completely penetration testable
- ASVS Level 2 is for applications that contain sensitive data, which requires protection and is the recommended level for most apps
- ASVS Level 3 is for the most critical applications – applications that perform high-value transactions, contain sensitive medical data, or any application that requires the highest level of trust
Most of the checklist items are for levels two and three, though there are some, like password security, that would be relevant at all three levels. Next to the level indications is the CWE that corresponds to each checklist item. CWE is a community-developed list of hardware and software weakness types. The goal is for you to be able to directly correlate these checklist items with weaknesses reported from your vulnerability management tools. Finally, the authentication section includes the corresponding NIST Digital Identity Guidelines standard as part of their effort for unity in standards across the industry.
National Institute of Technologies (NIST) Special Publication (SP) 800–218: Secure Software Development Framework (SSDF) Version 1.1
NIST is the National Institute of Standards and Technology, an agency of the U.S. Department of Commerce, charged with promoting “American innovation and industrial competitiveness.” As part of this mission, they provide various standards and frameworks for cybersecurity, including their special publication on software development. NIST’s Secure Software Development Framework (SSDF) is broken down into four areas:
- Prepare the Organization
- Protect the Software
- Produce Well-Secured Software
- Respond to Vulnerabilities
Each of these four is broken down into practices, which are then further divided into tasks. NIST then provides implementation examples for each of these tasks. For example, a practice is “Define Security Requirements for Software Development.” A task would be “Identify and document all security requirements for the organization’s software development infrastructures and processes and maintain the requirements over time.” One of the corresponding examples is, “Define policies for securing software development infrastructures and their components, including development endpoints, throughout the SDLC and maintaining that security.”
The SSDF also maps specific practices to the Executive Order (EO) on “Improving the Nation’s Cybersecurity (14028)” issued on May 12, 2021, which charged agencies, including NIST, with “enhancing cybersecurity through a variety of initiatives related to the security and integrity of the software supply chain.”
The NIST Framework goes into a little bit less detail than the OWASP standard, but the NIST Framework can help with the creation of high-level objectives for reporting to the board of directors and other leadership, and it is not in competition with the OWASP standard (as OWASP notes), so compliance with both is relatively straightforward.
International Organization for Standardization (ISO) 27034
The International Organization for Standardization (ISO) sets international standards for all types of industries, from food safety to the environment to IT security. ISO 27034 provides both an Organization Normative Framework (ONF) and an Application Normative Framework (ANF). The ONF is designed to be applied at the organizational level, so this involves designating roles and responsibilities, defining processes for IT security, general best practices, and adhering to the library of measures (Application Security Control (ASC) Library).
The ANF, on the other hand, is an application-specific version of the ONF that describes the specific requirements for that application. The application security controls are applied here based on the targeted level of trust, which ISO defines as “a set of Application Security Controls deemed necessary by the application owner to lower the risk associated with a specific application to an acceptable (or tolerable) level.”
ISO is a recognized international standard that is good for demonstrating a high level of security for regulated industries and global organizations. However, you do need to pay to access the ISO standard document, so if you’re not an enterprise software publisher, it might not be worth the investment.
Center for Internet Security (CIS) Control 16: Application Software Security
The Center for Internet Security (CIS) is a nonprofit organization that provides benchmarks and controls for securing IT systems and data. CIS also supports our fellow ISACs, the Multi-State ISAC, and the Elections Infrastructure ISAC, in conjunction with the Cybersecurity and Infrastructure Agency (CISA). CIS provides controls across all aspects of IT security, such as incident response, malware defenses, network monitoring, etc., with application security being covered in control 16. You may want to use the CIS control for application security if your organization has broadly adopted this set of controls to guide your overall security program strategy.
The CIS Application Software Security Control is broken down into 14 safeguards:
16.1: Establish and Maintain a Secure Application Development Process
16.2: Establish and Maintain a Process to Accept and Address Software Vulnerabilities
16.3: Perform Root Cause Analysis on Security Vulnerabilities
16.4: Establish and Manage an Inventory of Third-Party Software Components
16.5: Use Up-to-Date and Trusted Third-Party Software Components
16.6: Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
16.7: Use Standard Hardening Configuration Templates for Application Infrastructure
16.8: Separate Production and Non-Production Systems
16.9: Train Developers in Application Security Concepts and Secure Coding
16.10: Apply Secure Design Principles in Application Architectures
16.11: Leverage Vetted Modules or Services for Application Security Components
16.12: Implement Code-Level Security Checks
16.13: Conduct Application Penetration Testing
16.14: Conduct Threat Modeling
RH-ISAC members can join RH-ISAC’s Application Security Working Group, which provides a space for security professionals to share best practices with one another and learn from presentations on application security topics. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
