Last week’s SRA 311 (Risk Management: Assessment and Mitigation) lectures focused on all things vulnerability.  As defined in a much earlier lecture, the general qualitative (albeit probabilistic) expression for risk, R, is as follows:

R = {<e,p,o>}  (1)

where e is one of among many types of initiating events, o is one of many outcomes of concern, and the probability p is the joint probability of both e and o occurring, or:

p = Pr(e,o) = Pr(e)Pr(o|e)  (2a)

= Pr(o)Pr(e|o)  (2b)

where Pr(e) is the probability of event and Pr(o|e) is the vulnerability to realizing outcome o given e has occurred.  The use of the curly braces “{” and “}” in Eq. 1 implies that risk is the complete set of triplets for all possible combinations of e and o for a given situation (i.e., cross product of E and O, where E and O are the sets of all events and outcomes, respectively).  And it must be kept in mind that the scope of the risk analysis constrains how e, o, and p are assessed.

Common, but Apparently Different, Expressions for Risk. Now, the experienced risk practitioner might question why Eqs. 1 and 2 look so dramatically different than the prototypical formula for risk:

Risk = Threat × Vulnerability × Consequence (3)

As it turns out, the “colloquial” expression for risk in Eq. 3 is identical to the expression I put forward in Eq. 1.  To see this, let’s examine what Eq. 3 actually says.  The “colloquial” expression for risk states that risk is the combination of threat and vulnerability and consequence, that is, the “×” denotes the cartesian product and not the more restrictive arithmetic product.  Equation 1 says the same thing, namely that risk is the combination of all pairings of initiating events (e.g., threats), outcomes (e.g., consequences), and the probability that binds them.  This probability, according to Eq. 2a, is largely a function of the system states that enable event e to result in outcome o (e.g., vulnerabilities).  Again, Eqs. 1 and 3 are essentially the same, although I must admit that it is much easier to explain Eq. 3 to decision makers than it is to even come close to explaining Eq. 1.

So what about the commonly accepted definition of risk as “probability times consequence?”  This simplification of risk is actually equivalent to Eq. 2a under certain assumptions.  Equation 2a provides a means for expressing the full probability distribution over the space of potential outcomes.  If the outcomes o are expressed on a cardinal or ratio scale, then one can find the expected value of the vulnerability term, where the expected value is actually the expected loss given occurrence of an event (see any basic textbook on probability and statistics to see how this is done).  With vulnerability expressed as expected loss, Eq. 2a reduces to a probability times a consequence.  Alternatively, one can decompose the vulnerability term into two distinct probabilities as follows:

Pr(o|e) = Pr(o|e,s)Pr(s|e)  (4)

where Pr(s|e) is the probability of adversary success given attack (obviously this value is one when natural events are considered) the Pr(o|e,s) is the probability of an outcome given a successful attack.  Here, one can find the expected value of the outcome probability Pr(o|e,s) to arrive at a value for expected loss given a successful attack.  Again, Eq. 2a reduces to a probability times a consequence, albeit this time the probability is the product Pr(e)Pr(s|e) and the consequence is the expected loss given adversary success.  In fact, this is the form of Eq. 2a that is most often used in probabilistic security risk methods.  But it is important to note that Eq. 4 is just one version of Eq. 2a, and that there are many others that are simpler or more complex depending on the needs of the decision maker.  But in the end, Eq. 2 (both a and b) is the most general conceptual expression for risk.

Vulnerability As Notion and Vulnerability as Measure. As a notion, Professor Yacov Haimes at the University of Virginia defined vulnerability as “the manifestation of the inherent states of a system that can be exploited to adversely affect that system” (see “On the Definition of Vulnerabilities in Measuring Risks to Infrastructures” by Yacov Haimes, Risk Analysis, Vol. 26, No. 2, pp. 293-296 (2006), doi:10.1111/j.1539-6924.2006.00755.x).  According to this definition, a system is said to be vulnerable if there exists a combination of system states that renders it susceptible to adverse effects (outcomes) arising from a particular exploit (initiating event).  Consistent with this definition is the measure of vulnerability according to the term Pr(o|e).  This vulnerability term can be read as follows: “vulnerability is expressed as the probability of a given outcome following the occurrence of a specified event.” This probability is shaped by the performance of the system under the stress imposed on it by the initiating event, where higher values of this probability for a given combination of (e,o) indicate a greater susceptibility to harm of loss.

A more generic definition for vulnerability was offered in the paper “Vulnerability and Risk: Some Thoughts from a Political and Policy Perspective” by Sarewitz et al and published in Risk Analysis, Vol. 23, No. 4, pp. 805-810 (2003) (required reading for a large fraction of the class): “vulnerability is the inherent characteristics of a system that create the potential for loss.”  While similar to the definition posited by Haimes in the context of protecting infrastructures against acts of terrorism, the Sarewitz definition is more generic in that it asserts that vulnerability creates risk (where risk is defined as, in the more restrictive sense of security, as the potential for harm).  In fact, Sarewitz et al. emphasizes that “understanding and reducing vulnerabilities does not demand accurate predictions of the incidence of’ events.  This statement is 100% consistent with Eq. 2 in that vulnerability reduction yields a reduction in risk even in the probability of event remains unchanged.  For security managers this point is particularly important given the fact that it is insanely difficult to express likeliness of adversary actions in quantitative form.  Perhaps it is no surprise that vulnerability assessment is the prime focus of a security professional’s career, where the meager threat assessment (i.e., event likeliness assessments) are then used to help prioritize vulnerabilities for management attention.  Risk management, then, examines the actions taken by security practitioners to reduce the vulnerability for those event/outcome pairs that make management most nervous.

Extreme Events. Sarewitz et al. also made another point I think is very important: “extreme events are created by context.”  I wrote at length about this point in a previous post on natural perils, natural hazards, and natural disasters.  In themselves, events are not disasters; for example, a hurricane is not labeled a disaster until it has affected some system.  Before then, a hurricane is simply an event that one might label as a peril or hazard.  The label “disaster” is assigned only to events that have occurred and wrought a significant toll on the interests of an individual or group of individuals.  An extreme event is a game changer event, and much like a disaster is one that disturbs the affected system enough to change its configuration with respect to its pre-event state (e.g., population redistribution, new reactive policies, etc.).  It makes no sense to assess the vulnerability with respect to disastrous events because the mere label of disaster implies significant vulnerability.  Whether or not an event becomes a disaster depends on the magnitude of the vulnerability to outcomes one labels as disastrous given an event has occurred.  That is, the context of the matter determines which outcomes are disastrous and which are not, and the vulnerability assessment then can produce insights into the potential for disaster in the face of a triggering event.

How Vulnerability Assessment Is Done. Unlike previous lectures where I was able to provide guidance on constructing complete sets of events and outcomes, I could not offer my students similar tools for doing vulnerability assessment.  Why?  Because vulnerability assessments fall under the category of messy problems.  While it may be straightforward to articulate potential causes of harm and define a set of undesirable consequences, it is not a trivial matter to make defensible statements about the probability that an event will lead to a particular outcome.  Such statements insist that the analyst possess intimate knowledge of all aspects of the system under study, to include its security system, structural configuration, and response and recovery capabilities.  Even if you reduce the vulnerability problem into separable components (e.g., protection vulnerability and response vulnerability such as is described in a paper I coauthored), the level of knowledge required to do a vulnerability analysis is quite extensive.  Yet, people manage to do vulnerability assessment anyway.  How do they do it?

Well, if one appeals to the science of Naturalistic Decision Making, meaningful vulnerability assessments insist that that the vulnerability assessor has command over the two major sources of power: pattern recognition and mental simulation (I wrote something about this in a recent post on the (very tentative) McGill descriptive vulnerability assessment model).  Pattern recognition, a power that arrives at only through experience, enables an individual to quickly pick out the most significant environmental cues relevant for a given problem and use these cues to assess the degree to which the environment is similar to other situations from his experience.  In the event of a match (the likeliness of which increases with more personal experience), an individual uses his or her mental simulation power to quickly conduct thought experiments that “challenge” the environment and predict how it will respond to different initiating events.  (notice my use of the word “quickly”: have you ever seen a former special forces solider do a vulnerability assessment?  The more experienced the soldier is, the more quickly he or she can do a vulnerability assessment that means something).  I suspect that this simulation process for vulnerability assessment is iterative in that one starts with an outcome, backs out plausible events that might yield that outcome, reappraise vulnerability with respect to each identified initiating event, and so on.  But in the end the breadth and depth of the assessment is highly sensitive to the experience, objectivity, and biases held by the assessor.

But here is my challenge – I must teach vulnerability assessment to individuals with a minimum amount of background knowledge.  How can I do this?  The solution lies in the simple fact that when under pressure to produce answers, the lack of knowledge to render a defensible judgment is typically compensated for by bias, gut feel, and guesses.  One way to enable defensible analyses is to provide students with a wide array of structured analytic techniques aimed at alleviating all those aspects of reasoning that are detrimental to the end product (much like the way the intelligence community does it).  This is my focus of Part II (risk assessment) of my course – to provide a suite of techniques to help less experienced risk assessors properly structure their thinking so as to make sense of a particular situation and explicitly identify all uncertainties.

An Exercise on Vulnerability Assessment. To highlight the difficulties in actually doing a vulnerability assessment, I had my students spend 30 minutes of the second lecture assessing the vulnerability of Penn State campus (University Park) to disaster (note that much like most questions encountered in practice, I deliberately kept the question vague).  This exercise insisted on brainstorming what types of events would be considered disastrous, then identifying a spectrum of different causes for each type of disaster.  I provided no techniques for doing this in attempt to see how my students would reason through the problem.  The responses were mixed – what constituted a disaster varied among student groups, as well what types of events could causes disaster.  Perhaps this is because not a single group put themselves in the shoes of a campus decision maker; rather, each group adopted a personal view of disasters and their causes.  As I emphasized in class, analysis done in this manner imposes the personal biases of the analyst on a problem whose answers would inform a decision maker that might have a different opinion of what a disaster is.  The first step in any risk analysis is to know your customer well enough so as to properly frame the associated questions.  Overall the exercise went well, and provided me with good insight into how to proceed with part II of the course.

My Take on the Lecture

As a whole, I think I could have done better with this week of lectures.  For one, I assumed that the students had more background knowledge in probability than they really had.  In hindsight, I should have incorporated basic concepts from probability theory throughout the discussion of vulnerability.  I will definitely try this approach in next semester’s offering of SRA 311.  However, since vulnerability is a conditional probability, I am now forced to restructure the syllabus to start with a discussion on basic probability before getting into Bayes’ rule.  Essentially, this means I need to start with event likeliness (the topic of lecture 9) before lecturing on vulnerability.

A second thing I noticed was that I really talk too much, particularly on the topic of vulnerability assessment.  While this isn’t always a problem, the topic of vulnerability assessment is dry as a bone unless one already has some experience doing it.  In attempt to liven the discussion up, I intend next semester to incorporate more in-class exercises to flex students’ neural muscles on the topic.  Some ideas I have in mind include online worksheets that ask students to make general statements of vulnerability for a variety of high-level scenarios, another case study pegged to some current event (the recent bombing in Pakistan, as horrible as it was, would have made for a good case study focused on what makes a system vulnerable), and so on.  Feel free to share your thoughts or ideas, if you have any.

Send article as PDF to