w w w . a x w a y . c o m 1

White Paper

Top Ten Security Considerations for the Internet of Things- By Gunnar Peterson and Mark O’Neill

Gunnar Peterson, Acting Principal

of Arctec Group is a well known

industry advisor focused on providing

guidance – from a technology and

vendor-independent perspective –

to help improve business results.

He blogs (1raindrop.typepad.com)

and tweets (@oneraindrop) about

distributed systems, security, and

software that runs on them.

Mark O’Neill, Vice President of

Innovation at Axway, was founder and

CTO at Vordel, a leader of REST and

Web Services Security (acquired by

Axway in 2012). Mark is the author of

the book Web Services Security and

a contributing author of Hardening

Network Security. He provides

guidance on REST and Web Services

Security to Fortune 100 and Global

500 firms and is a frequent speaker

at key industry events such as the

RSA Security Conference and Oracle

OpenWorld.

The Internet of Things (IoT) is an industry megatrend that promises to open up new ways of doing business and communicating. The core difference between Internet of Things and previous computing revolutions is that in earlier transformations the human user has typically been the catalyst – we go to our PC to do some work; we go to the Web to research or to check email.

In the Internet of Things, the thing talks back.

Context always anchors considerations around security, and that goes double for IoT. The IoT use-cases that have appeared so far tend to be very domain-specific, a trend that looks set to continue. In this paper, we examine the top 10 security issues for IoT – along with suggested solutions – and then illuminate some of the issues in the context of two emerging domain-specific IoT scenarios: the Automotive industry and the Utility industry.

1. Protocol Proliferation

This is the Web, but not as we’ve known it. The myriad of IoT protocols makes the security architect’s job vastly more complicated than it is in the realm of simple web app security concerned primarily with HTTP.

Spoiler alert! The Internet of Things is a bit of a misnomer. The Internet is built on a consistent core that includes HTTP, HTML and Request/Response protocols. This relative simplicity enables security architects to layer-on security protocols – such as SSL – and be confident that they can deploy security services across any of their web applications through one protocol.

But the protocol landscape in Internet of Things is highly variegated. If the Internet’s menu of protocols is as straightforward as a McDonald’s menu, then the Internet of Things is more akin to a sprawling Middle Eastern bazaar with its cacophony of sights, sounds and

White Paper

w w w . a x w a y . c o m2

languages. There is HTTP to be sure (hence, the “Internet” of Things), but other protocols abound as well – such as CoAP, XMPP, AMQP and MQTT to name just a few.

Simply put, there is no one security protocol to rule them all, à la SSL.

Security architects must embrace this challenge and work to identify the right security protocol for each communication protocol. And often this means spanning protocols, rather than relying on any purely Web-based solution.

2. Initiation

IoT scenarios are potentially amazing, and can quickly enter the realm of science fiction. However, this paper is a “flying car”-free zone! We won’t project out too far beyond the emerging horizon; instead, we’ll focus on reviewing key security considerations around scenarios where the use-case catalyst is the object resource instead of the human user.

This may sound like we are slicing the salami too thin; but from a security perspective, a scenario wherein a human user is initiating action, versus a scenario in which connected objects are initiating action, is as different as night from day.

Just as security architects must embrace a wide array of security protocols in order to cover a range of IoT protocols, the well-worn Internet Request/Response model cannot be relied upon for all message exchange patterns. For a number of technical and logistical reasons, in an IoT landscape there are plenty of alternatives to the simple Request/Response. Granted, HTTP usually works with Request/Response; but in IoT, protocols can be initiated on the server side. As mentioned previously, CoAP, XMPP, AMQP, MQTT and other protocols may also be part of the mix; and each of these protocols in turn has its own specific message-exchange patterns – such as publish subscribe, request only, and request callback – in addition to the usual request/response pattern.

The security architect must map security protocols onto these communication protocols and their respective message-exchange patterns. For instance, which side of the “thingfrastructure” initiates the message exchange: the server side or the thing side? This may seem like a small matter, but the reason why it is not can be found in the next security consideration: access keys.

3. Access Keys

Many IoT devices currently in use rely on hard-coded access keys, leaving them vulnerable to brute force, spoofing and other types of attacks.

Key storage is problematic across all systems: Keys on the “thing side” allow for brute forcing and tampering; while key storage on the server side introduces distribution

Server Side Control

For most IoT systems, the server plays several roles. Just as with normal Internet systems, the server handles the presentation, logic and data-access chores; meanwhile the client is as thin as possible.

IoT servers, on the other hand, go a step further: They are typically charged with managing the client environment as well, including client registration, lifecycle management, patching and related tasks.

w w w . a x w a y . c o m 3

White Paper

and availability challenges. And while it’s impossible to predict all of the different communication protocols IoT implementations will require over the long haul, IoT systems will definitely need to solve authentication, integrity and in some cases confidentiality issues. Therefore, IoT will need a solid key management system.

Key management systems are responsible for managing the entire lifecycle of keys, including.

� Generating keys for use in the system � Distributing keys across the “thingfrastructure” � Revoking keys for session termination or end of life

What types of keys, how they are used, for what purpose (authentication, integrity, confidentiality), and how they are bound to the system, will vary from one system to the next.

4. Naming

The IT industry has gotten reasonably good at identifying human users, using Active Directory, LDAP and application user databases; but objects? Not so much. Consistent naming is the key to enforcing security policy.

What is equivalent of the LDAP or Active Directory for all the objects in the “thingfrastructure”? These de facto standards do not yet exist for IoT.

One of the principal jobs of directories or databases is to enforce naming. Names (in conjunction with keys) enable authentication and hence are a critical enabling factor for any IoT access-control scheme.

Every program must answer the question – who has access to do what? Name directories that enable assigning and managing the object’s rights, roles, and groups in a “thingfrastructure” are central to addressing questions around IoT access control

When implementing naming, extensibility is a must. Avoid approaches to naming that are locked into the paradigm of a human user. You may be naming an object, which does not fit into traditional LDAP or X.500 naming conventions.

5. Constrained Devices

Despite the challenges around IoT, we do have many security protocols to choose from. But deployments are often limited by the level of processing power available on the device side.

Enterprise computing is very used to thinking about scale in one direction only – up. But scalability cuts both ways. Scaling down can be just as, or even more problematic than scaling up. IoT system designers cannot architect based

White Paper

w w w . a x w a y . c o m4

on an assumption of the same level of processing power, storage or bandwidth characteristics of an enterprise-class network.

What this means to security architecture is that security protocols will have to be able to negotiate across a resource-constrained environment. Long story short: Say goodbye to verbose XML security tokens, and say hello to token-by-reference, backend attribute exchanges, and token resolution on the server side.

6. Time Services

Many IoT applications – such as NFC-enabled smart cards – do not encompass the concept of time. This lack may not seem like a security issue at first glance, until you realize that virtually all authentication protocols use time as a primary defense mechanism.

Authentication is always vulnerable to brute force; and one of the primary ways architects look to cope with this threat is by limiting retries. As anyone who has been locked out of their enterprise desktop knows, authentication requests can be throttled to minimize the number of retries in a given time window. But IoT-networked things cannot be assumed to have consistent, synchronized, or (as in the case of NFC smart cards) even any access to time services.

Lack of time services leaves the security architect facing sub-optimal tradeoffs. For example, do they not throttle retries through a time-based retry count, and thus be vulnerable to replay? Or do they enforce a retry and open up the possibility of locking device access?

Time affects more than just authentication. Logging systems are responsible for reporting who did what, and when. Without access to time services, logging systems may tag onto alternate ways to identify events, such as incrementing an event ID counter (a better option than authentication). This approach delivers the added benefit of being able to report on sequences.

Again, extensibility is a must here. Adding in sequences is possible only when your security solution is open to extension and not locked into a limited set of protocols.

7. Usability

Human users may not be able to reliably remember their password, but they are at least able to remember to call the help desk and have it re-set. In the Internet of Things, however, the entire usability surface is 180 degrees the other way – the subjects are not human users; instead they are usually things.

Consequently, the attack surface is different as well: In the world of human-browser interaction, social engineering is a security threat, through attempts to gain access by taking advantage of human behavior. In IoT, it is a different kind of engineering – reverse engineering – which is the threat. Devices may be disassembled in order to gain insight into their behavior and exploit them.

The Role of the Gateway

In this paper, we cover a number of situations in which a security gateway could be used to apply IoT security, effectively taking on the role of the server as far as the IoT client is aware. In this role, a gateway provides a point for enforcement of security policies, as well as for delivering patches and updates.

The gateway also plays the role of the traffic director by accepting requests from clients, in some cases pushing data to clients (such as for updates), and facilitating various protocols to work together.

w w w . a x w a y . c o m 5

White Paper

Will existing protocols such as Kerberos, X.509, Federation, OAuth, SAML and others be up to the challenge of securing the IoT? Or will we need to develop new protocols to account for usage dynamics that will differ from one machine-to-machine application to another?

IoT demands that security architects design for clients that may be entirely passive, unable to retry or reinitiate. A gateway can play the role of the server by acting as an intermediary; as far as the client is concerned, the gateway is the server. In this way, the gateway can perform security duties that the client is unable to perform.

8. Patching

You can’t predict where or when, but you can bet that vulnerabilities will be found in the “thingafrastructure”. The question is, how will you respond and how will those vulnerabilities be patched?

As with usability, we cannot assume a human is there to download and install patches, update extensions, and so on. Whether through pushing updates or virtual patching, the problem must be solved primarily on the server side. This scenario is another wherein the right gateway can help by acting as a server (as far as the client is concerned). In this role, the gateway can be the point at which patches are applied either virtually or by acting as a traffic director and initiating the download for clients.

9. Stunt Hacking

Hacking IoT is a great way to generate headlines – the more interesting the device, the more the attacker is interested – so you can be sure that there will be an endless flow of security research on this topic.

Time and attention from the hacking community is driven by two things – ability to monetize the results of the hack, and the intrinsically interesting nature of the hack itself. Over the long term, IoT will have to deal with both challenges.

In the near term, it’s reasonable to expect that every major hacking conference for many years to come will host a “Hacking the IoT” presentation. There are simply too many interesting targets in play for the hacker community to resist. And as IoT applications with economic utility are increasingly deployed (such as smart grid or NFC payments), they will surely attract interest from financially motivated attackers.

There are no technical solutions yet developed that can prevent hackers attempting an attack; so security architects deploying IoT systems should brace themselves for sustained attention from hackers, and prepare accordingly. IoT is not a place to assume you can fly under the radar. Many IoT systems will initially rely on “security by obscurity,” but this is not a safe or effective approach over the long haul.

Access Control

Access Control in the IoT must take into account the new landscape where the primary actors are not users, but rather objects. A new way of thinking about Attribute-Based Access Control (ABAC) is now required, in which attributes of users (if they are present) have to be understood alongside attributes of objects that are accessing resources.

White Paper

w w w . a x w a y . c o m6

10. Ugly Failure Modes

IoT apps touch real things in the physical world; so when they fail, so does your power, your supply chain, your fleet tracking capability, and so on. To make matters worse, retry and restart functions may be difficult to impossible to implement.

We’ve all encountered headlines about Internet security issues that impact real systems – like the 2010 “flash crash” that caused stock prices to drop precipitously. Granted, this event may have affected individual financial portfolios, but the problem centered on stock prices that exist virtually, and could be corrected.

Not so in the world of IoT, where water meters, cars, power systems and other physical objects are not so easily “corrected” when something goes wrong. The famous Ctrl-Alt-Del “three-finger salute” may not even be possible for many of the things that will connect across the “thingfrastructure” of an IoT future.

Building in the right kind of IoT security from the get-go means that security architects will be spending a lot of time in the leaf nodes of failure-mode decision trees. And it’s more critical than ever before that they clearly understand and anticipate the state of the system at the end of the failure mode – that is, the actual impact on the “thing” (is it operational, dead, fixable?) and the people who rely on it.

Case Study – Smart Meters for the Smart Home

IoT deployments are extremely context sensitive. There is no one use-case that captures all concerns related to IoT as a whole, which means that real-world case studies are especially valuable. Axway is currently assisting utility providers to build out new IT architectures that can deliver – in a controlled and secure manner – the application-to-application and machine-to-machine communication framework so critical to the success of an Internet of Things. Axway is working with both existing and new entrants to the energy delivery sector around the globe, driving innovation to help them develop smart-metering strategies that will enable them to deliver new value-add services and generate new revenue streams.

For example, First Utility in the UK now enables domestic and commercial consumers of energy utility services to access information about their energy consumption and billing via mobile devices. They can also view aggregated data collected from similar geo-located consumers so that they can compare their own usage patterns to that of others.

In the Netherlands, Essent – one of Europe’s top 5 power utility providers – uses Axway technology to deliver 24x7 multi-channel customer support service via the Internet and across mobile devices. Via a public API, Essent is exposing data about electric car refuelling points to third party developers, who are then creating mash-ups for drivers seeking a recharging location.

Object Repository

Enabling IoT requires mapping “things” to

policies. Currently there is no standard for

this mapping, but eventually a standard

must be evolved. Extensibility of the object

repository is also critical in order to scale

deployments over time. One worst-case

scenario would be to have a “catastrophic

success” – that is, a situation where a

deployment goes live successfully without

authoritative naming sources, and then

becomes wholly unmanageable due to lack

of policy and governance.

w w w . a x w a y . c o m 7

White Paper

Below is a typical example of what an IoT deployment would look like. This list includes elements relevant to the system administrator and architects operating on the Utility side, and also to the residential consumer of the utility service:

� Core IoT Smart Meter provided by the electricity utility: - Smart Meter in the home - API gateway to layer-on security - Backend internal systems at the utility

� End-User components - Home Wifi - Mobile app interface

This deployment illustrates a couple of key points about many IoT deployments; namely, that the system must encompass different components, different tech stacks, and formal and informal management regimes.

The diagram highlights the importance of the API gateway. The API gateway is the “glue layer” that plays traffic cop to route traffic, deliver messages and enforce policies. Since the system is comprised of different technical spokes, the API gateway forms the hub that ensures that the chain of responsibilities in the use case proceed according to security policy. Therefore, the lights stay on.

As you can see in the diagram, the API gateway also provides the data that feeds mobile apps to show the customer their electricity usage, historically and in real time.

Internal SystemsAPI

Gateway

Internet

Meter

Home Wifi

1. Smart Meter sends data to utility over home wifi connection

2. Mobile app consumes usage data via Web APIs

White Paper

w w w . a x w a y . c o m8

Case Study – Connected Car

The “Connected Car” is an evolution of vehicle telematics which enables a car to become a mobile computing platform, and in fact a “mobile data center.” With the evolution of automobile APIs and developer ecosystems around car communities, new opportunities to deliver content, services and real-time value to car drivers and passengers will also emerge for third-party providers. For many people, automobiles are central to their identity, and that means the car will play a very important role for us in the Internet of Things. Our cars won’t replace our laptops, mobile phones or connected homes, but they will augment them, enabling us to roam an increasingly Internet-connected world of objects via an online identity we authorize our vehicles to use to represent us.

In most Connected Car implementations, sensors in the car transmit data back to a server, using protocols not limited to HTTP/SSL (MQTT is often used). The data may be used for fleet management, such as ensuring that drivers are not in danger of being asleep at the wheel. The data may also be used to provide drivers with information about their cars, such as tire pressure, maintenance information and oil levels.

As shown on the diagram below, the same API gateway used to terminate the Connected Car IoT data may also be used as the backend for mobile apps to provide vehicle information to the user. In this way, the API gateway acts as the “pivot point” for data from the car to the user.

Security is paramount in this use case, since the Connected Car generally has APIs for remote unlocking and other “remote control” functionality.

Axway is working closely to drive IoT innovation across multiple sectors for leading global businesses related to the automotive industry. For example, Axway technology enables one of North America’s leading logistics firms to remotely monitor its large fleets to ensure that its drivers are not driving for longer periods of time than are permitted. In the U.S., Axway has helped Agero – the leading provider of roadside assistance and claims management services – build a complete, turnkey solution for connecting the vehicle to the digital highway. This solution allows Agero’s automotive and insurance clients to put connectivity and advanced technology services at the fingertips of their end consumers – the drivers. Through embedded technologies, timely alerts and automatic notifications, Agero can facilitate a real-time digital conversation between the vehicle, the driver and the insurers, including services like:

� Automated Diagnostic Trouble Code Notification � Green Driver � Maintenance Alert Notification � Owner’s Manual via Voice � Quality Feedback � Recall Advisor � Scheduled Vehicle Diagnostics

Monitoring

The absence of human users means an IoT system must have improved telemetry to monitor usage, availability and security on an ongoing basis, in real time. ”Things” cannot always reliably report on themselves; the right gateway will fill this role, directing traffic across the “thingfrastructure” and providing clear reporting on events in the system.

w w w . a x w a y . c o m 9

White Paper

Conclusion

Clearly, the promise of the IoT is beginning to emerge, and will increasingly become part of our daily lives. As discussed, this evolution comes with numerous security challenges that go beyond Web security issues of the past. These security issues can and must be mitigated if the IoT is to deliver on its promise of networked objects. To fulfil this promise, the “thingfrastructure” that enables IoT must be deployed using an API gateway that enables enterprises to layer-on the necessary security.

Internal SystemsAPI

Gateway

Mobile Apps

Internet

Sensor

For More Information, visit www.axway.comCopyright © Axway 2015. All rights reserved.

WP_TOP_10_SECURITY_INTERNET_OF_THINGS_EN_AXW_070915