Manage Learn to apply best practices and optimize your operations.

Writing software requirements that address security issues

Experts always say you need to bake security into the development lifecycle. To do that, you need to take a hard look at the security requirements written for the software. Kevin Beaver offers some advice on what you should consider during this critical phase of the SDLC.

Kevin Beaver

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

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.

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

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.