SCADA Security and USB

Eric Byres has an interesting blog posting over at the Practical SCADA Security blog talking about responses to the Stuxnet worm. He observed that many companies were reacting to Stuxnet, even companies without Siemens control systems. One of the responses that he had noticed was the increased restriction of the use of USB sticks (jump drives) on control system computers; a reasonable precaution when considering the probable use of portable drives in the Stuxnet infection process.

Eric discusses a couple of different options for controlling the use of jump drives including physical locks for USB ports and software controllers that will limit what specific devices can be accessed through USB ports. It’s an interesting discussion, well worth reading.

USB Ports

There are a couple of points that need to be made about the use of USB ports on computer systems in general and specifically in control system computers. First off, USB ports (and the supporting software systems) have made it much easier to attach a wide variety of devices to computers. The plug-and-play capabilities have made it much easier to replace keyboards, mice, and printers without having to worry about device drivers or re-booting systems.

In fact it is becoming much more difficult to find devices that can be plugged in to places other than a USB port. Blindly blocking such ports with permanent blocks (I have heard of people using super glue or epoxy resin to physically block these ports) could cause some significant problems down the road.

Physically managing USB ports has been complicated by the ready availability of devices that allow users to expand the number of USB ports. I use one on my lap top because I can’t plug my mouse and jump drive in at the same time because the two available USB ports are too close to each other. I plug this adapter in and turn one USB port into four.

Any control of the use of USB ports needs to include a training component, explaining to operators, technicians and control systems engineers the reasons for the control. Failure to do this will inevitably lead to people bypassing the controls to allow them to use their own USB based devices on the system.

Jump Drives

The wide availability of inexpensive file storage capacity in a plug-and-play device has made major changes in the way that we use computers. I know that it has made my job as a freelance writer much easier; I can carry my files with me in my pocket and use a wide variety of computers to do my work, transfer completed work to my customers and get a wide variety of data necessary to do my job.

There are a number of legitimate reasons to use jump drives on control system computers. Eric points out the use to collect system diagnostic data when network connections are not working. I have used a jump drive to collect screen shots from the control system work station to use in operator training documents.

As companies increase their control system security awareness there actually may be an increased need for the use of jump drives. A control system engineer I know does his system programming on his desk computer that is also used for the standard office work that no one can avoid. Needless to say this computer is linked to both the control system and the office networks.

This is exactly the type set up that the Stuxnet worm was designed to utilize. The USB device would not need to be plugged into one of the control system work stations to infect the control system. Insertion of the infection device into any of the office network computers would have lead to an infection of this dual use computer.

The obvious solution to this problem would be to give the control system engineer (and the technician who backs him up on system diagnostics) a separate computer for use with the control system that is not linked to the office network. A cheaper solution would be to continue to use the dual use computer, but remove the physical link to the control system using a jump drive to transfer the appropriate program files (but note that this was yet another method of Stuxnet propagation).

Considered Solutions

Anyone that has done any serious problem solving work knows that knee-jerk, reflex type responses to problems frequently cause more problems than they solve. In anything involving control system problems this is certainly true and control system security problems are no exception.

A well thought out response will be the only method that will have even a remote chance of protecting control systems from an attack as sophisticated as Stuxnet. The response will have an increased chance of being successful if it comes out of a team consideration of the problem; a team that includes operators, process engineers, IT, vendors, and security specialists. All of these specialties will be needed to put together a workable control system security program. And don’t forget the training program to support the security system.