What is the ISO 27034?
The ISO 27034 standard provides an internationally-recognized standard for application security. Though not officially completed yet, much of the ISO 27034 standard’s structure is already set through the publishing of the first part: ISO/IEC 27034–1:2011.
The ISO 27034 is closely aligned with several other ISO standards, particularly ISO 27005 for information security risk management.
Why should you care about the ISO 27034?
You should care about the ISO 27034 if you develop software and your clients are security conscious. For example, companies that build software used by financial services, healthcare, public sector, defense, aviation, medical device, and industrial controls/mission-critical industries will likely be steered in the direction of adhering to the ISO 27034 over time.
In the interim, compliance with ISO 27034–1 is a competitive differentiator against most other software companies. This is one reason Microsoft announced compliance with ISO 27034–1 in 2013. Even if the ISO 27034 appears too complex for you to adopt, using its concepts as a basis for creating your application security program will likely put you ahead of your competitors who do not use it all.
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 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 paper will help shed light on the ISO 27034 with respect to some of the core elements. You should treat this paper as a primer. It is not a substitute for the actual ISO 27034–1 standard document which is much more detailed.
Application Security Control (ASC)
The ASC is one of the base concepts of the 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 3 different levels of levels of trust:
- On one end of the spectrum, level 0 which includes against only ASCs that mitigate the highest risk
- On the other end, level 2 which includes the most ASCs and mitigates many more risks
- In between is level 1 which 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 part 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:
- Application is an online banking application
- Application is internal facing
- Application is external facing
- Application allows money transfer
- Application is subject to European Privacy Directive
- Application is subject to PCI DSS
- Application is subject to Gramm–Leach–Bliley Act (GLBA)
- 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. If you are interested you should read the standard document for more details
Using SD Elements to Help Achieve ISO 27034 Compliance
SD Elements is uniquely positioned to help you achieve ISO 27034 compliance.
- Organizational Normative Framework (ONF): The SD Elements task library serves as an ONF, including a repository of Application Security Controls (ASCs), mapping to compliance regulations, and user roles with permissions
- Application Normative Framework (ANF): A specific project in SD Elements serves as an ANF, as it instantiates the elements of the ONF that are relevant to a particular application derived through business, regulatory, and technical contexts
- Business, Regulatory, and Technical Contexts: Contexts are captured through the project settings interface, which uses an automated questionnaire to derive application-specific context
- Application Security Controls (ASC): Tasks in SD Elements represent application security controls
- Application Level of Trust: Priority levels for tasks in SD Elements allow organizations to specify minimum priority thresholds for different levels of trust. For example, the lowest level of trust encompasses only “High” priority tasks
- Verification: Testing tasks in SD Elements serve as ways to verify other requirements, which are ASCs