Protecting ICSs from Electronic Threats, Part 3

IT Security Certification Exams Don't Address ICS Issues, and Professional Engineering Exams Don't Address Cybersecurity

Share Print Related RSS

[The following is the third section of a three-part "Security Spotlight" series, which consists of portions of Joe Weiss' Protecting Industrial Control Systems from Electronic Threats, Momentum Press, 2010. Part 1 ran in the June issue of Control, and Part 2 ran in the August issue.]

Various organizations monitor cybersecurity exploits in the information technology (IT) industry, including the Computer Security Institute, SANS and Carnegie Mellon's Computer Emergency Response Team (CERT). These exploits number in the hundreds of thousands, which provide a meaningful value when assessing risk and allows consequences to the IT community to be meaningfully estimated.

However, the same can't be said for the industrial control system (ICS) community. The two main databases of industrial control system (ICS) incidents, the Repository of Industrial Security Incidents (RISI, www.securityincidents.org) and my own, have documented between 150 and 200 incidents over about 10 years. These are statistically insignificant numbers, which are made even more so because they're spread across multiple industries and countries. This usually means less resource allocation and funding. Also, because there's little information sharing between industries, a notable compromise of an ICS in one facility or industry may not be known to any of the others, resulting in a false sense of security.

Consequently, a valid cyber risk assessment would determine what systems are connected to other systems regardless of size. If systems are interconnected, they're cyber sensitive. So, for cybersecurity considerations, even a facility that's very small can be just as crucial if it's interconnected with larger facilities.

Security Activities by Industry

Several industries have common ICSs and use common industrial protocols, so there should be a common cybersecurity thread among them. For example, the North American Electrical Reliability Corp.'s (www.NERC.com) Control System Security Working Group has issued several documents that should be relevant to different industries, including a top 10 ICS vulnerability list and ICS time-stamping and business-network connectivity and patching guidelines. Also, NERC's Critical Infrastructure Protection (NERC-CIP) reliability standards identify the security needs and requirements for electric utilities, but also allow them to reclassify many assets as non-critical.

Likewise, the International Society of Automation (www.ISA.org) has started a joint working group between its ISA67 nuclear plant standards and ISA99 ICS cyber security committees to address nuclear plant cybersecurity, and the International Electrotechnical Commission (www.IEC.ch) had a similar nuclear plant cybersecurity group.

Demonstrations and Case Histories

There have been many demonstrations by the U.S. national laboratories of control system cyber attacks. Their purpose has been to make industry aware that cyber attacks are possible, plausible and can cause significant damage.

One of the first was by the Idaho National Laboratory (INL, https://inlportal.inl.gov) in 2004, which replaced buffer overflow software with an attack script to compromise substation equipment, and showed that vulnerabilities could be used to compromise controls, that attacks could be carried out from a long distance, and that traditional mitigation, such as firewalls couldn't block it.

Similarly, in 2007, the U.S. Department of Homeland Security (www.DHS.gov) and INL used the Aurora software vulnerability provided by the Electric Sector—Information Sharing and Analysis Center (ES-ISAC, www.esisac.com) to show that a cyber attack could physically damage rotating equipment. In this case, the attack caused a 3.8-MVA machine driven by a 5000-hp diesel engine and running at 1800 rpm to seize up due to internal mechanical damage.

Variations of these hacking demonstrations have been experienced by industry with differing impacts. Unfortunately, many in industry still refuse to believe that ICSs can be compromised by intentional or unintentional cyber events.  Meanwhile, because cyber incidents can be malicious or unintentional, ICSs must be protected from both. Many ICS cyber incidents have resulted from interconnectivity of systems and not from a lack of IT security methods, such as using complex passwords or effective firewalls.

For example, NRG Energy's (www.nrgenergy.com) corporate network identified many failed attempts to log onto its PCs from a plant workstation in 2009 and found the Conficker worm on these computers. Fortunately, none of the affected PCs had control authority for NRG's power control systems, but the utility also learned that it needed to adopt an effective patch management program.     

On the unintentional side, the Tennessee Valley Authority's (www.tva.gov) Brown's Ferry Unit 3 nuclear plant had to manually shut down in 2006 following a loss of both main coolant pumps. The utility found that the recirculation pumps' variable frequency drive controllers were unresponsive because of excessive traffic on the plant's integrated computer network. The incident didn't violate any IT cybersecurity procedures.

Government and Other ICS Security Recommendations

Based on my experiences and those of others, I'm following up Part 2's technical recommendations with these government, disclosure, certification, educational and vendor recommendations for improving cybersecurity:

  • To avoid legislation of cybersecurity issues that could make initial problems worse, the National Institute of Standards and Technology's (www.NIST.gov) Risk Management Framework should be adopted for all critical infrastructures or at least the critical infrastructure subset. Incorporate risk management principles and define measurable outcomes by moving to performance-based versus requirements-based oversight. Reporting of all ICS cyber incidents also should be mandatory. Extending corporate and personal liability considerations for ICS security can help stimulate information sharing and budgets.
  • Include ICS subject-matter experts at high-level cyber- security planning sessions.    
  • The U.S. Dept. of Defense (DoD, www.defense.gov) should continue to work with private industry and share appropriate information and technology, and industry should support DoD to help secure its critical infrastructures.
  • Establish, support and promote an open demonstration facility dedicated to cybersecurity best practices for ICSs.
  • Establish a global, non-governmental ICS-CERT staffed with ICS expertise for vulnerability disclosure and information sharing.

Certification and Educational Recommendations

  • Continue development of ICS security policy courses, and develop ICS cybersecurity curricula as an interdepartmental offering between computer science and engineering.
  • Develop ICS-specific cybersecurity awareness and training and include requirements for them as part of mandatory initial and periodic IT security classes.
  • Establish standard ICS cybersecurity certification metrics for personnel, processes and systems. Existing IT security certifications exams don't address ICS issues, and professional engineering exams don't address cybersecurity.

Vendor Recommendations

  • Use IT devices and best practices for securing workstations and networks using commercial operating systems.
  • Enable security devices before equipment is shipped.
  • Develop security technologies and best practices for  field devices based on ICS cyber incidents.
  • Develop a secure website for providing vulnerability disclosures. Provide cyber testing information to end users and system integrators who have need-to-know clearance. 

ICS Cyber Incident Response

  • If a cyber incident occurs, continue to operate the facility in an efficient, safe and secure manner until told otherwise. During an incident, odd and unexplained things may happen. Several incidents have occurred that were not recognized as such for hours or even days. So perform a comprehensive root-cause evaluation with IT and operations.
  • Seek to develop a procedure to respond to cyber incidents, including deciding when to escalate and activate emergency plans. Conduct tabletop training with all relevant organizations to reduce confusion.
  • Collect baselines for normal ICS network traffic, so you can check for differences when a cyber incident might be occurring. Logs from operator security, firewalls and intrusion detection devices can help.
  • Find out if a suspected cyber incident is related to software or data. Check existing inputs, call vendor's technical support, examine software and firmware signatures, reload software to last-known good release, and check configuration files for corruption. Also, check CPU usage, disk space, network traffic, and PLC, SCADA and DCS scan rates.
  • Contact DHS and the FBI to see if they have subject-matter experts who can provide some assistance.      
Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments