How to create secure systems. A brief introduction to SDL

When developing any software system, whether it is a simple website, desktop application or a complex three-link system, sooner or later security issues arise. It cannot be ruled out that the system you are developing will be attacked in some way. Moreover, depending on the type of system, its complexity, the applied technological solutions, attack vectors and their consequences can be of very different nature. Perhaps, from time to time, someone in the team carries out a security analysis of the developed system, modeling is carried out. Much worse if these questions are left for later. The results can be very disastrous if your system is hacked in commercial operation mode and you have to hurry to create corrections for a discovered flaw. Security issues are obviously best addressed. starting from the earliest stages of creating a system, such as requirements analysis and architectural modeling. But it’s best to do this throughout the entire life cycle of the system, integrating special steps in the development process designed to address these issues. One of these processes is Security Development Lifecycle - a set of practices aimed at improving the security of developed systems.

What is Security Development Lifecycle

SDL is a process that allows you to verify the required level of security of the developed system. SDL is based on practices aimed at training the team, preparing reports and direct actions related to the security analysis of the developed system and the implementation of mechanisms aimed at improving security. These practices in the form of concrete steps easily fit into the familiar spiral software development cycle.

Some of these practices alone can improve the security of the system being developed. But experience shows that their use as part of the development process can significantly improve the result and reduce costs.

Before Deploying SDL: Training

All team members, before directly starting development, must undergo a safety training and study important points related to current trends in this area. The basic level of this training should include:

Safe Design

• Decreased attack areas
• Deep defense
• Principle of least privilege
• Default security

Threat modeling, including the following topics:

• Threat Model Overview
• Impact of the threat model on the design
• Threat model restrictions based on threat model

Secure coding, including the following topics:

• Buffer overflow (for C and C ++ applications)
• Integer arithmetic errors (for C and C ++ applications)
• Cross-site scripting (for web applications)
• SQL injection (for applications interacting with the database)
• Weak cryptography

Security testing, including the following topics:

• Differences between Security Testing and Functional Testing
• Risk audit
• Security Testing Methods

Ensuring privacy, including the following topics:

• Types of Private Information
• Privacy: design best practices
• Risk audit
• Privacy: best practices
• Privacy: Best Testing Practices

Of course, when studying these topics, it is necessary to take into account the role (tester, developer, manager, analyst), however, it is very important that all team members undergo this training.

Requirement Analysis: Things to Consider in the Security Context

Already at the level of analysis of system requirements, important aspects related to security must be taken into account. At the same time, it is important to distinguish between “safe requirements” and “safety requirements”. There is a certain set of practices in the SDL, and several of these practices, “Security and Privacy Requirements Analysis,” can be applied at the requirements analysis stage. This practice is intended to identify functional requirements that require in-depth study of security-related issues. Such an audit may include the following information:

1. What part of the software requires threat analysis before release?
2. What part of the software requires design analysis in the context of security?
3. What part of the software requires additional analysis of the threat of penetration by an independent group?
4. Are there additional safety issues and risks that can be mitigated?
5. The boundaries of fuzzy testing in a security context.
6. What is the level of threat of disclosure of private data?

Safety Design

When designing applications, you can also apply a number of practices that can help improve application security. First of all, this is a reduction in the surface area of ​​possible attacks (Attack Surface Reduction) and threat modeling. Despite the close relationship between these two concepts, the first mechanism involves an active reduction in the ability of an attacker to exploit unknown security holes. To reduce the area of ​​possible attacks, you can apply layer-by-layer defense mechanisms and the principles of least privilege. Threat modeling, in turn, suggests which system components can be considered as attack vectors. A convenient tool for modeling threats is the Microsoft Thread Modeling Tool based on the STRIDE classification.

Security Implementation

The implementation phase is usually the most time-consuming part of the project. To facilitate this task, many tools, technologies and off-the-shelf components are used. In the security context, it is important that the list of this toolkit is pre-recorded. The recommended approach is the formation of a list of tools allowed during implementation. Wherever it is possible to exclude or specifically designate the use of unsafe or obsolete functions and components. In addition, the use of automated tools such as static code analysis is important.

Security verification (testing) phase

At this phase, it is possible to use practices such as dynamic code analysis (at runtime) that allows you to quickly identify abnormal behavior of functions, memory corruption, the use of privileged functions and other critical problems. One of the tools that can come in handy for solving this problem is AppVerifier. In addition to the standard functional tests, you should also add floating testing that is designed to test the application in the mode of entering incorrect data, incorrectly formed parameters and other conditions that can lead to abnormal behavior, but at the same time, the system should be in a safe state. Also at this stage, it is important to verify the simulated attack vectors in the previous phases in order to verify the correctness of the generated models.

Security Release Release Phase

At this phase, it is important to create a plan for the response of security incidents in which the order of interaction and reaction to identified threats or penetration will be declared. Final releases (RTM, RTW) must meet all pre-deployment security conditions agreed upon at the design stage before deployment. If this is not the case, even if all functional requirements are met, a repeat of the standard development cycle is necessary to fix security-related problems.

What's next

Of course, this note only reveals the most basic aspects of SDL, and further study is required for a successful application. The MSDN Security Center can help .

If you want to learn more about SDL, see tomorrow a live broadcast of the Microsoft Secure Software Development Conference . Among them there will be reports by Alex Lucas “Evolution of the Safe SDL Development Cycle”, Glenn Pitaveya “Implementation of SDL”.