Attachment 6 AWMS Engineering Plan.pdf

AWMS

APMC Workflow Management System (AWMS)

SYSTEMS ENGINEERING PLAN (SEP)

3/30/2022

APMC

Contents

1 Introduction

2 Program Technical Definition

2.1 Requirements Development

Requirements Trackability

2.2 Architectures and Interface Control

2.3 Design Considerations and Technical Certifications

3 Program Technical Management

3.1 Technical Planning

Technical Schedule

Maturity Assessment Planning

3.2 Technical Tracking

Technical Risk, Issue, and Opportunity Management

Risk Management

Software Engineering

3.2.3.1 Software Engineering Overview

3.2.3.2 Software Planning and Execution

3.2.3.3 Development, Testing and Deployment Environments

3.2.3.4 Software Obsolescence

Technology Insertion and Refresh

Configuration and Change Management

System Security Engineering

1 Introduction

The Army Medical Department (AMEDD) Professional Management Command (APMC) Workflow Management System (AWMS) was established as the centralized medical credentialing software suite for the United States Army Reserve (USAR) in 2006. The mission of AWMS is to support USAR commanders by ensuring the clinical force is appropriately credentialed in an efficient, cost effective manner. This facilitates the privileging for mobilization and training and enhances operational readiness of the USAR. AWMS suite of applications support APMC as a Management Information System for workload assignment, automated notifications, tracking productivity, evaluating performance metrics, and generating various management reports. Due to the uniqueness and the diverse population within the Medical Army Reserve footprint, AWMS provides key consolidated capabilities not supported elsewhere across the enterprise to facilitate the effective management, retention, tracking, and contact tracing of Army Reserve Medical providers. Credentialing is the process of establishing qualifications of licensed professionals and assessing their background and legitimacy to ensure patient safety. Privileging is the process of granting approval for licensed professionals to practice in their given field of medicine and is granted by Commanders of Military Treatment Facilities. This mission is codified in Army Regulation 40-68, Clinical Quality Management, 22 May 2009, and Defense Health Agency Procedures Manual 6025.13 vol. 4 dated 29 August 2019.

Upon award, the contractor will be required to develop the System Engineering Management Plan (SEMP) as a deliverable in accordance with the schedule outlined in the Statement of Work (SOW). As directed in the SOW, the Contractor will use the SEP as the basis for their plan. The SEP will be updated prior to any request for proposal during the contracting process or in the event of moving between milestones in the acquisition process.

AWMS is in the Operations and Support phase of its life-cycle. The objective of this phase is to provide enduring support for the capability established by AWMS. This includes active engagement in both functional and technical opportunities for continuous process improvement to maintain the relevance of the capability, the supporting technology, and the hosting solution.

2 Program Technical Definition

2.1 Requirements Development

A key part of the approach to this plan includes the AMEDD Professional Management Command (APMC) Workflow Management System Configuration Control Board (CCB) from which all requirements must originate. The CCB operates according to the CCB Charter and is the authority for approving work taken on by the IT Team. The CCB is responsible for prioritizing, approving, and validating work and receives input from the IT Team is support of performing their duties. This includes analyzing the technical approach, feasibility, and risks associated with performing the work and estimating the level of effort (LOE) to execute it. This also includes program protection, cybersecurity, cyber survivability, and operational resilience requirements defined in the requirements. The CCB and IT Team work together to schedule the work for inclusion in an up coming Sprint - a part of the SCRUM methodology.

Requirements Traceability

The individual applications and tools that make up the suite of APMC tools interoperate and support each other to achieve an overall outcome. A change made to one of these tools or applications has the potential to change the functionality of another. To track all the potential changes that can occur within each application or tool, Configuration Management practices are used to track changes to the individual Configuration Items (CI) that the IT Team modifies to address the functional changes approved by the Configuration Control Board (CCB). The application includes the following modules:

• AWMS

• ICTB requests

• CCQAS ETL

• My Credentials

• TAPDB-R HR Import ETL.

The categories of CIs within each application and tool includes

• Database Components

• Software code

• Data Processing rules

The individual CIs within each category include such items as:

• Stored Procedures

• DLLs

• Tables

For each release, requirements and the subsequent CI’s changed will be tracked in release notes.

2.2 Architectures and Interface Control

At the direction of the CCB, JCIDS architecture artifacts and any additional architecture views or diagrams, will be develop. These will be requested by the CCB should requirements changes deem them necessary. The current architection of AWMS is as follows:

AWMS currently has one interface with United States Army Reserve Command (USARC), G-1 (Personnel), Reserve Component Manpower System (RCMS) as depicted in the following diagram:

2.3 Design Considerations and Technical Certifications

System Security Engineering must be considered when undertaking any changes to AWMS.

The existing design and implementation of AWMS will undergo and annual threat assessment review that will include a vulnerability scan of the source code.

AWMS will be certified by the G6 for operation on the network on an annual basis.

3 Program Technical Management

3.1 Technical Planning

Technical Schedule The CCB meets monthly. As change requests are approved and prioritized the development team will establish a schedule based on Agile principles of repeatable sprints.

Maturity Assessment Planning As part of their planning, the CCB will consider the technology maturity of all critical technologies and manufacturing processes consistent with the USD(R&E) guidance for technology readiness and Manufacturing Readiness Level (MRL) assessments. They will instruct the development team to identify early cyber testing and artifacts that have been conducted or are planned, that provide the documentation of the technology and manufacturing process maturity.

3.2 Technical Tracking

Technical Risk, Issue, and Opportunity Management

Risk Management Risk will be recorded throughout the lifecycle of the program to help mitigate the potential of issue realization. During the CCB meetings the team will identify risks to the project’s objectives and scope and document them for assessment. The participants will then assess and prioritize risks for overall probability of occurrence and impact on the project. The team will then prioritize risks through associating a probability of occurrence percentage and provide mitigation strategies to prevent issue manifestation. For each risk, a mitigation recommendation will be included so provide the stakeholders with guidance on how to lower the chance of a risk becoming an issue.

All these activities will be documented in a project risk register which will be reviewed at every CCB meeting. The project team will then act through following recommendations or come up with alternative actions.

The Risk Register is a tool used in the Risk Management process. Risks can be identified by any project stakeholder. Once identified the risk, the CCB will enter it into the register and works with the project stakeholders to assess the potential impact the risk has on the project and mitigation and action plan strategies to either accept, reduce, or eliminate the impact(s).

Software Engineering

3.2.3.1 Software Engineering Overview

Software engineering will be provided to support the maintenance and minor enhancements required by the CCB. APMC will follow an Agile software development process that provides flexibility in prioritization and scheduling.

3.2.3.2 Software Planning and Execution

AWMS will follow an Agile software development methodology. Work will be identified and performed in sprints. The key goal of the approach is to maintain the satisfaction of the

Command as it pertains to meeting our mission. Change can be expected and an ability to adapt and deliver is paramount to our success. This includes the ability to deliver frequently and consistently in a short period of time.

Software planning and execution should be performed by conducting events in accordance with an agile methodology such as Scrum. Planning events should include the analysis of Change Requests approved and prioritized by the CCB and daily meetings should be conducted to identify and address risks and issues that need to be resolved to keep the work moving forward.

3.2.3.3 Development, Testing and Deployment Environments

The development and deployment configuration consists of a series of environments designed to evaluate the stability and completeness of the functionality prior to its delivery to the end user.

These environments are:

• Development

• Test/Stage

• Production

Development is where all requirements and agile tickets are initially developed. As developers complete a feature, it is unit tested and integration tested to ensure its stability per the ticket’s conditions of satisfaction, and its successful interaction with other components in the system. The software vendor deploys updates to the Development environment and tests them there. The development environment serves as the initial step in the process to ensure that new functionalities, bug fixes, or any other changes can be pushed to the production environment without issue.

The Test/Stage environment is used for functional and acceptance testing, ensuring that the application passes all documented test cases. The Test environment may interface with other application’s test environments to test system interfaces. It also serves as the staging location.

This is where APMC can do final acceptance testing of the application, and user training can also occur.

Production is the end-user environment and is where the application runs when it has ‘gone live’.

Deployments are scheduled regularly, at least once at the end of a defined delivery period (sprint), As the application is moved through each environment, a series of teams is involved in promoting the various components of the application, including the database, the application itself, and its dependencies and configurations.

3.2.3.4 Software Obsolescence

The obsolescence of software will be from a Diminishing Manufacturing Sources and Material Shortages (DMSMS) perspective. The CCB will plan the following:

• Functional changes resulting from hardware or software modifications (e.g., interfaces, deprecated data/functional constructs)

• Embedded COTS, GOTS, Military Off the Shelf

• Vendor end-of-life support (e.g., Windows XP, Windows Vista, Windows 7, Red Hat Enterprise Linux (prior to current 8.x))

• Infrastructure (e.g., software factory, digital twin)

• Changes resulting from published Information Assurance Vulnerability Alert (IAV-A) and Information Assurance Vulnerability Bulletin (IAV-B) security notices

• Configurable data items (e.g., anti-virus table updates, static configuration data tables, build scripts)

• The level of regression testing required at all levels (e.g., unit, CSC, CSCI, subsystem, system) to support continuous ATO impacts due to the changes in COTS, GOTS, or developmental software, including safety considerations and nuclear surety

Technology Insertion and Refresh The CCB will establish a cadence to identify technology insertion and refresh projects, approved or tentative including the following:

• Planning/execution status (e.g., nascent, total drawings 50% complete, and critical drawings 35% complete)

• Rationale (e.g., late-developing technology enables cost-effective achievement of user objective requirement(s), response to upgraded adversary capabilities, cost-effective improvement in R&M)

• Whether the project is covered in current acquisition program baseline; if not, state plan to fund project

• How DMSMS has been considered in the timing and scope of the project

• Any special provisions (that would not otherwise be included) in the present system design that enable/facilitate the project

• All identified risks related to technology insertion and refresh, including cyber risks to mission, with status of mitigation plans; embed or attach to the SEP

• The impact of the technology insertion and refresh on the ability to detect, respond, and recover from relevant cyber threats as may be elaborated in a Mission Based Cyber Risk Assessment (MBCRA).For emerging technology, which IPT(s) is (are) responsible for tracking and evaluation; include present maturity status

Configuration and Change Management All changes to AWMS must be processed and approved by the CCB.

All Change Requests (CR) are added to the Product Backlog and tracked from submission, approval/rejection, implementation by the IT Team, User Acceptance, Production Verification, and final acceptance by the CCB.

When Changes are submitted, the IT Team performs a Technical Review of the CR. During the Technical Review process, the IT Team may consult with the users to gather additional requirements or clarify question or concerns. Once the IT Team gains an understanding of the request they document an overview of the solution, determine an estimated level of effort (in days), assign a preliminary backlog priority, and a level of risk associated with the change.

Each month, the CCB meets to review the backlog of CRs. The CCB validates the priority of the CR and identifies the CRs that should be implemented. Approved CRs that have a completed

Technical Review are then scheduled by the IT Team and approved by the CCB for an upcoming sprint. Details concerning the CCB can be found in the CCB Charter.

Scheduling approved Changes begins with the IT Team conducting a Sprint planning session the output of which is a proposed list of changes and schedule for the upcoming sprint. Upon approval by the CCB, the IT Team begins implementation of the changes according to the sprint schedule. The lifecycle of a change request can be depicted as follows:

System Security Engineering AWMS will undergo an annual security threat assessment initiated and conducted by the G6 and the AWMS CCB and will included the following steps:

Step 1 – Initiation o Conduct Kick-off Meeting with App Owner o Request Documentation that you don’t already have.

o Follow-up e-mail to App Owner with anything you still need o Type up and provide meeting minutes for the Kick off meeting.

Step 2 – Documentation o Functional Architecture (one or multiple documents) o Hardware List (For STIG Purposes) Embedded in SSP Now o Applications/Services (For STIG Purposes) o Contingency Plan o System Security Plan (SSP) o Source code o Ports Protocols and Services o Service Level Agreement o DA 2930- PIA o CTO o Formal appointment letters o Threat Model o SOP o Developer List verified within last 90 days o If application is public facing:

o Webmaster declaration memo, o training verification, o OPSEC check (within last year)

Step 3 – HP Fortify o Scan Application Source Code with HP Fortify o Initial o Re-Evaluation Step 4 – ACAS/ SCAP Scan o Scan Application Assets with either ACAS or SCAP Tool o SCAP o ACAS

Step 5 – NIST SP 800-53 Controls o CM-1 Configuration Management Policy and Procedures § This control is intended to produce the policy and procedures that are required for the effective implementation of selected security controls and control enhancements in the configuration management family. The policy and procedures are consistent with applicable federal laws, Executive Orders, Directives, Policies, Regulations, Standards, and guidance.

§ Existing organizational policies and procedures may make the need for additional specific policies and procedures unnecessary. The configuration management policy can be included as part of the general information security policy for the organization. Configuration management procedures can be developed for the security program in general and for a particular information system, when required. The organizational risk management strategy is a key factor in the development of the configuration management policy.

o CM-2 Baseline Configuration

§ This control establishes a baseline configuration for the information system and its constituent components including communications and connectivity-related aspects of the system. The baseline configuration provides information about the components of an information system (the standard software load for a workstation, server, network component, or mobile device including operating system/installed applications with current version numbers and patch information), network topology, and the logical placement of the component within the system architecture. The baseline configuration is a documented, up-to-date specification to which the information system is built. Maintaining the baseline configuration involves creating new baselines as the information system changes over time.

The baseline configuration of the information system is consistent with the organization’s enterprise architecture.

o CM-3 Configuration Change Control § The organization determines the types of changes to the information system that are configuration controlled. Configuration change control for the information system involves the systematic proposal, justification, implementation, test/evaluation, review, and disposition of changes to the system, including upgrades and modifications. Configuration change control includes changes to components of the information system, changes to the configuration settings for information technology products (e.g., operating systems, applications, firewalls, and routers), emergency changes, and changes to remediate flaws. A typical organizational process for managing configuration changes to the information system includes, for example, a chartered Configuration Control Board that approves proposed changes to the system.

Auditing of changes refers to changes in activity before and after a change is made to the information system and the auditing activities required to implement the change.

o CM-4 Security Impact Analysis § Security impact analyses are conducted by organizational personnel with information security responsibilities, including for example, Information System Administrators, Information System Security Officers, Information System Security Managers and Information System Security Engineers. Individuals conducting security impact analyses have the appropriate skills and technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing information system documentation such as the security plan to understand how specific security controls are implemented within the system and how the changes might affect the controls. Security impact analysis may also include an assessment of risk to understand the impact of the changes and to determine if additional security controls are required. Security impact analysis is scaled in accordance with the security categorization of the information system. Related controls.

o CM-5 Access Restrictions for Change § The organization defines documents, approves and enforces physical and logical access restrictions associated with changes to the information system.

o CM-5(6) Access Restrictions for Change § The organization limits privileges to change software resident within software libraries (including privileged programs) o CM-6 Configuration Settings § Establishes and documents mandatory configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements.

§ Implements the configuration settings § Identifies documents and approves exceptions from the mandatory configuration settings for individual components within the information system based on explicit operational requirements.

§ Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.

o CM-8 Information System Component Inventory § Information deemed to be necessary by the organization to achieve effective property accountability can include hardware inventory specifications: manufacturer type, model, serial number, physical location, software license information, information system/component owner and for a networked component/device the machine name and network address.

o CM-9 Configuration Management Plan § Control: The organization develops documents and implements a configuration management plan for the information system that addresses roles, responsibilities and configuration management processes and procedures.

§ Defines the configuration items for the information system and when in the system development life cycle the configuration items are placed under configuration management and establishes the means for identifying configuration items throughout the system development life cycle and a process for managing the configuration of the configuration items.

o CP-2(4) Contingency Plan § The organization plans for the resumption of essential missions and business functions within organization-defined time period of contingency plan activation.

o CP-9 Information System Backup § Conducts backups of user-level information contained in the information system § Conducts backups of system-level information contained in the information system § Conducts backups of information system documentation including security-related documentation and protects the confidentiality and integrity of backup information at the storage location.

o CP-9(3) Information System Backup § The organization stores backup copies of the operating system and other critical information system software, as well as copies of the information system inventory (including hardware, software and firmware components) in a separate facility or in a fire-rated container that is not collocated with the operational system.

o SC-2 Application Partitioning § Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls.

o CM-7(3) Least Functionality § The organization ensures compliance with organization-defined registration requirements for ports, protocols, and services.

o PL-2(2) System Security Plan § The organization develops a functional architecture for the information system that identifies and maintains:

§ External interfaces, the information being exchanged across the interfaces and the protection mechanisms associated with each interface § User roles and the access privileges assigned to each role and unique security requirements.

§ Types of information processed, stored, or transmitted by the information system and any specific protection needs in accordance with applicable federal laws, Executive Orders, Directives, Policies, Regulations, Standards and Guidance.

§ Restoration priority of information or information system services o SA-4(3) Acquisitions § The organization requires software vendors/manufacturers to demonstrate that their software development processes employ state-of-the-practice software and security engineering methods, quality control processes and validation techniques to minimize flawed or malformed software.

o SA-10 Developer Configuration Management § Perform configuration management during information system design, development, implementation and operation § Manage and control changes to the information system § Implement only organization-approved changes

§ Document approved changes to the information system § Track security flaws and flaw resolution o SA-11(1) Developer Security Testing § The organization requires that information system developers/integrators employ code analysis tools to examine software for common flaws and document the results of the analysis.

o SC-13(1) Use of Cryptography § The organization employs, at a minimum, FIPS-validated cryptography to protect unclassified information.

o SC-28(1) Protection of Information at Rest § The organization employs cryptographic mechanisms to prevent unauthorized disclosure and modification of information at rest unless otherwise protected by alternative physical measures.

o SI-2 Flaw Remediation § Identifies, reports and corrects information system flaws.

§ Tests software updates related to flaw remediation for effectiveness and potential side effects on organizational information systems before installation.

§ Incorporates flaw remediation into the organizational configuration management process.

o SI-7 Software and Information Integrity § The information system detects unauthorized changes to software and information.

Step 6- STIG Checks

The following STIG checks must be performed on the application ð Application Security Development STIG ð Applicable Operating System STIG (Example: WIN7, WIN8, WIN10) ð Applicable application/service STIG (Example: IIS, SQL, .NET) ð Applicable Application Server STIG (Example: Server 2008 r2, Server 2012 r2)