Home > Intel Communities > Open Port IT Community > IT@Intel > Blog > Tags > metric

IT@Intel Blog

4 Posts tagged with the metric tag
1

Measures generate data and metrics organize data to generate information.  The difference between ‘data’ and ‘information’, the former is something you know, the latter is something you use.

 

Everyone wants information security to be easy.  Wouldn’t it be nice if it were simple enough to fit snugly inside a fortune cookie?  Well, although I don’t try to promote such foolish nonsense, I do on occasion pass on readily digestible nuggets to reinforce security principles and get people thinking how security applies to their environment.

 

The key to fortune cookie advice is ‘common sense’ in the context of security.  It must be simple, succinct, and make sense to everyone, while conveying important security aspects.

 

Fortune Cookie advice for September, 2009:

 

Data and Metrics.jpg

 

Measures generate data and metrics organize data to generate information. 

The difference between ‘data’ and ‘information’, the former is something you know,

the latter is something you use.

 

In security, it is easy to confuse the terms ‘measures’ and ‘metrics’.  They are two distinct but related concepts.  Measurement theory incorporates the scale of nominal, ordinal, interval, ratio, and absolute.  These scales are used to measure something, with the output being data.  Metrics however are about analysis and intelligent decision making.  Metrics translate data into meaningful information which will support decision making.  Data is something you know.  Information is something you use to make decisions.

 

Fortune Cookie Security Advice - No Royal Road to Security - July 2008

Fortune Cookie Security Advice - Strategic Compettive Secure - June 2009

Fortune Cookie Security Advice - May 2008

Fortune Cookie Security Advice - June 2008

Fortune Cookie Security Advice - August 2008

Fortune Cookie Security Advice - September 2008

Fortune Cookie Security Advice - November 2008

Fortune Cookie Security Advice - December 2008

Fortune Cookie Security Advice - January 2009

Fortune Cookie Security Advice - February 2009

Fortune Cookie Security Advice - March 2009

Fortune Cookie Security Advice - April 2009

Fortune Cookie Security Advice - May 2009

1 Comments Permalink
1

Telescope.jpgRisk metrics are the heart and soul of information security indicators.  An increasing proliferation of tools and assessments has emerged, attempting to quantify states of information security.  Given the nature of what is trying to be measured, this is arguably one of the toughest challenges in the metrics space.  The recent trend is for different bodies to develop and publish their own standards, which creates confusion regarding accuracy and applicability.  Why all the turmoil, competing models, and misalignment?  The sad story is (queue the somber violins) we just have not figured out how to measure information security risks very well.

 

I have seen and applied many different methods, audits, and evaluations with varying degrees of success and disappointment.  I have come to the following three basic conclusions:

  1. Current tools and methods lack maturity in this area, for both accuracy and comprehensiveness (and yes, I am guilty of contributing to the pool)
  2. No silver bullet exists.  A unified method, which provides a predictive overarching and detailed risk analysis, is unlikely.  Different approaches have their applicability.  Choose wisely 
  3. There is no replacement for a security professional’s brain.  From the selection of the analysis method, the gathering of relevant data, to the interpretation of the results, requires a seasoned security professional.  There is no substitute which can handle the ambiguity, chaos, and relational dependencies affecting the outcome


An example will help express some of the challenges.  The OCTAVE methodology, created by Carnegie Mellon University some years ago has been battle tested veteran in this role.  It is a qualitative to quantitative device which leverages the expertise of key people to give a numerical value of risk in their respective area.  Because personal bias and fears, the need to allow flexible ways of answering questions, and the varying degrees of base knowledge between the experts, results can vary greatly without even factoring in the changes occurring in the threat landscape.

 

Let me be clear, I am a fan and a longtime supporter.  However, it has its limitations.  I have developed several assessments based upon the model in a large environment.  As long as the limitations are accepted, it is applied where it leverages its strengths, and the process is rolled out properly, the results can be very valuable.

 

But don’t confuse value with precision.  I have observed the accuracy to be +/- 40% in complex organizations.  I believe this is largely due to multiple tiers of qualitative-to-quantitative analysis and the bias introduced at each level.  Credible sources have expressed a better +/- 20% accuracy for smaller implementations.  Although these numbers sound terrible, it is very good compared to other methods.  I have great respect for the chaps at Carnegie Mellon University who created the methodology.  Groups within our company have used a modified form of this approach, with advanced structures tailored to our computing ecosystem, for years with great success.  The low accuracy rate is not a poor reflection on the CMU model, rather it is a stark insight on how immature we are in this field.

 

So this is a sad story, but one which is not over.  A cadre of very bright people is working to tackle this problem.  In the short term, I expect to see many more methods, theories, templates, and standards emerge for specific situations.  In the end, I doubt if ever we will have a unified way to measure security risks, but I hold high hopes the best will be culled to a small number which can be applied to most situations and deliver reasonable metrics.

1 Comments Permalink
1

Choosing the right method to measure security value is important but not necessarily intuitive.

 

Some years ago, at the prodding of our department training expert, I developed a class teaching how to think critically while calculating information security value.  The benefits of the course are twofold.  The class helps security practitioners in creating more justifiable value assessments for their programs.  Additionally, it assists audiences of such assessments to question the validity and identify weak justifications.

 

I offered to teach the class once a year, internally to Intel, and figured the audience would dry up after the first class.  For some odd reason people continued to sign up year after year.  I honestly figured not many people would willingly choose to spend their time on such a dry subject.  In the first year, mostly information security professionals attended.  In subsequent years, to my surprise, a slew of people from finance, manufacturing, marketing, and product development have taken the course.  Sitting in my Inbox is my annual notification for instructing the class, with a list of students from multiple countries already signed up.  Curse you Bruce (training expert)!

 

With such a diverse audience, I figured I would share some of the materials with the broader community.  This is just a snippet, but one of the key chapters.  Feel free to comment (all comments will be forwarded to Bruce)

 

This section of the class touches on recommended methods to show value.  This is not an all encompassing list, but probably the most common to information security programs.  These are archetypes of measurement techniques, not specific questions or audits.  Most techniques in use today can be classified into one of these archetypes.  Each has a set of common characteristics with strengths, weaknesses, and applicability considerations.  Knowing these characteristics is to understand how best to validate or challenge the metric.

 

Information Security Metrics Archetypes

#1 Metric Type: Standards-Based Gap Analysis

Method: Compare the current state against a provided list
Measurement Scale: Nominal
Pro’s: Shows gaps against defined standards.  Can be very fast to accomplish, compared to other methods
Con’s: Does not show actual value, only alignment to a defined state
Applicability: Compliance to regulations, alignment to best-known-methods
Output: Scorecard to expected compliance, gap list of non-compliant areas
Notes: The value of compliance to a predefined standard resides in the applicability and comprehensiveness of the standard itself.  Typically, it is also specific to a particular area of risk.  Interpretation also can skew measures, if the standard is vague.

 

#2 Metric Type: Raw Gap Analysis

Method: Brainstorm from knowledgeable persons on what they think needs fixing
Measurement Scale: Nominal
Pro’s: Identifies the most apparent issues to correct.  May be as simple or complex as the organizer desires.
Con’s: Reliant on expertise of teams doing the analysis.  Not tied to any quantifiable savings.
Applicability: Response to incidents which already occurred, to prevent recurrence
Output: List of issues to correct
Notes: The value resides in the knowledge of the people conducting the analysis.  A mix of technologists as well as security is best, otherwise the output may lack real benefits


#3 Metric Type: Project Progress Tracking

Method: Metrics which track the start-to-finish progress of a security project
Measurement Scale: Interval
Pro’s: Shows advancement and progress of a project
Con’s: Does not tie the project to any savings or benefits
Applicability: Project management effectiveness
Output: Performance against schedule/budget metrics
Notes: This class of metric is often misused.  Progress of project completion is largely independent of what value it provides once instituted.  This can be used when a security project is a critical path item to another initiative where value is defined.


#4 Metric Type: Qualitative Risk Assessment

Method: Organized collection of concerns from knowledgeable persons on what they believe needs fixing and an explanation statement of the severity of the problems
Measurement Scale: Ordinal
Pro’s: Generates a list of areas to address with prioritized descriptions
Con’s: Reliant on the expertise of teams doing the analysis. Not tied to any quantifiable savings.  Can be time consuming.  May not be comprehensive.  May be skewed to only areas evaluated.  Personalities of the team may significantly alter the priority descriptions of items.
Applicability: Basic state of security gap analysis, scalable to an entire organization.
Output: Description of prioritized line-item gaps
Notes: This is one step above the Raw Gap Analysis method.  Best use is to identify and describe the priority of the most severe issues.  Rarely is this method comprehensive.


#5 Metric Type: Qualitative to Quantitative Risk Assessment

Method: Formal severity ranking, typically on a scale, of problems gathered from a Qualitative Risk exercise
Measurement Scale: Ordinal to Interval
Pro’s: Generates a prioritized list of areas to address, with relative values for comparison.  Can track over time to show incremental changes.
Con’s: Reliant on expertise of teams doing the analysis.  Relative values are not tied to any quantifiable savings.  Time consuming, requires tools for scalability.  Expect +/- 40% accuracy
Applicability: Advanced state of security gap analysis, scalable to an entire organization.
Output: Ranked descriptions of line-item gaps
Notes: This is one step more advanced from the Qualitative Risk assessment, giving numerical values to priority aspects (example: threat, vulnerability, consequences, etc.)


#6 Metric Type: Vulnerability Analysis

Method: Thorough inspection which documents all vulnerabilities
Measurement Scale: Interval
Pro’s: Identifies a list of vulnerabilities which exist
Con’s: Existence of vulnerabilities is not tied to losses.  Output can be overwhelming and underscores only a snap-shot in time of a rapidly changing environment.  Can be very time consuming, requires tools and interpretation.
Applicability: Applied to specific hardening initiatives or fed into a risk assessment
Output: Descriptions of potential vulnerabilities, may be ranked on severity or overall exposure
Notes: Vulnerability analysis poorly correlates to losses.  Just because a vulnerability exists, does not mean it will be exploited.  If exploited, it does not necessarily equate to a meaningful loss.  Question any vulnerability analysis, which claims specific dollar savings!


#7 Metric Type: Against Previous Performance/Operational Efficiency

Method: Statistical comparison against historical data, known costs, and trends (example: actuary tables)
Measurement Scale: Interval to Ratio
Pro’s: Uses actual data to derive the measurement.  Can show the value of a program.  Can be used to both predict value as well as derive sustaining value after project landing.
Con’s: Accuracy may suffer as historical patterns change.  Significant work to accomplish this metric.  Accuracy may be outdated quickly as the environment changes quickly.
Applicability: Before and after comparison of effects for value measurements.
Output: Historical performance and trend graphs showing relative positions.  Net Present Value (NPV) for operational spending.  Forecasts of high-level changes to risk.  Can provide a ‘value’ in terms of dollars.
Notes: Depending upon the historical data, it may not tie to actual security value.  Data trends in the security field tend to be incomplete, limited, and can be manipulated.  Operations costs may not reflect the benefit of security.  Best when used to compare data prior and after landing a security program.


#8 Metric Type: Value Calculation for a Return on Security Investment

Method: Financial model quantifying the dollar benefits of a security program
Measurement Scale: Interval to Ratio
Pro’s: Uses actual data to derive the measurement, based upon trends and control groups.  Potential to generate dollar values derived for both losses and loss prevented.  May comprehend defense-in-depth solutions, showing the individual as well as cumulative value.  Statistical predictions quantify accuracy
Con’s: Extremely difficult to produce.  Must have significant amounts of accurate data and understanding of the security environment.  Must use complex calculations and factor in unknowns.  Very difficult to scale.  Tools and processes are not well defined or mature in the industry.
Applicability: When sufficient historical data is available, an intuitive understanding of the security environment is present, and business values can be measured.  For use when justifiable estimates of dollar value of a security program is needed.
Output: Incident reduction metrics, estimated losses, and loss prevented metrics.  Single Loss Expectancy (SLE), incident and loss predictions.  Derived dollar value of individual security projects as well the value for multiple overlapping/complementary security systems.
Notes: Not for the faint of heart.  These types of analysis are ugly monsters to produce and validate.  All assumptions, calculations, and data sources must be documented.  Complete raw data sets must be provided.   May include limited aspects of other measurement archetypes to fill in gaps, thereby affecting accuracy.

 

 

Lastly, there is another choice which can be made: the decision to not measure the value of a security program.  I think this option is pursued more often than not and done for the entirely wrong reasons.  Measuring value is not easy.  It consumes time, resources, requires expertise, and once it is published the author may be under the spotlight to answer and justify the analysis for years to come.  But for all the sweat, tears, and pain, having a good understanding of the value, has merit for security programs of significant investment.

 

On the other hand, the simple reality is that in many cases a full blown analysis does not make sense.  For example, when a program is required to meet regulatory requirements or when the security investment is very small.  I would not do a comprehensive value assessment for justification to purchase a $10 cable lock.  Let common sense prevail.  If the value must be understood to compare to other options, articulate security posture, or justify spending, then do an assessment.  Otherwise, ask yourself if it is really needed.

1 Comments Permalink
0

Everyone wants information security to be easy.  Wouldn’t it be nice if it were simple enough to fit snugly inside a fortune cookie?  Well, although I don’t try to promote such foolish nonsense, I do on occasion pass on readily digestible nuggets to reinforce security principles and get people thinking how security applies to their environment.

 

Common Sense

I think the key to fortune cookie advice is ‘common sense’ in the context of security.  It must be simple, succinct, and make sense to everyone, while conveying important security aspects.

 

Fortune Cookie advice for February:

 

A worthless metric is one which fails to drive decisions, even when the metric result radically changes.

 

The world of information security is full of metrics.  Sadly, many are worthless.  A valuable metric is one which drives decisions.  Unfortunately, our industry also persists in publishing metrics which may nicely fill graphs and catch attention with flash, but in the end are meaningless.  The true test: can it facilitate change.

 

One of my favorite metrics to pick on is a graphic which shows the percentage of internet attacks by country.  Provided every year, this metric presentation is visually stunning, usually consisting of a background of the globe with offending countries in vibrant colors.  It is clear, attention grabbing, and even interesting in a sublime way.  Media outlets love the eye candy.  But at the end of the day, the data is meaningless.  It does not really matter where attacks initiate from.  Organizations will not change their course of security if the numbers shifted drastically over time.  The proximity and country of origin simply does not matter.  The number and types of attacks are far more relevant, but not the division of origin based upon international borders.

 

Whenever we are presented with metrics, we must think critically to understand their value.  Don’t get caught up in beautiful graphics or catchy titles.  Challenge everything.  Would you do something differently in your approach to securing your environment if the data changed radically?  If not, then move along, nothing here to see.

 

Fortune Cookie Security Advice - January 2009

Fortune Cookie Security Advice - December 2008

Fortune Cookie Security Advice - November 2008

Fortune Cookie Security Advice - September 2008

Fortune Cookie Security Advice - August 2008

Fortune Cookie Security Advice - June 2008

Fortune Cookie Security Advice - May 2008

0 Comments Permalink