By now we’ve all become familiar with safety integrity levels (SIL), as they have become part of our everyday lives. However, with the recent release of several cybersecurity standards in the IEC 62443 series, things are getting more complicated. This series of standards introduces two more levels that we will need to get used to quickly: maturity levels and security levels. The new levels may appear similar to SIL, but they need to be viewed in their own applicable context.

The standard defines three types of security levels:

  1. target security levels (SL-T)
  2. capability security levels (SL-C)
  3. achieved security levels (SL-A)

IEC 62443-3-2 requires that you break down your system into security zones. Then, using the security risk assessment process, assign security levels to zones and conduits. We recommend that zone and conduit security levels be assigned based on the potential consequences should an attack objective be achieved within that zone. As the security level increases, the security integrity (i.e., the difficultly of compromising the countermeasures that can prevent or mitigate the consequence) must increase. One can conceptually view this as striving to achieve an order of magnitude increased integrity for each step change in security level. We use the word conceptual because to date, a pragmatic means of SL quantification has not yet been developed and vetted by the community. One can apply a semi-quantitative approach, however.

Security Level Capability

Although security level capability applies to the zone and conduits, components and systems that exist within can also have their own security level capability, which can be very useful in helping to determine the overall security level of the zone if adequate information is provided. A component or system with a capability security level of 3 means that the component or system includes the capability to carry out the security functions required for capability security level 3. IEC 62443-3-3 (for systems) and IEC 62443-4-2 (for components) define the required security functions for each security level.

Note that a security level for a device will allow the user to understand the minimum capabilities of the device. However, security capabilities can be categorized into seven foundational requirements as follows:

  • FR1 – Identification and Authentication Control
  • FR2 – Use Control
  • FR3 – System Integrity
  • FR4 – Data Confidentiality
  • FR5 – Restricted Data Flow
  • FR6 – Timely Response to Events
  • FR7 – Resource Availability

Each foundational requirement contains many detailed security capabilities. A device that has been certified to security level 1, for example, must meet all security level 1 capabilities in all seven of these areas. However, in practical terms, a device may meet different security levels in each of these areas. For example, an SL 1 certified device may meet SL 1 for three of the foundational requirements and SL 2 and SL 3 for the others. Therefore, it is more useful to the user of the device to understand the device’s capability for each foundational requirement, rather than a single security level representing the minimum level achieved in all foundational requirements.

Achieved security levels represent the actual performance or integrity of the zone or conduit as compared to the security level target. Security level verification must be done to determine what security levels have been achieved.

Maturity Level and How it Relates to Security Level

So, you might be asking yourself at this point, where does maturity level fit and how does it relate to security level? Maturity levels are applied to processes and document how mature an organization is at carrying out a given process. Roughly they can be described as follows:

  • Maturity Level 1 – Ad-hoc process
  • Maturity Level 2 – Documented process, but not necessarily repeatable
  • Maturity Level 3 – Documented process that is repeatable and consistently followed
  • Maturity Level 4 – Documented process that is repeatable, consistently followed, measured, and steadily improved

But this still raises questions such as:

  • What is the relationship between maturity level and security level?
  • Can I build a Security Level 4 system using a Maturity Level 1 process?
  • Can I maintain a Security Level 4 system using a Maturity Level 1 process?

The answer to these questions are somewhat surprising. According to the current IEC 62443 standards, there is no relationship between maturity level and security level. So, you could develop and maintain a security level 4 system using a maturity level 1 process. However, it would stand to reason that the security level achieved may not measure up due to the lack of a repeatable process.

For this reason, it is recommended that asset owners actively practice continuous improvement and achieve maturity levels more commensurate with the SL-Ts that are defined. In addition, end users are at the mercy of their supply chain. For this reason, they should insist that a product supplier has work processes with a maturity level commensurate with or exceeding that of the security levels of the devices they develop.

Don’t Ignore Maturity Levels

The moral of this story is that when analyzing and trying to ensure a certain security level capability with an expectation that it will be achieved for your system, don’t ignore maturity levels. These levels must be included in the security level capability determination and in the choice of components used in the system. The use of certified products, when available, is one way to ensure that the maturity level is considered. The exida certification scheme, for example, includes an analysis of both the security level of a product, and the maturity level of the process used to create that product.

 

 

 

 

[Michael Medoff – Exida – original article]

[Picture: Exida]