The increasing number of IoT devices has led the industry to recognize the need for a specific evaluation methodology for this kind of products.
When it comes to IT security evaluation methodologies, the one that has been established in the market for the longest time is Common Criteria. Therefore, the SESIP methodology was designed using the principles and terminology used in Common Criteria, making it easily adoptable for all parties involved in the certification process.
So, the question that arises is: Is a specific methodology for IoT necessary? Let’s see.
Why do we need a methodology for IoT?
IoT devices have certain characteristics that differentiate them from any other IT product.
Lifecycle
To begin with, IoT devices are physical devices that, unlike other products, have a specific lifecycle:
- The manufacturer provides the product to the user.
- The user customizes it by entering personal data and configuration.
- The user uses the product, updates its firmware, and eventually may reset it to factory settings, going back to the second point.
- Finally, the user no longer needs the product, sometimes returning it to the manufacturer.
An IoT-oriented evaluation methodology can focus on this lifecycle, while a generic methodology lacks this capability.
Environment and Threats
By narrowing down the scope to IoT products, the SESIP methodology can limit the types of threats that need to be addressed for such devices.
In this aspect, SESIP defines a basic scenario in which the strength and adequacy of security mechanisms need to be verified to protect the product from network interface attacks. However, in this scenario, the attacker may have physical access to the device to perform reverse engineering, with the only limitation being the potential for attack during the preparation phase.
This initial scenario can be Extended to include physical access and untrusted software.
Extending with physical access simply adds the possibility for the attacker to have physical access to the product when executing the attack.
When Extending with untrusted software, the intention is to test the product’s resistance to updating/replacing legitimate software with malicious software.
How do we define that these extensions are included in our scope? Very easily, by adding the security functionality (SFRs) that protect against these types of attacks.
Modularity and Reusability
Any IoT device is a combination of hardware, software, and firmware that collectively provides its final functionality.
If the same processor or cryptographic library is being used by different manufacturers to develop their products, what sense does it make to evaluate the same functionality provided by these?
SESIP is a methodology that prioritizes reusing previous evaluations of the different elements that compose a product, focusing on how the integration of these elements is performed and the security functionality provided that was not previously evaluated.
Is it easy to get certified with this methodology?
SESIP offers manufacturers a straightforward way to demonstrate the security of their products.
Flexible Deliverables
Unlike Common Criteria, the deliverables (documentation) required for this methodology do not have such strict structure. SESIP focuses on ensuring that the necessary information for conducting the evaluation is provided to the laboratory, regardless of its format.
Therefore, in most cases, developers do not have to generate specific documentation for the evaluation, apart from the Security Target.
Self-Assessment
SESIP has five levels of assurance. This means that the higher the assurance level, the more information the developer needs to provide, and the more rigorous tests the laboratory shall perform.
At the first level of assurance (SESIP1), the developer conducts a self-assessment by documenting how the product implements the security functionality. The laboratory will analyse this document and provide a verdict on it.
This level facilitates the entry of developers who are not accustomed to this type of methodology. Higher assurance levels involve black-box testing, white-box testing…
