Metasploit is a well-known tool for web apps, and extending it to objects simply makes these objects as easy to hack as web apps. Indeed, there are many aspects in common between a Web App and a Connected Object: they can be reached from internet, they run complex software, they can be targeted by ransomware, and they can be misused.

Then, there are differences, and these differences make objects easier to hack than web apps. The most commonly cited is the lack of supervision of connected objects. This has allowed the creation of very large botnets of connected objects, and will most likely continue and worsen in the next few years, because few people realize that their fridge is in a botnet.

There is another difference, more subtle, but with great consequences on security: the objects’ availability. When targeting a web app, an attacker may know some of the software that has been used to build the app. He may even be aware of some vulnerabilities in this software. However, the attacker will know nothing of the product’s configuration, or of the security products and countermeasures deployed to protect it.

In order to design an attack, information must be gathered by probing the web app “live”, taking the risk of being detected by a sophisticated IDS or IPS, or of hitting a honeypot that will record his attack techniques. Metasploit helps by providing tools and a database of known issues, but such attacks still require great skills.

Now, let’s consider a connected object, even a complex one like a car. The attacker can tear the object apart, get access to memory chips, dump their content, and analyze it. This analysis will take time and resources, but there is no risk of getting caught, and countermeasures will eventually be exposed together with vulnerabilities. Metasploit will make the task even easier if the device includes known vulnerabilities. In the end, the attacker will obtain a viable attack path, by working in the security of a lab.

Detection is very difficult in such conditions. An IDS will protect a connected car, for instance, against random remote attacks. But a skilled attacker will only perform a live attack on a Connected Car after verifying that the IDS doesn’t catch it.

And this is only the beginning. Security research on connected objects is rather new, and focuses on the easiest targets. Skills will improve over time, making more sophisticated targets vulnerable. Now, let’s add to this equation an AI to assist in the reverse engineering and the identification of vulnerabilities. Traditional defenses are toast.

In a few years, if there is a vulnerability in a connected object, someone will find it and maybe exploit it. Encryption will provide a temporary protection. Trusted Execution Environments will add some hurdles. But these are just new countermeasures, not game changers.

That’s what I like in formally proven software. A mathematical proof that a piece of software does not leak information is a good countermeasure against reverse engineering AIs. With such a proof, finding a vulnerability is not about finding a software bug, it’s about finding an issue in a formal model that could lead to a wrong proof that could hide a bug. And that’s orders of magnitude more difficult, even for an AI.

Originally published on LinkedIn.

• Adi Shamir has made gloomy predictions about security in the next 15 years.
• Bruce Schneier has published a long essay about IoT security, with a vibrant and desperate call for action to governments.
• An AI is winning at poker against some of the best human players.

From these three sources, it sure looks like things will get worse before they get better. Let’s start by Shamir’s views on cybersecurity:

1. Cybersecurity is terrible, and it will get worse.
2. The Internet of Things will be a security disaster.
3. Cyber warfare will be the norm rather than the exception in conflicts.

All of this sounds very real today, so Shamir is just implying that it’s not going to get better any time soon. Schneier, on the other hand, is not giving up, by asking for a new government regulatory agency, and also for a body of public-interest technologists, who would be provide expertise into the public debate about technology.

That brings us to the third piece of news. An AI managed to win against really good poker players over several days. This requires strategy, bluffing, and much more. By extension, an AI can now pose as humans or beat humans in any narrowly defined situation, even when complex strategic thinking is required. OK, but even as I write it, I have a problem grasping the consequences of this sentence. I know a things or two about computing in general, and even about AI. Yet, it is very hard to see where that leads us, and how it applies to other fields, like cybersecurity.

So yes, Schneier is probably right in asking for regulatory agencies and public-interest technologists, because of the complexity of today’s technological issues. Shamir is probably right too, because Schneier is not going to get what he asks for, at least not in Trump’s USA (and I wouldn’t bet that we will get it in today’s Europe, either). So, what consequences does it have for “us”?

First, we have to stand strong ourselves. What we are doing at Prove & Run is right. Making devices stronger and more resilient/resistant to attacks is essential in the fight against attackers. And even if a majority of IoT actors don’t care, there remain enough responsible vendors to make a huge market for ProvenCore and applications.

Then, we need to remain humble. Stronger devices are not sufficient by themselves. 10 years ago, as an evaluator, I have used static analysis on Java Card programs to detect vulnerabilities that were very hard to find “manually”, with amazing success. So, if a small research team can program an AI that beats professional poker players, how long will it be before some team of hackers programs an AI that designs attacks on IoT systems? And if that happens, how much will our formal proofs matter? Even if our software is not broken, how easy will it be to bypass it?

French students learn in school about the great ligne Maginot, a very strong line of defense against Germany built in the early 1930’s. The Germans did not break it, they circumvented it.

I believe more strongly than ever that high-assurance security components and formally proven software are essential components of future secure systems. But we have to face a difficult challenge: make sure that no human or AI is able to bypass our highly resistant technology, effectively making it a 21st century ligne Maginot.

We can and will succeed. Our “We are the most secure” arguments are needed to attract our customers’ attention, but we must be careful to move to more complex “We are the foundations of the most secure systems” arguments as their understanding of the issues at stake improves and we get closer to implementation.

And let’s keep an eye on this AI thing.

Originally published on LinkedIn.

• The device performs its tasks normally, but the attacker also runs other software on it, for instance to make it participate to DDoS attacks.
• The device apparently works normally, but its behavior is somehow altered, for instance by providing wrong information.
• The device doesn’t work or obviously dysfunctions, for instance a car that won’t start.

A second factor to analyze the consequence of an attack is the duration of the attack, or the delay until recovery. Here, we can consider four situations:

• Until next reboot. I am confident that the firmware hasn’t been modified, so a reboot will remove the attack vector from RAM and address the problem.
• Until next hard reset. I am confident that the device will not boot on modified firmware, so a hard reset will restore a « good Â» copy of the last known correct firmware.
• Until next update. I am not sure about the full firmware, but I know that a firmware update will remain possible and will address the issue.
• Until replacement. The firmware update mechanism is corrupted as well (or the device is permanently damaged), so the only solution is to replace the device.

We could go further, but let’s stop here for now. The impact looks essential, but the differences between the three scenarios aren’t that great. An obvious dysfunction is bad, but a device whose behavior has been altered by an attacker can be just as bad, and a device that is controlled by a hacker can easily become dysfunctional. In all three situations, it is obvious that some fix is required.

That’s where duration and recovery are important. The two first options (reboot and hard reset) are only temporary fixes. Even if the attack is transient and can be removed, the vulnerabilities that made the attack possible are still present, and the attack can be reproduced easily. Ideally, a reboot or reset/restore must be accompanied with some operational restrictions (like a “safe mode”) until an update is performed.

What we are analyzing here with recovery methods is resilience, or according to Random House, “the power or ability to return to the original form, after being [attacked]”. It is a valuable property for systems that are submitted to high levels of stress. Resilience is about recovery, in opposition to resistance, which is about protection.

Resilience and resistance are complementary. Resilience is often considered easier to achieve than resistance, but maybe more importantly, resilience may still happen when resistance has failed. Even if an attack on a system has been successful, its recovery is possible is the system is resilient to that attack.

We can here use an analogy with resilience against natural disasters. Although a hurricane can cause massive destruction to coastal areas, (resistance is limited), most U.S. coastal areas are resilient against hurricanes because hurricane evacuation routes have been defined, and shelters are ready to host evacuated people. Such resilience measures rarely fail, and we are shocked when this occurs, like in New Orleans after Katrina.

For an embedded device, resilience is mostly about:

• Secure boot, to restart from a clean sheet upon reboot, and detect a potentially persistent attack.
• Firmware update, to load a new version that is not vulnerable to the attack.

More generally, resilience can be achieved through simple infrastructure means like roads and shelters. In the case of connected devices, resilience can be achieved through low-level features, within or below the operating system, and highly independent of the use case.

However, although resilience mechanisms are simple, they also need to be very robust. A hurricane shelter must be built on high ground with strong material like reinforced concrete that offer strong guarantees of resistance against a hurricane. Similarly, the secure boot and firmware updates of a connected device must be designed and implemented to resist attacks. In both cases, this resistance is easier to build because it is applied on a smaller scale, and it is mutualized:

• Smaller scale. A shelter is a single building, typically used for other purposes (like a stadium) that is relatively easy to reinforce. Similarly, a secure boot is a small mechanism, so is the security-critical subset of a firmware update mechanism. These mechanisms offer a small attack surface, and are therefore easier to protect than an entire software stack.
• Mutualized. A shelter is shared by all members of a community, who will use it together in case of emergency. Similarly, secure boot and firmware update are independent of the device’s role and application. The development and reinforcement efforts can therefore be mutualized, reducing the cost for every device.

Resilience must be proactive

Resilience is the capacity to recover from an attack, and as such, appears to be a highly reactive technology, that comes after the fact. It is of course true that resilience mechanisms are triggered after the fact, but in order to succeed, they need to be proactively prepared.

Just like evacuation routes and shelters need to be planned in advance and designed to resist a hurricane, resilience measures in IoT devices similarly need to be prepared beforehand. A firmware update mechanism is crucial, and it needs to be prepared with great care proactively. In particular, this mechanism must be designed to be highly resistant against attacks.

In the world of connected devices, we know that resistance to attacks will be difficult to achieve, because it requires a very large investment from vendors to fix all vulnerabilities and make their systems resistant to attacks. Resilience, on the other hand, can be achieved on a wide scale with a limited budget, and has the ability to provide a strong basis on which IoT security can gradually be built.