Writing software requirements that address security issues

The software requirements phase. It's the first and arguably the most important step in software development. Isn't this where security should be addressed in software projects? Yes, but often it isn't. Or at least security isn't addressed the way it needs to be. In the majority of software projects I've seen, "security requirements" are typically defined by the following:

1. Is it Internet facing? If so, we'll put it behind a firewall.
2. Is encryption needed? If so, we'll use SSL.
3. Will it take user input? If so, we'll use managed code to make sure we're safe from cross-site scripting and SQL injection.
4. Will sensitive information be processed or stored within the system? If so, we'll require passwords.

Most applications that I test for security flaws have these basics. They're fine and dandy -- and certainly a good start. The obstacle is that many developers don't go any deeper when defining security requirements. And product/project managers -- and even executive sponsors -- buy into and assume the basics are all that's needed for a truly secure application. This is a dangerous assumption. Today's software -- especially publicly accessible Web applications -- need much more if they're going to be sturdy and reliable from every reasonable angle.

When writing your requirements, make sure security is pervasive in all the key areas of your document. Your requirements should address the basics but also the commonly overlooked application vulnerabilities uncovered during threat modeling. Your document should include the following:

• An outline of how security helps the overall problem being solved by the application
• A statement that defines specific security goals
• Security controls inherent in the application's major features
• Features that support compliance with X, Y or Z regulation, such as the PCI Data Security Standard or the HIPAA Security Rule -- whatever your customers are up against
• How security enables, rather than detracts from, ease of use
• Security control limitations -- what they won't do or protect against
• Security features that enable user and system administration as well as future application security testing

Digg This!     StumbleUpon     Del.icio.us

VIEW ALL IN THIS CATEGORY

RELATED CONTENT Application Security Strategies Rich Internet applications security testing checklist The lowdown on PCI compliance Web 2.0 application security troubleshooting, testing tutorial Expert resolves issues plaguing OpenSTA users Fixing four Web 2.0 input validation security mistakes Social engineering training could disrupt botnet growth Web security problems: Five ways to stop login weaknesses Preparing for testing applications in the cloud The role of quality assurance (QA) pros in software security Common software security risks and oversights Building security into the SDLC (Software development life cycle) Problems caused by skipping analysis stage of SDLC Inexpensive phase of SDLC to catch and fix bugs GatherSpace beefs up cloud-based requirements management ALM: Best of breed vs. complete systems Software development life cycle phases, iterations, explained step by step The role of quality assurance (QA) pros in software security Common software security risks and oversights Why the quality assurance department should be involved in testing How to develop secure applications Secure software development practices 'not rocket science' Prevention techniques when gathering requirements Software Security Engineering: A Guide for Project Managers -- Chapter 3, Requirements Engineering for Secure Software Getting started with Web application misuse cases The essentials of Web application threat modeling Threat modeling enhanced with misuse cases Threat modeling key to pro-active security

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

Obviously you can't do it all. There are cost and benefit tradeoffs. The good thing is that most application security controls cost very little to integrate up front, and they're very effective in keeping the bad guys out. It's important to go beyond the bulleted items found in a RFP or a requirements list from product marketing. Sure, just because you've integrated security throughout your requirements document doesn't mean the end product can't be exploited somehow. But you'll at least know that you've done what's right.

Clear requirements are the blueprint and main determinant of the quality of your software projects. They also define just how secure your application is going to end up. Your application may look good and run well, but it may not hit the mark if it doesn't meet the security needs of your company or your customers.

If you're a developer or product manager, try to pull in someone from IT or an independent outsider who lives and breathes application security every day. If you're a security professional and you know that security is going to be a key component of a project, assert yourself. Make yourself known and ensure the right people are aware of the security issues at hand. No matter which side you're on, make sure security has a presence at the table, its voice is heard, and its principles make it into your requirements document.

-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog, providing security learning for IT professionals on the go. Kevin can be reached at kbeaver@principlelogic.com.