IEC 62443: A Cybersecurity Guide for Industrial Systems (Part 4)


Welcome back to the series on the IEC 62443 standard for industrial cybersecurity. This third installment will investigate the documents that are part of the second series of documents, or documents in the IEC 62443-3 series.

This series of documents are much more operational in nature than the ones from previous articles. So those of you who have been waiting for some more technical content, this series, and the series in the next article, will be for you!

  • 62443-3-1 Security technologies for industrial automation and control systems
  • 62443-3-2 Security risk assessment and system design
  • 62443-3-3 System security requirements and security levels

As you can see from the titles of the documents in the table above, we are now in the IEC 62443 standard, that focuses on Actually securing the industrial environments. Like in the previous articles on the documents that are part of the IEC 62443-1 series, I will provide you with knowledge of some of the content that is part of the documents in the IEC62443-3series. That way, you can focus on the documents that will provide you with most value, since the cost of buying the documents from your national standards body is nontrivial.

IEC 62443-3-1 Security technologies for industrial automation and control systems is a technical report, not a normative standard. What does that mean?

In the IEC world, a Technical Report (TR) and a Standard serve different purposes:

1. Technical Report (TR)

  • Nature: Informative, not normative.
  • Purpose: Shares knowledge, best practices, explanations, or background information.
  • Requirements: Does not contain mandatory requirements that must be followed to claim compliance.
  • Enforceability: You can’t be “certified” against a TR. It’s there to help you understand concepts, technologies, or context before applying standards.
  • Example: IEC 62443-3-1 explains security technologies — it doesn’t say “you must implement X” but rather “these are common security technologies and how they work.”

2. Standard (International Standard, IS)

  • Nature: Normative — contains shall statements (mandatory requirements) and sometimes should statements (recommended practices).
  • Purpose: Defines the exact rules, requirements, or criteria for designing, implementing, or verifying something.
  • Requirements: If you want to claim compliance with IEC 62443-3-3, you must meet all the shall statements in that standard.
  • Enforceability: Used for certifications, contracts, and regulatory compliance.

The main purpose of a technical report is to give readers — especially those working in industrial automation and control systems (IACS) — a broad overview of the security technologies available to protect such systems.

That being said, the content in IEC 62443-3-1 provides us with a lot of guidance on the kinds of technologies we can use in protecting an industrial environment.

  • A comprehensive overview of cybersecurity tools and countermeasures suitable for Industrial Automation and Control Systems (IACS).
  • Descriptions of various categories of security technologies, the types of products available in each category, as well as their advantages and disadvantages when applied in industrial environments.
  • Preliminary guidance and considerations for applying these technologies effectively within automated IACS settings.
  • The intended audience includes professionals seeking to understand the applicability of specific technologies in control system environments

What you will get out of this document, is:

  • Categories of Security Technologies: For instance, intrusion detection, encryption, network segmentation, access controls—each explained in terms of function and utility.
  • Use-Case Analysis: Insights into how each technology performs in IACS scenarios, covering pros and cons, such as interoperability, performance impact, or integration complexity.
  • Guidance for Selection: Though not prescriptive, the report helps readers judge which technologies might be appropriate for their environment based on the trade-offs discussed

The document will be especially beneficent for those who are new to industrial cybersecurity and needs some guidance and insight into the realities of securing industrial environments!

We have been doing risk assessments for our cybersecurity needs within normal IT for decades. It helps us communicate with the business and prioritize the investments in cybersecurity.

IEC 62443-3-2 Security risk assessment and system design brings several benefits to organizations managing industrial automation and control systems (IACS):

1. Structured, Repeatable Process

  • Provides a clear methodology for assessing security risks in IACS environments.
  • Reduces ad-hoc decision-making and ensures consistency across projects and sites.

2. Focused Security Investments

  • Zones and conduits approach allows you to prioritize high-risk areas.
  • Prevents wasting resources on overprotecting low-risk assets or under protecting critical ones.

3. Risk-Based Decision Making

  • Links security measures directly to risk levels, avoiding “checklist” security.
  • Aligns cybersecurity with business and operational priorities.

4. Improved Communication Between Stakeholders

  • Establishes a common language for asset owners, system integrators, suppliers, and regulators.
  • Reduces misunderstandings during design and procurement.

5. Supports Compliance and Certification

  • Aligns with the broader IEC 62443 framework and international cybersecurity expectations.
  • Can serve as evidence in audits, tenders, and regulatory reviews.

6. Integration with Lifecycle Security

  • Fits into the security-by-design approach by embedding risk assessment early in the system design process.
  • Ensures security isn’t an afterthought but a core design parameter.

Risk assessments are often looked down upon, but the benefits to communication with the business and stakeholders should not be underestimated! A typical workflow for assessing risk in and industrial setting can be seen ion the figure below.

This document feeds directly into the IEC 62443-3-2 document, since requirements and security levels are core to doing risk assessments.

Its purpose is to define the detailed technical cybersecurity requirements that an Industrial Automation and Control System (IACS) must meet to achieve a given Security Level (SL) — as determined earlier using IEC 62443-3-2.

A breakdown of the content of IEC 6244333, the standard that defines system-level security requirements for industrial automation and control systems (IACS) is:

1. Foundational Requirements

The document defines seven key categories, known as Foundational Requirements, which organize the detailed system-level requirements:

  1. Identification & Authentication Control (IAC)
  2. Use Control (UC)
  3. System Integrity (SI)
  4. Data Confidentiality (DC)
  5. Restricted Data Flow (RDF)
  6. Timely Response to Events (TRE)
  7. Resource Availability (RA

2. System Requirements (SRs) & Requirement Enhancements

  • Each FR is broken down into System Requirements—specific, technical shallstatements tailored to achieve security functionality.
  • Some SRs include Requirement Enhancements —additional, optional measures for higher security levels.

3. Security Levels

IEC 6244333 defines Security Levels (SLC for systems) that indicate the system’s resilience based on attacker capability:

  • SL 0: No specific protection required.
  • SL 1: Protest against casual or coincidental misuse.
  • SL 2–4: Increasingly robust requirements against intentional threats; SL 4 is for highly sophisticated and well-resourced adversaries.
    This enables selection and testing of systems based on the assessed risk and threat profile.

4. Linking Security Levels to Requirements

  • SRs (and REs) are mapped against each SL: the higher the SL, the more stringent or additional measures are required.
  • Systems are evaluated by comparing:
    • SLT (Target SL): The required security level from risk assessment (IEC 6244332)
    • SLC (Capability SL): The level the system can achieve
    • SLA (Achieved SL): The level actually implemented

This mapping shows whether additional compensating measures or redesigns are needed

This might all seem straight forward, but any project that aims to implement the security levels in an already existing industrial environment, should be taken very seriously, since it might impact an already fully functioning environment.

Doing this, will be MUCH easier when building new environments, or upgrading the various automation system, to more recent versions and hardware.

The documents that are part of the IEC 62443-3 series, are important operational documents, that helps us design and implement risk assessments and security levels for cybersecurity in an industrial setting.

The next article in the series will be looking at the document in the IEC 62443-4 series:

  • IEC 62443-4-1 Secure Product Development Lifecycle Requirements
  • IEC 62443-4-2 Technical Security Requirements for IACS Components

These documents are aimed, mainly, at the various vendors that produce gizmos for industrial environments, like PLC’s or SCADA systems. Even if you are not such an entity, having knowledge of these documents, can help you with the requirements that you might give to your chosen vendor for your industrial systems!

 

Check out the rest of the series:

Part I | Part II | Part III | Part IV | Vocabulary

Print Friendly, PDF & Email



Source link

About Cybernoz

Security researcher and threat analyst with expertise in malware analysis and incident response.