From cybersecurity strategy to technical projects, many companies struggle with how to put theory into practice for industrial control systems (ICS). Although it is difficult to completely cover the full range of the IEC 62443 standards and the related literature, this blog summarizes the key points for the IEC 62443 standards and provides some practical recommendations for Cybersecurity Management System (CSMS) development. This blog will also consider the importance of product and company certifications to support asset owners in their journey towards IEC 62443 compliance.

I. Executive Summary

This blog considers different aspects of how the IEC 62443 standard provides a holistic and wide-ranging approach to securing industrial control systems. The first step before creating a CSMS is to have the management team’s support to ensure the CSMS will have sufficient financial and organizational support to implement necessary actions. Afterwards, a risk assessment should be performed to understand the company risks, respective security levels (SL), and critical assets.

Once the risk and security factors are defined, it is necessary to develop countermeasures to bring the SuC to a level of risk that the company is willing to accept. This comprises of different steps and techniques, such as defense in depth and the creation of zones and conduits to provide different levels of protection.

A further step is the security monitoring for enhancing network visibility and planning how to respond to incidents. Finally, the human factor and supply chain management aspects should also be considered throughout the CSMS development process.

II. Introduction

In general, many companies struggle with how to transform theory into practical actions. These challenges range from how to gain the executives’ buy-in for cybersecurity strategy, to which technology will better fit their needs, and what the most relevant risks are for technical projects. This blog provides some guidance on how to perform key actions recommended by the IEC 62443 standards. Although we are just scratching the surface of this extensive work, this blog may help technicians and executives to improve their understanding of the standard recommendations.[5][6]

The series of IEC 62443 standards provide a holistic and wide-ranging approach to securing industrial control systems (ICS). These standards are holistic because they embrace the different structural aspects of security strategy, defined by the International Electrotechnical Commission (IEC) as People, Process, and Technology. In addition, these standards are wide-ranging because they cover a lot of ground providing internal and external recommendations to asset owners, supply chain management, and product development. For asset owners, the IEC 62443 standard recommends the creation of a Cybersecurity Management System (CSMS) that includes analyzing, addressing, monitoring, and improving the system against risks, according to the company’s risk appetite. For supply chain management, the specifications recommend security development throughout the product lifecycle. It starts from aspects of secure by design and extends to product manufacturing. The goal is to develop and maintain a reasonable level of security in the products and systems the solution provider offers during the product life cycle.[1][2][3][4]

The cybersecurity management system (CSMS) proposed by the IEC 62443 standard has six main elements:

1. Initiating the CSMS program (to provide the information that is required to get support from management).
2. High-level risk assessment (identifying and assessing the priority of risks).
3. Detailed risk assessment (detailed technical assessment of vulnerabilities).
4. Establish security, organization, and awareness policies.
5. Selecting and implementing countermeasures (to lower risk to the organization).
6. Maintaining the CSMS (to ensure the CSMS remains effective and supports the organization’s goals).[4]

III. Management Support

Before starting to consider technical aspects, the first important recommendation from the IEC 62443 standard is to consider the business rational and obtain support from management. To obtain support, the company needs to have a clear understanding of the systems, subsystems, and respective components that are essential or critical to operation and safety. Once this has been established, it will be easier to communicate to management the possible consequences if any component is impacted.[4]

A. Critical Assets

Critical assets include any device that, once compromised, may generate a high financial, health, safety, or environmental impact to an organization. The list of the company’s critical assets forms the basis of the risk management analysis and will be used to guide further decisions.[18]

B. Business Rationale

Once the company has identified the critical assets, it is necessary to obtain the management engagement and commitment to invest in the cybersecurity plan that will be developed. Without this support, the plan has a very low chance of success. High-level management should approve and participate in defining the business rationale to ensure the CSMS will have enough resources and support to deploy the necessary changes to the system and throughout the entire organization. In some cases, it is necessary to create a business case or business rationale, as suggested by the IEC 62443 standard to present to the management team. The business case or business rational contains a list of the potential threats and the possible consequences to the business with an estimation of the costs annually, as well as the cost of any countermeasures. This will provide a clear overview of the risks and costs for mitigation to acceptable levels, increasing the chances of obtaining support from management.[4][7][8]

IV. Risk Assessment

Once the management team is engaged and committed to supporting the CSMS, it is important to perform a risk assessment. Risk assessment is part of the overall risk management strategy of every company and it is a mandatory step to create a solid and efficient cybersecurity strategy. It requires correlation and collaboration between many different groups of people within the company. These levels have been defined by the National Institute of Standards and Technology (NIST) at the organization, mission/business processes, and information system (IT and ICS) levels.[11][13]

Risk management aims to assess and understand the different types of risks the company is susceptible to in different areas such as investment, budgeting, legal liability, safety, inventory, and supply chain risks. The focus of this blog will be on the ICS risks, which is generally agreed to pose one of the greatest potential areas of risk.[9][10][12]

To perform a risk assessment of the ICS, it is necessary to define the scope and boundaries of the system that will be assessed, also known as the System under Consideration (SuC). Once the SuC is defined, it is necessary to systematically identify, analyze the threats and vulnerabilities, and prioritize the risks based on their potential consequences. At the same time, it is also important to define asset criticality and dependencies to the operation.[9]

The risk formula is as follows:[1][2][4]

Likelihood _{Event_Occurring}=

Likelihood _{Threat_Realized} × Likelihood _{Vulnerability_Exploited} [1]

Risk = Likelihood _{Event_Occurring} × Consequence [2]

There are two different types of risk assessments applicable to ICS: high level and detailed risk assessments. As their names suggest, one approach deals primarily with high-level concepts and the other involves a detailed look at the different types of risk. It is common to perform a high-level risk assessment to support the business rationale and business case, with the latter performing a detailed risk assessment to ensure the system has specific countermeasures included in the design.[4][9][10][13][14]

An expected outcome from this step is to be able to form a comprehensive list of critical assets and determine where connectivity is taking place. The assessment should also be able to identify dependencies, determine what the critical risks are to the operation/safety of these processes, and the appropriate responses to these risks, which include the partition of the system into zones and conduits to mitigate risks to levels the company can accept.[15]

V. Defense in Depth

One of the most common security weaknesses in an ICS is the use of flat networks where there are no internal layers of protection and segregation, allowing all the devices to communicate with each other, even if it is not necessary. This is an undesirable scenario due to different internal and external factors: the facilitation of threats propagation (external factor) and the communication degradation (internal factor), which both result from a lack of control of the information on the network.[30]

To address this type of problem, upon completing the high-level cybersecurity risk assessment, it is necessary to begin the initial partitioning of the SuC. Each partition is called a zone. The concept of zones is detailed in the next section, but it also forms an important part of the broader concept of the defense-in-depth approach.[18]

Defense in depth is a military concept that provides different levels or layers of protection against a potential attacker or intruder trying to hack the SuC. In the context of a network, the result is a different tailored cybersecurity countermeasure deployed throughout the system. Although it is closely linked to technology, defense in depth should also consider other aspects, such as people and processes, as part of its deployment. Some important aspects of defense in depth include, but are not limited to, physical security, ICS network architecture (zones and conduits), ICS network perimeter security (firewalls and jump servers), host or device security, security monitoring, the human element, and vendor management.[10][19]

A. Establishment of Zones and Conduits

A zone, as part of the defense-in-depth strategy, is a subset of the network communication system where all the communication devices share the same security requirement and consequently are equally critical. It is possible to have a zone inside another zone with different security requirements.

Conduits provide inspection and protection of the communications shared by different zones. Zones and conduits can be established in the physical or logical sense. Lastly, conduits include the concept of a channel, which is a specific link within the conduit that respects the security level of the conduits where it is inserted. All these concepts are intended to achieve uniformity in protection. It should be noted that each zone is only as secure as its weakest link, therefore, it is highly recommended to isolate the high-risk assets into specific zones.[17]

B. Security Levels

An important part of the defense-in-depth strategy is to consider countermeasures for zones and internal products. Accordingly, the IEC 62443 standard introduces the concept of security levels (SL) that can be applied to zones, conduits, channels, and products. The security level is defined by researching a particular device, and then determining what level of security it should have, depending on its place in the system. The security levels may be classified into four distinct levels 1 to 4, (although the standard also mentions an “open” level 0 that is rarely used):

• Level 1 is a casual exposure
• Level 2 is an intentional attack with low resources
• Level 3 is an intentional attack with moderate resources
• Level 4 is an intentional attack with extensive resources

Once the security level target of a zone is defined, it is necessary to analyze if the devices inside the zone can meet the corresponding security level. If they do not, it is necessary to plan which countermeasures can help reach the SL target. These countermeasures can be technical (e.g., firewall), administrative (e.g., policies and procedures), or physical (e.g., locked doors).[17]

C. Protection of Critical Assets

As discussed in Section II, critical assets are essential to the correct operation of the ICS. Any impact on those assets may have a high financial, health, safety, or environmental impact on an organization. Those assets should always have a high priority in the risk assessment and in the company security strategy.

The criticality assessment is one input for the definition of scope and zone protection. This assessment identifies the level of impact that assets have on the organization. Other assessments, such as CARVER (Criticality, Accessibility, Recuperability), from the U.S. Department of Defense (DoD), aim to identify, from an attacker’s perspective, which targets could cause the largest impact to businesses. Regardless, it is expected that critical assets have higher security levels with proportional countermeasures that adhere to levels the company can accept. This is one of the reasons why the IEC 62443 standard foresees the use of zones inside zones with different security levels.[9][24][35]

D. Device Security

The same concept of security levels (SL) is also applied to products. The IEC 62443-4-2 defines the security requirements for four types of components: software application requirements (SAR), embedded device requirements (EDR), host device requirements (HDR), and network device requirements (NDR). There are also seven different perspectives, defined as foundational requirements (FR) for each type of component, including identification and authentication control (IAC), use control (UC), system integrity (SI), data confidentiality (DC), restricted data flow (RDF), timely response to events (TRE), and resource availability (RA). These definitions help asset owners simplify technical specifications and the product selection process, ensuring the expected security level is applied to their application, as each security level (SL) has distinct foundational requirements and details that can be tangibly measured and compared.[20]

In order to support an organization’s audit as to whether all of the above foundational requirements were really deployed on the devices, there are different laboratories, such as ISA Secure, that can certify products that satisfy the requirements of IEC 62443-4-2. These laboratories simplify the selection process for the asset owner, as all they need to do is determine the level of security required and select a certified product that meets that requirement. Consequently, all security features that the organization needs to satisfy the security requirements for the defined SL will be available.[21]

This component level security assurance adds another layer of protection to the system as part of a defense-in-depth strategy. This is known as hardening, and facilitates security level zone protection.[22][23]

VI. Security Monitoring for Enhancing Visibility

According to the U.S. Department of Homeland Security, in 2016, the most common threat was “unknown.” As it was only possible to manage what is visible, most incidents could not be investigated due to a lack of visibility, making it difficult to identify threats, understand how threats pass through defenses, and determine the steps taken to identify the origin of the attack. This is known as forensic analysis and provides important information to asset owners so they can understand how the incident happened and help avoid similar incidents in the future.[36][37][38]

Enhancing visibility requires a proper cybersecurity strategy to continuously monitor the system in order to identify potential threats that passed any defenses that were implemented.[4][24][25][26][27]

The most common solution for monitoring a network is a network intrusion detection system (NIDS), or simply, Intrusion Detection System (IDS). It enhances network visibility through the monitoring of anomalies in network traffic or malicious signatures. Adoption of an IDS facilitates forensic analysis and a response to the incident. To enhance efficiency, any forensic data collected from the IDS and other devices should be synchronized, as this will facilitate proper correlation analysis among the different types of data collected.[10]

It is also necessary to have a proper understanding of how to calculate the number of sensors needed, define where to install them, and determine whether a passive or active topology is most suited to each application. Each one of these aspects has advantages and disadvantages that should be evaluated when selecting a monitoring solution.[39][40]

VII. Response to Incidents

Although network visibility is important, it is more important to respond to the incidents detected, which requires a cybersecurity incident response plan. In short, cybersecurity incident response planning is the preparation for any negative events that may affect the ICS and how to get back to normal as quickly as possible after the incident occurs. Its main elements include planning, incident prevention, detection, containment, remediation, recovery and restoration, and post incident analysis/forensics. It also requires proper communication paths and to assign respective owners who will conduct forensic analysis for each response.[4][24][25][26][27][41]

One current discussion is the use of an intrusion prevention system (IPS) inside the ICS to respond to certain types of incidents. An IPS may use different types of technologies, such as a signature-based detection (which monitors specific events and threats) or anomaly-based detection (which monitors changes in trends) to identify a threat and execute pre-approved responses. Although it may vary case by case, a general recommendation for increasing its effectiveness and minimizing false positives is that if the IPS uses anomaly-based detection, it is to train the IPS and its algorithm offline first (passively). In this manner, the IPS will learn the network patterns and provide some potential answers that can be validated by the security analyst first, increasing its effectiveness. For example, one of the most common types of attack is the denial of service (DoS) that affects the network traffic flow pattern. Due to the deterministic nature of an ICS, these attacks are easily detected and are a good starting point to calibrate the effectiveness of an IPS.[10][31][32]

VIII. Human Factors, Training, and Security Awareness

When it comes to cybersecurity, the human factor should also be considered. This is a wide and complex topic because humans can insert different vulnerabilities into a system. Social engineering and misconfiguration are common examples, independent of the motivation (intentional and unintentional) and their causes (e.g., fatigue or lack of expertise). It is necessary to implement countermeasures to minimize these risks.[28][29]

For this reason, the IEC 62443 standard specifically calls for regular staff training and security awareness to all employees, providing them the information needed to perform their responsibilities in a more secure way, in order to minimize the risks caused by human error.[4]

IX. Supply Chain Management and Support

Another important element that spreads across all previously discussed items is the security of the supply chain and solution providers. Suppliers should provide security throughout the product lifecycle, including support, quality control, validation of performance, and vulnerability responses, among other aspects. To support conformity with those aspects, the IEC 62443 standard has a specific subsection, IEC 62443-4-1, to specify the requirements for ensuring secure by design throughout the product lifecycle (i.e., building, maintaining, and discontinuing devices). These requirements are generally associated with the support needed for patch management, policies, procedures, and security communications about known vulnerabilities. Similar to the IEC 62443-4-2 standard for product certification, it is possible to certify that a solution provider is following good security management practices and adheres to tangible criteria in the IEC 62443-4-1 standard, simplifying the asset owner’s decision-making process.[10][33][34]

X. Conclusion

Although now it is possible to become certified for devices and supply chain according to the IEC 62443 recommendations, asset owners should still consider holistically implementing the IEC 62443 standard. The IEC 62443 standard brings together several important aspects widely discussed by a global community of subject matter experts (SME). Even though this blog considers some important aspects that were presented in a progressive and actionable manner, it is difficult to simplify such an extensive body of information such as the IEC 62443. As a result, it is highly recommended that companies looking to adopt the recommendations of the IEC 62443 standard into their own applications consult certified partners and experts as they embark on their IEC 62443 journey. 

References 

1. IEC: “IEC Cyber security Brochure overview,” 2018.
2. SH Piggin: “Development of industrial cyber security standards: IEC 62443 for SCADA and Industrial Control System security,” 2013.
3. M Portella, M Hoeve, F Hwa, et al: “Implementing An Isa/Iec-62443 And ISO/IEC-27001 OT Cyber Security Management System At Dutch DSO Enexis," 2019.
4. ANSI/ISA-62443-2-1: “Security for Industrial Automation and Control Systems Part 2-1: Establishing an Industrial Automation and Control Systems Security Program,” 2009.
5. Doan: “Companies Need to Rethink What Cybersecurity Leadership Is;” https://hbr.org/2019/11/companies-need-to-rethink-what-cybersecurity-leadership-is. Accessed May 17, 2019.
6. J Parenty, JJ Dome: “Sizing Up Your Cyberrisks;” https://hbr.org/2019/11/sizing-up-your-cyberrisks. Accessed May 17, 2019. 
7. Elkhannoubi, M Belaissaoui: “Fundamental pillars for an effective cybersecurity strategy,” 2015. 
8. Winkler I: "7 elements of a successful security awareness program," CSO;  https://www.csoonline.com/article/2133408/network-security-the-7-elements-of-a-successful-security-awareness-program.html. Accessed July 26, 2021.
9. ISA/IEC-62443-3-2: “Security for Industrial Automation and Control Systems: Security Risk Assessment and System Design,” 2015.
10. Homeland Security: “Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies,” 2016.
11. NIST SP 800-82 Rev. 2: “Guide to Industrial Control Systems (ICS) Security.”
12. FIPS PUB 200: “Minimum Security Requirements for Federal Information and Information Systems.”
13. NIST SP 800-39: “Managing Information Security Risk Organization, Mission, and Information System View,” 2011.
14. Ganin P, Quach M, Panwar Z, et al: “Multicriteria Decision Framework for Cybersecurity Risk Assessment and Management,” 2017.
15. Office of the Secretary of Defense: “Handbook for Self-Assessing Security Vulnerabilities and Risk of Industrial Control Systems on DOD Installations,” 2014.
16. NISTIR 8179: “Criticality Analysis Process Model,” 2018.
17. “IEC TS 62443-1-1:2009 Industrial communication networks - Network and system security - Part 1-1: Terminology, concepts and models,” 2009.
18. Papakonstantinou J, Linnosmaa A, Z Bashir, et al: "Early Combined Safety - Security Defense in Depth Assessment of Complex Systems," 2020.
19. Idaho National Laboratory: “Control Systems Cyber Security: Defense in Depth Strategies,” 2006.
20. ISA/ANSI-62443-4-2: “Security for industrial automation and control systems, Part 4-2: Technical security requirements for IACS components,” 2018. 
21. ISASecure: "IEC 62443 - CSA Certification;" https://www.isasecure.org/en-US/Certification/IEC-62443-CSA-Certification.
22. Kwan: “Ironshield Best Practices Hardening Foundry Routers & Switches,” 2003.
23. Laszka, W Abbas, Y Vorobeychik, et al: “Synergistic Security for the Industrial Internet of Things: Integrating Redundancy, Diversity, and Hardening,” 2018.
24. ANSI/ISA‑62443‑3‑3: “Security for industrial automation and control systems Part 3-3: System security requirements and security levels,” 2013.
25. ISO/IEC 27001: “Information technology — Security techniques — Information security management systems — Requirements,” 2013.
26. NIST SP 800-53 Rev 4; “Security and Privacy Controls for Federal Information Systems and Organizations.”
27. CIS Controls, 2019.
28. Dekker: “The Field Guide to Understanding 'Human Error'," 2011.
29. Adams, M Makramalla: “Cybersecurity Skills Training: An Attacker-Centric Gamified Approach,” 2015.
30. Homeland Security: “Common Cybersecurity Vulnerabilities in Industrial Control Systems,” 2011.
31. Nurcan Y, S Gönen: “Attack detection/prevention system against cyber attack in industrial control systems,” 2018.
32. Das, V Menon, TH Morris: “On the Edge Realtime Intrusion Prevention System for DoS Attack,” 2018. 
33. ISASecure: "IEC 62443 - SDLA Certification;" https://www.isasecure.org/en-US/Certification/IEC-62443-SDLA-Certification-(1).
34. IEC 62443-4-1: "Security for industrial automation and control systems Part 4-1: Secure product development lifecycle requirements," 2018.
35. Cook, R Smith, L Maglaras, et al: “Measuring the Risk of Cyber Attack in Industrial Control Systems,” 2016.
36. CISA: “Incident Response Pie Charts (YIR 2016 Addendum),” 2016.
37. Spyridopoulos, T Tryfonas, J May: “Incident Analysis & Digital Forensics in SCADA and Industrial Control Systems,” 2013.
38. AP Rodrigues, RO Albuquerque, FEG Deus, et al: “Cybersecurity and Network Forensics: Analysis of Malicious Traffic towards a Honeynet with Deep Packet Inspection,” 2017.
39. S Ashoor, S Gore: “Importance of Intrusion Detection System (IDS),” 2011.
40. Homeland Security: “Recommended Practice: Creating Cyber Forensics Plans for Control Systems,” 2008.
41. Homeland Security: “Developing an Industrial Control Systems Cybersecurity Incident Response Capability,” 2009.

View in Portuguese: https://senhasegura.com/pt-br/uma-abordagem-pratica-para-adotar-as-normas-iec-62443/