Introduction to IEC 62443

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

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?

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

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:

SPY - a service company specialized in converting a company vision, strategy and business requirements into OT architectures.
Hi5 Energy - a company delivering Power Grids products and solutions Worldwide.
Swisscowboy ERP Solutions - a company delivering Enterprise resource planning solutions tailored to the customers’ needs.
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).

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:

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

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 :

whether all Security Levels are covered?
what Defense in Depth is according to this paper?
what the major differences, as presented in the paper, between SL1 and SL2?
whether any Device has been replaced and for what reason?

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 :

correct flow of categorized information throughout the system;
trust boundaries;
processes;
data stores;
interacting external entities;
internal and external communication protocols implemented in the product;
externally accessible physical ports including debug ports;
circuit board connections such as Joint Test Action Group (JTAG) connections or debug headers which might be used to attack the hardware;
potential attack vectors including attacks on the hardware, if applicable;
potential threats and their severity as defined by a vulnerability scoring system (for example, CVSS);
mitigations and/or dispositions for each threat;
security-related issues identified; and
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.
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.