The 17th chapter of the "White hat Talk web security" Study note security development process (SDL)

17th Chapter Security Development Process (SDL) 17.1 SDLIntroduction

Security development is an effective way to address security vulnerabilities from the root cause, and in the software lifecycle, this development model costs less.

SDL Process:

q Training

All developers must receive appropriate security training to understand the relevant safety knowledge.

q Safety Requirements

Define the safety requirements of the project.

q Quality door /bug Bar

quality gates and bug bars are the minimum acceptable levels for determining the quality of security and privacy.

q Security and privacy risk assessment

Assess the security status and threat model in your project

q Design Requirements

Consider safety issues at the beginning of product design

q reduce attack surface

Reducing the attack surface reduces the risk by reducing the opportunity for an attacker to exploit a potential vulnerability or vulnerability. Reducing the attack surface includes shutting down and restricting access to system services, applying the principle of least privilege, and layering defenses as much as possible.

q Threat Modeling

Establish a threat model to analyze the attacks that a project or product might encounter, and to give a solution

q using the specified tool

q Deprecated unsafe functions

q Static Analysis

q Dynamic Program Analysis

q Blur Test

Fuzzy testing is a specialized form of dynamic analysis that intentionally introduces an application to an undesirable format or triggers a program failure.

q analysis of threat model and attack surface

When requirements change, the security model also needs to be changed accordingly

q Incident Response Plan

The release of the product needs to leave the developer's contact information, as well as the corresponding documentation, to facilitate future problem solving.

q Final Security Assessment

q Publish / archive

17.2AgileSdl

The idea of Agile SDL is to implement safe work in a changing perspective. Requirements and functionality may be changing, and the code may be changing, requiring SDL to update the threat model and privacy policy at every stage, iterate on the necessary steps for fuzzy testing, code security analysis, and so on.

17.3 SDLPractical Experience

Criteria:

q fully communicate with the project manager to discharge sufficient time

q standardize the company's project process to ensure that all projects can be notified to the security team to avoid omissions

q establish the authority of the security Department and the project must be audited by the security department before it can be released

q placement of technology in the development, testing work manual

q Training security solutions for development engineers

q record all security bugsand motivate programmers to write secure code

17.4Requirements Analysis and design phase

A code base for secure programming should be established, along with some of the more common security coding issues.

17.5Development Phase

Sun 's security coding guidelines :

q Use carefully Privileged Code

q handle it carefully . static fields

q Minimize Scope (scope)

q Choose carefully Public (public) methods and Fields

q Appropriate for Packages (Package ) Protection

q use as much as possible not variable (immutable) Object

q never return a reference to an internal array that contains sensitive data

q never directly store user-supplied (user-supplied) the array

q careful use of serialization (serialization)

q use local methods with caution (Native methods)

q Clear Sensitive information

Java Safe anti-pattern

q ignoring those full-pattern code inadvertently creates a loophole.

typical of Java Secure encoding anti-pattern (antipatterns):

Ignore language features ( such as Integer overflow (Overflow))

do not pay attention to using serialization , do not pay attention to the use of privileged code

Define fields and methods to an inappropriate visibility scope

in non-final state (non-final) covert Channels in a static field (Covert Channels)

17.6testing Phase

Reference:http://blog.csdn.net/Test_sunny/article/details/4653783

Http://51CTO remind you, do not spam ads!/ceshi/ceshijishu/aqcs/2013/0715/206456.html

Http://51CTO remind you, do not spam ads!/ceshi/ceshijishu/aqcs/2012/0329/204547.html

This article is from the "dream to think XI" blog, please be sure to keep this source http://qiangmzsx.blog.51cto.com/2052549/1859569

The 17th chapter of the "White hat Talk web security" Study note security development process (SDL)