ISA/IEC 62443 – Compliance in Industrial Control Systems
The Cyber Threat to Industrial Controls
Industrial Automation and Control Systems (IACS) and Operational Technology (OT) are critical to our society. These systems play a vital role across many sectors. The production and distribution of electricity, oil, and natural gas are dependent on them. So are industries as diverse as water and wastewater management, transportation, chemical processing, pharmaceutical manufacturing, and food and beverage processing. In addition, manufacturing industries like automotive, aerospace, and durable goods rely on IACS and Programmable Logic Controllers (PLC). Our offices and factories leverage Industrial Internet of Things (IIoT) devices, including sensors, actuators, and smart instrumentation for HVAC, factory automation, and other activities.
In the past, many of these controls were only accessible within a factory or site. Today, most are internet-facing. While this significantly increases efficiency, it also increases the systems’ attack surfaces, exposing them to criminals and other adversaries. When any of these systems fail, the results range from troublesome to catastrophic.
- In 2023, an attack attributed to the Iranian Government’s Islamic Revolutionary Guard Corps (IRGC) targeted Unitronics PLCs, causing disruptions in water utilities in the US and Ireland. A design error that did not force users to change default passwords prompted threat actors to scan for internet-exposed endpoints using tools like Shodan.
- In April 2022, several US agencies issued an advisory on a malware toolkit called Pipedream designed to target ICS, PLC, and SCADA devices. The toolkit enables attackers “to scan for, compromise, and control affected devices once they have established initial access to the operational technology (OT) network.
- Safety instrumented systems (SIS) are used across the Oil and Gas, Chemicals, and public utility industries. The 2017 Triton/ Hatman attack triggered the shutdown of an industrial process at one organization.
Understanding ISA/IEC 62443
To address these cybersecurity needs, the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC) developed the ISA/IEC 62443 standard.
The standard provides an integrated approach to security, including risk assessment and defense-in-depth strategies. It identifies critical assets, implements tailored security measures, and addresses technological, human, and process-related risks.
The standard is structured into four key categories:
- General Standards (62443-1-x): Establish fundamental concepts, security terminology, and risk-based approaches to ICS security.
- Policies and Procedures (62443-2-x): Define effective IACS security management practices and security program implementation.
- System Security (62443-3-x): Defines system security requirements and risk assessments for system design based on different security levels.
- Component Security (62443-4-x): Address secure software development practices, ensuring that ICS components are designed with security in mind.
Not all systems face the same threats or criticality to operations. Recognizing this, ISA/ IEC 62443 provides five security levels. These levels, from SL 0 to SL 4, categorize the severity of potential threats and guide the implementation of appropriate security measures.
- Security Level 0: No special requirement or protection is required.
- Security Level 1: Protection against casual or coincidental violation
- Security Level 2: Protection against intentional violation using basic security measures with low resources, generic skills, and low motivation
- Security Level 3: Protection against intentional violation using advanced measures with moderate resources, IACSspecific skills, and moderate motivation
- Security Level 4: Protection against intentional violation using advanced measures with extended resources, IACSspecific skills, and high motivation.
By aligning security capabilities with the specific risks of each system component, the standard ensures that defenses are proportionate to the potential impact of a breach.
Challenges Meeting ISA/ IEC 62443 Compliance
Most organizations approach regulatory standards using a manual approach. Teams attempt to enumerate all the requirements, communicate those to design teams, remind engineering to implement each requirement, and require QA to test for the completion of the requirements. In short, teams manually identify and implement “security requirements” for the standard.
Security requirements are specific measures systems or applications must meet to protect against threats and vulnerabilities. They include functional and non-functional elements like authentication, authorization, confidentiality, integrity, and availability. Ideally, security requirements are defined in the requirements stages of the software development lifecycle alongside functional requirements for a project. In addition to industry standards, security requirements are influenced by organizational objectives, regulations, potential risks, and specific threats to an application or system.
Manual approaches to identifying security requirements and ensuring the implementation of appropriate controls may be manageable in a small, well-defined project, but teams struggle with manual approaches as projects grow and scale for several reasons:
Scalability: Identifying security requirements manually requires senior engineering and security resources to review applicable regulations, identify threats based on the development languages, frameworks, and deployment environments, and determine appropriate security controls. This is a timeconsuming process, and because these resources are in high demand within their organizations, it often leads to limiting security requirements to only the most critical projects.
Proprietary Processors and Languages—IACS and OT systems include software embedded in hardware. Security requirements vary with different processors and runtime environments, and embedded software may be written in C, B#, Embedded C++, and other less well-known languages than web applications. An organization’s secure coding knowledge may be less well defined for the unique needs of some languages.
Consistency: Manual security requirements are subject to the expertise and biases of the team creating them. This can lead to inconsistent threat identification, varying interpretations of standards, and different recommended security controls across projects. When the requirements are maintained in shared spreadsheets or email threads, ensuring the uniform implementation of controls can also be difficult.
Testing for Compliance: When security requirements are developed and communicated manually, organizations struggle to ensure controls are in place. Rather than communicating requirements to developers so that implementation becomes part of the normal development process, manual compliance test plans may focus on unique edge cases, increasing the risk of overlooking critical checks.
Documentation: Compliance with any standard requires evidence of actions taken. Written secure coding standards may seem like a simple way to track risks and controls, but from a compliance standpoint, they lack traceability. Without a central, controlled repository for risk assessment data with an auditable record of changes, it is difficult to prove compliance to an auditor, customer, or corporate board.
The Role of SD Elements in ISA/IEC 62443 Compliance
Generating and complying with security requirements at scale requires automation. SD Elements automatically identifies threats and security requirements and then translates those into actionable tasks for developers. This includes:
Automatic assignment enables development teams to build secure code as part of the normal development process rather than simply test for compliance during QA. Automated security requirements identify potential threats early in the development cycle, reducing security gaps in ICAS and OT systems. Reducing the uncertainty of rework due to security bugs found late in the development process allows teams to better estimate time to completion.
1. Automated Compliance Mapping and Risk Assessments
Analyzing the details of ISA/IEC 62443 to ensure that all requirements are met demands detailed knowledge of the standard. Doing so manually can take days or weeks. In contrast, SD Elements provides an automated mapping of ISA/IEC 62443 requirements to actionable security controls based on a short survey describing the application’s development languages, frameworks, and deployment environments. Tasks – including code examples – are assigned to individuals responsible for implementation through their normal tools, such as Jira. Without the need to learn a new “tool”, adoption by engineering is accelerated, allowing security requirements to scale across the organization.
2. Consistent and Accurate Coverage of Requirements
Automation eliminates personal biases to ensure consistent threat identification and controls that meet internal and external standards.
3. Intelligent Application of Controls
The Security Level in ISA/IEC 62443 recognizes the need for different security measures depending on each application’s threats and the consequences of a breach. When modeling an application, users indicate the Security Level required for the survey. In turn, SD Elements applies controls and countermeasures appropriate for that security level, relieving individual developers from spending hours determining what applies to their product.
4. Embedded Security-by-Design Principles
“Security by injection” approaches where weaknesses and vulnerabilities are found by security scanners cause rework, delay development cycles, and often result in technical debt. To avoid this, ISA/IEC 62443 emphasizes a security-by-design approach to software development, requiring ICAS software to be built with security controls from the outset.
SD Elements supports this approach by embedding security requirements directly into the SDLC, starting with the requirements and design phases. The platform provides realtime guidance, best practices, and security checklists to ensure developers follow secure coding principles.
5. Secure Development and Remediation Guidance
SD Elements offers a structured approach to secure software development, enabling teams to avoid vulnerabilities proactively rather than remediating bugs found through security testing later in the development lifecycle. By integrating security knowledge and automation, it incorporates secure by design practices into development workflows – before code is written. Security controls include code snippets in the language chosen and testing steps to ensure the requirement is satisfied early in the development process. This allows developers to take immediate, precise actions to mitigate risks without requiring deep expertise in cybersecurity.
6. Secure Coding Training
Coding errors occur when a developer is unaware of secure coding best practices or forgets them due to pressure to deliver functionality. Since most developers are not trained in secure coding principles, avoidable vulnerabilities are common in software.
SD Elements takes a developer-centric approach to learning, combining secure coding expertise and modern instructional design to deliver training to developers where they work and when needed. While on-demand courses cover topics in depth, SD Element’s Just-in-Time Training (JITT) features short videos that engage developers in real time, aiding in implementing security and privacy controls within their workflows through integrations with tools like Jira and ADO. This training activates when a developer is about to make security-related decisions, providing relevant content instantly and increasing the adoption of best practices at scale.
7. Integration with DevSecOps
SD Elements integrates easily with dozens of best-in-class DevSecOps tools, ensuring workflows remain uninterrupted. It supports a variety of development tools and technologies, such as build servers like Jenkins and GitLab, issue trackers like Jira and ServiceNow, and security testing tools including static analysis (SAST), dynamic analysis (DAST), and Software Composition Analysis (SCA). These integrations ensure continuous compliance with ISA/IEC 62443 by providing real-time compliance dashboards for security monitoring and enforcing security policies across development teams, leading to better collaboration between development and security.
8. Continuous Compliance
Most standards are updated over time. Keeping current on the requirements and controls can be difficult. In addition to ISA/IEC 62443, the SD Elements content library covers over
40 distinct regulations and standards, including the OWASP Top 10, OWASP API Top 10, NIST 800-53, and FedRAMP. It is maintained by a team of in-house security experts who continuously update the material to reflect the latest industry best practices, regulations, and emerging threats. This ensures that developers can access the most current and relevant security information while giving executive-level traceability to meet compliance and regulatory standards.