Updates to ISO 27001/27002 raise the bar on application security and vulnerability scanning

Key takeaways

 

• The October 2022 updates to ISO 27001/27002, the first since 2013, recognize technological changes such as the rise of cloud computing and agile development.
• For application development and security, they define controls that encompass the full software development life cycle for the first time.
• Updated ISO 27001/27002 security controls specify security testing at multiple points during development and after deployment, making vulnerability scanning a practical necessity. 

There’s mounting research to back up what you already know: The number of cyberattacks is increasing – and costing organizations more – every year. A comprehensive 2022 study of current and historical data notes a 44% rise in publicly reported cybersecurity incidents over the past decade, with a typical cost of $266,000 per incident that grows to $52 million for the top 5% of incidents. In response, organizations know they must protect themselves with ever-more-robust cybersecurity management systems that reach all the way back into their software development practices to ensure that the applications they build are inherently more secure. 

To that end, the International Organization for Standardization (ISO) 27001 information security, cybersecurity, and privacy protection standard and its companion document, ISO 27002, both updated in October 2022, provide an excellent and newly fleshed-out framework for doing so. The ISO 27002 2022 update, the first since 2013, reorganizes 14 information security categories into four – People, Organizational, Technological, and Physical – and for the first time directly addresses the full software development life cycle (SDLC). 

“The 2022 version is long overdue, especially because it provides so much more value when it comes to the framework organizations need to protect today’s information technologies,” said Matthew Sciberras, CISO and VP of Information Security at Invicti.

What’s new in ISO 27001/27002

The main text of the ISO 27001 standard describes in broad strokes the goals and characteristics of an overarching secure management system, while the annex lists in ISO 27002 describe in detail the security controls – i.e., processes, policies, and logical controls – that organizations can use to achieve their cybersecurity goals. The prior edition included a Software Development Environment control that mentioned SDLC, but the 2022 edition reorganizes multiple granular controls within a newly created SDLC control.  

Many of the new control requirements were prompted by innovations in both technology and cyberattacks over the past decade. For example, among the standard’s new requirements is one for defining security responsibilities between a cloud provider and an organization – one that would have had limited applicability nine years ago. 

Other new-for-2022 controls include building threat intelligence by collecting and analyzing data about existing or emerging threats; ensuring IT departments are prepared for business continuity; continuously monitoring physical premises to prevent unauthorized access; deleting stored information when no longer needed; masking/encrypting data to limit exposure of sensitive information; monitoring networks, systems, and applications for deviations from a defined baseline of normal activities; and restricting access to external websites that may compromise data.

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). 

What does this mean for developers?

The biggest impact of the updated standard for software development teams is that the new control for secure SDLC wraps a number of previous controls into a coherent set of requirements for the software life cycle. Specifically, ISO 27002 lists the following as requirements necessary for a secure SDLC and then links to one or more controls that expand on each requirement:

• Separating development, test, and production environments. 
• Defining security requirements in the specification and design phase. 
• Applying secure system architecture and engineering principles.
• Performing system and security testing on deployed code, such as regression testing, code scanning, and penetration tests.
• Using project management principles to address risks at any stage in the SDLC.
• Defining secure coding guidelines for each programming language.
• Building developer expertise in secure coding techniques and in finding and fixing vulnerabilities. 
• Creating secure repositories with restricted access to source code. 
• Securely protecting software, hardware, services, and network configurations. 
• Setting up secure version control with formal rules for managing changes to existing systems.
• Applying security requirements to any outsourced development.

“Everything in the updated standard represents practices that every good software engineering shop should be doing, but very few are doing all of these things,” Invicti’s Sciberras noted. Each gap in current secure development practices can translate into increased cybersecurity risk. 

While many of the listed controls were already included in the older version of the standard (if scattered among multiple categories), the secure coding control is new. This control specifies activities and best practices for establishing a secure development environment, defining and following coding standards, and continually maintaining the security of production code. Additionally, the standard requires organizations to hold third-party and open-source software to the same coding standards as they use internally.  

Why vulnerability scanning is necessary to comply with the standard

But even with the strictest design and coding practices, vulnerabilities can creep into an application. This is why vulnerability scanning during development and testing and after deployment is emphasized in multiple places in the standard. In addition to the overall SDLC control, there are two controls that directly address vulnerability testing:

• Management of Technical Vulnerability: Specifies that the organization’s exposure to attacks should be assessed and remedied. To accomplish this, the control recommends using vulnerability scanning tools as well as penetration testing. 
• Security Testing in Development and Acceptance: Recommends performing vulnerability scanning and penetration testing throughout the SDLC to verify that security requirements have been met. 

“The ISO standards tell you what to do but not how to do it, so any vulnerability and penetration testing method would be acceptable,” Sciberras explained. “But the automated capabilities that DAST brings to the table will lead most organizations toward DAST tools.”

In fact, four types of application security testing tools are in common use and work synergistically: software composition analysis (SCA), static application security testing (SAST), interactive application security testing (IAST), and dynamic application security testing (DAST). SCA, SAST, and IAST look for vulnerabilities on the code side, with SCA checking for known vulnerable components. DAST performs black-box testing on a running application, allowing it to be used both during development and after deployment. 

DAST tools can be incorporated into the SDLC and the continuous integration/continuous deployment (CI/CD) workflows that are the backbone of DevOps, and they can scan any type of web application, service, or API. Some such tools, notably Invicti’s, can also discover web assets in their crawling phase as well as identify outdated technology stack components, including runtimes, frameworks, databases, libraries, and web servers. 

Benefits of vulnerability scanning

Testing tools such as Invicti’s AppSec solutions continuously work on all phases of the CI/CD pipeline, scanning during development to validate code, scanning preproduction systems to validate the environment, and scanning test systems to validate production code. Further, they can be fully integrated with development and build tools so that when a vulnerability is found, they automatically notify the developer responsible for that code segment, providing the information needed to fix the problem.

A big advantage of Invicti’s DAST tools is that they provide automatic confirmation for the majority of important vulnerabilities to prove they are real issues and not false positives. In other words, when a vulnerability is identified, the tools attempt to safely perform a test attack and retrieve a piece of data as evidence. 

The new standard for application security

The bottom line is that vulnerabilities cannot be ignored at any point in the software development life cycle. Certainly, identifying and managing all threats can be daunting, but when faced with the possibility of an attack that could derail development or, worse, cause a breach for customers of deployed software, testing for vulnerabilities both early and often is more than an obvious solution – it’s the specified standard.