By Lina Hope 
Written by Bruce Cloutier | August 11, 2026
The Cybersecurity and Infrastructure Security Agency (CISA) has issued an unambiguous mandate: the era of "set it and forget it" for industrial operational technology (OT) must end. As the public internet continues to bleed into the industrial control space, the agency’s warnings regarding exposed OT devices have grown increasingly urgent. CISA’s directive is clear—remove OT from the public internet, enforce robust authentication, and harden network perimeters. While this guidance is both correct and necessary, it raises a profound, often overlooked question: Must every defensive measure be an escalating arms race of increased computational overhead, stronger cryptography, and more powerful hardware?
For the engineer tasked with maintaining deterministic industrial processes, the answer should be "no." There is a vital, often ignored middle ground between total air-gapping and the consumption of finite processing power by defensive overhead. By rethinking how we handle unsolicited network traffic, we can effectively neutralize the background noise of the internet without demanding more from the controllers themselves.
The Reality of a Hostile Digital Landscape
To understand the necessity of this new approach, one must first look through the eyes of an internet-facing device. Any IT professional who has monitored raw, unfiltered traffic hitting an exposed interface knows that the internet is not a neutral utility; it is a relentlessly hostile environment.
Within minutes of a device appearing on the public web, it is subjected to a gauntlet of automated abuse: port scanning, protocol fingerprinting, credential stuffing, and connection probing. Most OT operators remain blissfully unaware of the intensity of this barrage because their devices are tucked behind corporate firewalls. However, for those operating on the front lines, the traffic is deafening.
At the core of the JNIOR controller, the JANOS operating system was designed to bridge the divide between IT and OT requirements. This has turned the JNIOR into an unintentional, yet invaluable, laboratory for observing modern cyber-threats. By intentionally exposing units to the unfiltered public internet, we have gained a clear view of the "background radiation" of malicious activity—a persistent, automated, and indiscriminate force that defines the current state of global connectivity.
The Myth of "Targeted" Attacks
A common misconception in cybersecurity is that all attacks are "Stuxnet-class" events—sophisticated, state-sponsored, and hyper-targeted. In reality, the vast majority of threats facing OT infrastructure today are the result of indiscriminate, automated "botnets" sweeping the address space.
These automated systems do not know what they have found. They are merely searching for listening ports or vulnerable services to add to a list, often to be sold or exploited later. The danger here is not necessarily a targeted strike on a specific facility, but the sheer volume of "knocks on the door."
For a controller, every "knock" comes at a price. When an attacker initiates an SSH handshake, the controller is forced to negotiate encryption and evaluate credentials. This consumes CPU cycles that were intended for monitoring sensors or adjusting actuators. In a high-stakes industrial environment, this creates a secondary threat: a self-inflicted Denial-of-Service (DoS) condition, where the controller is so busy processing authentication requests from malicious scanners that it struggles to maintain the deterministic timing required for its core operations.
Defining "Internet-Facing": A Hidden Exposure
The definition of an "internet-facing" device is often misunderstood. It is not limited to controllers with a direct public IP address. In many modern environments, the danger lies in "hidden" exposures created by network architecture.
When an organization uses Network Address Translation (NAT) and port forwarding to allow remote access to a controller, the device is, for all intents and purposes, on the public internet. A router might be configured to forward SSH or web traffic from an external port to an internal IP address. To a remote scanner, the result is identical: they have found a listening service that responds to requests.
The challenge for the OT professional is determining if their controller is actually being reached. On the JNIOR, the NETSTAT -M command provides a real-time window into connection attempts. When a device that is supposedly shielded by a corporate firewall begins reporting connection attempts from random public IP addresses, it is a red flag that an upstream configuration is leaking traffic. Identifying this exposure is the first step toward reclaiming the security of the network.
The Strategy of Invisibility: SYN Greylisting
If the objective is to protect the controller, we must move beyond the binary of "permit" or "deny." We need to shift the burden of effort.
In the realm of email, "greylisting" has long been used to filter spam. It works on a simple economic principle: legitimate mail servers are designed to retry a delivery if they receive a temporary failure, whereas spam bots, moving at massive scale, rarely bother to wait.
We have applied this same principle to the TCP/IP stack in the form of SYN Greylisting. When enabled, the controller ignores the first SYN packet (the initial request to connect) from an unrecognized source. It returns no SYN-ACK. To a standard, automated scanner looking for a quick response, the device appears invisible—as if it doesn’t exist.
However, a legitimate client, operating according to standard TCP protocol, will retransmit its SYN request after a short interval. The JANOS system recognizes this persistence, notes the retry, and allows the connection to proceed. This approach requires almost zero additional computational power, as it occurs at the driver level, long before the system starts the expensive process of encryption or authentication.
Chronology of a Failed Defense: The "Shields Down" Test
To validate the efficacy of this strategy, we conducted a controlled experiment. We took a JNIOR unit and disabled its greylisting and blacklisting protections, leaving it fully exposed to the public internet.
The results were immediate and catastrophic for the device’s performance:
- Initial Exposure: The controller was flooded with SSH login attempts.
- Resource Exhaustion: Each SSH connection required the CPU to perform public-key cryptography. Processor usage spiked to 95 percent.
- System Instability: The sheer volume of connection-processing tasks prevented the controller from servicing its primary industrial functions.
- The Watchdog Reset: Eventually, the system watchdog, detecting that the controller was no longer responsive to its core tasks, triggered a hard reboot.
When we re-enabled SYN Greylisting, the contrast was stark. The "background noise" of the internet was effectively muted. The controller’s CPU returned to its idle state, and the device regained its determinism. By simply refusing to participate in the initial handshake with unknown entities, the controller remained invisible to the vast majority of indiscriminate scanners.
Implications for Industrial Cybersecurity
The lesson here is profound: industrial cybersecurity cannot be a perpetual cycle of buying faster processors to handle more complex security overhead. We must embrace "lightweight" defensive strategies that align with the reality of industrial operations.
The implications for the industry are significant:
- Efficiency: Security must not come at the cost of deterministic performance.
- Asymmetry: We should shift the cost of engagement back to the attacker. If a botnet has to expend extra effort to connect, it will move on to an easier target.
- Standardization: Capabilities like SYN Greylisting should not be proprietary curiosities. They should be considered for implementation in embedded TCP/IP stacks across the board.
Conclusion: A Call for Broadened Conversations
CISA’s warnings are a vital call to action. We must continue to enforce strict password policies, eliminate unnecessary services, and tighten firewalls. However, these steps are only one part of the puzzle. We need to introduce a new layer of strategy that focuses on reducing the attack surface by making our controllers less visible to the automated systems that plague the modern internet.
By adopting techniques that prioritize resource efficiency and leverage the fundamental behaviors of network protocols, we can protect our infrastructure without compromising the very tasks these controllers were built to perform. If a few lines of code can prevent an attack from ever reaching the authentication phase, why are we still forcing our controllers to "answer the door" to every stranger in the neighborhood?
It is time to stop the arms race and start playing smarter. The tools exist; the behavior is understood; and the safety of our industrial systems depends on our ability to distinguish between a legitimate request and the relentless, meaningless noise of the internet.
Sagoh 
Pevita Pearce 
Layla Zulfa 