ICS Operations Insecurity

Yesterday, the mailing list SCADASEC saw the start of a very scary discussion thread with a report from Jake Brodsky, a well-known and respected researcher and commentor on industrial control system security issues. It related to a discovery reported to him by another researcher made while using an unnamed internet search engine (possibly SHODAN, but it could have even been Google). That researcher found an unsecured FTP site that looked like “it was the home office to a small controls firm that does ICS application software programming”.

According to Jake’s report:

“It contained fully licensed copies of various vendor software packages. It had correspondence regarding various ongoing projects with utility plant upgrades. It had application programs. It had drawings. It had spreadsheets of I/O maps and descriptions.”

Now Jake has taken appropriate actions and that FTP site is now ‘secured’ (password protected), but there is no telling who else had seen the information available on the site and now had the keys to be able to execute an effective attack on the utilities that were blueprinted on the site.

To understand why this is such a big and scary issue, you have to understand why this is such a potential escalation of the threat of a successful catastrophic attack on an industrial control system.

Why No Attacks to Date

Readers of this blog have seen me talk about the increasing number of control system vulnerabilities over the last couple of years. With hundreds of thousands of internet facing control systems and hundreds of available control system application vulnerabilities the number of control systems in critical infrastructure that are wide-open for cyber attack is astounding. The only amazing thing is that we haven’t heard about successful attacks on these systems.

There may be a number of reasons for that including the fact that there is no requirement for anyone to report such an attack to the government or the media. In fact there is every incentive for system owners to not publicly report successful attacks or for the government to share information about any attacks reported to them.

Even so, it would be damn near impossible to keep out of the news the fact that a successful attack resulted in a catastrophic incident at a major petrochemical facility, major water treatment plant, gas/fuel pipeline or electrical power generation facility; all of these are high-value targets about which the world quickly hear if successfully and catastrophically attack.

Security through Complexity

One of the reasons that we have not heard about a successful, catastrophic attack on control systems is that, even with unauthorized and undetected access to such systems, it is incredibly difficult for an attacker to figure out how to get a control system to do something catastrophically wrong.

First off, most owners of these systems are not criminally negligent or critically stupid. The systems are designed with safety and some minimal level of security in mind. They don’t want their equipment exploding or their expensive chemicals being released into the environment; it is bad for business. So there are at least some rudimentary controls and process systems designed to prevent catastrophic incidents.

But beyond even that there is a much more basic reason why these systems are hard to attack with a catastrophic result. There are no self-destruct switches; there are no buttons marked “Start Plant Conflagration”; there are no controls marked “Blow up Chlorine Tank”. To make a control system do something like this would take the operation of a number of controls (in the proper sequence) while masking the outputs of dozens of sensors over a lengthy period of time so that the system operators don’t notice that something unusual is happening.

Oh, and one other minor thing, each of those controls and sensors have cryptic labels in the control system like MotorS001, or RTDP25, or Valve26K2. Now these labels are not coded as part of the security system for the facility; they are engineering shorthand. They are designed to be small enough that they can be placed on process and engineering drawings and be easily typed into control system programming.

A control system engineer or other process professional can probably only specifically identify a handful of the actual components in their system by just looking at the control label. To identify what specific component is based upon the control system label the engineer relies on a spread sheet that lists all of the inputs and outputs (I/O). That spread sheet would also typically describe what commands are available for that control and what each command would accomplish. Opening Valve26K2 might open an airline that would close a valve on a chlorine transfer line for instance; or it might close an airline that would allow a valve on a chlorine transfer line to close.

Control System Security

Now there are some basics about control system security. First you don’t want the bad guys to get access to your control system. Unfortunately, it is becoming increasingly obvious that in the modern control system world it is unlikely that anyone can promise with any degree of certainty that there are no holes in the security perimeter through which an attacker could gain access to a control system. In fact, I will be so bold as to proclaim that there is no system that cannot be accessed by a determined, educated and well-funded attacker. The higher the profile of your system, I will again be so bold as to proclaim, the higher the likelihood that your system perimeter has already been successfully penetrated.

If someone is already within your ICS perimeter, the one thing that you certainly don’t want them to have access to is your system diagrams and your I/O lists. With those three things anyone with a modicum of control system expertise and process knowledge has the capability to do pretty much what they want with your system. Anyone with just those three things (access, diagrams and I/O lists) has the capability to play with your system and acquire the necessary system expertise and process knowledge to significantly disrupt your operations; they may not be able to easily blow up your plant, but they can stop you from delivering goods/services to your customer.

Oh yes. By the way; if I have your process control diagrams and your I/O lists I know what kinds of devices you have in your system. I now have a better chance of finding a way into your system. With just a little bit of controls system vulnerability knowledge I can find out just which part of your system is most vulnerable to attack and just how to attack it. Even a script kiddy will now be able to find their way into your system with this information.

What Needs to be Done

It is becoming increasingly obvious that critical infrastructure security is more than just perimeter fences and security guards. In the modern world a major component is also control system security.

Similarly, control system security is more than system passwords and patching software. A facility can take every reasonable effort to secure their control system and find that a contractor or vendor has provided the keys to their system to a cruel world.

In his post on SCADASEC Jake asked the important question: What needs to be done? Here is my short answer.

Control system security personnel (and it is becoming increasingly obvious that we need these specialists at every level of our organizations) need to look beyond just system vulnerabilities and look at the operational security of their engineering department and the engineering departments of the vendors and contractors.

Organizations need to identify what information that they have in house would make it easier for an adversary to successfully attack their control systems. That information needs to be protected to protect the control system. I/O lists and system diagrams should be considered to be classified information and such document need to be kept under lock and key (or their computer equivalents; password protected files).

Agreement with vendors and contractors need to specify what information about the system is critical to the security of the system. Those agreements need to delineate what minimum security measures need to be in place to protect that information.

And all of this needs to be inspected and audited. The few regulatory agencies that look at cybersecurity need to expand their programs to include the security of system information. They need to require the identification of security critical information and establish minimum standards for the protection of that information.

Just as important though, everyone in the security chain needs to identify when that information has been or may have been compromised. When such breaches are identified, compensating controls need to be placed into operation to protect the system.

Control system security is not now, nor has it ever been, a game to be played by amateurs. In critical infrastructure this is deadly serious business. In other organizations it will only affect the life and death of the organization. In critical infrastructure it could affect the health and welfare of millions of people.