Cyber Security Certification | Industrial Control Security

Figure 6 illustrates a few of the locations of possible pathways into organisations that employ segregated process control/SCADA networks, and all of them have been points of entry for at least one ISID incident. For example, database records show that the Slammer worm had at least four different infiltration paths in the control systems it impacted:
1. The Davis-Besse nuclear power plant process computer and safety parameter display systems via a contractor’s T1 line;
2. A power SCADA system via a VPN;
3. A petroleum control system via a laptop;
4. A paper machine HMI via a dial-up modem.

The bottom line is that security designs that assume all traffic into the control system will flow through a single choke point may be making a dangerous assumption. Focusing a single solution (such as the Internet firewall) on a single connection point is likely to miss many possible entry points into the control system and leave the system open to attack.

Fig. 6. Typical entry points in control network structure

This analysis of the ISID data indicates that organisations that operate SCADA and control systems have good reason to be concerned about cyber security. Not only have the number of incidents increased dramatically in the past five years, but the seriousness of these events appears to be increasing as well. Furthermore, the cost of each incident can be substantial. Even if there is no direct impact on production or revenue, there is cost associated with expenditure of employee time, the cost of upgrading/changing equipment, and the risk to corporate reputation.

Virus and worm-related incidents make up a significant proportion of the total number of incidents impacting control systems. They also account for a significant percentage of the overall costs incurred due to the high volume of such incidents. The high frequency of virus and worm incidents suggests that security methods that are in place in many control systems are insufficient. For example, a perimeter firewall protecting the business network offers little protection against internally released viruses from mobile laptops connected to the control network.

The analysis points to two areas where the security of the typical SCADA/PCN system could be improved significantly. First, the large number of incidents involving well known and easily addressed threat vectors indicate that many of the security issues need to be addressed through better policy, practices, and education programs rather than through pure technology based solutions. For example, incidents involving the Slammer worm continue to be submitted to the ISID, almost five years after the patch for this vulnerability was initially released. Flaws in security policy and employee/contractor awareness are the root cause in nearly all these cases, rather than a failure in technologies such as antivirus or firewall software.

Second, the existence of the numerous secondary pathways into the SCADA and control system point to the need for comprehensive, indepth defence strategies. This includes better layering of firewall defences and the hardening of end-point devices through patch management, antivirus deployment, microfirewalls, and host firewalls within the SCADA/PCN proper. The remainder of this section describes both areas for improvement in more detail.

In any cyber security effort it is easy to get caught up in the razzledazzle of technological solutions and forget the soft aspects of security such as policy development, responsibilities, and staff training. Yet it is this human part of the equation that is critical to the success of any security program, not the technology.

Reviewing the incidents reported in the ISID, it becomes clear that the root cause of many of the events is a breakdown in these human factors rather than a true failure of technology. Thus it is critical that SCADA/control system owners and operators start by developing a comprehensive control system security management program that covers all aspects of industrial control system security, including cyber and physical security.

There are a number of excellent sources that provide guidance on how to create a control system security management system. The ISO/IEC 17799:2005 and ISO/IEC 27001:2005 standards specify a possible process from the IT perspective, while ISA-99.00.02-Part 2: Establishing an Industrial Automation and Control System Security Program defines the key requirements from a process control perspective. Industryspecific requirements for the electric power industry are defined in the North American Electrical Reliability Council (NERC) Standards CIP-002-1 through CIP-009-1.8

In addition to these formal standards are interpretive guides that help translate the language of standards into everyday terminology. A good example of this is the Symantec white paper, ‘Effective Practices for Meeting NERC Critical Infrastructure Protection Requirements in the Electric Power Industry.’ This paper summarises an effective security program into five key steps:
Step 1: Critical asset identification and risk assessment
Step 2: Security policy creation and update
Step 3: Disaster recovery planning
Step 4: Deployment of protective measures
Step 5: Security monitoring and management

Taking short cuts on any of these steps can be a recipe for disaster. For example, a number of incidents have occurred on sites where control system staff had moved well into Step 4 (deployment of protective measures) before completing the policy creation step. The result was that staff who did not understand the need for the security technologies on their site effectively nullified their security effectiveness by inappropriate actions. For example, during one particular site audit, network cables were discovered that circumvented the SCADA firewalls. The reason later given was that there was no risk analysis showing that the firewalls were important, nor was there a policy stating that bypassing them was unacceptable. Once again, this highlights the need for a control system security management system that is holistic and well designed, rather than a piecemeal approach to security.

In many of our discussions with controls engineers, we hear the comment: ‘We don’t need to worry about securing our control system because the IT department has a firewall between the company and the Internet that will protect us.’ Yet since nearly 40% of all reported incidents were transmitted from the business network to the control system, clearly this strategy isn’t working.

Modern security practice mandates that effective security requires a defence in depth strategy where critical systems are protected by layers of security. Depending on a single corporate firewall for control system security violates that strategy by creating a single point of security failure. Once the attacker or worm has either broken through or circumvented the single firewall, the entire control system is left wide open to exploitation.

Furthermore, the security needs of the business network are not the same as the security needs of the control network. For example, the business firewall must typically allow users on the inside of the network to browse the Internet using HTTP, while the control system typically requires security policies that explicitly forbid this. Simply put, a single firewall cannot be all things to all departments. A good control system security strategy needs to offer layers of protection, starting with a dedicated control system firewall and progressing to specific protection for key devices and systems on the plant floor or SCADA system.

The primary control system firewall defines the security perimeter for the control system and acts as the choke point for all traffic between the outside world and the control system. Proper design and deployment of this firewall is critical: ideally, it should be deployed in the appropriate multilayer architecture described in the NISCC Good Practice Guide on Firewall Deployment for SCADA and Process Control Networks. Often this is not the case; as Dorey noted in his PCSF keynote speech, comments like ‘My networks aren’t connected; my server uses a separate network card to connect to the PCN and the corporate network’ do not indicate a secure network design and are simply a great way to infect both networks. Similarly, using routers or switches with access control lists (ACL) is generally not acceptable. Detailed reasons for using proper firewalls and the basics of designing multilayer architectures are described in the NISCC Good Practice Guide.

Multifunction firewalls that combine firewall services, antivirus (A/V) services, VPN services, and intrusion detection services are also recommended. As noted previously, VPNs often bypass firewall rules because data is received in an encrypted format and cannot be validated by the firewall. Combining the firewall function and VPN function in one appliance addresses this issue because the firewall can be given the ability to decrypt (and if necessary re-encrypt) the VPN traffic.

Similarly, the challenges of deploying A/V in the control network can be partially addressed by multifunction firewalls. Systems that cannot use A/V software (such as PLCs) or systems where signature updating must be delayed can get some level of protection from a firewall that offers A/V services as well.

Once the electronic perimeter of the control system is secured, it is necessary to build the secondary layers of defence on the control system itself. This can be achieved using two primary techniques. For those control components (such as HMIs and data historians) that are based on traditional IT operating systems such as Windows and Linux, this can take advantage of the proven IT strategies of patch and antivirus management. For those devices like PLCs, RTUs, and DCS controllers, where patching or antivirus solutions are not readily available, the use of distributed security appliances is recommended. We will discuss both solutions in more detail below.