Skip to main content

Deployment models

Cyprobe supports three deployment models depending on network architecture, security policy, and connectivity constraints.

1. Passive tap (mirror port)​

The simplest and safest deployment. Cyprobe runs on a host connected to a SPAN / mirror port on the OT network switch.

┌─────────────────────────────────────────────┐
│ OT Switch │
│ PLC ──┬── HMI ──┬── SCADA Server │
│ │ │ │
│ └─────────┴── SPAN Port ──> Sensor │
│ [cyprobe] │
└─────────────────────────────────────────────┘

Setup​

  1. Configure a SPAN / mirror port on the OT switch to copy traffic to a dedicated port.
  2. Connect the sensor host to the mirror port.
  3. Run cyprobe in passive mode:
sudo cyprobe passive --interface eth0 --duration 0 --format json \
--output /var/log/cyprobe/assets.json

Characteristics​

  • Zero risk -- no packets injected into the OT network.
  • Full protocol visibility -- sees all traffic traversing the mirrored port.
  • Limitations -- cannot see traffic on segments not mirrored. Cannot extract device identity details that require active queries.

Any x86-64 or ARM64 Linux host with at least one Ethernet port. A Raspberry Pi 4 with a USB Ethernet adapter is sufficient for networks under 1 Gbps.

2. Inline gateway (ARM appliance)​

Cyprobe runs directly on an OT gateway appliance (Moxa, Advantech, or similar ARM-based industrial hardware) that sits between the OT network and the IT/DMZ network.

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ OT Network │────>│ Gateway │────>│ IT / DMZ │
│ (PLCs, HMIs)│ │ [cyprobe] │ │ │
└──────────────┘ └──────────────┘ └──────────────┘

Setup​

  1. Cross-compile cyprobe for the gateway's architecture (see Installation).
  2. Deploy the binary and rules to the gateway.
  3. Run passive mode on the OT-facing interface:
sudo cyprobe passive --interface eth1 --duration 0 --format json \
--output /var/log/cyprobe/assets.json
  1. Optionally run active probes on a schedule:
# cron: daily at 02:00
0 2 * * * sudo cyprobe active --targets 192.168.1.0/24 --active-confirm \
--safelist /etc/cyprobe/safelist.yml --format sarif \
--output /var/log/cyprobe/active-$(date +\%F).sarif

Characteristics​

  • Persistent monitoring -- runs continuously on dedicated hardware.
  • Low footprint -- cyprobe uses under 64 MB RAM and minimal CPU.
  • Active probing -- gateway position allows safe active probes with rate limiting.
  • Considerations -- gateway must be hardened. Firmware updates for the gateway itself should be managed separately.

Tested hardware​

DeviceArchitectureNotes
Moxa UC-8100Aarmv7-unknown-linux-gnueabihf512 MB RAM, dual Ethernet
Advantech EIS-D210aarch64-unknown-linux-gnu2 GB RAM, 4x GbE
Raspberry Pi 4aarch64-unknown-linux-gnu4 GB RAM, USB Ethernet
Generic x86 gatewayx86_64-unknown-linux-gnuAny thin client / mini PC

3. Cloud-connected (one-way HTTPS upload)​

Cyprobe runs on-site (passive tap or gateway) and periodically uploads results to the Cybrium platform. The connection is one-way outbound HTTPS -- no inbound ports, no VPN, no tunnel.

┌─────────────────────┐ ┌─────────────────────┐
│ OT Network │ │ Cybrium Platform │
│ ┌───────────────┐ │ │ │
│ │ Sensor │ │ HTTPS │ Asset Graph │
│ │ [cyprobe] │──│────────>│ Posture Dashboard │
│ └───────────────┘ │ POST │ Drift Alerts │
│ │ │ │
└─────────────────────┘ └─────────────────────┘

Setup​

  1. Deploy cyprobe on-site via either model above.
  2. Configure the upload endpoint:
export CYBRIUM_API_KEY=sk-...
export CYBRIUM_API_URL=https://app.cybrium.ai
  1. Schedule periodic uploads:
# cron: every 15 minutes
*/15 * * * * cyprobe upload /var/log/cyprobe/assets.json \
--title "Plant-A $(date +\%F-\%H\%M)"

Characteristics​

  • Outbound-only -- only HTTPS POST to the platform API. No listening ports.
  • Works through firewalls -- standard HTTPS on port 443.
  • Air-gap compatible -- for fully isolated networks, copy the output file to an internet-connected host manually and run cyprobe upload there.

Network requirements​

DirectionProtocolDestinationPort
OutboundHTTPSapp.cybrium.ai443

No inbound connections are required. The sensor never receives commands from the platform.

Choosing a model​

CriterionPassive tapInline gatewayCloud-connected
Risk to OT networkNoneLowNone
Active probingNoYesNo (upload only)
Continuous monitoringYesYesPeriodic
Platform integrationManualManual/cronAutomated
Air-gap supportYesYesFile transfer
Hardware costLowMediumLow

All three models can be combined. A typical deployment uses passive taps on each network segment, with one gateway for active probing, and cloud-connected uploads for centralized visibility.