The ISA IEC 62443 set of cyber-security standards are truly great. They are the world’s most popular, most widely applicable, and most comprehensive standards for securing industrial automation and control systems (IACS or ICS). Created by International Society of Automation (ISA) and then accepted and co-developed by Europe’s International Electro-technical Commission (IEC), the standards were endorsed by the UN for their Cybersecurity Common Regulatory Framework in 2019. In September 2020, the new Part 3-2 of the standard was released, providing guidance on performing risk assessments on an IACS so that security countermeasures can be identified and applied.
In 2021, IEC members voted to make 62443 a horizontal standard, meaning it will form the basis for all future ISA and IEC industry specific industrial security standards and frameworks. Most ICS security standards are narrow in scope and tied to an industry, nation, or government body. It’s very refreshing that 62443 is completely generalized. It would be nice to say that it’s almost perfect, but automation and control technologies are changing fast, and a standard this big does have some confusing spots. This is not lost on ISA’s SP99 technical committee that writes the standard, who are hard at work on a major rewrite of several of the older sections. So, if you’re tasked with implementing IEC 62443, what are the essentials you need to know? What’s confusing, and what’s changing?
Essential Knowledge for Protecting ICS Networks
IEC 62443 is a multi-part standard, and very broad. I’m assuming that readers here will be asset owners or charged with protected an industrial site. In that case, relevant sections to get started are:
- 1-1, Terminology, concepts and models
- 2-1, Security program requirements for IACS asset owners
- 3-2, risk assessments for system design
- 3-3, security requirements and security levels
These are outlined red in the following chart in Figure 1.
Getting access to the IEC 62443 standards does cost money, but I highly recommend grabbing the free Quick Start Guide, downloadable from the ISA. Also – membership in the ISA is less than the cost of two or three volumes of the standards, and ISA members get free access to ISA and IEC 62443 standards.
In a nutshell, implementing the standard to secure an ICS site means implementing a security program, described in 62443-2-1. To do so, a risk assessment would be done and any changes to the network and security design would be made, based on 62443-3-2. Based on the assessment results and design that exists, that site’s cyber defenses would be categorized into one of five levels, described in the 3-3 document. The level selected determines the degree of requirements needed to complete implementation of the security program, so secure the site to what you have determined is an acceptable level. The higher the security level, the greater the strength of the applied protection. The five levels are summarized in Table 1: IEC/ISA 62443-3-3 Security Levels.
| Security Level | Definition | Means | Resources | Skills | Motivation |
|---|---|---|---|---|---|
| SL-0 | No special requirement or protection required | — | — | — | — |
| SL-1 | Protection against unintentional or accidental misuse | Simple | Low | Generic | Low |
| SL-2 | Protection against intentional misuse by simple means with few resources, general skills and low motivation | ||||
| SL-3 | Protection against intentional misuse by sophisticated means with moderate resources, IACS-specific knowledge, and moderate motivation | Sophisticated | Moderate | ICS specific | Moderate |
| SL-4 | Protection against intentional misuse using sophisticated means with extensive resources, IACS-specific knowledge, and high motivation | Sophisticated | Extended | ICS specific | High |
Table 1: IEC/ISA 62443-3-3 Security Levels
Effectively, 62443 lays out a roadmap to engineer cyber security defenses, and to iterate between risk assessments and system design until an acceptable level of protection is deployed. IEC 62443 security levels are all defined based on the type of threat – the most capable adversary that the system is designed to defend against. This worst-case attacker is further defined in terms of their means, resources, skills and motivation. While this all sounds great, selecting the appropriate security level is confusing, and it is unfortunately too easy to select the wrong security level as the target level for an automation system or site.
Talk with a 62443 expert:
IEC 62443 Part 3-3: Picking The Right Security Levels
Choosing a security level (SL) target is difficult in the current version of IEC 62443 Part 3-3, because in most of the 62443 series of documents, security levels are described in terms of the characteristics of the perceived adversary, and not in terms of the worst-case consequences of compromise.
In a bit more detail, IEC 62443-1-1 states that a target security level should be assigned to every network zone based on a “… consideration of the likelihood and consequences of security of a zone or conduit being compromised.” The problem is that 62443-3-3 (repeatedly) describes security levels as in Table (1) – in terms of the capabilities of the adversaries the zone must be protected against, not in terms of consequence severity. This is not entirely wrong – it is reasonable for example to look at a safety system designed to prevent an environmental catastrophe and say that this safety system deserves the highest degree of protection – SL4. The problem is that many practitioners forget this one paragraph in 1-1 and look at 3-3, where security levels are repeatedly defined in terms of the capabilities of the adversary.
IEC 62443 section 3-3 was released a decade ago, in 2013. Then, risk assessments based on the profile of an attacker alone were understood to be a robust method. This might make sense if you are trying to protect the information in your network, where denying access to the information systems would use the most sophisticated defenses to make it very difficult for the attacker. With industrial systems and critical infrastructure, protecting operations is key. Here the goal is to keep operations running safely, continuously, and reliably. The updated way to look at operational cyber risk is to consider that every CPU, at any level of the control system, could be compromised to mis-operate. Then consider what systems and processes pose a health and safety, or operational reliability risk, with consequences too dangerous or costly for the business or operations team to accept. It is important that the process be protected from harm, and not be solely concerned about who or what type of threat would cause that harm.
Take the example of a small-batch distillery, renowned for their gin made from locally sourced ingredients. Being in the mountains, seasons are short and only one batch is produced per year. Any spoilage of the batch by any threat actor could bring unacceptable harm to the business, including bankruptcy. Tampering of the safety instrumented systems on the still could cause a fire, release of steam, or product. But since a very small number of staff generally stay out of the plant, have a regimented safety program, and stay safe behind a sealed door and tempered glass during operations, the greatest concern is losing their precious gin. They are mostly concerned about their local competition and the rise in the threat of criminal ransomware groups, more than they are about sophisticated ‘nation-state’ attackers.
Contrast the gin distillery to the example of a 600 MW natural gas-fed power plant. Here, mis-operation could cause not only loss of power to thousands of downstream customers, but loss of extremely long lead-time assets such as turbines, power lines, transformers and more. Further, the health and safety consequences of out-of-control rotating equipment, electric arcs, would be completely unacceptable. In some cases, a loss of 600 MW can be absorbed by the electric grid with enough excess capacity, but during times of peak demand could instead cause widespread outages over large geographical regions. The ensuing chaos on such a scale significantly endangers the public. Whether an attack is made by an unsophisticated adversary just poking around (a ‘script-kiddie’), or a highly motivated and well-resourced attacker (a ‘nation state’ group) does not really matter. The power company is expected, and mandated by regulations, to prepare their defenses accordingly. A higher security level and stronger security program should be chosen to protect a power plant than for a distillery, because of the nature of the consequences, not because of the nature of the expected adversary.
Into The Future with IEC 62443
The point is that consequences determine the security level, not the nature of the threat or the adversary. A risk assessment asking the wrong questions could lead to a naively applied security level and program. It’s good to know that the ISA is aware of this fact. About a year ago, on the Industrial Security Podcast Episode #73, Eric Cosman, chair of the ISA99 committee which authors the series of standards, mentioned that a revision to 62443 Part 3-3 is in the works, and that security levels were being re-evaluated in light of issues like this that have come up in the course of using the standards this last decade.
It might sound like IEC 62443 has fatal flaws. Far from it. Last year, Alex Nicoll, co-chair of the ISA99 committee, appeared on the Industrial Security Podcast Episode #79. In it, he expressed the committee’s goal to keep up with industry changes, and the understanding that change is occurring quickly in not only automation and control, but in cyber security as well. The committee has largely achieved its goal of creating a general, widely-applicable and accepted framework for improving security in the industrial and critical infrastructure space. He re-affirmed concerns around Security Levels and Risk Assessments, while also mentioning that new technologies like containerization, virtualization, edge devices and the cloud need to be incorporated. Alex mentioned that the strength of the standard is that it is made up of volunteers and depends on input from those with experience to ensure standard is relevant and applicable to a wide range of businesses. Applying principles is key, as fundamentals haven’t changed in 20-30 years and requires collaborative input and effort from asset owners, operators, integrators, and suppliers.
In short, the series of standards is useful and valuable. Issues have been identified with the series, and are being addressed in new versions of the standard.
Your feedback is always welcome. Feel free to reach out on LinkedIn.
