Systems Integration / SCADA

How vulnerable is your SCADA system?

Maj. Barry Charles Ezell, Ph.D., US Army, asserts that the same theory, model and methods used to quantify vulnerability to critical military infrastructure may be used to assess vulnerability to SCADA.

By Maj. Barry Charles Ezell, Ph.D., US Army

Having been a part the effort to protect critical and military infrastructure for 18 years as a service member of the US Army and nine years of academic research directly related to finding ways to harden water and Supervisory Control and Data Acquisition (SCADA) systems, I have remained interested in researching ways to quantify vulnerability to SCADA. 

Whereas many vulnerability studies identify vulnerable points in systems, most are without quantifiable rigor. I have seen first hand the frustration of military leaders who needed a way to quantify vulnerability to help make better force protection decisions. Unfortunately, quantification was not addressed, until now.

Military and civilian leaders have the responsibility to protect our Nation’s critical infrastructure, communities, and symbols of American power from terrorists, home and abroad, as well as from natural disasters. To this end, assessments are conducted to reduce vulnerability. In my research, I learned that the literature offers multiple definitions of vulnerability, confusing terms such as hazard, risk, vulnerability, assessment and analysis. In my dissertation research, a way to quantify vulnerability to critical infrastructure was developed and then deployed. I defined vulnerability and introduced a theory of vulnerability, induced from the literature. This article asserts that the same definition, theory, model and methods may be used to assess vulnerability to SCADA.

The article is organized into four sections. The first section details the definitions used in the vulnerability model. Following the definitions, a systems-based perspectiveof value systems design is used to describe how SCADA may be decomposed into subsystems and components for measurement and assessment. The second section describes the logic of value models and why the approach works well for quantifying vulnerability to SCADA, as well as other critical infrastructures. The final section is small example of how it may be applied, as well a discussion on how the approach can be scaled to accommodate much larger SCADA systems and multiple perspectives among stakeholders and experts. This is important because if we can quantify vulnerability, we can benchmark and decision-makers can decide the level of vulnerability that is acceptable or not. In addition, resources can be allocated to counter vulnerabilities in a cost-benefit manner.

Vulnerability (?) is defined as a measure of the susceptibility of SCADA to threat scenarios.  Vulnerability is not the same as risk. Risk is a function of scenario, likelihood of the scenario occurring and the associated consequences often quantified as the expected value of damage (lost lives, cost, etc.). My research asserts that vulnerability is a function of 1) threat scenario, 2) protection and 3) importance. The relationship between vulnerability and risk is the scenario. Scenario is often referred to as initiating event and threat scenario. In a very broad way, scenario is sometimes the answer to the question: “what can go wrong”, which is well established in risk assessment. SCADA vulnerability is measured by its 1) deterrence, 2) detection, 3) delay and 4) response capabilities. Importance implies that some SCADA subsystems are more critical to overall system performance than other SCADA subsystems. 

The concept of relative importance in a system’s components comes from the Infrastructure Risk Analysis Model (IRAM) developed in 2000. Protection evaluation measures come from the work of the American Water Works Association (AWWA). Deterrence those measures implemented that are perceived by adversaries as too difficult to defeat. Detection is the probability of determining that an unauthorized action has occurred or is occurring including: sensing, communicating alarm to control center, and assessing the alarm. Delay is defined as the time, measured in minutes that an element of a physical protection system designed to impede adversary penetration into or exit from the protected area. Response is defined as time (minutes) to respond to a threat.

Vulnerability Value Model Design
Decomposing SCADA into functions, subsystems and components is fairly well established practice. This decomposition is convenient for use in a value model. Value models assume relative independence between the structures to the extent to which it is realistic. Value models are an additive preference model. The benefits of a value model are that it avoids arbitrary scaling or aggregation and makes the model flexible for a variety of users. Flexibility is apparent because a value model allows the user to rate possible levels of evaluation measures with different scales to one scale: value ranging from zero as worst to 100 as the best value. Raw data-to-value score is simply a piecewise linear interpolation obtained from the value function. The form of the function can be monotonically increasing, decreasing, or both. A generic value model works in the following way: 1) raw data is entered; 2) value is calculated with respect to value functions; and 3) a global weight is applied.

SCADA may be decomposed into the functions it performs and the subsystems that accomplish each function. System representation of course is only as accurate as the decision-maker’s view that the definition and decomposition reflect his or her personal values of what SCADA is.

Another aspect of SCADA vulnerability value model design is the value function. Value functions transform measures into a value scale (0-100). The shape of the function rests completely on the expert’s personal value of a particular measure. To recap, a value model is an additive preference model in that it assigns value to each attribute measurement on a scale 0-100, using value assignment methodology. Value functions are built through subject-matter expertise assignment and have the following form: where m is the evaluation measure, xm  is the level of the mth measure, vm(xm) is the value of the value function at level xm, and wm is the product of the weights for each level up the hierarchy. 

In summary, a vulnerability value model of SCADA would comprise 1) system decomposition, 2) weight assignment for every component in the model and 3) complete value functions. Finally, it would include assessment for the model to calculate vulnerability. With the model built, the expert assesses SCADA by scoring each measure in the model. The actual assessment for an evaluation measure is then transformed by the model based on the value function. The value obtained is then subtracted from the ideal system score. The gap between the systems actual performance and the ideal score is the omega value of vulnerability.

Implications and Uses
The implication of the approach outlined here is that one may quantify vulnerability to SCADA as well as large-scale complex infrastructures. This is important because if we can measure it, then comparisons, tradeoffs and resource allocation can be logically applied. The model is robust in that it can deal with expert uncertainty in assessments. Instead of a vulnerability score that is discrete, the model allows us to see probabilistic outcomes.



Barry Charles Ezell has 18 years of military service in various command, staff and academic positions. As an assistant professor in the Department of Systems Engineering, West Point, NY, he published numerous papers in the field of SCADA security, risk-based decision-making and systems engineering. Ezell is continuing his research in the development of systems-based vulnerability assessment methodologies and models for critical infrastructure.