Heads Up!

Well I haven’t posted anything here in quite a while, but I really do have a good excuse this time. Not the usual been busy with work, life, etc. Watch for a follow-up post in the near future discussing some of the stuff I have been busy working on. In the meantime, there are a couple of items I just wanted to throw up here to make everyone aware.

1. This Thursday, November 13, is the Chicago OWASP meeting. Scott Stender from iSec Partners will be presenting on Concurrency Attacks in Web Applications, and Thomas Ptacek from Matasano Security will be talking about The Seven Deadly Features of Web Applications. You can find all the details on the where, when, and who here. I plan on attending and hope to see everyone there.
2. The 8th Annual Workshop on Economics of Information Security recently put out their call for papers. Next year’s conference will be held at University College London. More details on the conference here and great resources on the topic of economics in information security can be found here.

Apologies for the link dumping. I will follow this up very soon with some more interesting news.

White List vs. Black List

Jeremiah Grossman posted an entry on his blog yesterday about why most WAF’s are not currently implemented in blocking mode. To steal from Jeremiah who borrows from Dan Geer,

“When you know nothing, permit-all is the only option. When you know something, default-permit is what you can and should do. When you know everything, default-deny becomes possible, and only then.”

I think both Jeremiah and Dr. Dan are right on with their analysis. In fact, I would take this a step further and say this is ultimately how developers end up deciding whether to use a black list or white list approach when doing things like input validation. If you cannot fully document and articulate EVERYTHING about your site(s), it becomes impossible to create a valid whitelist. While knowing and understanding the majority of your site allows you to create a fairly effective black list, and of course, if you know nothing about your site you must allow all and pray.

To read a much more in-depth explanation of how this plays out in security, check out Dr. Dan Geer’s book. He delves into one of this blog’s favorite topics, the economics of information security and the trade-offs associated with it. Happy Reading!

Two Places You Need To Be

Register for both now. Hope to see you soon.

1. The Front Range OWASP Conference
2. The Workshop on the Economics of Information Security – 2008

More on Security Economics

The European Network and Information Security Agency has released a study open for comment on the economic barriers to information Security found here.

To quote ENISA, The principal objectives of the report are:

 

• To identify existing economic barriers for addressing Network and Information Security (NIS) issues in a single, open and competitive Internal Market for e-communication;
• To assess these barriers’ potential impact on the smooth functioning of the Internal Market for e-communication;
• To identify and analyse incentives (regulatory, non-regulatory, technical, educational, etc.) for lifting these barriers identified to cause distortion of the smooth functioning of the Internal Market for e-communication;
• To provide a range of recommendations to relevant actors (decision-makers both at EU and national level, industry, academia, etc.) for policy options, possible follow-up actions and initiatives.

Luminary Economics?

 There is a  good interview with Bruce Schneier over at the Freakonomics blog. I am just getting through it, but here are a couple of Q&A excerpts that I tend to get a lot and completely agree with the answer given:

“Q: So seriously, do you shop on Amazon, or anywhere else online for that matter?     

 A: Of course. I shop online all the time; it’s far easier than going to a store, or even calling a mail-order phone number, if I know exactly what I want.What you’re really asking me is about the security. No one steals credit card numbers one-by-one, by eavesdropping on the Internet connection. They’re all stolen in blocks of a million by hacking the back-end database. It doesn’t matter if you bought something over the Internet, by phone, by mail, or in person — you’re equally vulnerable.” 

I cannot stress this enough! It doesn’t matter whether your purchases are online or offline, in reality they’re all online. All of our transactions go through computer systems, are stored in large databases and are transmitted over networks. Look at the large security breaches in the news, many of them are ‘offline’ purchases. 

“Q: What was the one defining moment in your life that you knew you wanted to dedicate your life to computer security and cryptography?          

A: I don’t know. Security is primarily a way of looking at the world, and I’ve always looked at the world that way. As a child, I always noticed security systems — in retail stores, in banks, in office buildings — and how to defeat them. I remember accompanying my mother to the voting booth, and noticing ways to break the security. So it’s less of a defining moment and more of a slow process.”

 Security is a way of thinking. When interviewing candidates for information security roles, one of the things I look for beyond learned skills is how they think about problems. Specifically, a ‘security person’ thinks of different ways to break things. They think of ways to deconstruct the system and make it perform actions it was never intended to perform.

  

WEIS Call for Papers – 2008

The Workshop on the Economics of Information Security just opened up it’s call for papers for 2008. This year it will be held at Dartmouth College in New Hampshire.

I have written about this workshop in the past (here, here and here). The amount of quality content that comes out of this is incredible. As most readers of this blog know, information security is much greater than a technical issue. This workshop addresses many of those problems including the economic incentives of security and privacy, the various trade-offs individuals and groups must make to achieve a level of security, addressing negative externalities, the psychology of security and more.

If you have an interest in the driving factors of what makes many of our systems more or less secure, I would highly recommend this workshop. Last year’s workshop generated a tremendous amount of buzz about WabiSabiLabi. The online vulnerability marketplace for selling and purchasing vulnerabilities.

I would recommend reading Economics of Information Security as a great primer / introduction to the topics related to the workshop. You can find a link to it on the bookshelf of this site. It contains several papers that came directly from it. This is a great way to dig yourself out of some of the day to day technical details and start thinking about some of the more broad decision factors around security and privacy. While many of the papers come from academia, the information is a great way for those leading security programs in the private sector to understand the decision criteria that ultimately will fund or not fund their initiatives.

Recent Readings (and listenings)

I recently finished two books (OK one of them was audio), The Long Tail: Why the Future of Business is Selling More by Chris Anderson and Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks by Michael Zalewski. While they are both very different, they were both good reads and very appropriate topics for this blog. I would recommend both to regular readers here.

Ever since I finished the long tail a couple of weeks ago, I had been meaning to post on it and what it means to information security. Well while I was busy with other things a couple of people went it did just that. Over the weekend Mark Curphey wrote a 2 part post which sums up the book and how it relates to our field at a high level. Part 1 is here and Part 2 is here. I encourage you to read his posts if you have an interest in the economics of information security.

Another area that came to mind while reading this book (sorry, listening to this book) was the ever present topic these days of compliance. Organizations today have a number of regulations and laws that they must comply with in a given industry or geographic region. Some of these requirements make economic sense for the business, others are their to control the negative externalities of security. After reading (argh! LISTENING) to The Long Tail, I spent some time wondering how could a set of tools, processes, etc. make compliance economically sound and a choice organizations would make regardless of outside requirements (laws, regulations, etc).

I would like to challenge readers of this post to come up with some new ideas that would make these requirements that traditionally go against the rules of risk management and make them more sound for YOUR organization. The key here is every organization is different. What may make economic sense within mine, makes little to no sense in yours. That’s what makes the “one size fits all” approach of several regulations difficult on most companies today.

Have an idea? Post it here in a comment or send me an email!

Vulnerability Markets

There has been a lot of talk lately regarding both a paper that was presented at the Workshop on the Economics of Information Security (WEIS) last month entitled The Legitimate Vulnerability Market as well as the launch of a new online vulnerability auction marketplace, WabiSabiLabi. In fact, WabiSabiLabi is now being covered in mainstream media such as Forbes.

While some of these marketplaces are newly available, the practice of paying for vulnerabilities (or exploits) is certainly not. Several vendors such as Tipping Point, iDefense and even Netscape have either offered money for these in the past or have programs setup to purchase vulnerabilities from researchers. Many have made claims that they have even sold these to the U.S. government.

Much of the recent debate has been around ethics, very similar to the full disclosure discourse over the past several years. In the Forbes article, one interviewee speculates that black hats will always pay more for a vulnerability. While this may be true, again – this is nothing new. Vulnerabilities and exploits have always been sold to people with less than good intentions. What these new markets bring is an opportunity and forum for legitimate security researchers to be paid for their work while practicing responsible disclosure. An online vulnerability market can give the researcher the ability to understand more about the buyer, where they are coming from and their intention. It can also encourage legitimate vulnerability research. The more bugs that are found, ultimately will lead to more bugs fixed or not introduced at all. It provides incentives that simply weren’t there before and a way to adjust for a negative security externality.

There are several issues within a vulnerability market that need to be addressed in order for it to work effectively and establish a fair value for these vulnerabilities, but IMHO this is not an ethical debate. Within Charlie Miller’s paper, he discusses the inherent obstacles of this type of market. They include; Vulnerability information as a time sensitive commodity, Transparency in pricing, Finding buyers and sellers, Legitimate buyers, Demonstrating vulnerability value, Ensuring claim to vulnerability, and exclusivity of rights.

I encourage everyone to read the paper available on the WEIS site. If these markets are able to overcome the barriers and become successful, this will ultimately make our software more secure, not less.

Addressing Externalities with PCI

This is part 1 of a multi-part series on the effectiveness of PCI compliance on addressing security externalities.

A purely economical definition of an externaility is “a cost or a benefit arising from an activity that affects people other than those who decide the scale of the activity“. In computing, there are often unintended security costs that affect those that are not involved in the decision making progress. A good example of an externality in application security would be the shrinking of time it takes to go from prototype to production in recent web application development. Programming languages used to force developers to think about things like input validation and defining what is legal input. As 4GL languages and later web application development came about, the languages no longer required programmers to define input up-front. This (albeit minor) along with many other enhancements shrunk development time dramatically. The obvious externality here is a lack of security born by the users of the application built.

Within information security, there have traditionally been two ways of offsetting externalities – regulation and liability. In this series I will try and cover the PCI DSS, and in my very humble opinion, how effective it is in dealing with security externalities.

PCI DSS (Payment Card Industry Data Security Standard) is regulated by the various credit card associations and is meant to protect card holder data. It is made up of 12 high level objectives within 6 different areas of security.

Section 1: Build and Maintain a Secure Network

This section is made up of 2 high level objectives around network security and access. Given that network security is probably the most mature space within electronic security, this section is likely the least controversial. That being said, the devil remains in the details. One consistent issue with most security regulations is a tendency in getting to deep into the implementation of controls. Given broad diverse audiences, this is not an effective approach. I have often said the best regulations will state objectives that must be met and let the participating organizations define how they meet those objections. It is then up to an ‘independent’ third party arbitrator to determine if indeed those objectives are being met.

While part 1 is primarily a no-brainer, the PCI council still murks the waters a bit by adding redundant requirements and attempting to dictate control activities at times. Take the following 2 requirements:

1.1.6 Justification and documentation for any available protocols besides hypertext transfer protocol (HTTP), and secure sockets layer (SSL), secure shell (SSH), and virtual private network (VPN)

1.1.7 Justification and documentation for any risky protocols allowed (for example, file transfer protocol (FTP), which includes reason for use of protocol and security features implemented

Is there a difference between these? It appears the second requirement asks for security features implemented presumably to mitigate the issues with the risky protocol, but who defines risky protocol? I have to believe FTP isn’t the only one. And why don’t I have to justify HTTP, SSL, SSH and VPN? If there is no business need for those to be open, why shouldn’t I close them on the firewall?

Here’s another redundancy:

1.3.5 Restricting inbound and outbound traffic to that which is necessary for the cardholder data environment

1.3.7 Denying all other inbound and outbound traffic not specifically allowed

OK, so technically we’re now discussing the cardholder data environment, but shouldn’t this be the case for any and all environments?

Next up:

1.3.9 Installing personal firewall software on any mobile and employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.

Not a bad rule, too bad it doesn’t mean anything. A simple requirement to install software does not buy us any extra security. This requirement would be better off to stick with allowing justified protocols that were covered in excess in earlier requirements. If a personal firewall is installed on a laptop but is configured to allow all, we’re not addressing the risk (but we are technically compliant with PCI).

Overall, nothing terribly controversial in section 1. Most organizations have been doing this stuff for a long time. To be clear, I think regulation is a good way to address externalities and it’s impossible to please everyone; I am just hoping we continue to refine this standard so it makes sense for all merchants and service providers. Stick to the objectives and avoid conflicts of interest.

Up next: Section 2

Economics of Information Security: Updated

Several blogs have beaten me to the punch on this, but Ross Anderson and Tyler Moore from the University of Cambridge Computer Laboratory have published an updated survey on the Economics of Information Security. You can find it here. You can find the presentation from the conference here.