Attachment_6_-AMP_TO_0001_PWS.pdf

PERFORMANCE WORK STATEMENT

FOR

TASK ORDER (TO) 0001

ANALYSIS OF MOBILITY PLATFORM (AMP)

22 March 2013

1.0 DESCRIPTION OF SERVICES

1.1 Background.

The Analysis of Mobility Platform (AMP) is a transportation modeling and simulation framework used to obtain an end-to-end simulation of the Defense Transportation System (DTS). The primary AMP users include programmatic analysts at the United States Transportation Command (USTRANSCOM), Joint Staff J4 and J8, Office of the Secretary of Defense (OSD) Cost Assessment and Program Evaluation (CAPE), Military Surface Deployment and Distribution Command’s Transportation Engineering Agency (SDDCTEA), and the United States Army’s Center for Army Analysis (CAA). The Joint Distribution Process Analysis Center (JDPAC) is the functional manager for

AMP.

The AMP-Port Analysis Tools (AMP-PAT) is an analysis and decision support tool to assist Combatant Command planners, Joint Staff, OSD, CAA, and USTRANSCOM analysts in refining transportation enabler requirements during Time-Phased Force and Deployment Data (TPFDD) development processes and to provide throughput analysis for airports and seaports. AMP-PAT is used to support throughput analysis in a stand-alone mode or runs dynamically as an AMP federate. AMP-PAT includes the following six tools:

Airport Rapid Analysis Tool (ARAT) Airport Throughput Tool (ATT) Airport Simulation Tool (AST) Seaport Rapid Analysis Tool (SRAT) Seaport Throughput Tool (STT) Seaport Simulation Tool (SST)

1.2 Scope. This Performance Work Statement (PWS) contains requirements in support of AMP development for FY14 in the following areas: Optimization, Programmatic Analysis, Operational Applications, Seaport and Airport Analysis, Rapid Course-of-Action (COA) Development and Assessment, and Enterprise Integration. In addition, this PWS contains requirements for sustainment of AMP throughout FY14.

1.3 General Tasks. Task areas with associated subtasks to be performed are identified as: Contract Management, Technical Support for Studies and Analyses, Requirements Management, Support for Design and Development, Software Maintenance, Application Administration, Security Engineering and Cyber Security Requirements, Contingency Operations, Configuration Management, Enhancements, and New Capability.

1.3.1 Task Area 1 – Contract Management. (T-Ops) This task area shall encompass overall contract management to include administrative, clerical, documentation, and related functions during the period of performance of this task order.

The contractor shall provide a contract management function that tracks the performance of the work. Point of Contact (POC) information for the person(s) performing the contract management function shall be designated in writing to the Contracting Officer (CO) with a copy to the Contracting Officer’s Representative (COR) no later than the date of the Post-Award Conference. POC information shall include name, title, phone number, and e-mail address. The contractor shall ensure all personnel assigned to this contract meet the minimum requirements specified in the contractor’s proposal, in accordance with (IAW) the generic resumes provided as part of the contractor’s staffing approach. The contractor shall notify the CO in writing of changes to key personnel within three (3) business days after information is known. The contractor shall report ALL contractor labor hours

(including subcontractor labor hours) required for performance of services provided under this contract for th eAir Force via a secure data collection site. The contractor is required to completely fill in all required data fields using the following web address: http://www.ecmra.mil/. 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. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year, beginning with 2013. Contractors may direct questions to the help desk at: http://www.ecmra.mill

1.3.1.1 Task Area 1 Subtask 1 - Task Order Management Plan (TOMP). Reserved.

1.3.1.2 Task Area 1 Subtask 2 - Monthly Status Reports (MSR). (T-Ops) The contractor shall submit an MSR summarizing overall status, progress, and recommendations and shall include details and results of the work performed during the reporting period, identifying any issues, problem areas, and items that require Government action; work planned for the next month; change request and problem report evaluations, as necessary; dates and locations of in-process reviews (IPR) conducted; hours performed on each Contract Line Item Number (CLIN) by labor category; actual and projected expenditures; meetings attended, with a summary of relevant items discussed;

cost, schedule and/or performance variance that includes a description of how the variances were determined; risk assessment and mitigation recommendations; open issues; a list of deliverables provided; and key personnel (e.g., project manager, lead developer, lead engineer) changes. Estimated and actual travel costs shall be reported, together with contractor name, trip location and purpose, and dates of travel. The MSR shall include copies of invoices for all travel performed during the reporting period.

Deliverable: MSR

1.3.1.3 Task Area 1 Subtask 3 - In-Process Reviews (IPRs). (T-Ops) The contractor shall conduct and/or host IPRs on a twice-yearly basis. The Program Manager (PM) will determine dates and whether IPRs will be held at the contractor’s site, at USTRANSCOM, via video teleconference, web-cast, or conference call. IPRs shall summarize status, progress, new capability requirements and program schedule to include new requirements, risk identification, and proposed remediation plan in any task area. The contractor shall provide a draft agenda to the PM in accordance with the schedule in the deliverable table in Paragraph 4. The contractor shall prepare presentation materials and provide them to the PM in accordance with the schedule in the deliverable table in Paragraph 1.4. Following the IPR, and in accordance with the schedule in the deliverable table in Paragraph 1.4, the contractor shall submit minutes of the IPR to include date, IPR location, a list of attendees, a record of activity; decisions made; and an action items list that includes a description of the action item (AI), the primary person or organization responsible for accomplishing the AI, and an estimated completion date.

Deliverables: Agenda, Presentation Materials, IPR Meeting Minutes

1.3.1.4 Task Area 1 Subtask 4 - Integrated Master Schedule (IMS). (T-Ops) The contractor shall develop and deliver to the PM an IMS in Microsoft Project format that provides a schedule for all major milestones as currently tasked to the contractor. It also shall include anticipated future work to support schedule and workload de-confliction. The IMS shall include a Master Schedule that lists the major milestones and completion dates associated with each. The IMS shall also include sub-tasks necessary to achieve the milestone and scheduled completion dates for each sub-task. The IMS delivered to the government shall address development, test, and deployment for software releases containing approved new capability, enhancements, or problem reports, and shall show the critical path. The contractor shall keep this schedule current, making schedule changes as necessary after coordinating these changes with the PM. The IMS shall be delivered with the MSR, or when circumstances necessitate a change to the schedule, whichever occurs first.

Deliverable: IMS

1.3.1.5 Task Area 1 Subtask 5 - Demonstration Support. (T-Ops) The contractor shall conduct up to five demonstrations of software releases of any type at AMP IPRs, AMP User Group Meetings, or other venues. The contractor shall conduct technical presentations or demonstrations to USTRANSCOM, other Department of Defense

(DOD) commands, or other AMP users. The contractor shall support presentations or demonstrations at other venues when required by the PM.

1.3.1.6 Task Area 1 Subtask 6 – Teleconferences. (T-Ops) The contractor shall participate in weekly telephone conferences lasting 30 to 60 minutes to provide current status of all tasks.

1.3.2 Task Area 2 - Technical Support for Studies and Analyses. (T-Ops) The contractor shall support planning and execution of one major analytical study such as the Defense Program Guidance’s Mobility Capabilities and Requirements Studies and Quadrennial Defense Review, and up to four smaller studies that may spin off from the major study. This may require software modifications, analysis of study requirements and products, and on-site support. As appropriate to the specific study, the contractor shall work with other model development contractors to define upgrades and enhancements to software of AMP and the other models, and coordinate release and testing schedules. The contractor shall modify AMP software and shall enhance the graphical user interfaces (GUI) and/or charts as directed by the PM. The contractor shall conduct integration and testing, and perform trouble-shooting to repair or modify software problems identified during model execution.

1.3.3 Task Area 3 - Requirements Management. The contractor shall be responsible for facilitation and support of the administration of the AMP requirements management process.

1.3.3.1. (Optional Task) (T-Ops) When available, the contractor shall utilize the Government’s Requirement Management Tool (RMT) to input, track, trace, and manage requirements and supporting documentation. The Government’s RMTs may be composed of, for example, IBM’s Rational RequisitePro, ClearQuest, and ClearCase.

The Government shall provide the contractor access to these tools and the contractor employees shall be proficient in the use of these tools. The Government will not provide IBM Rational RequisitePro, ClearQuest, and ClearCase training to the contractor. The Government will maintain and use these tools to monitor the requirements management process.

1.3.3.2. (T-Ops) The contractor shall document its internal requirements management process in a Requirements Management Plan (RMP), and use tools that can transition to the Government’s RMTs to input, track, trace, and manage requirements and supporting documentation. The content of the RMP shall be in accordance with the RMP template provided as Government-furnished information (GFI).

Deliverable: RMP

1.3.3.3. (Optional Task) (T-Ops) The contractor shall have thirty (30) business days to transition to the Government-sponsored environment when the Government-provided tools become available. The end state will have all open and historical baselines and requirements loaded into the RMTs. The contractor shall load the current baseline and any open requirements within the first 30-business day transition period. The contractor shall have one hundred and twenty (120) business days to transition all historical baselines and requirements into the RMTs.

1.3.3.4. (T-Ops) Using an automated tracking tool, the contractor shall maintain the traceability of all requirements from capabilities needs through design and test; document all changes to those requirements and record the rationale for those changes throughout the system lifecycle. Requirements traceability will be confirmed at each technical review (e.g., IPRs, test readiness reviews (TRR), operational readiness reviews (ORR), production readiness reviews (PRR), Requirements Definition Document (RDD) reviews).

The contractor shall assess each requirement and provide an impact assessment that includes an analysis of level of effort and impacts to program costs and program schedule. The contractor shall record these assessments in its requirements management tool.

1.3.4 Task Area 4 – Support for Design and Development. (T-CAP) The contractor shall have responsibility to support design and development as designated in the subtasks below. Design and development of new capability within AMP also encompasses software integration and at least three tests considered a part of the development process: unit, regression, and integration testing.

1.3.4.1 Task Area 4 Subtask 1 – General Support. The contractor shall:

(a) Propose release content and schedules based upon Government requirements and priorities

(b) Provide necessary models and simulations to support the verification, validation, and authentication

(VV&A) process

(c) Provide software size (executable lines of code and function points), cost, and schedule estimates, and include justification and methodology used to derive the estimates

The contractor shall ensure that the AMP software is developed to be compatible with the current and any projected USTRANSCOM software configurations (e.g., United States Air Force (USAF) Standard Desktop Configuration (SDC), network, security, Internet browser). The Government will furnish the contractor with the approved USTRANSCOM software configurations.

1.3.4.1.1 Task Area 4 Subtask 2 – Software Requirements Specification (SRS). The contractor shall provide an SRS that describes the user’s functional requirements in detail and in a form that will support design and development of software to satisfy functional and technical requirements. The SRS shall conform to the requirements of Contract Data Requirements List (CDRL) A001 (Data Item (DI)-IPSC-81433A, Software Requirements Specification). The USTRANSCOM Program Management Office (PMO) will review and approve the SRS prior to contractor implementation.

1.3.4.2 Task Area 4 Subtask 3 – Software Testing. The contractor shall support Government participation in test events. These events include Government Witness Testing (GWT) and User Acceptance Testing (UAT) of the software to ensure it is validated and verified against the provided requirements or problem reports. The purpose of GWT is to observe contractor systems integration testing (SIT) of the software planned for use during UAT. During UAT, the contractor shall record and track deficiencies discovered by functional users participating in UAT and by contractor personnel, but shall not issue a new version of software for continuation of UAT without PM approval.

In accordance with PM and Functional Manager (FM) prioritization and PM direction, the contractor shall resolve these deficiencies and present another software version for either GWT or UAT.

1.3.4.2.1. Software releases are categorized into major, minor, maintenance, or emergency releases. Releases are classified as “major” if they include change(s) in the system architecture (e.g., introduction or elimination of a database, transition from client-based application to web-based access) or security posture. Major releases also include new functionality, and also may contain fixes to software problem reports. Releases are classified as “minor” if they include new functionality, but no changes to the system architecture or security posture. Minor releases also may contain fixes to software problem reports. Maintenance releases contain only fixes to software problem reports. Emergency releases normally contain only fixes to software problem reports, but may include new capability rushed to the field to support a high-priority requirement. For each major, minor, or maintenance release, the contractor shall prepare a Software Test Description (STD) that describes the developer’s test methodology and traces requirements from contractual and/or requirements documentation through to test cases. The STD shall conform to the requirements of CDRL A002 (DI-IPSC-81439A/T (tailored), Software Test Description.) The contractor shall create test cases for each requirement that shall provide detailed test instructions, any pre-conditions or inputs, and expected results for each required functional capability or defect. This STD also shall describe the contractor’s approach to conduct regression testing on changes made to commercial off-the-shelf components and application software components. In addition, the contractor shall provide documentation that records the status and results of the contractor’s test efforts. The STD, test cases, and test reports shall be delivered in accordance with the deliverable table in Paragraph 1.4. The contractor shall conduct a Test Readiness Review (TRR) before contractor systems integration testing commences and an Operational Readiness Review (ORR) before UAT commences. The goals of these reviews are to confirm the readiness of the application and test infrastructure (e.g., test environment and documentation) to start each test event, to identify the proper exit criteria necessary to complete each test event, and obtain Government approval to proceed toward the next milestone leading ultimately to software fielding. The contractor shall prepare briefing slides for each TRR and ORR and provide them for Government review before either TRR or ORR occurs. Timing of delivery of the TRR and ORR slides for Government review is as noted in the Deliverable Table in Paragraph 1.4. The contractor shall deliver a Software Test Report (STR) that details test results following completion of GWT and SIT. The contractor shall submit one report that consolidates results of both test events. This report shall conform to the requirements of CDRL A003 (DI-IPSC-81440A/T STR, Software Test Report).

1.3.4.2.2 The TRR shall at a minimum, address the following topics, issues, and events:

(a) Test methodology to verify contents of the release

(b) Software Problem Reports (SPR) contained in the release

(c) Review of all formal test documentation (requirements traceability matrix (RTM), test cases, test plans)

(d) Verification of the availability of all necessary personnel, forms, equipment, software, and support material, and/or data for the test to be performed

(e) Review that all new requirements are mapped to test cases

(f) Confirm that each SPR has a test case developed against it, or provision of reason why one has not been developed

(g) Verification that test procedures have been reviewed and recommendations incorporated into the appropriate documentation

(h) Results of regression testing

1.3.4.2.3. To support the ORR, the developer shall produce the test artifacts along with a description of any open Software Test Report/Software Problem Report (STR/SPR) for review by the PMO and functional representatives.

The successful outcome of this review should result in Government PM approval to proceed to UAT. The developer shall deliver all artifacts to the PMO and place them under CM control including a draft Software Version Description (SVD).

1.3.4.2.4. Once the software is delivered to the Government for UAT, the contractor shall not implement changes to the software baseline under test until the Government has completed (or postponed) testing, prioritized software or test problem reports, and has accepted the change(s) proposed to resolve the problem(s). The contractor shall identify and track deficiencies discovered during UAT, but shall not issue a new version of software for continuation of UAT without PM approval. In accordance with PM and FM prioritization and PM direction, the contractor shall resolve these deficiencies and present another software version for either GWT or UAT. After completion of UAT, the Government will conduct a Production Readiness Review (PRR), with developer participation, that demonstrates readiness of the application and infrastructure to support fielding to the production environment, and to issue a fielding decision.

1.3.4.2.5. If the contractor uses automated test scripts to verify software problem fixes for a software version entering a scheduled test event involving Government participation, the contractor shall provide a user-readable version of the automated test script(s) and expected test result(s) for each test case; these shall be included in the Software Test Cases deliverable. The contractor shall provide the results of automated testing of the software build to be used at the start of scheduled test events, and any builds occurring during scheduled test events. The contractor shall include these automated test result(s) as an addendum to the STR.

1.3.4.2.6. The contractor shall meet all government specifications for each requirement at each release. The PM will make the final decision concerning software acceptance. Deficiencies will be documented, prioritized, tracked, and may result in non-acceptance of the software release by the Government. The software shall be resubmitted for testing and only accepted by the Government once it passes government testing. In this contract, deficiencies are defined as the difference between the functional specifications stated by the Government and the capability provided in the software being delivered to the Government. This definition includes capability previously delivered to the Government that was not a part of the new functional specifications or code changed due to fixing problems with the software that the Government Configuration Control Board (CCB) authorized.

1.3.4.3 Task Area 4 Subtask 4 – AMP Software Releases. The contractor shall provide up to two (2) minor releases, up to three (3) scheduled maintenance releases, and up to six (6) emergency releases annually; emergency releases will occur between regularly scheduled releases. The following pertains:

Each release must undergo Information Assurance (IA) review to determine the degree to which the changes incorporated into the software impact the security or hardware architectures of the system, or include the implementation of a new operating system, database, or interface. This review is accomplished by submitting update requests through the Cyberspace Infrastructure Planning System (CIPS). The contractor shall assist the Government in achieving software acceptance through the USTRANSCOM security CIPS process by accomplishing tasks described in Paragraph 1.3.7. Successful completion of this process will result when the USTRANSCOM Information Assurance Manager grants his/her approval of the updated product version within CIPS.

Version numbering shall be consistent with the description contained in the Government Configuration Management Plan (CMP).

The contractor shall provide the following items:

Source code Executable programs

Source code shall be delivered in conformance with the requirements of CDRL A004 (DI-IPSC-81488/T, Computer Software Product (CSP)).

The contractor shall update the Software User Manual (SUM) to provide USTRANSCOM functional personnel appropriate guidance for system operation. The SUM shall conform to the requirements of CDRL A005 (DI-IPSC- 81443A/T, Software User Manual).

The contractor shall follow the software release process addressed in the Government AMP CMP. The contractor also shall deliver software source code with each release. Using the processes described in the CMP, the Government CCB will determine the contents of each software release after consideration of the developer’s recommended release contents and the functional user’s priorities.

The contractor shall deliver an SVD in accordance with the deliverable table in Paragraph 1.4. The SVD shall conform to the requirements of CDRL A006 (DI-IPSC-81442A, Software Version Description). The contractor shall submit an updated SVD whenever the Government CCB approves changes to the software baseline. The contractor shall not undertake work on requirements (new capability (functionality) or software maintenance) that have not been approved by the Government until the Government CCB has approved the requirements.

Deliverables: SRS, Software Test Descriptions, STRs, TRR slides, ORR slides, SVDs, Software releases, Updates to Software User Manual, source code

1.3.5 Task Area 5– Software Maintenance

1.3.5.1 AMP Software Maintenance (includes AMP-Port Analysis Tools (PAT), Joint Mobility Closure Estimator (JMCE), Distribution Performance Nodal Model, Nodal Management). (T-Ops) The contractor shall correct problems that AMP users encounter with the software, and shall conduct unit, integration, and regression testing of these fixes. The contractor shall maintain the data objects, run-time infrastructure, and adapt to changes in the AMP component models to ensure federated runs are operational. As software problems are corrected, the contractor shall adhere to the test and release requirements contained in Paragraphs 1.3.4.1 and 1.3.4.2 above.

The contractor shall:

(a) Facilitate and support the administration of the AMP problem reports management process

(b) Code, test, document, and support full integration of software and software releases

(c) Propose release content and schedules based upon software maintenance priorities directed by the

AMP Configuration Control Board (CCB)

(d) Provide software level of effort, cost, and schedule estimates, and include justification and methodology used to derive the estimates

(e) Provide configuration management (CM), quality assurance (QA), and documentation for all AMP software

1.3.5.2 AMP Agile Transportation for the 21st Century (AT21) and Rapid Course-of-Action Analysis Tool (RCAT) Software Maintenance. (T-Ops – AT21) The contractor shall correct problems that AMP AT21 and RCAT users encounter with the software, and shall conduct unit, integration, and regression testing of these fixes.

The contractor shall:

(a) Facilitate and support the administration of the management process for problem reports submitted by AMP AT21 and RCAT users

(b) Code, test, document, and support full integration of software and software releases

(c) Propose release content and schedules based upon software maintenance priorities directed by the

AMP Configuration Control Board (CCB)

(d) Provide software level of effort, cost, and schedule estimates, and include and methodology used to derive the estimates

(e) Provide configuration management (CM), quality assurance (QA), and documentation for all AMP software

1.3.6 Task Area 6 – Application Administration. (T-Ops) The contractor shall provide on-site application administration and support to USTRANSCOM system administrators and functional users. This includes the following activities:

(a) Plan, schedule and support installation of AMP software, to include application patches and updates.

Troubleshoot AMP installation problems. Support Functional Area Communications Computer System Manager installation of AMP application software on Secure Internet Protocol Router Network (SIPRNET) clients, as necessary

(b) Support optimization, backup, recovery, modification, and upgrade of software. Debug AMP software and support testing of the application (e.g., USTRANSCOM Test Lab, support of GWT and UAT)

(c) Provide technical support for hardware refresh efforts

(d) Provide Help Desk support to assist functional users troubleshoot and correct AMP problems

(e) Keep information located on the AMP webshare site current, including keeping the web pages updated with the latest downloadable AMP software releases, sample data, and AMP User Group materials

(f) Assist Government security and networking personnel to resolve application-related issues

The contractor shall keep the AMP Application Administration Manual updated. The contents of the manual shall include account administration; software installation; obtaining, generating, and updating reference files, shared drives, and web pages; troubleshooting and resolving operating system conflicts, maintaining logs, and creating reports, as required.

Deliverable: Updated Application Administration Manual

1.3.6.1 Task Area 6, Subtask 1 – AMP Model User Training. (T-Ops) The contractor shall provide up to ten sessions of AMP training. Training shall be on the use of the AMP modeling tools. USTRANSCOM will coordinate and provide the training classroom (including hardware) if such training is required. Training shall be consistent with industry standards and result in the trainees’ full understanding of the capabilities and the designed use of the associated software applications and GUIs.

1.3.6.2 Task Area 6, Subtask 2 – Update AMP Training Materials. (T-Ops) The contractor shall update the self-paced training materials as new AMP capability is delivered to the Government. The purpose of the training materials is to provide a new analyst an overview of the AMP software with the objective of enabling this analyst to perform the following functions using the software following completion of this training. The training materials shall include, but not be limited to, at least one training scenario and practical exercises.

a. Understand major concepts of airlift, sealift, Continental United States (CONUS), theater, and sustainment and how they work within the model

b. Understand how to open, import, export, and run an AMP scenario

c. Understand basic navigation of the tool; i.e., where editors are located, how the basic GUI functions work (i.e., copy, paste, filter, etc), and what data is located within each editor

d. Understand what reports are available and where they are located

e. Be able to complete practical exercises provided

Deliverable: Updated self-paced training materials

1.3.7 Task 7 – Security Engineering and Cyber Security Requirements

1.3.7.1 Task 7 Subtask 1 – Security Engineering Requirements.

The contractor shall evaluate all AMP releases to ensure security issues are identified and addressed using the Defense Information Systems Agency (DISA) Application Security and Development Checklist and Security Technical Implementation Guide (STIG). The contractor shall conduct code reviews and apply required security features for all AMP software releases.

1.3.7.1.1 (T-Ops) The contractor shall monitor and analyze IA Vulnerability Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Cyber Command (USCYBERCOM) and vendor security advisories and make recommendation to the Government for applicability to AMP.

1.3.7.1.1.1 (T-Ops) The contractor shall prepare an initial analysis and assessment for high impact (risk) advisories (based on the STIG Finding Severity Category listed in the IA Vulnerability Advisories [IAVA] and IA Vulnerability Bulletins [IAVB]) and submit them to the PM and USTRANSCOM AMP Engineer. All STIG Finding Severity Category I and II IAVAs and IAVBs are considered high impact.

Deliverable: High Impact Risk Advisory

1.3.7.1.1.2 (T-Ops) The contractor shall prepare an analysis for other than high impact advisories and provide it to the USTRANSCOM AMP Engineer.

Deliverable: Other-than-High Impact Risk Advisory

1.3.7.1.1.3 (T-Ops) The contractor shall provide a summary of security analysis and assessment results during weekly teleconferences and in an update in the MSR.

Deliverable: Security Summary

1.3.7.1.2 (T-Ops) The contractor shall analyze applicable security bulletins to determine impact, identify mitigating factors, and develop recommendations to the Government regarding potential courses of action. Contractor recommendations shall be compliant with AMP, USTRANSCOM, and DOD security requirements. The contractor shall ensure that patch deployments and other significant security activities are documented in the IMS.

1.3.7.1.3 Application Design, Information System Security Engineering Principles. (T-Ops) The contractor shall ensure that information system security engineering is employed during all changes to the application software.

As part of the contractor’s change control process, the contractor shall ensure participation by an Information System Security Engineer or an IA representative qualified as an Information Assurance Technical (IAT) Level I, IAW DOD 8570.01-M, Information Assurance Workforce Improvement Program, to evaluate the impact of each change on security. The contractor shall document the results of this evaluation in the contractor’s requirements management tool.

1.3.7.1.4 Software Assurance and Security Engineering Practices. (T-Ops) In coordination with the Government, the contractor shall design, develop and implement secure applications and configurations using the DISA Application Security and Development Checklist and STIG. The contractor shall describe how it plans to complete the DISA Application Security and Development Checklist and STIG, and to employ the automated code scan tool (reference Paragraph 1.3.7.1.4.1 below). The contractor also shall adhere to vendor security guidance, industry best practices, such as those discussed in the documents located at http://www.safecode.org/publications/SAFECode_BestPractices0208.pdf and https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/ISC2_WPIV.pdf; and applicable vendor product security patches. The contractor shall ensure applications comply with the DISA Application Security and Development Checklist and STIG; DOD Instruction (DODI) 8500.2, Information Assurance Implementation; and DODI 8551.1, Ports, Protocols, and Services Management (PPSM) (current version). For all software releases, the contractor shall conduct software security testing in accordance with the DISA Application Security and Development Checklist and STIG and, for major releases and reaccreditations, submit the completed checklist to the Government in accordance with Paragraph 1.4, Deliverables. As validation of continued compliance with the STIG, the developer shall submit application code scan reports for each software release as indicated in the deliverables table.

The contractor’s Information System Security Engineer shall participate in Government and contractor formal and informal design reviews to identify potential security weaknesses, deficiencies, and/or vulnerabilities in the design.

The Information System Security Engineer also shall ensure appropriate security requirements are included as part of the requirements traceability matrix. As part of the contractor’s change control process, the contractor shall ensure participation by the Information System Security Engineer or an IA representative qualified IAW DOD 8570.01-M, Information Assurance Workforce Improvement Program, to evaluate the impact of each change on security.

Deliverable: Implementation Plan for the DISA Application Security and Development Checklist and STIG and Code Scanning Tool, Completed DISA Application Security and Development Checklist and STIG

1.3.7.1.4.1 Use of Automated Code Scanning Tool. (T-Ops) The contractor shall use an automated tool to scan the application source code to identify and remediate vulnerabilities or weaknesses in the application design/coding, such as those described in CWE/SANS TOP 25 Most Dangerous Programming Errors (http://www.sans.org/top25-programming-errors) and OWASP Top Ten (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), that could be exploited by unauthorized sources. The contractor shall ensure the operator of this tool is trained on its operation. This training shall be at no cost to the Government. The contractor shall submit reports containing the results of the application code scans.

Deliverables: Application code scan reports

1.3.7.1.5 Non-Secure Software. If the Government determines, after a security audit (e.g., security test and evaluation (ST&E)), that software delivered under this contract is non-secure, the Government will provide written notice to the contractor of each non-conformity. Software will be “non-secure” under this contract if it contains a programming error listed on the current approved version of the CWE/SANS TOP 25 or a web application security flaw listed on the current approved version of the OWASP Top Ten. Such notice constitutes revocation of acceptance of delivered software. The contractor shall have twenty (20) business days after receipt of such notice (Remedy Period) to remedy each non-conformity by modifying/replacing and redelivering the software to the Government. If the Government determines, after a security audit following a Remedy Period, that the redelivered software is non-secure, and thus non-conforming, the Government may reject the delivery, provide notice of the non-conformance, and document the contractor’s performance record. Alternatively, the Government may accept non-conforming software, receive appropriate consideration (equitable price reduction on a fixed price contract, reimbursement for costs of security audit, reimbursement for costs to correct the non-compliances, etc.), and document the contractor’s performance record.

1.3.7.1.6 Source Code Configuration Control (Versioning). The contractor will use a strict version control process for software development.

1.3.7.2 Task 7 Subtask 2 – Cyber Security Requirements.

1.3.7.2.1 Requirements for Contractor Provision of Security Plan and IA Controls. (T-Ops) The contractor shall establish an IA Program to implement and sustain appropriate IA management, operational, and technical controls and processes required to safeguard DOD non-public information resident on or transiting the contractor's unclassified information systems from unauthorized access and disclosure. Protection measures applied must be commensurate with the risks (i.e. consequences and their probability) of loss, misuse, unauthorized access, or modification of information. The contractor shall submit for Government approval an overarching security plan that describes its strategy for implementation of IA and Industrial Security requirements throughout the life of the contract. The security plan shall address the security controls described in National Institute of Standards and Technology (NIST) Special Publication 800-53(current version), Recommended Security Controls for Federal Information Systems and Organizations, 1 May 2010 (http://csrc.mist.gov/publications/PubsSPs.html), and shall be tailored in scope and depth appropriate to the effort, the specific unclassified DOD information resident on or transiting the contractor's unclassified information systems, and approved by the Government.

1.3.7.2.2 Developer Environment. (T-Ops) The contractor development environment shall be physically and logically isolated from other networks, to include its enterprise unclassified network. Security guidelines for the environment must be documented and the security program implemented shall address the security controls described in NIST Special Publication 800-53 (current version), Recommended Security Controls for Federal Information Systems and Organizations (http://csrc.mist.gov/publications/PubsSPs.html).

1.3.7.2.3 Remote Access. (T-Ops) Contractor Furnished Equipment (CFE) employed for remote access to a Government network shall meet equivalent Government Furnished Equipment (GFE) IA computing requirements.

The contractor shall ensure that all CFE (hardware and software) employed to access these environments meet the following minimum Government IA requirements and provide periodic certification of compliance as a pre-requisite to being granted network access.

(a) Use of personal systems is prohibited;

(b) Operating systems (OS) and applications shall be configured for compliance with applicable STIGs;

(c) DOD approved anti-virus and anti-spyware software shall be installed and signatures must be configured to automatically update on a daily basis;

(d) DOD approved personal firewall shall be utilized and configured to permit traffic by exception only, dropping all other traffic. If the personal firewall provides intrusion detection or prevention; the signatures or rules shall be updated at the same intervals as the anti-virus software;

(e) Computers must be IAVM compliant;

(f) Computers shall be scanned with the DOD version of E-eye Retina vulnerability scanner (or current approved DOD scanner solution) at a minimum of every twenty (20) business days. All vulnerabilities shall be remediated and reported to the AMP Information Assurance Manager (IAM).

(g) Contractor employees shall possess a current Government issued Common Access Card (CAC) and install Government certified CAC readers; and

(h) Verification of compliance with these requirements shall be provided to an appointed Government representative on a monthly basis.

1.3.7.2.4 Information Assurance Training. (T-Ops) The contractor’s employees physically assigned to USTRANSCOM / Transportation Component Commands (TCC) at Scott AFB (SAFB) shall attend/complete security training as prescribed by DOD and USTRANSCOM/TCC instructions. At a minimum, this includes Employee Initial Security Training, Annual Security Awareness Training, Operations Security (OPSEC), DOD Antiterrorism Level 1 Training, Personally Identifiable Information (PII) Training and Security Stand-Down Day Training scheduled by the Commander of the organization to which the employee is assigned. Contract employees assigned elsewhere shall attend security training established by their respective government security offices and/or installations. The contractor shall deliver to the Government documentation verifying completion of required contractor security training.

Deliverable: Contractor Security Training Completion Documentation

1.3.7.2.5 Information Assurance Workforce Improvement Program (IAWIP). (T-Ops) The contractor shall:

(a) Ensure that personnel performing information assurance functions have the proper and current information assurance certification (IAT Level I) to perform information assurance functions in accordance with DOD 8570.01-M, IAWIP. The contractor shall meet the applicable information assurance certification requirements, including:

1) DOD-approved information assurance workforce certifications appropriate IAT Level I, as listed in DOD 8570.01-M; and

2) Appropriate operating system certification for information assurance technical positions as required by DOD 8570.01-M

(b) Upon request by the Government, the contractor shall provide documentation supporting the information assurance certification status of personnel performing information assurance functions.

(c) Contractor personnel who do not have proper and current certifications shall be denied access to DOD information systems for the purpose of performing information assurance functions.

The contractor shall deliver to the Government documentation verifying IAWIP certification.

Deliverable: IAWIP Certification Documentation

1.3.7.2.6 Support of Computer Network Defense Service Provider (CNDSP) / Host-Based Security System (HBSS). (T-Ops) The contractor shall comply with all applicable subscriber-related CNDSP / HBSS requirements as stipulated under subscriber responsibilities in the CNDSP Memorandum of Agreement between USTRANSCOM and the Army Research Laboratory (CNDSP), 17 April 2012.

1.3.8 Task Area 8 – Support for Annual AMP Contingency Plan Review. (T-Ops) Each year the PMO engineer selects certain scenarios from the AMP Contingency Plan for review. The contractor shall participate in this annual review and shall modify portions of the program contingency plan applicable to the application administrator’s role as the Government representatives deem necessary.

1.3.9 Task Area 9: Configuration Management (CM).

CM support is required to meet USTRANSCOM technical and security requirements. The CM process facilitates orderly configuration identification, change identification and control, status reporting and configuration auditing of product information for such beneficial purposes as to revise capability; improve performance, reliability, or maintainability; extend life; reduce cost; reduce risk and liability; or reduce defects. CM ensures that changes take place in an identifiable and controlled process and do not adversely affect the properties of the other system or interfaces.

CM establishes and maintains the integrity of the products of a project throughout the project life cycle. CM involves identifying the configuration items of products developed and delivered to the customer, systematically controlling changes to the configuration, and maintaining configuration traceability. The contractor’s configuration management processes must complement the Government CM processes.

1.3.9.1 Task 9 Subtask 1: Configuration Manager Responsibilities. (T‐Ops)

The contractor’s Configuration Manager shall create the contractor’s CMP and ensure the contractor’s CMP and processes are consistent with the Government CMP and processes. The contractor’s Configuration Manager shall establish and maintain the following:

Plan organization

Methods, procedures, and controls

Baselines (versioning)

Configuration identification

Change control

Configuration status accounting

CM audits of total configuration to include hardware, software, and firmware

CM Repository

CM Process

Deliverable: CMP

1.3.9.2 Task 9 Subtask 2: Configuration Identification. (T-Ops)

The contractor shall provide configuration identification as specified in its CMP. This identification shall include hardware configuration items and software configuration items. All configuration items must be uniquely identifiable by use of a configuration item number and nomenclature. The contractor shall deliver a computer software configuration item (CSCI) listing.

Deliverable: CSCI Listing

1.3.9.3 Task 9 Subtask 3: Change Control. (T-Ops)

The contractor shall provide change control for all AMP baselines and configuration items to include documentation, hardware, commercial off-the-shelf (COTS) software, application, source, and executable code. The contractor shall employ its change control process to identify, track, and release all changes and problems identified with the program. The contractor initially shall use its change control process and will transition to the PMO’s requirements management tool (Rational ClearQuest) to identify, track, and release all changes and problems identified with the program when directed by the Government. The Government will provide web access to ClearQuest for the contractor’s help desk and support personnel. The contractor shall provide all source code deliveries to the Government provided tool (Rational ClearCase), when directed by the Government. The Government will provide the web access to the contractor’s CM team for this purpose.

1.3.9.4 Task 9 Subtask 4: Evaluating Requested Changes. (T-Ops)

The contractor shall evaluate all change requests. Evaluations include requirement clarification and analysis, including an estimate of the level of effort to implement the requested change, determination if the requirement is obligatory or optional, determination if the requirement is feasible, and the consequences of the proposed change, such as ability to adhere to standards and any impacts on training. The contractor shall provide this information to the Government via the automated requirements management tool. The contractor initially shall use its change control process supported by tools it currently uses. The contractor shall transition its current change control database to the Government’s requirements management tool when the latter is implemented. Upon the implementation of the change control tool (CCT) databases, the contractor shall have thirty (30) business days to transition to the Government-provided CCT.

1.3.9.5 Task 9 Subtask 5: Asset Management. (T-Ops)

The contractor shall provide and maintain an asset management system to track all AMP hardware and software, warranties, maintenance support agreements, software licensing, and accountability for significant hardware purchases or upgrades. The contractor shall identify all existing infrastructure assets, hardware, and COTS software that are not Internet Protocol version 6 (IPv6) capable. The contractor shall provide status of baselines, configuration items, and all outstanding enhancements and defects. The contractor shall deliver the information requirements of this paragraph to the Government in the form of a Status Accounting Report according to the schedule in Paragraph 1.4.

Deliverable: Status Accounting Reports

1.3.9.6 Task 9 Subtask 6: Configuration Working Group (CWG). (T-Ops)

The contractor’s Configuration Manager will participate in CWGs. The CWG is formed under the authority of the CCB and meets when directed by the Government. The Government estimates CWGs will be held approximately every two weeks during the period of performance. Meetings will last no more than one hour, and should require minimum preparation time (an average of one hour per meeting). CWG reviews will include contractor change request evaluations, unresolved help desk tickets, proposed releases, data quality issues, engineering change proposals, and requests for deviations. The CWG determines the validity of all items and issues and prepares each item for CCB presentation if required.

1.3.9.7 Task 9 Subtask 7: Configuration Management Audits. (T-Ops)

The contractor shall conduct physical and functional configuration audits of each code baseline or release delivered to the Government. The Government reserves the right to participate in the audits. The contractor shall notify the Government of its intent to conduct a physical or functional configuration audit no later than 30 calendar days prior to the conduct of each of these audits.

1.3.10 Task Area 10 – Enhancements. Reserved.

1.3.11 Task Area 11 – New Capability. (T-CAP) For purposes of this PWS, new capability consists of capability that currently does not exist in the software. As directed by the PM via the Configuration Control Board process described in the government CMP, the contractor shall provide software that will include new capability in AMP.

The contractor shall design; develop; conduct unit, integration, and regression testing; and fully integrate all new capabilities, enhancements, and software fixes with current software; and, as specified by requirement, provide requisite documentation for each new capability. The contractor shall provide the following new software capability to the existing AMP application.