Attachment_2_-_SDLC.pdf

CUI

i

Federal Energy Regulatory Commission

Systems Development Life Cycle Policy

May 2018

Federal Energy Regulatory Commission Information Security and Systems Assurance Division

888 1st Street NE Washington, DC 20426

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission ii

Document Control

This is a controlled document produced by the Federal Energy Regulatory Commission. The control and release of this document is the responsibility of the document owner. This includes any amendment that may be required.

Document Control

Date April 8, 2014

Author(s) Christina Handley, Mittal Desai, Gerald Thomas, Jolinda Murray, Kaveh Tahvildary

Document Title FERC System Development Life Cycle (SDLC)

Owner Details

Name Christina Handley

Office/Region Federal Energy Regulatory Commission, Washington, DC 20426

Contact Number (202) 502-6500

E-mail Address christina.handley@ferc.gov

Revision History

Issue Date Author Comments

1.0 January 31, 2011 Gerald Thomas Official Release

2.0 April 9, 2012 Thomas Housman • 4.3 Removed: Risk Assessment (RAR)

• 4.3 Renamed: FIPS 199 Categorization to Draft FIPS

199 Categorization

• 4.4 Removed: Risk Assessment (RAR)

• 4.4 Renamed: FIPS 199 Categorization to Draft FIPS

199 Categorization

• 5.2 Removed: Risk Assessment (RAR)

• 5.2 Renamed: FIPS 199 Categorization to Draft FIPS

199 Categorization

• 5.3 Added the following paragraphs:

• FIPS 199/NIST 800-60 Categorization: Review the sensitivity of the information entering, stored in, and exiting the system. Perform a Final FIPS 199/NIST 800- 60 categorization.

• Risk Assessment: Perform a risk assessment of the inherent risk in the system.

• 5.4 Added: Final FIPS 199 Categorization

• 5.4 Added: Risk Assessment

3.0 April 8, 2014 Salma Mack • Changed document security labeling to “For Official Use Only”

• Changed DCIO to CIO

3.1 June 20, 2016 Jessie Wilson

(CSRA)

• Updated Policy to match standard format

• Changed FOUO designation to CUI

4.0 May, 2018 Gerald Thomas

Jolinda Murray

Mittal Desai Kaveh Tahvildary Christina Handley

• Added governance processes e.g. ITIRB role

• Added use of project sites

• Changed CCN to CRQ

• Added Initiation Phase to Overview of Phases

• Updated all sections to capture CPIC, EA and budgetary processes

• Updated entry and exit criteria

• Removed policy and responsibility statements from process description section

• Created responsibility section

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission iii

Revision History

• Added visual graphic of SDLC phases, required deliverables to exit each phase and checklist

• Revised System Assurance to Testing

• Added appendices with CRQ, Transition Package

Agreement, et al

• Changed from Manual to Policy

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

Contents

1 INTRODUCTION

1.1 Background

1.2 Purpose

1.3 Scope

1.4 Authorities

2 OVERVIEW OF PHASES

3 PLANNING PHASE

4 INITIATION PHASE

5 ANALYSIS PHASE

6 DESIGN PHASE

7 DEVELOPMENT PHASE

8 TESTING PHASE

9 DEPLOYMENT PHASE

10 OPERATIONS, MAINTENANCE AND SUPPORT PHASE

11 DISPOSAL PHASE

12 DEVIATION

APPENDIX A: APPROVAL

APPENDIX B: SDLC ROADMAP

APPENDIX C: SDLC PROJECT CHECKLIST

APPENDIX D: CRQ TEMPLATE

APPENDIX E: TRPA TEMPLATE

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

1 INTRODUCTION

1.1 Background

The System Development Life Cycle (SDLC) is a structured, integrated approach to procuring, developing, and implementing Information Technology (IT) solutions. The SDLC ensures that IT solutions align with the Commission’s mission and support its business needs while minimizing risks and maximizing returns throughout the solution life cycle. The SDLC relies on systematic planning, requirements definition, development, implementation and validation to ensure that each solution satisfies the stated requirements efficiently and effectively. Each IT solution is consolidated into the enterprise architecture and Service Catalog so that CIO can ensure that all systems support the FERC mission and goals, and work in concert when appropriate, including systems under development, systems currently in use, and systems scheduled for retirement and or replacement. The SDLC is important for systems pending retirement or replacement since those systems may continue to store sensitive information. Engineers who specify or recommend components of systems are the best source of knowledge and expertise in evaluating the capacity of components to store information and then identify the best practices and procedures to sanitize or destroy these components.

The SDLC is composed of processes that are encapsulated in a series of phases. The SDLC requires approval to advance from one phase to the next by the respective CIO authorities. Each phase lists entry criteria such as documentation, approval, or other specific data needed to start the phase and each phase lists expected deliverables that should be completed in the phase before seeking approval to advance to the next phase.

1.2 Purpose

This document describes the process for planning, designing, developing, testing, deploying and supporting an information system at FERC.

1.3 Scope

The SDLC applies to all CIO projects and tasks that follow a traditional software or system development waterfall methodology. Projects that follow an agile development process are out of scope. Routine hardware and software deployments are out of scope.

1.4 Authorities

All processes that are executed in accordance with the SDLC must adhere to all other FERC and CIO policies which include (but are not limited to):

• CIO policies, procedures and directives

• CIO COR Responsibilities Policies

• FERC Configuration Management policies and procedures

• FERC CPIC policies and procedures

• FERC security policies and procedures

• FERC Enterprise Architecture policies and procedures

• FERC IT operations policies and procedures

• FERC IT Project Review Board

• FERC IT Investment Review Board

• FERC Records Management polices and procedures

• Applicable, federal policies, procedures and directives https://ws.sp.ferc.gov/FERCollaborate%20Library/Forms/By%20Program%20Office.aspx https://ws.sp.ferc.gov/CIO/OCIO/ITPARC/Team%20Documents/Policy%20Documentation/ITPARC%20Policies/CIO%20COR%20Policy.pdf https://ws.sp.ferc.gov/CIO/OCIO/ITPARC/Team%20Documents/Policy%20Documentation/ITPARC%20Policies/CIO%20COR%20Policy.pdf

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

2 OVERVIEW OF PHASES

The SDLC process is composed of a number of clearly defined work phases:

• Planning

• Initiation

• Analysis

• Design

• Development

• Test

• Deployment

• Operations, Maintenance and Support

• Disposal

3 PLANNING PHASE

Element Description Purpose

• The purpose of the plannning phase is to gather high level Program Office requirements for information, information systems and communications systems enhancements or modifications, define the scope of the project, estimate project costs and obtain IT Investment Review Board (ITIRB) or budgetary approval to proceed.

Entry Criteria

• None

Process • IT PRM conducts a data call to gather Program Office (including CIO) requirements for IT investments, also known as “Capital Planning and Investment Control” Requests or “CPIC”s

• ITPRM provides the CIO PMO with a list and slides containing the project title, status, scope and objective, cost, activities and results, risks and schedule information following the approved format

• CIO presents candidate projects to the ITIRB for approval and prioritization

• Upon ITIRB approval, the CPIC team develops a “memo” for the proposed solution or collaborates with the Enterprise Architecture Working Group to develop the full solutions package comprising alternatives analysis and a proposed solution (if needed).

The proposed solution includes product comparison analysis as necessary for decision making

• The CIO and CIO Directors assign a federal project manager and the Contracting Officer

Planning Initiation Analysis Design Development Test Deployment

Operations, Maintenance

& Support

Disposal

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

Represenative (COR) to execute the project

• CPIC team provides the documentation to the respective CIO Director, COR and Project Manager

• Approved work is assigned to a director within the CIO for project oversight

• End users or system owners request system change requests for enhancements through the CPIC process

• End users or system owners request system change requests to resolve breaks and fixes which are sent to the Director of Systems development and engineering for analysis, obtaining task order cost estimates and entering into the budget request or spend plan

• The CIO Director requests and allocates funds for an activity within the appropriate chart of account in the CIO Budget. ITPRM reviews, obtains corrections and approval by the CIO and updates the FERC financial management system to include the project for the appropriate fiscal year.

Responsibilities • ITPRM and the EAWG consult with the Program offices in developing CPIC slides and solutions packages

• Work is assigned to and accepted by a CIO Director who is accountable for the budgeting, tracking, and oversight of the work as an IT project

• Program Offices are responsible for submitting IT investment request aka “CPIC” requests and system change requests for enhancements through the CPIC data call process o ITPRM and SDE facilitate the above requirements gathering as needed

• Director of Systemsdevelopment and engineering is responsible for analysis, obtaining task order cost estimates and entering into the budget request or spend plan for approved fiscal year

• CIO and PMO are responsible for presenting projects and their respective funding requests to ITIRB for approval

• CIO is responsible for approving the introduction of new technologies into the FERC environment in consulation with Program Offices and SMEs

Exit Criteria • ITIRB approved IT investment (aka “CPIC”) or budget approved IT investment

(hardware, software or services) including system break/fixes

• Assignment to the CIO Director

• Assignment of a Project Manager

• Assignment of the Contracting Officer Representative (COR) (if applicable)

• An ITPRM approved CPIC solutions package and/or solutions memo

• ITIRB Approval (if applicable)

• CIO Budget Approval

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

4 INITIATION PHASE

• The purpose of the initiation phase is to initiate the project and to develop project plans to manage time, cost, quality, change, risk and issues.

• ITIRB approved IT investment (aka “CPIC”) or budget approved IT investment (hardware, software or services) including system break/fixes

• An ITPRM approved CPIC solutions package and/or solutions memo

• CIO Budget Disbursement

Process • The ITPRM Director requests and obtains funding from the CFO for/during the year of project execution o The funds for the activity must be requested and allocated by the CIO Director within the appropriate chart of account in the FERC financial management system

• The CIO Director translates the original work request requirements into a project definition that describes the work to be performed. The definition must provide enough detail so that a level-of-effort can be estimated for the work and resources can be appropriately assigned or acquired for the project. The project definition must be provided on the task order (as the task description) or in the acquisition package as applicable.

• The CIO Director sets the end date for the task.

• The CIO Director procures contracting resources as necessary to execute the task (via IT Support Services Contract Task Order or separate procurement). If a contractor is used to perform the work, the contractor provides a project lead. The CIO Director reviews the project definition, funding, and period of performance with the project manager. The CIO Director provides oversight regarding contractor invoices and project procurements. All contractor charges and project procurements must be reconciled with project funding requirements (e.g cost proposal) and the CIO budget.

• The project manager manages the project activities to ensure a timely, cost-effective, and secure deployment of assigned work. To plan for a successful project the project manager performs these functions:

• The project manager establishes a project site on the CIO FERCollaborate dashboard.

The project site is to have a summary slide that provides project scope, project cost, near term milestones, completed milestones, risk and a project timeline. The project site is to have a project schedule, a risk registry, and a file structure to contain all project artifacts.

The project site is used to track action items.

• The project manager consults with the Records Officer to produce the records schedule IAW NARA requirements and to understand how the system must be engineered to comply e.g. with records beyond the life of the planned IT system.

• The project manager provides a Project Management Plan (PMP) for each project.

Where appropriate, multiple projects may be assigned to a single PMP. At a minimum, the PMP must provide the following information for each project:

o Scope Statement – defines, verifies, and controls the scope of the project. The

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission scope statement should use the same scope language as presented in the ITIRB slide (as applicable) (Required) o Budget Control Plan– defines project financial management including how cost variance will be reported and escalated (Required) o Earned Value Management System (EVMS) – Ensure that EVMS is established, monitored, and updated during the entire project. EVMS is only required for projects that are longer than 1 month in duration. The following EVMS metrics are tracked for all activities project schedules:

BAC – Budget At Completion (Total Cost Estimate for Project Plan)

BCWS – Budgeted Cost of Work Scheduled (Planned Value or PV)

BCWP – Budgeted Cost of Work Performed (Earned Value or EV)

ACWP – Actual Cost of Work Performed (From Timekeeping System)

SPI – Scheduled Performance Index (BCWP/BCWS) o Schedule Control Plan – defines project schedule management including how schedule variance will be reported and escalated (Required) o Quality Assurance Surveillance Plan– defines the quality assurance surveillance plan to ensure project deliverables are completed correctly (Required) o Change Management Plan – defines the strategy, process and communications to manage, track and integrate changes, evolving requirements, user-adoption, etc. (Required) o Communication Plan –lists the meetings, presentations, training, etc… to provide adequate communication including progress, status schedules and content (Required) o Procurement Management Plan – provides the procurement strategy and process for tracking procurements. Excludes contract administration (If applicable).

o Project Risk Management - describes how risks will be captured, mitigated and monitored (Required).

o Transition Plan – Defines the transition plan to move the completed product into production. Reference the Transition Package Agreement (TrPA). Must identify impact to and additional requirements for transition to IT Operations. The TrPA should follow ITIL guidance (Required) o Configuration Management Plan – describes how the project will follow FERC configuration management policies (Required) o Validation and Acceptance Plan – describes the plan for demonstrating that the project meets the stated requirements and fulfills the original need together with any authorized changes used to update the project baseline. Indicates what type of testing will be performed. Testing may include but is not limited to Unit Testing, Integration Testing, Functional Requirements Testing, User Acceptance Testing, Regression Testing, Smoke Testing (Required) o System Security Plan, Draft – addresses the inherent and residual risks of the system and its impact on the FERC IT environment, shared activities with FERC partners and other federal government elements (Required)

• The Authorizing Official (AO), Information System Owner (ISO), and Information System Security Officer (ISSO) are identified for defined major systems listed in the http://share.ferc.gov/SiteDirectory/CM/CRCCNCCA%20Templates/TrPA%20Template_Updated%202018.doc

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

SSP

• The project manager provides a project schedule that has the following minimum requirements:

o Activities are scheduled no longer than 2 calendar weeks in duration o Schedule at least one milestone in each calendar week of the project.

o All Transition Package Agreement (TrPA) deliverables must be referenced in the project schedule.

o All project milestones must be included in the EVMS calculations.

o The project schedule must be available on the CIO dashboard

• The project manager introduces the project to the Project Review Board (PRB), CIO organization, contractors, and interested stakeholders.

o The project manager provides details at the PRB including:

Project scope

Project schedule

Project risks

Project dependencies

Overview of the Transition Package Agreement (TrPA). Note:

communication plan must be presented to ITOPS to ensure supportability

• The project manager escalates cost variances to the CIO Director. The CIO Director will raise funding risks to the CIO and ITPRM Director

• Identify training needs. Train staff on newer technologies. Detailed Training Plan provided in the Design Phase of SDLC. Identifying initial training needs to allow for budget or contract planning

• The project manager obtains written approval from the assigned CIO Director to complete the project initation phase and to commence to the project analysis phase

• The COR prepares the acquisition package (if applicable)

Responsibilities • For work that requires the use of contractors and/or procurements and acquisitions, the

CIO Director abides by all federal and FERC policies regarding the COR role

• The CIO Director is responsible for ensuring that the cost of the project does not exceed the approved budget

• The CIO Director is responsible for informing ITPRM and the CIO of any budget variances and request approvals

• The project manager is responsible for creating and managing the project schedule, Project Management Plan and coordinating meetings with the PRB as necessary

• The Authorizing Official (AO) is responsible for accepting the residual risk of the system and its impact on the FERC IT environment

• The COR is responsible for preparation of the acquisition packages (SOW, ICGE, Security Checklist, etc) with the assistance of ITPRM

• The CIO Director is responsible for reviewing and approving SDLC phase

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission documentation

Exit Criteria • FERC financial management system updated

• CIO project collaboration site

• Project

• Definition / Project Description on Task Order or in Acquisition Package

• Task Order (if applicable)

• Project Management Plan (includes Scope Statement, Budget Control Plan, Earned Value Management System (EVMS), Schedule Control Plan, Quality Assurance Surveillance Plan, Change Management Plan, Communication Plan, Procurement Management Plan, Project Risk Management, Transition Plan, Configuration Management Plan, Testing Validation and Acceptance Plan, System Security Plan

• Project Schedule

• Project Risk log

• EVMS updated

• Transition Package Agreement (TrPA)

• System Security Plan, Draft or Update, as applicable

• Identification of the Authorizing Official (AO), Information System Owner (ISO), and Information System Security Officer (ISSO) to ISSA Division

• Records Officer approved records retention schedule (Draft)

• Acquistion Package (SOW, IGCE, Security Checklist, et al) (if applicable)

• Training needs identifying initial staff training needs on new technologies. The intent of identifying training needs during this phase is to ensure that the architects, developers and testers have been trained in the skills and compentencies to create systems on new technologies

• CPIC tracker updated

• Director approval to proceed to Analysis Phase

• Presentation to PRB to review SDLC deliverables (checklist) indicating completion

5 ANALYSIS PHASE

• The purpose of the analysis phase is to document the functional requirements in detail to include system inputs, processes, outputs, and interfaces. The system is described in terms of the functions to be performed (what it will do), not in terms of software and hardware operations (how it will do it).

• Project Management Plan

• Project Schedule

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• CIO project collaboration site

• Project Risks (log) documented

• EVMS prepared

• Transition Package Agreement (TrPA)

• System Security Plan, Draft or Update, as applicable

• Records Officer approved records retention schedule

• Acquistion Package (SOW, IGCE, Security Checklist, et al)

Process • The project manager schedules, captures, and documents the functional requirements that address the scope of the assigned task. This step requires eliciting, analyzing, specifying, prioritizing, verifying and negotiating business functions that the system must deliver and support. The project manager performs the following requirements collection activities:

o Conduct interviews with business stakeholders o Solicit input from technical systems architects, security staff, and ITOPS engineers o Examine current technical white papers and/or other trade media o Perform a site survey, if required

• The project manager educates all project stakeholders regarding the overall use and outcome of the system.

• The project manager obtains documented CIO and Program Office (Business) Sponsor approval of the functional (business system) requirements document.

• The project manager documents requirements that cannot be expressed in data and process models such as service level agreements, legal mandates and physical specifications in a set of non-functional requirements.

• The project manager documents a description of the logical and physical boundaries of the system. Included are also statements regarding current status of the system such as operational, under development, or undergoing a major modification. Appropriate to each description is detail regarding the content and extent of customized components, content of Commercially Off The Shelf (COTS) and Government Off The Shelf (GOTS) products involved.

• The project manager allocates / assigns the proper resources to the project to provide the following privacy and security requirements and deliverables:

o Concept of operations – defines where the system resides, and a description of significant roles, responsibilities, and competencies necessary for the system to operate. Includes system owner roles and responsibilities o Statement of impact – defines impacts to existing systems and infrastructure o Dependencies on existing systems – defines any interconnections needed between systems o FIPS 199/NIST 800-60 categorization (preliminary) – defines the sensitivity of the information entering, stored in, and exiting the system o Business Impact Analysis (BIA) - determines the criticality and perishability of information associated with the system and the business impacts if system is

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission impaired or out of service. The BIA identifies the Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for the system.

o Privacy Threshold Assessment, if required o Privacy impact assessment, if required o Statement of Records Notice (SORN), if required o Determination of what laws, directives, and policies are applicable to this IT project and how they are be addressed. (IE: OMB A-123) o Identification of how the system interconnects and impacts existing systems o System Management Plan: describes how the system is administered and managed. This description should include impact on the existing IT administration and management structures and the necessary detail to integrate the new system into those activities.

o Security and privacy controls necessary to establish the control baseline. (FIPS

200/NIST SP800-53)

o Threats to the system / threat model o Abuse - Use cases o Security architecture design o Tailored and segmented controls that meet the mitigation requirements of the risk assessment and are consistent with the security architecture

Requires System Interconnection Agreements, if such exist, that include relevant mitigating security and privacy controls.

• The Project Manager or assigned resource creates the Functional Requirements Document (FRD), Requirements Traceability Matrix (RTM) and maintains the Requirements Change Matrix (RCM):

o Functional Requirements Document (FRD) - contains all system and report requirements (to include storage, compute, backup and disaster recovery), security requirements, use cases, and supplementary specifications that provide the basis for design and development of the system. These requirements must include considerations for capacity and growth. The FRD also contains the Requirements Traceability Matrix, Reports Requirements and Business Process Models/Maps. The Project Manager will coordinate with the Reports Program Manager the schedule and implementation of all report requirements (as applicable). The Project Manager will coordinate with the Program Office or CIO Division (ITPRM, PMO or SDE) to schedule and complete business process models/maps (as applicable).

o Requirements Traceability Matrix (RTM) - maps each detailed functional requirement, system design element, security requirement, and test case to their source. This ensures understanding of requirements and their sources, scope management, and verifies that all requirements have been fulfilled o Requirements Change Matrix (RCM) - is a detailed log of all system changes that have been made over the life of a system. Each change is mapped to the version of the system that was released into production

• The project manager obtains written approval from the system owner and CIO Director regarding the documented requirements prior to closing out the analysis phase and commencing to the design phase

• The SDE assigned resource, typically the SDE Task Lead, updates the Earned Value

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

Management System for T&M projects as needed

Responsibilities • The project manager is responsible for leading efforts to gather and document functional requirements, for coordinating delivery of privacy and security documentation, and for communicating and coordinating all activities in the analysis phase

• The project manager is responsible for allocating ensuring that the proper resources are available on the project and requesting additional resources from the CIO Director if needed

• The Privacy Officer is responsible for producing the PTA, PIA and SORN as needed

• Assigned resources are responsible for deliverables as tasked by the project manager

• ISSA Security resources are responsible for providing or approving the security architecture design and security controls

• The CIO Director is responsible for requesting and obtaining additional resources, if needed

• The CIO is responsible for approving allocation of additional resources, if needed

• ITPRM is responsible for updating the budget, if needed

• The Director of SDE is responsible for ensuring the EVMS is updated and accurate

• ISSA is responsible for performing a preliminary FIPS 200/NIST SP800-53 categorization

• The Director is responsible for approving transition to the next phase of the SDLC

Exit Criteria • Functional Requirements Document

• Non-functional (including Special System) Requirements Document

• Federal Director or Progam Office System Owner (as applicable) Review and Approval of Functional Requirements Document

• Requirements Traceability Matrix

• Requirement Change Matrix

• Concept of Operations

• Statement of impact

• Dependencies on existing systems

• Business Impact Analysis (BIA)

• Determination of what laws, directives, and policies are applicable to this IT project and how they are be addressed. (IE: OMB A-123)

• Identification of how the system interconnects and impacts existing systems

• System Management Plan

• Security and privacy controls necessary to establish the control baseline. (FIPS

200/NIST SP800-53)

• Threats to the system / threat model

• Abuse - Use cases

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• Security architecture design

• Tailored and segmented controls

• Privacy Impact Assessment, if required

• Privacy Threshold Assessment, if required

• SORN, if required

• Draft FIPS 199 Categorization

• Description of system assumptions and constraints

• Description of applicable compliance requirements and how the system complies.

• System Interconnection Agreements, if required

• EVMS update for T&M projects, if applicable

• Budget approval, if required

• FERC financial management system updated

• FEAMS update (acquisition information)

• Director approval to proceed to Design Phase

• Project Manager presentation to PRB to review SDLC deliverables (checklist) indicating completion

6 DESIGN PHASE

• The purpose of the design phase is to transform the detailed, defined functional requirements developed in the analysis phase into complete, detailed technical specifications for the system that guides the Development Phase.

• The decisions made in this phase address, in detail, how the system will meet the defined functional, physical, interface, data, security, and privacy requirements. Design Phase activities may be conducted in an iterative fashion, producing first a general design that emphasizes the functional aspects of the system, then a more detailed design that expands the general design by adding all the necessary technical detail.

• Transition Package Agreement

• Functional Requirements Document

• Requirements Traceability Matrix

• Requirement Change Matrix

• Draft FIPS 199 Categorization

• Non - Functional (Special System) Requirements Document

• Concept of Operations

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• Description of system assumptions and constraints

• Description of applicable compliance requirements and how the system complies

• System Interconnection Agreements, if required

• Statement of impact

• Dependencies on existing systems

• Business Impact Analysis (BIA)

• Identification of how the system interconnects and impacts existing systems

• System Management Plan

• Security and privacy controls necessary to establish the control baseline (FIPS 200/NIST

SP800-53)

• Threats to the system / threat model

• Abuse - Use cases

• Security architecture design

• Tailored and segmented controls

• Solutions Package

Process • The project manager manages the creation, content, and completeness of the System Design Document SDD. The SDD contains the following information:

o Top-level system architecture - identifies the major hardware and/or software configuration items that comprise the system. The architecture contains a description of all system components such as:

Databases

Servers/Web Servers

Active Directory/Group Policy configuration

System integration points

Software/Frameworks

Switches, Routers, Appliances

External but dependent system services necessary to support the system o Interfaces - includes interfaces with external hardware and/or software components, tasks to be performed by system personnel, and system descriptions include user inputs, expected outputs, and interface designs. Any public facing components must be identified. Process diagrams are used to capture system processes. (Must include external FERC interconnections identified by the System Interconnection Agreements.)

o Test Lab or Software Development Environment - is an isolated, secure means to create, integrate, pilot, and develop a solution in a technical infrastructure that is completely independent of the production network while still being a functional replica.

o Test Environment - is an isolated test environment to perform controlled testing of system requirements in an environment that is completely independent of all other network environments o Continuous Monitoring – includes mechanisms and detail component

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission configurations to ensure that activity and security events are logged and an audit and forensic trail is produced

• The project manager assigns resources to provide a Contingency Plan is developed based on the BIA that also integrates with the FERC organizational COOP

• The project manager assigns resources to provide a disaster recovery plan is developed based on the BIA while also utilizing and integrating with FERC centralized disaster recovery capabilities

• The project manager assigns resources to provide a support plan that is developed to address how the system will be supported and level of impact on the FERC ITOPS support system if used. If ITOPS is used, the plan should address any new competencies the help desk and infrastructure support staff must have to support the system at the level of service expected by the end customer. The support plan includes training plans for training manuals, user guides, etc. to ensure operational and support capbailities re in lace prior to production releases of technologies. The project manager obtains and secures any support SLA’s that meet the end customer’s requirements. SLA’s should include security and privacy concerns of the system and its information together with response times, point of contact, and escalation procedures

• The project manager assigns resources to provide a test plan which is created to validate that the requirements (specified in the FRD, RTM and RCM design) documented in the SDD is correctly satisfied.

• The project manager in collaboration with the assigned security resource reviews the sensitivity of the information and performs a Final FIPS 199/NIST 800-60 categorization.

• The assigned security resource performs a risk assessment of the inherent risk in the system.

The project manager in collaboration with the assigned security resource provides a security test plan is developed to test the security services, mechanisms, and controls as they would be integrated into the system.

• If the SDD suggests a solution that requires training of CIO or FERC personnel, then the project manager sees that a training plan is created. The purpose of a Training Plan is to outline the training goals for the new or enhanced system. During the design phase a training plan outline is created containing the objectives, needs, strategy, and curriculum to be addressed for training users. Training is conducted for system users, administrators, and operation support staff.

• The project manager works with system engineers to assess system components for their ability to store residual information that might be sensitive. Each identified component having this capacity has a designed and defined procedure to sanitize or destroy the component sufficient to assure no recovery of the information.

• The project manager obtains approval from the CIO Director regarding the documented system design prior to closing out the design phase and commencing to the development phase.

Responsibilities • The project manager is responsible for coordinating and ensuring the creation of the system design document, test plans, training plans, and all other activities or deliverables in the design phase

• The designated security resource is responsible for ensuring that a proper risk assessment is conducted, the FIPS categorization is prepared, and security test plans are properly documented

• The designated ITOPS resources are responsible for identifying customer support

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission requirments, operational SLA impacts, and any other operational requirements

• The CIO SE Director is responsibe for approving system design artifacts

Exit Criteria • System Design Document

• Contingency Plan Draft

• Disaster Recovery Plan Draft

• System Retirement Plan

• Final FIPS 199 Categorization

• Risk Assessment

• Security Test Plan

• Support Plan

• Test Plan

• Training Plan Outline (if needed)

• Service Level Agreements (if applicable)

• Director approval to proceed to Development Phase

7 DEVELOPMENT PHASE

• The purpose of the development phase is to translate design specifications into hardware and software components. Systems are developed per the design specifications. Tests are performed on each individual component to verify that the components operate in accordance with functional requirements and that the components are integrated into progressively larger assemblies and re‐tested to ensure that the individual components interact correctly. This process continues until the configuration items specified in the Design Phase have been created.

• Transition Package Agreement

• Functional Requirements Document

• Requirements Traceability Matrix

• Requirement Change Matrix

• System Design Document

• Contingency Plan Draft

• Disaster Recovery Plan Draft

• Security Test Plan

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• Test Plan

• System Retirement Plan

• Final FIPS 199 Categorization

• Risk Assessment

Process • The CIO Director provides or assigns resources to provide procurements for any services, hardware, software, licenses, or warranties as listed in the SDD, PMP, and/or project schedule.

• The project manager ensures the establishment of an environment to development, integrate, test, or pilot hardware and software as stated in the SDD. IT Operations may prepare environmental assests for use by SDE or SDE may provide engineering services for use by IT Operations

• The project manager facilitates the coding and unit testing by the development resources of custom developed software. The software is developed according to specifications as described in the project design phase.

• The project manager coordinates integration testing with approval and oversight of the CIO security and systems assurance division. All software components are tested in accordance with the test plan as documented in the analysis and design phase.

• The project manager ensures that newly built or acquired hardware components are tested against the specifications developed during the design phase.

• The project manager ensures that the assigned security resources test configured system and security component integration for correct functioning and effectiveness in addressing the associated risk. Ensure that the elements supporting continuous monitoring are effective and operating as expected.

• The project manager delivers a completed contingency plan as designed in the Design Phase.

• The project manager delivers a completed disaster recover plan as designed in the Design Phase

• The project manager manages the creation of draft CRQs for scheduled production configuration changes.

• The project manager ensures the content, completeness, and delivery of all documentation necessary for implementation and operation of the system in a reliable and secure manner. All such documentation includes the relevant management and operational controls necessary to ensure the reliable and secure operation of the system over its lifetime. This documentation includes at a minimum:

o Training Manuals o Maintenance/Warranty documentation o System Operations Manual o User and Operator Manuals

• Development Approval: The project manager obtains approval from the CIO SE Director regarding the completed system prior to closing out the development phase and commencing to the systems assurance testing phase.

• The project manager presents to the PRB for review an overview of the completion of the deliverables of the development phase compared to the FRD and updates to the project schedule, risks and resource dependencies

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission o Throughout the project the project manager addresses the PRB at any point in time per the Project Review Board Charter which indicates the following circumstances

PRB must approve vetting of significant proposed changes in scope to the IT Investment Review Board approved scope

PRB approves and directs corrective action to minimize risk or realized project issues which may include a review of the project risks and issues

PRB may be used to discuss creative solutions

Responsibilities • The project manager is responsible for managing and ensuring the development of the system

• The CIO Director is responsible for finalizing any purchases for hardware, software, or services

• Upon request by the PM, CIO Director or CIO, the PRB is responsible for making course correction decisions

• The CIO Director of SE is responsible for approving to proceed to the Testing Phase or vetting to PRB for approving to proceed to the Testing Phase as needed

• The project manager is responsible for vetting reports requirements to the reports operational manager/project manager

• The reports manager is responsible for ensuring report requests are entered into the on-line report request for tracking

• The development resources/team perform unit testing

• The Director is responsible for approving transition to the next phase of the SDLC

Exit Criteria • Functioning System

• Reports

• Integration Test Summary Report

• Contingency Plan

• Disaster Recovery Plan

• Draft CRQ(s)

• Draft Training Manuals

• Draft Maintenance Plan

• Draft SOPs

• Draft User Documentation

• System Security Plan

• Director approval to proceed to Test Phase

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

8 TESTING PHASE

The purpose of the Testing phase is two-fold.

• First is to test and ensure that the completed system functions to meet the following criteria:

o Satisfy the functional requirements;

o Satisfy the business needs;

o Adhere to all mandates, physical constraints and service level agreements; and o Operate as described in the User and Operator Manuals.

• Second is to assurance test to demonstrate that the residual risk of the system and its impact on the FERC IT environment has been reduced to an acceptable level. Further consideration is also given to the impact on FERC partners and the shared federal environment. Once completed and certified, the Authorizing Official can accredit the system for operation.

• Transition Package Agreement

• Functional Requirements Document

• Requirements Traceability Matrix

• Requirement Change Matrix

• System Design Document

• Test Plans

• Integration Test Summary Report

• Contingency Plan

• Disaster Recovery Plan

• Draft CRQ(s)

• Draft Training Manuals

• Draft Maintenance Plan

• Draft SOPs

• Draft User Documentation

• System Security Plan

• Security Test Plan

Process • The project manager submits CRQs to set up test environments. The CCB approves CRQs which are required for any asset to be deployed to the production network

• ITPRM updates FEAMS

• The project manager facilitates the testing of business use cases against the completed system. Defects are recorded and repaired as necessary to meet the requirements and design of the system as outlined in the Test Plan. After the successful completion of testing the Test Summary Report is created. The test summary report contains the test scripts and the results of the executed test scripts.

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• The CIO director negotiates with FERC management to determine if one or more FERC program offices are required to perform testing of the completed system prior to production implementation. The project manager facilitates the ability of the program offices to test business use cases against the completed system. The project manager manages the collection of system defects as noted by the FERC staff and forward a record of the defects to the Director for review. The Director determines the course of action to any address cost and schedule risks or adjustments and obtains approval. The Director authorizes the project manager to present the specified defects to the development team for repair.

• The project manager ensures that the assigned security staff conducts Security Testing and Evaluation (ST&E) to cover all personnel, management, operational, and technical controls employed in support of this project and follow and cover the contents of the Security Test Plan. Testing is accomplished by an assessor organization. The project manager ensures that the system is completed and stable, ready and available and for security testing. The project manager coordinates with the security assessor organization to facilitate all testing activities based on NIST 800-53 and 800-53a. As a part of the evaluation of this system and its impact on the FERC IT environment, the following categories comprising multiple items and varying levels of effort are reviewed for completeness and effectiveness:

o Access Control o Awareness and Training o Audit and Accountability o Configuration Management o Contigency Planning o Identification and Authentication o Incident Response o Maintenance o Media Protection o Physical and Environmental Protection o Planning o Personnel Security o Risk Assessment o Secrity Assessment and Authorization o System and Service Acquisition o System and Communication Protection o System and Information Integrity o Program Management

• The assessor organization produces documented certification results and recommendation to the ISO, ISSO, and AO. The ISO and ISSO will review and approve the certifcations results for the system. The AO will be presented the recommendation for accrediaton of the system and if the AO accepts, the the project manager may move ahead to close this phase. If there are POA&Ms, then they must be corrected according to the milestones contained therein

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• The project manager does not allow the system to operate and deliver services to the end customer until an official accreditation (Approval To Operate) has been signed by the AO as evidenced in the Security Authorization Decision Letter

• The project manager ensures that all changes to the project are baselined and unchanged including documentation beginning with this phase. Allowed changes are only be those necessary to satisfy the content of any POA&M produced. The project manager maintains this baseline until the project has been successfully placed under change and configuration management control

• The project manager obtains approval from the system owner and the CIO Director regarding the readiness of the completed system prior to closing out the Testing phase, Systems Assurance and Validation and commencing to the Implementation phase

Responsibilities • The project manager is responsible for the coordination and execution of all test plans and user acceptance of the system

• Assigned testers will perform integration and system assurance testing of the completed system

• The assessor organization is responsible for producing evidence that the system is secure and making the recommendation for accreditation

• The ISO and ISSO is responsible for reviewing and approving the certifcations results for the system

• The system owner is responsible for accepting the system

• The Director is responsible for approving transition to the next phase of the SDLC

Exit Criteria • Systems Validation Test Summary Report

• CRQ(s)

• Training Manuals

• Maintenance Plan

• SOPs

• User Documentation

• Customer Acceptance Statement/UAT report

• Security Certification and Recommendation Report

• Security Authorization Decision Letter

• FEAMS update

• CCB Approval to proceed to Deployment Phase

9 DEPLOYMENT PHASE

The purpose of the Deployment Phase is: first, to install the system in the production environment and to bring the system into live operation; and second, to ensure that the system, as developed and implemented:

Systems Development Life Cycle Manual CUI Federal Energy Regulatory Commission

• Satisfies the functional requirements;

• Satisfies the business needs;

• Complies with all applicable laws, regulations, and policies;

• Adheres to all mandates, physical constraints and service level agreements;

• Operates as described in the User and Operator Manuals;

• Transition the operational system from development to production; and complete project close-out.

• All Approved Transition Package Agreement Documents

• Approved CRQ(s)

• Security Certification and Recommendation Report

• Security Authorization Decision Letter

Process • The CIO director ensures that any impact regarding production implementation is clearly communicated to FERC staff prior to deployment.

• The project manager serves as the deployment manager unless another individual is designated as the deployment manager by the CIO Director.

• The deploymet manager ensures the execution of the following tasks and processes below:

• The deployment prepares a deployment checklist of activities to be performed and tasks to be completed to ensure a successful deployment.

• The deployment manager ensures that all necessary training is scheduled and completed prior to production implementation.

• The deployment manager ensures that all issues during and (60 days) post deployment are tracked, mitigated and resolved. The deployment list of tasks may include but is not limited to feedback from system users during deployment that may require training, communications or vetting issues to developers for resolution.

• The deployment manager verifies that any communications to FERC staff have been scheduled and completed prior to production implementation.

• The deployment manager verifies that the production system has been properly transitioned in accordance with the TrPA to the IT Operations staff and that the system is incorporated into the FERC Service Catalog.

• The deployment manager ensures…