Since the introduction of SESIP, there have been some recurrent questions, says Carlos Serratos, GlobalPlatform Security Task Force co-vice-chair. One of those revolves around the relationship with Common Criteria. That is because, in reality, SESIP fills a gap in the security evaluation space, coexisting side by side with Common Criteria in a harmonious, complementary way. While this is easy to say, it is worth exploring and addressing some of the misunderstandings along the way.
The origins of Common Criteria
Before the SESIP methodology was established, there was the standard ISO/IEC 15408 which is often referred to as Common Criteria or ‘CC’. It is the most recognised and mature standard for qualifying the risk introduced by IT equipment.
First established as a methodology for IT procurement of public entities, Common Criteria has become a reference in the industry one which has been used in public and private sectors and addresses a large list of IT product types. However, the strength of Common Criteria, in terms of being a generic evaluation program, has become something of a ‘liability’ in the IoT domain. That is because, while IoT product time-to-market and cost sensitivities are key drivers, Common Criteria lives on the opposite corner of the chart (see Figure 1 below).
Figure 1. The relative position of Common Criteria (CC) versus the market needs of the IoT domain
The origins of SESIP
It is here where SESIP comes into the picture and offers a viable alternative. Addressing the IoT market with a methodology optimised for IoT components and platforms, SESIP takes best practices and lessons learned from the Common Criteria experience.
And so, here lies the first difference but also the complementary nature of the two standards: while Common Criteria can also be used for IoT platforms since it is made for all kinds of IT equipment it results in evaluations with a cost and effort unaligned with the IoT market expectations. Meanwhile, SESIP addresses it by applying best practices from Common Criteria, and security evaluation in general, in a custom-built manner for IoT.
Common Criteria’s approach to composition is from a general-purpose methodology perspective. It adds a level of complexity, and this problem is inherent to any ‘general’ solution in a world with a variety of scenarios. In comparison, SESIP focuses solely on IoT components and platforms.
What the audience requires from Common Criteria and SESIP
Due to historical reasons, Common Criteria addresses the evaluators and certifiers as the prime audience. It is oriented to a very specialised audience who have specific skills and knowledge (especially as Common Criteria is not easy to read), and the objective does not address the needs of developers. After all, the standard was created as an audit tool for the procurement of IT equipment.
In that regard, SESIP instead looks to address the developer’s needs. It aims for simplicity, clear understanding, and transparency and is designed to be understood by a non-specialised audience. For example, there might be a developer of a TLS stack looking to use an RTOS from another developer who is using a crypto library from another developer that relies on the random number generation of a chip. And although each professional has a different requirement, all of them will be using SESIP.
For that reason, the SESIP methodology requirements for the documentation, presentation of the evaluation results, and all related evaluation information are accessible, readable, and understandable by an audience made up of developers rather than evaluation and certification specialists, as is the case of Common Criteria.
Ultimately, SESIP is a tool for developers to select the right platforms and components to apply State-Of-The-Art technology according to their use cases, as we explored in a previous blog. The methodology is looking to solve a problem beyond security functionality and visibility, instead exploring fragmentation as there are hundreds of standards, policies, and regulations worldwide for the IoT.
Evidence from SESIP-certified components and platforms serve as evidence of the conformance for the device security functionality that can be mapped in the consumer (EN 303645, NIST 8259a, NIST 8425), industrial (IEC62443-4-2), medtech (DTSeC), and automotive markets (ISO21434).
The overall differences at-a-glance
| Common Criteria | SESIP |
| Any kind of IT products and domains | Specific for IoT platform and platforms |
| Long time and costly evaluations | Quick and cheaper compared to CC |
| Additional complexity due to its generic nature | Optimised performance due to its specific use |
| Target audience: Evaluators, certifiers and auditors | Target audience: IoT platform and product developers |
| Formalities first, usability next | Usability first, formalities next |
| Demonstrates the security capabilities of the product | Provides evidence of the security capabilities for reusability |
| Addresses the proof of security capabilities problem by formal evaluations | Addresses the issue of IoT requirements fragmentation by means of evidence of component |
In summary, a SESIP evaluation is never the end of the road, it is often the start of the security journey. The Common Criteria and SESIP standards are particularly good at something, and one will be the strong option over the other for a particular application and domain. In truth, that is a great place to be for security and standards because, by having similar origins, they are both complementary in nature.
The author is Carlos Serratos, co-vice-chair at GlobalPlatform Security Task Force.
Comment on this article below or via Twitter: @IoTNow_OR @jcIoTnow
- SEO Powered Content & PR Distribution. Get Amplified Today.
- PlatoAiStream. Web3 Data Intelligence. Knowledge Amplified. Access Here.
- Minting the Future w Adryenn Ashley. Access Here.
- Buy and Sell Shares in PRE-IPO Companies with PREIPO®. Access Here.
- Source: https://www.iot-now.com/2023/05/31/131016-securing-the-iot-sesip-or-common-criteria-that-is-not-the-question/
