Posts Tagged ‘Information Security’

Security decision methods poll Results

Monday, October 12th, 2009

A couple of weeks ago, I wrote a post on how we in the security industry make decisions. After a bit of waxing philosophical, I proposed a list of decision “methods” I regularly see in use among organizations. I also created a small survey (that contained a few additional methods) to capture your experiences for comparison. The response was not overwhelming by any stretch but the results are below (click the image to make it bigger).

Decisions survey results_small

(more…)

Security Decisions – How do you make them?

Monday, September 28th, 2009
As a student of both the fields of Information Technology/Security and Management Science (http://en.wikipedia.org/wiki/Management_science), I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for and advocate our need of engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).
One area where the engineering and management mindset clash is in decision-making. The engineer asks “What do I need to know to precisely formulate all factors in this decision?” while the management scientist asks “What do I need to know to make a good decision?”. In such matters, I side heavily with the management scientist.
The obvious application of this is in evaluating potential security initiatives or projects (“Should we do X, Y, or Z?”). In most cases, it is impossible to precisely formulate all factors in the decision, so we abandon the “scientific” route and revert to some other method of making it (see below). This is where our predominantly engineering mindset hurts us. Instead, we should realize that organizations have always made decisions using varying amounts of information of varying quality. Our dilemma is not new. Valid and vetted approaches exist for structured decision problems with an abundance of precise data and also for unstructured problems with sparse amounts of “fuzzy” data. They are out there and eagerly waiting for us to apply them to problems in our domain.
Ok, I’m off the soapbox. The main goal of this post is to ask how your company makes “Should we do X, Y, or Z?” decisions. I’ll start the conversation by listing the methods I see used most often. In doing so, I make no judgment on any method’s ability to support good decisions (though it’s clear some have more value than others).
The “Adamant Auditor” method: You’ve been here. The 22 year old kid shows up 3 months out of the university with his checklist etched in stone. He darn well better be able to check off all those boxes or you’re toast. “But if X does Z and Y does Z, then X=Y… and we’ve done Y” you argue only to receive blank stares. Good luck with that. Unless you can build a credible risk-based argument, you might as well just do X like he says.
The “Peer Pressure” method: This is the grown-up equivalent to doing what the cool kids do “Peers X and Y are doing Z, so we should too” is the justification here. It might be that X and Y have their act together and are great role models. Then again, they might think that alcohol, blindfolds, and a game of high-speed Chicken make for a great Friday night. Remember what your Mama said – “If so and so jumped off a cliff, would you?”
The “WIBeHI” method: If you’ve ever used anything that sounds remotely like “Wouldn’t It Be Horrible If X happened, therefore we should do Y” to justify a security initiative, then you’ve used this method. The potential worst-case scenario (and often some extra FUD for good measure) is the main decision criterion in this approach.
The “Guru Guidance” method: Every organization has its guru and every guru has his opinion. Just ask him. It might be that nobody understands the technical justification behind what they’re recommending, but he knows his stuff, right? Right?
The “Poll the Panel” method: Often called the “Delphi Method” but I’ve never thought the name very fitting. No journey to a mystical oracle with secret knowledge is required; you simply gather your smart folks and get them to come to a decision. The assumption is that decisions made by many are better than decisions made by one.
The “Pet Project” method: Perhaps it was the advertisement in that magazine on the plane. Maybe that analyst report. Who knows why your boss wants that project so badly, but its clear she does. And in this job market, who’s going to argue? If you can get it done while also squeezing in something with actual benefit, there’s a chance you can still put a mark in the Win column.
My tone here is obviously facetious but I am quite serious that I believe these methods (or some form of them) account for the majority of security decisions made in most organizations. Is this your experience as well? We’ve put up a quick, one-question poll on the topic here and would love to hear from you (we’ll share the results later). If any of these methods resonate or if you have some to add, please chime in.

As a student of both the fields of Information Technology/Security and Management Science, I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for, and advocate our need of, engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).

One area where the engineering and management mindset clash is in decision-making. The engineer asks, “What do I need to know to precisely formulate all factors in this decision?” Meanwhile, the management scientist asks “What do I need to know to make a good decision?” In such matters, I side heavily with the management scientist. (more…)

Re-imagining Information Security Standards

Tuesday, September 22nd, 2009

Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

RE-IMAGINING INFORMATION SECURITY STANDARDS
Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”.  But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.
I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:
1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.
2.)  To request your feedback on the idea.
So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:
1.) A standard must provide for its own obsolescence/evolution  (falsification and a transparent falsification process must be built in)
2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)
3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)
RE-IMAGINING INFOSEC STANDARDS: THEIR NATURE
Digging right in, if we want to re-imagine standards we might start by reviewing the fundamental nature of what a standard is.  In a very real sense, our standards are models.  As such, any standard is only a hypothesis about how to keep our information confidential and available while maintaining its integrity.  But if we’re going to (finally) acknowledge that InfoSec standards are models/hypotheses, then we need to embrace a fundamental premise behind scientific theory: a model or hypothesis is meant to be tested, falsified, and evolved.  As such, our new view of InfoSec standards would require that we keep whoever developed the standard (or its current custodian), accountable for that scientific method.
Science Requires Falsification and Innovation
Now ideally, we’d have two things built into the concept of accountability.  These two ideas would mean that the standard would provide for its own obsolescence or evolution, and are the premise behind my first usefulness requirement, “a standard must provide for it’s own obsolescence/evolution  (falsification and a transparent falsification process must be built-in).”
1.)  The InfoSec standard itself should have a falsification process built into them.  The standard might describe the pursuit of falsification, what falsification/failures for the standard might look like, and provide us with the means to report a probable failure.
2.)  The standard custodian should provide transparency and reporting about that falsification process. Practitioners would have up to date knowledge about failures so that they can keep an eye out for them in their own environment, and hopefully be able to offer a modification to or alteration of the standard based on new information.  So whether this is just “patching” the standard or if it leads to a whole new hypothesis, we (the InfoSec community) would at least have visibility into a need to “re-secure”.
RE-IMAGINING INFOSEC STANDARDS:  THEIR PURPOSES
Related to our examination of fundamental nature, let’s think about what InfoSec standards are a model *of*.  We said that they are models we build to help us with our quest for maintaining the C, I, and A of our business data.  In that regard, we might suggest that they are about Information Security “engineering” and management.  In other words, design and implement practices to ensure C, I, and A and then establish practices to maintain the desired level of C, I, and A.  But if you’re building a control framework or understanding how you should best operate it, both disciplines require the use of measurements. This then necessitates the development, use, and reporting of metrics (indeed, the concept of measurement would be very useful in the scientific method process above).
The Purpose of Standards Requires Measurement
So while we’re re-imagining InfoSec standards, let’s imagine this: standards that tell us not only how to measure the standard’s outcome (secure enough) in a state of nature assessment, but also how to measure the actions that cause “secure enough” – what we might call the quality of standard adherence.  This gives us my second standards usefulness requirement,  “a standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)”.
This way (and only in this way) we might know that by having expended X amount of effort for compliance to the InfoSec Standard, it produced Y amount of outcome.  Then people who implement the standard can discuss how they got Y+n amount of outcome for X-z amount of effort thanks to some new control, or how they are consistently seeing Y amount of outcome from year to year regardless of whether they spent X-1 or X+1 amount of effort, and so on.  But we are at the point, as an industry, where measurement is not just desirable – these days it’s actually necessary.
RE-IMAGINING INFOSEC STANDARS: PLAYING NICELY TOGETHER
Finally, since we’re trying to describe a new way of looking at security standards, maybe we could discuss the creation of a means by which models might be able to contribute information to each other.
You see, my belief is that Information Security, as we’re able to describe it right now, is too complex for one over-arching textbook sized model.  Rather, I believe that we’ll be more effective if we break the big problem up into smaller, more digestible chunks.  So practitioners of the various operational security duties can actually focus on their area of expertise, and not try to be masters of multiple domains (specialization is good, they say).
Standards Must Communicate To Have Aggregate Value
However, if we took the time with a whiteboard to try to paint a picture of all the components of organizational security (talking about the various areas of security specialization in sort of an object oriented sense, if you will), I’m betting we’d see that each area of security needs to be able to share information with others in a meaningful manner.  So Software Development processes need to exchange information with Vulnerability Management, who needs to talk to Intrusion Detection/Prevention, who needs to talk to Incident Response, and so on.  Now if we can establish rationalized metrics for the models (above), then ideally we’d be using a common security taxonomy, or at least using translation documents provided by the standard that would allow us to use one disciplines metrics (prior or posterior) if relevant to another discipline.  This gives us my final standard requirement, “a standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)”.
Carrying that idea forward, it would probably be a great thing to have multiple competing models in any specific field, and wouldn’t it be wonderful if the language and meaning that they used were the same or easily translated (other than measurement models, obviously)?  So we would have an idea of comparative (in)effectiveness between competing models!
MOVING TOWARD A RE-IMAGINING
Yeah, so I’ve described a dream world of candy cane trees, rainbows, and happy unicorns.  Sure.  And I know it might take a generation or two of security professionals to get there.  But that doesn’t mean we can’t start now, and start with our current standards bodies – especially within the context of the pursuit and transparency of falsification and the development of meaningful metrics.  All it takes is the will to try and the willingness to fail.  As my co-presenter David Mortman and I said at Black Hat this year, “Models don’t have to be perfect, just ego-less”.Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:

1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.

2.)  To request your feedback on the idea.

So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:

1.) A standard must provide for its own obsolescence/evolution (falsification and a transparent falsification process must be built in)

2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)

3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)

(more…)

Preparation for Internet Attacks

Tuesday, August 25th, 2009

by William Murray

Headlines this week have reported on denial of service attacks against  Twitter, Facebook and several other social networking sites.  These follow attacks in July against various government sites in the US and South Korea.  The headlines have elicited all kinds of commentary, most of it stopping just short of concluding that the sky is falling.  In all of this coverage, I have seen almost nothing about what this means to the average enterprise or what one ought to do about it.
Denial of service attacks work by exhausting finite resources.  (They are different from an attack that compromises a system and then breaks it or shuts it down. ) Historically we thought of them as exhausting system resources.  For example, “Syn  flood” attacks against servers work by exhausting memory until the server dies.   However, modern distributed denial of service (“DDoS”) attacks (“distributed” modifies “attack,” not “denial of service”) work by exhausting network band-width, usually the “last mile” to the victim.
To maximize the availability of resources in general, and information assets in particular, it helps to have some appreciation of the threat.  Most of the threats to availability are natural, not man-made.  They include everything from massive events like Hurricane Katrina to component failures.  Historically, most of the man-made threat has been accidental, errors and omissions.  This was in part because even the most malicious lacked the resources or motivation for more than the most local attacks.
The modern open network has changed that.  Not only may an individual control vast stolen resources (”bot-nets”) but he can direct them against a target of choice.  At first, the use of this power was by children and other amateurs and targets were somewhat random.  Increasingly the power is used by professionals and victims are chosen to make money (e.g., by extortion or short selling of securities).  The attack against Estonia, among the tiniest of nation states, has created fear that nation states might attempt to use the links between them to attack one another for political or military purposes.
Our fundamental strategies for ensuring availability include adequate capacity and reserves, easily deployed, avoiding single points of failure, planned response to events, and insurance.  The planned responses include relations with key suppliers.  Here is where the potential for denial of service attacks suggests a new tactic, pre-arrangement with one’s upstream network service providers.
Steve Gibson reports that in the first well-publicized attack against grc.com, it took him 12 hours to find the right individual at his internet service provider and ten minutes for that person to fix it.  Since one will rarely have so much capacity that an attacker cannot exhaust it, assistance from one’s upstream provider is always helpful and may be essential.
Internet service providers offer multiple alternatives for mitigating denial of service attacks, from simple filtering, alternative addresses, alternative paths, to capacity for absorbing the attack.  Many spell out these services in their offerings.  Some of these services are separately priced.  (For the few enterprises that are targets of choice for denial of service attacks, there are specialized services that offer massive capacity for absorbing attacks.)
Media coverage to the contrary notwithstanding, and at least for the time being, for the average enterprise, network-based denial of service attacks will be rare and short lived.  They may be slightly more likely than regional disasters but less damaging. They should be addressed in the context of other threats to availability.
That leaves the issues of a national denial of service attack,  like Estonia, a global denial of service attack, like SQL/Slammer, or “Cyber Terrorism.”   The so-called attack against Estonia was really a number of loosely coordinated attacks against a very small nation state that was unusually dependent on the Internet.  While somewhat effective, even it consumed only a small portion of the total capacity of  even that small country.  The recent coordinated attacks against the US and S. Korea were even less effective.
SQL/Slammer was a global denial of service attack which attempted to exploit a wide-spread vulnerability to organize Internet nodes against the Internet itself.  It produced a noticeable, localized, and short-lived decrease in the useable capacity of the Internet.  Because it was easily recognized, it was possible to put filters in place to shut it down within hours.  However, one can easily visualize a more heterogeneous attack that would have been more difficult to stifle.  One cannot afford to dismiss the possibility of such an attack. However, as time passes, the potential for it to be effective diminishes.   The wide-spread use of restrictive policies, e.g.,  default deny, personal firewalls, resists the marshalling of the Internet’s nodes against itself, the capacity to be exhausted increases, and the preparation and strategies of the operators improve.
Terrorism can be defined as an attempt to achieve political ends by frightening the populous.  While the death and destruction is beyond question, its effectiveness in achieving its ends has always been questionable.  In modern terrorism, the means have become so separated from the ends that the terror has become and end in itself.  The speculation about “Cyber Terrorism” is based upon the idea that the  Internet might be such an attractive means to a terrorist as to make its use for  an attack all but inevitable.  To the extent that it permits a small number of people to exercise control or project power at a distance, the Internet is an attractive attack vector.  It is certainly attractive as a means of demonstrating the vulnerability of a highly technologic society.  However, as a means of creating terror, it is far less attractive than random death and destruction.
“Think globally, act locally.”  For most of us, the proper response to any potential for “Cyber Terrorism” is  to  protect our own  resources so that they cannot be used against our neighbors.

Recent headlines have reported on denial of service attacks against Twitter, Facebook and several other social networking sites.  These follow attacks in July against various government sites in the US and South Korea.  The headlines have elicited all kinds of commentary, most of it stopping just short of concluding that the sky is falling.  In all of this coverage, I have seen almost nothing about what this means to the average enterprise or what one ought to do about it.

Denial of service attacks work by exhausting finite resources.  (They are different from an attack that compromises a system and then breaks it or shuts it down.) Historically we thought of them as exhausting system resources.  For example, “Syn  flood” attacks against servers work by exhausting memory until the server dies.   However, modern distributed denial of service (“DDoS”) attacks (“distributed” modifies “attack,” not “denial of service”) work by exhausting network bandwidth, usually the “last mile” to the victim.

(more…)

Talking about Risk

Wednesday, July 15th, 2009

by William Murray


Not so long ago, but in a different era, the rogue hackers were building tools to automate the creation of viruses and worms to exploit newly publicized vulnerabilities.  They boasted that these tools were enabling them to develop malicious code faster and faster and that soon they would be able to create an attack within twenty-four hours of the identification of a vulnerability. Thus was born the idea of the “zero-day” attack.  Note that “zero-day” is a term of art, that it modifies attack, and that it is relative to the identification of the vulnerability.  

While it is sometimes used to refer to a previously unknown vulnerability, the words have no meaning in that context. “Zero-day” relative to what?  To yesterday?  The term has lost its original meaning without gaining a new one.  It became an expression that, not only carried no meaning of its own, but confused the meaning of any terms with which it was used.  This aggravates the general problem in security that our terms of art, e.g. threat, attack, vulnerability, and risk are used without distinction, not to say interchangeably.  Multiple times a week I find myself parsing quotes about security in the media, in a sometimes vain attempt to figure out what the source intends.

(more…)

What’s the deal with Anti-Forensics?

Sunday, May 31st, 2009

Despite the release of numerous tools intended to make things easier for forensic investigators, there’s also development on the other side of the law. I’ve personally given multiple presentations on the topic of anti-forensics at various conferences and have also attended my fair share as well. No matter where you go, it always seems to be a very polarized discussion.

You have the folks on one side of the room that go to the presentations seemingly just to heckle the speakers. They claim that anti-forensics doesn’t exist, and that it’s a myth propagated by the companies that do investigations. Let’s just say for argument’s sake they’re right. Can anybody out there prove that it’s not happening?

Now let’s look at it from the other side. Do we have cases where we have confirmed that anti-forensics was in use? Yes – and we’re not talking about a meager amount either. Based on just our metrics, we see anti-forensics is involved in more than a third of our caseload. And considering that, by its very nature, it’s designed to never be found, we can reasonably assume that the actual presence of anti-forensics is probably much higher.

On what side of the room are you? Any experiences you wish to share regarding AF?

Exploitation of Previously Unknown DirectShow Vulnerability Occurring

Friday, May 29th, 2009

Microsoft has announced that they have discovered a vulnerability in DirectShow. Exploitation of the vulnerability could allow a criminal to run code of their choice in the victim’s security context simply by the victim browsing to a website while allowing scripts to run. The browser being used doesn’t matter providing it allows scripting. Microsoft is aware of limited attacks in-the-wild. Patches are being developed.

All versions of Windows are vulnerable, except Vista and Server 2008. It is worth noting that DirectShow was patched for similar vulnerabilities in April 2009, and previously in December of 2007. Neither of those vulnerabilities was ever significantly exploited.

(more…)

When you’re pwned, you’re pwned. Any questions?

Friday, April 17th, 2009

Multiprotocol Label Switching (MPLS) security is not for the faint hearted. However, like most information technology, understanding basic principles and having a policy founded on sound principles allows an administrator to sleep at night knowing the networks are secure.  A policy for employing thoughtful and conservative essential practices and having quality assurance practices to ensure continuity of secure operations is one of those basic principles.  An antithetical principle is that when a criminal takes control of your systems, bad things are going to happen.

(more…)

The 2009 Data Breach Investigations Report

Wednesday, April 15th, 2009

Get it free of charge with no sign-up requirements here.

Creating the single-year sequel to a four-year report on over 500 breach investigations is a daunting prospect. While it would be impossible to trump the sheer scope of the original 2008 DBIR, we’ve sought to preserve its strengths and introduce some key enhancements for 2009. Here is some of what you can expect in this release:

First, you’ll notice the report is quite a bit larger than last year. Hopefully it’s worth the extra disk space (which isn’t saying much given current prices) and/or toner (which *is* saying a lot given current prices). Rather than platitudes and pitches, we’ve worked to fill those extra pages with real substance. Everyone loves data.

(more…)

2009 DBIR: Demographics

Wednesday, April 15th, 2009

In our minds, there are two very interesting items with regard to demographics in this years report.  The first is that the number of attacks in the financial services industry more than doubled in 2008.  More importantly, an amazing 93% of compromised records were the result of breaches in the financial services industry.  As we said in our report, this is largely due to a few cleverly designed and executed attacks which yielded huge payloads.  It will be interesting to see if this trend continues or if the bigger players in the financial services field will be more successful in avoiding these attacks in the coming year.
On a side note, we have seen a few comments from our readers in which they question why we included size of industry in our demographics section.  This was done simply to illustrate that the caseload didn’t all come from very large or very small companies, but was spread across a wide range.
The other noteworthy item is that 13% of the organizations in our caseload had recently changed hands as a result of an acquisition or merger.  While we make no bones about the fact that we cannot draw any ‘scientific’ conclusions from this data point, we find it relevant and of great interest.  Anyone with any experience of large scale change in any company can testify to the fact that they rarely (nice way of saying NEVER) go smoothly. Hopefully, any insight our investigators can lend to what commonalities exist between the breach victims of recently merged companies can be applied to prevent future crimes from occurring.  What are your thoughts?

2009 DBIR: Sources of Data Breaches

Wednesday, April 15th, 2009

I’ve been reading reviews of the 2009 DBIR today and I gotta say – I’m surprised at the lack of snarling and teeth gnashing over our stats on who’s behind all these breaches and lost records. Last year, we received no shortage of comments (positive and negative) about insiders causing the fewest breaches. I won’t go into all the various reasons behind our findings here since that is done in the report. I would like to say that I was surprised at the disproportionality of Fig 8.

(more…)

2009 DBIR: Attack Difficulty

Wednesday, April 15th, 2009

by Chris Porter

The relative difficulty of attacks leading to data compromise is an excellent indicator of both the current threat environment and the state of modern security programs. After each forensic investigation, our VzB investigators assess the attack and classify the difficulty into the following categories: None, Low, Moderate and High.

There are several rather interesting finds within the data this year. One is that attackers used simple methods of attack in over 50% of the breaches. The basic conclusion from this is that attackers still do not have to work very hard to get the data they desire.

Another interesting find in this data set is related to a new metric that we have added. This year the attacks have also been analyzed for the number of records breached. If you look at the highly difficult attacks in this data set, they are responsible for 95% of the 285 million records breached.

I also found it interesting that when you look at an attack from end to end, the difficult part typically occurs after the criminal penetrates the perimeter. Most highly difficult attacks were given that classification because of the elaborate nature of the malware used to capture data rather than the hack used to get in the door. The latter is usually involves more run-of-the-mill techniques.

What did you find interesting? Please share in the comments section below.

2009 DBIR: Attack targeting

Wednesday, April 15th, 2009

In our report we found it helpful to further break down the standard classifications of attacks, opportunistic and targeted, into three categories:
Random opportunistic – victim randomly selected
Directed opportunistic – victim selected, but only because they were known to have a particular exploitable weakness
Fully targeted – victim was chosen and then attack planned

In 2008, fully targeted attacks rose to a 5 year high, and accounted for 90% of total records compromised in 2008 (by comparison, it was 14% in last years model).  We have said in the past that if criminals (particularly organized crime with its vast resources) take aim at your organization and attack you with enough intensity over a long enough time span it is likely that they will breach your perimeter.  The caseload for this report seems to go a long way toward proving this to be true.
At the same time, the majority of attacks were not fully targeted, but were of the more opportunistic variety.  The old adage of the deer and the bear applies here.  When being chased by a bear you don’t have to be the fastest deer, you just have to be faster than the one next to you.  In other words, set up your defenses in such a way as to minimize your chances of being the target for these kinds of attacks.  This can be attempted in a variety of ways.  One important element is to retain as little data as possible in the first place. If you don’t absolutely have to have if for business reasons, or if your legal department doesn’t insist on it (good luck), then get rid of it.   Also, know where your critical information resides at all times, and who has access to it.  You may feel that you don’t have the time or resources to do this.  Relax, if you don’t find it the criminals will do it for you for free.

2009 DBIR: Compromised Assets

Tuesday, April 14th, 2009

Figure 25 in the 2009 Data Breach Investigations Report (p30) shows that for the big computer crime cases in 2008, the vast majority involved data from servers (Online Data 94% of cases).  In only 17% of all cases were End-User Systems involved in any part of a target.  In only about 1% of cases (one case out of 90, Figure 16) were End-User Systems part of the attack pathway.  The very same data, when viewed by the percent of records lost, shows that 99.9% of records were taken from servers, while just 0.01% of the records were taken from End-User systems.  Wow!

(more…)

2009 DBIR: Compromised Data

Tuesday, April 14th, 2009

To my mind, this section included several areas of interest. The sheer number of compromised records we investigated in 2008 is surprising – even to us. Only time will tell how the numbers will stack up in 2009 but we’ve already worked several large cases this year.

One of the things we discussed internally when analyzing the data from 2008 was how useful the “% of records” statistics would be since it was so dominated by a few large breaches (the largest 4 or 5 breaches exceed 90% of all 285 million records). We thought about removing them. We thought about pulling them out and presenting them separately alongside the smaller yet more numerous breaches. In the end, we decided keep everything together and provide distributions, measures of central tendency, etc to describe the data set.

The breakdown of data types shown in Figure 29 of the report was not unexpected and probably not surprising to many. However, I have fielded a huge amount of questions and interest with respect to the discussion around PIN data. In retrospect, it would have been wise to call this out separately and we will do so in the next report. Attacks targeting this type of data were, without a doubt, one the defining developments in the world of cybercrime in 2008. Unfortunately, I feel we will be dealing with it for some time to come.