ISO 27034 on Application Security: Reading It = A Waste of Time?

The title of ISO 27034 is “Information technology — Security techniques — Application security”. It is referenced in the BSI guidelines, among other places.

But some manufacturers are asking themselves: do I need to read this standard as well? Should I expect my auditor to demand conformity with this standard (with reference to the state of the art)?

Before you spend a lot of money on this standard and spend time studying (it is hundreds of pages long), this article will give you an overview of it. Then you can make your decision.

1. ISO 27034: why you should even consider this standard

a) Because inadequate IT security causes harm and endangers patients

The new records being set every year for the number of attacks, of new malicious software programs, and of companies and patients suffering harm make clear: we don’t have the IT security of most applications under control.

So, a standard like ISO 27034 can help to identify and apply best practices in order to improve the IT security of your own devices and systems.

b) Because IT security is a regulatory requirement

The number of regulatory requirements for IT security and data protection is increasing exponentially. These include, on the one hand, non-sector-specific directives such as the NIS Directive (Directive on security of network and information systems) and the General Data Protection Regulation (GDPR) as well as, on the other, sector-specific regulations.

For medical devices, the EU medical device regulations (MDRIVDR) as well as IT security requirements such as those contained in the German Verordnung für digitale Gesundheitsanwendungen (DiGAV) apply.

Additional information

You can find an overview of the jungle of regulatory requirements for the IT security of medical devices and for the healthcare sector here.

c) Because you need to know the state of the art, and not just during audits

However, these laws and regulations are not able to keep up with technological progress quick enough to allow them to make concrete specifications. Therefore, the regulations require manufacturers to guarantee the IT security of their devices according to the state of the art.

This state of the art is described in standards. The BSI confirms that IEC 27034 is one of these standards in its guidelines on medical device security.

As a manufacturer or operator of medical devices, during an audit, you should at least have heard of ISO 27034 and be able to give reasons if you have not followed this family of standards.

2. Overview of ISO 27034

a) Who ISO 27034 is aimed at

The family of standards is aimed at a very wide readership:

  • Managers, including project managers, IT security managers, software application managers
  • Technical teams, such as software architects, software developers and testers, system administrators and other technical personnel
  • Purchasers of software
  • Service providers who develop and/or provide software and who have to guarantee the security of this software
  • Auditors
  • Users who install and use the software

b) Objectives and non-objectives of ISO 27034

The objectives of ISO 27034 are:

  • To provide concepts, principles and processes
  • To support manufacturers in defining risk-based IT security requirements
  • To provide mechanisms for demonstrating the IT security of applications
  • To make the requirements of the ISO 27001 family implementable

Unfortunately, ISO 27042 does not want to define any concrete measures or coding rules. Nor does it claim to be a standard for software life cycle processes, for project management or for development.

c) Overview of the ISO 27034 family

Reference

Name

Published

ISO/IEC 27034-1

Overview and concepts

2011 (Confirmed in 2017)

ISO/IEC 27034-2

Organization normative framework

2015

ISO/IEC 27034-3

Application security management process

2018

ISO/IEC 27034-4

Validation and verification

2020 (DIS status)

ISO/IEC 27034-5

Protocols and application security controls data structure

2017

ISO/IEC TS 27034-5-1

Protocols and application security controls data structure, XML schemas

2018

ISO/IEC 27034-6

Case studies

2016

ISO/IEC 27034-7

Assurance prediction framework

2018

3. ISO 27034-1

ISO 27034-1 is the introductory standard. In section 5, it describes its interaction with the other members of this family of standards. In sections 6 and 7.1, it introduces general concepts.

The standard follows a holistic and academic approach. It differentiates between the framework at the organizational level (Organization Normative Framework (ONF) – chapters 7.2 and 8.1) and the specific framework for an application (Application Normative Framework (ANF) – section 7.3 and 8.3).

a) Organization Normative Framework (ONF)

At the ONF level, manufacturers should define:

  • The processes related to IT security
  • The associated roles and responsibilities
  • General best practices
  • Library of measures (Application Security Control Library – ASC Library)

ISO 27034 requires these definitions to be specific for the company’s business, regulatory and technological context (see Fig. 3).

For medical device manufacturers, the regulatory context includes the regulations and laws named above. The business context might involve, for example, the manufacturer developing devices with a specific intended purpose and operating software as a service, as a lot of DIGA manufacturers, for example, do.

Recurring requirement specifications for applications can also be collected in a repository at the ONF level.

b) Application Security Control

Application Security Controls (ASCs) are a central concept of ISO 27034 at both the organizational and the application levels.

The standard defines these ASC as follows:

 Definition: Application Security Control

“data structure containing a precise enumeration and description of a security activity and its associated verification measurement to be performed at a specific point in an application’s life cycle”

Source: ISO 27034-1

ISO 27034-5 describes this data structure in the form of XML Schema files.

An ASC contains the following information:

Element

Related attributes

Examples

ASC identification

Name; ID; author; date; references to other ASCs and to related elements in the context

 

Aim of the ASC

Reason for the ASC; level of trust to be achieved (see below); threat to be controlled by it; corresponding element of the specification

An ASC can relate, for example, to a requirement that a user be correctly authenticated.

Target Level of Trust = high

Activity

Description of the activity; outputs to be achieved; method to be used; subject of the activity; timing of the activity; responsible role (with necessary qualifications); associated costs

Developers should use approved Java libraries to implement session administration. They should do this during the development phase. The expected result is that the login is saved in the audit log and that a unit test has checked this function. This takes around 10 days.

Verification of the ASC

Here, too, it has to be specified who does what, when, with what objective, how (which method), and how much it will cost.

The verification is performed by another developer based on the review of the audit log and the documented unit test results. This verification takes 1 day.

ISO 15408-3 and NIST-Special Publication 800-53 contain thousands of these ASCs. Even at the organizational level, the ASCs should be given the aforementioned contexts and Targeted Levels of Trust.

c) Targeted Level of Trust

ISO 27034 defines the Targeted Level of Trust as follows:

Definition: Targeted Level of Trust

“name or label of a set of Application Security Controls deemed necessary by the application owner to lower the risk associated with a specific application to an acceptable (or tolerable) level, following an application security risk analysis”

Source

Ultimately, these labels are texts that the organization may define itself, for example, 1 to 5, or “low”, “medium”, and “high”. They group the ASCs that together define the necessary activities for a trust level.

Context

Specifications, restrictions

Target level low

Target level medium

Target level high

Business context

Defibrillator programming

 

ASC9

ASC12

Regulatory context

IEC 60601-1

 

ASC22

ASC3

Regulatory context

GDPR

ASC11

 

ASC3

Technical context

Windows operating system

 

ASC22, ASC23

 

Applications

Login

ASC31

ASC12

 

d) Application Security Life Cycle Reference Model

Similar to an SOP, manufacturers should define a reference model for processes related to IT security for their respective context, even though this model should still be independent of the specific application. These processes must cover all phases of the application life cycle:

  • Supply
    • Preparation, including the collection of requirements
    • Outsourcing
    • Development
    • Purchase
    • Putting into operation
  • Operation
    • Use
    • Archiving
    • Decommissioning

For both phases the processes must be described in order to manage the associated infrastructure and audit everything.

The Organization Normative Framework (ONF) including its processes must itself be subjected to a “meta-process.” Similar to the management evaluation in an ISO 13485-compliant QM system, the aim is to continually improve the system (in this case, the ONF) and adapt it to changing contexts.

e) Application Normative Framework (ANF)

With the Application Normative Framework (ANF), organizations create an application-specific instance of the Organization Normative Framework (ONF). To do this, they have to describe the specific requirements and environments/contexts and assess the risks (see Fig. 2).

The parts of the ANF comparable to the ONF are:

  • Contexts
  • Processes
  • Actors, roles, responsibilities
  • ASCs with associated Targeted Levels of Trust

During an audit (verification, validation), auditors use the ASCs named in the ANF to help them audit both the project and the device (see Fig. 2).

4. Summary & recommendations

a) Strength: a precise (data) model

The ISO 27034 family of standards follows a holistic and logical top-down approach. Starting with precise definitions, the standard takes the whole context into consideration.

On the basis of this, it establishes a process that first determines the general rules of the game at a company level, i.e. the Organization Normative Framework. This framework includes Application Security Controls (ASCs).

Thanks to a specified data structure, these ASCs can not only be reused, they can also be placed in a company and device-specific context.

As with QM systems, specific requirements are derived from the general specifications. For QM systems, this would be, for example, development plans. In this case, it is the Application Normative Framework (ANF).

b) Too abstract for a lot of organizations

But this same systematic and complex approach is also its weakness: ISO 27034 alone is of limited use to manufacturers. They have to follow the path from a meta-meta level to the concrete device. All the while not confusing the risks according to ISO 27034 with the risks according to ISO 14971.

This multi-stage process of concretization and mapping to the specific situation is likely to overwhelm most companies, particularly the smaller ones. They need concrete and specific instructions on what to do.

c) Use alternatives

Johner Institut or notified body guidelines

Manufacturers are better off using the Johner Institut's guideline, which has been adapted and adopted by the notified bodies. This is because it consolidates dozens of regulatory requirements and clearly specifies verifiable requirements for IT security of devices and the design of processes related to IT security.

This guideline doesn’t just save you time reading all these regulations, it will also help you make the jump from the abstract levels of an ISO 27034 to a concrete project.

Concrete process model

This means that manufacturers have also implemented a "Secure Development Life Cycle”, as ISO 27034 calls it in the informative annex that names it as a potential example.

d) Argue wisely with auditors

If an auditor asks, for example, with reference to the BSI guidelines, whether you are working in conformity with ISO 27034, the following arguments are useful:

  1. The BSI guideline only proposes ISO 27034 as an example. It also mentions IEC 62304, for which it is easier to demonstrate conformity, as another example.
  2. ISO 27034 does not set any concrete requirements in terms of ASCs. Instead, you could use a life cycle, as outlined in Annex A of ISO 27034, and use the ASCs in the Johner Institut's or notified body’s guidelines.
  3. The requirements regarding the ONF process would be met if the process conformed with ISO 13485. This requires, however, that the management review, for example, actually evaluates the IT security of the devices and the organization within their context.
  4. The regulatory context as well as the business context are already sufficiently well defined by the company's activities.

Auditors are, therefore, recommended to not spend their time discussing ISO 27034 and to demand compliance with the general safety and performance requirements. Unfortunately, the mapping of these requirements to concrete and verifiable requirements in the MDCG 2019-16 did not really work.

d) Stay away from ISO 27034-4

Do not buy the draft of ISO 27034-4 – it is mainly made up of empty headings:

A lot of people find charging money for this questionable.

f) Conclusion

You should know what ISO 27034 is all about. By reading this article, you have already familiarized yourself with a lot of important concepts.

If you have sufficient resources, then buy, read and follow ISO 27034.

However, before going out and running the risk of getting stuck in the academic jungle, you would be better advised to study the laws and to ensure, using the guidelinesor a concrete process model such as the one above, that you:

  • comply with the regulatory requirements and
  • ensure the IT security of your devices and
  • thus, ensure safety.

Because in the end it's all about one thing: your patients.

Author:

Prof. Dr. Christian Johner

Find out what Johner Institute can do for you
Starter-Kit_rot_dunkel

A quick overview: Our

Starter-Kit

Learn More Pfeil_weiß
blog_rot_dunkel

Always up to date: Our

Newsletter

Learn More Pfeil_grau
X

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.