The CISA Alert: Security Beyond Solitary Confinement

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.

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.