The growth of interconnected devices is immense where published reports estimate by 2020, there will be well over 50 billion devices in use globally. What will be more profound is that the continued exponential growth will far exceed that estimate into the foreseeable future. How big will that figure be is anyone’s guess at the moment with the insatiable appetite to put all things connected to the internet. Without any question information security and privacy has become a significant challenge and is rapidly becoming so complex, that securing these devices may seem insurmountable with the attack surface footprint becoming infinite in size.
“Internet of Targets” Security Dilemma
The IoT opens a completely new aspect to security where the Internet meets the physical world. This has some serious implications on security as the attack threat moves from manipulating and exfiltrate information to controlling actuation – it is moving from the digital to the physical world. Consequently, it infinitely expands the attack surface from known threats and known devices, to additional security threats of new devices, protocols, and workflows. Many operational systems are moving from closed systems (e.g., SCADA, Modbus, CIP) into IP-based systems which further expands the attack surface. The IoT can be affected by various categories of security threats including the following:
- Cyber terrorism: Nuclear plants (For example, Stuxnet virus), electrical grids, traffic monitoring, railways, airports/aircraft and all critical infrastructures.
- “Script kiddies” or others targeting residential IoT: Unprotected webcams, stealing content, breaking into home control systems including smart meters.
- Common worms jumping from ICT to IoT: Generally limited to things running consumer O/S: Windows, Linux, iOS, Android.
- State sponsored and/or organized crime: Access to intellectual property, sabotage, and espionage.
For the layman, to better understand the sheer size, consider IPv4 which has now run out of usable IP addresses that can be assigned to a device. IPv4 has only 4,294,967,296 (4.3 billion) addresses since its inception in the 1980’s. This was a serious limitation and nobody thought the “Internet of Things” (IoT) would evolve and IPv4 could not scale to the astronomical numbers that are now occurring. The new IPv6 now being rolled out provides theoretically 3,400,000,000,000,000,000,000,000,000,000,000,000,000 (340 Undecillion) IP addresses. Think of it as every device made connected and controlled over the internet can have its own IP, an “identity artifact” equivalent to a DNA marker unique to every living organism’s chromosome. This is where the rubber meets the road which enables the IoT its explosive growth. Yet with the IoT, its not merely having enough IP addresses imaginable for every device and in addition have one for every human being on this planet, it is also about “machine to human”, “human to machine” and “machine to machine” communication. From a security perspective identity is one of the most critical and fundamental cornerstones towards securing the IoT.
I do stress that IPv6 enables each manufactured device globally the capability to have a uniquely assigned IP address and that can serve as one plausible identity marker yet the use of DHCP and proxies also masks the identity of the device to the owner or another object using it. Moreover, it can serve as an electronic tracking marker much like a serial number does today manually.
Identity Management (IdM) LifeCycle
In user identity management (Traditional IdM) we have rather long living lifecycles of an identity. In day to day service like e-mail, texting, telephone, etc. a user account exists for months, years or even a lifetime. In the IoT objects have very different lifetimes. This might range from years or decades down to days or minutes quite a broad range indeed, but that can also exist in the traditional sense. For example, a parcel might be shipped from one location to another. The parcel gets an RFID tag associated with an identifier (tracking number). It moves from logistic center to another, perhaps crossing borders, it is tracked, controlled and routed. As soon as it arrives the identity of the parcel disappears.
Ownership and identity relationships
Things or objects in the IoT often have a relationship to real persons and it many cases to other objects. These could be owners, manufacturers, users, administrators, or many other functions. A product might be owned by a manufacturer first and subsequently by a user who bought the product, later that owner sells it to another owner or disposes of it. The owner, user or administrator of an object might change over time. Ownership and identity relationships in the IoT have an impact on other identity related processes like e.g. authentication, authorization. The owner of a thing might be challenged for authentication or be asked for authorization policies.
In the classic identity management certain protection methods have been established over the years to protect an identity from abuse. We have authentication methods to proof identities, secure channels to transmit identity attributes and passwords and other data are stored encrypted. Security concepts like integrity, availability, authenticity, non-repudiation are built in classic identity protocols like SAML and OpenID. In the IoT the situation is different where many communication protocols are not based on the internet protocol. Many sensors or actuators have just restricted resources in terms of energy, bandwidth, and connectivity. Protocols like enOcean [www.enocean.com] or KNX [www.knx.org] use only few bytes to send commands or receive values. There are profound limitations for encryption, challenge response procedure or other security mechanisms.
Authentication and Authorization
These classic mechanisms (user ID and password) may not directly work in the IoT. Many objects have to provide some sort of lightweight token or certificate for an authentication where no user (providing a password) is involved. For stronger authentication means of individuals we usually combine two or multiple factors. These factors are based on following proofs:
- Something that you have
- Something that you know
- Something that you are (e.g. biometry)
In the IoT the last two proofs are not applicable to objects anymore.
How to find/address Things in the IoT (DNS and IPv6 are not enough)
In this section I will get into the technical weeds a bit with the “identifiers”.
In the IoT objects will be connected with different technologies and protocols. Many of the protocols are non-HTTP (Web)-based and some are even not IP-based. As a consequence not all objects in the Internet of Things have an IP-address. Different protocols use different kind of identifiers.
Limitations of hardware addresses for routing purpose
Even in case devices have an IP-based address it is not a good idea to code this address hard in an application much like the user ID and password that never should be used in software code. The device or its interface might change and then all the software has to be corrected. That is the reason a hardware address is mapped to a domain specific identifier. For instance, header control software will rather access http://moraetes.com instead of 184.108.40.206 a DNS redirect to LinkedIn. That’s due to the fact that the LinkedIn service might change his hosting service or simply move to another server infrastructure. In this case the IP address might change from 220.127.116.11 to that of a cloud provider. DNS maps the domain name moraetes.com and will stay the same. DNS can be configured to provide the new IP-address for the same domain name so the application will still work with the domain name but fail by using the IP address.
Object Identifiers in the IoT
Object Identifiers are names assigned to things. The things that are named can include logical or physical objects, and names can be given either to “types of things” or to the “things” themselves. We can call the first a “class identifier”, since it refers to a class (or type, or category) of things; the latter an “instance identifier”. These terms come from computer programming, there may be other terms from ontology or elsewhere that are more suitable. In the case of an automobile, the VIN is the instance identifier, in a computer the serial number or a service tag as in all Dell computers while the make and model would be class identifiers.
On Object Identifiers vs ITU-T OIDs
The ITU-T defines a number of specifications pertaining to Object Identifiers (OIDs), but other implementations that are not ITU-T OIDs also can be considered Object Identifiers. In this article I will use “OID” to refer to ITU-T OIDs, and “Object Identifier” to refer to the concept more broadly to make it easier to understand.
Types of Identifiers
- Instances vs Class – refer to a thing or to a type of thing.
- Unique vs non-unique – identifier issued to only one object or to many.
- Synonyms vs no synonyms – objects permitted multiple synonymous identifiers.
- Governance options – names registration and management where either one authority controls the entire namespace, or is there hierarchical management.
- Human usable vs machine usable
- Global vs local namespace
- Types of Objects
The concept of object identification applies to numerous types of objects. Names can identify specific instances of objects or they can refer to classes of object – consider a network device, it is important to identify the specific network interface associated with that device, and it is also important to identify the type of device.
Physical Versus Logical
Object Identifiers are applied to any number of things found in the physical world such as computing devices, mobile devices, servers, network infrastructure, meters, sensors, cameras, actuators, locks, medical implants, vehicles (and vehicle components) and more. Each of those things can be referenced by an identifier, and additional identifying information can be conveyed regarding relationships to other objects. For example a server may have a unique hostname, but also be assigned a number of IP addresses corresponding to its physical network interfaces. The full identification of the system would include the name of the server, the IP address of each network interface and the association between the server and the network interfaces.
ITU-T OIDs can be used to refer to physical objects, prominently in the Management Information Base (MIBs) used by the Simple Network Management Protocol (SNMP).
In addition to physical things, the area of identification of logical objects deserves consideration. Logical objects include software, services, data and databases, documents and other digital objects, and more. Identification of software is an area of considerable interest to a number of organizations, and approaches include Software ID Tags and the Common Platform Enumeration. ITU-T OIDs can be used to refer to a number of logical objects. Web services can be identified by the URL used to access them. The Digital Object Identifier (DOI) standard is standardized as ISO 26324:2012, and provides a way of directly referencing digital objects as opposed to using a URL to identify how to access the document, which may not remain valid over time.
Governance of Object Data
Objects in the IoT produce data that might lead to personally identifiable information (PII) and Personal Health Information (PHI). A car for example is able to track GPS positions and to provide a complete movement profile of a certain person.
Although these data are mainly used for maintenance or additional services in automotive user information and consent should be mandatory. Data minimization and data collection (in advance
Complex machines e.g. combine harvesters have hundreds of sensors that are able to produce tons of data. Data should not be collected if they are not used for a specific use-case.
The following are major considerations of IoT governance:
- Data Ownership/Control
- Who owns/controls data
In a combine harvester or vehicle (truck, automobile, motorcycle), is the data owned by?
- The manufacturer
- Service provider (e.g., maintenance/repair shop)
- Harvester/vehicle owner
- Each harvester/vehicle user
- Prospective buyers
- Family members
- Other passengers (e.g., others whose GPS locations also become known)
- What happens when you pick up a stranger (hitch-hiker) or give a ride to the airport to an unknown colleague met at a conference
- A third-party who provides the sensor to support a service, such as:
- Disseminating aggregated data as a subscription service.
- Collecting driver behavioral data to determine insurance rates.
- From a data transaction that requires the interaction of multiple devices owned/controlled by multiple parties.
- When a device is sold.
Whose consent will be required for interactions that involve numerous sensors, controllers, and reporting devices? For example, if an auto manufacturer owns data collected by a vehicle, will it require consent from the vehicle owner and service provider? Will each user be required to provide consent for data generated while they are driving?
Data Ownership, Control and Consent Contracts
What attributes would an identity registry need to maintain to be of use to people or devices seeking sensor or controller devices to integrate into a solution. For example,
- Weather sensors
- Traffic sensors
- Location tracking sensors
- Security sensors
- Weather alerts
- Traffic alerts
- Location tracking alerts
- Security alerts
- Will owners/users have the ability to prevent their devices from being discovered?
- Will they have some selectivity about who can discover their devices?
- Will they have some control over who can interrogate their devices?
- How will devices preclude impersonation of the other devices with which they exchange data?
- Will each device that might generate, process, or report on private, sensitive, or confidential data be required to provide its own IAM capabilities to prevent fraudulent use?
- Will devices be required to develop usernames and passwords to interact with other devices? (How does my calendar system access a GPS system for my child’s school bus, to minimize her waiting in the cold on a snowy day when traffic is behind schedule?)
- Who sets the username/password or other criteria?
- How will this information be stored securely?
- How will it be modified/updated?
“Fog Computing” is an architecture specifically designed to process data and events from IoT devices closer to the source as opposed to a central data center or “Cloud”. Fog Computing is an expansion of the cloud paradigm, similar to cloud computing but closer to the ground. The Fog Computing architecture extends the cloud out into the physical world of things.
As I look upon it the IoT encompasses engineering data captured from information transmitted by these smart devices or objects with each one having a unique identity artifact an IP address and there are additional identity artifacts involved beyond the scope of this article. What must be understood is with the current state of the art adaptive and reactive technologies, which provides the enablement of embedded and distributed intelligence or “Fog Computing”. These technologies form the core architectural component of the IoT and for these primary limitations:
- Network Capacity Preservation: It is well known network bandwidth can be limited and collecting data from a central point in the network always leads to using a large amount of the network capacity.
- Centralized Data Collection: Centralized data collection and smart object or device management does not scale as required by the internet. For instance, managing several million sensors and actuators in an electrical “smart grid” network cannot efficiently be done using a centralized approach.
- Closed Loop Functions: The IoT requires reduced reaction times. For instance, in the electrical smart grid sending an alarm via multiple hops from a sensor to a centralized system (which runs analytics) before relaying a response to an actuator would entail unacceptable delays. Consider detecting a breach on a device occurring where any delayed response would undermine the security and integrity of the network.
The Brains of IoT
The Service Management System (SMS) forms the basis of the IoT architecture. SMS interacts with intelligent databases that contain intellectual capital information, contact information, policy information, manufacturing and historical data. SMS also support image recognition technologies to identify objects, people, buildings, places, logos, land marks and anything else that have value to consumers and enterprises. Smartphones and tablets equipped with cameras have pushed this technology from mainly
Complexity is one of the largest barriers to effective security, and securing the Internet of Things is no doubt going to increase that complexity exponentially in organizations both large and small. You’re going to have to up your security game by doing more of it that is better, faster and cheaper than ever before. The time to be thinking about keeping the Internet of Things in check on your network and any other networks that are associated with your business is NOW. Get the right people on board and at least start with a policy update that outlines access privileges with all of these connected devices. Policies aren’t the magic solution to security they often do more harm than good by creating a false sense of security and compliance, remember that being in compliance is not being secure.