IoT Security Foundation Conference
The inaugural IoT Security Foundation Conference was held Tuesday at the Royal Society in London. The conference opened with an introduction to the Foundation's history and mission (and an invitation to join). The IoT Security Foundation, an international, collaborative, vendor-neutral, not-for-profit organization, "aspires to be the expert resource for sharing knowledge, best practice, and advice." The Foundation's mission is "to make the Internet of Things secure, to aid its adoption and maximize its benefits," in short, "make it safe to connect." Security of Internet-of-things (IoT) deployment was the conference's focus. The motivation for that focus was clear: raise the general standard of industry practice.
There's a lot of hype surrounding the IoT, and much of that hype surrounds its potential as opposed to its security. The effects of that focus, the introduction noted, may be seen in the sort of hasty design decisions that have hardly conduced to security: many devices re-use the same server-side HTTPS, certificates may be fixed into firmware, the same SSH login credentials are reused, and so on.
The IoT is many things, not one big thing. Recall Archilochus's epigram: "the fox knows many things; the hedgehog knows one big thing." IoT security is a family of problems that calls for foxy solutions.
IoT security, the big picture: threats and opportunities.
The first session featured speakers who presented an overview of the challenges the IoT presents.
A national perspective on IoT security: "IoT Security — The Policy Perspective."
Jessica Rushworth (Director, Government Engagement and Policy at Digital Catapult, a UK government-funded private company) shared her insights into the interests and concerns shaping IoT security policy.
She noted that the UK government had fifteen years' experience sharing data from the IoT. Such policy as has evolved is about managing risk. There's no IoT security policy, but there are cyber and IoT policies, and these do intersect. IoTUK, which launched in September of this year, represents a real attempt to implement security by design.
But efforts along these lines go back some years. Rushworth described some recent history.
The 2011 National Cyber Security Programme focused on cyber's impact on defense, critical infrastructure, and the economy. It included guidance for large and small companies, and it came with an investment of £860 million. By 2015, she noted, this investment had essentially doubled to £1.9 billion.
But the IoT is a new area, and a very broad one, and so policy will necessarily be both complex and mutable. Policy makers and others concerned with the sector recognize a need to focus on the system level, such as smart cities and national health infrastructure, as opposed to just the consumer level (like the Internet-enabled refrigerators that seem to have achieved folkloric status).
"There is a danger of trivialising the importance of the Internet of Things through examples that are used to stereotype it," IoTUK warns in a report, "for example, the 'fridge that orders fresh milk.' The Internet of Things has the potential to have a greater impact on society than the first digital revolution."
In March of 2014, at the CeBIT conference, British Prime Minister Cameron and German Chancellor Merkel developed ten recommendations for policy makers. The third of these is particularly noteworthy: "Government departments should be prepared to take appropriate risk by supporting demonstrator projects. These must be scalable and security should be an integral part of their design."
One response to that recommendation has been the formation of IoTUK, a national program with funding of £40 million intended to advance the UK's IoT capability. Its initiatives include the Research Hub, City Demonstrator and Incubator, and Health Care Test Beds (NHS England). Since, Rushworth said, "IoT matters to the extent that you can do interesting things with it," IoTUK seeks to spur work on interesting things. £10 million has gone to each of these three initiatives, with appropriate competition for pilot project grants.
We need, Rushworth stressed, privacy and security-by-design. Academic research supported by IoTUK will focus on delivering privacy and promoting trust in IoT security. Digital Catapult's role includes advising companies on how to design in IoT privacy and safety.
Gartner has said that half of all IoT solutions can be expected to originate in start-ups less than three years old. Rushworth closed with this advice. Businesses need to plan for success. They should cultivate security thinking from the outset, always thinking about securing devices and data.
What's in store for the Internet-of-things in 2016.
Paul Egan, IoTUK Principal Consultant, shared his predictions for the Internet-of-Things in 2016. Counting back from five, these were his top forecasts, as presented in a recent IoTUK blog post:
Fifth: Software. In the platform space, expect consolidation and failure as the number of platforms increases. Currently, the customer spend on these services is very small in comparison to the number of products in the market. Some of the players will simply run out of money, some will fail to prove their business model, and some will be acquired as a defensive strategy by enterprises that can't, don't, or won't develop these capabilities in-house.
Fourth: Investment. Starting from a staggeringly low base, venture capitalists will start to look more favourably on IoT hardware startups as an alternative to the ‘unicorn hunt’ in the software/platform space. Expect acquisitions of some leaders and the fading of some rising stars as those without a viable, scalable business model run out of steam.
Third: Consumer. A number of well-known global brands are preparing to launch an IoT "killer app" or device. We might not recognise it when we see it but by the end of the 2016 many will point to this “thing” as their definition of IoT.
Second: Networks. 2016 will be a make or break year for wireless network operators. The anticipated launch of narrowband IoT networks by global mobile operators will counter some of the momentum from low-power wide area network (LPWAN) players like Sigfox, NWave, Telensa and the LoRa Alliance. Expect LPWAN and short range connectivity technologies to overtake the number of cellular connections for IoT.
And finally at number one for 2016…
First: Security. Security will become the biggest single IoT subject, as well as its greatest opportunity for commercial success. It will also be the biggest risk for enterprise failure. Expect a very public and very large-scale hack of an IoT application or device. Think the Fiat-Jeep hack, but on a larger scale.
Connected devices: “Market Opportunities for Security in the IoT Market.”
Robin Duke-Woolley (CEO, Beecham Research) drew upon fifteen years of experience with end-to-end embedded development for the IoT.
He described the machine-to-machine (M2M) world of connected devices, in which he sees nine market sectors. In that world we see very little in common across solutions, even within the same sector. As a result of this lack of commonality, we see continuing growth in the number of IoT platforms: where there were fourteen application platforms in 2008, more than three hundred exist today. These, Duke-Woolley stressed, are completely separate, and so we see many silos today.
There are security issues but each M2M solution can be dealt with as its own case. However, in the IoT, data from different sectors can be, and indeed often must be, analyzed together. Thus securing the system globally across several silos becomes far more challenging. For example, the solution for fleet management will be different from that for car telematics. You would want to have those solutions cross-communicate in the IoT, but today there's no interoperability between them.
Showing an IoT threat map, he characterized the IoT as crossing many M2M solutions. "Many people just say 'IoT' when they mean M2M." But in the IoT, there will be internal interfaces, with their associated vulnerabilities. Interface proliferation will mean varying levels of security per sector, depending on their threat levels. How then do you respect those levels? Do you default to the highest? Do you do so dynamically across sectors?
If you could have a secure environment for IoT, you could then have more interesting services, as in a Smart City. There are of course large security concerns in energy and transportation, but if you succeed, then you can bring new value to "users of cities," both people and businesses. The IoT is also not going to be purely an urban phenomenon: smart farming will also benefit from the IoT.
It is not, he cautioned, inevitable that everything will be connected. We need to weigh the costs of connectivity versus its risks and benefits, and in this respect marketplace discussions currently remain unrealistic. External factors involving economics and uncertainty can cause (and historically have caused) the connected devices market to flatten periodically.
We need to recall ourselves to rationality: easily tossed about numbers like 20 billion connected devices in 2020 and trillions of new dollars in the market by 2025 are unrealistic—"just ridiculous." We can expect to see 20-30% growth in the M2M market, which will likely accelerate due to more types of connections being made. But current hype would mean more than 100% per year growth, "So this is not going to happen."
Initially, most IoT solutions are enterprise oriented. Motivations for adopting them include cost reduction, regulation, or new revenue opportunity. We can expect a move away from cost savings towards new service revenue opportunities. It will take time to implement those solutions and service models, and so "amazing growth" will be tempered by the time required to implement and roll out those models.
It's more likely, Duke-Woolley predicted, that we'd see connected devices in the low billions around 2020. That count wouldn't include more traditional endpoints like phones, laptops, tablets, and PCs: not devices controlled by an interactive user with screen, keyboard, and mouse. Interface proliferation will need to be tackled.
The coming challenge is to provide better security with fast growth. Transport and industrial sectors will see the most growth. He sees five key trends:
- Increasing interoperability.
- Closer integration with enterprise IT.
- More concern with optimizations of operations.
- Movement from monitoring to control, with an attendant need for more real-time data.
- Greater mission criticality for IoT/M2M solutions as they move from being tactically nice to have to being strategically necessary, with an increased use of data across sector boundaries.
Without IoT security, there will be no substantial market. We therefore shouldn't consider security a cost. Instead, it's an enabler of new market opportunities. The first of these opportunities with occur within sectors, across solutions (and security needs within sectors are different across solution), and then will spread across sectors.
Real-world case studies of IoT security breaches and how to avoid them in future.
The second session was devoted to case studies of particular IoT security challenges as they exist today.
Building secure applications for the Internet-of-things: "Snoopers charters? What is your IoT device up to in your home?"
Ken Munro (Director, Pen Test Partners) focused on those folkloric consumer devices we hear about when the IoT comes up. He sees simple vulnerabilities arising from failure to observe sound design practices like writing mobile applications securely, and obfuscating code to make reverse engineering difficult. "Sadly, this is not generally done today." His stories of vulnerability research into particular devices highlight both the complexity of the IoT and the simplicity of the many design miscues we find therein.
Here are some of the devices he and his associates have unpacked. First, consider the Internet-connected teakettle. Disassemble the device and find the Wi-Fi card, then download the manual. Look at the relevant Android app and turn it into a Java JAR file, and then look at it to find the default IP address. Read the manual to see that the password is the default from the vendor, and that the device supports Hayes AT modem command set. Recover the SSID; recover the PSK. Thus you can de-auth the kettle and man-in-the-middle the Wi-Fi, send the default password and recover the wireless password. The default password is not randomly set, and even when set it's just six digits and can be brute-forced.
Tea drinkers aren't the only ones at risk. Pen Test Partners has also hacked an Internet-enabled coffeemaker. The coffeemaker represents an improvement over the teakettle, but the mobile app drives the coffeemaker using a simple binary protocol that uses ASCII, UDP and TCP on port 2081. Reverse engineer and fuzz the ASCII protocol. Command J is AT+GMR; ESP8266 AT Command Set. The hackers had to correlate the ESP8266 to the ASCII protocol implemented by the vendor. Command 7 makes coffee, but Letter M produces denial-of-service in an endless firmware update loop. AT+CWSAP retrieves SSID; they're still looking to get the command for the pre-shared key.
The Cayla interactive doll is another case. This toy uses an unsecured bluetooth channel to talk to the doll. The mobile app helpfully has a SQL database of swear words, and will use a Wikipedia API to filter swear words, using HTTP. Locally stored content is not filtered. The vendor fix was to encrypt the database with a static database password in the client code, and this was not changed per user.
Samsung smart TV audio is sent to Nuance communications for voice to text. Both directions are plaintext, to Nuance and back to the TV. The vendor eventually encrypted traffic after the vulnerability was disclosed.
In a Samsung smart fridge they found that the helpful offer to synchronize your Gmail calendar with a screen on the refrigerator's door (thereby enabling to consult your schedule as you forage for leftovers) in fact can compromise your Gmail account. The Gmail password is not properly protected, and an attacker can recover it.
Hoover's smart oven uses "roll-their-own" encryption for local communication. Crash reports are public.
Munro closed with a more hopeful example: "Fitbit was good about working with security researchers." Pen Test Partners used debug ports on smart scale to discover that SSID was improperly handled, and the vendor worked quickly to patch the flaw.
The takeaway for designers is to use basic hygiene: use properly obfuscated code, don't use static credentials and keys, don't use plain text network communications, and pin SSL certificates.
Cybersecurity in healthcare and pharmaceuticals: "Security of the Medical Internet of Things."
Caroline Rivett (Director, Cyber Security and Privacy at KPMG) opened by asserting that health care and pharmaceuticals are lagging other industry sectors in cyber security. Patient confidentiality is of course very important, "but we need data availability and—even more so—integrity. Should information be changed in records, it could have severe negative impacts on patient health." The imperatives of availability and integrity introduce inevitable friction into attempts at improving security.
Medical technology includes wearables, implantables (like pace makers, insulin pumps, replacement bones or joints), injectables (that is, smart pills), and automation (surgical robots using telepresence, compounding devices, sensors on external systems such as inhalers).
Many Wi-Fi-enabled medical devices have poor design from a security standpoint, and in this they resemble the consumer market. Such lack of security, Rivett said, has been an inhibitor to adoption of IoT technology.
Major concerns include the fact that medical devices are an attack vector into hospital networks, potentially leading to loss or disclosure or patient records. Medical devices can also be suborned to cause possible damage to patients (consider, for example, the risk a compromised insulin pump or pacemaker poses to the user's health, or even life).
In the US, she said, the Food and Drug Administration (FDA) is making an effort to listen to security researchers. Security aspects of design of smart devices in the medical ecosystem and their testing have become a priority.
She recommended the familiar risk-management move of deciding what to protect in the medical IoT. She advocated standardization versus reinvention, and the use of open standards whenever possible. And finally, she called for close coordination among regulators and implementers.
Car hacking: “What I learned about IOT from hacking the Tesla Model S”
Marc Rogers (Cloudflare's Head of Infosec) took as his car-hacking lesson "the dissonance between a proliferation of simply designed devices and devices that will be deployed longer."
Tesla, he said at the outset, responded very professionally to responsible disclosure, and "the Tesla was designed much better than what you see in commercial IoT. The Tesla is a data center on wheels." It has three primary computers. Infotainment and drive-critical systems are well separated, with only the gateway connecting the LAN and CAN bus. The gateway limits what can be done on the CAN side, and it was, Rogers said, very time consuming to hack through to the CAN bus—some three months of effort.
Instrumentation Cluster was unremarkable. The 17-inch touch screen had lots of connections, with a MicroSD and SD card and SUB port and Ethernet. It had an old browser and an old webkit with lots of vulnerabilities. You could crash the browser but not gain execution due to memory layout (he said he wants to work on that more).
The USB gave debug access, but the bootloader was secured. An SD card in the system contains VPN keys used to access Tesla's cloud. The MMC card holds map data, with a shell script that runs as root to update the maps. Tesla, he thought, did a good job overall with OpenVPN, but the big takeaway is that researchers still found corner-cutting in implementation despite solid effort at good design. You need both.
Tesla turned off the X11 service in response to the researchers' analysis. Here are some of the other findings from their study.
Old package versions, Rogers noted, were used in the Ubuntu distribution. These now have vulnerabilities. A car can last up to twenty years, but you can't get updates after five years. "How do you update your car once a software vendor goes away?" There is a dedicated patch management system. The status command provided unauthenticated access, and the handshake URL was presented.
Tesla had noticed people using Ethernet, and so added a security measure (if you did not put a special UDP packet every 30 seconds, you would be moved to a different VLAN). But they used physical cabling to connect the Ethernet cable from the CIC to the IC, and connect via a switch to get extra ports to access.
The firmware file system was not encrypted. Researchers were able to download and decompress and analyze the firmware. (They found some fun firmware that prints "NI," from the Pythons' "Knights Who Say 'Ni'.")
Many weak passwords were found in the shadow password file, for root level accounts. Researchers were able to get root in the IC, and then on the CID due to a plaintext stored temporary password.
You can fairly easily get a security token for any car. They found SSID for Tesla Service, and can force cars to connect to a rogue Wi-Fi and honk their horn every time they drive past. By the end of the study researchers could power on and off, start, open and close the sunroof, lock and unlock doors, change the climate, and—inevitably—honk the horn.
None of this, Rogers stressed, should detract from the good job Tesla did overall. The lesson rather is that, even with a very solid effort at security, problems persisted. Tesla had a perimeter security model and needed more defense in depth. They had ARM TrustZone but didn't use it. Their protocols were not all authenticated or encrypted. You need to assume an attacker owns the network. Each component should be hardened independently, and one should assume the infotainment system will be hacked and design the rest of the system accordingly.
There are some significant pieces of good news. Tesla's given sound attention to graceful degradation. The handbrake activates at speeds below 7mph to stop the car in the event of a total system failure. If all computers die, you can steer the car and manually handbrake. You can safely stop the car.
Tesla's design also showed very good separation between infotainment and drive control.
The company responded positively to the research results, and hired a head of security to look at these problems as software problems as opposed to just an automotive recall problem. Rogers left the engagement with a very positive view of Tesla's approach to using responsible disclosures to fix problems.
"Security needs to be better than the weakest link in the chain for long-term unattended systems that provide physical access to unknown persons." That is, in systems like cars.
Making it safe to connect: exploring the solutions space.
The final session addressed solutions—where work on security is likely to have its biggest payoffs for the IoT.
Avoiding a slow-motion train wreck: "Delivering Trustworthy Products in IoT."
Simon Moore (CTO, Secure Thingz) quoted a 2014 report from the UK's Secret Intelligence Service: "The IoT is a slow-motion train wreck." If slow motion, perhaps avoidable, so how might we avert disaster? Assume, Moore said, that designers are not infallible, that systems will be compromised, and that systems must still be designed for recovery, update, and remediation. Some of the questions we need to answer include when to update, who's responsible for doing so, where does liability reside, what components are impacted, and who's trusted with this process?
Big Data and new services are fundamental to the value of IoT. We need trusted data from across systems, vendors, and regions, and such trust can only be achieved through a secure device framework.
Because protection of critical intellectual property is an issue, Moore said, Secure Thingz has a per-device firmware encryption scheme so the OEM knows how many devices have been programmed, and this helps combat the grey market in manufacturing.
Can you improve uptime and partial functionality when degraded? Can you monitor and manage a device before, during, and after an attack?
With respect to confidentiality, crypto accelerators are seeing greater adoption in the embedded market. This allows for a smaller code base that's more easily managed and audited. An integrated root-of-trust on devices allows for greater assurance (including constrained measurable boot and isolation of different sections of code). Crypto accelerators can also reduce power consumption.
There are intellectual property challenges in cryptography, he noted. Elliptic Curve Cryptography will continue to be covered by patents until early 2017.
Confidentiality derives from how we execute and manage keys. Entropy should be based on NIST 800-90 compliant true random number generator. Keys must be unique per device. Systems should be provisioned early and enabled for "crypto agility."
"Cryptography is not security," Moore said. "It is a tool, the tip of the iceberg." Confidentiality relies on a high-integrity platform because cryptography alone is insufficient. "Traditional embedded systems were islands with very narrow levels of connectivity," but systems in the IoT are naturally widely connected.
We need a verifiable root of trust: strong cryptographic identifiers, secure hardware isolations, and secure boot foundation for trusted software.
Availability is supported by isolation of system components, simplification of system components to aid testing and validation, monitoring and analysis of the system, cryptographic measurement of status, and finally by recovery and remediation. We need to isolate and replace compromised components, updating and managing systems over their full life cycle.
Consumers. Ecosystems. Sheep: “Mind the gaps: why we need new, truly open, multi-domain heterogeneous solutions.”
Tony King-Smith (Board Member at the prpl Foundation and EVP Marketing at Imagination Technologies) described the prpl Foundation as an open-source foundation created by Imagination. It concerns itself with open source around MIPS and other architectures so that solutions can be open. Imagination is an intellectual property company focused around MIPS.
Consumer IoT, King-Smith reminded the conference, is a mass market. Consumers need need confidence in the technology, and their expectations have been shifted by various markets: they now expect items to do more than they used to do—consider smart TV as an example. Because consumer IoT is a mass market, we must deliver security in a form consumers will accept.
But security isn't keeping up: people use systems that have been used by others (like payment systems, smart cards, streaming video), designers aren't recognizing proprietary hardware and software lock-ins, and box-level certification remains at odds with dynamic provisioning.
So this, King-Smith said, is where we must mind the gaps, gaps between what people think they need to secure and what in fact they need to secure. Co-processors may have shared memory spaces. High-security zones for some activities (like payment) are good, "but they're very CPU-centric in thinking." We need to think about the entire system, and we may in fact need multiple secure zones.
King-Smith advocates open source as opposed to proprietary approaches for OEMs. They created the prpl security PEG (PRPL engineering group) to establish a necessary neutral approach. Qualcomm, Broadcom, Ingenic, Imagination, BT, and Cavium are all participants. They want multi-domain security, enforced using hardware separation, heterogeneous (CPU, GPU, SoC fabric) with open APIs and HALs enabling operation on any SoC.
"This is a tall order." They're focusing on hardware virtualization, bringing it to embedded development platforms, putting virtualization in the GPUs and then in the communication units.
The home gateway router is a good example of the challenge. It needs separation for guest networks, IoT services, router, and LAN. A trusted hypervisor can initialize as part of a secure boot process, and it's possible to migrate to this approach in a cost effective way.
Security cannot, King-Smith stressed, be treated in isolation. There are three different worlds—devices, services (delivered from data centers), and applications. We need, in the IoT, to bring these worlds together.
The coming generation of edge devices will not be dumb and small, but complex. Here we need separation of functions, and this too must be cost effective.
"Protecting Critical Industrial Infrastructure Using Isolation Technology and Threat Intelligence."
Will Keegan (Technical Director, Software Security at Lynx Software Technologies) and David DuFour (Senior Director of Security Architecture, Webroot) held a conversation on critical infrastructure protection.
Keegan began by asserting that foundational security can consist of kernel integrity protection, configuration policy protection, and an application protection framework. He is not in favor of open-source because of its problems with respect to long-term maintenance. His company is the developer of LynxOS, a COTS separation kernel operating system.
Separation kernels provide limited kernel exposure and limit functionality (no drivers, I/O services, etc.). The kernel's real-time properties are important for interfacing with timing-based protocols. Separation kernels move functionality up to user space so that the hypervisor kernel can remain simple. Monolithic kernels have many APIs to access the kernel from user land, and access from user land can always be abused.
Describing himself as a "threat intelligence person," DuFour explained how he understands threat intelligence. He believes in machine learning, in moving security outside the OS and closer to the hardware. He does not believe current machine learning approaches can handle SCADA and Industrial IoT network anomaly detection.
Currently, we use honeypots and machine learning to gather threat data. Machine learning classifies languages of attack pages. So what can we do with threat intelligence in the IoT?
"So Who Owns the Security of the IoT?"
Paul Dorey (Royal Holloway, University of London and CSOconfidential) drew a cultural distinction between control system engineers (very disciplined with respect to design, measurement, and operation) and the IT community (less rigorous than the control system engineers in these respects). But the IT community has understood for some time that security was an issue, whereas control system engineers had not until recently done so.
In the IoT we have ecosystems as opposed to closed systems. Consider the Miller and Valasek Jeep hack. Who is responsible for the system of a Jeep on a Sprint Network being hacked via the CAN bus and V850 controller? Is it is manufacturer, the V850 designer, or the network carrier? The manufacturer sent a letter and a USB stick. The consumer became responsible for patching.
Contrast that with Windows 10, where you don't get a chance to decide when to patch. "End users are not good at patching." Dorey then offered questions and reflections on responsibility for security.
Is the service provider responsible? Smart TV has a bad surveillance characteristic, and manufacturers do not have a strong security or privacy ethic.
Or the chip manufacturer? The phone Provider? The Trusted Platform Module has existed for a long time. But just because you deploy a capability does not mean you utilize it.
So most of the IoT is neither designed nor deployed as secure. Security by design is surprisingly absent. Note how different this is from the realm of safety, which does tend to be designed in.
Can the hub moderate? Can it be a security service? Can it phone home for unpatched devices? Can it constrain network behavior? Why don't ISPs sell security services?
In the energy sector we see smart meters, and the smart grid has made progress on security standards.
Standards should include service levels, an example of which might be time to patch deployment from patch availability.
Dorey expressed a preference for engineering design for security and safety over Agile development. And he closed with the inevitable answer to his series of questions: "The entire supply chain is responsible for security."