Security aspects of software development require a close attention from the very beginning of the development life cycle – actually, from the very first contact with your stakeholders. In any area in life, having appropriate security safeguards in place is the precondition that needs to be met before we even make the first step, let alone complete an activity.
So, how do we achieve that in software development specifically? Aside from acknowledging the importance of security, there are three basic steps that every development process needs to go through to make sure that all has been done well security-wise.
1. Gather requirements
The first step is to gather functional requirements for future software. Think about collecting requirements for the software you re building – now, imagine going through the same process, but this time approaching it from the security perspective.
Usually you try to get your head around the domain you will develop software for, right? You talk with stakeholders, talk about use cases, try to elicit functional requirements (brainstorming, storyboarding, interviews, questionnaires, etc.). This time, you will do the same, just with security considerations in mind.
You may wonder, what exactly is the difference? Let s put it like this: functional requirements are telling us what software should do; on the other hand, security requirements are telling us what software should not do. Security requirements need to address the confidentiality, integrity and availability of the application.
For example, instead of “Customer will send message from Service 1 to another domain Service 2”, you ll need to keep in mind that “Customer will send a message that MUST NOT be seen and tampered with by third parties from Service 1 to another domain Service 2” (if that s what is required, of course).
Or, instead of “Websites will fetch images from Amazon S3”, you may need to consider that “Website will fetch images only from Amazon S3, other domains must be disallowed”.
2. Separate requirements
The second step is also hugely important. You ll need to separate functional and security requirements; please, don’t put them together.
When merged with functional requirements, they re at risk of being put aside or not being handled properly. Therefore, keeping them apart is key to enforcing the right security attitude.
3. Define requirements
Finally, in the third step, you ll need to put requirements on paper. When setting out to do this, make sure you:
- Keep security requirements clear and precise
- Set up a clear way of testing whether a requirement was met or not
- Clearly communicate to developers what exactly they need to do to meet the requirements
- Make requirements implementable in real time
- Make requirements a high priority when they re up for implementation
Here s how a security requirement that meets these criteria could look like:
- Messages from Service1 to Service2 should not be readable by third parties, and it should not be possible to tamer messages in any kind.
- Https should be forced (HSTS) and messages digitally signed.
- Testers should check if communication is through https and try bypass https and to tamper messages.
- To get this security requirements you can use one of the following security requirements methodologies:
- Abuse Case – describes how an attacker can abuse software and it is related to use cases by threatening relationships. Ex. Users can send messages from Service1 to Service2 and the attacker threatens this by tampering the message. (bold one is abuse case)
- Security Use Case – is related to abuse cases and it tries to defeat or counter abuse cases. It is related to abuse cases by mitigation relationships. Ex. Users will send messages and software will mitigate tampering threats by digitally signing messages so attackers can not tamper with them.
- Abuser Stories – are something like abuse stories but from the attacker perspective. Ex: as an attacker I want to intercept and tamper messages. Or: as a client I can send a valid message but to the wrong service endpoint with a message body not intended for that service (not intentionally).
Please bear in mind that not every security aspect must be dealt with. It s ok to take some risks; it s fine to assume that, let s say, Service1 and Service2 will work in the private network, and https will not be required. However, it is still important to put these requirements on paper, because the environment may change and, with it, security aspects too. For example, maybe we will move Service 1 to the outside network but in this case we will have security requirements for Service1 to check with. In the end, you should have security requirements on paper, and they should be updated regularly just like functional software requirements.
And, that s it. Obviously, the actual work you ll need to do will not feel as simple and neat as this three-step description. But it would feel much more complex if you d approach it without structure and without proper understanding of priorities. Speaking of which, developing the security mindset – understanding the importance of security and investing in it from very early on – should always come first.