The trouble with likelihood

It’s common to see charts similar to the one below used to communicate risk.  On one axis we have Impact, and on the other we have Likelihood.  We’ll save a discussion regarding Impact for another post, but in this post I’d like to point out a couple of subtle but important limitations with the term “likelihood”.

Likelihood connotes the probability of an event occurring.  In fact, you may see explicit probability ranges assigned to each qualitative label (e.g., “Very High = 90% to 100% probable”).   And, while this seems to be on the right track, there are two problems with it:

• It often doesn’t include a timeframe reference.  In other words, does the likelihood statement refer to the probability of the event occurring this week, this year, in this lifetime?
• It doesn’t provide the means to differentiate between something that may happen once vs. something that may happen multiple times.  For example, a statement; “The likelihood of a virus infection is Very High” doesn’t differentiate whether the event is likely to happen once or many times.

These two limitations become critical when we’re trying to quantify and/or compare risk issues.

Using frequency, we can account for events that occur many times within the defined timeframe as well as those that occur fewer than once in the timeframe (e.g., .01 times per year, or once in one hundred years).  Of course, this raises the question of how we determine frequency, particularly for infrequent events.  In the interest of keeping this post to a reasonable length, I’ll cover that another time (soon).

Drawing lines

You may have seen charts like the ones below, with lines drawn to differentiate High from Medium, etc.

(NOTE:  Magnitude scales will vary based on the risk capacity/tolerance of the organization)

These can be useful, but a few challenges I’ve encountered with this approach include:

• If the risk point falls barely on one side of the line or the other, do the lines really serve a useful purpose, at least from the perspective of being able to assign a qualitative value?
• Who drew the lines?  At one place I’ve worked, I couldn’t get management to provide guidance on where to draw the lines so I took a stab at drawing them based on what I thought management’s risk tolerance was given their earlier decisions.  This seemed to work okay, as I didn’t experience much push-back from management, but you need to constantly look for evidence that the lines need to be changed.
• Particularly in larger companies with multiple affiliates or subsidiaries, line placement will vary because each part of the enterprise will have its own risk tolerance.  A “critical” loss at the subsidiary level might not equate to a rounding error at the enterprise level.  I’ve dealt with this by plotting results on two charts; one scaled to the enterprise risk tolerance, and another drawn to the subsidiary’s tolerance.

Of course, the fact that the point isn’t really a point at all, but the intersection of two ranges or distributions further affects the utility of lines.

I’ve found two ways of charting risk that seem to be well received by management (below).

(NOTE: These charts were created using Monte Carlo analyses within FAIR-based applications)

My preference is the scatter plot, which does a nice job of visualizing the uncertainty that is a part of any risk analysis.  A couple of things to note:

• No lines have been drawn to label the result “High”, “Medium”, etc.
• I haven’t used a green-to-red background on the charts.

I will use those illustrative tools if requested by management, but I tend not to use them otherwise.  Besides the challenges I noted above regarding lines, my rationale is that lines and colors tend to bias interpretation of the results.  In other words, if someone sees a risk point plotted in a red background or in the “High” section of the chart, they equate those results as “unacceptable”.  The fact is, the acceptability of a risk condition is often dependent on the value proposition of the situation, the cost to mitigate risk, etc.  I’ve found management is intelligent enough to know that the upper-right part of the chart means more risk than the lower-left.

Shrdlu is entertaining and insightful and writes everything I wish I could have written on the Blogo-topic du jour, GRC.

Because many organizations are beginning to wrestle the funding beast at this time of year, I thought I’d focus this week’s post on the question of “appropriate funding”.  It only tangentially touches on the question of communicating about risk, but I’ll return to part two of that series next week.

One of the arguments I’ve heard folks use to dismiss the notion of a risk-based approach to security is that it’s been tried and failed.  The argument goes on to claim that it isn’t possible to get appropriate funding for security because management just doesn’t “get it”.  And, while I agree that many (most?) past attempts at risk-based security have struggled, I’d submit that it was because the methods used didn’t address risk effectively.  They often focused solely on worst-case outcomes (which is the Chicken Little problem), didn’t apply any rigor in determining risk, simply focused on vulnerability (but called it “risk”), or treated the problem as a possibility issue versus a probability issue. 

Of course, the argument about funding begs the question of what constitutes “appropriate funding”.  It’s naive (or arrogant) to believe that I — as an information security professional — am in a position to understand the incredible mix of business issues that determine the right risk-balance for an organization.  Running a business requires weighing the various risk-domains management faces (investment, insurance, product, market, security, etc.) as well as complex value propositions in light of the organization’s objectives and limited resources.  And, while it’s imperative that information security professionals seek to understand the business side of the equation, we are never going to have the same breadth and depth of vision into the organization’s unique mix of business issues that executive management has.  Combine that with the fact that it isn’t our risk tolerance that matters, and it should be crystal clear that complaints of being “underfunded” have to be cast in the light of “Compared to what?”.  Compared to what we think it ought to be?  Compared to some industry baseline of questionable applicability to our organization?

Of course, I struggled to get management support for years.  I tried leveraging fear, uncertainty, and doubt.  I also tried the old “You have to do it because it’s best practice” card.  And although both of these can work for awhile, at the end of the day, management’s perspective will likely be that you’re paranoid and you lack perspective about the nature of running a business.  I’ve come to the conclusion that if I believe I’m underfunded, then it’s likely:

• I haven’t done a good job of communicating risk to the business, 
• I don’t sufficiently understand the risk tolerance of the organization’s leadership, and/or
• I don’t understand the mix of competing risk issues, resource limitations, or business objectives.  

It’s my responsibility to see that I’m not underfunded by providing high quality (unbiased) risk information to management.  If I do that, then I can expect to receive an appropriate level of funding given the other business considerations management faces and their risk tolerance.  The funding may be less than I’d like given my risk tolerance, but that’s a personal problem. 

Frankly, since taking a risk-based approach to my job, I’ve had very little difficulty getting management support for the stuff that matters most.

In his comments a couple of weeks ago, Walter brought up an important point.  Paraphrased, he pointed out that misrepresenting the precision of an analysis is a bad thing.  He also pointed out that this isn’t so much a problem with the analysis model (although it’s more likely to occur with a quantitative model), but rather tends to be a problem with how an analyst communicates results to management.

With that in mind, I thought I’d write a couple of posts about communicating risk.  In this week’s post, I’ll talk about “risk qualifiers” that can be critical in helping management understand the true nature of some risk scenarios.

“I can live with this…”

Let’s say that you’ve done an analysis and the results look something like what’s shown in the charts below (I’ve included both a qualitative and a quantitative version):

At first glance, a decision maker might think “This doesn’t look so bad.  I can live with this level of risk.”  But that’s not necessarily the whole story…

Unstable conditions

An unstable risk condition exists when the following characteristics co-exist:

• Threat event frequency is low
• Vulnerability is high
• Probable loss magnitude is significant

When these conditions exist, the low loss event frequency is driven solely by the low threat event frequency.  In other words, we’re not actively managing loss event frequency; we’re just trusting to luck.  If threat event frequency changes (or an event occurs at all), then significant impact will likely occur.  An example might be an internal application that handles a significant volume of sensitive consumer records, but that has little or no authentication or authorization control in place.

Now, if all we provided management was a qualitative “Medium/Low” risk statement or a quantitative statement that “probable loss event frequency is roughly once every ten years with a probable loss magnitude of $500k”, then we haven’t really allowed management to make an informed decision.  

This additional information about the unstable nature of the risk condition is critical for a couple of reasons:  1) it allows management to decide whether they want to gamble, and 2) instability can reflect poorly from a due diligence perspective.  

Fragile conditions

A fragile condition exists when the following characteristics co-exist:

• Threat event frequency is high
• Vulnerability is low, but dependent on a single effective control
• Probable loss magnitude is significant

At a glance, this will look similar to an unstable condition.  In this case however, a single control is all that prevents a high loss event frequency.  An example might be a single layer Internet architecture, where the volume of threat events is high but the firewall is generally quite effective.   

Differentiation

One big advantage these qualifiers provide is to be able to differentiate between risk conditions that, from a risk chart perspective, look the same.  This differentiation allows us to prioritize better, which leads to more cost-effective risk management.  

Another advantage is that it provides nomenclature for expressing what our intuition has probably already recognized.  In other words, the experienced information security professional would intuitively recognize the difference between an unstable or fragile condition and one that isn’t (but that may look the same on a chart).  In my experience, what we tend to do in those instances is label the condition “high risk”.  The problem with this is that it  lumps these scenarios in with those where loss event frequency and loss magnitude are high, which erodes management’s ability to prioritize effectively.

At the end of the day, effectively managing any complex set of issues requires an ability to differentiate.  These qualifiers have proven to be extremely useful in that regard.

“Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.”
- Bruce Schneier

For me, acquiring a “security” mindset wasn’t tough.  I was lucky enough to work with some great penetration testers.  The whole “social engineering” thing was easy to “get”, too.  By my second engagement, I acquired a love for figuring out how to manipulate the denigrated bureaucracy.

The problem with the security mindset is that, in risk analysis, it carries over as a bias.  When I’m out training organizations, there’s usually a really smart guy with ages of cybercop experience who will devolve the conversation about Vulnerability (Threat Capability vs. our Controls) into how he would use his knowledge of the systems and their weaknesses to possibly steal millions and millions of dollars/identities/trade secrets/whatever in a particularly clever way.  It happens every session.  It’s not a bad thing - but it has to be qualified within the context of the applicable threat community.  Are we really worried about an uber-brilliant admin with 20 years at the company and intimate knowledge of the systems architecture as a threat community?  Maybe we are, and if so this is a great and relevant discussion.

But if we’re not able to throw the resources at a problem needed to address someone whose skills and resources are in the top 1/10 of 1% of the threat community out there, what we’ve done is had a rabbit trail conversation that *if* an attacker had near perfect knowledge of the system and it’s defenses, it would be possible to evade prevention, detection, and most likely response until it was too late.  Great, but there’s a bias there that we’re carrying into the discussion because of the security mindset.

Thing is that once the security mindset matures with experience we *know* that it is possible for any system, regardless of physical location or vendors that supply software, to be compromised.  The question the risk analyst must answer however, is really “What is *probable*?”.   And we should really belabor the point that “What is probable?” is not just a “Can it be done?” question. Yes, Level of Effort or Skills & Resources are relevant pieces of prior information, but what is similarly (if not more) important is the concept of frequency of events - or “*Is* it being done or more likely to be done in the future, and at what rate?”

EXAMPLE OF THE DIFFERENCE

There should probably be a Godwin-esque law about 9/11 examples and security by now, but you’ll forgive the indulgence.  Post 9/11, we had all sorts of questions about the risk of attackers and national infrastructure.  And the reason isn’t because we couldn’t imagine all sorts of creative attacks against nuclear power plants, metropolitan water supplies or large visibility entertainment venues.  Our uncertainty was due to a perceived possibility in an increase in frequency.  They did something spectacular once, (when) will they do it again?

This should be the mindset of the risk analyst.  Understand that it can be done, and how it may be accomplished, to be sure.  But it’s imperative that we frame that knowledge within the context of frequency and impact considerations.

For me, the good news is that mindests don’t seem to be fixed.  Training analysts in FAIR has shown me that these mindsets can be learned and unlearned.  In fact, I’m starting to think that a sign of IQ/EQ/Whatever might be said to be the speed with which one may adopt other mindsets.

Relevant References:

http://www.bloginfosec.com/2008/04/10/the-misleading-nature-of-schneiers-security-mindset/

http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html

Another perspective on risk management that I’ve found useful is to recognize that risk issues are “open-ended” in nature rather than “well-structured”.  Well-structured problems can be reasoned to a single correct answer – e.g., 3+3=6, or “Will I overdraw my bank account if I write this check?”  Open-ended problems, on the other hand, are those that can’t be reasoned to a single, undisputed correct answer. Examples of open-ended problems include:

• What’s the right solution for peace in the Middle East?
• What’s the best financial investment or insurance plan?
• Should I step on the accelerator or the brake at this yellow traffic signal?

Most of the information security/risk problems we face are open-ended – in other words, there are very few clear, undisputed correct answers.  Examples of open-ended questions we’re forced to deal with include:

• What’s the best solution for this risk issue?
• Is this amount of risk acceptable?
• What is the highest priority of our many security issues?

Because these issues defy simple, indisputable answers, and because each of our circumstances will vary, we’re forced to apply critical thinking skills.  This, of course, flies in the face of prescriptive standards and “best practices” that try to portray the risk landscape as black and white (well-structured) when it’s clearly shades of grey (open-ended).  To be fair, non-prescriptive standards and “best practices” play an important role as directional references — compasses so-to-speak.  But even a really good compass can’t always account for the unique circumstances we encounter.

As I see it, any grade school graduate can recite a standard or compare a checklist against what they see in front of them.  Whether we realize it or not and whether we like it or not, we have to prioritize, make decisions, and defend/explain our rationale within a complex open-ended environment.  Sometimes a specific best practice or standard will be the most cost-effective solution for a given circumstance; sometimes it won’t.  The important thing is being able to recognize the difference.  That’s where critical thinking comes in, and that’s where we provide real value as professionals.

An interesting one-page matrix (in a Word document) that categorizes thought process maturity can be found here.  It’s worth a read.

(Third in the series regarding vulnerability)

Apologies in advance, for the length of this post…

In a perfect world…
… we’d know which specific threat agent was going to act against us and know the capability of that threat agent in absolute terms (e.g., pounds per square inch), as well as know (through testing) what our resistance capabilities are in those same absolute terms. If we had this information AND assuming this information was precisely correct all of the time, vulnerability becomes a clear and simple binary consideration — we will be or we won’t be.

Stating the obvious (anyway)
Losses occur when threat events take place that we’re vulnerable to. This is true whether we’re talking about weather events, human error, or malicious acts. Obviously, we don’t experience loss with every threat event, which means we’re only vulnerable sometimes — i.e., less than 100% of the time. This means there is some probability associated with whether we’ll be vulnerable to any given threat event. The process of measuring vulnerability is intended to help us understand what that probability is likely to be.

Simplest approach
Perhaps the simplest approach is to identify the threat community you’re analyzing risk against and simply estimate your ability to resist the capabilities of that threat community. For example, we might estimate that our web application is capable of resisting all but the top 2% of the cyber-criminal threat community — i.e., two out of a hundred hackers have the skill and resources to defeat the application’s security.

This works as a quick-and-dirty solution, and in many cases is good enough. Read on if you’re interested in a somewhat more involved approach.

Uncertainty
Unfortunately, in the real world we usually don’t know:

• Which threat agent is going to act next,
• What their capabilities are, or
• What our resistance capability is going to be

Making matters even more challenging:

• We don’t have an absolute measurement scale for some threat categories (e.g., human capability)
• Our measurements are imprecise (e.g., we can’t measure force or resistance perfectly)
• One or more of the values being measured may vary over time (e.g., hurricane wind speed varies throughout the lifetime of the storm, and strength can change throughout the lifetime of a control )
• One or more of the values being measured may vary across a population (e.g., not all hurricanes have the same wind speed)

When absolute scales apply
(Warning: This is an illustration and not an engineering exercise, for those who might want to argue details.)

Some types of threat categories can be measured using absolute scales (e.g., wind speed in miles per hour), which makes things a bit more straightforward. For example, thru testing we could estimate that a structure should be capable of resisting wind forces between 150 and 200 MPH.

By using a distribution to describe this measurement, we account for the fact that under some circumstances wind speeds of less than 150 MPH might compromise the structure, while in some circumstances the structure may be able to withstand speeds greater than 200 MPH.

If we wanted to measure the structure’s vulnerability to a specific type of storm (e.g., a tornado) we could plot a similar distribution for tornado wind speeds (black curve below). This distribution reflects the fact that wind speeds vary from tornado to tornado, ranging from under 100 MPH to over 300 MPH, with most falling in the 200 MPH range. (Keep in mind this is just an illustration and isn’t intended to reflect actual tornado data.)

In order to determine the probability of being vulnerable, we’d use a Monte Carlo function to:

1. Take a random value from the tornado distribution and from the structural resistance distribution
2. Compare the values — i.e., for this iteration, determine whether wind speed was greater than resistance
3. If wind speed was greater, increment a counter that tracks the number of vulnerable instances
4. Repeat a thousand iterations (or ten thousand, a million, etc.),
5. After completing all of the iterations, the vulnerability counter divided by the number of iterations provides the probability of this structure being vulnerable to tornado winds

When an absolute scale doesn’t exist (the human threat community)
Human threat capability can be boiled down to skills and resources. Because skills and resources vary from individual to individual, we can characterize threat community capability as a distribution. At one end of the distribution are those threat agents who have the least capability, while at the other end are those who are the most capable. As seems to be the case for most things in nature (e.g., weather events), the distribution is probably pretty close to being bell-shaped (i.e., the majority of threat agents fall somewhere below those who are most capable and above those who are least capable).

A “100% secure” control (if such a thing existed) could be illustrated as existing outside of the threat community capability distribution. It would be 0% vulnerable.

More realistically, we can in most cases expect that some portion of the threat population would have the skill and resources to compromise a control (shown below).

Now, because of the uncertainties regarding threat capabilities and control strength, it would be more accurate to describe control strength as a distribution as well. For example, we expect the control is at least resistant to 90% of the general threat population, and may be resistant to as much as 99%+ of the population.

This is fine as far as it goes, but it doesn’t get us the answer we’re looking for in most circumstances. Most of the time it isn’t enough to know our vulnerability to the general threat population. In most analyses, we want to know what our vulnerability is to a particular threat community (e.g., cyber criminals, nation-state intel units, etc.). In that case, we’d have to plot the capability of the threat community in question (red distribution).

With that plotted, we can run our Monte Carlo function again, generating a probable vulnerability by taking random samples from the control distribution and the distribution of the specific threat community in question.

The key to measuring vulnerability in the absence of an absolute scale is to use the general threat population capability as the comparative baseline for both control strength and the capability of the threat community in question.

Considerations
Of course, because some malicious threat communities tend to share knowledge and tools, there can be an equalizing effect, which potentially narrows the width of the threat capability curve (shown below) but likely wouldn’t change its fundamental bell-shape. The good news is that this narrowing effect wouldn’t alter how we measure. The bad news is that it does affect vulnerability, which we know intuitively anyway.

Another consideration is the fact that the capability of the malicious population evolves over time — i.e., the curve shifts to the right along the continuum. For example, at one time in the past DES was considered invulnerable to brute force cracking. It isn’t any longer. In other words, we could say that the control stayed in place along the continuum, but the capability curve shifted to the right. This highlights the fact that it’s important to keep abreast of how threat capability evolves, so that you can evolve your defenses as well. Also, this is good fodder for the importance of defense-in-depth.

Concerns
An obvious concern is the inexact nature of these estimates and the potential for the analyst to estimate badly for various reasons. We’ve covered this issue previously in other postings, so I won’t go into it in depth now. Suffice it to say that yes, this is an inexact measurement fraught with all of the goblins that any measurement approach is subject to. That said, keep in mind a few things:

• The ability to estimate effectively can be significantly improved using calibration techniques
• There’s no such thing as a perfectly exact measurement, whether you’re using a laser or the width of your thumb to do the measuring. Therefore, the purpose of measurement is to reduce uncertainty, not eliminate it
• You can apply confidence levels to your estimates, both to describe the probability of actual values being outside of the estimated minimum and maximum, and to shape the peakedness/flatness of the curve
• Monte Carlo analysis is designed to help account for the uncertainty in measures
• You should never convey to management that these numbers are exact. In my experience management won’t have any problem with this, as the numbers they’re given from other business disciplines have precision challenges of their own.

Bottom line — If you’re trying to quantify risk, then you have to quantify vulnerability. This is one logical means of doing so. What’s more, it seems to accurately reflect how we subconsciously evaluate and quantify vulnerability anyway, only it brings the analysis to the surface. And by bringing it to the surface, it allows us to better understand and analyze risk scenarios.

If there’s interest, I can provide a couple of examples in a future post. Also, if there’s interest, I can include an example where the threat event is due to error rather than malicious intent.

(A continuation of last week’s post)

Take a look at the following list and ask yourself which of the following would be labeled “vulnerable”:

• An eight -character password made up of alpha and numeric characters
• A six-character password made up solely of alphabetic characters
• A four-character PIN made up solely of numbers
• A fourteen-character password made up of alpha, numeric, and special characters

Actually, there are a couple of rational answers — 1) “it depends”, and 2) “all of them, to some degree”. As I think about it, maybe these are both the same answer stated from slightly different perspectives.

It Depends
The “it depends” answer comes from the fact that we haven’t identified the threat agent we’re up against. If we’re talking about a threat agent who isn’t particularly skilled, isn’t leveraging a toolset that makes up for their lack of skill, and/or doesn’t have much time in which to carry out their attack, then even the four-character numeric PIN might be more than they’re capable of defeating. On the other hand, if the threat agent is highly skilled, has powerful tools, and has lots of time, then even the fourteen-character password can be defeated. This, it seems, also supports the “all of them” answer. The point is, everything is potentially vulnerable under the right (or wrong) circumstances.

Unfortunately, we tend to use the term vulnerability as if it’s a binary condition. Something is vulnerable or it’s not. But whether we realize it or not, what we’re really doing when we say that something is or isn’t vulnerable, is making unstated assumptions and generalizations about threat capability relative to the control in question.

Of course, some folks insist that we have to rate controls against the “most capable” threat agent. A couple of problems with that include:

• Who’s to say what the most capable threat agent is capable of?

• If we’re judging against the most capable threat agent, then everything is theoretically vulnerable (given enough skill, resources, and motivation)

The fact is, when someone calls something vulnerable (or not vulnerable) they’re consciously or subconsciously quantifying the threat capability as well as the control condition, comparing the two, and then making a judgment about the degree of vulnerability. Or, I suppose, they may just be blindly following someone else’s proclamation that “this is vulnerable” and “that isn’t”.

So, if we’re performing subconscious quantification and comparison when we rate the vulnerability of something, is there any reason we can’t/shouldn’t be more conscious about it? What’s the downside? And is there any reason to believe conscious analysis would be less accurate than the subconscious one? Think about it. Subconscious assessment is at least as exposed (and arguably much more exposed) to errors of omission, errors in estimation, and personal bias/gaming, which means conscious analysis can be no worse and has the opportunity to be much better.

Next week — “Measuring Vulnerability”

When a new vulnerability is discovered in (for example) an operating system, does that mean the system was vulnerable all along? As I see it, the answer is “No”.

The rationale behind this answer is based on the fact that weakness (a.k.a. vulnerability) is a relative term. Logically, a relative term requires at least two components – one relative to another. Oh, it’s true that the “flawed” condition within the operating system existed all along, but in order for that condition to actually BE vulnerable, the capability to exploit the condition had to exist. And within the context of a human threat community, capability requires two things: knowledge and resources. Consequently, until the condition was known to be exploitable, it couldn’t be leveraged and wasn’t a vulnerability.

So, if a vulnerable condition occurs when available force becomes greater than the ability to resist that force, then vulnerability can come about in one or more of three ways:

1. Resistance strength is diminished in some manner (e.g., cutting part-way through a rope)

2. Available force increases so that it exceeds existing levels of resistance (e.g., more weight is added to the end of the rope)

3. An asset is newly exposed to threat elements, either because the threat elements are new to its landscape or it enters a threat landscape it didn’t exist in before (more on this in a second)

Regardless of the cause, whenever available force becomes greater than the ability to resist, you have what can be referred to as a “vulnerability event” – i.e., vulnerability now exists where it didn’t before.

In our operating system scenario, nothing changed about the operating system itself. What changed was threat capability, which increased as soon as the threat community became aware of the condition’s exploitability. At that instant, the knowledge component of the threat community’s capability changed, and their resources likely changed soon after, when exploit code was developed.

Vulnerability, not loss

Here’s another example prompted by an excellent question posed by Stacy on the “layer8.itsecuritygeek blog — essentially, how should we classify “near miss” events where, for example, someone sends sensitive information unencrypted over the Internet? Is that a “loss event”? By my reckoning, the answer is no – unless and until actual loss to the organization materializes. Instead, it’s another example of a vulnerability event – i.e., vulnerability to loss now exists where it didn’t before (ref. #3 above).

Why “vulnerability events” matter

If history provides any clues to the future, some folks are going to question why I feel the need to define yet another term. It’s a fair question (pun intended).

If you’re familiar with FAIR you already know that we define two other event types – Threat Events and Loss Events. Threat events occur when a threat agent acts against an asset. Loss events occur when loss results from a Threat Event (i.e., as happens when force exceeds resistance). The reason it’s important that we make distinctions between event types is three-fold:

• It helps us to better understand our problem space, which is always a good thing,

• It allows us to communicate more consistently and effectively, and

• It enables us to identify and make meaningful use of metrics

This last point is especially important as we try to make better use of metrics.

But a quick Friday Fun post about how you can play a flash game at work and get away with it:

BMC has created video game about ITIL.  Give it a whirl and just explain that you’re trying to understand how “best practices for service management” … “can help IT deliver business benefit”.

Post your scores in the comments!