Security development lifecycle (SDL) was first proposed by Microsoft in software engineering to help with software security solutions. SDL is a security process that focuses on software development, with the principles of security and privacy in all stages of development. Since 2004, SDL has been a mandatory policy in the business of Microsoft.
The methods in the SDL process try to identify the root causes of security vulnerabilities. The safety of the product can be ensured when software engineering is under control.
SDL has positive significance in reducing the number of loopholes. According to the National Vulnerability Database, the data on loopholes are as follows: Every year, thousands of new vulnerabilities appear, most of which are harmful but with a low level of risk. These gaps appear often in applications and most of them can easily be taken advantage of.
The National Institute of Standards and Technology estimates cost of rectifying a vulnerability as being 30 times that of the original cost of design and implementation of the software/application. Forrester Research, Inc., and Aberdeen Group have found that if the company uses a structured process like Microsoft’s SDL, security problems can be addressed in the phase of development; therefore, vulnerabilities are more likely to be discovered and repaired early, reducing the total cost of software development.
Microsoft has traditionally been the focus of hackers, with many of its clients suffering from safety problems. Because of the deteriorating condition of the external environment, Bill Gates, in January 2002, issued his trusted computing memo. Trusted computing start-up has fundamentally changed companies’ priority for software security. Order from senior management put security as the top priority in Microsoft, in order to achieve a steady stimulation in engineering reform. SDL is an important component in trusted computing.
Microsoft’s SDL process is roughly divided into 16 stages (after optimization).
Stage 1: Training
All members of the development team must receive appropriate safety training and gain relevant knowledge. Training in SDL looks simple, but it is indispensable. The training also involves improving efficiency of the implementation process to reduce the communication cost. Trainees will include developers, testers, project managers, product managers, etc.
Microsoft’s recommended training will cover security design, threat modeling, security code, safety test, and privacy.
Stage 2: Safety requirements
Before establishing the project, communication with project manager or product owner is essential to determine the security requirements and necessary actions. Confirming the project plan and milestones are also important to avoid project delays due to safety issues—this is what the project manager wants.
Stage 3: Quality door/bug toolbar
Quality gate and bug bar are used to determine the minimum acceptable level of q uality in security and privacy. At the beginning of the project, definition of these standards will enhance the understanding of security issues related to risk and help the team in the development process find and fix security bugs. Project team members must discuss with each other about the quality of the door (e.g., before the code checks in, they must review it and fix all compiler warnings) in each development phase, then hand the door to a security consultant for examination and approval of quality, where the security adviser will add project-specific instructions as well as more strict safety requirements. In addition, the project team needs to clarify its compliance to the security door to complete the final safety representative (FSR).
Bug bar is applied to the quality of a software development project and used to define the severity of a vulnerability. For example, any product upon release should not contain any known vulnerabilities rated as key or important. Once a bug bar is set, it should be consistent.
Stage 4: Security and privacy risk assessment
Safety risk assessment (SRA) and privacy risk assessment (PRA) are necessary processes to determine what functions need to be further analyzed. These assessments must include the following information:
- Which aspects of the program need a threat model before release? (Safety)
- Which aspects of the program need security design evaluation before release? (Safety)
- Which aspects of the program need to be approved by penetration tests recognized by both sides? (Safety)
- Is any more testing or analysis required by security consultant to mitigate security risks? (Safety)
- What is the scope of fuzz testing? (Safety)
- Privacy intrusion rating. (Privacy)
Stage 5: Design requirements
During the design phase, security and privacy should be considered. Security requirements should be addressed at the beginning of a project to avoid making changes later on.
Stage 6: Reduce the chance of attack
Reducing the chance of attack is closely related to threat modeling to solve the problem of security from a slightly different perspective. This way the chances of the attacker using potential weaknesses or loopholes can be reduced, including closed or restricted access to system services, applying the principle of least privilege, and employing layered defense wherever possible.
Stage 7: Threat modeling
Threat modeling is good practice as it helps the designer identify security issues in the product. Microsoft’s STRIDE model is used for threat modeling.
Stage 8: Using the specified tool
Development teams use a compiler, linker, and other related tools that may involve some security-related risks. The development team needs to consult the security team before deciding on what versions to use.
Stage 9: Abandon insecure functions
Commonly used functions may cause trouble, so these and API should be disabled. Instead functions recommended by the security team should be used.
Stage 10: Static analysis
Static code analysis can be done by related tools and the results compared with manual analysis.
Stage 11: Dynamic program analysis
This is complementary to static analysis, which is used to validate the safety of links.
Stage 12: Fuzzy testing
Fuzzy testing is a specialized form of dynamic analysis, which involves deliberately putting wrong format or random data into the application to trigger program failure. Fuzzy testing strategy is based on the intended use as well as the function of the application and design specifications. The security adviser may insist on additional fuzzy testing or expand the scope and increase the duration of testing as needed.
Stage 13: Threat model and the attack surface
Because of various factors like a change in requirements, the development of a project deviates from its original goals, so in a later phase of the project, it might be necessary to rebuild the threat model and conduct the attack analysis to find problems and fix them immediately.
Stage 14: Incident response plan
Whenever software is released under the constraint of SDL requirements, it must contain an incident response plan. Even if a newly released product does not contain any known vulnerabilities, it may face threats in the future. If the product contains third-party code, it is important to have the contact information of that party and include them in the incident response plan, so as to ensure that all relevant parties are present in case of emergency.
Stage 15: Final safety evaluation
Ultimate safety evaluation (FSR) is to carefully check the implementation of all the safety activities before the release of the software. FSR will come up with three different results.
- Passing FSR. All the security and privacy issues are fixed or alleviated.
- Parsing FSR with exceptions. All the security and privacy issues are fixed or alleviated. All the unexpected issues also have been addressed. Problems that cannot be solved this time will be recorded to be fixed in the next release.
- Reporting issues of FSR. If all the requirements of SDL are not met and security consultants and product team cannot compromise, security adviser cannot approve the project, and the project cannot be released. All problems must be solved before release, or be reported to senior management for decision.
Stage 16: Publish/archive
Passing FSR is a prerequisite for the product’s release, but we still need to record all kinds of problems and documents on file at the same time, to help with emergency response and product upgrade.
As we can see, the implementation of Microsoft’s SDL process is meticulous. Microsoft has also helped all product teams and partners to implement SDL with a positive outcome. In Microsoft’s SDL products, vulnerabilities are significantly lessened, making exploitation difficult.
The main difference between SAMM and Microsoft’s SDL is that SDL is suitable for software developers whose primary business is design and sale of software. SAMM is more suitable for self-developed software by users such as banks and other online service providers. Software engineering among software developers tends to be more mature with strict quality control; and self-developed software in enterprises place more emphasis on efficiency. So the practice of software engineering also differs for these two models.