Standards are critical for secure connectivity in industrial IoT - Embedded.com

Standards are critical for secure connectivity in industrial IoT

It’s fair to say that cybersecurity for operational technology (OT) and industrial control systems (ICS) lags quite considerably behind that of enterprise IT. Yet the move towards Industrial IoT (IIoT) means it is now vital to close this gap and protect not just manufacturing processes but also critical infrastructure such as energy, health and transportation.

As connectivity increases and individual components connect to the web—allowing remote monitoring, software updates, better analysis of data, and automation from such systems—the attack surface increases significantly, and the need to protect against cyberattack becomes a business imperative. This is true not only of critical infrastructure, for instance the 2013/14 Russian Dragonfly attack, but across the board, for example, TSMC’s 2018 shutdown caused by a WannaCry malware variant.

For manufacturing alone, Verizon’s latest Data Breach Investigations Report has recorded over 200 espionage-based security breaches and over 700 financially motivated attacks in the past year.

The development of, agreement on and certification of industry standards play a key role in protecting such systems.

Evolution of Industrial IoT

Cybersecurity in OT lags largely because many of the legacy systems were created for a non-connected world. While incidents occured even back in the 80s — see 1982’s reported CIA attack on Soviet gas infrastructure— the opportunities were fewer and hacks were harder to pull off.

In fact, it wasn’t until the turn of the century, when Ethernet was introduced, that OT systems became more widely connected. As a result, many of the individual components still in use today were never designed for the implications of TCP/IP connection, nor were some of the communication protocols connecting industrial electronic devices, for example Modbus.

Moreover, many organizations running such systems want to move from a siloed OT model to a more connected IT or even IIoT model as a way to use data more effectively. To do this with legacy equipment, and get data moving from one side of the factory to another, firewall ports and pinholes must be opened, thus increasing the attack surface.

By their very nature, OT systems are hierarchical and security standards typically mirror the Purdue Model in which the network is split into functionality layers: from Level 0 (sensors and actuators), up through the OT environment, to the highest level, Level 5, the company’s enterprise IT network. Data flows through these levels to provide data about the plant, and to provide business context for ICS to adjust performance or set delivery schedules.


Purdue Model (Source: IoT Security Foundation)

This model also suits IIoT devices well; it can be argued that each IoT device is a “Purdue Model in a box,” with a sensor, a processor and a connection to the enterprise network. However, for remote monitoring equipment, like that used in smart cities, systems don’t just connect to the enterprise network, but directly to the cloud, a Level 6, if you will. This couples them more closely to Internet-borne threats.

Security standards, guidelines, regulations

As the Internet becomes increasingly important to our economic and social well-being, with innovation being rife throughout value chains, standards and regulations are needed to protect all stakeholders from unintended consequences and malicious intent.

We’re no longer in a world that follows a predefined M2M model, where known equipment from just one (or very few) vendors make up the system, and each element can be trusted. This old model meant that proprietary protocols could be implemented specifically for a vendor: For example, ABB or Honeywell, each with differences, sometimes to the point of contradiction.

The move to IIoT systems changes this. Not only does equipment come from multiple vendors, sensors are connected to wide area networks (WANs) such as LoRa or 5G, and located remotely. Standards therefore need to be used and adopted throughout the ecosystem.

As has been noted, “The great thing about standards is there’s so many to choose from,” but with so many standard-setting bodies it’s no wonder TÜV Reinland’s 2019 Cybersecurity Trends report warns: “Industrial IoT faces a major standards challenge.”

Those worthy of mention here include the general standards SP 800-82 from the U.S. National Institute of Standards and Technology (NIST) and ISA/IEC 62443, as well as several industry-specific standards and guidelines from governmental organizations. There are also vendor-specific standards from the major players such as ABB, General Electric and Siemens.

It is also worth noting that there is no standard that runs the gamut from the sensor all the way up to the cloud. Additionally, there’s traditionally been some conflict and contradictions between standards, leading to incompatibility and/or non-compliance. However, this is becoming rarer in the OT/IIoT sector, where we typically see convergence. Even the vendor-specific protocols now reference the broader standards such as SP 800-82, and in particular ISA/IEC 62443.

SP 800-82

SP 800-82 began life 15 years ago as an ICS and supervisory control and data acquisition (SCADA) system cybersecurity standard from NIST.

It specifically addresses ICS threats and vulnerabilities, as well as risk management, recommended practices, architectures and tools. It’s become more comprehensive with each update, adding, for example, tailored security baselines for low-, moderate- and high-impact ICS equipment.

NIST also is addressing concerns of ICS security in mid-sized companies and has begun expanding testbeds for robotics, smart transportation and chemical processing, among others.

ISA/IEC 62443

International in nature, and applying to ICS users and not just suppliers, this is probably the most prominent ICS cybersecurity series of standards.

These specs were created to be more specific to industrial control use cases than SP 800-82. They provide a flexible framework to mitigate the security vulnerabilities of industrial automation and control systems, both current and future.

Like SP 800-82, they’re designed to prevent danger to the public and employees, loss of public confidence, violation of regulatory requirements, IP theft, economic loss and national security attacks, and have become the basis of many industry-specific standards.


John Moor

Matching the Purdue Model, they are hierarchical and split into four levels: General, Policies and Procedures, System and Component. Not all are published yet, but four in particular are worthy of highlighting: 62443-2-4 (policies for system integration); 62443-4-1 (requirements for a secure development lifecycle); 62443-4-2 (component security specifications); and 62443-3-3 (security requirements and levels).

The standards are detailed, representing requirements across the industrial control sector. Security requirements are outlined for each level to protect uptime, intellectual property and safety, with clear expectations for each stakeholder within the IIoT ecosystem. Individual vendors’ guidelines and industry-specific standards—for energy generation—are now typically based on 62443, translating relevant subsections to suit that industry’s language and protocols.

The UN Economic Commission for Europe’s Common Regulatory Framework on Cybersecurity has integrated ISA/IEC 62443, and the U.S. NIST SP 800-82 has been aligned with it.

It is also worth noting that the standard has been criticized for being expensive to access, which could potentially prevent or slow companies from implementing best practices.

Industry-specific standards

As mentioned, there are many industry-specific standards created to protect critical infrastructure such as the electricity network. For example, the U.S. Energy Department has developed standards based on ISA/IEC 62443 in collaboration with the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Keen to highlight best practices, the organization has published its recommendations in an infographic.

These also align with guidelines for energy infrastructure developed by the U.K. National Cyber Security Center.

While the standards often overlap, there is room for interpretation and implementation. How do we make sure everybody’s choosing to interpret them in a consistent way, and how do we measure the degree of compliance? Then there is certifying systems when every sensor and every control system is different.

While governments now mandate a certain level of security must be met for critical infrastructure, security breaches focus on weak points.  When purchasing IIoT equipment, ask if a supplier is penetration testing a device sufficiently, and whether it’s meeting all requirements to the same level as other suppliers.

Take energy, for example: How to ensure the trustworthiness of all smart meters being added to the network? To do so, we must build trust and then enforce it through these common standards.

Part of this is changing: The U.S. Defense Department announced the Cybersecurity Maturity Model Certification program this year. Cybersecurity shifts from being the fourth pillar of any procurement cycle—alongside cost, schedule, and performance—to the foundation. In addition, third-party assessment is now mandatory.

Cost is the enemy of security, and the cost of full certification on these systems is very high. Add to this the lack of certification houses and it is easy to understand why self-certification is still used in many sectors.

Because there is no one-size-fits-all approach, a standard must still be contextualized for an individual organization. Having experts who can determine contextual background, both operationally and strategically, for the organization, and then apply these best practices is fundamental. Yet there’s a significant skills shortage.

Zero trust, the move to IIoT, the cloud, edge computing

Big changes have emerged in the way infrastructure is managed. Sensors are now located remotely and communicate back over WANs making it more difficult to isolate some of these capabilities, including control and analysis functions.

The Covid-19 pandemic and the need to provide home workers with remote access for monitoring systems, can only accelerate this trend. It also lends greater urgency to strengthening security.

That requires looking beyond ISA/IEC 62443 and NIST SP 800-82 to more specifically address IIoT and its introduction of cloud and edge computing to the industrial context.

Historically, OT security relied on implicit trust, based on an assumed trusted network. Systems are no longer based on a single- or almost-single-vendor model. As the number of IIoT devices from multiple vendors increases, implicit trust will not be enough. We need “zero trust” networks, where device relationships and security state are assured and devices are hardened to resist the untrusted environment. Indeed, this is a focus of the IoT Security Foundation’s smart building working group.

IT is already heading this way; it should also be the case for the IIoT world. Indeed, vendors and standards bodies have been looking at automatic deployment provisioning of devices: For example, Intel, with its Secure Device Onboarding, now submitted to the FIDO Alliance.

What this means in a real world, say, a smart city deployment, is that sensor installation will become plug-and-play, with the device knowing the source to contact to establish trust relationships with other parts of the infrastructure.

This will be accelerated by edge computing and AI deployments, so sensors, actuators and control systems will inherently become smarter: as they collect data, they can also check its validity.

We start with secure and trusted chips, software and the cloud-based management systems and their communications being equally secured and trusted. The result is robust infrastructure. But it also means standards and certification must be established.

Increased connectivity means increased vulnerability, and firewalls are not the answer. They create a false sense of security, and don’t really secure critical systems. In such a world we all have a role to play in making it safe to connect. For those seeking to benefit from having smarter IIoT systems, remember these wise words: “if it ain’t secure, it ain’t smart.”

–John Moor is managing director of the IoT Security Foundation. This article was written in collaboration with Professor Paul Dorey (CSO Confidential), Pam Gupta (OutSecure), Professor Paul Kearney (Birmingham City University), Nirmal Misra (Device Authority) and Haydn Povey (Secure Thingz).

>> This article was originally published on our sister site, EE Times.

 


Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.