Year Of Security for Java – Week 44 – Follow a Secure SDLC

No Gravatar

What is it and why should I care?

Software development has taken an interesting path over the short lifetime of the field. It began as a deeply technical field where only the best and brightest could participate, which is not unusual since it was born out of engineering, a very technical and structured field itself. However, as the field opened more widely to the general population due to the Internet as well as widespread access to computers and simpler programming paradigms, the barrier of entry was significantly lowered. There’s recently been some educated guesswork that places the number of java developers in the world at 6-10 million. That’s just one (albeit popular) language. In addition, the newer development platforms (web/mobile) and reduced time to market (days/weeks instead of months/years) have made the field even more popular and populous. Add to these points the fact that the web in particular was built to be open and that most developers haven’t had significant security training, often including even those building platforms and languages.

From a software security perspective, that’s a challenging environment in which to function: simple and accessible languages/frameworks that are fairly insecure being used by novices, or even professionals, with little to no security training. Historically in software, security has been an afterthought – we’ve done a poor job overall with basic concepts such as validating input, encoding output, authentication, access control, etc. As for more esoteric issues, we have typically engineered solutions well after the attacks are discovered and known (this is partially acceptable since “you don’t know what you don’t know”). However, we also seem to have very bad memories, and tend to re-introduce the same weaknesses of design repeatedly (see web->mobile).

But there is hope! I have no doubt that the software security field is going to be active for a long time (lots of problems), but I am a firm believer that we can make significant improvement, especially within our sphere of influence. What it requires though is baking security into the way we build and deliver software, our software development life cycle (SDLC). Many of the posts in this series (and on this blog generally) are point solutions to specific problems. However, securing the SDLC is far more broad and reaching. The SDLC is just the way you build software, the set of steps you follow to get from thought or need to working software to retirement of the product. Examples you’ve heard of are agile, waterfall, spiral, etc. The point is that whether yours is heavily structured or very ad-hoc, you follow some process.

The simple idea of securing the SDLC is that you modify your current process (or adopt a new one) in a way that accounts for security. The truth is that if you want specific attributes out of something you build, you must plan for those attributes before you build it, or the re-engineering effort is not acceptable. If I want a chair that rocks, but I just start cutting pieces of wood in the shape of a chair that I’ve seen before (copy-paste code from stackoverflow or previous projects), I’m going to end up with something like a chair … but not one that rocks, and certainly not one that rocks smoothly.

What should I do about it?

We want to build secure software, and we know we have to plan for it. Now, we need a process that allows that and helps us plan for that. Luckily there are several open source popular models that you can consider to help you get started. All of these should be customized and tailored for your environment, but they are very good at giving you ideas of areas of consideration. It’s a good idea to get familiar with several, so even if you use one as your basic model, you can borrow from others to create a plan that works in your organization. While there are many good resources (the US CERT catalogs several), a few of noted interest are the Microsoft Security Development Lifecycle (SDL), Software Security Framework – Building Security In (SSF) and the Software Assurance Maturity Model (OpenSAMM).

All of the models (including those I haven’t mentioned) have strong and weak areas, but I personally like these three a lot, and for different reasons (though they’re all reasonably similar, when push comes to shove). The Microsoft SDL has great documentation and lots of great tools and worksheets ready-built to help you get going. The SSF-BSI is grounded with real data (openly published, see BSIMM) and is extremely logical and simple and clean. The OpenSAMM is great because it shows very clearly how to extend and customize it for your environment. You get a great idea of the options available, and you can make an informed choice of what steps work for you.

It is actually pretty rare in our field that we have so many quality options that are open and available to solve a certain problem. In this case, we’re fortunate that we have options. Make sure that whatever route you choose, that you follow it, and certainly improve over time. If you find a hole in your methodology, fill it in with a practice so it’s no longer an issue.

In conclusion, software security is a long and arduous journey. Building secure software is no easy feat, but it helps tremendously to have a plan. Fortunately, there are several quality options for SDLC frameworks that account for security. Read about the different models to get ideas before you start – some cover certain areas better than others. Build a model that works in your environment, and by all means, use it!


Be Sociable, Share!

Technorati Tags: , , , , ,