2024.09.04 MilMove PWS - DRAFT.docx

DOCX document 7 MB Posted

Attached to
Request for Information: MilMove Development and Sustainment
Solicitation number
HTC711-RFI-1
Issued by

About this file

This document is a Performance Work Statement (PWS) for the MilMove software application. MilMove is the next generation application required for shipment and storage of both household goods and privately owned vehicles for Department of Defense (DOD) service members, dependents, and other customers supported by the Defense Personal Property Program.

The objective of this requirement is to provide software development support and expertise for MilMove, including all software code and associated components and integrations. The PWS includes five task areas: Task Order Management, Software Development Support, Implementing New Operational Capabilities, Monitoring and Production Application Support, and Risk Management Framework (RMF) Support. Key deliverables include software, release documentation, updated project documents, and RMF security documentation. The contractor shall use an Agile Scrum methodology and provide cybersecurity support, DISA STIG compliance, and port/protocol management. The period of performance is from October 2025 through September 2030.

View the file

Other files

File Type Posted
MilMove Technical Summaryv2.pdf PDF
20240920 TRANSCOM24D012 RFI Questions .pdf PDF
2024.09.20 MilMove PWS - DRAFT.docx DOCX document
2024.09.09 MilMove RFI.docx DOCX document
2024.09.09 MilMove RFI.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

MilMove

4 September 2024

UNCLASSIFIED

Version Number 1.0

UNCLASSIFIED

Table of Contents

1 Description of Services1
1.1 Background1
The MilMove deployment plan is subject to change. Capabilities in the TOPS application supporting tender based NTS shipments (and NTS-Retrograde FAR) will be phased into MilMove at a later time.1
1.2 Objective1
1.3 Scope2
1.4 References2
1.5 Performance Requirements2
1.5.1 Task Area 1: Task Order Management3
1.5.2 Task Area 2: Software Development Support5
1.5.3 Task Area 3: Implement New Operational Capability8
1.5.4 Task Area 4: Monitoring and Production Application Support9
1.5.5 Task Area 5: Risk Management Framework (RMF) Support15
1.6 Delivery Schedule23
1.6.1 Development Security Operations (DevSecOps)27
1.6.2 Warranty27
1.6.3 Unsupported Components27
1.6.4 Secure Software27
1.6.5 Inspection28
1.6.6 Flaw Remediation28
1.6.7 Final Acceptance28
2 Performance Standards28
3 Government Furnished Equipment (GFE), Government Provided Software (GPS), and Government Furnished Information (GFI)29
3.1 Use of Government-Furnished Computers.29
3.1.1 Privately Owned Computers30
3.1.2 Information Services30
3.1.3 Access to Government Services30
3.1.4 Official Business30
3.2 Government Furnished Information (GFI)31
3.3 Property Accountability31
4 General Information31
4.1 Place of Performance31
4.2 Account Management31
4.3 Section 508 Accessibility31
4.4 Travel and Other Direct Costs32
4.4.1 Travel32
4.4.2 Other Direct Costs Requirements33
4.5 Period of Performance33
4.6 Specialized Skills Required33
4.7 Velocity34
4.8 Latent Defects34
4.9 Identification of Security and Non-Disclosure Requirements34
4.10 Quality Assurance34
4.11 Standards34
5 Security35
5.1 Physical, Personnel, Information, Antiterrorism/Force Protection and Industrial35
5.2 USTRANSCOM Joint Security Office Points of Contact:35
5.3 Operations Security (OPSEC)35
5.4 Security Regulation Compliance35
5.5 USTRANSCOM – Cyberspace Workforce Management and Qualification35
5.5.1 DoD Cyberspace Workforce (DCWF) Management and Qualification35
Appendix A: List of Government Furnished Information37
Appendix B: Acronyms38
Appendix C: DoD Cyber Workforce Framework Code Assignments40

UNCLASSIFIED

UNCLASSIFIED

1. Description of Services Background The United States Transportation Command (USTRANSCOM) provides global air, land, and sea transportation for the Department of Defense (DoD), both in times of peace and war through its Transportation Component Commands (TCCs): Air Mobility Command (AMC); Surface Deployment and Distribution Command (SDDC); and Military Sealift Command (MSC). USTRANSCOM’s mission is to conduct globally integrated mobility operations, lead the broader Joint Deployment and Distribution Enterprise (JDDE), and provide enabling capabilities in order to project and sustain the Joint Force in support of national objectives.

The Defense Personal Property Program (DP3) is a Department of Defense (DoD) program administered by the Commander, USTRANSCOM in accordance with Department of Defense Instruction (DODI) 4500.57, Transportation and Traffic Management. The DP3 is responsible for executing household goods and privately owned vehicle shipping and storage programs for military service and U.S. Coast Guard members, Department of Defense (DoD) civilians, and their families. The DP3 serves as a centralized, integrated program designed to generate year-round quality capacity and ensure program accountability exists to meet DoD’s personnel relocation needs.

MilMove is the next generation application required for shipment and storage of both household goods (HHGs) and privately owned vehicles (POVs) for Department of Defense (DOD) services members, dependents, and other customers supported by the Defense Personal Property Program (DP3). MilMove will replace DPS Increment III and enables government oversight of the Global Household Goods contractor (GHC), the single move manager that is responsible for household goods shipments from start to finish. MilMove will provide customer onboarding, ordering, invoice creation, government oversight functions, and interfaces to support newly defined processes for customers moving under GHC, and later Global Privately-Owned Vehicles Contract (GPC), Non-Temporary Storage Contract (NTS-C) and other moves handled by FAR-based contracts under the DPMO.

The MilMove deployment plan is subject to change. Capabilities in the TOPS application supporting tender based NTS shipments (and NTS-Retrograde FAR) will be phased into MilMove at a later time.

Objective The objective of this requirement is to provide software development support and expertise for MilMove. This includes all software code and associated components and integrations. Software development support shall include any phase of the Software Development Lifecycle (SDLC), including concept development, planning, requirements elicitation and analysis, systems design and development, coding and testing, deployment, implementation, integration, troubleshooting, security posture, documentation, and software application maintenance. Responsibilities include managing the code baseline, the hosted environment, and system interfaces. The code baseline may change as a result of user preference, latent defects, change requests, security requirements, or updates to Commercial Off The Shelf (COTS) products used by the system. Additionally, the Contractor shall provide production support to include troubleshooting and resolving user problems as well as identifying opportunities to improve the system. Overall, software development support shall include all aspects of the SDLC necessary to sustain and modify the system baseline. The Contractor shall work closely with other members of the team to include Government Product Owners, engineers, security, and end-users.

Scope The Contractor shall provide solution consulting and programming to: (1) implement new system capabilities; (2) implement change requests; (3) sustain deployed capabilities by rapidly troubleshooting and repairing software issues (i.e. correct software defects); (4) provide technical expertise to ensure high availability of the application to meet the USTRANSCOM mission; (5) improve the system’s security posture; and (6) receive and respond to problems reported by system users Tier 2 helpdesk support.

Unless otherwise specified in this PWS, all days are designated as calendar days. The PWS includes the following task areas:

Task Area 1: Task Order Management Task Area 2: Software Development Support Task Area 3: Implement New Operational Capabilities Task Area 4: Monitoring and Production Application Support Task Area 5: RMF Support Task Area 6: Sustainment and Maintenance –Ticketing Tool (Service Now or equivalent) and Telephone Support

References All references can be found in Attachment 1_References.

Performance Requirements The Contractor shall use a Government owned Application Lifecycle Management (ALM) tool (e.g. Jira) to effectively manage and execute the Agile Scrum methodology to analyze requirements, decompose large requirements into logical sub artifacts, create user story level artifacts and technical specifications (i.e. Epics or large features must be decomposed into user stories), coordinate with the appropriate subject matter experts (both technical and functional) to receive approved acceptance criteria for Epic/Task/Subtask level artifacts, set Story Points and establish a waterline, develop and test software, create test scripts and implement User Acceptance Testing (UAT), and keep artifact statuses updated (artifacts are the method for identifying a change with software which will be deployed into Production). To maintain predicable velocity, the developers should complete the artifacts they commit to in each software sprint, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within the government provided ALM tool. The technical release documentation shall document all changes and procedures necessary to promote a release into production.

The Government will assign requirements to the Contractor for fulfillment in the Government provided ALM tool. Each assigned requirement will have one or more associated artifacts.

The software development increments are program increments that are divided into sprints and are defined by the Government. Program increments are planned as no longer than ten (10) weeks in length; and result in software releases. Program increments will consist of up to five (5) two (2) week sprints.

Task Area 1: Task Order Management

The Contractor shall provide the planning, direction, coordination, and control necessary to accomplish all requirements in this PWS. The Contractor shall designate key personnel responsible for the cost, schedule, and technical performance for the contract and shall serve as a primary Point of Contact for both management and technical matters. In addition, the Contractor shall participate in Program Management Reviews where the status of the work and associated deliverables are reviewed in the context of the business processes supported by the system.

Deliverables:

Task Order Management Plan (TOMP). The Contractor shall prepare a TOMP describing the technical approach, organizational resources, and management controls to be employed to meet requirements.

Product Roadmap. The Contractor shall maintain a product roadmap to plan out new system capabilities, functionality changes, system maintenance, and/or product upgrades. The product roadmap shall include current program increment+2 at a minimum. The Contractor shall collaborate with the Government Program Manager and Government Functional Lead to obtain the Government’s priority on software features and product updates.

Kick-Off Meeting (KOM) The Contractor shall attend a KOM with all partners to establish a baseline of understanding after the contract award or as directed by the Contracting Officer (KO) at a location to be determined by the COR within ten (10) business days of contract start. Participants will include Program Manager (PM), Government Technical Lead, Government Functional Lead, KO, COR, and other key Contractor personnel and Government staff. At the KOM, the Contractor shall present the details of its intended approach and approximated project schedule for review and approval by the COR. The KOM will serve to resolve strategic questions, refine goals, define success, and explore the biggest challenges and breakthrough opportunities for the Government, and identify any needed changes to the approach. This will be the beginning of a dialogue between the Government and the Contractor to ensure successful execution of this contract by the Contractor. The Contractor shall coordinate the agenda for the KOM and include, as a minimum, the following:

Introduction of management and technical teams Presentation of management plans and reports, technical issues, resolutions, and mitigation strategies Establishment of common understanding of the contract Other relevant items may be introduced at the discretion of the Government Deliverables:

KOM Agenda KOM Briefing Materials KOM Action Item Lists KOM Minutes Monthly Status Report (MSR) The Contractor shall provide a MSR that includes by task the financial, performance, system availability, and schedule status. The MSR will include proposed changes to the schedule as detailed in the management plan as well as property accountability, technical accomplishments, issues and risks, and planned activities for the next reporting period. Any issue requiring Government response or action shall be brought to the Government’s attention immediately upon identification, and status captured in monthly reports.

This report will contain the calls and artifacts received and the actions taken during the reporting period. It shall correlate actions taken to other tasks or solutions that address resolving the reason for the artifact. Since the artifacts are assigned via the Government ALM tool, and the Contractor will enter results into the Government ALM tool, metrics associated with the responsiveness, quantity, and duration of the artifacts will be extracted directly from the Government ALM tool. The status report shall include a cumulative tally of all artifacts assigned to the most recently completed release that have not been previously reported. This tally shall include the release identifier, total number of artifacts assigned to a release per category, the category (e.g. established within the ALM tool such as Requirement, Change Request (CR), Defect), and a total sum of total artifacts across all categories. Further, the report shall contain a sum of artifacts (per category and overall total) that were planned for each sprint (i.e. above the waterline after sprint planning using story points), as well as the sum of artifacts that are accepted in UAT (per category and overall total) and placed into production with the scheduled release. The bottom of the table shall include totals for each column. A notional example is provided below:

Table 1 – Notional Example

Waterline
Deployed
Release
CR
Defect
Requirement
Total
CR
Defect
Requirement
Total
10.3
17
4
9
30
17
5
7
29

10.3.1

10.4
22
9
4
35
22
9
4
35
Totals
39
16
13
68
39
17
11
67

Deliverable:

Monthly Status Report (MSR) Contract Manpower Report The contractor shall report in the System for Award Management (SAM): 1) the total dollar amount invoiced for services performed during the previous Government fiscal year under the contract; 2) the prime contractor direct labor hours expended on the services performed during the previous Government fiscal year; and 3) if applicable Tier I subcontract number, including DUNS number/Unique Entity Identifier (UEI) and name, and the number of subcontractor direct labor hours expended under the contract. Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September 30.

Deliverable:

Contract Manpower Report in SAM Contract Transition Prior to contract expiration, or in the event of a different Contractor winning a follow-on contract, the Contractor shall provide at a minimum all materials and support necessary to accomplish a seamless and expeditious transition of the tasks identified in this PWS to the incoming Contractor. The Contractor shall include electronic copies of the following: all in-progress working files, Concept of Operation (CONOPS) procedures, and final phase out meeting with Government, incumbent and the new Contractor. The Contractor shall support a formal contract closeout process, including the documenting of lessons learned throughout the life of the contract. All deliverables shall be provided forty-five (45) business days before the end of the contract period of performance.

Deliverables:

Transition Plan In-Progress Working Files Concept of Operations (CONOPS) Procedures Lessons Learned Task Area 2: Software Development Support This task includes responding to requirements that are generated by the Government through change requests, program, security, production support, or trouble reporting mechanisms. ALM artifacts are the method for identifying software changes, which will be deployed into the Production environment. The Contractor shall properly record user stories, associated acceptance criteria, issues, and software solutions to create a knowledge base within the Government’s ALM tool. The Contractor shall use the Agile Scrum Framework; along with extreme programming practices such as test-driven development, refactoring, and continuous integration; when completing artifacts to include: requirements elicitation and decomposition, completion of user stories and specifications, software development, security code scans, unit testing, integration testing, automated testing, and UAT. The Contractor shall use a microservices architecture for new code, and decouple monolithic legacy code when appropriate (e.g. failure isolation, multiple rates of change, simplify external dependencies, etc.) for long-term usability and scalability of the application. Additionally, the Contractor shall automate testing, security updates, configuration management, the software build process, etc. necessary to achieve Continuous Integration/Continuous Delivery (CI/CD).

Deliverables:

Software. The primary deliverable of this task is software code, system configurations, database schemas, etc. resulting from this task. All software code, system configurations, database schemas, etc. associated with this contract shall be the property of the Government and shall not contain any company proprietary markings, logos, or any distribution restrictions. Software code shall be installed on the Government’s Staging and Production servers and provided as a tagged code segment via the Government managed code repository and/or delivered on other mutually agreed upon format.

Release Documentation. As a minimum, this shall include a work plan with recurring updates, static code scans (e.g. Fortify scans), release test plan with results, UAT plan with test scripts and release notes which include all artifacts with associated descriptions and solutions, deployment instructions, and a list of DODAF artifacts that will be impacted / updated at the end of the PI.

Updated Project Documents. Documentation sufficient to install, operate, and maintain the system shall be provided and maintained. These documents shall include updates to the product roadmap, COTS products, training manuals, user manuals, system installation procedures, and any supporting documents necessary for the Government to sustain the system.

Updated System Documents, Security Documents, White Papers. All solution changes shall be documented as user stories, technical specifications and/or diagrams, interface control documents, system configuration documents, and/or Department of Defense Architecture Framework (DODAF) architectural artifacts. Additionally, documentation will be generated and maintained to support Static Code Analysis, the Risk Management Framework (RMF), Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), DODI 8530.01, and the DOD Cloud Computing Security Requirements Guide.

Agile Software Development Support The Contractor shall respond to ALM artifacts to change the system, as prioritized and assigned by the Government Product Owner. The Contractor shall participate in and/or lead the Scrum process and other meetings to define, build, test, document, and deploy updates to the system baseline. The Contractor shall ensure ample lead-time for understanding and responding to unique change requests. The planning for requested functionality may include the Contractor’s recommendations to minimize rework and cost. If a change is beyond the Contractor’s capacity to complete within one sprint, the Contractor shall decompose the Epic and/or Features into smaller user stories; and update the schedule (i.e. product roadmap). Complex tasks may require additional planning before coding. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The Contractor shall work with subject matter experts to create, and receive approval on, user stories and associated acceptance criteria, functional specifications and/or technical specifications. The Contractor shall support UAT for releases to ensure proposed changes are acceptable to users; and, when required, host release reviews for functional users to illustrate system changes. The Contractor shall assist with minor mod checklists (i.e. release notes); and shall provide necessary support to maintain and document the security posture of the application as required by the RMF or applicable DOD accreditation process.

Software Defect Support The Contractor shall immediately respond to escalated production support issues that cause work stoppage or operational problems with the system, and ensure the Production system operates without interruption to functional users. Software defects that result in a work stoppage or impact to business operations shall result in an unplanned software Hot Fix. Correcting defects identified through production support that do not result in a work stoppage shall be prioritized and assigned to current sprint or a future sprint by the Government depending on the impact to business operations. The Contractor shall assist the production support activity in identifying the root cause of production support malfunctions and creating ALM artifacts (i.e. software code changes) to permanently resolve or prevent them. The Contractor shall input all actions taken to resolve artifacts into the Government ALM tool. The Contractor shall coordinate with production support to ensure minimal rework and downtime during software changes, and to ensure the production support activity understands planned system changes.

Commercial of the Shelf (COTS) Support The Contractor shall provide support services for changes in COTS products to include patches (e.g. application, operating system, database), upgrades, and/or migration to newer technologies. This will involve analyzing the system for incompatibilities and deprecated features. Once prioritized by the Government, the Contractor shall refactor the necessary code to ensure continued system stability. The refactoring shall be assigned to sprint(s) and follow the Agile SDLC process for integration and testing of refactored code.

Deployment Pipeline Support MilMove is hosted in the Amazon Web Services (AWS) GovCloud. The Contractor shall provide the expertise required to operate and maintain the Development, Non-Production, and Production environments to reliably and efficiently compile, build, and deploy code. This shall include maintaining virtual machines and components, such as servers, memory, firewalls, load balancers, and storage (i.e. databases). Additionally, the Contractor shall maintain and update the Ports, Protocols, and Services (PPS) information. This shall include ports for internal and external traffic as well as the source and destination IP Addresses information. Air Force Department of Defense (AF-DOD) approved PPS worksheet will be used; available on the PPS Management at http://intelshare.intelink.gov/sites/ppsm.

DOD Security Requirements Guides (SRGs) and Security Technical Implementation Guides (STIGs) Compliance Support The contractor shall run the applicable Enclave T&D and ASD STIGs against their environments and deliver results NLT 60 days after the contract start date and NLT 60 days after each DISA STIG/SRG update is released.

The Contractor shall register with the DISA STIG library (https://cyber.mil/stigs/) upon contract award to receive notifications for updates to ensure the application and supporting application technology (i.e. operating system, database, servers, etc.) comply with the most up-to-date version of the DISA SRGs and STIGs. The Contractor shall evaluate each SRG/STIG item, determine applicability based on presence of technology/functionality, and annotate the checklist comment section for each item with statements of review status, applicability, and compliance/non-compliance. In the event of a non-compliant SRG/STIG check, the contractor will annotate open SRGs/STIG findings, along with fix or proposed mitigation actions, on a Plan of Action and Milestones (POA&M) for Government approval.

Task Area 3: Implement New Operational Capability The Contractor shall respond to ALM artifacts (i.e. new requirements) to implement new capabilities in the system (i.e. different than implementing change requests to existing capabilities). New capabilities will focus on creating new/additional system operational activities. This task shall include all Agile SDLC activities to support implementing new capabilities. The Contractor shall properly record user stories, associated acceptance criteria, issues, and software solutions to create a knowledge base within the Government’s ALM tool. The Contractor shall analyze end-to-end user experience and develop user interface concepts. The Contractor shall use the Scrum framework, extreme programming engineering practices, and a microservices architecture when completing artifacts to include: requirements elicitation and decomposition, completion of user stories and specifications, software development, unit testing, integration testing, automated testing, and UAT.

Deliverables:

Software. The primary deliverable of this task is software code, system configurations, database schemas, etc. resulting from this task. All software code, system configurations, database schemas, etc. associated with this contract shall be the property of the Government and shall not contain any company proprietary markings, logos, or any distribution restrictions. Software code shall be installed on the Government’s Staging and Production servers and provided as a tagged code segment via the Government managed code repository and/or delivered on other mutually agreed upon format.

Release Documentation. As a minimum, this shall include a work plan with recurring updates, static code scans (e.g. Fortify scans), release test plan with results, UAT plan with test scripts and release notes which include all artifacts with associated descriptions and solutions, deployment instructions, and a list of DODAF artifacts that will be impacted / updated at the end of the PI.

Updated Project Documents. Documentation sufficient to install, operate, and maintain the system shall be provided and maintained. These documents shall include updates to the product roadmap, COTS products, training manuals, user manuals, system installation procedures, and any supporting documents necessary for the Government to sustain the system.

Updated System Documents, Security Documents, White Papers. All solution changes shall be documented as user stories, technical specifications and/or diagrams, interface control documents, system configuration documents, and/or DODAF architectural artifacts. Additionally, documentation will be generated and maintained to support Static Code Analysis, the RMF, DISA STIGs, DODI 8530.01, DOD 8140, and the DOD Cloud Computing Security Requirements Guide.

Design and Plan The Contractor shall provide a project plan, and once directed by the Government employ the Scrum process to design the necessary capability. The Contractor shall provide SMEs or business analysts to facilitate feature design and planning. This design shall include all necessary artifacts, with appropriate sizing/complexity documented in the Government ALM, required for planning, development, and testing. The project plan shall include logical milestones (i.e. Epics/Features) for the deployment, which will result in a Minimal Viable Product (MVP), as well as additional functionality and/or enhancements.

Build and Deploy The Contractor shall employ the Scrum process and extreme programming engineering practices to define, build, test, document, and deploy updates to the system using a microservices architecture. This process agility shall support system change frequency for sprint cycle. Each new capability plan shall include checkpoints for milestones to include acceptance for design, build, test, and deploy. The Contractor shall maximize the use of automated testing scripts and tools to support rapid development of capabilities within the Agile development life cycle. Checkpoints are inherent in the Agile development process; however, it is extremely important that new capability software components be uniquely identified during the process. User stories (i.e. functional specifications) shall capture features to be deployed and will be used by the Government as a basis for testing and acceptance.

Static Application Security Testing (SAST) Support The Contractor shall run static code scans using a Government-approved code scan tool (e.g. Micro Focus Fortify) to mitigate potential of security vulnerabilities from being deployed into the production environment. Scans will utilize current scan engine and rule pack as determined by release candidate delivery date. If the software code has been redeveloped or refactored (changing the source code without modifying the external functional behavior), new scans must be provided to the Government by the Contractor.

Task Area 4: Monitoring and Production Application Support This task includes monitoring and troubleshooting production applications; and responding to incidents that are generated by system users. Production support tickets shall be generated within the Government ALM tool. Production support tickets are the method for tracking and resolving incidents (i.e. specific issues), as well as processing user account requests. Incidents may involve generating software defect artifacts (i.e. for systemic problems requiring code changes); which will be prioritized by the Government. The Contractor shall document incidents and systemic problems for accurate reporting, metrics, and to provide a knowledge base within the Government ALM tool. The Contractor shall be responsible for ensuring the description and resolution for incidents they resolve are documented clearly.

Deliverables:

· System Performance Report. This report shall contain all open tickets listed in order of priority starting with highest priority, and further sorted such that the earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket #, priority, associated tickets, descriptions, corrective action, date opened and closed with the user, as well as trend and other pertinent data. It shall correlate actions taken to other tasks or solutions that resolved similar tickets. If the Contractor has detected a trend, this report shall include a brief summary of the trend, associated tickets, pertinent distribution of causes, and recommended corrective action to prevent similar troubles. The Contractor shall use their expertise to recommend changes to software code, queries, data validations, etc. The Government will review these recommendations and provide guidance when appropriate. Since the production support tickets are managed via the Government ALM tool, metrics associated with responsiveness, quantity, and duration of tickets shall be extracted directly from the ALM tool and summarized in the report.

· Cyber Intrusion Incident Report. This report shall provide details identifying the root cause, impacts, and actions taken to resolve and prevent the vulnerabilities. The Initial Cyber Intrusion Incident Report is due within four (4) hours of the event. The Cyber Intrusion Incident Report Update is due within twenty-four (24) hours of the event.

Monitoring Support The Contractor shall monitor current health, performance statistics, recent errors, full logs, and key metrics. The Contractor shall ensure the system is working normally; and report and resolve any breaches, security attacks, or anomalies in activity. The Contractor shall use log collection, monitoring, and analysis to understand the relationship between network, infrastructure, servers, application framework, and user behavior to gain a comprehensive view across all activity, across all sources, servers, and locations.

Operationally Critical Support The services designated under this contract are “operationally critical support” as defined in DFARS 252.204-7012.

Cybersecurity Incident Reporting In addition to the DFARS 252.204-7012 reporting requirements for unclassified systems and DoD Manual (DoDM) 5220.22, National Industrial Security Program Operating Manual (NISPOM) for classified systems, reportable cyber-incidents include, but are not limited to, the following:

Cyber-incidents as defined in Table 2.

Notifications by a federal, state, or local law enforcement agency or cyber-center (i.e., National Cyber Investigative Joint Task Force (NCIJTF), National Cybersecurity & Communications Integration Center (NCCIC)) of being a victim of a successful or unsuccessful cyber-event, anomaly, incident, insider threat, breach, intrusion, or exfiltration.

Table 2 – Cyber-incidents

Incident Category
Description
Root Level Intrusion
Unauthorized privileged access to an IS. Privileged access, often referred to as administrative or root access, provides unrestricted access to the IS. This category includes unauthorized access to information or unauthorized access to account credentials that could be used to perform administrative functions (e.g., domain administrator). If the IS is compromised with malicious code that provides remote interactive control, it will be reported in this category.
User Level Intrusion
Unauthorized non-privileged access to an IS. Non-privileged access, often referred to as user level access, provides restricted access to the IS based on the privileges granted to the user. This includes unauthorized access to information or unauthorized access to account credentials that could be used to perform user functions such as accessing Web applications, Web portals, or other similar information resources. If the IS is compromised with malicious code that provides remote interactive control, it will be reported in this category.
Denial of Service
Denial of Service (Incident)—Activity that denies, degrades, or

disrupts normal functionality of an IS or DoD information network.

Malicious Logic
Installation of software designed and/or deployed by adversaries with malicious intentions for the purpose of gaining access to resources or information without the consent or knowledge of the user. This only includes malicious code that does not provide remote interactive control of the compromised IS. Malicious code that has allowed interactive access should be categorized as Root or User Level Intrusion incidents. Interactive active access may include automated tools that establish an open channel of communications to and/or from an IS.
Ransomware
Malware designed to encrypt files on a device, rendering any files and the systems that rely on them unusable. Malicious actors then demand ransom in exchange for decryption. Ransomware actors often target and threaten to sell or leak exfiltrated data or authentication information if the ransom is not paid. Ransomware is a reportable incident that may be associated with multiple incident categories depending on the attack vector and execution.

If the cyber-incident affects a classified system, vulnerabilities associated with the incident will be classified per the current version of USTRANSCOM Instruction 31-02, Security Classification Guide.

Cybersecurity Incident Reporting Timelines In addition to providing the notification required by DFARS 252.204-7012, the contractor is required to notify USTRANSCOM as soon as practical, but no later than 72 hours after discovering a reportable cyber-incident. The reporting timeline begins when the incident is discovered or reported to the company, its employees, contractors, or cybersecurity firm responsible for providing cybersecurity and response for the company. The contractor shall contact the USTRANSCOM Cyber Operations Center (CyOC) via phone at 618-817-4222. If the contractor does not immediately reach the CyOC via phone, the contractor shall send an email notification to transcom.scott.tcj6.mbx.cyoc-dodin-operations@mail.mil.

Mandatory Repoting Data The contractor shall work with the USTRANSCOM CyOC through resolution of the incident. Within 72 hours of becoming aware of a reportable cyber-incident, the contractor shall provide an initial notification of the incident, even if some details are not yet available, which includes, but is not limited to, the following information:

(a) Company Name

(b) Who will be the POC with contact information

(c) Contracting Officer POC (name, telephone, email)

(d) Overall Assessment –Description of incident, data at risk, mitigations applied

(e) Indicators of compromise

(f) Vector of attack (if known)

(g) Estimated time of attack (if known) The contractor shall provide a follow-on cyber-incident report to the USTRANSCOM CyOC within 5 days of becoming aware of a reportable cyber-incident, which includes, but is not limited to, the following information:

(a) Contractor unique Commercial and Government Entity (CAGE) code

(b) Contract numbers affected

(c) Facility CAGE code where the incident occurred if different than the prime Contractor location

(d) POC if different than the POC recorded in the System for Award Management (name, address, position, telephone, email)

(e) Contracting Officer POC (name, telephone, email)

(f) Contract clearance level

(g) DoD programs, platforms, systems, or information involved

(h) Location(s) of compromise

(i) Date incident discovered

(j) Type of compromise (e.g., unauthorized access, inadvertent release, other)

(k) Description of technical information compromised

(l) Any additional information relevant to the information compromise Incident Reporting Coordination In the event of a cyber-incident, USTRANSCOM may conduct an on-site review of network or information systems where DoD information is resident on or transiting to assist the contractor in evaluating the extent of the incident and to share information in an effort to minimize the impact to both parties. Date and time of on-site visits will be mutually agreed upon by USTRANSCOM and the contractor in advance.

The contractor agrees to allow follow-on actions by the Government (e.g., USTRANSCOM, Federal Bureau of Investigation, Department of Homeland Security, DC3, etc.) to further characterize and evaluate the suspect activity. The contractor acknowledges that damage assessments might be necessary to ascertain an incident methodology and identify systems compromised as a result of the incident. Once an incident is identified, the contractor agrees to take all reasonable and appropriate steps to preserve any and all evidence, information, data, logs, electronic files and similar type information (reference NIST Special Publication 800-61, Computer Security Incident Handling Guide, (current version)) related to the incident for subsequent forensic analysis so that an accurate and complete damage assessment can be accomplished by the Government.

The contractor is not required to maintain an organic forensic capability, but must ensure data is preserved (e.g., remove an affected system, while still powered on, from the network) and all actions documented until forensic analysis can be performed by the Government or, if the Government is unable to conduct the forensic analysis, a mutually agreed upon third party (e.g., Federally Funded Research and Development Center (FFRDC), commercial security contractor, etc.). Any follow-on actions shall be coordinated with the contractor via the Contracting Officer.

The contractor agrees to indemnify and hold the government harmless for following any recommendations to remedy or mitigate the cyber-incident following the actions under 1.5.1. and 1.5.2.

Confidentiality and Non-Attribution Statement The Government may use and disclose reported information as authorized by law and will only provide attribution information on a need-to-know basis to authorized persons for cybersecurity and related purposes (e.g., in support of forensic analysis, incident response, compromise or damage assessments, law enforcement, counterintelligence, threat reporting, and trend analysis). The Government may share threat information with other USTRANSCOM industry partners without attributing or identifying the affected contractor.

Production Support The Contractor shall respond to and resolve operational problems with the system. This task includes responding to incidents, analyzing and correcting specific incidents, creating software development artifacts for systemic problems requiring code changes, and following escalated tickets to resolution. Typical incidents to be resolved under this task include database updates for specific records with incorrect data, which involves determining the cause of the issue, correcting the database, and determining whether a permanent code fix is necessary.

Production Support Analysis The Contractor shall analyze problems and solutions to detect and report trends and “worst actor” features and/or processes. These recommendations shall consider the simplest solutions first. For example, a trend in user errors for entering data might be solved by adding help text or changing data validations. On the other hand, recurring errors may require changes to functionality or the database. The Contractor’s expertise must be sufficient to support such analysis and to provide concise, actionable recommendations. For complex recommendations, the Contractor may have to collaborate with the Government or other Contractor personnel to create change specifications. Support analysis may also result in recommending changes to system documentation or training material.

Cybersecurity Analysis The Contractor shall monitor and analyze Information Assurance Vulnerability Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Computer Emergency Readiness Team (US-CERT), and vendor security advisories. The Contractor shall determine system impact, identify mitigating factors, and provide recommendations to the Government regarding potential courses of action. The Contractor’s recommendations shall be compliant with DOD security requirements and industry best security practices. The Contractor shall ensure that cybersecurity remediation, patch deployments, and other significant security activities are considered in the Product Roadmap.

Cybersecurity Service Provider (CSSP) Support The Contractor shall provide Host Based Security System (HBSS) and Assured Compliance Assessment Solution (ACAS) scans weekly; and shall participate in one (1) Continuity of Operations (COOP) exercise (i.e. Intrusion Assessment or Incident Response) annually.

Interoperability Certification Support The Contractor shall ensure MilMove maintains interoperability certification by the Joint Interoperability Test Command (JITC) in accordance with Chairman Joint Chiefs of Staff (CJCS) Instruction 5123.01H. All documentation delivered also must meet recommendations and guidelines defined in DOD Instruction 8330.01. The Contractor shall comply with the most current version of each reference. The Contractor shall review and provide inputs (if applicable) to the MilMove DODAF artifacts provided by the USTRANSCOM enterprise architecture team and review the Enhanced Information Support Plan (e-ISP).

DOD Architectural Framework (DODAF) Support The Contractor shall create and update DoD Architectural Framework (DoDAF) architecture views that align to the current version of the Business Enterprise Architecture (BEA) for software design that affects the architecture using Microsoft Office Visio for graphical artifacts (e.g. SV-1, OV-6, etc.) or other appropriate application for tabular or prose-based artifacts (e.g. SV-6 or AV-1). The Contractor shall create and populate Data Information Viewpoint and Service Viewpoint with views based on all other software design documentation delivered. At a minimum, the Contractor shall maintain and provide updated SV-4, SV-5a, DIV-2 (Logical Data Model), SV-1, SV-6, SV-7, OV-5, and OV-6 following each PI as part of PI Planning for the next increment.

Task Area 5: Risk Management Framework (RMF) Support The contractor shall develop, configure, and/or operate information system components and/or information systems securely in accordance with the current versions of DOD policy, National Institute of Standards and Technology (NIST) Special Publications (SPs), National Security Agency (NSA) publications, Committee on National Security Systems (CNSS) issuances, and United States Cyber Command (USCYBERCOM) tasking orders, and requirements; support improving cyber resiliency for the information system and reducing vulnerability to the DODIN. Support continuous monitoring and the integration of security and risk management framework (RMF) activities into the systems development lifecycle (SDLC). (Section is customized by the requirements of the contract. For example, a system is already operational and contract support would be responsible for applying patches, running vulnerability scans, etc.) Specific contractual requirements are set forth below.

Authorization and Assessment (A&A) Support The contractor shall create, edit, update, and maintain information system security assessment and authorization (A&A) documentation/evidence of control compliance for all applicable security control families necessary to achieve an authorization decision (authorization to operate/connect [ATO/ATC] or interim authorization to test [IATT]) and/or support continued authorization in accordance with (IAW) the current version of DOD Instruction (DODI) 8500.01, Cybersecurity, DODI 8510.01, NIST Special Publication 800-37, Risk Management Framework (RMF) for DoD Information Technology (IT), Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6510.01F, Information Assurance (IA) and Support to Computer Network Defense (CND), Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B, Cyber Incident Handling Program, Committee on National Security Systems Instruction (CNSSI) 1253, Security Categorization and Control Selection for National Security Systems, NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, and NIST SP 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans. In addition, the contractor shall support and update existing system security documentation within the Enterprise Mission Assurance Support Service (eMASS) or other government selected tool in accordance with timelines and frequencies specified by the government to facilitate/maintain security authorization in accordance with DOD RMF and USTRANSCOM RMF authorization requirements. (Customizable based upon the system requirements. The PM(s) will need to identify the requirements within the PWS required to bring the system into full RMF package. This will include timelines as required by the PM[s].)

The contractor shall support requirements submitting systems for authorization decisions (ATO/ATC/IATT) within the timelines identified in the USTRANSCOM Chief Information Officer (CIO) memorandum, Risk Management Framework (RMF) Guidance. The contractor will produce evidence/artifacts that validate security control requirements established within NIST SP 800-53, IAW USTRANSCOM published standards and guidance by utilizing the current USTRANSCOM RMF grading rubric. Evidence/artifacts meeting assessment standards of NIST SP 800-53a will be utilized to support an authorization decision according to the normal processing times and the authorization need date. The contractor shall identify sources of evidence/artifacts for the A&A package to the Government. Deliverable. The RFP/PWS can address failure to meet quality standards but recommend the quality threshold be 95% of the evidence meeting this standard be added to the Service Delivery Summary.)

The contractor shall support Interim Authorization to Test (IATT) activities for system testing on the operational network or when using live data (data that has not been sanitized to remove operational information) by providing the following documentation: An updated architectural diagram (showing test configuration), proposed ports, protocols, and services (PPS) declaration worksheet, and a comprehensive test plan that describes the test environment, projected specific testing events and schedules, and expected outcomes for remediating existing or future vulnerability.

The contractor shall provide A&A metrics for the following types of packages: Packages in progress, returned as incomplete/incorrect, in delay due to unavailable resources (staffing, expertise, equipment, software, or access), completed, and projected authorization activities related to IATTs, conditional ATOs (cATOs), ATCs, and minor modifications. The method of delivery and frequency will be determined by the Government (e.g., spreadsheet, briefing, inclusion in the monthly status report, etc.).

The contractor shall have an ongoing responsibility for writing and/or updating supporting evidence/artifacts required by the applicable security controls for all deliverables, as identified in control guidance in eMASS, NIST SP 800-53 series documents, and/or CNSSI 1253. The contractor shall demonstrate requirements compliance, outline non-compliance and mitigations, and justify non-applicable controls to support information system/enterprise continuous monitoring efforts and the USTRANSCOM Digital Modernization Strategy. Deliverable.

The contractor shall ensure security control evidence/artifacts clearly support compliance or describe non-compliance with the security control within eMASS. Non-compliance will state the raw severity of the risk, mitigations (in place and/or planned), and a recommendation for residual risk to the government. Evidence/artifacts will be specific to the security control and will have annotation within the artifact to call attention to the topic. Evidence/artifacts will be delivered to the government according to the government-specified authorization/reauthorization timeline within eMASS or other government-selected tool. (PMs will determine a realistic timeline within the PWS that reflects the authorization or reauthorization.)

The contractor shall provide evidence for applicable security controls, as identified in the current version of NIST 800-53A and NIST SP 800-30, Guide for Conducting Risk Assessments, or as specified in applicable DOD, CNSS, and USTRANSCOM guidance to demonstrate compliance with the requirements of the Defense Information…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .