Risk and CVSS (Post 1)

August 24, 2008

I recently stumbled across the CVSS v2 vulnerability scoring method – as I was writing a post about risk vernacular. Per the CVSS v2 complete guide, “The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impact of IT vulnerabilities.”  As I started highlighting parts of the guide that were thought provoking from a risk perspective, I realized this would probably result in at least two posts – maybe three. So off we go…

I would encourage anyone reading this to perform their own review of CVSS and how it can possibly augment their own risk assessments efforts. In my opinion, there are some really useful “metric vectors” that provide a simple yet powerful way to analyze a vulnerability. In addition, I really like how they have a simple “scoring vector” – essentially a shorthand representation of all the individual “metric vectors”. I could see how this could be really useful for archiving / documenting purposes but for also being to programmatically manipulating for other purposes.

Thought 1: One of the first things that stood out to me as I started reading the CVSS guide was on page three, where they talk about “prioritized risk”. While I agree that their vulnerability score can be considered contextual and be used to compare variance in multiple vulnerabilities– I do not agree that it is representative of the actual risk to the organization.

Here is why.

No where in CVSS is there a metric for gauging how often assets within your environment – that have the vulnerability being analyzed- are being attacked let alone compromised. Now, I am not implying that the authors and maintainers of CVSS are trying to mislead security professionals – but I think this underscores a problem within our industry about knowing what risk is, the elements that make up risk, and risk vernacular.

Let’s talk about vulnerability for a minute. Generally speaking, it can be something (noun, a weakness) or a state / condition (adjective, my application is highly vulnerable to x). It would appear that CVSS accounts for both because you use CVSS to determine how vulnerable you are to vulnerability. Sounds confusing – but not all is lost.

FAIR – the risk assessment methodology I use – accounts for vulnerability as a condition. Within FAIR, vulnerability is derived from “threat capability” (the percentage of my threat community that can overcome control resistance) and “control resistance” (the percentage of control resistance I have against the “threat population” as a whole; for FAIR, threat community is a subset of threat population). When you have and can leverage a methodology and risk taxonomy like FAIR – you can see how easy it is to not take for granted what I would call risk term generalizations – using terms without truly understanding how they should be properly used or not knowing what they really mean. Just to reiterate – vulnerability is an element of risk – not risk itself.

Thought 2: On page 6, section 1.7 of the guide “Quick Definitions”, “threat” is defined as the “likelihood or frequency of a harmful event occurring”. This is the closest to “threat event frequency” or “loss event frequency” that CVSS comes close to touching. Threat can be both a noun and verb – but I have yet to see a dictionary that includes likelihood in its definition. It may sound like I am splitting hairs on definitions and picking on the CVSS folks – this is not my intention; but some of the concepts being discussed are foundational to understanding risk.

To wrap this first post about CVSS, I would offer the following:

1.    That the CVSS-SOG consider participating in the The Open Group; specifically in the “Risk Management and Analysis Taxonomy” forum.
2.    Do not discount the useful of CVSS in analyzing a vulnerability or a state of vulnerability. Just because there may be some risk term short comings does not mean their metric vectors cannot be effectively used.

In the next CVSS related post, I will focus more on the CVSS Metric Groups and how these have forced me to take a step back and evaluate the rigor and consistency I apply to risk assessments.

Advertisements

Risk Vernacular

August 16, 2008

Vernacular is such a “power” word. At 10,000 feet and in the context of risk; “risk vernacular” is essentially a “risk language”.

As I begin to move closer to presenting scenarios and risk analyses, I decided to create a separate page on the blog for some risk terms and definitions. Some of them will be FAIR terms and some others are terms I have learned about from other risk disciplines or stumbled across that seemed to make sense. Yes, there may be disagreement on what I have listed. Please understand that these are the terms that I have cut my “risk teeth” on and seem to stand up fairly well to scrutiny within our industry and our peers in other risk discipline.

Bur more importantly – these are terms and definitions that I think are easy to explain to the non-risk individual.

Take a look at the page, and be prepared to revisit it, because a lot of these terms will be referenced extensively in coming posts.

The next post will be about the “Common Vulnerability Rating System v2”; some positive thoughts, “lukewarm” thoughts, and “caution flags”.


Is The InfoSec Risk Assessor Alone?

August 10, 2008
Am I Alone?

Am I Alone?

Probably not. Whether it is a risk based cost benefit analysis, decision theory, or a formal / informal risk assessment – risk assessments are probably occurring somewhere in your organization.

One goal of I have for this blog is to make the subject matter relevant to information security folks regardless of the size of organization we may work for or the role we have within our profession. The reality is, that for those not employed by a large company or government entity that has a dedicated risk assessment group – it is too easy to assume that you do not have the time, the tools, or an advocate in place to even talk about information security let alone manage it.

So where to begin?

There are many entities or persons within an organization that perform some form a of risk assessment. The methodology, rigor, and subject matter might be different across all these groups –but decisions are being made based off risk.

Below is a list of groups or individuals that immediately stand out to me:

1.    Key business executives.
2.    Decision makers with fiscal responsibility.
3.    Internal auditors.
4.    External auditors.
5.    Enterprise risk management groups / individuals.
6.    Financial risk management groups / individuals.
7.    General council / legal entities.
8.    Capital risk management groups.
9.    You.
10.    Others that I am probably missing.

The following thoughts are probably more geared for those that are not in dedicated information risk assessment role and maybe do not work in an organization where there is strong information risk management governance – let alone a strong information security group.

1. A quick way to learn about what is important to your leadership from a risk perspective, is to ask them what concerns them when it comes to information and security. Try to get a 15 minute meeting and ask the question. Not only are you being proactive but you will learn more about your leadership and possibly your business as a whole. The risks that most information security think of first are probably not the same risks that come up first from non-security executives. Meeting with the business leaders and business decision makers is so critical and if done appropriately can pay off in dividends.

2. Do not let yourself get tunnel vision and only think that you are alone or that only your risk issues matter. Reach out to those peer groups that also deal with risk on some form and gain insight from them. The impact (monetary loss) of risk scenarios they may be most concerned about could help you better define your approach to looking for risk issues as well as better recommend security controls for mitigating risk.

Here is a link to a PDF I Googled upon that talks about enterprise risk management. It’s a good overview of ERM for the large organization but maybe too much to digest for the small organization, so keep on reading below.

Where Can I Begin?

For those that do not work in an organization with a formal information security risk management group, identifying and managing key information security risks may seem like a daunting task. After thinking about the sophistication of the program I work within, the steps below could be a starting point for you. BTW, this should be approached in the spirit of collaboration versus the spirit of security police. I still cringe every time one of my co-workers even jokes about getting an official security badge…

1. As you review project activities or other operational activities and come across security concerns – document them. Whether it is a small database or a spreadsheet, capture the date, the security concern (or risk issue), the reason it is a risk (impact to the organization), the team or person that can facilitate mitigation, a date for follow-up, and a unique identifier.

2. Before communicating the risk issue to the appropriate parties, take a few minutes to research risk issue in question for possible mitigation techniques and to ensure it is valid – even if you are not an expert in the space you identified the risk issue. This step warrants a separate posting, but there is nothing more frustrating then what I would call the “sea gull” risk assessor – someone who swoops in, makes a lot of noise about risks, poops all over the place, and then moves on without offering any mitigation help whatsoever. In some minds, this is the different between a risk assessor and risk consultant – again – separate post.

3. Communicate the risk issue to the person(s) who can facilitate mitigation. Maybe this is via email, telephone call, or an in person meeting. The goal of this meeting should be to communicate the risk issue and attempt to get a commitment to mitigate. Regardless, leave the conversation setting an expectation of a follow-up six or twelve months out. Make a few notes on your risk issues record about the conversation you had.

4. Schedule a reminder to follow-up on this risk issue 6-12 months out (as needed).

5. Repeat as needed. Maintain realistic expectations – especially if this is truly a new initiative for you. Not all risk issues will be mitigated nor will everyone be receptive of your efforts.

There is a saying I learned in the Marine Corps which goes like this: “It is better to be tried by 12 then carried by 6”. Though a different context, the underlying message is applicable to managing information security risks even in a simple five step model listed above: trying to do the right or necessary thing and defending it is better then having not done anything and not having an opportunity to explain why.


What Is Risk? – Follow-Up 1

August 4, 2008

Ms. Shrdlu over at Layer8 welcomed me to the “Risk-0-Drome” and then did not hesitate to take my previous post to task (or “takes issue with” in her terms) with my claim that of ‘A loss form needs to take form in the form of money’. I think there are three points to respond to:

1.    Quantifying loss forms in terms of money
2.    Quantifying the hard loss forms – reasonably
3.    Hayes’ Information Security Risk Management “CMM” Levels (Qualitative vs. Quantitative)

Here are my responses (some of them are posts all in themselves):

POINT 1: Yes! I do think that risk does eventually reduce down to a monetary value. At the end of the risk decision (assuming one occurs), either the risk is mitigated (to an accepted level – thus reduced), ignored, or transferred . The only unit of measure that exists to measure this amount is effort and product cost – effort of which which can usually be reduced further to a monetary value. Determining effort in the context of monetary values is an art and science all in itself, but is not unachievable.

Now, is every security or “risk professional” in a good position to quantify risk? No! Should they be? In a lot of cases, it may NOT be necessary. However, there is an opportunity cost to mitigate, to assess, to respond, to even think about the impact this could have to an organization.

What is reasonable? Reasonable is relative. Reasonable to you and me may literally be a scoff or afterthought to someone else in the organization. To be honest, if at the end of the assessment if a decision maker decides to assume the risk (not going to mitigate it) AND all my ducks are in a row (meaning, I did not miss a significant information element that could impact my assessment or a mitigation recommendation); then, assuming I have adequate documentation – I am OK with that individual assuming the risk. Please do not take it as a CYA approach to risk management – it is not. It is merely an acceptance that some decision makers are willing to assume (and / or transfer) risk – vs. mitigate it.

POINT 2: Shrdlu also questions whether reputation loss can be measured in terms of money. I think you can. Your company pays for advertising – essentially impressions on consumers. If your company suffers a breach and makes the headlines you (or your marketing folks) can probably quantify the number of media outlets that reported it, their daily readership, and the cost your company would have spent to advertise to the same outlets for the right reasons. The real struggle – is being able to quantify lost business as a result of the negative coverage – but even this could be attempted via sampling.

This type of assessment is pretty in-depth, time intensive and probably not warranted for most risk issues. But, even if you cannot quantify some of these hard-to-quantify loss forms, we can still use them to our advantage. I think they fit nicely into the concept of “contributing factors” – factors that facto into the severity of impact or frequency of loss. The “contributing factors” concept is not explicitly outlined in FAIR, but I think it is implied when justifying various FAIR taxonomy element values and can effectively compliment those loss forms we can quantify like productivity loss, replacement, legal, etc.

POINT 3: Not all information risk management groups are able to leverage risk quantification; their risk management efforts may be immature (for lack of a better term) or their management does not require a higher level of sophistication. That is fine. Precision vs. accuracy (reasonable) are different beasts that cost different amounts of money. While most risk professionals (not necessarily info sec folks) would like to give you 95%, 90% or 80% confidence in their estimates; such a high-level confidence level may not be necessary to make a well-informed decision.

So, maybe this comes down to an Information Security Risk CMM concept – through the eyes of Hayes:

Level 0: Risk, schmisk – who cares?

Level 1: We know what risk is – our business partners may not understand how it impacts them. It’s a great four letter word that we can use in conversation, and somewhere in our organization it is talked about outside infosec; sometimes even documented. In the probable vs. possible quandary, risk is usually articulated in possible.

Level 2: Risk is talked about outside information security. We know we need to manage information security risk. We try to document whenever possible (or feasible) and manage appropriately. We understand our business as a whole and are able to properly contextualize risk issues in our environment.

Level 3: We have a defined risk management process. There is a moderate level of information security / risk management governance. It looks good on paper, but is highly dependent on adequate time and resources to begin even thinking about it being half-way effective. We use terms like LOW, MEDIUM, or HIGH or maybe “NOTHING TO WORRY ABOUT”, “SOMETHING SHOULD PROBABLY BE DONE”, or “OMG, PUT ON YOUR ‘OH FACE’ and RAISE RED FLAGS”. We try to identify risk issues before it has an opportunity to enter a production environment.

Level 4: We actually try to manage risk. We document, provide mitigation consulting, perform follow-up, and have strong information security / risk management governance. We have inserted ourselves into the SDLC or PLC and critical IT / Business process to ensure some form of coverage. Qualitative labels are OK, but provide little insight to the organization’s information security risk exposure at a cumulative or aggregate level. In a tight economy – budget justification will come down to “needs” vs. “wants” and cost / benefits decisions – qualitative labels do not provide much value. We reach out to other risk groups in the company to leverage their data / information as well as their governance if applicable.

Level 5 – All of number four, plus – integrated risk management across risk disciplines and granular enterprise reporting – this can only be achieved via quantifying risk.

I realize that not all organizations need to manage their risk to the degree of a level 5. But I would argue that when we articulate risk to decision makers, we need to do so effectively. It should not require slides and should not take numerous meetings but some risk issues will. Regardless, it should be straightforward and to the point. I have actually practiced the equivalent of an elevator pitch to prepare for meetings where the purpose was to review risk assessments. For some decisions makers it may be the only time we get to make a positive impression on her or him – so I would prefer to make it count.

Thanks for stirring up the pot Shrdlu – but it’s not a mudfight yet… 🙂

Updated 8/5/2008 – Changed Mr. Shrdlu to Ms. Shrdlu.