11

Implementation of the ICS

Cybersecurity Management Approach

11.1. Introduction

11.1.1. Organization of the process

Securing a control command system has many facets. Several possibilities

exist to organize the process. A fairly natural approach is to consider the
different phases of the risk evolution, or more precisely the course of events
leading to damage.

First of all, it is necessary to put in place controls to limit the possibility

of occurrence of unwanted events. In the case that, despite these controls,
attacks occur, it is important to be able to detect them and provide
appropriate mechanisms. If an attack is detected, to limit damage, an
appropriate response must be planned and implemented. Finally, after this
crisis phase, if damage has occurred, we must be able to restore the system
and learn lessons to improve system security. This approach is the one
proposed in the well-known NIST Cyber Security Framework (Figure 11.1),
which focuses on the different phases of risk management:
– identification;
– protection;
– detection, during operation;
– the response to attack;
– recovery.
274 Cybersecurity of Industrial Systems

For each phase, a number of areas have been identified. They include a
list of security measures to be implemented.

Figure 11.1. Structure of the NIST framework. For a color

version of this figure, see www.iste.co.uk/flaus/cybersecurity.zip

For the protection phase, an approach based on the defense-in-depth

approach makes it possible to properly structure actions in the case of
industrial systems. It is very similar to the LOPA method, used for the
operational safety of industrial systems, or the defense-in-depth approach
used in nuclear power.

A partitioning into zones and conduits as proposed by IEC 62443

(Chapter 7) makes it possible to set up a defense in depth in an appropriate
way (Figure 11.2).
 Implementation of the ICS Cybersecurity Management Approach 275

Data/physical process

Applications

Machines

Network

Perimeter

Physical access

Organization and
human factor

Figure 11.2. Defense in depth. For a color version

of this figure, see www.iste.co.uk/flaus/cybersecurity.zip

11.1.2. Technical, human and organizational aspects

Risk analysis approaches make it possible, either by using a checklist or

by using a detailed approach, to identify the vulnerabilities of a system and
the security measures to implement in order to achieve a given level of
control. It is important to remember that a significant number of these
measures are not technical and concern the organization and the human
factor. Many of them are of course not specific to industrial control system
(ICS) and concern the information system as a whole.

11.1.3. Different levels of implementation and maturity

It is not always possible to implement all measures at once. Most often,

the measurements are organized according to the diagram in Figure 11.3. The
protection measures are the first to be implemented, then the monitoring
systems are deployed in the second phase.

In addition, the measures put in place can be more or less well controlled.
Quality of implementation is assessed using the level of maturity, such as that
proposed by the IEC 62443 approach (Chapter 7), inspired by the CMMI
scale.
276 Cybersecurity of Industrial Systems

Passive defense Active defense Adaptive defense

- Learning from attacks to
- Architecture - Incident monitoring
design and implement new
- Filtering - Analysis and response
measures

Figure 11.3. Different levels of countermeasures. For a color

version of this figure, see www.iste.co.uk/flaus/cybersecurity.zip

The rest of this chapter first proposes a simplified approach to securing

ICS, and then presents all the steps of a more detailed approach. The choice
between the two types of approaches depends on the issues and the level of
risk.

11.2. Simplified process

If the stakes are low, a simplified approach to risk control may be

sufficient. It is based on the 13 good practices proposed by ANSSI (ANSSI
2012a), which cover all important aspects.

It is useful to have carried out a mapping of the equipment (section

11.4.1), even if it is simplified, to determine:
– the workstations and servers in the perimeter;
– network equipment;
– PLCs and other low level control-command devices.

Based on the description of the installation and knowledge of its scope,

the approach, which is part of a defense-in-depth approach, consists of
implementing 13 good practices, described in more detail later in this
chapter:
– BP01: physical access control to equipment and fieldbuses (Chapter 1,
section 1.1);
– BP02: partitioning networks (section 11.10);
 Implementation of the ICS Cybersecurity Management Approach 277

– BP03: ensure that off-network exchanges via removable media are also
partitioned (section 11.11);
– BP04: user access control and user authorization management (section
11.14);
– BP05: harden the configurations (section 11.12);
– BP06: set up a logging of abnormal events and generate alarms (section
11.16.1);
– BP07: manage PLC configurations and programs to avoid unwanted
changes (section 11.13);
– BP08: make validated backups (section 11.19.1);
– BP09: have up-to-date documentation on the installation, reserved for
the authorized users (section 11.4.2);
– BP10: implement antivirus protection with regular updates (section
11.12.6);
– BP11: apply security patches regularly (section 11.17.2);
– BP12: protect the PLCs as well as possible given the technical
possibilities (section 11.12.3);
– BP13: pay particular attention to engineering stations, ensuring that the
good practices mentioned above are properly applied, especially for mobile
consoles (section 11.12.2).

These measures are all detailed below. They provide a satisfactory level
of security for a non-critical installation.

11.3. Detailed approach

The above pragmatic approach consists of applying a number of relatively

generic measures, which make it possible to obtain a “good” level of security,
and to maintain it at a minimum by setting up regular updates and
monitoring.

If we wish to implement an approach that is more adapted to the

installation, and with a more detailed understanding of the measures to be
implemented, the approach begins with a risk assessment, and includes a
number of steps presented in Figure 11.4. They can be classified into five
categories.
278 Cybersecurity of Industrial Systems

Identification Defense in depth Detection Response Recovery

4. Definition of the
security policy and 13. Implement an 15. Set up an
1. Make an incident handling
the procedures incident detection
inventory plan and an alert
system (IDS, SIEM)
5. Secure human chain
aspects
16. Set up a recovery
14. Set up security
and continuity plan
2. Assess risks monitoring (patch
6. Physical security
management, audit..)

Security of the IT/OT

3. Governance and system
Management 7. Sécuriser
7. Securel’architecture
network
et le périmètre du réseau
system
8.Secure off-network
exchanges
9.Secure stations
9.Sécuriser and
les postes
et equipment
équipements
10.Sécuriser
10. Secure data and
données
etconfigurations
configurations
11. Sécuriser les accès
11. Secure user access
utilisateur

12. Secure
interactions with
suppliers

Passive defense Active defense

Figure 11.4. Steps in the ICS security process. For a color

version of this figure, see www.iste.co.uk/flaus/cybersecurity.zip

– Identification:
1) inventory the facility (section 11.4);
2) assess the risk (section 11.5);
3) set up a governance system and, optionally at first, a risk
management system (section 11.6).

– Protection (with defense in depth):

4) secure organizational aspects with the definition of policy and
procedures (section 11.7);
5) secure human aspects: awareness, training, training (section 11.8);
6) secure from a physical point of view (section I.1);
7) secure the network (section 11.10);
8) secure off-network exchanges (section 11.11);
9) secure stations and equipment (section 11.12);
 Implementation of the ICS Cybersecurity Management Approach 279

10) secure data and configurations (section 11.13);

11) secure user access (section 11.14);
12) secure interactions with suppliers (section 11.15).

– Detection:
13) implement an incident detection system (section 11.16);
14) set up security monitoring (section 11.17).

– Response:

15) establish an incident handling plan and an alert chain

(section 11.18).

– Recovery:

16) implement a recovery and activity continuity plan (section 11.19).

These different steps are detailed in the following.

11.4. Inventory of assets

11.4.1. Mapping

In order to be able to assess the risks, or even simply to systematically

implement good practices, it is necessary to first make an inventory of the
various elements of the installation.

This approach was described in Chapter 10 (section 10.1).

It makes it possible to obtain a physical mapping and a logical data flow

mapping.

11.4.2. Documentation management

The description of the mapping, the technical documentation of the

installations, the architecture and geographical location diagrams and the
addressing plan provide an image of the installation. These documents can be
supplemented by user manuals, maintenance plans and operating documents.
Some may contain passwords (such as some on-call documents).
280 Cybersecurity of Industrial Systems

All these documents must be managed to be as up-to-date as possible and

also secured, as they provide sensitive information to potential attackers.

A documentation management policy (update process, retention period,

mailing list, storage, etc.) must be defined. Documentation relating to an
information system should not be kept on the system itself.

11.5. Risk assessment

The objective of this step is to assess the risk level of the installation. Risk
assessment methods are presented in Chapter 9. The question is:
– on the one hand, what the impacts of a cyber-attack may be, particularly
in terms of material damage to people or property, or on production
capacities;
– on the other hand, what is the likelihood of occurrence of the
undesirable events that caused these impacts.

This likelihood may depend on the vulnerability of the ICS, but also on
the operating security measures to protect against poor control system
behaviour.

The objective of this analysis is to identify the most critical parts of the
installation and, depending on this criticality, to decide on the different
security measures to be implemented.

A question for risk analysis is whether the installation can be broken

down into different zones a priori, which is not necessarily easy. The IEC
62443 standard proposes carrying out a preliminary global analysis to
facilitate this breakdown into zones, then to proceed to a detailed analysis of
each zone.

To perform this risk analysis, either the risk analysis methods presented in
Chapter 9 or the ANSSI class approach (Chapter 6), which allows the
criticality level to be determined in a simplified way, may be used.
 Implementation of the ICS Cybersecurity Management Approach 281

11.6. Governance and ISMS

11.6.1. Governance of the ICS and its enviroment

One of the challenges of ICS security management is that Operation

Technology (OT) security governance and Information Technology (IT)
security governance are generally managed by different managers, with
different cultures and objectives.

OT equipment is managed by the operating manager or automation

department, while IT equipment of the ICS is managed by the IT department
and, in some cases, by both parties (Figure 11.5). Often, there is doubt about
who has responsibility for the security of the ICS infrastructure, which can lead
to serious gaps in security management.

The various responsibilities and missions must therefore be analyzed and

documented. This information will be used to define roles and
responsibilities in the security policy.

Wireless network
PLC, RTU Workstations,
management, network
sensors, business
equipment, servers,
Actuators, servers, web,
printers, mobile
etc. etc.
terminals, firewall, IDS
IPS, etc.

Figure 11.5. OT/IT responsibilities

11.6.2. ISMS for ICS

The approach presented in section 11.3 describes the steps to implement an

ICS security approach. Ultimately, this approach must be part of a PDCA-type
security management system (Chapter 3). Steps 1–13, “Identification”,
“Protection” and “Incident detection” correspond to the plan and do phases. The
check phase, which consists of monitoring security, is partially addressed in step
282 Cybersecurity of Industrial Systems

14 (audit). In this phase, two types of indicators are being monitored to

determine:
– if the security measure is (correctly) implemented by the organization,
such as the deployment rate of security patches;
– if the security measure effectively reduces risk, for example, by measuring
the number of contaminated workstations or the number of users clicking on a
hacked email (preferably sent by the IT department for testing purposes).

This information makes it possible to correct the security measures

implemented at each of the steps proposed in Figure 11.4 in the act phase.

11.7. Definition of the security policy and procedures

From an organizational point of view, the first step is to define security

policies and procedures for OT-related aspects in order to complement the
company’s ISSP (Information Systems Security Policy). It must be written in,
taking into account the compliance with laws and regulations.

Policy
Why should it be done?
Who should do it?

Procedures
How and when?

Figure 11.6. Security policy and procedures

The ICS security policy can begin by describing the context and scope of
the ICS and then recall the challenges of industrial security. It then defines
the ICS security organization with the definition of roles and responsibilities,
in particular between the IT and OT world, as well as relations with external
service providers. In the case of an operator of essential service (OES), the
aspects concerning relations with the authorities must be defined.

The security policy must also address issues such as user account
management, use of removable media, remote access, mobile devices, use of
 Implementation of the ICS Cybersecurity Management Approach 283

personal terminals, antivirus management, security update management,

change management, backup and recovery procedures and incident response.
It can also deal with documentation management (update process, storage,
duration), outsourcing management and clauses to be included in contracts.

It is recommended to produce documents independent of the ISSP of IT

systems and to refer to them if necessary.

Based on the security policy, the procedures and guidelines implementing

the policy are developed. It is of course possible to rely on the
recommendations of the various guides and standards (Chapter 6). The
guidelines define the rules of use, good practices, etc. They may concern, for
example, the operating operator, the network administrator or external service
providers. Procedures describe how to perform the different tasks, for
example, how to perform the vulnerability analysis in a concrete way.

11.8. Securing human aspects

The human factor is important in risk management. Training or awareness-

raising, possibly supplemented by situational exercises or tests, must be carried
out. This training, which is still often neglected in the OT world, must be
adapted to the types of tasks and responsibilities of each individual. We will
distinguish for example:
– operating personnel;
– managers;
– personnel performing maintenance or development;
– new hires;
– external service providers;
– the visitors.

Training should ensure that staff are aware of the security policy and
procedures and implement them. The first step is to develop an awareness
program for all employees involved. This awareness must be supported by
management. It must then be followed by regular communications to remind us
of the risks and important points.

In a second step, a more targeted training program should be conducted. It

is recommended to base it on the roles for the security of ICS. Designing a
284 Cybersecurity of Industrial Systems

role-based training program begins by identifying the main roles; this

identification can be based on the list presented above (operating staff,
managers, etc.). Then, training needs are identified for each role. For
example, visitor training can focus on defining authorized and prohibited
activities on site, while development staff training can focus on configuration
management issues and the secure use of network resources. Management
training may focus on how to react when an employee reports a possible
security violation.

11.9. Physical security

Physical access to equipment is one of the potential vectors of attack. It is

possible to insert a USB key, set up a keylogger, connect directly to the
network, steal data or even equipment for reverse engineering purposes, or
simply destroy machines.

Physical security is therefore very important, as is logical access control.

The approach to be implemented, similar to the security of logical access,

consists of defining the perimeter to be protected, identifying the roles of the
various stakeholders, dividing the installation into zones and defining
accesses to the zones depending on the roles. Connection cables must also be
protected, as well as remote equipment.

Several layers of protection can be implemented, such as a fence around

the facility, and then locked doors on the ICS building, as well as additional
locked doors for the control room and equipment rooms.

Access can be authorized using different types of techniques (badge,

keys, etc.), monitored with cameras and connected to a logging system
connected to the SCADA supervision.

Access management based on roles and staff taking into account new
employees and employment termination must be provided.

The access control system must be compatible with management of

emergencies related to physical risks (e.g. fire, toxic leak). A glass breakage
type system can be used.
 Implementation of the ICS Cybersecurity Management Approach 285

11.10. Network security

Network security consists of setting up a secure architecture and then

performing perimeter monitoring (firewall or data diode). The methodology
and systems for filtering data flows are described in Chapter 10.

Access to the network is authorized according to roles and users. This

requires an access control system as described in section 11.14.

Remember that a virtual network is not a risk-free solution: the source

and destination are vulnerable; if malware is installed on the source
computer, it can infect the destination computer without even being detected,
since the flows are encrypted. This issue is addressed in Chapter 10.

11.11. Securing exchanges by removable media

A policy for the use of this type of media must be defined. At a minimum,
the software restrictions (no autostart from removable media) must be
activated.

For greater security, these media should not be used, and transfers should
be made through a dedicated and secure workstation with antivirus software.

11.12. Securing machines

11.12.1. Securing workstations and servers

The various equipment, computer workstations, network equipment,

servers, PLCs and specific equipment must be secured with measures that
reduce vulnerability such as:
– the deactivation of default accounts;
– closing open ports and using non-standard ports (for example, for SSH,
do not use port 22);
– uninstalling unused applications and services such as test tools,
debugging tools or network functions;
– the periodic installation of security patches (section 11.17.2);
– the implementation of a “whitelisting” system for applications
(authorized list).
286 Cybersecurity of Industrial Systems

A host-based intrusion detection system (HIDS, Chapter 10) can be set up

and connected to the Security Information and Event Management (SIEM).

11.12.2. Securing engineering stations

Engineering stations are special workstations. They are used for

development and to send the code to the PLCs. They therefore contain critical
information and can, because of the development environments that are
present, offer more vulnerabilities. Analysis of attacks carried out shows that
they are often a vector of attack, as this was the case for Stuxnet.

In addition to the general recommendations, it is necessary for these

workstations:
– systematically to identify and authenticate users;
– to check that the antivirus update is functional;
– to check that the OS and software are updated;
– not to connect mobile engineering workstations to networks other than
the OT network;
– to shut down the workstations when they are not in use.

Firewalls must be configured so that these workstations can be updated.

11.12.3. Securing PLCs

PLCs are particularly sensitive and vulnerable equipment. In addition to

the general measures for workstations that may apply, the basic measures to
be implemented on this equipment include:
– protection of logical access to PLCs by a password, which must not be
the default password;
– protection of physical access to the PLCs (locked cabinet) and, if
necessary, detection of opening by sending an alarm;
– the deactivation of remote configuration and/or remote programming
modes when this possibility exists;
– the configuration of read-only access for first-level maintenance
interventions, where this functionality exists;
 Implementation of the ICS Cybersecurity Management Approach 287

– protection of access to source code and embedded code in CPUs;

– disabling unnecessary services (web, for example);
– disabling unused logical ports;
– the restriction of the IP addresses that can be connected.

11.12.4. Securing IIoT equipment

In addition to measures similar to conventional computer equipment, it is

recommended to follow good practices such as those of the Industrial Internet
Consortium (IIC) (Chapter 6) (Hanna et al. 2018), including the use of
devices with a secure element (Chapter 10, section 10.7) (Hauet n.d.b).

In addition, it should be noted that new approaches based on the blockchain

are promising in terms of solutions for securing IIoT networks (Appendix 2).

11.12.5. Securing network equipment

Network equipment including routers, gateways, switches and firewalls,

industrial or not, are equipment with a computer and an operating system
inside. It is therefore necessary to monitor vulnerabilities that involve them,
update firmware and implement a password management policy for these
devices (change of default password, periodic change and according to staff
movements).

IoT gateways are special devices that provide communication between

internal networks of IoT devices and the Internet. In particular, they are
responsible for encryption. They must be configured to use TLS (Transport
Layer Security, appendix 1.10) or another type of VPN such as IPsec and to
use certificate-based authentication, both for internal and external
communication.

The Cloud platform must be configured with the appropriate controls and
supplied with the correct certificates.

11.12.6. Antivirus

Implementation of antivirus software is a basic security measure.

Remember that this is a necessary measure, but is not sufficient alone
288 Cybersecurity of Industrial Systems

because an antivirus does not necessarily detect all viruses. In addition,

antivirus software is limited to certain operating systems (Windows or Mac
OS) and does not exist for PLCs and other OT equipment.

To be effective, antivirus protection must be up to date. The update in the

OT zone must be carried out without compromising the protection provided
by the architecture and perimeter protection. Installation on all workstations
in the OT zone is therefore not necessarily to be preferred. An analysis must
be carried out to identify the stations to be equipped and those that will not be
equipped and will be made safe by a hardening of the configuration, as they
are in areas not directly connected, or are subject to particular constraints
related to operational safety (availability).

The deployment and update policy must include:

– deployment on all mobile stations, engineering stations, remote
maintenance stations and SCADA stations (if it does not have compatibility
problems);
– antivirus scanning at the firewall level;
– an automatic update of non-critical items;
– a manual update of sensitive items with a fixed frequency;
– special care for the monitoring of demilitarized zone (DMZ) area
stations (which can be attack relays);
– the deployment of an antivirus server in the DMZ area.

11.13. Data security and configuration

Data and configurations of OT equipment (programs and parameters) must be

managed specifically. It is necessary to set up a procedure to manage the integrity
of this data and compare the current running versions and those saved in the
development stations.

In addition, when a new version is put into service, it is necessary to check

that the differences between the previous version and the new version correspond
to the changes made.

Commercial configuration management software can make this task easier.

 Implementation of the ICS Cybersecurity Management Approach 289

In addition, all important data (firmware, standard software, SCADA

software packages, PLC programs, configurations, etc.) should be saved and
exchanged with an authenticity verification mechanism (signature).

11.14. Securing logical accesses

The security of logical access, based on user access control, is based on

more or less sophisticated technical means and a procedure for using these
means by defining the roles and rights of each user. The security measures to
be implemented are as follows:
– access permissions should be managed on a role-based basis,
incorporating the principle of least privilege and segregation of duties.
Depending on the areas, an analysis must determine who can access them and
who to what resources;
– identities and identifying information must be issued, managed,
verified, revoked and audited for authorized devices, users and processes;
– remote access must be managed;
– users and equipment must be authenticated with one- or two-factor
methods depending on the level of risk.

Older, or less powerful, hardware does not always have very advanced
authentication capabilities, which can be a problem. In addition, it is often
difficult to implement centralized authentication management, such as LDAP
(Lightweight Directory Access Protocol, a protocol for querying directory
services).

From a practical point of view, passwords should be chosen according to

appropriate rules to provide a good level of security, and default passwords
such as admin/admin should be changed.
290 Cybersecurity of Industrial Systems

Users Roles Rights

App
Dupond Admin installation

Network access
Engineer
Dupuis
Read/write
Operator files
SCADA
One or more roles application
Rights for
each role

Figure 11.7. Access control by role

11.15. Securing supplier and service provider interactions

In all its life phases, the security of an ICS depends heavily on a number
of external suppliers or service providers. Recent attacks as Stuxnet have
demonstrated this.

To guarantee the desired level of security, special requirements apply to

these stakeholders. These have been standardized (IEC 62443-2-4 standard)
or are given in various guides (ANSSI 2013a).

Several aspects can be identified:

– component procurement: off-the-shelf components (COTS) may
contain vulnerabilities, whether intentional, such as backdoors, or not, simply
because they are due to a software development process that does not take
security into account. To prevent this risk, it is possible to use suppliers or
products certified with CSPN (ANSSI n.d.), ISA Secure (IEC n.d.) and TUV
(TÜV Certification n.d.) certifications for example;
– outsourcing and external service providers: these providers must at least
be trained. For high-risk sites or OESs, providers must be qualified (qualified
trusted providers).
 Implementation of the ICS Cybersecurity Management Approach 291

11.16. Incident detection

11.16.1. Logging and alerts

To complement the protection measures, an incident detection system

must be implemented. Most systems (workstations, servers, network
equipment) have the ability to log different types of events. These
possibilities must be activated.

The questions that arise are the types of events to be recorded and the
storage period in order to limit the size of storage. These logs can be
centralized with a SIEM.

11.16.2. Intrusion detection system

To monitor the network and workstations, it is possible to set up an IDS.

These systems are presented in Chapter 10.

11.16.3. Centralization of events (SIEM)

To process events centrally, there are systems called SIEM, presented in

Chapter 10. These can be coupled with SCADA supervision to generate
alerts.

11.17. Security monitoring

11.17.1. Updating mapping and documentation

The system can be upgraded, especially with IIoT architectures or mobile

devices. A procedure to keep the mapping up to date, possibly supplemented
by a computer tool for detecting new equipment, should be put in place.

In parallel, the documentation (section 11.4.2) must be kept up to date.

11.17.2. Security patch management

New vulnerabilities in hardware and software are regularly discovered

and published by Computer Emergency Response Teams (CERTs)
(Chapter 5).
292 Cybersecurity of Industrial Systems

The updating of security patches must be done within the framework of a

controlled process, with the implementation of an adapted organization.
Compared to IT systems, automatic updating of software patches is not
always possible, on the one hand, because equipment does not always have
this possibility, and, on the other hand, because the risk of disrupting
production is high. The patch management policy must be adapted to the
risks and constraints. It can be adapted to different types of equipment, with,
for example:
– a systematic update of the workstations;
– a periodic update or during maintenance for PLCs.

For workstation updates, it may be preferable to use the DMZ.

The monitoring activity is based on mapping, and it will be all the more
effective if the mapping is exhaustive.

11.17.3. Audit of the facility

An audit of the installation can be carried out regularly using the

approach described in Chapter 5, and regular penetration tests during
maintenance periods can also be considered to avoid disrupting normal
operation.

11.18. Incident handling

Incidents detected by systems implemented in the previous phase should

be appropriately addressed. This is defined by the implementation of an
organization and procedures that make it possible to determine:
– what to do when an incident is detected;
– who must be alerted according to the level of importance of the
incident;
– which measures should be applied in the response phase.

The response to incidents in the ICS case must take into account the
physical aspect of the process: it is not possible to stop it in any situation and
a mechanism must be provided to bring it back to a safe situation, or to
 Implementation of the ICS Cybersecurity Management Approach 293

provide for operation in degraded mode. The answer must also take into
account the fact that the system operates in real time, and be fast enough.

In the event of an incident, responders must be trained in the specific

scenarios of the ICS, as normal methods of recovering computer systems may
not be applicable to an ICS.

An escalation management process can be defined to manage incidents at

the right level of responsibility.

The incident management process must also include a post-incident

analysis phase. This feedback allows for continuous improvement in risk
management.

11.19. Recovery

If certain feared events occur, damage may occur to the ICS and the
installation. It is therefore important to be prepared to restart the activity as
soon as possible. Two levels of damage can be considered:
– the first one concerns programs and data, and a recovery allows to
restart;
– the second concerns physical damage and, in this case, more extensive
rehabilitation is required.

11.19.1. Backup

A backup policy must be defined. It includes defining the scope of the

elements to be backed up, which includes:
– images of servers and workstations;
– configuration databases (users, alarm thresholds, etc.);
– PLC programs (sources) and data;
– the control parameters and firmware of intelligent sensors and
actuators;
– SCADA historian database;
– PLC firmware, configuration files and network equipment firmware
(switch, VPN, router, firewall, etc.).
294 Cybersecurity of Industrial Systems

In a second step, it is necessary to define the periodicity of the backup and

the storage duration. Regulatory requirements may need to be considered.

Finally, it is necessary to define the means to perform the backup, which

can be automated, but not always for some OT equipment settings. A
traceability of the modifications is therefore to be expected.

The last step is to provide for regular backup testing procedures.

11.19.2. Business continuity plan

A business continuity plan is designed to ensure the company’s survival

in the event of a disaster. It must therefore integrate industrial information
systems. It includes defining the Disaster Recovery Plan, which identifies the
means and procedures necessary to return to a nominal situation as quickly as
possible in the event of significant damage. It also describes how to rebuild
the system following a cyber-attack, fire, flood or data loss.

11.20. Cybersecurity and lifecycle

The measures presented are implemented in the operation and

maintenance phase of the installation. However, it is important to anticipate
this cybersecurity issue from the early stages in the design phase and
integration phase. A process of transfer of responsibility for cybersecurity
and useful information about it must be provided during the commissioning.
Finally, cybersecurity must also be managed during the deconstruction phase,
one of the well-known vulnerabilities being the disposal of devices
containing confidential data.