Operational Technology Discovery deployment scenarios

Deployment scenarios for OT Discovery vary based on a network's architecture. Use these scenarios to help determine how to deploy the OT Discovery components in your OT environment.

Note:

The OT Discovery Collector can be deployed to the same locations as the Discovery Sensor for OT.

General recommendations

General recommendations and guidance are listed in each scenario in these sections. Not all networks are the same. The requirements in this section are a generalization for the scenario. Consider factors such as segmentation level, communication pathways, network traffic, redundancy, and environmental conditions. For resource recommendations for the Operational Technology Discovery components see the Resources for OT Discovery System section.

Flat network architecture across multiple sites

A flat network architecture is a network design that has all available Discovery Console for OT, Discovery Sensor for OT, and OT Discovery Collector connected to a single network, where the Sensors and Collectors can communicate with each other directly.

You can have one or more sites that communicate with each other.

Figure 1. Flat network

The Console, Sensors, and MID Server connect at Purdue level 3.5 and push data through the switches and the firewall to the ServiceNow instance for ingestion.

Components in the flat network

The following are the components in a flat network.

• Discovery Console for OT and Discovery Sensor for OT.
• A localized appliance or VM that serves as the command-and-control interface for asset discovery and communication in its respective segment. This appliance or VM manages credentials, protocol handlers, and initiates querying operations locally. In such a scenario, a typical deployment means that one Console covers multiple sites.
• Deploy the Console at a layer where the MID Server can connect to the Console and the ServiceNow instance.
• Deploy Sensors based on the desired speed of the discovery. In a truly flat network, a Discovery Sensor for OT can reach all the OT assets in that network. More Sensors in the network can help improve the speed of discovery.

Multiple independent segmented sites

A segmented site architecture is a network design that has the network split into multiple segments. Each segment contains its own Discovery Console for OT and multiples of the Discovery Sensor for OT and the OT Discovery Collector. There is no communication between sites. Each of the segments could be considered a flat network.

Figure 2. Segmented sites

In this OT environment, the network is segmented into three distinct zones for operational clarity, security, and control:

• Site 1 Operational Technology segment
• Site 2 Operational Technology segment
• Physical Security Network segment

Each segment contains its own isolated infrastructure to reduce risk and increase visibility in its respective domain. Components in each segment:

• Discovery Console for OT or VM that serves as the command-and-control interface for asset discovery and communication in its respective segment. It manages credentials, protocol handlers, and initiates scanning operations locally.
• Discovery Sensor for OT is deployed in each segment. The Sensor performs active discovery, collects network traffic, and queries for known protocols (for example, Modbus, DNP3, BACnet). It reports findings to its segment's Console.

The Consoles and Sensors are deployed in their respective network zones and don't have direct outbound access to the internet.

Micro-segmented site with multiple networks

A segmented site architecture with multiple networks is a network design that has more than one network split into multiple segments. Each segment contains multiple network segments and its own Discovery Console for OT and Discovery Sensor for OT.

• Make sure the Sensors and Collectors have a communication pathway to the Console.
• Deploy Sensors in each segment where the Sensor can perform active discovery in the segment and collect network traffic and can scan or query for known protocols (for example, Modbus, DNP3, BACnet). It reports findings to its segment's Console.
• If you use an existing host to do the discovery in the network such as Human Machine Interface (HMI) or Engineering Workstation (EWS), you can install the OT Discovery Collector to perform discovery.

Figure 3. Segmented site with multiple networks

Resources for OT Discovery System

The requirements in this section are a generalization. Consider factors such as segmentation level, communication pathways, network traffic, redundancy, and environmental conditions. Also account for physical constraints when determining network requirements. The following tables provide resource estimates for each OT Discovery component. Review your system requirements beyond these minimums.

Table 1. Discovery Console for OT System requirements

Component	Minimum System Requirements
Discovery Console for OT	16 GB RAM 100 GB Hard drive 2 CPUs

For additional requirements for the Console, see Requirements for Discovery Console for OT installation and Install the Discovery Console for OT.

Table 2. Discovery Sensor for OT System requirements

Component	Minimum System Requirements
Discovery Sensor for OT	2 GB RAM* 100 GB Hard drive 2 CPUs 2 virtual NIC cards *8 GB of RAM is recommend for all queries.

For additional requirements for the Sensor, see .

Collector minimum system requirements

The OT Discovery Collector can be installed and run on either a Windows OS or a Linux OS.

Component Operating System	Minimum System Requirements
Windows	The OT Discovery Collector installation is compatible with Windows 10 or Windows 11 systems. The required Windows (10 or 11) environment for the OT Discovery Collector is x86_64. ARM or Apple Silicon devices are not supported. See Install the OT Discovery Collector on a Windows system.
Linux	See Install OT Discovery Collector on a Linux system for specific information.