IoT Security: How Concerned Should You Really Be? -- ADTmag

IoT Security: How Concerned Should You Really Be?

An in-depth look at the top four Internet of Things (IoT) or Internet of Everything (IoE) security issues for developers, and how seriously each should be taken.

By Ian Murphy
November 24, 2014

The explosion of devices all connected to the Internet, which is what the Internet of Things (IoT) and the Internet of Everything (IoE) promises, is going to cause some interesting and non-trivial security issues. Or is it?

Security often raises a mix bag of emotions for those within the development community, ranging from wariness (bad) to weariness (worse) given the volume of breaches attributed to coding and scripting errors easy to guard against. As the security threat landscape broadens with the explosion of Internet connected devices, security becomes indispensable.

In this article I will take four things I hear talked about regularly when IoT or IoE comes up. They are far from an exhaustive set of issues, but they are representative of many of the challenges involved, especially in terms of security and where it will be applied. Developers and development teams looking to the Internet of Things will need to recognise and understand the security challenges if they are not to fall at the first hurdle.

Issue 1: IT Security Is Overstretched Already
True. IT Security is under more pressure than at any time in its history. External attacks such as malware, phishing, Distributed Denial of Service (DDoS) are just part of the problem. Old software once considered safe is increasingly being shown to have fundamental flaws which cannot be easily fixed.

Other threats include the rise of Bring Your Own Device (BYOD) with users bringing insecure devices into the enterprise and attaching them to the network. These devices can be easily infected outside the enterprise and once attached to the network, without a proper set of controls which small to mid-sized enterprises often don't have, can easily inject malware into the enterprise.

Cloud computing which is providing a lot of benefit to the enterprise is also being used by cyber criminals to host their malware, steal data and help them build large networks to crack encryption. The rise of the nation state as a cyber-threat is also a serious worry as they have unlimited budget, can have exceptional security skills and are capable of designing complex attacks such as Advanced Persistent Threats (APTs), which means that they are more of a risk than organised crime.

All of this comes at a time when budgets are getting repeatedly cut and regulators are looking to increase the controls on what can be done with data. The result is an IT Security function that for most organisations is in disarray and without the right tools and guidance will be incapable of dealing with what is facing it.

Issue 2: Are White and Brown Goods a Problem for the Enterprise?
Quite possibly. Connected televisions have been with us for a while as have Internet enabled satellite and cable TV boxes, DVD players, HiFi systems and fridges. The next wave of connectivity will include freezers, washing machines, dish washers and most objects you see around the house.

Inside enterprises there are often fridges, TVs and dish washers in break rooms and on every floor. Those very large companies that operate a campus mentality are likely to have large numbers of these devices along with games consoles and other externally connected devices and each purchasing cycle adds more. These devices arrive with no security set on them and it takes very little effort for an interested employee to connect them to the corporate network.

These devices are often connected for good reason. For example, sending service data back to the manufacturer so that an engineer can be onsite before a device fails or as soon after a failure occurs as is possible. This remote engineering and monitoring process is used by companies to control parts of their business and IT estate as well as by printer manufacturers. As a result, it is seen as a perfectly valid and trustworthy mechanism by many. That said, it does raise the questions as to what devices should be connected to the main corporate network and what might be best assigned to a specific network for monitoring purposes by authorised third parties.

Unfortunately there is little to no security on these devices. If connected through the corporate network such devices can be used as an open conduit by attackers to target businesses. What we are seeing here is a repeat of the early days of Wi-Fi routers where there was no default security or controls. It took over a decade to get manufacturers to lock these down and for providers to send them with security already preconfigured.

In the white and brown goods market the bill of materials is so tight that there is no budget for making them secure. Take a fridge for example. Talk to engineers at the large manufacturers in Europe and the Far East and privately they will talk about their security budget being in the order of just a few dollars. Even with the economies of scale that they can achieve by spreading a solution across multiple device ranges, this does not amount to much in terms of R&D or even buying in and licensing a solution. Now think about this issue replicated across many other types of physical devices that won't also benefit from the necessary security investments and you begin to get a glimpse of the holes ready for exploitation.

A simple solution (as we highlight earlier) is to create a separate network to which these devices can be attached. It does not need access to core network services or enterprise systems. It is analogous to a guest network but instead of being open and with no password, there should still be a process by which IT authorises and manages the connections as future functionality may lead to these devices being taken over by attackers.

We have already seen stories of Internet connected fridges being used to send spam and this is just one possible attack. In the case of a dishwasher or washing machine, an attacker could cause a flood in the home or the office. For fridges and freezers they could raise the temperature making food spoil quickly. They could disable security and fire alarms to prevent emergency services responding to an incident.

A better solution would be for governments to use the extensive legislation that covers white and brown goods to insist on security if they can be connected to the Internet. This is starting to happen with discussions already taking place with the European Commission and other bodies. In the US, the Federal Trade Commission is all too aware of the problem of poor device security. Last year, manufacturers of baby alarms were instructed to make them secure to stop criminals using them being used to spy on homes. Ahead of the regulations it behoves the development teams to think about the potential security risks and protect accordingly.

Issue 3: Industrial Sensors Cannot Be Made Secure
True and False. One of the big targets for discussions around IoT/IoE is the ability to connect the billions of remote sensors that already exist. For example, a chemical plant will have hundreds of sensors in an area the size of a football pitch. Many of these use existing System Control and Data Acquisition (SCADA) systems to communicate with control rooms.

It is true that many older systems are poorly coded from a security perspective. Where those systems are connected to critical infrastructure, companies are being pressured to replace them with more secure systems. This will take time, perhaps decades, as there are so many devices out there but it is worth taking a step back to understand how they will be connected and the risk they pose.

One of the reasons for connecting these sensors is to get better information as to how a plant or system is working. Proponents of IoT/IoE believe that gathering that data directly into the data analytics systems will improve safety and provide new ways of improving processes. Anyone with experiences in computer aided advance control applications like those that might be used to overlay advance control algothrims on valves and instruments in a chemical processing plant will already have seen examples of this working to good effect -- especially within existing telematic control systems. Of course, not all systems will benefit from this approach because it will depend on the sensors, their data, how easy it is to import the data and what can be gleaned from that data.

Many sensors within the industrial world will be used in a data gathering mode only. There will be no remote control capability where commands can be sent back down the line to reset a physical device such as a control valve. Today, that data is already aggregated into hubs and that could be integrated into corporate systems if required. This would certainly allow better real-time analysis of the data leading to greater control.

However, the data is not encrypted between the remote device and the hub and offers a potential for false data to be transmitted if hacked. This could lead operators to take a set of wrong decisions. However, outside of a sensor or connection malfunction many of these systems have various fail safes that would require multiple points of attack with bad data to create a problem.

The bigger risks are the two-way command and control systems. Where those systems are not using encrypted command sets and if they are attached to the Internet there is a clear risk. The US regularly publishes an abstracted set of data on insecure public facing systems that are connected to critical infrastructure.

There are of course ways of getting around such vulnerabilities. In both of these cases of data gathering sensors and those enabling two-way remote control, older hardware has limited memory and processing capability that would allow encryption. For data gathering devices, security updates would occur at the hub point. Where the devices have remote execution and control capabilities, there is a need to look at how they can be better secured and this might mean installing a new generation of devices or ensuring that the connection between them and the hub is a closed system. This would mean that the hub, once again, becomes the point at which the new security is introduced. Two problems: one solution. The fundamental point is once again, security considerations requires a higher architectural strategy and a risk based governance policy that dictates what remains in a closed network system and what gets connected to either the Internet or any corporate network.

Issue 4: Connected Cars Are a Hacker's Dream
True to a limited extent. Over the last three years, there have been a number of proven hacks on the computer and control systems in cars. It is a subject that the industry likes to avoid and is rarely willing to comment on. Examples such as the ability to take control of the brake and accelerator by wirelessly hacking into the tyre pressure sensor are seen as limited, but demonstrate future potential.

A fully automated car is going to consist of hundreds of systems. Some systems will be in a controlled hierarchy based on function, some will be safety critical and others will be open to third-parties. For example, a good case of the latter is the number of people already delivering SatNav and entertainment systems to the automotive industry. So far, there have been no proven attacks against this part of the supply chain although as it matures into a greater business that may change.

One way that it could change is as people connect to their home computers to download content, they open up the risk of malware being installed. This is where the automotive industry must develop highly segregated systems that limit what can be downloaded or inspects and checks the downloads. There is no doubt that this will be unpopular with some if it creates walled gardens such as Apple's App Store. However, the potential safety risk should mean that manufacturers will have a defence if questioned by competition regulators.

Another issue would be to adopt the container approach currently being promoted by Open Source company Docker and its peers. This would allow companies to develop self-contained, sand-boxed applications that could be downloaded into a vehicle. This would not only benefit entertainment providers but also those delivering other systems inside a vehicle. It would also provide manufacturers with a standardised approach to the management of applications and enable them to develop application stores that could be open to after-market vendors developing new systems for cars.

One challenge here will be what language to use in the development and the amount of memory available to developers. There is a strong history in recent years of embedded system design by chip manufacturers involved in the automotive industry. The regulatory requirements on the chip vendors to support their product for several decades does mean that developers who invest in the skills required to do bare-metal coding will see payback over time.

With chip vendor ARM looking to challenge the dominance of incumbents such as Infineon, this promises to open up the market to support common languages which will speed up access for developers.

However, the biggest challenge of all is still in how the car manufacturers develop their own security standards. One project that could help here is the European Union funded Critical Systems Engineering Acceleration (Crystal) project www.crystal-artemis.eu. This is designed to look at interoperability between systems with safety a key part of its design. Even with that, the industry will have to do much more than at present to develop, promote and certify any software running inside a car. This is not an inconsequential problem. Unlike business and consumer computer systems that generally have a lifespan of up to a decade or more, cars have a much longer lifespan.

Cars are also maintained by many people outside of the dealer networks and current anti-competition laws in many countries require manufacturers to work with third party garages to help them maintain vehicles. This means that the number of people with detailed information on the attack surface of a connected car is going to be very large and the larger the number of people, the harder it will be to make it secure.

The Bottom Line on IoT/IoE Security
I set out to look at four things that get raised whenever I talk about IoT/IoE with people. There are many other things that I could have looked at such as healthcare, wearables, transport and critical infrastructure. However, the challenges highlighted here are just as valid for those areas as they are for those I've chosen.

The bottom line is that the security of IoT/IoE will depend on the business and how it approaches the challenge. Today, it is possible to secure an enterprise against the vast majority of attacks without making it unusable for the workforce. To do so requires investment, skills, training, tools, processes and the right guidance services to be in place. Many companies struggle in more than one area, but that does not mean that IT systems are all flawed.

The same will be true of IoT/IoE as we go forward. Some people will swap out some of their SCADA systems and replace critical solutions with new solutions that have built-in encryption and secure interfaces and others will get by with what they have. White and brown good vendors will only add serious security when to do so is mandated or if they can justify increasing the bill of materials and pass that cost to customers.

The complexity of a connected car equals and even exceeds the complexity of most small and mid-sized enterprises. The lessons from how the car industry approaches the split between safety critical, control and general purpose systems such as entertainment will be useful to a lot of companies in developing their own security strategies for IoT based systems. The only drawback is that it will be a journey that may see some twist and turns since the connected car as currently marketed is not yet mainstream.

As for developers and development teams IoT and IoE are simply just another opportunity. There will be new languages, new security challenges and new tools to learn, but those who invest in writing quality code with the support of the right tooling and practices that can meet the security challenges of different vertical markets will most certainly recoup their investment.