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 Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant 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.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.