Quantifying Cyber Security Risk
August 19, 2006: Brown’s Ferry Nuclear Power Station experiences excessive process control network traffic resulting in a loss of their recirculation pumps. The operators initiate a manual shutdown and take the system to a safe state. A subsequent U.S. Nuclear Regulatory Commission (NRC) report identifies the root cause as excessive traffic on the plant’s computer network from an un...
August 19, 2006: Brown’s Ferry Nuclear Power Station experiences excessive process control network traffic resulting in a loss of their recirculation pumps. The operators initiate a manual shutdown and take the system to a safe state. A subsequent U.S. Nuclear Regulatory Commission (NRC) report identifies the root cause as excessive traffic on the plant’s computer network from an unidentified source. Resulting corrective action was implementation of a firewall to limit external connections and traffic to the process control network. This incident has not been designated a cyber security event.
While the Brown’s Ferry Nuclear Power Station event was not designated a cyber security event, congressional review and comments reviewing the story state that they have “…great concern about the cybersecurity posture of our nation’s nuclear power plants …” This concern transcends the nation’s nuclear power plants to encompass U.S. critical infrastructure and the cyber security of larger supervisory control and data acquisition (SCADA) systemsas well as process control systems (PCS).
Firewalls and other protective strategies must permit unimpeded flow of required information while cutting off unauthorized access.
The nation’s critical infrastructure “…provide(s) the foundation for our national security, governance, economic vitality, and way of life,” says the National Strategy for the Physical Protection of Critical Infrastructure and Key Assets, 2004. For the greatest part this critical infrastructure relies on SCADA and PCSs as means to monitor and control essential processes.
This reliance on computer based systems in the context of changing international terrorist threats, hackers, and disgruntled current and former employees combines to raise the nation’s risk of cyber security threats. While the amount of SCADA and PCS cyber security literature drastically increased after Sept. 11, 2001, most firms still face significant challenges in developing, implementing, and maintaining a cyber security program. One key challenge is that a firm’s cyber security program is just one of many funding requests that senior management decision makers have to consider on a recurring basis. Selecting where and how to allocate limited financial resources is a constant management conundrum further complicated by the recent and rapidly growing number of SCADA system cyber threats.
The changing and increasing SCADA cyber security threats are guiding operators, engineers and senior decision makers into new areas of threat analysis and mitigation. This article’s intent is to provide insight into this growing threat area and a tool to assist in evaluating and quantifying the threats. This tool hopes to address the most difficult aspect of any risk mitigation process: risk assessment. Before a firm can develop, implement and maintain a risk mitigation cyber security program, it must understand the risk. Understanding occurs through the assessment process and tends to be a difficult and subjective effort.
Begin with systems
Applying the model assists all people involved in SCADA and PCS cyber security efforts with a means to understand the range of potential results by merging the areas of risk and consequences into a quantifiable outcome. From this, you can move forward in making better-informed decisions on an appropriate cyber security program level. (For the sake of space, further references to SCADA systems also include PCS platforms.)
SCADA is described as a process of collecting remote system data and status information, presenting it via human/machine interfaces (HMI), that provide system operators visibility of the remote site, and the ability to perform remote control functions from a central location. Over time, SCADA systems have become critical enablers which assist a company to control remote or distributed systems effectively and efficiently to deliver a final product.
The forerunner of today’s technically sophisticated SCADA systems traces back to the 1912 Chicago power industry which relied on telephone lines and voice communications. A centrally located control room supervisor was able to obtain remote power station status from operators and direct control functions. Using this technical innovation, the early day SCADA system enhanced the power grid’s effective and efficient operation.
From these humble beginnings, SCADA systems have evolved into sophisticated technology enablers which allow operation of virtually every type of process control system. They ensure a steady source of reliable electrical power, a steady supply of natural gas to factories and homes, and enhance liquid pipeline control. Many processes now operate at a level of safety, effectiveness, and efficiency never achieved before. Technological advances have made it possible to deploy and operate high speed, near real time, remote monitoring and control SCADA systems.
Modern day, highly advanced technology based SCADA systems are the result of evolutionary change. Beginning with people talking on the phone to proprietary electronic controls operating over dedicated telecommunication systems to today’s highly sophisticated and advanced process control networked based environment, each step forward brought forth greater process control capabilities and enhanced business opportunities but also new or different levels of associated risks.
The risks we will consider are now based on widely deployed computer operating systems, common technology standards, and firms’ greater need to share data across business units and with other firms. These still routinely use public telecommunication infrastructure and standard network protocols which presents a two-pronged challenge: the system has to provide a free flow of data to support business needs, while protecting that data from purposeful or accidental cyber threats. The threat level is a truly global issue and has been escalating at varying rates since Sept. 11, 2001.
A SCADA sysem connected directly to the Internet without any protection will likely be invaded by roving malware within minutes quickly rendeed incapable of operating.
Setting out to quantify SCADA cyber security risk is complex and difficult, yet it is an essential activity. Without a quantifiable risk assignment method, senior management and key stakeholders in your organization are limited in their ability to weigh risks properly against associated costs of a cyber security program in the context of overall corporate financial planning. The absence of hard data hinders key leaders in their decision making process and raises the probability that a cyber security program will not find a suitable position within the corporate strategic and tactical structure.
The risk management process is a three-step process:
Risk quantification; and,
As the U.S. Department of Defense notes, “Risk assessment is the problem definition stage of management that identifies and analyzes (quantifies) prospective program events in terms of probability and consequences/impacts. It is probably the most difficult and time-consuming part of the management process. Despite its complexity, risk assessment is one of the most important phases of the risk process.”
The two key elements of risk assessment are: quantifying the likelihood of a cyber security event occurring, and determining the severity of resulting consequences if the event is successful.
Before proceeding, a note of caution is appropriate. These exercises use ordinal scale ratings to assist the decision making process, but you shouldn’t attribute too much mathematical precision to the results. Ordinal scale values only provide relative representation of order of one value to another. They do not provide a specific measure of differences in the relationships. For example, when using a one to five ordinal scale, if you rate an item one and another two, the second item is not twice as good or bad as the first. The ranking simply shows the second item rates above the first.
One method of quantifying the relationship between severity and probability is shown in Table 1, cyber security risk matrix. This matrix represents one technique to develop a qualitative ordering of risks. The derived rankings are based on the potential outcome or severity of a successful attack and the probability that an attack occurs. Overall, the table provides representative range of potential risk assignment outcomes from a low of C1, with low severity and low probability, to the highest of A3 which represents high severity and high probability of occurrence.
Determination of the risk assignment outcome is derived through an iterative process of assigning probabilities and consequences specific to your company. While the matrix concept is straight forward and easy to understand, making those assignments tends to be complex and difficult, for many reasons, as is discussed.
Attacks from without...
In some respects, asking yourself if you are likely to be the subject of a cyber attack is like asking if you will be struck by lightning. On a sunny day there is little probability, but being on a golf course with no trees during an electrical storm is asking for trouble. The difference is that it is easy to see indicators of lightning but impossible to determine if a hacker is trying to break into your system at any given moment. A tall metallic structure on flat terrain will attract lightning and should be protected appropriately, just as some types of systems tend to attract hackers.
Determining the probably of receiving an attack is something that a company has to do for itself, but it is a very complex judgment call. Returning to the lightning example, it’s as if you can’t see the sky but you still have to make an educated guess or simply prepare for the worst. It involves trying to balance a range of external and internal company factors and attributes that are nebulous at best and often simply unknown. Some of these include external drivers such as how attractive this type of asset is to terrorists in general in the context of the current threat level.
Internal contributing attributes include potential disgruntled employees, overall management philosophy (and how employees regard that philosophy), as well as general cyber security technical capabilities. Quantifying these various attributes is a major component of several SCADA cyber security papers such as McIntyre, Singer, Stamp, and the U.S. General Accounting Office. (See the additional reading sidebar.)
Generally cyber security practitioners divide risks into two categories each with its own threat level:
The risk to a simple, unprotected control system installation running a common, standard operating system connected directly to the Internet (see graphic); and,
The risk to a higher security control system outfitted with multiple levels of protection (see graphic).
The first security risk view is one where a company is operating their SCADA system without firewalls or any other security protection while connected to the internet. An example of this risk was demonstrated by Spencer Kelly’s, BBC Click Online 2005 computer security scenario report. In this experiment, a “clean” computer operating a common operating system was connected to the Internet without a firewall or virus protection software. In this environment, the first virus was detected within seconds and by the end of five minutes the computer’s processing capability was fully consumed with malicious programs.
The message of this exercise is obvious. An unprotected SCADA system based on a common computer operating platform and connected to the Internet will likely be attacked in moments and fully immobilized within hours. Clearly, this has the highest possible risk ranking and must be avoided under any circumstances.
Coming in May 2008: Part 2 —Understanding cyber incidents and their severity helps as you plot a strategy.
M. Henrie is a research assistant professor of logistics at the University of Alaska, Anchorage. Reach him at firstname.lastname@example.org .
P. Liddell is SCADA supervisor at Alyeska Pipeline Service Co. Reach him at email@example.com .
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.