Cyber Security - IT Security Meets OT Security

Paul Didier, Solution Architect Cisco
October 10, 2018

Abstract
This session will look at how CIP Security can be used in-conjunction withcurrent and in-development IT Security tools and technologies to significantly
improve plant floor security and protection. We will discuss how to apply
network access control and Plant and Cell-Area zone segmentation policies ina structured, scaleable manner. 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. Lastly, we will look at some advanced, under-development
standards to automatically apply trust and policy based on IETF standards suchas Bootstrapping Remote Secure Key Infrastructure (BRSKI) and Manufacturer
Usage Description (MUD) specifications

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org2•••••Why are we talking about this?
A look at some of the standards and how they line up security-wise
BRSKI – Bootstrapping Remote Secure Key Infrastructure
MUD – Manufacturers User Descriptions
How it could work
– Scenario 1– Scenario 2

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

3Gratuitous IoT Growth Chart

25b+

IoT Units Installed BaseGrand Total

6.4b

3.8b

2014

4.9b

2015

2016

2017

Source: http://www.cisco.com/c/en/us/solutions/service-provider/visual-networking-index-vni/index.html

2018

2019

2020

The Network Administrator’s Problem
Number of Types of Things$$

A snapshot of Security Standards
Onboarding(ID & Trust)ClassificationandAuthorization• CIP Security: Pull& Push
• 802.1AR (DevID)• Enrollment overSecure Transport(EST RFC7030)• BRSKI• 802.1X NetworkAccess Control• xDS device
descriptor• Manufacturers
User Description(MUD)

Segment &Protect• VLANs• ACLs• TLS and DTLS

•Secure Group
Tagging (DraftIETF)

Monitor• Syslog• SNMP• IPFIX

Bootstrapping Remote Secure KeyInfrastructure(BRSKI)

Technical Track© 2018 ODVA, Inc.

2018 Industry Conference & 19th Annual Meeting
All rights reserved.

www.odva.org

7

Zero-touch provisioning of IoT devices• We want to encourage IoT device vendors to embed an X.509 certificate

in their devices, and support IEEE 802.1X for authentication• It would be even more valuable if we could safely automatically authorize

IoT devices to be on the IT or OT network• IoT devices don’t have a UI, and manually adding large number of IoT devices

onto the network won’t scale• But when the X.509 certificates come from a variety of manufacturers, wearen’t able to easily share a common trust root, and thus can’t easily
authenticate them

The necessary components• The IoT 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 IoT device & Production network support a multi-vendor bootstrapping protocol(BRSKI)• draft-ietf-anima-bootstrapping-keyinfra-04• 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 IoT Device and Production network have amutual trust, and the IoT device can be admitted to the network.

BRSKI• The IoT Thing requests some assurance that it should join this network.

• The request is forwarded to the MASA server, which returns a signed “audittoken” to the network, which also forwards it to the IoT Device• At the end there is mutual trust provided by the MASA server
Plant Data
CenterIoT ThingAAA/BRSKI
ServerNetwork“request for assurance
that domain is safe”

Manufacturer
MASA Server

Request sent over IPIP
Request sent to MASA server”audit token” returned”audit token” returned”audit token” returnedManufacturing User Descriptions(MUD)

Translating intent into config
Any intended use can be clearly identified
by the manufacturer

All other uses can be warned against
in a statement by the manufacturer

access-list 10 permit hostcontroller.mfg.example.com

access-list 10 deny any any

MUD IETF draft• draft-ietf-opsawg-mud-01• Defines the format of a MUD file (YANG/JSON) for describing policy about a device, such as

its network access policy. This network access policy can be turned into ACLs and placed ona network access port
• Defines a new URI for referencing the MUD file, which describes the location of the MUD file
on a public web server.
• E.g., https://mud.mfg.example.com/.well-known/mud/v1/CAS11LCDLversion2.12• Defines protocol extensions that a IoT device uses to forward the URI to network devices• X.509 certificate extension• DHCP option• LLDP TLV

Actors in a MUD scenario• IoT Thing: Emits the MUD URI• MUD Controller: Receives the MUD URI (forwarded from a AAA server), resolves theURI to recover the MUD file, translates the MUD policy into ACLs, and delivers theACLs to the AAA server• Manufacturer Web Server: Serves the MUD file to all comers
ITNetwork

Plant network
IoT Thing

AAAServer

MUD
Controller

Plant Data Center

Internet

Manuf. Web Serverwith MUD file

The preferred method of URI distribution• MUD URI is placed in the IoT Thing certificate, used by 802.1X/EAP-TLS
Data Center

IoT ThingAAA
ServerPlant Network

EAP over 802.1X(MUD URI carried in
The X.509 certificate
used by an EAP method)

Controller

EAP over RADIUS
MUD URI
Fetch MUD FileRADIUS(ACLs delivered to Cisco GW)

DHCP & Data

MUD

Manuf. Web Serverwith MUD fileACLsMUD without IEEE 802.1X/EAP-TLS
When MUD URI is distributed in DHCP or LLDP, the port starts with a default
policy that only allows packets necessary to provision the IoT Thing (e.g., DHCPor LLDP)
Data Center

IoT Thing

AAAServerPlant Network

MUD

Manuf. Web Serverwith MUD fileController

DHCP or LLDP(MUD URI carried asa protocol extension)

RADIUS(MUD URI delivered asa protocol extension)

RADIUS(ACLs delivered to switch)

DataFetch MUD File

Results: Micro-segmentation••••AccessSwitch

Enterprise NetworkAccess limited to devices
based on manufacturer
recommendations
Policy choices easily
identified by MUD file
Hacked devices can’t probefor holes
An additional layer ofsecurity– BUT- manufacturers
should still always secure
their devices

Status of MUD• draft-ietf-opsawg-mud-25 is an IETF Proposed Standard• Additional capabilities to be introduced over time

Scenario 1: EasierUse of LLDP tocommunicate
manufacturer usage
descriptions

Initial Configuration (the same as before)
Plant Network• Capable network connectivity• MUD file server would sit on the Internet• Hacked system maybe authorized but not known to be a “Production”
Thing (perhaps a laptop)

Registrar/ AAA Server
MUD Controller

Manufacturer ServerOnboarding Process
MAC authenticated Bypass (MAB)

Plant Network• Device does not do any authentication

Registrar/ AAA Server
MUD Controller

Manufacturer Server

Device States What It Is via LLDP MUD-URL
Plant Network• https://example.com/.well-known/mud/v1/mudfile• LLDP information forwarded to ISE• Address information collected

Registrar/ AAA Server
MUD Controller

Manufacturer Server

Retrieve Manufacturer Information
Plant Network• AAA server gets profile information from MUD controller• Controller retrieves the information from
the Manufacturer

Registrar/ AAA Server
MUD Controller

Manufacturer Server

Approval and Access List GenerationPlant Network• Approval, if required for initial device types

AAA Server
MUD Controller

Manufacturer ServerIssue Change of Authorization
Plant NetworkAAA Server
MUD Controller

Manufacturer Server

Scenario 2: Harder
Full scale manufacturer
certificate authentication andauthorization(the big one)

Initial Configuration
Plant Network• Capable network equipment• MUD file server would sit on the Internet• Hacked system is authorized but not known to be a Thing (perhaps alaptop)

Registrar/ AAA Server
MUD Controller

Manufacturer ServerOnboarding Process
Device Connects

Enterprise Network• Assume hacked device has general access• Onboarding device is initially isolatedRegistrar
MUD Controller

Manufacturer Server

Bootstrap
Find RegistrarEnterprise NetworkRegistrar
MUD Controller

Manufacturer ServermDNS Registrar Discovery

Bootstrap
Initiate Registration• Device transmits its manufacturer certificate• This contains URL of manufacturer (MUD file) server

Registrar
MUD Controller

Manufacturer Server

Bootstrap
Retrieve MUD File from Manufacturer, to Find MASA ServerRegistrar
MUD ControllerManufacturer Server

Request a Voucher to Send to the Device

Registrar

Manufacturer Server

Administrative Approval, if Required(Probably Only First of This Type of Device)

Registrar

Install Trust Anchor and Perform EST Registration toObtain A Local Certificate
Yay!! At the end of this step, the device is registered!
Next up: determine its access

Registrar

Manufacturer Server

Now Device Authenticates Using 802.1X
Enterprise Network• 802.1X from device to the switch• EAP-TLS over radius from switch to the AAA server

AAA Server

Manufacturer ServerDetermine Appropriate Authorization• AAA server requests profile from MUD controller• No need to retrieve MUD file (we already did that)AAA Server

Manufacturer ServerEffect Change of Authorization
Enterprise Network• RESTful interface to MUD controller• Radius back to switch

AAA Server
MUD Controller

Manufacturer ServerMore information• draft-ietf-opsawg-mud-25.txt (MUD)• https://mudmaker.org• draft-friel-brski-over-802dot11-00.txt (Problem statement)• Information list: mud-interest@cisco.com• IETF WGs: opsawg@ietf.org (MUD) anima@ietf.org (BRSKI)

THANK YOU