How to address security during requirements gathering

How to address security during requirements gathering

I've heard that application security should be considered during the requirements phase so that security is included throughout the development lifecycle. What specifically needs to happen or be included in the requirements to make sure security is addressed? Can you give some examples?

    Requires Free Membership to View

    Login

    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.

In today's environment of readily available information and fast searching it is important to consider how you will protect confidential information. Not only at the first level of defense, such as who can log in to a system, but making sure enough information is available to other consumers who can benefit from the information your application will gather. At the same time you want to make sure you are not compromising anything confidential. For example, is it alright to let a user see how many patients were treated at a hospital as long as you don't let that user see the patient names? That may be one type of security requirement you would need to think through and build into your application.

In order to discover these security requirements, you have to consider the environment you work within. Some requirements may be dictated for you already if you work in a highly regulated industry or you may need to discover them. Consider who will have access to these systems. Brainstorm to gather your list of users beyond the obvious ones. For example, could an unauthorized user run a report against a database that would expose confidential information?

Security requirements will likely drive the architecture in a certain direction, and considering these requirements up front might also save time or money later on. You may discover there is a pre-packaged security module that can be purchased or that your company has a user authentication system already in place, enabling you to reduce your cost and time to completion. It is probably beneficial to work closely with the application architect during these discussions about security.

Security requirements resources:
Authentication and authorization for Web applications

Wachovia banks on entitlement management for fine-grained application security

Integrating security into your software development life cycle

I worked on a project where a legacy application was being made available via the Internet to company employees. The legacy application did not have major security concerns, since it was installed on an employee's laptop and ran locally. That application benefited from the security of the operating system. However, during the process of making the application available via the Internet, the application team had to consider an entirely new security model. The legacy application as it was did not even require the user to login. That, of course, would no longer work with an Internet-based application, so the team had to consider the security requirements for accessing the system and adding a log-in capability. It turned out there was a single sign-on initiative under way and integrating with that system was the best bet. If we did not ask early on, we might have built yet another authentication system.

Requirements work continual during projects
I'd like to address the term "requirements phase" mentioned in the question. New requirements will be found throughout the lifecycle of the project. The question is how well you manage the change and what impact the new requirements will have on your plan. There is typically more requirements activity early in a project, but I caution against thinking that the "requirements phase" is complete until the next time.

This was first published in October 2007