The CISA Alert: Security Beyond Solitary Confinement

Summary: CISA is right to sound the alarm over Internet-exposed operational technology. But must every unwanted connection be answered with more authentication, stronger cryptography, and more processing power? There are remarkably lightweight ways to make malicious automation work harder while allowing OT controllers to concentrate on the job they were installed to do.

>> The Alert Is Worth Taking Seriously

CISA has issued an urgent warning about the continued exposure of operational technology (OT) to the public Internet. The message is direct and deliberately uncompromising: act now. Remove OT connections to the public Internet, change default passwords immediately, restrict remote access, and strengthen authentication and network protections. These are not presented as suggestions for future consideration, but as immediate steps needed to reduce the growing cyber threat to industrial systems. [1]

The urgency is justified. But the growing need for OT connectivity makes one recommendation particularly difficult: simply eliminating the ability to communicate is not always an option. Nor should the alternative be limited to an escalating cycle of stronger cryptography, greater computational requirements, and eventual hardware replacement. There is another class of defense that deserves far more attention: techniques that reduce the attacker’s opportunity while consuming almost none of the controller’s resources. Perhaps it is time to bring some of these to the table and broaden the conversation.

Any IT professional who has observed the unfiltered network traffic at an Internet-facing device knows that the concern is absolutely justified. The public Internet is an extraordinarily hostile environment. Within minutes, an exposed device will encounter port scans, connection probes, login attempts, protocol fingerprinting, credential attacks, and other automated activity. Most people never see any of this and are consequently unaware just how relentless it is.

JANOS, the operating system at the heart of the JNIOR, was purpose-built from the start to support both OT and IT requirements. That has also made JANOS something of a proving ground. While the vast majority of JNIORs operate within air-gapped or otherwise controlled networks, we have intentionally operated units directly on public IP addresses – the worst-case exposure – to observe, understand, and develop defenses against this kind of activity. Watching that traffic in real time quickly changes one’s perspective on what an embedded device should be expected to tolerate.

Strong login credentials are an essential defense, but an attacker does not need to successfully log in to create a problem. A sustained password attack can consume significant processor resources for minutes at a time. Consider an SSH login attack where every attempt requires the controller to negotiate a secure connection before credentials can even be evaluated. As security algorithms become stronger, the computational investment in each unwanted connection increases. The attacker does not need to defeat the cryptography. It need only make the controller perform it. For an OT controller expected to maintain deterministic operation, simply processing the attack becomes part of the threat. Whether intentional or not, the result can begin to resemble a denial-of-service (DoS) attack against the controller.

Have we been addressing the problem or amplifying it?

 

>> Not Every Attack Is Stuxnet

It is useful to distinguish between targeted attacks and the enormous amount of indiscriminate malicious activity constantly circulating on the Internet. Stuxnet is perhaps the classic example of a targeted industrial attack. Its creators understood the systems they intended to compromise, developed sophisticated techniques specifically to reach them, and had a very particular objective. Most hostile Internet traffic is nothing like that.

An almost constant level of ongoing attack is generated by automated systems sweeping enormous address ranges looking for listening ports, recognizable services, vulnerable software, or credentials that just happen to work. The intent might not be “seek and destroy.” The goal might be nothing more than to locate a potential target and add that to a list to be sold to the highest bidder. Those systems generally have no idea what equipment they have found. Yet every response they provoke imposes some cost on the equipment while costing the scanner comparatively little.

That distinction matters. Defending against a determined adversary with detailed knowledge of your equipment is a very different problem from dealing with the relentless background activity of the Internet. Yet both arrive at the same network interface and demand attention from the same finite set of resources. In an OT device, those resources are responsible for monitoring inputs, controlling outputs, executing application logic, and maintaining deterministic operation. There is little benefit in allowing anonymous automated scanners to compete for them.

The obvious response is to prevent as much unnecessary traffic as possible from distracting the controller. In an IT world of routers, firewalls, proxies, and managed switches, does the OT professional really know whether their edge controllers are at risk?

 

>> What Does “Internet-Facing” Mean?

An Internet-facing OT device does not necessarily have its own public IP address. The most obvious—and most exposed—case is a controller assigned a public IP address and connected directly to the Internet. More commonly, the controller resides on a private network behind a router or firewall using Network Address Translation (NAT), where unsolicited Internet traffic normally cannot reach it. That changes when port forwarding is configured. A router might be instructed, for example, to forward incoming SSH or web connections to a specific controller on the private network. The controller still has a private IP address, but one or more of its services are now effectively exposed to the public Internet. From the perspective of an automated scanner, there may be little practical difference. It found a port, sent a request, and something answered.

Not all external connectivity creates that same exposure. A controller that initiates an outbound connection through NAT does not automatically become available for unsolicited inbound connections. Gateways, proxies, VPNs, and properly configured firewalls provide still other architectures for controlling what can reach OT equipment. The important question is therefore not simply whether an OT device is “connected to the Internet,” but what paths exist through the surrounding network for an unsolicited connection to reach it.

For the OT professional, determining whether this exposure exists need not require a detailed audit of the surrounding IT infrastructure. The controller itself can provide useful evidence. On a JNIOR, for example, the NETSTAT -M command monitors network connections and connection attempts in real time. Unexpected incoming connection attempts from public IP addresses are direct evidence that some path through the network exists. If an edge controller sitting behind what is believed to be a protective firewall suddenly begins reporting unsolicited connection attempts from public IP addresses, there is something worth investigating.

If unexpected Internet traffic is reaching an edge controller, it is important to enlist the assistance of network personnel. There may be something upstream that can be done, and others need to be aware of the exposure. But the controller need not remain a passive participant. There are things it can do for itself.

 

>> A Cloak of Invisibility?

There is no shortage of established cybersecurity advice. Change default passwords. Eliminate unused accounts. Disable services and protocols that are not required. Require authentication where it is available. Restrict access through firewalls and other network controls. All of these measures are important, and CISA is right to reinforce them. [2] But this is well-traveled ground. The cybersecurity industry has been repeating much of this advice for years, and there is little value in beating that particular horse again here.

Consider instead the strategic value of invisibility. Much of the malicious activity circulating on the Internet is automated network reconnaissance—looking for targets rather than attacking a specifically selected one. Every response provides information. A reply to a PING confirms that something is there. A SYN-ACK packet confirms that a TCP service is listening. A protocol response may identify the service and perhaps even the equipment behind it. With each exchange, an anonymous scanner learns something more while the controller expends resources providing the lesson.

What if the controller could remain fully accessible to legitimate users while appearing invisible to much of that reconnaissance? Such a capability would not replace passwords, authentication, encryption, or firewalls. Nor would it make the controller invisible to a determined adversary who already knew where to look. But against the enormous background population searching blindly for its next target, invisibility provides a significant strategic advantage. An edge controller has no obligation to announce its presence, identify its services, or spend resources responding to every stranger who knocks.

This deserves to be part of the cybersecurity conversation. Before requiring more processing power to execute stronger defenses against every connection attempt, we should ask how many of those connections need to be entertained in the first place. Reducing the attack surface is good. Reducing the population that can discover that attack surface is better still.

And this is not theoretical. JANOS already provides the JNIOR with such a cloak. It requires no additional hardware, no gateway, no cloud service, and no increasingly complex cryptographic algorithm. The capability is called SYN greylisting.

 

>> SYN Greylisting: Don’t Answer Every Knock

The idea behind greylisting is not new. Email servers have long used greylisting to take advantage of an important difference between legitimate mail systems and systems attempting to operate at enormous scale. A legitimate mail server encountering a temporary refusal is expected to wait and try again. A system attempting to contact millions of potential targets has a very different economic incentive. Time spent repeatedly pursuing one uncooperative address is time not spent discovering thousands of others. Greylisting turns persistence into a simple test of legitimacy. [3]

The same asymmetry exists in automated network reconnaissance and port scanning. A legitimate TCP client is designed with the assumption that packets can be lost. If its initial SYN receives no response, it retransmits. [4] An automated scanner sweeping millions of IP addresses and ports has little incentive to devote the same amount of time to every address that remains silent. Many therefore send a probe, wait briefly for a response, and move on. Forcing a retry imposes a small cost on a legitimate client, but multiplied across millions of potential targets, it imposes additional cost on the scanner as well.

JANOS SYN greylisting exploits exactly that behavior. When enabled, the initial SYN packet requesting connection to an open port is deliberately ignored. No SYN-ACK packet is returned. To a scanner performing a quick sweep, there may appear to be nothing there. A legitimate client, however, retransmits its SYN connection request as TCP was designed to do. If that retry arrives within an appropriate window—not suspiciously fast and not so late that the original attempt has been forgotten—JANOS allows the connection to proceed. No whitelist management is required. The same client must demonstrate the same simple behavior the next time it initiates a connection. The connection delay has minimal impact.

 

 

The result is a remarkably inexpensive filter requiring very little code in the TCP driver itself. Because it operates at that level, the protection automatically applies across listening ports and protocols before authentication, encryption, protocol processing, or application software becomes involved. There is no whitelist to maintain and no additional security service to configure. The controller does not have to determine whether the stranger is malicious. It merely asks the stranger to demonstrate a small amount of persistence before agreeing to spend resources on the conversation. For once, some of the cost of initiating an unwanted interaction has been shifted away from the controller and back toward the stranger knocking on its door.

An automated scanner can, of course, be designed to retry. SYN greylisting is not intended to be an impenetrable barrier. Its value is in refusing to make reconnaissance effortless. Scanners that do not retry receive nothing. Those that adapt must generate additional traffic and devote additional resources to the task. Older automated tools, malware, and worms that never anticipated such behavior may simply fail to discover the device at all. The objective is not to make reconnaissance impossible, but to stop making it unnecessarily easy.

That raises a larger question: why should this capability be limited to JANOS?

 

>> What Happens When You Drop the Shields?

There is an obvious way to determine whether SYN greylisting is actually accomplishing anything: turn it off. We did exactly that on one of the JNIORs intentionally operating on a public IP address. With the protection enabled, the controller routinely spends about 95 percent of its processor time idle even while the surrounding Internet remains busy with reconnaissance and malicious traffic.

With SYN greylisting disabled, that changed dramatically. Automated connection attempts began progressing into the services themselves. SSH was particularly expensive. Each incoming connection could initiate several seconds of public-key cryptography before authentication was even attempted. At times, SSH consumed roughly 95 percent of the available processor resources. During the overnight test, the accumulation of SSH activity eventually prevented processes from yielding for long enough that the JANOS process watchdog interpreted the condition as a failure and rebooted the controller. The system log identified the cause: “SSH Server caused watchdog reset.”

The following morning, we went a step further and disabled the separate IP Blacklister as well. The result provided an unobstructed view of the background Internet. SSH password attacks continued connection after connection. Other clients attempted command-line credentials, web exploits, TLS negotiations, protocol probes, and assorted reconnaissance. One SSH source methodically tried a succession of root passwords, establishing a secure connection for each attempt and forcing the controller to perform the associated cryptographic work before ultimately failing authentication.

The controller continued doing its job, but the effect was obvious to a legitimate user. Interactive SSH response became intermittent enough that at times the controller appeared to have stopped responding. Eventually the requested command would execute. The processor had simply been busy servicing strangers. For an OT controller, that is more than an inconvenience. Processor time being unpredictably diverted into network security directly challenges the goal of deterministic operation. The controller’s first responsibility remains the process it was installed to monitor and control.

Our test JNIOR was deliberately connected using a public IP address so that the activity could be observed without an upstream firewall hiding any of it. That is the extreme case, but the issue is not limited to controllers connected that way. A service exposed through port forwarding presents the same listening port to the public Internet. If unsolicited traffic can reach that port, the controller must deal with it regardless of the network architecture that delivered it.

This illustrates an important distinction. Strong authentication can prevent an attacker from gaining access, but it does not necessarily prevent an attacker from consuming the resources required to reach authentication. The strongest password in the world does nothing to recover the processor time spent determining that the password was wrong.

With SYN greylisting restored, most of those interactions once again disappear before SSH, TLS, the web server, or application software ever become involved. The attack has not been defeated through stronger cryptography. For the overwhelming majority of automated connection attempts, it simply never gets started.

 

>> Let’s Turn the Tables

Industrial cybersecurity cannot become an endless contest in which every increase in malicious activity is answered by requiring the controller to perform still more work. Stronger cryptography, more sophisticated authentication, and increasingly complex security protocols all have their place. They also consume resources. In OT, those resources were purchased first to monitor and control a process, and the expectation is that they will continue doing so deterministically for many years.

SYN greylisting demonstrates another way of thinking about the problem. It does not attempt to identify the attacker. It does not inspect a growing database of threats. It does not require another processor, gateway, subscription, or cloud service. It simply exploits the behavior of legitimate TCP clients to avoid engaging with a large population of automated reconnaissance in the first place. A defense need not be impenetrable to be worthwhile. Sometimes merely refusing to cooperate changes the equation.

JANOS has served as a proving ground for this approach, but SYN greylisting should not remain a JNIOR curiosity. It deserves consideration as a defensive capability in embedded TCP/IP stacks generally. Widespread use could frustrate existing scanners, malware, and worms that do not retry while forcing newer reconnaissance tools to expend additional effort. Legitimate TCP clients already know how to get through. And the implementation can occur before expensive authentication, encryption, or application processing ever begins.

Perhaps the larger lesson is that we need to broaden the industrial cybersecurity conversation. We should continue making authentication stronger and communications more secure. But we should devote equal creativity to defenses that consume fewer resources, reduce unnecessary interaction, preserve determinism, and shift some of the burden back toward those generating the malicious traffic.

CISA has made clear how serious the problem has become. SYN greylisting demonstrates that stronger security does not always require stronger hardware, more computation, or another layer of complexity. Sometimes the better defense is simply to understand how the attack works and refuse to cooperate with it. The approach is inexpensive, the underlying TCP behavior already exists, and we have demonstrated that it works.

If a few lines of code in a TCP stack can prevent this much malicious activity from ever getting started, what are we waiting for?

 

>> 

 

References

1. Cybersecurity and Infrastructure Security Agency (CISA) et al., Primary Mitigations to Reduce Cyber Threats to Operational Technology, May 6, 2025. U.S. Cybersecurity and Infrastructure Security Agency.
2. Cybersecurity and Infrastructure Security Agency (CISA), Internet Exposure Reduction Guidance, June 4, 2025. U.S. Cybersecurity and Infrastructure Security Agency.
3. M. Kucherawy and D. Crocker, Email Greylisting: An Applicability Statement for SMTP, RFC 6647, Internet Engineering Task Force, June 2012.
4. W. Eddy, ed., Transmission Control Protocol (TCP), RFC 9293, Internet Engineering Task Force, August 2022.