Standing On The Shoulders Of Giants (SOTSOG): My Parents

June 23, 2010

INFORMATION SECURITY PROFESSION TRAITS: TENACIOUS & FAITHFUL

This post is about my parents. My parents have been married for about 40 years and everyone in our family (parents, sister and I) still talks to one another!

My Dad is a Baptist minister; has been since I was like three years old or something. My mom currently works in the healthcare industry, but growing up she was a full-time Mom and as we got older she had some administrative jobs. People underestimate the demands placed upon ministers and their families. They get a lot of satisfaction from their profession. They give more then they earn- let alone take. Our family did not have excess but we were not poor either; the word optimal comes to mind.

TENACIOUS (Merriam Webster definition / synonyms)
My parents adhere to a way of life that was not always easy to understand growing up. I respect my parents for their resolve and desire to guard me (often against my desires) from situations that could have had undesirable consequences. However, I still managed to get myself in trouble on occasion. I would laugh when being corrected, once in awhile I made remarks that were not polite, I cut a girl’s hair “tail” off in the 6th grade, I liked flirting with girls- normal stuff…right?

Spanking – both in the home and in schools – was still a norm in the small town I spent the majority of my childhood in. Yep, I got spanked once in awhile – and to the best of my knowledge I deserved every one of them. I preferred the hand or a ping pong paddle instead of a wooden spoon or a real paddle. I also learned at some point that attempting to run away from or move in the paddling process could result in misplacement of the object striking me. Deep down inside I know my parents did not enjoy punishing me – they would probably never verbally admit they received some satisfaction from it – but if they ever read this – I bet you they would start to crack a smile…

Even though I do not share *all* of their political, social, or spiritual views – I respect – and even admire – them for their tenaciousness.

So how does this pertain to information security or risk management? From my perspective, it is not always easy to be in this profession. Between technology changes, doubters, binary IT mindsets, shortage of data sets, the nature of our work and a slew of other things – it is easy to become frustrated with our profession and leave. Our profession is not a one, two or three year stroll in the park that should reward folks with extra money because they passed the CISSP exam or know a list of acronyms. We are in a journey within a profession that is still evolving and that is slowly but surely integrating itself within business management. To that end is where I think tenacity comes into play.

FAITHFUL (Merriam Webster definition / synonyms)

When I reflect back on the first 18 years of my life – my parents are usually the first thought that comes to mind when I think about faithfulness.  With my Dad being a minister, I grew up seeing first hand how he and my mother served the church(s) he ministered to. The word ‘served’ is probably not an adequate word to describe his and her commitment to a group of people of which they would drop pretty much anything they were doing to be there in someone’s time of need – regardless of the circumstances.

So how does this pertain to information security or risk management? Well, there is a lot of randomness associated with the nature of our profession. We have very little control over externally initiated security incidents or even incidents that occur internally – no matter how awesome or weak our risk management programs are. Thus, we have to be there to deal with incidents and issues; 24×7. Faithfulness is applicable in many aspects of our lives; our personal relationships, our professional relationships, our employer, our profession and the list goes on. There are lots of times where we as information security professionals are not popular with the teams we are helping or non-information security people leaders in general. This is where faith comes into play. If you first stick to the principles of our profession and not get wrapped up in the emotions of others objections to what we are here to do – you will probably prevail.

The next SOTSOG post will be about the United States Marine Corps – feel free to drop down and give them 20, plus one for those currently getting shot at – just because!

Note: I started this post on 5/30/2010. A lot of things have happened since then that make me appreciate my parents even more. My Dad was having some chest pains and after a heart catheterization found out he had a 95% blocked artery in his heart; he had a stent put in the same day. Two days later he and my Mom made an emergency flight to Hilton Head to drive two of our relatives back to Ohio; one of which who had been admitted to the emergency room because of a blocked bowel. Yet another example of unselfish faithfulness.

Leave a Comment » | Uncategorized | Permalink
Posted by Chris Hayes

Risktical Blog Series: SOTSOG

May 28, 2010

Recently in the information security web 2.0 circles there has been some buzz about “breaking” into the industry, what does career goodness look like, etc. This has prompted me to think about my journey to date; and I would like to write a series titled “Standing On The Shoulders Of Giants” (SOTSOG).

The first few posts in the series may have little to do with risk management since they date back to my childhood and Marine Corps days. However, it would be negligent of me not to reference some people or things dear to me from those days since it established the foundation from which I have been built upon.

For each post, I will make a point to highlight the one or two qualities from that particular “giant” that I think applies to the information risk management professional. And just in case I forget to write the following points in my posts let me take the opportunity to do it now:

1. YOU are responsible for YOUR career (period).
2. YOU cannot control EVERY aspect of YOUR career.
3. However, YOU are responsible for how YOU deal with the things YOU cannot CONTROL
4. Its OK to admit YOU don’t know something
5. The advice I give to kids going into boot camp or learning something brand new: KEEP YOUR EYES AND EARS OPEN and YOUR MOUTH SHUT!

I hope you will enjoy the series. I will try not to expose too much of the gooey center inside my crunchy shell.

Leave a Comment » | Information Security, Informational, Risk | Tagged: | Permalink
Posted by Chris Hayes

Impromtu IT Risk Assessment Poll

May 25, 2010

You can select up to two answers. Thank you for participating!

1 Comment | Uncategorized | Permalink
Posted by Chris Hayes

Impromtu PCI-DSS Poll

May 14, 2010

Leave a Comment » | PCI-DSS | Permalink
Posted by Chris Hayes

More Heat Map Love

May 11, 2010

In my previous post “Heat Map Love” I attempted to illustrate the relationship between plots on a heat map and a loss distribution. In this post I am going to illustrate another method to show the relationship – hopefully in simpler terms.

In the heat map above I have plotted five example risk issues:

I: Application security; cross-site scripting; external facing application(s); actual loss events between 2-10 times a year; low magnitude per event – less then $10,000.

II: Data confidentiality; lost / stolen mobile device or computer; no hard disk encryption; simulated or actual one loss event per year, low to moderate magnitude per event.

III:  PCI-DSS Compliance; level 2 Visa merchant; not compliant with numerous PCI-DSS standards; merchant self-reports not being in compliance this year; merchant expects monthly fines of $5,000 for a one year total of $60,000.

IV: Malware outbreak; large malware outbreak (greater then 10% of your protected endpoints). Less then once every ten years; magnitude per event could range between $100,000 and $1,000,000; productivity hit, external consulting, etc.

V: Availability; loss of data center; very low frequency; very large magnitude per event.

Since there is a frequency and magnitude of loss associated with each of these issues we can conceptually associate these issues with a loss distribution (assuming that our loss distribution is a normal-like or log normal).

Step 1: Hold a piece of paper with the heat map looking like the image below:

Step 2: Flip the paper towards you so the heat map looks like image below (flip vertical):


Step 3: Rotate the paper counter-clockwise 90 degrees; it should like the image below.


For ease of illustration; let’s overlay a log normal distribution.

What we see is in line with what we discussed in the “Heat Map Love” post:

Risk V – Loss of data center; is driving the tail; very low frequency; very large magnitude.
Risk IV – Malware outbreak; low frequency; but significant or high magnitude.
Risk III – Annual PCI fines from Visa via acquirer / processor; once per year; $60K.
Risk II – Lost or stolen laptop that had confidential information on it; response and notification costs not expected to be significant.
Risk I – Lots of small application security issues; for example cross site scripting; numerous detected and reported instances per year; low cost per event.

There you have it – a less technical way to perform a sniff test on your heat map plots and / or validate against a loss distribution.

Once you have taught everyone how to perform this artwork paper rotation trick. You can have a paper airplane flying contest.

Leave a Comment » | Risk | Tagged: , , | Permalink
Posted by Chris Hayes

Heat Map Love

May 6, 2010

First, I would like to welcome Jack Jones *back* to the world of risk blogging. Jack blogged a few weeks ago on the subject of heat maps; “Lipstick on Pigs” and “Lipstick Part II”; prompting a response by Jared Pfost of Third Defense. These are great posts that underscore the need to structure and leverage heat maps in an effective and defensible manner.

The purpose of this post is to share a recent “ah hah” moment involving heat maps and loss distributions. Whether you are an advocate or not of risk quantification or simulation modeling – it is hard to criticize one for having tools or procedures in place that essentially serve as a “risk sniff test”. I consider reconciling portions of a loss distribution to a heat map – a pretty useful sniff test.

QUESTION TO BE ANSWERED: How do I reconcile – or validate – the plotting of a heat map bubble with a loss distribution?

Well, it depends…but let’s establish some context.

•    5-by-5 heat map. The X axis of the heat map represents “Frequency of Loss”; the Y axis represents “Magnitude of Loss”. Each axis is broken into 5 sections.

•    Let’ say we have a heat map whose bubbles represent categories of risk issues (ISO 27002 categories, BASEL II OpRisk Categories, etc…).

•    At a minimum, all of these issues have been assessed with some methodology and/or tool (I prefer FAIR) that allow us to associate the frequency and magnitude of loss for each and every issue.

•    We can perform thousands of simulation iterations for each and every issue in the risk repository, perform analysis, determine categories of risk that are contributing the most to various percentiles of the loss distribution, and then associate them with a heat map.

•    For the purpose of this post we are going to make a good faith assumption that our loss distribution resembles a log-normal or normal “like” distribution.

Back in my “Rainbow Risk” post I shared an example of a “rainbow chart”; a 100% stacked bar chart representing the contribution of loss that a category contributes (by percentage) to any given loss distribution percentile. For example, in the rainbow chart on that post, it showed that Business Continuity Mgmt category of risk issues accounted for about 55% of the risk in the 99th percentile. On a heat map, most significant IT Business Continuity issues are probably going to be very low frequency, very high magnitude events. Thus, it is fairly intuitive that very low frequency / very high frequency magnitude loss events would “drive” the tail of a given loss distribution.

In the images below, I have mapped areas on a heat map (image 1) to areas on a distribution (image 2). Specifically, I am trying to illustrate how frequency and magnitude for any given issue factors into or most likely represented in a loss distribution.

Image 1
Image 2

Area A – Very low frequency, very high magnitude risk issues. These types of events or risk issues drive the tail portion of a loss distribution.

Area B – Very low frequency, moderate or high magnitude risk issues; or low to moderate frequency, very high magnitude loss events. It can be said that these type of issues also drive the tail – but maybe not as much past the 99th percentile like issues associated with Area A.

Area C – Low to Moderate frequency, moderate or high magnitude.  These issues are best represented in the middle of the distribution; generally speaking, around one standard deviation on both sides of the mean.

Area D – Very frequent, moderate or high magnitude. Loss associated with these issues is not as severe as those of Areas A and B; but are typically greater then the mean expected loss.

Area E – Very frequent, very high magnitude. Generally speaking, these issues probably drive the portion of the distribution between 1 and 2.5 standard deviations (to the right of the mean).

Area F – Low or moderate frequency, low or moderate magnitude. These issues best factor into the area of the distribution left of the mean. Loss associated with these issues is less then the mean.

In closing, I would share at least one use case for performing this analysis or validation. Key risk heat maps. If all of your issues have frequency and magnitude values as well as some other attributes associated with the issue, you can:

1.    Perform simulations on all of these issues.
2.    Calculate their contributions to various distribution percentiles
3.    Analyze the results by various attributes (ISO 27002, BASEL II, IT Process, etc…).
4.    Chart derived information (categories of risk) on a heat map
5.    Review for plausibility / accuracy (this should occur all the time)

I welcome any feedback!

1 Comment | Risk | Tagged: , , , | Permalink
Posted by Chris Hayes

Rainbow Risk

April 1, 2010

One of the benefits of quantifying risk for an information risk issue or finding is that it gives us an additional dimension for aggregate risk analysis. Instead of just simple counts of issues categorized by ISO 27002 section – we can now analyze risk (dollar values) in numerous contexts; limited primarily by the data you are collecting and your ability to associate some data elements to various frameworks. (ISO 27002, BASEL II, COBIT IT Processes, etc…).

Loss simulation and aggregate risk analysis is a big part of my world right now. However, one of the most complex challenges I face is visually representing risk in a meaningful manner to management. So, over the next few posts, I want to share some visualizations of risk and how they could possibly be used for decision making.

The chart above is often referred to as a “rainbow chart”. Technically speaking though, it is a 100% Stacked Bar Chart. What this chart is depicting is the breakdown of risk (percentage of loss and ISO 27002 section) of a simulated aggregate loss distribution; by loss distribution percentile. Say what…?

Let’s break it down…

Warning – I am going to oversimplify some statistical concepts. And yes – all of the percentages and dollar values are from a dataset with fictitious data for the purposes of illustration.

Output from simulations are often analyzed by percentiles. We often zero in on the 50th percentile; sometimes an indicator of the mean or expected loss for a defined time frame. For illustration purposes let’s associate some dollar values to loss distribution percentiles:

5th percentile: $100K
50th percentile: $1M
80th percentile: $2M
99th percentile: $5M

Given the dollar values above as well as the chart we can infer the following:

5th percentile:
a.    5% of the iterations resulted in simulated loss of around $100K.
b.    Roughly 30% of the simulated loss at the 5th percentile is related to Compliance issues (~33%; $33K).
c.    Another 30% of the simulated loss at the 5th percentile is related to Access Control issues (~30%; $30K).
d.    About 20% of the simulated loss at the 5th percentile is related to Systems Development & Maintenance issues (~20%; $20K).
e.    About 8% of the simulated loss at the 5th percentile is related to Business Continuity Mgmt issues (~8%; $8K).

50th percentile:
a.    50% of the iterations resulted in simulated loss of around $1M.
b.    Roughly 28% of the simulated loss at the 50th percentile is related to Compliance issues (~28%; $280K).
c.    Another 30% of the simulated loss at the 50th percentile is related to Access Control issues (~30%; $300K).
d.    About 22% of the simulated loss at the 50th percentile is related to Systems Development & Maintenance issues (~22%; $220K).
e.    About 12% of the simulated loss at the 50th percentile is related to Business Continuity Mgmt issues (~12%; $120K).

99th percentile:
a.    1% of the iterations resulted in simulated loss of around $5M (100% -99% = 1%).
b.    Roughly 12% of the simulated loss at the 99th percentile is related to Compliance issues (~12%; $600K).
c.    Another 15% of the simulated loss at the 99th percentile is related to Access Control issues (~15%; $750K).
d.    About 12% of the simulated loss at the 99th percentile is related to Systems Development & Maintenance issues (~12%; $600K).
e.    About 55% of the simulated loss at the 99th percentile is related to Business Continuity Mgmt issues (~55%; $2.75M).

PRACTICAL APPLICATION

This type of risk visualization allows for the following:

1.    BETTER VISIBILITY. Gives us visibility to risk by loss severity and by ISO 27002 sections.
2.    INFORMED DECISIONS. Allows for tactical and strategic decision making.
a.    Tactical. Risk around the 50th percentile is loss we would expect 50% of the time; time being annually. Thus, we can actively manage (reduce or maintain) expected annual loss by targeting categories of risk at this or surrounding percentiles.
b.    Strategic. Risk around the 80th (1-in-5) or 90th (1-in-10) percentiles is greater in severity but less likely to occur. However when you think of this in terms of years and given the volatility of threats in our profession – we have to be mindful of low frequency / high magnitude loss events. Thus, to address the risk at these percentiles – we could be more strategic in our planning and investments. It could take a few years to mitigate the risk down to an acceptable level – but we can spread those mitigation costs over time.
3.    COST / BENEFIT ANALYSIS. Above I listed risk at the 80th percentile to be about $2M dollars. We can quickly see that 30% of the risk at the 80th percentile is related to Access Control (~30%, $600K). If I want to reduce the access control related risk at this percentile and I estimate it’s going to cost me $100K – I can demonstrate a risk reduction both mathematically and by re-running my simulations absent issues that would be mitigated by my investment.
4.    DRILL DOWN. Depending on how your issues are tagged, we could drill down into ISO 27002 sections to see which sub-sections are driving the most risk for its parent section.

FINAL THOUGHT. There is uncertainty with risk. Performing aggregate analysis and simulations on your entire risk repository highlights the variability of loss and can make it easier to explain uncertainty to others outside the information security profession. Take for example the “compliance risk” values above. Annual expected loss associated with Compliance-related issues could be as little as $33K, most likely $280K and possibly $600K or worse. Do not underestimate management’s ability to understand this uncertainty and their appetite to make effective decisions around it.

1 Comment | Risk | Tagged: , , , , | Permalink
Posted by Chris Hayes

Working With External Data (Part 2 of X)

February 2, 2010

This is the second post of a series related to working with external data for analysis or modeling purposes. You can read the first post HERE or read the “cliff notes” summary below.

***

Part 1 “Cliff Notes”

1.    Know what information you are hoping to derive from the data.
2.    Methodically narrow down your data for relevant data points. More data does not guarantee better or more accurate information.
3.    Some refinement considerations include:
a.    Time frames. Limit your data set to a span of time commensurate with a minimum level of technology as well as a consistent expectation of regulatory / industry standard requirements.
b.    Good fit. Consider points related to your industry, service offering / value proposition, and loss form categories.
c.    Duplicate records. When working with multiple external data sources, keep an eye out for duplicate event records.
d.    Consistency. Be consistent in how you analyze data points.

NOTE: Collecting and right sizing external data is useful for comparing your internal loss events to external loss events, understanding what a worst-case loss could like for your company and possibly incorporating into a data set to be used for modeling purposes.

***

In this post, I want to focus on right-sizing data points in your data set commiserate with the size of your company.

1.     Determine the minimum value where right-sizing is not worth the effort. When faced with hundreds or even thousands of data points – there is going to be a “magic number” of records where the number of records lost does not warrant right sizing. The more you understand your business processes and partner with the appropriate stakeholder (business partners, marketing, legal, privacy, etc…) the easier making this determination should be. They *should* be the subject matter expert(s) on these matters and be leveraged whenever possible.

TIME-OUT. For the uber-privacy / legal folks our there, the loss of just one record is not desirable. But, we have to be reasonable and acknowledge that are thresholds where the “squirm factor” varies.

2.    Understand the type of data lost / compromised. This is really easy to overlook. Some data loss events involve just customer (consumer) data, other events may include just employee data, and some events may include both types of data. Understanding the type of data lost could prove useful in determining which right-sizing method to use.

3.    Right-sizing factors (proportions). This is where things get interesting. It also where objectivity and consistency have to be demonstrated. Whether we are performing risk assessments, right-sizing data points, or collecting information to draw conclusions from – it is important that we are as objective as possible; reducing subjectivity whenever possible. The key point I want to make here is that if used appropriately and consistently, a right-sizing exercise is more objective in nature then stating it happened to company X so it could happen to us without any analysis whatsoever. You may want to make a brief note as to why you chose a certain right-sizing factor in case you need reminded at a later point for whatever reasons. Let’s look at a few right-sizing options (keep in mind that we are building upon what we covered in the first post):

a.    # of Employees. If a data point is from a company in the same industry or has the same value proposition – using number of employees could be a good right-sizing factor. Some inferences can be made around the number of employees. Is it unreasonable that if a company half of your size loses 10,000 records and is obligated to protect data equally as well as your company, that the same event could happen to your company for 20,000 records? Using number of employees is also useful when the data point only involves confidential employee data.

b.    Revenue. Revenue could be another right-sizing factor. Maybe the data point is from a different industry where staffing types / level differ from your industry but the value proposition is related (property & casualty insurance versus health insurance).

c.    Equity. In some cases, equity can be used as a right-sizing data point. # of employees or revenue may not be appropriate or the proportions could be unrealistic. Equity could be a third option.

d.    Others. There could be some other right sizing factors depending on your industry or the problem you need to make decisions for. Just make sure that whatever that factor is, that it is generally regarded as a sound comparative measurement factor and document any assumptions. Again, I cannot underscore the need for objectivity and consistency.

NOTE: Keep an eye out for some data points that have been right-sized but the calculated value far exceeds the total number of records you have in your organization. Consider another right-sizing factor or change to the maximum amount of records you have; and of course, document. Some situations may warrant keeping the value (like a risk assessment related to merger or acquisition where the number of records you are obligated to protect now- doubles, triples, etc…). What you don’t want is someone calling you out on a data point that is not even realistic for your organization because of a simple oversight (I speak from experience).

4.    Sources of Information. In order to right-size data points – especially in the context of the factors above (employees, revenue, equity), you have to get information about the companies related to that external data point. I would submit that the information you need is available in most of the cases – it is just a matter of time and creativity.

a.    Internal information. You need to collect your own internal information for the right sizing factors before you can right-size against external data point company information. HR may be able to give you # of employees by year and hopefully there are numerous internal authoritative resources that have your revenue and equity values (if you are publically traded – this information is publically available; though you should still confer / validate with internal sources).

b.    External information. Be Creative. Yahoo business, Dun & Bradstreet, company name Google searches combined with “annual report” or “corporate filings”, company websites and Fortune 100, 500 or 1000 lists; these are stating points. Just remember to make sure you are right-sizing in the context of the same year the incident occurred in – and be consistent.

In the next post for this series, we will look at analyzing a right-sized data set to begin collecting information. For example, does the data resemble a statistical model? Does it resemble your internal data points? What if my data set has too few data points?

Leave a Comment » | Information Security, Informational, Risk | Tagged: , , | Permalink
Posted by Chris Hayes

What’s In Your Wallet?

December 28, 2009

A few weeks back I jumped feet first into a blog post at Securosis by David Mortman titled “Changing The Game”. There are a lot of comments but one comment in particular by Rich Mogull has resulted in me doing some soul searching, adding a new question to my bank of interview questions, and forcing me to write a blog post (while on Christmas / New Year’s vacation).

Below is the majority of the comment that Rich made:

“The problem I think we have in infosec is that the economics are skewed to distort risk analysis (see my post on the anonymization of losses), and we fundamentally lack the proper data to make truly informed risk decisions.

I do think we are creeping slowly in the right direction- the Verizon report is one example on the data front, and it’s the main reason we are focusing so much on metrics models.

One area where I do think we need to be cautious is the need in many financial and insurance models to tie everything to monetary value. Since “loss” has a different meaning in the digital world due to us usually not losing access to the asset as with physical loss, the models don’t fully translate.”

So here is my question to you as a reader: What Is Your Information Risk Management Philosophy in regards to risk quantification? Do you even have one?

There is a lot of skepticism in our industry – sometimes packaged as healthy scrutiny – when it comes to the topic of risk quantification and tying loss forms to monetary values. Below are some of my “philosophical” thoughts about Information Risk Management specifically as it pertains to risk quantification.

1.    Security Events / Incidents Have An Opportunity Cost. When something “bad” occurs – it costs the company money to respond. Whether it is “green dollars” going out the door or soft dollars associated with the hourly cost of full time employees responding to the event, the reality is that the company will deal with the incident and that response effort usually takes away from other responsibilities or objectives. We can count green dollars, but counting the internal costs can be more challenging; the size and maturity of the HR/IT organization will factor into the ease of doing this. Bottom line: It costs money.

2.    It Costs Money to Maintain a Security Posture. One of the executives at my company referred to this concept as “anchoring costs”. A perfect example of this is malware protection. A company may spend $125,000 dollars a year in malware maintenance / support fees; a solution that is considered to be 96% effective against malware in the wild with advanced detection / heuristic capabilities.  For simple illustration purposes, let’s state that there are two full-time employees on the malware team ($50K each) – that’s an additional (minimum, excluding benefits, etc..) $100K on top of the $125K to manage, maintain, and support a malware protection capability; a grand total of $225K per year. This is an example of an anchoring cost: the company is spending $225K a year to protect against a malware outbreak or event that could result in loss of productivity – i.e. deliver its value proposition – or prevent data theft / compromise. We could probably spend a few days debating if this particular anchoring cost accounts for the expected amount we would lose in a given year without malware protection or if this annual anchoring cost is to address a risk value further out in a loss distribution (1-in20; 80th percentile, 1-in-100; 99th percentile). Bottom line: It costs money to maintain a security posture.

3.    Overcapitalization. Now we are moving into the ERM space – and this concept may be limited in scope from an industry perspective – but it is evolving and can facilitate decision making in some organizations. Economic capital models account for various types of risk. One of those risk types is operational risk – of which information security and continuity management risks fall under. Below is a broad definition of economic capital (Wikipedia):

“Economic capital is the amount of risk capital, assessed on a realistic basis, which a firm requires to cover the risks that it is running or collecting as a going concern, such as market risk, credit risk, and operational risk.” (BTW, I really like the phrase “assessed on a realistic basis”)

One analogy I read on overcapitalization in the last few days was comparing overcapitalization to an overweight person. Too much weight can lead to health problems and other challenges. In addition, the extra weight inhibits our flexibility and speed.

Assuming that you are quantifying risk issues, and assuming that these data points can be rolled up into an economic capital model – it is clear that risk quantification for the information security / continuity management issues we manage- can contribute to enterprise risk management. I think an argument can be made – especially in the insurance industry – that company leadership has much more opportunity and influence to manage (reduce) operational risk – then other risk types, for example weather / catastrophe risk. Yes, operational risk is probably a very small percentage of economic capital. However, the higher the economic capital amount – the higher cost to the company to maintain that amount and it could reduce their ability to use some of that money for other purposes. In addition, regardless if operational risk is only a tiny percentage of economic capital models – the margin of difference between competing products and competitors in the market place is sometimes so small that reducing just a small percentage of expenses or operational risk – could result in some form of competitive advantage (product pricing, investments, expansion, etc..).

Bottom line: I would rather be contributing to our business in a strategic manner using words, concepts and measurement methods  they are familiar with, versus some qualitative approach that does not lend itself to effective decision making.

4.    Motives. Given the current economic climate, a lot of people (infosec professionals, infosec executives, friends, relatives, etc..) are skeptical of risk models. I understand why. Here is how I professionally reconcile such concerns / skepticisms.

a.    Apples and Oranges. Economic capital models ( and at a smaller level – risk issue quantification) and investment models have different purposes. The former is about ensuring a company can covers its liabilities. The latter – in most cases – is about opportunity – profit.

b.    Motives. I think you have to look at the motives of companies or individuals that are attempting to quantify information security / continuity management risk. What they are trying to do is ensure that their company understands their exposure in the information risk management space. This is where the phrase “assessed on a realistic basis” comes back to mind. Is a sound and repeatable risk assessment methodology being used consistently to assess risks? Are loss forms that are being estimated best case, most likely loss, worse case loss or a combination (distribution) of the three? Are we packaging information that allows effective decision making, or are we “crying wolf” and packaging scare tactics? In most cases, information risk management groups are just trying to give the best information. Yes, there will be misses in either frequency of loss or magnitude of loss – but that is the nature of risk.

So there you have it, some of my thoughts on risk quantification and why I support it passionately. Ask yourself, “Can I defend why I am passionate about my favorite aspect of information risk management?” If not, I challenge you to go through the thought exercises.  I welcome your feedback.

Happy Holidays!

1 Comment | Information Security, Risk | Tagged: , , , | Permalink
Posted by Chris Hayes

Verizon – 2009 Data Breach Investigations Supplemental Report

December 9, 2009

This is no doubt one of many blog posts regarding the Verizon Business RISK Team “2009 Data Breach Investigations Supplemental Report” (DBISR). Below are a few of my thoughts.

1.    Quality of the Data. While it is neither the intent or spirit of the report to compare the usefulness of the information or the quality of the data to public data sources, I think it is important to recognize that the facts being collected by the Verizon team are generally more credible then the third-party sources that other public sources rely upon. In scenarios where I am trying to gather information about a breach or compiling a dataset for analysis – I am going to have a higher level of confidence in data / information from sources closer to the incident – then third parties just reporting on it. This does not mean that 3rd-party data is not legit – I am just suggesting the quality – from an accuracy and reliability perspective – is different and should be recognized.

2.    Data Overlap. On page 23 – is a table comparing the Verizon IR breaches and records lost to the equivalent DataLossDB values (keep in mind these are point in time values). The question I have is, how many of the 592 breaches in Verizon’s dataset are accounted for in the DataLossDB dataset? The reality is that in some US states (assuming all the breaches were in the US), data breach notification is not required, so an event can occur that does not result in breach notification to the consumer or the applicable State Attorneys General. If there were a difference between Verizon and DataLossDB – it only strengthens my confidence in their data because it contains credible data points not represented elsewhere (private consortium data aside).

3.    Threat Action “Profiles”. If you have not printed pages 5-21 and posted them on your cubicle / office wall – or recommended to your peers or other information security professionals – why not? Seriously. Threat actor / threat community profiles are such a valuable resource for security / risk practitioners to quickly reference, especially when we are dealing with dozens of threats and hundreds of controls. I can assure you that I will probably incorporate some of the DBSIR “threat action” profiles for some work I am doing in this same space with my employer – good job Verizon!

4.    Industry. My final observation is related to the industry and size of companies where breaches have occurred. I have blogged about this recently and I only mention this to remind folks that not every data point whether it is from Verizon, DataLossDB, PrivacyRights.Org, or other public / private data sources may be relevant to your industry or your company. The reality is that there are different expectations and regulatory requirements between industries and you have to keep that in mind while in the process of drawing conclusions from these types of reports.

Overall, two thumbs up to the Verizon Business RISK team. I commend them on their willingness to share this information and their desire to influence our industry as a whole.

Leave a Comment » | Uncategorized | Permalink
Posted by Chris Hayes

« Previous Entries