In this article, I will be talking about WHY documentation of security concepts are important and NOT a waste of paper.
Note: These are simply notes I made on a video I found interesting! (https://www.youtube.com/watch?v=GU5ayb3kTqM)
Why Do We Need Security Concepts?
Goal 1: So that the implementer can develop it (they aren’t going to do it if you don’t tell them.)
Goal 2: Enabling security reviews before implementation follows a SecDev Ops methodology where security controls are outlined before the first line of code is written. Otherwise, if there was a security error later on in the project, it would be much harder to detect and more expensive to fix.
Contents of Security Concepts
- What do we want to protect?
- What are we protecting it from?
- Security assumptions (Secure methods like AES are one of the security controls that what we’re protecting relies upon and who knows how long it’ll be until AES is crackable.)
- Non-security boundary conditions (issues that are not primarily concerned with security… e.g. required RAM. We have to make sure that security does not interfere too much with the actual product’s operational functions.)
A summary for non-technical folk.
Formal Concept Description
Introduce the concept but with some technical detail.
Documentation of Remaining Attack Surface
Filling in the gaps. This is the Risk Analysis portion of the documentation.
What happens if one of the security mechanisms breaks? Is the whole concept broken or do we have a security net? This is also known as Defense in Depth.
To help the developer with what they should look out for.
I hope you learnt something from this small post. More coming soon!