How to create a secure system. A brief introduction to SDL

When developing any software system, be it a simple website, a desktop application, or a complex three-link complex, security issues arise sooner or later. 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, the vectors of attacks and their consequences can have very different character. Perhaps, from time to time, someone in the team conducts a security analysis of the system being developed, a simulation is being conducted. Much worse if these questions are left for later. The results can be very deplorable if your system is hacked in commercial use and you have to in a hurry to create fixes for the detected flaw. Obviously, security issues are best dealt with, starting from the earliest stages of creating a system, such as requirements analysis and architectural modeling. But it is best to do this throughout the entire life cycle of the system, integrating in the development process special steps designed to address these issues. One of these processes is the Security Development Lifecycle, a set of practices aimed at improving the security of the systems being developed.

What is Security Development Lifecycle

SDL is a process that allows you to ensure the necessary level of security of the developed system. SDL is based on the practice of the team focused on training, reporting and direct actions related to the safety analysis of the system being developed and the implementation of mechanisms aimed at improving security. These practices in the form of concrete steps easily fall on the usual spiral cycle of software development.

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

Before implementing SDL: Training

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

Safe design

• Reduced attack areas
• Deep protection
• Principle of least privilege
• Default security

Threat modeling, including the following topics:

• Overview of threat models
• Impact of threat model on design
• Coding style 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: best design practices
• Risk audit
• Privacy: best development 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 pass this training.

Requirement Analysis: What to Consider in the Security Context

Already at the level of analyzing system requirements, important safety aspects need to be considered. At the same time, it is important to distinguish between “safe requirements” and “safety requirements”. There is a 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 designed to identify functional requirements that have the need for in-depth study of safety related issues. Such an audit may include the following information:

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

Design with safety

When designing applications, you can also apply a number of practices that will help increase the security of the application. The first is the reduction of the surface area of ​​possible attacks (Attack Surface Reduction) and the modeling of threats. Despite the close interconnection of these two concepts, the first mechanism involves actively reducing the attacker's ability 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. Modeling threats, in turn, suggests which components of the system can be considered as attack vectors. A convenient tool for modeling threats is the Microsoft Thread Modeling Tool based on the STRIDE classification.

Implementation with security

The implementation phase is usually the most time consuming part of the project. To facilitate this task a lot of tools, technologies and ready-made components are used. In the security context, it is important that the list of this toolkit be recorded in advance. The recommended approach is to create a list of tools allowed for implementation. Wherever it is possible to exclude or specifically designate the use of unsafe or outdated functions and components. In addition, the use of automated tools such as static code analysis is important.

Phase verification (testing) with regard to security

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

Security Phase Release

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

What's next

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

If you want to learn more about SDL, watch the live broadcast of the reports of the Microsoft Secure Software Development Conference tomorrow. Including there will be reports by Alex Lucas "The Evolution of the SDL Safe Development Cycle", Glenn Pitavey "Implementation of the SDL".