Attachment J3 - SDLC Policy.pdf

DEPARTMENT OF HEALTH & HUMAN SERVICES

Centers for Medicare & Medicaid Services Office of Clinical Standards and Quality Information Systems Group 7500 Security Boulevard Baltimore, Maryland 21244-1850

QualityNet System Development Life Cycle (SDLC)

Policies and Procedures

Version 3.0

March 2006

Prepared by:

Buccaneer Computer Systems & Service, Inc.

6799 Kennedy Road, Suite J, Warrenton, VA 20187

QualityNet SDLC May 2006

Summary of Changes in QualityNet

Items below reflect the changes in the new QualityNet SDLC, Version 3.0, March, 2006.

1. Page 5, third paragraph, added sentence at end of paragraph: "Important aspects of each project may include legislative mandates such as Privacy, Security, HIPAA and 508 Compliance.

(See Attachment 2 –Legislative Mandates).".

2. Page 5 and 6, added documentation for the use of Dimensions.

3. Added Attachment 13 - Adding Deployment Packages to Dimensions.

4. Added Attachment 14 - Retrieving Deployment Packages from Dimensions.

5. Added Attachment 15 - Deployment Package Life Cycle Description and Deployment Package Definitions.

6. Page 7 and 8, System Development Life Cycle (Check Points, Activities, Artifacts) table.

Added 508 Compliance and Dimensions Source Code Management check points in table.

7. Page 9, bullet eight, add "to include Section 508 Compliance testing" to end of sentence.

8. Page 10, under "The Application Development Organization will:", add bullet, "Development will work with CM to create operational planning input into the Dimensions environment.".

9. Page 11, System Development Life Cycle, Application Developer Timeline table. Added 508 Compliance and VPAT Template actions.

10. Page 12, under "The IV&V Organization will:", second bullet, added "inclusive of additional Section 508 Compliance testing.".

11. Page 12, under "The IV&V Organization will:", added bullet, "IV&V staff will ensure they have access to code within Dimensions.".

12. Page 20, under "The QNET Information Systems Security Officer (ISSO) will:", added bullet "ISSO Security staff will ensure they have access to Dimensions.".

ii

13. Page 20, added "3.7 508 Compliance" section.

14. Page 23 and 24, under "The Application Development Organization will:", first bullet, added sentence, "These will include the specific requirements related to the application's Section 508 Compliance adherence or acceptable "work-around" as identified in the VPAT, http://qnettech.sdps.org/sdlc/VPAT.doc.".

15. Page 23, under "The Application Development Organization will:", add bullet, "Work with CM to ensure that the appropriate development requirements are established within Dimensions.

16. Page 27, under "The Application Development Organization will:", add bullet, "Development will work with ITF to ensure engagement from is entered into the Dimensions.".

17. Page 27, under "The ITF Organization will:", add bullet, "ITF staff will ensure they have access to IFT Engagement Request requirements from Dimensions.".

18. Page 29, under "The Application Development Organization will:" add bullet, "After the code has been released, the developer will add the final report to Dimensions.".

19. Page 29, under "The ITF Organization will:", add bullet, "Ensure access to Dimensions.".

20. Page 31, under "The Application Development Organization will:", add bullet, "Release Test Summary Report to Dimensions.".

21. Page 31, under "The ITF Organization will:", add bullet, "Release Stress Test reports to Dimensions.".

22. Page 33, under "QNET Infrastructure/Supporting Toolset", add bullet, "PVCS Dimensions: utilized for source code management.".

23. Page 35, fourth paragraph, change first sentence to read: "To facilitate the independent validation process, the application developer will export the deployment package to Dimensions for use in the IVV process.".

24. Page 36, under "The application Development Organization will:", add bullet, "Ensure update to requirements are established in Dimensions.".

25. Page 36, under "The Application Development Organization will:", added bullet, "Complete the Voluntary Product Accessibility Template (VPAT), http://qnettech.sdps.org/sdlc/VPAT.doc, to identify section 508 Compliance adherence or acceptable "work-around".".

iii http://qnettech.sdps.org/sdlc/VPAT.doc

26. Page 36, under "The IV&V organization will:", added fifth bullet, "Inform both the Internal QA Staff and the Federal System owner of any Section 508 Compliance failures found while testing."

27. Page 36, under "The IV&V Organization will:", add bullet, "Establish documentation and findings in Dimensions.".

28. Page 37, under "The Federal System Owner will:", first bullet, added "including the scope and specific requirements for compliance with Section 508 of the Rehabilitation Act." to end of sentence.

29. Page 38, under "The Application Development Organization will:", add bullet, "Treat the IV&V approved instances of the application and database, which will be stored in Dimensions, as the release point to production.".

30. Page 38, under "The IV&V Organization and Dimension Administrators will:" add bullet, "Preserve a baseline for the application in Dimensions.".

31. Page 43, under "The Application Development Organization will:" add bullet, "Ensure system/application/process documentation is stored in Dimensions.".

32. Page 43, under "The IV&V Organization will:" add bullet, "Ensure access to Dimensions for Technical Documentation.".

33. Page 44, under "The IV&V Organization will:" add bullet, "Ensure IV&V testing report is stored in Dimensions.".

34. Page 46, under "The Application Development Organization will:", added bullet, "Ensure application/web pages, content, and client server applications comply with Section 508 of the Rehabilitation Act.".

35. Page 46, under "The Application Development Organization will:", add bullet, "Ensure system/application/process documentation is stored in Dimensions.".

36. Page 47, under "The IV&V Organization will:" add bullet, "Ensure access to Dimensions for Technical Documentation.".

37. Page 47, under "The IV&V organization will:", fifth bullet, added "including the scope of testing for compliance with Section 508 of the Rehabilitation Act." to end of sentence.

38. Page ATT2-4, Attachment 2 - Legislative Mandates. Added references to Section 508 of the Rehabilitation Act and the Final FAR Rule.

39. Page ATT2-4, Attachment 2 - Legislative Mandates. Add VPAT information, QNet Tech website, and direct link to VPAT document.

iv

40. Page ATT9-1, Attachment 9 - Model for Internal Quality Assurance Lab", under "WebXM by Watchfire", added "These features allow testing the level of compliance with Section 508 or the W3C's WCAG accessibility standards.

41. Page ATT9-2, Attachment 9 - Model for Internal Quality Assurance Lab", added sentence, "IV&V will utilize an approved CMS Section 508 tool or service for Section 508 acceptability and compliance.".

42. Page ATT11, Attachment 11 - Change made to attachment.

43. Page ATT13, Attachment 13 - Added.

44. Page ATT14, Attachment 14 - Added.

45. Page ATT15, Attachment 15 - Added.

v

Table of Contents

Introduction

1. The Role of Strategic Planning in the SDLC

2. Application Operational Planning

3. QNET Security SDLC Process

3.1 Initiation and Pre-Development Phase

3.2 Development Phase

3.3 Implementation Phase

3.4 Operations and Maintenance Phase

3.5 Post Operational Phase

3.6 508 Compliance

4. Isolated Test Facility (ITF) SDLC Process

4.1 Application Requirements Gathering and Application Development

4.2 The Role of the ITF in Stress Testing

4.3 ITF Rules of Engagement: Processes, Procedures

4.3.1 Schedule

4.3.2 Test Planning

4.3.3 Test Readiness Review

4.3.4 Environment

4.3.5 Test Cases

4.3.6 Reporting

4.4 Supported Processes and Supporting Toolset by Infrastructure

4.4.1 ITF Infrastructure

4.4.2 QNET Infrastructure

5. Quality Assurance and Independent Verification and Validation

5.1 IV&V

5.2 Beta Testers

5.3 IV&V Production Release

6. Integration Testing

7. Subsequent Releases of Applications

Appendix A – Terms, Definitions, Acronyms Appendix B - Testing Software Descriptions

Attachment 1 - Requirements Attachment 2 - Legislative Mandates Attachment 3 - QualityNet Architecture Review Board Charter Attachment 4 - QualityNet CCBoard Engineering Review Team Charter Attachment 5 – IV&V Rules of Engagement Attachment 6 - Development Life Cycle (SDLC) Attachment 7 - ITF Engagement Request Form Attachment 8 - IV&V Engagement Request Attachment 9 - Model for Internal Quality Assurance Lab Attachment 10 – Dimensions System Migration and Update Procedures vi

Attachment 11 – Test Exception Risk Assessment Attachment 12 – SDLC Process Flow Attachment 13 - Adding a Deployment Package to Dimensions Attachment 14 - Retrieving a Deployment Package from Dimensions Attachment 15 - Deployment Package Life Cycle & Definitions vii

QualityNet SDLC May 2006

QualityNet

Introduction This document specifies the System Development Life Cycle (SDLC) process as it relates to the QNET infrastructure, Security, Isolated Test Facility (ITF) and Independent Verification and Validation (IV&V) processes. These processes encompass an explanation of the SDLC approach from high level strategic planning, followed by a detailed discussion of each SDLC process. In some cases, steps of the process are documented in greater detail in companion documentation, which is provided in the Appendices of this document.

The guidelines for progressing through the phases of application approval, planning, security, application development, user acceptance testing, independent validation, stress testing, and production release (SDLC) are discussed herein. In some SDLC stages, a strict enterprise methodology is required, and in other cases flexibility is given for independent internal (independent application development organization) processes.

Applicable QNET workgroups are identified throughout the body of this document. The relationship of these groups and their range of responsibilities to specific stages of the SDLC are defined, along with responsibilities assigned to individual roles.

A standard toolset is defined and configured to support SDLC policies. Where further detailed information is required on this toolset and/or its configuration, references to companion documentation are made.

Defining the process of requirements collection (See Attachment 1 - Requirements) and stipulating the tool that houses requirements is not part of the SDLC EDT charter. However, it is understood that the application developer will have business requirements that are utilized as part of the SDLC process discussed in this document.

The goal of the QualityNet SDLC is to ensure the release of the highest quality source code or COTS products, utilizing proven, compatible, enterprise software that performs acceptably and is delivered in an acceptable timeframe. There will be a direct correlation between the success or failure of a system navigating the SDLC, and the amount of attention and effort given to planning.

QualityNet SDLC May 2006

1. The Role of Strategic Planning in the SDLC

It is imperative that programmatic management defines, to the best of their ability, a strategic (2 to 3 year), as well as tactical (6 to 12 months) plan. It is understood that legislative mandates (See Attachment 2 – Legislative Mandates), shifting priorities, etc., change these plans.

However, in order for operational plans to be defined, there must be some framework of tactical and strategic goals. Scheduling tasks is more easily accomplished if there is consideration given to longer range planning. It should be evident how the proposed application or application releases flowing through the SDLC fit into the tactical and strategic goals for the system.

Every Federal system owner must engage the programmatic community to develop, revise and amend the strategic and tactical goals for their individual system. The tactical plan should be reviewed every January and be completed no later than the last full working day of January. The strategic plan will be posted to the QNet TECH (http://qnettech.sdps.org/) site so that the strategic plan can be reviewed by any administrator, developer, or manager that has access to the QNET site. The QNet TECH (http://qnettech.sdps.org/) site is strictly for administrators, developers, and managers, as the general user community does not have access to this site.

In summary, the respective responsibilities for the strategic planning phase are as follows.

The Federal System Owner will:

• Define strategic (2 to 3 year) and tactical (6 month) goals for the system and ensure they are posted on the QNet TECH (http://qnettech.sdps.org/) site. These plans will be revisited and revised every January and be completed no later than the last full working day of that month.

2. Application Operational Planning

Target QNET Architecture, the Architecture Review Board (ARB), the Change Control Board (CCB)

It is the responsibility of the Federal system owners to be familiar with the QNET target application architecture. They identify the appropriate application development parties who must interface with the Architecture Review Board (ARB) and the Change Control Board (CCB). The ARB is the senior technical body that sets the technical standards for the technologies and their application within QaluityNet (See Attachment 3 – Architecture Review Board Charter.)

The CCB is the entry point in to QNET operations (See Attachment 4 - Change Control Board Charter) for any proposed new system to be developed for QNET or significant changes to the existing QNET structure.

In addition, any existing systems that are candidates for rewrites to a new target technology must also be reviewed by the ARB. It is not necessary for communication with the ARB on the development and release of QNET software utilizing approaches and products already http://qnettech.sdps.org/ https://blackpearl.bcssi.com/exchweb/bin/redir.asp?URL=http://qnettech.sdps.org/ http://qnettech.sdps.org/ https://blackpearl.bcssi.com/exchweb/bin/redir.asp?URL=http://qnettech.sdps.org/ http://qnettech.sdps.org/ https://blackpearl.bcssi.com/exchweb/bin/redir.asp?URL=http://qnettech.sdps.org/

QualityNet SDLC May 2006 sanctioned as a QNET standard by the ARB. The ARB meets monthly. Figure 1 depicts how these organizations interact during this phase.

1. Application Development Organization

RAC-D

2. Configuration

Management Administrator

4. Architecture Review Board

ARB?

5. Is the RAC-D Approved by

ARB?

Application Development Commences

RAC-D Approval Process

(1) The application development organization reviews the QNET target architecture documentation and fills out a RAC-D and anticipated implementation date for the proposed system.

(2) The RAC-D is submitted to the Configuration Management Administrator.

(3) Tracking number is assigned, RAC-D is entered into Dimensions, and forwarded to ARB.

(4) The ARB interfaces with the Application Development organization to resolve any technical approaches that do not conform to the target QNET architecture. Non-compliance will affect the anticipated implementation date.

(5) The ARB reviews RAC-D for compliance with QNET target architecture and recommends approval or disapproval for proposed system.

N Y

3. Assign Tracking Number, Enter into

Dimensions, and Forward to ARB

Figure 1 - RAC-D Approval Process

For new systems, the Federal system owner will require that the development organization obtain a copy of the Requirements and Conceptual Design Document (RAC-D) from the QNET Change Control Board (CCB). The federal application owner will require that the development organization obtain a copy of the QNET target application architecture from the ARB so that the application development organization (ADO) can determine whether their proposed technologies and architecture comply with the QNET standards. The federal owner will require that the development organization receives a copy of the procedures to be used for independent validation of their application by an independent verification and validation vendor (IV&V).

(Discussed in Attachment 5 – IV&V Rules Engagement).

QualityNet SDLC May 2006

The federal application owner will require that the application development organization receives a copy of this document, so they are familiar with the SDLC process for QNET and the compliance expectations. All pertinent documents can be downloaded and printed from the QNet TECH (http://qnettech.sdps.org/) site.

Upon review of the preferred QNET architecture document, as well as any security guidelines provided by the ISSO, the application development organization will complete the RAC-D and submit it to the CCB. The RAC-D template available on the QNet TECH (http://qnettech.sdps.org/) website provides a complete list of required information. The application development organization will also provide an anticipated implementation plan for the development of the application, to include: projected development schedule, security planning, projected ITF timeline (if required), and projected production release timeline. The application development organization will coordinate with the QNET Information System Security Officer (ISSO) on security and contingency planning requirements and work with the IV&V Project Manager to establish the IV&V testing timelines.

In some cases, the new proposed system may be using well-established and sanctioned methodologies, so there may not be any need for a RAC-D or an ARB review. Members of the ARB also serve on the CCB and have the authority to make this determination. The CCB will serve as the entry point for the project, and put it on a faster track if it is already architecture compliant. If, in the opinion of the ARB personnel on the CCB, the proposed system needs further analysis from an application architecture perspective, the RAC-D will be designated as an “in progress”, since it will be deferred to the ARB for review.

If the proposed system is rejected by the ARB from an application architecture perspective, or the system proposes new enterprise software purchases, the ARB will work with the application development entity until an acceptable planned implementation is identified. This may include appropriate ITF engagements to validate new software. If an ITF engagement is required by the ARB, it is incumbent upon the ARB to notify the Federal Infrastructure Owner of this activity.

It should be noted that an ITF engagement before release will necessitate revisiting the anticipated implementation date.

Any Federal system owner can require that enterprise software is tested, or that an application is stress tested before release. The nature of this testing would vary based on mutually agreed to criteria determined by the system owner and the ITF staff. Time in the ITF lab would have to be scheduled with the appropriate staff.

Once an acceptable approach is identified, the RAC-D will be amended, and referred back to the CCB with approval from ARB. It is the prerogative of the CCB/ARB to require that the application is stress tested and has been certified and accredited by the security team before release. This certification may be waived at the discretion of the Deputy Director and/or Director of the Information Systems Groups (ISG) within CMS. The ISSO must provide an estimate on how long it would take to get the application certified. This is required to assess the overall impact of the certification on the application development timelines.

http://32.86.166.94:8081/index.shtml http://32.86.166.94:8081/index.shtml https://blackpearl.bcssi.com/exchweb/bin/redir.asp?URL=http://qnettech.sdps.org/ http://32.86.166.94:8081/index.shtml

QualityNet SDLC May 2006

Upon approval from the ARB/CCB process, the Federal system owner will be notified of their RAC-D’s approval, at which time they will select an appropriate independent validation contractor and beta testers. (See Attachment 4 – QualityNet Change Control Board Engineering Review Team Charter).

In addition to the above resource allocation efforts, the Federal system owner will require the application development organization collect functional requirements utilizing a tool compatible with the CMS approved test tool suite. This will ensure that requirements can be shared with the IV&V team. To interface with the test tool suite, the requirements shall be in MS Word, Excel or Access.

Constant communication among the application owner, the application developer, quality assurance, the ISSO, the ITF (if required) and IV&V is important during the planning phases.

Once the initially approved milestones have been set, they will be shared with all components of this team. Important dates include the ITF engagement (if new enterprise software or stress testing) is required, QA testing, IV&V testing, ITF stress testing, security certification and accreditation (if it has not been waived), and production release. Important aspects of each project may include legislative mandates such as Privacy, Security, HIPAA and 508 Compliance.

(See Attachment 2 –Legislative Mandates).

The QualityNet configuration management administrator, application development organization, application development organization internal quality assurance (QA) organization, and the independent verification and validation (IV&V) organization to work together to ensure approved application code is stored in Dimensions. All QualityNet system development contracts were modified to direct the use of the SDLC polices and procedures. At this time, there are two approved methods for compliance: (1) the direct use of the CMS implementation of Dimensions for source code management and related documentation, or (2) the delivery of Deployment Packages as defined below which will be archived in the CMS implementation of Dimensions. (See Attachment 15 for Deployment Package Life Cycle Description and Deployment Package Definitions).

(1) Direct Use of Dimensions

A Federal System Owner may choose to have their application development organization use the CMS implementation of Dimensions for their day-to-day archival of source code and related project documentation. At a minimum, the items archived in Dimensions must include:

1. A complete set of source code corresponding to the application version delivered for IV&V deployment.

2. A complete set of application files for the version delivered for Production deployment including but not limited to executables, classes, JAR/EAR files, configuration files, build scripts, etc.

3. A complete set of deployment instructions for the version delivered for Production deployment.

QualityNet SDLC May 2006

4. Additional items that may not be adequately described above but deemed necessary for inclusion by the application development organization and/or Federal System Owner.

(2) Delivery of Deployment Packages

1. Deployment package procedures have been established to facilitate the collaborative effort between these various organizations. These procedures are the required method to deliver system releases to IV&V, as well as, system releases to the government that have been granted an IV&V waiver for contractors utilizing this delivery method. The deployment package procedures are located in (See Attachment 13 - Adding Deployment Packages to Dimensions and Attachment 14 - Retrieving Deployment Packages from Dimensions), and at http://qnettech.sdps.org.

QualityNet SDLC May 2006

SYSTEM DEVELOPMENT LIFE CYCLE

(Check Points, Activities, Artifacts)

APPLICATION

PLANNING DEVELOPMENT PHASE IMPLEMENTATION

PHASE

APPLICATION

DEVELOPMENT

o Review ARB Charter o Review CCB Charter o Review QNET SDLC Process

Document o Complete RAC-D Application o Review QNET Architecture

Specification o Review IV&V Rules of

Engagement o Review ITF Rules of

Engagement o Submit RAC-D to ARB o 508 Compliance & VPAT o Receive Business Requirements Document from application owner o Create Systems Design Document o Provide anticipated development schedule o Provide projected production release timeline o Develop Code, ensuring compliance with Privacy, Security, HIPAA and Section 508 mandates o Provide Impact Analysis to QA &

IV&V

o Select IV&V Contractor o Submit IV&V Engagement Request

Form o Schedule IV&V Lab Time o Complete and Submit an ITF

Request Form o Schedule ITF Lab Time o Complete VPAT o Work with CM, QA and IV&V to ensure approved application code is stored in Dimensions.

o Work with CM to deploy application to production.

ARB

o Provide Application Development with definition of the preferred QNET target application architecture o Accept/Reject RAC-D o Determine if application needs stress testing o Require new proposed enterprise software product is validated in the ITF o N/A o N/A

CCB

o Create CR for approved RAC-D o Identify servers, resources and hardware purchases o N/A o N/A

INTERNAL QA

o Collaborate with Application Development and Federal System owner to identify required resources for testing o Review and update User Manual o Review and update Requirements

Documentation o Review and update Design

Documentation o Test Planning and Execution o Review VPAT o Coordinate Beta Testing if applicable o Coordinate Section 508 Compliance testing for applications o Deliver Beta Testing Results to

Federal System Owner, Beta Testers and IV&V Contractor o Work with CM and IV&V to ensure approved application code is stored in Dimensions.

QualityNet SDLC May 2006

SYSTEM DEVELOPMENT LIFE CYCLE

(Check Points, Activities, Artifacts)

APPLICATION

PLANNING DEVELOPMENT PHASE IMPLEMENTATION

PHASE

IV&V

o Collaborate with Application Development to identify required resources for testing o Provide IV&V Rules of Engagement documentation to application development o Develop and inform application development of testing timelines o Review Business Requirements Documentation o Coordinate Section 508 Compliance testing for applications o Review System Design Documentation o Review Beta Testing results o Conduct Test Planning in

TestDirector o Participate in Readiness Meetings o Give go/no go decision for release into production to Federal System Owner and QA Team Lead.

o Submit IV&V Final Report o Work with CM and QA to ensure IV&V approved application code is stored in Dimensions o Execute tests in TestDirector o Identify defects

ITF

o Collaborate with Application Development to identify required resources for testing o Perform ITF Research as needed o Provide ITF Rules of Engagement documentation to application development o Develop and inform application development of testing timelines o Review RAC-D o Execute Stress Testing o Execute Trade Study

Testing o Submit ITF Final Report

SECURITY

o Review RAC-D.

o Collaborate with Application

Development to identify security requirements.

o Initiate Risk Assessment.

o Data Sensitivity Assessment o E-authentication Risk

Assessment determination.

o Provide Security Rules of Engagement to application development.

o Complete Risk Assessment.

o Certification & Accreditation o 508 Compliance Validation Check

QualityNet SDLC May 2006

In summary, the respective responsibilities for the application operational planning phase are as follows:

• Require that the application development entity receive a copy of the RAC-D, QNET target architecture specification, definition of the SDLC process (this document), and procedures for IV&V engagement.

• Require that the application development organization receive a copy of the QNET System Security Policies Handbook.

• Select an appropriate IV&V organization for the proposed application once the application approach is approved by the CCB/ARB.

• Select appropriate beta testers from user community.

• Stipulate that requirements are documented in a format compatible with test tracking tool, such as MS Word, Excel or Access.

• Upon acceptance of the architectural approach (approved RAC-D), decide whether stress testing is required of this application. If so, require that the application development organization schedule time in the ITF as a future engagement. They should ensure that the ITF engagement is reflected in the anticipated implementation timeline.

• Require that new enterprise software being proposed by the system is tested in the ITF.

• Require that the ADO create an anticipated project timeline, so that the IV&V contractor and ITF staff can review it and identify resource (personnel and ITF hardware) availability for stress testing or research and IV&V testing to include Section 508 Compliance testing.

• Require that the ADO, in coordination with the ISSO, perform; a data sensitivity assessment, Risk Assessment (RA) when appropriate, e-authentication risk assessment when appropriate, and receive Certification & Accreditation (C&A) prior to placing the system into production (See Section 3 - QNET Security SDLC Process). This certification and accreditation may be waived or deferred for later development at the discretion of the Deputy Director and/or Director, ISG.

The Application Development Organization will:

• Obtain and review the QNET architecture specification.

• Obtain and review the definition of the QNET SDLC process (this document).

• Obtain and review the IV&V rules of engagement document.

• Complete and submit the RAC-D to the CCB.

• Work with the ARB, if necessary, to amend application approach to comply with target

QNET application architecture.

• Work with the ISSO to perform; a data sensitivity assessment, RA when appropriate, e-authentication risk assessment when appropriate.

• Upon acceptance of architecture approach (approval of RAC-D), immediately begin documenting requirements.

QualityNet SDLC May 2006

• Upon acceptance of architecture approach, immediately document the anticipated high-level project timeline so that resource implications for IV&V testing and ITF scheduling can be assessed.

• Upon acceptance of the architecture approach, schedule project time in the ITF for stress testing (or Research where applicable) if required by the Federal systems owner.

• Have dedicated security staff representing their organization to work with the ISSO and security team in providing necessary documentation throughout the security certification process. The application development organization’s security resource is the primary point of contact for the ISSO and security team.

• Development will work with CM to create operational planning input into the Dimensions environment.

QualityNet SDLC May 2006

SYSTEM DEVELOPMENT LIFE CYCLE

APPLICATION DEVELOPER TIMELINE

PHASE ACTION ESTIMATE TIME TO

COMPLETE

Review QNET SDLC Process Document ~3 Days Review ARB Charter ~3 Hours Review CCB Charter ~3 Hours Review QNET Architecture Specification ~1 Day Review ITF Rules of Engagement ~2 Hours Review IV&V Rules of Engagement ~2 Hours Review Security Rules of Engagement ~2 Hours Review Section 508 Compliance and VPAT Template ~1 Day Work with CM to Create Appropriate Environment ~4 Days Complete RAC-D Application ~1 Day Submit RAC-D to ARB ~1 Hour

APPLICATION

PLANNING

Receive RAC-D approval/denial ~10 – 30 Days Create Requirements Document ~1 - 30 Days Create Systems Design Document ~1 - 30 Days Provide anticipated development schedule ~10 Days Provide projected production release timeline ~10 Days Develop Code ~1 - 6 Months Complete and Submit an ITF Request Form ~1 Day Schedule ITF Lab Time with ITF Lab Manager ~1 Day Select IV&V Contractor ~1 Day Submit IV&V Engagement Request Form 30 days prior to engagement ~1 Day Schedule IV&V Lab Time with IV&V Manager 30 days prior to engagement ~1 Day Complete VPAT ~1 - 3 Days

DEVELOPMENT

PHASE

Coordinate with Security on Risk Assessment ~1 - 2 Weeks Work with CM, QA and IV&V on approved application code. ~1 Day Work with CM to deploy application to production.

*Dependent on the size of the Data ~1 - 3 Days

IMPLEMENTATION

PHASE

Work with Security on Certification & Accreditation ~1 - 2 Weeks

QualityNet SDLC May 2006

The ARB will:

• Accept/Reject the proposed application as specified in the RAC-D from a target application architecture perspective.

• Interface with the application development organization until acceptable architecture is Decide whether or not to require that the application is stress tested before release.

• Decide whether or not to require that a new proposed enterprise software product is validated in the ITF.

• Make a recommendation back to the CCB that the architecture and engineering approach is either acceptable or unacceptable.

The Federal Infrastructure Owner will:

• Be notified by the ARB if an ITF engagement is required.

The CCB will:

• Review RAC-D and approve or refer to ARB for guidance. Members of the ARB sit on the CCB.

• Have the prerogative, in consultation with the ARB, to require that the application be stress tested prior to release.

The QNET Information Systems Security Officer (ISSO) will:

• Participate and serve as a member with Architectural Review Board.

• Provide the ADO with the application development security guidelines for QNet systems.

• Participate and serve as a member with Architectural Review Board.

• Review RAC-D to ensure adequate security planning.

• Coordinate activities with CMS Systems Security Group (SSG) to receive C&A approval prior to a system going into production if the C&A has not been waived or deferred by the Deputy Director and/or Director, SSG. If the C&A has been deferred until after production, then the ISSO will continue to work with the ADO’s security resource to attain certification post-production.

The IV&V Organization will:

• Provide rules of engagement documentation to the ADO for approved applications.

• Develop and inform the application development team of IV&V testing timelines, inclusive of additional Section 508 Compliance testing.

• Assist with the configuration and setup of TestDirector for the IV&V domain.

• IV&V staff will ensure they have access to code within Dimensions.

QualityNet SDLC May 2006

3. QNET Security SDLC Process

The implementation of an effective Information System Security (ISS) process begins at the start of the System Design Life Cycle (SDLC) process. (See: Attachment 6 - Security – CMS Methodology). During the SDLC, system information relating to Protected Health Information (PHI) is often involved and necessitates the requirement for a System Security Plan (SSP) deliverable prior to implementation of the system/application into production. CMS has issued guidelines and methodology for implementing security into the SDLC lifecycle. CMS ISS SDLC guidance can be obtained from:

http://www.cms.hhs.gov/it/security/References/ps.asp

• CMS Information Systems Security Policy, Standards and Guidelines, Handbook, Version 1.0, February 19, 2002, Chapter 7, “Integrating Computer Systems Security into the System Development Life Cycle (SDLC)” http://www.cms.hhs.gov/it/security/docs/handbook.pdf

• System Security Plans (SSP) Methodology, Version 3.0, Draft. November 6, 2002, Chapter 5, “System Security Plan Life Cycle” http://www.cms.hhs.gov/it/security/docs/ssp_meth.pdf

The QNET SDLC security process is presented in Figure 2. The process is comprised of five life-cycle phases and a series of security activities that transpire within each phase.

• Initiation and Pre-Development Phase

• Development Phase

• Implementation Phase

• Operation and Maintenance

• Post-Operational/Disposition Phase

3.1 Initiation and Pre-Development Phase

During the pre-development phase, the need for a system is expressed and the purpose of the system is documented (See Attachment 3 – Architecture Review Board Charter and Attachment 4 - Change Control Board Charter). The initial system requirement documentation is processed by the CCB and reviewed by the ARB.

The mission of the QualityNet Change Control Board (CCB) is to consolidate, evaluate, rank, and recommend implementation or disapproval of suggested changes and improvements to the QualityNet network or the software that runs on the network and to facilitate the acquisition of that hardware/software.

The mission of the QualityNet Architecture Review Board (ARB) is to ensure performance standards, promote enterprise architecture concepts, minimize redundant efforts, promote interoperability, create a stabilized environment, analyze future direction, and specify security standards to ensure the integrity of the network and protection of data. The ARB will review, http://www.cms.hhs.gov/it/security/References/ps.asp http://www.cms.hhs.gov/it/security/docs/handbook.pdf

QualityNet SDLC May 2006 provide input and offer suggestions on application architectures directed to the ARB prior to being deployed within QualityNet.

The ISSO and security team will work with the dedicated security personnel from the ADO to perform:

• An information sensitivity assessment to review the sensitivity of the information to be processed. http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

• An Electronic Protected Health Information (EPHI) determination.

http://csrc.nist.gov/publications/nistpubs/800-66/SP800-66.pdf

• An initial risk assessment of the application.

http://cms.hhs.gov/it/security/docs/RA_meth.pdf

• A System security assessment and the development of a security requirement document (i.e., personnel security, physical security, input/output, data integrity/validation, identification and authentication, authorization and access, and audits).

• Initiation of the security plan is based on available information at the onset of the SDLC process. http://www.cms.hhs.gov/it/security/docs/ssp_meth.pdf

The HIPAA Security Rule specifically focuses on the safeguarding of electronic protected health information (EPHI). EPHI is individually identifiable health information (IIHI) that is transmitted or maintained electronically. EPHI excludes information transmitted or maintained in media that are not electronic.

The E-Government Act of 2002 (Public Law 107-347) recognized the importance of information security to the economic and national security interests of the United States. Title III of the E- Government Act, entitled the Federal Information Security Management Act of 2002 (FISMA), tasked the National Institute of Standards and Technology (NIST) with responsibilities for standards and guidelines, including the development of:

• Standards to be used by all Federal agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to a range of risk levels;

• Guidelines recommending the types of information and information systems to be included in each category; and

• Minimum information security requirements (i.e., management, operational, and technical controls), for information and information systems in each such category.

FIPS Publication 199, http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf, addresses categorizing information and information sensitivity analysis.

Electronic authentication (E-authentication) is the process of establishing confidence in user identities electronically presented to an information system.

Special Publication 800-63, http://csrc.nist.gov/publications/nistpubs/800-63/SP800- 63v6_3_3.pdf, supplements OMB guidance, E-Authentication Guidance for http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf http://csrc.nist.gov/publications/nistpubs/800-66/SP800-66.pdf http://cms.hhs.gov/it/security/docs/RA_meth.pdf http://www.cms.hhs.gov/it/security/docs/ssp_meth.pdf http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf

QualityNet SDLC May 2006

Federal Agencies, (OMB 04-04), that defines four levels of authentication Levels 1 to 4, in terms of the consequences of the authentication errors and misuse of credentials.

A preliminary risk assessment http://cms.hhs.gov/it/security/docs/RA_and_SSP_guidance.pdf should be conducted that results in an initial description of the basic security needs of the system.

A preliminary risk assessment should define the threat environment in which the product or system will operate. This assessment is followed by an initial identification of required security controls that must be met to protect the product/system in the intended operational environment.

This preliminary risk assessment will be conducted by the ISSO and security team in conjunction with the dedicated ADO security resource.

3.2 Development Phase

During the development phase, the system is designed, purchased, programmed, developed, or otherwise constructed. The six steps in the development phase are:

• Formal Risk Assessment.

• Security Planning.

• Security Requirements Analysis (i.e., personnel security, physical security, authentication, access, and audits).

• System Security Plan (SSP) Update.

• Test and Evaluation.

• Contingency and Disaster Recovery Planning.

The first step in analyzing the security functional requirements is to identify the protection requirements for the system through a formal risk assessment process. Documentation can be found at:

http://cms.hhs.gov/it/security/docs/RA_meth.pdf http://cms.hhs.gov/it/security/docs/RA_and_SSP_guidance.pdf

This analysis will build on the initial risk assessment performed during the Initiation phase, but will be more in-depth and specific. The risk assessment brings together important information for agency officials with regard to the protection of the information system and generates essential information required for the security plan.

To perform the information security risk assessment, the system owner and the ADO must identify the system’s threats and associated vulnerabilities. For each threat/vulnerability pair, the system owner determines the severity of impact upon the system’s confidentiality, integrity and availability, and determines the likelihood of the vulnerability exploit occurring given existing security controls. The product of the likelihood of occurrence and the impact severity results in the risk level for the system based on the exposure to the threat/vulnerability pair.

Once the risk level is determined for each threat/vulnerability pair, safeguards are identified for pairs with moderate or high-risk levels. The risk is re-evaluated to determine the remaining risk, or residual risk level, after the recommended safeguard is implemented.

http://cms.hhs.gov/it/security/docs/RA_and_SSP_guidance.pdf http://cms.hhs.gov/it/security/docs/RA_meth.pdf http://cms.hhs.gov/it/security/docs/RA_and_SSP_guidance.pdf

QualityNet SDLC May 2006

NIST Special Publication 800-30, http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf Risk Management Guide for Information Technology Systems, can be consulted for guidance on conducting risk assessments.

The second step in analyzing system development security requirements is security planning.

The CMS SSP Methodology, located at:

http://www.cms.hhs.gov/it/security/docs/ssp_meth.pdf

The primary objective of the CMS SSP Methodology is to provide IT security guidance to CMS components and its partners in implementing an IT security program that ensures regulatory and standards compliance. It is a tool to be used to ensure continuity of operations and the Confidentiality, Integrity, Availability (CIA), audit ability and accountability of information and resources.

The Federal Information Security Management Act (FISMA) requires agencies to have system security plans that address networks, facilities, information systems, or groups of information systems, as appropriate. QualityNet has two security plans:

• The QualityNet General Support System (GSS), System Security Plan (SSP), Version 1, May 2, 2005 addresses the QualityNet Infrastructure.

• The Health Care Quality Improvement System (HCQIS) Major Application, System Security Plan (SSP), Version 2, May 31, 2004 addresses the three QualityNet application groups (i.e., CROWN, SDPS, and QIES).

These System Security Plans are certified and receive either interim or final accreditation every three years. The risk assessments, that are part of this development phase, are submitted to the CMS System Security Group (SSG) where they are reviewed and are filed with the appropriate System Security Plan. Identified risks are made part of CMS submissions to OMB and include:

• Corrective Action Plans

• Plan of Actions and Milestones (POA&M)

• Privacy Impact Assessments (PIAs)

Security Planning for an information system ensures that required security controls (planned or in place) are fully documented. The security plan also provides a complete characterization or description of the information system. Attachments may include references to key documents supporting the agency’s information security program (e.g., configuration management plan, contingency plan, incident response plan, security awareness and training plan, rules of behavior, risk assessment, security test and evaluation results, system interconnection agreements, security authorizations/accreditations, and plan of action and milestones).

NIST Special Publication 800-18, Guide for Developing Security Plans Information Technology Systems, http://csrc.nist.gov/publications/nistpubs/800-18/Planguide.PDF http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf http://csrc.nist.gov/publications/nistpubs/800-18/Planguide.PDF

QualityNet SDLC May 2006 and, NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf, can be consulted for guidance on development of system security plans.

The third step during the development phase is testing and evaluation.

The security controls developed for a new application or system must be tested and evaluated prior to deployment to ensure that the controls are working properly and are effective. Some types of security controls (primarily those controls of a non-technical nature) cannot be tested and evaluated until the information system is deployed—these are typically management and operation level controls. For those security controls that can be assessed prior to deployment, a security test and evaluation plan must be written and approved by the QualityNet ISSO. This plan guides the developmental security testing and evaluation of the security controls and provides important feedback to information system developers and integrators.

The fourth step during the development phase is to review contingency and disaster recovery requirements. These requirements must be included, with QualityNet ISSO review and coordination, into the CMS QualityNet Contingency Plan. The determination as to whether any given system must have a disaster recovery plan is at the discretion of the Deputy Director and/or Director, ISG.

The CMS QualityNet Contingency Plan establishes procedures to recover applications and system components following a major disruption. The following objectives have been established for this plan:

• Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:

Notification/Activation phase to detect and assess damage and to activate the plan Recovery phase to restore temporary IT operations and recover damage done to the original system Reconstitution phase to restore IT system processing capabilities to normal operations.

• Identify the activities, resources, and procedures needed to carry out system/application group processing requirements during prolonged interruptions.

• Assign responsibilities to designated QualityNet personnel and provide guidance for recovering affected system/application groups during prolonged periods of interruption and transition to normal operations.

• Ensure coordination with other CMS staff who will participate in the contingency planning strategies. Ensure coordination with external points of contact and vendors who will participate in the contingency planning strategies.

These four development activities support or coincide with the ISSO and SSG certification and accreditation activities that all systems must undergo to ensure security compliance. The System Owner performs system certification. Accrediting a system must be performed by the CMS CIO http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf

QualityNet SDLC May 2006 or CIO representative. At the end of this phase the system security plan must be complete and functional.

3.3 Implementation Phase

Any testing of the security features that are part of the system design will be made part of the IV&V testing. This testing may also occur ahead of IV+V at the discretion of the ADO during the internal QA phase of validation.

Prior to final system deployment, a security certification should be conducted by the system owner, coordinated by the ISSO, to ensure that security controls established in response to security requirements are included as part of the system development process. This security certification may be waived or deferred at the discretion of the Deputy Director and/or Director, ISG. If deferred, the ISSO, security team, and ADO security staff will continue to work toward certification during the post-implementation phase of the system development.

In addition, periodic testing and evaluation of the security controls in an information system must be done to ensure that the controls are effectively implemented. When comprehensive evaluation of security control effectiveness is necessary through established verification techniques and procedures (also known as security certification) is a critical activity that can be conducted by the IV&V team to give the system owner confidence that the appropriate safeguards and countermeasures are in place to protect the agency’s information system.

3.4 Operations and Maintenance Phase

During this phase, the system performs its work. If the system undergoes significant modifications that impact the security of the system, the ISSO will be notified by the Federal System owner. As a result of the notification the ISSO will ensure that all changes to security activities will be documented in the security plan.