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

IT@Intel Blog

10 Posts tagged with the measure tag
0

I just read this paper authored by some of Intel's IT experts in the area of client management.  As an employee of Intel, I am now a huge fan of these rock stars.  Why? because they were able, through proactive IT management practices, reduce blue screens inside Intel's employee base by over 50% in the last year (Q2'08 to Q3'09).  There are now 3,000 fewer laptop blue screens than there were a year ago --> that is a huge productivity advantage for Intel workers.

 

blue scree reduction q2'08 - q3'09.JPG

Issue Tracking, Pareto Analysis and use of new management capabilities and technologies like Intel vPro Technology were at the center of these capabilities.

 

Read about how Refael Mizrahi, Shachaf Levi and Jeff Kilford made my life as an intel employee a whole lot easier by Improving Client Stability with Proactive Problem Management.  You Rock!

 

Chris

0 Comments Permalink
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
0

There is no Royal Road to understanding and achieving information security

 

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 July, 2009:

 

Road1.jpg

There is no Royal Road to understanding and achieving information security

 

Taking a line of thought from Euclid, there is no easy route to understand the ever changing complexities of information security.

We exist in an era where information security is both exciting and complex. 

 

The rapid evolution of information technology, increasing number of targets, and the explosive development of creative tools attackers employ all contribute to a dynamic environment where a continual struggle between aggressors and defenders shifts the balance on a daily basis.  Only through hard work can security professionals effectively pursue achieving an optimal level of security which manages the tradeoffs of cost against controlling impacts and effectiveness of attacks.  Achieving information security is an exercise in hard work, diligence, consistency, and flexibility to adapt technology and behaviors in meeting the challenge.

       

 

Fortune Cookie Security Advice - Strategic Compettive Secure - June 2009

Fortune Cookie Security Advice - May 2008

 

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

0 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
0

Think strategic.  Act competitive.  Be secure.

 

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 June, 2009:

 

 

Strategy.gif

Think strategic.  Act competitive.  Be secure.

 

Security is a sustaining commitment where long term planning provides a distinct advantage.  Threats are derived from intelligent adversaries.  Success requires maneuvering in a competitive manner to remain secure.

 

 

 

 

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

0 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 May:

 

Fear and anxiety will lead to poor risk analysis conclusions

 

Stay focused on the available facts, use a dose of reality to fill in the gaps, and trust reliable risk models to generate analytical conclusions.

 

Excerpt from the Traps of Measuring Security Blog: In our world of information security, we must take a step back from the limitations and biases we possess and stay true to proper forms of analysis in order to see the truth.  It is far too easy for us to slip backwards and inaccurately measure risk of situations we don’t understand.  Let’s continue to remind each other of this fact and challenge risk assessments, especially in situations where concern is more prevalent than fact.

 

So am I contributing to the problem of over simplifying security? Or am I reaching out to those who might not take an inordinate amount of time necessary to understand the complexities and nuances of our industry? You decide and feel free to share your knowledge-nuggets.

 

Fortune Cookie Security Advice - April 2009

Fortune Cookie Security Advice - May 2008

Fortune Cookie Security Advice - June 2008

Fortune Cookie Security Advice - September 2008

Fortune Cookie Security Advice - November 2008

Fortune Cookie Security Advice - August 2008

0 Comments Permalink
0

We naturally take comfort in being able to quantify the vagueness of challenges in our existence.  This past week, I was again reminded the cup of information security is filled partially with the complexities of human perception and ambiguity of emotions weighing our mental models of judgment.  These can be misleading.

 

This is not a revelation.  I thrive in the trenches of security measures and metrics, and learned this lesson many seasons past.  But it is so easy to fall back into the comfort of measuring, calculating, estimating, and even predicting risks with first impressions, and foregoing proper data collection and dispassionate analysis.

 

It is in our very nature to apply our big cognitive brains in an attempt to make sense of something which causes concern for our minds when we encounter situations we fail to grapple.  We default to familiar structures of logic and experience to give some insight, even if it is invalid.  If we cannot grasp a cloud, it makes us feel better to at least measure it.

 

I recently travelled to the beautiful city of Shanghai.  In the sprawling city of 19 million, getting about requires the use of a local taxi.  Drivers are aggressive by American standards.  They creatively use all lanes, including those of oncoming traffic, to weave in and out between pedestrians, other vehicles, and bicycles, all at high speed.  Roadway guides such as speed signs, stoplights, and lane markers are just cosmetic.  The concept of ‘right of way’ is defined by the vehicle which gets there first.  Tens of thousands of taxi drivers vie for pole positions at every light and traffic snarl.  I counted no less than half a dozen head-on near misses the first day.

 

Not surprisingly I was a bit concerned for my safety.  But what was the actual risk?  It seemed high, with all the jockeying, speed challenges, and lurching in front of other cars at a moment’s notice.  In formal terms, the security risk calculation was off the map.  Keeping it simple, risk can be defined as equaling the (threat) x (consequence) x (vulnerability).  Threats were abundant and vectoring from every angle.  Vulnerabilities were painfully obvious as the situation was an example of near uncontrolled chaos heavily dependent upon human judgment and intervention.  Lastly, the consequences registered as likely life threatening.  Vehicle safety measures are not equal to US standards, with no airbags and rarely a functioning seatbelt.  My brain began to do the rough math and formed a mental model where the conclusion was somewhere near the “I’m screwed” end of the spectrum.

 

Over time, I started to take a different perspective.  By the end of the week, and too many close calls to count, I observed the city’s taxi’s did not show damage which would be consistent with rampant numbers of collisions.  Although chaotic and unpredictable, they found a balance in avoiding impacts.  My drivers’ never appeared nervous.  Many were happy to take calls on their cell phones while racing into oncoming traffic and weaving back into our directional flow at the last second.  Yet, they were not worried.  The pedestrians who seemed intent on walking into direct paths of vehicles always looked up at the last possible moment and jumped out of the way of an untimely demise.

 

The dangers were still there.  Nothing changed but my perception.  The risks were high, controls were low, but it was the incident rate that was the telling measure.  Lack of vehicle accidents in such a tremendous population meant they operated in an efficient manner which my brain could not comprehend as safe.  But it was.  My initial evaluation misled me to a wrong conclusion: an inaccurate determination of risk.  I felt safer than before.  To this day, I cannot comprehend how they do it.

 

In our world of information security, we must take a step back from the limitations and biases we possess and stay true to proper forms of analysis in order to see the truth.  It is far too easy for us to slip backwards and inaccurately measure risk of situations we don’t understand.  Let’s continue to remind each other of this fact and challenge risk assessments, especially in situations where concern is more prevalent than fact.

0 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
1

Good security conversations benefit all involved. The more we share, discuss, and challenge each other, the more we advance our industry. Thankfully, I have the benefit of working closely with a brigade of information security professionals and we banter at every opportunity, for the sheer pleasure and insights. In that same spirit, we hosted our first Blog-Talk radio session. This was a general discussion of the problems of measuring security.

 

 

 

 

 

 

The 30 minute discussion can be replayed here

Two other internet chats are planned. Everyone is welcome to participate or just listen in. Details can be found here.

1 Comments Permalink
2

In my experience over the years, calculating security value and providing consulting to others doing the same, I have noticed the same 4 questions tend to rear their ugly heads. Requests by senior managers, finance analyst, business value analysts, project and program managers all fall into one or more of these types of inquires. And when I say they are ugly, oh they are.

 

In most cases the parties seeking information are in some phase of the decision cycle:

 

Should I spend money on security? - This is a business decision based upon compelling drivers, usually loss of some kind, including non-compliance to regulatory requirements (which could send a C-level officer to spend an extended vacation at Club Fed) or risk of a catastrophic blunder sufficient to crater the organization. The business aspects must include how many coins are in the coffers, amount of loss (both realized and unrealized) on the table, and if money could be better spent elsewhere (opportunity costs)

 

How much should I spend? - A value decision considering what the organization is willing to accept in losses, what can be spent on security, and the amount of loss which could be prevented. Optimally, there exists a point at any given time which management is willing to spend a certain amount on security, which prevents enough loss to bring the residual losses to an acceptable level.

 

 

What should I spend it on? - An exercise in comparative analysis of available options which drives down overall costs, while increasing the losses prevented, and maintaining the optimal level of security and residual loss.

 

 

 

 

 

On to the ugly questions (feel free to share your experiences):

 

 

Ugly Question #1: How do I select the security product/program with the best value?

This is typically asked by senior management or by a product/service manager seeking to identify the best solution among a pool of several competing initiatives. As an example, they might be looking to purchase an Intrusion Prevention System (IPS) and looking for the best of breed. Conversely they may be looking to establish or improve a security capability (example: data protection) and trying to determine the best product among multiple solutions (encryption, IPS, document tracking, data destruction policy, etc.) across multiple vendors.

 

 

The challenge is to be able to compare which solution will best achieve the optimal level of security. This is a function of security cost, losses prevented (effectiveness), and acceptance of residual loss. To simply go for the cheapest, most effective, or fastest to adopt is most often than not, the wrong long term answer. (..and security is a long term proposition)

 

 

Ugly Question #2: What is the value of this security product/program?

This is asked by management and project managers when a solution is in the proposal stage, by the sustaining operation folks once it has been implemented into the environment, and by management during times when the organization is looking for opportunities to cut costs. As value is a dynamic concept, it can radically change based upon business, legal, and social aspects as well as the normal fluctuations in the threat landscape. First step here is to identify what types of value was intended to be provided and the appropriate metric to measure those aspects.

 

As an example, management may be seeking to protect the organization's image and liability from the loss of Personal Identifiable Information (PII) through the implementation of a hard drive encryption program for company laptops. The metrics may be as simple as determining the saturation of the program and if encryption is sufficient to protect from liability in the geographies they do business in. In this manner you can estimate the amount of coverage for which liability and image concerns are abated.

 

You might think, wait, that is not a dollar figure! Where is the value? Well, in this case, management may be looking for the establishment of a capability. Either we are protected from this threat or we are not protected. The same stratagem could be compliance with HIPPA or other regulations. To attempt to quantify a dollar figure in this example would be overkill and may detract from what is intended. Realistically, a dollar savings cannot reasonably be calculated now matter what kind of magic hat you possess. I have seen some attempts, by people with the best intent, to do this very calculation. But not knowing if or when or to what extent a loss may occur, nor to be able to truly measure the potential losses due to the large number of unknown variables which have an astronomical range of potential damage, these assessments are pure folly (but really fun to poke holes in). Half the battle in measuring the value of security is to know what limitations exist regarding the granularity of what can realistically be measured and validated.

 

 

Ugly Question #3: How do I compare the value between security and non-security initiatives?

This one bites. Really. It is almost impossible to do, anyone can challenge the results, and if you get this wrong everybody hates you. This comes up when senior management must decide where to spend hard earned budgetary dollars. It becomes an "us versus them" battle between security and some other group. Each party wants the money to spend and the infighting can get downright dirty. So what is a manager to do? Just tap your friendly neighborhood security analyst to calculate the value (just as long as it is not me), then compare against the value of the non-security program. Easy, right?

 

 

I wish. Security programs rarely have the benefit of real dollar justification attached. Unless you are in the security products/service industry, security does not generate revenue, it is just overhead. More on that in a different blog. Non-security programs have the edge here. A marketing program may generate XX dollars, an operations efficiency program may save YY downtime or be able to cut ZZ heads from the budget. These strong arguments bark loudly to management. Security value will retort with a whimper, maybe a risk reduction of xx% or at best a loss prevented of yy dollars. Did I mention even calculating such values takes more time, with more assumptions, and can't, in most cases, ever be validated as compared to the non-security programs? Pure ugliness. Alas it is not impossible. I have seen the fight won (ie. management given accurate and comparable data to make the best decision), but be beware, the deck is stacked against security.

 

 

Ugly Question #4: How much should my organization spend on security?

This is the big-daddy of questions, posed by senior management or if the organization is large enough, by a divisional head. Although I plan on discussing this in greater detail in another blog and whitepaper, the path to take is to identify the optimal level of security.

 

Every organization is different with ever changing business needs and drivers. What one company desires from its security program and is willing to spend will differ from its neighbor. The willingness to accept different levels of loss also vary greatly. But there are common perspectives which are shared to a great degree by all organizations. As an example, in most instances we don't want to spend more on security than we get in return (typically in the loss prevented).

 

 

If we look at an organization individually and imagine an increasing line of spending, for each point on that line we have an amount of residual loss which will be experienced (in theory, trending down to some degree as the security spending goes up) and therefore an amount of loss prevented for each point as well. At a strategic level, these three lines give us what is needed to answer this ugly question.

 

 

How much should be spent? Optimally, an organization should spend the amount of money on security which prevents enough loss to bring the residual losses to an acceptable level. What I have found, is the target exists somewhere between the low point of a diminishing rate of return and the high crossover point where the spending exceeds the loss prevented. Only management can decide exactly where the sweet-spot exists for any given moment.

 

 

Now your turn. What ugly question has been thrown in your direction?

 

Practical Aspects of Measuring Security

2 Comments Permalink