Modernes Lagerhaus mit Roboterarm, Drohnen und Roboterträgern.
chesky - stock.adobe.com
2021-10-15 short info

IEC 62443 series of standards to be expanded: Evaluation methodology as an important project

Cybersecurity in industrial automation is a central topic for all companies involved. The series of IEC 62443 provides numerous requirements to this end and offers important orientation for the respective players in the industrial environment.

With the development of rules for profiles and an evaluation methodology, two relevant projects are currently underway to further expand the series of standards, reduce complexity and thus provide easier access to the topic.

Sebastian Fritsch heads the evaluation methodology project. In an interview he talks about the motivation behind the project, the ongoing work and future implementation.

Contact

Christian Seipel

Interview with Sebastian Fritsch

DKE: Mr. Fritsch, please be so kind as to elaborate upon the new projects for the IEC 62443 series of standards. What is the underlying motivation?

Fritsch: The projects already have a longer history and the motivation to work on them is somewhat different in each case.

When it comes to the project involving the evaluation methodology for IEC 62443-4-2, for example, there is a wide range of certifications on the market, but with little comparability. Among other things, which standards are used to evaluate the security industry components is not transparent. The aim of our project is to define a transparent framework for this purpose, according to which testing and certification companies can define their evaluation programs for components.

Our motivation for the project to develop rules for profiles has grown over time. It also started with the IEC 62443 series of standards, because certain parts already explicitly mention that tailoring has taken place. Thus, there was a tendency in the application for a kind of "arbitrary picking and choosing" of requirements. On the German side we then started to formulate proposals in the standardization process as to what concrete profiles should look like – for individual, specific parts of the standard, in order to make it clear that there is only a certain, meaningful selection of requirements.

From the original discussion the result has been that we need to address this issue on a much broader basis and require rules on how profiles are developed.

The increasing complexity of the IEC 62443 series of standards is to be reduced

DKE: You mentioned the term "tailoring". Does this mean that no new requirements are described, but instead existing requirements are used and adapted to corresponding roles or sector areas?

Fritsch: I do not think that we have quite finished as far as consideration of sectors is concerned. However, roles are a good keyword and point of view as well; certain requirements are not necessary from a particular role. Let's take a maintenance provider, for example, who doesn't build anything and therefore does not have to prove any requirement in this area, but only during the actual operational phase. In this example the focus is placed exclusively on the operational aspects.

DKE: The IEC 62443 series of standards is considered to be complex and not easy to understand. Further parts will be added to the series of standards in the future. Won't this make it even more complex?

Fritsch: A clear aim for us is to ultimately reduce this increasing complexity. One important aspect that contributes to this complexity is the language – that is, how the standard is written. I notice this again and again, particularly in the evaluation methodology for IEC 62443-4-2, where I act as a project leader. A good example is provided by the component requirements, which are sometimes described in an unclear manner; often it is unclear when they are actually fulfilled. The feedback already after publication of the "TeleTrusT test scheme IEC 62443-4-2" – in historical terms it could actually be referred to as a preliminary project – indicated that there is quite a need for substantiation.

One major point that I notice again and again when it comes to project implementation and in discussions at IEC level, is that although we manage to discuss significantly more topics, we also keep coming back to the same points: The standard is not specific enough in some places or it leaves a lot of room for interpretation. Thus, our goal must be to formulate in a manner that lends itself to better evaluation. Therefore, we maintain a list of items that should be specified later in the parts that have already been published.

What I have learned personally is that IEC 62443 is an application standard, but not a standard that also has the property of being evaluable. If we adopt this additional perspective, i.e., to describe an evaluation methodology and assessment methodology, then we arrive at the point where certain aspects in the requirement standard as well should and must be formulated in a different manner. I think this could result in great added value for the entire series of standards and for practical application.

At the same time, however, from the point of view of standardization this also means taking two strands of complexity into consideration when developing a standard. However, once we have overcome these hurdles, I am certain that we will be able to significantly reduce the complexity of IEC 62443 and make it simpler and more "accessible".

Evaluators are given specific tasks to review through the logic of the evaluation process

DKE: Let's talk about the evaluation methodology. What will this look like in concrete terms?

Fritsch: I would be glad to. But I would like to point out from the outset that we are still talking about ongoing work in this project. Therefore, it is possible that several aspects will not be included in the evaluation methodology as described today.

The IEC 62443 series of standards is a canon of standards where there are cross-relationships that we have to consider in the evaluation methodology project. A good keyword here is the safe development process, which is described in Part 4-1 of the series of standards. All the explanations contained therein serve as a basis for the secure development of components. In addition, the functional requirements are defined in Part 4-2. Both parts together provide the framework for the evaluation methodology.

The new part IEC TS 62443-6-2 on evaluation methodology will not go beyond this and will not specify additional requirements. This has already become clear in the discussions over the past few months. Instead, it will be the case that we will aim to form logical units. Just to give an example: If the sequence of certain test steps is clear and dependencies even occur, then this will be taken note of in the sequence of specified evaluation activities. The logic of the evaluation process derives from this construct. In this manner the evaluator is given concrete tasks to review.

Common understanding is needed at the national and international level

DKE: The evaluation methodology project is still very new: How is the work progressing thus far and when is publication of the new part of the standard planned?

Fritsch: We started work on the evaluation methodology project in December 2020.

In the initial stages we entered the national discussion with our New Work Item Proposal (NWIP) and a very concrete proposal. At the international level our proposal led to intensive discussions and an adjustment in understanding. It so happened that our national view was not met with the same understanding at the international level. We already had to revise many passages as well as the terminology, but we also had to explain a lot while contributing to the development of mutual understanding.

However, – and this is important – we have taken the first big steps forward by agreeing on a rough structure for the evaluation methodology while arriving at a common understanding to this end: The requirements from the requirements standards provide the framework, we then cluster logical units and build the evaluation tasks on the basis of these – so that we very closely adhere to the main standard. We are currently in the process of preparing this in operational terms within the scope of an initial committee draft. This will show whether we have already achieved common understanding at the level of content.

The project planning provides for a target date of July 2023. I think we will need this time completely, as we are currently still dealing with the big picture. And further discussions will certainly follow when it comes down to the details.

In particular the manufacturers of components show great interest in this project

DKE: What type of project is the evaluation methodology?

Fritsch: The project on component evaluation methodology is to be published as a technical specification, specifically as IEC TS 62443-6-2 with the title: "Security evaluation methodology for IEC 62443 - Part 4-2: Technical security requirements for IACS components"

DKE: What is the composition of the group of experts working on this project? Are other experts still being sought for collaboration?

Fritsch: We are already well-positioned when it comes to personnel. This is also due to the fact that the evaluation methodology had already generated a great deal of interest in advance. In principle our working group consists primarily of manufacturers, but several auditors and certifiers also take part in the meetings on a regular basis.

We would welcome integrators and operators for additional perspectives, but conversely, we also have to say that ultimately it is about the components that are developed by manufacturers. The extent to which this topic is relevant for them must now be determined by the integrators and operators themselves.

DKE/AK 931.1.4 is to function as an anchor for project stakeholders at the national level

DKE: Which standardization committees are involved in the work for the new projects?

Fritsch: At the international level the new projects are all at IEC/TC 65/WG 10. The three projects are working in parallel, each with its own schedule and in separately organized meetings.

At the national level the projects are taken up by standardization committee DKE/AK 931.1.4. However, I would like to mention here that it is not so much a matter of doing substantive work, but rather of providing information – where do the projects currently stand, what challenges need to be solved, and what are the next steps? We therefore see the national standards committee primarily as an "anchor" for interested parties who would like to learn more about the ongoing projects.

In the national working group, we also intend to still have discussions on whether we still need evaluation methods to support testing for other parts of IEC 62443 as well.

But as I said before, the technical discussion of the three ongoing projects is already taking place on a very active basis at the international level where it is appropriately placed.

DKE: Thank you very much for the interview, Mr. Fritsch.

For this interview we would like to thank

Portraitfoto Sebastian Fritsch

Sebastian Fritsch

secuvera GmbH, Head of Test Center for IT Security and Industrial Security

Portraitfoto Sebastian Fritsch

secuvera GmbH, Head of Test Center for IT Security and Industrial Security


Interested in additional content about Cybersecurity?

Cybersecurity

The high degree to which our infrastructures are networked poses several threats to information security and data protection in systems. Within DKE, the cybersecurity department deals with important security issues that span across the entire service life of a system or system component. One of the main goals is to understand cybersecurity as an innovation topic and address it holistically in the relevant domains. You can find further information about this subject area in

DKE Area of Work Cybersecurity