Over the past few months, numerous breaches have been reported in connected embedded devices ranging from medical devices to programmable logic controllers (PLCs). The so-called Internet of Things (IoT) is now under attack in similar ways to the rest of the IT infrastructure, but there are two major differences:

  • IoT devices rarely have the same security level as professional IT hardware. Many of them have been developed prioritizing time-to-market and are lightly evaluated for security. On the other hand, IT hardware has been exposed and exploited for many years, and the industry has evolved countermeasures.
  • IoT devices are now cheap and produced in volume. They will pop up in the IT network for many good and bad reasons. The fact is that they cannot be simply discarded but they cannot be ignored either.

This security softness makes those new connected devices a great way into an IT network but their ubiquity and volume also make them a great vector to launch reflective attacks on other targets, as evidenced by the Mirai botnet and its offspring.

IoT devices are generally meant to be driven from the cloud (typical for home automation systems) or from a private server (typical for OT networks). These remote connections bring business value through the centralized gathering and analysis of sensor data and by providing manual or rule-based actuation in the field. Traditionally very little thought is given to security and more particularly to recovering from a security breach. At best, the devices can be updated remotely but this is not sufficient to ensure the security of an entire network. And that’s before we even consider that the remote connections also make the attack surface larger.

The Genie Is Out

In an ideal world, security is not an afterthought. Security is part of the whole product lifecycle. Coming back to reality, billions of devices are connected today and, for the most part, are not secure. There is no way to put this genie back in the bottle, even if we wanted to. Fortunately, some manufacturers are starting to include security in their IoT systems. Unfortunately, this doesn’t help the billions of devices that are already deployed.

Highly regulated markets such as the medical sector already have their guidelines. The FDA has published “Postmarket Management of Cybersecurity in Medical Devices” which essentially gives recommendations to manufacturers about the management of medical devices once they are out in the wild.

It is reassuring to know that pacemakers and insulin pumps will be managed throughout their lifecycle. This doesn’t fix the rest of IT and OT though as the manufacturer of your average connected device does not and probably never will implement such security guidelines. For IoT, we will need to deploy countermeasures to secure the network.

Going back to the basics, prevention, detection and response are the commonly accepted pillars of the information security process. How does this translate to connected devices that are already in the field?

Know the Threat and Contain It 

Before deploying countermeasures, a company has to understand its gaps. Therefore, the first step is to better understand the potential threat through a discovery. This discovery should not only include wired devices but also wireless ones. The various radio protocols, modulations and frequencies in use make this task non-trivial and such an analysis requires some fairly advanced tools.

The discovery is likely to show known and unknown devices. Among the known ones, there will be some sensitive ones such as video surveillance cameras. It is never too late to evaluate the hardware, software and network security of such devices as they are exposed. These generally come in small numbers and they can be managed like other IT assets (incl. updates, configuration management, etc.). It is unlikely that the local penetration testing company will do a great job analyzing the security of exposed embedded devices as this requires hardware security skills.

One of the main countermeasures companies deploy with IoT is segregation. It is a good practice to isolate or compartmentalize IoT devices from the rest of the network (e.g. NAC). In reality, most of those connected devices will need access to the Internet to function. Even if they are only allowed to connect to some kind of limited “guest” network, they could still be used to carry out reflective attacks to target other entities.

In addition to corporate-controlled devices, there are also one-off or user-provided devices, i.e. the newest “iThing” for the CEO and the connected toys the product engineers promise they need to get the job done. What can be done about detecting their presence and threats targeting them?

Enter Live Monitoring

As preventive measures are never as perfect as we would like them to be, detective countermeasures are needed. A solid SOC or a Cyber Fusion Center would be ideal but a NOC is already a good first step to identify some of the most obvious attacks like a reflective DDoS.

Monitoring is all about threat intelligence and skilled security analysts. The threat intelligence feeds must include IOCs for embedded devices and the security analysts must be able to hunt for threats on those less conventional devices.

Live monitoring will also keep the list of connected devices up-to-date and allow for better preventive measures.

That “Oops” Moment

If the detection job is done right, attacks will be discovered quickly and they will require fast and efficient response. The response is tightly linked to the type of attack, to the assets under attack and to the value at risk. While some devices could simply be disconnected / isolated, others need to be fixed / swapped and put back online as quickly as possible (e.g. video surveillance equipment).

The nightmare scenario is when the OT network gets compromised, as this has a direct impact on the business. OT networks will often include highly specific equipment, which makes them less susceptible to generic attacks but more interesting for targeted ones (e.g. Stuxnet). Dealing with this type of breach is difficult because:

  • Detection is non-trivial in case of targeted attacks as the IOCs are generally not available and behavioral triggers are very specific to the OT devices in use
  • When detected, targeted attacks require custom reverse-engineering of the exploit and its payload in order to be able to devise proper remediation actions
  • If the exploited vulnerabilities are new (i.e. 0-day), there will be no security update available. The vendor will have to be involved in order to understand the exploitation path and the underlying vulnerabilities in order to build a security patch.
  • The “if it ain’t broke don’t fix it” motto unfortunately still very much applies in the OT world. The people in charge will be reluctant to make changes to the system. The attack would often need to be a significant threat to the business to justify upgrading or changing devices.

Incident response needs to be properly planned and drilled during peace time. During war time (i.e. post-breach), people tend to panic and take wrong decisions based on inaccurate or incomplete data. Having a checklist and a script to go through will help those who don’t experience this kind of situation on a regular basis.

Taking Some Distance

Once an incident is solved, the one question that we often get is: can I trust my network again? Well, one should never trust their network. It is almost impossible to assert that a network is 100% clean. Companies on average take months to detect breaches and solving one incident is no guarantee that the network is trustworthy. Defense in depth, advanced detection mechanisms and rapid response are the main keys to stay on top of the security cat & mouse game.

Device manufacturers who care about security will have embedded mechanisms to prevent known types of attacks, to help detect odd behaviors, to report failures, to allow for rapid reaction to breaches and to provide renewable security. These manufacturers will also have dedicated security teams that will provide stellar service when threats arise.

As a CISO, it is best to stop the bleeding before taking care of the wounds. One great place to start is procurement. New devices being purchased need to go through a security evaluation that will ensure they are sound security-wise on day one and that they will be manageable in the long run. Then it is a matter of dealing with the current threats until the future gets brighter.

Joël Conus

Joël Conus

Vice President of Innovation & Labs at Kudelski Security
As Vice President of Innovation & Labs at Kudelski Security, Joël Conus leads Advanced Security Labs and Rapid Prototyping. With more than 17 years working within the Kudelski Group. Joël has held leadership positions in pay-TV anti-piracy, cyber intelligence, security operations and engineering. Notable accomplishments include several patents. He received his Master’s in Computer Science from Ecole Polytechnique Fédérale de Lausanne in Switzerland and is also a Certified Information Systems Security Professional.
Joël Conus