What is security?¶
If you would look up security in a dictionary, you would get a definition more or less like:
protected against threats
In other words, if we want to be secure, we need to know what threats exist and how to protect against them. A security requirement therefore states that we want to be protected against a certain threat, and sometimes how. Finding security requirements is essentially the same as finding threats.
In other literature, you will find definitions of security in terms of certain properties, such as confidentiality, integrity and availability. The problem with these properties is that they are hard to define and not orthogonal, we can for example get confidentiality by making data unavailable [Schneider].
Danezis gives a more precise, but still abstract definition of security in his SecAppDev talk, i.e. “properties [that] must be maintained despite a resourced strategic adversary.” [Danezis]. These properties, called a security policy, combined with knowledge of threats, called a threat model, answers the question whether a system is secure or not [Danezis].
In this guide, we follow the less formal definition, because it works for our purposes.
The above definition of ‘secure’ also shows that 100% security is not realistic, since we can never be sure to have covered all threats, or to have protected against threats, because they conflict with functionality, performance, usability, or costs. This moves security down on the priority list.
Instead of aiming for 100% security, we must set our goal to be secure enough. What is enough depends on the software’s environment and whether we are willing to accept certain threats. Such decisions are part of risk assessment, and can be difficult.
When we know a threat’s risk, we can protect against it in different ways. If the risk is acceptable, we can simply do nothing and accept the risk. Otherwise, we will need to take measures to reduce the risk. This is called mitigation. A mitigation can be technical (such as using a firewall) or non-technical (such as legal action or insurance). Of course every mitigation has a cost, and not every mitigation may be worth the expense.
Your risk can differ from my risk. The software’s environment may be different, or your security needs may be stricter than mine. Often if end-user security risks vary wildly, technical mitigations are made configurable. The responsibility for mitigating the threat is then transfered to the user of the software, who will have to configure the system securely. As a software developer however, you will have to explain how the risk can be mitgated through the configuration and to ensure that the implementation of the mitigation is correct.
As you progress more in the development process, software requirements will become more detailed and concrete. Similar to functional requirements, security requirements exist at different abstraction levels. In earlier phases of the development, security requirements will be more abstract than in later phases. Who creates the requirements is also important, as finding concrete security requirements asks for a certain expertise. We distinguish three abstraction levels, that are discussed in the next sections 1.
Business level security requirements¶
At the highest level, we find the business processes, for which we write the software. Requirements on this level are fairly abstract and do not assume a particular user interface yet. Typically the end-user or business owner is the best party to think about the applicable threats at this level. For example, a security requirement for serving coffee to customers could be: “a customer should not get coffee without paying”. Note that this requirement applies just as well to a coffee machine as to a human vendor serving coffee.
User interaction level security requirements¶
Just like a normal user, an attacker interacts with the system through a user interface. This user interface influences where and when an attack can happen. Typically developers and end-users or business/product owners create security requirements at this level together, similar to how they determine the user interface itself. For example, we may require that “maintenance functions on the coffee machine are only available to users with administrator privileges”.
System level security requirements¶
Probably the biggest source of threats are the technical components of the system. Every technology comes with its own unique threats. A developer must be aware of such threats in order to mitigate them. System level threats are very technical in nature. An example of a security requirement for the coffee machine, could be that the remote maintenance interface must only be available via HTTPS using a valid client certificate. Such requirements are created as the system design becomes more concrete. Sometimes however, the system’s environment dictates certain system level security requirements, for example because the system must interface with other systems. In other cases, compliance will yield security requirements, for example because laws or regulation require them.
Determining threat impact¶
In general you cannot mitigate all threats, and your software will be vulnerable to some of them. Users of the system cannot assess the risk if they cannot understand the threat impact. We want to be able to translate technical risks at the system level to higher level business risks. For example, if our code contains an XPath injection problem, not everybody may understand what that means. But if we explain that a user can see another user’s medical data, it is a lot clearer. You can prioritize your security requirements better if you can make this translation.
To define security for a system, we must know as many threats as possible, and decide how to mitigate them. The risk of a threat and the mitigation cost determine whether to mitigate the threat or not. Threats exist at different abstraction levels and different stakeholders create them at different times in the development process. It helps to put threats in perspective if we can translate technical threats to more abstract business threats.
Too many ways exist to categorize software requirements, and it is confusing. In the security world, categorizations almost always fail. The point here is to show that security requirements exist at different abstraction levels and that different stakeholders can create them at different times.