For ISO 27001 compliance, test application security across your SDLC

Key takeaways

 

• ISO 27001/27002 updates for 2022 raise the bar for application security at all points in the software development life cycle.
• While vulnerability testing is a key requirement, a “multi-level and multi-methodology approach” is needed for development teams to achieve compliance.
• Luckily, a spectrum of testing tools is available for doing so. 

Attackers are constantly devising new and more devious ways to gain access to systems to steal confidential information, gain financially, or wreak havoc on an organization’s reputation and bottom line. That’s why strong security should be included as an ultimate goal in every DevOps project – right alongside achieving the designed functionality. And strong security means the application is free of security holes and will not succumb to malicious user input or intrusion attacks.

Achieving that goal is a challenge, which is why the updated International Standards Organization (ISO) 27001/27002 documents emphasize security testing throughout the software development life cycle (SDLC). In fact, the ISO 27001 information security, cybersecurity, and privacy protection standard and its companion document, ISO 27002, both updated in October 2022, now specifically require security testing in the SDLC, stating: “Security testing processes should be defined and implemented in the development life cycle.” 

Join the webinar with Invicti CISO and VP of Information Security Matthew Sciberras on Jan 26th:
New ISO 27001 Requirements for a Secure SDLC with Vulnerability Scanning 

Multiple tools needed for ISO 27001 SDLC security

These ISO documents lay out a strategy for managing security risks while developing and deploying applications. The ISO 27001 document describes the desired characteristics of an information security management system, while the ISO 27002 document defines specific directives and policies developers should implement to preserve the confidentiality, integrity, and availability of information.

Fortunately, many tools are available to test application security throughout the SDLC. Some tools look for weaknesses in code, others test user inputs in a running program, still others monitor a running program for possible intrusions. None of these tools is sufficient on its own. Each category of security testing tool has a place in an organization’s security testing suite. “A comprehensive, multi-level and multi-methodology approach is the only way to truly improve the security of the SDLC,” said Matthew Sciberras. 

To get the full text of both standards, you can purchase the documents directly from the ISO site (ISO 27001:2022 and ISO 27002:2022, in CHF) or the ANSI site (ISO 27001:2022 and ISO 27002:2022, in USD). 

Catch coding flaws early 

To catch vulnerabilities early in the coding cycle and before the application is running, static application security testing (SAST) and software composition analysis (SCA) tools are two options, often classified as white-box testing because both SAST and SCA have access to the code. 

SAST tools scan source code for known weaknesses. For example, they look for the flaws noted in the Common Weakness Enumeration (CWE) list, the 25 most dangerous software errors identified by the SANS Institute, and the Open Web Application Security Project (OWASP) Top 10 critical coding errors. These tools can detect vulnerabilities early in the SDLC, and in code that is deployed but not activated. Many of these tools integrate directly into build systems and issue-tracking systems. This makes the testing an integral part of the SDLC, rather than an extra step that developers might be tempted to skip under deadline pressure. One disadvantage is that some of these SAST tools are slow-running and may report false positives. 

SCA tools are designed to check for vulnerable open-source software components. An integral part of today’s applications, open-source software makes up, on average, 78% of the code base of deployed applications. SCA tools tend to be fast and have low false positive rates but have a limited scope. SAST and SCA tools are good for both initial coding as well as validating software updates in a continuous integration/continuous delivery (CI/CD) environment.

Continue testing deployed code

Once an application is running, whether in a test environment or deployed to a production system, you have more options for security testing. Interactive application security testing (IAST) tools interact with a running web application to provide runtime insights. Dynamic application security testing (DAST) tools perform black-box testing on web applications and mobile apps, runtime application self-protection (RASP) tools monitor inputs and outputs in a running application, and web application and API protection (WAAP) tools protect any exposed application programming interfaces (APIs). 

IAST tests can be integrated into the testing cycle or scheduled to run as needed. Because IAST tools access some code and configuration information, they are often referred to as gray-box testing. Some tools can assess the severity of the vulnerability and automatically issue a ticket to issue-tracking software. A wide variety of tools are marketed as IAST, but a good rule of thumb in terms of time to value is to look for tools that work without requiring changes to the code. 

Like IAST, modern DAST tools can also be integrated into the build cycle. An advantage of DAST tools is that they can be run from the first development builds through to post-deployment. They are independent of programming language, so the same tool can be used on any web-based application. These tools map out an application and then test all identified inputs for vulnerabilities, searching for opportunities for injections and other attacks. DAST tools can also assign priorities to the vulnerabilities found and issue tickets to issue-tracking software. These tools typically have a lower rate of false positives than for other types of automated testing, especially where they can provide confirmation. 

RASP tools, which are integrated with running web applications or mobile apps, have access to code and data. Rather than running tests, they block attacks by identifying behavior anomalies. Because of this, they can also be effective against zero-day attacks that exploit a newly identified vulnerability before an organization has time to close the gap. Although not a testing tool, a web application firewall (WAF) also provides some protection against attacks in the application layer. WAFs filter traffic based on predefined rules, allowing them to block known attacks. Like any firewall, these need to be configured and the appropriate rules defined. 

The bottom line

In sum, vulnerability scanning such as DAST, while required by the ISO 27001 2022 updates and a foundational component of web application security testing, is not enough by itself. A secure SDLC needs a comprehensive approach to testing methodologies. Penetration tests are needed because not every vulnerability can be detected automatically, especially business logic vulnerabilities. Code scanning with SAST can help detect vulnerabilities very early and in parts of code that may be deployed but not activated (so not testable dynamically) in the current build of the application.

With all these tools at an organization’s disposal, complying with the high security bar set by the ISO 27001/27002 documents while still delivering a functional application becomes an achievable goal.

Join the Invicti webinar with Matthew Sciberras on Jan 26th to learn more:
New ISO 27001 Requirements for a Secure SDLC with Vulnerability Scanning