Software security development cycle-SDL

Statement. The article only represents your personal opinion and has no connection with your company.

1. Overview

Security development cycle, namely security development lifecycle (SDL), is a management model proposed by Microsoft to guide the software development process from a security perspective. SDL is not a theoretical model. It is a software development model that Microsoft develops step by step in practice to face security challenges in the real world. So what is SDL and how it is combined with the traditional software development model? Before answering these questions, Let's explain a basic question. The reader of this article, why do you consider using SDL to guide software development? 2. Why should we guide the entire software development process from a security perspective?Many readers may say that software security is very important. But these are issues that should be taken into consideration when Microsoft or other large software development vendors conduct software development. They seem to have nothing to do with me. It is not surprising to have such an idea. A: currently, security questions are not limited to operating system software. All applications face security challenges. 2.1 security challenges in the Internet environmentThe security field is one of the most active branches in computer technology. The emergence of each new technology also brings corresponding risks. Different times and technologies pose different security challenges. In the past few years, the attack modes of computers have never changed for specific purposes. Instead of simply boarding the front page of a newspaper or playing a prank, it has a specific purpose, that is, stealing users' confidential information, such as bank accounts and passwords, to obtain economic benefits. The change in purpose leads to a change in means. A few years ago, traditional attack methods mainly targeted operating system security vulnerabilities, because operating systems can cause the most extensive spread of viruses. However, the "most extensive" is no longer the purpose of the attack. As a result, the attacking software system has expanded from the operating system to various applications such as image processing, office processing, backup software, anti-virus software, and Web applications. For example, the most popular attack method, SQL injection, is not for operating systems, but for typical web applications. Specifically, if the developed application: · network-oriented functional interfaces · database-oriented applications · different levels of permission control · storing important/sensitive information should be considered for security considerations in the software development process. 2.2 limitations of traditional software development processesIn the traditional software development process, such as the waterfall model, the Center focuses on the product functions, and there is no security concerns. Therefore, it is not surprising that security software cannot be developed. Microsoft's software development process was a good example before SDL proposed. It can create software with relatively complete functions, such as earlier Windows versions, but cannot meet security requirements. Requirement Analysis. Traditional demand analysis of software development processes tends to have this tendency. Once a user uses the software, the more functions they can use, the better, and the more flexible the user's work environment. However, in reality, the more features that can be directly used, the better? It is often necessary to make a balance between flexibility and convenience and security. For example, should I disable functions that are not frequently needed by default? Software Design. In the traditional software design process, how to effectively and correctly implement functions is considered. It is often agreed that data from relevant modules is trustworthy, and user data is verified only at the interface of the peripheral data module. The consequence is that if a module has security problems, the entire software system will not be protected. Software coding and evaluation. Similarly, software coding practices focus on how to effectively and correctly implement functions. No coding and review guidance for security issues, such as the side effects of specific API functions and stack overflow errors. There is no corresponding compilation tool or static program analysis tool to check for common code security errors. Test. Designing data in the traditional black/white box mode cannot simulate a malicious attack data. This is because the traditional test data is designed according to the function documentation, and the data scope is limited to normal data and boundary conditions to simulate the normal user use environment. 2.3 insufficient knowledge structure of traditional softwareIn the past, the education on software development, such as software engineering, data structure, compilation principle, system structure, program language, etc., did not have any knowledge about software security. If developers do not fully understand security issues, do not understand the basic principles of security design, common types of security vulnerabilities, and how to design security-targeted test data, the developed code is naturally more likely to have security vulnerabilities. For example, the following code [2, p147] shows the security vulnerabilities in Windows RPC calls. It is the root cause of the explosion of the shock wave virus (blster. Didn't you think it was that simple? So what is the problem with this code? Hresult getmachinename (wchar * pwszpath) {wchar wszmachinename [n + 1];... lpwstr pwszservename = wszmachinename; while (* pwszpath! = L' // ') * pwszservername ++ = * pwszpath ++;...} If you have seen the problem, congratulations! Most developers do not know the correct answer before they pass security training. The problem with the code is that the string length of pwszpath is not verified, resulting in overflow of the wszmachinename stack variable. It should be emphasized here that the knowledge of software security is not the understanding and use of security functions. For example, the principle of encryption and decryption, the use of SSL, and so on. Understanding this knowledge is useful, but only understanding the use of SSL does not guarantee the security of the network software. 2.4 instance: Data from MicrosoftWindows Server 2003 is Microsoft's first large-scale implementation of SDL in operating system development. Although Windows Server 2003 is not developed from the beginning to the end in strict accordance with the SDL specification, we can see from the data shown in Figure 1 that, SDL greatly reduces the security vulnerabilities of operating system software. Data comes from [1]. Figure 1 Comparison of Windows 2000 and Windows Server 2003 Security Vulnerabilities 3. How to Apply SDL to traditional software development models 3.1 SDL SummaryFigure 2: SDL Development Mode

Figure 2 is a simplified SDL development model. The core concept of SDL is to integrate software security considerations into every stage of Software Development: requirement analysis, design, coding, testing, and maintenance.

Why is this simplified SDL? · Traditional software development models, such as Waterfall models, are simplified models. In actual development, demand analysis, design, development, and testing are a repeating spiral development model (spiral model ). The requirement analysis and design documents are modified several times. The impact on software security should be considered during each modification. · The complete SDL model also includes several more detailed stages. For example, the final security review (FSR) phase before the product is officially released. For more information, see [2. · This model does not include training and education for engineering personnel. A good process, if there is no corresponding engineering personnel to implement, will also be on paper. One of the ways to educate engineers is to change concepts and enhance security awareness. Second, master basic security knowledge. 3.1.1 sd3 + C PrinciplesSd3 + c is the basic principle of implementing SDL summarized by Microsoft. · Secure by design ). The Design and Implementation of Software should consider how to protect itself (and the stored information) against external attacks. · Secure by default ). How to reduce security risks should be considered for the default software configuration runtime environment. An important assumption is that there are always security vulnerabilities in the software code. So how can we reduce the harm of these security vulnerabilities? For example, can I run on Common User Permissions without administrator permissions? Can some high-risk code modules be disabled by default? · Secure deployment (secure in deployment ). The software must provide relevant documents and tools to guide users on how to use the software safely. · Communication ). Developers need to prepare a response to the security vulnerabilities in the released product. 3.2 Requirement Analysis: Set security objectivesIn the demand analysis stage, add the following security considerations: · security functions provided by the product · how the product securely interacts with users (or other software modules) · special, security considerations affect the product development plan. · Product risk assessment and threat model (Threat modeling) · default product function configuration 3.3 security designIn the security design phase, the following two aspects are particularly considered. · Reduce attack interfaces. For example, if a network software is designed to listen to those Network Ports, can it reduce the number of listening ports? Which users can establish connections with these ports, do they need to enhance authentication? · Deep defense. In the design of the underlying module, it is assumed that the upper module may have security vulnerabilities. Further verification of transmitted data is considered. 3.4 How to Avoid code security problemsEvery developer must follow the security coding rules. · Use the latest compiler and compilation options. For Microsoft's latest C/C ++ compiler, use the following two compilation options: ·/GS options. Add additional code to detect function stack cache overflow errors. ·/Safeseh option. Add additional exception handling information to ensure that the Code is called legally, rather than the exception handling program that has been illegally tampered. · Prohibit the use of specific dangerous APIs. Many security vulnerabilities are caused by improper use of dangerous API functions. Common dangerous functions such as strcpy, strcat, sprintf, and strlen. These dangerous functions have been marked as "deprecated" in the latest C Language Runtime Library ". For more information, see [3. To replace these functions, consider using strsafe defined functions. The specific ions are not provided here. [4] includes detailed information about strsafe. · Use static language analysis tools to scan Security Vulnerabilities · regularly review Security Code 3.5 Security Test: Simulate malicious inputThe concept of fuzz testing is introduced in security testing. Its main purpose is to create malicious input data to simulate the behavior of software under malicious attacks. Fuzz testing can include file testing, network data testing, user interface input data testing, and so on. We use the AVI file to illustrate a typical fuzz test. The following is the definition of AVI Header: typedef struct _ avimainheader {... DWORD dwstreams; DWORD dwsuggestedbuffersize; DWORD dwwidth; DWORD dwheight ;...} avimainheader; if the general range of dwsuggestedbuffersize is 1 K-4 K, the following code will not be faulty under normal circumstances. Dwsuggestedbuffersize = pbuffer-> getdw (); m_psuggestedbuffer = new char [dwsuggestedbuffersize]; but if we maliciously set this input variable value to 0 xFFFF In the fuzz test, it may be found that it leads to a system memory allocation error, which can avoid a DoS (Deny of Service) vulnerability on the client/server. Based on the fuzz principle, we also design other test data based on the structure information of the AVI Header, such:

• Malicious dwstreams
• Malicious image size: dwwidth, dwheight
• No or multiple AVI headers, etc.

  3.6 security response and maintenance: Emergency ResponseCurrently, any software development model (including SDL) cannot ensure that the released software has no security vulnerabilities. Therefore, a corresponding model needs to be developed in advance, including:

• (Detected internally or externally) How to report Security Vulnerabilities
• How to assess the severity of Security Vulnerabilities
• Security Patch Development Process
• Security patch testing process
• Security patch release process
• How to avoid similar security vulnerabilities in future development

  4. SummaryPractice has proved that SDL can effectively reduce software security vulnerabilities and improve software security. But it is not omnipotent. Software that implements SDL development cannot completely avoid security vulnerabilities. For example, Windows Vista is developed in strict accordance with SDL, but it still has security vulnerabilities. However, we expect that the number and severity of security vulnerabilities will be much less than the previous operating system. There is no free lunch in the security field. SDL implementation requires time, energy, education, management, and other support. However, if you don't buy this lunch, the dinner bill may be much higher than you think. Limited by space, only one general description of SDL can be made here. For more information, see references in the appendix. 5. References

1. The trustworthy computing security development lifecycle, Steve lipner, Michael Howard

2. The security development lifecycle, Michael Howard, Steve lipner

3. deprecated CRT functions,Http://msdn2.microsoft.com/en-us/library/ms235384 (vs.80). aspx, Microsoft Corporation

4. Using the strsafe. h functions, http://msdn2.microsoft.com/en-us/library/ms647466.aspx, Microsoft Corporation