Click the blue text above to select “Set as Favorite”.
Key information delivered on D1 time!
When companies adopt cybersecurity products to ensure the security of IoT devices, they should ask themselves several questions.
Companies may face significant challenges in achieving security when building IoT solutions. It can be said that adopting cloud platforms for protective solutions is not new, and there are many well-established practices and support frameworks to help companies implement the right things. When it comes to hardware, embedded IoT devices that will ultimately connect to the public network remain an unknown area for most people.
The following will explore several questions that companies should ask themselves when adopting IoT devices and provide some answers to help make their IoT devices as secure as possible.
1. What is the identity of the device? Is it non-falsifiable?
When companies authenticate individuals based on websites or any form of online service, they typically rely on Multi-Factor Authentication (MFA) to avoid impersonation and identity theft. Multi-Factor Authentication effectively prevents cyber attackers from falsifying their online identity because they may not have access to all the evidence required for authentication for the stated website or service.
For example, a cyber attacker may know a user’s password or even steal their phone, but they will not know the six-digit code set on the phone, nor will they have access to the fingerprint. In short: they will not be able to complete the login process and impersonate the user.
So, can a similar mechanism be implemented to prevent the impersonation of IoT device identities? The answer is to use dedicated hardware, such as a Trusted Platform Module (TPM). In short, such devices have cryptographic keys protected by hardware. The private key, once stored in the module, never leaves the module, and the public key is then used to prove the identity of the device. Since the keys cannot be falsified, simulating the device is essentially equivalent to physical access to it, which of course brings other security issues.
2. Where does the code run?
The term Trusted Computing Base (TCB) refers to the hardware, firmware, and software components that are critical to system security. From the previously mentioned Trusted Platform Module (TPM) to its operating system (which could be real-time) kernel, various aspects of the IoT device will play a role in ensuring the overall security of the system.
When designing IoT devices, it is essential to remember that the trusted computing base should be as small as possible. This can minimize the attack surface and reduce the errors or risks within the Trusted Computing Base (TCB), allowing cyber attackers to bypass security protections and deploy malicious payloads, such as stealing valuable business data.
If possible, an operating system or real-time operating system should be constructed that only allows the company to release and enable the functions that are genuinely necessary. In any case, the company’s application code should run outside the Trusted Computing Base (TCB), allowing it to operate normally without compromising security.
3. Are software components partitioned?
A watchdog timer is actually a clever concept that can automatically trigger a complete reset if a component of the embedded system stops responding, but sometimes it is also worth considering whether they should exist in the first place.
Historically, and often due to hardware limitations, embedded code has been designed as a relatively monolithic blob where a defect or vulnerability in one component could potentially compromise the entire system, hence the need for a watchdog to mitigate the consequences of software failures.
Now, what happens if, in addition to harmless software errors causing the module and system to hang, the module may have vulnerabilities? Of course, one does not want attackers to take control of their entire system due to a defect in a software module.
To mitigate this risk, secure IoT devices should allow partitioning of their various software components and implement hardware-enforced boundaries between them. If built on a real-time operating system (RTOS) and modules can run as independent tasks or processes, their state may be quite good.
Moreover, ideally, a secure model should be in place that restricts the hardware resources accessible by each software module.
4. What is the scope of network exposure through security mechanisms?
From Distributed Denial of Service (DDoS) or ransomware attacks to using IoT devices as a way to access corporate networks, IoT devices can be tempting targets for hackers. Companies should assume their devices will be attacked by hackers, who are often more creative and persistent than people realize.
Defense in depth, originating from the military, is a technique to deter attackers by deploying defensive resources not only at the front lines but also in the rear (such as fortifications and military units).
Defense in depth applies to IoT devices (often IT) and includes implementing multi-layer security controls, employing multiple mitigations for each potential threat.
For example, a combination of internal firewalls that control access to physical buses, network firewalls, and secure boot will significantly reduce the chances of devices being compromised. If attackers are unlikely to execute malicious payloads through secure boot, the firewalls will prevent them from physically accessing the device’s peripherals or connecting to remote third-party servers.
5. Is authentication based on passwords or certificates?
Have people heard of shodan.io? It is a search engine that essentially reveals the darkest secrets of IoT. For example, passwords like “1234” and “admin” are among those secrets, and shodan.io allows companies to find IoT and network devices online that have not changed their default passwords.
In addition to the obvious threats posed by publicly accessible devices relying on default credentials, password-based authentication can be challenging to manage at scale.
For example, how to recover from a stolen password, particularly when thousands of devices deployed in the field use that password? On the other hand, certificate-based authentication does not rely on shared secrets and can allow mutual authentication, thereby reducing the risk of man-in-the-middle attacks.
6. Can devices be easily auto-updated?
When it comes to IoT devices, there’s a saying: “If it can’t be updated, it can’t be secured.”
To keep devices secure, they need to allow security updates to be rolled out as security threats evolve and cyber attackers discover new attack vectors. The security of updatable devices includes, for instance, the ability to roll out operating system updates (like patching zero-day vulnerabilities) or deploying new certificates.
Ideally, companies should also take appropriate hardware measures to prevent devices from reverting to known vulnerable states after updates.
7. Do the company’s IoT devices report failures?
There can be many reasons why IoT devices may fail. For example, it could be due to a cyber attacker attempting to control them by exploiting vulnerabilities or trying to brute-force passwords. It may also simply be due to the device encountering extreme conditions and switching to an uncertain state, making it vulnerable to attack.
Regardless of the reason, it is crucial to be able to track these device failures to not only diagnose and correct them but also to isolate and mitigate potential attack vectors before effectively exploiting these failures.
There are also solutions that can help report errors. The Azure Security Center for IoT and its associated open-source agents are excellent examples of how to automatically collect and log events, such as failed login attempts or connections from unusual IP addresses.
Conclusion
This article was inspired by the article “Seven Features of Highly Secure Devices”. If companies want to explore some of the best practices related to each high-level security topic listed, they should do a cross-reference.
Finally, if companies wish to operate actual devices and actual code to familiarize themselves with this new area, the Azure Sphere development kit can be recommended as a tool to master the tools needed to build secure IoT devices.
The kit is based on an open hardware reference design that essentially implements all the listed attributes and ensures the security of IoT devices. It features a secure, connected microcontroller unit (MCU), a customized advanced operating system based on Linux, and cloud-based security services that provide continuous updatable security.
Currently, there are also many tutorials and code examples available to help companies use Azure Sphere and start understanding all the considerations when building IoT devices.
Copyright Statement:This article is compiled by D1Net, and reprints must indicate the source as: D1Net. If the source is not indicated, D1Net reserves the right to pursue legal responsibility.
(Source: D1Net)
If you work in a field of enterprise IT, networking, or communications, and wish to share your views, you are welcome to submit to D1Net.
Submission Email: [email protected]
Click the blue text to follow.
You can also search for the public account “D1net” to choose to follow the sub-public accounts of various fields (cloud computing, data centers, big data, CIO, enterprise communications, enterprise application software, network communications, information security, servers, storage, AI, smart cities, etc.) under D1net.
