OT Security: Are We Protecting the Information?
Industrial network engineers have always been uneasy with the task of "protecting information". The real priority for OT security is in stopping inbound malicious information from entering the system and threatening machinery and workers.
Andrew Ginter
Connectivity between OT / industrial automation systems, between OT systems and IT systems, and between all this and Internet-based cloud services continues to increase. On the surface, this trend demands that we encrypt everything, thus protecting the information. And, because no operating system nor cryptosystem is perfect, we must also deploy at least the “detect,” “respond” and “recover” pillars of the US National Institute for Standards and Technology Cybersecurity Framework6 (NIST CSF). Since connectivity leads sooner or later to intrusions, we must use sophisticated intrusion detection techniques, in hopes that when we are compromised, we can detect the attacks, respond to them, and recover normal functionality again before we suffer downtime, equipment damage, casualties, or other unacceptable consequences.
Monitoring Data vs. Control Data
Industrial network engineers, however, have always been uneasy with protecting information. Consider a six-story catalytic cracking tower full of high-pressure, high-temperature hydrocarbon liquids and gasses. Imagine we are standing in front of the cracker watching a technician carrying out routine maintenance. In front of us are two analog gauges reporting temperature and pressure, and a dial controlling the flow of fuel to the cracker’s furnace.
We look over our shoulder and notice that, outside the fence, someone is sitting with a telescope pointed at the gauges, taking notes. We tap the technician on the shoulder. “That person over there seems to be writing down our settings,” we say. “They are stealing information.” What does the technician do? They might call corporate security. Depending on policy, they might shrug their shoulders and go back to work. The consequence of stealing that information is a business consequence – it is somebody else’s problem.
Now imagine that the person behind the telescope cuts a hole in the fence, runs up to us, cranks the furnace fuel feed hard to the right, and runs away. What does the technician do? They scream for security. They run to the dial and returns it immediately to the correct position. Over-heating the cracker risks damage to the catalyst and possibly a fire and an explosion.
The point here is that monitoring information that leaves the site is just information – with value comparable to the value of any other information in an IT network. All control information that enters the industrial site, however, is a potential threat. Calling both examples simply “attacks on information” and saying “encrypt everything to protect the information” ignores this fundamental difference.
“…monitoring information that leaves the site is just information – with value comparable to the value of any other information in an IT network. All control information that enters the industrial site, however, is a potential threat.”
Protect The Information?
In many, but not all, industries, the goal for most network engineers is not to “protect the information” but rather to prevent unacceptable physical consequences of cyber attacks. Universal connectivity lets monitoring information leave the plant, yes, but it also lets potentially dangerous control information enter the plant. Encryption provides no protection against a compromised cloud that sends attack information into the plant inside of an encrypted, authenticated connection.
Putting cryptographic and other protections in place for monitoring information that leaves the site makes sense. The business and societal consequences of an attacker stealing monitoring information are similar to the consequences of an attacker stealing other kinds of business information. Putting information-protecting mechanisms in place for control information is often woefully inadequate, because at many industrial sites, the consequences of compromised controls are completely unacceptable.
Hope Is Not Good Engineering
Engineers are also uneasy with the focus on detect, respond, and recover activities. Hoping that we can detect attacks in progress and respond in time to prevent unacceptable physical consequences is not good engineering. Engineers do not “hope” their bridges will not collapse, nor “hope” that their 300-ton steam turbines will not shake themselves to pieces. Engineers design systems that simply do not fail in the face of a defined set of threats. That said, yes engineers often do monitor or periodically inspect their finished products to ensure that they are holding up as designed, but any engineer caught “crossing their fingers” in a design risks being drummed out of the profession.
To read further on network engineering solutions at IT/OT or OT/Internet criticality boundaries, click here to request a free copy of the author’s latest book: Engineering-Grade OT Security: A manager’s guide.
About the author
Andrew Ginter
Share
Trending posts
Stay up to date
Subscribe to our blog and receive insights straight to your inbox