Fundamental Models and Security Levels

Learning objectives

Define a system under consideration.
Group assets into justified zones.
Record allowed communication as conduits.
Explain SL-T, SL-A and SL-C.
Distinguish security level from process maturity.

Introduction

This module introduces models used to reason consistently about IACS security.

Planned video lesson

Module 05 video lesson

Video lesson coming soon. The written module can be completed without the video.

Planned recording: 9-12 minutes building the Riverside zone-and-conduit model and separating SL-T, SL-A, SL-C and maturity level.

Transcript will be added with the video.

Main lesson

Start with the system under consideration

The system under consideration, or SuC, is the defined system being assessed or designed. Its boundary must include everything needed to deliver the essential function and every dependency that can materially affect it.

A useful SuC definition records:

Essential functions and performance.
Physical and logical boundaries.
Included and excluded assets.
Users and organisations.
External systems and services.
Operating modes and safe states.
Existing safeguards.
Assumptions and constraints.
Lifecycle stage.

If the SuC is vague, the risk assessment and security level claim will also be vague.

Zones group assets with common security needs

A zone is a logical or physical grouping of assets that share security requirements. Good zone boundaries usually reflect differences in:

Function and criticality.
Trust and ownership.
Required security level.
Exposure.
Technology or lifecycle.
Physical location.
Consequence if compromised.

Do not create zones merely by copying VLAN numbers or ISA-95 levels. Those can inform the model, but the security rationale must come from risk.

Conduits describe controlled communication

A conduit groups communication paths between zones and states how information is allowed to flow. Each conduit should record:

Source and destination zones.
Business or operational purpose.
Initiating asset.
Protocol, port and direction.
Authentication and authorisation.
Boundary control.
Monitoring and logging.
Availability and latency requirements.
Owner and approval.
Behaviour during failure or emergency.

A line on a diagram is not a conduit specification.

Security levels express resistance to threat capability

IEC 62443 uses security levels to communicate the strength of required or supported protection. At a high level:

Level	General interpretation
SL 0	No specific requirement assigned for the foundational requirement
SL 1	Protection against casual or coincidental violation
SL 2	Protection against intentional violation using simple means, low resources and generic skills
SL 3	Protection against intentional violation using sophisticated means, moderate resources and IACS-specific skills
SL 4	Protection against intentional violation using sophisticated means, extended resources and IACS-specific skills

The detailed meaning must come from the applicable standard. Security levels are not labels such as “basic, silver, gold and platinum”, and the highest number is not automatically the best engineering choice. Stronger controls can add cost, complexity, latency and operational burden. The target must follow from risk.

Use the three security-level views correctly

SL-T - target security level: the required resistance derived from risk for a zone or conduit.
SL-A - achieved security level: the protection actually achieved by the integrated and operated system.
SL-C - capability security level: the capability a component or system can support when correctly integrated and used within its assumptions.

Buying an SL-C capable component does not prove SL-A. Configuration, architecture, external controls, users and maintenance all affect the result.

Security levels should be considered across the seven foundational requirements. A vector such as SL-T = [2, 2, 3, 1, 2, 2, 1] communicates more than a single “SL 2” label because different security objectives may need different strength.

Maturity level is a different question

Maturity describes how consistently an organisation performs and improves a process. Exact maturity requirements depend on the invoked part and edition. At a high level, the progression is:

Initial or ad hoc.
Managed and repeatable.
Defined and practised across the organisation.
Measured and improving.

A mature supplier can consistently develop an unsuitable product. A technically capable product can come from an immature process. Never use maturity level and security level as synonyms.

Planned original figure — M05-F01

Draw Riverside as five zones - process control, protective function, telemetry, enterprise services and vendor access - with named conduits and trust boundaries.

Planned asset: /static/training/ot-cyber-security/module-05/figure-01.svg

Engineering example

Riverside application

Riverside provides a small but realistic system for defining the system under consideration, grouping assets into zones and justifying conduit requirements.

Practical activity

Apply what you learned

Create an initial model with at least:

Process-control zone.
Protective-function zone.
Telemetry / central SCADA zone.
Enterprise reporting zone.
Remote-support zone.

For each boundary, ask whether communication is essential. Remove any route that has no documented purpose. Then propose an SL-T vector for the process-control zone and write one sentence of risk rationale for each element. The numbers are provisional until the detailed assessment is complete.

Your response (optional)

Record your reasoning and project notes here. Your response stays in this browser and is not submitted to the website.

Loading saved response…

0 / 10,000

Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.

Knowledge check

Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.

1. A draft zone model simply assigns one zone to each existing VLAN. When is that defensible?

Whenever inter-VLAN routing is controlled by an industrial firewall and each VLAN has a unique IP subnet.Only when the grouping is also justified by common security requirements and assessed conduits.Whenever the VLAN numbering follows the Purdue levels and separates control from enterprise assets.

2. Every controller in a zone has an SL-C 3 component claim, but the zone uses a shared administrator account and unrestricted engineering access. What is the correct conclusion?

The zone achieves SL-A 3 because the least capable installed component is SL-C 3.The zone achieves SL-A 2 after one security level is deducted for integration weaknesses.No SL-A is established; the integrated zone must be assessed against its requirements.

3. What does an SL-T vector such as [2, 2, 3, 1, 2, 2, 1] communicate?

The target strength for each of the seven foundational requirements, allowing different risk needs to remain visible.The maturity of seven lifecycle processes, averaged to determine the overall supplier rating.The minimum capability level required for each of seven component types in the zone.

0 of 3 questions answered correctly.

Key takeaways

Remember these points

Zones are risk-based groupings; VLANs are only one possible implementation mechanism.
Conduits define and control necessary communication between zones.
Security-level targets, capability and achieved performance answer different questions and are best expressed as vectors.

Relevant standards and guidance

This module uses original explanatory language. Consult the applicable editions and project requirements rather than treating this lesson as normative text.

ISA/IEC 62443-3-2
ISA/IEC 62443-3-3

Last reviewed

15 July 2026.