Chapter 10. An Enterprise Software Security Program


Chapter 10. An Enterprise Software Security Program[1]

[1] Parts of this chapter appeared in original form in IEEE Security & Privacy magazine co-authored with Dan Taylor [Taylor and McGraw 2005].

I have found no greater satisfaction than achieving success through honest dealing and strict adherence to the view that, for you to gain, those you deal with should gain as well.

Alan Greenspan

Adopting software security in a large organization is a challenge that takes careful planning. Cultural change of any variety is difficult in big companies. Minefields surrounding software process (a religious choice),[2] development tools, programming language, platform, and other technical decisions only exacerbate the difficulty.

[2] A number of very large enterprises I have worked with have washed their hands of process and have declared their agnosticism loudly (in many cases turning to the wild west for in-spiration). They've all had Big-5s come in and deploy three to six software development processes, but either the processes became immediate shelfware or nobody remembers who is supposed to be using which. Risk management is not practiced.

Corporate politics is also an issue, with real courage required to foment software security change. Two political factors in particular impede progress. The first is momentum. In many cases, lines of business have depended on applications and systems for five or more years, and the applications have become set in stone. These organizations will not jeopardize the support to their top lines without having a huge multiyear program budget and executive sign-off on the risk. The second is territory-related "fear of change." Director and VP (line of business) budget and team size are at stake. It is hard to tell a Director he is losing all five database engineers and his $1.8 million annual maintenance budget when you hook the application up to the more secure (shared services) enterprise reporting interface. Regardless of these issues, leading software shops have been working hard to improve the way they develop software in order to build security in.

In some circles, the term Secure Development Lifecycle (SDL) is used to describe the goal state of a software security program. For example, Microsoft uses this term to describe its adjusted software process. Because of the process-agnostic approach that I prescribe, any SDL is in the end a combination of your already-in-place software development lifecycle (SDLC) and the best practices described in Part II. That is, you already know how to build and ship software (though you may not be perfect), and what you really need to concentrate on is adjusting that existing approach to produce more secure software. This chapter is about how to begin to accomplish the cultural change necessary to put an SDL in place. We start the process by demonstrating the value of software security, showing initial success that will lubricate (fund and motivate) cultural change and building a clear, actionable roadmap for that change.

Software security initiatives are possible and are underway in a growing number of organizations. A number of programs have proven beneficial for those that have implemented them. This chapter describes one approach that works, with an emphasis on business process engineering that may be unfamiliar to technical practitioners. By following a number of commonsense steps, a software security improvement program has a greater chance of achieving its ultimate goalsoftware security that makes business sense.




Software Security. Building Security In
Software Security: Building Security In
ISBN: 0321356705
EAN: 2147483647
Year: 2004
Pages: 154
Authors: Gary McGraw

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net