How to gather security requirements for software projects and what to look for

How to gather security requirements for software projects and what to look for

What is the best way of gathering security requirements? Are there examples of standard security requirements for different types of applications (ie. Web applications?)

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The best way to gather security requirements is to think big and think long term. What is it you're trying to accomplish with the application you're building? How will security add value to the overall problem that's addressed by the application? Will the necessary controls for today serve the application well down the road? Determine the specific business goals first and then you can drill down from there and determine specific security requirements.

When looking at the details, you'll need to consider authentication, access controls, encryption, audit logging, and minimum configuration requirements for the underlying server OS, Web server, middleware, and database system. You'll also want to drill down further and address common vulnerabilities related to input validation, URL manipulation, privilege escalation, application logic and so on.

Focus not only on best practices but also on how security can be used as an enabler or provide a competitive advantage to your business. Also, don't overlook the importance of documenting any known limitations the security controls you're building in have - they will exist. List the weaknesses, tradeoffs and any other compensating controls that can be used to keep things in check.

Finally, be careful using other people's requirements. Simply downloading security requirements templates off the Internet is akin to downloading security policy documents and assuming - better yet, hoping - they'll work in your business' best interests. It's OK to get rolling with some general guidelines but only you and your team will know what's best for your business given your own unique situation.

This was first published in July 2010