Problem solve Get help with specific problems with your technologies, process and projects.

What is needed to define and fulfill software security requirements?

There are important distinctions between security requirements and security controls, as well as the expertise needed to define and satisfy each. In this expert response, Sue Burk offers a clear definition of security requirements and explanations of the categories they fall under. Ultimately users and business owners do play a part in the process of defining security requirements.

Is it really necessary to have “requirements” for security other than, “The data and code should remain protected”? Users and business owners don’t have enough technical knowledge to define more detail than that.

Technical knowledge is a must to satisfy most software security requirements, but business knowledge is needed to define these important requirements. Let’s make a clear distinction between security requirements and security controls.

A security requirement is a business need related to the protection of an organization. Often, security requirements focus on data or data access or enforce underlying business rules. Like all requirements, security requirements must support business objectives and goals. For example, in banking, a security requirement might ensure that a borrower cannot claim he or she never agreed to the terms and conditions of the loan.

A security control is a way to fulfill one or more security requirements. Each security control can be implemented with procedural or technical components (or both). In our example, the bank’s security requirement might be supported by a security control called “nonrepudiation,” which ensures that someone cannot deny that he or she took a specific action. For the bank, there are several options for implementing nonrepudiation, such as requiring that a loan be signed and notarized in person or asking an online applicant to click on an “I agree” button.

From a business or organizational perspective, security requirements fall into several categories, each of which can be satisfied by one or more security controls.

  1. Permission to access data or exercise functionality. Here are examples of security controls that are used to implement this category of security requirements:
    • Authentication: confirming the identity of an individual or role
    • Authorization: confirming that the individual or role is entitled to access functionality or data
  1. Verification of “who” did “what.” Examples of the controls are:
    • Auditing and compliance measures
    • Nonrepudiation
  1. Securing information—that is, making information unavailable and inaccessible to those who are not allowed to have it. Examples of the controls are
  1. Security policies, procedures, and practices. Note that some of these requirements focus on the security of the business, and others focus on “the business of security”—that is, the policies and practices of the security organization. Here’s an example of a control:
    • Separation of duties: dividing a task into a number of smaller tasks to prevent any one individual from having control of the entire task.
  • You can use these categories as starting points for eliciting security requirements or as a way to find out more about requirements you’ve already discovered. Continuing with bank loans as an example, the “permission” category leads to additional business questions, such as, “What roles are allowed to override a loan denial?” The “securing information” category suggests the question, “Is it ever permissible to display the applicant’s full account number, and, if so, who is allowed to see it?” The “security practices” category often raises questions about separation of duties: can loan applications be handled as one-stop-shopping, or must the loan application be separate from the loan approval? The business answers to such questions help you choose the security controls to meet the requirements and define how stringently they need to be enforced.

    Ideally, security requirements should be implementation independent; users and business owners do not need technical knowledge to define them. It’s true that most business users won’t ask their technical staff to prevent SQL injection (manipulation of executing code to enable unauthorized database access), but they certainly can define which roles or individuals are authorized to access and alter various portions of the organization’s information and specify that the information must be unavailable, inaccessible, and unmodifiable by unauthorized roles or individuals.

    As with all requirements, security requirements must be testable. And metrics must be established to ensure that everyone has the same understanding of what constitutes meeting these requirements.[1] You can use Planguage to structure these requirements as well as ensure that you capture the detail needed to make them testable.[2]

    For more information on security requirements and security controls, the website for the Open Web Application Security Project (OWASP) — www.owasp.org — contains excellent reference information, such as http://www.owasp.org/index.php/Document_security-relevant_requirements and http://www.owasp.org/index.php/Category:Control.

    [1] See, for example, p. 329 of Ellen Gottesdiener’s Software Requirements Memory Jogger (Goal/QPC, 2005), ISBN 978-1-57681-114-6.
    [2] Tom Gilb, Competitive Engineering: A Handbook for Systems and Software Engineering Management Using Planguage (Addison-Wesley, 2005), ISBN 0 7506 6507 6.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.