Nowadays, security becomes an important aspect of almost every software system. Unfortunately, it does not necessary mean that security is adequately considered in every piece of software. What does “adequately” mean? For me, security measures are adequate if an investment to them is less than loss caused if these measures were not implemented. I would say this explanation is clear if there is no unknown variable there, i.e., the potential loss.
If a company has no security incidents so far, does it mean that its security measures are adequate and it should not put additional investments in security? It is really hard to say yes or no. The software may change (e.g., it may introduces new features with new attack vectors), the market can change (e.g., more people can start using the software, so it may become more attractive to attackers), and the environment where the software is used may change (e.g., from an intranet solution it may become a public cloud based solution).
The history gives us a generous hint. No matter what, security incidents happen. The question is only when a what impact it will have on the customers and the company.
“Security is a process, not a product”
– Bruce Schneier
In order to create secure products, a company should regularly evolve and adapt its development processes to changes that continuously take place around us.
Here, in Y Soft, we decided to examine and try in one of our development teams the Microsoft Secure Development Lifecycle (SDL) that is a process aiming to help to build more secure software.
In this series of posts, I would like to:
- Look at Microsoft SDL in more details,
- Describe its advantage/disadvantages as we perceive them here in Y Soft,
- Describe obstacles we meet and how we overcome them.
Secure Development Lifecycle (SDL) is a process that helps to build more secure software. Microsoft introduced its SDL in 2004, successfully uses and regularly updates it. Microsoft SDL covers all phases of development process, e.g., Requirements, Design, Implementation, Verification and Release.
Training → Requirements → Design → Implementation → Verification → Release → Response
Microsoft SDL describes tasks that should be completed at each phase and also provides tools and training materials that are available free of charge.
Key features of Microsoft SDL, as I perceive them, are:
- Security is considered systematically. Developers and managers can be certain to some degree that important security issues were not overlooked and they will not emerge at release (or after release) phase where their resolution is often not cost effective.
- Microsoft SDL is designed to be a part of software development process. And this is probably the most important thing about it. A bullet-proof system does not exist. New attacks appear all the time. And it is important that new defenses that come after are in place and in time.
- Security is considered early in the product lifecycle. The process starts from the requirements phase. It means that design reflects requirements on security features and features that need to be secure. The process that starts from the requirements phase, among other, decreases the risk of security design flaws in the later phases and hence decreases the total development cost.
- Process is primarily focused on developers. Most of the tasks from the Microsoft SDL are completed by developers themselves. The tasks include among others, threat modeling, secure design, code analysis using static analysis tools, etc. Security experts are those who are consulting, reviewing and helping developers to get their job done right.
- It can be integrated gradually. Microsoft SDL defines four maturity levels (Basic, Standardized, Advanced and Dynamic) where each level has additional tasks (that should be completed) in comparison to the previous one.
- It naturally fits the software development process. Tasks and activities defined in the Microsoft SDL logically follow or extend tasks that are normally done by developers. For example, for systematic threat analysis, a developer can utilize the Microsoft SDL Threat Modeling Tool. This tool uses Data Flow Diagrams (DFDs) that resemble container/component diagram from C4 model that is used by our developing teams.
Next time, we will look at the training and requirements phase, and discuss activities and tasks we decided to implement.