Eplc Security Approach Template
Eplc Security Approach Template
<Project Name>
1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field
document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs. After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9. These actions must be done separately for any fields contained with the documents Header and Footer. Modify boilerplate text as appropriate for the specific project. styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.
2.
3. To add any new sections to the document, ensure that the appropriate header and body text 4. To update the Table of Contents, right-click on it and select Update field and choose the option
- Update entire table.
5. Before submission of the first draft of this document, delete this instruction section Notes to the
Author and all instructions to the author throughout the entire document.
Page 1 of 13
<Project Name>
VERSION HISTORY
[Provide information on how the development and distribution of the Security Approach will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]
Version Implemented Revision Approved Number By Date By 1.0 <Author name> <mm/dd/yy> <name> Approval Description of Change Date <mm/dd/yy> <description of change>
Page 2 of 13
<Project Name>
TABLE OF CONTENTS
1 INTRODUCTION......................................................................................................................4 1.1 Purpose of the Security Approach......................................................................................4 4 2 SECURITY APPROACH..........................................................................................................4 2.1 Process Overview...............................................................................................................4 2.2 Security Approach Summary.............................................................................................4 3 TEAM MEMBERS.....................................................................................................................5 3.1 Certification and Accreditation Team................................................................................5 3.2 Security Team.....................................................................................................................5 4 SYSTEM CATEGORIZATION...............................................................................................5 4.1 Core Systems .....................................................................................................................5 4.2 Sub-Systems.......................................................................................................................6 4.3 Interconnected Systems......................................................................................................6 5 PROGRAMMATIC ACTIVITIES...........................................................................................6 5.1 Team Training....................................................................................................................6 5.2 Requirements Management................................................................................................6 5.3 Configuration Management................................................................................................7 5.4 Risk Management...............................................................................................................7 5.5 Change Management..........................................................................................................7 APPENDIX A: SECURITY APPROACH APPROVAL..........................................................8 APPENDIX B: REFERENCES...................................................................................................9 APPENDIX C: KEY TERMS....................................................................................................10 APPENDIX D: RELATED DOCUMENTS.............................................................................11
Page 3 of 13
<Project Name>
1 INTRODUCTION
1.1 PURPOSE OF THE SECURITY APPROACH Defining a security approach for a project provides a line of site from business requirements through team members and components all the way to implemented security controls. It documents clear responsibilities for implementation, certification, and accreditation of the system security and provides a framework for communicating security based impacts on other development and project management activities. This security approach defines from a security perspective how systems associated with the <Project Name> project will be characterized, categorized, and managed.
2 SECURITY APPROACH
2.1 PROCESS OVERVIEW [Summarize the steps necessary for establishing the security approach.] The project manager, working with in collaboration with the security team developed a preliminary assessment of the systems FIPS 199 categorization, and using the proposed project goals defined the following approach to securing the IT system in development. The approach seeks the most cost effective and efficient approach to meeting technical, operational, and managerial security requirements. The approach seeks to ensure that security considerations are effectively integrated with other critical processes such as requirements analysis and risk management throughout the life of the project, and that an early assessment of system classification and boundary definitions are appropriately considered to facilitate development and certification efforts later in the project lifecycle. 2.2 SECURITY APPROACH SUMMARY [Summarize the overall system approach here. Description should reflect decisions that guided how the system boundaries have been defined and the relative maturity of the systems being developed or modified as well as any system interconnections and dependencies. The relationship with existing systems, internal and external, is critical to defining how to approach the overall security of this system. Identifying a security manager for each system and certifying and accreditation authority early in the process ensures that both development and ongoing maintenance are cost effective and efficient.] <Provisional High-Level Diagram of Systems with FIPS 199 classification and interconnections identified>
Page 4 of 13
<Project Name>
3 TEAM MEMBERS
3.1 CERTIFICATION AND ACCREDITATION TEAM
Project Role Chief Information Officer Information System Owner Senior Information Security Officer Chief Information Security Officer Authorizing Official Name <name> <name> <name> <name> <name>
3.2
SECURITY TEAM [Define the security stakeholders in this section. Include names, roles and contact information]
Name <name> Project Role System Security Manager Developer Security Critical Partner C&A Authority Security <system name(s) within scope of responsibility if applicable>
4 SYSTEM CATEGORIZATION
4.1 CORE SYSTEMS Description <System Name> is a new system under development intended to [describe system purpose]. Security Manager [Identify the security manager for this system] Characterization <System Name> is characterized as a <GSS, MA, or Other>. Categorization Based on an estimate of FIPS 199 impact, this system is provisionally defined as a <LOW, MODERATE or HIGH>
EPLC Security Approach (v<1.0>) [Insert appropriate disclaimer(s)] Page 5 of 13
<Project Name>
Boundaries [Describe at a high-level what security services or components are to be included in the part of the system] Dependencies [Describe the security services or components being inherited from a GSS or MA] Interconnections [Describe other system interconnections established for data sharing, business continuity, or backup] 4.2 SUB-SYSTEMS Description <System Name> is a new system under development intended to <describe system purpose>. Security Manager [Identify the security manager for this system] Characterization <System Name> is characterized as a <GSS, MA, or Other>. Categorization Based on an estimate of FIPS 199 impact, this system is provisionally defined as a <LOW, MODERATE or HIGH> Boundaries [Describe at a high-level what security services or components are to be included in the part of the system] Dependencies [Describe the security services or components being inherited from a GSS or MA] Interconnections [Describe other system interconnections established for data sharing, business continuity, or backup] 4.3 INTERCONNECTED SYSTEMS Description <System Name> is a new system under development intended to <describe system purpose>. Security Contact [Include contact information for this system] Interconnections [Describe other system interconnections established for data sharing, business continuity, or backup]
5 PROGRAMMATIC ACTIVITIES
[Use this section to define administrative and management activities that support the overall security approach. These include activities such as training, configuration management, risk management, and communication plans.] 5.1 TEAM TRAINING [Outline specific training related to security. Include any database or developer training that applies to development activities. Include any specific rules of behavior or special security considerations on which team members need to be educated.] 5.2 REQUIREMENTS MANAGEMENT Baseline security requirements for each system have been integrated into the Requirements Management process documented in <Project Management or Requirements Management document name> located on <full network path location>.
Page 6 of 13
<Project Name>
5.3
CONFIGURATION MANAGEMENT Baseline security requirements for each system have been integrated into the Configuration Management process documented in <Project Management or Configuration Management document name> located on <full network path location>.
5.4
RISK MANAGEMENT Baseline security requirements for each system have been integrated into the Risk Management process documented in <Project Management or Risk Management document name> located on <full network path location>.
5.5
CHANGE MANAGEMENT Baseline security requirements for each system have been integrated into the Change Management process documented in <Project Management or Change Management document name> located on <full network path location>.
Page 7 of 13
<Project Name>
Page 8 of 13
<Project Name>
APPENDIX B: REFERENCES
[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.] The following table summarizes the documents referenced in this document. Document Name Description Location
<Document Name and Version Number> <Document description> <URL or Network path where document is located>
Page 9 of 13
<Project Name>
Definition
<Provide definition of term and acronyms used in this document.>
Page 10 of 13
<Project Name>
Page 11 of 13