OT Deployment

Stellar Cyber has a flexible deployment model and a unified platform that natively supports Operational Technology (OT) security use cases. This allows immediate deployment and future proofing to new security demands. Defending both IT and OT from a single platform results in a more efficient and cost effective approach to Security Operations.

Introduction

Stellar Cyber’s integrations, Connectors and Parsers, Sensors, approach to Detections, and Partner Ecosystem address the main challenges of getting complete visibility across both IT and OT environments. Those challenges are typically:

• Ability to integrate any IT and OT source in a single SOC Platform—Addressed by Connectors and Parsers

• Inability to get agent-based solutions in OT environment, thus a need for agentless security solutions—Addressed by Security Sensors

• Need for broad, out-of-the-box, detection coverage across IT, OT, and IT or OT lateral movement use cases—Addressed by approach to Detections

• Network architecture requirements restricting unidirectional data flow or inability to deploy any sensors in an OT environment—Addressed by Partner Ecosystem

Use this guide to understand the in-depth capabilities of Stellar Cyber in OT environments, the detection use cases covered, and the deployment scenarios for network architectures and risk levels.

Technical Capabilities

Multiple Stellar Cyber components play different roles in getting coverage into OT environments and providing detection coverage. If not already familiar, it is recommended to be acquainted with Stellar Cyber’s architecture prior to continuing this guide.

The following table lists the core technologies leveraged by Stellar Cyber and the associated component in OT environments.

Technology	Stellar Cyber Product Component	Details
DPI	Security & Linux Sensors	3700 total protocols, 57 SCADA (includes iccp and dnp3), 18 IoT; entire support list detailed below. See DPI SCADA Reference.
IDS	Security & Linux Sensors	Real time updates from paid signature feeds.
Malware AV	Security Sensors	Over the wire file reconstruction and classification.
NTA / NDR	Data Processor	Supervised and unsupervised Machine Learning.
Asset Discovery	Data Processor	Asset discovery and resolution from all data sources.
Vulnerability Management	Security Sensor	Third party vulnerability management sensors can be installed on a Security Sensor (for example, Tenable).
DMZ Log Collection	Connectors, Logs via Security Sensors, Linux & Windows Sensors	Ability to collect logs from all sources within DMZ (for example, Windows jump host, Zero Trust Solution).
Level 3 Device Log Collection	Logs via Security Sensors, Linux & Windows Sensors	Ability to collect logs from all sources within Level 3 (for example, Engineering Workstation, Remote Access Server).
OT Product Log Collection	Logs via Security Sensors	Ability to collect logs from OT security products (for example, Nozomi) and OT devices (for example, Honeywell).
Incident Correlation	Data Processor	Analyze and investigate all alerts, across IT and OT, together automatically.

DPI SCADA Reference

IDS Signature Reference

Stellar Cyber’s Security Sensors are continuously updated with signatures from Proofpoint ET Pro out-of-the-box. The ruleset contains coverage against OT attacks, for example, SCADA and IoT. With an upcoming release of Stellar Cyber’s Threat Intelligence feature, all signatures will become searchable in the platform itself.

Detection Use Cases

From the technologies described above, visibility and detections are created that can be used to cover key use cases related to defending OT.

Use Case	Methodology
Non-Standard SCADA Protocol Detection	DPI engine detects all protocols occurring within SCADA network Custom Detection: Alert if anything outside standard protocols (for example, iccp & dnp3) occurs in the SCADA network (defined by subnet, host list, etc.)
SCADA Network Segmentation Violation	All traffic flows (east-west, north-south) is monitored via Sensors, Logs (for example, firewalls), and Connectors (for example, endpoint products) Alert if SCADA hosts communicate with anything outside of other SCADA hosts or DMZ (defined by subnet, host list, etc.)
Network Attack Detection	IDS, with commercial signature feeds, will pick up thousands of network-based attacks
Malicious or Suspicious File	Malware AV will reconstruct files over the wire and detect if they are malicious or suspicious Can optionally submit to cloud-based Malware Sandbox if there is Internet access
Anomalous Communication / Process / Port / Data Transfer	“Normal” is learned for all environments, including SCADA If a SCADA asset has an anomalous communication with another asset, process launch, port usage, data transfer, NDR alerts
IT to OT Lateral Movement	All data across IT, DMZ, and OT are collected and analyzed Alerts are correlated together to detect incidents that start / end in IT, and laterally move to OT

Deployment Scenarios

Getting visibility into OT environments depends on a number of factors of how those networks are managed to include connectivity and managed infrastructure. The following deployment scenarios will reference the Purdue Model, which is a network and device segmentation guideline for Industrial Control Systems (ICS). For an overview of the Purdue Model, reference this overview from ZScaler.

Stellar Cyber can be flexibly deployed depending on the OT network architecture and risk levels. Use the following table for understanding which deployment scenario is best suited for your enterprise. For the most comprehensive solution, Stellar Cyber recommends deployment scenario (1). For the easiest to deploy, easiest to maintain, and lowest risk solution, Stellar Cyber recommends deployment scenario (2).

Deployment Scenario	Description	Technologies Required
(1) Sensors Deployed to Level 3 & 2 Switches	Security Sensors are deployed, as hardware or VMs, in Level 3 and 2, and mirror relevant switch traffic. When you would do this It is acceptable to put sensors in Level 3 and below, and you want full visibility and capability.	Security Sensors (Optional) Data Diode (Optional) Breakout Network TAP
(2) Sensors Deployed in Level 4 With Traffic Visibility	Security Sensors are deployed, as hardware or VMs, in Level 4 and receive mirrored traffic from Level 3 switches and below. When you would do this It is too risky to put products in Level 3 and you want easy updates on the sensors.	Security Sensors Aggregator Network TAP Packet Broker (Optional) Data Diode TAP
(3) Sensors Deployed in Level 4 With No Traffic Visibility	Security Sensors are deployed, as hardware or VMs, in Level 4 and receive any available syslog sources from Level 3 and below. When you would do this When the network is not willing to accept anything new in Level 3 and below but there is some logging infrastructure in place.	Security Sensors (Optional) Data Diode TAP
(4) Airgap	If an OT environment is truly air gapped, there is no network path to receive any telemetry back to Stellar Cyber. Stellar Cyber can be deployed in an air gapped network, however it would be unproductive to have a single instance of Stellar Cyber for a single air gapped IT environment.	N/A
(5) Combination of Scenarios	If certain OT environments have different risk levels or networking infrastructure, some combination of scenarios (1), (2), and (3) can be deployed.

In the subsequent scenario subsections, diagrams detail specific capabilities deployed in certain locations, along with what telemetry is collected from where (both color coded for reference).

(1) Sensors Deployed to Level 3 & 2 Switches

Pros: This scenario is the maximal security coverage because it allows for capabilities like Vulnerability Management to be deployed and device level syslog to be easily collected.

Cons: It involves installing agentless software or new hardware in Level 3 or below, which comes with risk and bureaucratic process.

The following diagram shows several integrations and components deployed. Not everything here is strictly necessary (such as, DMZ server logs, Firewall Syslog, OT Device Syslog), however recommended for maximal coverage.

Components and integrations deployed:

• Device Syslog (Red)—Any OT device capable of forwarding syslog events sends events to a Security Sensor to then forward to the Data Processor

• Security Sensors (Orange)—Security Sensors are deployed off of core OT switches, mirroring traffic to perform capabilities including Network Traffic Analysis (NTA), Deep Packet Inspection (DPI), Intrusion Detection System (IDS), Malware Sandbox, and Vulnerability Management (VM)

• Server Sensors (Purple)—Small agents used for log collection can be deployed on DMZ servers

• Firewall Syslog (Blue)—DMZ and above Firewalls can forward syslog to the Data Processor or Security Sensors

• Data Processor (Grey)—The Data Processor can be deployed on-premise or as a SaaS solution

Data Diode TAP Usage

Breakout Network TAP Usage

(2) Sensors Deployed in Level 4 With Traffic Visibility

Pros: This scenario is the easiest to deploy and less risky from a perspective of introducing new products within the OT environment, while maintaining much of the visibility from deployment scenario (1). Security Sensors can auto update since they have access to download software from the Data Processor.

Cons: It does involve acquiring additional networking technologies, specifically Aggregator Network TAPs and a Packet Broker. Some log collection may be more challenging if syslog cannot be easily streamed out of the environment, and certain capabilities like Vulnerability Management will not be deployable to Level 3 and below.

The following diagram shows several integrations and components deployed. Not everything here is strictly necessary, however recommended for maximal coverage.

Components and integrations deployed:

• Device Syslog (Red)—Any OT device capable of forwarding syslog events sends events through the Data Diode TAP to a Security Sensor to then forward to the Data Processor

• Security Sensor (Orange)—A Security Sensor is deployed in Level 4 receiving mirrored traffic from the Packet Broker in Level 3, which allows it to perform capabilities including Network Traffic Analysis (NTA), Deep Packet Inspection (DPI), Intrusion Detection System (IDS), and Malware Sandbox

• Firewall Syslog (Blue)—Level 4 Firewalls can forward syslog to the Data Processor or Security Sensors

• Data Processor (Grey)—The Data Processor can be deployed on-premise or as a SaaS solution

• Aggregator TAP (Green)—Mirrors network traffic from one or many switches with the purpose of forwarding to a Packet Broker

• Packet Broker (Green)—Receives and forwards traffic from one or many Aggregator TAPs or Network Breakout TAPs to then forward as a single stream to a Security Sensor

• Data Diode TAP (Green)—Physically enforces unidirectional communication between Level 4 and Level 3

Data Diode TAP Usage

(3) Sensors Deployed in Level 4 With No Traffic Visibility

Pros: This scenario does not place any new products in the OT environment. Security Sensors can auto update since they have access to download software from the Data Processor.

Cons: Losing traffic level visibility in the OT environment significantly limits detection use cases.

The following diagram shows several integrations and components deployed. Not everything here is strictly necessary (such as, DMZ server logs, Firewall Syslog, OT Device Syslog), however recommended for maximal coverage.

Components and integrations deployed:

• Device Syslog (Red)—Any OT device capable of forwarding syslog events sends to a Security Sensor to then forward to the Data Processor

• Security Sensor (Orange)—A Security Sensor is deployed in the DMZ and is only acting as a Log Forwarder since it has no access to OT network traffic

• Server Sensors (Purple)—Small agents used for log collection can be deployed on DMZ servers

• Firewall Syslog (Blue)—All DMZ and above Firewalls can forward syslog to the Data Processor or Security Sensors

• Data Processor (Grey)—The Data Processor can be deployed on-premise or as a SaaS solution

(4) Airgap

Pros: Strict network segmentation between OT and IT environments.

Cons: Not any security gains in practice compared to a Data Diode preventing data transmission one way at the physical layer. Additionally, a true airgap is operationally painful, and inherently obscures security visibility.

(5) Combination of Scenarios

The deployment scenarios above can easily be combined for enterprises that have multiple OT environments that need various approaches to security. For example, a water treatment enterprise may have many small sites and a single large water processing site. For the small sites, each one implements Deployment Scenario (2). However for the large site, Deployment Scenario (1) is implemented. All data ends up at a single Data Processor to defend all OT environments in addition to any IT environments.

Technology Options For OT Networking

Stellar Cyber is, from a technical perspective, agnostic to different networking solution providers for Data Diodes, Network Breakout TAPs, Aggregator TAPs, and Packet Brokers. However, Garland Technology is Stellar Cyber’s preferred and recommended vendor to work with as they have an extensive portfolio of products completely focused on the different networking and visibility challenges faced by OT environments.