Skip to main content


How 2020 Presidential Candidates Can Guard Against Cyberattacks

The 2016 presidential election witnessed unprecedented Russian cyberattacks and disinformation campaigns designed to disrupt the U.S. electoral system by influencing public opinion. The Russian goal is intended to destabilize the U.S.  through ideological activism, advancing their interest and further their political agenda. Their methods compromised computer systems of candidates and political parties using the exfiltrated data to spread disinformation and influence presidential elections.

On January 6, 2017, the U.S. Director of National Intelligence released a declassified report “Assessing Russian Activities and Intentions in Recent U.S. Elections.” According to the report, Vladimir Putin ordered a massive campaign orchestrating attacks from multiple fronts that involved spreading pro-Trump propaganda on social media to hacking the Democratic National Committee (DNC). Their methods resulted in massive data breaches within the DNC that included access to John Podesta's email f…

Identity Management for the Internet of Things

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 growing so complicated, that securing these devices may seem insurmountable with the attack surface footprint becoming infinite in size.

“Internet of Targets” Security Dilemma

The IoT opens an entirely new aspect of security where the Internet meets the physical world. This has some severe implications for security as the attacking 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 tools, protocols, and workflows. Many operating systems are moving from closed systems (e.g., SCADA, Modbus, CIP) into IP-based networks which further expands the attack surface. The IoT can be affected by various categories of security threats including the following:

  • Cyberterrorism: Nuclear plants (For example, the 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, it’s not merely having enough IP addresses imaginable for every device and also 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 security, perspective identity is one of the most critical and fundamental cornerstones towards securing the IoT.
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


Ownership and identify relationships

Things or objects in the IoT often have a link to real persons and in 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 the 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.

Protection Mechanisms

In the traditional identity management, specific protection methods have been established over the years to protect 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 standard 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 regarding energy, bandwidth, and connectivity. Protocols like EnOcean [] or KNX []  use only a few bytes to send commands or receive values. There are profound limitations to encryption, challenge-response procedure or other security mechanisms.

Authentication and Authorization

These traditional 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 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 the following proofs:

  1. Something that you have
  2. Something that you know
  3. Something that you are (e.g., biometry)
In the IoT, the last two tests 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.”

Various protocols

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 of 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 instead access http://some-domain-name instead of an IP DNS redirect to LinkedIn. That’s because the LinkedIn service might change his hosting service or just move to another server infrastructure. In this case, the IP address might change from to that of a cloud provider. DNS maps the domain name 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 some specifications about 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 too 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 essential to determine the particular network interface associated with that device, and it is also crucial to identify the type of device.

Physical versus Logical

Physical Objects
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 some 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).

Logical Objects
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. The license of the software is an area of considerable interest to some organizations, and approaches include Software ID Tags and the Common Platform Enumeration.  ITU-T OIDs can be used to refer to some 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 specific 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 significant considerations of IoT governance:

  • Data Ownership/Control
  • Who owns/controls data
In a combine harvester or vehicle (truck, automobile, motorcycle), is the data held by?
  • The manufacturer
  • Dealer
  • The service provider (e.g., maintenance/repair shop)
  • Harvester/vehicle owner
  • Each harvester/vehicle user
  • Employees
  • Clients
  • Prospective buyers
  • Family members
  • Friends
  • 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 numerous parties.
    • When a device is sold.
    • Consent
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

The rationale is that current contracts (e.g., privacy policies, website terms of use) are one-sided that the negotiation asymmetry may be considered unfair.

Identity Discovery

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?

Identity impersonation

  • 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?

 The Architecture

“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.

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 significant amount of the network capacity.
  • Centralized Data Collection: Centralized data collection and smart object or device management do 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 smart electrical 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 supports image recognition technologies to identify objects, people, buildings, places, logos, landmarks and anything else that have value to consumers and enterprises.

Complexity is one of the most significant barriers to adequate 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 systems 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 agreement is not being secure.