The New School of Information Security

The past 10 years have been the best in the country’s aviation history with 153 fatalities. That’s two deaths for every 100 million passengers on commercial flights, according to an Associated Press analysis of government accident data.

The improvement is remarkable. Just a decade earlier, at the time the safest, passengers were 10 times as likely to die when flying on an American plane. The risk of death was even greater during the start of the jet age, with 1,696 people dying — 133 out of every 100 million passengers — from 1962 to 1971. The figures exclude acts of terrorism.

…
There are a number of reasons for the improvements.

• The industry has learned from the past. New planes and engines are designed with prior mistakes in mind. Investigations of accidents have led to changes in procedures to ensure the same missteps don’t occur again.
• Better sharing of information. New databases allow pilots, airlines, plane manufactures and regulators to track incidents and near misses. Computers pick up subtle trends. For instance, a particular runway might have a higher rate of aborted landings when there is fog. Regulators noticing this could improve lighting and add more time between landings.

(“It’s never been safer to fly; deaths at record low“, AP, link to Seattle PI version.)

Well, it seems there’s nothing for information security to learn here. Move along.

Filed under: Doing it Differently, measurement, Science of Risk Management by adam on Wednesday, January 25, 2012
No Comments »

In the past, we have has some decidedly critical words for the Ponemon Institute reports, such as “A critique of Ponemon Institute methodology for “churn”” or “Another critique of Ponemon’s method for estimating ‘cost of data breach’“. And to be honest, I’d become sufficiently frustrated that I’d focused my time on other things.

So I’d like to now draw attention to a post by Patrick Florer, “Some Thoughts about PERT and other distributions“, in which he says:

What follows are the results of an attempt to answer this question using a small data set extracted from a Ponemon Institute report called “Compliance Cost Associated with the Storage of Unstructured Information”, sponsored by Novell and published in May, 2011. I selected this report because, starting on page 14, all of the raw data are presented in tabular format. As an aside, this is the first report I have come across that publishes the raw data – please take note, Verizon, if you are reading this!

So I simply wanted to offer kudos to the Ponemon Institute for doing this.

I haven’t yet had a chance to dig into the report, but felt that given our past critiques I should take note of a very positive step.

Filed under: best practice, compliance, measurement, Reports and Data by adam on Monday, January 23, 2012
No Comments »

There’s been a lot of noise of late because Oracle just released their latest round of patches and there are a total of 78 of them. There’s no doubt that that is a lot of patches. But in and of itself the number of patches is a terrible metric for how secure a product is. This is even more the case of companies that bundle all of their patches for all of their product lines at once. Most of the chatter I’ve seen, implies that all 78 are for the main Oracle database, but if you read their announcement, you’ll see the breakdown is as follows:

Oracle Database Server – 2 patches
Oracle Fusion Middleware – 11 patches
Oracle E-Business Suite – 3 patches
Oracle Supply Chain Products Suite – 1 patch
Oracle PeopleSoft – 6 patches
Oracle JD Edwards – 8 patches
Oracle Sun Products – 17 patches
Oracle Virtualization – 3 patches
Oracle MySQL – 27 patches

Fully 60% of the above patches are from OSS products. So which is more secure: open source or closed source. Or let’s compare Oracle DB vs MySQL: 2 versus 27 patches?

What do these numbers tell you? Absolutely nothing. Even with something like CVSS you still can’t tell which product is more secure. The whole thing is a load of malarkey. The product that is and will remain most secure is the one that you can manage and maintain the easiest for your organization.

Filed under: metrics by David Mortman on Thursday, January 19, 2012
1 Comment »

I am seeking feedback from others who may have experience developing and presenting security metrics to various stakeholders at their organization. I have a number of questions I’ve thought of, and put them into a simple survey form. I am  looking for any examples of the good, bad and ugly involved in developing meaningful metrics. What has worked well and what has failed miserably? How have you packaged and presented the results in a meaningful way to your executives?

If you can spare a few minutes, please consider taking this survey. Even if you answer one question, it is helpful!

https://docs.google.com/spreadsheet/viewform?formkey=dGhDLXZHQVB5eEZoSy03aU5JQnZxV2c6MQ

You may also simply share an example, graphics or slides via email. I will be using your feedback to facilitate peer discussions and in a presentation aimed at educating security professionals on how they can improve their security metrics program.

Thanks in advance,

John

Filed under: Uncategorized by alex on Monday, January 16, 2012
No Comments »

From an operations and security perspective, continuous deployment is either the best idea since sliced bread or the worst idea since organic spray pancakes in a can. It’s all of matter of execution. Continuos deployment is the logical extension of the Agile development methodology. Adam recently linked to an study that showed that a 25% increase in features lead to a 200% increase in code complexity, so by making change sets smaller we dramatically  decrease the complexity in each release. This translates to a much lower chance of failure.  Smaller change sets also mean that rolling back in the case of a failure state is also much easier. Finally, smaller change sets make identifying what broke unit and integration tests easier and far easier to code review which increases the chances of catching serious issues prior to deployment. All of this points to building systems that are more stable, more reliable, have less downtime and are easier to secure. This assumes, of course, that you are doing continuos deployment well.

In order for continuous deployment (and DevOps in general) to be successful there needs to be consistent process and automation. There are lots of other factors as well, such as qualified developers, proper monitoring, the right deployment tools but those are for another discussion.

Consistent processes are essential if you are to guarantee that the deployment happens the same way every time. To put it bluntly, when it comes to operations and security, variation is evil. Look to Gene Kim’s research (Visual Ops, Visual Ops Security) or more traditional manufacturing methodologies like Six-Sigma for a deep dive into why variation is so very very bad. The short version though is that in manufacturing, variation  means products you can’t sell. In IT, variation means downtime, performance issues, and security issues. At the most basic level, if you are making changes and you are making changes to how you make the changes, you create a much harder situation from which to troubleshoot. This translates to longer incident response times and longer times to recovery which nobody wants. Especially in an online business.

The easiest way to keep deployment process consistent is to remove the human element as much as possible. In other words, automate as much it as possible. This has the added advantage of saving the humans for reviewing errors and identifying potential issues faster. It doesn’t matter which automation mechanism you use as long as it’s stable and supports your operating environment well. Ideally, it will either be the same system as currently being used the by the operations and applications teams (e.g. chef, puppet, cfengine) or be one that can integrated with those systems (e.g. hudson/jenkins).

With good check-in/build release messages, you even get automated logging for your change management systems and updates to your configuration management database (CMDB).

Filed under: Cloud Security by David Mortman on Monday, January 16, 2012
4 Comments »

We’re honored to be nominated in three categories for the Security Bloggers Awards:

• Most Educational
• Most Entertaining
• Hall of Fame

On behalf of all of us who blog here, we’re honored by the nomination, and would like to ask for your vote.

We’d also like to urge you to vote for our friends at Securosis for “Best Representing the Security Industry.” We don’t think Securosis actually is the best representative of the industry today. But I think they represent what we all ought to aspire to be, a empirical, business-aware industry. So please consider them as a part of the broad “New School” sort of slate. We’d also like to put a word in for the ThreatPost podcast as a great mix of technical and non-technical content, and for Veracode for best corporate blog. We’re suggesting Veracode in large part for Chris Eng’s empirical and side-splittingly funny thought leadership videos, but also for a general avoidance of FUD in their blogging.

But whomever you like, please take a moment to vote.

Filed under: blogs & podcasts by adam on Thursday, January 12, 2012
No Comments »

This is a great video about how much of software engineering runs on folk knowledge about how software is built:

“Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True”

There’s a very strong New School tie here. We need to study what’s being done and how well it works to figure out how to make better software more reliably.

Incidentally, at around 28 minutes in, Wilson mentions Nachi Nagappan‘s work on physical distance versus managerial distance, and then jumps to remote hires at a a startup. While I’m not sure of which paper Wilson is discussing, almost all of Nagappan’s work is done with Microsoft developers and products. As such, both have to be seen in the context of Microsoft’s deep and shared experience in shipping software. By definition, that shared experience doesn’t exist at a startup. And as to the managerial distance issue, it’s satirically discussed here. Assuming that his results generalize is a large jump, and one that I’m not sure I’d make.

Filed under: blogs & podcasts, Data Analysis by adam on Wednesday, January 11, 2012
No Comments »

Adam Montville left a comment on my post, “Paper: The Security of Password Expiration“, and I wanted to expand on his question:

Passwords suck when they’re not properly cared for. We know this. Any other known form of
authentication we have is difficult because of the infrastructure required to pull it off. That
sucks too. Does this leave us at a stalemate where we need to get people to care about their
passwords?

I think the answer is “almost.” We need to agree that passwords suck when they’re not properly cared for, and that caring for them is hard. So we need to assume that passwords will tend to be poor, reused, etc, and develop methods to deal with that. Most of our mechanisms today punish users. We tell them to memorize 100 or more unique passwords, and then “security experts” abuse them for re-use or using a password management tool.

Cormac Herley has claimed that the password has a set of properties including being subject to memorization that make it impossible to replace, and we should accept that and start engineering for it. (“A Research Agenda Acknowledging the Persistence of Passwords” and “Passwords: If We’re So Smart Why Are We Still Using Them?“)

Similarly, Nate Lawson posted “On the evolving security of password schemes” which closes “most admins focus too much on increasing entropy of user choices and not enough on decreasing the attacker’s guess rate and implementing responses to limit their access when they do get a hit.” Indeed.

We need to observe the world, and ask how we can work within the constraints it presents regardless of if those constraints are economic, sociological or evolutionary.

Filed under: best practice, Doing it Differently by adam on Tuesday, January 10, 2012
1 Comment »

Via Nathan Yau’s awesome Flowing Data blog.

Filed under: Uncategorized by alex on Tuesday, January 10, 2012
1 Comment »

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.

Filed under: data, research papers by adam on Thursday, January 5, 2012
2 Comments »