What are security requirements

In every organization, it is important to define and document the cybersecurity requirements.

Requirements are mandatory security controls and practices defined by the security team, but that must be frequently implemented by other parts of the company. In this article I call these other parts of the company “engineering teams”.

Something similar to requirements are recommendations. Recommendations are very important, but optional, and very dependent on the specific case. While requirements have been decided by the company to be essential, recommendations are not essential.

The balance between what is mandatory (requirements) and what is optional (recommendations) is critical for keeping the organization agile and business-oriented.

Why we need documented security requirements

When we don’t have documented security requirements, the security team bases their decisions on common sense and experience. The problem with common sense is that it is less common than you might think and that it is ambiguous: what is common sense for you might not be common sense for other people. The problem of experience is that each person on the security team could have a different quantity of experience, so what someone thinks it’s absolutely necessary, others can think it’s not. Additionally, even the same person facing similar situations might make different decisions if they make the decision based on what they think at that specific moment.

By defining and documenting the security requirements we reduce many of these problems. For example, we set the baseline for the whole security team. Independently of the experience, the security team could make similar decisions based on the same documented requirements. This way the security team is more consistent. Consistency is very valuable for any company and engineering teams appreciate that a lot.

Another benefit is that if you have the requirements documented, you can share them with engineering teams from the beginning, even before they start a new project. This way they can anticipate the work and effort that will be needed; they will plan better their engagement; and they can take into account security requirements on the design from the beginning. It is important that we anticipate and make the requirements clear for engineering teams as soon as possible.

Documented security requirements also help agility in two ways. The security team doesn’t need to reinvent the wheel for each project. They can base their approach on existing security requirements. The second way is by empowering the security team. If we say to the security team that security requirements should be based on common sense, they will be afraid of making decisions because they will always have concerns about whether their decision is common sense or not. This will cause the security team to escalate more questions and decisions to their managers and will generate bottlenecks. This will also generate friction with engineering teams as they will perceive that the security person working with them doesn’t have authority to make decisions and that they have to escalate important questions to their managers. With security requirements documented, many questions will be escalated too, but not that many, as many questions will be solved in the requirements.

Problems we face when defining security requirements

When defining security requirements we usually face the problem of the level of detail. On one hand, we want that security requirements are defined at a high level to give space to engineering teams to implement it in the best way possible. However, in this situation some people will say that we are not defining the requirements enough and that it is not clear what we want them to implement.

On the other hand, if we define the security requirements with too much detail, we will be entering a zone that we don’t want to enter: the implementation zone. We are not specialists about the implementation so if we prescribe how to implement something, we might not be recommending the best solution. Moreover, if we are too detailed, we don’t give this necessary space to engineering teams.

There is no definitive solution for this problem. The approach we should take is to make them as specific as necessary, but not more. We should specify what we really want to see in the implementation and keep the rest as recommended. In case of doubt, reduce the level of detail. When the requirement is too high level, we can always help, as security experts, on defining better the solution for the specific project. We should assume that if the requirement is defined at a high level it is because the implementation is not that important and those who defined the security requirement were not expecting a specific implementation.

How security requirements and recommendations should be documented

• Security requirements should be documented using the words “shall” or “must” to make it clear they are mandatory.
• Security recommendations should be documented using the word “should” to make it clear they are recommendations.
• Security requirements should include an explanation about why they are necessary. They should be meaningful and not based on superstitions (many security requirements nowadays are based on superstitions and not on real technical risks).
• The documentation associated with the security requirements should include hints about how to implement them or links to additional documentation. It should be made clear if the implementation details are mandatory or just ideas or guidelines. This is important because the organization or the project should be able to implement the security requirements! I have seen security requirements that the engineering teams couldn’t comply with. When asked the security team why they asked for requirements engineering teams cannot comply with they told me that was not their problem…
• The number of security requirements should be minimum. They should be only those that are absolutely essential! The rest should be recommendations. Take into account that implementing them, and then maintaining them, takes effort and sometimes reduces agility and modifies how the organization works. The less requirements, the better.
• We should make an effort to define security requirements and recommendations that are transparent for engineering teams and customers and don’t affect the company agility. This is not essential, but it is important and very interesting. However, if the risk they reduce is worth it, any security control should be considered.
• Security requirements should be concise and not ambiguous. They should be plain clear for anyone reading them. We should not give space for imagination. We have more flexibility with security recommendations.
• We can have many recommendations, hundreds of them. Their application will be prescribed by the security team, but its implementation should not be enforced. It depends on each case.

Requirements should be verified by the security team

Establishing requirements is not a fire and forget exercise. Security teams have to feel accountable for their correct implementation. They are not. Engineering teams are. But security teams cannot settle with only the definition. That does not help to improve the security of the company, that is the major objective. We all should have the same goal, to improve the security of the company, and not only do our part.

When security requirements are established, two things should happen. New projects should comply with the requirements going forward. And deadlines should be established for old projects to comply with them. This means that at some point all projects, old and new, should comply with all the requirements.

The security team should take the responsibility of being on top of the implementation. They have to ask engineering teams how they are doing, if they are blocked or on time, if they are facing issues, etc. Yes, in my opinion this is necessary for the benefit of the organization.

When requirements are implemented, the security team should test them. It’s ok to do sanity checks by observation, interviews or documentation review. The verification does not need to be exhaustive, but the security team has to see evidence of the implementation. What is not verified, does not exist.

Security requirements degrade with time. It is important to verify the security requirements at planned intervals. It is not necessary to review everything each year, for example, but it is interesting to do some sample and also take any opportunity to review a control. Just a smell that something might not be happening as expected is a reason to check again if a related security requirement is implemented and maintained.

Exceptions

Requirements are mandatory. They must be implemented in all cases. However, in security we should never follow instructions or requirements blindly. We always have to use our brain and think. Is this security control appropriate for this case? Am I sure? Do engineers think differently? Why? We will find cases and situations where a mandatory security control is not the right thing to do. Maybe because the effort is much greater than the benefit or because the complexity it introduces is not worth the risk it reduces. There are many reasons.

If there exists a reason to not implement a security requirement, first thing we have to do is think about what was the objective of the requirement and think if there is another security control that could cover that security requirement, or its objective, and that it’s appropriate for the case. This is called a compensatory control.

In any case, if a security requirement is not implemented, we have to document it in an exception. The exception should be documented and escalated within the organization to the appropriate roles. The important thing is that the stakeholders understand and agree with not implementing the security requirement.

There are two kinds of exceptions: justified and unjustified.

The justified exceptions are those where, in fact, we think that the security requirement does not give any benefit or does not reduce any risk for this specific case or scenario. That should be documented, escalated, and approved, but there should be a fast track for approving them.

Unjustified exceptions are hard ones. These are associated with security requirements that the engineering team does not want to implement, but the security team does not agree because it is a risk too high for the organization. The security team should not settle with the engineering team accepting the risk. That’s not enough because the engineering team might not have understood the risk or can be putting the company at risk in a negligent way. The security team has to generate all the noise that is necessary in relation to unjustified exceptions and escalate them as high as possible within the processes of the organization. It is important that everyone knows that we don’t agree and that the exception puts the organization at risk.

Be careful with unjustified exceptions. Many many many times security people are very exaggerated and tend to overstate the risk of not implementing a security requirement: “what if this happens?”, when the probability of that happening is really low and the impact dubious. It is important that the security team trains and works a lot on being realistic and being able to differentiate what is really important for the security and what are best practices and hygiene. Both are important, but in order to have more credibility, the security team should only burn the boats when it is absolutely necessary and not for small things.

Conclusions

Defining security requirements is hard, but definitely necessary and worth it. We don’t have to try to define them perfectly the first time and we have to establish a process of continuous improvement of them to adjust its detail.

Security teams have to feel responsible for its definition, but be on top of its implementation by engineering teams. If security requirements are only on paper that does not help the security posture of the company.