Handbook on Operational Technology and its Security

Handbook on Operational Technology and its Security

Introducing an OT/OT Security Framework

Preface

This is a handbook aimed for professionals working in the Operational Technology (OT) area and Information Technology (IT) professionals working where IT is connected to OT, as well as top level management of organizations spanning both IT and OT environments. The handbook will provide an overview of the problems and possibilities when having connected IT and OT environments, as well as provide ideas and a potential structure for how this can be organized to achieve a risk-based approach for how to also include the OT and OT security alike IT and IT/information security in a minimalistic management system for IT/information/OT security.

The reason to combine OT and OT security into a common framework is that these two are intricately intertwined due to the long lifecycles of OT assets and must be managed together for it all to work.

The handbook is based upon experiences from the Cybersäkerhetsnod Norr project and action research conducted in 4 large industrial projects. Further, the research has also been the basis for developing two academic courses at master’s degree level.

As this is a handbook, it is written so that each of the chapters can be read as freestanding ones. Thus, there may be some overlaps between the chapters. The handbook is primarily written for use within the EU or by global organizations headquartered within the EU.

The handbook has 7 parts according to below for to provide an introduction to OT/OT security prior to outlining a proposed OT/OT security framework (OTSF), which can be used to provide a structure and ideas when addressing this matter:

• Part 1 - Information technology (IT), Operational Technology (OT), the convergence of IT and OT, and Enterprise Technology (ET)

• Part 2 - International standards, frameworks, models, wireless and cellular communications technologies of interest

• Part 3 - Governance, compliance, legal and additional holistic perspectives on an OT/OT security framework (OTSF)

• Part 4 - An outline for an OTSF starting at the policy level

• Part 5 - An outline for an OTSF continuing with the standards level

• Part 6 - An outline for an OTSF ending with the user guide level

• Part 7 - Methodology for approaching an OTSF and mapping of standards for facilitating compliance checks

The handbook has been edited and authored by the following and a reference group of professionals working in the OT/OT security area has provided ideas for improvements and additions as well as ensured the quality of the handbook:

• Editor: John Lindström

• Authors: John Lindström, Jari Delin and Karl Andersson

• Reference group: Asif Iqbal, Tomas Nilsson, Michael Blom, Erik Hedlund and Mikael Jonsson

• Images: Shutterstock

Acknowledgements: The writing of the handbook was funded by the authors’ own organizations and partly supported by the European Regional Development Fund and the Cybersäkerhetsnod Norr-project (no. 20366918) and the Interreg Aurora program, Arctic 6G project, award no. 20357901.

Copyright 2025 Luleå tekniska universitet. Please feel free to borrow and freely use the handbook’s texts. However, please refer to the handbook according to: Lindström, J., Delin, J., Andersson, K., Handbook on Operational Technology and its Security: Introducing an OT/OT Security Framework, first edition, Luleå tekniska universitet, Sweden, 2025.

Improvement of handbook: If you find anything in the handbook that is incorrect or have ideas for improvements, please e-mail this to: karl.andersson@ltu.se and john.lindstrom@ltu.se

ISBN: 978-91-8048-890-7

Disclaimer: This handbook has been written for use mainly within Sweden and the European Union, and although most of the aspects discussed are of a general nature, readers should have this fact in mind while reading. The handbook’s content should not be construed as technical or legal advice on any specific facts or circumstances. The content is not exhaustive and is intended for limited general informational purposes only. The authors make no representations as to accuracy, completeness, actuality, suitability, or validity of any information and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis with no warranties, and confers no rights. Readers should consult appropriate technical, accounting or legal consultants concerning any specific question or the relevance of the subjects discussed herein to particular factual circumstances.

Part 1 – Information Technology (IT), Operational

Technology (OT), the convergence of IT and OT, and Enterprise Technology (ET)

The focus of this handbook is OT environments used in process and manufacturing organizations, as well as critical infrastructures, and concerns both the production and distribution parts of these. There are OT environments almost everywhere, such as larger buildings with ventilation, heating/cooling, electronic locks and alarms, safety systems, sprinkler systems, heart starter systems, or outside of these with alarm systems, CCTV, car heating outlets, etc. Some of these systems may not be categorized as OT systems and may not have a good fit inside of either the IT or OT environments. Most domestic houses have similar installations, but in a smaller scale. Further, a lot of infrastructure is managed by OT environments, like in railways, city traffic control systems, bridges and tunnels. In the past, most OT environments and related assets were run standalone or connected in isolated OT networks within an organization. The OT environments were not connected to the organization’s IT environment or any external public network, such as, the Internet. Due to requirements for faster response times, optimized operations, and a need to get a better overview and control of the processes executed within the OT environment, the OT environments started to get connected to the IT environment and various IT systems such as Enterprise Resource Planning (ERP) and higher-level Manufacturing Execution Systems (MES). In distributed OT environments, the islands started to get connected to the main OT network or got remote access and management capabilities. In some cases, there was not any “designated” OT networks, so they ended up in the IT network.

Of great concern, which was discovered a bit later, was that the security levels of many OT environments and their assets were inadequate. Previously, most cyber-attacks targeted the IT environments and their assets along with cloud services exposed via Internet. However, this has changed and cyberattacks or viruses targeting OT environments and assets are unfortunately getting something to expect on a frequent basis. The problem is that many OT environments were not set up and designed to have a high level of security and that there may be a lot of old assets, which were not designed to be connected or designed to resist various threats. This is about to change, but many organizations have a technical debt both in terms of legacy hardware, various software (e.g., firmware, operating systems, frameworks) and applications/systems, which are hard to secure and may need to be replaced or isolated (i.e., run in island mode). To get a better understanding of commonalities and differences between IT and OT environments and their assets, the following sub-section will highlight these on a highly generalized level. However, it is important to understand this as it is for most organizations not possible,

or feasible, to exchange all their old and insecure OT assets to modern ones due the cost to procure the new ones. Most old assets will be used until their technical lifecycle ends unless the economic lifecycle comes into a halt before that.

The Industry4.0 concept1, which was coined in Germany about 10-15 years ago, has sped up the integration of OT systems and that IT and OT environments increasingly get connected too. This is due to what is wanted is an integrated data and information flow from various IT systems to OT systems and further to get reports and feedback etc. back from the production processes to the IT systems. In addition, wanted is to also get a management overview of the processes’ execution status, process flows, output quality and volumes. The continuation of this is that more and more organizations adapting to Industry4.0 also want to integrate their data and information flows with the partners in the value-chains/networks they participate in. The vertical and horizontal integration of data and information flows require interoperability, adequate cybersecurity and IT/OT security. What to expect from the emerging Industry5.0 concept, where humans are to be more involved in the production and distribution processes, must be included in the OT and OT security contexts later as the outcomes become more evident. Due to the increasing number of advanced cyberattacks, which can disrupt production and distribution operations, impair important flows in society, plus cost a lot of money to remedy, the European Union (EU) has started to modernize its legal frameworks and statue to counter this. See more on EU compliance requirements and new and emerging legal implications on cybersecurity and OT security in Part 3.

In addition, machine learning (ML) and artificial intelligence (AI) start to make an impact in many fields and are also present in general cybersecurity, IT/information security and OT security. There will likely be tools that help to continuously improve the security level as well as many tools also used by malicious actors to find weaknesses and ways to negatively impact organizations or the services they rely on.

1.1 Commonalities and differences between IT and OT – highly generalized aspects

To get a better understanding of the opportunities and barriers related to OT environments and their often-heterogeneous collections of assets, Table 1.1 below aims to provide a highly generalized view of why the security level may not always be easy to fix and that fixing it can cost a lot of money and require a lot of effort as well.

1 Industrie 4.0 - https://www.plattform-i40.de/IP/Navigation/EN/Home/home.html

Table 1.1 – Commonalities and differences

Aspect IT

OT

Common length of asset lifecycles 2-8 years 5-50 years

Level of complexity in the environment

Level of human resources (manpower) available

Asset management control level

Cost for updates, repairs or generation changes

Common prioritization of confidentiality (C), integrity (I) and availability (A) plus more

Complex Great complexity (a lot of assets and mix of old and new generations)

Commonly a lot of IT resources

Commonly a few OT resources

Commonly good Harder to keep track of assets (and often the control level is not adequate)

Low to moderate. Updates are commonly part of the maintenance agreement

High to extremely high. Updates are often not part of the maintenance plan/agreement

CIA - Accountability - Provenance AIC - Accountability - Provenance

The most limiting factor is probably the length of the lifecycles and in many production and manufacturing processes there are a mix of old and new assets (e.g., machinery, equipment, components) as well as network topologies and communication protocols used. This mix, combined with the fact that an OT

environment often has a lot of assets, causes the complexity level to be a lot higher compared to a normal IT environment. Thus, OT environments need to be well maintained, cared for and supported by a well-working asset management system, which in turn is supported by configuration management and change management of systems and processes. Else, if needed to for instance find where all instances of Log4Shell/Log4J2 or similar, as severe vulnerabilities are discovered, it will take a lot of time and resources to execute that discovery manually.

When setting up a new factory/mill/installation, there is an opportunity to get new and modern OT assets. However, many of the offered OT assets may be old already from the start as these have not yet been modernized by the providers of such. However, the new EU directives and regulations will soon require that all new installations of IT and OT assets meet the minimum levels stipulated by the directives and regulations. Thus, many old OT assets will need to be replaced by new generations unless they can be upgraded and blocking hardware parts can be replaced with compliant ones3

1.2 How to get OT/OT security to be included in the overall management system for information security?

Currently, most management systems for IT or information security do not bring in the aspects of OT/OT security. Further, the situation is the same for healthcare contexts using Medical Technology (MT), which has many similarities with OT. The additions of an OT/OT security policy and also such an MT policy (or perhaps an MT/MT security policy) are visualized in Figure 1.1 below. The idea is to reuse as much as possible of an organization’s already existing management system for to get such a minimalistic structure as possible with no, or very little, extra overhead.

2 https://www.ibm.com/think/topics/log4j

3 Lindström, J., Kyösti, P., Psarommatis, F., Andersson, K., & Starck Enman, K. (2024). Extending Product Lifecycles —An Initial Model with New and Emerging Existential Design Aspects Required for Long and Extendable Lifecycles. Applied Sciences, 14(13), 5812.

Figure 1.1 – outline of a minimalistic structure regarding a management system for information and OT security

By bringing in the OT/OT security to the management system, that shows this is important for the organization and that organization, roles, responsibilities, authorizations, and budgets etc. are decided and allocated. As for the IT and IT/information security policies depicted in Figure 1.1, the OT/OT security policy should also be driven by risk assessments/analyses and any other significant conditions that may have impact on the OT environment and its processes being executed with a specified wanted level of availability. The higher level of availability wanted, the more conditions must support that (e.g., utility supplier and product/ service provider service level agreements), and this will cost and require continuous management and governance to work over time. As also can be seen in Figure 1.1 is that the policy level is complemented by standards and user guidelines levels, which will be further explained and outlined in Parts 4-6. These three levels, i.e., policy, standards and user guidelines, will make up the OT/OT security framework (OTSF) which is the core of this handbook. The correspondence on the IT side is to have an IT/information security framework (ISF) combining the IT and IT/information security policies with the respective standards and user guidelines. To notice is that OT has been merged with the OT security as the long lifecycles makes lifecycle management an intricate issue for both OT and OT security.

into, as smoothly as possible, the OTSF. There may also be legal directives and regulations affecting IT and OT, and that must be understood too as it may differ a bit between the IT and OT although it should be the same for an entire organization (e.g., EU NIS2, GDPR, AI Act, etc.), which is further outlined in Part 3.

To sustain a good relationship between IT and OT, planning, documentation, and sharing of information is necessary. Further, any changes which may affect important parts of an IT or OT environment as well as the “other side”, also need to be

1.3 IT and OT need to work together

The IT and OT personnel needs to work together and preferably cross-train and help out in the daily work. As can be seen in Figure 1.2, the standards used (i.e., “languages”) for to build the infrastructure and maintain these within IT and OT are most often not the same. Wanted is that the IT and OT sides jack into each other as smoothly as possible and the security level achieved is not lower than wanted to create new vulnerabilities. Thus, this requires that IT and OT work together and jointly plan for the future and manage any changes that may affect the other in a coordinated manner. Thus, to support that IT and OT work together, the ISF needs to jack

communicated and coordinated. To achieve that, joint regular planning meetings with IT and OT change coordinators and technical specialists are proposed.

Further, to get a work situation where the staff are happy and not stressed, the “normal” situation should have an approach to be proactive and prevent problems but be prepared to respond to any issues that can arise (see Figure 1.3). A work situation where there are hot issues every day and no possibility to focus on long term results and development, may lead to stressed staff and a high level of staff turnover. If that happens, it will be even harder to work on value-creating tasks as new staff needs to be trained continuously while issues pop up.

Figure 1.2 – IT and OT are not the same – yet – and must work together to be secure

Figure 1.3 – Level of preparation to achieve availability, robustness and resilience

The key to achieve a high level of availability, robustness and resilience regarding the processes executed within the OT environment – is the ability to work on the right things and focus on long term results!

1.4 Convergence of IT/OT

The term “convergence of IT/OT” divides many professionals working in IT or OT. Some professionals posit that the same type of networks, network equipment, servers/equipment and protocols will be used within both IT and OT. Others assert that there is a trend towards convergence, but the long lifecycles of OT assets and technical debt invested in will slow down this convergence a lot.

Another idea what the term means is for instance that IT and OT environments can be merged into one main IT/OT environment and just be segmented for separation, perhaps using micro segmentation tools. This may work for some instances,

e.g., where the flows are slow, and the number/volume of output is low. How this would work for critical production and distribution processes with dependencies for real-time data exchange, having great process speed and throughput volumes, thus requiring network performance and stability – is to be tested and verified.

Thus, there are some slow indications of either of the above views of the IT/IT convergence, but more proof and verifications are required prior to that any of the views (or even both) can be widely accepted. Further, there is a footnote in Part 4, as part of potential definitions, which embraces the idea of the IT and OT environments merging into one.

1.5 Assets that not clearly are IT or OT – Enterprise Technology (ET)

There are several IoT and OT systems that do not fit into the connected OT environment of a process or manufacturing organization or a critical infrastructure. This is due to that these systems may be old and unsecure, lack connectivity, or just should not be connected to an OT environment for other reasons such as there is no logical need to connect exposed and vulnerable assets. Examples of such systems are quality system, maintenance systems, greasing/lubrication systems, ventilation/heating systems, safety systems, heart starter systems, sprinkler systems, alarm systems, CCTV, passage/lock systems, etc. In this handbook, these systems will be denoted as Enterprise Technology (ET) systems. An example of desired separation from the IT and OT environments can be viewed in Figure 1.4. Any wired connections to Internet should be made via Level 5 and its external DMZ. The IT and OT environments are modelled á la the Purdue model, which can be read more about in Part 2.

The concept of ET systems is to make sure that all systems have management. ET systems are preferably placed at Level 3.5 (Industrial DMZ). They can be isolated or be a member of a ”function-group”, depending on the system’s size. An example of functional grouping can be viewed below (see Figure 1.4 to the right in the enlarged ET “environment”) with the different groups ET1-4:

• Safety, people or equipment (ET1)

• Quality, usually quality verifying systems (ET2)

• Maintenance, various condition-monitoring systems (ET3)

• Common, cameras, link servers etc. (ET4)

To further consider is that IT, OT and ET systems can be “active” or “passive”. Active means that it has an active role in the production process. A passive one means that it for instance collects data but does not play an active part in the production process. However, passive ones may be very important for the overall production process and other processes and systems. By understanding if a system is active or passive, it makes it easier to assign ownership and responsibility to the right roles

The “higher” up a system is, the more security there needs to be. Since the system managers can reside in either IT or OT, it is usually more convenient that IT manages the Industrial DMZ (level 3.5) as in the example in Figures 1.4 and 1.5. A rule of thumb is that OT systems should terminate their data connections at level 3. If more security is needed, the ET-levels can be split into two parts, see Figure 1.4 and the secure (ETxa) and restricted (ETxb) parts. The difference is that ETxa only has connections to OnPrem-systems while ETxb can have cloud connections. Further, if deemed necessary in the OT part, a level 1.5 with an extra “control level DMZ” can be set up as an additional protective layer.

Further, it is advisable to only connect what must be connected and is needed in or to the OT environment, as anything else will just increase the risk level and potentially slow down the network’s performance. If the ET systems need to be connected to the network, this should preferably be made within the Industrial DMZ, to keep a clear separation and to minimize risks, using physical and logical network segments having strict control that only authorized and wanted network traffic can flow in and out of the ET segments. If necessary, oneway network traffic can be enforced by using a network data diode solution. In addition, some ET segments can be run in island mode, i.e., separated and not connected to any internal network, if they have a mobile connection to send out data for analytics concerning maintenance/optimization purposes.

Figure 1.5 – Example of secure communications design for OT/IT data exchange (including and extra level 1.5 control level DMZ)

Figure 1.4 – Example of connected IT and OT environments and an additional ET environment connected via the Industrial DMZ

1.5.1 Categorization and classification and design considerations for communications to and from ET systems

As ET systems can be a risk for both the IT and OT environments, the ET systems should be classified, user account management strictly enforced, and the communications to and from them should be securely designed. IT terminates at level 3.5, while OT terminates at level 3. (I.e., OT is responsible for leaving the correct data at level 3.) Like for any OT connections, use of unique connection accounts should be enforced. Further, any remote access (to connect from distance) or external connections (to send out or bring in data to/from the outside world) should be considered a high risk and any ET system involved be secured adequately. All connections in/out of a segment should be considered as exceptions and be documented as such. All external connections involving high-risk ET systems should be reviewed at least annually.

To be able to configure ET systems right, their criticality needs to be categorized and classified. Below are some basic considerations (see Figure 1.6) which can later be used to calculate an “ET Score”:

• Do the sensors send data to Level 5? (No/Yes)

• Is the Data company sensitive? (No/Yes)

• What is the origin of signal? (Internal/External)

• Where is the data processed? (Internally/Externally)

• Sensor-level (DMZ)? (Level 3/2/1/0)

• In case of malfunction/manipulation, is there a direct impact on production? (No/Yes)

• In case of malfunction/manipulation, is there an indirect impact on production? (No/Yes)

• How much impact on production would a manipulated value yield? (Low (1) to High (5))

• How is external data presented? (Externally/Internally)

• Is processed data sent above redline (see Figure 1.5)? (No/Yes)

• Is processed data, (above redline), sent back or inserted into DCS or corresponding? (No/Yes)

In order to get “points” you can assign “No & Internally =0”, “Yes & Externally =10”. The idea is to weigh the different answers according to your specific standards, giving you a hint of how much security you need to apply.

Further, decide upon which ET object category the systems pertain to:

• Safety – Fire alarm, Entrance, surveillance.

• Quality – Laboratory, calibration (can also in rare cases include for instance web inspection systems (WIS)), basically everything that verifies the quality of the product

• Maintenance – Condition monitoring/analysing (lubrication, vibration, AMS etc.)

• Common (local and centralized) – Other, like link servers, asset monitoring, etc.

Additionally, put the systems into an ET Application category:

• Category A – Restricted networks, restricted users.

• Category B – Restricted user

• Category C – Common users

Finally, provide an ET Computer Class for the systems:

• Class 1 – Specified user, unique admins

• Class 2 – Common users, unique admins

• Class 3 – Common users, domain admins

As the above are summarized and assessed, make an object classification and DMZ level determination. ET systems are categorized after function and usage, and a risk assessment decision needs to be made for each ET system regarding if it shall be isolated network wise or function wise. A system can be “standalone” with only local users or partly integrated in IT-domain. (No OT domain accounts should be allowed at this level.) Here, systems/functions can be categorized according to process impact and data integrity according to below:

• Object Category - Security, Quality, Maintenance or Common

• Object Type - What does the system “do”?

• Computer Class - What type of users, admins, function-accounts etc.

• Connections - External/Internal, termination points

Figure

Together with a questionnaire, which can be made in EXCEL or similar spread sheet (see Figure 1.7a and 1.7b), an “ETscore” can be calculated for each ET system and provide guidance on required protection level for the system (e.g., isolation, redundancy, SLA, backup retention etc.). The formula used can be based upon how many ET asset components (see basic considerations bullet list) that are used, where they

are (level) and any communications need. Different answer options will provide a part score, which each can be weighed, and then summed up. The ET score can for instance be from low (0) to high (100), and the higher the score is the more protection and barriers etc. are required (e.g., use of separate networks, separate user accounts, etc.).

Figure 1.7a – Example of ET-score calculation sheet

This also requires that there is something like a:

• Responsible, Accountable, Consulted, and Informed (RACI) service level agreement (SLA), or

• Responsibility Assignment Matrix (RAM), or

• Linear Responsibility Chart (LRC) or similar to ensure that everyone knows who does what and why concerning the ET systems. From this it is possible to outline various ET system configurations.

Further, regarding system maintenance, every ET system must have (see Parts 4 and 5):

• A system owner,

• A system responsible,

• A data responsible, and

• A maintenance plan to avoid having ET systems without ownership and long-term management and maintenance.

1.5.2 An example regarding a cloud monitoring system which gathers data from Level 1 with termination points

Below is an example of how monitoring can be set up for ET systems (but of course also for OT systems) at level 1 and upwards. In Figure 1.8, the monitoring and set up are according to:

Figure 1.7b – Continued example of ET-score calculation sheet

• Level 1 data is sent/gathered to level 2 with a proprietary protocol

• Level 2 data is placed in level 3

• Level 3 transfers data to level 3.5

• Level 3.5 (restricted) connects to the assigned/decided cloud service

This gives, all in all, 8 termination points. Proposed best practice is to have different methods for getting data in and out of a zone. Remember that there are all kinds of proxy server

solutions available to use, such as: web/HTTP, file transfer with intermediary storage, gateways, etc. A rule of thumb is to keep the proxy “in house”!

This way, a user can retrieve the data using a web browser at levels 4 or 5 (as data should not be available at levels 1 and 2). If the returning data needs to be available in levels 1 or 2, one must create a new, similar, path so that the level below can retrieve data from the higher levels. Connections shall always be initiated from the bottom up.

Figure 1.8 – Example with termination points and set ups for ET systems

Part 2 – International standards, frameworks, models, wireless and cellular communications technologies of interest

Part 2 comprises a summary and writeup of useful standards, frameworks, and models related to OT/OT security, such as IEC 62443 (ISA 99), NIST SP 800-82, ISO 27019, ISO 27017/18, ISO 42001, ISA-95, Purdue-model, etc. Further, there is an overview of wireless and cellular communications technologies which can be used, if adequately segmented and secured, as part of OT environments or as external environments that are connected via external connections set up (see Part 5 and section 5.5.2.3).

Although using one or more security-related standards, that does not necessarily make your OT environment “cybersecure”. There are some questions to critically reflect upon for to understand how to become cybersecure:

• What is in the standards used?

• What is not in the standards?

• Are you “secured” if you follow a standard? If not, what in addition do you need to do?

• What do you need to do to become cybersecure now and over time?

• IT and OT are often connected – what does that imply concerning “cybersecurity” and the use of standards, frameworks and models etc.?

2.1 International standards of interest

There are quite a few international standards of interest concerning OT security and how to connect IT and OT environments (see section 2.2 for more on frameworks and models of interest). Some existing and well-established standards to read and consider are:

• The IEC 624434 (ISA-99) regarding security for industrial automation and control systems. This is a suite with four layers/levels: (1) general, (2) policies and procedures, (3) system, and (4) component. The suite provides useful guidance when considering making an OTSF as well as for providers of OT or IoT systems (i.e., IEC 62443 parts 3-3, 4-1 and 4.2). Commonly the suite is used for land-based operations but there are also adaptions of the 3-3 and 4-1, with extensions, to use for the maritime sector (e.g., IACS UR E275 and the sets of requirements from DNV and Lloyd’s Register applies to suppliers of OT and IoT systems whereas the IACS UR E26 applies to ship builders)

• The USA provides OT security guidance to its public organizations and the NIST SP 800-82r3 publication6 is one of these guidelines provided by the NIST organization. In brief, it discusses an approach for how to separate IT from OT (separation and segmentation) and improve the OT security through developing an OT security program, OT risk management, OT cybersecurity architecture, and applying the overarching NIST Cybersecurity Framework7 (CSF) also to OT

• Concerning the energy utility industry, there is the ISO 27019 standard which provides advice/requirements on information security controls related to production and distribution. The standard is based upon the ISO 27001/27002 and can be useful for organizations operating within the energy utility sector

• As more and more cloud services are used by OT systems to send data for analytics, cloud security standards are of interest too, e.g., ISO 27017/18. Consider how to keep data integrity and confidentiality from point to point!

• Regarding the emerging use of Artificial Intelligence (AI) and Machine Learning (ML), most organizations will likely use these within both the IT and OT environments in the future. There are some advice/requirements available in the new ISO 420018 standard for how to set up a management system for AI alike the 27001 for information security

There are quite a few standards and guidance available which can be used while crafting and maintaining an OTSF. Within EU, most countries have national organizations9 and the ENISA10 providing several guidelines and advice for OT and IoT security. One of the most recent ones from ENISA is the technical implementation guidance for NIS211

2.2 Frameworks and models of interest for industrial control systems integration

The original ISA-9512 and Purdue13 models (see adaptations in Figure 2.1) are almost the same and the number of levels used can vary. The ISA-99, which also is referred to as IEC-62443, can be found in section 2.1. Commonly, OT spans levels 0-2 or 0-3 and IT spans levels 3, 4, 3-4 or 4-5. Thus, two levels can be collapsed into one both within the IT and OT if wanted. These levels will later be referred to in Part 4. The main differences between the two models are the industrial demilitarized zone and suggested segmentations in the industrial security zone(s) in the Purdue model.

4 https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards

5 https://iacs.org.uk/news/iacs-ur-e26-and-e27-press-release

6 https://csrc.nist.gov/pubs/sp/800/82/r3/final

7 https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

8 https://www.iso.org/standard/81230.html

9 https://www.msb.se/en/

10 https://enisa.europa.eu/

11 https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance

12 https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard

13 Developed by the Purdue University in the 1990s

The Figure 2.1 provides a model for how to structure functionality and OT systems. However, in reality, the OT environment should be much more structured with functionality and security levels (depending on data/ information, asset type and status, criticality, availability, exposure, etc.) in mind to avoid that a single breach or problem can take out a whole level or process. For a start, one idea is to analyse and separate the main processes (refer to the “s” in the Purdue model’s industrial security zones) from each other and map out which OT systems and supporting systems that are required for these to operate (e.g., essential network services such as AD, domain controllers/DHCP, NTP, data custodians/historians, etc.). Each main process should preferably be segmented into an own physical and logical network segment using (preferably also using both physical and logical) sub-segments/zones to divide it up further according to functionality and security levels. If the process is critical and requires a very high level of availability and resilience, all essential network services should be available within that segment (i.e., redundant network services). This may not always be easy but is doable also for an AD! Further, if Internet connections are required that must be catered for as well in a secure and controlled manner. In addition, recommended is to separate layers of a process’ OT systems using firewalls or advanced/managed switches etc. to only allow wanted and authorized network traffic flow up, down and sideways within a process. If the main processes need to communicate, that is preferably made via designated in/out communications points of the process. If there is a need to “shortcut” the communications due to extreme need for speed, such communications in between lower levels of processes (i.e., residing in different segments) should be controlled by designated firewalls. Common resources or services, needed by more than one process, may be placed where it makes most sense, such as in an OT data centre or within the Industrial DMZ. These should of course also be secured and grouped to ensure availability and other aspects of importance. See Figure 2.2 for additional ideas for practical implementation of the ISA-95 and Purdue-model. If there is a need to send data out from or into a segment, ensure to use standardized methods to do it (see later section 5.5.2.3).

Figure 2.2 – Practical segmentation and network architecture based on functionality and security levels using a process perspective and communications to other processes etc. via a designated in/out communications point

In Figure 2.2, the network equipment and communications routes should be double or triple depending on availability and resilience requirements. However, the figure is simplified to highlight the use of sub-segmentation and zones. The red parts at the bottom of Figure 2.2 indicates the movement of physical input/output and the production/manufacturing refinement progress via three process steps.

The traditional ISA-95 model with a pyramid often requires specific (hard coded) integrations between the systems and layers, unless Application Programming Interfaces (APIs), message brokers, or data custodians/storages, are used to bridge the integration gaps. Such integrations may impair the flexibility and changeability of the pyramid and may also require extensive testing after changes. To improve agility, shorten development and change cycles, enhance cybersecuri-

Figure 2.1 – Original ISA-95 and adapted Purdue models and their levels

ty functionality and baseline level, etc., the concept of Service Oriented Architecture (SOA) can be used and various OT and IoT systems can be built comprising several micro-services instead of having all code in a joint structure. Further, there is a new RAMI4.0 architecture14 which is aimed at replacing the old ISA-95 ideas. Further, there are competent platforms to use for building new, as well as replacing old, OT and IoT systems in a much more efficient manner with considerably lower total cost throughout such systems’ lifecycles The savings of effort and cost are related to using a common platform15 (an example is the Eclipse Arrowhead framework16 using a secure local cloud approach) to build systems upon, as there are already a lot of existing functionality to use as well as that the platform can be extended and then used by all systems built on top of it. Therefore, it is not necessary to extend each of the systems with all new functionality and test each of these systems rigorously as the platform itself can firstly be tested prior to being used for system development and updates.

2.3 Wireless and cellular communications technologies of interest

The use of wireless and cellular communications will likely increase as these technologies evolve with improved security level, bandwidth, robustness, and lower latency. The use of wireless communications technologies within OT environments has several advantages such as:

• Less cabling and cost related to this over time. This may be attractive for various sensors used for measurements. If to use it also for actuation or control purposes, the spectrum needs to be stable and the technology used have low, or within the needed requirement, latency regarding the communications

• Additional flexibility to move around and changes assets which are not stationary (or attached to the floor or foundations)

• Less problems in case of fires etc. where cables can burn off

However, there are some problems to take into consideration as wireless and cellular communications depends on that the electromagnetic spectrum is not disturbed too much as that may hinder different frequencies to propagate adequately:

• Solar storms or other types of increased activity in space (cosmic radiation)

• Melting of metals

• Fast spinning/turning equipment or machines

• Malicious activity with intentional disturbance or the electromagnetic spectrum (e.g., frequency jammers or electromagnetic pulses generated)

• Power cables with high voltage and current levels (i.e., magnetic field strength)

14 https://www.isa.org/intech-home/2019/march-april/features/rami-4-0-reference-architectural-model-for-industr

15 Kyösti, P., & Lindström, J. (2022). SOA-Based Platform Use in Development and Operation of Automation Solutions: Challenges, Opportunities, and Supporting Pillars towards Emerging Trends. Applied Sciences, 12(3), 1074.

16 https://www.eclipse.org/community/eclipse_newsletter/2020/july/1.php#:~:text=The%20Eclipse%20Arrowhead%20project%20 was%20created%20to%20provide,of%20the%20Arrowhead%20Tools%20European%20research%20project%20

When planning to use wireless or cellular communications technologies within an OT environment, the needs must be thoroughly investigated together with the surrounding context and potentially make measurements or tests that it will work without significant problems. There also should be a process for verifying the signals’ authenticity.

If users or asset communications are traversing wireless or cellular network segments, it is necessary to apply a high level of security preferably based upon the zero-trust concept, which is expected to evolve and be increasingly used in Wi-Fi, LoRa and 5/6G settings. Recommended is to use adequate: identification (for users, processes, systems and devices, etc.), strong authentication (2- or multi factor), high grade encryption keys and algorithms (preferably quantum computing compliant), protected exchange of keys and certificates (preferably quantum computing compliant), as well as having an intelligent zero-trust stack to manage access and authorizations. Such a stack may comprise intelligent policy engines, policy update functions, policy administrators and policy enforcement points, etc. according to novel research findings17 Further, network monitoring, logging, log analysis, and continuous diagnostics and mitigation will be needed here alike in normal OT environment settings.

If using wireless or cellular communications technologies, it is most important that the security level is intact if allowed to connect or communicate to other parts of an OT environment and its other network segments Commonly, if having wireless communication, using Wi-Fi or similar, within an OT segment it should not be possible to connect or communicate to other network segments unless the security level is at par or better within the wireless part. Further, some providers of private 5G and potentially later 6G networks usually also offers Wi-Fi as part of the solution. Recommended is to use another solution for Wi-Fi to be able to keep control of the security level and how the network segments and routing actually are made. In addition, recommended is to segment off, i.e., isolate, parts of OT networks if there must be use of 4G/5G- and later 6G SIM-cards within equipment or solutions for to communicate directly to the outside world. This practise is not recommended, unless there are no wired options and this is necessary, and it is further brought up in the OT security principles (i.e., standard for OT architecture) in Part 6 where recommendations for responsible/secure usage of wireless and cellular communications are further outlined.

If there is a strong need for users with administrative privileges to use Wi-Fi or 5G/6G private networks within an OT environment and access other network segments, high grade security should be applied combined with zero-trust methodology. Additionally, if there are production or distribution process-related communications, which is needed and authorized, from a wireless or cellular OT segment to another network segment, this may be allowed if adequate security level and zero-trust methodology are applied. To remember is that this may cause vulnerabilities over time unless the updating and patching of networks, network equipment, and the assets used within the process are not timely and accurate.

Use wireless and cellular communications technologies within OT environments with due care and only if you know that such networks and network segments are secure

enough to be connected. Else, use isolated networks or network segments and just allow data to be exchanged as if the data came from any outside/external party.

2.3.1 UWB and Bluetooth

Ultra-wideband (UWB) technology may be used for communications between assets, such as, moving machines/vehicles, where there is a need for very accurate positioning (as UWB commonly has positioning error of only a few cm) and is applicable to use in contexts with unmanned/autonomous or remotely controlled machines/vehicles.

Bluetooth is often used by service engineers, operators or administrators of OT systems which lack a human machine interface (HMI) to from a close distance connect to OT systems without the need to plug in an HMI or connect via a cable from a laptop or similar. The Bluetooth should not be activated in OT systems unless it is used/active and should therefore be disabled as a default state. If OT systems are hardened, any UWB, Bluetooth and any Wi-Fi access point are commonly disabled or removed as the normal mode of operations.

The expected ranges of UWB and Bluetooth communications are short (up to 20-30 meters) with quite high bandwidth. It is necessary to keep up with developments of UWB and Bluetooth standards, improved cybersecurity levels, and keep any OT or IoT systems using these updated accordingly for to ensure that such networks are adequately secure. Unfortunately, older OT and IoT systems using for instance Bluetooth may lack adequate cybersecurity level due to not having been updated for a long time. Therefore, these systems may need to be isolated (i.e., island mode) due to poor general security level or that the Bluetooth is too unsecure to use if connected to the OT network. Further, having old versions of Bluetooth may impair the possibilities to connect using recent devices or laptops, as the protocol’s backward compatibility is usually only a few versions.

2.3.2 Wi-Fi

Wi-Fi technologies have improved, in terms of robustness, range and bandwidth, during the last decades and is used sparsely within OT environments. It can be a good idea to have wireless network segments (or sub-segments/zones) if the production processes are dynamic/changeable and there is a need to shuffle around non-stationary production equipment and where cabling is very difficult to achieve.

An important rule is that there should never be any open or guest Wi-Fi networks in the OT environment and absolutely no internet! There should only be secure Wi-Fi networks (i.e., encrypted, hidden, having strong authentication mechanisms, and strong keys/certificates used) with identified and authenticated users, processes or devices. If having OT administrator Wi-Fi segments, the access control, authorization and overall security level must be high if connecting to other network segments and assets therein. Remote access solutions should always be used by administrators when connecting to OT assets unless sitting “on the console”. The range of Wi-Fi access points reach is quite short, up to 150 m with high bandwidth, depending on obstacles and frequency used. There are extenders/boosters (special antennas)

17 N. Nahar, K. Andersson, O. Schelén and S. Saguna, A Survey on Zero Trust Architecture: Applications and Challenges of 6G Networks, in IEEE Access, vol. 12, pp. 94753-94764, 2024.

which can add some extra range and the recent n version with MIMO support and ac/ax/be/bn versions of the IEEE 802.11 standard have really improved robustness, range and bandwidth of Wi-Fi.

If using Wi-Fi networks within the OT environment, it is necessary to keep up with developments of Wi-Fi standards and continuously improve the cybersecurity level, and ensure to not use Wi-Fi networks with low level of cybersecurity (which unfortunately may be a problem if the OT assets connected are old and not have recent Wi-Fi security capabilities).

Some providers of private 5G, and later also potentially 6G, cellular networks also offer an add-on with Wi-Fi networks as part of the solution. It is recommended that this add-on is not used and that the organization sets up Wi-Fi networks using access points etc. from other vendors and keep the network segments separated in case that either the private cellular network segment is hacked or have problems - or the same happens to the Wi-Fi network segment. This provides separation and also another layer of security if using both wireless and cellular communications technologies. The use of Wi-Fi for signal transmission must always be risk assessed (and compared to a wired solution) since the signal traverses through different layers of equipment. In addition, one must also bear in mind how to verify the communications’ integrity (e.g., that a value received is a product of the signal etc. measured).

2.3.3 Long Range (LoRa)

Long Range (LoRA) is a wireless communications technology suitable for transfer of smaller amounts of data over long distances in an energy efficient manner. LoRaWANs is the communications protocol used, but the term LoRa is used to denote it all.

The LoRa range is long, up to hundreds of km (if using relay techniques) depending on the frequency and bandwidth (data rate). The higher bandwidth the shorter range. However, the practical use is commonly within one to a few km.

LoRa networks and the sensors etc. using it are vulnerable if residing outside of protected areas or perimeters and physically accessible to anyone. The security related to LoRa networks needs to be high and these networks should preferably not be attached to an OT network but have a controlled data transfer in if that is needed.

LoRA networks are often used to collect data from sensors or systems, at a distance, that are distributed and there are no wired networks available. If there is a need to use LoRa networks for actuation or control purposes, the cybersecurity and physical protection levels need to be high concerning the communications and the OT or IoT system at the end point

2.3.4 Cellular communications with 4G/5G/6G and edge services

Since long ago, cellular communications technologies have been used within OT environments to connect distributed/ remote locations with installations such as: pump stations for clean water and wastewater, electric grid infrastructure, roads, railways, bridges, and sensors etc. As the first and second generations (1/2G) generations of cellular networks were slowly replaced with 3/4G, the range was impaired and remote/rural locations were no longer able to connect and had to find new ways for communications. The 1G networks were analogue and had better coverage and range compared to the following digital 2/3/4G networks. The rapid expansion of Internet and optical fibre installations have provided new opportunities to connect even remote/rural installations, and when building up

new installations, such as wind power parks, solar panel parks, or hydro power stations, the optical fibres are commonly installed at the same time as the power cables are dug down into the ground. The same goes for when building new railways. Further, 3G is on its way out and 4/5G SIM-cards are used in some OT equipment and IoT systems to provide connectivity, in particular for getting data out from sensors (measurements to be able to analyse operations, status of machinery/system, and possibilities for optimizations) and operations (availability/ stops, function, output, problems/status, maintenance need, etc.). However, if using SIM-cards, these systems should not be connected within an OT environment/network but have adequate ways to exchange data/information via APIs or message brokers etc. Thus, these systems having SIM-cards should be isolated (island mode), and connections to these systems from the outside, such as for administrative purposes, software or configuration updates, should have high grade security-level unless made on location (without remote access). Operators of cellular networks may provide private access point names (APNs), which can be used to improve the security level of the connections to distributed or remote installations lacking wired connectivity.

Secure IoT or OT gateways, having a mix of firewall/ router/protocol translator/intermediate data storage capabilities, are often used to segment off IoT or OT solutions from the OT network complementing the OT network’s firewalls. Further, these gateways can often also be equipped with SIMcards to communicate with for instance cloud services for data collection and analytic purposes as well as administrative and software update purposes. If a gateway is equipped with a SIM-card, it is recommended that it is not attached to an OT network as that may provide vulnerabilities (but should be run in island mode). If the data extracted via the gateway is needed to be fed back into the processes, the set up should be designed differently unless it is acceptable to get the data back via an external connection (see standards in section 5.5.2.3) and timeliness is not critical.

It is anticipated that both public and private 5/6G networks will increasingly be used in OT contexts due to flexibility, cost and improved latency if the cybersecurity level can be

kept high applying zero-trust methods and technologies. The private networks can be used for local/site purposes while the public networks used for connecting distributed/remote locations/installations if there is no Internet or other wired networks available. Any private network should be segmented and connected to the OT environment with care and only if you know what you are doing to not cause vulnerabilities in the OT environment. To connect, using public networks, should be made as with any other external connections and remote access using the standards for such (see section 5.5.2.3).

Further, it is anticipated that edge services, residing in the cellular networks, also will be increasingly used to speed up response times and reduce the amount of data (i.e., via pre-processing) that is stored and later further processed in the cloud services or data centers. Figure 2.3 outlines how public and private cellular networks, with edge services, can be combined with wired/fiber networks to connect most of what for instance a critical infrastructure provider needs in terms of connecting administrative processes with local and distributed production and distribution processes.

See for instance additional reading18 on how to address zero-trust in a future 6G context. Hopefully, the range of 6G communications will not depend on the physical coverage of the base stations on the ground but be able to also use satellites to increase the range and maybe get even better than the 1G’s coverage and range were.

The development of physical SIM-cards into eSIM-cards will increase the flexibility of management and decrease the need for manual visits to change SIM-cards. The advantages of eSIM-cards are that it is possible to switch operator without the need to switch the SIM-card, which will save a lot of time and also reduce the need for travelling to remote/distributed installations etc. Another option to consider, if having a private 5G or later 6G network is to start your own operator and make agreements with a number of operators, allowing automatic operator switching, to enable increased coverage and redundancy (as the coverage usually varies per mobile operator – in particularly outside of larger cities and in rural areas).

Figure 2.3 – Connecting administrative processes with production and distribution processes using various wired/fibre networks combined with 5/6G private and public cellular networks

18 Nahar, N.,

A Survey on Zero Trust Architecture: Applications and Challenges of 6G Networks. IEEE Access, 12, 94753–94764.

Andersson, K., Schelén, O., & Saguna, S. (2024).

Part 3 – Governance, compliance, legal and additional holistic perspectives on an OT/OT security framework (OTSF)

3.1 Governance of OTSF

Governance, which in this context means to oversee and manage, can be seen as a tool for a management team of an organization to keep on top of the most pressing issues in a number of relevant areas. Regarding the OTSF, there will always be a number of issues and opportunities to deal with, and from a management perspective it is important to know what the most import 10-20 issues are to be able to follow up on these. Thus, an idea is that the roles involved in developing and maintaining the OTSF compile such a OTSF governance list or table and keep it updated in terms of outstanding issues and the status of mitigating/solving these and provide this as input to management meetings and the CISO.

3.2

Compliance and legal requirements

Compliance to rules is important for any organization as it develops and grows. Else, there is a risk that unnecessary problems arise and that the focus ends up on the wrong matters. Regarding the rules, there are for instance mandatory, formal and informal ones. The mandatory ones commonly pertain to legal directives and regulations, and these should

be transformed into formal rules for the organization which also comprise what is important for the organization in terms of rules, the standards an organization has decided to comply or certify to, or business practices and moral/ethics accepted if being part of trade organizations or associations. Thus, the formal rules can comprise written organizational policies and standards decided upon complemented by the unwritten rules and standards of an organization’s culture. Thus, compliance may include both mandatory, formal and informal elements to follow up on as these change and develop. It is up to an organization to decide how to follow up on compliance and what to check up, and due to the total burden of compliance it is most likely not possible to follow up on it all each time due to the time and effort that would require. Therefore, a selection of important elements can be followed up each year and some of these may need to be followed up every time if being very important for the organization. Others, of lesser importance, can be exchanged for new ones on every occasion if these were passed on the last time.

Within EU, there are several new and emerging legal frameworks coming into effect. The reason for modernizing

many of the EU directives and regulations is that the accumulated cost of cyberattacks for the EU territory is very high and that EU wants an improved stability or robustness to withstand any issues, man-made or natural, in the strive towards a resilient Europe. Below are some examples of EU directives and regulations which may have impact on organizations having IT and OT environments as well as the suppliers of IoT or OT systems or other types of assets used in OT environments:

• EU Network and Information Security Directive 2 (NIS2) – cybersecurity in networks and information systems

• EU General Data Protection Regulation (GDPR) and Schrems II – protection of personal data

• EU AI Act – responsible use of AI

• EU CER – resilience of critical entities/infrastructures

• EU Cyber Resilience Act (CRA) – cybersecurity of digital/connected products and services

• EU Cybersecurity Act (CSA) – cybersecurity certification framework for products, services and processes

• EU Radio Equipment Directive (RED) – cybersecurity for wirelessly/radio connected products, part of the CE-mark within EU

• EU Data Act – ensuring customer/user access to data in systems and services

• EU Machinery Regulation – health and safety for the design and construction of machinery including some cybersecurity

• EU Digital Service Act – to prevent illegal content and disinformation as well as to achieve transparent advertising

• EU Digital Markets Act (DMA) – to make markets in digital sector fairer and contestable in particular if operating large web portals or digital eco-systems

In addition, the Digital Product Passports (DPP) initiative, part of EU’s Ecodesign for Sustainable Products Regulation, may also have an impact on the providers of IT/OT/IoT systems and provide information where software updates and hardware spare parts can be found etc., which can help facilitate customers’/users’ long-term operational and availability objectives.

Concerning organizations and providers of OT systems and equipment outside of the EU, any additional laws and regulations pertaining to the territories active within need to be complied too as well. Thus, there may be quite a large investigation of legal and regulatory compliance needed for organizations with a global presence. Figure 3.1 outlines a highly generalized and simplified view on which EU directives and regulations apply to different types of organizations.

Figure 3.1 – Generalized and simplified view of applicability of some EU directives and regulations

The above should be complemented with any national laws of applicability, selected or mandatory industry standards (see Part 2), and any informal rules as part of the compliance activities. Further, several of the compliance requirements may also affect how an OT environment is set up and integrated into an IT environment and the outside world. Concerning providers of OT assets, the compliance requirements may, combined with best practices, as well as functional and context specific requirements, need to be part of the requirement engineering and analysis for OT assets offered to the market. Figure 3.2 provides an idea for how to assess and analyze the compliance to EU directives and regulations combined with national laws, standards, and informal rules etc. of applicability. Each element with rules firstly needs to be assessed and analyzed, and will form a set of compliance requirements – which can be seen as each of the colored ellipses in Figure 3.2. It is most likely that many of the elements overlap, to a large or small extent, and this is visualized as the inner circle, followed by significant overlaps in the middle circle, and smaller overlaps (if any) in the outer circle.

what additional security requirements international standards and frameworks may add to the legal ones. Concerning providers of OT assets and IoT products/services used within OT environments, the above legal developments will pose a significant number of regulatory requirements to adhere to or there is a risk that the new sales will be stopped due to non-compliance. The concept of privacy by design is extended with the security/secure by design and design by default, thus now moving a lot of security responsibility to the provider from the customer side .

3.3 Additional holistic perspectives

It is important to plan ahead and keep track of potential future developments, in particular, regarding development of legal frameworks, industrial standards and hostile cybersecurity activities. Further, to also track and plan for are an organization’s technology debt and what the providers’ plans for procured OT assets are as well as these assets’ current and foreseen security level. Land-based OT security lags a bit behind maritime OT security, which has clear requirements on a need for classification of vessels, crafts or platforms, also having some industrial standards mapping out 4 levels of security depending on criticality, potential damage that can be inflicted by a cyberattack, and sector/industry type. Most of the maritime industrial standards originates from common United Nation decisions and have a basis in the IEC 62443 3-3/4-1 standard complemented with the International Association of Classification Societies Unified Requirements E26 for ship builders and E27 for providers of on-board systems and equipment (i.e., IoT and OT systems, etc.).

Suggested is to start planning of actions to remedy with the inner circle and move outwards when completed, unless there are ellipses which must be catered for within hard deadlines due to expected enforcement leading to for instance stop of new sales for providers of OT assets.

Further, being part of value-chains/networks with critical infrastructures or critical services for society, may cause that an organization must comply to more of the directives and regulations than anticipated at first sight. Thus, this requires a thorough analysis to understand which legal requirements apply to the organization. Further, Part 2 looks further into

Thus, land-based organizations with IT and OT environments can study the maritime OT security as it is not farfetched that this level of security is needed ashore as well!

In addition, there are industries which have very high requirements for cybersecurity and OT-related security, such as space, aviation, nuclear power plants, telecom, etc., but we will not bring in these perspectives here as their requirements are higher and not always applicable for the context of this handbook.

One way of having a structured way of working, i.e., operational processes, is to take the major parts from the ITIL used in the IT area and adapt it to a format that suits the OT environment – which may become “OTIL”.

19 Lindström, J. (eds). (2023). Handbook for development of cybersecure IoT-products. Smarter Electronic Systems, IoT Sweden, and Swedish Electronics Trade Association: Stockholm, Sweden. Available online: https://www.smartareelektroniksystem.se/handbocker/

20 https://www.dnv.com/cyber/industries/maritime/

21 https://www.lr.org/en/services/classification-certification/cyber-resilience/cyber-safe-for-marine/

22 https://iacs.org.uk/resolutions/unified-requirements/ur-e

23 https://wiki.en.it-processmaps.com/index.php/History_of_ITIL

Figure 3.2 – Idea for how to approach the compliance assessment/analyses – inner out approach for mapping out requirements

Part 4 – An outline for an OTSF starting at the policy level

A proposed structure for the OTSF is as follows having three levels with (see Figure 4.1):

• Policy – outlines the organization’s rules for what is allowed or not and which roles are responsible for different areas. The length should be max 15 pages

• Standards – outlines and describes important processes, procedures, set-ups and configurations, i.e., how to do specified tasks or set up things in a standardized and uniform manner for to get the same wanted result nonetheless who performs the task etc. The standards may be as long as necessary

• User guide – guides the users to act and behave in a secure manner and raises awareness about OT/OT security. The user guide should be 1-2 pages and only comprise the most important from the policy and standards

It is important to keep the OTSF as simple and lean as possible to make it work also in practice and not only for audits and governance purposes. However, very large organizations may have an additional high-level policy or a directive etc. Thus, an OTSF should provide adequate structure regarding responsibilities, authorizations, organization, processes and standards to enhance clarity, efficiency, availability- and security levels – but not be overly rigid and detailed to instead hamper flexibility, initiative and happiness at work! The proposed OTSF further provides some dimensions not addressed, or only partly addressed, by the international standards brought up in section 2.1, which are needed to organize and connect different parts of an organization. In addition, the OTSF needs to be kept updated at least annually – or else it will become outdated.

4.1 Outline for what content to have in the policy of the OTSF

What contents to have in an OTSF policy? A general OTSF can span the following areas at the policy level:

• Organization of OT security

• HR-related security

• Risk and availability management

• Lifecycle management of the OT environments

• OT environment architecture and security

• OT network security

• External resources and safe/smart sourcing in the OT environment

• …and if not already addressed in the IT/information security framework (ISF): Physical and environmental security, Business Continuity Planning (BCP), Disaster Recovery Planning (DRP), Incident Response Planning (IRP), etc.

• Non-compliance and reporting

• OTSF Governance

Figure 4.1 – Proposed structure for an OTSF with three distinct parts

The above areas should be complemented with any additional area that is of importance for an organization and how it should manage its OT environments over time.

An OTSF should be to the point and condensed, or else it will not be used. Further, an OTSF should comprise what is needed to govern/manage the OT security, which includes the risk level wanted, context description, if it is a critical infrastructure or industrial type organization, as well as how adequate the corresponding ISF affects the OTSF!

4.2 Introduction to the OTSF

A policy should always have an introduction to explain why it is needed, who owns and keeps it updated, and define any terms and abbreviations needed. Thus, introduce the policy and the structure of the OTSF having underlying standards and user guidelines. If an organization has multiple inter-connected sites, (e.g., factories, mills or large installations), it can be a good idea to have common OTSF complemented by any local or regional variations due to legal or regulatory requirements. The OTSF standards and user guide are outlined in the following Parts 5 and 6.

4.2.1 Purpose of the OTSF

It is important to explain the purpose of an OTSF and its policy as it will affect most roles in an OT environment including management, externals and trusted third parties. The idea is to have a minimum set of common rules which are integrated into the ISF. If there is no integration and coordination between the ISF and OTSF, the outcome will be slow changes, security vulnerabilities and impaired process performance. The OTSF should be risk-based and comply to mandatory laws and regulations, and may further adhere, comply and use international standards and models, such as, adapted ISA-95 and Purdue models, appropriate NIST and ISO-standards, and selected parts of the IEC 62443.

4.2.2 Scope and applicability

It is important to outline the scope, which may be the organization’s business activities and operation related to OT/ OT security. Thus, the applicability may be for all employees and roles as well as contracted externals who work for the organization or on behalf of it. Further, to specify the applicability it may further include board members, management, specialists, workers, interns, contractors and other third parties etc. Suggested is that, depending on organizational structure, the manager for the mill/factory/installation is responsible for the communication and implementation of the OTSF and that it is integrated with the ISF. Further, all employees of the organization should be individually responsible for reading, understanding and following the OTSF with this policy and underlying standards and user guide. In addition, also included in the scope is ET as that may be an important part of OT environments.

4.2.3

OTSF objectives

Proposed is to state what the objective of the OTSF and its policy is to ensure that the responsibilities for OT/OT security are incorporated where responsibility for lifecycle management and protection of OT assets, data and resources needs to be defined. Any responsibility should have adequate matching authorization to be able to achieve what is expected also if the normal management is not present or reachable.

24 https://searchdatacenter.techtarget.com/definition/IT

Additional common objectives may be:

• to ensure the safety and security of all assets in OT environments and the safety of all humans working or being present in OT environments

• to ensure the availability and function of an OT environment

• to ensure the integrity of data and OT systems

• to reduce risk of accidental or deliberate misuse of OT systems and other assets

• to ensure confidentiality of data and that OT security policies are adhered to when using mobile computing, remote connections and data are shared

• to ensure a resilient and secure incoming supply chain for hardware, software, services as well as input to the production/manufacturing processes

• to ensure a resilient and secure outgoing distribution process/chain to the next part of the value chain or customer

It is necessary to clarify the order of priority for an OT environment, its security and expected operations. It is commonly as follows:

1. Availability (A)

2. Integrity (I)

3. Confidentiality (C)

Thus, this is the reversed order compared to IT environments, where the order of priority commonly is reversed:

1. Confidentiality (C)

2. Integrity (I)

3. Availability (A)

The reversed order, i.e., AIC vs CIA, combined with the focus to keep the often very expensive OT assets operating at high availability with process integrity, may make the structure and objectives of the OTSF a bit different compared to the ISF which focuses more on keeping data and information confidential and intact as well as IT assets as IT/information systems operational. Process integrity encompasses that, e.g., a production process continuously works and produces output within a wanted range of specifications or quality levels. Examples are production and distribution of electricity and clean water, which we want around the clock, every day of the year, and which need to be according to what is expected, or a lot of machinery and appliances will break down and people will get sick. In such cases, it will be hard to continue as usual to produce or manufacture the expected output and business contingency planning may be required to be invoked (see later in Part 4 and also in Part 7).

4.2.4 Definitions

Define important terms and concepts as well as make a list of abbreviations to help new employees or externals to easier understand. Examples of definitions are:

• IT - Information Technology - what is commonly used in the administrative part of an organizations to govern, coordinate/control, manage and steer the operations and supporting activities24

• OT - Operational Technology - what is used to produce or manufacture wanted output using specified input. Add a figure or two, similar to Figures 1.4 and 2.1, which outlines how the IT and OT can be modelled, separated, and inter-connected in a structured way. In the figure, the levels 4-5 can be considered as the IT and concerned with security of data/information. Further, levels 0-3 can be considered as the OT where availability of the production process and work safety are paramount25. OT may also include what is used within the distribution processes

• IoT – Internet of things - the concept of IoT within production units is often misused. The basic rule within OT is that there is no Internet. The topology of “standard” IoT equipment is to display data “where-ever” on L4 and above, which makes it difficult to use within controllers on L1

• ET – Enterprise Technology - there are several IoT and OT systems that do not fit well into the connected IT or OT environment. This is due to that these systems may be old and unsecure, lack connectivity, or just should not be connected to an OT environment for other reasons such as no logical need to connect, or having exposed and vulnerable parts. If connected, an ET environment can preferably be attached via the Industrial DMZ. Some ET systems should be run in island mode and not be connected at all to a wired network

• Convergence of IT and OT - IT and OT are on a path to slowly converge and OT has started to use more and more of IT-related concepts, equipment and services. This will change how the OT is architected, developed, set up, maintained, and managed26. However, any legacy

25 https://whatis.techtarget.com/definition/operational-technology

assets used in OT will slow down the progression of the convergence. The commonly longer lifecycles of OT assets are a further slowing down factor to consider

4.3 Organization of OT/OT security

The objective with the organization of OT security should be to ensure that the responsibility for OT security is incorporated where responsibility for protection of OT assets, data and resources is necessary. Further, common objectives are further to ensure: (1) the availability and function of the production processes and their assets which run in the OT environment, (2) integrity of data and needed systems, reduce risk of accidental or deliberate system misuse, and also (3) to ensure confidentiality of data and that the OTSF is adhered to.

The responsibility for the OT environment starts, e.g., at the industrial DMZ firewalls where the OT environment connects to the IT environment (see example in Figure 4.2). Each organization must decide upon where to have this demarcation line of ownership to find the best fit for the own organization. This division between the IT and OT environments provides a clear ”point of ownership” for the respective environments. However, ownership and who manages the Industrial DMZ may not be the same (see also section 1.5). The industrial DMZ shall protect both the IT and OT environments and enable a possible separation of IT and OT if needed. The firewalls, switches/routers, etc. involved in the industrial DMZ shall protect the underlying OT network, subnets and segments. All traffic between the different networks, subnets, and segments should be controlled (there should only be allowed needed and authorized traffic from approved senders to receivers on network segment level) and monitored.

26 https://searchitoperations.techtarget.com/definition/IT-OT-convergence

4.3.1 OT security roles and responsibilities

It is necessary to define roles and responsibilities related to OT and its security. It is common that a factory/mill/installation manager has the overall responsibility for how the OTSF is implemented and decides the roles’ responsibilities with related authorities. Below are some potential roles involved in OT and its security. It is very important that the responsibilities and authorities are clearly defined and divided up, to facilitate efficient operations and less organizational friction.

4.3.2 Roles

The following are examples of generic roles for factories/ mills/installations starting from the top level:

• Senior manager for whole operation above factory/mill/installation (e.g., senior vice president, chief operating officer (COO) or chief technology officer (CTO)) - governance and owner of OTSF documents and that these are kept up to date and maintained

• Chief Information Security Officer (CISO) or similar role – responsible for overall IT/information security and needs to coordinate with all OT security responsible distributed at factories/mills/installations as well as cooperate with the IT/OT security coordinator. Member of OT security network

• IT/OT security coordinator - is responsible for keeping all the overall OTSF documents up to date in practice and that risks are analyzed regularly, to spread the OTSF contents and awareness building. Further, an addition may be to form and run an internal OT security network involving also staff from IT to share experiences and knowledge. Additional responsibilities are OT security governance, ordering and evaluation of audits, propose changes in either ISF or OTSF, achieve adherence at all factories/mills/installations, and propose adjustments to be coordinated within the internal OT security network

• Factory/mill/installation manager - has the overall responsibility for a whole factory/mill/installation and appoints an OT security responsible

• OT secur ity responsible - responsible for the security of the OT environment with its OT assets and the related processes. There should be one OT security responsible at each factory/mill/installation. Further, responsibilities include also OT security related availability management, risk collection/analysis/management, and to develop and maintain necessary user guidelines and instructions (and if needed to adapt these to the specific factory/mill/installation). Member of OT security network

• IT/OT technical coordinator – a technical coordinator role, within the IT or OT parts of the organizations, who has as a technical coordinator role during implementation of the OTSF and its standards within the manufacturing/production supporting the OT security responsible at each site. Member of OT security network

• ET responsible – basically the same as the system owner or delegated person/function. Often, the responsibility for ET systems can be shared between those who procure and use the ET systems (an operational unit) whereas IT or OT departments can be responsible for maintenance depending on the organization set up concerning ET

• Physical security and safety responsible – such a role is necessary unless clearly part of the senior management role (see also section 4.10)

• Environmental security and safety responsiblesuch a role is necessary unless clearly part of the senior management role (see also section 4.10)

To facilitate the exchange of knowledge and know-how regarding OT/OT security, an internal OT security network can be set up within an organization having meetings 3-4 times per year. Such a network can help to make all roles involved to learn to know each other, enhance collaboration if the organization is distributed/global, and bring up problems and new topics to discuss at each of the meetings.

In addition, there should be a role who owns the OT-related data, i.e., data owner, and coordinates that data is handled properly and digitally preserved etc. This responsibility may be added to the CISO unless there is a Chief Information Officer (CIO) who does this.

Figure 4.2 – Example of demarcation line of ownership between IT and OT

4.3.3 Audit and compliance of the OT security

As it is important to keep the OT security up to date at all times, it is necessary to, on a regular basis, audit all of it and more often the known weaker parts of it. This needs to be planned and conducted, and all involved need to understand why it is conducted to minimise any negativisms and obstructions. Thus, audits need to be conducted regarding the OT security controls (and standards or processes etc.) so that they are adequate and fulfil their objectives. Examples of to audit:

• Contents of policy – do the rules work, and if the personnel comply to the rules

• Contents of standards – do the standards work or do they need changes or updates, and do the involved personnel work according to the standards

• Contents of user guide – are the contents up to date or should be changed, and to test if the personnel understand the instructions of the user guide and also know most of it by heart

Further, some specific standards to monitor extra and audit more often are for instance the following which involve outbound and inbound connections, as well as network security:

• External connections – all connections for sending out or bringing in data from OT segments should be treated as exceptions and documented accordingly. Refer to a template describing why the external connection is needed, who ordered it to be set up, if/when it should be terminated, and if there are any other considerations to make

• Remote access – all remote accesses should be made via the organizational standard solutions. All remote accesses should personal, time limited, ordered by a responsible manager, revised on a regular basis and only give access to the OT assets required (consider risks for lateral movement by potential intruders)

• Rules and configurations for firewalls, routers, switches and gateways etc. – to ensure that the rules and configurations are up to date, apply the principle of least privilege on network level to only allow needed/ wanted authorized network traffic within the OT environment. A change management process is needed to keep a clean list of rules

The audit here is related to the Human Resources security-related audit outlined next.

Regarding external compliance to legal and regulatory requirements, selected international standards, etc., this should be made at the top level of an organisation as more parts than OT are likely affected. In particular, if an organization is global, spans many different types of legal and regulatory zones, there is a need to adhere to various international standards, as well depending on geography, this is a huge task which needs adequate competencies, planning and a lot of effort to keep the status of compliance up to date. See Parts 2 and 3 for more information.

4.3 –

of necessary information flow from HR-processes to access control and user account processes within IT and OT environments

4.4 Human Resources (HR)-related security

The OT security controls, part of the policy and standards, which are related to Human Resources (HR) should be audited regularly for each factory/mill/installation. Examples of such OT security controls include policy rules regarding user management, access management and authorization levels. What need to be ensured are that the user lifecycle works in a dynamic manner and that accounts not needed are disabled or removed in a timely fashion. Further, remote access should also be provided on a limited time basis, with potential renewal by authorized manager, and to only provide access to what is required. The principle of least privilege should always be applied and if access rights or authorizations are no longer needed these should be removed. Therefore, use HR-processes for on-boarding, change of position/tasks as well de-boarding (see Part 5 and sections 5.1 and 5.2), and these should be linked to processes for access control management and user account management (see section 4.7.5 and Figure 4.3). Therefore, it can be a good idea to have the policies to overlap each other a bit and provide some “glue” (see orange dotted arrow in Figure 4.3) to make them all together stronger than the individual ones are by themselves. Further, the principle of two-hands should be applied where needed, such as when making important rules or configuration changes in firewalls or routers, or exporting valuable/sensitive data from databases, etc. Thus, start with stating what to audit and why it is important for HR-related security.

4.4.1 OT competencies and skills management – and the need for a matrix

Outline that HR has the responsibility together with the management team of a factory/mill/installation to ensure that the necessary OT and OT security competencies are available. Further, it is important that no single employee, consultant or third party is the only one having critical competencies and skills regarding the overall OT environment and its processes and OT security. The critical competencies and skills should be mapped in a matrix to ensure that there are overlaps for each of the critical ones. The matrix should be updated at least on an annual basis, or more often if the employee turnover is high. To reach this, training programs and educations for OT/OT security personnel are needed on a continuous basis. Remember that a management team decision can be made to outsource competencies and skills, but it should be to complement or reinforce the internal ones rather than creating a dependency to externals.

4.4.2 IT and OT need to work together

State that it is of utmost importance that the personnel working within IT and OT in the connected areas, think,

plan, coordinate and work well together. Else, there is a risk for long conflicts, low workplace satisfaction, and poor overall performance of the production processes running in the OT environment. In particular, change management where any changes within IT affects OT, or vice versa, is a must and that all such changes are prepared, planned, and coordinated together. Thus, information sharing meetings and change management meetings with planning/coordination should be held on a regular basis including the adequate roles from IT and OT. Larger changes or major investments should be well planned to get the best effect out of these.

4.4.3 Visitors to OT environments

There should be a process for how to manage visitors, and especially if the OT environments are hazardous. A good idea is to gather any visitors at a front desk (reception), from where it is not possible to enter the IT or OT environments without adequate credentials. An employee of the organization should always receive the visitors and ensure to log them in/ out according to the visitors’ process. The log in and out are required to keep track of whom are on the site in case of an accident or emergency. Further, it is a good idea to always require that visitors are accompanied by an employee (i.e., the host) when in the IT or OT environments and that they should not be allowed to visit any sensitive areas/zones unless there is a reason and necessary guidance is available. Some third parties or consultants, which are trusted after a long relationship and who has adequate knowledge and training, can be let alone to enter the IT and OT environments with clear instructions for what to do and how to behave. See section 5.2 for more information.

Access to some OT environments, where there are hazards and dangerous areas, may require that the visitor has taken a basic safety/security awareness training and pass a test to ensure having understood the awareness training. This is to avoid accidents and unnecessary safety/security stops in the processes running in the OT environment.

4.5 OT risk and availability management

As for security in general, the foundation of OT security is risk management combined with availability management. The risk and availability management processes provide over-arching requirements for how to design, build, and maintain the OT environments with the production and distribution processes stable, robust, resilient, available, with intact integrity and confidentiality, and thus overall secure

Figure

Example

Due to the importance of risk and availability management, all policy rules and standards of the OTSF, should all consider these as input when being further developed and maintained.

In addition, any potential ET assets and processes, which are considered as supporting the critical processes in the OT environment, should also be added to the risk and availability management upon need.

4.5.1 OT risk management

Outline that the OT risk management should be part of the general and IT risk management processes. Proposed is to develop a risk assessment/analysis process for OT that is linked to the ditto in IT and at the overall general level of the organization. The OT risk management process should be a part of the OTSF standards (see section 5.3). The risks found in the OT environment should be assessed together with the ones found in the IT environment, to learn if the risks cross IT and OT or only are related to one of the environments. Further, it can be a good idea to form a forum to manage risks that are not only related to one environment, and that this forum meets after the respective risk assessments/analysis for each environment have been completed.

Risk assessments/analysis should be conducted on a regular basis, and at least once a year or more often if changes in the surrounding world requires that. It is important to keep the total overall/aggregated risk level at an acceptable level, and this level should be decided by the management team and board of directors for an organization.

Procurement of new assets should require a risk assessment as part of the procurement process, to avoid procuring assets that are not secure from start (or at all) as these assets may have a long lifecycle. Thus, a secure procurement process should be part of the OTSF standards (see section 5.4.1 and potentially read more here as well27). What is to be considered, both

as risk and availability issues, is to have secure incoming supply and outgoing distribution chains, and that these need to be analysed and overseen as part of the risk and availability management

To keep track of OT-related threats, vulnerabilities, risks, etc., proposed is to have a role who is risk responsible (see OT security responsible role in the roles section earlier) to collect and store these in a secure database or adequate repository.

4.5.2 OT availability management

Concerning most OT environments, wanted is high availability of its processes and assets running in the production and distribution. Therefore, as a start this is facilitated by an appropriate OT architecture design with OT security. This may include for instance redundancy of electric power (with UPS where needed) and utilities, no single-point-of-failures in OT networks and communications, critical network services, essential OT systems, etc.

Thus, the baseline requirements for availability within an OT environment should be assessed, mapped out, and documented. Ensure to identify, classify and document the most critical parts and assets. Further, the design and set up of the critical parts shall be made to meet the classification requirements. To support the above, an OT availability management process should be part of the OTSF standards (see section 5.3). This process should, as the risk management process, take into account to have a secure incoming supply chain, to ensure that the required input to critical processes and necessary software, hardware, components, spare parts and other overhaul and maintenance etc. of OT assets can be conducted in a timely manner. The secure distribution chain for output produced should also be considered as in many cases there is a limited storage space to keep output if the distribution process fails.

27 https://www.vdma.eu/documents/d/group-34568/applied-risk-management-final

A key ingredient in availability management is service level agreements (SLAs) from external providers of hardware, software, or services necessary for the critical parts and processes. The external SLAs need to be aligned with the internal classifications and expectations of availability. Important to consider is that external SLAs with fast start time are expensive, and thus additional internal measures could be explored to be able to solve more problems using own personnel. Thus, consider to make such an availability classification on both critical process and asset levels. An example of such is:

A. Maximum 15 minutes unplanned downtime

B. Maximum 60 minutes unplanned downtime

C. Maximum 24 hours unplanned downtime

D. Maximum 48 hours unplanned downtime

The critical processes should further be part of the business continuity plan, and the critical systems involved should each have a disaster recovery plan. A disaster recovery plan can be included in a system maintenance plan (see section 5.5.2.3) unless managed separately and kept updated at least annually.

To learn from issues and mitigate such issues, as much as is relevant compared to the potential impact, all OT security-related problems/incidents, interruptions, and stops, which are not directly related to the maintenance of production equipment/machines or the operations of the production processes, shall be documented in enough detail. Ensure to collect these reports in a secure database or repository. Further, to improve the availability, have a senior OT/OT security team to analyse the new reports every 3 or 6 months to learn if the availability problems can be mitigated or prevented to occur again.

Additionally, there are advantages if the availability management is integrated into the predictive/proactive or condition-based maintenance of OT systems as well as quality management, as these depend on each otherd28. This can be expanded into a zero defect manufacturing (ZDM) scenario connecting all these aspects into a common methodology and model29

4.6 Lifecycle management of OT environments

This section is probably the most important of all in the OTSF as it encompasses how to manage all assets over their lifecycles. As many OT assets are very expensive and may take time to get replaced, poor lifecycle management and short-termed planning can be very costly and impair the overall and expected levels of process and output quality as well as availability. Thus, carefully outline the lifecycle management of OT environments to ensure adequate management, operations, maintenance and protection of OT environments. This entails OT assets and data/information during their useful life until the end-of-life.

4.6.1 OT asset management

Describe the essence of the OT asset management process, which should include how to procure, manage, operate, maintain, retire, and protect OT assets for these to provide an optimal return-on-investment as well as be safe to use throughout their whole lifecycles. The management com-

prises to keep track of all OT assets and their status so that it is possible to plan for maintenance, changes, updates and replacements, and execute necessary actions all the way until end-of-life and following disposal, destruction or re-cycling. The operations should be within set limits to ensure that the assets will operate in a controlled manner and the maintenance to keep the assets operational and available at a wanted level. Preferably, there should be an OT asset management system where all significant OT assets are electronically recorded to ensure proper overall management of assets as well as accurate provision of access rights to OT assets. The asset management is directly linked to change, configuration and obsolescence management, and thus all these must work together or else the overall asset management will require a lot of manual management, and many matters will be missed and forgotten. Any changes to assets should continuously render an update in the asset management systems and related change and configuration (and potentially also obsolescence) systems as well! If possible, in order to make the OT asset management efficient and manageable over time, the asset management system should have an auto-discovery of assets and changes to such (which also involves change and configuration management) which works without disrupting processes or assets. Further, input and changes regarding assets to the asset management, change and configuration management systems should be automatized as much as possible, but also have manual input as well as other input possibilities such as files or secure database connections. Procurement of assets should be made in a secure way as well, as it can be very hard and costly to add adequate security later on. See section 5.4 for more information.

Regarding ET assets, these should also be part of the asset management. As these assets may not all be connected/online, they may need to be entered manually or if there is asset information elsewhere to use and import in the asset management system. ET assets should have a different tag or asset name compared to ditto IT and OT ones.

As the asset management is the foundation for efficient and orderly management of OT and its asset, OT security, and cybersecurity overall, the various systems used as part the asset management must be highly secure and any connections to these as well. Else, an attacker can easily get all the information needed about various types of assets including their configurations.

4.6.1.1 Classification of OT assets and data/information

Assets and data/information should be classified in order to understand which are more important than others. Thus, make a classification and classify OT assets and data/information. Keep these classifications stored in the asset management system to enable sorting, listing and prioritizations. Ensure that, at least, all critical OT assets are classified. A possible way to make a simplistic classification is to use 1 (lowest) to 4 (highest) concerning these three or more classifiers:

• Availability – levels 1-4. The availability levels should further be specified in terms of what 1-4 are equal to (e.g., 90/95/99/99,99%). Here, external dependencies

28 Lindström, J., Larsson, H., Jonsson, M., Lejon, E., Towards Intelligent and Sustainable Production: Combining and Integrating Online Predictive Maintenance and Continuous Quality Control, Procedia CIRP, Volume 63, 2017, pp.443-448, ISSN 2212-8271.

29 Lindström, J., Kyösti, P., Birk, W., Lejon, E. An Initial Model for Zero Defect Manufacturing. Applied Sciences, 2020, 10(13), 4570.

and SLAs must also match the wanted level of availability. Any planned maintenance stops or similar must also be considered. If there are legal and regulatory requirements on continuous recording of environmental data, this must be kept in mind to avoid fees or penalties. See also availability management in section 4.5.2

• Integrity – levels 1-4. The integrity levels should further be specified in terms of what 1-4 stand for

• Confidentiality – levels 1-4. The integrity levels should further be specified in terms of what 1-4 entail

As the OT assets and data/information have been classified, adequate protection mechanisms and security controls should be implemented to match the requirements of the classification.

4.6.1.2

Ownership of OT assets

Ensure to clearly define the ownerships and responsibilities regarding OT assets in the OTSF. See more on this in section 4.3.1 on OT security roles and responsibilities.

4.6.1.3

Procurement of OT assets

If an organization buys insecure OT assets it will be hard and costly to add the necessary security later on, and it will also be hard to maintain that security. Thus, recommended is to make, or change the existing, procurement process, (see section 5.4.1), to become secure as well as that what is procured is secure from start. Commonly, this process is owned by the procurement part of the organization and the procurement team also owns the process. Of importance is to get the adequate security questions and requirements into the process as well as ensure that the right roles within OT and OT security are involved from the very start to avoid having to redo a lot of procurement work.

The rules here in the policy part should stipulate that the procurement process, including OT security, should be used for all OT-related request-for-information (RFI), tenders, agreements/contracts, etc. Further, there should be clear requirements for what suppliers and consultants should do and how to behave in terms of OT security, as well as what the own organization should do itself. All RFIs, tenders, and agreements/contracts should be verified with the OT security responsible prior to finalization and start of the procurement.

4.6.1.4

Handling of OT assets throughout their lifecycles

Outline which processes and operational procedures, for the handling and storage of OT assets and data/information, that needs to be established and implemented to protect the OT assets and data/information concerning unavailability, integrity or inconsistency, unauthorized disclosure, or misuse. The processes and operational procedures, see following sub-sections, should be defined for so that the management and handling of OT assets and data/information are consistent with their classifications. See also section 5.4 for more.

Regarding ET assets, these should also be included in the configuration management, obsolescence management and change management processes and supporting systems.

4.6.1.4.1 Configuration Management

Configuration management entails a continuous process for to keep track what is inside of an OT asset in terms of hardware components/parts, firmware, operating systems, platforms, applications or other types of software. Commonly, a configuration management system, linked to the asset management system, is used to keep an electronic record of all OT assets, their status, and level of configuration. Any configuration changes should be recorded for to be used for planning and execution of updates/patches, changes or replacements, etc. A configuration management system can be very helpful to find where a certain component or software is used in case of serious vulnerabilities or problems are detected or communicated via national CSIRTs30, CVEs31 or suppliers’ vulnerabilities alert information. Examples of cases where a configuration management system helped to quickly find where vulnerable components were situated was for instance the Log4j or Log4Shell cases, which can be read about in articles available on the Internet. Organizations which did not have a reliable configuration management system often spent months to find out where these existed, without finally knowing if their search had been exhaustive enough.

4.6.1.4.2 Obsolescence Management

Obsolescence management encompasses to have a plan and, if needed, a storage of critical hardware and software components over time to ensure that if old but still critical OT assets break down, there are replacement parts or other ways to remedy the problem Thus, outline for how the obsolescence management process should plan to ensure timely access to necessary components, devices, replacement parts etc., in case the vendors stop selling them, for to keep the OT environments working and available. The use of 3D-scanners and 3D-printing can limit the size and number of physical parts etc. necessary to keep in stock. Another possible strategy for keeping costs down, as obsolescence management is expensive, is to make an agreement with partner and competitor organizations to keep and manage a joint storage of all that is needed instead of that each organization should have its own. Thus, outline the rules and strategies to maintain timely access to all necessary components, etc., by for instance:

• As long as possible, make agreements with suppliers/vendors guaranteeing timely access. Ensure to get a notice if the suppliers/vendors plan to end-of-life components etc. so that these can be purchased instead of re-cycled

• Build an adequate own stock

• Make internal agreements within the own organization, if it is large and there are similar OT assets used elsewhere, to ship to other factories/mills/installations quickly in case of problems

• Make external agreements to set up a joint storage facility where all critical components are stored until decided that a component will not be used again and it can be sold or re-cycled 30

4.6.1.4.3 Change Management

Recommended is to device a change management process and having a change management system to manage, plan and document changes to provide traceability, overview and plannability of work. It is important to share change-related information with all who needs that (e.g., stakeholders from IT, OT and other parts of the organization). Ensure to analyse any potential impact prior to carrying out the change. The analysis should comprise a security assessment. Following the analysis, any changes should be planned and communicated in a timely manner. Further, the changes should also be tested/verified, documented and reported as completed when finalized. To find the needs for change and decision-making regarding changes, the following should be regarded for planning and acceptance:

• Production capacity and flow demands should be monitored, and projections of future capacity and flow requirements made, to ensure that there are adequate processing capabilities and storage are available

• The OT security responsible should monitor and document the capacity and flow demand to ensure that the adequate processing capabilities and storage are available. The documentation should be securely and safely stored to enable access and reviews

• Acceptance criteria for new OT systems, upgrades and new versions should be established, and suitable tests of these should be carried out prior to acceptance

• Recommended is that it is the responsibility of the OT security responsible also includes to require assurance that security functionality and necessary processing capacity is implemented and working according to the specified requirements. Note that this is in particularly important concerning access rights, remote access and connectivity abilities

• Ensure that development, test and production environments should be kept separated as much as possible, and these are to be kept separated over time

• Ensure that development and testing should not be made in the production environment (unless there are no other available options, risks are assessed, and that there is a decision to do that). Any data sets used in development and testing are to be kept secret and apart. Preferably, the test environments shall be set up as a limited but representative environment with key components, devices and equipment, which are similarly connected as in the real production and distribution processes. Here, the purpose is to test any major changes, updates and patches prior to making/installing them in the real production or distribution processes

• There should be defined and written rules for the transfer of OT software etc. from development to the production or distribution processes

In addition, there should be strict control over the implementation of changes using a formal change control procedure part of the change management process. Modifications, except vendor-supplied software or fixes/updates, to OT software packages should always be evaluated if necessary and any essential changes controlled and installed during change windows or planned stops. All changes should be fully tested and documented according to change control procedures so that they can, if needed, be re-applied also to future OT software upgrades.

4.6.1.4.4 Simulation model of OT environment (or limited testing lab)

If possible and necessary, a simulation model of the OT environment with its critical parts, i.e., a digital twin, could be used where it is possible to simulate changes in production

and distribution processes prior to making them for to learn if and how to do the change. If it is not possible to have a digital twin, a limited testing lab with real equipment representing the most critical parts of the production and distribution processes can be used to test before making any changes in the real processes. Further, one or more digital twins can be used to simulate new start parameters or configurations to initiate the production processes with after maintenance stops, smaller or major changes, as well as additions of new parts to processes.

4.6.1.4.5 OT systems’ documentation management

It is crucial to manage all the OT systems’ documentation and keep it all secure and protected from unauthorized access (as there is likely a lot of sensitive data/information). Thus, a secure documentation system is needed and there should be backups made on a regular basis as well. Availability of OT systems’ documentation should be ensured also during incidents and larger problems. The documentation should all have provenance in terms of author, change dates, and version control where it is possible to access old versions if needed.

Further, ensure that there is documentation about which OT systems that are connected to each other and necessary firewall/routing rules to get that to work. See also section 5.5.2.3 for more information on documentation templates.

4.6.1.4.6 Vulnerability management, update and patch management

Outline that upon the continuous need to make updates, patch or upgrade software in the OT environment, these should firstly always be checked with OT system/application vendor support notes and be tested prior to roll out (refer to system maintenance plan, see section 5.5.2.3). This is necessary to ensure that these activities do not cause unnecessary stops or problems in the production or distribution Underline the importance of that changes are not allowed without testing if the integrity and availability requirements are high. Thus, if possible, recommended is that any updates, patches or upgrades etc. should be rolled out in a controlled manner during planned stops in the production or distribution processes.

Based upon the existing, new and emerging EU laws and regulations, for those who are concerned, the requirements posed on the providers of various IT, OT, and IoT systems as well as cloud services etc. require that the number of software updates (e.g., fixes, patches, updates and upgrades) will increase through-out the whole lifecycles. Further, if waiting too long between making these updates the outcome can become undefined (not properly tested) even though some providers do cumulative ones or that the updates are applied in a recommended sequence. In addition, the digital product passports will provide information on where to find software updates and hardware spare parts.

4.6.1.4.6.1 Vulnerability scanning - automatic Consider scanning appropriate parts of OT environment and, in particular, if there are cloud services or APIs, etc., used, which are exposed on the Internet. Preferably, automatic vulnerability scanning should be made on a regular basis from the outside world and, if appropriate, also within the IT and OT environments to find any known vulnerabilities. There should be designated recipients of scan reports who will

initiate actions if/when needed. If possible, automate as much of the analysis of the scans as possible to enable fast responses.

4.6.1.4.6.2 Penetration testing (manual)

In addition to the regular automatic vulnerability scanning, manual penetration testing should be done from the outside world one or a few times per year. Suggested is that the penetration testing involves remote access possibilities, cloud services, web servers, and APIs, etc., exposed on or to the Internet. Further, access to the OT environment from the IT environment should also be penetration tested on a regular basis and after larger changes or modifications. In addition, to consider is also if to try penetrating the OT network segments and any critical OT systems and networks services from just inside of the Industrial DMZ. Apart from the outside, it should also be tested to exfiltrate data from the inside of the OT environment out the Internet, which should only be possible using the external connections decided and set up. Another method to do the latter is to place a beacon inside the OT network that tries to reach a node on the “outside”, which can indicate unwanted leaks from inside out.

4.6.1.4.7 Management and end-of-life/disposal of OT assets and media

Describe how the management of OT assets and media, throughout the lifecycle and all the way to the end-of-life and disposal, should be made. Ensure to bring up what needs to be controlled and secured to ensure current and future confidentiality and integrity of the OT environment and its OT assets such as OT systems, storage media, and various network components.

4.6.1.4.7.1 Management of OT assets

As there may be OT assets of high value for competitors and hackers, some assets must be managed securely with extra care according to the asset management classification as well as how such are handled during the lifecycles and at the end of the lifecycle. Examples of such assets are: firewalls, routers, switches, devices, machines, etc. All these may contain information about know-how, recipes, special settings/configurations, IT and OT networks, user accounts, and other confidential information. Common principles for management may be with due care, maintenance and common sense during all of the lifecycles to keep these assets functioning with high availability. Due diligence should further be applied during the procurement process and later during installation/commissioning as well as major changes or when having externals accessing these assets.

Further, outline how OT assets without any confidential information, should be managed in order to keep them well-functioning with high availability.

4.6.1.4.7.2 Management of removable media

Provide rules for how to manage any removable media used in either OT systems or when making updates or configuration changes etc. Any removable media must be extra controlled and managed securely during the lifecycles, and special wiping/cleaning solutions may be applied if having for instance re-usable USB-sticks or disks. Further, any removable media can be coloured with for instance red for OT and yellow for IT – and the idea is that only red ones must be used within the OT environment and yellow in the IT ditto.

4.6.1.4.7.3

End-of-life and disposal of OT assets and media

Add any formal processes or procedures required to ensure a secure end-of-life and disposal of OT assets. Concerning OT assets and media containing sensitive/confidential information, proposed is that these should be securely stored, endof-lived, and decommissioned (i.e., wiped clean electronically) before used by another application within the organization or sent to destruction or re-cycling. Commonly, there is often such a process part of the ISF regarding secure lifecycle management of IT assets and data/information which can be extended also for OT

If OT assets are to be down-cycled, or sold to an external party, the process for end-of-life and decommissioning (which also includes to handle/deactivate/remove, e.g., any licenses, databases, user accounts, and sensitive/confidential data or information) should preferably be applied here too.

If storing end-of-lived OT assets and media for disposal, the aggregation effect of having a large quantity of unclassified data/information may cause a sensitive situation. Thus, some advice is to avoid accumulating large numbers of assets and dispose regularly. Further, if it is not possible to wipe OT assets and media clean, these should be destroyed prior to disposal.

4.6.2 Development and testing of OT systems and applications

If the organization develops, extends or integrates OT systems with other systems and platforms, proposed is to have rules for these development activities so that they are executed according to a well-established model or methodology, which is selected for the problem or task to solve. Further, if externals, such as, consultants or software vendors, are involved, having a process and a secure development lifecycle as well as secure development/test environments are important. Concerning OT security, the development model or methodology should include at least functional and security specifications addressing the following:

• Functional requirements analysis and specification

• Defining targets and objectives

• Formulation of requirements and use cases

• Security requirement analysis and specification

• Defining targets and objectives

• Formulation of requirements and extra use cases (if needed)

• Creation of quality requirements for to pass decisiogates/ points

• System architecture with surrounding OT environment

- risk analysis should be made during the design phase as well as to be re-visited after the design phase to include any major changes made. Training may be required prior conducting such risk analysis

• Threat modelling – use an established model to model threats. Training may be required prior conducting such analysis

• Security assurance – include measures such as penetration testing, code review and system architecture analysis (to meet requirements of availability, integrity, confidentiality and security overall)

• Continuous risk management – ensure that risks are considered continuously, e.g., at the start of a new phase or sprint. Any security measures necessary should be made regardless which development model or methodology is used (e.g., waterfall, agile, dev-ops, dev-sec-ops, etc.)

All development teams, including internal and external ones, should have training in secure system development and secure development lifecycles. Further, recommended is that the OT project budgets always have adequate funding assigned for OT security.

Depending of operational context and type of organization as well as type of value-chain participating in, there may be laws and regulations as well as mandatory industry standards to comply with. See Parts 3 and 2 for more on this.

4.6.2.1 Security requirements analysis and specification

Ensure that the security functionality requirements are introduced, or even better if integrated with, together with the functional and any other non-functional requirements at the start of any development-related project or activity. Further, the security functionality must be verified under the testing/quality assurance part of a project or activity.

Always consider if it is possible to use automated security controls prior to using manual ones to satisfy functional, non-functional, and security requirements. Further, depending on context, the development project or activity itself may have security constraints to consider.

Make clear and formalize who shall decide upon development requirements and any following changes to these. The decider, e.g., the originator/requester of a project, should preferably decide, document and communicate the requirements to the project or activity leader. That leader should then be responsible to implement the functional, non-functional, and security requirements. That leader should manage the development within the normal risk analysis process and report any significant risks to the IT/OT security coordinator (or whom that is responsible). When ordering any OT or information systems, the originator/requester should follow the secure OT procurement process (see section 5.4.1).

4.6.2.2 Security in OT systems and applications

4.6.2.2.1 Validation of input and output data

Decide how any data input to OT systems and applications shall be validated for to ensure that these are appropriate and correct prior to being input into the systems or applications. These validations/checks should, when relevant, be included in the developed code. Further, any data output from OT systems and application should also be validated where appropriate.

4.6.2.2.2 Security control regarding operating systems (OS) software

Operating systems (OS), firmware or other types of embedded software should be cared for extra. In particular, when accessing these with administrative rights, logging should be made to facilitate any audits and forensics needed. Some events to log are for instance:

• Any changes to input data (from other systems or user input) should firstly be authorized and then logged to provide traceability and accountability

• Suggested is that there is a documented operational procedure for to handle any detected errors/problems during the validation

• Proposed is that the responsibilities and authorities concerning the data input process are documented as part of role/job descriptions. These responsibilities/authorities should be regarded during the system development and at least be recommended at delivery for to be decided upon and documented

• Ensure that security checks/verifications are performed and documented at implementation of new or changed software concerning operating systems. Further, any vendor supplied software used in OS should be maintained at a level supported by the OS supplier. Physical or logical access should only be given to software vendors and OS suppliers for support purposes when necessary, having documented management approval. The software vendors and OS suppliers should be identified, authenticated, and their activities should be monitored and logged for to provide traceability and accountability

4.6.2.2.3 Data in transit - secure communications and middle storage

The communications to and from an OT system or application should be secure and encrypted (see section 4.7.4 for more information). Further, the inter-process communications and communications in between components/parts should also be secure and encrypted (e.g., between gateway/data collection server, switches, PLC, HMI and other intelligent parts). “Secure” encompasses both session integrity and confidentiality. If data in transit is stored during transit, it should be secured while stored as well.

4.6.2.2.4

General security requirements for OT systems

Depending on context and complexity, an OT system may need from only basic security functionality up to very advanced security functionality (including formal cybersecurity certifications). A number of such functionalities can be found in sections 4.6, 4.7 and 4.8 and the secure procurement process should have lists with such general security functionalities prepared, for instance for each of the main types of OT systems.

4.6.2.2.5 Assurance of quality and documentation

Ensure that the overall responsibility for any development project or activity is assigned to an individual, for example a project leader, and each OT system or application under development should have an asset owner. Document responsibilities and authorities. Further, quality assurance responsibility and authorities should also be decided upon, and the final test report should conclude if the developed OT systems and applications are developed according to security requirements (as outlined in section 4.6.2). A full set of (1) development and (2) system documentation should be maintained for all systems undergoing changes, development or long-term software/application/OS/firmware-related maintenance.

4.7 OT environment architecture and security

Outline what the objectives are to set the level wanted. Common and general objectives to consider are:

• To ensure a secure, robust, stable and resilient OT environment operating at a high level of availability

• To prevent unauthorized access and use of OT systems

• To detect and timely respond to unauthorized activities, malfunctions, or anomalies, within the OT environment

• To ensure the integrity of the processes which operate within the OT environment as well as the output from these processes (i.e., that the processes work as they should and produce the wanted output within the desired specifications)

4.7.1 OT environment owner requirements

It is crucial to clarify who owns the OT environment and its various OT assets (e.g., systems and equipment) due to responsibilities for maintenance and budget allocations, authorization, access controls and usage. Thus, consider defining and documenting the requirements for to achieve a secure, robust, stable and resilient OT environment operating at a high availability level. Make sure that the rules and rights for administrators, users, and externals are clearly outlined. Access rights and authorization levels should be restricted/limited as defined and always adhere to the least access rights/privileges concepts (i.e., on a need basis, and no more, when needed). Define and document the requirements for identity management and access control and ensure that these rules and rights are clearly stated for the users.

In addition, to avoid unnecessary problems caused by external service providers, consultants and suppliers, ensure providing a clear statement of the organization’s business and cybersecurity requirements to be met during the procurement process and later while onboarding of these

4.7.2 OT architecture principles

It is paramount that the OT architecture is well-considered, planned and designed to be safe and enable security, robustness and resilience to achieve the wanted level of availability for the OT environment with its production and distribution processes (see also section 4.5.2 and availability management). Firstly, decide upon the main architecture principles and how to model the IT and OT together. (As the preference of the authors is to separate the IT and OT environments, according to Parts 1 and 2, the following text will be according to that philosophy and modelling).

Ensure that the OT architecture to the largest extent possible is layered, segmented, zoned (or sub-segmented), and where needed segregated. Functionality and security levels should guide these decisions. Further, the OT environment should be set up, for to prevent problems to spread and propagate, to make it harder to cyberattack as well as for to minimize the effects of any internal mistakes or unplanned breakdowns. Thus, craft an OT reference architecture standard (see section 5.5), which can be seen as a blueprint for green field (new assets) and brown field (existing assets) activities stipulating all, or at least most, principles to consider regarding OT architecture. The OT reference architecture standard should always be used when addressing availability/redundancy of: electricity/power/utilities, communications, OT systems, critical parts, components and network services. Further, the OT reference architecture standard should be used for to keep order and maintain the OT environment and all its processes and assets. In addition, in particular, if the organization has multiple sites and installations, there is a need for an IP-address standard (see section 5.5.1). Such a standard should outline how to structure/plan the OT architecture and networks so that they can communicate and be interoperable. In addition, a naming standard (i.e., naming convention for assets) for components, equipment, laptops, servers, etc., should be applied to keep order and make it easier to work (see section 5.5.1).

Further, ensure to also include how to connect ET assets in a secure and efficient manner. In addition, consider the need for use of islanding in case there are OT systems (or ET systems)

that are not secure and should not be connected to the OT network. Further, the OT environment and its networks should also be prepared for problems and cases when there is a need to disconnect the OT environment from the Industrial DMZ and IT environment and thus needs to have all essential network services and necessary supporting services and set up to continue to function anyways. If data should only be allowed to pass in one direction, the use of network data diodes should be considered to enhance network security.

4.7.3 Hardening of OT networks and assets (essential network services, components, network devices, equipment and servers etc.)

To minimize the attack surfaces for cyber attackers, viruses and malware, etc., it is necessary to harden the OT networks and assets. The hardening is also needed to minimize the effects of any internal mistakes or unintended side effects of actions. See standard for configuration and hardening of OT assets in section 5.5.2.1. Thus, the configuration and hardening can be defined as following:

• OT networks (i.e., levels L0/L1/L2/L3) – to always have modern (up-to-date) and updated network equipment, rules and configurations. Further, only wanted and authorized network traffic should be able to go out and in to network segments as well as within these segments and their zones (sub-segments)

• Essential network services – the essential network services for OT should always be available within the OT environment in case that the IT environment needs to be disconnected. If a process must always continue to work, the process’ network segment(s) may need to have its own distributed network services as well. These must be extra considered in terms of hardening and should have at least what follows below. Additional hardening measures may be to use whitelisting of IP addresses and adequate input control/filtering, etc. The physical networks for IT and OT must be separated and the Industrial DMZ can be used as a “kill switch” in case a quick separation is needed due to for instance a cyberattack –and the network services need to manage situations like that and continue to operate

• OT systems and equipment – the hardening may comprise that operating systems are hardened, that not needed communication ports, USB-ports, and services are removed or deactivated. If deactivated, such can be turned on while needed and then deactivated again. Further, any functionality or applications which are not necessary/used should be removed. It is important that the hardening standard is followed so that all hardening efforts render the same effect. In addition, the various software should be timely updated to avoid having known vulnerabilities for long periods of time

In addition, users should always use a normal user account and only be logged in with administrative privileges when needed and then log down to normal user again (see example in Figure 4.4). Decide upon the rules for how logon and logout should be implemented in the OT environment and its OT systems and services. An example is that it is OK to logon upwards but that it is not allowed to logon downwards, which should require a logout firstly.

This will make it harder for any viruses and malware to spread as well as intruders to move upwards for to gain administrator control privileges. Any operator accounts used on operator stations, located in operator/monitoring rooms which are not

manned all around the clock, should have forced inactivity logout activated for operators accounts with control or administrative authorities.

Figure 4.4 – Example of OT account logon model and rules for that

Figure 4.5 – Example of OT access “BoxTiering”

In order to separate functions and accesses within a segment and across segments, one can apply the concept of “BoxTiering”. It is important to divide up, i.e., boxing, access rights to only enable to access to where access is required and not to anything else. See example in Figure 4.5 on “BoxTiering” and how this is applied for different processes/network segments and their sub-processes/network sub-segments.

4.7.4

Use of encryption, key and certificate management, and related processes for enrolment and revocation

As confidentiality and integrity must work to support availability, there are some matters related to encryption controls which must be decided upon and set up. A lot of the OT security functionality depend on a number of cryptographic controls, and thus encryption keys and certificates need to be managed over time. These activities should be formalized into a cryptographic standard and key and certificate management process addressing enrolment, renewal and revocation of certificates and keys (see section 5.5.2.2). Use of long-lived certificates and keys should be avoided.

As there has been a lot of changes and additions to various laws, directives, regulations and industry standards, see Parts 2 and 3, ensure that the use of cryptographic controls and related certificates and keys adhere and comply with any restrictions for usage and export of such. If exporting cryptographic controls, ensure that this is investigated prior to any exporting activities.

Due to the progress within the field of quantum computing, all existing use of encryption algorithms, keys and key and certificate management processes need to be reviewed and successively exchanged to post quantum compliant versions. Else, this will constitute for multiple large risks to mitigate when it may be too late. Thus, this encompasses all from authentication processes, any internal and external communications, external connections as well as remote access solutions etc.

4.7.5 Identity, authentication and access control management in the OT environment

For identity and access control management to work in a structured and unified manner, there need to be some formal processes for granting user access to the OT environment with its processes and OT systems, information and services including registration and de-registration (see section 4.4 and Figure 4.3 as well as section 5.5.2.3).

Ensure that any privileged, or elevated, access rights and authorizations are restricted and closely monitored. A formal review process should be defined and reviews of all user accounts with their access rights and authorization need to be conducted regularly (preferably at least every three months to close/inactivate any not needed ones). Any privileged, or elevated, user access rights and authorizations should be reviewed at least every three months too. Thus, concerning identity management and access control there shall be defined and set up policies and requirements according to:

• Identity management

• There should be a process for creation, maintaining/ changing and removal of identities, which should be connected to the HR process for on- and off boarding, change of position/tasks as well de-boarding (see Figure 4.3)

• Preferably, user identities (userIDs), passwords and credentials should be issued on a personal basis and never shared among employees. There may be exceptions for devices and equipment etc. which can only have one user account with one password). UserIDs, passwords and credentials should be considered and securely kept as secrets to achieve accountability, traceability and accurate logging of access

• Ensure that all persons or entities, who have access rights to any of the organization’s internal IT resources, OT resources, or information, have an unique IT userID and/or OT userID for personal use. It is never an option to have the same userID in the IT and OT environments. There should be no trust across domains. If wanted, the naming standard (see section 5.5.1) can be extended to include also userIDs

• Further, the userIDs should never provide any indication of that user's privilege level, such as administrator, manager or supervisor. See the standard roles in OT systems in section 5.5.2.3

• Authentication management - passwords and other credentials

• Ensure that the allocation of passwords is controlled using a formal authentication management process. The process must be secured and the passwords kept confidential throughout their lifetimes

• Encourage the use of password management systems (i.e., a password manager solution) to achieve an efficient use of strong passwords (where possible), which are kept protected from disclosure during creation, storage, processing, transportation, validation and change

• If it is not possible to use a password management system everywhere, device a password standard for normal user accounts and accounts with administrative or any higher privileges (see section 5.5.2.3). Concerning passwords, these rules should be obeyed without any exceptions:

n Make sure that externals are never allowed to set their own passwords for accessing any of the organization’s OT assets. The reason is that externals (e.g., OT system vendors) often use the same userID and passwords at many different installations/factories/mills to make it simpler for themselves. Thus, ensure that the organization’s own employees always decide and set these passwords

n Observe that it should be clearly prohibited to use the same passwords in the IT and OT environments

• If needed and possible, two or multifactor authentication should be used to access OT assets and in particular the critical ones. A standard for two or multifactor authentication (see section 5.5.2.3) should be crafted to limit the number of solutions used.

n Preferably, all administrative and privileged/elevated access to OT assets should require two or multifactor authentication

n In case of a disconnect between the IT and OT environments, two or multifactor solutions still need to work in the OT environment (i.e., can not depend on having access to the IT environment)

• Access control management

• Ensure that the process for creation, maintaining, changing and removal of access rights is connected to the HR processes for on-boarding, change of position/tasks as well as de-boarding (see section 4.4 and Figure 4.3 as well as section 5.5.2.3). Preferably, apply the principles of least access and privileges. Administrative, privileged or elevated access rights should only be used by authorized users when needed. Else, normal user access rights should be used to avoid adding risk to operations. There are a number of access decisions to consider and then decide upon for how this should be set up and enforced to be practical and secure:

n How to access the organization’s IT environment from the OT environment?

n How to access limited parts of the IT environment from the OT environment?

n In general, there should not be access to the OT environment from the IT environment unless using the standard remote access solution. In such cases, the access should be limited to only the necessary OT assets

n Whom and how should these have access to the OT environment (while inside of the OT environment) and which parts of it (i.e., segments, zones or sub-segments, equipment, devices, etc.)? Ensure that granular access is enforced and that no general access is allowed since that can create large risks. Some access decisions to make are:

• Who should have access to engineering workstations, operator stations, servers and applications?

• Who should have access to information resources and source code etc.?

• Who should have access to the OT environment’s documentation or parts thereof?

• Who should have access to operating systems and have rights to change or update these, or to change configurations or set ups?

n Who should have access to Internet, web sites or social media etc. (which should normally not be allowed) from within the OT environment?

• Principles for access – rules for logging up and logging down

• Make a standard for how access should be set up, i.e., standard account logon rules, (see section 5.5.2.3), which stipulates how and what can be accessed when logged into the OT environment. Proposed is to use the common rule that it is OK to log up, but logging downwards should require log out prior to logging down

• External connections and remote access

• Ensure that any external connections (i.e., transfer of data in and out of the organization) and remote access (i.e., access made from outside of the OT environment or to a protected OT network segment etc. within the OT environment from another segment) shall be made according to the external connections and remote access standards (see section 5.5.2.3). All decisions made by an authorized “Remote Access Responsible”, concerning external connections and remote access should be documented (i.e., who, what, when, and why). It is important that the identification and authentication of these users have a high level of accountability and that there are logs and traceability concerning assets accessed, actions, session durations, and which external connections that have been used. Preferably, decide upon rules such as:

• Each external connection and remote access session shall be time limited (e.g., 15/30/60 minutes. Avoid allowing longer sessions. Preferred is that a new session is set up if there is a need for more than 60 minutes durations)

• All user accounts or similar configurations for external connections and remote access shall be time limited (i.e., have an expiration date) which require renewal. A maximum time should be set and that should preferably not be longer than six months. As such user accounts or configurations near the limited time, an email should be sent out to the responsible manager for extending or the user account or configuration should be automatically disabled (and removed after an additional specified time)

• For each external connection and remote access, ensure to assess the risk and apply necessary protection level based on who gains access to the data or other assets. The OT data’s or asset’s classification should guide the protection level requirements

• Ensure to stipulate that any remote access made to the OT environment by, e.g., consultants, suppliers, or system/application vendors etc. are allowed under the following rules:

• It must be pre-decided which tools and actions are allowed. Further, this should be documented in the procurement agreement to regulate responsibilities and liabilities

• It should not be allowed to freely download files or bring files on non-authorized media into the OT environment! Any external files should be sent in to the OT environment using a designated and secure process. Commonly, an employee of the organization should download any needed files or software packages to a secure laptop or file share, disconnected from the OT environment, and verify/check that these files or packages are expected, virus-free and OK prior to transferred into the OT environment

• It should not be allowed to make any configuration changes to servers, equipment or operating systems etc. without explicit permission from an employee of the organization and as part of a work order. Further, such changes should be recorded and documented in the asset/configuration/change management systems accordingly

4.7.6 Sharing of data via external storage or cloud services etc.

It is most important to control and tightly manage what data can be shared using resources (e.g., external data centers with storage or cloud services) outside of the organization’s perimeter. Further, it should be stipulated how this should be realized. Sharing of data can be made with internal parties, external parties (e.g., vendors of OT systems or applications for predictive/proactive/condition-based maintenance reasons), or third parties such as consultants or regulatory/official bodies overseeing the operations and emission levels etc.

Commonly, sharing of data from the OT environment is made via the industrial DMZ, or any other internal termination points decided, and from there the data can be fetched or sent out further to external storage and cloud services. Avoid having direct continuous connections from the OT environment to the outside world unless these are carefully secured (see Figure 1.5 concerning ideas for termination points). Further, a good idea is to have SLAs for the critical connections based on the consequences - “what happens if the data delivered is corrupted or missing?”

Ensure that the sharing of data internally, with partners or providers, using external storage facilities or cloud services, is made according to the external connections (data sharing) standard (see section 5.5.2.3). Preferably, prior to sharing any data, a number of management decisions should be made and documented and the sharing list reviewed at least annually:

•Is it OK to share the data or information? Who is responsible?

• Who is the recipient? What is the intended usage of the data?

• Which data or information is OK to transfer out of the organization’s own networks and for what purposes?

• Which encryption and key length (unless using the standard one) shall be used for the transfer and when at rest?

• How long should the usage period be?

• What shall happen to the data or information when it should not be used anymore (removal or archiving)?

• How is the data protected “in transit”?

In addition, a special case which needs to be decided upon is how to handle any outside data from suppliers/vendors that needs to return to any OT systems or assets (such as feedback loops or optimization data/configurations). Here, it is important to ensure that the returning data corresponds to the data sent out (and also is expected).

4.7.7 Internal sharing of OT-related data on a regular basis

There is usually a need to share OT-related data and information etc. internally within an organization and, in particular, if the organization has multiple sites. Thus, if OT-related data needs to be shared within the organization, ensure that the sharing is adequately secured, set up according to purpose (if for a regular basis/continuously), documented in the asset management system, and a data sharing list reviewed once or twice a year to prevent data leaks. The documentation should include for instance the following:

• Is it OK to share the data or information?

• Are the protocols used up to date?

• Who, or what role, is responsible for the decision and that the sharing is reviewed?

• From where-to-where will the sharing occur?

• Who is the recipient?

• Which encryption and key length (unless using the standard one) shall be used for the transfer and when at rest?

• How long should the usage period be?

• What shall happen to the data or information when it should not be used anymore (removal or archiving)?

Concerning irregular or one-time sharing, make this simple and straightforward using designated protected sharing tools or internal secure email.

4.7.8 Documentation of the OT environment, its architecture and processes

To build up a long-term structural capital requires that processes are formalized, assets are cared for and maintained and that what is needed is documented. If an organization has multiple sites, it can be a good idea to craft documentation temples for the most common documents to ensure that these look the same everywhere and holds the data/information that is needed.

Thus, it may be beneficial to document the OT environment, its architecture and processes according to the organization’s OT documentation standard (with a defined set of proposed templates – see section 5.5.2.3). Further, these documents need, on a regular basis or at least annually, to be updated to reflect changes and additions within the OT environment or related matters. A documentation system, or internal sharing tool with version control, should be used to keep track of the documents and to provide granular access for those who should have access (as some of these documents will be confidential). The documents should be available for those who need them, and also in case there are any major problems or an ongoing cyberattack. Thus, a decision needs to be made if some documents should be printed or also downloaded by key roles to their laptops etc.

From a disaster recovery perspective, some documentation concerning for instance how to configure access control, network devices or equipment, may need to be available close to where the spares or replacement equipment on the shelf are kept. The reason for this is to enable short down times and a high level of availability.

4.7.9 Backup of OT servers and data/information

Making backups of OT assets is important and it is also important to understand what the asset do, what needs to be backuped (e.g., operating systems, firmware, software, applications, data, configurations, etc.) and how often. Many OT systems do not rely too much on historical data concerning the operations and may just need the last operational data to be able to continue after a stop or restore. There are several strategies to do backups, and the recent virtualization has improved the ability to quickly backup and restore a lot. Some potential strategies to consider are:

• Make a local backup close to the OT asset and make a backup to an OT data center once day or when deemed as adequate

• If using virtualization, a snapshot can be made often

• Make a backup to the OT data center once day or when deemed as adequate

• The OT data center should have an offsite backup that is de-linked and immutable (i.e., only connected at the time of the backup transfer and the stored backups are not possible to change/alter)

Further, restoring of OT assets needs to work when necessary and thus this needs to be tested/verified at regular intervals. Concerning critical OT assets, the restore process should be verified 1-4 times per year.

Ensure that the backups are made, according to the backup standard (see section 5.5.2.3), of all essential OT assets (e.g., servers, databases, PLCs, device/equipment configurations (where possible), engineering workstations, operator laptops, development environments/source code, and the OT documentation, etc.). Recommended is that the backups made should be separated from where they are made (i.e., in the OT data center, another building or location) and regularly

tested to read back/restore and be able to resume operation. Concerning the storage of the backups, these should be tagged and the file names should clearly indicate what asset is the origin, when the backup was made. Further, it should be straightforward to find the latest backup made. In addition, the backups shall be logically separated and de-linked from the OT environment so that the backups do not get over-written, encrypted or altered in case of a virus/encryption attack. The backup and restore arrangements for individual systems should be regularly tested to ensure that they meet the asset classification requirements (i.e., time limits) and are aligned with the disaster recovery and business continuity plans.

It is considered as good practice to have a textual description of how the operational and backup processes function together. This increases the possibility of restoring everything from scratch if needed!

Figures 4.6 and 4.7 shows examples for how backup strategies can be implemented in cost efficient manners combining resources in the IT and OT environments.

Figure 4.6 provides a high-level perspective at network segment level whereas Figure 4.7 is further detailed and refers to good practice and recommendations concerning storage from NIST23

Figure 4.6 - Backup setup example – high-level

Figure 4.7 - Backup setup example – further detailed

Remembering that having backups is necessary but also to test and verify that the backups can be easily found and are curant, as well as possible to restore. The testing and verification of backup and restore should be done regularly, and more often for critical OT systems and assets.

Further, a rule-of-thumb is to make as little backups as possible depending on requirements (as the more data there is, the more it will cost, and it will be harder to locate the backup needed for restoring the function). Thus, consider making a backup plan with links to each OT assets’ maintenance plan (where a link to the backups can be found). To keep track of any backup process changes and the “best before date” of backups (see Figure 4.6 upper right part), keep this information in the asset- or change management system.

4.7.10

Use of external media

The use of external media is related to many risks and thus needs to be controlled to avoid that viruses, malware and other problems impair the availability and integrity of the OT environment and the processes operating within.

Thus, there is a need to strictly control the use of external media, e.g., USB-sticks or disks, DVDs, cell phones, digital cameras, tablets, etc., that are brought into the OT environment. Ensure that mobile devices do not connect to Wi-Fi networks available within the OT environment. These should only use the organization’s internal apps etc. via mobile operator networks or the IT environment’s Wi-Fi networks where mobile equipment is allowed. If the organization has its own 5G network, it can of course be used if properly secured. Recommended is that any tablets/pads can be used in the OT environment if they are dedicated for specific OT use/tasks and only used within the OT environment. Further, the same rules that applies for cell phones should apply for tablets/pads.

Ensure that no external media, (if not dedicated and sanctioned), is used in the OT environment. An idea is to have different colours of external media that are used in the IT respectively OT environments (and red is often used for the OT). Further, no externals such as consultants or vendors/providers of systems or equipment, may use their own external media in the OT environment unless approved in writing (part of the work order). In addition, no external media should be allowed to be brought out of the organization’s facilities by externals unless authorized to do that. Mobile phones should not be allowed in the OT environment except for voice-calling, texting, and use of the organization’s own apps, and should preferably be connected via a mobile operator network (as stated earlier too).

Tablets/pads and cell phones should be charged via an electric wall socket and never via a USB port on any asset within the OT environment. Any tablets/pads, which are used in the OT environment, must never be connected to Internet via a mobile phone

4.7.11 Changes

Make sure that any changes in the OT environment architecture should only be conducted by employees with adequate training and competence/skill level. Further, these employees should also have “making changes, development or maintenance” or similar written as part of their work descriptions. The change management process (see OT asset management in section 4.6.1) should be followed and changes documented and recorded in the adequate systems.

4.8 OT network security

State what the objectives are for the OT network security, as this impacts the scope, coverage and protection level. An example of objectives can be as follows:

• Prevent unauthorized access to the OT environment and its assets

• Prevent damage and disturbances to the OT environment and its networks

• Prevent damage and disturbances to assets such as: OT systems, information, information-handling systems, etc.

• Ensure availability and prevent interruptions within the production/manufacturing or distribution processes

• Ensure integrity of processes, OT systems and data/ information

• Prevent compromise of assets

4.8.1 OT network owner requirements

Define and document the requirements to achieve according to the objectives above, which may be summarized to for instance: a secure, stable, robust and resilient OT environment with high availability level.

Ensure to bring up that:

• The rules and rights for administrators, users, and externals should be clearly stated/documented in OT role descriptions or similar

• Monitoring of networks with back door and anomalies detection, malware and virus protection, and logging and log analysis should be ensured

• If a very high availability is wanted, there should be redundancy of essential network services enabling islanding of OT network segments (in case of severe network problems or cyberattacks)

• Service providers, consultants or suppliers/vendors should during the procurement process get a clear statement of the business requirements to be met by the OT environment. See secure procurement process in section 5.4.1 and section 4.9 on externals resources and secure/safe sourcing in the OT environment

• If having ET assets, include objectives for these as well as they usually are required to keep a high availability level

4.8.2 Documentation of operational processes and procedures

Operational processes and procedures need to be documented and maintained over time in order to provide the support needed for new employees, or other people in need, and during any problems. The documentation should be protected and stored so that authorized employees can access these during normal and abnormal operations/situations (e.g., incident response or disaster recovery). Operational processes and procedures should be handled and managed as formal documents, and an adequate management level should accept/authorize any changes made. Thus, the management responsibility for OT operations should include the development of appropriate operational processes and procedures needed. Such may vary from organization to organization and their needs.

4.8.3 Monitoring of OT networks with intrusion detection

It may not be possible to monitor all parts of an OT environment and its networks. However, it is a good idea to monitor the OT networks where suitable and possible.

Potential events/activities to monitor are:

• Access to OT networks and equipment

• Access to essential OT servers (higher level of monitoring and logging)

• Network communications

• Execution of unauthorized software or services

• Addition of unauthorized network equipment such as routers, switches, WLAN access points or 3/4/5G dongles or access points

• Attempts to achieve control of administrative or privileged accounts

• Extensive logon attempts

• Outgoing/incoming data transfers from/to the OT environment – data is commonly transferred to well-known recipients. If there are unknown data transfers, and if particular from sensitive OT assets, these should halted/ blocked and investigated. There are tools to monitor outgoing data traffic as well

These events should be further analysed to detect anomalies, unauthorized activities/communications, addition of unauthorized devices/equipment, and potential intrusions or malware or virus establishment/outbreak, etc. Preferably, the monitoring data should be collected automatically, or manually where not possible, preferably automatically analysed and warnings/alarms should be dispatched in a timely manner to administrators on duty or according to the incident response plan. Any use or installation of unauthorized components/equipment/devices/laptops etc. as well as unauthorized software should be reported to appropriate manger/ role and be removed/disabled as soon as possible.

If the value created in the OT environment is very high, using a security operations centre (SOC) should be considered. A SOC can be part of the IT and OT operations or be acquired as a service.

If using an external SOC, define what actions the SOC actually can do within the OT environment. (Usually, it is more important to be able to continue to control the processes than turning everything off in an uncontrolled manner.)

4.8.3.1 Malware and virus protection

As malware and viruses, alike many other cyberattacks, target OT environments and the assets therein, there is a need for malware and virus protection to be combined with other security controls to form a defense, ability to discover, and an ability to contain and hinder a wide infection/spread. Thus, monitoring of the OT network with intrusion detection combined with malware and virus protection should be considered for how to get the best effect and timely warnings if something is going on. Further, to consider is if there are real-time communications involving old equipment (e.g., PLCs), protocols and network topologies, it may not be suitable to use malware and virus protection as well as network monitoring using active searching as this can hinder or impair any real-time communications and old equipment. However, consider equipping laptops, tabs/pads etc., used in the OT environment with malware and virus protection. Preferably, the protection shall be based on the organization’s standard malware and anti-virus protection, standard endpoint

detection and response (EDR)/managed detection and response (MDR)/extended detection and response (XDR) (see further in section 5.6), appropriate system access and change management controls. To prevent cyberattacks, malware or viruses to quickly infect, spread and propagate within the OT environment, the OT environment should be segmented and strict access control rules applied combined with hardening of the equipment and servers etc. used. Only authorized and wanted network traffic should be able to flow between segments, this also applies within a segment between any sub-segments. Use the security level and functionality wanted as a guide for how to do the segmentation and sub-segmentation etc.

If needed, it should be possible to “island” segments, (i.e., to pull out the outgoing network cables from the firewall/ router/switch etc.), to protect them and enable continued production/manufacturing and distribution processes. For this purpose, it is also important to define an incident management process and practice, so that everyone knows how to act.

4.8.3.2 Discovery and removal of back doors, mobile routers or Wi-Fi/Bluetooth access points

Vendors of OT systems and applications etc. will earn their trust level after good work and adequate behavior. However, initial vendor trustability must be assessed/screened prior to procurement of OT systems, applications, hardware or services, and the software and hardware inspected to ensure that there are no back doors, unauthorized hidden mobile routers or Wi-Fi/Bluetooth access points etc. If possible, new hardware or software should be monitored for a considerable amount of time prior to removal/relaxing of monitoring.

4.8.3.3 Logging and log analysis

Logging and log analysis are important tools to trace what has occurred and to mitigate. Further, timely analysis can provide insights in ongoing illicit activities enabling fast response with containment. Thus, any log servers must be very protected themselves so that an attacker cannot alter the logs to disguise or remove any traces of illicit activities. There are security information and event management (SIEM) solutions which also works well in OT environments, and these may provide more and further advanced functionality than a log server combined with an analytic tool.

Ensure that all relevant actions and activities in the OT environment are logged with accurate time stamps (use NTP-servers). Preferably, use automatic log analysis to filter out what manual log analysis can timely address. Certain activities, such as, repeated logon attempts or logons at strange times from unknown sources, should trigger automatic responses and alarms/notifications, and potentially the Incident Response Plan. In addition, log-in functionality should be set to stop or pause log-in attempts after for instance 3 failed ones.

It is necessary to keep some logs for a longer period, and this depends on type and significance for the OT environment. Within Europe and the European Union, GDPR may limit the time to keep logs unless this is agreed upon. Ensure that any audit logs keeping exceptions and other security-related events are backed up and kept securely for at least 12-18 months. Depending on applicable laws and regulations, certain audit logs may need to be securely archived up to ten years.

Establish a standard for logging in the OT environment (see section 5.6), considering what data/information to log from assets and why. The standard should be used by all asset owners and at procurement of new assets including their set up, commissioning and later maintenance.

4.8.4 Necessary network services – located in secure sub-networks with redundancy

Necessary, or essential, network services are required for the OT environment and its processes to work. Without these network services, there may be a sudden stop or gradual loss of functionality.

Thus, ensure that there is a redundancy of necessary network services for each network segment of the OT environment. This is needed to ensure availability in case of problems, cyberattacks and the need to “island” a segment. The network services should preferably be located within secured sub-networks, with minimal access and communications allowed, to ensure timely response times and availability. Examples of necessary network services are for instance: NTP (network time – which should always be the single time source within an OT environment), directory services such as LDAP or Active Directory (AD), and domain controllers, etc.

4.8.5

OT systems review, controls and audit considerations

An organization should regularly perform independent internal audits to assure that the OT security requirements are implemented and executed so that the OT security objectives are met

Any audits of OT systems or other assets should be planned and approved for to minimize the risk of disruptions within the production/manufacturing or distribution processes. Preferably, any audits should be conducted prior to risk analysis, and the audit outcome used as input to the risk analysis process. Important is that the audits must not be conducted by those responsible for developing or operating the audited OT environment and functionality.

Any auditors should always use prepared internal control routines to be conducted under limited and controlled user rights (for to not cause issues or problems). The access to system audit tools must be protected to prevent potential misuse or compromise.

4.9 External resources and secure/safe sourcing in the OT environment

Having external resources within the OT environment adds many risks as they may want to work according to their own minds as well as may want to bring in unauthorized equipment, software, tools, etc. for to make their work as easy as possible. However, the risks associated with this are very high and thus this needs to be controlled and managed to not risk unavailability, malware/viruses, and cyberattacks.

To keep the OT environment secure and intact, while having external resources on site or via remote access, it is necessary to prevent unauthorized access, damages and disturbances to the OT environment and its networks, data/information assets, information-handling systems or any other OT assets. The secure procurement process (see section 5.4.1) and business agreements should therefore clearly outline that external resources need to comply to the rules, standards and user guidelines of the OTSF for to:

• Ensure that availability is not impaired and to prevent interruptions of business, production/manufacturing or distribution processes or activities

• Keep the integrity of processes, OT systems and data/ information

• Prevent loss, damage or compromise of assets

4.9.1 Relations with external suppliers and consultants

As external suppliers of services, applications, products, etc., and consultants are more or less always present in the OT environments, the following risks and issues may need to be controlled as part of the relation:

• Avoid single sourcing - in particular concerning: electric power and essential utilities, communications (redundant fibres from different providers and non-overlapping entry points), hardware, software, competences/ skills, and manpower, etc.

• Background checks and security clearanceexternal companies and consultants may need to be background checked and get a security clearance prior to signing agreements as part of the procurement process

• Compliance to the OTSF - external suppliers and consultants need to comply to the OTSF, or else their agreement or contract may be terminated. Further, additional legal measures may be taken if the rules are purpOsely broken resulting in damages or unavailability etc.

• Trust level - as external suppliers and consultants prove themselves and can be trusted, the further they can become authorized to do as well as get corresponding access rights needed. Ensure to document in the agreement (or work orders) what they are authorized to do, when, how and under what circumstances. Non-disclosure agreements (NDAs) should be signed with the externals’ companies

• Usage of external media – the OTSF rules for use of external media, cell phones and laptops etc. apply and no usage of external USB sticks/disks, or memory/disks in digital cameras or cell phones is normally allowed. The organization’s own standard USB sticks/disks and standard laptops for externals are to be used only, and any deviations from this shall be risk assessed and documented (see more in section 5.7). Any incoming files from the outside must be cleared/checked by an employee of the organization prior to that these are used in the OT environment. The use of cell phones must comply to the OTSF rules and any additional local regulations at each factory/mill/installation

• Charging via electric wall sockets - charging of cell phones, tablets/pads, etc., must be made via an electric wall socket and never via USB ports on any asset of the organization

• Remote access and credentials - if an external is granted remote access rights to the IT and/or OT environments, the access shall be made according to the OTSF and its standards. Further, the passwords or login credentials must be kept secret, and it is not allowed to share them with others. MFA should preferably be used as well

• Passwords – the target system accounts/passwords should be set by an employee of the organization to avoid that the same passwords are used at many sites by the same externals

• Access on site - if granted access to the IT and/or OT environments on site, the access should be made using an organizational laptop. No external laptops should be allowed to be used unless there are very strong reasons to do so and this is risk assessed as well

4.9.2 Use of third parties and outsourcing

Bringing third parties into the OT environment and use of outsourcing may pose additional risks compared to if the organization conducts the same tasks or activities itself. As part of the procurement process any third party or outsourcing partner should be evaluated and screened prior agreements and engagements. A risk assessment and impact analysis should be made to decide if it is OK to use the third party or outsourcing for the task or activity.

The security requirements of outsourcing management and third-party control of selected OT networks, OT systems, etc. shall be addressed in an agreement between the parties (see also procurement-related texts in sections 4.6.1.3, 4.6.2 and 4.7.5).

The security level in the services provided by the third party or outsourcing partner, shall comply with the organization’s ISF and OTSF. Further, as outsourcing contracts may pose complex security questions, the security controls included in this document shall serve as a starting point for an agreement of the structure, content, implementation and maintenance of a security management plan. In addition, there should be contact persons for incident response and disaster recovery at both the own organization and the outsourcing partner.

4.9.3 Cloud services, AI, and external hosting and hybrid scenarios

If using public cloud services, this will require some work to find a match of the organization’s internal IT/OT security requirements with the cloud service provider’s offerings and associated cost for that. Thus, ensure that the organization’s security requirements are adequately met in the agreement with the provider (see standard process for procurement

of cloud services in section 5.7). If using public AI services, this is a special case of a cloud service and may require additional risk assessments and training on how to use these to not disclose any IPR or confidential OT data/information. If possible, it should be considered to use internal AI services instead of public ones and, in particular, where any IPR and confidential data/information may be used as input.

Always ensure that risks are assessed and documented prior to the procurement is finalized and usage of cloud services and AI. Further, make sure the importance of the IPR, data/information or functionality to be used within the cloud service or AI is clearly understood.

In case there is a need to use various external hosting scenarios or cloud deployment models, i.e. private, public, hybrid IT, hybrid cloud, multi cloud, etc., ensure to map the requirements and assess the associated risks during the procurement process (and decide if any of these are viable options to pursue).

Remember to, as part of the risk assessment, map which IPR or data/information is in focus and how the data flows between the organization and the cloud service etc. to ensure that adequate protection level for the IPR or data/information is adequately protected during their intended lifecycles and finally properly deleted/removed.

In addition, as part of the procurement process, it should be investigated how IPR and data/information is backed up and to where and for how long, how it is possible to move the engagement to another provider’s cloud service etc., incident management and disaster recovery coordination, audits of the provider’s security level, and how to end the engagement.

4.9.4 Outsourced OT software/system development

It is quite common that some, or most, OT software/system development is outsourced to OT system vendors or specialized software development or integration consultants. As the OT software and systems may comprise IPR and quite a bit of confidential know-how etc. after being developed or adapted for the organization, the outsourcing needs to be secure in many ways and several security controls applied to secure outsourced OT software development (which may occur on- or off site at the outsourcing partners’ own facilities). As this will involve both IT and OT matters, ensure that the outsourced OT software/system development complies with the ISF and OTSF requirements.

In addition, if we use external or cloud-based development environments for outsourced OT software/system development or involve further external third parties as part of the process, this all should be assessed and controlled by the organization. Further, this may include assets part of the OT environment such as engineering stations, virtual clients, IPR, data/information and licenses. Any network segments, or zones/sub-segments, part of development activities should be adequately separated from the operational ones.

4.9.5 ISF, OTSF and further requirements for supplier and outsourcing relationships

As there are many relationships with suppliers, consultants and outsourcing arrangements, it must be remembered that a chain is never stronger than its weakest links. The security level at any of these externals may have a serious impact on the organization and must therefore be kept intact, audited and revised over time. These relationships need continuous management in order to maintain the security level related to IT (ISF) and OT (OTSF) intact.

4.9.5.1 Identification of risks related to third parties and their access to OT environments

The need for risk assessments, when involving externals in the OT environment, has been brought up many times, but can never be stressed too many times since external “setups” may change in many aspects, such as, employees, ownership, financial status, etc. The use of third parties is a special case of externals, which may require a bit extra as there is no tangible relation such as with suppliers of, for instance, utilities, OT systems or other types of assets.

Any need for services from a third party, assess risks and potential consequential damage/impact. Linked to the outcome of the assessment, and if the third party is engaged, authentication, access rights, and authorizations should be decided and set up. Preferably, the agreement, or the following work order, should stipulate any responsibility, authorization, as well as restrictions. The proposed is that the OT security responsible or owner of the asset/process in focus should grant the access rights and authorizations necessary to carry out the work order.

Ensure that the agreement with the third party includes responsibilities, authorizations, as well as sanctions, (i.e., the ISF and OTSF). The agreement should also outline which security controls are necessary, e.g., secure remote access, access rights, etc., as well as how to withdraw access rights and authorizations if necessary.

If the external resources work within the OT environment, i.e., on site, they should use the organization’s standard laptops, and any other equipment needed. If any external laptops or equipment are used, it should be risk assessed and a documented decision allowing that.

4.9.5.2 Management of external resources

Concerning management of external resources, be proactive and think in advance to minimize any risks and maximize the potential effect or outcomes. Thus, make sure to try to identify and assess any risks of using an external resource in advance. Further, also consider, in advance, what is needed for the external resource to carry out the work order(s) in such an efficient and secure manner as possible. If the assessment points to that security controls are needed, these should be included in the agreement or work order(s).

4.10 Physical and environmental security and safety

If there is no specific policy or similar already available as part of the overall management of an organization, the rules for physical and environmental security and safety can be added here as well. Ensure to involve all the specialists and competencies required to get this correct and adequate according to legal, regulatory and business requirements. As a number of supporting systems are related to physical and environmental security and safety, these should be considered to reside within the ET environment or not be connected to any environment at all (i.e., be isolated). See Figure 1.4 for potential ideas on how to connect, if to connect, the ET environment to the Industrial DMZ. Supporting systems that may reside within an ET environment are:

• CCTV and perimeter alarm systems

• Entrance, passage and lock systems

• Fire and gas alarm systems and fire distinguishing systems

• Leakage warning systems (chemicals, oils, liquids)

• Environmental threshold value measurement systems – to stay within limits of environmental permissions and laws/ regulations

4.10.1 Physical security and safety

The rules for physical security and safety are critical to avoid human injuries and having unauthorized persons in dangerous, confidential or critical parts of a factory, mill or installation. Thus, an elaborated plan for access rules is required along with having multiple layers of physical security and safety controls, which combined should provide an adequate level of protection. Further, there should be a role with responsibility for physical security and safety (or work environment security and safety etc.).

The need for overall physical protection, i.e., security and safety, should be analysed at regular intervals or when there are large changes planned or made. The analysis, planning and actions should cover at least the following:

• Outside perimeter and internal areas:

• External risks – depends on nature of operations, organized crime’s interest in operations or assets, and national politics/geopolitical status etc.

• Visitor entrance – consider having two stages where the first is a locked waiting room where visitors need to be picked up by host and there is an additional locked door to the offices and operations

• Visiting areas – what areas are visitors allowed to be in with a host and/or alone. Suggested is to have a colouring system to indicate where visitors can be alone and not (e.g., green – OK, red – with host, and black – confidential/not allowed)

• Confidential areas – what areas are visitors not allowed to be in at all? These areas should require access control and also be marked with “No visitors allowed”

• OT assets should be within areas that are accessible only for authorized personnel (internals as well as externals). Expensive and crucial assets should be extra protected and have CCTV or similar monitoring

• Protection of Internet cabling, internal network cabling, and internal network equipment – these needs to be physically protected to avoid unnecessary disruptions as well as intentional tampering. Key locations should be monitored with CCTV and logical and physical accesses logged as well

• Protection of data centres, high voltage/transformer rooms, or other dangerous and important parts required for the operations - these facilities may require special fire distinguishing systems, with entrance logs and trainings required to be allowed to enter

• Incoming raw materials – if there are risks for fires, leakages or theft etc. at the incoming temporary storage area this needs to have adequate monitoring and protection level. Further, the incoming supply-chain should be analysed to ensure a timely inflow of raw materials (as well as services required) to avoid standstills or unplanned stops due to a missing ingredient/component with consequences of having no space to store it all

• Outgoing products or components - if there are risks for fires, leakages or theft etc. in the temporary storage area this needs to have adequate monitoring and protection level. Further, the outgoing distribution chain should be analysed and planned to ensure that a timely outflow is enabled and avoid having no space to store products produced or manufactured

• Redundancy of critical utilities – ensure, to a reasonable and economic extent, that there are two or more internet providers with separated incoming cables, redundant internal networks (to ensure that the warning systems and monitoring also works beside the operations). If possible, ensure to have redundant utilities (or a stock/storage for at least the time required to in a controlled manner shut down the operations) regarding water, electricity, heating, cooling, etc.as well as to have key network and OT systems components (e.g., firewalls, routers, switches, PLCs, etc.) in stock. Another option is sharing a joint stock with others/partners having a similar set up of operations

• Dangerous and hazardous areas – if there are dangerous or hazardous areas, where there are areas where dangerous chemicals are stored or handled, large vehicles, dangerous machinery, or robotics moving around autonomously, etc., there needs to be signs and warnings as well maybe also containments to prevent workers from exposure or injuries. Further, this may require mandatory trainings of workers, third parties or visitors prior to being allowed to enter into such areas

In case of major problems concerning the buildings or locations, it should be investigated and planned for having extra sites to continue the possible operations from. It may be hard to quickly move production environments or having a “warm site” to move over to, but this should be considered anyways. Concerning administrative and other personnel, who are not essential to have on site, a plan for having a shared location with others or work from home are options. This is part of business continuity planning and has become a smaller issue since the recent pandemics, where remote work was supported by improved remote access solutions and collaboration tools.

4.10.2 Environmental security and safety

The laws and regulations concerning environmental security and safety are strict in most countries and, in particular, within the EU. This area requires expertise regarding security and safety but also for all permits that may be required to operate an organisation with production and/or manufacturing as well as incoming supply-chains and outgoing distribution-chains. Among other matters to analyse and plan for, there are those that may have severe impact and others with less impact shortterm or long-term. Examples of such areas include:

• Alarm and detection systems – to quickly detect any signs of leakage of fluids, oils, chemicals or gases. Escalation procedures are needed for fast and safe remedy

• Emergency storages of leakages or spills – if a leakage or spill occur, there may be a need to contain it and hinder further spreading prior to sanitization

• Cleaning and/or filtration of process water etc. –commonly, process water is cleaned or filtered to enable either re-circulation within the process or disperse into the sewage system or outlet. In addition, excess heat from process water can be harvested and re-used for heating etc.

The responsibility and permits concerning the environmental security and safety are most important to uphold as there may be hefty penalties in case of non-coherence. Further, there should be a role with responsibility for environmental security and safety to coordinate this area

4.11 Business continuity, disaster recovery and incident management

Commonly, there should be general plans for incident management and business continuity management as part of the management system (see Figure 1.1). A good idea is to have an overall and general process33 including both as well as disaster recovery, supported by checklists and facts which may be handy to have in stressed situations. It is timesaving to have team-members defined in forehand, and do not forget to involve people from the production and distribution, since they have the last saying regarding actions taken in a live system. Usually, the manufacturing process is more important than a criticality patching. If the systems are correctly setup/ segmented, you can take a couple of points away from the CVSS-score.

Simplicity is key and complexity banned as part of such processes. The focus of a business continuity plan should always be an organization’s critical processes, which are the processes that must work and continue due to for instance legal/regulatory requirements, service level agreements, contract/agreement stipulations, etc. Thus, regarding most manufacturing or process industries and critical infrastructures, the critical processes are:

• Incoming supply chain (input required to keep the following processes going – may need to be resilient and secure in some parts)

• Production/manufacturing process (including maintenance if necessary)

• Distribution process (may need to be resilient and secure in some parts) with outgoing supply chain

Thus, a business continuity plan helps to prioritize and focus an organization at a time with serious problems and there should

be a trained crisis management who leads, plans and initiates necessary actions for to get back to a normal situation again. These processes need to have supportive utilities (electricity, water, cooling, etc.), production/manufacturing equipment, IT/OT/IoT systems, trained personnel, a functioning work environment (and if the premier work location is not available – this may require having one or more prepared replacement sites which can be cold, semi-warm or warm), and any other critical materials required. Thus, there can be a need to have replacement/reserve procedures, from one to three, for each step in the critical processes to keep these running under various conditions. If there are not supporting systems working, there should be manual procedures to keep the critical processes going (and this requires regular trainings and man-power available). Naturally, it is a problem if there is only one main factory/mill or installation in case there is a major disaster and it burns down, get blown up or is physically destroyed in other ways. Concerning critical infrastructures, these should be built with redundancy, certain distribution and avoid having single points of failure. This thinking can also be applied to manufacturing/process industries although it may be more profitable to have fewer large factories, mills or installations.

To start with, an overall and general crisis management/ business contingency process, including some general crisis management, can be used to set the scene and provide understanding of how escalation from an incident to a crisis situation should be made (see Figure 4.8). Further, regarding general crisis management, some events mainly related to physical security can be put in a general physical safety/security policy (see Figure 1.1) and comprise for instance: evacuation procedure/plan and gathering points, what to do in case of intrusions of hostile person, threats made via phone or mail, procedure in case of suspicious packages are received/opened, etc. Such a policy should be tailored for each location.

33 Lindström, J., A model to explain a business contingency process, Disaster Prevention and Management, 21(2), 2012, pp.269-281.

As can be seen in Figure 4.8, the process starts with the normal situation, i.e., intelligence gathering phase, which includes monitoring of the surrounding world/contexts and vulnerability management with updating and patching of known problems for to avoid any incidents. However, if and when an incident occurs the process moves to the incident response step where an incident response team (or more such teams if necessary) is activated to try to locate, contain and mitigate the incident. If this is not possible and certain systems get affected, the disaster recovery step is also activated with as many disaster recovery teams as needed trying to resolve any issues. If there is indications that it is not possible to contain, manage, and timely mitigate as it starts to affect more systems, this can be called a “situation” and needs to be escalated from either the incident management or disaster recovery to the assessment team, which starts the situation assessment phase for to de-

cide whether it is a “crisis” or “no crisis”. If there is “no crisis”, the responsibility is returned back to the incident response and disaster recovery teams. An example of incident response process can be seen in Figure 4.9 and concerning an example of a ditto for disaster recovery in Figure 4.10. However, if the assessment team decides that it is a “crisis”, then they will initiate the emergency phase and the business continuity plan and quickly assemble the crisis management team to start to investigate, manage and mitigate the crisis. When the starting up has been completed (1-2 hours maximum) then it is time to move to the crisis management phase and care for all that need to be catered for. When all is catered for, the process should move into the recovery phase and manage all that is required for to get back to an as normal situation as possible again. To manage the problems, a simplistic business continuity plan/process can be used as indicated in Figure 4.8.

Figure 4.8 – Overall and general crisis management (business contingency) process based upon Lindström (2012)

Figure 4.9 – Example of an incident response process

Regarding disaster recovery planning, there should be such plans for each critical system within both the IT and OT environments and a general disaster recovery process can be used as part of the individual plans. As there is likely a need to have multiple disaster recovery plans, a general template should be used to ensure that all information on how to shut and close down a system in a controlled manner or make an emergency stop, preferably without losing data or transactions, as well as how to in a controlled manner start up or restore the system from backups as well as if needed re-install, configure, and re-start it. Furter, all contact information to necessary internal roles, external partners/consultants/ vendors, etc., should also be part of the plans. Remember to only have what is needed – and nothing else, as that may confuse instead of help during a stressed situation.

If the business continuity plan and crisis management team is activated, this can be organized alike in healthcare where there

is firstly and emergency phase, which should be short and decisions made to start up all that is required and then transition into the crisis management phase, where the mitigation may take as long as it needs. As the mitigation comes to an end, a transition to the recovery phase, where a normalization and management of backlogs etc. should be made prior to ending this phase and declare the crisis as over. Further, as can be seen in Figure 4.11, the durations of the phases and number of involved are indicated. It is important to understand this, as a lot of resources and effort will be required if moving into a “crisis” and manage it all the way until it is over.

In addition, to manage general crisis situations, which are events not having direct impact on the critical processes but on the future business, the organization’s brand and trustworthiness, the business continuity plan can be extended to include basic management of such as well using the same process if necessary.

Figure 4.10 – Example of a disaster recovery process

Figure 4.11 – Example of a business continuity plan/process

The business continuity-, incident management-, and disaster recovery planning need to be maintained, and the involved teams/roles must train on a regular basis. Thus, the overall management system should comprise a plan for awareness building, training, and education as well as the maintenance plans34 which can preferably be part of the strategic plan (see Figure 1.1) to minimize the number of documents. Remembering is that the better prepared one is - it is likely that if having a serious event, or a crisis, the faster it will take to recover, and the consequences will be smaller as well.

4.12 Non-compliance and reporting

A policy, or directive, should comprise the rules for what should be accomplished as part of the strategic (long-term), tactical (mid-term) and operational (short-term) planning and activities. Thus, there needs to be rules for what happens if someone, either employee of the organisation or an external, such as consultant, supplier, or board member, etc., does not comply to the OTSF and general management system (see Figure 1.1). A common way of managing non-compliance is to have a process with an initial step of making this aware and discussing what is wrong with the person involved. Hopefully, this will solve most issues. If the actions are repeated, then a follow up is needed and a disciplinary procedure may need to be initiated. If the intent is non-malicious, this may lead to required trainings and awareness building in order to change the behaviour and also add necessary knowledge to avoid the issues in the future. However, if the intent is malicious, it should be stated that this may lead to revoked access to the IT

and OT environments as well as further disciplinary actions such as change of role, responsibilities, authorizations or termination of employment. In case the intent and results are very serious or violates laws and regulations, this may further lead to reporting to police and other authorities involved.

The non-compliance and reporting should be aligned between all the different policies part of the management system. The HR policy, and any potential HR handbook, should form the foundation concerning this matter.

4.13 OTSF governance

To ensure governance of the OTSF by top management, a good idea is to select the 15-20 top problems and keep track of these and their progress. As problems get mitigated, new one should be added and tracked.

The job to do this is the responsibility of the Senior manager for whole operation above factory/mill/installation, but it is often delegated to the CISO and the IT/OT security coordinator (see the roles-related sections 4.3.1 and 4.3.2). However, the important thing is that this is continuously conducted, and the 15-20 top problems kept up to date and exchanged for new ones when needed. The “governance list” should preferably be used as input and reported at monthly or quarterly top management meetings. If we do this, the OT area and its security becomes part of the top management agenda and not only when it is time for new investments or KPIs related to production and distribution are reported and discussed.

33 Lindström, J., Samuelsson, S., Hägerfors, A., Business continuity planning methodology, Disaster Prevention and Management, 19(2), 2010, pp.243-255.

Part 5 – An outline for an OTSF continuing with the standards level

Some matters need to be standardized to always get the same, or at least very similar, benign output from an “activity”. Examples of such are: backups, hardening of assets, remote access solutions to use, how to set up external connections, how to configure laptops and how to handle USB-sticks in the OT environment, or share data via data centres or cloud services. Thus, this can entail standardized processes, procedures, configurations, set ups, or selections of which “solutions” that must be used for different purposes or contexts, etc. The idea is to have as few standards as possible, but enough to keep the OT environment safe and secure. Thus, you need to consider what your needs are and what support your OT organization needs in terms of standards. If the staff is experienced and the employee turnover is low, there can be less whereas if the staff is inexperienced and the employee turnover is high – more standards may be needed.

5.1 Standards related to organization of OT/OT security

Currently, there is no proposed standards related to organization of OT/OT security except for the roles and responsibilities and a potential need for an audit process related to the OTSF, which can be found in section 4.3.3.

5.2 Standards for HR-related security

The first HR-related security process is the start of a chain of processes/activities which should be initiated by HR. HR should together with appropriate managers handle employees during their whole employment lifecycle to facilitate adequate role descriptions, including authorization and responsibilities, with related access rights. The access rights and authorization should be dynamic and be adapted to only what is needed depending on role, tasks, and the need for data and information, etc. Thus, the principles of least access rights and least privileges should be applied and where needed also the “two-hands” or “threehands” principles if changing very important assets, such as, firewall settings or making decisions which can have large impact or costs. Thus, a good idea is to define the necessary processes for:

• On-boarding – what activities are to be initiated, what assets and privileges should be provided (keys, pass cards, credentials, laptop, mobile phone, access rights and authorization, remote access, etc.), rules of employment and non-disclosure, ISF and OTSF walk through, safety/ security and other needed trainings, etc.

• Change of position/tasks – what activities are to be initiated, what assets and privileges should be repossessed/changed/provided, trainings needed, etc.

35 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

36 https://csrc.nist.gov/pubs/sp/800/30/r1/final

• De-boarding - what activities are to be initiated, what assets should be returned (e.g., keys, pass cards, credentials, laptop, mobile phones, etc.) and privileges (e.g., access rights, authorizations, and remote access) should be inactivated and removed at certain dates/times

Commonly, visitors and temporary contractors, etc., come and stay for a couple of hours, or a day or two, and need to be managed so that safety and security are upheld. Thus, a visitor process should be devised to manage all that is needed as smoothly as possible according to:

• Visitor process - for to know whom are on site, where they are, how to reach them (mobile phone or walkie-talkie), what they do, who is responsible for them, if they need safety training to be let in, for how long should they on site, when they leave the site, etc. All this should be recorded and documented, and this is needed in case of an emergency evacuation or accident to know who are on site and where. The visitor process should preferably be applied to temporary contractors, third parties, employees from OT system vendors, etc., that are not on site on a regular basis with an additional work order and instructions. If on site on a regular basis, these should probably have adequate safety training and time limited pass cards etc. and necessary work orders with instructions

5.3 Standards concerning OT risk and availability management

It is advisable to craft a process for OT risk management and supporting templates to speed it up and ensure that what are needed/wanted are part of the risk assessments and analyses (see proposed templates in section 5.5.2.3). There are many existing standards/frameworks/processes that can be used as a basis and which can be adapted to fit an organization’s OT risk management, c.f. ISO 31000, ISO 27005, NIST Cybersecurity Framework (CSF)35, NIST SP 800-30r136, and NIST SP800-82r337. Thus, study these and take what is appropriate from these and craft your own processes and templates needed. It is further suggested that there is a role with the responsibility to keep a risk register (i.e., collect and keep/register potential risks) and who leads risk assessments and analyses on a regular basis. A common practice is to separate risks that are possible to quantify (e.g., in terms of costs if they occur) and those that are qualitative (risks that are hard to relate to a cost but may have a small to a large impact in terms of trustworthiness, availability, confidentiality or integrity, etc.). The following mitigation of risks may need allocation of budget, efforts and to free up staff from normal routine work and mitigate the risks.

37 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf

Further, it is also advisable to craft and process for OT availability management so that the work is made in a structured manner and that no major issues impairing availability are missed out. Proposed is to have a role responsible, e.g., the same OT security responsible, who alike for the risks should keep an availability problem register and lead availability management meetings on a regular basis. The objective of such meetings is to find the root causes to issues that have occurred and either avoid re-doing something causing this or make changes to hinder these from occurring again. Some mitigation solutions may involve training of staff and, alike for risks, create an awareness that availability is also key for most production/manufacturing and distribution processes.

The registers related to both processes above may be similar, and the same system could potentially be used if the input can be labelled as potential risk or availability problem Sometimes, the input may need to have both labels. Common content used for risk registers are:

• Asset name/ID, description, and where it is located

• Vulnerability or problem description

• Threat or event that triggers

• Potential probability that it occurs (initial estimate to be refined during analysis)

• Potential impact if it occurs (initial estimate to be refined during analysis)

• Risk or availability issue description

• Relation IT/OT environments in terms of what happens within the IT environment if changes or problems occur in the OT environment (and vice versa if it is an IT/ information security related risk)

• Categorization (e.g., trustworthiness (T), availability (A), confidentiality (C), integrity (I))

• Ideas for mitigation or how the issue was initially resolved or temporarily fixed

• Possibility to make attachments of documents, images, etc.

• Possibility to add additional free text needed to frame or describe further

To keep the register, it is important to transfer notes on paper and conversations into text and store that, or else there is a risk that it all will be forgotten, and it all may happen again. Thus, it is important that all OT staff knows whom to contact concerning risks and availability issues.

To remember is that both the above processes should consider resilient secure supply- and distribution chains for to ensure that the critical processes are operational, available and the integrity within specifications for both processes and output produced

As part of the OT risk management process, it is advisable to make a report and conduct a second walk-through of it to finalize the assessments and analysis. To assist management and budget decisions, it can be a good idea to craft a trend analysis in terms of number of risks, average risk level, etc., for to learn if the “risk environment” changes and needs more attention and resources. Subsequently, the report should be submitted for management review and prioritization of which risks to continue to address. Following, a further detailed business impact analysis should be made for the by management prioritized risks. Select which to continue to address and mitigate these. In addition, these risks should be investigated for how to mitigate them through use of:

• technical/logical/administrative controls, or

• change of staff or externals/third-party behaviour, or

• need to change production/distribution processes, or

• need to change production/distribution environment, or

• need to change the OTSF

Following, make cost/effort estimations to complete the assessments and analysis. Having made thorough investigations, now it is possible to decide upon which risks to mitigate and to assign resources and budget. Finally, document all the mitigated risks as well as the remaining/residual risks.

To remember is that any imminent risks and/or availability issues found during the processes shall be immediately flagged and highlighted to management for mitigation

5.4 Standards pertaining to lifecycle management of the OT environments

5.4.1 A secure OT procurement process

As the lifecycle of OT assets are long and changes to these may have large effects, there is a need to do some thinking in advance regarding procuring and making changes to OT assets. Concerning procurement of OT assets, this process is often managed by the procurement part of an organization and thus that part owns the process. Therefore, the OT procurement process should be a link to the actual process document owned and maintained by the procurement team working on OT assets. It is important that the process comprises a number of steps and investigations, which may differ from procurement of IT assets or other types of assets. Some process steps which are good to have are to:

• Always involve the OT security responsible from the very beginning (as procuring OT assets that are not secure may lead to very expensive measures later on or even that they can not be connected to the OT network)

• Check if the templates with procurement texts and project handbook are applicable (see templates in section 5.5.2.3)

• Follow a basic OT security checklist on mandatory requirements – have a general part, an advanced part, and for connected assets. This checklist should be made and kept updated by the OT security responsible and may be somewhat different depending on the type of OT asset and risks related to those. Examples of items to have here are:

• Upgrades of OT software and hardware – what is included in the initial procurement cost and running/maintenance costs?

n Are the operating systems and OT software (applications) including all that is needed for the server and client sides?

n Are works related to upgrades and/or migrations included?

• Operating systems support and upgrades – will OT software upgrades from one operating system level to another be included (for instance moving from Windows 10 to 11)?

• What are the requirements for IT/OT security?

n Availability, integrity and confidentiality aspects?

• IP-address set up wanted

• Installation and configuration of procured OT assets. No unmanaged OT workstations or servers should be created, and all OT workstations or servers should be installed on hardened base installations

• Are there needs for external vendors or third parties to have remote access (from the outside) or to send out/in data etc. using an external connection? These needs should be confirmed and outlined according to the standards for remote access and external connections (and not according to the vendor’s wishes):

n Remote access from outside (as well as perhaps also within the OT environment)

• For granular access to assets - use the solution which is integrated into the asset management system, and/or

• For general access to assets - use the standard VPN solution (which is harder to limit access for)

n External connections – data/file sharing options

• Sending out data/files via cloud – then use specified cloud solutions

• Sending and receiving data/files using automated data exchange – then use specified automated data exchange solution

• Data/files sent/retrieved/received from and to OT systems directly – all data/files must be controlled by an employee of the organization using anti-virus etc. before brought into the OT environment

• Backup of OT asset and data – this should be made according to the backup standard and assigned backup system(s) should be used and backups made on a regular basis. Further, decide upon the retention time of the backups as that may have an impact on the total data storage needed to procure

• Will there be a need for development and testing? See section 4.6.2 for more information (and here integrations into other assets and systems may apply too). The following should be regarded as well:

• The overall OTSF requirements are always mandatory and that the security level planned complies with the constraints of the OTSF and ISF security architectures

• Any additional requirements resulting from a risk assessment/business impact analysis (BIA) must be covered

• The level of testing needed concerning security functionality including any constraints for test data

• The procedures for:

n Incident reporting and handling

n Disaster recovery, how to make backups and rollbacks/recoveries

n Decision and control of access rights

n Change requests

n Business continuity planning additions needed (if the asset is of critical nature)

• That the asset’s level of security is adequate. Ensure this by having the development team present the vulnerability analysis with technical, administrative and logical measures taken to protect the asset

• Make the requirement specification where OT security requirements are included (as well as security-related test requirements if applicable) and ensure that these are adequately documented. Iterate the requirement specification with all who are concerned and get it signed off by the OT security responsible prior to moving on. In particular, necessary integrations to other OT systems, data sharing, and remote access, etc. need to be sorted out and how to do it in a secure manner

• Potentially, assign a design review board to review the plans/architecture/ideas for how this will fit into the context where the asset is supposed to operate. Also, review and consider for how to maintain and uphold the security and functional levels of the asset over time

• Is there a requirement that the incoming supply chains, related to the OT asset’s hardware, software, services and maintenance, etc., are resilient and/or secure? If yes, this should be investigated and discussed with potential providers, third parties and consultants, etc., as part of the pre-qualification of such.

• Make a pre-qualification of providers (and whom else that may be needed)

• Ask qualified providers (and whom else part of the procurement) for a request for information (RFI) and/ or offer (RFQ) and analyze how it corresponds to the set of requirements posed. Make a risk assessment/analysis if the new OT asset can be connected or not to the OT environment and which providers’ RFI/RFQ can be put forth to the next step in the procurement process evaluation

• Who wants to procure the OT asset? Make an OT system maintenance plan (see templates in section 5.5.2.3) to outline the operational and economic responsibilities – and do not continue with the next step until this is sorted to avoid future issues and irresponsibility problems

• Invoke the design review board (if previously engaged) to walk through the offer (RFQ) and to report if there are any remaining issues or not. Further, if there are any changes needed, this needs to be agreed upon among all involved parties

• At the step where one or more alternatives is/are proposed, this should be granted by the OT security responsible and planned asset owner prior to accepting it and moving towards making an order. Thus, a final decisions meeting (GO/NO GO) should be held with all necessary parties with responsibilities and authorities present. This is to ensure that all is OK prior any “GO” decision

• If the decision is “GO”, the procurement process continues and contract/agreement etc. is signed

See Appendix A for an example of what a Request For Information (RFI) to a supplier can comprise. Further, see Appendix B for an example of how a Delivery Limits statement can be written to clarify responsibilities among the stakeholders involved etc.

5.4.2 Change management process

If there is no general change management process defined, for instance within the IT environment’s processes related to ITIL etc., such a process should be defined and set up plus supported by a change management system to keep track and record all about the changes. The change management process should facilitate that all involved can see what is going on (cock-pit overview). Further, the process should ensure that IT and OT departments as well as the IT and OT security responsible roles meet, plan together, assess risks, and coordinate when pre-conditions needed should be ready for the change to be executed. This way, changes can be planned and prepared for and be executed faster and smoothly without friction between the IT and OT departments due to adequate communication and coordination completed. If possible, each asset within the asset management system should have a link to the changes if being involved.

5.4.3 Configuration management process

Further, if there is no configuration management process defined elsewhere, like for the change management process, such a process should be defined and set up as well as being supported by a configuration management system. The configuration management process should facilitate that there is an overview, and details whenever needed, of each asset’s hardware, software application and platform/OS, etc., configuration, patch and update levels. The addition of new assets and continuous updating of their configuration status need to be automated as much as possible or else this will not work in the long term. Thus, it should be possible to find out which assets have been updated or not, and if any assets comprise any open-source components (which can significantly reduce the amount of time and accuracy when trying to locate for instance where the Log4j framework is used in case there is an incident or severe vulnerability discovered). The configuration man-

agement system therefore needs to be able to carefully scan assets or import updates from other sources, take input from patch/update services and manual input, without disrupting the operation of the assets and processes these are used within. The asset management system needs to be integrated (or have links) with the configuration management system and potentially also the change management system to be able to track decisions and changes or configurations made.

5.4.4 Obsolescence management process

In addition, if there is no obsolescence management process defined, such a process should be defined, crafted, and supported by an obsolescence management system (or if there is such a module within the asset management system). Obsolescence management pertains to keeping physical spare parts to machines, equipment, servers, etc. in own stock (if having multiple internal sites this can be split up between these), set up a joint stock with external partner organizations having the same or similar needs, or set up longterm agreements with suppliers to ensure a timely supply of spare parts during the lifecycles of the assets. This is commonly a costly process and may require large storage facilities if the plethora of assets is diverse and spans long asset lifecycles. Further, the necessary software (i.e., applications, platforms/ frameworks, BIOS, firmware, OS, etc.) must also be stored to cater for a potential restore process of old assets (and thus this is also somewhat connected to backup/restore and disaster recovery of assets). The obsolescence management system should be connected to the asset management system to keep track of the storage levels of spare parts and software etc. for each asset. Further, it should be considered how to ensure that the software is stored and how to ensure that this is made during an asset’s whole lifecycle (which may require integration with installation processes, patch/update services, etc.) and that there is digital storage alongside the physical storage.

5.4.5

Secure processes and procedures for OT asset lifecycle management

The asset management, change management, configuration management and obsolescence management systems must be highly secured as these are key to the lifecycle management of the OT environment and its assets (and further comprise a lot of sensitive information for hackers etc.). Therefore, ensure to keep these systems in a highly secured network segment or sub-segment/zone and all administrative access or when making changes should require 2FA/MFA using encrypted communications.

Outline a procedure for classification of OT assets which is invoked regularly or at procurement of new or end-of-life of old OT assets. Suggested is to have different levels to support focus and assignment of resources for the management of the OT assets during different situations and phases of their lifecycles.

All things come to an end, and there is a need for a process for secure end-of-life and disposal of OT assets to ensure that there is no sensitive or confidential data/information, IPR or recipes, network configurations, or similar left in an asset prior to that key parts of it are deinstalled, destructed, recycled or the asset gets a new lifecycle elsewhere after refurbishment and reconditioning. A problem with a new lifecycle, or down-cycling, is how to maintain that software updates, spare parts and support can still be available for the new context.

5.5

Standards related to OT environment architecture and security

5.5.1 OT reference architecture standard

As an OT reference architecture standard will require several pages, this standard can preferably be an own document and be referred to from here. The standard can also comprise, at the end of it, three common scenarios for how to approach planning and implementation of OTSF and its OT reference architecture standard. The three scenarios are greenfield, brownfield with a lot of change needs, and a rather up-to-date site, as outlined later in section 7.1.

The standard may comprise the following, which may be augmented or changed depending on need and context. It is important to provide enough background and specific information to enable experienced and new OT staff and third parties/consultants to work efficiently and avoid expensive mistakes and re-implementations.

Background and scope

Describe and outline the following to provide a better understanding of why this is needed and provide motivation:

• About the OT reference architecture standard –provide a general background and also if there are some standards, frameworks or models that should be foundational or used otherwise

• Objective, purpose and business needs – set the expectations and the intentions of investments and efforts made regarding OT, OT security, and the quality of OT network services, to enable the processes and their assets operating within the OT environment

• Any legal and regulatory requirements - what are mandatory requirements to adhere to and are there different such if being a global organization? Outline the most important and refer to the analysis made regarding what set of requirements to consider (see Part 3)

• Reading instructions – outline the purpose and meaning of the standard and that it constitutes a set of principles to use rather than firm rules. If making deviations, such should be well considered and the additional risks assessed

• Terminology and abbreviations – list and define the most common terminology (ISF, OTSF, DMZ, Levels 0-4/5, etc.) and abbreviations used

A nomenclature or ontology may also be handy to have to outline how the organization of the OT area is made (e.g., enterprise, site, production area, production line, production cell, station, entity and component). Further, a hierarchy model should be outlined to establish the relationship between DMZ, IT environment (or enterprise security zone if using the Purdue model), Industrial DMZ, OT environment (or industrial security zone if applying the Purdue model’s terminology), OT segment (or zone of using the Purdue model), OT sub-segment/zone, area, and isolated area (e.g., unmanaged OT systems that are too old and insecure to be connected). Add some figures/diagrams to increase the understanding of all this if applicable.

OT reference architecture standard

• Reference OT architectures, models and industrial standards that are to be used/applied – outline which/any reference architectures and/or standards that are to be used or are foundational. Add figures as that increases the understanding for all involved. Examples to consider for general use are: ISA-95, Purdue model, IEC62443 series, and what is useful from NIST and ISO etc. (see Figure 1.2 and Part 2). To note is that this has impact on the procurement process and lifecycle management of assets as well

• Overview of OT architecture standard – start with summarizing the main principles for the OT architecture, how to secure it, and how to maintain it in a secure manner. How should different networks be connected (e.g., applying zero-trust), and general rules for which equipment that may be used within the OT environment, and principles for isolation/islanding can be appropriate to have here as well. Add figures to improve understanding. Further, how and where to have external or internal data centers, use of virtualization, backup/restore principles, resilience/redundancy principles, as well as incident management and disaster recovery principles should be outlined in combination with that there should be maintenance plans for all major assets (comprising for instance ownership, responsibilities/authorities, budgets for maintenance and any operational aspects). In addition, physical and logical access principles should be stated in combination with how to protect the assets plus if there are any parts of the OT environment that need to be controlled in terms of temperature, humidity, or have clean air, etc. Lastly, access principles such as “principle of least access” and “need to know” etc. should be stated and applied to all OT assets as well as the whole OT environment in general. If there are elements or clusters of ET systems, outline how to put these in a potential ET environment and if/how that should be connected to the IT/OT via for instance the industrial DMZ (see example in Figure 1.4)

• OT architecture standard – add what is required here. Below, there are a number of commonly needed areas/ items to consider to have a flexible and scalable OT environment with high availability, integrity, confidentiality as well as network performance:

• OT network with levels, zones and areas - state how to plan and build OT networks. Unless using for instance the recent local clouds set up (based on the SOA and RAMI4.0 principles – see section 2.2), outline in further detail how to use the traditional set up with levels, segments, zones, areas, etc. based on the above selected reference architectures/ models/standards. Remember to separate and use sub-segments and zones to secure functionalities depending on their required security levels (see example in Figure 5.1). State if physical network segments should be overlapped with virtual LANs (VLANs) and network equipment be used to only allow wanted and authorized network traffic in order to build layers of security. Describe how OT assets, that are insecure, should be isolated or partly isolated (e.g., ET). There should also be preparation for islanding of the whole OT environment, or parts of it, in case there is a serious issue in the IT environment (or if an issue in the OT environment can propagate to the IT environment as well)

• Isolation of critical parts of OT architecture – make clear if there are any sensitive or critical parts of the OT environment that must be strictly segmented, isolated, or not possible to remotely connect to (i.e., require local admin and support). Examples are what is commonly denoted as “unmanaged vendor machines or equipment”

• Wired networks and LANs in the OT architecture – provide instructions for how to plan and build wired networks (and combining that with VLANs) and make figures with an overview, a close up, and one with enough details to successfully be able to build the wired networks. Point out that the networks should be adequately protected and only allow needed/wanted access and communications in/out for to prevent networks problems, spread of viruses/malware, make it harder for intrusion attempts and a potential successful attacker to move around within the OT environment. A good plan and set up of the wired networks are crucial for network performance, security in general and minimizing propagation of problems or issues

• Wireless LANs (WLANs) in the OT architecture – OT WLANs may be allowed and needed to be used where wired networks are not possible due to mobility requirements or that wiring is very hard or expensive to achieve. If private cellular networks based on 5G or similar will be used as well, consider segmenting these in a similar manner alike the WLANs and avoid using the often also offered WLAN solution. It is better to have a separate WLAN solution concerning separation (and make it harder for any attacker). State the principles here for setting up and use of WLANs and how these should be configured and what minimum security level is required for attaching equipment or OT systems to

such networks. If Bluetooth is used, it should only be on a temporary basis and shut off when not used. If Bluetooth is needed for static usage, such solutions should be isolated/islanded and not have any connections to the rest of the OT environment. If the WLAN standard requirements get lengthy, break this out into a separate document and link it here. Common items/areas to consider, to ensure function with adequate security, availability, quality-of-service and optimized traffic are among others:

n Security requirements:

• Minimum level of security

• Security protocols

• Public Key Infrastructure (PKI) and certificates

n Which devices should be able to connect and control/detection of such devices

n Availability/redundancy/robustness requirements:

• Quality-of-service for data communications, prioritization of traffic, queueing rules etc.

n Quality-of-service measurements and need to reserve bandwidth for different purposes

n Optimization of traffic

n WLAN design and set up:

• Set up and parameters – specify which and how to set up these

• Modes and roaming– specify which and how to set up these

• Protocols– specify which are allowed and how to set up these

• Frequencies – specify which and how to set up these

• Casting rules – specify which and how to set up these, block/disable the others

• SIM-cards – suggested is to have that public SIMcards are not allowed in any OT assets that are connected to any OT network. If an OT solution has a public SIM-card, it should be operated in isolated/ islanded mode. If there is a private 5G network available and the organization is its own mobile operator (see section 2.3), then the risk should be assessed prior to using such a set up and such assets are connected to any OT network

• Availability and redundancy – there is a need to plan for availability and redundancy concerning aspects such as electric power (uninterrupted power supplies (UPS), batteries of other kinds, or diesel generators) and other utilities, such as mobile communications/Internet, water, heating, cooling, etc., required for the operations. The OT architecture should not have any single point of failures concerning: Internet access, internal OT network communications (main network equipment, redundant communication paths, topology design, etc.), OT systems, critical parts, components and network services, etc. Further, as many production/manufacturing processes may have steps depending on fast

response times, or real-time communications, quality-of-service must be considered for how the OT networks are set up, how data are communicated, if there is a need for prioritization of certain network traffic, as well as how to set up queueing and casting rules for network communications

• To keep order in the OT architecture and network – for to keep order and be able to maintain the OT architecture on a long-term basis, a structured approach is recommended for how the various networks, segments, zones, areas and potential levels are tagged or marked for easy recognition during maintenance, re-development or addition of new networks, etc. Such a structure should consider how to be able to separate different wired networks, zones and areas, etc. by using for instance color and/ or numbering schemes. Further, any wireless and mobile networks must also be part of this structured approach. See Figure 5.2 for an example of multi-site setup having common servers

• IP-address standard for OT networks – if having a larger network, or there are many networks connected as part of a global organization, it is necessary to have a standard for IP-addresses to ensure network performance, scalability and security. This should also be supported by an IP-address system which can provide an overview, support IP-address planning, and indicate if there are unintended IP-address overlaps, which may cause serious network problems or loops. Further, concerning connected OT assets, there is often a need to have MAC-addresses recorded (preferably within the OT asset management systems) as part of the IP-address planning work

• Naming standard – there is a need to have a naming standard, or naming convention, for the be able to scale up OT environments and, in particular, if having multiple connected sites. If it is not possible to decide own new identities/names for OT assets, the serial number of the asset can be used as “device name”

• OT backup standard – state how backups for OT assets should be set up and specify if there are different types of backups as well. Often, backups are made (1) locally (but not next to the OT asset in case of a flooding or fire), (2) in an internal data center, and (3) in an external data center. Steps (2) and (3) should preferably be de-linked (i.e., only connected at the time of backup transfer) and provide immutable (i.e., it is not possible to make any changes) storage with meta data about when the backup was made etc. Depending on criticality, the number of backup levels should be as many as deemed necessary. Further, restore tests should be made for all critical OT systems at regular intervals and any restore problems reported to the OT responsible role. Physical access to backups should be limited and only on a need basis and logged, and access to backups should only be allowed for authorized roles as part of the maintenance, restore, or disaster recovery management. In addition, a retention plan for backups should be devised and any legal/regulatory requirements may require that backups are kept for long time. The increasing use of virtualization in OT data centers can simplify backups by using “snapshots” which are fast to make and to restore

Figure 5.1 – Example of resilient segment setup used to separate functions, or sub-processes, in a process

Checklist for OT reference architecture standard – if there is a need to have check lists for different scenarios, see section 7.1.§

5.5.2 Additional standards related to OT environment architecture and security

Usually, there are plenty more standards needed concerning the OT environment architecture and security, and several suggestions are listed below. Remember that you should add, change or remove such depending on the needs of your OTSF.

5.5.2.1 Standard for configuration and hardening of OT assets

Hardening of OT assets is alike for IT assets a necessity/must to do, and there are different groups of assets to consider having a standard for to ensure that these groups are hardened the same way. Make an instruction for how to set up, configure, and harden each type of asset below using the examples following.

Standard for standard configurations and hardening of OT assets:

• Network configurations:

• Allow only minimal/required level of communications

• Everything else should disabled or removed (i.e., only allowed IP-addresses, ports and protocols, etc.)

• New equipment must be vulnerability scanned immediately after it is connected using a tool approved by the OT security responsible

• Network devices/equipment or components:

• Network devices/equipment etc. should be placed in locked cabinets or locked rooms. Remove any

unnecessary services/applications or disable any such services/applications which can not be removed

• Legacy communication services, such as, Telnet or FTP, shall be disabled and only enabled when needed

• All communication ports and USB ports which are not to be used shall be disabled

• Replace all default standard passwords

• Use only encrypted connections for administrative tasks

n 2- or multifactor authentication for administrator or remote logon should be enabled/used if possible

• Tablets (Windows/Android-based, iPADs, or similar) and mobile phones:

• If possible, try to standardize using one type of tablet and two types of mobile phones

• If possible, craft and use a standard image which is hardened with pre-installed applications and adequately configured

• Use a mobile device management (MDM) system/ service with localization and remote wipe ability (for confidential applications and data)

• Preferably, use the standard remote access solutions with two- or multi-factor authentication to connect to the OT environment and do not connect directly into the OT environment

• Workstations/laptops:

• Craft and use one or more standard images which is/ are hardened with pre-installed applications and adequately configured. Different images may be needed for general use, specific use, and for administrative use

Figure 5.2 – Example of multi-site setup having common server resources

n Workstations/laptops shall only have active what is needed and remove all services/applications, etc., not needed/used

n Communication services, such as, Telnet and FTP, shall be disabled and only enabled when needed

n All communication ports and USB ports not used shall be disabled

n Follow the standard for user and admin passwords (see further below) and use encrypted connections for administrative tasks or remote access

n Disk encryption shall be enabled

• If possible, use domain policies (for instance group policy objects/GPOs or similar) to control the workstations’/laptop’s functionality

• Servers:

• If suitable, craft and use standard images for different types of servers which is/are hardened with pre-installed applications and adequately configured

• If possible, use domain policies (for instance group policy objects/GPOs or similar) to control the servers’ functionality

• Servers shall only have active what is needed and ensure to remove all services/applications, etc., not needed/used

• Legacy communication services, such as, Telnet or FTP, shall be disabled and only enabled when needed

• All communication ports and USB ports not used shall be disabled

• Follow the standard for user and admin passwords (see further below) and use encrypted connections for administrative tasks and remote access

• 2- or multifactor authentication for administrator or remote logon should be enabled/used if possible

• “Unmanaged” - supplier-maintained equipment/ machines:

• Such equipment/machines must be protected with network segmentation (isolation is preferred)

• Internet access should only be allowed after risk assessment – and may be opened up temporarily when needed

5.5.2.2 Standard for cryptography and a process for key and certificate management

Outline what should be the minimum baseline, i.e., what are the bottom accepted criteria, concerning a cryptographic standard for use within the OT environment and outside of it in terms of:

• Minimum level of cryptographic algorithm strength and associated key lengths etc. plus any withdrawal dates

• Which algorithms that are preferred and should be configured to be used together with minimum key lengths etc. plus any withdrawal dates

• Should public key infrastructures (PKI) be used and how to manage that? See further below in the key and certificate management process

• How to address post quantum compliance (PQC) –when to change algorithms and keys and to which?

Associated with the cryptographic standard is the key and certificate management38 process, which also needs to become PQC within soon. Certificates can be used for authentication and encryption purposes. Outline how cryptographic keys and certificates are to be securely managed (i.e.,

38 https://www.servicenow.com/products/it-operations-management/what-is-certificate-management.html

enrollment, creation, transfer/provisioning/discovery, storage, inventory, monitoring/renewal (keep expiration dates honored and replace old ones where adequate), retirement/destruction/ deletion, revocation/revocation list) during the whole lifecycles and which role is responsible for maintaining all of this.

5.5.2.3 Standards for roles in OT systems, logon rules, authentication and more

To create unity and uniformness in various OT systems it is a good idea to have a standard for roles in OT systems

However, this does not imply that the passwords or similar are the same across these OT systems! A common role set up may look like this:

• Admin – administratOr rOle with privileged access rights and authOrizatiOn. if lOgging in remOtely, an adequate secure remOte access sOlutiOn shOuld be used. the access rights and authOrizatiOns shOuld be based On the principle Of least privileges

• Poweruser – role for managers or supervisors etc. with advanced access rights and authorization, based on the principle of least privileges. If logging in remotely, an adequate secure remote access solution should be used

• Advanced operator – role for workers or operators with normal access rights and authorization required to conduct work tasks (including making changes to operational parameters but not any OT system configuration changes), based on the principle of least privileges

• Light operator – role for operators with normal access and authorization required having only access to the most basic operations and read rights in general

See Figure 5.3 for an example of user roles and separation of duties within an OT environment.

Further, some older OT systems can only have 2-4 user accounts which are role-based. For such, it is not possible to

have individual user accounts with better traceability in logs. For OT systems that are safety critical, it is common that these only have 3-4 role-based user accounts that are shared. However, this requires that the physical protection of these OT systems is ensured, and only authorized staff are allowed to use these OT systems

A standard for user and admin passwords should be decided and stipulate how long these should be (normally at least 8 and 16 characters unless the OT systems are very old and only can handle shorter ones) and require a mix of different types of characters, numbers and special characters. Further, if long passwords are not used it should also be stipulated how often these passwords should be changed. It should be forbidden to have the same passwords across different OT systems as well as that any default passwords must be changed into a password decided by the own organization (and not by vendors or consultants). If logging in remotely, the usage of longer and very strong passwords via a password storage/manager can be handy and require less changes of passwords.

Stipulate what should be the general standard requirements and preferred solutions for 2-factor or MFA (which should be PQC or planned to become) and when these must be used. Further, also add what are the standard requirements and preferred solutions to use for authentication during remote accesses if it differs from the general 2-factor or MFA standard.

When traversing OT systems, i.e., logging up or down within such and their different parts/levels, there should be standard account logon rules (see Figure 4.4). A general rule is that it is OK to log up, but when logging downwards a log out should be required. This is to hinder that a potential intruder can traverse a whole system by getting access to a privileged role. That may at least protect to some level and create a better forensic trail if the worst happens.

Regarding principles for OT connections (and access rules), the use of tiering can be used (see Figure 1.5) to allow/enable only authorized OT connections in a planned manner.

Figure 5.3 – Example of user roles and separation of duties

Process and standard for remote access (for the organization’s own employees and externals) to the OT environment. To remember is that the solutions used should be PQC (or planned to be) to future proof this important aspect! The standard shall also be mandated in any contracts with externals. The following process steps can be integrated with the standard solutions to use (see examples in Figures 5.4 and 5.5 covering both internal and external remote access):

• Approvals of remote access shall always be documented and added in the standard set of organizational documentation for each installation/factory/mill. Access rights/limitations and the need for logging, monitoring and alerts etc. should be noted and executed upon. Depending on the trust or confidence level for any external (i.e., non-employee), additional access rights can be granted if needed and the risk level is acceptable. Otherwise, access rights shall always be granted on a least privilege basis and always be time limited

• The remote access for externals, to the OT environment shall be set up according to below, where option 1 is recommended. Else, it shall be motivated and documented accordingly. The remote access shall always be time limited and renewed with regular intervals, and if the external stops working for the external/third-party

contracted, the remote access shall be removed immediately. Options for recommended remote access are:

1. High-level VPN or similar with access control via the asset management system or similar system for to only get access to the OT assets included in the tasks contracted (recommended)

2. Low level VPN (to be used only if option 1 is not viable as this provides less control in general)

• Other options, such as, 3/4/5G-modems, ADSL, Lan2Lan, non-standard gateways, etc. shall not be used, and existing such are to be moved to options 1 or 2. If OT systems are isolated, the use of 3/4/5G-modems may be used after a risk assessment is conducted and the risks accepted

• Remote access, for employees, to the OT environment shall be set up using option 1 above via the asset management system or option 2 depending on the employee’s needs and responsibilities (i.e., privileged access management). Access rights shall be changed if responsibilities/authorities are changed according to the ISF and HR processes. The remote access must always be time limited and renewed with regular intervals

Figure 5.4 – Example of internal and external remote access planning and setup based on an asset management system

The standard for external data sharing shall be used when sharing data in various ways (i.e., inwards and outwards) according to below. See Figure 5.5 for an example of planning and partial documentation. Adequate protection level for all external connections must be ensured and avoid having continuous connections and use short sessions instead All data sharing decisions must be documented and reviewed regularly:

• Sending out data/files via a cloud service – stipulate which standard and prepared cloud services there are to be used. Else, make a risk assessment for each connection which is not part of the standard

• Sending and receiving data/files via an automated data exchange service and which data formats that are preferred (e.g., EdiFact, JSON or XML) – stipulate which services are to be used and their preferred data formats

• Data/files sent/retrieved/received from and to OT systems directly:

• Investigate if a gateway can be used to send and retrieve data or files. Some providers of OT systems can provide a secure gateway to cater for data and file transmissions in and out while also providing additional security such as advanced VPN, non-routing through, and basic firewall capabilities for to create a secure network sub-segment. Proposed is to use some kind of proxy/s terminating in levels 3, 4 and 5

• Ensure the authenticity of data sent and received

• Data/files sent out – all data/files sent outwards from OT assets shall be granted by an employee of the organization prior to set up and start of sending out data/files

• Data/files received – all data/files communicated inwards to OT assets should be blocked unless approved

• Data/files retrieved – all files retrieved must be controlled by an employee of the organization and anti-virus programs prior to being used within the OT environment

• If application programing interfaces (APIs) are to be used for outwards (and potentially inwards too) data sharing, such connections need to be reviewed and risk assessed prior to being set up and used

• Central data collection services – some OT environments may have a data collection server which collects various types of data from OT systems and sensors (via files or an API etc.) and then in turn makes the data available for consumer systems in the IT or OT environments. A central data collection service must be well secured and are often situated in the industrial DMZ in an own network segment. To mix data from many OT systems in one or more data collection services poses a high risk and must be considered when securing these services. Similar specific data collection services, which should be separate and highly secured are for instance collection of network activity logs, audit logs and backups

Documentation of OT environments is crucial and if having multiple sites and geographies involved, as having a uniform way to document provides faster and easier access to the information sought for. Further, where the documentation is stored/published should also be known to all involved with authorization and access rights (as some of the documentation will be of a confidential nature). Documentation of an OT environment and its architecture and processes may comprise the following and, if adequate, make templates for each template to enable uniformness and predictability of the contents. Consider crafting the following OTSF standard documentation templates:

• IT/OT set up and connection(s) in between

• OT architecture implementation – make a high level and then describe in more detail. Describe the present implementation and then if there is a wanted one. See section 5.5.1 for the OT reference architecture

• IP-address plan

• Backup set up

• Access rights

• List of connections between systems and description of these

Figure 5.5 – Example of access condition chart for internal/external remote access and data sharing planning

• List of external data sharing and how that is set up

• Operating procedures/processes

• Disaster Recovery Plans (and Business Continuity Plan if it does not exist elsewhere)

• Procurement texts (and potential project handbook) to always be used, such as texts to be included in procurement documentation and/or checklists. See also the secure procurement process in section 5.4.1.

• OT system maintenance plan template (see example in Appendix C), which should comprise for instance:

• System information regarding system/asset or similar, system/asset description, owner (budget/cost owner), asset identification (for asset management system), maintenance responsible

• Supplier/provider info:

n Supplier/provider, contract or agreement id/nr, telephone, and additional contact information such as names and emails

• Connections to other systems – list any system etc. that are connected and who is responsible (including any internet access)

• List of licenses – list any licenses required in terms of computers with asset id/nr, licenses for software and their license nr/id

• Link to disaster recovery plan

• …and anything else that may be required!

• Risk assessment/analysis template – include all regularly used types of documents or files

Backup and restore set ups and procedures are crucial that they work and are tested at regular intervals. Restore procedures need to be set up for each critical OT system/asset where needed. Further, to ensure that backups are made in a uniform manner, below is a standard for how to set up backups (see also section 5.5.1 on OT backups). See an example in Figure 5.6 illustrating how planning for high resilience can be

outlined. OT assets, such as servers, equipment, data/information, etc., shall be backed up according to the principles below:

• The backup system should be logically separated/ de-linked from the environment being backuped to prevent encryption viruses etc. to propagate. Preferably, the backups shall also be immutable (i.e., not possible to change)

• If needed, backups can be made (1) locally, (2) in a data center, and also (3) in an external backup site. The process’ requirement on availability and risk level should decide how many levels of backups are necessary

• Physical access to backup systems and backups shall be limited to only authorized employees – i.e., locked up in a data center or room etc. and all accesses logged

• Logical access control to backup systems and backups shall be limited to only authorized employees and all accesses logged

• Backup media/files shall be made incrementally and retained up to a year, or longer according to legal/regulatory requirements (e.g., safety and quality)

• Backups shall not be stored close to where the backuped OT asset is in case of fire or flooding etc. (unless it is a local backup and there are more backups made to a data center etc.)

• Backups shall be tested and read back to OT assets on a regular basis. If backups cannot be successfully re-read, it must be immediately reported to the OT asset owner and OT security responsible

As bringing in external media, such as USB sticks or disks, into an OT environment is risky, this must be in a controlled and risk aware manner. Therefore, a standard for external media is needed and it is common that an organization’s dedicated OT external media is bought in a specific color to highlight that it is only, for instance red-colored external media, that is

Figure 5.6 – Example of backup planning for high resilience and ability to manage severe problems in a timely manner

allowed into the OT environment and for instance yellow or white-colored ones are for the IT environment. The standard for use of external media may constitute that:

• The media shall be clearly marked with red tape or color and numbered (for logging purposes)

• USBs shall be encrypted using an encryption solution stated (and keys escrowed to a central key store)

• External media like disks, USBs, USB-disks, etc., shall be managed in a secure and responsible way and locked in while not used

• The external media shall be wiped clean upon return after usage, either manually or with a wiping tool. If such a wiping tool is not available, consider to end-of-life/discard/destruct that external media used unless too costly

External vendors or consultants must not use their own external media (USB-sticks or disks etc.) in the OT environment (see also section 5.7 below) unless risk assessed and approved by OT security responsible in writing.

5.6 Standards for OT network security

This section spans both OT network and device security and is kept rather brief as what needs to go in here is solution-oriented and specific.

Standard for anti-virus, personal firewall etc. products to use on OT servers, workstations, laptops and devices. Outline which organizational standard solutions to use for each of the asset types and that they need to be preferably set to being auto updated if possible.

Standard for endpoint detection and response (EDR)/ managed detection and response (MDR)/extended detection and response (XDR). Such solutions span from the endpoints towards also including the network, and risk assessments and a decision need to be made and outlined here what to use and where. Further, assess if different contexts should require use of a lesser/stronger solution. Observe that

such solutions are to be used only where suitable and appropriate to not cause any network or device problems.

Standard for logging in the OT environment – outline what to log and where concerning different types of OT systems and network equipment, and also how to protect these logs/logs servers from encryption viruses and unauthorized tampering etc. Further, also include where the logs are to be backed up and if this differs depending on asset type. In addition, the logs should be used for monitoring of activity, logins, and administrative actions etc. Therefore, the log servers may need to be possible to be integrated to or that the log files are sent to log analysis system (e.g., SIEM).

5.7 Standards concerning external resources and secure/safe sourcing in the OT environment

If externals may be allowed to use their own equipment, such as, USBs or laptops etc., within the OT environment – it must be regulated. On a regular basis, the organization should provide adequate and standardized equipment necessary for the tasks. Else, a risk assessment and documented decision should be made prior to using any external equipment within the OT environment. As standard laptop for externals may be according to:

• Laptop which has the organization’s standard configuration and is hardened (and an approved and adequately tagged/colored USB stick can be supplied if needed)

• The laptop should only have the applications and development environment, etc., which are required for performing the tasks specified in the work order(s)

• Local administration should only be granted if the tasks require that

• The username should have an extension or clear marking that it is a username for external plus having a strong password

• 2- or multifactor authentication shall be applied depending on security level and from where/how the work will be performed

• The laptop should be possible to remotely wipe/shutdown/admin by an authorized administrator

If there are reasons for not to use a standard laptop for externals, the external should connect to for instance the IT WLAN guest network and access using the remote access set up. In case there is a need to use a specialized laptop or computer with special applications, advanced ports, or communications capabilities, etc., not available within the standard laptop for externals, a risk assessment shall be made and documented for that and then filed together with the contract/ assignment and work order details prior to being used within the OT environment. Use of externals’ own USB sticks or similar should be avoided. However, if this is a must, then ensure that the USB sticks are controlled regarding malware and viruses and the matter also risk assessed and documented in the work order prior to usage.

If there are extra security requirements to consider during procurement of cloud services, make some standard texts or additions that can be included in the secure OT procurement process (see section 5.4.1 unless this is not already available on the IT side).

5.8 Standards pertaining to physical and environmental security

If this is not managed in other documents, add any processes and standards deemed necessary here related to physical and environmental security.

5.9 Standards related to business continuity, disaster recovery and incident management

If this is not managed in other documents, such as a strategic plan for IT and information security (see Figure 1.1), add any processes and standards deemed necessary here. Typically, each of the business continuity and incident response plans should be reviewed and updated (i.e., maintenance processes) at

least annually, and this requires that there are processes and responsible roles who owns and ensure to do this. Concerning the disaster recovery plans, there can be many of these as there should be a specific one for each of the critical OT systems/ assets. Thus, there needs to be a process for maintaining these disaster recovery plans (or at least review) on an annual basis or after significant changes have occurred and to ensure that all disaster recovery plans are cared for. This is not an easy task/process step as there may be many critical OT systems/assets. In addition, the maintenance of disaster recovery plans could also include backup/restore testing.

5.10 Standards for non-compliance and reporting

Many organizations have a HR handbook or similar where processes and procedures for non-compliance to the organization’s rules (i.e., policies) and expected behaviour are stipulated. If there is no such central location for such processes and procedures, these need to be written as part of each policy, and such processes or procedures can be devised to have steps and escalation to manage various types of problematic behaviour starting with initial discussion/information on the matter and gradually move up to suspension from work, penalties or termination of employment in case of very serious and repeated incidents. Concerning if any legal violations or crimes have been conducted, these aspects also need to be part of this as well as that reporting to police (or additional adequate authorities in case of industrial espionage or sabotage, etc.) is mandatory in such cases.

5.11 Process, documentation and problem repository concerning OTSF governance

Make a process for the OTSF governance to ensure that this is kept up to date at least 2-4 times/year and keep the top 15-20 problems in a document or problem repository’s management view. Further, keep all problems in a central repository so that these are not forgotten and unwilling omitted.

Part 6 – An outline for an OTSF ending with the user guide level

What to have in a user guide is a quite tricky thing to decide. A user guide should preferably be a brief and snappy guide for the most important DOs and DO NOTs in 1-2 pages. Therefore, consider what to have in the OTSF user guide and keep it very short, or it will not be used. The user guide should comprise the practical essence of the policy and standards parts.

This user guide is intended for users, i.e., employees, contractors, consultants and other workers. The purpose is to outline responsibilities and necessary behaviors within OT/ OT security. Below are some potential areas to consider as part of the user guide:

• Users´ responsibilities within the OT environment. It is every user’s responsibility to:

• Comply with all relevant policies and standards

• Keep yourself informed regarding any important changes in policies and standards

• Meet visitors at the entrance gate and follow them during the visit. Employees are encouraged to challenge visitors/strangers without their host present and ask who they are, who their host is, and what they do here

• Protect the OT environment with its critical/sensitive assets: machines, OT systems, network devices/ equipment, and data/information. If you notice anything that seems suspicious or out of the ordinary – report it to your manager!

• OT assets. Users of OT assets (e.g., workstations, servers, PLCs, robots, network equipment or devices) are responsible for their protection. Basic rules are:

• OT workstations or servers should not be left unattended when logged in

• Terminate active sessions when finished, unless they are secured by a locking mechanism, for example a password protected screen saver

• Information must be erased before disposal or re-use. OT assets containing sensitive/confidential information must be physically destroyed or thoroughly wiped

• Only authorized OT tablets can be used within the OT environment. Other tablets should connect via the IT environment and use the standard remote access solution

• Tablets and mobile phones must never be charged using USB ports on any OT assets. These must be charged via the electric outlets

• OT information assets. To protect OT information assets, the following basic rules shall be followed:

• Mobile phones are not allowed to connect to any OT networks

• Tablets can be used if these are dedicated to use only within the OT environment and not used elsewhere

• USB sticks and other removable media. It is only allowed to use the organization’s own standard USB sticks and removable media within the OT environment. Only USB sticks dedicated for use within the OT environment are allowed. No external ones, or those which have been used elsewhere, are allowed!

• Do not let externals use their own laptops, USBs, or other removable media in the OT environment unless explicitly allowed and documented in the work order

• Important OT data, programming code, etc., must be backed up. If these are not currently backed up, get help to do it, as it must be done on a regular basis. This is a crucial part of the recovery process

• Incidents. Any suspected security incidents such as virus/cyberattacks, faults in the security system, potential damage, and damage that has already occurred, should be reported to the manager responsible or OT security responsible as soon as possible. The report should be documented to provide the basis for incident management/response knowledge and statistics. Make sure to have a well-known incident process

• Passwords. Users are required to follow the standards and good security practice in the selection and use of passwords:

• Do not include passwords in automated log-on processes for other than tier-2 (with low access rights and privileges)

• Avoid keeping a paper record of passwords, unless this can be stored securely

• Revealing the account password to others or allowing them to use the account is prohibited. This includes family and other household members when working from home. However, if the account on an OT system is role-based, the password needs to be shared among those who are authorized users

• For guidance in the selection of passwords, see the password standards

• Unacceptable Use. The following activities are in general prohibited, and a user may be exempted from these restrictions during legitimate job responsibilities:

• Under no circumstances is a user authorized to engage in any activity that is illegal under local, national or international laws or regulations while utilizing any of the organization’s OT resources

• Connecting unauthorized devices or equipment to the OT environment and its networks is strictly forbidden

• Connecting tablets or laptops, which are dedicated to the OT environment, to the Internet via a cell phone or non-secured network

• Non-compliance. Failure to comply with the OTSF may lead to disciplinary action, up to revocation of access rights, suspension or termination of employment, depending on the severity and circumstances

Part 7 – Methodology for approaching an OTSF and mapping of standards for facilitating compliance checks

At the time when starting to read up and comprehend what an OTSF may comprise, it can feel like a huge task. Therefore, there is an approach for how to go about this with three common scenarios to suggest what to start with, what to do next and what to do last. Further, as there may be inquiries regarding compliance and mapping towards various international standards and frameworks, there are simplistic tables covering such at the end concerning the OTSF’s three levels: policy, standards, and user guide.

7.1 Approach for developing and implementing an OTSF for three different situations

If starting to address OT/OT security management when there are very few formal decisions and not much formal documentation, a methodology can be considered to use for three different situations. Firstly, if it is a greenfield context where to build a new factory/mill/installation, it is open to plan however one

OTSF topic/area

Develop the OTSF policy (with the rules) and implement it. Of particular importance is the specify the organization, roles with responsibilities/authorization, and where the IT and OT environments are separated in terms of responsibility

Develop the most necessary OTSF standards (e.g., security reference architecture for OT, remote access, external connections, procurement of secure OT assets, risk and availability management processes) and implement them

feel is the best way forward. Below, we suggest ideas for what to start with as some matters may affect many following matters and decisions. Secondly, if it is a brownfield context where an existing factory/mill/installation will be remodelled and rebuilt significantly, there may be other things to ensure prior to moving on with further changes. Thirdly, if it is a context with an existing factory/mill/installation that is rather up to date, but the OT/OT security is not managed and well implemented, another way of approaching may be necessary to avoid having to redo many things as more is learned during that change process.

The idea is to have three phases, #1-3, as part of a simplistic approach to address OT/OT security if not a lot is already made. Thus, 1=to start with, 2=intermediary, and 3=to do last. The Table does not fully cover all aspects of an OTSF but can help to do initial planning and get started up and all organizations need to make a complete plan and implementation for it all.

with lots of upcoming changes Up to date site but no formalized OT/ OT security management

Table 7.1 – Approaches for how to address OT/OT security – 3 common scenarios

HR processes to the OT environment and its various systems to provide input to user and access management

Make a production/distribution processes layout and design a secure and redundant internal/external network with physical and logical separations (use the standard security reference architecture for OT security design if exists) with redundant network services, such as: NTP, AD/LDAP, WSUS, DNS, anti-virus/malware or similar, domain controllers, etc.

Separation of networks into enterprise security and industrial security zones with an Industrial DMZ in between. Further, segment the IT and OT environments and also apply sub-segments/zones within the segments to achieve layers and additional protection of sensitive parts (depending on functionality, type of asset, and security level required)

If using network domains, make a separation between IT, OT and network equipment into separate main ones. Further, divide each of these into adequate sub-domains (e.g., based on processes or segmentations/sub-segments/zones or similar)

Design or update the physical and logical security and safety perimeter with site resilience. Ensure to mange incoming and outgoing supply chains too

What needs to be redundant?

Utility redundancy needed (clean water, wastewater, ventilation/ cooling, heating, electricity, outgoing communications via fibres, piping, etc.)

Are one or more internal data centres needed – OT, Industrial DMZ, IT – should they be connected or standalone. OT data centres should primarily be localized within the OT environment (or DMZ) and secondarily in the IT environment

Redundancy of OT servers etc. when these are virtualized plus backup/restore and disaster recovery plans for all critical ones

– physical and logical separations

– logical and also physical separation if possible

– logical and also physical separation if possible

OT data are backed up adequately (applications, software/programming code, data, etc.) and backups checked and re-read/restored with OK outcome. Have backups with several levels (local, internal data centre, and external data centre)? If having virtualized OT servers - snapshots can be used for local backups

Consider having double or triple network connections (fibres), i.e., redundant communications paths, from key production/distribution processes and their network segments to the industrial DMZ (should be part of the security reference architecture). These should also be adequately physically separated

The main network equipment (e.g., firewalls, routers and switches) and essential network services shall be redundant (at least doubled)

Consider if the production/distribution processes are physically vulnerable (i.e., when outside of the security and safety perimeter of sites). Examples are power grid, clean water and wastewater management systems, railways, etc. How to protect and monitor such as well as any control installations/sites distributed in low populated areas without overview of inhabitants?

Analyze and test if there are any remaining single points of failure and remedy such! Are there own spares of key/critical network equipment, etc., available on the shelf?

Only dedicated OT devices and computers should be able to connect to the network within the industrial security zone, else access should be made via remote access and data sent in/out using external connections solutions

Only standard workstations, laptops and tablets, etc., running standard images of operating systems should be able to connect to zones/areas within the industrial security zone. Exceptions are that authorized externals may use their own equipment and directly via a wire or similar connect to production equipment on site (PLCs, HMIs, robots, etc.)

Employees with need, may after risk assessment and authorization, get special access from the enterprise security zone to the industrial one via for instance AD and firewall settings

Suppliers and consultants etc. should connect to a separate/dedicated zone in the industrial security zone and from there via remote access to any OT assets

The use of other types of tablets, mobile scanners, Raspberry PIs, etc. shall be restricted to a separate/dedicated zone in the industrial security zone. It shall not be possible to initiate connections to these from outside of the industrial security zone, and these can be used to access to other zones based on access rights and firewall rules. The separate/dedicated zone may comprise a WLAN enabling Wi-Fi-connections. Also consider requiring use of remote access solution

Physical and logical access to data centres/rooms, main network equipment, communication hubs, etc. restricted to only authorized personnel and all mentioned assets adequately protected and secured

Data centres/rooms have controlled environment and are adapted for long-term operations with fire control solutions and electric power backup (e.g., UPS)

Ensure that all OT systems are in water protected racks, or containments if racks are not possible) and have a local backup solution if needed

What is needed concerning central solutions for backup/restore, network monitoring/logging or SIEM, audit log server, etc. Where to put these and redundancy needed?

Update and document the operational processes needed to maintain the OT environment and its security (IRP, DRP, BCP, maintenance plans for each OT asset of criticality, etc.)

OT WLANs set up and configured adequately – security, availability/ redundancy/robustness, quality-of-service, optimization of traffic, other WLAN design parameters

No use of public SIM-cards in any OT equipment (unless risk assessed and isolated)

Keeping order in the OT architecture and network – have a structured approach for tagging/marking and separation of network parts

Use an IP-address standard and plan to avoid network problem (in particular, if growing/changing or extending the organization)

Naming – use the standard for naming of identities to keep order and avoid network problems

…and then later the rest of the OTSF that have not yet been implemented!

If wanted, or deemed as needed, please feel free to adapt Table 7.1 and have more phases if that helps to organize the work better!

7.2 Mapping of standards for to facilitate compliance checks

Compliance checks are not that fun but necessary. Here, compliance to laws and regulations will not be addressed but compliance to a few commonly used industrial standards. It

can be most helpful, as this is a repetitive task over time, to document the basics and update it on an annual basis. If wanted, the standards and models can be changed or extended to fit the context and requirements from stakeholders regarding compliance. Table 7.2 comprises the areas of the policy level.

Organization of OT security Mainly for IT but role concept and responsibilities useful

HR-related security Mainly for IT but partly appliable

Risk and availability management

tecture

External resources and safe/smart sourcing in the

If not managed elsewhere, also…

(Physical and environmental security)

(Business Continuity Planning (BCP))

(Disaster Recovery Planning (DRP))

(Incident Response Planning (IRP))

appliable for

appliable for OT as well

Table 7.2 – Mapping of some common standards and models towards the OTSF policy areas

Further, Table 7.3 comprises the areas of the standards level, and Table 7.3 may be necessary if the requirements on general cybersecurity and OT/OT security are high or regulated.

Table 7.3 – Mapping of some common standards and models towards the OTSF standards

Risk management process

Procurement process and secure supply-chains

External connections

Remote access

Authentication/2FA/MFA and passwords

Hardening of networks and assets

Security reference architecture for OT

Templates for the most important OT security-related documents

appliable for OT as well

a bit appliable for OT as well

a bit appliable for OT as well

a bit appliable for OT as well

a bit appliable for OT as well

appliable for OT as well

Additionally, Table 7.4 comprises the areas of the user guide level, and Table 7.4 may be necessary if the requirements on general cybersecurity and OT/OT security are very high or regulated. Else, the table can be omitted.

Table 7.4 – Mapping of some common standards and models towards the OTSF user guidelines

Useful readings summary

Standards

• IEC 62443 - https://www.isa.org/standards-andpublications/isa-standards/isa-iec-62443-series-of-standards

• ISA 95 - https://www.isa.org/standards-and-publications/ isa-standards/isa-95-standard

• NIST SP 800-82r3 - https://csrc.nist.gov/pubs/sp/800/82/ r3/final

• NIST CSF 2.0 - https://csrc.nist.gov/pubs/cswp/29/ the-nist-cybersecurity-framework-csf-20/final

• ISO 27001 - https://www.iso.org/standard/27001

• ISO 42011 - https://www.iso.org/standard/81230.html

• NIST SP 800-30r1 - https://csrc.nist.gov/pubs/sp/800/30/ r1/final

• ISO 27005 - https://www.iso.org/standard/80585.html

• ISO 31000 - https://www.iso.org/standard/65694.html

Frameworks and models

• Industrie 4.0 - https://www.plattform-i40.de/IP/Navigation/EN/Home/home.html

• RAMI4.0 - https://www.isa.org/intech-home/2019/ march-april/features/rami-4-0-reference-architectural-model-for-industr

• Eclipse Arrowhead framework - https://www.eclipse.org/ community/eclipse_newsletter/2020/july/1.php#:~:text=The%20Eclipse%20Arrowhead%20project%20was%20 created%20to%20provide,of%20the%20Arrowhead%20 Tools%20European%20research%20project%20.

And web sites to find more information at:

• Swedish Civil Contingencies Agency (Sweden)https://www.msb.se/en/

• ENISA (EU) - https://enisa.europa.eu/

• EU NIS2 - https://digital-strategy.ec.europa.eu/en/policies/ nis2-directive

• EU NIS2 technical implementation guidelineshttps://www.enisa.europa.eu/publications/nis2technical-implementation-guidance

• EU CRA - https://digital-strategy.ec.europa.eu/en/policies/ cyber-resilience-act

• VDMA risk management process - https://www.vdma.eu/ documents/d/group-34568/applied-risk-management-final

• CERT.SE - https://cert.se/en/

• CVE - https://www.cve.org/

Appendices A - C

Appendix A – Potential contents to have in a Request for Information (RFI) document

Appendix B – Potential contents for a delivery limits statement

Appendix C – Example of an OT asset maintenance plan

With support from: