CIP Security Pull Policy

Jack Visoky, Joakim Wiberg, David Smith
Rockwell Automation, HMS Networks,
Schneider ElectricIntroduction••

We already have the CIP Security Pull Model, where a device is able toautomatically request/receive a certificate
There is still a lot of other configuration needed for CIP Security to work––––•Allowed Cipher Suites
Additional Trust Anchors (certificates)
Send full certificate chain or notEtc.

It would be ideal if a device could also automatically request/receive thisinformation– And it was delivered in a secure manner!

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

2

Use Cases – What is the Motivation•

Ethernet LAN Diagram

Deliver CIP Security config to a device
behind a NAT– Configuration tool on the public network
cannot push config to the private network•Operator HMI

10.22.8.11

Historian10.22.8.12

10.22.8.13

Client-only software– There is no CIP Target to push to!

•Workstation

Automatic device replacement with full
CIP Security deployment (not justcertificate)

10.22.0.1

Router-Firewall

10.20.0.1

172.16.0.1
10.20.14.10

HMITechnical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

OTConfigSCADA– Everything is delivered automaticallywww.odva.org

PLC

10.20.14.111

IO

Motor3Could this be used to deliver other CIP configuration?
••Sure, but that is not our focus
That said, we are defining a generic way to set
CIP attributes and call services of various
objects, which is essentially what CIP
configuration is– At the same time other technologies (e.g.
Safety, Motion) may present corner cases thatneed to be dealt with–Technical Track© 2023 ODVA, Inc.

>
2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

4Requirements••••Document format – we need to deliver the data as a
document so that it is independent of transport
Authenticity – fundamental requirement for verifying theconfig was not tampered and came from an authorized
sourceConfidentiality – not nearly as important as authenticity
but it could be useful, especially for PSKs or for anenvironment where there is a lot of concern regarding data
confidentiality in general
Versioning – important to ensure that consumers of thedocument are using the same version, also prevents
downgrade/replay style attacks

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

5Requirements•••

Automatic discovery – existing Pull Model for
certificates provides this, need to continue to support
automatic discovery of the server
Configuring retry – if the server is unavailable for any
reason then the CIP device needs to be able to retry(could happen if too many nodes attempt
communication at once)
Trigger a reconfiguration – after initial policy isdeployed there are likely going to be changes, so thedevice needs to “check back” for updates, this needs tobe configurable somehow

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

6Requirements•••

Ease of use with CIP Configuration – it’s the whole
point of this endeavor, to support CIP configuration!
Suitable for embedded computing environments –most (although not all) CIP endpoints are devices
running in an embedded compute environment;
technologies not well suited to this are not ideal (e.g.
parsing takes up too many resources, etc.)
Human Readable – nice to have; primary purpose is formachines to consume this data, not humans, but still it
would be ideal if a human could read this data

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

7Technologies – Some Examples•••

The following are some example
technologies that were evaluatedMore could of course be looked at, but thesefour give a reasonable representative set ofthe options
AutomationML– Powerful but optimized for a different use case(data exchange amongst engineering tools)•JSON– Lightweight and compact, schema would needto be defined– Would be well suited to the task as it would becustom-built for it

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

8

•

Existing policy language– Reusable but not well suited toembedded environments– Example of this would be Rego, which isused with the Open Policy Agent (OPA)• Others exist but clearly none are purpose
built for this task•

Encoded CIP services– Devices already understand this– Services could simply be encoded in adocument– High reuse but not human readable orindependently extensible

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

9How do they stack up?
AutomationML Custom Existing
PolicyJSONLanguage
like Rego
Document Format 101010

Encoded CIP Explanation
Commands

Authenticity

1010108

Confidentiality

1010108Versioning

1010108

Technical Track© 2023 ODVA, Inc.

10

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

All options provide data in a document
formatAutomationML, JSON, and most existing
policy languages already have mechanisms
for applying a digital signature. A custom fileof encoded CIP commands would need todefine a mechanism or choose from one of
the many file signing formats.
Essentially the same scoring and same
reasoning as for authenticity
Once again, the same reasoning holds;
existing languages can use existingversioning
www.odva.org

10How do they stack up?
AutomationML Custom
JSONAutomaticDiscovery

n/an/aConfiguration
Retry

99Trigger a
Reconfiguration

99

Technical Track© 2023 ODVA, Inc.

Existing Encoded CIP Explanation
PolicyCommands
Languagelike Rego
None of these technologies provide this, it
n/an/awould need to be added through anothermeans like DNS-SD
AutomationML, JSON and existing policy
97
languages can easily encode this via a namevalue pair, or encoded CIP commands as those
don’t have a seamless way to do thisSame reasoning as for Configuration Retry
972023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

11How do they stack up?
AutomationML Custom
JSON

610

Existing Encoded Explanation
PolicyCIPLanguage Commandlike Rego s
JSON is a very lightweight technology and would be210

Human Readable 899

Suitable for anembeddedenvironment

Technical Track© 2023 ODVA, Inc.

specifically tailored to this use case, therefore it is highly
efficient. Many of the existing languages are not well
suited to an embedded space. AutomationML is used insome embedded applications, but is feature rich andbuilt on XML, which is not very lightweight. CIPcommands are already used in the embedded space, so
this option is also very well suited.

32023 Industry Conference & 22nd Annual Meeting
All rights reserved.

JSON and many existing languages are very
human readable, AutomationML is a bit more
complex but still fits here. CIP commands
however are not generally human readable.
www.odva.org

12AutomationML Custom
JSON

Optimized for CIP 6Totals

Technical Track© 2023 ODVA, Inc.

97886

Existing Encoded Explanation
PolicyCIPLanguage Commandlike Rego sA custom JSON for CIP Security policy is well110suited to delivering CIP, and of course CIP
commands are perfectly suited to this task.
AutomationML is not, and many existing policy
languages are not possible to use for thispurpose.
702023 Industry Conference & 22nd Annual Meeting
All rights reserved.

71

www.odva.org

13

Conclusions•••

This is a big step forward toenable security on more use
cases, especially for IIoT
JSON with a custom schema
seems like the best option
Spec enhancement to follow– Being worked on in SIG rightnow

Technical Track© 2023 ODVA, Inc.

2023 Industry Conference & 22nd Annual Meeting
All rights reserved.

www.odva.org

14