This blog is the third in a series of blogs published by Dragos covering the requirements, documents, and key concepts of the ISA/IEC 62443 series of cybersecurity standards. Part 1 of this blog series described the benefits of adopting the standards, and Part 2 explored the organization of the series of standards and shared the segmentation of documents that apply to different stakeholder groups. In this installment, we’ll cover several key concepts that are presented within the series of standards. These key concepts should be leveraged as guideposts for assessing your organization’s alignment with the series of standards.
The goal of the ISA/IEC 62443 series is to improve the reliability, integrity, and security of Industrial Automation and Control Systems (IACS) using a risk-based, methodical process. By adopting a standards-based approach, organizations can lower the possibility of a successful cyber attack, ensure consistency in requirements across all stakeholders, and incorporate security measures throughout the lifecycle of their IACS.
ISA/IEC 62443 allows an Asset Owner to select the set of requirements that best fits their needs based on their risks. At Dragos, we offer technology, infrastructure, and professional services support to help translate the objectives within ISA/IEC 62443 into actionable components of your cybersecurity plan, customized to fit your specific environment and risk profiles.
Connect with a Dragos Expert
Learn more about our OT cybersecurity technology, services, and threat intelligence offerings.
Contact UsRisk Management
Risk management, as described in Part 3-2, is the systematic process of identifying, assessing, and treating risks to reduce them to a tolerable level. The first step is to identify the scope as well as the critical systems and assets within the IACS. The Asset Owner will then conduct a multi-step risk assessment to help them prioritize their risk treatments, such as avoiding, transferring, accepting, or mitigating. The ISA/IEC 62443 Series does not specify the exact methodology, recommending that it be compatible with the organization’s overall risk processes.
The initial risk assessment helps the organization prioritize their efforts and break the system into zones and conduits. The detailed risk assessment will result in the organization identifying Target Security Levels, as well as the set of cybersecurity countermeasures needed to defend the IACS.
Zones & Conduits, Architecture, and Segmentation
A security zone is a grouping of systems and components based on their functional, logical, and physical relationship that share common security requirements. A conduit is a logical or physical grouping of communication channels connecting two or more zones that share common security requirements. Where feasible, Asset Owners should try to keep their zones and conduits consistent with their network architecture to avoid extra unnecessary complexity.
ISA/IEC 62443 uses what is commonly referred to as the Purdue Reference Model (derived from the Purdue Enterprise Reference Architecture [PERA] based on principles established by Purdue Laboratory for Applied Industrial Control [PLAIC]) as a way to describe how data flows through industrial networks. It breaks the system down into different hierarchical levels based on their response time and function. Many organizations chose to mirror the concepts of the Purdue levels into their network architectures, but care needs to be taken when considering different technical solutions, such as wireless, cloud, remote access, and Industrial Internet of Things (IIoT).
Security Levels
A Security Level (SL) is defined as a measure of confidence that the system, zone, or conduit is free from vulnerabilities and functions in the intended manner. How and when an organization uses SLs depends on where they are in their life cycle. There are three types of SLs used throughout the ISA/IEC 62443 Series:
- Target Security Levels (SL-T) are the desired level of security for a particular Automation Solution. These define how much protection the Asset Owner believes is needed to protect the system, zone, or conduit. An Asset Owner uses the risk assessment process (Part 3-2) to determine the appropriate SL-T and then documents that SL-T in their Cybersecurity Requirements Specification.
- Capability Security Levels (SL-C) are the native technical security countermeasures available within a system (Part 3-3) or component (Part 4-2) that can be integrated and configured to protect the Automation Solution without any additional compensating countermeasures (discussed later).
- Achieved Security Levels (SL-A) are the actual, measured SLs for a particular Automation Solution, generally determined after the Automation Solution is in operation.
The SL-C requirements for systems (Part 3-3) and components (Part 4-2) are grouped into different levels using an increasing level of potential risk reduction. In contrast to the quantitative risk reduction in safety engineering, SL-Cs are qualitative and take an attacker perspective on how many resources, skills, and motives they would need to overcome the countermeasures required at that SL.
Compensating Countermeasures
There may be some cases where the risks cannot be reduced to a tolerable level for a particular zone or conduit in an IACS with the native capabilities provided by the technical solutions. Compensating countermeasures are used in lieu of or in addition to the native capabilities to satisfy one or more security requirements. Often, these are additional policies or procedures to augment the existing technology to reduce the risks to a tolerable level. In some cases, they may be alternate technical solutions that meet the spirit of the requirement.
Align with ISA/IEC 62443
Ready to put your insights into action?
Take the next steps and contact our team today.