Addressing SIS Cyber Security; Is it First or Last?

Amit Yoran, former director of the DHS’s National Cyber Security Division says, “We have a growing problem as our adversaries focus on critical infrastructure. What we need is a layered defense in which the overall system is still available and not subject to a systemic failure.”

Bryan Singer, co-chairman of the ISA99 standards committee, explains how you can use what you know to develop a defense-in-depth architecture that provides the layered defense that Yoran suggests: “The IEC 61508 and 61511 standards define a four-layer model for dealing with process safety requirements in two separate categories, hardware safety integrity and systematic system integrity. This probabilistic model utilizes failure modes and effects analysis to project risk and damages during a system failure, and provides a clear model by which systems can be assessed or implemented to achieve the desired level of safety risk reduction. While many attempt to draw parallels between security and safety, this is one intersection that the lessons are clear and provide an equally effective model for security.”

As you probably already suspected, developing a defense-in-depth security strategy is not as simple as applying the IEC safety standards. Singer cautions, “While the SIL model does supply several interesting options to security analysis, the model does fall short in several areas. Safety focuses more heavily on the likelihood of device faults under normal operating conditions, where normal is considered to be all system components available and functioning in their as-designed state, regardless of a given system failure. Security presents the challenge of being able to violate such design constraints, and also requires additional emphasis on software and network communications integrity.”

Safety systems with a low probability of failing on demand can be designed and installed by properly applying the appropriate IEC safety standards. Similarly security systems can be constructed to provide a low probability of random system failures. But unlike process control and safety systems, security systems frequently incur directed and intentional attacks at multiple levels of the architecture. Thus the single point analysis defined in the IEC standards is not adequate to ensure that a given security device will not fail on demand.

One size does not fit all

Scott Borg, director and chief economist at the U.S. Cyber Consequences Unit says, “We are using the same or similar products to protect oil refineries, hospitals, power grids, and other facilities. It is no wonder we have vulnerabilities. Vendors must develop industry-specific security solutions designed to address the particular needs of critical infrastructure.”

Until recently, process control and safety system security used the same hardware and software as IT departments. In fact, within many organizations there continues to be IT-driven initiatives to force standardized security architectures across the company’s entire communication network. Though the desire to standardize is noble, it ignores the unique requirements of domains such as clinical trials, pilot plants, laboratory systems, manufacturing execution systems, process control systems, and safety instrumented systems.

For example, the long-held belief that hackers don’t understand control and SCADA technologies, which supposedly makes them immune from attacks, has been repeatedly proven false. Also, the increased use of well documented open fieldbus, distributed control, and SCADA systems as well as open communication standards (e.g., OPC and Modbus) makes it much easy for hackers to learn about these platforms and more inviting to develop and share/sell ways to penetrate and compromise associated networks and systems.

Eric Crossman, an engineering solutions architect for Dow Chemical and steering team sponsor for the Chemical Sector Cyber Security Program (CSCSP) of the Chemical Information Technology Center of the American Chemistry Council, explains that big companies like Dow Chemical have been working on securing control systems for a long time, however until 9/11 assessing the vulnerability of these systems remained a low priority.

Like Dow Chemical, following 9/11, others ramped up their vulnerability assessments, but apparently not enough.

Single protection, single failure

September 2005: The Slammer worm penetrated a private computer network at Ohio’s idled Davis-Besse nuclear plant and disabled a safety monitoring system for nearly five hours. The worm entered the plant network through an interconnected contractor’s network, bypassing Davis-Besse’s firewall.

The Davis-Besse incident reveals the fallacy of relying on a single means of protecting the jewels and emphasizes the importance of a business-wide defense-in-depth architecture. An effective approach incorporates hardware and software that is specifically designed to protect unique domains, such as those of control and safety systems.

Within the security industry, efforts are underway to establish hardware and software security assurance levels (SALs)—similar to SIL ratings for safety instrumented systems—however those efforts are still at least a year or two away from making SAL-certified devices available for purchase. In the meantime, it behooves users to assemble control and safety systems using devices that have successfully passed industry-specific, third-party security conformance testing, such as Achilles Certification from Wurldtech.

Connecting control and safety systems

August 2007: A “data storm” initiated by a malfunctioning PLC on Unit 3 of the Browns Ferry nuclear power plant required operators to shut down the reactor manually after two water recirculation pumps failed.

During the past year or so, discussions about connecting or not connecting control and safety systems together has appeared in numerous publications, white papers, blog posts, and conference presentations.

Understanding why this particular topic has garnered so much discussion and coverage really comes down to defining terms. In this particular case the terms being contested when used in the context of control and safety systems are “separated” and “integrated.”

Those in the totally-separated camp often include security vulnerabilities into their arguments: If there are no connections, then the safety system is totally immune from a cyber-attack. Perhaps true, but since many attacks are initiated by “insiders,” eliminating the connection doesn’t necessarily ensure the system is totally immune from a malicious attack.

Those in the integrated camp argue that there are significant operational benefits to spending the time and effort to design an integrated but separate solution. In fact, when properly integrated, people are more likely to be informed of any unauthorized access or changes to the safety systems. Additional benefits to an integrated control and safety solution include:

Consistent development and operating environment;

Reduced training costs;

Simpler architectures;

Reliable and fast communications;

Reduced implementation and startup time;

Improved status information handling; and

Improved fault handling.

When fully studied and understood, what makes developing an integrated yet separate solution not only possible but practical is the fact that IEC 61508, which is the foundation for IEC 61511, is a performance-based standard and not a prescriptive-based standard.

Paraphrasing IEC 61508-1, Clause 7.6.2.7 it is possible to meet the standards separation requirements as long as the control and safety systems use different:

Components;

Chip sets;

Operating system software;

CPUs;

Power sources;

Cabinets with unique key locks;

Communication networks;

Engineering workstations; and

Test and maintenance procedures.

That means that you need to be prepared to demonstrate, through quantified analysis, calculations, design documentation, and documented operating and maintenance results, that the system will operate as expected when called upon. If or when the control system fails and places a demand on one of the safety-related systems, that the cause of the control system failure will not have a negative impact on the safety system’s ability to perform its defined safety functions. If all works in that manner, your integrated solution conforms to IEC safety standards.

From a cyber security perspective, these IEC 61508 diversity requirements are consistent with an effective defense-in-depth architecture. Assuming that separate communication networks include appropriate firewall and intrusion detection means, the safety system network is at least one layer deeper in a defense-in-depth architecture than the control system.

When carefully analyzed, the ability to connect control and safety systems together safely and securely requires understanding and carefully considering all applicable standards and recommended practices. Following a correct interpretation of the applicable standards as well as the proper application of good engineering practices, then it is possible and beneficial to design, specify, implement, commission, operate, and maintain an integrated control and safety system implementation.

Not a one-shot effort

September 2007: Hackers compromised dozens of Department of Homeland Security (DHS) computers, moving sensitive information to Chinese-language Websites. Investigators pointed a finger at Unisys Corp., a government contractor with a $1 billion dollar contract to safeguard DHS computers, saying the firm tried to hide the incidents from the department.

Most people these days are familiar with the circular continuous improvement and life-cycle diagrams that accompany anything that requires some sort of risk assessment.

At home, we review our retirement investments; our life, auto, health, and homeowner’s insurance; and the like. In the workplace, periodic risk assessment and mitigation reviews are conducted for such things as regulatory, environmental, legal, customer satisfaction, employee health and safety, information technologies, share-holder value, and similar metrics.

When you factor in our voracious appetite for ever increasing advanced technologies to help us stay in touch 24/7 and reportedly make us more productive, it becomes clear how these same technologies increase our vulnerability to attackers and their increasingly advanced weapons.

For example, in the US-CERT Cyber Security Bulletin dated January 14, 2008, there were three medium vulnerabilities listed for Apple’s iPhone.

Does that mean that an attacker could sit in a doctor’s waiting room and use BlueTooth technology to attach an undetected Trojan into the iPhone of every pharmaceutical sales person that enters that office that day? Does that mean that when those sales persons return to their respective offices and place their iPhones into the synchronization hub that the embedded Trojan enters your network? That is only one high-tech attack vector.

Considering all the factors discussed in this article, when it comes to the question of whether SIS cyber security should come first or last, the answer is : neither. Addressing SIS cyber security in isolation is foolhardy and likely to create a false sense of security. Process control, process safety, and security, including cyber security, are so entwined that the only way to achieve a robust, safe, and secure solution is to assess, analyze, and include them as part of a company-wide defense-in-depth business continuity architecture.

Author Information

Bob Huba is a senior product manager for Emerson Process Management and coordinates security and cyber security initiatives for DeltaV products. Chuck Miller is the business development manager for safety instrumented systems for Emerson Process Management.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.