<<Project Name>>

Security Plan

 

Customer Name

 

 

 

 

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

 

Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ó 2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

 


 

Revision & Sign-off Sheet

Change Record

Date

Author

Version

Change Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reviewers

Name

Version Approved

Position

Date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Distribution

Name

Position

 

 

 

 

 

 

 

 

 

Document Properties

Item

Details

Document Title

Security Plan

Author

 

Creation Date

 

Last Updated

 

 


 

Table of Contents

 

Summary

Solution Overview and Owner

Objectives

Solution Description

Assignment of Security Responsibility

General Solution Description

Solution Environment

Solution Interconnection and Information Sharing

Information Sensitivity and Criticality Assessment

Threats

Management Controls

Risk Assessment and Management

Review of Security Controls

Rules of Behavior

Operational Controls

Personnel Security

Sensitivity Level

Required Background Screenings

Restriction of User Access

Process for User Accounts

Separation of Duties

User Accountability

Termination Procedures

Physical and Environmental Protection

Production and Information Controls

Contingency Planning

System Hardware and Software Maintenance Controls

Data Integrity/Validation Controls

Incident Response Capability

Documentation

Security Awareness and Training

Technical Controls

Identification and Authentication

Password Policy

Account Lockout Policy

Kerberos Policy

Logical Access Controls

Public Access Controls

Audit Policy

Ongoing Security Management

Appendix A: Security Definitions

Appendix B: Guidelines for Ongoing Security Management


 

[Introduction to the Template

 

Description: The Security Plan describes how the solution will be brought to acceptable security levels in order to operate successfully. This plan describes what security threats will exist and how implementing security standards will mitigate those.

 

Justification: The Security Plan will identify development, test, and deployment activities that will design, build, and implement a secure solution. Those activities will be incorporated into the teams’ plans and increase customer confidence that the solution will meet with security expectations. The process of developing the Security Plan produces a series of security standards intended to reduce the security risks to an acceptable level. Before these security standards can be implemented, the customer should decide whether the implementation costs of the measures is aligned with risk reduction, and whether the risks are reduced to an acceptable level.

 

{Team Role Primary: Release Management is responsible for the development of the Security plan. Development plays a primary role in providing content to the plan that ensures that technical implementation of the security features is feasible. Program Management ensures that the Security Plan in developed with quality and is incorporated into the Master Project Plan. 

 

Team Role Secondary: All roles are responsible for reviewing the plan to ensure its execution is feasible.}]

 


 

Summary

[Description: Provide an overall summary of the contents of this document.

 

Justification: Some readers may need to know only the highlights of the plan, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]

<<Begin text here>>

 

Solution Overview and Owner

[Description: The Solution Overview and Owner section describes the overall solution and how critical the solution is in the organization. This should include the name of the group responsible for the solution and the specific owners of the solution (name, title, address, phone and fax number, email address).]

<<Begin text here>>

 

Objectives

[Description: The Objectives section defines the primary drivers that were used to create the security approach and the key objectives of that approach. A secure solution would typically have the following objectives:

 

 

Justification: Identifying the drivers and objectives signals to the customer that Microsoft has carefully considered the situation and created an appropriate security approach.]

<<Begin text here>>

 

Solution Description

[Description: The Solution Description section provides descriptive information on the solution in general and the aspects of the solution that present security issues.

 

Justification: This information is the basis for developing security requirements, as it identifies scenarios that demand security analysis.]

<<Begin text here>>

 

Assignment of Security Responsibility

[Description: The Assignment of Security Responsibility section describes the roles and responsibilities of all users having access to the solution. This should include the approximate number of authorized users and their physical locations.]

<<Begin text here>>

 

General Solution Description

[Description: The General Solution Description section describes the solution’s function or purpose and the information it processes. Describe the processing flow of the solution from input to output. List user organizations (internal & external) and the type of data and processing provided to them.]

<<Begin text here>>

 

Solution Environment

[Description: The Solution Environment section provides a general description of the solution’s environmental or technical factors that raise special security concerns (dial-up lines, open network, etc.) Include a diagram of architecture here or in an Appendix, if applicable. Describe the primary computing platform(s) used and the principal solution components, including hardware, software, and communications resource. Include any security software protecting the solution and information. List the physical location(s) of the solution.]

<<Begin text here>>

 

Solution Interconnection and Information Sharing

[Description: Organizations may consider requiring that a written authorization, such as a statement of understanding or agreement, be obtained prior to connection with other solutions and/or sharing sensitive data/information. The Solution Interconnection and Information Sharing section lists all those interconnections and identifies any such agreements. If the solution is to be connected to an external system not covered by a security plan, provide a brief discussion of any security concerns that need to be considered for protection. This section should also include a description of the rules for interconnecting systems and for protecting shared data.]

<<Begin text here>>

 

Information Sensitivity and Criticality Assessment

[Description: The Information Sensitivity and Criticality Assessment section describes, in general terms, the information handled by the solution and the need for protective measures. It should list the types of sensitive information the solution accesses. Examples may include administrative, financial, grant/contract, patient, proprietary, research, Privacy Act. Each of the information types should be characterized using the three basic protection requirements (confidentiality, integrity, and availability). The level of protection required is determined by an evaluation of the sensitivity and criticality of the information processed, the relationship of the solution to the organization's mission, and the economic value of the solution components.

 

Use the sensitivity and criticality definitions found in the Appendix

 

Below are two tables that can be used to define solution protection requirements. The second is more granular. Select the level of detail appropriate to your project. It may be applicable to include a statement of the estimated risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information in the solution.]

 

System Protection Requirements

High

Medium

Low

Confidentiality

 

 

 

Integrity

 

 

 

Availability

 

 

 

 

Information Type

Confidentiality (High, Medium or Low)

Integrity

Availability

Administrative

 

 

 

Financial

 

 

 

Grant/Contract

 

 

 

Patient

 

 

 

Proprietary

 

 

 

Research

 

 

 

Privacy Act

 

 

 

Other (specify)

 

 

 

 

Threats

[Description: The Threats section provides a comprehensive analysis of the possible threats to the solution. A classification of the different kinds of threats to quality information delivery is suggested in the following table. This includes deliberate and non-deliberate threats. This is not meant to be exhaustive – add threats appropriate to the subject solution.

 

Using the MSF Risk management approach, generate a baseline list of security threats and estimate 1) the probability of the threat being realized and 2) the magnitude or impact of the loss should that risk occur. Probability will be estimated using a 0 (low) to 1 (high) scale for risk probability and a 1 (low) to 5 (high) for risk impact. The product of probability times impact yields risk exposure. Risks will be prioritized by the magnitude of risk exposure and appropriate mitigation and contingency plans developed for the highest priority risks.

 

Impact:

 

 

 

Impact on Solution

Risk Probability

Mitigation plan or contingency plan

 

Data completeness

Data Accuracy

Data access

Unauthorized data access

á -High

â - Low

 

(Modify as necessary)

Environmental

 

Fire

 

 

 

 

 

Offsite backup, business continuity plan

Flood

 

 

 

 

 

Offsite backup, raised floors, business continuity plan

Storm (including lightning)

 

 

 

 

 

Surge protectors, go offline during lightning policy

Earthquake

 

 

 

 

 

Offsite backup, business continuity plan

Heat

 

 

 

 

 

Monitored, temperature controlled room, temperature monitors inside servers, fan and filter inspections

Cold

 

 

 

 

 

Monitored, temperature controlled room

Static electricity

 

 

 

 

 

Grounding cables

Sprinklers

 

 

 

 

 

Offsite backup, business continuity plan

Dust and dirt

 

 

 

 

 

Regular inspection and replacement of dust filters

“Technology”

Power surges or sags

 

 

 

 

 

UPS with sag protection

Power interruption

 

 

 

 

 

UPS with battery backup

Magnetic

 

 

 

 

 

“No magnets” policies

Computer vulnerabilities

 

 

 

 

 

 

Hard drives

 

 

 

 

 

RAID, Backups, locks, format before reuse policy, large SCSI drives

Power supplies

 

 

 

 

 

Redundancy

Cables and connectors

 

 

 

 

 

Physical security, documentation, labeling, audits

Memory

 

 

 

 

 

Maximum memory

CPU speed

 

 

 

 

 

Upgradeable multiprocessor machines

Other semiconductor components

 

 

 

 

 

Hardware standard configurations

Router vulnerabilities

 

 

 

 

 

Redundancy, documentation, audits, training

Packet filters

 

 

 

 

 

Redundancy, documentation, audits, training

Software vulnerabilities

 

 

 

 

 

 

Software design

 

 

 

 

 

Design reviews, managed development process, training, setting constraints and identifying limits

Software construction

 

 

 

 

 

Code reviews, managed development process, training, source code control

Software testing

 

 

 

 

 

Code reviews, managed development process, dedicated test engineers, automated testing tools, training

Software documentation

 

 

 

 

 

Managed development process, documentation standards, document version control

Configuration errors

 

 

 

 

 

Training, documentation, audits, automated deployment

License limits exceeded

 

 

 

 

 

Auditing, training

Networking and telecommunications vulnerabilities

 

 

 

 

 

 

Domain or account design

 

 

 

 

 

Training, documentation, audits, use of NT

Resource access control

 

 

 

 

 

Training, documentation, audits, use of NT

Transmitting passwords in the clear

 

 

 

 

 

Training, configuration documentation, use of NT, DPA and SSL or other encryption methods

Failure to use authentication methods

 

 

 

 

 

Training, configuration documentation, use of NT, DPA, and SSL or other authentication methods

Packet filter configuration errors

 

 

 

 

 

Training, configuration documentation

Modem dialup (RAS)

 

 

 

 

 

Separate security policies, call-back, NT, RADIUS, audits, RAS policies, training

Management systems configuration

 

 

 

 

 

Training, configuration, audits

“Human Activity”

Password loss or compromise

 

 

 

 

 

Training, policies, use of strong password technologies

Introduction of viruses, worms, etc.

 

 

 

 

 

Training, policies, virus scanning software

Deliberate Attacks on data integrity

 

 

 

 

 

Virus scanning software, training, data access policies, NTFS, password protection of resources

“User error”

 

 

 

 

 

Training, software design and configuration, audits, backups, policies, limiting user rights

Software reconfiguration

 

 

 

 

 

Backups, limiting administrator rights, policies, configuration documentation, training, use of “Locked-down” desktop configuration

Trojan horses

 

 

 

 

 

Use “trusted code” or components from “trusted” sources

Trapdoors

 

 

 

 

 

Use “trusted code” or components from “trusted” sources

Registry attacks

 

 

 

 

 

Physical security of servers, limit access to NT registry

Unapproved software installation

 

 

 

 

 

Training, policies, audits

Excessive use of bandwidth

 

 

 

 

 

Planning, performance monitoring, training

Unauthorized internal users

 

 

 

 

 

NT security accounts, monitoring, strong passwords, principle of least privilege

Denial of service attacks

 

 

 

 

 

Service Packs, Proxy, Training

Theft

 

 

 

 

 

Physical security, locks, training, policies

Data theft via copy

 

 

 

 

 

Physical security, locks, training, policies, auditing

Hardware theft

 

 

 

 

 

Physical security, locks, training, policies

Laptops with dialup capability

 

 

 

 

 

Do not “save password,” separate RAS passwords, dialback, training, policies

Backup tapes

 

 

 

 

 

Training, policies and procedures, auditing, testing, offsite storage, physical security

Evolving Environmental Constraints

Legislation (e.g. regarding length of cryptographic keys for export, or use of encryption)

 

 

 

 

 

Follow standards bodies. Use industry standards when possible

Public opinion

 

 

 

 

 

Use industry standards when possible, have standard, documented operational procedures with periodic review process

 

Management Controls

[Description: The Management Controls section describes the management-level approach to controlling security for the solution. This includes risk assessment processes, risk reviews, and the behavioral expectations of all individuals who work within the solution.]

 

Risk Assessment and Management

[Description: The Risk Assessment and Management section describes the risk assessment methodology to be used to continuously identify the threats and vulnerabilities of the solution. This should include information about any existing assessments and those conducted in the future. For existing assessments, state who conducted it and when. For future assessments, identify the group that will conduct the assessment and the expected frequency of that assessment. If there is no existing solution risk assessment, include a milestone date (month and year) for its completion.]

<<Begin text here>>

 

Review of Security Controls

[Description: The Review of Security Controls section identifies any independent security reviews that will be conducted on the solution. Include information about the type of security evaluation to be performed, who will performed the review, and the purpose of the review.]

<<Begin text here>>

 

Rules of Behavior

[Description: The Rules of Behavior section describes the written set of rules of behavior established for the solution. These should be made available to every user prior to the user receiving access to the solution with a signature page to acknowledge receipt. The rules of behavior should clearly delineate responsibilities and expected behavior of all individuals with access to the solution. They should state the consequences of inconsistent behavior or non-compliance. They should also include appropriate limits on interconnections to other solution.]

<<Begin text here>>

 

Operational Controls

[Description: The Operational Controls section describes the operational-level approach to controlling security for the solution. This includes personnel controls, physical and environmental protections, and other operational security processes.]

<<Begin text here>>

 

Personnel Security

[Description: The Personnel Security section defines how the solution users will be managed to ensure security.]

<<Begin text here>>

 

Sensitivity Level

[Description: The Sensitivity Level section describes how positions are reviewed for sensitivity level.]

<<Begin text here>>

 

Required Background Screenings

[Description: The Required Background Screenings section describes any background screenings that are appropriate for positions to which employees are assigned.]

<<Begin text here>>

 

Restriction of User Access

[Description: The Restriction of User Access section describes how user access is restricted to the minimum amount necessary to perform their assignments.]

<<Begin text here>>

 

Process for User Accounts

[Description: The Process for User Accounts section describes the process for requesting, establishing, issuing, and closing user accounts.]

<<Begin text here>>

 

Separation of Duties

[Description: The Separation of Duties section describes how critical functions are divided among different individuals.]

<<Begin text here>>

 

User Accountability

[Description: The User Accountability section describes the mechanisms that are in place for holding users responsible for their actions.]

<<Begin text here>>

 

Termination Procedures

[Description: The Termination Procedures section describes the friendly and unfriendly user termination procedures.]

<<Begin text here>>

 

Physical and Environmental Protection

[Description: The Physical and Environmental Protection section describes the physical protection in the area where solution processing takes place (e.g., locks on terminals, physical barriers around the building and processing area, etc.). Factors to address include physical access, fire safety, failure of supporting utilities, structural collapse, plumbing leaks, interception of data, mobile and portable systems.]

<<Begin text here>>

 

Production and Information Controls

[Description:  The Production and Information Controls section provides a synopsis of the procedures that support the solution’s operations. Describe the controls used for the processing, storing, and disposing of information and media as well as the labeling and distribution procedures for the information. The controls used to monitor the installation of software updates should also be listed. Below is a sampling of topics that may be reported in this section:

 

 

<<Begin text here>>

 

Contingency Planning

[Description: The Contingency Planning section briefly describes the contingency plan that would be followed to ensure the solution continues to be processed if the supporting IT system were unavailable. If a formal Backup and Recovery Plan has been completed, reference the plan. The contingency plan should include descriptions for the following:

 

 

<<Begin text here>>

System Hardware and Software Maintenance Controls

[Description: The System Hardware and Software Maintenance Controls section briefly describes the plans that involve the maintenance of solution hardware and software. The plan should include descriptions for the following:

 

·        Is there version control that allows association of components to the appropriate application/system version?

·        Are all changes to the solution components documented?

·        Are there impact analyses to determine the effect of proposed changes on existing security control to include the required training for both technical and user communities associated with the change in hardware/software?

·        Are there change identification, approval, and documentation procedures?

·        Are there procedures for ensuring contingency plans and other associated documentation are updated to reflect system changes?]

 

<<Begin text here>>

 

Data Integrity/Validation Controls

[Description: The Data Integrity/Validation Controls section briefly describes the plans that involve the maintenance of data integrity/validation controls. The plan should include descriptions for the following:

 

·        Is virus detection and elimination software installed? If so, are there procedures for updating virus signature files, automatic and/or manual virus scans, and virus eradication and reporting?

·        Are integrity verification tools or programs used by the solution to look for evidence of data tampering, errors, and omissions?

·        Is an intrusion detection tool installed to monitor the solution?

·        Are procedures in place to handle and close out security incidents?

·        Are other network security software packages used?

·        Is solution performance monitoring used to analyze performance logs in real time to look for availability problems, including active attacks, and solution and network slowdowns and crashes?]

 

<<Begin text here>>

 

Incident Response Capability

[Description:  The Incident Response Capability section briefly describes the plans that involve the maintenance of incident reporting. The plan should include descriptions for the following:

 

 

<<Begin text here>>

 

Documentation

[Description: The Documentation section defines the documentation (descriptions of the hardware and software, policies, procedures, and approvals) related to information security in the solution. Describe the procedure used to update any documentation. Also list the physical location of documentation. Examples may include:

 

·        Design specifications

 

<<Begin text here>>

Security Awareness and Training

[Description: The Security Awareness and Training section describes the type and frequency of solution-specific security training provided to employees and contractor personnel (workshops, formal classroom, focus groups, role-based training, and on-the-job training). It also describes the procedures for assuring that employees and contractor personnel have been provided adequate training.]

<<Begin text here>>

 

Technical Controls

[Description: The Technical Controls section describes the technical controls for ensuring the solution’s security. This includes identification, authentication, and access policies and controls.]

 

Identification and Authentication

[Description: The Identification and Authentication section describes the solution’s user authentication control mechanisms (password, token, and biometrics). Indicate the frequency of password changes, describe how changes are enforced, and identify who changes the passwords (the user, the system administrator, or the application/system. The following three sub-sections should be completed if an additional password system is used in the solution.]

<<Begin text here>>

 

Password Policy

 

 

<<Begin text here>>

Account Lockout Policy

 

<<Begin text here>>

Kerberos Policy

[Description: Describe how user logon restrictions are enforced and maximum lifetime for user ticket.]

<<Begin text here>>

 

Logical Access Controls

[Description: The Logical Access Controls section describes the controls in place to authorize or restrict the activities of users and personnel within the solution. Describe hardware or software features that are designed to permit only authorized access to or within the solution, to restrict users to authorized transactions and functions, and/or to detect unauthorized activities. The following may apply:

 

 

<<Begin text here>>

 

Public Access Controls

[Description: The Public Access Control section applies if the public accesses the solution. This section describes the additional security controls used to protect the solution's integrity and to protect the confidence of the public in the solution. Such controls include segregating information made directly accessible to the public from official agency records. Others may include:

 

·        Some form of identification and authentication

·        Access controls to limit what the user can read, write, modify, or delete

·        Controls to prevent public users from modifying information in the system

·        Digital signatures

·        CD-ROM for on-line storage of information for distribution

·        Copies of information for public access available on a separate system

·        Controls to prohibit the public from accessing live databases

·        Verification that programs and information distributed to the public are virus-free

·        Audit trails and user confidentiality

·        System and data availability

·        Legal consideration]

 

<<Begin text here>>

 

Audit Policy

[Description: The Audit Policy section briefly describes the following elements of an audit policy:

 

 

<<Begin text here>>

 

Ongoing Security Management

[Description: The Ongoing Security Management section addresses the process of determining if the security standards are in place and adhered to, if they fulfill the requirements during operation, and if they are still relevant or should be altered after changes have taken place. This section should address three elements of this process:

 

 

Guidelines for these processes can be found in Appendix B.]


 

Appendix A: Security Definitions

 

[Sensitivity:

 

Confidentiality refers to information that requires protection from unauthorized disclosure.

 

Integrity refers to information that must be protected from unauthorized, unanticipated, or unintentional modification.

 

Availability refers to information or services that must be available on a timely basis to meet mission requirements.

 

 

Criticality:

 

Low Sensitivity information requires a minimal amount of protection. This level includes information considered to be in the public domain.

 

Medium Sensitivity includes important data that must be protected from unauthorized alteration. This level includes information pertaining to correspondence and other document files whose release needs to be controlled.

 

High Sensitivity information requires the greatest safeguards at the user level. High sensitivity information includes, but is not limited to, highly critical or proprietary information, financial or grant data, or records subject to the Privacy Act.]

 


 

Appendix B: Guidelines for Ongoing Security Management

 

[Maintaining the Level of Security

 

The level of security attained after implementing the corporate security standard can only be maintained if:

 

 

 

 

 

 

 

Checking the use of Corporate Security Standards

 

In order to maintain the level of security required, it must be ensured that all corporate security standards are employed in precisely the manner described in the Security Plan.

 

This must be guaranteed for all solutions during both the planning and operation stages. Checks should be carried out as to whether the proper security standards have been completely and correctly implemented. Periodical tests should be carried out as to whether these corporate security standards are used correctly, adhered to and whether they are accepted. Random testing can be useful in this regard.

 

Assessment reports should be compiled automatically as part of the corporate security standards. The results of these checks should be passed on to a corporate security officer and the IT security group so that appropriate action can be taken should problems arise.

 

Checking Targets and Reaction to Changes

 

By checking the targets, management should get a clear picture of

 

 

 

In the event that these checks show that the actual risk differs from the accepted risk defined in the security goals, resources should be made available in order to change this situation. Moreover, it should be ensured that all changes regarding security are handled correctly. For example:

 

 

 

 

These changes have a significant effect on the security risks and should be detected as soon as possible in order to allow action to be taken in good time.]