Internet of Things: Evolution or Revolution?
Human societies usually use the number and impact of their revolutions to measure their importance in the global history. There is therefore a race to overhype the impact of small changes and pretend evolutions are revolutions. The invention of the stone-based fire lighter, of the round wheel or cutting a king's throat in a starving France did cause dramatic changes in the fate of society and opened to new ways of living. These were really revolutions.
IoT is just a simple evolution of already known technologies and it has been around for much longer than journalists can remember. Ever heard of SCADA systems or Home Automation? They usually didn't go over the Internet but that's really the only thing that they missed to become an IoT. The revolution (if at all) about IoT is the marketing hype around it, the new applications that are targeting general public and the new risks that we will have to control and mitigate.
What's all this security stuff, anyhow?
For those who may find this title familiar, my reference in terms of introduction of technical subjects is Bob Pease, this genius who popularized a wide series of electronics topics over the years and passed away in 2008.
From a security point of view, a system starts becoming useful the moment its first intruder breaks in: this first intruder is called the end user. The comment may sound harsh but it is a vision that developers often miss to realize. The end user is a genuine part of the system but his interface is often an entry point for hackers, and this has been known for years. With IoT, we will see that the security risks are not limited to the interface but may open back doors and impact the real world, leading to a variety of new dangers: a blog site puts your reputation at risk, a financial institution puts your money at risk, an IoT can put your house at risk.
Risks vs. Dangers
There is a thing that irritates me in the press: many firms publish articles about how secure their products are and I often get to the end without understanding their claims - and often see how they are trying to sell me a product based on unsupported arguments. Is Linux really more secure than Windows? Is a Flash-based embedded system more secure than a desktop? The security level of a system depends on the weakest link, which will probably be the application. A Flash-based embedded system can abort an intrusion when you reboot it, as long as the application locks the ability to reprogram its memory. You may statistically improve security by using well tested elements but they are no guarantee at the level of the finished product.
All systems are potential risks, unless they are obvious or obsolete. To avoid intrusions, disconnect the network cable and disable the USB connector... but this will complicate the design of an IoT system. The point is not to avoid all risks but identify and mitigate them. But what is a risk, to start with?
A risk is a potential misbehavior that can be triggered by a specific condition. For instance, you work for a company that pays your salary. There is a permanent risk that your employer cannot pay your salary at the end of the month. If all the customers go away, the risk converts to a danger. Your work is a proactive measure to ensure that your employer has products to sell and ensure your salary at then end of the month, hence reduce the probability that the risk becomes true.
Risks Metrics
Generally speaking risks must be measured in terms of impact and probability. A truck may crash into your house: if it happened, the impact would be very high for your family but, if you live in a straight section of a street, the probability is very low, hence a low risk.
For every feature that we define, it is critical to determine if it can have an impact on the overall operation and, if it is the case, how to minimize the probability. If the probability cannot be reduced either, the feature should be reconsidered.
The 4 pillars of security
I have an open letter to marketing guys: "Please do not send me an article about secure products if you don't qualify the term. Best regards. Olivier". I hope I made myself clear.
Any Computer Science course dedicated to security will talk about the 3 pillars: Authentication, Confidentiality, Integrity. I personally prefer the extended definition that includes also Availability, although it is a direct consequence of Integrity. In short, I know that my information is safe if I can identify who the provider is, make sure that no one else has access to it without prior authorization, receive it unadulterated and have permanent access to updates. If you miss any of these 4, your system is unsafe, period. Remember the option of disconnecting the network cable above? You just broke the availability of information so you just made your system unsafe by applying DoS (Denial of Service). The challenge goes beyond this.
Safety vs. Security
Safety and Security are 2 typical marketing buzzwords. However, Security is usually a better selling argument than Safety so it tends to be preferred. I don't think this confusion does anyone any good so let's have a closer look.
We have just seen what Security is about but what is Safety? Safety if the condition of being protected from non-desirable conditions (summary of Wikipedia's definition). Is a secure system safe? In essence, yes. Is a safe system secure anyhow? Not necessarily.
I saw recently an article explaining that an embedded RTOS was secure: I'm afraid that a "secure" system is not synonym of "very safe". An RTOS takes care of tasks execution and, in some cases, can isolate the tasks from each other. On the other hand, it does not control the identity of the users nor with whom the tasks communicate. From this viewpoint, we can talk about safety. Any security feature will have to be implemented in the application itself.
Is Linux a secure system? Let aside the typical discussions about coding mistakes and other flaws, it offers features like user identification, encryption and firewall that help building a secure solution. From a design perspective, it can be considered secure. Note that I'm only talking about design: if you don't configure the system correctly or apply the relevant patches, your system can quickly become the target of a hack. Linux, or any Operating System considered as secure, is not a silver bullet or a magic wand.
My RF link is secure because it is encrypted
Have you ever heard this argument? Although it is true that secure systems are usually encrypted, the reverse is not a guarantee. WiFi is encrypted but if you ever loose your password, there are some Linux distribution that will help you to crack it. I'm talking about Open Source software and a standard laptop that you can discretely take in your car. Even the computing power of a modern mobile phone would sufficient to hack into a WiFi network.
Encryption serves 3 main goals:
- Confidentiality, reducing unauthorized read access to the information;
- Authentication, reducing unauthorized write access to the network;
- Integrity, reducing the risk that adulterations go through undetected.
Confidentiality is the hardest of all because, even with the most complex algorithms, the decryption is a matter of time. My recommendation is to transmit only partial information that can be reconstructed only with an intimate knowledge of the solution.
Authentication is a more severe issue so it should use complex challenges. If you have to encrypt a password, send a clue to the counterpart, who will have to derive the encryption key from contextual data. It is not perfect but will at least reduce the risk of simple replay attacks. The idea is that, by the time they worked out what your current key is, you have already changed it.
Encryption does not guarantee integrity but it can help to protect contents. Multiple and variable keys will give a harder time to attackers to determine how to extract the sensitive information and alter it.
Availability, however, will remain a risk that should be assumed. If it can happen and is not acceptable, it probably means that the solution will have to be redesigned.
Now, if your RF link inherent encryption does not ensure the above, it is probably time to define a complementary strategy at application level.
By the way, what is IoT?
You cannot control a system's security if you don't define its scope. IoT is a mix of things that bring their own complexity and risks. IoT is an end-to-end system, that combines sensors and actuators, a local hub, a central server and an Internet access to monitor and control the far end, usually through a web site or a mobile application. This type of solution can give you the option of starting the central heating of your house on the way back from vacation or monitor a nuclear test without exposing your personal to radiation. Assume that an intruder breaks into the system and activates a feature in an uncontrolled manner: in the first case, you may burn gas in excess in your house while the latter you could well kill people and cause major damage to the environment. With great powers come great responsibilities.
IoT solutions must be secure by design without compromise and the level of control must depend on the criticity of the information. Let's assume that a hacker gets into the control of your central heating: what could happen if he gets read access to the temperature of the boiler? I suspect not much. Assume now that he can alter the reading: the boiler could stop working or, even worse, work non-stop and overheat, with the associated fire hazards that this could cause. Remember that the whole point of IoT is remote control and you probably won't have local human feedback to detect the failure.
Our first lesson is that the information should be segmented and made available on a need-to-know basis.
Why do we need 4 layers?
There is no general definition that imposes it but IoT designs usually follow this pattern: 1) local sensors and actuators, 2) a local hub, 3) a central server and 4) web access. These 4 layers have 3 main interfaces that need consideration, with their own associated risks. Web access threats are a recurrent subject and I don't claim to make a major contribution here, apart from highlighting that the impact goes well beyond a simple database this time.
The link between the local hub and the server will often be a proprietary protocol, as it is internal to the system. Its security will probably be under-evaluated for being hidden from the external world. The Stuxnet virus should be a loud reminder that systems are never intrinsically safe and that security-by-obfuscation has long been obsolete. What can we do to protect it? First, make sure that all actions controlled at this level are reversible: in the case of the central heating control, allow the ambient temperature to vary between 10 and 30 degrees Celcius and let the thermostat take care internally of the control of the boiler. This way, your hacker may increase your bill at the end of the month but the boiler's internal regulation and your house will be safe. We don't completely avoid the risk but we mitigate it (reduce the impact). Second, define patterns for fault detection: if the average outside temperature is 20 degrees Celcius, you can probably ignore requests to switch on the heating. Third, challenge your counterpart with random queries on a regular basis: a hacker may find the answer to a given challenge but will have a harder job to control your system permanently.
The local loop between the sensors/actuators and the local hub will probably be the weakest point in the chain because it will (erroneously) be considered safe: hackers would need to break in physically to interact with it. This false sense of safety can open doors to a variety of hacks: it is clear that a guy on the other side of the planet will have a hard time breaking into your ZigBee network but there are other ways to do it - and another audience. Local loops are traditionally designed to give close and accurate control over the system and can therefore cause higher level of damage.
Regarding physical connections, there are 2 main classes: wired and wireless. Wireless networks are easier to install but restrict the usability in terms of concurrent access (availability) and privacy (confidentiality). It is not necessarily a major restriction but has to be evaluated on a case-by-case basis.
Outlook
IoT is a new paradigm and the design requires a minimum of attention. The rules are not specially new but take a new light for some of the actors.
First, understand that the pillars of application security may not be equally important: in the case of the remote control of a central heating, confidentiality may not be as critical as authentication. In the case of a missile, geolocation may be as important as control. It will have to be evaluated for each project and information item.
Second, segment the types of information and define clearly what item needs to be handled within each scope. Our firmware applications handle global and local variables, or public and private methods. Likewise, our IoT should handle information within the sensor/actuator, within the local loop (between the sensor/actuator and the local hub), up to the server or up to the web application.
Third, evaluate the security requirements for each layer: we may find that the connection between the local hub and the actuator can be a simple 12V/1A control line but it will have to be checked. If encryption is required, check the required complexity and volatility of the keys: it can affect the complexity of the sensor or actuator and the microcontroller choice.
Fourth, scalability will be a decision criterion. If you design a new system, make sure that you offer flexible features. If your solution is initially designed for a house, make sure it can support a complete, multi-storey building. But whatever you do, make sure that security risks remain under control.
Finally, take some time to study other people's errors: there are some sites like SANS or OWASP that specialize in best practices and can help to reduce the risks. It can be a great complement to our own experience.
No comments:
Post a Comment