Ten steps to secure control systems

A fundamental principal of effective IT governance is that a business unit must have absolute control over the systems, applications and infrastructure upon which their critical business processes rely. This does not imply that Business Units should be able to do absolutely anything they want. Rather, it means that ALL changes to a system must be reviewed and approved by the Business Unit that owns or relies upon the system. For shared systems, such as Email, Domain Name Services, etc., while the IT Department may “own” or be in charge of the system, all the Business Units that rely upon those systems should be able to review and provide input to proposed changes. Essential to accomplishing this is a robust Change Management software system and a rigidly adhered to Change Management process. 

Additionally, a method of auditing for compliance needs to exist. The methodology should not just rely on examining records in the change management system, but also should detect changes in the environment and ensure that the change management process was used to effect the change.

Typically, a robust change management process/software system will:

1. Maintain a list of individuals who must be notified if a change is proposed for particular categories of systems (SCADA, Network, Applications, Firewall, etc.). The process should ensure that the appropriate individuals are notified of the proposed change.
2. Enforce a defined time limit in which changes must be reviewed prior to approval and implementation.
3. Maintain a list of people who must approve a change for each category of change.
4. Require and maintain documentation of what tests (reference to test procedure if a standard one exists) were performed to make sure the change functions properly.
5. Require backout procedures in case something goes wrong.  
6. Keep a record of the above steps for each change, recording information such as change number, dates, who submitted, who approved, and who implemented.
7. Incorporate process for streamlining and shortening the process for emergency situations (usually called HotFix).  This usually provides for a single approval with notifications and documentation after the emergency change has been implemented. 

Secure Architecture
In order to function securely, the infrastructure devices used to accomplish the functions of the control system must be isolated from outside negative influences. A negative influence can be anything from an engineer requesting a massive amount of data to the high volume of traffic generated by a hacker’s worm or virus.  

To accomplish this isolation, all of the machines associated with the primary function of the control system must be grouped together on a common network and protected from other networks. Before this can be done, the perimeter of the control system environment must be clearly defined and all connections to the outside documented. The appropriate method of securing these connections must be identified and implemented. For Internet Protocol (IP) connections, this requires a firewall.

Firewalls
Firewalls are built to regulate connections between machines inside the firewall and machines outside the firewall. Firewall rules can be written to allow any traffic or to restrict traffic to only specific devices and applications. In order to help secure the control system environment the firewall should be configured to reject all connection requests either inbound or outbound. Then, as functionality is added to the control system environment, new rules can specifically allow the connections required by that functionality. In general, connection requests from the outside should never be allowed.

Implementation of a firewall between the corporate and control systems telecom network will also allow a Demilitarized Zone (DMZ) to be established between the two. This DMZ can then be used for placement of database and application servers that can bridge the two networks in a secure architecture. This will be explored further when we discuss remote access.

Getting data in and out
The types of systems that need to get data to and from the control system environment will vary depending on the application. To remain secure, applications within the control system environment should push data needed by applications external to the control system environment out to those external applications. Also, when external data is needed within the control system environment, applications within the secured environment should pull the data in.

Again, when data residing on the control systems environment is needed by employees or applications on the outside, the data should be pushed to a data repository on the outside. The employees and applications that need the data then should query the outside data repository, not the control system environment.

Wireless
This discussion will be limited to 802.11 type WIFI implementations. It will be assumed that you want to encrypt and secure these types of connections. Specific technologies discussed will be WEP, WPA and WPA2/802.11i encryption.

WEP offers very little protection and should not be used in a business environment. It takes only about an hour or two for a high school hacker to collect enough information to break the encryption key and connect to your network.

WPA is a good alternative for installed bases of 802.11 that have only WEP as an option because the technology is available with only a firmware upgrade. Besides good encryption device authentication is available, but the technology is susceptible to Denial of Service attacks. Just a few packets sent with the wrong encryption key can cause the device to reboot. This was intended as a precaution against hack attempts, but in a control environment the results are damaging.