Microsoft Security Development Lifecycle (SDL) 4.1a

lunes, 23 de noviembre de 2009

Microsoft Security Development Lifecycle (SDL) 4.1a

The Microsoft Security Development Lifecycle (SDL) is an industry-Cleading software security assurance process. A Microsoft-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in Microsoft software and culture. Combining a holistic and practical approach, the SDL introduces security and privacy early and throughout all phases of the development process. It has led Microsoft to measurable and widely recognized security improvements in flagship products, such as Windows Vista® and Microsoft SQL Server®. Microsoft is publishing the detailed SDL process guidance as part of its commitment to enable a more secure and trustworthy computing ecosystem.

A new updated version of Microsoft Security Development Lifecycle has been released recently. The 125 pages whitepaper is a comprehensive set of guidelines aiming at making agile development and security best practices fit together for the first time.

In this release Microsoft indicates “7 Phases” as the hearth beating of the Security Development Lifecycle.

1.Training (Core Training)
2.Requirements (Define quality/bugs bar)
3.Design (Attack surface analysis – Threat modelling)
4.Implementation (Specify tools – Enforce banned functions – Static Analysis )
5.Verification (Dynamic / Fuzz testing – Verify threat models/attack surface )
6.Release (Response plan – Final Security Review – Release archive)
7.Response (Response execution)

For those who are new to SDLC and or to this whitepaper – read it. Anyone involved in professional software development should read carefully this document.
The Education and Awareness – Pre SDL Requirements: Security Training (for example) urge that all members of a software development team should receive appropriate training to stay informed about security basics and recent trends in security and privacy.

In fact, Microsoft suggests individuals who develop software programs should
attend at least one security training class each year.

Security Training
can help ensure software is created with security and privacy in mind and can
also help development teams stay current on security issues. Project team
members are strongly encouraged to seek additional security and privacy
education that is appropriate to their needs or products.

The entire team should remain informed about security issues in the industry. Attacks and threats evolve constantly, and staying current is important.

Another interesting part, which is new of this version is the Security Code Review. And how it’s introduced to the reader.

Security code reviews are a critical component of the Security Development Lifecycle. Given the opportunity to review old code or work on a new cool feature, developers lean towards the latter. Unsurprisingly, attackers don't target only new functionality; they will attack all code, regardless of its age. Waiting to make the code more secure in the next version of the product is not a good solution for protecting customers, and therefore, high-risk items that are considered the most sensitive and important for security should be reviewed in depth at the earliest opportunity.

Microsoft suggest to determine the most-at risk components using the following criteria and perform an in-depth security review of the code making up those components.

◦Priority 1 code is considered to be the most sensitive from a security standpoint. The following are examples of Priority 1 code, but please note this is not necessarily a definitive list. Pri 1 code is all Internet- or network-facing code, code in the Trusted Computing Base (TCB)—such as kernel or SYSTEM code, code running as administrator or Local System, code running as an elevated user (also includes LocalService and NetworkService), or features with a prior history of vulnerability, regardless of version. Any code that handles secret data, such as encryption keys and passwords, is considered Pri 1 code. For managed code, Priority 1 code is considered to be any unverifiable code (any code that the standard PEVerify.exe tool reports as not verified). All code supporting functionality exposed on the maximum attack surface is considered Pri 1 code by definition.
◦Priority 2 is optionally installed code that runs with user privilege, or code that is installed by default that doesn't meet the Priority 1 criteria.
◦Priority 3 is rarely used code and setup code. Setup code that handles secret data, such as encryption keys and passwords, is always considered Priority 1 code.