1. Introduction

This ‘living document’ focuses on cybersecurity in the context of safety, availability and privacy in infrastructure. Although the document is specifically aimed at tunnels, its content is widely applicable to all infrastructural works with industrial automation such as bridges and locks.

The first edition of this living document was launched on 30 May 2018, the second (current) version on 26 November 2019. In this second edition, the living document was extended to cover the entire life cycle of a tunnel/object and the tasks and responsibilities of all stakeholders involved during these project phases were described.

The guide is limited to points of attention and does not provide a complete elaboration of systems, designs and procedures because they are specific to a project, organisation and system. This document provides many considerations, but it cannot be and does not wish to be complete.

1.1 What is cybersecurity for operational technology (OT)?

Cyber crime is generally thought of as referring to attacks on the corporate IT network. For instance, a DDoS attack that shuts down a service, malware that steals business information or a database that is contaminated with erroneous data. However, the time when hackers only singled out traditional IT environments is long gone. More and more often, they are also targeting the operational environment: the OT environment of, say, energy companies and factories. And in those situations, the damage is immediately many times larger. A company’s critical OT process that is suddenly shut down can mean that a plant’s production lines come to a standstill, terminals are closed, tunnels become unsafe and bridges no longer open or close. As a result, the consequences are incalculable.

In order to provide a good frame of reference for this guide, we first define what we mean by cybersecurity in this document:

All security actions taken to prevent damage caused by the failure, malfunction or misuse of an information system or computer. Actions are also taken to limit and/or repair damage if it does occur. Examples of damage are no longer being able to access a computer system when one wants to, or that the stored information ends up with others or is no longer correct. The actions relate to processes in the organisation, technology and the behaviour of people.

(Source: cybersecurity-woordenboek)

Note:

For OT systems, an information system or computer needs to be supplemented with ICT and/or industrial automation. Because OT systems connect the digital and physical worlds, a cyber incident can, in addition to the damage mentioned in the definition, also cause damage in the physical world, for example injuries (persons), or the collision of a ship with a suddenly closing bridge.

So when we talk about cybersecurity, we are actually talking about digital resilience.

1.2 Cybersecurity working group

At the ‘Secure software’ event on 10 February 2015 organised by the COB platform Veiligheid, Jaap van Wissen from Rijkswaterstaat explained the information sharing and analysis centres (ISACs) for vital sectors in the Netherlands, see figure below.

Overview of ISACs active in the Netherlands. As standard, three different public organisations are affiliated with each ISAC: the National Cybersecurity Centre (NCSC), the General Intelligence and Security Service (AIVD) and Team High Tech Crime (THTC) of the National Police. (Source: NCSC)

As a result of this session, the initiative arose for an ISAC focused on cybersecurity in tunnels. The Tunnels ISAC was set up with the following mission and objectives:

1. The Tunnels ISAC provides a secure and trusted environment in which parties that are part of the vital infrastructure in the tunnel community can exchange sensitive and confidential information about cyber threats and best practices with the government parties responsible for security and cybersecurity.
2. The Tunnels ISAC is a forum where the sharing of knowledge, information and experiences regarding cybersecurity between members of the tunnel community plays a central role.
3. The Tunnels ISAC contributes to the strengthening of the security/chain security in the sector by forming a permanent network, which makes it easier for parties to find each other, including outside the consultation process.
4. Added value and mutual trust form the basis of the Tunnels ISAC.

In addition to the Tunnels ISAC, a Cybersecurity working group has been set up, which has produced this living document. The working group consists of approximately 40 participants, from governments and market parties such as engineering firms, system integrators, suppliers and cybersecurity companies.

1.3 Reason for producing this guide

The absence of cybersecurity can have immense consequences. For example, cyber incidents can cause enormous damage and injury, and not just financial damage. The organisational continuity of vital and non-vital processes can have major social and economic consequences, which can also affect people’s safety. In addition, damage to an organisation’s image can have a huge impact. The credibility of the organisation vis-à-vis clients and potential clients can be seriously damaged. As an organisation, you can take all kinds of measures against financial risks, such as insurance and/or reserving a risk budget, but damage to your image cannot be insured and is often permanent.

Management in both the public and private sectors is not yet fully aware of the reality of the threat of a cyber incident. Often-heard statements are:

What could they get from us?

We’re not interesting, are we?

This wouldn’t happen to us, you know!

We’ve got our affairs in order.

Our systems are not connected to the Internet.

In addition, the costs of security measures are a deterrent for many organisations.

However, it is no longer a question of whether you will be hacked,

but when and what the impact will be.

For the most recent reports, see: National Cybersecurity Centre (NCSC).

1.4 Objective

Various studies have shown that the government, the business community and private individuals are taking many steps to increase their digital resilience. However, it is not happening fast enough and everyone is still lagging far behind. This is evidenced, among other things, by the Cybersecurity Assessment Netherlands 2019 report produced by the National Cybersecurity Centre (NCSC).

By means of this guide, the COB network aims to improve awareness of cybersecurity and to allow all parties involved in the realisation and management of infrastructural projects to gain knowledge of the various aspects of cybersecurity. This knowledge enables the parties involved to assess the digital resilience of their object and to optimise processes in such a way that the correct actions can be taken in good time, to prevent or control cyber incidents. The guide also helps parties to mitigate any effects that may have arisen in the event of an incident.

1.5 Terminology

Different terms are used for the automated systems in the tunnels, such as

industrial automation and control systems (IACS), industrial control systems (ICS), industrial automation (IA) and operational technology (OT). In this living document, the term operational technology (OT) is utilised for the operational systems, networks and applications.

For the purpose of this document, the term ’tunnel’ refers to the tunnel system including the connections to the wide area network (WAN) and traffic control centre; see diagram below. The traffic control centre and the WAN are therefore not part of the tunnel system.

Diagram of tunnel system and traffic control centre

For an explanation of the other jargon used in this document and within the cybersecurity sector, you can consult the Cyberveilig Nederland glossary of terms.

1.6 Structure

For the sake of accessibility and recognisability, the living document has been divided into general, generic chapters and specific descriptions corresponding to the life cycle of a tunnel. The planning phase/tender and demolition have been dealt with in a limited way because the cybersecurity aspects in these phases are limited and relatively clear.

Schematic representation of project phases.

Each project phase is based on a risk-based approach. The benefits of such an approach are numerous. It means that the approach is highly structured and it is possible, for example, to prioritise measures so that the greatest risks can be clearly identified and all risks can be managed.

To support and illustrate the approach, a number of practical examples are described in chapter 13. Practical experience. This chapter is also structured per life phase of the object.

In the appendices, you can find a comparison between OT and IT Appendix 1: OT vs. IT, an explanation of the abbreviations used Appendix 2: Abbreviations and an overview of the standards and directives in force on 26 November 2019 as referred to in the living document Appendix 3: Standards and guidelines.

2. Alert and competent

2.1 Awareness

Awareness is the cheapest and most effective method of laying the foundation for cybersecurity within an organisation. An example of a campaign to raise awareness is the Safe Banking website. Here you can find tips and videos about recognising when something is not right with emails or phone calls that supposedly come from your bank. For instance, as soon as you are asked for personal details or to send your bank card back to the bank, the alarm bells should ring. Your bank will never ask you to do this kind of thing. In other words: ‘Hang up! Click away from the site! Call your bank!’

In addition to raising the cybersecurity awareness of all the people involved in the tunnel, specific officials must be appointed and there are also a number of specific requirements with regard to staff who are operational in the management of the tunnel (own and hired-in personnel); see the following chapters.

2.2 Education, training and exercise (ETE)

Some cyber incidents can lead to a crisis situation in which the safety of people or the environment can no longer be guaranteed. In order to have a framework for action in such a crisis, it is important to be prepared for the steps that need to be taken. The ETE programme is therefore very important in the crisis-management structure. Frequent education, training and exercise should be permanently on the agenda in an organisation.

8. Incidents and recovery includes more information and depth with regard to incidents and recovery.

2.2.1 Importance of ETE

Within infrastructure, the awareness of cybersecurity is increasing. One of the highest requirements, ‘a safe object’, is not only about the technology and providing redundant solutions, but also about policy, processes and procedures, during both the construction and operational phases. Total security does not exist and would not be economically justifiable, not even to achieve a ‘cyber-secure’ situation. So it is not possible to demand that every single thing is perfectly organised. Objectives are:

• The risks have been identified and are being managed.
• An acceptable level of risk has been determined.
• It is clear what management measures need to be taken and why.
• There is a sound OT security policy in place.

When identifying the risks, for example by means of a security assessment, it is important to examine the three aspects: ‘people’, ‘organisation’ and ’technology’. These crucial aspects should be approached together. Only then can cybersecurity be managed in a responsible manner and can responsible cost-effective measures be taken to meet the highest demands. Through ETE, the right balance can be found between people, organisation and technology.

The domain of cybersecurity within infrastructure is still in a development phase. A ‘cyber road map’ containing the improvements that are planned to be implemented in the coming years is indispensable in this respect.

It goes without saying that ETE is an essential part of the ‘cyber road map’. After all, it improves performance and can prevent crucial mistakes – especially in hectic situations. Having, maintaining and practising with frameworks and plans helps to ensure continuity and increases the self-awareness and self-confidence of staff. It also ensures that errors and omissions in the road maps can be found and corrected before a real crisis occurs.

2.2.2 Focus areas ETE programme

Staying trained

Training to raise people’s awareness to the desired level quickly, is very important, but how do we make sure that the people involved don’t fall back into old habits just as quickly? The answer is to keep repeating. Repetition makes people stay sharp and can be done in many different ways. Some examples:

• A periodic refresher course (classroom or e-learning)
• Toolbox meetings
• Newsletters/mailings
• Cybersecurity flyers
• ‘Food for thought’ items/one-liners/maxims
• Narrowcasting
• Serious games and quizzes during meetings
• Sharing experiences of incidents within the organisation

Staff involvement with and awareness of the crisis aspect

Staff in an organisation should be aware of the factors that can lead to a crisis in the work process, which then requires an appropriate crisis approach. In addition, it is important to know not only the crisis roles, but also the associated frameworks for action and working methods.

Risk assessment

Based on the exploration of the work process, a risk assessment is carried out.

In addition, a package of measures is developed on the basis of the risk assessment. This package is included in a process flow, in which the various actors are identified.

Continuity

The continuity of a certain work process is important in order to safeguard the socially vital function, but also to identify the alternatives that will allow continuation of the functionality in a manner other than the normal structure.

Awareness

Awareness is an important aspect in the functioning of those directly involved in the normal work process. Keeping your finger on the pulse by means of questions, scenarios and exercises contributes to the alertness and commitment of the staff.

Frameworks and plans:

The structure and operation of an object in an emergency situation must always be transparent by means of frameworks and plans. The various plans in laws and regulations describe the framework for action in order to safeguard continuity. Especially when a crisis occurs in which the object or process is disrupted or fails. The following plans can also be identified:

Crisis structure

The crisis structure is established by the management in a document that outlines the tasks, powers, responsibilities and core tasks of the main actors and stakeholders in the crisis organisation. It is important for the crisis structure, and its role, to be practised on a regular basis by means of a particular scenario for an appropriate incident. This is done on the basis of a script and under the supervision of a trainer.

Upscaling model

The upscaling model is a further elaboration of the stakeholders who, in the process, have to be successively informed about a crisis, and how information about managing the crisis is subsequently provided by means of frequent reports.

Incident response process

This process describes how an incident report is dealt with and how it is monitored.

Evaluation process

An important area of focus after a crisis is the evaluation. An evaluation model is used to evaluate the steps and decisions taken in order to learn from them and, if necessary, to improve the crisis process and related matters.

3. Legislation

3.1 Introduction

The vast majority of the rules and regulations relating to cybersecurity come from the European Union (EU). European legislation is therefore a dominant force in creating a framework of common standards for cybersecurity. The EU has two main legislative instruments: regulations and directives.

Regulations, such as the General Data Protection Regulation (GDPR), have direct application in all of the member states. Directives, such as the Directive on security of network and information systems (NIS Directive), must first be implemented in national legislation by the member states. The Netherlands implemented the NIS Directive in the Network and Information Systems (Security) Act.

The regimes for operational security are the principal frameworks for cybersecurity: the security of tunnels (the Tunnel Act, TSI-SRT – technical specifications for interoperability safety in railway tunnels), the security of the railways (Railways Act, Local Railways Act), public safety, safe working conditions, environmental safety, social safety, etc. Although cybersecurity is not yet specifically mentioned in these regulations, in this day and age a tunnel manager cannot ignore that aspect in managing security risks. In that respect, the regulations lag behind the reality. It is the tunnel manager’s responsibility to fill in the gaps.

There is a specific law for tunnels. The duties and responsibilities laid down in the law with regard to security are discussed in more detail later. However, the Tunnel Act applies specifically to road tunnels. The applicable laws for rail tunnels are the Railways Act and the Local Railways Act. The law defines the organisation, duties and responsibilities (of the tunnel manager, the security officer and the competent authority) differently for the railways. The report Consequences of the entry into force of the Local Railways Act from the COB/KPT contains a clear diagram of the organisational structure. Despite the differences, the contents of this living document also apply in full to railway tunnels.

The laws and regulations mentioned in this chapter are all based on the principle of managing risks. A cybersecurity system designed in accordance with the contents of this living document provides a good basis for compliance with the existing legislation.

3.2 General Data Protection Regulation (GDPR)

In addition to availability and safety, cybersecurity is also intended to protect privacy. The General Data Protection Regulation lays down rules for the processing of the personal data of natural persons.

3.2.1 Definition of personal data

Article 4 of the GDPR contains an extremely broad definition of ‘personal data’. Briefly, it provides that personal data are any data which are related to an identifiable natural person. These data can include car registration numbers, camera images, information from log files and, with the emergence of smart mobility, data that a vehicle shares with the surrounding infrastructure. In this living document, for practical purposes personal data include things such as camera images of persons and licence plates, audio recordings and log-in data of employees.

The context of the data can also be relevant. Linking anonymous data from different sources can generate personal data because the combination of data is so unique that a natural person can be identified from them.

3.2.2 Definition of processing

The GDPR also contains a broad definition of ‘processing’. The definition includes practically every action relating to personal data, in any case including collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, transmission, dissemination, otherwise making available, alignment or combination, restriction, erasure or destruction.

3.2.3 Purpose and grounds

The GDPR provides that personal data may only be processed for a legitimate purpose and with a legal ground. Processing personal data without a legitimate purpose and a legal ground is a no-go. For tunnel managers, the legitimate purpose is to guarantee safe passage of traffic through the tunnel. The legal ground lies in the road manager’s statutory duties.

‘Data minimisation’ is another important criterion in the GDPR. It means that the processing of personal data must be confined to what is essential for its purpose, but also that personal data must not be retained for any longer than necessary.

3.2.4 Security of personal data

The GDPR obliges the data processor to take appropriate technical and organisational measures to ensure an appropriate level of security of personal data. What those measures are, depends on the current state of technology: what is an appropriate measure now might no longer be appropriate in a year’s time. Furthermore, the appropriate security level also depends on the risks associated with the data processing, which have to be analysed in light of the risks for the natural person whose data is processed.

Article 32 of the GDPR further includes a number of mandatory security measures:

• the pseudonymisation and encryption of personal data;
• the ability to ensure the ongoing confidentiality, integrity and availability of personal data;
• the ability to restore the availability of and access to personal data in the event of a physical or technical incident;
• a process for regularly testing the effectiveness of the technical and organisational measures;
• a process for deleting personal data at the request of the natural person concerned.

3.2.5 Duty to notify data breaches

The GDPR contains a duty to report a data breach. A data breach occurs in the following cases:

• breach of confidentiality: access by an unauthorised person or unintentional disclosure of personal data;
• breach of integrity: when there is an unauthorised or accidental alteration of personal data;
• breach of availability: when there is an unauthorised or unintentional loss of access to, or destruction of, personal data.

Under the above definition, the accidental deletion of camera images is a data breach, for example.

The data controller must document every data breach in the data breach register. If a data breach leads to a risk to the rights and freedoms of the individuals concerned, the controller is also obliged to notify the data breach to the Dutch Data Protection Authority. It is therefore important to inform the organisation’s data protection officer immediately if a data breach is discovered (see box).

3.3 Network and Information Systems (Security) Act

The Network and Information Systems (Security) Act is the Dutch law implementing the European Network and Information Security Directive (NIS Directive) and entered into force on 9 November 2018. The objective of the law and the directive is to ensure that suppliers of essential services and digital service providers take appropriate technical and organisational measures to prevent cyber incidents. The law also requires these organisations to take appropriate measures to minimise the consequences if a cyber incident occurs.

The rationale behind this requirement is that cyber incidents affecting this type of organisation can have a disruptive effect on society. An incident can have a serious negative impact on the country’s security or the health of its inhabitants or cause severe economic damage, for example.

3.3.1 Suppliers of essential services and digital service providers

As already mentioned, the scope of the Network and Information Systems (Security) Act is confined to ‘suppliers of essential services and digital service providers’. The Minister of Justice and Security designates the essential services, a list of which can be found in the Network and Information Systems (Security) Decree. The relevant organisations are informed by the ministry that they have been designated as suppliers of essential services.

Note:

When this living document was being written, road tunnels had not been designated as an essential service and are therefore not covered by the Network and Information Systems (Security) Act. The minister regularly reviews the list of suppliers of essential services, therefore certain tunnels might in the future be designated as essential services.

Digital service providers have to determine for themselves whether they fall within the scope of the act. They do so in the following situations:

• It is an online marketplace, search engine and/or cloud service provider; with
• 50 or more employees or a balance sheet total or annual turnover of €10 million; and
• a European head office or a representative in the Netherlands.

3.3.2 Duty of care

The law does not prescribe any specific measures. The law imposes a duty of care on organisations that fall under the scope of the act, which requires those organisations to take measures to manage the risks to the security of their networks and information systems. In other words, the measures taken must be tailored to the specific risks for the organisation concerned. The law provides that at least the following aspects must be considered in determining the measures to be taken:

• The security of systems and facilities
• Incident handling
• Management of operational continuity
• Supervision, monitoring and testing
• Compliance with international standards

Organisations must also take appropriate measures to prevent cyber incidents that impair security and contain the consequences of any such cyber incidents as far as possible.

3.3.3 Obligation to notify

The law also contains an obligation for organisations to notify a cyber incident under certain circumstances. An organisation covered by the law must notify any incident that has had, or could have, a significant impact on the continuity of the service it provides.

Factors that determine whether an incident could have a significant impact are:

• the number of users affected by the disruption of the service;
• the duration of the incident;
• the size of the geographic area affected by the incident.

3.4 Other legislation

In addition to the GDPR and the Network and Information Systems (Security) Act, there is other legislation that affects cybersecurity in relation to tunnels. For the national government, the following regulations apply:

• Government Information Security Regulation (Voorschrift Informatiebeveiliging Rijksdienst, VIR).
• Government Information Security Regulation for Special Information (Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere Informatie, VIR-BI).
  The emphasis in the VIR-BI is on the duty of care of each ministry and its line management to safeguard the security of special data. The VIR-BI can be seen as a supplement to the VIR. Although written for central government bodies, the VIR-BI contains excellent advice that could also be helpful for municipalities and provinces in protecting special data. With the growing entanglement of processes and information, there should in time be a similar regulation, for example with rules on the classification of information, and measures for municipalities.
• Cybersecurity Implementation Guideline for Rijkswaterstaat Objects (Cybersecurity Implementatierichtlijn Objecten Rijkswaterstaat, CSIR). The CSIR is a supplement to the BIR drafted by Rijkswaterstaat with specific rules for the objects managed by Rijkswaterstaat.

Note:

The Government Information Security Baseline (BIO) will take effect on 1 January 2020. The BIO is a framework that replaces the Information Security Baseline (BIR), Inter-provincial Information Security Baseline (IBI), the Municipalities Information Security Baseline (BIG) and the Water Boards Information Security Baseline (BIWA).

At the time of the publication of the living document (26 November 2019), Rijkswaterstaat was preparing an update of the CSIR to bring it into line with the BIO and to incorporate further measures from IEC 62443.

3.5 Tunnel Act

The Road Tunnels (Additional Safety Rules) Act (Warvw) and the Road Tunnels (Additional Safety Rules) Regulation (Rarvw) refer to various security-related roles. For more information, see the brochure Tunnel security explained published by the Kennisplatform Tunnelveiligheid (KPT). The following is a list of important roles:

As already mentioned, the Tunnel Act applies only to road tunnels. Other legislation applies for rail tunnels (see above).

4. Cybersecurity organisation

By embedding cybersecurity tasks, responsibilities and powers in the organisation, cybersecurity will become part of the organisation’s standard processes. The aim is to ensure that:

1. Cybersecurity risks are identified.
2. Measures are formulated and entrusted to people with professional knowledge, so that the measures are correctly implemented.
3. The maintenance and evaluation of measures is verified against legislation and changing threats.

4.1 Cybersecurity management system (CSMS)

To safeguard cybersecurity within the OT organisation, a cybersecurity management system (CSMS) can be utilised. A CSMS consists of a set of plans, reports, measures, instructions, policies, procedures and evaluation processes that help the organisation to pay attention to cybersecurity without losing the overview. A CSMS helps to manage cybersecurity for the OT environment in a structured way that is able to be validated. Part of the CSMS involves periodic verification of the compliance with and effectiveness of the CSMS.

Infrastructure and tunnels are characterised by the fact that there are one or more suppliers, a users’ organisation and a control or management organisation, depending on the type of contract (see below). The CSMS can then be distributed over these parties, but must always function as a whole.

Note:

For organisations with a company-wide Information Security Management System (ISMS), it is smarter to follow that. Organisations whose automation consists mainly of OT systems should consider a CSMS in conformity with IEC 62443.

4.2 Contract

The type of contract influences the organisation of cybersecurity. The most commonly used types of contract in infrastructure are:

1. Design, build, finance, maintain (DBFM)
2. Design, build, finance, maintain, operate (DBFMO)
3. Design and construct (D&C)
4. Engineering and construct (E&C)
5. Performance contract (PC)

These types of contract differ in the extent to which the phases design, realisation and maintenance are included in the contract. In the case of cybersecurity, this has consequences for the influence that the contractor has on the implementation of the cybersecurity measures. In the case of D&C and even more strongly E&C, the organisational measures and part of the technical measures will already be determined by the client. In this case, the primary coordination of the cybersecurity activities lies with the client. The execution of the specifically mentioned activities is entrusted to the contractor. In the case of DBFM and DBFMO, the entire organisation is arranged by the contractor. The client has a verifying role.

Performance contracts are aimed at managing an object or area of land and do not include any design or realisation work. In this contract, it is up to the contractor to preserve at least the existing security measures.

4.3 Organisational form during the life cycle

In the various phases of the life cycle of an object, different forms of organisation apply. For example, for product development we have product groups, for construction projects we have a design and realisation process that conforms to the V-model from systems engineering (see ISO 15288), and for management and maintenance, the PDCA cycle (including the demolition phase) is used. The figure below illustrates these different forms. The structure of the organisation has direct consequences for the tasks of cybersecurity officers.

Forms of organisation during the object’s life cycle

Cybersecurity is an integral part of all these activities and work. It is important to recognise the transition between the phases as a risk and to respond in time. For example, have the manager join in early in the development and design phase. In order to present the relationship with cybersecurity in a clearer way, a relationship diagram has been drawn up, see box.

Cybersecurity relationship diagram (currently only available in Dutch).

The table below provides an explanation of the tasks and responsibilities associated with the relationship diagram.

The way in which the organisation is organised depends on the size and complexity of the scope (new-build, renovation, maintenance and demolition). A number of organisation models are described in IPM (RWS) and ISO 55000 (asset management).

4.4 Base organisational model for cybersecurity

The model below shows which cybersecurity roles can be distinguished in which phase of the life cycle. Depending on the scope of the work, several roles may be assigned to the cybersecurity coordinator in a certain phase.

4.5 Tips for a smooth collaboration

4.6 Case study: Responsibility Assignment Matrix (RAM) for a road tunnel

The RAM shown below (tasks, powers and responsibilities) gives an example of a possible division of roles between a client and contractors in a tunnel project. An attempt has been made to provide a practical structure based on the joint responsibility of the contractor and the client, keeping an eye on the result, whereby the knowledge and skills of both parties are put to optimum use.

Three preliminary remarks:

1. For each contract/organisation/object, the interpretation will be different. The main purpose of the matrix is to facilitate discussion of the situation with all the parties involved.
2. The matrix tries to strike a balance between conscious responsibility (for example, the tunnel manager being responsible for a great deal), and responsibility for the actual execution of tasks.
3. Cyber incidents soon transcend the context of the contract. There will have to be known agreements at management level about how to deal with the impact on objects outside the scope, and with the consequences of external incidents.

Example of RAM based on the DBFM contract form. The matrix is also available to download in a larger size.

The client provides the right frameworks in the tender. The role of the client subsequently becomes that of an ‘involved assessor’ and ‘advisor with accompanying responsibilities’. In the design phase, the contractor draws up the plans and instructions in collaboration with all the specialists. An important role is played by process management and the ICT design of the contractor’s working environment. During realisation, the technical measures are implemented and validated. The process of drawing up status reports, evaluating annually, auditing and updating the risk analyses is carried out in the operational phase.

5. Risk-based approach

This chapter describes a strategy by which stakeholders can assess the digital resilience of an object/project and design processes in such a way as to ensure that timely and effective measures can be taken to prevent or manage cyber incidents, or to mitigate the impact of incidents if necessary. See also chapter 8. Incidents and recovery.

5.1 Introduction

Broadly speaking, cybersecurity can be approached in three ways:

This living document describes a risk-based approach because it is the most comprehensive. In practice, a composite approach will always be used. There will often be an applicable baseline or regulation, for example the BIO, which prescribes basic mandatory measures for the particular organisation or sector. Additional specific measures are then determined on the basis of actual risks or a risk classification. Every tunnel manager can therefore compile an individual version.

Risk management for existing systems

There are six steps in the risk-based approach for existing systems that need to be supplemented with additional cybersecurity measures:

1. Inventory
   
   1. of the current system design and existing vulnerabilities,
   2. of the current operation (processes and actors), and
   3. of the operational objectives for security, availability and privacy, and the accepted residual risks (acceptable incidents per year).

The inventory focuses on three themes: people, organisation and technology.

1. Drafting of a risk assessment (threats/events, opportunities, current vulnerabilities and operational impact).
2. Selection of the technological and organisational measures to be taken.
3. Evaluation and acceptance of residual risks.
4. Implementation of the measures.
5. Monitoring of the measures (including verification and validation).

Steps in the risk-based approach.

Risk-based approach with new-build and renovation

Only the initial steps are different with a new system/operation or a renovation. In this case, the emphasis is on designing cybersecurity measures and ensuring the cybersecurity of systems/components to be procured rather than identifying the vulnerabilities of an existing system and organisation.

The approach then consists of the following steps:

1. Inventory
   
   1. of the planned operation (processes and actors), and
   2. of the operational objectives for security, availability and privacy and the accepted residual risks (or acceptable number of operational incidents per year) as a result of cyber incidents.

This can be derived from the description of the project’s operational process.

1. Drafting of the risk assessment (threats/events, opportunities and operational impact).
2. Design of the technical and organisational measures.
3. Evaluation and acceptance of the residual risks.
4. Implementation of the measures.
5. Monitoring of cybersecurity (including verification and validation).

5.2 Cybersecurity risk management

Cybersecurity risk management relates to the risks of security incidents over the entire life cycle of an OT system and starts with the cybersecurity risk assessment once the cybersecurity objectives have been derived from the project’s operational objectives. The analysis is part of the design process that has to be carried out for each phase of the life cycle of an OT system – from new build, maintenance and renovation to demolition (what should be done with old data, connections, organisation, people, etc.). The purpose of the analysis is to identify measures that correspond with a realistic assessment of the threat and/or the vulnerability of the (existing) system and organisation. These cybersecurity measures should be practical and affordable (efficient and effective) and help to achieve the objectives of the system and facilitate the planned operation.

The design choices are the result of a balancing of different, often conflicting, aspects, such as the technical possibilities and limitations, operational usefulness, organisational and financial constraints and human aspects. Both preventive and corrective measures have to be formulated with a view to reducing the chance of the occurrence of a cyber incident and – if an incident does occur – mitigating the impact on the system and the operation. The cybersecurity risk assessment highlights the residual risks and the recovery measures that will be required for the system and the operation.

Cybersecurity risk management should be embedded in the asset management of a specific system (object or asset). ISO 55000 is a useful guideline for asset management and covers an asset’s entire life cycle. The Cybersecurity Management System (CSMS) should be an integral part of the asset-management process.

Note:

For organisations with a company-wide Information Security Management System (ISMS), it is smarter to follow that. Organisations whose automation consists mainly of OT systems should consider a CSMS in conformity with IEC 62443.

5.3 Inventory of operational objectives

For both new and existing systems, the envisaged operation (exploitation, management and maintenance) and the operational objectives must be established. The envisaged operation can be documented in process descriptions or ‘ConOps’. The acceptable number and types of operational incidents each year – to be agreed with the users and maintenance and management organisations – constitute the acceptable residual risk of cyber incidents.

Operational goals as the basis of the cybersecurity design.

The causality between cyber incidents and physical damage and personal injury.

5.3.1 Threat assessment and logs

Every year the NCSC publishes an update of the Cybersecurity Assessment Netherlands. For every operation and for every system, a specific security assessment should be drafted for the design process and to formulate (and evaluate) the specific cybersecurity measures.

A ‘cybersecurity incident log’ is a tool for documenting the security assessment for a specific operational environment or system. Cybersecurity assessments are generally drawn up by cybersecurity experts. However, it is sensible to have the realism of these assessments peer-reviewed and to have the client and the users evaluate their impact on the operation, especially with respect to the acceptance of residual risks, since they have an impact on the operation.

5.3.2 Existing operational measures

In the case of existing systems, an inventory is made of the current system design, measures and vulnerabilities (‘as is’). The risk assessment is followed by new measures, which in fact constitute a new system design (‘to be’). For new systems, the cybersecurity measures are designed on the basis of the envisaged operation and operational objectives and the threats.

There is a lot of information about cybersecurity measures to be found in best practices, national and international standards, general guidelines, checklists and manufacturer’s instructions. In general, for a specific OT system in a specific environment and for a specific operational purpose, specific cybersecurity measures are selected during the design process, as a subset of general measures. See the section 10.1 Design for the types of measures and the choices that can be made.

Sources of information about cybersecurity risk assessment and management

1. Guide to risk assessment from the National Advisory Centre for the Critical Infrastructure (Navi)
2. ISO27005, Information security risk management
3. ISO27001, Information security management
4. ISO31000, Risk management
5. IEC 62443, Technical security requirements
6. ISO27035, Incident response
7. Guide to performance-based risk assessment (PRA), RWS.

5.4 Drafting a risk assessment and quantifying the risks

The inventory is followed by a risk assessment, which determines the chance of each risk occurring and calculates the damage if things actually go wrong. In the risk assessment, the inventoried risks are quantified by multiplying the likelyhood of a risk occurring by its consequences: risk = chance x impact. Measures that could be taken to address the risks are then also considered.

Residual risks

The purpose of a risk assessment is to establish how the risks can be managed or reduced to an acceptable level. Besides a risk assessment, a cost-benefit analysis and an analysis of the operational objectives are carried out, since it isn’t automatically necessary to hedge every risk: if the cost of measures to reduce a risk is higher than the potential damage or personal injury in light of the prescribed operational objectives (security, availability and privacy), the risk might be accepted as a residual risk.

It is important that the hedging or acceptance of risk corresponds with the organisation’s risk appetite and that the organisation is capable of absorbing the effects of operational incidents. A system of risk management (or risk control), with permanent or periodic risk analyses, is an essential element of a good cybersecurity policy.

There are two types of risk assessment:

• Qualitative: qualitative estimates of the risks are made.
• Quantitative: where possible, the risks are quantified in measurable criteria, usually expressed in terms of the financial consequences or the number of acceptable incidents (residual risk) or cases of personal injury.

There are a number of methods of risk assessment. Methods often used for applications of industrial automation are a fault tree analysis or a failure mode, effects (and criticality) analysis, or FME(C)A. A new standard is being drafted for OT systems: the ISO/IEC 62443-3-2. This standard describes the ‘security risk assessment and system design’ and will probably be published in 2019. The ISO/IEC 27000 series contains various standards for information security. The ISO/IEC 27005 standard covers information security risk management. The ISO/IEC 27000 series of standards is geared mainly towards information technology (IT) environments, such as office automation (SAP, Microsoft Office, etc.), and is in some respects unsuitable for OT systems such as the operation, management and monitoring of tunnels (see also Appendix 1: OT vs. IT).

Note:

Whereas IT and OT have traditionally been separate domains, nowadays a growing number of manufacturing processes depend on IT solutions. As a result, the OT environment is more frequently affected by malware from the IT environment. In practice, more than half of the malware problems in an OT environment arise from the organisation’s own IT systems. Moreover, the development of the Internet of Things (IoT) has now reached the OT world. Naturally, this creates many new possibilities, but unfortunately also new security threats; an increase in the number of factory sensors represents a larger ‘attack surface’. Specific knowledge and expertise, as well as a clear understanding of the impact of a cyber attack and how to defend against it, are needed to reconcile cybersecurity in the two domains.

Availability and integrity are top priorities on the OT agenda. Cyber defences have to protect them, but at the same time must not disrupt the business processes. At the same time, threats to the IT environment must be prevented, while the priority might be to preserve confidentiality, for example. An obvious solution for properly securing both worlds is an integrated ‘IT/OT approach’.

5.5 Measures

5.5.1 Types of measure

Broadly speaking, a risk inventory and analysis focuses on three themes: people, organisation and technology. The figure below shows the three themes and their mutual relationships. It follows that a proper cybersecurity management plan has to embrace all three themes. To arrive at a particular risk level (classification), a weighted set of measures will have to be adopted in each of these areas.

The balance of cybersecurity measures.

1. The human factor: awareness, tasks, powers and responsibilities of employees, managers, maintenance staff, etc.
2. The organisation: vision, strategy and policy relating to risk management, governance, standardisation, legal aspects, contract management, GDPR, etc.
3. Technology: physical access security, IT, OT, hardware, software, the built-up environment.

The measures to be taken can be determined on the basis of a risk assessment. ISO/IEC 62443 is an important guideline for such an analysis. The following list provides some examples of responses to the outcome of a risk assessment:

• Prevention: measures to prevent something from happening or reduce the chance of it happening.
• Detection: measures to detect a (potential) threat and/or damage when it occurs.
• Repression: measures to limit the damage when a threat occurs.
• Correction: adopting measures that are activated as soon as something happens in order to reverse (some or all of) the effects.
• Acceptance of the risk: no (extra) measures are taken; the chance of a threat occurring and its possible consequences are accepted.
• Transfer of the risk: the financial risk is transferred through insurance, or the operational risk though outsourcing.[1]

In the diagram below, a distinction is made between proactive and recovery measures. Both categories apply to technology, organisation and human behaviour. Proactive measures are primarily intended to significantly reduce the chance of a cyber incident occurring. However, the scale of an incident’s impact cannot always be determined. The purpose of proactive measures (‘staying healthy’) is to protect the asset against malware and manipulation or changes to software and/or hardware in the event of a failure of the physical access security. The measures on the right-hand side of the diagram (‘healing quickly’) are intended to reduce the impact of an incident and to fully restore the asset’s functionality as quickly as possible (validation and verification). The basic requirement is that the event is detected; without detection, no remedial measures can be taken.

Note:

If third parties gain access to an asset without being noticed (i.e., all the proactive barriers have failed, including detection methods and audits), the impact will not necessarily be immediately visible.

Diagram of proactive and recovery measures.

The purpose of the measures under ‘healing quickly’ is to greatly shorten the time taken for diagnosis and repair of the problem and start-up. This set of measures helps to limit the damage to the organisation’s reputation and reduce the time needed to restore the asset’s function(s).

The Swiss-cheese model (Source: James Reason)

5.5.2 Selection of measures

The selection of measures to be taken can depend heavily on the condition of the object and the technical status of its installations. There will be a wider choice of measures with a new building than with an older existing object, in which the age of the existing installations and the technology used in them can vary greatly.

In new-build projects, ‘security by design’ and cybersecurity are integrated in the design of the installation(s) and the overall design. With a renovation, the process involves ‘security by customization’: bespoke solutions for the individual installations and a protective layer of security over the installations as a whole.

Depending on the risk, a decision has to be made, with transparent reasons, on the combination of precautionary measures to be taken against cyber incidents and the minimum recovery measures that will be needed. Measures must have a specific purpose, which has to be respected by the ‘people’, the ‘organisation’ and the ‘technology’ as long as the measure is in effect. Failure to implement the measures properly (for example, making a work around because it is too much trouble to perform maintenance) will increase the risk again.

The risk inventory and analysis yields a list of the impact that particular measures will have on the risk of events occurring. Measures can have very different outcomes. For example, some measures will have little effect and others will have a huge impact. A particular measure could also have a negative effect on another measure or have a negative impact on the functionality of the object. It is crucial to select the correct measures during this phase, and that calls for careful consideration. The selection should therefore preferably be made by a team composed of appropriate experts.

Once the measures have been selected, it is time to review again the risks that will remain in each domain once the measures have been implemented. The differential risk is then the difference between the effect if a measure is not adopted and the impact if that measure were to be implemented. The residual risk is the effect (including the chance of it occurring) that remains when all the measures to manage the risk have been taken. These residual risks can be underpinned with scenarios of the consequences in terms of time, finances and/or staff if the risk occurs. This residual risk must be accepted at management level.

The measures should be geared as closely as possible to each other and reinforce one another. Naturally, the greater the number of proactive measures, the smaller the chance of an incident occurring. However, there are also drawbacks to persevering with these measures, including management costs and potential problems in maintaining and making changes to the installations/the system.

5.5.3 The human factor

The theme ‘People’ is mainly concerned with awareness-raising and training for managers, operators, maintenance staff and others who have to carry out work on the objects. It applies to both internal and external staff. Employees are often unaware of the risks of their actions. For example, too many still share their log-in details (username and password) with colleagues, or write them down on a piece of paper which is left lying near the relevant installation. Or maintenance staff connect their laptop to an installation on which they have to carry out maintenance before scanning it for malware. These are just three examples of human behaviour that is undesirable in this digital age. More than 70% of reported security incidents are due, at least in part, to people’s lack of awareness or failure to act correctly. Other examples are inserting a USB stick that you have found into your laptop; losing information, both on paper and on digital media; and sharing information, consciously or unconsciously, with unauthorised persons. However, individuals who have been dismissed or who are in financial difficulties also represent a serious risk.

People are therefore also an important factor in relation to cybersecurity. Systems can be compromised by unsafe behaviour. It is therefore important for people to be trained (in terms of both knowledge and awareness) in safe working practices. Technical and procedural measures should also take serious account of human behaviour. People who feel a technological and/or procedural solution hampers them in their work will come up with a workaround, but the workaround seldom makes the situation safer. The key lies in finding the right balance between functionality, security and convenience.

The risks associated with the theme of ‘people’ can also embrace a dissatisfied employee, an incompetent employee or a vengeful former employee. These risks are covered in the risk inventory, while the risk assessment assesses the chance of the risk occurring and its possible impact. It is important to be aware of the potential risks and the measures that can be taken, such as blocking accounts, regularly changing passwords and providing training for employees.

Organising courses and conducting frequent exercises are ways of maintaining ‘cyber awareness’ among employees. To avoid hiring unauthorised/undesirable staff members, you could draft a non-disclosure statement and require everyone to sign it, or insist on submission of a certificate of conduct (VOG). The costs of these measures will be outweighed by the improvement in quality, smaller staff turnover, etc.

5.5.4 The organisation

The shape of the organisation can vary greatly according to the nature and size of the project/contract. See also chapter 4. Cybersecurity organisation.

ISO/IEC-62443-2-2 and ISO/IEC 27002 contain guidelines on the roles and the requirements that need to be defined for information security and cybersecurity. The figure illustrates a variety of the roles connected with cybersecurity.

Example of cybersecurity roles

Each role can be delegated to a specialist but, particularly with smaller projects/contracts, that will obviously be neither feasible nor desirable.

By embedding tasks, powers and responsibilities relating to cybersecurity in the organisation, identified risks can be referred to the appropriate person/problem owner. Those persons can also help to accurately estimate the threat and its potential impact during the risk assessment. If they do not possess the necessary expertise to properly assess the situation, they should consult persons who do or follow a training programme to gain the skills needed to make their own assessment.

Two very common support roles are:

• Mandated official for connecting equipment
  Explicit permission has to be granted for every non-standard connection of equipment. The mandated official determines and applies the frameworks for granting permission to connect equipment, the registration of the equipment to be connected and for investigating the risks.
• Personnel with authorised access to log data
  Persons authorised to have access to log data must meet strict requirements with respect to the confidential treatment of information. The data can include personal data and therefore fall under the GDPR. Log data can also often contain information that could reveal vulnerabilities in a system to a hacker, such as details of the particular version, IP addresses, the protocols used, etc. Specific requirements are therefore prescribed for accessing and processing log data.

Other roles will be created and persons appointed to perform them according to the nature of the project or the organisation.

5.5.5 Technology

The technology is an important link in the cybersecurity chain and must be used optimally. However, technology is not infallible and should be regularly evaluated and, where necessary, modified. The technology used should be appropriate for the organisation and match the knowledge and experience of the responsible people in the organisation. The ‘golden triangle’ must be in balance.

To limit cyber risks, tunnel equipment (but also the devices used by maintenance staff, such as laptops and data carriers) must be kept up-to-date and virus-free. This is particularly important because the sub-systems are built by different suppliers. The access points must be designed in such a way that they can be used safely. It must also be evident to which installations there is remote access. A sub-installation might have wireless and internet access for maintenance work and it might be possible to reach the entire network via this access point. Practice has shown that these risks are not always obvious or sometimes go unnoticed, but these vulnerabilities can be identified with proper monitoring.

Note:

The technology must be safe and robust, but must not make performance of maintenance and recovery work impossible, since otherwise maintenance workers will employ a workaround or fail to carry out repairs.

5.6 Management

Managing, auditing and reporting is a three-step process of assessing, design and operating effectiveness. For example, there should be a documented procedure for patching the tunnel operating system. In this case, design and operating effectiveness means that the measure must be adopted, the procedure must be documented and the relevant party must follow the procedure as described.

If a recent risk assessment has identified vulnerabilities in a tunnel system and the necessary measures have been taken, the level of cybersecurity achieved has to be maintained. In that context, maintenance means monitoring every aspect of cybersecurity: security of physical access to IA-related areas, logical access, network links, hardening and patching procedures, procedures for security incidents, the incident response plan, logging and monitoring, agreements and procedures with contractors, awareness raising and training for tunnel managers and other relevant personnel, controlled revision of procedures, procedures for back-ups and mitigating measures for other vulnerabilities that emerge from the risk assessment. Special attention should be devoted to the recommendations on security from suppliers and from the Ministry of Justice and Security’s National Cybersecurity Centre.

With all the methods and aspects of cybersecurity monitoring, it is important to make agreements on the frequency with which inspections, controls and audits will be carried out. Where possible, they should coincide with the inspections, controls and audits unrelated to cybersecurity that have to carried out by virtue of agreements and/or legislation.

Monitoring can be roughly divided into two aspects:

1. Organisation, personnel and procedures;
2. Technology.

5.6.1 Organisation, personnel and procedures

Non-technological aspects can be monitored in various ways, with various combinations of methods. The monitoring can be light or very intensive, for example. In ascending order from light to intensive, methods include:

1. Internal monitoring by an organisation’s own employees on the instructions of the tunnel manager.
2. Internal monitoring and/or inspections by the information security officer.
3. Peer review by a tunnel manager who falls under another competent authority.
4. Audit by the competent authority’s internal audit service.
5. Audit by an external auditor.

Prior to a control/inspection/audit, agreements must be made with the tunnel manager on its criteria and its scope.

A report must always be made of the control/inspection/audit, containing at least the following information:

1. ‘Administrative details’ of the control/inspection/audit, including the name of the client, the name of the contractor, the date, the criteria, the scope, etc.
2. Results of the control/inspection/audit.
3. Proposed modifications or improvements with respect to the aspects that were investigated.
4. Results of previous controls/inspections/audits and the progress made on the action points.
5. A rough estimate of the resources needed to make the changes and improvements.

Outsourced work

Since a lot of work is outsourced, this aspect must receive special attention. When work is outsourced, it is very important that the external party follows all of the procedures and measures that apply for the internal organisation. If they have to be departed from, ensure that the derogation is authorised and documented so that it can always be traced and accounted for.

It is the contractor’s responsibility to demonstrate that the delegated activities and responsibilities comply with the original requirements. By law, the tunnel manager remains ultimately responsible for the security of the object and must ensure that the delegated activities are carried out properly.

5.6.2 Technological aspects

The aspects discussed above also apply for the criteria, scope and reporting with respect to technological aspects, which are:

1. Patching, logging, hardening, monitoring, back-ups, access security, network links, etc.
2. Technical inspection mechanisms, including detection software, firewalls, antivirus software and penetration tests.
3. Outsourcing (conditions, responsibilities, etc.).

Controls/inspections/audits of these aspects of cybersecurity could be carried out under a contract with an external cybersecurity company, for example. As a member of ISAC Tunnels, Rijkswaterstaat’s Security Operations Centre (SOC) can be asked for information, advice or support.

The report must devote sufficient attention to non-conformities in the procedures and in the technology as prescribed and implemented in the cybersecurity policy. In particular, the arguments for and the risks of derogations must be properly documented and authorised.

In addition to the formal reporting, any vulnerabilities that are discovered should be discussed in ISAC Tunnels so that all the tunnel managers in the Netherlands are aware of them.

6. Verification and validation

Security measures in general must not only be in place, but must also be demonstrably effective. The same applies for cybersecurity measures: verification and validation are also required for this form of security. Verification objectively and explicitly demonstrates that a solution meets the prescribed requirements. Validation shows that a solution is fit for purpose. Naturally, the verification and validation procedure for cybersecurity also has to encompass unusual situations. In other words, it is not only the ‘sunny day’ scenario that has to be tested, but also scenarios for ‘rainy days’.

The definitions of verification and validation are often slightly different in different knowledge domains. There are therefore a wide variety of definitions in use internationally. The following definitions are taken from the Guideline for Systems Engineering in the Civil Engineering Sector:

Verification:
Confirmation that the specified requirements have been met by providing objective evidence.

Validation:
Confirmation that the product meets the requirements and needs of the customer, by providing objective evidence coupled with actual perception and use, in addition to verification.

Considerations in a verification and validation process are:

A: The method used to provide evidence.

B: The criterion.

C: The assessor.

D: Additional activities, criteria and assessors that are needed to provide sufficiently objective evidence. These include verification during successive phases of a project or even at multiple locations during a specific phase.

E: The timing of the verification/validation.

F: The starting conditions necessary to commence the verification/validation procedure. For example, if someone else has to complete their task in the project before the validation of one’s own task can start.

G: The validity of the verification or validation method used. For example, if the contractor proposes a method of providing evidence that is new or unknown to the principal.

H: The risk of non-compliance with the criterion. For example, if it cannot be shown in advance that a theoretical system performance is feasible in practice, specific management measures might have to be defined for some criteria.

Steps in the verification process

Times of validation

• Validation of requirements, validation sessions
• Design validation, design reviews
• Product validation, testing of the work
• Functional simulation of the system, or 3D simulation

Validation at the right times avoids failure costs.

For cybersecurity, the verification and validation procedure must also explicitly cover non-standard situations. In other words, not only the ‘sunny day’ scenario, but also ‘rainy days’ scenarios must be tested. For example, if a minimum length is prescribed for passwords, the following aspects should be separately validated:

• a password with the required length can be chosen
• a password with a (random) longer length can be chosen
• a password with a shorter length leads to an error message from the system and cannot be chosen

Sources:

• Guidelines for systems engineering.
• Guidelines on implementation of cybersecurity for objects, Rijkswaterstaat
• Procedure description 00044 – Verification and Validation, Rijkswaterstaat

7. Monitoring

7.1 Introduction

No matter what measures are taken, cyber incidents cannot be prevented entirely. Furthermore, a certain degree of residual risk is usually accepted. With a system of cybersecurity monitoring, the status of the digital security of the technical systems is constantly monitored so that new vulnerabilities can be identified and cyber incidents can be detected and dealt with.

Once the ‘normal’ behaviour has been established, the purpose of monitoring is to detect threats of an incident by recognising abnormal behaviour, to document any cybersecurity-related events and to collect evidence. The Government Information Security Baseline (BIO) obliges organisations to take measures to achieve those objectives. The responsibility for compliance with the BIO, including security monitoring, lies with the managing party.

According to the Cybersecurity Assessment Netherlands 2019, on average it takes 78 days to detect an intrusion into a system. It is therefore essential to take adequate measures to detect breaches and to properly monitor and test the system and the processes. Factors to consider are:

• how good is your Security Operations Centre (SOC);
• how quickly you install patches;
• how quickly you respond to an incident;
• how quickly you can process information about a threat; and
• how you deal with a crisis.

A coordinated and documented escalation model will probably promote the earlier notification and escalation of abnormal behaviour and help to ensure that an incident can be resolved more quickly and effectively.

The National Cybersecurity Centre has published Guidelines for the implementation of detection solutions to assist with the design of monitoring systems.

7.2 Implementation of logging and monitoring

The following sections outline some of the issues that need to be addressed when implementing a logging and monitoring system. In this context, the log data are created on a local device (computer, switch, etc.). They should then be collected in a central log server. The local and central databases containing log data should be protected against unauthorised alteration or deletion.

8. Incidents and recovery

“There are just two types of companies, those that have been hacked and those that will be”, as Robert Mueller said in his speech, Combating threats in the cyber world. Although many people would agree with this sentiment, there is still little awareness that this also applies to OT environments. Each and every IA environment connected to an external network is already subject to constant attack. In addition to the incidents via scanning of the internet that have become almost commonplace, there are also other opportunities for breaches of an IA environment. This chapter describes the detection, logging, assessment and processing of cyber incidents in OT systems.

8.1 What is a cyber incident?

8.1.1 Definition

‘A security incident is an event or action that could potentially jeopardise or breach the security of hardware, software, information, a process or an organisation,’ according to the cybersecurity-woordenboek. In other words, a security incident may also be the result of an oversight, an unintentional/well-intentioned change with an accidental, negative effect.

In general, classes of activity that are recognised as security breaches are:

1. Attempts to gain unauthorised access to a system and/or data.
2. Unauthorised use of systems to process or store data.
3. Changes to system firmware, software or hardware without the permission of the system administrators.
4. A malicious disruption and/or denial of service.

8.1.2 Life cycle

The National Institute of Standards and Technology (NIST) has an introduction and explanation of the life cycle of an incident as shown in the illustration below. The phases are explained in greater detail in the other sections of this chapter.

Life cycle of an incident (source: Computer Security Incident Handling Guide, NIST).

8.1.3 Causes and recognition

The Cybersecurity Beeld Nederland 2019 (CSBN2019) document shows that there has been a change in the nature of cyber attacks. The number of ‘chance’ breaches by non-specialist individuals (script kiddies) is falling. However, the number of consciously-planned attacks by nation states is on the increase. Attacks of this kind are characterised by a long lead time, use of advanced resources and specialised workers. In order to prevent such incidents, or to resolve them effectively, it is necessary to deploy larger forces in terms of resources and employees, and to have an integrated policy based on a coherent strategy. A cyber attacker needs only a small point of entry to gain access. Security enforcers have to be alert to potential vulnerabilities in order to close off any such points of entry.

A security incident is not always visible, and cannot always be easily identified as such. This is why awareness and training to recognise and report incidents is the first, preparatory step.

Potential triggers indicating security incidents (source: Cybersecurityrichtlijn RWS) include:

• Loss of service, hardware or facilities.
• System errors or overload (including disruption of the backup process).
• Human error leading to disruption of service or system unavailability.
• Breach of physical and logical security features of the object in question.
• Breach of operations and system administration.
• Unauthorised system alterations.
• Non-compliance with policy or code of conduct.
• Virus alerts.
• Loss or theft of company resources.
• Abuse of authority.
• Vandalism, gratuitous damage.
• Attacks via networks accessible to the public, such as the internet.
• Suspicious system behaviour.
• Unauthorised connection of mobile equipment.
• Unauthorised connection of removable media.
• Unauthorised connection to networks.
• Irregularities in logical access.
• Suspicious or weak spots in systems or networks.
• Malware alert.
• New vulnerabilities.

8.1.4 Notification and logging

In order to be able to deal with an incident correctly it is crucial that incidents are reported immediately to the relevant incident manager. Even if there is a possibility that the situation in question might not qualify as an incident, a notification must still be generated. Notifications of this kind must be made sincerely. The person reporting the incident must not be put under pressure to ‘cover up’ potential incidents by not reporting them, or to downplay them for personal, economic or other reasons. When logging incidents it is important to establish the following aspects:

• Location
• Date and time
• System concerned
• Company situation
• Action taken
• Person making the report and witnesses
• Are there any others present?

The information in this notification forms the initial input from which the recovery plan can be drafted. Once this information has been established, it is important to be aware that the input has, potentially, not just technical value but also legal value.

8.2 Phase 1: Preparation

Proper preparation means that an organisation is ready for action and can respond promptly where an incident arises. An appropriate ‘ready to detect and respond’ attitude forms part of the ‘security incident response process’ for the object/organisation/administrator in question.

• Being aware and following training is a first step. This step, together with screening of personnel and formalising tasks, powers and responsibilities, forms the preparation for the human side of the incident response process.
• The organisation must build in safeguards to prevent incidents caused by people. Each activity controlled by an individual carries with it the risk of causing a security incident, either consciously or subconsciously. In addition to integrity audits, other important instruments are the ‘two-man rule’, card system and formalised decision making.
• Information relating to confidential information (and who has access to it) must be securely protected. Password management is an important aspect. Mechanisms like multi-factor authentication must be considered. Create temporary passwords for a design and test phase. Passwords known to more than one person are not allowed.
• From a technical point of view, ‘automatic’ detection and incident logging are built in. Forwarding of notifications and follow-up of detection is part of the response process. A new vulnerability in technical systems may be maliciously exploited, but is not, in and of itself, a security incident. This living document also sees patching as one of the technical measures. To prevent incidents, proper implementation of patching or patch analyses in good time is an important issue. Leaving a newly-completed system ‘unpatched’, something that was hardly out of the ordinary until very recently, is now inconceivable.

Incidents must be reported to the incident manager. The duties and responsibilities of the incident manager must be outlined in advance, see chapter 4. Cybersecurity organisation and the measures in the various project phases.

8.3 Phase 2: Detection and analysis

8.3.1 First response

The focus of this phase is to establish whether there has, indeed, been a security breach leading to an incident and, if so, how serious the incident is. It is important to have a classification matrix to establish the impact and the required level of up-scaling quickly.

The person reporting the incident is often also involved as the first responder. In this respect, it is important to inculcate conscious behaviour focused on preventing escalation of the incident, and protecting available evidence. Another aspect that is important here is protecting the object in question, so that security is safeguarded. An example of this would be closing a tunnel. Also important in this respect is the role of a forensic investigator and the balance between recovery of the object’s function (for instance, putting images back on systems) and gathering evidence for the follow-up procedure (which may mean that the process of recovery takes longer).

8.3.2 Classification

Classification depends on the nature of the impact (is the system as a whole down, has there been a data leak, etc.) and the type of incident. A typical classification is Critical, Significant, Low, Negligible. Incidents can be prioritised using this classification. In this respect, it is important to differentiate between the time in which an incident has to be reported and a prioritisation in how incidents and escalation are dealt with. This is important in order to be able to differentiate between differing levels of up-scaling and, as a consequence, establishing the sequence of the incident response process. For methods of classification, see:

• Federal Incident Reporting Guidelines.
• Computer security incident handling guide, page 33
• Cybersecurity incident response guide, page 36.

Classification and escalation are necessary because the issue here is not merely technical, i.e. getting the system up and running again, but also involves notifying the right people/parties. A standard communications plan based on a classification system is recommended. This must also cover a list of incidents for which the Autoriteit Persoonsgegevens (AP), the NCSC and/or the client need to be notified immediately.

8.3.3 Incident analysis

After classification and prioritisation, the following step is allocating incidents to a response team. The composition of the response team depends on the classification and the phase of the project. Typically, a team is made up of:

• Representative of the administrator (object, system).
• Service organisation (responsible for system components).
• Internal cybersecurity experts (e.g. the SOC in question).
• External cybersecurity experts (e.g. from the service organisation).
• Communications representative.
• Legal Affairs department representative.
• -…

What is crucial to the response team is a full understanding of the existing system architecture and operational processes. In addition, there must be sufficient representation of people with knowledge of the vulnerabilities and the possible impact of these. Technical and operational knowledge is brought together from design data, CMDB, business process and knowledge of IT/OT.

An overview graph shows an analysis of systems, applications, individuals and business processes involved. This analysis will have an iterative character. The first version describes the functional impact on the business process. The analysis then expands to highlight the technical level. The analysis also takes into account the possibility of the incident escalating, leading to a spread of the impact, and the fact that the choice of corrective action can also have an impact on other parts of the system.

8.4 Phase 3: Corrective action

The response team carries out an analysis of the incident and determines any corrective action. A structured approach is important in this context. A recovery plan must be drafted to obtain this structure. The recovery plan starts with the information obtained from the notification and then follows the process for dealing with the situation, up to and including the lessons learned and final report on the incident. The recovery plan is geared to selecting and implementing corrective action.

A recovery plan can vary from a ‘simple’ log in an Excel spreadsheet up to an entire volume covering analysis of systems and log files for the purposes of a forensic investigation. It is up to the response team to choose what form the recovery plan takes.

Subjects covered in a recovery plan include:

Closing the incident

Once the recovery plan has been implemented, it is important that the incident is administratively rounded off and formally closed. This will be in a different way for each project. An incident database often contains the notification and the steps leading to closure of the incident. Depending on the type of contract, the client and contractor may wish to make a settlement based on the logging of incoming and closed incidents. The recovery plan also forms the input for a potential forensic investigation, and therefore is of legal value.

8.5 Phase 4: Evaluation and lessons learned

8.5.1 One-off or structural incidents

It is important to learn from incidents involving security breaches. Sharing information on such incidents with other organisations by means of ISACs (Information Systemworks and Analysis of Changes), for example, is of essential importance for learning both within the Netherlands and abroad. Incident logging and regular reporting on incidents that occur are ingredients in a proper information security policy. As a result, once the incident has been closed, the recovery plan can be rounded off with the chapters ‘improvement’ and ‘communications’.

The occurrence of an incident may be caused by a one-off event. Once the incident has been resolved, a re-evaluation can be used to determine whether or not this incident could occur again. If the answer is yes, then options will have to be explored for a structural solution. Alternatively, it could be viewed as a residual risk and, as a result, nothing changes. For example: the risk created by forgetting to lock a PC can be reduced by configuring the PC so that it locks automatically after a specific period of inactivity. The normal operational process for determining the period of inactivity before locking must, of course, be taken into account in this respect.

Structural incidents cannot be resolved merely by correction of the incident that occurs. The vulnerability of the object as a whole can be reduced by implementing corrective action in other, comparable systems. Under those circumstances it is important to know exactly what the existing configuration is.

Preventative measures can be carried out on the basis of an annual update of the risk assessment. Newly-discovered vulnerabilities may lead to extra security measures or to the choice of adding and/or replacing systems.

8.5.2 Reports and communication in relation to incidents

The client will need to gain insight into incidents that have occurred and how they have been closed. Urgent and critical incidents must be forwarded immediately to the client’s security contact. A standard report can be used to give insight into incidents that have occurred and the action taken. The report shall be delivered regularly (once per quarter is an ideal benchmark for this) in the form of an executive summary. This report will not contain every detail on the incident, as some of the information is confidential. It is worthwhile to discuss the format and level of detail with the client. That way the client will gain an insight into the nature and impact of any incidents that arise, plus information on prevention of similar incidents. On request, the client may be given an insight into the recovery plan that has been drawn up. Even if there have been no incidents in the reporting period in question, a report must still be drawn up. Where the measures have resulted in adjustments to systems, this will also have to be processed in the ‘as-built’ project documentation and in the CMDB.

8.6 In practice: typical incidents at various stages in a project

The online Triton is the world’s most murderous malware, and it’s spreading article gives a good picture of the way in which cyber attackers have operated in the past, slowly permeating the ‘defence in depth’ layers to reach the engineering station in the OT network and exploit a zero-day vulnerability.

Another incident trigger is documentation on the current objects that is spread out among the various parties that have worked on the object in question. This contains sensitive information (IP addresses, firewall rules, software operating systems, configurations, etc.). In practice, asset management shares such documentation with new projects, without always remembering to consider the sensitivity of the information or its relevance to the recipient. The person who shares this information is unaware that, in doing so, he is opening a door that allows access to previous projects. The recipient may have no intention of using the information for malicious purposes, but the information is nonetheless available to a much wider audience than would otherwise be the case. All parties involved in a project must be aware that information must remain confidential, even after the project has run its course. Transferring documents and processes in the form of a template must only be done after anonymisation and removal of all sensitive information.

9. Planning phase and tender procedure

9.1 Introduction

The planning phase refers to the physical and spatial phase that is rounded off with a planning decision, such as a decision on the route of infrastructure, or development and zoning plans at provincial or municipal level. A tunnel safety plan is also drawn up during this phase. The starting points of the cybersecurity policy may be included in this and then constitute a formal part of the agreed statutory plan, i.e. an official part of the tender procedure.

Tender procedures are driven by additions to or replacement of existing infrastructure, in the field of both building services and civil engineering. Life-cycle considerations, management and maintenance, and changing legislation are all key drivers in this respect. OT has an important role to play in the control of infrastructure. Due to continued digitisation, new functionality in this area is becoming available all the time. Remote control is a prime example of a new opportunity of this kind. ‘Being connected’ is ever more important, both from an operational point of view and from the perspective of management and maintenance. Easy availability of information often ensures that there is a lot of interest in its own right. There are many benefits, but also new risks, including cybersecurity.

In order to safeguard cybersecurity throughout the life cycle of an object, the client will have to consider contractually enshrining cybersecurity during contract negotiations. The aim of this is that the contractor delivers and maintains a system that meets the organisation’s cybersecurity requirements, see also 4. Cybersecurity organisation.

9.2 Tasks, powers and responsibilities

In this phase there is a client and various bidders. The focus in this phase is on information management (DMS) and screening of personnel.

Tasks of the client:

• Include cybersecurity regulations as contract terms.
• Classify documents and systems for information exchange.
• Request an NDA (non-disclosure agreement) before forwarding documents.
• Monitor removal of information provided to unsuccessful bidders.

Tasks of bidders:

• Request an NDA (non-disclosure agreement) from third parties.
• Configure a confidential document environment.
• Where necessary, configure a physically-segregated project environment.
• Include cybersecurity terms in tender (for all phases of the project).

9.3 Considerations prior to a tender procedure

In preparation for a tender procedure, the client will have to think about cybersecurity. This may include the following aspects:

Awareness

In the context of a wider sense of security, it is essential to create awareness of cybersecurity. Both the client and the contractor must be prepared to have cybersecurity ‘flowing through their veins’. A similar process is often used in auditing security in general. What this teaches us is that it is not enough merely to take all sorts of precautions. Without a real appreciation of security as a whole, individual measures can easily be circumvented.

Life cycle

Cybersecurity has its own life cycle that often differs from the technical life cycle of the OT system in question. Today, threats come and go in less time than it takes a system to become obsolete. There is always the possibility that a system has to be replaced before the end of its service life for cybersecurity reasons. Although it may well be possible to come up with measures to prolong the life cycle within the system’s service life.

Integrated design

Cybersecurity demands an integrated, multi-disciplinary design, with a focus on life-cycle costing (LCC). Only then is it possible to make a proper selection of the measures to be taken in terms of process or technology. LCC is important because cybersecurity measures demand attention throughout the entire life cycle of the system. In that context, the availability of the system is also certainly worth attention. A nightly update, as is customary in the IT world, is not always acceptable.

Management and maintenance

Cybersecurity demands management and maintenance. The work this involves is of a different type than ‘regular’ management and maintenance activities for the object. It demands different know-how and expertise, and is sometimes at odds with the level of availability required. Outsourcing maintenance in relation to cybersecurity is a cybersecurity risk in and of itself. From the perspective of cost and the required know-how it is understandable, but it requires very clear guidance.

Information security

Cybersecurity demands proper information security, as the unintentional release of information forms a cybersecurity risk in its own right. This is an aspect that needs attention during the tender procedure, as it is at that point that it is important to share information with potential contractors. Openness surrounding the existing situation is the only way to achieve the right solutions.

New build or renovation?

New build and renovation both have very different dynamics. Not least because the latter is often subject to the precondition that the highest possible availability is guaranteed. In addition, where elements are built from scratch, the cybersecurity aspect is often a blank canvas to be filled to the required level of resilience. Where renovation is concerned, the existing situation may, from the start, impose several limitations that make it impossible to achieve a specific level of resilience within the budget allocated.

Many objects were built in a time in which there was little attention for cybersecurity (although it was already an issue). Where this is the case, it may be wise, in an integral context, to consider reverse engineering, with the aim of arriving at a new design that can then form the basis for further expansion.

Resilience throughout the chain

The starting point for the design is the resilience level to be achieved. This will have to be viewed in terms of not just the infrastructure in question, but also for the chain of which the infrastructure forms a part. After all, a chain is only as strong as its weakest link. Of course, the question that has to be addressed is whether or not to outsource the process of determining the level of resilience.

9.4 During the tender procedure

At each step of the tender procedure, the following aspects deserve attention.

Provision of information

Time will have to be spent thinking about making sensitive information relating to cybersecurity available. Not only during the tender procedure, but also thereafter in relation to unsuccessful candidates. For instance, consider information on security systems, access control and the data-transmission network(s): who is allowed to see such information and how is it protected? Document systems and document shares, and CAD/BIM environments also need attention.

Cybersecurity as a criterion for selection

During the selection process and at the stages of Request for Proposal (RFP) and proposal submittal, know-how and experience of both processes and technology have a role to play in how to deal with objects with a specific resilience level. Requesting references and/or an action plan are options in this respect.

Project/tender management

Cybersecurity is a concern from the moment that a contract is awarded, not just from the moment at which the object is completed and ready for use. During the design and build phases, cybersecurity is perhaps even more important than on completion. Most preventative work can be done at this stage. And corrective or repair work at a later date is much more costly.

In the preparatory phase of the tender procedure the client must consider the requirements that the technical (and other) infrastructure to be supplied must meet in order to be sufficiently resistant to cybersecurity threats. In addition, the client must think about the requirements that the bidder must comply with in the field of cybersecurity, both during the project phase and, in the case of a DBFM contract, during the operations phase.

9.5 Management

Cybersecurity measures must be fully incorporated into both the technical design and the organisations concerned (the people). It is therefore important for these aspects to form part of the tender requirements. With the help of the systems engineering, these requirements will be validated in subsequent phases with the aim of further enshrining the measures.

It is also important for information that forms part of the tender process to be classified. Sensitive information must solely be made available in a secure environment, and the availability of such information must be contingent on signing a confidentiality agreement. An agreement of this kind must include a clause to specify that sensitive information must be destroyed or anonymised after the contract has run its course. For miscellaneous aspects in relation to monitoring, see 7. Monitoring.

10. Construction phase (new build)

When building a tunnel, the process can be split into the following phases, see the figure below:

• 10.1 Design
• 10.2 Building
• 10.3 Handover

From the start of the project one must realise that all information produced under the auspices of the project could be of interest to someone with malicious intent at a later date. So right from the beginning, the very configuration of the project, it is important to draw up rules for the classification and processing of all documentation that will be generated.

Everyone working on the project must be aware of the risks in this area and must know what action to take to keep the risk of design documentation getting into the wrong hands as small as possible.

10.1 Design

The agreed contract forms the basic documentation for the design phase of a building project. That contract contains many requirements for the project to be implemented. Most of the requirements relate to the functionality of the object to be built but, ideally, the contract will also cover non-functional requirements, not least on the issue of cybersecurity. See the 9. Planning phase and tender procedure chapter for the way in which the contract is formed.

Unlike the functional requirements, requirements relating to cybersecurity will have consequences for almost all aspects of the design; that is why it is sensible to incorporate this subject as an integrated theme in the design, rather than ‘outsourcing it’ as something for the various specialists in specific parts of the system to consider.

The client may already have described identified risks in the contract. Those risks can be used to formulate control measures to address the risks that pose an unacceptable threat. In the event of the client not having identified any risks, one of the first tasks facing the contractor in the design phase is to carry out a risk assessment together with the client. IEC-62443 3-2 can be used as a guideline in this respect. Another option is to use ISO/IEC 27005, from the ISO/IEC 27000 series, although this standard is geared more towards environments which deal with information.

Where IT and OT were, traditionally, seen as two separate worlds, today an increasing number of factory processes depend on IT solutions. To protect both worlds properly, it is necessary to have an integrated ‘IT/OT approach’ to cybersecurity.

Cybersecurity in the design process, in new-build projects and during maintenance

Ideally, cybersecurity is a regular part of the design process of an OT system. Cybersecurity is one of the aspects in a RAMS (or RAMSHEEP) analysis. Many OT systems in the Netherlands in 2019 are in need of a check-up in order to update resistance to the cyber threats of the present day. In that case, what is required is cybersecurity renovation, which presents the opportunity of drafting the cybersecurity requirements (by the book) in both quantitative and qualitative terms on the basis of the operational objectives of the OT system, and of designing and implementing the appropriate, specific cybersecurity measures on the basis of a structural risk assessment (threats, vulnerabilities). Where the OT systems are serviced under the regular maintenance regime, a minimum cybersecurity requirement of any change not lowering the current cybersecurity level may apply.

In terms of the design it is important that the object to be delivered under the contract is ‘cyber safe’, not just at the point of completion, but thereafter as well. The design must take into account, wherever possible, the ability to make changes that are needed to keep the object cyber safe during its service life. This principle has an impact on both the design of the technology and the design of the processes and structure of management and maintenance.

10.1.1 Tasks, powers and responsibilities

In this phase there is a client and a contractor. The contractor creates a design that demonstrably complies with the required legislation. This phase focuses on information management (DMS), security by design and screening of personnel.

Tasks of the client:

• Appraising cybersecurity plans, cybersecurity risk assessments.
• Testing of designs, both in terms of structural aspects and operational technology.
• Managing cybersecurity requirements when deploying third parties and sub-contractors.
• Co-ordinating approach and implementation with policy-making agencies.
• Discussing cybersecurity in management meetings.

Tasks of the contractor:

• Cybersecurity risk assessment.
• Drafting a management plan for cybersecurity.
• Drafting security plan(s) for cybersecurity.
• Drafting procedures for cybersecurity.
• Risk assessment and selection of control measures.
• Follow through on cybersecurity requirements in respect of consultancies and sub-contractors.
• Discussing cybersecurity in management meetings.

10.1.2 Risks/points for consideration

The basis for surveying the situation and the measures to be defined is the concept of integrated, layered security, or ‘defence in depth’, see the figure below. Each layer of security represents part of the whole. As the building blocks differ for each layer, the measures to be taken are also different. The diversity of measures to be taken ensures that a weakness in one layer can be made up for by a measure in a different layer. Creating sufficient security for each layer gives rise to a security concept of cumulative protection for the core. The benefit of this accumulation of layers of security is that the risk of the system as a whole being disrupted reduces, because an array of security features have to fail before the system as a whole fails.

Schematic depiction of layers of security.

An important point to realise is that there are two sorts of risks facing a project in the critical infrastructure. On the one hand, the product created under the terms of the project implies a certain level of risk (e.g. the automated operating system, monitoring and control of a tunnel, bridge or lock), while on the other hand, there are risks associated with the project itself. We will first address the risks that could arise in relation to the product, then we will turn our attention to the risks associated with the project.

The following is a much-used list of threats in an OT environment:

1. unauthorised persons have physical access to operating and technical areas.
2. unauthorised persons have access to the IT and OT/SCADA systems and/or documentation, such as drawings, manuals and the like.
3. Information on security vulnerabilities and security breaches is missing, as is a framework for action.
4. Unauthorised persons have access to the data network (via the internet or wireless applications).
5. IT and OT/SCADA systems have vulnerabilities and are susceptible to malware.
6. Inability to detect and analyse abnormal behaviour on the data network and incidents arising via logging and monitoring.
7. Hazards introduced by operations and/or maintenance workers. They are unaware of potentially dangerous situations, do not have the right training, have not signed a confidentiality agreement or are not in possession of a recent certificate of good conduct (VOG).
8. Functional changes may have unintentional effects on safety and security, and may even cause the functional operation of IT and OT/SCADA systems to fail, either completely or in part.
9. The enforcement and effectiveness of the cybersecurity measures is not guaranteed, and this has not been applied to subcontractors as a matter of course.
10. In the event of disruption to the system or functional changes there is no fall-back option (no back-up or recovery process).

On the basis of this set of ten threats, it is possible to define a set of risks by identifying one or more vulnerabilities and one or more adverse consequences. The potential result of this exercise is shown in the summary below:

1. Unauthorised persons gain control of means of access and are able to enter operations and technical areas. This means that they can operate and deactivate OT systems.
2. Unauthorised persons enter operations and technical areas by means of social engineering (tailgating or appeal to vanity/authority). This means that they can operate and deactivate OT systems.
3. Unauthorised persons find a way to break into operations and technical areas. This means that they can operate and deactivate OT systems.
4. Unauthorised persons gain control of other people’s login data and, in so doing, gain access to the internal network. From this network it is possible to operate and manage OT systems.
5. Unauthorised persons use an open external connection to gain access to the internal network. From this network it is possible to operate and manage OT systems.
6. Unauthorised persons hack into the remote access/authentication process and gain direct access to the internal network. From this network it is possible to operate and manage OT systems.
7. Vulnerabilities cannot be remedied because reporting on vulnerabilities has not been carried out or acted upon.
8. Security incidents do not elicit a proper response or other response of any kind in good time, so dependent systems also become inaccessible.
9. Unauthorised persons find a way to circumvent the operations or management network security and are able to gain control of OT equipment in the network.
10. Malware from external sources penetrates the system and freezes infected systems.
11. Malware from external sources penetrates the system and harvests data from infected systems.
12. Targeted malware from external sources penetrates the system as far as the PLCs and executes commands that lead to physical damage.
13. Incidents are not detected in good time, so a cyber incident has an impact on more than one subsystem.
14. Information on incidents is not recorded, which complicates system recovery and hinders the implementation of extra security.
15. Operations or maintenance personnel deliberately leak confidential information.
16. Operations or maintenance personnel are lax in their handling of information and accidentally leak confidential information.
17. Operations or maintenance personnel connect infected hardware to the internal IT or OT/SCADA network, which deactivates OT equipment.
18. Operations or maintenance personnel fail to recognise signals indicating an incident, or ignore them, so the incident cannot be stopped (or not stopped in time).
19. An unverified change in software or hardware is not compatible with the rest of the system. As a result, certain OT systems cannot be controlled.
20. An unverified change in software or hardware responds differently to expected (manual) commands. As a result, the system behaves differently to the operators’ intention, which leads to physical damage.
21. An unverified change in software or hardware introduces malware or opens a ‘back door’ to the system. This means that OT equipment can be controlled or deactivated by third parties.
22. Specific measures are not complied with internally, as a result of which other risks are amplified.
23. Specific measures are not included in contracts with subcontractors, as a result of which hardware or other equipment and operating systems provided do not have the required level of security.
24. Subcontractors fail to comply with specific measures, as a result of which hardware or other equipment and operating systems provided do not have the required level of security.
25. As there is no fall-back option, systems have to be backed-up manually, as a result of which the system is unavailable for a longer period.
26. The fall-back option has insufficient security, and is also infected on activation.
27. The fall-back option has not been updated and, on activation, causes unverified functional changes.

Note: the above summary is intended to be an example of situations that may arise, rather than an exhaustive list.

On the basis of the above list of threats, IEC-62443-3-2 makes it possible to make a baseline measurement and assess the risk level without creating control measures. Using the baseline measurement, it then becomes apparent what the most significant risks are, and the control measures that are required to reduce the risks to an acceptable level. Precisely what that acceptable level is must be determined by the organisation that is going to manage the object to be created. They will be confronted with the consequences of the risk occurring, and the necessity of recovering normal functionality of the object within a reasonable time frame and at reasonable expense. Potential measures will be explored in the following section.

As explained above, there are also risks associated with the project itself. These are no longer those associated with the OT, but rather risks that are the consequence of the fact that the project generates information that is of potential interest to malicious third parties. This can then be subdivided into information on the project (who is working on it, how much does it cost, what is the progress, etc.) and information on the object to be created (the design documentation). For the purposes of this living document the design documentation is particularly important: sufficient practical information relating to protecting information on the project can be found elsewhere.

The design documentation (from a to z) may be used, if it gets into the wrong hands, to investigate whether the design has any weak points and how it is configured to tackle attacks. That is why it is important to carry out a risk assessment for this documentation, too (ISO/IEC 27005 can be used for this purpose). Subjects that must be addressed in that context:

• Sufficient physical access security at the design locations and workstations on site. In other words: access restricted to personnel who work there. There are measures in place to prevent access by unauthorised persons.
• Secure storage of the design documentation; who is allowed to do what, and how is this protected?
• What is expected of personnel working on the project in relation to communications, both internal and external, and how can design documentation be shared in a secure and trusted manner?
• How is the review and approval process set up, and what risks might it harbour? Who is allowed to see what, and how is this safeguarded?
• How are the computer systems that are used to create the design documentation protected?

10.1.3 Measures

When defining control measures it is important to keep an eye on three aspects at all times, namely People, the Organisation itself and Technology. Such measures often have an impact on more than one of these aspects and must be in equilibrium if the intended effect is to be achieved. If, for instance, technical measures alone are created while other aspects are ignored, the intended level of risk control will not be achieved. More to the point, new risks that cannot yet be envisaged may arise because people who are unaware of, or do not understand the reason or importance behind the measures circumvent them. One example of this is the introduction of minimum requirements for passwords: this often leads to situations in which strong passwords are written on a scrap of paper and stuck to the monitor or under the keyboard, which has the effect of completely negating the purpose of the measure and actually increasing the risk.

10.1.4 Management

The process of managing measures in the design phase concentrates particularly on the implementation of the cybersecurity requirements in the technical design on the part of the contractor, and the testing of these by the client. In addition, it is important that information that forms part of the design is classified. Sensitive information must be available solely in a secure environment with access control. This is also the case where communication with potential suppliers is concerned; in this respect, consider agreeing terms on how confidential information and documentation is dealt with. The document management process may be audited. For miscellaneous aspects in relation to monitoring, see 7. Monitoring.

10.2 Building

This section describes the way in which the subject of cybersecurity is addressed during the implementation (building) of an infrastructural project.

10.2.1 Tasks, powers and responsibilities

In this phase there is a client and a contractor. In this phase, the focus is on safe access, network security and screening of personnel (of third parties).

Tasks of the client:

• Awareness and training of future operators.
• Awareness and training of company personnel.
• Reviewing the implementation of cybersecurity measures.

Tasks of the contractor:

• Cybersecurity risk assessment.
• Establish clearly-defined powers for cybersecurity officers. Under what circumstances can implementation be stopped in response to an incident?
• Where necessary, build a secure test environment.
• Access control and logging.
• Access control of each room in which active hardware is set up.
• Draft a procedure for cybersecurity.
• Verify and validate user accounts and log files.
• Implement hardening for all IT and OT.
• Penetration test (internal/outsourced).
• Implement cybersecurity requirements in relation to suppliers and subcontractors.
• Protect information at the construction site.

10.2.2 Risks/points for consideration

• Actual access security of design locations and work stations.
• Information storage (location and security (who is allowed to do what and how is this protected?)).
• Communications guidelines, both internal and external.
• Review and approval process (who is allowed to do what and how is this monitored, both on the part of the client and contractor in its capacity as competent authority).
• Security for computer systems.
• Segregation of operational and new situation
  • New build: e.g. traffic centre or operational data transmission network.
  • Renovation/conversion: e.g. operational local systems.
• Who is allowed to do what and how is this monitored, both in terms of insight into and implementation of the testing.

10.2.3 Measures

10.2.4 Monitoring

During the construction phase it is vital to include testing and validation of the implementation of cybersecurity requirements as an integral part of the systems engineering. The client may also carry out audits during the construction phase. In this context consider workplace visits and physical inspections. Access management in relation to the construction site and any confidential information that can be found there is a point for consideration.

10.3 Handover

This section addresses the handover phase. The term ‘handover’ means the point at which the project organisation transfers control over the project to the organisation concerned with operations. In terms of the project this is a single point in the cycle, a transition between project phases. With a view to cybersecurity, handover is seen as more than a single point, as the project team must take account of the fact that the point of handover and transfer to the management and operating organisation can only be successful if prepared properly. Points for consideration in relation to preparation for handover are outlined below.

10.3.1 Risks/points for consideration

Handover marks the point of transfer from construction to exploitation and, accordingly, the start of the processes that form part of operations and management. Among other things, this means that the following subjects must be taken into consideration:

10.3.2 Measures

To smooth the handover process, the transition from phase to phase (i.e. from construction to handover) must go hand in hand with the appropriate conditions and they must constitute deliverables of the construction project. A construction project should usually hand over the project results to a management organisation to kick off management at the technical/operational level. In a similar way, the project results may also be handed over to the cybersecurity management organisation. See 4. Cybersecurity organisation

10.3.3 Monitoring

Cybersecurity must be incorporated into the DNA of the organisation and be a fixed part of each and every discussion on the maintenance of the object. By frequently having the object risk report updated, it is possible to reveal where attention needs to be focused if cybersecurity is to be kept up to date.

11. Exploitation phase

11.1 Introduction

Operation

Exploitation is the phase after the tunnel system has been opened for use in accordance with the tunnel opening permit, during which it is operated and monitored in accordance with standard procedures, including those designed to manage cybersecurity.

Operational

The tunnel is operational if the tunnel system is in use. One of the activities during the use phase is maintenance: the measures taken to ensure that the condition of the tunnel system does not change, for example by one-for-one replacement of worn-out parts, lubrication and cleaning, patching, reading log files and checking calibrations and settings. For recurring activities, there should be procedures that have to be followed, which can (should) safeguard cybersecurity. For incidental maintenance activities that are not covered by procedures, cybersecurity must be guaranteed on a case-by-case basis.

Renovation

Renovation of the tunnel system involves:

1. redesigning the system (or parts of it) in such a way that the changes still support the original purpose and are kept in good condition with regular maintenance;
2. redesigning the system for a new purpose.

This document distinguishes two forms of renovation: the situation where the tunnel is closed entirely and/or is only partially used for short periods, and the situation where the tunnel is closed entirely for a longer period (examples are the Velsertunnel and the Koningstunnel). There is no definition of ‘short’ or ‘long’: it depends on the specific project. If the tunnel is closed for a longer period, the approach corresponds with that for new-build, see section 10.2 Building (new-build).

11.2 Operational phase

This section covers the object’s operational phase: the period when the tunnel system is in use. One of the activities during the tunnel’s use is maintenance.

11.2.1 Tasks, powers and responsibilities

During this phase, there is a client and a contractor. The focus in this phase is on physical and logical access control, auditing and evaluation, and the screening of personnel.

Tasks of the client:

• Assessment of risk analyses and reports relating to cybersecurity.
• Annual audit.
• Network monitoring.
• Incident response.

Tasks of the contractor:

• Cybersecurity risk assessment
• Clear definition of the powers of cybersecurity officers. Under what conditions can an object be shut down in the event of an incident?
• Registration and monitoring of physical and logical access.
• Network monitoring, reporting.
• Incident response.
• Patching.
• Evaluation of aspects such as long-term processes, documentation, incidents, log files, drafting/assessment of reports, reviewing risk estimates, etc.
• Testing of back-up and recovery procedures.
• Annual evaluation and report.

11.2.2 Measures

11.2.3 Management

The exploitation phase is generally the longest one. It is important for the parties concerned to have a clear understanding of the delegation of specific responsibilities. Continuous processes to manage measures include reports (of incidents, status of access control, etc.) and consultative structures. It is also important to review the estimated cybersecurity risks and the cybersecurity plan and ensuing measures frequently. Monitoring of systems and networks and conducting internal/external audits of the technology and the organisation can also contribute to permanent compliance with measures. Naturally, the client and the contractor must have the necessary budget and expertise for these activities.

A number of crucial aspects of the exploitation phase were already mentioned under ‘Opening’, such as the training of personnel, the execution and effectiveness of the password and cybersecurity policy and the design of the management organisation. On top of that, the training plan also has to be implemented during the exploitation phase. Any developments in the domain of cybersecurity that affect or influence work processes must be included in the teaching materials for the education and training plan. For the general aspects of monitoring, see chapter 7. Monitoring.

11.3 Renovation

This section describes the approach to cybersecurity if the tunnel system (or parts of it) will be closed entirely and/or will only be partly in use for short periods. If the tunnel is closed for a longer period, the approach corresponds with that for new-build, see section 10.2 Building (new-build)

As mentioned earlier, cybersecurity in relation to an object starts with a risk inventory. What are the risks? What are the threats? What are the consequences if a risk occurs? Can we remove the cause? Should we limit the consequences? Et cetera.

In that respect, a renovation starts in the same way as a new-build project: establish the client’s requirements, carry out a risk inventory and follow the V-model. But for a renovation project, there are two additional aspects to the risk inventory. First, it might not be necessary to replace every part of the system; second, it might be impossible (or difficult) to reduce all of the risks because of design choices that were made earlier and cannot now be changed (without difficulty).

11.3.1 Tasks, powers and responsibilities

During this phase, there is a client and a contractor. Depending on the nature of the renovation, this phase can also include a design and a building phase, as well as a demolition phase. One aspect that demands special attention is the fact that renovation involves a complex hybrid situation of an old system and a new system.

Tasks of client:

• risk assessment.
• Clearly determine who is responsible for security in the existing situation (in the various phases).

Tasks of contractor:

• Also performs a risk assessment.
• Plans and validates phased transition from the old system to the new one.
• Safely disposes of information-bearing components.
• Focus on secure access, network security, screening of personnel (also of third parties).

11.3.2 Measures

Two situations need to be taken into account in the case of renovation:

• Installations that need to be (partially) replaced, and
• The constraints that the existing situation might create for the desired new situation.

The measures to be taken are also determined by the duration of the tunnel’s closure. They will usually be specific to the situation and will therefore create more, and more complex, risks than with new-build and demolition.

11.3.3 Monitoring

The systems and installations that need to be changed are identified during the renovation phase. This usually involves upgrades or the replacement of entire systems. Expansions also fall within the scope of this phase.

During this phase, the principles of systems engineering are followed. This means that the (new) security requirements apply and must be fully incorporated in the entire renovation process, including the system and network architecture. For specific construction and new-build aspects, see chapter 10. Construction phase (new build).

Released systems/installations must be assessed for sensitive business and personal information and then sent (at least in the case of national tunnels) to the State-owned Moveable Property Agency (Domeinen Roerende Zaken, DRZ). This process is helped by a well-maintained IT/OT/application configuration management system. For specific aspects of the demolition phase, see chapter 12. Demolition.

Security audits during the renovation phase (for example, visits by the client to workshops and workstations) will enhance awareness of security.

12. Demolition

When an infrastructure object is being demolished, the main focus in terms of cybersecurity is on how information is destroyed or saved. Discarding information or information carriers that contain security data constitutes a cyber risk. On the other hand, not everything can simply be destroyed because companies and public authorities have a duty to save certain information (see rules for government archives and explanatory notes from the Tax and Customs Administration).

12.1 Tasks, powers and responsibilities

In this phase, there is a client and a contractor. The focus in this phase is on safely disposing of information-carrying components and shutting down external connections to the demolished object.

Tasks of client:

• Shut off connections to the object.
• Receive and wipe clean or destroy network equipment.
• Safely archive all project information.
• Dispose of all non-archived information (documentation, back-ups, personal data, log files).

Tasks of contractor:

• Classify equipment from the project.
• Wipe clean or destroy data carriers.
• Hand over client’s equipment.
• Remove all documentation found at the object and destroy or hand over the documentation to the client.

12.2 Measures and monitoring

The systems that will have to be disposed of are identified at the beginning of the demolition phase. These systems have to be ‘dismantled’ in a professional manner, which means that a demolition/dismantling plan must be drawn up and approved by the parties concerned. The plan must cover the following subjects.

• What is the scale of the demolition, which (sub-)systems have to be removed and which should continue to function temporarily or permanently?
• Asset lists of the systems to be demolished.
• Identify which components/equipment/products (or product data) contain sensitive business/personal information.
• Determine how the released materials will be disconnected and disposed of.
• Released systems/installations must be assessed for sensitive business and personal information and sent for destruction (at least in the case of government tunnels) to Domeinen Roerende Zaken (DRZ). These items include data carriers, documentation (client and sub-contractors), switches, firewalls, settings in OT equipment and PLCs, etc.
• Planning (starting date and duration, authorisation of relevant personnel).
• Supervision, both at the physical location (decoupling and transport) and during the logistics process up to and including scrapping.
• Validation with a final report.

13. Practical experience

This chapter contains practical examples of things that might be found during inspections or after evaluations of incidents. The findings are accompanied by suggestions for management measures that could be taken to enhance resilience against cyber risks.

For news of recent hacks, see the notices on the site of the National Cybersecurity Centre (NCSC). Indegy also produces an infographic with up-to-date information.

13.1 Layered security

For the security of an infrastructure object, the principles of layered security are followed:

A hacker first has to succeed in gaining access to a system. He or she can do so via the network or by gaining physical access to the rooms where the system is kept. Once access has been gained to the system, the hacker can try and enter it or manipulate it. This can be done by abusing accounts and passwords or by exploiting software, viruses, existing vulnerabilities, etc. For the tunnel’s operator, manager or maintenance staff, it is important to detect and recognise what has happened. They then also have to know what to do. If things do go wrong, the operator must know what action to take to limit the impact and prevent any further damage.

13.2 Physical access security

Findings

• Maintenance workers are often on-site unannounced; the tunnel operator has no security task and allows people in.
  Risk: a hacker can enter the site unchallenged.
• There is no procedure for granting access where it is needed, but even simple anti-burglary measures often do not meet requirements.
• Risk: a hacker can simply break in and gain access to rooms in which the systems are kept.

Measures

• Introduce a key management and access procedure, keep it up to date and ensure compliance with it.
• Always require visitors to report on arrival at a location, particularly contractors.
• Improve and maintain the standard of anti-burglary measures.
• Institute security zones (on the grounds and in buildings).

13.3 Network security

Findings

• Unfounded confidence in the insulation of the SCADA system from other networks means that people fail to take adequate measures in other areas.
  Risk: awareness declines, making the system vulnerable.
• There are direct (internet) connections to the tunnel systems.
  Risk: infection of SCADA with malware or open access to SCADA for unauthorised persons.
• There are various connections between office automation and the SCADA network.
  Risk: infection of SCADA with malware or access to SCADA from office automation.
• There are various modems and open ports that were previously used to gain access to SCADA from internet.
  Risk: it is easier for a hacker to abuse the network.

Measures

• Insulate the SCADA systems from other networks.
• Monitoring and control of the connections with the tunnel system.
• Remove connections between office automation and the tunnel system.
• Remove open ports and modems (that have no function).
• Authentication and encryption.
• Create a controlled route for getting ‘from outside to inside’, for example using a jump server which has proper security and is permanently monitored.

13.4 Logical access security

Findings

• Functional accounts rather than personal accounts.
  Risk: it is impossible to ascertain who did what if something goes wrong.
• Passwords are almost never changed.
  Risk: everyone who has ever had contact with the tunnel can log on.
• Passwords are almost always in the local handbook.
  Risk: unauthorised persons can also log on.

Measures

• Tighten up and regularly update the password policy.
• Tighten up and regularly update the log-in procedures, for example with the use of multi-factor authentication.
• Change passwords whenever procedures are introduced.
• Lock management and operation workstations after use and during absence.

13.5 Anti-malware and patching

Findings

• Possible malware found in SCADA network. Absence of anti-malware measures.
  Risk: malware can have a negative effect on the system or allow remote access.
• Patches are only implemented if SCADA is not working. Very old software is often still used.
  Risk: the hacker can use a vulnerability in the system to evade the logical access control or malware can cause a DoS or open up access.

Measures

• Prohibit connection of unscanned USB sticks or laptops.
• Remove the malware that is found and apply anti-malware programs around the tunnel systems.
• Stipulate anti-malware measures in maintenance contracts.
• Replace software that is no longer supported by the supplier (no security updates).
• Have a system administrator install verified security patches via a portal.

13.6 Detection

Findings

• Operators treat all unusual reports as a technical fault in the SCADA systems.
  Risk: a hack is no longer recognised as a non-conformity, with the result that the vulnerability the hacker exploited is not looked for or discovered and the hacker can proceed again after the function has been restored by a member of the maintenance staff.
• Maintenance staff do not look for vulnerabilities or malware.
  Risk: vulnerabilities or malware may be present without anyone’s knowledge, thus allowing a hacker to proceed.
• Tunnel systems do not all save log data or the data are not retained.
  Risk: it is impossible to discover the cause of abnormal behaviour, thus a hacker can proceed.

Measures

• Internal and external personnel must be sufficiently aware of and familiar with the risks (cybersecurity awareness). This can be promoted by organising:
  • specific workshops for tunnel operators (awareness training).
  • training (e-learning) for maintenance staff and managers.
• Every suspected cyber incident should be notified to the incident officer. If necessary, hire a security specialist for advice.
• Draft and implement a procedure for cyber incidents.
• Arrange active monitoring by a security operations centre.
• Record and save log data for all tunnel systems.

13.7 Perspective for action

Findings

• There is no perspective for action for a cyber incident specifically for tunnels.
  Risk: the maintenance party resets the SCADA system and the hacker can proceed again or hack the following tunnel. The tunnel manager is ‘blind’ to hackers.

Measures

• Draft a tunnel-specific perspective for action for various hacking scenarios.
• In the event of serious disruption to the normal operating process, use the emergency stop to prevent further damage/consequences.
• Monitor the crisis management process.
• The operator’s initial reaction is to close the tunnel. That is correct.

13.8 Back-ups and asset management

Findings

• There are clean back-ups, but they are not always up-to-date or immediately accessible.
  Risk: there is an unnecessary delay in restoring the function and the most recent changes are lost.
• There are clean and recent back-ups, but the recovery process for the entire chain is never practised.
  Risk: restoring the system’s operations is unnecessarily delayed.
• Asset management is not entirely in order. Documents are sometimes updated and distributed, but sometimes they are not.
  Risks:
• There is insufficient reliable documentation available if recovery or rebuilding is necessary.
• It is impossible to respond to notifications about new vulnerabilities or hacks from a CERT if it is not known which versions of software have been installed.

Measures

• Regularly make or update back-ups and test whether resets are possible.
• Update registration of software and documentation.
• Improve the management process for software and documentation management.
• Improve the change process.
• Contractually guarantee that the maintenance party will keep the documentation up to date.

Appendix 1: OT vs. IT

The IEC 62443 standards are written from the perspective of the industrial environment (operational technology, OT). OT systems comprise ICS, SCADA, PLC and IO systems and contain software, firmware and hardware. Confidentiality, integrity and availability are less of a priority within OT: a tunnel must remain operational to prevent traffic congestion, whereby information is more widely available than is desirable from the perspective of confidentiality.

The ISO/IEC 27000 standard is intended mainly for office environments based on information technology (IT), such as office automation (SAP, Microsoft Office, etc.). Confidentiality is the most important factor in the case of IT, followed by integrity and availability. For example, who has access to what confidential business data?

The following table shows the differences between IT and OT systems (source: Applied Control Solutions).

Note:

Whereas IT and OT have traditionally been separate domains, a growing number of today’s manufacturing processes depend on IT solutions. Consequently, the OT environment is more often affected by malware from the IT environment. In practice, more than half of the malware problems in an OT environment are found to arise from the organisation’s own IT systems. The development of the Internet of Things (IoT) has now reached the OT world. For proper protection of both domains, the logical answer seems to be an integrated ‘IT/OT’ approach to cybersecurity.

Appendix 2: Abbreviations

Appendix 3: Standards and guidelines

List of the current norms and guidelines cited in the living document as of 26 November 2019.