10 principles for securing control systems

FIGURE 1: THE KEMA CYBER SECURITY ASSESSMENT METHODOLOGY
(Click on the image to view an enlarged .pdf of this chart.)

Typically, the passive Vulnerability Assessment is the first step in the process. From that point, the client can stop there or choose any combination of the other options: invasive vulnerability assessment, risk assessment and/or penetration test.


8) Incident Response
Though incident response plans are tailored to each firm’s organization and management, there are some common tasks to include in any response plan. While most plans pick skilled technical staffs to be in charge during an incident, experience shows that the manager with the most skin to lose is the one who takes charge. A solution might be to have a technical response coordinator and an overall incident manager from the business unit with the compromised systems.

It’s also important to identify what can and can’t be done by staff when an incident is discovered. While it may be prudent to give system administrators emergency authority to shut down or cut off e-mail servers or file servers, it may not be prudent to let them shut off control system devices. These issues need to be explored and clearly communicated to front line responders, so they’ll know what they can do on their own authority and what must be approved regardless of the emergency situation.

Team members required for incident response must be identified for each type of incident. Also, it’s a good idea to have one person, usually someone both technical and familiar with management, to serve as management liaison. Table-top drills that explore what people would do to respond to different types of incidents are priceless. Make a list of all the different threats, identified in vulnerability and risk assessments, and discuss with each target what they would need to do to recover. For instance, if you discovered that a malicious hacker had been in your control system telecom environment for 10 days, what would you do to ensure that all your systems were configured and working properly?

In addition, a plan that no one knows about is worthless. So, tell everyone who could possibly be involved in an incident response team about the plan and how it works.

Finally, because most incident responses are studies in controlled chaos, don’t expect people who have the most to lose to review the Incident Response Plan before taking action. Actual incidents are totally different than what’s anticipated, but planning and practice gives participants the knowledge and experience they need to adapt.

9) Configuration and Patch Management
Configuration management means knowing what’s supposed to be installed and running on a device, and being able to determine whether its configuration is approved. Manual and automatic processes and tools can check configurations to see if unauthorized changes have been made to a system.   Configuration management can also help reconstruct a system or machine if a disaster occurs.

Patch management tests released patches and applies them to appropriate systems. This is difficult in all environments, and especially so in control systems. Patches must be tested to ensure they don’t introduce unintended problems, and to check their interrelationships with other patches, systems, and application software.   

10) Monitoring Malicious Code
While regular or continuous system monitoring for malicious code is needed, it’s counter productive to implement a security tool or procedure that prevents a system from fulfilling its business objective. Unfortunately, systems that must complete transactions in a small, discrete portion of time are often impacted by anti-virus software.

Usually, restricting anti-virus software from running on files that are used in real time is a sufficient precaution. With control systems, however, tests must be made to ensure that system resources consumed by the anti-virus software don’t interfere with the process control software.

For example, a problem with isolating a control system behind a firewall is that it automatically provides virus definition update files to the control devices. One solution is to place a server containing tested updates in the control system DMZ, and configure anti-virus software in the control environment to retrieve updates from this DMZ server.  

In addition, many control devices don’t support log file creation, but there isn’t much to log since most of these systems don’t require authentication or authorization. However, control systems that use Windows or UNIX variations do support logging of security events, and these should be used.

Each company’s security analysts should decide what to log. Most agree that, at a minimum, failed logon attempts and failed attempts to access files should be logged.

Also, regular review of the logs can glean information undetected by other tools, such as network intrusion detection/prevention (NIDS). However, since log files are usually large and there are so many systems, users should consider buying a log file collection and analysis tool.

Likewise, host intrusion detection/prevention (HIDS) technology can detect unauthorized activity at the server. However, HIDS agents usually consume approximately 5% of a server’s resources, and so testing is recommended to make sure this agent doesn’t interfere with control functions. Also, many events of most interest, such as unauthorized access attempts and failed logons, can be detected using NIDS. This is a “passive” control in the sense that agents run on dedicated devices, which analyze data packets that flow through the network without introducing measurable latency. Also, many new intrusion prevention devices have anomaly detection capabilities. Since the network traffic in a control environment is basically static (there may be more or less of it, but the types of traffic and network behaviour rarely changes), NIDS with anomaly detection capabilities may be ideal. Initial tests by several NIDS suppliers and control system vendors are confirming this assumption.

No Silver Bullet!
There is no “silver bullet” tool or technique for securing any computing system. No matter what steps you take, vulnerabilities will still exist. However, pursuing a comprehensive security program that is constantly monitored, updated, and reviewed by third parties does constitute due diligence and will keep your system as secure as possible.

---

About the Author

Jay Abshier is a principal at KEMA Inc. Consulting Group. He can be reached at jay.abshier@kema.com.