[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:

• Data is complete: no data has been lost
• Data is accurate: no data has been corrupted
• Data is accessible: authorized users can access the data in a timely and useful fashion
• No unauthorized access: only authorized users access data

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.]

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:

• Data is complete: no data has been lost
• Data is accurate: no data has been corrupted
• Data is accessible: authorized users can access the data in a timely and useful fashion
• No unauthorized access: only authorized users access data]

	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:

• Is there a Help Desk or group that offers advice and can respond to security incidents in a timely manner?
• Are there procedures in place documenting how to recognize, handle, report, and track incidents and/or problems?
• Do these procedures outline how to categorize and prioritize incidents?
• Are there procedures to ensure unauthorized individuals cannot read, copy, alter, or steal printed or electronic information?
• Are there procedures for ensuring that only authorized users pick up, receive, or deliver input and output information and media?
• Are there audit trails for receipt of sensitive inputs/outputs?
• Are there procedures for restricting access to output products?
• Is there internal/external labeling for sensitivity (e.g., Privacy Act, Proprietary?)
• Is there external labeling with special handling instructions (e.g., log/inventory identifiers, controlled access, special storage instructions, release or destruction dates)?
• Are there audit trails for inventory management?
• Is there a media storage vault or library containing physical, environmental protection controls/procedures?
• Are there procedures for sanitizing electronic media for reuse?
• Are there procedures for controlled storage, handling, or destroying spoiled media or media that cannot be effectively sanitized for reuse?
• Are there procedures for shredding or other destructive measures for hardcopy media when no longer required?]

<<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:

• Agreements of backup processing
• Documented backup procedures including frequency (daily, weekly, monthly) and scope (full, incremental, and differential backup)
• Location of stored backups and generations of backups
• Are tested contingency/disaster recovery plans in place? How often are they tested?
• Are all employees trained in their roles and responsibilities relative to the emergency, disaster, and contingency plans?
• Coverage of backup procedures, e.g., what is being backed up?]

<<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:

• Are there restrictions/controls on those who perform hardware and software maintenance and repair activities?
• Are there procedures used for controlling remote maintenance services where diagnostic procedures or maintenance is performed through telecommunications arrangements?
• Are software warranties managed to minimize the cost of upgrades and cost-reimbursement or replacement for deficiencies?
• Describe any formal change control process in place.

·        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:

• Are there procedures for reporting incidents handled either by solution personnel or externally?
• Are there procedures for recognizing and handling incidents, i.e., what files and logs should be kept, who to contact, and when?
• Who receives and responds to alerts/advisories, e.g., vendor patches, exploited vulnerabilities?
• What preventative measures are in place, i.e., intrusion detection tools, automated audit logs, penetration testing?]

<<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:

• Vendor documentation of hardware/software
• Functional requirements

·        Design specifications

• Source code documents
• Testing procedures and results
• Records of verification reviews/site inspections
• Standard operating procedures
• User rules/manuals
• Emergency procedures
• Contingency plans
• Risk assessments]

<<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

• [Maximum Password Age
• Minimum Password Age
• Minimum Password Length
• Passwords must meet complexity requirements of installed password filter
• Allow storage of passwords using reversible encryption for all users in the domain
• User must logon to change password]

<<Begin text here>>

Account Lockout Policy

• [Account lockout threshold
• Lockout duration
• Reset account lockout after]

<<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:

• Describe how access rights are granted. Are privileges granted based on job function?
• Describe how users are restricted from accessing the operating system or other system resources not required in the performance of their duties.
• Describe controls to detect unauthorized transaction attempts by authorized and/or unauthorized users. Describe any restrictions to prevent users from accessing the solution outside of normal work hours or on weekends.
• Indicate if encryption is used to prevent access to sensitive files as part of the solution access control procedures.
• Describe the rationale for electing to use or not use warning banners, and provide an example if banners are used.]

<<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:

• Audit Account Logon events
• Audit Account Management
• Audit Directory Service Access
• Audit Logon Events
• Audit Object Access
• Audit Policy Change
• Audit Privilege Use
• Audit Process Tracking
• Audit System Events]

<<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:

• Maintaining the Level of Security
• Checking the use of Corporate Security Standards
• Checking targets and reaction to changes

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:

• Organizational regulations allow the maintenance of the security standards during current operation.

• Responsibilities have been clearly designated.

• Standards are regularly checked to see if they are applied.

• Security standards are reinforced if new hotspots become known.

• Corporate security standards are adjusted in line with changes in personnel, organization, hardware, or software.

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

• What the Corporate security standards have achieved compared to the targets stated in the security goals.

• Whether what has already been achieved complies with the security requirements of the company and whether security activities have been successful.

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:

• Changes in tasks or priorities for the company

• Physical modifications, for example, after moving premises

• Changes in threats and/or hotspots

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.]