User:Jesse/Vegas2011/SecuringApplicationsAtScale

Panel title: "Trillions of Lines of Code and Counting: Securing Applications at Scale"

Panel participants

0. Moderator. Likes to argue "It IS possible to create secure applications" but feels like data is proving him wrong.

From left to right:

1. Deere guy.

2. Former Verizon data-breach-report guy (incident-focused)

3. Jeremiah Grossman, focused on web security

4. Adobe / former antivirus guy

What's your agenda?

[2] Incidents of magnitude are often SQL injection

[3] "How do we make the next version of the web have fewer vulnerabilities?" - Jeremiah Grossman

[4] Corporate-wide strategy, especially for code they ship: Education, aligning incentives, measuring (in that order)

((So uh how do you fix your BUSINESS DECISION incentives? This is a problem for Microsoft too, IMO.))

[1] Manufacturing companies tend to be slow-moving. Lots of old code. We'd prefer the security budget to not be motivated by big incidents.

Education, training, awareness

[4] In-house computer-based training and certification. "White belt" through "Black belt" levels, which you can place on your internal profile, to make it fun. 20-40 minute chunks.

[2] "Education" is the wrong tack; think "Hacking" instead. Get developers in the "hacking" mindset. Adam Shostack's card game, even as a drinking game. Hack the developers' minds. Hack the accountants and executives to get buy-in.

[1] Get developers used to pushing out patches on a monthly cycle. Leverage reports from competitors and the security industry; outsource to companies that know security.

Tools

[3] 17 million software developers, most of whom have not had security training. We don't have enough trainers for these people. Need software-based training, tools for things you can automate or semi-automate, and management/priorities.

[1] Automation is important because it has scale, but you can't solve everything with tools?

[4] Mitigation is great. DEP, ASLR, sandboxing. Extra work or a harder step for attackers. But these mitigations have have up-front cost.

Motivation and incentives. Justification of security budget and effort.

[4] Security has the ear of the CEO, has a slide at the board meeting.

[2] We're failing at fending off targeted attacks.

[1] Market security within your company. Learn what your CEO considers important: maybe it's privacy, or protecting trade secrets, or availability.

[2] Build security in. "Find and fix" should not be the only model.

[3] Publish per-department security scorecards internally.

Role of better programming languages and libraries

I asked this one.

For example, how much better can we do than C++ and PHP?

[3] When we look at web security, there is little difference between languages in the frequency of things like XSS holes. The security team doesn't have input into the language choice. Security researchers don't know which frameworks will become popular.

[4] A lot of the problems we're seeing in C++ are solved problems. This gives me hope that we could solve web-level problems (like XSS) in the same way. "Covering up for human nature of making little mistakes".

Reusable standard components and libraries

Someone in the audience asked about reusable components. For example, a "single sign-on component", so we don't keep rewriting the same fragile things.

[4] Enthusiastically agree. If you have 1000 applications and 990 implementations of password stores, they're probably mostly wrong. (Especially if fired employees might have access to many systems.) OWASP 'SAPI' API?

[2] Ruby 'gems' often don't try to be secure. They only try to be fast, easy, and lego-like.

What have you screwed up and learned from?

[4] Some things that make sense for a single project don't work at scale. Manual code review doesn't scale (e.g. Adobe with a billion lines of code). Simply waving test results around -- "I pen-tested and found 30 security bugs" -- doesn't alone convince people that security is important.

[1] Assume there will be vulnerabilities. Have processes for fixing and deploying fixes.

[3] IT security spends too much protecting networks (spending on firewalls) and not enough protecting business applications. This is backwards from how IT spends money.

Someone asked: of the breaches you've seen, how many were from in-house code?

[2] Not much.

Parallels between auto industry and computer industry

Improving quality; leaving US and coming back; some players compete on safety.

Outsourcing

[4] When outsourcing, it's easy to quantify performance+uptime requirements but hard to quantify security requirements. It's hard to spec out and communicate what you from your contractors, especially when all communication is written and asynchronous. But it's possible with effort put into the communication, and perhaps a focus on requirements around testing.

[1] Retention is low in outsourcing-target companies.

Licensing and certification of developers

[1] Deere is familiar with certification, having many actual engineers at the company. Inclined to move in this direction.

[4] Works well with *internal* certification. "What your team is doing is risky, you're going to need two black belts on your team." (This turns internal certification into a career accelerator!) Having hundreds of companies agree on a standard as to what should go into a certification? That would be lots of wrangling.

[2] "How do you make it not be CISSP?" There's lots of bad training out there; very little that helps developers understand thread modeling and fuzzing and thinking-like-an-attacker.

Static analysis vs dynamic testing?

[3] I'm in the business of both. They measure very different things, and help at different times in the lifecycle. "Early defect reduction" vs "late hackability metrics".

[4] Good to have a repeatable testing process, where you can see that the number of bugs is going down.