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.
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.
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 (MDR, IVDR) as well as IT security requirements such as those contained in the German Verordnung für digitale Gesundheitsanwendungen (DiGAV) apply.
You can find an overview of the jungle of regulatory requirements for the IT security of medical devices and for the healthcare sector here.
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.
The family of standards is aimed at a very wide readership:
The objectives of ISO 27034 are:
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.
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 |
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).
At the ONF level, manufacturers should define:
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.
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:
“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.
ISO 27034 defines the Targeted Level of Trust as follows:
“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 |
|
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:
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.
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:
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).
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).
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.
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.
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:
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.
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.
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:
Because in the end it's all about one thing: your patients.