Skip to content

Introduction to IEC 62443 – with solutions

Exercice 1 : Assessing a company maturity level ?

There exists many forms in which a company may assess its own maturity. In this particular case you will need to see how effective this can be using the tool made available by ICT minimum standards (https://www.ncsc.admin.ch/ncsc/en/home/infos-fuer/infos-it-spezialisten/themen/ikt-minimalstandards.html)?

Use the tool and state your opinion as far as

  • complexity of filling in the tool and time to be invested
  • readiness for OT systems
  • any other comment you may have
Solution

The solution is… what you have learned through the use of the tool 😉.

Obviously, one should come to the realization that

  1. the tool is an effective way to get an understanding what the company maturity is (with little investment)
  2. it does take critical infrastructures into account in the questions, though it clearly is not tailored solely at OT systems

Exercice 2 : Level: Maturity, Security - the same or different ?

In the theoretical part we discussed the term levels used throughout IEC 62443. Can you explain the main different between Maturity and Security Levels? Where do they originated from?

Solution

The terms do differenciate clearly. Namely

  1. SL indicate technical requirements for systems (IEC 62443-3-3) and products (IEC 62443-4-2) and are evaluated in the standard by four so-called Security Levels. The different levels indicate the resistance against different classes of attackers. The levels are

    1. Security Level 0: No special requirement or protection required.
    2. Security Level 1: Protection against unintentional or accidental misuse
    3. Security Level 2: Protection against intentional misuse by simple means with few resources, general skills and low motivation
    4. Security Level 3: Protection against intentional misuse by sophisticated means with moderate resources, automation-specific knowledge and moderate motivation
    5. Security Level 4: Protection against intentional misuse using sophisticated means with extensive resources, automation-specific knowledge and high motivation

  2. ML indicate a certain level of a maturity level, all process-related requirements must always be practiced during product development or integration, e.g. the selection of only individual criteria is not standard-compliant. This system is based on the Capability Maturity Model Integration (CMMI) framework. The maturity levels are described as follows:

    1. Maturity Level 1 - Initial: Product suppliers usually carry out product development ad hoc and often undocumented (or not fully documented).
    2. Maturity Level 2 - Managed: The product supplier is able to manage the development of a product according to written guidelines. It must be demonstrated that the personnel who carry out the process have the appropriate expertise, are trained and/or follow written procedures. The processes are repeatable.
    3. Maturity Level 3 - Defined (practiced): The process is repeatable throughout the supplier’s organization. The processes have been practiced and there is evidence that this has been done.
    4. Maturity Level 4 - Improving: Product suppliers use appropriate process metrics to monitor the effectiveness and performance of the process and demonstrate continuous improvement in these areas.

Exercice 3 : Rationale for certifying a company

You work for a company whose main business is delivering water to the households of a middle sized city. A new person has been appointed as CEO of this company and, while meeting with his management team that you are part of, asks what IEC 62443 part the company shall be certified in - he heard that holding such certification is invaluable for companies of the sector.

Please:

  • state what your reponse would be
  • list the advantages / disadvantages would be if your company was to undergo such certification
  • sketch a way to launch such certification process
Solution

You would explain to your CEO that the company is subject to strict cybersecurity requirements (among others) as it is qualified as a Critical Infrastructure by government definition.

You would also add that the IEC 62443 series is a set of standards that address the security of industrial automation and control systems. For a company in the water utility sector, the most relevant part of the IEC 62443 standard would likely be IEC 62443-2-4, which focuses on security program requirements for IACS (Industrial Automation and Control Systems) service providers. Additionally, IEC 62443-3-3, which deals with system security requirements and security levels, could also be highly relevant as it provides a framework for securing the systems that control and monitor water distribution.

Advantages and Disadvantages of IEC 62443 Certification

Advantages:

  1. Enhanced Security Posture:

    • Certification ensures that robust security measures are in place to protect critical infrastructure from cyber threats

  2. Regulatory Compliance:

    • Helps meet regulatory requirements and standards specific to the water utility sector, potentially avoiding fines and legal issues

  3. Customer Trust:

    • Demonstrates a commitment to security and reliability, enhancing customer confidence and trust

  4. Risk Management:

    • Provides a structured approach to identifying and mitigating risks, reducing the likelihood of security incidents

  5. Competitive Advantage:

    • Certification can differentiate the company from competitors, potentially opening up new business opportunities

Disadvantages:

  1. Cost:

    • The certification process can be expensive, requiring investment in consulting services, training, and potentially new security technologies/devices

  2. Time-Consuming:

    • Achieving certification can be a lengthy process, requiring significant time and resources from staff

  3. Complexity:

    • The standards can be complex and may require specialized knowledge to implement effectively

  4. Ongoing Maintenance:

    • Certification is not a one-time effort; it requires continuous monitoring, updating, and periodic re-certification

Sketching a Way to Launch the Certification Process

  1. Initial Assessment:

    • Conduct an initial assessment to understand the current security posture and identify gaps relative to the IEC 62443 standards
    • Engage with a consulting firm that specializes in IEC 62443 to provide guidance and support

  2. Management Commitment:

    • Secure commitment from top management to allocate necessary resources and support the certification process

  3. Project Planning:

    • Develop a detailed project plan outlining the steps, timeline, and resources required for certification
    • Assign a project manager and a cross-functional team to oversee the process

  4. Training and Awareness:

    • Provide training for employees on the IEC 62443 standards and their roles in achieving certification
    • Raise awareness about the importance of cybersecurity and the certification process

  5. Gap Analysis and Remediation:

    • Perform a detailed gap analysis to identify specific areas that need improvement
    • Develop and implement a remediation plan to address identified gaps

  6. Documentation:

    • Develop and update necessary documentation, including policies, procedures, and records required by the standard

  7. Internal Audit:

    • Conduct internal audits to ensure that the implemented measures meet the requirements of the IEC 62443 standard
    • Address any findings from the internal audit

  8. Certification Audit:

    • Engage a certified body to perform the official certification audit
    • Address any non-conformities identified during the audit

  9. Continuous Improvement:

    • Establish a process for continuous monitoring and improvement of the security program
    • Plan for periodic re-certification audits to maintain certification

Exercice 4 : What IEC 62443 family shall the following companies go for?

Given the following companies whose business is fundamentally different, what IEC certification would you suggest them to go for?

Companies:

  1. SPY - a service company specialized in converting a company vision, strategy and business requirements into OT architectures.
  2. Hi5 Energy - a company delivering Power Grids products and solutions Worldwide.
  3. Swisscowboy ERP Solutions - a company delivering Enterprise resource planning solutions tailored to the customers’ needs.
  4. SHEnergy (Schaffausen Energy) - a local energy provider whose strategy is to expand, within the same business, to distribute energy to entreprises and houses in different areas of France and Germany (in addition to expanding to neighbouring areas within Switzerland).
Solution

Here the suggested certification candidates for the cited companies:

Given the requirement to focus on the IEC 62443 family of standards, here are the tailored suggestions for each company:

  1. SPY - OT Architecture Service Company

    Suggested Certification: IEC 62443-2-4

    Justification:

    • IEC 62443-2-4 is specifically designed for service providers like SPY, which specializes in converting company visions and strategies into OT architectures
    • This certification focuses on the security capabilities of service providers, ensuring that SPY can demonstrate its expertise and commitment to securing industrial automation and control systems for its clients

  2. Hi5 Energy - Power Grids Products and Solutions

    Suggested Certification: IEC 62443-4-1 and IEC 62443-4-2

    Justification:

    • Hi5 Energy, which delivers power grid products and solutions worldwide, should consider IEC 62443-4-1 and IEC 62443-4-2
    • IEC 62443-4-1: This part of the standard focuses on secure product development lifecycle requirements. It is essential for Hi5 Energy as it ensures that security is integrated throughout the development process of their power grid products
    • IEC 62443-4-2: This part deals with technical security requirements for IACS components. Since Hi5 Energy provides products and solutions for power grids, adhering to IEC 62443-4-2 will ensure that their products meet the necessary technical security requirements, enhancing the overall security and reliability of their solutions

  3. Swisscowboy ERP Solutions - Custom ERP Solutions Provider

    Suggested Certification: None from the IEC 62443 family

    Justification:

    • Swisscowboy ERP Solutions specializes in delivering custom ERP solutions, which are primarily focused on IT systems and business processes rather than industrial automation and control systems. The IEC 62443 family of standards is specifically designed for industrial automation and control systems security
    • While IEC 62443-3-3 could be considered if their ERP solutions interface with OT environments, it is not the most applicable or likely certification for a company focused solely on ERP solutions. Instead, Swisscowboy ERP Solutions might be better suited to pursue certifications like ISO/IEC 27001, which focuses on information security management systems and is more aligned with IT and data security

  4. SHEnergy (Schaffhausen Energy) - Local Energy Provider

    Suggested Certification: IEC 62443-3-3

    Justification:

    • SHEnergy, as a local energy provider looking to expand, should consider IEC 62443-3-3. This standard focuses on the security requirements for systems, which is crucial for energy providers that rely on secure and resilient control systems
    • Implementing IEC 62443-3-3 will help SHEnergy ensure the security of its energy distribution systems, which is essential for reliable and safe operations as they expand into new markets

    Alternatively, though more general and not focused on the company expansion (which does enjoy the benefits of having a standardized architectural solution), IEC 62443-2-1: Security Program Requirements for IACS Asset Owners may be considered. This part of the standard is specifically designed for asset owners and provides requirements for establishing an IACS security management program. It covers aspects such as security policies, procedures, and organizational structures.

Exercice 5 : IEC 62443-2-4 - a Service Provider example

A company, SecureAutomation, is a professional services provider active in the IACS domain. Its comprehensive description can be read below

Company Description: SecureAutomation Inc.

SecureAutomation Inc. is a professional services provider specializing in Industrial Automation and Control System (IACS) cybersecurity. They offer comprehensive security solutions tailored to protect critical infrastructure and manufacturing facilities from emerging cyber threats.

SecureAutomation’s service portfolio encompasses a wide range of IACS security activities, with the exception of wireless network implementation and anti-malware software management. Their expert teams support clients in various industries by:

  1. Staffing dedicated personnel (SP.01) for automation solution related activities, ensuring clients have access to skilled resources when needed.
  2. Providing assurance services (SP.02) to validate that clients’ security policies are effectively enforced within their IACS environments.
  3. Collaborating with clients on architectural design (SP.03), incorporating security principles into the overall system architecture for better protection against cyber threats.
  4. Focusing on the secure integration of Safety Instrumented Systems (SIS) (SP.05) to ensure both safety and security are addressed in parallel.
  5. Implementing robust configuration management (SP.06) practices to maintain control over IACS components, minimizing the risk of unauthorized changes.
  6. Establishing and managing remote access controls (SP.07) to limit unauthorized access and prevent unauthorized data transfer.
  7. Defining effective event management strategies (SP.08), enabling clients to promptly detect and respond to security incidents.
  8. Administering user accounts (SP.09) securely, ensuring that only authorized individuals have access to IACS components.
  9. Implementing patch management processes (SP.11) to keep systems updated and protected against known vulnerabilities.
  10. Supporting clients in developing and maintaining comprehensive backup and restore procedures (SP.12), minimizing downtime in case of data loss or system failure.

By focusing on these core IACS cybersecurity activities, SecureAutomation Inc. helps its clients build robust, resilient, and secure industrial automation systems that protect their operations and assets from evolving cyber threats.

Question:

Given the above description, can you state what SecureAutomation’s self-assessment for the following IEC 62443-2-4 requirements will be?

For each requirement assume you will need to use 2 additional columns of the following format:

Compliant Comment (s)
1. Supported
2. Supported with some restrictions/partly needs clarifications
3. Not supported		 e.g. This will be externalize to company YXZ

1. Requirement 1

Req ID BR/RE Functional Area Topic Subtopic Doc?
SP.01.04 BR Solution staffing Background checks Service provider No
Requirement description Rationale
The service provider shall have the capability to ensure that it assigns only service provider personnel to Automation Solution related activities who have successfully passed security-related background checks, where feasible, and to the extent allowed by applicable law. “The capabilities specified by this BR and its REs are used to protect the Automation Solution from being staffed with personnel whose trustworthiness may be questionable. While the background check cannot guarantee trustworthiness, it can identify personnel who have had trouble with their trustworthiness.
Having this capability means that the service provider has an identifiable process for verifying the integrity of the service provider personnel it will assign to work on the Automation Solution. This requirement also recognizes that the ability to perform background checks is not always possible because of applicable laws or because of lack of support by local authorities and/or service organizations. For example, there may be countries that do not prohibit background checks, but that provide no support for conducting a background check, making it infeasible or impractical for the service provider to perform such a check.
How and how often background checks are performed are left to the service provider. Examples of background checks include identity verification and criminal record checks. “

2. Requirement 2

Req ID BR/RE Functional Area Topic Subtopic Doc?
SP.04.01 BR Wireless Network design Technical description No
Requirement description Rationale
“The service provider shall have the capability to ensure that its Automation Solution architecture documentation describing wireless systems is current in its description of the following.

1) Data exchange between a Level 1 network and wireless instrumentation,
2) Data exchange between a Level 2 network and a Level 3 network through a secure wireless link,
3) Security mechanisms that prevent an intruder from gaining access to the Automation Solution using the wireless system,
4) Security mechanisms that restrict access within the Automation Solution by workers with handheld wireless devices,
5) Where required, security mechanisms that provide protection for remote management of wireless systems.

NOTE 1 The term “”Level”” refers to the position in the Purdue Reference Model as standardized by ISA 95 and IEC 62264-1 (see clause 5.3). “		 “The capability specified by this BR is used to ensure that wireless networks are protected from being used to gain unauthorized access to the Automation Solution. Having this capability means that the service provider has an identifiable process for keeping current its wireless communications architecture documentation that includes data flows, security mechanisms, and the use of wireless bridges.

NOTE 2 Zones and conduits as described in IEC 62443-3-2 are often used to define the security boundaries associated with wireless access to wired devices/workstations in the Automation Solution.”

3. Requirement 3

Req ID BR/RE Functional Area Topic Subtopic Doc?
SP.10.04 BR Malware protection Manual process Malware definition files Yes
Requirement description Rationale
“The service provider shall have the capability to provide to the asset owner documentation that describes:

1) how malware definition files for the Automation Solution are evaluated and approved,
2) reporting the status of malware definition files to the asset owner within N days after release of the files by the manufacturer, where N has been agreed to by the service provider and asset owner. This status includes the applicability (e.g. component and version) and approval state (e.g. approved, installed, disapproved, etc.) for each malware definition file.		 “The capability specified by this BR is used to ensure that service provider has a process for verifying that new malware definition files are compatible with the Automation Solution and that they are available to the Automation Solution in a timely manner.
Having this capability means that the service provider has an identifiable process for approving malware definition files and informing the asset owner of the results within a mutually agreed to time period after their release by the anti-malware software manufacturer. This does not require installation within this time-period, it requires only that files are approved for installation within the time period. Approval means that the service provider has evaluated the files for conflicts with their system. Those that conflict with the operation of the system are not approved.”
Solution

The solution is

Req ID Compliant Comment (s)
SP.01.04 2. Supported with some restrictions/partly needs clarifications We do support this. However, we need to understand whether certain nationalities are restricted
SP.04.01 1. Supported This is realized through our official partner Ericsson Gmbh (link to dedicated document covering the solution)
SP.10.04 1. Not Supported We need to address through a partner. Candidates identified already and offers requested already. Once this process is finalized, we can change this by stating that “Supported, description defined by our partner according to document Doc. 125687”

Exercice 6 : IEC 62443-3-3 - a concrete System Architecture example

In the following document, named Practical Overview of Implementing IEC 62443 Security Levels in Industrial Control Applications, Schneider Electric explains how the different Security Levels may be implemented based on the architecture depicted below.

Can you explain :

  1. whether all Security Levels are covered?
  2. what Defense in Depth is according to this paper?
  3. what the major differences, as presented in the paper, between SL1 and SL2?
  4. whether any Device has been replaced and for what reason?
Solution
  1. No, SL4 is not present
  2. The steps cited are :
    1. Create a Security Plan
    2. Separate Networks
    3. Perimeter Protection
    4. Network Segmentation
    5. Device Hardening
    6. Monitor and Update
  3. SL2 includes requirements specified in SL1, and adds requirements(specifically IEC 62443-3-3 specifies 23 of them) - in the paper these have been defined as 11 (see page 9). It is important to note that some of the requirements are enhancements to requirements specified in SL1 and some are new requirements. For example, in SL1, the system must authenticate and authorize human users. In SL2, the system must also authenticate and authorize software processes and devices. In SL1, the system must detect, report, and prevent malicious software. In SL2 the system must detect, report, and prevent malicious software at all zone entry and exit points. In some cases, new requirements are added like the ability to support certificates for authentication. Some of the specifications require products to be added to the network. A unified account management appliance, Certificate Authority, Back-up Server, Event Server and Network Intrusion Detection System have been added to the network. In addition, the control network has been segmented into two separate networks. Note that the potential ICS device replaced to support new features required in SL2 (having to upgrade to a new PLC that supports secure protocols for example) are not captured in the diagram.
  4. Yes, devices have been replaced to ensure that secure protocols are supported.

Exercice 7 : IEC 62443-4-1 - OT Threat Model example

Using the example used in Threat Models in OT Systems (exercices), state whether you would be able to fulfill IEC 62441-4-1 (a precondition for a product certification 62443-4-2) related to Threat Modeling (SR-2, chapter 6.3). Namely,

R-2: Threat model requirements :

  1. correct flow of categorized information throughout the system;
  2. trust boundaries;
  3. processes;
  4. data stores;
  5. interacting external entities;
  6. internal and external communication protocols implemented in the product;
  7. externally accessible physical ports including debug ports;
  8. circuit board connections such as Joint Test Action Group (JTAG) connections or debug headers which might be used to attack the hardware;
  9. potential attack vectors including attacks on the hardware, if applicable;
  10. potential threats and their severity as defined by a vulnerability scoring system (for example, CVSS);
  11. mitigations and/or dispositions for each threat;
  12. security-related issues identified; and
  13. external dependencies in the form of drivers or third-party applications (code that is not developed by the supplier) that are linked into the application.
  14. The threat model shall be reviewed and verified by the development team to ensure that it is correct and understood.

SR-2: Threat model - Rationale and supplemental guidance

This process is required to ensure that security threats for the product are identified, validated, documented, addressed and tested by the product’s project team according to the defense in depth strategy. Having this process means that a threat model for the product is defined and maintained throughout the product life-cycle (for example, as a result of changing threats or updates to the defense in depth strategy) that identifies and describes threats that can occur within the product security context, and against which product is expected to defend itself. External dependencies are external components or systems that the product depends upon for security. As an example, a product could depend on power for physical security. Or a product could depend on the session management of a web server to be secure. In these examples, failure of the external dependency could lead to a security vulnerability in the product, so mitigations need to be put in place to minimize the chances of such failures. So for the power example, the mitigation could be the installation of an uninterruptable power supply (UPS). In the example of a web server, security should be considered when choosing a web server, and if a secure web server cannot be found, then other compensating measures need to be considered. Third-party code is an external dependency that can present significant challenges in determining where the threats can occur. If deeply embedded there might not be access to/from this code that crosses a trust boundary. If there is access to the trust boundary, a deeper inspection of the third-party code can be needed.

Solution

Taking all the requirements and going through them we would obtain the following result.

R-2: Threat model requirements :

  1. correct flow of categorized information throughout the system; -> available
  2. trust boundaries; -> available
  3. processes; -> available
  4. data stores; -> available
  5. interacting external entities; -> available
  6. internal and external communication protocols implemented in the product; -> available
  7. externally accessible physical ports including debug ports; -> not available as not known
  8. circuit board connections such as Joint Test Action Group (JTAG) connections or debug headers which might be used to attack the hardware; -> not available as not known
  9. potential attack vectors including attacks on the hardware, if applicable; -> not available as not known
  10. potential threats and their severity as defined by a vulnerability scoring system (for example, CVSS); -> not available as not known
  11. mitigations and/or dispositions for each threat; -> partly available
  12. security-related issues identified; and -> partly available
  13. external dependencies in the form of drivers or third-party applications (code that is not developed by the supplier) that are linked into the application. -> not available as not known
  14. The threat model shall be reviewed and verified by the development team to ensure that it is correct and understood. -> available as reviewed together