Quantifying Cyber Security Risk

Part 1 of this article appeared in Inside Process in the March 2008, issue of Control Engineering. Cyber security practitioners generally divide risks into two categories, each with its own threat level: The first security risk view is one where a company is operating its SCADA system without firewalls or any other security protection while connected to the Internet.


Part 1 of this article appeared in Inside Process in the March 2008, issue of Control Engineering.

Cyber security practitioners generally 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).

A SCADA system connected directly to the Internet without any protection will likely be invaded by roving malware within minutes and quickly rendered incapable of operating.

The first security risk view is one where a company is operating its SCADA system without firewalls or any other security protection while connected to the Internet. Such an unprotected SCADA system based on a common computer operating platform and connected to the Internet will likely be attacked within moments and fully immobilized within hours. Clearly, this category has the highest possible risk ranking and must be avoided under any circumstances.

That being the case, the second risk profile is more appropriate for an actual operating SCADA system. In this view, the relevant risk is associated with a specific targeted attack rather than a random cyber threat from the host of malicious software code roaming the Internet looking for unprotected systems.

One way to evaluate your situation is to examine historical precedents, including cyber incidents in your company and industry. If there is sufficient historical information available, the risk analysis team can extrapolate or interpret the historical findings into probability of future occurrences. As most companies lack sufficient internal historical occurrences to form a realistic assignment, development of a risk probability assignment is reliant on industry reported events. Bear in mind that cyber activity is on the rise, so don’t delude yourself into believing it will remain at historical levels. Always assume your historical picture is incomplete and hacking activity levels will only go up.

There are disagreements within the cyber security community on the number and frequency of reported SCADA cyber security attacks. Some sources indicate a very low level of reported attacks, while others indicate a much higher level with trends continuing to point up. This discrepancy leaves engineers wondering how to best interpret the data.

Understanding cyber incidents

Thoroughly documented accounts of cyber security incidents are relatively rare. Victims are understandably reluctant to discuss details and experts don’t like to glorify or encourage cyber criminals. Consequently, cyber security literature tends to discuss the same specific, verifiable, SCADA cyber security occurrences:

  • April 2000, Maroochy Shire, Queensland, Australia, sewage released into parks, rivers and a hotel;

  • May 2001, California Independent System Operator, hackers gain access to one of the computer networks but are unsuccessful at penetrating any control network;

  • January 2003, Slammer worm penetrates the control system of a U.S. nuclear power plant; and

  • January 2008, The CIA reports that cyber criminals broke into an unidentified electric utility (outside the U.S.) and shut down service as part of an apparent extortion scheme.

Firewalls and other protective strategies must permit unimpeded flow of required information while cutting off unauthorized access.

Others cite a much wider range of events. Byres and Lowe of the British Columbia Institute of Technology (BCIT) compiled an industrial cyber security incident database from 1995 to 2003. They report that database holds 41 incidents, of which 34 were judged to be events of sufficient quality for statistical analysis. The analysis spans the years from 1995 to 2003. Between 1995 and 2000, reported cyber security attacks ranged from one to three per year. Starting in 2001 the events show a steady increase with four in 2001, six in 2002, and 10 in 2003.

While there are different opinions on the frequency of verifiable SCADA cyber security events, one consistent and common theme is that the number is understated. The lack of reporting is driven by industries that do not want to release this type of negative information in addition to a lack of regulatory requirements to report to any specific body. Once a company accepts the reality of cyber crime and terrorism, it must then analyze the probability that an event will occur in its systems.

Quantifying the probability of a company-specific event occurring is a complex activity built on analysis that is at best subjective. Lacking concrete and verifiable threats, such as might be supplied by the U.S. Department of Homeland Security, any risk analysis must begin by asking some potentially difficult questions:

  • Will we be subjected to an attack from the inside by a disgruntled employee, like the Maroochy sewage release;

  • Will a hacker find us purely at random for personal amusement or notoriety;

  • Could malware prowling the Internet slip through our protection;

  • Is a hacker trying to break in for extortion purposes or other financial gain;

  • Are terrorists breaking in to make a political or religious statement; and,

  • How attractive a target are we to hackers.

Each company undergoing a risk analysis must at least try to establish an individualized risk probability factor based on risk attributes. One certain thing for any company operating SCADA systems is that the probability of occurrence is not zero. Once a firm has established a probability of occurrence, the next step is to identify the severity or consequences of a successful attack.

Understanding severity

Deriving a severity of occurrence ranking is complicated by the breadth of the range of potential outcomes possible for every system. A low consequence event would be that a hacker has simply gained access to the system, but with no negative consequences. The California Independent System Operator hacker incident mentioned above is an example of this type. On the other end of the spectrum is an event that triggers catastrophic effects that can include loss of life, extensive environmental harm, and may result in the company going out of business. The difference between a low consequence and catastrophic hacking event may hinge on what valve a hacker decides to open once he is in your control system.

Anticipating the possibilities involves some worst-case scenario analysis, such as:

  • Potentially explosive process accidents;

  • Disruption of utility service delivery;

  • Contaminated product due to recipe tampering;

  • Release of finished product or feedstocks with environmental consequences;

  • Damage to process equipment;

  • Loss of operational data and manufacturing history;

  • Loss of production capacity during recovery and cleanup; and,

  • Company-specific possibilities based on the nature of your manufacturing operations.

After identifying these potential consequences, the next step is ranking them, rather than trying to assign a specific value. It can be difficult to compare a loss of feedstock against damage to equipment given the potential severity range for either event. Moreover, the two functions may be protected by the same mitigation solution. Nonetheless, clearly identifying a set of risk levels, depending on the derived probability and consequence severity assignments, provides decision makers a set of support values to use as they consider potential risk mitigation efforts.

Writing on the wall

Successful cyber attacks could cause widespread electrical outages, similar to the August 14, 2003 Northeast blackout, or loss of other essential services such as natural gas deliveries. While not a cyber event, the Northeast blackout did demonstrate the magnitude and effect that major SCADA system events can have. The results of this single event impacted at least 50 million people and caused at least $6 billion in financial losses.

Each company has to balance the risk of a potential SCADA cyber security event, the effects an event could have on the company, its customers, and other stakeholders, as well as the cost of a cyber security mitigation program. The hardest step in the design and deployment of the overall risk mitigation strategy is quantifying the risk. However, when done in an objective and thoughtful way, a company can increase the effectiveness and reduce the cost of a subsequent protection strategy program.

Author Information

Morgan Henrie is a research assistant professor of logistics at the University of Alaska, Anchorage. Reach him at afmeh1@uaa.alaska.edu .

Paul Liddell is SCADA supervisor at Alyeska Pipeline Service Co. Reach him at liddellp@alyeska-pipeline.com .

No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

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.