The primary objective of this page is to provide up to date information about CIP IEC-62443-4-x assessment. Recently CIP Security workgroup has engaged with one of the ANSI accredited ISO/IEC 17065 PRODUCT CERTIFICATION BODY. This page would be updated periodically as soon as there is some update about CIP assessment.

The primary objective of the CIP Security workgroup (WG) is to constantly investigate various industrial security standards that help to address burgeoning Cyber Security issues. Moreover, the Security WG constantly strives to closely monitor recent developments in Industrial security and evaluate them for their value add in the CIP platform. Additionally, when vulnerabilities are reported in Debian packages, the WG works with the Debian community to incorporate bug fixes in CIP source code as soon as possible. Some of the key goals of Security WG are highlighted in the following diagram.

The Security workgroup is currently focusing on how CIP can be certified for IEC-62443-4-x standards. This is being led by Renesas Electronics and strongly supported by other CIP member companies including Toshiba, Siemens, Cybertrust, Moxa, and others. The main objective of the CIP Security workgroup activities is to significantly reduce overall certification effort, cost as well as maintenance cost for suppliers by leveraging a certified CIP platform. It is expected that the artifacts of a certified CIP such as Test cases, Application and Hardware rules, and several others can be re-used by suppliers driving efficiency and costs savings.

Recently the CIP Security workgroup has initiated discussion with one of the most popular IEC/ISASecure scheme certification bodies. This section would be kept up to date in future as the CIP certification for IEC-62443-4-x progresses

The following members are currently working as part of the CIP security workgroup. All members regularly participate in weekly as well as bi-weekly meetings to discuss various security requirements. It is expected that more members will join this group in the future.

1. Kento Yoshida, Renesas Electronics Corporation, Tokyo, Japan

2. Masashi Kudo, Cybertrust, Tokyo, Japan

3. SZ Lin (林上智), Moxa Inc, New Taipei City, Taiwan

4. Yasin Demirci, Siemens Mobility, Brunswick, Germany

5. Dinesh Kumar, Toshiba Software India, Bangalore

6. Venkata Pyla, Toshiba Software India, Bangalore

Generally, suppliers or end product owners prefer to use open source software in order to minimize overall product development costs. On the other hand, IEC certification cost is quite high where it becomes a key concern for suppliers for getting their products certified and while remaining competitive. For getting any product certified for IEC-62443-4-x one needs to spend a significant amount of money as it requires immense security domain knowledge as well as additional resources for creating required certification artifacts.

CIP already promises super long term support (SLTS) for both CIP Kernel as well as CIP Core, which is beyond usual upstream long term support. In order to further reduce certification costs for CIP based products, CIP member companies strive to get IEC-62443-4-x certification for the CIP platform. Since CIP is not an end product, full certification to CIP cannot be granted, instead, CIP would be eligible for IEC-62443-4-X assessment.

1. Leverage the experience and expertise of CIP member companies to certify CIP and pass the benefits of certified CIP platform to suppliers

2. Create certification artifacts which can be re-used by suppliers for end-product certification

3. Share the know-how of the entire certification process with suppliers and help them to achieve the certification goals with minimum effort

4. Many CIP member companies are also hardware manufacturer or supplier of reference boards which can also be used to validate IEC-62443-4-x security requirements

CIP members are working with the certification body to know exactly what all documents are usually required for certification. However, there are many possible scenarios when required documents may vary e.g. targeted device category (There are four device categories defined in IEC-62443-4-2). As of now CIP members decided to apply for Networking and Embedded categories for certification and the expected security level is three (SL-3). However, exact details will be known once the gap assessment is completed by the Certification Body.

Initially, the following documents are expected to be available for gap assessment, though it’s not mandatory. This list would be revised as assessment processes over the period of time.

1. User Manual

2. Security feature document

3. Product features/product capabilities

4. Configuration Management

5. Development process document

After gap analysis, the Certification Body will point out additional documents required for actual certification as well as missing information in existing documents

The CIP project is hosted under the Linux Foundation. At the time of writing this document, there are eight CIP member companies who strongly support CIP development activities in all possible manners. All CIP member companies have direct access to CIP project resources such as CIP Kernel, CIP Core as well as documents and sample applications developed for IEC-62443-4-x certification. CIP members can directly participate during CIP certification and some of the reference devices can be certified for IEC-62443-4-x as reference devices which can be later used for developing end products by leveraging the certified CIP platform.

However, non-CIP member companies have the option to join the CIP project and re-use CIP for developing final products. Detailed information of how to join the CIP project is available at https://www.cip-project.org/about/join

TBD: We are working to update this section soon.

(Please note that the following section has been written based on the discussion with a specific Certification Body, so it is quite likely that there might be some differences in policies or few things with respect to other Certification Body)*

What would be the security level as defined in IEC-62443-4-2 which can be achieved by CIP assessment/certification?

There are four security levels defined in IEC-62443-4-2 standard. SL-1 to SL-4 have different security requirements to meet. SL-1 requires basic security functionality support whereas SL-4 requires complex security requirements.

As per the CIP security WG investigation, CIP software + reference hardware can meet SL-3. However, it is not yet confirmed by the Certification body

What kind of products category is being addressed/covered as part of the CIP certification?

IEC-62443-4-2 covers the following four categories of devices from a certification standpoint. We did an internal survey and decided to apply for the “Embedded and Network” category certification for CIP, since most of the products developed using CIP would fall under these two categories.

What is the policy of the Certification Body or criteria to maintain the certification for a long time?

According to the Certification body, there are two options for Certification - One option allows changes without reassessment up to three years. After three years a surveillance audit would be done to review all changes done in 3 years and confirm whether changes were done by following a compliant process. Based on the results of the surveillance audit the certification would be extended for another 3 years.

Another option is that changes are not allowed without re-assessment. The option is decided based on the Engineering Change Processes followed by the manufacturer

How Debian packages would help to achieve IEC-62443-4-2 security requirements?

CIP security workgroup members investigated all security requirements of IEC-62443-4-2. It was found that there are many functional security requirements that can be achieved by adding a few Debian packages in CIP. E.g. Some of the requirements and packages are listed here. A detailed list is maintained by the Security workgroup, however, because of the confidentiality clause of IEC, it cannot be made public.

Is there any development process recommended/needed for the Certification / Assessment?

CIP Security workgroup has just initiated a discussion with the Certification body to understand the entire process of IEC-62443-4-x certification. Moreover, security WG has also finished an investigation of IEC-62443-4-2 security requirements and identified Debian packages required to meet security requirements.

Furthermore, IEC-62443-4-1 defines secure development practices in detail which should be followed for product development.

So far based on the initial interaction with the certification body, it has not yet been conveyed what kind of development process would be needed for certification. It is expected this would be clarified and documented during gap assessment

How the certification/assessment is carried out in case of open source products like CIP

The Certification body currently has no prior experience of certifying open source products like CIP. However, there are many certifications already completed which use open source software in proprietary products.

According to CB, there are two ways to handle open source software

1. The product (like CIP) that is being certified will take a snapshot of the open source and then put the snapshot under version control and apply all the processes as if they developed the code themselves. The developers will need to monitor the open source and determine if a new snapshot is needed. Using this method, the product (like CIP) developer has controls in place to check for malicious code.

2. The other means is to use open source that is vetted by another group. Basically the owner of the open source gets some sort of certification

There is no security certification model that follows a completely open source model, being that anyone can modify the code anytime. This may be possible for commercial applications that don’t have security or safety issues.

Whatever the model finally is, some entity has to use a certified process to develop and include the code into the final product. The security of the final product is ultimately owned by the organization that licenses its use.

Does the Certification body actually validate all the security requirements by themselves?

The certification of IEC-62443-4-1 is purely paper-based. CB works with the development team and reviews all the available processes as well as development documents. Based on the recommendations of IEC-62443-4-1 and available product documents, CB provides further recommendations

In contrast, the certification of IEC-62443-4-2 requires an evaluation report which describes how IEC-62443-4-2 security requirements are met. In most of the cases IEC-62443-4-2 certification proceeds only based on the evaluation report, sometimes CB may request to demonstrate the technical capability of the product to validate evaluation report

Since CIP is hosted under Linux Foundation and many CIP member companies contribute to the CIP development, who would be the owner of CIP certification? Or with whom the Certification body does communicate?

At the moment there are a few unclear points about this question. However, we have the following understanding based on the interaction done with CB so far.

The certification would be awarded to CIP and the organization plays a little role. Since the supplier will use certified CIP to develop the final product, the ownership is vital for the end product.

As per the current understanding, the applicant of CIP certification would be representative of Linux Foundation. In addition, other CIP security workgroup members will work closely with CB during gap assessment as well as final certification.

Approximately how much time it will take for Certification Body to grant CIP Certification/Assessment

There is no fixed time to complete the entire process. Predominantly it depends upon the turnaround time of the development team, how quickly all the artifacts are made ready and all the gaps pointed by CB are fulfilled as well as incorporated into artifacts, accordingly, the entire process can be sped up.

What would be the output of CIP Assessment/Certification?

Since CIP is not an end product instead a platform. There are several IEC-62443-4-2 security requirements that can be met only by the final product. Apart from that, CIP being an open source development project, cannot meet major secure development practices defined in IEC-62443-4-1.

Because of the above-mentioned reasons, CIP would not qualify for full certification, instead, CB will do an assessment of CIP artifacts against IEC-62443-4-2 and IEC-62443-4-1.

The output of this assessment would be a report which will have details of requirements met and not met by CIP. Requirements that are not met by CIP could be met by the end product based on CIP and hence the end product gets full certification.

During the certification of an end product based on CIP, requirements met by CIP are not assessed again, only requirements which are not met by CIP are assessed.

Since CIP maintains multiple versions of the CIP kernel, which version of CIP kernel would be used for Assessment/Certification?

It depends upon CIP members to decide which version of CIP kernel is used for certification. Once the version of CIP Kernel is decided, the same is used for the entire certification as in the certification/assessment report the versions of software and hardware is mentioned.

Similarly, it is recommended by CB to define a version for CIP Core which can be similar to Debian release versions. However, a detailed discussion for this topic is in progress within the CIP Core workgroup.

Is there any plan to get CIP assessment/certification for CIP software and some CIP member company reference hardware?

We are still discussing this point internally within CIP member companies, this section would be updated as it is finalized

Are there any Regular weekly/bi-weekly meetings held by security WG? What is the process to join the CIP Security workgroup?

IRC meeting is held weekly once where all technical discussion is held and all security members participate.

For joining the security workgroup, first joining the CIP project is mandatory

Are there multiple phases of IEC-62443-4-x certification?

Yes. The entire certification process can be divided into three phases (This description is not shared by CB, instead, it has been documented based on the learning so far).

Phase-1: Requirements Discussion

The applicant, such as CIP members, contact the Certification Body, and explain the certification requirements. During this phase, the applicant needs to share brief detail of the product to be certified as well as clarify any queries related to the requirements.

Phase-2: Gap assessment

Once phase-1 is completed, the CB shares a proposal for gap assessment which defines the following items.

1. Applicant details, project requirements

2. Work scope

3. Cost of gap assessment

Once both parties agree, gap assessment is carried out by CB. CB and development team members work together and all the available documents are reviewed to find gaps against IEC-62443-4-1 & IEC-62443-4-2.

At the end of Phase-2 CB prepares a detailed report for gap assessment which describes what are the missing items or information in existing artifacts.

Phase-3: Certification/Assessment

Before the beginning of phase-3, the development team works to complete all the documents, features, evaluation report, etc.

During final certification/assessment, again CB and development team members work together, CB reviews all the artifacts and verifies all the gaps. Moreover, during this phase,

CB checks the complete evaluation report and if needed, a demo is given of features or requirements in question.

There is a possibility this phase may have multiple iterations. If in the first iteration something is found incomplete, CB may ask to complete and give some time and later again it is reviewed.

Finally based on findings of CB certification/assessment report is granted.