Alleen in het Engels beschikbaar
Blog post 27 May 2020 by Robin Vossen, Senior Security Specialist at Secura
Creating a path through IoT Security with ETSI EN 303 645
IoT devices create a lot of new opportunities for all industries. However, the IoT landscape is known (even beyond security researchers) to contain a lot of security vulnerabilities.
As everything is getting connected to the internet, risks are involved. Especially with IoT products as they have a high complexity and a pressure to go to market before similar products from other competitors do. The above described combination leads to security vulnerabilities within these devices, as developers are often not granted the time they need to develop a complex product, with a corresponding security architecture.
There are numerous ways to tackle these security issues. One of the ways you could attempt to tame the beast named "IoT security" is using frameworks or standards. These give developers insight in the kind of security issues their device can have. One of these standards is the ETSI EN 303 645.
As of the beginning of this year, Secura has been experimenting with this standard in order to identify if it would cover (consumer) IoT security to a satisfactory degree. As the problem with standards is that they limit the scope of the research drastically, it is very important that the selected standard is wide enough to cover most bases explored and exploited by attackers.
The ETSI EN 303 645 was chosen as it seems to cover quite a few bases being; the hardware itself, privacy, company policies and (most important) the security of the software in place.
So, what is this ETSI EN 303 645 standard you might wonder. This standard is made by the ETSI (European Telecommunications Standards Institute) group and is developed to address the security for consumer Internet of Things. The word 'consumer' is key here, as the targets will not be IIoT (Industrial Internet of Things) or POS systems (Point of Sale), but consumer grade hardware such as that new gadget you bought the other week. When threat modeling this device category as a whole, the primary risks are software related risks such as leaking data or being exploited to become a bot (malware et. al.) for other attacks and not so much the risk of compromising the hardware (e.g. physical access required).
The standard dictates a number of requirements, which are defined over thirteen categories;
- No universal default passwords.
- Implement a means of manage reports of vulnerabilities.
- Keep software updated.
- Securely store sensitive security parameters.
- Communicate securely.
- Minimise exposed attack surfaces.
- Ensure software integrity.
- Ensure that personal data is protected.
- Make systems resistant to outages.
- Examine system telemetry data.
- Make it easy for consumers to delete personal data.
- Make installation and maintenance of devices easy.
- Validate input data
As is clear by reading these requirements, these points require internal knowledge about the product. This could either be gathered within a crystal box or a black box approach. These two methods of research will vastly differ.
For a crystal box approach, the manufacturer would have to be involved by supplying source code and design documentation, thus allowing for regular source code audits using documentation to determine how are the trust boundaries set and maintained.
However, when a black box method is employed the firmware will have to be dumped and reverse engineered in order to get a solid understanding of what is done how and what measures are taken to ensure that the device does not get compromised.
The crystal box approach offers most insight and is least time-consuming, however often the seller of the IoT device is not the End-to-End builder of the device hardware and software. This often results in a black-box approach, where experts aim to address most requirements within a reasonable timeframe.
As there is quite a lot of ambiguity in the current version of the ETSI EN 303 645 standard (in terms of how requirements are formulated), it is of utmost importance that specific minimum criteria are agreed upon.
An example of this situation would be requirement 4.3-5 - “Timeliness of security updates". The definition of "timeliness" is not set and without a hard boundary this will always be a point of discussion. The same statement holds true for requirement 4.3-12 – “Periodic check for updates". Once every ten years is also periodic. As described earlier, when a minimum acceptance criterion is set, for example once a month the chance of exploitation is reduced while maintaining the flexibility in implementation.
Due to the fact that many of the requirements are expressed in such open manner, Secura has created a proprietary testing guide. The reason this testing guide was developed was to drive the industry towards adoption of the standard, as well as making the testing approach more concrete, less ambiguous, while maintaining the flexibility. The creation of this testing guide led to an invitation from NEN (the Dutch standardisation organisation) to one of their organised events. The event was a meet-up with people from the industry, aimed at talking about the requirements within the ETSI EN 303 645, as well as the practical applicability and value of this standard in the context of consumer IoT.
Due to Secura's practical experience using this standard and interest in the developed testing guide, Secura participated in this event. Moreover, there was interest in the testing guide which Secura developed on this topic. The reason we developed this was to drive the industry towards adoption, as well as making the testing approach more concrete, less ambiguous, while maintaining the flexibility. The participation led to many interesting discussions, related to the adoption of the standard.
A question that was asked during this meet-up by a developer of IoT devices was: "why would we adhere to this?”, which is an honest and critical question.
After all, compliance with the standard is (currently) not mandatory and at the same time it could be costly sometimes. Besides the intrinsic drive to create secure products and to prevent your product to become a gaping hole in the users’ network, the primary reason would be to future proof your company, products and developers for when this standard does become mandatory. Within the use of DigiD (Logius) we have seen the same kind of trend. When DigiD was created there were no laws or regulation in place mandating the use of this methodology. A similar situation can be currently seen around ETSI EN 303 645.
And then there is something which develops slowly overtime in laws and a more secure internet. For this reason, it would be best to prepare now, when mistakes are not yet penalised to learn about the wonderful world of IoT Security.
For now, we have our logic analysers, soldering irons and disassemblers to perform the security assessment of the IoT devices you are developing or you have within your network. Whether being cameras, radios or other similar gadgets, we are happy to support you ensure that malicious entities cannot exploit these products and abuse them to act as an entry point within your secured network.
As with an evolution; first there is nothing, then there is something and then it develops slowly overtime; for security concretely in laws and a more secure internet. For this reason, it would be best to prepare yourself now and get to know this ETSI standard while we jointly learn about the wonderful world of IoT Security.
Read more about the ETSI standard in our fact sheet. If you have any questions concerning IoT Security, please contact us at info@secura.com.
Fact sheets
