The Beginner’s Guide to ISO 27034

Conversely, you should care about ISO 27034 if you buy software and you are security conscious. Nearly all vulnerabilities listed in the common vulnerabilities & exposures (CVE) database are the result of insecure software.

These vulnerabilities make your organization more insecure in several ways.

• Insecure operating systems, browsers, and desktop software result in the contraction of malware.
• Insecure web applications result in the direct compromise of your internal servers; and other software, particularly with the proliferation of embedded devices in the Internet of Things (IoT) provides new attack surfaces into your internal network.

In many ways, most of the rest of your information security spending is a result of holes in the security of the software you bought. Because there isn’t enough customer or regulatory pressure on most software vendors to build secure software from the start, there really isn’t any incentive for most vendors to change their behavior.

Becoming savvy about software security, particularly in driving your vendors to adopt the ISO 27034, will have a major impact in reducing the risk to your organization and the general state of information security overall.

Understanding core elements of the ISO 27034

In order to comprehensively tackle as large a problem as software security, the ISO 27034 is complex. It includes many concepts, terms, and activities that most organizations are unfamiliar with.

This post will help shed light on ISO 27034 with respect to some of the core elements.

Application Security Control (ASC)

The ASC is one of the base concepts of ISO 27034. An ASC is simply a control to prevent a security weakness within an application. For example, “binding variables in SQL statements” is an application security control to prevent SQL injection  —  a common application security weakness. Some organizations may refer to these as application security requirements.

Each ASC is relevant to a particular application based on its contexts. In the binding SQL statement example, the ASC is relevant to applications that use a database. In this case, we are referring to a technical context.

There are also regulatory contexts. For example, an ASC to mask credit card numbers on screen is relevant to applications that fall under the scope of the Payment Card Industry Data Security Standard (PCI DSS).

Other ASCs may be relevant to a particular business context, such as a control to prevent one user from being able to view another user’s account in an online banking application. This is only relevant to applications that have online banking functionality.

Each ASC must also have a verification measurement. For example, the verification for “binding variables in SQL statements” may include auditing all source code to ensure that every interaction with a database follows the control. Alternatively, it may include running a scanning tool that checks for SQL injection vulnerabilities.

Application Level of Trust

Even though ASCs use contexts to derive when they apply to a particular application, not every application has the same need for security controls. For example, an internal-facing application with no sensitive data has a very different risk profile than a web-facing application with customers’ personally identifiable information. For this reason, ISO 27034 introduces the concept of Levels of Trust. Each ASC can fit within one or more levels of trust.

For example, a bank may have three different levels of trust:

• On one end of the spectrum, level 0 that includes only ASCs that mitigate the highest risk.
• On the other end, level 2 that includes the most ASCs and mitigates many more risks.
• In between is level 1 that has fewer ASCs than level 2 and more ASCs than level 0.

When you first create an application, it has a targeted level of trust. After the application is audited, it reveals an actual level of trust. In theory, these two should be the same. However, there may be cases where application developers fail to properly implement controls. This results in the application actually having a lower level of trust than anticipated.

Organization Normative Framework (ONF)

At its essence, the ONF is a company-wide repository of Application Security Controls and processes. The organization can store and update ASCs in a central library called an ASC Library, which is part of the ONF. The ONF also specifies how and when an application development project should use a particular security activity, such as conducting a penetration test. It groups ASCs by level of trust, which is described below.

An example of an application security control library:

The ONF also includes a list of all of the elements in the business, regulatory, and technological contexts. For example, a bank may have the following:

Business contexts:

• Application is an online banking application
• Application is internal facing
• Application is external facing
• Application allows money transfer

Regulatory contexts:

• Application is subject to European Privacy Directive
• Application is subject to PCI DSS
• Application is subject to Gramm–Leach–Bliley Act (GLBA)

Technological contexts:

• Application is web-based
• Application is an embedded system
• Application uses RESTful web services
• Application uses a SQL database
• Application uses Java

The ONF includes an application specifications repository, which is essentially a place to store functional requirements for all applications. For many companies, this is an Application Lifecycle Management tool like Atlassian JIRA.

The ONF also includes an Application Life Cycle Security Reference Model. This is basically a complex way of saying a process-agnostic way to define planning, building/buying, testing, using, and decommissioning applications and their associated infrastructure. The purpose of this model is to define at which stages a particular ASC should be used regardless of which kind of process you use (e.g. waterfall vs. agile).

The standard goes into depth about the various elements of the life cycle. The standard uses the term Application Life Cycle rather than software development process or life cycle because its scope is broader: it includes all the steps before and after actually developing an application.

There are other elements in the ONF, such as details around roles & responsibilities which complement this. Refer to the ISO paper for more details on these.

Application Normative Framework (ANF)

The ANF is the set of ASCs and application security processes that apply to a particular application, based on its contexts, specifications (i.e. functional requirements or user stories), and its development & operational processes (a.k.a. application lifecycle).

For example, an online banking application with a highly targeted level of trust may have 100 different ASCs, along with a variety of application security processes such as threat modeling and/or code reviews. These ASCs and processes map to the application team’s agile development process along with its operational and decommissioning processes.

Application Security Verification Process

The verification process includes assessing each ASC using its verification measurements. In layman’s speak, this generally means performing assessment activities like code reviews and penetration testing. Most organizations are likely already undergoing some sort of application security verification process. However, the difference with ISO 27034 is that the verification is tied back to ASCs. In other words, you are defining requirements on how to secure your applications and you are tying your testing activities back to those requirements. Few organizations map their security testing back to controls/requirements.

Other ISO 27034 concepts

The standard details many other concepts, such as performing application security risk assessments, processes to create the ONF and ANF, and others.