5 Application Security Standards You Should Know

It shouldn’t be surprising that application security has become more important over the last few years. As part of the move to the cloud, applications have become the foundation of business operations. Today, more companies use more applications to do more things than ever before. SaaS applications transmit, store, and process large amounts of sensitive data — from personally identifiable information (PII) to intellectual property.

A July 2021 report from F5 Labs gives insight into how malicious actors use vulnerabilities in applications as part of their attacks and the impact it has on businesses, noting:

• 56% of the largest incidents in the last 5 years were linked to a web application security issue
• 57% of reported financial losses for the largest web application incidents over the last 5 years were attributed to state-affiliated threat actors
• 12% of threat groups use the ATT&CK tactic of exploiting public-facing applications

Application Security (AppSec) is now fundamental to ensuring continued business stability. While security is never the same as compliance, the five application security standards you should know give you a minimum set of baselines for putting best practices into place.

OWASP Application Security Verification Standard (ASVS)

The Open Web Application Security Project (OWASP) may be the one of the most respected standards in the developer community. The nonprofit foundation is a community-led, open-source resource focusing on:

• Tools and resources
• Community and networking
• Education and training

In October 2021, OWASP updated the ASVS which provides a basis for designing, building, and testing technical application security controls. The ASVS establishes three verification levels:

• Level 1: low assurance levels, completely penetration testable
• Level 2: applications containing sensitive data, recommended for most apps
• Level 3: applications performing high-value transactions, containing sensitive medical data, or requiring the highest level of trust

The ASVS lists 14 controls:

• 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 review
• Business logic review
• Files and resources
• API and web service
• Configuration

Additionally, the ASVS notes it can be applied to the following use cases:

• Security architecture guide
• Replacement for off-the-shelf secure coding checklists
• Guide for automated unit and integration tests
• Secure development training
• Driver for agile AppSec
• Framework for guiding the procurement of secure software

National Institute of Technologies (NIST) Special Publication (SP) 800–218 (DRAFT)

NIST is the US federal agency tasked with setting out best practices governing the public sector. Released for public comment on September 30, 2021, the NIST 800–218 (DRAFT) “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities” outlines 19 practices organized into the following four categories:

• Prepare the organization (PO)
• Protect the software (PS)
• Produce well-secured software (PW)
• Respond to vulnerabilities (RV)

The 19 practices are accompanied by tasks that can achieve compliance. These practices are:

• Define security requirements for software development (PO.1)
• Implement roles and responsibilities (PO.2)
• Implement supporting toolchains (PO.3)
• Define and use the criteria for software security checks (PO.4)
• Implement and maintain secure environments for software development (PO.5)
• Protect all forms of code from authorized access and tampering (PS.1)
• Provide a mechanism for verifying software release integrity (PS.2)
• Archive and protect each software release (PS.3)
• Design software to meet security requirements and mitigate security risks (PW.1)
• Review the software design to verify compliance with security requirements and risk information (PW.2)
• Reuse existing, well-secure software when feasible instead of duplicating functionality (PW.4)
• Create source code by adhering to secure coding practices (PW.5)
• Configure the integrated development environment, compilation, interpreter, and build processes to improve executable security (PW.6)
• Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements (PW.7)
• Test executable code to identify vulnerabilities and verify compliance with security requirements (PW.8)
• Configure software to have secure settings by default (PW.9)
• Identify and confirm vulnerabilities on an ongoing basis (RV.1)
• Assess, prioritize, and remediate vulnerabilities (RV.2)
• Analyze vulnerabilities to identify their root causes (RV.3)

International Organization for Standardization (ISO) 27034

ISO is the international industry association that sets standards across multiple industries, including technology. ISO 27034 establishes the Application Normative Framework (ANF) and Application Security Management Process that offer controls and processes for the secure software development lifecycle (SSDLC).

The ANF outlines the following 10 components:

• Defining the application business context
• Reviewing the application regulatory context
• Understanding the application technological context
• Application specifications
• Assigning roles, responsibilities, and qualifications
• Setting selected Application Security Controls (ASCs)
• Processes related to the security of the application
• Application lifecycle
• Information involved by the application

Center for Internet Security (CIS) Control 16: Application Software Security

CIS is a community-driven nonprofit that sets best practices for securing IT systems and data. While OWASP focuses only on applications, CIS incorporates application security into its set of 18 overarching security controls.

Under Control 16 “Application Software Security,” the 14 controls are:

• Establish and maintain a process to accept and address software vulnerabilities
• Perform root cause analysis on security vulnerabilities
• Establish and manage an inventory of third-party software components
• Use up-to-date and trusted third-party software components
• Establish and maintain a severity rating system and process for application vulnerabilities
• Use standard hardening configuration templates for application infrastructure
• Separate production and non-production systems
• Train developers in application security concepts and secure coding
• Apply secure design principles in application architectures
• Leverage vetted modules or services for application security components
• Implement code-level security checks
• Conduct application penetration testing
• Conduct threat modeling

Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS)

For any applications handling payment card information, PA-DSS guides the secure development practices. PCI is the standards organization that manages payment card security under the PCI Data Security Standard (PCI DSS). The PCI can levy fines up to $100,000 per month for compliance violations.

PA-DSS outlines 14 compliance requirements:

• Do not retain full track data, card verification code or value
• Protect stored cardholder data
• Provide secure authentication features
• Log payment application activity
• Develop secure payment applications
• Protect wireless transmissions
• Test payment application to address vulnerabilities and maintain payment application updates
• Facilitate secure network implementation
• Cardholder data must never be stored on a server connected to the internet
• Facilitate remote access to payment application
• Encrypt sensitive traffic over public networks
• Encrypt all non-console administrative access
• Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators
• Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators

Under “Requirement 5: Develop secure payment applications,” PA-DSS goes into further detail for developers outlining 6 primary requirements with multiple sub-requirements within them, including:

• Define and implement a formal secure development process that includes code review prior to release, secure source control practices, and secure code development training
• Prevent common coding vulnerabilities, including those described in the OWASP Top Ten and all “high risk” vulnerabilities outlined in PA-DSS Requirement 7
• Establish change-control procedures
• Document software-versioning methodology
• Engage in a risk assessment to identify potential application security design flaws and vulnerabilities during the software development process
• Implement and document the authorization process for final application releases and updates

Complying with Application Security Standards

Across the five application security standards, many of the best practices and controls overlap. For example, mitigating the risk of an injection attack, engaging in code reviews, and ensuring developers have secure code training are fundamental steps to all compliance mandates. Often, a team may need to map their processes to multiple standards, like NIST and PA-DSS if they are developing software that will be used to collect payments and might be used in the public sector.

With ShiftLeft, AppSec teams have all the tools they need to secure applications and meet compliance requirements. ShiftLeft enables DevSecOps teams to build security testing directly into their workflows for continuous application security monitoring during the development phase. They can supplement these capabilities with ShiftLeft Education by assigning appropriate training to the right team, providing reporting capabilities, and aligning certifications to compliance requirements. ShiftLeft CORE provides the compliance reports that leadership, partners, and auditors need. ShiftLeft CORE is the only code analysis platform to provide a software bill of materials (SBoM) that uniquely accounts for the specific attackability of each open source package used by the app. Unless attackability is determined, the security risk of your application is artificially inflated by vulnerabilities in open source libraries that are impossible for outsiders to reach given the architecture of your application.