2008 DOI: Day 7 - The SDLC is your friend

2007 Incite: The Information Strikes Back
2007 finally brings acknowledgement that data/information security is different than protecting the network and servers. Yet, there is a major skills shortage in folks that understand how to protect applications and databases, resulting in accelerating interest in application and database security product offerings. But history will repeat itself, as a “fool with a tool” is still a fool, which doesn’t help customers solve any problems.

2008 Incite: The SDLC is your friend
As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Like yesterday’s piece on laptop encryption, I decided to split the 2007 information security Incite in 2008. Why? Because starting to implement a secure software development lifecycle (SDLC) is a key imperative this year. No you can’t wait until next year or the year after that. Software projects take years to go from idea through deployment to maintenance. Sure there are many iterations along the way, but if a project starts in 2008 and isn’t built thinking about security from the get-go, it’s not going to happen later.

I’m not going to go through the numbers of why it’s important to fix software defects early in the process. That is obvious or at least it should be. You want to eliminate issues prior to software being deployed. Bokay?

Here’s the rub. Organizationally, it’s hard to embrace secure coding standards. You need a seriously high level mandate to get everyone on board, and those take some time. Yesterday on Microsoft’s SDL blog, Michael Howard, details how Microsoft embraced their SDL. Basically they did it because Bill Gates told them to. They had no other choice. Unfortunately sometimes that’s what it takes to get the behavior changes that are required.

There are other reasons why the SDL needs to be a short-term imperative. It may be the first situation where security leadership influences other parts of IT and the business to think about security – before they have to. Remember, being a senior security professional requires sales and persuasion skills. Yes, these are more valuable than technical chops moving forward.

As I mentioned, it’s a long tough slog to get the developers to do a threat model when they are architecting the application. It’s hard to get Q/A to add more security tests to their harness because they are already behind since they got the code late. It’s hard to get them to hold up a release, which is already late, because there are serious security holes. Yes, it’s hard.

So how do you increment to get there, knowing that true adoption of the SDLC will take years? Basically you need to attack the issues on multiple fronts. You’ve got to make the investment in the process (SDLC), but you are also well suited to start thinking about how tools can supplement your efforts to amend the process.

Neither web application scanners nor web app firewalls ever really hit the big time. They remain interesting niche markets, but that’s far from what is required to solve the problem. Let’s hit the scanners first. Basically these tools tell you (at a high level) where the holes are in your applications. Actually, to be more correct, they will find SOME of the holes.

Web app scanners cannot find logic flaws in your applications. They have trouble detecting cross-site request forgery. You still need humans to do that. So running the systematic application penetration test is critical to uncovering those issues the technology doesn’t catch. The fact is the tools only go so far and we still need skilled humans to do a comprehensive analysis of an application.

Yet, running a current generation scanner is better than not running one at all. Two of the biggest players in that space were Watchfire and SPI Dynamics. Both were acquired last year by the development tools divisions of IBM and HP, respectively. There is a real risk that innovation slows for both of these companies, since the scanner business is hardly adjacent to development tools.

On the web app firewall front, these devices just never got going. And now you have new entrants (like Palo Alto Networks) and the existing firewall folks claiming to do more sophisticated application-level firewall functions. There are some protocols and attack vectors that web app firewalls handle, that the other devices can’t. Does that mean you need it? As usual, it depends on what you are trying to protect. If it’s that important, then the answer may be yes. But the market has spoken thus far, and web app firewalls are being voted off the island.

I want to wrap up with a little career advice. I get asked frequently where practitioners should focus their efforts and how they can maximize their opportunities and status within their organization. I tell them to learn how to break and protect applications. There is a major skills shortage in dealing with application security, so if you are looking to become more relevant – that’s where to supplement your skills.

Photo credit: freshelectrons