Securing Software – Where do I start?

Open up any news reader and there’s bound to be a bold headline about a recent application hack. The attack exposure may be due to poor design (like a stored-in-the-clear hard coded password) or it could just be yet another web application with a SQL injection vulnerability — but either way, the message is the same: application security matters.

Most executives get this at a high-level — they’ve read enough of those bold headlines, they know they need to do something about “application security” but, unless that executive started out life on a development team, it’s a good bet he or she doesn’t have much insight about how to go from software insecurity to a reliable application portfolio.

And with no one to help guide the way, it’s not unusual to find a company trying to solve the application security problem the wrong way around – from the outside in. Rather than looking at their development processes, a company just staring to implement application security may just hire an external company to do a basic web application scan. They then remediate (or sometimes ignore) problems uncovered by the scan, and hope that solved the problem.

And if you’ve read the marketing material from some third party web application scanning firms, you can’t really blame organizations new to the application security space for trusting in those scans. The vendors make a strong case for their product capability and some of the products are very mature and thorough for the kind of assessment work they do.

The Wrong Way Around

Starting at the end of the process is truly the wrong way around.

You don’t have to be a fan of the classic “Boehm’s Curve” to have heard that it’s cheaper to find and fix flaws and bugs earlier in the development process. Building Security In, Correctness by Construction and Secure by Design have long been mantras of the software security community. But for executives and managers at a company that’s new to application security, trying to get them to start at the beginning can be a challenge. If it’s possible to solve the whole problem with a third party scan, why bother with all the heavy lifting of Building Security In?

Here are just some reasons why:

• Those external scans only catch a small portion of the problems
• Some of them don’t even automatically crawl and inventory the externally facing web apps. Not to mention the apps, services and databases those apps interact with.
• If you’re only looking at dynamic testing, it’s a good bet you won’t know where in the source code the flaw occurred. So you can tell your developers to go fix the vulnerability, but won’t be able to give them guidance on where in the source the fix needs to go (both to help them fix this instance, but also to help keep them from making the same mistake again in the future)
• There’s plenty of research to support the metric that it will cost a lot more to fix that app once it’s in production than it will to deploy it without critical vulnerabilities in the first place.

But if the company isn’t at a maturity level where more robust development processes can be supported, trying to get them to adopt what appears to be a heavy, hard to implement set of new rules and standards can be challenging at best.

Maturity Makes it Easy

Well, “easy” may be a bit of a stretch, but implementing application security can certainly be made easier when the maturity level of the company is assessed and the plan is put in place that supports the company’s current levels of expertise, business requirements and overall approach to development.

Rather than starting with a pitch for products or trying to get the company to implement a program they’re not ready for, a great place to start is with a maturity model review. There are a number of free frameworks available to help assess maturity, including the OWASP supported Open Software Assurance Maturity Model and Cigital’s Building Security In Maturity Model. OpenSamm includes more specific guidance on how to get to the next level of maturity by applying the model and implementing practices. BSIMM provides the high level model, but more specific guidance is supplied as part of a BSIMM assessment that Cigital sells as a service.

Mapping a company to a maturity model will identify the areas where the company is lagging behind and highlight what steps need to be taken to move forward. Note that this doesn’t mean foisting a rigorous SDLC process on a firm that’s not ready for it; instead, it means figuring out where the company is with their program and helping them move to the next level at a pace that fits the business. And since models are broken down into areas (like Governance and Deployment), organizations can decide which areas they want to focus on first. While it’d be great if every company was able to devote infinite resources to application security, the reality is that almost everyone has to prioritize and solve the problems that are the biggest problem for their own business first.

Moving on Up

Once some success has been shown with increasing maturity in a few targeted areas, a company can determine whether or not they want to continue to focus on that area or to focus on increasing maturity across all areas of the model. When testing is a priority, that’s when tools come into the equation.

Ideally, an organization will look at building some level of security in from the requirements definition phase, but using a maturity model will at least help them get a better idea of where they are across their life cycle. Though a point and click third party assessment of externally facing web applications has its place in the software security life cycle, in most cases it is not the right place to start. Using a maturity model can help point a company in the right direction and stay with them when they are ready to increase their maturity level.

Do you agree with this approach? Let me know in the comments below.