Appendix O: Security Plan (Sample)

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.

On This Page

Pre-SDL Requirements: Security Training
Phase One: Requirements
Phase Two: Design
Phase Three: Implementation
Phase Four: Verification
Phase Five: Release
Post-SDL Requirement: Response

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