Listen to this Post
Introduction:
The traditional SCADA (Supervisory Control and Data Acquisition) paradigm relies on centralized servers, databases, and complex software layers to manage industrial processes. However, a new architectural pattern is emerging from the operational technology (OT) community: “SCADA-less.” This is not a product, but a design philosophy where resilience is paramount. In a SCADA-less architecture, local control and monitoring continue to function even if the central database, network, or HMI fails. This shift toward lightweight, distributed intelligence is redefining how we approach security and reliability in Industrial Internet of Things (IIoT) and critical infrastructure environments.
Learning Objectives:
- Understand the core principles of SCADA-less architecture and how it differs from traditional OT designs.
- Learn how to implement local failover and data buffering mechanisms to ensure operational continuity.
- Explore the security implications of distributed control and how to harden edge devices against cyber threats.
You Should Know:
1. The SCADA-Less Philosophy: Control at the Edge
The essence of a SCADA-less system is the decoupling of control from the central monitoring plane. Eddy neves’ post highlights that in this architecture, “control must continue if everything else fails.” This means that the intelligence responsible for running a process (like a Programmable Logic Controller or a Remote Terminal Unit) does not depend on a constant connection to a server to execute its primary function. The monitoring layer becomes a consumer of data rather than a master of operations.
To understand this practically, consider how a traditional Windows-based SCADA client polls an RTU for data. In a SCADA-less model, the RTU publishes its status locally. If the network goes down, the local HMI (Human-Machine Interface) at the machine level continues to show real-time data because it is reading directly from the controller or a local data broker.
- Simulating a SCADA-Less Environment with Docker and MQTT
To test a lightweight, resilient architecture, we can simulate a simple SCADA-less setup using open-source tools. This stack uses MQTT (a lightweight messaging protocol) to decouple data producers from consumers.
Step-by-step guide for Linux (Ubuntu/Debian):
1. Install Docker and Docker Compose:
sudo apt update sudo apt install docker.io docker-compose -y sudo systemctl start docker sudo systemctl enable docker
- Create a `docker-compose.yml` file for the message broker and a data simulator:
version: '3' services: mosquitto: image: eclipse-mosquitto:latest container_name: mqtt_broker ports:</li> </ol> - "1883:1883" volumes: - ./mosquitto/config:/mosquitto/config restart: unless-stopped simulator: image: alpine:latest container_name: data_simulator command: sh -c "apk add mosquitto-clients; while true; do mosquitto_pub -h mosquitto -t 'sensor/temperature' -m $$(echo $$((20 + RANDOM % 10))); sleep 5; done" depends_on: - mosquitto
3. Run the stack:
sudo docker-compose up -d
4. Simulate a “Database Failure”: Subscribe to the data locally. Even if a central database is offline, the `simulator` container continues publishing to the `mosquitto` broker. Any local HMI or historian subscribing to the broker will continue receiving data, proving that data collection is not a single point of failure.
On the host machine, subscribe to see the live feed sudo apt install mosquitto-clients -y mosquitto_sub -h localhost -t "sensor/temperature"
3. Implementing Local Data Buffering for Network Outages
A key tenet of SCADA-less is that “the network cannot be a prerequisite.” If the connection to the central server drops, edge devices must store data locally and forward it when connectivity is restored (store-and-forward). This is often handled by the communication protocol itself or by middleware like Node-RED.
Node-RED Flow for Data Buffering:
- Install Node-RED on an edge device (like a Raspberry Pi): `bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)`
2. Run Node-RED: `node-red-start`
- Access the flow editor at
http://<device-ip>:1880.
4. Build a resilient flow:
- Inject a simulated temperature value.
- Connect to an MQTT output node (to send to the cloud).
- Crucially, add a “Queue” node (node-red-contrib-queue) or a “Tail” node. Configure it to store messages in memory or on disk if the MQTT broker is unreachable.
- When the MQTT connection is restored, the queue releases the stored data, ensuring no data loss during the network interruption.
- Hardening the Edge: Security in a Distributed Model
While SCADA-less improves operational resilience, it expands the attack surface. If a central server is compromised in a traditional model, the process might still run, but in a SCADA-less model, attackers may target the edge devices directly. Harden Linux-based edge devices using these commands:
Linux Hardening Commands:
1. Remove unnecessary packages sudo apt purge xserver-xorg If it's a headless server sudo apt autoremove <ol> <li>Harden SSH sudo nano /etc/ssh/sshd_config Set: PermitRootLogin no Set: PasswordAuthentication no (Use SSH keys only) Set: AllowUsers specific_username sudo systemctl restart sshd</p></li> <li><p>Set up a strict firewall (UFW) sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 1883/tcp comment 'MQTT' sudo ufw allow 22/tcp comment 'SSH' sudo ufw enable</p></li> <li><p>Implement immutable tags for OT devices (if using Proxmox or similar) pct set <container-id> --features keyctl=1,nesting=1
5. SCADA-Less and the “No Database” Constraint
The original post states “the database must not dictate operation.” In practice, this means the historian (the database that stores trends and logs) is a downstream consumer, not an upstream requirement. You can achieve this using tools like Telegraf, InfluxDB, and Grafana, where Telegraf agents collect data locally and buffer it.
Windows Configuration (Using Telegraf):
1. Download Telegraf from the InfluxData website.
- Edit the `telegraf.conf` file to define inputs (e.g., `[[inputs.win_perf_counters]]` for CPU/Memory) and outputs.
- Configure the `outputs.influxdb` plugin with a `buffer` size.
[[outputs.influxdb]] urls = ["http://central-server:8086"] Central server database = "telegraf" retention_policy = "" write_consistency = "any" timeout = "5s" If the connection fails, buffer up to 10,000 metrics in memory metric_buffer_limit = 10000
- Run Telegraf:
telegraf.exe --config telegraf.conf. If the central InfluxDB goes down, Telegraf holds the data in memory and pushes it once the database recovers.
6. Vulnerability Exploitation and Mitigation in SCADA-Less Systems
If edge devices become the primary source of truth, exploiting them becomes a primary goal for attackers. Consider a scenario where an attacker gains access to the local MQTT broker (port 1883 often left open and unencrypted).
Simulated Attack (For Educational Purposes):
From an attacker's machine on the same network 1. Scan for open MQTT brokers nmap -p 1883 --open -sV 192.168.1.0/24 <ol> <li>Subscribe to all topics to eavesdrop (if no authentication) mosquitto_sub -h 192.168.1.100 -t "" -v</p></li> <li><p>Publish malicious set points If the topic is 'actuator/valve/status', send a close command mosquitto_pub -h 192.168.1.100 -t "actuator/valve/command" -m "CLOSE"
Mitigation Steps:
- Enable TLS/SSL on MQTT: Generate certificates and configure the broker (
mosquitto.conf) to require them.listener 8883 cafile /etc/mosquitto/ca.crt certfile /etc/mosquitto/server.crt keyfile /etc/mosquitto/server.key require_certificate true
- Implement Network Segmentation: Place edge devices and HMIs in a dedicated OT VLAN with strict access control lists (ACLs) preventing direct access from the corporate IT network.
What Undercode Say:
- Resilience is Security: The SCADA-less movement forces a re-evaluation of “availability” as a security pillar. By removing central dependencies, architects ensure that processes remain available even during a cyber-attack targeting the IT/OT boundary.
- The Perimeter is Now the Endpoint: This architecture confirms that the classic castle-and-moat security model is dead. Security controls must move to the device level. Every PLC, RTU, and edge gateway must be treated as a potential trust boundary, requiring encryption, authentication, and regular patching.
The shift toward SCADA-less architecture represents a maturation of OT thinking, borrowing concepts from distributed systems and microservices used in the cloud. It acknowledges that perfect, constant connectivity is a myth, and that industrial processes must be designed to survive network partitions and system failures gracefully. However, this distribution of intelligence requires an equally distributed security model. Engineers must now embed security into the firmware of devices and the configuration of local brokers, rather than relying solely on firewalls to protect a central data center. This trend will accelerate as IIoT devices proliferate, making operational resilience a function of robust edge design rather than central oversight.
Prediction:
As SCADA-less patterns become standard, we will see a rise in “edge-native” security solutions. Traditional network-based intrusion detection systems (IDS) will become less effective as traffic is encrypted end-to-end and never reaches a central point. The future of OT security will lie in endpoint detection and response (EDR) for embedded Linux systems and anomaly detection directly on the PLC or gateway, using AI to understand baseline behavior at the individual machine level rather than the plant level.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Eddy Neves – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
