IEEE flags security as software development life cycle requirement

By Mathew Schwartz, Contributing Writer 26 Apr 2006 | SearchSoftwareQuality.com

Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

How can you produce secure applications?

For help, look to the newly approved version of the IEEE P1074 Standard for Developing Project Life Cycle Processes, one of the few -- or perhaps only -- project life cycle methodologies built to address security.

The revised IEEE P1074 proposes something that project managers may find radical: dealing with security throughout the life cycle of the software rather than handing it off to one development group at the end.

IEEE P1074 gives project leaders a plan for including all aspects of the software development life cycle (SDLC) when making security-related decisions. It puts projects in enterprise business context, and it provides the framework for coordinating software security efforts across all disciplines and over the lifetime of the software.

"This revision is groundbreaking in that it is the first IEEE software process standard to embed dedicated, mandatory, security-related activities in the software development life cycle that specifically address how to determine your project security objectives at the top of a project, and how to validate they were achieved at the end of a project," said Bar Biszick-Lockwood, an SDLC and security process standards expert who headed up the volunteer team that proposed the P1074 revisions to the IEEE.

Of course, "there are two kinds of people or companies: those that take security seriously and those who don't," said Jeremiah Grossman, founder and chief technology officer of WhiteHat Security Inc. in Santa Clara, Calif., and co-founder of the Web Application Security Consortium (WASC). For companies in the former camp, their project teams have battled that "there are very few, if any, resources that really give out a plan for how to implement security throughout the software life cycle and beyond."

[The revised IEEE P1074] provides a rationale for why security needs to be a component for all groups. It can't be a subset or standalone process. Jeremiah Grossman Co-founder, Web Application Security Consortium

Enter the revised IEEE P1074. "It provides a rationale for why security needs to be a component for all groups," Grossman said. "It can't be a subset or standalone process. And you know what? I agree."

Band-Aid approach doesn't work
Effective security requires not only prioritizing security at the beginning of a project, but also increasing its visibility throughout the SDLC. "We can try after the fact, our Band-Aid approaches, but it's going to be fundamentally broken," Grossman said.

Yet, when many project leaders and business customers consider security -- if they do -- it's as an add-on, or a coding problem. Some of that thinking stems from a lack of understanding between developers and project leaders.

"The disconnect, in my opinion, lies with the fact that developers are responsible for recommending and implementing security protections -- using secure coding and other techniques -- but it is the customer that ultimately sets priority on the requirements," said Biszick-Lockwood, and "few customers are willing to highly prioritize a requirement they think they should get by default."

Furthermore customers don't hear differently, she said. "Few developers have the risk analysis skills, communications skills, or motivation, to communicate the risk of not placing proper attention on security, since by raising such issues they simply make more work for themselves if they are unable to justify schedule extensions or more money for additional project personnel," Biszick-Lockwood said.

Regulations push security projects
Yet companies are increasingly under the gun to change their ways. Thank the California Security Breack Information Act (SB 1386) and similar data-breach notification laws in more than 20 other states, plus the Sarbanes-Oxley Act (SOX), which mandates controls on financial information.

"It's kind of a perfect storm from a security quality perspective," said Herbert H. Thompson, Ph.D., chief security strategist of Wilmington, Mass.-based Security Innovation. "You've got consequences of failure, which are increasing because I have to tell folks about it, and you've also got increased visibility of security projects, because I have to have audits."

Bake security into the SDLC Build security into the SDLC and keep the bad guys out  Secure SDLC: Integrating security into your software development life cycle  IEEE P1074-2005: Roadmap for Optimizing Security in the System and Software Life Cycle (PDF)

Of course the lingua franca of business development is return on investment, and project leaders want metrics to defend new security approaches. "They're asking, 'How can I justify to management that I include this overhead?' Because there will be costs; it's not going to come for free," Thompson said. "There's either going to be extra developer time or extra testing time -- or it will increase shipping time."

The Application Security Industry Consortium (AppSIC), which Thompson chairs, is trying to generate just such metrics to help companies better specify and justify their security initiatives. Having hard data should help project leaders make a business case for prioritizing security and further make security a de rigueur part of any software development.

In the meantime, however, thanks to the revised IEEE P1074, companies now at least have a methodology for incorporating security into their project life cycles.

Tags: Building security into the SDLC (Software development life cycle),  Software development fundamentals,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us