I'm going to sound like I'm harping on this issue, but the biggest challenge is education. Corporations first need to understand their exposure from disgruntled and/or naive employees. Then they need to carefully consider how to address the balance between ease of use and security. One size does not fit all, but that's typically where executives want to go. In the long run, it'll cost corporations in productivity if they keep the development staff under as tight of a rein as call center employees, for example.

Corporations also need to understand that security is a process, not a product, but products are an important part. Firewalls are the obvious example here. They're an invaluable component to the security plan, but don't stop there. Also, it's the wrong idea to create a task force that ends up just producing a 100 page document on what the security policies are and then decree that everyone must read and comply with it. It's good to have the policy for reference, but go the next step to get products in place and teach people how to make them part of their routine. And then also have a plan on how you revisit and decide if/when to replace those products as needed.

Based on your experiences, do you find proprietary software or open source software to be more secure?

I can't really objectively say, but I do tend to trust open source more. I'm not going to pretend that I've personally audited every line of the OSS projects I use, but it's comforting to know that I could. I think it's also in security's benefit that OSS is written by people who genuinely care about the project -- they care enough to donate their time in the vast majority of cases. Plus they're not under market based deadline to deliver before a competitor does. Both of these features reduce the risk that the developers will take shortcuts and be careless with their code.

On the other hand, OSS projects attract plenty of novice programmers who may not have learned how to write secure code yet. Plus there's no guarantee that just because experienced people could have audited the code, that they actually have. So we have to be careful not to just blindly trust the security of OSS.


My litmus test is to see how many people are credited in the README as contributing to the project. A large number means that many people have looked at the code, and hopefully their level of experience follows a bell curve so you've had plenty of experience involved. I don't instantly trust a project that has just a few contributors -- they could just be prolific, but undisciplined high school students.

What's your take on the full disclosure of vulnerabilities?

Before the DMCA, this was an easy answer: when you find a vulnerability first tell the vendor and give them a reasonable amount of time to respond. If they don't, then publish publicly. I won't go into a screed on the DMCA, but it is forcing honest people to avoid the upfront approach and the corresponding risk of legal action. As it is, a US citizen would need to either get a foreigner they trust to actually do the notifications for them, or else step a bit closer to the black hat hacker community to learn how to hide their tracks of communication so they can report it themselves. The basic strategy still applies -- it's just harder now.

What are your future plans? Any exciting new projects?