Interview with Jeff Williams

The Conference Guide for OWASP AppSec Research 2010 in Stockholm featured an exclusive interview I did with Jeff Williams, volunteer Chair of the OWASP Foundation.

Here it is online:

Will OWASP ever reach out to developers?

OWASP focuses on outreach in 2010, and with the prevalence of application security flaws I'd say that's a good focus. But how do we reach out? How should appsec professionals reach software developers?

Jeff: To say that software development groups don’t fully trust security people is an understatement. This isn’t too surprising, seeing how some appsec professionals parade security holes around to get budget for their application security programs. Frankly, most appsec programs are reactive verification programs, designed to find vulnerabilities after they are created.

This era of security separate from development has to end. Instead, we need to get integrated with software development teams and business organizations, working together to get security started much earlier in the software process.

The right way to reach out is to get in there and actually help. Help figure out the threat model, design security architecture, place security controls, and develop test cases. If you find a vulnerability after the application is complete, you failed. And if you’re only talking with other security people, you’re doing it wrong.

Application security and the word Trust

The word trust is often used in IT security. How would you say application security applies to the trust relationship between customers and vendors, or endusers and developers if you will?

Jeff: Today, most trust is blind – and quite frankly unwarranted. There’s just no way for users to know whether the software they’re using is even remotely trustworthy. I’ve talked many times about how this information asymmetry turns the software market into a “market for lemons.” The solution is visibility and transparency for application security, which is the reason why OWASP’s mission focuses on creating visibility.

The whole point of application security is to generate informed trust, where people make decisions about software based on a full and accurate understanding of the risks involved. To achieve this, OWASP is trying to bootstrap a new era of open security ecosystems and “security in sunshine.”

Do developers care about rugged software?

Joshua Corman, David Rice, and you released the Rugged Software Manifesto in February. Does it stick to software developers or is it just an appsec utopia? Do developers really care if their software is rugged or not?

Jeff: We’re trying to bring application security to developers in a way that doesn’t involve threats, coercion, or embarrassment. Recent efforts to try to make developers liable for software vulnerabilities will only result in keeping critical security information shadowed in darkness. The only way we will make progress in application security is by bringing together business people, software developers, and security people and getting them to work together.

Rugged gets all of those groups focused on security in a positive way. In the same way that the Agile movement resonates with developers worldwide who are fed up with the traditional waterfall approach to development, Rugged appeals to developers who want their code to be strong enough to trust.

Virtually all of the developers I meet do care about security, but they need an ecosystem that supports them to make it a reality.

Java rootkits and trusted developers

At Blackhat USA last year you presented the paper "Enterprise Java Rootkits -- Hardly Anyone Watches the Developers" (pdf). Are malicious or disgruntled developers really something we should care about? Who's responsible – the CSO, the CIO, the team leader, or?

Jeff: I’m mostly a “builder,” but occasionally when it’s really important, I reveal my “breaker” side. Malicious developers are literally a “movie plot” threat, but that doesn’t mean we shouldn’t think about it. I set out to figure out the likelihood and impact of the risk associated with malicious developers. It quickly became clear that the amount of damage was virtually unlimited – at least as bad as the worst vulnerability possible and probably quite a bit worse.

The likelihood is harder to calculate, but scary. Imagine you have 200 developers – what are the odds that one of them is disgruntled or in a difficult life situation. Then think about what it would cost to get one of them to betray your company. Then think about all the code you’re trusting – custom code, libraries, test cases, your tool chain, and more. All of those developers are running with full trust deep in your infrastructure.

The paper investigates lots of ways that a malicious developer might hide their attack and concludes that it is quite easy for relatively unskilled developers to do this. There are some very interesting techniques for hiding these attacks and even attacking whole sectors by Trojaning libraries.

So to answer your question, yes – we should care about this risk. There are some simple things we can do about it, but the point of the paper was to kick off research in this area so that we can start to figure out how to protect ourselves for the longterm.