August 2019
MASTER THESIS
“Standardized Security Assessment Framework for ICS Devices and pilot project”
University of Twente
Faculty of Electrical Engineering, Mathematics and Computer Science
Author: Anna Prudnikova (1924818)
Supervisor (University of Twente): Dr. Jeroen Van der Ham Supervisor (Secura B.V.): Razvan Venter
2
Title page
Student name: Anna Prudnikova Student number: 1924818 Telephone: +79166907159
E-mail: a.prudnikova@student.utwente.com
Topic of Master Thesis: Standardized Security Assessment Framework for ICS Devices and pilot project
Company: Secura B.V.
Company address: Karspeldreef 8, 1101 CJ Amsterdam, The Netherlands
3
Acknowledgment
During six months of the research and writing my Master Thesis I received support and help from a lot of different people. I would like to thank everyone involved and give specific acknowledgment to the following people.
First of all, I would like to thank my supervisor Dr. Jeroen van der Ham, who supported me during the whole process of writing my Master Thesis, provided a valuable feedback and recommended me a company which can provide me with an internship position and support me with conducting the research. The company Secura B.V. happened to be a perfect match.
I would also like to thank the company Secura B.V., where I was working on my thesis for six months, especially for providing resources and devices for performing pilot part of my project.
My special gratitude goes to my supervisor within the company Razvan Venter who gave me guidance in creating the framework and helped me to outline structure and timeline of my thesis.
Moreover, I would like to thank Jos Wetzel, who supported me in technical questions of programming and testing devices during evaluation process.
Moreover, I would also like to show gratitude to my family and friends who supported me from the very beginning of my master studies, believed in my success and were there for me when I needed moral support.
4
Abstract
The modern world becomes more and more digitalized. The information technologies (IT) keep penetrating all spheres of our life. This major trend of digitalization also changed the industrial sector; Industrial Control Systems (ICS) become more interconnected and the boundaries between classic IT systems and ICS become less clear. IT protocols such as IP or TCP tend to be used within ICS due to their simplicity and widespread. This trend leads to the fact that ICS that originally were not designed to be secure against state of the art cyber-attacks become vulnerable.
One of the main problem within the cyber security domain of ICS is the lack of regulation.
Manufactures do not have obligations to make their devices secure. Currently there exist a number of different best practice documents in the domain, but presented requirements overlap or sometimes even contradict each other, which complicates their efficient application. None of the existing documents could be used to perform an in-depth analysis of ICS devices security.
To address this problem we created Standardized Security Assessment Framework for ICS Devices, which could be used by all actors involved in industrial processes: industrial companies, certification laboratories and IT integrators or manufacturers of ICS devices to assess and eventually strengthen the cyber security level of ICS devices.
The created framework is based on five different documents related to ICS cyber security that were chosen as the most relevant ones based on specific parameters. From those five documents, we identified more than two hundred requirements (227), performed an overlapping process to identify relevant requirements for ICS devices and eventually presented one hundred forty (140) requirements.
To finalize the created framework, we performed an evaluation process (or so-called pilot project) by testing three different devices, in order to assess compliance with all included requirements. This process allowed to further improve the Framework and revealed that twenty- three of original requirements were either not relevant for single devices (only relevant on system level) and therefore were deleted or partly/completely repeated other requirements and in this case – merged. Thus, the final version of the Framework contains one hundred seventeen requirements (117). Additionally, for every requirement from the Framework we created excessive guidance with description of methods and tools needed to perform the assessing process of compliance.
Moreover, we presented recommendations on how to strengthen security of tested devices on different levels: device-based, system-based and process related. We included in the recommendations the list of possible security solutions that could be used together with the device to reach the compliance with the created framework; based on an example of one device we introduced compensation measures for every requirement that was not fulfilled within this device.
5
Table of Contents
Acknowledgment ... 3
Abstract ... 4
Table of Contents ... 5
1. Introduction / Motivation of the topic ... 7
1.1. Introduction to ICS ... 7
1.2. Problem statement ... 8
1.3. Research questions ... 8
1.4. Relevance ... 9
1.5. Structure of the thesis ... 10
2. Literature review ... 11
2.1. Brief overview on ICS security ... 11
2.2. ICS security standards ... 11
2.3. ICS certification schemes ... 14
3. Research methodology ... 18
3.1. Conceptual model ... 18
4. Research results ... 20
4.1. Selection of ICS security standards and relevant requirements ... 20
4.2. Design of Standardized Security Assessment Framework ... 21
4.3. Requirements overlapping ... 22
4.4. Concept of security levels ... 23
4.5. Methods and tools used for testing ... 24
4.6. Final Standardized Security Assessment Framework ... 25
5. Evaluation process ... 51
5.1. Testing methodology ... 51
5.2. Testing results of PLC 1 ... 52
5.3. Testing results of PLC 2 ... 64
5.4. Testing results of the Switch ... 75
5.5. Comparison of testing results ... 87
6. Discussion ... 89
6.1. Analysis of the results and recommendations ... 89
6.2. Limitations ... 99
7. Conclusion and Future work ... 100
7.1. Conclusion ... 100
6 7.2. Future research ... 101 References ... 102 Appendix A. Complete testing results for PLC 1 ... 103
7
1. Introduction / Motivation of the topic
1.1. Introduction to ICS
Industrial Control System (ICS) is a general term used to describe different types of control systems that are used for industrial process control. ICS term includes different devices, systems and networks. ICS are normally used in a number of industries such as water, electrical, oil and gas, transportation, chemical, automotive, food and many more [1].
There exist several types of possible ICS systems, such as Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS) or Safety Instrumented Systems. Additionally, major parts of ICS are specific devices, such as Programmable Logic Controllers (PLC), Remote Terminal Units (RTU), specific industrial network devices. A PLC is one of the most sophisticated type of ICS devices and is a form of industrial computer that is designed to function in harsh industrial conditions. A PLC is typically used to directly control industrial processes. Moreover, a PLC could be also used in civil applications, such as controlling traffic lights.
The difference between different types of ICS is presented in the Figure 1. Difference between ICS/SCADA/DCS/PLC.
Figure 1. Difference between ICS/SCADA/DCS/PLC.
Industrial control systems in modern understanding have been around since 1950 [2]. The first PLC was developed in USA in 1968. New technologies keep emerging, such as the Internet of Things (IoT), cloud computing or connected cars. This major trend of digitalization can also be referred to as Industry 4.0 or the 4th industrial revolution. Overall, Industry 4.0 refers to manufactory automation (“smart factories”), describes the way we produce goods, and characterizes the industrial sector nowadays. Thus, industrial control systems have also faced major changes in their design – turning into cyber-physical systems instead of simply physical.
ICS become more interconnected and the boundaries between classic IT systems and ICS become less clear. IT protocols such as IP, TCP tend to be used within ICS due to their simplicity and widespread.
Historically, there was a separation between Operational Technologies (OT), which could be roughly explained as hardware and software that is used for controlling physical embedded devices, and IT. Therefore, ICS were considered to be “air-gapped” from classical IT and the
ICS
SCADA
DCS PLC
8 Internet and thus were considered to be secure from possible security attacks. Unfortunately, recent cyber security incidents within ICS domain proved this theory to be wrong [3, 4].
1.2. Problem statement
With this rise of IT field, questions of cyber security keep getting more priority. In the recent years, the severity and frequency of cyber-attacks is increasing. All of those trends lead to the fact that ICS, that originally were not designed to be secure against state of the art cyber-attacks and are supposed to be used in place for 10-20 years, become vulnerable. The number of reported incidents in the sphere of ICS rises, the most severe example being the malware Stuxnet [3]. Stuxnet was specifically designed to target PLC and caused major damage to Iran’s nuclear program in 2010. This was the first major incident to cause disturbances of ICS. As an example of recent malware specific to ICS, we could refer to TRITON [4]. TRITON was targeting Safety Instrumented Systems (SIS) causing them to falsely enter safe mode and thus shutting down the whole industrial process.
Recent studies [4, 6] show an overall increase of awareness of industrial companies regarding cyber security issues and their preparedness to take actions to prevail them. Unfortunately, the maturity of ICS cybersecurity still remains low, but trending to increase steadily. The experts in [3] claim that “managing risks and compliance is the key” to cybersecurity in the industrial environment. At the same time, the level of compliance to guidance and regulations in the sphere of ICS is relatively low. It could be explained by the fact that currently there exist multiple guidelines, recommendations and standards that often overlap or even contradict each other in their requirements. Thus, there is a clear need of a unified framework that could be used by industrial companies to build their security upon and to be able to test it. Creating such a framework is the goal of this research. By all means, compliance to cyber security guidelines does not always mean high level of cyber security but it could be considered as a first major step, especially for the companies that do not have required expertise in security.
Meanwhile, there is another part of the problem – the lack of mandatory cyber security certification schemes that allows vendors of ICS equipment to keep producing insecure devices.
Majority of manufacturers are unaware of any existing standards or recommendations in the domain of ICS cyber security.
To overcome these issues there exists a need of creating a single unified framework for assessing cyber security of ICS that would combine all relevant requirements and provide guidelines on how to assess them. Moreover, this framework should be highly advertised and accepted on a European or even international level. As a starting point for the Master Thesis, it was decided to focus on the security assessment of ICS devices and possible certification schemes. The final name of created framework is “Standardized Security Assessment Framework for ICS Devices” (hereinafter referred to as the Framework or created framework).
1.3. Research questions
Taking into consideration the problem stated in section 1.2, we are going to formulate two main research question as followed:
1. What standards for ICS cyber security could be considered the most relevant and how to merge all requirements from chosen standards into a single framework for assessing the cyber security of ICS devices?
9 2. How the requirements presented in the created framework could be tested to assess the
cyber security for ICS devices?
To be able to answer the main research questions we need to answer a number of subquestions:
1. What are the most relevant standards for ICS cyber security based on country/zone of influence, organization-developer, scope, requirements elaboration?
2. How could the requirements from selected standards be merged together to create a single framework for assessing the cyber security of ICS devices?
3. What types of security levels could be introduced within the framework for the purpose of a certification scheme?
4. How to test all the requirements introduced within the framework?
5. What tools should be used for testing?
6. Is it technically feasible to test all the requirements introduced within the framework?
7. In which way can the framework be used for testing and certification?
1.4. Relevance
1.4.1. Academic relevance
With the rise of awareness in the field of ICS cyber security, more and more new guidelines (recommendation, standards, checklists) keep emerging in different countries. Even though those documents have slightly different focus, they all aim at the same goal – increase maturity of cyber security for industry. The problem here is that not all of those documents work well together, because there is no solid basis to which they can refer and be further adapted to specific needs. Moreover, they all are presented in different formats: recommendations, guidelines, standards. This leads to complication when it comes to choosing which source to implement and to follow. The value of the current research for academic purposes is that we are providing this basis based on already existing standards that proved their value and are currently being used in ICS industry. The ultimate goal is to be able to create a single framework that could be used by different countries and be adapted for their use cases. Current research is a first step towards reaching this goal. By analysing and performing the overlap of more than two hundred requirements from five different documents (guidelines, recommendations, standards) we simplified the future work for academic field and allowed to avoid duplication of work. Additionally, we tried to make all requirements less ambiguous and add more detailed explanation to avoid possible misinterpretations.
1.4.2. Industry relevance
Even though current research is highly relevant for the academic field, it is even more relevant for practical implementation within ICS industry. For industries, the main added advantage of our research is the description of methods and tools that are required to assess compliance. For every requirement, we introduced explanation on how this requirement should be tested, what information could be found in documentation and what possible tools (software of hardware) could be required to perform the technical assessment.
The additional value that framework brings is an opportunity to improve current certification schemes for ICS. Since the certification of ICS is a relatively new topic, most of certification laboratories have not yet reached a high maturity level. The main problem they face is how to correctly interpret requirements and most importantly how to actually test them: should the focus be on documentation review or actual technical testing. That is where the framework
10 comes in hand. It explains what types of tests should be sufficient to assess the compliance of each requirement and how to proceed with the assessment process. Currently Secura B.V. is actively involved in improving the assessment methodology, together with certification bodies.
Moreover, combining of five most complete guidelines allows to address cyber security for ICS devices from all perspectives. The framework has a highly practical approach which has not been introduced before. It is especially relevant to industrial companies that use ICS devices to control industrial processes but are not used to consider cyber security when it comes to introducing new devices within their systems. Following the guidelines presented in the Framework they can assess the security level of ICS devices they currently use without support from IT integrators which will allow to cut financial expenses for those companies. For manufacturers of ICS devices following the created framework during testing process would allow to strengthen overall security of their devices, since it will allow them to identify all possible weak features and identify how they can be improved.
To summarize, the created framework could be used by:
Testing laboratories and certification bodies for cyber security to provide extensive assessment for the tested devices;
Industrial companies to assess if certain devices should be introduced within their systems and which risks it could bring;
Manufacturers (vendors) creating ICS devices to assess their security;
1.5. Structure of the thesis
In chapter two we are going to introduce the literature overview. It contains three main parts:
general background on ICS security, discussion about different standards related to ICS security and identification of possible existing certification schemes.
Chapter three provides a description for research methodology and steps that were taken in order to answer stated research questions and all related subquestions.
In chapter four we provide research results, including information regarding choosing of relevant requirements and overlapping them and the final version of Standardized Security Assessment Framework for ICS Devices.
Chapter five reports on evaluation process (pilot project) including results of testing of three different ICS devices in accordance with created framework. Additionally in this chapter we provide comparison of testing results.
In chapter six we discuss the obtained results and provid recommendation for securing the tested ICS devices based on the assessment, by implementing it in cooperation with certain security systems. Moreover, we reflect on limitations that we faced during the research project.
Finally, chapter seven concludes the research project and provides additional outline for possible future work.
11
2. Literature review
2.1. Brief overview on ICS security
Until recently, ICS were considered secure due to their isolation from internet and classical IT infrastructure, which is why they were not build to be secure and resilient against potential cyber security attacks. Introduction of open standards such as Ethernet, TCP/IP and web- technologies within operation technology to increase connectivity opened the door for attackers to exploit vulnerable systems.
First major researches in the field of ICS security started to emerge in the beginning of 2000th and gained the focus of research society after the incident with Stuxnet [3] together with the first attempts to introduce guidelines. The main topics of research were different: starting from analysing myths and actual facts behind ICS cyber security in [7] and finishing at outlining main challenges that ICS face [8].
The main conclusion that could be derived from the publications is that the ICS field is currently in a transition from being completely closed and isolated, to interconnectivity and that it will take some time for industries to be able to keep up with rising cyber security challenges. The key of doing so is by raising awareness, that cyber threats are real and they need to be addressed.
For our research we are going to focus on identifying and analyzing the most relevant standards for ICS cyber security that support the process of raising awareness and securing ICS.
2.2. ICS security standards
As was mentioned in Part 1 of this document, currently there exist a number of different guidelines, recommendations and regulations in the area of ICS cyber security. The short description of these documents could be found in Table 1. List of all possible standards / guidelines / recommendations for ICS cybersecurity. Further, you can find brief analysis for all eight regulatory documents:
1. IEC62443 series. Industrial communication networks – Network and system security [9].
2. NIST SP800-82. Guide to ICS security [10].
3. NERC-CIP. Version 5 CIP Cyber Security Standards [11].
4. NIST Framework for Improving Critical Infrastructure Cybersecurity [12]
5. UL2900-2-2. Outline of Investigation for Software Cybersecurity for Network- Connectable Products, Part 2-2: Particular requirements for ICS [13].
6. ENISA. Indispensable baseline security requirements for the procurement of secure ICT products and services [14].
7. NCSC. Checklist security of ICS/SCADA systems [15].
8. MSB. Guide to increased security in industrial information and control systems [16].
2.2.1. IEC62443 Series
IEC 62443 [9] is a series of standards created by the International Electrotechnical Commission (IEC), the international standards and conformity assessment body for all fields of electro- technology.
This series of standards was originally developed by ISA99 committee, part of the International Society of Automation and later adopted by IEC. The series of Standards consists of fourteen
12 different standards, together providing a flexible framework to secure industrial and automation control systems (IACS). The main security requirements for IACS products are introduced in two of these standards:
1. IEC 62443-4-2, Security for Industrial Automation and Control Systems: Technical Security Requirements for IACS Components.
2. IEC 62443-3-3, System Security Requirements and Security Level.
For the purpose of creating the Framework we focused on requirements from IEC 62443-4-2 and IEC 62443-3-3. Overall, both standards contain seven categories of basic requirements, defined as Functional Requirements (FR). Requirements include both technical and procedural/process aspects related to the product in scope.
Moreover, the series of standards introduces the concept of security levels (SL). The standards define four security levels for IACS products and systems, which would test the increasing level of security features used to protect against penetration within the system/component.
Additionally, they introduce three different types of security levels: target SL, achieved SL and capabilities SL.
2.2.2. NIST SP800-82
NIST SP800-82 [10] is a special publication (SP) “Guide to Industrial Control Systems Security” developed by National Institute of Standards and Technology (NIST) which is responsible for creating guidelines for all spheres of technology from the electronic health records to smart electric power grid for USA.
The publication is based on another publication by NIST “IT Security for Industrial Control Systems” (NISTIR6859), currently withdrawn. NIST SP800-82 outlines guidelines for securing ICS including all possible types such as Supervisory Control and Data Acquisition (SCADA), Distributed Control Systems (DCS) and Programmable Logic Controllers (PLC). The publication provides information about ICS and their typical topologies, points to specific ICS vulnerabilities and threats and gives recommendations on how to secure ICS.
NIST SP800-82 specifies eighteen control families for possible security measures in correlation with NIST SP800-53 “Security and Privacy Controls for Federal Information Systems and Organizations” [17]. The standard contains both technical and organizational related requirements.
2.2.3. NERC-CIP
NERC-CIP [11] is a series of standards for Critical Infrastructure Protection (CIP) developed by the North-American Reliability Corporation (NERC), which is a non-profit international regulatory authority responsible for developing and enforcing Reliability Standards to secure power grids in the United States, Canada and north Mexico.
NECR-CIP currently consists of eleven different standards that contain recommendations for bulk power systems; nine of those Standards include requirements both process related and technical. Additionally, it outlines physical security requirements. Overall, the series specify more than forty rules and almost one hundred sub-requirements.
13 Moreover, NERC-CIP introduces the Cyber System Categorization standard, which outlines the basics on how to classify bulk electric systems (BES) to further identify relevant requirements.
2.2.4. NIST Framework for Improving Critical Infrastructure Cybersecurity
Framework for Improving Critical Infrastructure Cybersecurity [12] is a publication created by NIST in 2018.
It describes a recommendatory risk management framework for critical infrastructure of USA to support management of cyber security risks for all involved parties. It outlines the basic guidelines to identify and manage risks and gives recommendation on how those guidelines could be adapted by any organization based on their used technologies. Additionally, it gives references to different widely accepted standards and guidelines for supported technologies.
With support of this framework organizations can:
- outline their current cyber security state;
- specify their target cyber security state;
- identify the processes to continuously improve their state of cyber security;
- assess the progress in reaching the target state;
- raise awareness of different stakeholders about possible cyber security risks.
The document is purely process-related and does not provide any technical recommendations on securing ICS.
2.2.5. UL2900-2-2
UL2900-2-2 [13] is a standard that outlines requirements for Industrial Control Systems developed by a global certification company Underwriters Laboratories (UL).
The goal of the standard is to be able to test and validate ICS. It addresses testing criteria for assessing cyber security of software components of ICS. It contains four main categories of requirements: risk controls, risk management, vulnerabilities and exploits, software weakness analysis with overall more than forty requirements presented.
UL2900-2-2 should be considered together with another standard developed by UL – 2900-1- 1 [18] that specifies general requirements for network-connectable devices to receive extra guidance for certain requirements.
2.2.6. ENISA
ENISA “Indispensable baseline security requirements for the procurement of secure ICT products and services” [14] is a paper developed by European Union Agency for Network and Information Security, which is a center of expertise for cyber security in Europe with main focus on network and information security.
The paper outlines basic minimum security requirements for procurement of information and communications technology (ICT) products. The main goal of this paper is to help companies avoid possible “lock-in” to specific vendors of software and hardware and providers of services.
The ENISA paper is based upon best practices and commonly used standards in the field of cyber security chosen by experts. It does not substitute other certification schemes or commonly
14 known standards, instead it should be used as an addition to them. It specifies ten main categories of the requirements with almost forty requirements included. Most of these requirements are process related.
2.2.7. NCSC. Checklist security of ICS/SCADA systems
Checklist security of ICS/SCADA systems [15] was developed by National Cyber Security Center (NCSC) of Ministry of Security and Justice of the Netherlands. NCSC is the central information hub and main center of expertise in the field of cyber security in the Netherlands.
The Checklist was published in 2016 and outlines both organizational and technical measures to ensure cyber security of ICS domain.
It outlines seven main organizational measures, ten technical and operational measures and give brief explanation and references to all of them. The presented measures are introduced on a high level and do not explain how those measures should be tested or implemented.
2.2.8. MSB. Guide to increased security in industrial information and control systems Guide to increased security in industrial information and control systems was created by Swedish Civil Contingency Agency (MSB). MSB is responsible for preparing society for major accidents and crises, the Director of the Agency is appointed by the Swedish government.
The guide provides seventeen basic recommendations for increasing security of ICS. The provided recommendations are high level and contain both process related and technical recommendations. For each recommendation, the reference to another regulatory document is provided together with some examples and description of possible problems.
The main focus of this guide is to raise awareness about ICS security and provide explanation on why is it important to all actors involved in industrial processes.
2.3. ICS certification schemes
During the research, we additionally studied possible certification schemes for ICS. All certification schemes are based on IEC62443 series of standards, as the only worldwide- recognized ICS cyber security standard. Currently there exist two world recognized certification schemes for ICS:
- ISASecure™ certifications;
- IECEE certifications.
Moreover, there exist independent certification schemes, such as a scheme offered by TÜV SÜD.
The brief overview of existing certification schemes is introduced below.
2.3.1. ISASecure
ISASecure™ is a conformance certification program for independent certification of industrial automation and control products and systems. It is managed by ISCI – non-profit automation controls industry consortium.
ISASecure offers three certification schemes with four security assurance levels based on IEC62443 series of standards:
15 - ISASecure Embedded Device Security Assurance (EDSA) Certification based on
IEC62443-4-2);
- ISASecure System Security Assurance (SSA) Certification (based on IEC62443-3-3);
- ISASecure Security Development Lifecycle Assurance (SDLA) Certification (based on IEC62443-4-1).
ISASecure offers certification for off-the-shelf ICS systems, ICS devices and product development security lifecycle.
Currently there exist three accredited ISASecure Certification bodies from different countries.
ISASecure certified thirty five ICS devices and systems. The first certificate was issued in 2017.
2.3.2. IECEE
IECEE is International Electrotechnical Comission (IEC) System of Conformity Assessment Schemes for Electrotechnical Equipment and Components based on IEC International Standards.
IECEE offers five certification schemes according to IEC62443 series of standards:
- IEC 62443-2-4. Security for industrial automation and control systems - Part 2-4:
Security program requirements for IACS service providers;
- IEC 62443-2-4/AMD1. Amendment 1 - Security for industrial automation and control systems - Part 2-4: Security program requirements for IACS service providers;
- IEC 62443-3-3. Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels.
- IEC 62443-4-1. Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements ;
- IEC62443-4-2. Security for industrial automation and control systems - Part 4-2:
Technical security requirements for IACS components.
The first certification scheme was included in IECEE System in 2017 for IEC 62443-2-4. In total, there are thirty five certification bodies included in the scheme.
2.3.3. TÜV SÜD
TÜV SÜD is a technical service corporation based in Germany and working in the fields of industry, mobility and certification.
The company offers certification for product manufacturers, system integrators and control system operators for three standards of the IEC62443 series:
- IEC 62443-3-3. Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels.
- IEC 62443-4-1. Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements ;
- IEC62443-4-2. Security for industrial automation and control systems - Part 4-2:
Technical security requirements for IACS components.
TÜV SÜD is accredited according to IEC 62443 by the German Accreditation Body (DAkkS).
16 Table 1. List of all possible standards / guidelines / recommendations for ICS cybersecurity
# Originating country/
zone
Organiza
tion Name Field Description Number of requirements
1 Worldwide IEC IEC 62443 Series.
Industrial communication networks – Network and system security.
ICS (IACS) A series of standards, 2 types of main requirements:
3-3. System security requirements;
4-2. Technical security requirements for IACS components.
3-3. System security requirements.
Total: 7 categories, 57 requirements + requirement enhancements.
4-2. Technical security requirements for IACS components.
Total: 7 categories, 61 requirements + requirement enhancements.
2 USA NIST SP 800-82.
Guide to ICS security.
ICS Requirements are referenced to a main Standard SP 800-53 with a table of overlays presented.
It was created for cyber security of information systems used in the federal government. Often used in non- governmental organizations as a good practice standard.
18 control families.
Total: 177 requirements
3 USA NERC NERC-CIP
Critical infrastructure protection.
Cyber Security Standards.
Critical Infrastructure (electric sector)
A series of standards. Mandatory for power system operators in USA, Canada and North part of Mexico.
Referenced at IEC 62443, that they should work together.
The major requirements could be found in Security Management control CIP-003-5.
For each category there exists the specific standard with clarification.
9 standards with different requirements.
Total: 94 requirements.
4 USA NIST Framework for Improving Critical
Infrastructure Cybersecurity. Critical
Infrastructure A risk-based approach to managing cybersecurity risk, composed of three parts:
Core, Implementation Tiers, Profiles. Each component reinforces the connection between business mission and cybersecurity activities.
5 main categories.
Total: 108 requirements
5 Company
specific
UL 2900-2-2.
Outline of Investigation for Software Cybersecurity for Network-Connectable Products,
ICS The requirements created by a global company UL. Must be used together with global document UL 2900-1. Part 1: General requirements.
4 major categories.
Total: 46 requirements
17
Part 2-2: Particular requirements for ICS.
6 EU ENISA Indispensable baseline security requirements for the procurement of secure ICT products and services.
General ICT Generic requirements for the procurement of ICT products and services
10 categories.
Total: 39 requirements.
7 NL NCSC
(National Cyber Security Center)
Checklist security of ICS/SCADA
systems. ICS Organizational and technical measures that
are considered as good practice. Not detailed, high level requirements.
7 organizational measures, 10 technical measures.
Total: 17 requirements.
8 Sweden Swedish
Civil Contingen cy Agency (MSB)
Guide to increased security in industrial information and control systems.
ICS 17 general recommendations with references for each and one of them to the standard they are derived from, more like a summary.
For each recommendation there are given objectives, that are actual actions to be taken.
17 major recommendations.
Total: 17 requirements.
18
3. Research methodology
3.1. Conceptual model
Considering the nature of formulated research questions, we used Design Science (DS) research methodology to tackle them. This is a research methodology that was specifically designed to perform researches in the area of information technology. For our research we used methodology proposed in [19], the definition they use is as follows:
“Design science…creates and evaluates IT artifacts intended to solve identified organizational problems”.
There are six main activities identified in [19]:
1. Problem identification and motivation.
2. Defining the objectives for a solution.
3. Design and development.
4. Demonstration.
5. Evaluation.
6. Communication.
Figure 2. Design Science research methodology Defining objectives
for a solution
Design and development
Demonstration
Evaluation
Communication Problem identification
19 The methodology could be used as a cycle (Figure 2. Design Science research methodology) with iterations that help shaping the final solution and could possibly lead to changing of an original identified problem and objections for the solution.
To adapt the proposed methodology for the identified research questions we performed six following steps presented in Table 2. Correlation between research steps and results presented in the Thesis.
Table 2. Correlation between research steps and results presented in the Thesis
# Step Part of the Thesis
1 Problem identification and motivation 1
2 Defining the objectives for creating a framework 1
3 Framework development 2, 4
4 Defining methods/tools for testing process 4
5 Testing process 4
6 Reporting results 5, 6
3.1.1. Correlation of research questions with DS research methodology
The exact research methods of research methodology DS used to answer research questions are presented in Table 3. Correlation of research questions with DS research methodology.
Table 3. Correlation of research questions with DS research methodology
# Research question Step of DS research
methodology Main research questions
1 What standards for ICS cyber security could be considered most relevant and how to merge all introduced requirements in chosen standards into a single framework for assessing cyber security of ICS devices?
1-3
2 How requirements presented in the created framework could be tested
to assess cyber security for ICS devices? 4-5
Sub-questions
1 What are the most relevant standards for ICS cyber security based on country/zone of influence, organization-developer, scope, requirements elaboration?
2-3
2 How could be requirements from selected standards be merged together to create a single framework for assessing cyber security of ICS
devices?
3
3 What types of security levels could be introduced within a framework
for certification scheme? 3
4 How to test all the requirements introduced within the framework? 4
5 What tools should be used for testing? 4
6 Is it technically feasible to test all the requirements introduced within
the framework? 5
7 In which way can the framework be used for testing and certification? 6
20
4. Research results
4.1. Selection of ICS security standards and relevant requirements
As was discussed in Chapter 3 of the Master Thesis eight different guidelines (standards, recommendations, checklists etc.) regarding ICS security were analyzed. The performed analysis revealed that not all of the selected standards are relevant to the main goal of the Master Thesis. Therefore, we further analyzed the standards and compared them based on a number of parameters. The important parameters for comparison are:
type of the document (standards, guidelines, recommendations etc.);
status (mandatory, recommendatory);
zone of influence (worldwide, USA, Europe);
type of included requirements (technical, administrative);
scope (system-related, device-related).
For our Framework we selected the documents that fit at least three of five following criteria:
type: standard or guidelines;
status: mandatory;
zone of influence: worldwide or Europe;
type of requirements: technical;
scope: devices-related.
The result of analysis is Presented in Table 4. Comparison analysis of ICS regulatory documents. Underlined are the parameters that follow previously described criteria.
Table 4. Comparison analysis of ICS regulatory documents.
Name of the
document Type of the
document Status Zone of
influence Type of
requirements Scope IEC 62443
Series Standard Recommendatory Worldwide Technical System-related Device-related NIST SP 800-
82 Guidelines Recommendatory USA Technical
Administrative System-related Device-related
NERC-CIP Standard Mandatory USA,
Canada, North Mexico
Technical
Administrative System-related
UL 2900-2-2 Guidelines Recommendatory Worldwide Technical Administrative
Device-related ENISA
Indispensable baseline security requirements for the
procurement of secure ICT products and services
Guidelines Recommendatory Europe Technical
Administrative System-related Device-related
NCSC Checklist security of
Guidelines Recommendatory NL Technical
Administrative System-related
21
ICS/SCADA systems Guide to increased security in industrial information and control systems
Guidelines Recommendatory Sweden Administrative System-related
NIST
Framework for Improving Critical Infrastructure Cybersecurity
Framework Recommendatory USA Administrative System-related
Therefore, this leads us to five final documents that were used to create the Framework:
1. IEC62443 series. Industrial communication networks – Network and system security [9].
2. NIST SP800-82. Guide to ICS security [10].
3. NERC-CIP. Version 5 CIP Cyber Security Standards [11].
4. UL2900-2-2. Outline of Investigation for Software Cybersecurity for Network- Connectable Products, Part 2-2: Particular requirements for ICS [12].
5. ENISA. Indispensable baseline security requirements for the procurement of secure ICT products and services [13].
4.2. Design of Standardized Security Assessment Framework
To simplify navigation in the created framework it was decided to create it in the format of an Excel file. To fully represent all collected information during the analysis of related regulatory documents the Framework contains following parts (each represented in a form of separate sheet):
Document info. Basic information about the Framework.
Relevant standards. Description of chosen as relevant standards in part 4.1 of this Thesis.
All requirements. All possible requirements taken from five chosen standards.
All requirements (commented). All possible requirements with extra comments on how they were integrated further.
Merged requirements. The final requirements of the Framework after overlapping process with a comment field to trace the original requirement.
Security levels (SL). Dedicated Security Level (SL) for each of final requirements.
Methods/tools. Description of methods and tools that are used for testing of the final requirements.
IEC62443-3-3 checklist. Correlation between final requirements of the Framework and IEC62443-3-3.
Appendix 1. Requirements for Secure Mechanisms for Storing Sensitive Data and Personally Identifiable data.
Appendix 2. Requirements for Security Functions.
22 More detailed description of main parts of the Framework is presented in Parts 4.3-4.5 of the Master Thesis.
4.3. Requirements overlapping
As a first step to overlap requirements into a single framework we extracted all possible requirements from five chosen in Part 4.1 standards and included them into a single table.
Overall, there were identified sixteen different categories for requirements and in total two hundred twenty seven requirements.
Next, we identified the major document that was going to be used as a basis1 for our Framework.
The only analysed document that has a status of a standard and thus could be considered as a priority to all the rest of the chosen documents is IEC62443-4-2.
As a further step, we analysed all extracted requirements to create a limited number of categories. Based on the selected standard we identified seven possible groups of which all the requirements could be part of (five of those groups completely correlate with the fundamental requirements from IEC62443-4-2). Those groups are as follows:
1. Identification and Authentication control (IAC).
2. Use control (UC).
3. Audit and accountability (AU).
4. System integrity and authenticity (SIA).
5. Data confidentiality (DC).
6. System and communication protection (SCP).
7. Security by design (SD).
Next step was to assign categories for all extracted requirements. First, we started with requirements from IEC62443-4-2 since it was chosen as a basis. After we put all requirements from IEC62443-4-2 into dedicated categories, we started with dividing all the rest of requirements into the same categories. As a result, we received the same amount of requirements but split into seven categories.
Finally, since a lot of requirements overlap each other we performed an integration procedure.
Requirements from IEC62443-4-2 were taken as basic requirements. Additionally, some of the requirements have so-called “Requirement Enhancements” that could be used to strengthen the security. Rest of the requirements were processed in three different ways:
fully overlapping requirements – merged with basic requirements;
partly overlapping – added as extra part for basic requirement;
not overlapping – taken as new basic requirements.
Eventually this led us to one hundred seventeen requirements (one hundred thirsty six with enhancements) divided into seven categories. The process of overlapping could be traced back
1 By basis we mean that all requirements from the chosen document will be considered as main ones, requirements from other documents will be merged with them or added as additional
23 by following the information from “comment” part in the excel file of the Framework (sheet
“Merged requirements”).
The whole process of overlapping of the requirements could be presented in a form of simplified logic diagram (Figure 3. Simplified logic diagram for overlapping process of requirements).
Figure 3. Simplified logic diagram for overlapping process of requirements 4.4. Concept of security levels
Another important part of the Framework is the concept of Security Level (SL). The basic idea of SL was taken from series of standards IEC62443 [9]. The series of standards introduce three different types of SL:
Target SL (SL-T). Represents the necessary level of security that needs to be achieved for a particular IACS or a certain zone. Normally is chosen by industrial company by means of performing risk assessment.
Achieved SL (SL-A). Represents actual level of security for a particular IACS or a component. Could be measured after the system is implemented or in the state of final project. Could be done by industrial company or by system provider. Used to establish whether the goal for target SL was met.
24
Capabilities SL (SL-C). Represents a maximum possible SL that could be achieved if the component / system is properly configured. Could be done by industrial company or by system provider.
Four possible levels are introduced [9]:
SL 1. Protection against casual or coincidental violation.
SL 2. Protection against intentional violating using simple means with low resources, generic skills and low motivation.
SL 3. Protection against intentional violating using sophisticated means with moderate resources, system specific skills and moderate motivation.
SL 4. Protection against intentional violation using sophisticated means with extended resources, system specific skills and high motivation.
The goal of this work is to enable the process of assessing and certifying ICS devices. Usually, any certification process states the level of certification which was achieved; in our case – security level. Thus, for the Framework it was decided to simplify the concept of security levels and leave only one type that could be used for certification purposes. The gradation system of four possible SL stays the same.
For every requirement from the Framework, a correlated SL was assigned. For requirements from IEC62443-4-2 the same level was assigned as used in the standard. Since only this standard introduces the concept of SL, for the rest of the requirements, the SL was chosen based on its content and similarity to requirements from IEC62443-4-2. Most of those requirements are more advanced comparing to requirements from IEC62443-4-2. Taking into consideration that most of the device currently are barely able to meet requirements for SL 1 for more advanced requirements we assigned SL 3 and SL 4 from gradation presented within the Framework.
4.5. Methods and tools used for testing
Additionally to perform the pilot project for the Master Thesis we added to the Framework a separate table with description of methods and tools which shall be used to assess security of ICS devices.
There are three main methods presented:
- reviewing the documentation for the tested device;
- technical verification by testing process;
- analysing the firmware.
Every requirement could be tested either by using one of those methods or a set of methods combined.
For each device, the vendor normally provides extensive documentation that is delivered together with the device or could be accessed via Internet through official vendor web-sites.
Additionally, vendor web-sites commonly contain the section with answering users’ questions.
Analyzing all this documentation and all relevant information found on the Internet is an essential step in assessing security of a device.
Additionally, when possible all information found in the documentation should be verified by actual technical testing. Moreover, often the documentation does not contain all needed
25 information, thus technical testing is the only way to assess whether requirement is met or not met. To simplify testing process on Step 5 we provided brief description on how to proceed with testing for every requirement.
In cases when no information could be found in documentation or on-line and there is no clear way to test any particular requirement we attempted to analyse the devices’ firmware. However, in most cases ICS devices have proprietary firmware installed that requires performing reverse- engineering, which is out of scope of current Master Thesis due to complexity and high time consummation.
Different tools could be used to perform technical testing. Most of the tools are typical for penetration testing, the description of tools used for assessment is presented in Part 5. Of the Master Thesis.
Some of the requirements could be tested without a need for external tools but only require established connection with a tested device with a personal computer (PC). Those requirements are usually assessed to verify that some functions of the device are implemented as described in documentation.
4.6. Final Standardized Security Assessment Framework
The final version of the Standardized Security Assessment Framework for ICS [20] in excel file could be provided upon request.
In the Master Thesis we included the merged requirements of the Framework which are presented in Table 5. Framework1.
The table has following columns:
- Category. The name of one of the seven group for requirements.
- Requirement name. The name of the requirement.
- Description. The full description and explanation what the requirement mean.
- Possible enhancements. Additional measures that should be implemented.
- Type. There are three main types of requirements: ICS specific (specifically formulated to be relevant to ICS), General (relevant to IT in general), device specific (depend on type of ICS device: HDR, NDR, EDR). ICS specific and General requirements are relevant to all types of devices; device specific depend on the type of the device.
- Security level. The reference to SL (in terms of created framework).
1 The exact source for every requirement is not include in the Master Thesis, since some of the Standards are not available in open access, so were specifically purchased by Secura B.V. Publishing contains of the Standards are prohibited by confidentiality agreement
