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.
- 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
- Verification of “who” did “what.” Examples of the controls are:
- Auditing and compliance measures
- Securing information—that is, making information unavailable and inaccessible to those who are not allowed to have it. Examples of the controls are
- Physical security (seals, locks, isolated guarded storage): preventing data or functionality from getting into the hands (literally) of an unauthorized individual
- Encryption: preventing unauthorized access to data by encoding it
- 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. You can use Planguage to structure these requirements as well as ensure that you capture the detail needed to make them testable.
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.
Dig Deeper on Topics Archive
Related Q&A from Sue Burk
Does sequence matter when you are not using use cases or process modeling techniques? Expert Sue Burk explains the importance of sequence by using a ... Continue Reading
Do new technologies affect the requirements gathering process? In this response, expert Sue Burk delves into this question, explaining the tenets of ... Continue Reading
Expert Sue Burk explains the importance of gaining proper approval for requirements changes and offers suggestions for the most efficient ways to ... Continue Reading