Appendix O: Security Plan (Sample)

Artigo
05/22/2012

Note: This sample document is for illustration purposes only. The content presented below outlines basic criteria to consider when creating security processes. It is not a complete list of activities or criteria and should not be treated as such.

This document outlines the security activities for as they relate to each step of the Security Development Lifecycle (SDL). It describes the objective and provides a basic outline of each activity. It also identifies owners and expected deliverables from the activity. Most of the deliverables are included as exit criteria for different milestones for the project.

For successful execution of this security plan, the security team must perform security sign-offs, reviews, check-pointing, among other activities, for the security ship-readiness of the product at various project milestones. It is recommended that a “virtual” team be created, made up of individuals from program management, development, test, and UX.

The remainder of this document describes the minimum activities needed to build a secure product, the milestones during which they should be performed, and the owners and the deliverables for each activity.

Pre-SDL Requirements: Security Training

Education and Awareness

Define which types of security training are available for your personnel.
Identify who creates and/or delivers the classes.
Define where they can find information about the classes.

Phase One: Requirements

Project Inception

Determine whether the SDL applies to your component.
Identify the team or individual that is responsible for tracking and managing security for your project.
Ensure that bug reporting tools can track issues and that a database can be queried dynamically for all security issues at any time.
Define and document a project’s security bug bar.

Cost Analysis

Complete a security risk assessment.

Phase Two: Design

Establish and Follow Best Practices for Design

Create functional specifications that describe security features that are directly exposed to users.
Design specifications should describe how to implement these features, and how to implement all functionality as secure features.

Risk Analysis

Review security requirements and expectations to identify security concerns.
Complete threat models for all functionality identified during the cost analysis phase.

Phase Three: Implementation

Creating Documentation and Tools

Define security best practices documentation and tools.

Establish and Follow Best Practices for Development

Establish, communicate, and follow effective practices for developing secure code to detect and remove security issues early in the development cycle.

Phase Four: Verification

Security and Privacy Testing

Define fuzz testing, penetration, and run-time tests.
- Determine which file formats will be fuzz tested.
- Determine which networking interfaces will be fuzz tested.
- Determine which tools will be used to fuzz test files and networking interfaces.
Re-evaluate attack surface.
Re-evaluate threat models.

Security Push

Determine if there is a need for a security push.
Define the security push steps.
- Determine the timeline for the security push.
- Determine whether there will be intensive education of project staff prior to the push.
- Determine whether there are any other intensive tasks you want to focus on.
- Define how the security vulnerabilities will be tracked.

Public Release Privacy Review

Update the appropriate SDL Privacy Questionnaire for any significant privacy changes that were made during implementation verification.
Work with your privacy advisor and legal representatives to create an approved privacy disclosure.
Post the privacy disclosure to the appropriate website before each public release.

Phase Five: Release

Planning

Identify who is responsible for security servicing.
Provide contact information for people who respond to security incidents.
Ensure process are in place to handle all types of security issues—for example, code reused or inherited from other teams and code licensed from third parties.
Create a documented sustaining model that addresses the need to release immediate patches in response to security vulnerabilities and does not depend entirely on infrequent service packs.

Final Security Review and Privacy Review

Define a due date for all project information that is required to start the Final Security Review (FSR).
Review threat models.
Review security issues that were deferred or rejected for the current release.
Validate results of all security tools.
Submit exception requests to a security advisor for review.

Release to Manufacturing/Release to Web

Submit symbols for all publicly released products as part of the release process.
Design and implement a sign-off process to ensure security and other policy compliance before you ship.

Post-SDL Requirement: Response

Security Servicing and Response Execution

Develop a response plan that includes preparations for potential post-release issues.
Be available to respond to any possible security vulnerabilities that warrant a response.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

Partilhar via