Spire Security Viewpoint

Social Security Numbers don't have to be predicted - they are known

A few researchers have done some work in predicting Social Security Numbers. I haven't read the report yet, but am not sure how significant this news is. I think it is fairly common knowledge that there are geographic and time elements to social security numbers.

More importantly, we don't really have to predict SSNs, because they aren't secret. In a typical lifetime, over 150,000 people will have legitimate access to your SSN (my estimate). No need for predictions, it is just available information.

Treating SSNs as secrets is part of our ongoing identity crisis.

More:
A Modest Proposal to Eliminate the SSN Façade
Is the SSN a good identifier?
SSNs Re-Re-Re-Revisited

A Few "Favorite" Security Metrics - RSA 2009 Edition

I moderated a "Security Metrics Exchange" peer-to-peer roundtable at RSA 2009. Here is the abstract:

"Many metrics sessions never actually get to metrics. In this p2p, we will discuss real-world metrics in use. To participate, you must bring your own "Top 5" metrics and be ready to discuss their value proposition and use cases. We will interactively evaluate the metrics and everyone will leave with the group's list of the most useful metrics in today's enteprise security environments."

So, the goal was a simple one, and it is clear that there is no overarching structure to the metrics, but I think it is useful to see what metrics were top-of-mind at the session. Here are the ones we came up with (and discussed) during the session:

% of Managers that Certify User Roles

Number of Password Resets

Cost per Password Reset

Number of Failed Logins

Number of Stale Accounts

Dead but Active Accounts

Login Spoof Attempts

Avg Time to Provision

Number of Privileged User Accounts

Number of VPN Connections per Week

User Account Growth Rate

% Systems Patched {OS; Platform use}

% Bandwidth Change

Number of Viruses

Avg Time to Recover

Avg Vulns per Host

Number of Applications

Number of Ports Open

Number of Servers

Number of Desktops

% of Systems with AV Installed {turned on; up-to-date}

Number of Exploitable Vulns

% of Security-related Defects

Avg Time to Find Vulns

Incidents per Month

I am not a fan of some of these metrics, but they are interesting nonetheless. I hope to find time to analyze them further in the future.

A Minimalist View of Security

Day to day, the things we do as security professionals can be pretty complex. From a control perspective, it is fairly common to take a product category-like view and work from there. But nowadays, the security functions being performed have all been defined and anything "new" really is a flavor of something we've already done (this is why those of us who've been in the industry for awhile lament that everything's been done before).

The resulting maturity of the security market creates a situation where thinking in terms of product categories becomes increasingly difficult as any new category feels vaguely familiar and existing categories extend into adjacent territory. In short, we spend a lot of time getting better at what we are doing, adapting to new technology, and improving deployment options more than we are fundamentally changing the rules of the security game.

It may be useful to have a set of "atomic security functions" that act as building blocks so that all other solutions can be shown to be combinatorial or derivative of these functions. All of these functions are inline - between source consumer and target provider.

Here's a start:

1. Authenticate
   • source (e.g. user | machine | program | message)
   • destination
2. Filter
   • source (e.g. access control based on source identity)
   • destination
   • traffic characteristics (non-deterministic)
3. Obfuscate (e.g. encrypt, usually)
4. Validate (e.g. check integrity of program | data | content)
5. Monitor (I am not convinced this one belongs, but have included it given our propensity to monitor. I think in the end, this is really another form of filter.)

I am not convinced this list is complete for inline functionality, so please feel free to offer up your own. When you think about it, it can be surprisingly difficult to factor out what we think we know about security functions, especially in the face of existing mature product categories.

Things that confuse me, volume 1

Just felt compelled to document my ignorance in a handful of posts I read last night and this morning:

1. "IE Protected Mode, while not a true defendable security boundary" So what exactly is a true defendable security boundary, and why doesn't IE protected mode fit the bill? Are there other examples of truly defendable security boundaries out there?
2. "As security through obscurity does not exist" What's your password again? and your firewall configuration? And does security without obscurity exist?
3. "Shouldn’t the MBTA be suing the vendor who sold them the flawed system?" Hmmm, I don't know - is there such thing as a perfect (non-flawed) system?

Protection Rackets

Update: Clarified my question and point in second to last paragraph.

The Guardian had an article yesterday about how vulnerability auctions are essentially protection rackets and it is all bad for security:

This year computer users will be more exposed to cybercriminals than ever before. It's not just because online crime is so attractive to identity theft gangs but, ironically, because the computer security industry that is supposed to protect users has deteriorated - from one which shared everything about newly discovered weaknesses to what some within it now call a "protection racket".

...

"The security industry is fast becoming a protection racket. There's no other word for it," Henry says. "The tradition has always been for vendors to share information on vulnerabilities so we can all protect our customers. Now you've got hackers being given a so-called legitimate route of selling vulnerabilities to a single company who then protect their own.

People love certainty, even when the knowledge may increase the risk, which it does with broader disclosure. You see, the vulnerability already exists in your environment, so you have already accepted that risk. The only thing that changes the equation, then, is the threat side - and more people knowing about it equals greater threat, and therefore increased risk.

Mitigation techniques that are tied to specific knowledge of specific vulnerabilities (e.g. patches) are inherently flawed. The benefit is greatly outweighed by the cost, when you look at a) the proportional allocation of resources across ALL vulnerabilities (including unidentified ones) in an environment, and b) the number of vulnerabilities that are actually exploited.

Ask yourself this question: why do would you think bugfinders are finding ALL of the exact same vulnerabilities that the bad guys are finding and using? There are so many vulnerabilities to choose from, the "collision" rate could easily be very low (and is low, according to security professionals who subscribe to the belief that the black hats are winning). In order to be sufficient, an explicit discovery strategy must find every vulnerability.

The industry must either increase vulnerability discovery by (probably) a factor of 10x or more to even attempt to catch up with every single vulnerability ever created and being created in real-time.... or come up with new methods for protection.

For further reading, see my original post on vulnerability auctions.

If Everyone in the U.S. has their SSN stolen...

... what is the impact on the overall risk of identity fraud?

This occurred to me when I read a prediction that by the middle of this year this would be the case [at least I think that was the prediction, and I can't find it right now - please forward to me if you find it. thanks.]

I don't recall any discussion about this, and I think it is trickier than it sounds. I inferred from the point that this was entirely "A Bad Thing" but that is not obvious to me. It seems like it would be in the best interest of anyone who has had their SSNs stolen to hope for more of the same, in an attempt to reduce their own risk of fraud (because there are more identities to choose from). Of course, this assumes that there is some satiating level for fraudulent activity.

I think the real question may be one of supply and demand - are there enough SSNs out there to meet the demand from buyers/perpetrators, or not? If yes, then the assumption holds and I think the overall risk reaches some sort of equilibrium point. If not, then everyone's risk may have slightly increased.

Update: Links to previous posts on this topic.

- Estimate the number of people with defendable access to your SSN here.

- Learn about why we should just publish all SSNs and get it over with here.

Has anyone seen my $180 billion recently?

(must have spent it on insecure software...)

Dark Reading: Insecure Software Costs US $180B per Year, according to David Rice in his book, Geekonomics. [Me: I wonder how he came up with that?]

Here's the nut graph from the Dark Reading article:

He estimates that the actual cost of insecure software to the U.S. is at least $180 billion per year, although he acknowledges that such numbers are "soft." He based his estimates on other numbers -- including a recent General Accounting Office report that says the U.S. cybercrime market is around $117 billion -- as well as other reports, such as estimates of worldwide phishing operations of $350 billion per year.

Here's the pertinent part of his book (p. 37):

In the case of software, the National Institute of Standards and Technology (NIST) the cost of inadequate software testing cost the United States roughly $60 billion, which is just under 1% of GDP. This cost does not account for other social costs associated with software usage such as cyber crime and related identity theft, however. A 2007 report by the Government Account [sic] Office (GAO) estimated cyber crime costs the U.S. economy approximately $117 billion a year.

Given that $117 and $60 make $177 ~ $180 billion, I am going to assume these are the sources the DR article (and other parts of the book) reference:

1. The NIST study in 2002, which was actually done under contract by RTI: Economic Impacts of Inadequate Infrastructure for Software Testing.
2. The $117 billion estimate, which actually comes from an article written about the GAO report in E-commerce Times: Cybercrime Costs US Economy at Least $117B Each Year. The GAO report itself is available as well: Cybercrime: Public and Private Entities Face Challenges in Addressing Cyber Threats.

Though I've been known to employ my own back-of-the-envelope estimates on occasion, I have a number of reservations about the approach employed by Geekonomics:

1. The RTI study employed interview techniques and included all faults, not just security-related ones. In addition, the estimate was actually a range from a "feasible" $23 billion to the $60 billion identified in the book.
2. The GAO report is all secondary research; it simply aggregates the information from other studies. The $117 billion amount was derived from 3 of the identified reports totaled together. One main source for the $117 billion ($67.2 billion) was the 2005 FBI Computer Crime Survey. This survey includes, for example, losses associated with laptop/PDA theft that were not caused by "insecure" software.
3. The second largest report cited by the GAO is an identity theft report that cites $49.3 billion in losses. Unfortunately, the full report costs $2500 so I could only work with press reports. In any case, to source identity theft of all types back to insecure software is a huge leap. In at least one account (the "consumer version") only 2% of the incidents are Internet-related.
4. Btw, I believe all of these numbers (certainly most of them) are for the U.S. only.

I don't know if this number is too high or too low, but I do know that this estimate doesn't get us any closer to knowing the true cost of insecure software.

Evaluating Password "Strength"

"sp" at OpenRCE has written  a very interesting analysis of the passwords chosen by about 45,000 MySpace users. Apparently, these passwords were found somewhere on the Internet, presumably the results of some sort of phishing attack. This analysis mirrors one done by Bruce Schneier for Wired about a year ago. It might be interesting to compare the two, however, it is more important to point out a huge flaw in both analyses - they purport to measure "strength" of passwords, and yet every single password in this instance is equally strong. That is, every password in this case is equally susceptible to inappropriate use, whether it happens to be "password" or "pqhw43n!#510,88CAap8neoxpo!$58".

Gulp! Is that a Naked Emperor I See?

In the midst of his riff on Amrit's anti-FUD lament, Alex at Risk Management Insight relates a story about an enterprise that installed a data leakage / content monitoring / extrusion prevention solution to evaluate data leakage throughout its organization. At the end of the trial, they made an important observation:

"If they were leaking all this data, where were all the incidents?"

The idea of "leakage" is a notion worth addressing in a world of mobile employees, outsourced business functions, and super-strategic partnerships where data is routinely shared across many traditional boundaries. It is pretty straightforward to identify a leak simply as a violation of policy - that is, sensitive data was shared when it shouldn't have been. Another type of leak is the nefarious one - when an employee is caught stealing information and transferring it to a competitor or using it for his/her own gain. The former is (anecdotally) the most common situation, but the latter is the most significant.

Alex continues his comments to discuss how frequency of incidents fit into the risk equation, and how these leakage events don't necessarily result in incidents where the information is used against the owner. (The parallel here with personal information is simply that loss of identity information doesn't necessarily lead to identity fraud.)

Of course, the notion of an incident and its corresponding loss function is trickier than is described here - while I don't subscribe to the whole mentality of massive, secret breaches HAPPENING RIGHT NOW EVERYWHERE!!!! and leading to significant losses WHILE WE REMAIN UNAWARE!!!! , it isn't hard to assert that some organizations are likely to be in this situation right now, and when that enterprise figures out that it has been breached, it will correlate its damage estimates with the duration of the breach (longer time, higher damages).

[Allow me to brainstorm briefly, because duration is an important point here - it may mean we'll need to differentiate between incidence and prevalence at some point in the future of information security.]

My point: Evidence matters. That is, we must continue to distinguish among the nature and types of incidents and corresponding losses. Policy violations may lead to losses like regulatory fines, but not necessarily abuse of data, which was the reason for the policy in the first place.

All of these issues, of course, point to the need for more quantitative, objective (oh, and causative) work being done to understand consequences in situations where "leakage" is the norm, not the exception. (Btw, DLP solutions are great for simply understanding the volume and usage patterns of sensitive data to get this information).

Update: Adam asks a great question in the comments. (Thanks for the links, Adam!). Here is an attempt at clarification:

As far as I can tell from reading the article, it makes precisely my (intended) point which I probably didn't make as well as I could have.

Let's see if I can clarify what I believe, and I haven't seen any data to refute these beliefs as of yet. (Nor have I seen great data that supports them, however):

1) There are undoubtedly lots of "leakage events" going on all the time. These are, by and large, occurring through "garden variety" policy abuse by employees and stolen laptops/PDAs; they are generally not malicious attacker events. Any of these cases might result in losses.

2) There is also much, much more information sharing going on that is considered legitimate by policy but also may end up resulting in losses.

3) Malicious attackers do not have a stronghold in every enterprise on the planet (unless you count employees as malicious attackers;-)). They are likely, however, to have compromised some relatively small proportion of organizations and these organizations don't know about it yet.

While I don't know this, I suspect a large (huge, really) portion of the "breaches" being reported in your article are of the policy abuse and stolen laptop situations. When I asserted my opinion above, I was talking about malicious attacker breaches of the TJX variety, though I wasn't clear in saying this.

In any case, the larger part of my post intended to suggest (and I believe Alex intended this as well) that even though leakage events occur frequently, it is not clear how much of this leakage is turned into losses like identity fraud, competitive market share, stolen customers, etc*. In addition, it is not even clear whether these leakage events create higher risk for an enterprise that is already sharing information in huge volumes.

* Note that the bulk of losses associated with these events revolve around notification, legal costs, and forensics analysis, and not around the losses mentioned previously.

Thresholds and Scale of Identity Fraud

A new study from ID Analytics provides evidence that you are better off being a victim of a large data breach (e.g. VA 26 millon records) than a small one (your alma mater):

Smaller breaches had a higher misuse rate than larger breaches. Misuse of personal data ranged from one in 200 identities for breaches of fewer than 5,000 individuals to a misuse rate of less than one in 10,000 identities for breaches of more than 100,000 individuals.

This is an assertion I made after the VA breach:

If this is true, then it is best for each individual involved to be one of many; the larger the number of SSNs stolen, the less likely any individual is to be a victim. So 26.5 million is better than, say, 5 and 300 million would be better still. (Obviously, the best case would be to not be in this group at all).

(more of my commentary on the VA incident.)