CIP Security can be used in conjunction with current and in-development IT Security tools and technologies to significantly improve plant floor security and protection. In this article, we will discuss how to apply network access control and Plant and Cell-Area zone segmentation policies in a structured, scalable manner that improves to improve and security and reliability of plant networks.

As well, we will review the value of monitoring network and security health through the use of traffic flow monitoring (NetFlow/IPFIX, IETF RFC 7011-7015) features and security monitoring applications.

And finally, we will look at advanced, under-development standards to automatically apply trust and policy based on IETF standards such as Bootstrapping Remote Secure Key Infrastructure (BRSKI) and Manufacturer Usage Description (MUD) specifications.

Why are we talking about this

The IoT is expected to grow rapidly over the upcoming years. Below is a chart of estimated IoT units/things that are expected to be connected. That large growth of things poses challenges in ecosystems that are expected to manage closely the devices that are connected, such as Manufacturing.

This rapid growth will be a significant problem for administrators of the networks that are the focus of this growth, such as production facilities, factories and plants found in Manufacturing.

A key consideration will be how to automate the on-boarding and policy deployment for new things on the network. To that point, some “IT” new standards are being developed to help solve those challenges. But those can only be effectively deployed with the cooperation of the thing makers – of which the ODVA is a good ecosystem of device vendors.

Security standards: a thing’s view

This article introduces two developing IT-based, IETF standards that should help automate the security processes for Industrial Automation and Control devices as they become operational in machine builder, customer or system integrator’s processes.

They will help automation the onboarding by automatically deploying secure credential to devices (BRSKI) and help Manufacturers express key characteristics about how the device should be classified and authorized – key steps to eventually segment and protect the devices and the Industrial Automation and Control System where they operate.

BRSKI

An overview of Bootstrapping Remote Secure Key Infrastructure (BRSKI) illustrates how it can be used in industrial networking.

ODVA has established standards for devices around Identification and Authorization in the CIP Security standards. Recently, a “pull-model” has been adopted as a mechanism to automate the delivery of secure credentials to a CIP device.

In the IETF, the Autonomic Networking Integrated Model and Approach (ANIMA) Working Group is developing a standard (RFC) around Bootstrapping Remote Secure Key Infrastructure (BRSKI). The BRSKI standard outlines means to automatically deploy identity to devices so that they can be authorized on the network and establish secure communications.

This enables Zero-touch provisioning of IACS devices that meets both the needs of OT for known devices to be on the network and IT to do that in automatic and secure mechanisms.

The necessary components for this process to occur include:

• The device is manufactured with an X.509 certificate and private key that conform to IEEE 802.1AR.
• This is a standard definition of a “manufacturing certificate”
• The device & production network support for the multi-vendor bootstrapping protocol (BRSKI)
• The IoT device manufacturer supports a Manufacturer Authorized Signing Authority (MASA), which keeps a log of which devices have been installed in which IT or OT domains.
• At the end of the BRSKI protocol, the device and production network have a mutual trust, and the IoT device can be admitted to the network.

Below is a description of the key components and the process outlined in the BRSKI documentation. This model should be relevant for device vendors, machine builders, system integrators and customers as a key part of securing the chain of suppliers needed to build production systems.

Manufacturer’s User Descriptions

In the IETF’s Operations and Management Area Working Group (opsawg), the group is working on the Manufacturer Usage Descriptor (MUD) specification.

A MUD “file” would be a means for manufacturers to describe policy about devices that can help classify and authorize devices as they join production networks.

This information can be used to help establish network policies around segmentation to protect IAC devices and systems. The same working group also established IP Flow Information and Export protocol (IPFIX) used to monitor communications in IP networks, such as a CIP EtherNet/IP network.

The depiction below describes how a device can express where to find the relevant MUD file and how IACS production network can retrieve, store and maintain those files. The device expresses this via a Universal Resource Locator (URL).

There are two basic means envisioned to support how a device can express where to find it’s MUD URL. First the URL could be contained within a devices certificate, for example its CIP-Security certificate. Or it can be programmed to express the URL via common network discovery or addressing functions, such as LLDP or DHCP.

The end results of deploying MUD information is that the production system and network can establish segmentation. This still requires more input and process from both the IT and OT communities, but it’s a key step in the process of automating these security procedures.

How it could work: simple system

Together, BRSKI and MUD can be combined to automate much of the security deployment and implementation for IACS devices, such as CIP, in production networks.
In a simple example envisioned for brownfield deployments with largely SW-based enhancements to devices. Here is a description of the process:

• Initial Configuration
• Onboarding process
• Device announces itself via LLDP or DHCP
• MUD File is retrieved
• Approval given and Policy Assigned
• Network Access Control granted based on Policy

How it could work: complex system

Here is a description of the process:

• Initial Configuration
• Onboarding Process:
  • Device Connects
  • Bootsrapping starts, finds registrar
  • Initiate Registration; express MUD URL
  • Retrieve MUD file
  • Request Voucher
  • Approval (for first time device types)
• Install Trust Anchor
• Authenticate via 802.1x
• Determine Authorization
• Network Access Control granted based on Policy

Paul Didier, Manufacturing Solution Architect, Cisco Systems