Archive for the 'Reports and Data' Category

Petroski on Engineering

As I was reading the (very enjoyable) “To Engineer is Human,” I was struck by this quote, in which Petroski first quotes Victorian-era engineer Robert Stephenson, and then comments:

…he hoped that all the casualties and accidents, which had occurred during their progress, would be noticed in revising the Paper; for nothing was so instructive to the younger Members of the Profession, as records of accidents in large works, and of the means employed in repairing the damage. A faithful account of those accidents, and of the means by which the consequences were met, was really more valuable than a description of the most successful works. The older Engineers derived their most useful store of experience from the observations of those casualties which had occurred to their own and to other works, and it was most important that they should be faithfully recorded in the archives of the Institution.

Today Robert Stephenson would likely express the same hope, mutatis mutandis, about the failure of computer programs and the measures that have been taken to protect them.

Now, Petroski is talking about failures of computers in engineering, rather than the engineering of computers. But I think there’s little doubt that he’d say that the same applies to the engineering of computers. Both the chapter “The limits of design” and the new afterword are worth reading with an eye to what they can teach us about information security and disclosure. Actually, the entire book is worth reading, but the analogies are strongest there.

The Visual Display of Quantitative Information

In Verizon’s post, “A Comparison of [Verizon's] DBIR with UK breach report,” we see:

pie-charts-suck.jpg

Quick: which is larger, the grey slice on top, or the grey slice on the bottom? And ought grey be used for “sophisticated” or “moderate”?


I’m confident that both organizations are focused on accurate reporting. I am optimistic that this small example in the utlity of pie charts will inform report writers. The report writers and their graphics departments, loving their customers, will move to bar charts to help them compare numbers between sources.

I’m confident that not using pie charts is a best practice.

Elsewhere: “The only time it makes sense to use a pie chart.”

And elsewhere: “The Visual Display of Quantitative Information, 2nd edition

Comments on the Verizon DBIR Supplemental Report

On December 9th, Verizon released a supplement to their 2009 Data Breach Investigations Report. One might optimistically think of this as volume 2, #2 in the series.

A good deal of praise has already been forthcoming, and I’m generally impressed with the report, and very glad it’s available and free. But in this post, I’m going to offer up a stack of criticism. This isn’t intended to detract from the report, but to encourage and improve it.

My biggest request is to focus more on the “requests for additional recommendations for deterring, preventing and detecting breaches,” which is the fourth common theme. In particular, each of the elements of the threat action catalog has what appears to be a grab-bag of mitigators. The first threat action, “keyloggers and spyware” has a dozen. (I’d make it a baker’s dozen by splitting host IDS and integrity monitoring.) How these are selected is unclear. How each was tested for validity is unclear. The relative costs of each is not assessed. I would urge the authors to include a table of all mitigators, showing how often each is present, which types of threat actions they expect it would impact, and an estimate of cost or relative cost. (A preventative mitigator present at over 50% of incidents should likely be removed from the list.)

In fact, on page 22, a list of lessons learned is presented. That breakdown would be an provocative top row of a table of mitigators.

My next large request is to break out threat actions better. Figure 2 is hard to read, as it combines threat categories which Verizon calls Malware, Hacking and misuse, and I’d characterize as gaining access and using that access. Perhaps that should include expanding access, but two small tables would be easier to read, as would the same sort applied to the data in the break-out.

Some other places where I raised my eyebrows:

  • Page 2 discloses that non-essential details have been altered. That’s an interesting choice of words, especially noting how carefully other words are chosen. (For example, page 26, “We find this interesting” versus “We find this fascinating.”)
  • Page 7, “Ubiquitous but particularly common …” would imply either not really ubiquitous in other industries.
  • Page 8, “non-sanctioned commercial remote desktop program.” Was a sanctioning process available? Was work at home a supported scenario? Was there software to support that scenario that was sanctioned? I ask because of the implicit judgement of the researcher who installed the software, and a guess that the blame may reasonably be placed on the IT department.
  • Page 15 “We very often see [unauthorized access]” but it’s listed as 8% of breaches and 1% of records compromised. Which is a … provocative … definition of very often. (The same idiom is used with similar numbers on page 19.)

The comparisons between the DLDB and the Verizon database are, to borrow a word, fascinating.

None of this is intended to detract from the report, which is worth reading and comparing to your control set. How’s your coverage on what they believe would be effective?

NotObvious On Heartland

I posted this also to the securitymetrics.org mailing list.  Sorry if discussing in multiple  venues ticks you off.

The Not Obvious blog has an interesting write up on the Heartland Breach and impact.  From the blog post:

“Heartland has had to pay other fines to Visa and MasterCard, but the total of $12.6 million they have set aside to handle the one-time costs is a drop in the bucket compared $1.5 billion in 2008 revenue and does not really even skim much off the top of the $161 million in profits from that same year (the numbers for 2009 look to be tracking the same). It is almost a guarantee that any member of the class action who submits a claim will see many years of scrutiny before receiving any payment, something which Heartland can factor into their yearly financial plans (and accommodate for by increasing fees).”

For thought:

  1. One wonders how much a “sufficient” (loaded term, of course) InfoSec program for a company like Heartland costs on an annual basis.
  2. Does this set a sort of “worst case” bounds to impact distributions?
  3. If so, how does a worst case impact of ~$13million (US) impact security management at retailers (politically)?

NEW: Verizon 2009 DBIR Supplement

verizon DBIR sup

Full report is here.  A quick overview from a Wired magazine article:

The supplement provides case studies, involving anonymous Verizon clients, that detail some of the tools and methods hackers used to compromise the more than 285 million sensitive records that were breached in 90 forensic cases Verizon handled last year.

[Disclosure: Alex's paw prints are on this report somewhere.]

Sweden: An Interesting Demographic Case Study In Internet Fraud

saab-900(quietly, wistfully singing “Yesterday” by the Beatles)

From my favorite Swedish Infosec Blog, Crowmoor.se. I don’t speak Swedish, so I couldn’t really read the fine article they linked to.  Do go read their blog post, I’ll wait here.

Back?  Great.  Here are my thoughts on those numbers:

SWEDISH FRAUD STATISTICS RELEASED

The World Bank estimates the population of Sweden to be 9,220,986 - 2008

For Reference, London (2006 figures) was 7.5 million, New York City was 8.275 million in 2007

So the Swedish “market” for fraud was around 60,000 people out of a total population of 9,000,000 suffering an average  of  €1050-1100 each.  This line of thinking draws the inevitable comparison to what VC call The Chinese Soft Drink Argument (If we can just get each person from China to buy one drink, we’ll make a billion!), obviously, but I thought it was interesting to put this into context.

When I saw those numbers, I thought of a couple of other stats I’d like to have at hand:

Break down of types of “attacks” that resulted in fraud (was the attack primarily hacking, was their SE involved, was it phishing, etc.), estimated number of attack attempts, number of arrests, demographics around Internet banking and broadband penetration…

What other information do you think would be helpful to you as a practitioner?

obligatory Swedish Chef reference:

Engineers vs. Scammers

Adam recently sent me a link to a paper titled, “Understanding scam victims: seven principles for systems security.”  The paper examines a number of real-world (i.e. face-to-face) frauds and then extrapolates security principles which can be applied generically to both face-to-face and information or IT security problems.

By illustrating these principles with examples taken from the British television series The Real Hustle, they provide accessible examples of how reasonable, intelligent people can be manipulated into making extremely poor (for them) decisions and being defrauded as a result. Perhaps you’re thinking, “That’s all well and good, but what do I care about other people getting scammed due to behaviors that I would like to believe I would never engage in?”

It’s a nice idea, and while it may hold true with some of them, such as the Dishonesty Principle (“It’s illegal, that’s why you’re getting such a good deal.”), many of these scams work not because the person is trying to do something sneaky, because they’re either trying to “Do The Right Thing,” e.g. The Social Compliance Principle, just get the job done, such as the Distraction Principle, or just plain get fooled, e.g. the Deception Principle,

So, like it or not, the paper would seem to tell us, you’re Damned if You Do, Damned If You Don’t, and eventually you’ll let your guard down at just the wrong time. The sub-title of the paper might as well have been, “Why your security system will eventually fail, no matter how good it is.”

So what’s the point of trying?

Well, first off, because all hope is not lost—even if you don’t read the paper, there are a number of points to consider, two of which I want to call out because they are essential to designing or analyzing a security system (or, really, a system which requires a degree of security):

• Identify the cases where the security of your system depends on an authentication task (of known people, of unknown people or of “objects”, including cash machines and web sites) performed by humans.

• Understand and acknowledge that users are very good at recognizing known people but easily deceived when asked to “authenticate”, in the widest sense of the word, “objects” or unknown people.

By understanding how and why systems fail, we can design them in such a manner as to avoid the failure. For example, never forget that authentication is really a two-way street, even most people are generally bad (at best) and oblivious (in general) to their role in the problem.

In the case of an ATM, the traditional security efforts are around protecting the ATM from malicious users. The fact that the users must also be protected from malicious ATM’s never seems to come up. Likewise, phishing and other forms of credential harvesting depend on the victim being unable to accurately authenticate the requester of their credentials, whether due to falling prey to Distraction, Deception, or Social Compliance.

By understanding this and explicitly forcing that problem to be considered “in-scope” by the system designers, we accomplish two important security goals. First, we address the fact that authentication is a two-way street, even if only it only a formal process (e.g. logging in) in one direction. Second, we expand the pool of people working on solving the problem and thus potentially creating a valuable innovation which can be applied across that problem elsewhere.

What we can’t do is take the easy way out and “blame the users.” In fact, the authors even close their paper by reminding us of this fact:

Our message for the system security architect is that it is naïve and pointless just to lay the blame on the users and whinge that “the system I designed would be secure if only users were less gullible”; instead, the successful security designer seeking a robust solution will acknowledge the existence of these vulnerabilities as an unavoidable consequence of human nature and will actively build safeguards that prevent their exploitation.

While Adam, Alex and I were discussing the paper, Adam took the bold step of declaring that,

The principles that tell an engineer what to do are better than those that tell a scammer what to do.

Personally, I’m going to confess that while I don’t disagree with his statement, I don’t think it matters, either. Engineering principles can help us make better decisions and design better systems, but unfortunately, they don’t let us make perfect decisions or design perfect solutions. Fortunately, even if they did we’d still have innovation elsewhere to create new and interesting problems which people would employ us to solve.

Regardless, there will always be an interplay of innovation and reaction on both sides of the equation—for scammers or attackers and for security engineers or defenders*. The attackers find a hole, the defenders find a way to close it or render it ineffective. So the attackers find a new hole, ad infinitum. The hole can be a weakness in an IT system, a business process, or, as is the case in many of the examples in Part One, the human brain.

Here’s where it gets tricky, though. Most defenders work for Someone Else. By that, I mean that they are employees of, either directly or by contract, of some other entity who is in the business of Getting Something Done. The entity is typically not in the business of Securing Things. Thus, the Distraction Principle is already working against us before we ever even get to work in the morning.

Next, once the asset is not something obviously valuable, such as money, people’s ability to recognize it as such fails rapidly, especially when they interact with it on a day-to-day basis. This is especially true when trying to protect trade secrets and other Intellectual Assets. I have been in meetings where Very Senior people were asked to identify the critical secrets in their branch of the organization and they were unable to do so. It’s not that they didn’t have any, it’s that they couldn’t pick them out of the crowd of their responsibilities because everyone they dealt with was also authorized to see them, so they had no recurring reminder or other filtering mechanism.  This is one of the reasons that Top Secret documents are stamped “Top Secret.”

In the examples from the paper, scammers utilize the opposite form of this problem in their principle of Deception, by convincing people that valueless things are actually, in fact, valuable—fake diamond rings, TV boxes with rocks in them, etc. In the corporate world, people don’t know, understand or remember what’s valuable, and thus are unable to properly prioritize protecting it among their other responsibilities (the Distraction Principle again).

Thus, I would argue that the issue is that people are just bad at accurately assessing value; that their ability to do so degrades over time; and that their ability is further weakened when scammers manipulate them.  Call it the Valuation Principle. This, in turn, makes them more vulnerable to a variety of ways of losing their valuables, be it cash, a car, or a Trade Secret, by application of the other Principles in the paper.

The challenge is that while it’s irrational to protect everything if only a small portion of the assets need the highest level of protection, most people (and thus, their organizations) are really bad at determining what level of security an asset actually requires (even with tools like classification and risk assessment).  Cost-effective Information Protection is as much about determining what to protect as ensuring that it’s protected.

* I assign these roles under the assumption that the defender holds an asset that an attacker wants to access or possess.

Chris Soghoian’s Surveillance Metrics

I also posted about this on Emergent Chaos, but since our readership doesn’t fully overlap, I’m commenting on it here as well.

Chis Soghoian, has just posted some of his new research into government electronic surveillance here in the US. The numbers are truly astounding (Sprint for instance provided geo-location data on customers eight million times in thirteen months).

There’s lots of great data on what’s being collected versus what’s being reported as collected. I know you’ll all be shocked to know that surveillance is dramatically under reported. It’s all very very interesting. Check it out.

Rational Ignorance: The Users’ view of security

Cormac Herley at Microsoft Research has done us all a favor and released a paper So Long, And No Thanks for the Externalities:  The Rational Rejection of Security Advice by Users which opens its abstract with:

It is often suggested that users are hopelessly lazy and unmotivated on security questions. They chose weak passwords, ignore security warnings, and are oblivious to certi cates errors. We argue that users’ rejection of the security advice they receive is entirely rational from an economic perspective.

And you know it’s going to be good when they write:

Thus we find that most security advice simply offers a poor cost-benefit tradeoff to users and is rejected.  Security advice is a daily burden, applied to the whole population, while an upper bound on the benefit is the harm suffered by the fraction that become victims annually.  When that fraction is small, designing security advice that is beneficial is very hard.  For example, it makes little sense to burden all users with a daily task to spare 0.01% of them a modest annual pain.

People are not stupid.  They make what we, as relative experts on the topic of security, perceive to be bad decisions, but this paper argues that their behavior is rational.

[W]e argue for a third view, which is that users’ rejection of the security advice they receive is entirely rational from an economic viewpoint.  The advice o ers to shield them from the direct costs of attacks, but burdens them with increased indirect costs, or externalities. Since the direct costs are generally small relative to the indirect ones they reject this bargain. Since victimization is rare, and imposes a one-time cost, while security advice applies to everyone and is an ongoing cost, the burden ends up being larger than that caused by the ill it addresses.

The paper provides both a good and accessible overview of externalities and rational behavior using spam as an example.

For example, Kanich et al. [32] document a campaign of 350 million spam messages sent for $2731 worth of sales made. If 1% of the spam made it into in-boxes, and each message in an inbox absorbed 2 seconds of the recipient’s time this represents 1944 hours of user
time wasted, or $28188 at twice the US minimum wage of $7.25 per hour.

Coincidentally, we get a little over 300 million spam messages into our corporate email gateways every month, which means that I can compare the cost-per-delete-click (at $7.25/hour) against the cost of our corporate spam filtering contract without having to do any real math.  Since we pay about $50,000/month for filtering.  That means that we’re getting a pretty good deal, since our white-collar employees cost over $14/hour.

That’s just time that would be spent seeing and deleting the message, don’t forget.  Fourteen Dollars per hour completely ignores the cost of attention disruption (much more than two seconds) and the Direct Losses, either because I cannot quantify, which causes the entire argument to appear specious in the eyes of  Senior Leadership, or I am not at liberty to disclose enough detail to pass the “cannot quantify” test.

They then go on to document in fairly accessible models why password complexity, anti-phishing awareness, and SSL Errors are cost-inefficient, and get into a favorite topic of mine, the difficulty of defining security losses or the benefit from adding safeguards at the end-user level.  This section should be mandatory reading for any security person who attempts to talk to non-security people about the topic–i.e. all of us.

What’s missing from the paper, though, is the next logical step of analysis, the appropriate Risk Management strategy in response to the information presented. Hopefully that will be the follow-on paper, because as it was, it felt like a bit of a cliff-hanger to me.  All of the discussion assumes that mitigation is the only option.  This may feel right from a Security perspective, but it’s probably not the correct risk management decision.

To manage the risk in these cases, though, I see a strong argument for risk transfer.  High-Impact, Low-Likelihood events are best managed by aggregating the risk into a pool and spreading the cost across the pool, i.e. buying insurance against these losses.  If you could buy anti-phishing insurance for $1/person/year (which, realistically, is multiples of what it could cost if 200 million people all bought in) rather than throwing large, uncoordinated piles of money at ineffective awareness training or technical countermeasures which will probably be out-innovated by the attackers in hours or days, why wouldn’t you?

Why have anti-virus vendors not thought of this?  If your AV vendor said they would also insure you against Direct Losses (having your bank account cleaned out) for your $50/year subscription, would that differentiate them enough to win your business?

By all means, we should continue to work on the challenges of improving the security experience and reducing the risk of using computers.  More accurately, though, we should be reducing the amount that must be experienced by users at all to improve security of their information and transactions.

Questions about Schaeffer’s 80% improvement

According to Kim Zetter at Wired, in Senate testimony, Richard Schaeffer, the information assurance director at NSA, claimed that “If network administrators simply instituted proper configuration policies and conducted good network monitoring, about 80 percent of commonly known cyber attacks could be prevented.”

I’m trying to find if that’s the FDCC (Federal Desktop Core Configuration), SCAP, or something less crisply defined.

The hearings include a testimony link to a PDF, and the NSA.gov site has a version as well. I haven’t had a chance to watch the testimony as delivered.

Neither contain “80″ or “eighty.” Does someone know exactly what set of practices constitute “proper configuration policies and conducted good network monitoring,” and over what timeline and population they were measuring? Are there cost estimates for the activity suggested?