Mapping Security Requirements Standards: OWASP ASVS ISO 27001

 


 

The Challenge of Mapping Security Requirements to Standards

There is no secret process for building secure software. At its core, secure development requires organizations to identify threats and risks, then build controls to mitigate risks.

There are plenty of frameworks available to help and regulatory standards also provide guidance.

In many organizations, the problem is not the lack of available guidance. Instead, it is the difficulty in mapping those standards and guidelines to actionable security requirements and controls. This requires teams to understand all in-scope regulatory requirements for each application. Some make this easy. The Payment Card Industry Data Security Standard (PCI DSS), provides granular guidance on securing applications managing cardholder information, including testing procedures for each requirement. Others, like the Health Information Portability and Accountability Act (HIPAA) simply require organizations to “Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [organization], then build policies and controls to mitigate risk from those threats.”

Mapping requirements to standards ensures compliance. Doing so when attempting to comply with multiple standards can be challenging. For example, many organizations strive for compliance with ISO 27001 for enterprise information security.

To secure the software they build, they also comply with the OWASP Application Security Verification Standard framework. Avoiding redundancy and extra work when dealing with both standards can be difficult.

This article looks at how an organization can minimize duplication when complying with these standards.

What is OWASP ASVS?

The Open Worldwide Application Security Project (OWASP) has provided resources, tools, and education to help organizations build more secure software for over 20 years. One such resource is the OWASP Application Security Verification Standard (ASVS), a framework that provides a detailed set of security requirements that organizations can use “to create a Secure Coding Checklist specific to [their] application, platform or organization.”

ASVS defines security controls for 14 categories in its Architecture section, including Design and Threat Modeling, Authentication, Access Control, Password Security, and others. It provides three security levels and varies the requirements based on the criticality of each application:

  • ASVS Level 1: The “bare minimum” standard for any application.
  • ASVS Level 2: The category for applications that manage sensitive information or when data integrity is critical. The framework suggests that “most applications” fall into the
  • ASVS Level 3: Level 3 is for “high value, high assurance, or high safety” This would include critical infrastructure or applications where a breach or failure would “significantly impact” the organization.

What is ISO 27001?

ISO 27001 is an international standard for information security management systems (ISMS) jointly created by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). While ASVS is focused solely on application security, ISO 27001 provides organizations with a framework to protect sensitive data across all applications and systems. Annex A of ISO 27001 provides a list of 93 security controls that organizations can implement across four “control domains”:

  • People Controls: 8 controls covering topics including screening potential employees, security awareness training, confidentiality agreements, and remote working.
  • Physical Controls: 14 controls including physical security perimeters and monitoring and “clear desk” policies.
  • Technological Controls: 34 controls including Privileged access rights, source code control, data masking, and

Potential Overlaps Between OWASP ASVS and ISO 27001 Requirements

As noted, OWASP ASVS applies only to building secure web applications and web services. ISO 27001 is broader, covering all systems. Mapping OWASP ASVS to ISO 27001 allows organizations to align application security with broader information security policies and avoid conflicting policies and controls. Here are some examples

  • Organizational Controls: 37 controls that cover organizational policies, segregation of duties, return of organizational assets, supplier agreements, and other factors.

V1 Architecture, Design and Threat Modeling

The ASVS contends that as organizations adopt DevSecOps practices, security architecture must evolve away from traditional enterprise architecture roles. DevSecOps requires adopting agile security principles while maintaining core security architecture concepts.

ASVS Requirements

V1.1 (Secure Software Development Lifecycle) requires teams to integrate threat modeling into the design phase to identify and mitigate potential vulnerabilities early on. It specifically requires teams to “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.”

ISO 27001 Requirements

Annex A.14.1: Security requirements of information systems: This control focuses on integrating security requirements throughout the lifecycle of information systems, ensuring confidentiality, integrity, and availability across all stages of the development lifecycle.

Annex A.14.2: Security in development and support processes: Ensures that information security controls are designed and implemented during the development process.

Annex A 8.26: Application Security Requirements: Defines the procedure for identifying, specifying, and approving information security requirements during the development or acquisition of applications.

What to Watch For

Mapping Architecture, Design and Threat Modeling activities to ISO 27001 A.14 integrates application security practices with broader ISMS standards regarding integrating security into a system’s life cycle. Further, it supports A8.26 by ensuring that any third-party components or services integrated into the application are assessed for security risks throughout the development lifecycle, including any design changes or enhancements. As you develop security controls, make sure they are consistent across both standards.

ASVS Requirement

V1.6 Cryptographic Architecture Cryptography is used to protect data in applications and communications. While encrypting “everything” may seem simple, it can inhibit application performance and impact costs. Further, encryption algorithms have a useful “shelf life” and must be replaceable as older algorithms become increasingly “hackable”.

V1.6 requires organizations to enforce policies for managing cryptographic keys, key rotation, and to treat as insecure all client-side secrets such as password or API tokens.

ISO 27001 Requirement

Annex A 8.24: Use of cryptography – The ISO guidance emphasizes selecting appropriate controls, managing cryptographic keys, algorithm selection, and secure protocols. Additionally, it addresses using secure communication protocols like TLS and SSH to protect data during transmission.

What to Watch For

ASVS V1.6 can support ISO 27001 A.8.24 by ensuring that applications are designed with secure cryptographic practices in mind.

This includes ensuring that data encryption is properly implemented and managed within the application to support broader ISMS requirements for secure cryptographic controls.

Common Challenges When Mapping Requirements

Today’s regulatory environment changes rapidly. Overlapping areas, including those noted above, require careful alignment to avoid redundancy. The key to compliance is visibility to requirements and consistency in approved security controls. Ad hoc testing for compliance at the end of the development process slows down development and contributes to friction between development, compliance, and security teams.

Tracking Updates

Regulatory standards and best practices (whether internal or external) are subject to changes. Tracking changes, translating those into security requirements, and updating appropriate security controls can be challenging for a single standard. Multiplying that by the dozens of security and privacy standards organizations must address can challenge even large security and compliance teams.

Scalability

Determining which controls are required by ASVS and ISO 27001 requires deep knowledge of both programs. In most organizations, there will be a small number of experts able to perform that task. Due to the time involved, this can limit applying appropriate security requirements to only the most critical applications. This leaves the majority of an organization’s application inventory at risk.

Consistency

As personnel change, so too do opinions on the security requirements and controls. Manually assessing threats to an application or system and the appropriate countermeasures for each threat leads to inconsistent security controls. Using shared documents and spreadsheets to communicate and track the proper implementation of each control, often left to the discretion of QA.

Limited Security Resources

Relying on a security team to map all requirements is a recipe for failure. Teams responsible for application security are dwarfed in size by development teams. The BSIMM15 study by Black Duck analyzed 121 organizations and a total of over 259,000 developers managing over 90,000 applications. For every 100 developers there were only 1.4 security personnel and 3 security champions.

Depending on these resources to track and map requirements to all regulatory standards is ill advised.

Auditability

Spreadsheets may seem to be a simple way to track risks and controls, but from a regulatory compliance standpoint they lack auditability. Without a central, controlled repository for risk assessment data, with an auditable record of changes, it is difficult to prove compliance to an auditor, customer, or corporate Board.

How SD Elements Helps

SD Elements allows development, security, and operations teams to generate security requirements and ensure compliance with traceability. Based on a brief survey, SD Elements identifies threats to the application, its technology stack, and deployment environment. It further maps requirements from applicable regulatory standards and translates those into actionable controls that include code snippets and detailed test plans.

Deduplication of Overlapping Requirements

The SD Elements Content Library covers over 40 distinct regulations and standards including the OWASP ASVS, ISO 27001, NIST 800-53,and FedRAMP. SD Elements determines which standards and requirements are “in scope” based on the survey and automatically deduplicates overlapping requirements.

Consistent, Trackable Requirements and Controls

Our knowledgebase of industry and regulatory standards, development frameworks, and security best practices eliminates ad hoc decisions, ensuring consistency across an organization’s entire application inventory. If desired, organizations can customize the survey and controls to match internal security policies. It provides a centralized, controlled, and auditable environment for recording all activity regarding a project’s requirements, assigned controls, and implementation.

Continuous Updates

Regulatory requirements change frequently, as do internal policies and the threat space. To keep organizations protected without investing in an in-house team, SD Elements’ content library is continuously updated by security experts at Security Compass. As new content on security weaknesses and mitigations are added to the content library, users are automatically notified and have the option to accept the latest content updates applicable to a project.

About SD Elements

Almost every application will require compliance with customer or regulatory standards. While frameworks like OWASP ASVS and regulatory standards like ISO 27001 offer guidance, turning these into actionable security requirements and controls in a non- redundant and consistent manner challenges most organizations. SD Elements enables teams to proactively reduce risk by addressing security requirements before coding begins. It provides development and operations with effective security controls that are implemented during the normal development process. This, in turn, minimizes costs from the rework required when teams rely solely on security scanners to mitigate risk.

About the Author

Bruce Warren is a seasoned technology marketing executive with over 20 years experience across all marketing disciplines including brand and communications, product marketing, and demand generation. Prior to joining Security Compass, Bruce held a variety of progressively senior leadership positions within B2B software companies in a range of industries. Bruce holds a BA (Advanced Major) in English from the University of King’s College, Dalhousie, an MBA from London Business School and is a graduate of the CMO program from Northwestern University – Kellogg School of Management.

Security Compass helps organizations build secure and compliant software by design. SD Elements, our core platform, enables teams to identify potential threats and generate security requirements before coding begins. Seamless integrations with existing DevSecOps tools and workflows enable developers to produce secure code efficiently. Our Application Security Training combines a rigorous curriculum with hands-on labs, equipping developers with the skills to build secure software with confidence. To discover how Security Compass enables secure software development at scale, visit www.securitycompass.com.