By Steve Mustard, PE, CAP, GICSP, President & CEO of National Automation, and past president of the International Society of Automation, (CS)²AI Fellow
May 8, 2024
Following the webinar on January 31st 2024, I received the list of audience questions and comments. We did get into some of them in the session, but there was not time to address the vast majority. I grouped all the questions and comments into these broad categories so I could comment:
Standards in general
ISA standards
Risk assessment
How to apply ISA/IEC62443
Workforce development
Conformance assessment
Standards in general
When discussing standards for anything, two comments always come up, and rightly so. The audience said it better than I could:
“Security is more than just ticking all of the boxes”
“Standards are inherently a lagging activity”
One audience member gave additional comments on the first point:
“Security and compliance are not equal to each other, we have to remember that Security is a process, that evolves overtime, therefore best using a framework that includes the concepts of continuous improvement, audit and change to continuously improve Security. Align Security with the Business, and the business outcome, as business becomes more agile (Industry 4.0), security needs to be built for agility.”
All of this is true. No standard, ISA/IEC62443 included, can provide 100% security. As noted, security is an evolving situation. A common mistake for asset owners is to think they can invest one time in a cybersecurity management system and then forget about it. The ISA/IEC62443 cybersecurity management system requirements defined in ISA/IEC62443-2-1 recognize this, and include performance measurement and audits, as well as a continuous process of “assess, implement, and maintain”.
Likewise, someone else said:
“Being compliant doesn't necessarily mean that you're secure; being secure (risk reduced to an acceptable level) doesn't imply that you’re compliant to regulations. But in my view the latter should always prevail, compliance should not be the goal it should be a ‘by product’”.
The key to ISA/IEC62443 is indeed to implement a risk-informed solution and recognizing that an organization can only reduce the risk to as low as reasonably practicable (ALARP), not zero. Regulations, by nature, are the minimum level that must be achieved by all. ISA/IEC62443 defines multiple security levels that align to varying degrees of risk, allowing for more security where needed, and less security when not necessary.
Back to the second point, expressed by someone else like so:
“Standards are inherently a lagging activity. Vendors only want to collaborate on standards when they enable the market to grow in some way, otherwise they much prefer the monopoly rents associated with proprietary offerings.”
There’s certainly plenty of examples in the automation and control space of vendors enjoying the benefits of proprietary solutions, for instance with their own communications protocols. I think this is much harder to achieve with security. I always use the analogy of hazardous equipment design, since the objective is similar – one to reduce the likelihood and consequence of an ignition source in a potentially explosive atmosphere, the other to reduce the likelihood and consequence of a threat exploiting a vulnerability in a control system. Vendors can’t really come up with their own proprietary security solutions any more than they can come up with their own hazardous equipment solutions. In my view, conformance to security standards is a way to increase product sales. Products that meet ISA/IEC62443-4-2 from vendors that meet ISA/IEC62443-4-1 are not only objectively more secure, but evidence shows they are more reliable.
Questions about ISA standards
There were a few questions in this category, some easy, like this one:
“Where does the ISA 62443 standard vary from the IEC 62443 standard?”
The ISA version of the standard, ISA99, is identical to IEC62443, so ISA99-01-01 is the same as ISA/IEC62443-1-1 and so on.
This question came up too:
“Is Steve aware of a reference that maps 62443 to other frameworks like NIST 800-82?”
I don’t know of any official mapping, but I have seen people do their own. I think te best “official” mapping is in the NIST Cybersecurity Framework, which lists normative elements in ISA/IEC62443 alongside similar statements in the NIST 800 series, CSC, COBIT, and ISO 27001, like this:
Someone else asked a very reasonable question:
“I always like to ask what alternatives there are to 62443? Are there other models or frameworks or assessments ?”
And someone asked something similar:
“For an OT operator, why having so many standards/documents (too complex) and why not go with a single one, like NIST SP 800-82 instead?.”
I think it’s true to say that the security profession is not short of frameworks, guides, or methodologies. I believe one of our problems in the control systems world is that we still haven’t converged on one single standard. Everywhere I go I see people doing things in different ways. Different can be good, but not when it is incomplete or more subjective. For example, in the insurance space, brokers still create their own checklists to assess an organization’s security posture. How can an insurer be confident that one checklist is as good as another?
Other guides cover aspects such as technical controls, policies, procedures, and training. Assessments can be used to check for gaps, and other risk assessment guides can be used. Any organization can use any methodology they feel is appropriate. I would argue that if you are going to choose one then choose the most comprehensive one and choose one that is internationally recognized. Even if the asset owner is limited to one country, vendors and service providers are rarely tied to one geographic region and don’t want the time and expense of responding to multiple sets of requirements.
ISA/IEC62443 is the only international consensus-based series of standards for industrial automation and control systems security. It addresses every aspect of security, from governance, policies, procedures, training, as well as the risk-based implementation of security controls. As already noted, ISA/IEC62443 won’t make anyone 100% secure, nor will it keep anyone secure if they stop following it after implementation.
Someone asked this about the ISA committee producing this series of standards:
“How do you staff up for this standard? Is there a single coordinator or a committee?”
The ISA99 committee has two co-chairs (volunteers) and staff administration. It is broken down into multiple working groups and is run in accordance with ANSI requirements for standards development organizations (SDO). The following link provides more information about the committee and how to get involved or find out more:
Someone else asked a similar question to ones earlier about the slow pace of standards development:
“Steve-is there any thoughts how to balance getting input from a global ISA community to develop high quality standards while getting them out in a more timely manner to consume? For example, it's very exciting that IIoT standard is being crafted but in my opinion, this standard would have been more timely when IIoT started to become an emerging trend years ago.”
Producing standards in accordance with ANSI/IEC/ISO requirements takes time, and there’s no getting round some of the steps required to ensure a true consensus-based result.
Having said this, I would say that since the foundational parts of ISA/IEC62443 were published, new elements have been created much more quickly. One of the important things to emphasize about the series of standards is that it is intentionally vendor- and technology-agnostic. Requirements in ISA/IEC62443-2-1 and ISA/IEC62443-3-2 are fundamental and apply regardless of whether it’s IIoT that we are considering – for instance the principles of risk assessment are unchanged even if the technology changes.
In my view, the way that ISA/IEC62443 standards can be produced more quickly are:
Have asset owners demand that their vendors and service providers meet consensus-based international standards. A common set of requirements is attractive to vendors and service providers as it makes their work responding to proposals easier. Asset owners will be better able to compare offerings based on objective measures such as Security Level.
Have vendors and service providers coalesce around ISA/IEC62443, in the same way they have around IEC61511, IEC61131, ISO27001, and so on.
The work will still have to follow the necessary processes but all the effort that goes into creating competing guides and checklists can instead be directed to accelerating a common consensus-based international standard.
Questions about risk assessment
I mentioned in the session that I believe risk assessment is the biggest issue in control systems security. Look at all the checklists and methodologies. Almost all focus on gap or vulnerability assessment. Ask a vendor and they’ll tell you what vulnerabilities their product addresses. Vulnerability is an important part of security, but it is only one part of the risk equation:
Risk = Threat x Vulnerability x Consequence
In the risk assessment process we convert Threat x Vulnerability to Likelihood so the equation becomes:
Risk = Likelihood x Consequence
Then we plot the risks on a matrix like this:
In my experience, very few people do the risk assessment process. If they do, they create their own security risk method or matrix. This is a recipe for having security risks ignored. Leadership will assume that you are taking care of that stuff and they’ll continue to focus on their business risks, which are plotted on a matrix like the one above.
Someone in the audience pointed to this academic paper, which recommends caution with the use of risk matrices:
The article focused on the mathematical and logical limitations of risk matrices as sources of information for risk management decision making and priority setting. In short, the concern is “how can you guarantee your estimate of likelihood or consequence is correct?” which is a valid point.
In my book Industrial Cybersecurity Case Studies and Best Practices (https://www.isa.org/products/industrial-cybersecurity-case-studies-and-best-pra) I dedicate an entire chapter to this issue. I identify many methods to systematically determine likelihood (e.g. Monte Carlo Simulation and Bayesian Analysis). The results of any method are only as good as the inputs. Ultimately no-one is looking for a precise answer (99.82% likelihood that it will cost $1,203,420), but a justifiable, repeatable indication of the risk that can be used to compare against other risks determined using the same method.
The other thing that people do wrong if they do risk assessment is misunderstand what consequence means. This member of the audience made this point:
“Something that I think is missing in the standard and could be there in -3-2 is the relevance of a Business Impact analysis for the IACS High-level risk assessment. Such a BIA might point you to the crown jewels.”
In fact, it is defined in ISA/IEC62443-3-2 that consequence is the business impact, measured as things like physical safety, environmental impact, financial, production, regulatory, or reputation. And identifying the crown jewels is exactly why this is important. Once you identify the crown jewels, then you create your zones and conduits to protect them.
Someone suggested:
“In my opinion it would be better to start with your risk assessment and work from there.”
And this is also what the ISA/IEC62443 defines. Initial- or high-level risk assessment is the first step in the process:
As I mentioned in the session Jim McGlone and Ed Marzal explain perfectly in Security PHA Review (https://www.isa.org/products/security-pha-review-for-consequence-based-cybe-1) how to conduct a process hazard analysis (PHA) and incorporate security into that process, rather than create a separate process with different consequences.
Since we are talking about this book, I’ll address another comment from the audience related to the book’s concept of unhackable controls or, as the book defines them, non-hackable safeguards.
In my explanation of the cyber PHA process, which considers whether causes are hackable, and then whether safeguards (controls) are hackable:
The aim is to identify at least one non-hackable safeguard so that if the programmable electronic equipment is compromised the consequence is avoided. I said that controls like firewalls are programmable electronic equipment so, although they are important controls in defense in depth, they are still hackable and there is still a need to for a non-hackable control.
Someone in the audience asked:
“What about Waterfalls products? They claim they are unhackable?”
This is a good question, because data diodes/unidirectional gateways like Waterfall produce have one-way communications based on physical means, not software.
However, Jim and Ed define non-hackable safeguards (or controls) as those that “are typically simple mechanical devices that have been in use in industry for hundreds of years.” The book gives examples such as pressure relief valves, mechanical overspeed trips, check valves, buckling pins, and rupture discs. The common theme of these is that they are not dependent on any software, electronics, or in many cases, power to function.
The reason why this is important is also that the data diode is a preventive control, not a mitigating control. This is best understood by looking at a bowtie diagram:
This simplified diagram shows preventive controls, or barriers/safeguards on the left of the cybersecurity incident. They are in place to reduce the likelihood of the incident. Firewalls and data diodes are typical preventive controls.
The barriers to the right of the incident are mitigating controls. These reduce the consequence of the incident when it occurs. Mechanical failsafes are a typical mitigating control. In the control systems world, it is essential to understand the need for both types of control, and not rely only on preventive controls.
Another point to note is that it is becoming more common to use electronic protection devices, and the cyber PHA process helps inform how to do this while ensuring a well-considered set of preventive and mitigating barriers is in place.
One of the unique things about ISA/IEC62443 is that it is a risk-based approach. There were some questions about this from the audience:
“Are there any special cybersecurity risk assessments techniques as it is for 61511?”
“What I'm missing so far is the concept of Security Level Target (SL-T) and Security Level achieved (SL-A) (SL-C based on -4-2)”
“How critical it is to define threat vectors in Risk Matrix for the assessment? A calibration wrt is needed?”
ISA/IEC62443 does not specify how risk assessments should be done. It states that a risk assessment process needs to be defined and used. This is where it is important to use the organization’s existing methodology. Doing so will ensure that security risks will be considered at the same level as other business risks.
The principles of risk assessment set out in ISA/IEC62443 are derived from long standing risk assessment processes defined in other standards such as IEC61508 and its derived standards such as IEC61511.
In ISA/IEC62443, after the initial (or high-level) risk assessment and assignment of zones and conduits, there is a detailed risk assessment. In that stage it is essential to identify the threat vectors, as well as vulnerabilities and exploits.
How to apply ISA/IEC62443
It is not unusual to assume that ISA/IEC62443 may not apply to a sector, technology, or process. In fact the series of standards is written to be independent of sector, technology, or process. The audience asked some interesting questions related to the series of standards:
“How can Bacnet /ip or sc be modified to be conformant with 62443-3”
ISA/IEC62443 defines a series of security requirements in seven foundational requirement areas:
Identification and authorization control
Use control
System integrity
Data confidentiality
Restricted data flow
Timely response to events
Resource availability
Some of the requirements will apply to the protocol (or its deployment) and some of the requirements will apply to devices, systems, and process and procedures around the protocol. The security capabilities of the protocol will inform what additional controls, if any, need to be in place to achieve a particular desired Security Level Target (SL-T).
“I work for a company that supply things like vehicles, these products have a set of assets that make it up, and won't change for say 5 or 10 years, so would you treat them different to a nuclear plant for instance? Does 62443 work for these, ISO27001 does not, or is there something better?”
ISA/IEC62443 can be applied to any of those examples. The basic principles of ISA/IEC62443 are as follows:
Define a cybersecurity management system to ensure that cybersecurity is managed throughout the lifecycle of the asset (whatever that asset might be).
Define and implement a risk assessment methodology and identify the risks related to the asset.
Define the Security Level Target (SL-T) for the asset and then identify the controls needed to meet that SL-T.
The requirements defined in ISA/IEC62443 recognize the unique nature of OT environments. For example, the focus on availability/safety versus data confidentiality found in ISO 27001.
“Thank you for a great presentation. Do you have some preferred references for handling non-employees/externals in OT environments?”
ISA/IEC62443-2-4 (Security program requirements for IACS service providers) provides requirements for third parties involved in systems integration, product supply, and maintenance. These include requirements for staffing, assurance, architecture, configuration management, remote access, event and account management, malware protection and patch management, and backup and restoration. These requirements would apply during project and operations phases.
“Does the cloud fit into the zone and conduits model? Is it a new zone? Or does it, for example, appear in the Plant A Supervisory Control Zone?”
In ISA/IEC62443 the cloud would likely be its own zone. The connection between other zones and the cloud would be defined as conduits. The creation of the cloud zone and related conduits would take into account what function it performed (e.g., condition monitoring) and what data was required to perform this function.
However, the creation of zones and conduits is not prescribed. The ISA/IEC62443 series of standards defines some requirements for zones (e.g. separate safety zones, separate wireless zones, etc.) but otherwise users can define zones how they see fit to manage their security risk.
“The zones & conduits concepts seem to share some parallels with the ministry of Defence domains, islands and causeways from Domain Based Security (DBSy) from the late 90s and the later government IS1. was the DBSy approach any inspiration, is it just coincidence, or is it my misinterpretation?”
There are some similarities between zones and conduits and the DBSy concept. A domain in the DBSy concept is a logical place where people work with information using a computer system. A Zone in ISA/IEC62443 is a logical grouping of physical, informational, and application assets sharing common security requirements.
One of the main inputs into the zone and conduit model was the Purdue Enterprise Reference Architecture (PERA) in which end users, integrators and vendors share in integrating applications at key layers in the enterprise, including the industrial automation and control system environment.
Understanding how to use the concepts of PERA, zones, and conduits is fundamental to creating a secure and reliable architecture, and it is one of the areas that I see is most often misunderstood.
“Are networked sensors and actuators components of a control system required to meet component level security requirements?”
ISA/IEC62443 defines requirements for embedded devices, host devices, applications, and network devices. An embedded device is defined by the series of standards as “special purpose device designed to directly monitor or control and industrial process.” So if a user wishes to require that all devices, including networked sensors and actuators, are ISA/IEC62443 conformant, then they would need to meet the relevant requirements.
“How applicable are the standards to non-OT/ICS systems, such as telecoms systems like access control, CCTV, radio that support operations but are not quite IT, but not OT either?”
The principles of ISA/IEC62443 can be applied to any system that has an impact on the real or operational world. The risk assessment process identifies the consequences of failure of the system, and this helps inform what the security level should be for the system. This in turn identifies the security requirements needed to meet that security level.
“How do you determine SL for a system? How does the SL relate to the risk matrix and is there a standard way to determine the SL of any given system?”
The ISA/IEC62443 process is to assign security level to each risk level. Consider the risk matrix earlier. The associated SL-T would be as follows:
Workforce assessment
Some members of the audience asked questions about how to ensure that we could ensure people are trained in this important series of standards. For example:
“How can individual professionals obtain the standard and qualify themselves if they are not tied to a company that has purchased the standard? If there is no other way, how will the workforce be developed?”
Individual professionals can access the standards documents as members of ISA (as well as obtain discounts on training and publications). Membership of ISA (https://www.isa.org/membership), like membership of CS2AI (https://www.cs2ai.org/plans-pricing), costs very little. In fact, membership of both ISA and CS2AI will cost around $5 per week total. If industry professionals are serious about working in this space, I believe they should be prepared to invest this nominal sum.
“This a huge toolkit of guidance - are there courses now routinely required in engineering schools teaching young engineers about all this? Thx - great presentation! :-)”
ISA provides training in the series of standards, and a certificate program for those who wish to demonstrate their competence across the entire security lifecycle (https://www.isa.org/certification/certificate-programs/isa-iec-62443-cybersecurity-certificate-program).
Various programs exist to help improve student awareness of control systems security. A two-year associate degree program in mission critical operations was developed by the US Department of Labor, and a certification exists for those who wish to demonstrate their knowledge in this area. A study guide is available for those wishing to take the exam (https://www.isa.org/products/mission-critical-operations-primer).
The US Department of Labor also provides the Automation Competency Model (ACM - https://www.careeronestop.org/competencymodel/competency-models/automation.aspx), to which ISA subject matter experts contribute. This model defines the key skills, knowledge, and abilities that automation professionals need from entry level to advanced career level and is updated regularly to ensure that emerging technologies are included, recognizing that the automation profession is constantly evolving. One of the key blocks of skills, knowledge, and abilities relates to control systems security.
Conformance assessment
One of the important aspects of an international consensus-based standard is that it is possible to demonstrate conformance with the standard. Since ISA/IEC62443 is a series of standards covering different elements of the security lifecycle, there are different conformance possibilities.
Audience members asked several questions related to conformance. First:
“Is there a device certification for 62443 similar to the UL rating in the US?”
ISA/IEC62443-4-2 defines requirements for IACS components. Requirements are defined for embedded devices (PLCs, RTUs, IEDs), host devices (servers, workstations), network devices (routers, switches, firewalls), and applications (DCS, SCADA, historian). Some requirements are common across all categories, and some are specific to the category. As with system security, there are security levels defining progressively more comprehensive requirements.
Vendors can obtain a certificate of conformance to ISA/IEC62443-4-2 for their component by having it assessed by an independent test lab. One of the pre-requisites is to have conformance to ISA/IEC62443-4-1, secure product development lifecycle requirements.
Another good question, highlighting that ISA/IEC62443 is not just about product security requirements:
“Are suppliers or operators/integrators certified?”
ISA/IEC62443-2-4 defines requirements for IACS service providers, including integrators, product suppliers, and maintenance providers. An evaluation methodology is being produced that will allow these service providers to obtain conformance to ISA/IEC62443-4-2.
A separate program is under way to develop a conformance program (IACS Security Assurance) that would allow operators to have their facilities demonstrate conformance to ISA/IEC62443-2-1, -2-3, -2-4, -3-2, and -3-3.
This question covers some similar ground, but also asks an additional question:
“What systems are there in place to certify compliance in SL0-4? What are the time frames expected to progress through them? How much of the industry is covered/rates at the SL levels?”
The conformance programs are mentioned above. The ISASecure website provides details of vendors who have obtained a conformance certificate for their development lifecycle, system, or component. The level of coverage is still growing. I believe asset owners need to drive the demand for vendors, along with their products, to be conformant to the requirements. Conformance can be a key differentiator between vendors and their products as asset owners seek security by design.
This was an interesting question:
“We are currently developing a SL1 product (Equipment under control). it is not clear how to take into account the location when accessing the requirements. seems like it should be a limited subset compared to a product at the operations management level.”
The requirements for SL-C of a device do not change based on where in the hierarchy of a facility the device is used. What changes based on the hierarchy is the SL-T, which is based on the risk that is assessed for that part of the hierarchy (typically the zone).
Also, as noted in the session, SL1 is the lowest level of security requirements, to protect against “casual or coincidental violation.” The level below this is SL0, which is “no specific requirements or protection necessary”.
Another valid question:
“Is there any checklist included for applying 62443?”
There are no checklists provided as part of the series of standards, although each document in the series tends to provide a table of requirements associated with varying security levels, for instance this extract of the table in ISA/IEC62443-3-3:
This was an important question to ask:
“How long does a certification last? has expiration date?”
Certificates related to processes must be renewed every three years. Certificates for products are based on a particular version of the product (hardware/software/firmware) and a particular instance of the standards/assessment methodology. Vendors cannot transfer this product conformance to other products.
A question about one of the newer developments in the ISA/IEC62443 series:
“The new 1-5 development which provide a profile, it is intended to be similar to Common Criteria Protection Profile that are focused on types of products (network devices, biometric, databases, etc.)? or it is more focused on sector or areas of application adding mandatory SL and requirements to meet for those profiles?”
This development is still in the early stages and will specify a scheme for drafting cybersecurity profiles for the ISA/IEC 62443 series. Cybersecurity profiles based on this scheme are intended to be published as subparts of the ISA/IEC 62443-5 series. ISA/IEC 62443 cybersecurity profiles can be used by interested parties to adopt a defined set of requirements specified in the ISA/IEC 62443 series. The necessity of cybersecurity profiles can reside in the need to adopt for example the generic ISA/IEC 62443 terminology (e.g. roles) or the interpretation of requirements to a distinct industry sector or area of application.
And finally, to close:
“Could Steve please give us a sense about the level of adoption of this standard(s)? For example, in the EU market vs the US and, if possible, which industry (energy, utilities, etc) has the highest adoption?”
Based on my experience, I would say oil and gas supermajors have fully embraced the series of standards, whereas other sectors are in various stages of adoption. World-wide I believe adoption is growing rapidly around the world. Requests for proposal now routinely include ISA/IEC62443. As I mentioned, it is my experience that some of these references are incomplete or vague (e.g. “meet ISA/IEC62443 without specifying which part(s)) but as awareness grows this is changing.
The ISA Global Cybersecurity Alliance (https://isagca.org/) is a global consortium working to provide guidance on how to implement ISA/IEC62443. They provide many free white papers and guides. ISA also organizes an annual OT Cyber Summit to bring together thought leaders in this area. The next event is in London in June 2024 (https://www.isa.org/events-and-conferences/ot-cybersecurity-summit).