Following the Colonial Pipeline Ransomware incident, Twitter exploded in to an orgy of blather from people demanding that we “air-gap” ICS. Those righteous keyboard warriors know what is best, I’m sure.
We cannot avoid having a secured connection with the office. But on the other hand, we don’t need ICS networks to be connected to the office 100% of the time. If there are elements in the office that require “real-time” performance, then someone should examine the data flows and why such connections are required. In most cases, the connection could be replaced by a reporting device on the OT side of the network, or it is just someone’s pet project that has no business case.
Office connections should have asynchronous, buffered connections. For example, I visited a pipeline operation similar to Colonial about three years ago. While they operated at a slightly smaller scale, They had a very manual connection between the office and the control room. At the beginning of the shift, the office would hand the operations staff a few sheets of paper with a list of what petroleum products need to move through the pipeline from where to where. The operators do this, and when the shift is up, the operators would generate a report for the office and hand the clerical and planning staff a few sheets of paper with the current results. This was not a huge amount of time-critical data.
So if some executives come to you thumping their chests saying “we must be connected all the time because it’s complex and intricate” –tell them to go fly a kite. They need to get a sense of perspective. By the way, flying a kite is a great way to relax, and feel small, while your kite flies high.
Furthermore, we should all practice network segmentation. This means periodically disconnecting the automated segments of the operation by disconnecting network connections. This gives people proper training and practice for identifying those key network segments so that they won’t be flustered and make mistakes when the real need arises. It also trims the operation down to essential automation so that everyone knows exactly what to expect.
When people work with automation enabled all the time, one should expect the manual skills and understanding of the automated systems to atrophy. If operators and office staff do not fully understand what the automation should do next and how it is supposed to work, how will they be able to determine that something is broken before it is too late?
This practice of breaking automation into semi-automatic subsystems is not just good for security, but also for operational proficiency and diagnostic training. In the case of a pipeline such as this, going back to older methods of faxed fuel orders and the like is also good as a method of cross-checking the automation.
And that brings me back to the people who think these systems cannot possibly operate without the automation. I like automation. I have designed automation over my entire career. But it is important to keep the semi-auto and manual controls available. If the automation or the instrumentation fails, there should be a backup plan of some sort. Assuming that without automation everything falls apart would be like assuming that without an autopilot, a ship would automatically run aground. It won’t. The pilot would end up working a lot harder and the maneuvers may not be as precise, but the ship is in no danger –unless the pilot has forgotten how to operate the ship.
“Air-Gapping” the networks between OT and IT is not practical in most cases. There is a significant Return on Investment for connecting them. But limiting the flow of traffic and practicing procedures for isolating the two is not as crazy as it sounds. Practicing that feature also has a very significant Return on the Investment. It is probably worth doing.
