CONFIGURATION MANAGEMENT PLAN (CMP) For the CRS Replacement Project
STATE OF WASHINGTON DEPARTMENT OF SOCIAL AND HEALTH SERVICES
Table of Contents
1.0 VERSION HISTORY ...... 4
2.0 INTRODUCTION ...... 4 2.1 BACKGROUND...... 4 2.2 OVERVIEW OF THE SYSTEM(S) ...... 4 2.2.1 System Mission...... 4 The Economic Services Administration is implementing an off-the-shelf solution to replace a failing Client Receivables System (CRS) for the Office of Financial Recovery (OFR). By funding this request, ESA is expected to be able to prevent costly failures, implement efficient account establishment and tracking processes, and optimize recoveries...... 4 2.2.2 Data Flow Description ...... 4 2.2.3 System Architecture ...... 9 2.2.4 System Administration and Management Activities ...... 10 2.3 PURPOSE OF THIS DOCUMENT ...... 10 2.4 SCOPE ...... 10 2.5 CM ROLES AND RESPONSIBILITIES ...... 10 2.6 CM POLICIES AND PROCEDURES ...... 12 2.6.2 Change Control Board – Organization Level...... Error! Bookmark not defined. 2.6.3 Configuration Management Board Change Functions ...... 14 2.6.4 Frequency of CMB Policy and Procedure Reviews ...... 14 2.6.5 Schedules and Resource Requirements ...... 15 2.7 CM TOOLS...... 15 2.7.1 Change Requests & Tracking ...... 15 2.7.2 Component & Configuration Item Tracking ...... 15 2.7.3 Release Management ...... 15 2.7.4 Document Management ...... 16 2.7.5 Monitoring ...... 16 2.8 CM RETENTION, ARCHIVING, STORAGE & DISPOSAL ...... 17 2.8.1 Retention ...... 17 2.8.2 Archiving ...... 17 2.8.3 Storage...... 17 2.8.4 Destruction ...... 17 3.0 CM ACTIVITIES ...... 18
3.1 CONFIGURATION ITEMS...... 18 3.1.1 Use of Configuration Items ...... 18 3.1.2 Example Configuration Items ...... 18 3.1.3 Composition of a Configuration Item ...... 18 3.1.4 Information System Components ...... 18
2
3.1.5 Types of Configuration Items (CI) ...... 19 3.1.6 Criteria for Identifying Configuration Items ...... 20 3.1.7 Configuration Item Labeling...... 20 3.1.8 Configuration Item Versioning ...... 20 3.2 CONFIGURATION BASELINING ...... 21 3.2.1 Identification of Applicable Common Secure Configurations...... 21 3.2.2 Information System Component CI Baselines ...... 21 3.3 CONFIGURATION CHANGE CONTROL ...... 21 3.3.1 Change Request...... 21 3.3.2 Assigning CR Type ...... 22 3.3.3 Change Request Transition ...... 23 3.3.4 CR State Transitions ...... 23 3.3.5 Post Release Review...... 23 3.3.6 Handling of Scheduled, Unscheduled, & Unauthorized Changes ...... 24 3.3.7 Functional Testing ...... 26 3.3.8 Submission of findings to the Configuration Management Board ...... 26 3.3.9 Configuration Management Board Evaluation and Approval Process ...... 27 3.3.10 Patch Management ...... 28 3.3.11 Recording Requirements ...... 28 3.4 CM MONITORING ...... 29 3.4.1 Organization Level Monitoring Tools ...... 30 3.4.2 Monitoring Frequencies...... 30 3.5 CM REPORTING...... 30 3.5.1 Reporting Recipients ...... 30 3.5.2 Reviewing Reports ...... 30
3
1.0 VERSION HISTORY The Configuration Management Plan (CMP) is a “living document” – as processes and systems are continuously improved, the necessary related changes will be reflected in this document. This section will be used to maintain version control for the CMP. As changes are suggested and implemented, they will be reflected in chronological fashion.
Version Change Description Changed By Date 1.0 Preliminary Draft for Review Liberum LLC 11/22/2016
2.0 INTRODUCTION This is the Department of Social and Social Health Services (DSHS) software focused Configuration Management Plan. This document is intended for comments and feedback from stakeholders.
2.1 BACKGROUND The configuration of the Client Receivables System and its components has a direct impact on the Washington State recoupments and collection of State and Federal assistance programs. How those configurations are established and maintained requires a disciplined approach for providing adequate tracking of configurations, releases, and versions during development.
This process is critical for accomplishing the objectives of the CRS Replacement Project and maintaining an accurate collections and debt management system in accordance with state and federal regulations and policies.
2.2 OVERVIEW OF THE SYSTEM(S)
2.2.1 System Mission
The Economic Services Administration is implementing an off-the-shelf solution to replace a failing Client Receivables System (CRS) for the Office of Financial Recovery (OFR). By funding this request, ESA is expected to be able to prevent costly failures, implement efficient account establishment and tracking processes, and optimize recoveries.
2.2.2 Data Flow Description The data flow for this configuration management plan is based on 4 stable environments with the exact same hardware and baseline application setup. Each of the environments are clearly defined and accessed only by the designated teams as follows:
4
2.2.2.1 Business Analysts – Business Analyst SB Environment (BASB) Business Analyst SB Environment (BASB) allows BA Team members to do configuration and functionality testing. The BASB environment is also used for research and development for the BA Team prior to release into the DEVSB Environment.
Figure 1 - BASB Environment
2.2.2.2 Developers – Development SB Environment (DEVSB) Development SB Environment (DEVSB) allows for Development Team members to develop, create, test, and promote custom programs and ETL’s, after formal validation, for release into the Development Environment.
5
Figure 2 - DEVSB Environment
2.2.2.3 Developers – Development Environment (DEV) The Development Environment is used as the final promotion environment prior to approving the software release to move on to the Testing Environment. The Development Manager is responsible for this environment and once the developers complete their own development and testing of functionality, will use the DEV environment to incorporate all updates prior to notifying the Release Manager of a software release.
6
Figure 3 - DEV Environment
2.2.2.4 Software Release Process This workflow shown below depicts the Software Release Process after the Development Environment Manager has approved the software release and is ready to promote the updated versions. The Release Manager and Configuration Manager will ensure that the compilation of Configuration and Development Releases are successful, all versions are merged and bundled into a single zip file, it is archived, and then published to each team Lead to update each of their respective environments with the new Release.
7
Figure 4 - Software Release Cycle
2.2.2.5 Software QA/Test Team – Test Environment (TEST) The following diagram demonstrates the process for updating the test environment when a new release is available and the versioning of the environment in coordination with the new software release. When a new release is available, the previous snapshot archived by the Release Manager in the designated location, and the new release is implemented by the Release Manager and Database Administrator. Once the implementation is performed, verification of the implementation is conducted by the owners of each of the environments. Upon successful verification of the implementation, a new version (Snapshot) is created by the Release Manager. After the environment is versioned by the environment owner, the environment will be made available for the testing process.
8
Figure 5 - Test Environment
2.2.3 System Architecture The current proposed system architecture for the WaTech Virtual Private Cloud environments are listed below. These are subject to change based on any unforeseen system requirements that are identified. Virtual Host 1 2 3 4 BASB DEVSB DEVELOPMENT TEST (App (App (App Server/Web (App Server/Web Server/Web Server/SQL DB) Server/Web Server/SQL DB) Server/SQL Server/SQL DB) DB) Server O/S SQL 2014 SQL 2014 SQL 2014 SQL 2014 Windows O/S Windows Server Windows Server Windows Server Windows 2012 R2 (64-bit) 2012 R2 (64-bit) 2012 R2 (64-bit) Server 2012 R2 (64-bit) Core 4 Core 4 Core 4 Core 4 Core Memory 16 GB 16 GB 16 GB 16 GB Space 400 GB 400 GB 400 GB 400 GB (hardrive)
9
Applications Jboss App, 6.1 Jboss App, 6.1 Jboss App, 6.1 EAP, Jboss App, 6.1 EAP, Apache EAP, Apache Apache 2.4.9 w/ EAP, Apache 2.4.9 w/ 1.2.10 2.4.9 w/ 1.2.10 1.2.10 mod-jk 2.4.9 w/ 1.2.10 mod-jk mod-jk mod-jk Applications Apache 1.0.1g Apache 1.0.1g Apache 1.0.1g Open Apache 1.0.1g Open SSL Open SSL SSL Open SSL Applications Java 8 or higher Java 8 or higher Java 8 or higher Java 8 or higher
2.2.4 System Administration and Management Activities The System Administrators will be designated by the Project Director and be members of the current Development Team. Overall management activities will be approved by the Project Director or members of the Steering Committee as necessary.
2.3 PURPOSE OF THIS DOCUMENT The purpose of this document is to detail and explain the configuration management process during the development and testing of the CRS Replacement Project COTS system. It will also detail the data flow, owners for each Configuration Item, Release Management process, version promotion in environments, and how each software release will be implemented within an identifiable and controlled environment.
This document is intended to be a living document and will be updated and reviewed at regular intervals.
2.4 SCOPE The scope of this document is the identification for a software configuration management plan. Software Configuration Management is the management and control of all releases and configurations, from design to development to testing, for a COTS DM9 system to enable proper promotion and facilitate the management of all releases to ensure a complete application is provided with all functionality. CM builds on the general concepts, processes, and activities of configuration management by focusing attention on the development and implementation of the DM9 system.
Software configuration management requirements are integrated into (or complement) existing organizational configuration management processes (e.g., business functions, applications, products) and other current state and federal systems that tie into it.
2.5 CM ROLES AND RESPONSIBILITIES The set of roles (at the organizational as well as the design and development level) that are relevant to the CM program are defined along with the responsibilities.
The responsibilities are in the context of CM only and are not inclusive of other non-CM responsibilities the roles may also have.
10
The following table defines CM roles and responsibilities.
CM Role Description Level Executive Sponsor The Executive Sponsor designates and/or provides a CM Organization Project Director for the organization and approves the organizational CM design and implementation. Project Director The Project Director, also the Configuration Control Organization Authority, provides staff with organization and system infrastructure expertise to serve on the CCB and/or to conduct implementation impact analysis. The Project Director may also be the Authorizing Official. Authorizing Official The AO manages or participates in the CCB for systems Organization (AO) s/he authorizes and may provide technical staff to conduct and/or review implementation impact analysis.
The AO coordinates with the Project Director on CM issues and makes the final determination whether or not a given change or set of changes continues to be an acceptable implementation. System Owner (SO) The SO identifies, defines, and ensures implementation of System the aspects of CM for the DM9 system that have not been defined by the organization of which the information system is a part, such as OFR or ESA. The SO also ensures implementation of organizational- level CM requirements for the DM9 system. CM Program Manager The CM Program Manager develops CM policies and Organization procedures, provides direction, and oversees the implementation of the CM program for the organization and/or system level CM program. Lead Business Analyst The Lead BA assists the information system owner with System (BA) implementation of CM for the system, conducts design and configuration activities (reporting and analysis), and may serve on the CCB. The Lead BA also is the Specification Owner. System/Software The system/software developer ensures that secure System Developer configuration settings are built into applications in accordance with approved designs provided by the BA requirements and assists with configuration impact analyses and configuration monitoring activities as needed. In addition, the system/software developer may be included in the process for determining the appropriate baseline configuration for relevant CIs and may serve on
11
CM Role Description Level the CCB.
All Developers are also responsible for complying with CM policies and implementing/following CM procedures. Business Team The Business Team ensures that the demonstrated System configurations in the DM9 system are meeting the business requirements, policies, and procedures, while providing analysis on the products viability as the CRS replacement. DM9 User The DM9 user initiates change requests, assists with System functional testing, and complies with CM requirements.
2.6 CM Policies and Procedures
2.6.1.1 CM Policies
2.6.1.1.1 All updated configurations, releases or other changes, beyond the baseline configuration and initial LLDS configurations, cannot be promoted to the Development Server unless approved by the CCB. 2.6.1.1.2 Prior to promoting a new code to the Test Server, all versioning must be completed and documented to ensure proper release management policies and procedures are maintained. 2.6.1.1.3 Once a new baseline is approved and promoted, it will be permanently backed up and managed by the Configuration Manager. 2.6.1.1.4 All rollbacks or wipes of environments will be tracked and catalogued by the Configuration Manager. This ensures that the correct baseline is restored and that the historical record of system changes is accurately documented.
2.6.1.2 CM Procedures DSHS’s Change Management and SDLC procedures are thoroughly documented in Business Process Models (BPMs) using formal BPMN standards.
The Change Request Process diagram details the initial analysis phases of the change request process including all variations dependent on CR Type as listed in Section 3.3.2. All lower level processes are then accessed through the appropriate CR Type dependent sub process (if applicable). If the initiating change is related to a patch, the Patch Management process would be accessed, otherwise all other CR’s will be managed by this document
Below is a high level outline of the CR Process Diagrams:
12
13
2.6.1.3 Configuration Management Board – Organization Level The Configuration Management Board (CMB) is comprised of the Project Director, the Configuration Manager, the Release Manager, the Quality Assurance provider, and the Project Management Team. The CMB oversees the change process to ensure implementation requirements are being met and to enforce standards and any exceptions to standards in order to reduce confusion, complexity, and gaps in the review process.
The CMB is particularly focused on implementation considerations around established configurations from a variety of sources. In addition to state and federal requirements for collections around state and federal assistance programs, the CMB must bring to bear other department, agency, state, and federal controls and policies. The CM plan ensures the CMB engages in the appropriate considerations at each step in the change lifecycle, for all kinds and sources of change.
The DM9 system is made of a wide variety of configurable items. In addition to network components, system settings, other agency system interfaces and servers, the CMB scope must broadly include any change to the custom applications maintained and developed by DSHS, including both architectural and functional changes that may have implementation implications. As such, because functional changes are considered part of the “configuration” of the information system, the CMB functions, in effect, as a “change” management board. For a full definition of the CMB’s authority and scope see the DSHS Configuration Management Board Charter on the Project SharePoint site here.
2.6.2 Configuration Management Board Change Functions The Configuration Management Boards (CMB) responsibility and authority is to review and approve change requests (CRs) and the sublevel configuration items (CI’s) for the CRS Replacement Project. This includes both hardware and software change requests. They will evaluate and approve changes to the CRS Replacement project systems. The systems under this CMB’s control are all software, COTS systems, DM9, and hardware used in the various required environments. See the CRS Replacement Project Configuration Management Board Charter on the Project SharePoint site here.
2.6.3 Frequency of CMB Policy and Procedure Reviews The Configuration Management Board will conduct reviews of its policies and procedures at a frequency defined in the below table.
Review Frequency Policies Every 6 months Procedures Reviewed as needed as agenda items for the CMB.
Through the use of continuous process improvement techniques, CMB procedures will continuously be streamlined and made more efficient as changes are made to the system.
14
2.6.4 Schedules and Resource Requirements The Configuration Management Board (CMB) will convene weekly unless otherwise required to meet, or in the case there are no CI’s or other agenda items, or cancel. The Project Manager will be responsible to schedule, prepare materials, and disseminate the agenda for the CMB. The Project Director will chair the CMB meetings.
The following change conditions would require the CMB to convene in addition to the regularly scheduled meetings: • Any CR that is immediately and negatively impacting the projects schedule, scope, or budget.
2.7 CM TOOLS A number of tools are employed by DSHS that either directly or indirectly support the activities of the CM process. Some of these tools were developed by the agency, while others were developed by third parties. This section outlines the CM tools that are used and provides information about how, when, and by whom the tools are used.
2.7.1 Change Requests & Tracking On the SharePoint Project Page is a custom form, titled Change Request, developed by DCS and vendors for use by internal users for the purpose of logging and tracking Change Requests. Once a CR has been logged, information about the CR, such as identifier, status, and type, is tracked and managed. The CRS SharePoint Project Page is used when a project team member wishes to submit a CR for review, as well as when there are updates to the CR (e.g. the CR’s status changes). The CRS SharePoint Project Page is used by project team end users, BA’s, Developers, and IT Managers.
2.7.2 Component & Configuration Item Tracking Tracking changes to components and configuration items is done with the use of the configuration item database. Each time a change is made to a configuration item, a new version of that component is created that reflects the new current definition of the configuration item. Updating the configuration item inventory via the database is performed by the Developers. Developers will notify the Configuration Manager of any updates. Instructions on when and how to update the ISC and CI lists are explicitly referenced within the BPM steps that require the update activity. Detailed explanations and definitions of what information is tracked can be found in the “Configuration Items” section.
2.7.3 Release Management Overall release management will be managed and controlled by the Release Manager (RM). The RM will be solely responsible for ensuring all the newest versions of Configuration Items are incorporated into a complete “release”, that is then used as the new baseline for all environments. This establishes continuity and seamless testing between groups and servers. Each of the Configuration Items is assigned an owner. Owners are solely responsible for the revision and version control of their specified CI. The Owners are also responsible for updating the RM’s Tool to show that a newer or updated version is available of the CI. All naming conventions must be followed for the Owners and RM to ensure continuity. Refer to the Configuration Item Owner Inventory document, under the Release
15
Management SharePoint folder.
The Development Team will be using Subversion as their revision and version control tool. The versions of each configuration item will then be maintained on the Release Managers database and updated by the Development Team Owner for that specific CI. The RM will be tracking and maintaining the versions and releases of each CI using a combination of SharePoint and Excel spreadsheets.
For more detailed information, please refer to the Release Management Plan on the CRS SharePoint site here.
2.7.4 Document Management Microsoft SharePoint is the document management solution used to manage all electronic documents that define and comprise the configuration change control process. All configuration change control process documents are version controlled and managed via SharePoint. All documents pertaining to an individual CR are uploaded to a single, unique location on SharePoint and are also version controlled. Anytime a change to a controlled document occurs, a new version of that document is uploaded to SharePoint. Previous versions are retained for review and archiving purposes.
SharePoint will be used by the BA, BA’s, IT Management, Developers, and the Release Manager to store, backup, and archive their work. Every version of a SharePoint document is automatically assigned a version # by SharePoint. That number is used, in conjunction with the Configuration Item ID#, to uniquely identify each instance of a configuration item.
2.7.5 Monitoring
2.7.5.1 Code Monitoring DCS does not leverage any automated code monitoring tools at this time.
2.7.5.2 Workstation Monitoring DCS does not conduct monitoring of workstations as part of this software implementation.
2.7.5.3 Configuration Item Inventory Monitoring Monitoring the configuration item inventory confirms that the existing configuration is identical to the current approved baseline configuration. It ensures that no unapproved components (i.e. items not listed in the component inventory) or out-of-date components exist in the system.
• Configuration inventory monitoring is accomplished by the use of either the Microsoft System Center 2012 Configuration Manager or Hypervisor tool in conjunction with the CI Inventory database. Configuration Inventory monitoring is performed by the Business analysts and Developers
16
2.8 CM RETENTION, ARCHIVING, STORAGE & DISPOSAL Records pertaining to security-focused configuration management are retained for a number of reasons, including legal, technical, and business requirements. The Washington State Archives State Government General Records Retention Schedule, or SGGRRS, defines the retention, archiving, and destruction schedules for public records documenting common functions and activities of state government agencies.
2.8.1 Retention The SGGRRS defines the minimum retention period for records based on the type of record. Once the record retention period has been met, the record is either transferred to Washington State Archives for approval and selective retention or destroyed.
In order to maintain efficient and effective management of state resources, the Washington State Archives office strongly recommends the disposition of records at the end of their minimum retention period.
Refer to the SGGRRS to determine the retention schedule for a specific type of CM document.
2.8.2 Archiving Records that are designated as ARCHIVAL must not be destroyed. Records that are designated as ARCHIVAL (Approval Required) must be appraised by the Washington State Archives before disposition.
2.8.3 Storage All active (i.e. non-Archived) CM electronic documents and artifacts are stored on SharePoint.
2.8.4 Destruction All records and artifacts slated for destruction must be destroyed in a manner which renders the data unrecoverable and is the sole responsibility of the IT owner of SharePoint, the servers, or other systems containing data. Paper documents must be shredded or otherwise rendered unrecoverable. Electronic documents must be securely deleted and all data on electronic data storage devices (e.g. hard drives) must be completely and securely erased before the storage device is disposed of.
17
3.0 CM ACTIVITIES An information system is composed of many components that can be interconnected in a multitude of arrangements to meet a variety of business, mission, and information security needs. How these information system components are networked, configured, and managed is critical in providing adequate information security and supporting an organization’s risk management processes.
CIs give organizations a way to decompose the information system into manageable parts whose configurations can be actively managed. The purpose of breaking up an information system into CIs is to allow more granularity and control in managing the secure, accurate configuration of the system.
3.1 CONFIGURATION ITEMS A CI is an identifiable part of a system (e.g., hardware, software, firmware, documentation, or a combination thereof) that is a discrete target or component of configuration control processes.
3.1.1 Use of Configuration Items A CI is an aggregation of information system components that is designated for configuration management and treated as a single entity throughout the CM process.
3.1.2 Example Configuration Items Example CI’s would be: • Specific information system components, e.g.: server, application • A group of information system components, e.g.: group of servers with like operating systems, an application or suite of applications • A non-component object, e.g.: firmware, documentation • An information system as a whole
3.1.3 Composition of a Configuration Item A CI may be composed of one or more information systems components (ISCs), one or more non- component (NC) information system objects (e.g., documentation, diagrams, firmware), or some combination thereof as indicated in the following representations: i. CIA = {ISC1, ISC2, …ISCn} ii. CIB = {NC1, NC2, …NCn} iii. CIC = {ISC1, ISC2, …ISCn + NC1, NC2, …NCn} where n is greater than or equal to one.
3.1.4 Information System Components An information system component is a discrete, identifiable, IT asset that represents a building block of an information system. The information system component inventory is made up of all information system components that compose the information system.
The information system component inventory can be represented as:
18
i. IS Component Inventory = {ISC1, ISC2, … ISCn}, where n is greater than or equal to one, and ISC represents an information system component within the organization.
3.1.4.1 Use of Information System Components By utilizing the IS component inventory, each item in the inventory is associated with information that can be leveraged for determination of approved configuration baselines, configuration change control/security impact analysis, and monitoring/reporting.
3.1.4.2 Example Information System Components Some example ISC’s would be: mainframes, workstations, servers (e.g., database, electronic mail, authentication, Web, proxy, file, domain name), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications.
3.1.4.3 Information System Component Groupings Every item within the IS component inventory (i.e. ISC) is associated with one and only one CI, and hence, is included within the authorization boundary of a single information system.
3.1.5 Types of Configuration Items (CI) • Implemented Configuration o This includes the environment, organization, and organizational structure configuration items impacting the base configuration of the COTS application. • Custom Program o These cover the custom monitoring and ETL programs required for the COTS application to function properly. • COTS Software Installation o This covers the current version of the current DM COTS application. • Environment o This will cover the development, test, and production environments. • Function Specification o Functional specifications are all LLDS’s, DI FDD’s, workflow specs, user roles, DM9 config design specs, reference tables, UDP specs, Notice specs, and Reports specs. Servers • BASB • DEVSB • DEV Server • TEST Server Applications • DM9.8 or current version • Apache (Jboss) • KETTLE (ETL)
19
• Windows Server 2012 R2 Network Component Types • Virtual Private Cloud - WaTech
3.1.6 Criteria for Identifying Configuration Items The methodology used to identify the Configuration Items was based on all major software, hardware, development, design and configuration items that are required to successfully implement the DM9, REAP, solution for the CRS Replacement Project. CI’s do not include the lowest levels of the WBS, and task list from the project schedule, instead are inclusive of all major components to complete a single LLDS, configure DM9 for use, and all tables, references, roles and rules engines.
3.1.7 Configuration Item Labeling Each CI requires the following information to identify and define it: • Type (Implementation Configuration, Custom Program, COTS Software Installation, Environment, Functional Spec) • Item (sub-defined within each Type) • Item Subtype (if attached to a specific LLDS) • Phase (design, configuration, development, test) • Owner’s first and last name • Description • Location (environment, DB, workstation, etc)
3.1.8 Configuration Item Versioning Standard Convention will always be Major.Minor.Patch.Emergency. Dashes are allowed instead of periods.
3.1.8.1 Full release: vN.0 Example of 1st Release: v1.0 Partial Release: vN.N.0 Example of 1st Minor release to v1.0: v1.1.0 Patch Release: vN.N.N Example: Patch to v2.3.0: v2.3.1.0 Emergency Release: vN.N.N.N Example 2nd Emergency Release to v3.1.0: v3.1.0.2
3.1.8.2 Archive: Configuration: AC-
20
3.1.8.3 Release: R-
3.2 CONFIGURATION BASELINING A baseline configuration is a set of specifications for a system, or CI within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes. It is, in effect, the current configuration.
3.2.1 Identification of Applicable Common Secure Configurations Common Secure Configurations identify commonly recognized and standardized secure configurations to be applied to configuration items. Common secure configurations are derived from established federal, organizational, or industry standards.
3.2.2 Information System Component CI Baselines Baseline information is defined for each Configuration Item down to the Information System Component level. Configuration Item baselines will be defined at the level of CI groupings or CI Types.
3.2.2.1 Server Configurations Server Administrators will store and share this baseline documentation from the CRS Replacement Project SharePoint site.
3.2.2.2 Application Configurations All configurations settings are part of the original DM9 Application baseline and are included and referenced specifically in the approved release.
3.3 CONFIGURATION CHANGE CONTROL Configuration Change Control is the process for managing updates to the baseline configurations for all configuration items. Refer to the CM flow diagrams for specific system and specification owners. The specification owners are responsible for: • Mapping overall impact of any new version. • Completing the actual update or change to the system, functionality or specification. • Ensure each change is documented in the Configuration DB • Notify the Release Manager of the updates The CM will be responsible for compiling and creating a complete release of the newest version for use on the various servers and environments.
3.3.1 Change Request The Change Request process is triggered when a need for a change is identified. The source(s) of the
21
request as well as the system(s) affected are recorded on the CR. A CR is assigned one of the following types; Scheduled, Unscheduled, Unauthorized, Preapproved, Exempt.
3.3.2 Assigning CR Type The main deciding factor when assigning a CR Type is the relative size and complexity of the identified change, with the exception of the unauthorized type. A CR with the unauthorized type represents a change that was implemented without change control management.
Type Description Examples Exempt The Exempt type is used for minor, low Database content updates, complexity changes that are very common. creating/removing/updating accounts, and creation or deletion of user files. Preapproved The Preapproved type is used for moderately Vendor-provided security complex changes that require the full amount of patches, updated antivirus documentation however are preapproved by signatures, and replacement the Configuration Management Board. of defective peripherals or internal hardware. Unauthorized The removal of an unauthorized component or An unauthorized component program from the current configuration/system. or third party program. Scheduled Scheduled and Unscheduled changes are the See Below and most complex changes, those that require the Unscheduled full amount of documentation, as well as approval by the Configuration Management Board. Unscheduled A change that represents an emergency type An emergency fix to an issue situation. A change that must be expedited found in the system. through the process and fully documented after implementation.
Scheduled A typical change for which the full process Changes to workstation Workstation must be followed that impacts specific devices or configuration. hardware or software. Scheduled Workstation changes do not require design review. Scheduled A typical change for which the full CM process Changes to Data Schema, Application must be followed that impacts specific redefining Data Values, networks, servers, or applications. Scheduled changes to security profile of Application changes require design review. application, and changes to non-standard hosting platform or application language.
22
3.3.3 Change Request Transition After the Configuration Management Board has reviewed and approved the change detailed by a Change Request during the Initiation phase of the Configuration Management process, the owner for each of the different CI’s included on the CR are notified, as well as the Release Manager. Upon approval, the CR transitions to a Work Request (WR) and the notified owner will be responsible for completing and versioning.
3.3.4 CR State Transitions State Action Resulting State Draft User submits the Change Submitted Request (CR) with a sponsor. Submitted Initial analysis is performed by Assigned BA Lead and the CR is assigned to a BA. Assigned CR Analysis is performed Leadership Team Assessment Team Resources are estimated, CR is For Review prioritized, Design Review is conducted (if applicable) For Review CMB approves the change Development For Review CMB denies the change Declined Development Change is implemented Testing Testing Implementation is tested and CMB approved Testing Implementation is tested and Development denied CMB Configuration Management Release Board approves the CR. CMB Configuration Management Declined Board denies the CR. Release Release was unsuccessful Development Release Release was successful Closed
3.3.5 Post Release Review If after the release a security issue is found, the Work Request related to the issue must be identified. The WR is then re-assigned and returns to the CM Process in order to resolve or mitigate the issue.
23
3.3.6 Handling of Scheduled, Unscheduled, & Unauthorized Changes A change originating from a CR will initiate the configuration change control process. Based on its type, a CR is handled as described in the table below:
Type Definition Handling Initiated by Proposed Change Request Once a CR is drafted, the proposed change is formally A planned change, usually entered into the change control process. If configuration stemming from a CR, that is control is required, the proposed change is analyzed for Scheduled evaluated before the change is security impacts, tested to confirm all impacts have been implemented identified, and then implemented if approved by the CMB.
Emergency Situation An unscheduled change is handled in much the same way An unplanned change, usually as a scheduled change. The primary difference being that stemming from an emergency the implementation step occurs before the CR is drafted Unscheduled situation, that is implemented and evaluated. As soon as time allows, a CR must be before the change is evaluated completed and formally entered into the change control process.
If an unauthorized change is discovered a decision must Discovery in System be made as to whether the component is required and A change that occurs outside of the should stay or it is needs to be removed. configuration control process.
Unauthorized These types of changes are usually If the component should stay a new emergency Change discovered during configuration Request (CR with type = unscheduled) should be and/or vulnerability monitoring created.
24
Type Definition Handling Initiated by If the component should be removed a new CR with type = unauthorized should be created in order to record the removal of the component.
25
3.3.7 Functional Testing Functional testing occurs prior to system implementation. This ensures interfaces and configurations created for the new application are working properly.
Refer to (CRS Replacement Master Test Plan-Draft.docx, CRS Replacment Stage Test Plan- Draft.docx and LLDS Group Test Plans.) Functional test plans for each LLDS are described within the Master Test Plan, Stage Test Plan, and Group Test Plans.
Depending on the type of system(s) impacted by the change, different types of functional testing will need to be completed. The testing required is outlined in the table below.
Change Impacts Testing Type Testing Performed By
Only Custom Application Software Code Analysis Developer
Only Configuration Baseline including COTS Security Conformance Checklist BA Hardware & Software
Both Custom Application Software & Code Analysis Developer Configuration Baseline & & Security Conformance Checklist BA
3.3.7.1 Selecting Checklists Each configuration “Type” will be selected based on the type of Release conducted from Table 3.3.6. Checklists will always contain Implemented Configuration and Functional Spec types. Checklists will be created and selected based on the Release Manager’s guidance.
3.3.7.2 Flaw Remediation If a weakness or defect is discovered during either the Checklist process or Code Analysis, remedial action must be taken to correct or mitigate the weakness or defect. These actions must then be documented in the applicable template or tool.
3.3.8 Submission of findings to the Configuration Management Board The submission of findings to the Configuration Management Board is performed at every phase of the overall process by specific participants as defined by the table below.
Phase Actor Documents Submitted
26
Phase Actor Documents Submitted Initiation BA Development & Implementation BA Maintenance RM
All documents after creation are attached to the Change Request posted in SharePoint and continue with the CR throughout its lifecycle.
3.3.9 Configuration Management Board Evaluation and Approval Process The following criteria will be used by the CMB to evaluate Change Requests at each phase of the security focused configuration management process and provide a disposition. The CMB Chair will document and communicate the results of their evaluation as defined in the table below.
The Timeframe for Evaluation begins once the CR and all applicable documentation, as defined in the Submission of Finding to the Configuration Management Board section, have been submitted to the CMB.
Phase Evaluation Criteria Communication Time frame for Evaluation Initiation • Change Request addresses CMB Review section of 1 Day essential business need(s) CR Analysis Summary • Estimated Resource and Risk Levels of implementing proposed change are acceptable • The Technical Design spec addresses the business needs identified in the Change Request Development • The results of the Impact Status of the Change 2 days Analyses performed by the BA and Request in the CRS Application Developer, including Testing Replacement Project Results and Conformance Checklists Page results as applicable • Functional Testing Results Post Release • Results of the post-release Status of the Change 1 day Impact Analysis performed by the Request in the CRS Release Manager, including any Replacement Project additional impacts or vulnerabilities not Page previously identified
If after the specified Timeframe for Evaluation has elapsed and the CMB has not issued a disposition of a CR, no other CRs can be evaluated by the CMB until a disposition is issued for the undisposed CR.
The CMB maintains the authority to override this subjugation on a case by case basis. In the event of
27
such an override, the CMB must provide the reason for the override, as well as provide a new date by which a disposition will be issued.
3.3.10 Patch Management Patch Management is the process of acquiring, testing, and installing patches or pieces of software designed to fix problems and/or update a computer program or its supporting data.
All patches are sent to DCS through DSHS. All required patches are subject to the Patch Management process. Third party and optional patches are subject to the normal CR Process.
3.3.11 Recording Requirements The following table is for reference and defines the information that may be recorded by the organization during the configuration management process. The table also indicates the role responsible for recording the information as well as where the information is recorded.
Note that not all information listed in the table will be recorded for every change that goes through the configuration management process. Each responsible party will log the version on the Release Manager’s database on the CRS SharePoint site. Each owner is responsible for accumulating and creating the new version of their specified CI in the CMP.
Item Type Owne r
Environment Configuration Files Implemented Configuration Max Reymer
Organization Configuration Items Implemented Configuration Hugh Powers
Organizational Structure Configuration Items Implemented Configuration Hugh Powers
Work Management Configuration Items Implemented Configuration Hugh Powers
Business Rules Engine Implemented Configuration Hugh Powers
Notices Implemented Configuration Sue Hauder
User Defined Pages Implemented Configuration Hugh Powers
Reference Tables Implemented Configuration Hugh Powers
User Profiles Implemented Configuration Hugh Powers
Function Authorization Roles Implemented Configuration Hugh Powers, Max Reymer
28
Reports Implemented Configuration Sue Hauder
ETL Programs Custom Programming Hugh Powers
Monitoring Programs Custom Programming Hugh Powers
DM9 Software Installation COTS Software Installation Hugh Powers
Dev "Environment" Environment Max Reymer
Test "Environment" Environment Jonathan Wiebersch
Production "Environment" Environment Max Reymer
LLDS Functional Spec Adam Richards
DI FDD Functional Spec Adam Richards
Workfow/UC Specification Functional Spec Adam Richards
User Role Authorization Mapping Functional Spec Adam Richards
CRS-Debt Manager Configuration Design Functional Spec Adam Richards Specification
REAP Reference Tables Specification Functional Spec Adam Richards
REAP UDPs Specification Functional Spec Adam Richards
REAP Notices Specification Functional Spec Adam Richards
REAP Reports Specification Functional Spec Adam Richards
REAP Environment Configuration File Specification Functional Spec Adam Richards
Threat Model Hosting Luke Whitehall
Virtual Private Cloud Hosting Luke Whitehall
3.4 CM MONITORING CM monitoring activities confirm that the existing configuration is identical to the current approved baseline configuration, that all items in the component inventory can be identified and are associated with
29
the appropriate information system. CM monitoring also ensures that all identified components are approved components. CM monitoring is accomplished through assessment and reporting activities, both of which are carried out under the direction of the Lead BA.
3.4.1 Organization Level Monitoring Tools At the organizational level, monitoring is carried out with the use of the Microsoft System Center 2012 Configuration Manager or Hypervisor tool.
3.4.2 Monitoring Frequencies
The organization will check or define the following at a frequency defined in the table below.
Review Frequency Reevaluation of privileges Twice Monthly Reviews to identify and eliminate unnecessary functions, ports, Twice Monthly protocols, and services Employing automated mechanisms to detect the addition of Twice Monthly unauthorized components/devices into the information system Reviews and updates to the baseline configuration Twice Monthly
3.5 CM REPORTING CM reporting addresses the secure state of individual information system configurations and also supports the gathering of data for metrics that are used to provide quantitative evidence that the CM program is meeting stated goals.
The results of the CM monitoring activities are reported at each Steering Committee Meeting.
3.5.1 Reporting Recipients The results of the CM monitoring activities are reported to the Project Manager and Project Director by the acting CM Program Manager.
3.5.2 Reviewing Reports Upon receipt of the CM monitoring results report, the Project Manager and Project Director shall review the report, comparing the reported CM metrics to the organization-defined goals for the CM program. The Executive Management Team may request additional information regarding the CM program from the CM Program Manager.
30