The Common Criteria (CC) can be considered the core cybersecurity standard. All other industry-specific standards have very large overlaps with it. This is also due to its history: It was launched in the early 1990s to create a common international standard and is based in part on the country-specific security standards of that time. Today's industry-specific standards such as the DO-356A / ED-203A in avionics are based on the principles of the CC.

The CC evaluation levels include seven levels, with 7 being the highest and 1 being the lowest. The levels are intended to provide reasonable confidence in an IT system and are assigned by independent testing laboratories and government authorities in cooperation with the client seeking certification. The client aims for a pre-determined level, and the testing laboratory assists with the certification work. The state authority ultimately awards the certification. Which software holds a current certificate and at which level can be checked at any time on Commoncriteriaportal.org. Only those listed there have a certified product.

Evaluation Assurance Levels (EAL) of the Common Criteria

If one wants to achieve one of the seven EALs, certain conditions must be met. First, the three dimensions that are important in grading an embedded system are scope, depth and rigor. Scope simply means how large the part of the respective embedded system is (you can also have only parts of an embedded system certified - the Common Criteria gives you the freedom to certify what you want to certify). The depth indicates how fine-grained the examination of the product is, how detailed the analysis is carried out. Finally, the rigor indicates how rigidly the evaluation is performed. This ranges up to formal proofs that something is secure. According to a predefined matrix, classes are listed with subfamilies, each of which raises objectives and requirements for the embedded system to be certified. The three dimensions here are the compass for the respective level of the classes. The areas (referred to here as classes) that are consulted are Development, Guideline Documents, Lifecycle Support, Security Target Evaluation (the Security Target is the central document with which the system integrator proves its efforts), Testing and Vulnerability Assessment. The Test class, for example, contains the Depth (ATE_DPT) and Functional Testing (ATE_FUN) subfamilies, among others. Depth (ATE_DPT) is not to be confused with the previously mentioned dimension depth.

EAL 3 or 5 - What's the Difference and where does PikeOS stand there?

The previous certification of the PikeOS Separation Kernel was at the level EAL 3+ (the plus sign indicates that in addition to all the levels of the subfamilies that had to be achieved, additional evaluation took place with optional classes that seemed meaningful in the context of the embedded system). EAL 3 indicates that the embedded system has been methodically tested and verified. This includes or is understood to include a complete security target in which the security functional requirements (SFR) have been analyzed, a description of the security architecture of the embedded system in order to understand its functionality, interface descriptions and guidance documents. Functional and pen testing and vulnerability analysis are also required. Some further requirements must be met, such as configuration management of the embedded system and proof of secure delivery procedures. The Common Criteria speaks of an overall moderate security level for developers and users, which can be independently confirmed.

The Separation Kernel of PikeOS has now reached EAL 5+ in version 5.1.3. Among other things, this level provides that, in addition to the above-mentioned requirements, modular security feature design (TSF, TOE Security Functions) is added for the first time. The TSFs comprise the hardware, software, firmware (i.e., the hardware abstraction layer, which can be the BIOS or board support packages), which must meet the described requirements (Security Functional Requirements, SFRs). The biggest difference is that the embedded system has not only been methodically tested and checked, but has been developed in a more structured way and is therefore more analyzable, and a semi-formal description exists.

In the case of PikeOS, the plus sign ( + ) indicates that, in addition to all requirements at the EAL 5 level, the optional classes AVA_VAN (Vulnerability Analysis), ADV_IMP (Implementation Representation), ALC_DVS (Development Security), ALC_CMC (CM Capabilities) (among others) have also been achieved at the maximum level EAL 7. In other words, PikeOS has EAL 7 level in some points. Especially for the Vulnerability Analysis class, this is a strong added value for system integrators, because it has been proven that remaining vulnerabilities of the TOE are only exploitable by attackers with the attack potential of (in Common Criteria language) "beyond high". This is the highest possible rating. It is based on a score determined by factors such as the time required for identification and exploitation (Elapsed Time), the technical expertise required, which includes not only certain knowledge but also the number of attackers (Expertise), knowledge of the design and operation of the TOE (Knowledge of TOE), the "window of opportunity", and the equipment required, such as IT hardware/software or other tools required for exploitation (Equipment). EAL 5+ in this case also means that PikeOS reaches the level of the French standard of the national cybersecurity agency ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) "Qualification renforcée".

Want to learn more about PikeOS and Security? More information at www.sysgo.com/pikeos