Recent statistics show that the security issues associated with internet of things (IoT) devices are on the rise. This is a direct consequence of the number of IoT projects continuously growing. Gartner predicted that tens of billions of connected devices will flood the market by 2020, up from just shy of 9 billion in 2017 — and with that boon will inevitably come an exponential increase in IoT vulnerabilities.

According to the “IBM X-Force Threat Intelligence Index Report,” 30 percent of all vulnerabilities documented in the past three decades were reported in the past three years — that’s more than 42,000 vulnerabilities. In 2018 alone, IBM X-Force Red’s Vulnerability Management Services identified an average of 1,440 unique vulnerabilities per organization.

On the bright side, there is a gradually increasing awareness from the IoT industry — as well as the broader public — about the urgent need to tackle these issues. While cybersecurity projects for the IoT share many aspects with classic IT projects, they also come with many specific challenges that require special attention.

IoT architectures are complex; even the most basic components include devices, edge systems/concentrations, telecommunication lines, and back-end, mobile and AI applications. While the perimeter of an IoT project is always difficult to define, to build a secure IoT architecture, we need to consider IoT architecture security as a whole.

Repurposing Security by Design for IoT Projects

Security by design should be implemented at the earliest stages of building IoT projects. Most of the security design principles that are largely used in the information security field can be repurposed for IoT, as long as security leaders consider the following:

Economy of Mechanism

In a complex scenario where many security technologies and mechanisms are deployed, the risk of misconfiguration is higher. IoT devices are usually resource-constrained. In this case, economy of mechanism is helpful to maintain the viability of the system. Usually, IoT devices runs over a battery. Implementing too many security controls can drain the battery and harm the device itself. An attack can be focused to drain the battery and shut down the device.

Castel Approach

Also known as defense in depth (DiD), the Castel approach is the application of multiple layers of security mechanisms. The rationale is that no single defense measure can help you stay ahead of all attacks. A layered security system forces the attacker to penetrate through all the layers to reach its target.

Less Is More Secure

In 1975, Saltzer and Schroeder introduced the least privilege principle, which stipulates that every program and user should operate with the minimum set of privileges and access to complete the job. Applied to our scope, this means that a system needs to be accessed by multiple users. A privilege policy must be implemented to guarantee the right access and use of the system.

Another mechanism that should be implemented is separation of duty, which means a system should not grant permission upon a single condition. One example of how this could be applied is implementing two-factor authentication for critical tasks.

Isolation

When possible, a system must be disconnected from public networks with the use of firewall, DMZ, and an intrusion detection and/or prevention system (IDS/IPS). It may also be necessary to implement multiple layers of virtual private network (VPN) access. In the case of mission-critical devices, consider a full air-gapped approach.

Attack Surface

When more functions are available, that means more entry points for an attacker to exploit. Evaluating the attack surface is important to deploy an efficient defense strategy and to evaluate whether a function is really necessary.

Understanding the Perimeter and Configuration

The IoT comprises several devices that are distributed in a perimeter that may be very wide. In the case of Mirai, for example, the attackers compromised cameras in an effort to get to an external Domain Name System (DNS).

Having a clear understanding of the perimeters in terms of devices, communications, controls and the relationship between those devices is vital. Being able to fully comprehend those devices, including their very nature, their functionalities, the log data they produce and their working conditions, is also crucial.

Data logs in particular can help anomaly detection tools identify errant behavior. The data must be normalized, which requires a deep industry knowledge and familiarity with the device itself. Once normalization is achieved, the detected anomalies can easily unveil potential cyberattacks.

What Services Are Provided?

Once the perimeter is clear, document the type of services and how they relate to the devices. A configuration management database (CMDB) can help determine which configuration items, attributes and services are connected to each other. Below are the three main types of services to consider.

Explicit Services

Explicit services are clearly documented. For example, in energy distribution, metering systems are used to understand the energy utilization, video surveillance is used to control the physical access to protected areas, etc.

Implicit Services

Implicit services aren’t explicitly mentioned, but it’s critical to take them into consideration. For example, threat actors might use intelligence present in the infrastructure to attack third parties.

Expected Services

It is important to discuss the objectives of a cybersecurity project with the committee. In the case where physical security (e.g., visibility on individuals entering a specific room) needs to be improved, additional controls that are not necessarily are included in the cybersecurity controls will be required. In other words, specific devices might be necessary to implement additional cybersecurity controls.

The description of services leads to consideration of the attackers’ motives, which can vary depending on the type of project. In operational technology, threat actors usually try to interrupt explicit services, as was the case with Stuxnet. In IoT attacks, they usually try to control devices as part of a larger effort to compromise implicit services.

Threat Modeling and Security Controls

Once services and configurations are clearly defined, the risk of possible threats must be explored to provide the inputs to the next phase. To help better discover and understand the risks during this phase, security teams can use prototyping or penetration testing when and where possible.

Upon defining and documenting the aforementioned risks, the project owner — an external project manager, the chief information security officer (CISO) or a security specialist assigned by the CISO — needs to prioritize and then properly implement the security controls required to mitigate or minimize the risks and improve the organization’s cybersecurity posture.

The IoT Exacerbates Old Security Woes

The security controls to be implemented in an IoT project depend on the configurations, services and risks associated with the task at hand. For example, if devices generate significant data, anomaly detection could be considered. If penetration testing is possible, a good practice could be to use the control to understand the real risks. Also, a proper level of segmentation in many cases can address most of the issues. This is very similar to what we have in IT projects, but keep in mind that the IoT extremizes all the challenges we already have in IT, such us heterogeneity of devices, difficulty in defining a perimeter and more.