Please nominate in the comments.

Also, please discuss what the criteria should be.

]]> http://newschoolsecurity.com/2012/02/time-for-an-award-for-best-data/feed/ 2 http://newschoolsecurity.com/2012/01/paper-the-security-of-password-expiration/ http://newschoolsecurity.com/2012/01/paper-the-security-of-password-expiration/#comments Thu, 05 Jan 2012 16:19:14 +0000 adam http://newschoolsecurity.com/?p=2433 The security of modern password expiration: an algorithmic framework and empirical analysis, by Yingian Zhang, Fabian Monrose and Michael Reiter. (ACM DOI link)

This paper presents the first large-scale study of the success of password expiration in meeting its intended purpose, namely revoking access to an account by an attacker who has captured the account’s password. Using a dataset of over 7700 accounts, we assess the extent to which passwords that users choose to replace expired ones pose an obstacle to the attacker’s continued access. We develop a framework by which an attacker can search for a user’s new password from an old one, and design an efficient algorithm to build an approximately optimal search strategy. We then use this strategy to measure the difficulty of breaking newly chosen passwords from old ones. We believe our study calls into question the merit of continuing the practice of password expiration.

This is the sort of work that we at the New School love. Take a best practice recommended by just about everyone for what seems like excellent reasons, and take notice of the fact that human beings are going to game your practice. Then get some actual data, and see how effective the practice is.

Unfortunately, we lack data on rates of compromise for organizations with different password change policies. So it’s hard to tell if password policies actually do any good, or which ones do good. However, we can guess that not making your default password “stratfor” is a good idea.

ACM gets a link because they allow you to post copies of your own papers, rather than inhibiting the progress of science by locking it all up.

Its December and so its the season for lists. Here is my list of Top 5 Security Influencers, this is the list with the people who have the biggest (good and/or bad) influence on your company and user’s security:

My list is slightly different:

1. The Person Coding Your App
2. Your DBA
3. Your Testers
4. Your Ops team
5. The person with the data
6. Uma Thurman
7. You

That’s right, without data to argue an effective case for investing in security, you have less influence than Uma Thurman. And even if you have more influence than her, if you want to be in the top 5, you better be the person bringing the data.

As long as we’re hiding everything that might allow us to judge comparative effectiveness, we’re going to continue making no progress.

Ahh, but which Uma?

Update: Chris Hoff asks “But WHICH Uma? Kill Bill Uma or Pulp Fiction Uma?” and sadly, I have to answer: The Truth About Cats and Dogs Uma. You remember. Silly romantic comedy where guy falls in love with radio veterinarian Janeane Garofalo, who’s embarrassed about her looks? And Uma plays her gorgeous but vapid neighbor? That’s the Uma with the more influence than you. The one who spends time trying to not be bubbly when her audition for a newscaster job leads off with “hundreds of people feared dead in a nuclear accident?” Yeah. That Uma. Because at least she’s nice to look at while going on about stuff no one cares about. But you know? If you show up with some chops and some useful data to back your claims, you can do better than that.

On the downside, you’re unlikely to ever be as influential as Kill Bill Uma. Because, you know, she has a sword, and a demonstrated willingness to slice the heads off of people who argue with her, and a don’t-care attitude about jail. It’s hard to top that for short term influence. Just ask the 3rd guy trying to code your app, and hoping it doesn’t crash. He’s got eyes for no one not carrying that sword.

]]> http://newschoolsecurity.com/2011/12/top-5-security-influencers-of-2011/feed/ 1 http://newschoolsecurity.com/2011/03/fixes-to-wysophal%e2%80%99s-application-security-debt-metric/ http://newschoolsecurity.com/2011/03/fixes-to-wysophal%e2%80%99s-application-security-debt-metric/#comments Sat, 05 Mar 2011 09:47:27 +0000 Russell http://newschoolsecurity.com/?p=2099 In two recent blog posts (here and here), Chris Wysopal (CTO of Veracode) proposed a metric called “Application Security Debt”.  I like the general idea, but I have found some problems in his method.  In this post, I suggest corrections that will be both more credible and more accurate, at least for half of the formula.  The second half is harder to do right and needs more thinking.

Overview

Application Security Debt is based on the concept of  “technical debt” proposed by Ward Cunningham (a programmer who developed the first wiki program): describes it like this:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Chris adds:

The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul.

Here is Chris’ summary of Application Security Debt:

Security debt is similar to technical debt. Both debts are design and implementation constructions that have negative aspects that aggregate over time and the code must be re-worked to get out of debt. Security debt is based on the latent vulnerabilities within an application. Application interest rates are the real world factors outside of the control of the software development team that lead to vulnerabilities having real cost. These factors include the cost of a security breach and attacker motivation to discover and exploit the latent vulnerabilities.

Chris’ second post describes a financial model that estimates the cost of Application Security Debt.  Framing the metric in financial terms will presumably help managers compare the cost of the “debt” to the cost of developing more secure software or costs of fixing the vulnerabilities.  (Note: Veracode provides a range of application security testing services, so they have an interest in economically justifying their services.  This isn’t a criticism of Veracode, Chris, or his proposal.  Just a reality.)

Chris’ model is focused on the simplest case where the application developer and application user is the same organization, so that it bears the costs of development, maintenance, and also any security breaches that result.  Starting with the simplest case is a great idea when proposing a new method.  So far so good.

Chris defines his financial model this way:

The basic financial model for security debt is monetary risk that can be expressed as expected loss. The formula for expected loss is event likelihood X impact in dollars. Event likelihood is based on the makeup of vulnerabilities in the application and the likelihood that the vulnerabilities will be discovered and exploited. The impact is the cost of a security breach based on an exploit of one of those vulnerabilities.  [Emphasis in original]

This is, of course, a version of the bottom-up Annualized Loss Expectancy (ALE) formula for individual risk elements:

• ALE = Single Loss Expectancy X Annual Rate of Occurrence

(Mike Rothman recently crapped on all “risk metrics” by lumping them all into the ALE formula.  I’ll critique ALE and Mike’s post in a separate blog post.)

ALE issues aside, I think Chris is making mistakes in his definition of Application Security Debt that will lead to serious confusion.

Debt = Expected Principal + Interest Costs

Chris made a mistake when he defines monetary value of the Application Security Debt as expected loss due to security breaches.    Instead, the ‘Principal’ part of the debt formula is the cost of fixing security problems beyond what is budgeted. Chris had it right in his summary in the first article:

The cost of technical debt is the time and money it will take to rewrite the poor code after you ship and bring it back to the quality required to maintain the software over the long haul.

Expected losses are in the category of “Interest Costs” as Chris said in his summary:

Application interest rates are the real world factors outside of the control of the software development team that lead to vulnerabilities having real cost.

Putting this together in simple language:

“Application Security Debt is a ‘loan’ with variable principal which could range from 0% to 100% of your original project costs. The ‘principal’ is what you’ll eventually have to pay to fix security bugs or rewrite the code.  It also has varying and uncertain ‘interest costs’, which are the costs of security breaches due to these vulnerabilities. This includes the possibility of the mother-of-all balloon payments (i.e. a huge loss event).”

The good news is that Expected Principal is relatively easy to estimate with good accuracy and without a lot of outside data.  The not-so-good-news is that Interest Cost is a bear to estimate.

Estimating ‘Expected Principal’

For simplicity, let’s assume that cost of fixing code (above the budgeted costs) occurs in discrete increments, F:

1. Zero  (i.e. your debt is ‘forgiven’)
2. Minor fixes and patches (‘Principal’ = 10% increase in project cost)
3. Major fixes and patches  (‘Principal’ = 25% increase in project cost)
4. Substantial rewrite (‘Principal’ = 50% increase in project cost)
5. Total rewrite   (‘Principal’ = 100% increase in project cost, or more)

Thus, the best case is that you owe no principal and the worst case is that you owe principal equal to the entire cost of the project.  You could include other factors such as external costs of schedule delays, costs of rehiring your programmers after you fire them all , or what ever.  My point is that these costs are not open-ended, but are a multiplier on your original development costs.

The Expected Principal (EP) is equal to each of these cost scenarios multiplied by their probability of management choosing that option:

For example, if the original cost of the application development project is $1 million, and there is 5% chance of Zero costs, 80% of Minor code fix costs, and 15% chance of Substantial rewrite costs, then the Expected Principal would be $155,000, or 16% of the original cost.

This is important: Expected Principal is ultimately determined by management decisions and ‘threshold of pain’.  This means that the value of p(F), above, is a subjective probability.  It would be an ideal metric to estimate using prediction markets (PMs).   (PMs have been used successfully in software development to estimate shipment dates and defect rates, for example.)

Another implication: you don’t need to accurately forecast future loss events or their economic impact to get a decent estimate of Expected Principal.  Instead, you only need to estimate the Interest Costs very roughly to determine which code fix scenario is most likely.    You could even estimate p(F) by setting thresholds for the number and severity of vulnerabilities discovered by certain levels of effort.  Better, you could combine these methods to ‘triangulate’ on estimates of p(F).

To calibrate these subjective probability estimates, it would be very helpful to collect historical data on the % of applications that have some level of rewrite or schedule delay due to security problems.  (Hint hint!)

Estimating ‘Interest Costs’ on the Debt will be Hard

The second part of the Application Security Debt formula is ‘Interest Costs’.  This is where things get hairy.   All the members of the ALE family of risk calculations have a similar flaws: 1) prodigious data requirements and 2) propagation of uncertainty through the calculations.  Furthermore, some suffer by using only mean values and ignoring extreme values (i.e. the “tails” of the probability distribution curves).

Chris acknowledges these issues, at least the requirement for more and better data:

Now you are probably thinking that this is getting a little tenuous and it is. We need better data on likelihood type and likelihood of an application breach by industry and other factors like company size.

Data issues aside, I think there are flaws in his use of ALE and calculation methods.  Here’s one thought experiment to show how it could lead to the wrong conclusions, in my opinion.

Let’s use Chris’ ‘baseline expected loss’ table, where he calculates the expected loss for each type of vulnerability.  Imagine that we are comparing two similar applications, A and B.  Assume that each project is expected to have the same number of vulnerabilities, five each.  Let’s say the development cost of each project is $1 million.  Application A has five SQL injection vulnerabilities while application B has one SQL Injection vulnerability and four Remote File Inclusion vulnerabilities.  Doing the calculations:

• A’s expected losses = $19,220,000
• B’s expected losses = $5,074,080

Does project A really have four times more risk than project B? Probably not.  From what I know, the number of vulnerabilities in an application is not proportional to the likelihood that the application will be breached.  Instead, I’d guess that the likelihood of being breached is a function of where the application is in the IT architecture, how accessible it is, how important it is to attackers, etc.

Also, there’s the ‘weakest link’ effect: “given enough random attackers or one persistent attacker, it only takes one vulnerability to lead to a breach”.  Assuming all SQL Injection vulnerabilities are equally discoverable and equally exploitable, then we should estimate that application B with one SQL Injection vulnerability is just as likely to get breached as application A with five, all other things being equal.

(I confess I’m not an expert in application security or vulnerability analysis, so these comments are my interpretation of what others have written or said.)

Even if my logic here is flawed somewhat, my main point is that the relation between number of vulnerabilities and likelihood of being breached is non-linear and it may even be indeterminate if contextual factors dominate.

This example also hints at another severe weakness in the ALE method – it ignores correlation and dependence between risk elements and factors.  We know from forensic analysis and the DBIR that severe security breaches involve a sequence of exploits and attacks.  This means that the likelihood of breach in one application is dependent on the likelihood of breach in other applications and systems.  An application might appear unimportant, but it might be a stepping-stone to other applications, databases, and networks.

It’s hard to account for all these factors and influences together without some sort of over-arching model for enterprise-level information security and risk.   Basically, you are looking for the ‘risk contribution’ of those specific application vulnerabilities to total costs, now and in the uncertain future.    Formally, the ‘Interest Cost’ for any given set of application vulnerabilities is the difference between the Total Cost of Security (TCoS) in two possible worlds: World 1) application A has X vulnerabilities, vs. World 2) application A does not have X vulnerabilities (or if application A is not deployed at all).

What we really need are some short-cut approximations for this that doesn’t require a complete data set and risk estimates for the whole enterprise.  One approach I’m interested is in using modern AI methods (data mining, machine learning, inference methods).  This is on-going research.

Summary

I’m glad Chris proposed his Application Security Debt metric.  I hope my post has been helpful in correcting some of the errors, as I see them.  The good news is that the “Expected Principal” component of the metric looks like it can be estimated fairly easily and with good accuracy.  On the other hand, the “Interest Cost” component needs a lot of work.  I’m happy to collaborate with Chris or anyone else who wants to work on this.

Here’s the website: www.nortoncybercrimeindex.com (all in FLASH)

Here’s a typical article:

Norton Cybercrime Index, unveiled today, rates the current state of cybercrime in a single, simple number and indicates whether the danger level is going up or down. Interested visitors can drill down for almost any level of detail. [...]

The index is open-ended, like the Dow Jones Industrial Average. Symantec’s proprietary algorithm draws on many sources to produce the index, among them the Symantec Global Intelligence Network, Norton Safe Web and the millions of customers using Norton 360 Version 4.0, Norton AntiVirus 2011, and Norton Internet Security 2011. To ensure the validity of the algorithm Symantec had it analyzed by experts at the University of Texas’s Institute for Cyber Security; the experts approved.

What’s the goal?  From the FAQ (embedded in FLASH):

Symantec created the Norton Cybercrime Index to show people that cybercrime is real, it can happen to anybody, and there is something you can do to protect yourself.

How is it calculated?

…using a statistical model and algorithm, which assigns values to the number of online threats observed each day.  Threats include malware, fraud, identity theft, spam, phishing, and social engineering trickery.  Once threats are quantified and processes through an algorithm, the Norton Cybercrime Index number is generated.  The algorithm has been endorsed by the University of Texas San Antonio as a valid measurement reflecting the risk of cybercrime.”

My initial judgement

It looks like it is purely a product of Symantec’s marketing department.  There’s a massive PR effort underway via blogs, twitter, public places (e.g. London, Times Square), and probably at the RSA Conference, now underway in San Francisco. The web advertising firm Fine Design Group created the FLASH UI, and tweeted about it first.

It will be interesting to probe their methods and data, assuming that Symantec will be transparent about the “proprietary algorithm” used to compute the index.  If they really want to establish credibility, it would be irrational to treat this as proprietary, confidential, and closed, for all the obvious reasons.  ID Analytics is listed as a data provider, but there’s no evidence that their ‘advanced analytics’ are used by Symantec, only their summary data regarding personal identity theft in the US.

I’d be very surprised if any of Symantec’s metrics experts are behind it.  I don’t know of anyone in the security metrics community who has been contacted or involved as an outside expert.  They certainly haven’t presented it for peer review at last Monday’s Mini-metricon (why not?) or to the securitymetrics.org email list (why not?) or any academic conference or journal (why not?).  Searching the University of Texas at San Antonio, Institute of Cyber Security’s web site, I couldn’t find any mention of their work on this project, nor any presentation or report.  A search of Google Scholar for “cyber crime index” produced a few results, but not related to this and not from anyone at UT-SA.

Q: Who did have an early look at this?  A: Angus Kidman, a blogger from Gizmodo.  And what did he learn from his demo?  From his blog post:

“On the day of the demo, these were the top search terms being targeted for poisoning:

• Invisible
• Camel toe
• Wifetube”

Right.  How very useful.  I’ll now modify my search patterns so I avoid those words today.

I don’t have  a good feeling about this

It smells like FUD in a spiffy FLASH interface. Sure, there probably is real data behind it, but it’s aggregated into an index that is supposed to mean something.  A daily index!  The FUD label fits because this presentation gives the illusion of scientific validity, precision, reliable aggregation, and meaningful signals, when that none of these are present (it appears). Using fancy words like “statistical method” and “algorithm” gives it the air of scientific validity without really saying anything.  Worse, those words hide the assumptions, judgments, fudge factors, and who-knows-what that make the index work.

My intuition about this is that Symantec marketing manager wanted to create a “daily itch” to get average people to read what ever news blips were available that day about ‘cybercrime’, which would increase the chances that they would move from ‘awareness’ to ‘action’ (= buy more Symantec stuff).  By getting this out as a daily index, any up or down moves each day will trigger some people to click the buttons to find out ‘why?’.   But this will take them to news items, but not any credible justification of why they might be at greater risk on that day, compared to the day before.

As a thought experiment, imagine a similar ‘Risk Index’ that is powered by astrology readings, numerological interpretations of Nostradamus’ texts, or some other daily signal source.  With the appropriate shroud of credibility, some number of people are going to start following it, and when ever it changes, they will seek information as to ‘what does this mean for me?’  It would serve have exactly the same function as their current design.  This doesn’t prove anything, but establishes in my mind some plausibility.

What’s the harm?

Some might argue that this is harmless or even mildly beneficial if it prompts people to be more aware of security problems and to fix their security problems.  But I think it’s harmful because it promotes a false signal and a false method for doing information security metrics — for consumers or for anyone else.

Maybe I’m wrong and this may be an important advance, or at least a step forward.   At very the least, it shows that one  major security product/service vendor spent money to define a method, collect data, and make public the results.  Prior to this, no major vendor was even spending money on it.

What to do now

Is there any way this Index could be redirected to be a more valuable and extensible project?  I hope so.  But for that to happen, those of us how care about the New School approach to security need to apply the full-court press on Symantec to open up their method and data.

Your action — contact Symantec, preferably in-person at RSA Conference, and demand they open up and also engage in the security metrics community in a serious way.  The burden of proof is on them, and if they can’t back it up then they should be shamed.

Sorry, dreaming there for a minute.

What Brian really did was go look at what attackers are doing in their commercial exploit kits, and discovered that Java exploits have surpassed Adobe exploits in ‘his’ sample.

I’m curious what you all think of the approach. What can we learn from attacker toolkits and marketing pitches? What are the limits of this?

]]> http://newschoolsecurity.com/2010/10/java-security-criminals/feed/ 1 http://newschoolsecurity.com/2010/10/fines-or-reporting/ http://newschoolsecurity.com/2010/10/fines-or-reporting/#comments Fri, 01 Oct 2010 15:40:36 +0000 adam http://newschoolsecurity.com/?p=1792 Over at the Office of Inadequate Security, Dissent does excellent work digging into several perspectives on Discover Card breaches: Discover’s reports, and the (apparent) silence of breached entities.

I’m concerned that for many of the breaches they report, we have never seen breach reports filed by the entities themselves nor media reports on the incidents. For now, though, let’s start with what I found when I received one batch of their reports to NYS. Keep in mind as you read the summaries that we are only talking about the number of Discover card users affected by the incidents and for only two states. The numbers affected by each incident could be considerably higher, but since the entities themselves never filed breach reports with NYS or Maine, I have no additional information at this time. (“Staring into the abyss: how many breaches go unreported?“)

As much as I’d like to encourage security and punish failures, I’d like to first see us know how much is wrong so we can estimate progress over time.

]]> http://newschoolsecurity.com/2010/10/fines-or-reporting/feed/ 0 http://newschoolsecurity.com/2010/09/attention-securosis-2010-data-security-survey-results/ http://newschoolsecurity.com/2010/09/attention-securosis-2010-data-security-survey-results/#comments Wed, 15 Sep 2010 17:10:31 +0000 alex http://newschoolsecurity.com/?p=1776 The Securosis 2010 Data Security Survey results are out! http://bit.ly/aR4MuY

Go, go and be NewSchool!  Seriously, don’t spend anymore time here, click the link!

Jim Tiller of British Telecom has published a blog post called “Risk Appetite, Counting Security Calories Won’t Help”. I’d like to discuss Jim’s blog post because I think it shows a difference in perspectives between our organizations. I’d also like to counter a few of the assertions he makes because I find these to be misunderstandings that are common in our industry.

“Anyone who knows me or has subjected themselves to my writings knows I have some uneasiness with today’s role of risk. It’s not the process, but more of how there is so much focus on risk as if it were a science – but it’s not. Not even close.”

Let me begin my rebuttal by first arguing that risk management, at its basis, is at least ”scientific work”. What I mean by that is elegantly summed up by Eliezer Yudkowsky on the Less Wrong blog. To use Eliezer’s words, I’ll offer that scientific work is “the reporting of the likelihood ratios for any popular hypotheses.”

You should go read “Risk Appetite: Counting Risk Calories is All You Can Do“.

Rich is right that there’s currently no market, but that doesn’t mean there’s no demand. I think there are a couple of inhibitors to the market, but the key one is that transaction costs are kept high by a lack of data about outcomes. Every one of the startups selling you a product will claim that it blocks “APT” and “Data loss” but none of them have compelling data about efficacy. None of us have great, broad data about what problems lead to breaches, and none of us have data about what solutions products effectively prevent those problems. None of us have data about how often the products are deployed and managed effectively.

So when the salespeople come in with their “$204 per record” and compliance demands and all the rest, there’s no good way to distinguish between it, and as a result, the market is a slog for both real innovation and snake-oil.

If someone could innovate to address these problems, say by collecting and analyzing data about what really happens inside a company, they might have a business.

More broadly, for a market to function, there needs to be supply which exists in plenty, and demand, which exists, and a way to link them. And there’s the chasm.

I’ll also point out that we discussed innovation a bit on pages 126-127 of The New School, where we opine that much security needs to be integrated into your infrastructure and thus will be purchased from larger vendors.

]]> http://newschoolsecurity.com/2010/03/counterpoint-there-is-demand-for-security-innovation/feed/ 1