When one cyberattack becomes a thousand: Protecting the IoT

February 1, 2015 OpenSystems Media

It sounds like a scenario out of a science fiction thriller – in the far future, everything from traffic lights and rail switches to pacemakers and hospital monitors is connected, leading to an improved quality of life but putting every day citizens on the front lines of computer security. Not only are these devices connected, they are actively talking to each other – in fact, many are downright chatty! Instead of just stealing patient medical data or customer credit card data, security breaches and hacker attacks can cause widespread devastation, from traffic accidents to turning off critical medical devices. Scary, right? Now imagine that this connected future isn't really that far off, thanks to the emergence of the Internet of Things (IoT), which means that security of smart devices is front and center today.

An IoT implementation is essentially a composite, distributed solution, meaning that it's a set of applications deployed across several physical and logical servers. When you consider how this complexity interacts with security concerns, you begin to understand why security issues can very well end up limiting what enterprises get out of the IoT. Like any distributed solution, every environment and application has its own security requirements. Added to this is the challenge of securing the solution as a whole and addressing the issues resulting from its scale and the high degree of connectivity, which massively increases the attack surface and raises the stakes of what's at risk.

There are two things that characterize today's enterprise IoT solution: the data that's flowing through the system and the degree to which devices and the data center connect and communicate to each other. Systems composed of devices relaying information to the data center and operational applications have been with us for decades, but today's difference lies in how these devices function. Where in earlier examples devices typically were passive data collectors, they now can operate in their environment based on data that they've collected or that has been relayed to them from the data center. It's essentially the difference between a thermometer that reads temperatures, passing that data along without acting on it, and a thermostat that's part of a smart energy solution that can change a home's heat, not only in response to local readings but based on readings from thousands of other thermostats aggregated into an energy utilization grid. By virtue of the device being connected to applications controlling energy infrastructure, however, it poses far more risk than when it was a passive data collector that could impact only a single home.

In the thermostat scenario, the likely goal of an attack would be to manipulate some aspect of the energy grid by gaining access to the operational applications. In other scenarios, the target of an attack could be the data itself. For example, devices used in financial transactions or health care carry personal data protected by privacy regulations. The data flowing through an IoT implementation must be protected both when it is "at rest" on a device or gateway and when "in-flight" during transmission among various tiers of the distributed architecture. This sheds light on the three security areas of the utmost importance to the IoT:

  • Hardening devices
  • Protecting data
  • Securing connections

Hardening the device

Volumes can be written about protecting the physical device from tampering, vandalism, and the elements. Securing the software on the device, however, is equally important as it serves as the entry point into the enterprise system, the area where maximum damage can be done. Hardening the device software is a matter of protecting the data and the environment in which the applications on disk operate. One recommended approach is to use disk encryption and install a highly secure operating system. The disk encryption protects the data itself while the security policies enforced at the operating-system level will help ensure that applications are accessed only by privileged processes. Both layers of security are required to make sure that the device software cannot be compromised.

Deploying secure devices into the field is one thing – maintaining their security is another. Keeping the device software as secure as possible requires applying security patches as they become available, a very different approach to how most embedded devices are treated today. The "dumber" the device (the less functionality and lower cost it has), the greater the tendency to ignore it until it's time to replace it. The sheer scale of an IoT deployment that can include tens of thousands of devices makes maintaining security a daunting proposition, but if the devices can be the entry point for an attack on enterprise systems, you must include the ability to deliver patches to devices as part of your security strategy.

In highly regulated industries, managing patch delivery and security maintenance comes with an auditing requirement. In which case, you not only have to apply patches to thousands of devices, but you must be able to document and confirm that you took the appropriate steps to secure the devices. Include a management tool (or set of tools) as a project requirement to be able to efficiently push updates out to thousands of devices and report on the state of each device in terms of applied security patches and other software changes.

Securing the communications

It's not just the devices that are vulnerable to attack. One common method cybercriminals use is hijacking data midstream. Here again, you can apply security at various layers. You can encrypt the data, use secure networking protocols such as Transport Layer Security (TLS) running on a LAN/WAN and use VPN to further connect LANs over a WAN instead of relying on the Internet. Running a private network infrastructure over dedicated fibre rather than communicating over the Internet is a far more secure scenario, though an expensive one. Clearly, the cost and overhead of these methods has to be weighed against the risk.

There is another way to intercept device communications – posing as a trusted entity. It is essential that any inbound or outbound communication is verified as coming from or going to a trusted device or server, typically using authentication keys or certificates. Domain managers such as Microsoft Active Directory or the FreeIPA (identity, policy, and authentication) controller in Linux provide this level of security for applications and users and can be extended to manage security for IoT devices and processes.

Protecting the Data

Data encryption has been mentioned in terms of hardening the device by encrypting data written to disk and in terms of securing the communications among components. There has traditionally been performance cost to data encryption, which is probably the reason why enterprises have taken shortcuts in this area – with dire consequences as breaches at Home Depot and Target have recently showcased. However, recent processors include dedicated hardware instructions for crypto acceleration, making encryption much more feasible. Encryption need not be an all-or-nothing approach. Understanding the data that is being collected and transmitted in an IoT system and knowing what the security requirements are for protecting the data at rest and in flight are key to designing a pragmatic security architecture. As a rule of thumb, if data is valuable – either direct economic value or cost if it is exposed – it is worth the cost of encrypting it.

Not all data needs the same degree of protection. Sensor readings that have no real meaning without context or where little damage can be done if these are hijacked or compromised probably don't have to be encrypted, or you could implement a simpler solution like using a single crypto key for all devices. This makes the devices easier to deal with while providing some protection.

Save the encryption for data that must be protected due to its value, the potential exposure a leak could affect, or damage caused by tampering with a data stream. To go back to the home heating example, stealing or jumbling a home's temperature readings is low impact while intercepting and manipulating temperature data that controls a biomedical lab's HVAC system might result in significant damage.

The same approach to measuring risk and impact will guide decisions about how much protection is needed for data at rest, that is data written to disk on a device or server, and how much is needed when data moves between components. In some instances, encryption is not enough so data is transmitted in ways that context is difficult to reconstruct if some of the packets are intercepted. For example, one can separate credit card numbers from identifying information and send them in different transmissions. Some organizations use algorithms for "jumbling" and re-assembling data streams in addition to encryption.

First steps

Is security for the IoT complex? Yes, because the attack surface is huge, the risk can be very high, and the consequences severe. The good news is that the tools at your disposal are familiar to most IT organizations and well proven. The challenging part is providing the right level of security at each device, gateway, or server and then surveying all the connection points, assessing the risk posed at each one, and choosing the best-suited protection method (Table 1).

Table 1: Guidelines for securing an Internet of Things solution.

Ken McLaurin is Senior Manager, Product Strategy at Red Hat Inc.

Red Hat Inc. www.redhat.com @RedHatNews linkedin.com/company/red-hat plus.google.com/+RedHat youtube.com/user/RedHatVideos

Ken McLaurin (Red Hat Inc.)
Previous Article
Leveraging automotive development standards to mitigate risk, part 2

ISO 26262, MISRA, and other standards seek to normalize software development for automotive applications by...

Next Article
A fantastic adventure into programming

Simple coding projects and DIY/maker boards can be a fun, practical way to introduce the art and science of...


Stay updated on security-related design topics with the security edition of our Embedded Daily newsletter.

Subscribed! Look for 1st copy soon.
Error - something went wrong!