HC102817R0047_AMD02.pdf

HC102817R0047

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print)

30-105-04EXCEPTION TO SF 30

APPROVED BY OIRM 11-84

STANDARD FORM 30 (Rev. 10-83) Prescribed by GSA

FAR (48 CFR) 53.243

a. The purpose of this amendment is to respond to additional contractor questions.

b. A revised Performance Work Statement is being provided.

c. Attachment J-4 is incorporated to answ er additional questions.

d. The point of contact for this modification is michael.h.jacobs1.civ@mail.mil

1. CONTRACT ID CODE PAGE OF PAGES

J 1 69

16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

16C. DATE SIGNED

BY 25-May-2017

16B. UNITED STATES OF AMERICA15C. DATE SIGNED15B. CONTRACTOR/OFFEROR

(Signature of Contracting Officer)(Signature of person authorized to sign)

8. NAME AND ADDRESS OF CONTRACTOR (No., Street, County, State and Zip Code) X HC102817R0047

X 9B. DATED (SEE ITEM 11)

11-Apr-2017

10B. DATED (SEE ITEM 13)

9A. AMENDMENT OF SOLICITATION NO.

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offer is extended, X is not extended.

Offer must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended by one of the following methods:

(a) By completing Items 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted;

or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN

REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE

CONTRACT ORDER NO. IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(B).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

10A. MOD. OF CONTRACT/ORDER NO.

2. AMENDMENT/MODIFICATION NO. 5. PROJECT NO.(If applicable)

6. ISSUED BY

3. EFFECTIVE DATE

25-May-2017

CODE

DISA/DITCO-SCOTT-PL83

2300 EAST DRIVE

SCOTT AFB IL 62225-5406

HC1028 7. ADMINISTERED BY (If other than item 6)

4. REQUISITION/PURCHASE REQ. NO.

CODE

See Item 6

FACILITY CODECODE

EMAIL:TEL:

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been added by full text:

REVISED PWS AMD02

PERFORMANCE WORK STATEMENT (PWS)

as of May 8, 2017

Contract Number: To be determined Task Order (TO) Number: To be determined Tracking Number: HC1028-17-R-0047 Follow-on to Previous Contract and TO Number:

HC1028-15-F-0282

1 Contracting Officer’s Representative (COR)

a. Primary COR.

Name:

Organization:

Department of Defense Activity Address Code (DODAAC):

Address:

Phone Number:

Fax Number:

E-Mail Address:

b. Alternate COR.

c. Alternate COR

2 Contract or TO Title

Department of Defense (DoD) Public Key Infrastructure (PKI) and Common Service Provider (CSP) Engineering and Technical Support

3 Background The Net Centric Assurance capabilities includes the Department of Defense (DoD) PKI as the mechanism for providing Public Key (PK) certificates that support mission critical DoD applications. PKI satisfies the DoD’s Information Assurance (IA) requirement for confidentiality and authentication of network transactions, identification and verification of data integrity, and non-repudiation of communications or transactions. Since 1998, the PKI program has evolved into an operational program consolidated under a single Program Management Office (PMO), which oversees the DoD-wide effort to identify and PK enable applications to take advantage of the PKI security services by providing guidance and a capability for interoperability testing.

As PKI capabilities have expanded and become more ubiquitous, requirements for its security benefits and systems enhancements have increased in order to better meet the reliability and availability requirements of the DoD community. As a result, there is now an increased demand for high assurance operation of the DoD PKI systems, requiring the infrastructure to be modernized and secured against evolving threats.

4 Objectives To specify the system engineering and technical support necessary to strengthen the security postures and technical capability for the DoD PKI.

5 Scope The scope of this TO requires support in the form of subject matter experts responsible for reviewing system engineering documentation and developing software to support PKI. This TO will be executed in accordance with the current DoD X.509 Certificate Policy and the appropriate DoD approved architectures, program standards and guidelines such as Defense Information Infrastructure (DII), Defense Information Systems Network (DISN), and Global Information Grid (GIG). The scope of this effort includes the following areas:

Task Area 1 - Task Management and Support Task Area 2 - Combination of Token Management System (TMS) and Common Service

Provider (CSP) Task Area 3 - Develop issuance interface for SIPR REL DMZ delegated identity

Task Area 4 - Dogtag Certificate System development (FFP) Task Area 5 - Dogtag Certificate System New Development activities Task Area 6 - Dogtag Certificate System New Development activities (CPFF)

The contractor shall identify, track and maintain a list of software defects that were discovered by the contractor or the Government. The defects are expected to fall into two categories:

security vulnerabilities and operational issues. The contractor shall identify if an IAVA, CVE, or government reported security vulnerability impacts an existing system within 24 hours of notification, with all reasonable efforts to complete a patch that corrects the security vulnerability within 5 business days. The contractor shall complete operational issue patches within 10 business days. The Government will prioritize the operational issue patches to be completed.

Patches for security vulnerabilities have priority over patches for operational issues. The Government anticipates that there could be as many as three vulnerabilities or patches to be completed each month. The contractor shall record all open and completed software defects and document the results in the IPR Report.

The contractor shall use industry best practices to create source code comments in a format extractible by Doxygen to develop Applicate Programmable Interface (API) documents, user manuals, and security evaluation documents as required by the development schedule. For example, different types of comments may be related to method invocation, TODO activities marked in the source tree, and specific cryptographic operations, constants, or configurations.

The contractor shall implement new capabilities through development activities for the following categories – 1) developing new support for other data source providers, 2) developing new support for smartcards that conform to the current Global Platform version at task execution, 3) implementing support for new cryptographic algorithms or PKI standards, 4) developing new support for emerging web technologies, and 5) new development to support future server operating systems, such as RHEL 8, that the CS product would need to migrate to.It is expected that there will be a total of 1 enhancement per quarter from any of the above categories.

The contractor shall develop a suite of regression test cases or procedures for the existing and updated software baseline and deliver a ZIP file within 10 days of the start of testing, containing the source tree of generated tests. The tests shall include code unit tests (i.e. Junit) and functional tests (i.e. JMeter) for library and application interfaces. The contractor shall execute the regression test cases, record the results, and deliver the results within 15 days after the completion of the testing.

Deliverables:

IPR Report (Monthly, PPT Slides or PDF document) API documents (After each major enhancement, Doxygen generated document) User Manuals (After each major enhancement, Doxygen generated document) Security Evaluation documents (After each major enhancement, Doxygen generated document) Regression Test Cases/Procedures (within 10 days after the start of testing, ZIP file containing all source tree files) Regression Test Report (15 days after completion of testing, MS Word)

Task Area 7 - Support Security enhancements Task Area 8 - Review and patch the Red Hat Certificate System source code for defects

Task Area 9 - Notification of issuance events to users Task Area 10 - Research and Deploy an Alternate Certificate Management products Task Area 11 - Mobile Device Derived Credential Issuance Support Task Area 12 - Procure Hardware and Software Task Area 13 - Error! Reference source not found.

Task Area 14 - Development Lab Support Task Area 15 - Web Based Bulk Revoker (WBBR) Reengineering (Optional) Task Area 16 - PKE Engineering Support (Optional) Task Area 17 - PKE Engineering Policy and Guidance Development and Review –

Technical and Strategic (Optional) Task Area 18 - Transition Task (Optional) Task Area 19 - Supply Chain Risk Management (SCRM)

6 Performance Requirements

6.1 Task Management and Support (FFP)

6.1.1 Task Management Control and Planning (FFP)

The contractor shall hold monthly In-Process Reviews (IPRs). The contractor shall conduct each IPR with a coordinated agenda, briefing materials, document minutes of the IPRs and provide information regarding TO status, e.g., work progress, price and/or cost of travel/materials, schedule data, projected tasks with completion status and areas of concern. IPRs shall provide for interchanges between the Government and the contractor. The IPRs shall provide a forum to address technical and programmatic topics of the TO.

The contractor shall develop a single initial Integrated Master Schedule (IMS) to include each exercised task area that contains all of the technical and functional activities required to complete the tasking and deliver the IMS within 30 days of contract award.

The contractor shall update the IMS monthly to include updated tasking, current progress and any recently exercised task areas, and deliver the updated IMS to the Government.

The contractor shall submit an initial organizational report to include an overarching organization personnel hierarchy, and a subsequent page with an employee/personnel listing to show name, email and phone number within 30 days of contract award. The contractor shall submit an updated organizational report within 30 days of an employee gain.

The contractor shall provide a monthly financial and cost based reports and activity based cost report which covers all tasks under this effort. These monthly reports will record the progress, issues and cost expenditures for the reporting period.

Deliverables:

IPR Report (Monthly, Power Point (PPT) Slides or Portable Document Format (PDF) document) Initial IMS (Delivered within 15 days of award, Microsoft (MS) Project) Updated IMS (Monthly, MS Project)

Organizational Report (Delivered within 30 days of award, Quarterly after initial delivery, MS Word) Monthly Financial, Cost Based and Activity Based Cost Report (Monthly, Contractor Format)

6.1.2 Task Reporting (FFP)

The contractor shall provide a monthly status report (MSR) that describes the status and progress of the efforts on each of the exercised task areas against the IMS.

The information in the MSR shall include the following information:

Description of activities completed and deliverables provided during the current month for the TO.

Brief description of issues, challenges, or problems identified during the reporting period.

Description of the outcome of any trips, technical visit, and related results for the reporting period.

Deliverables:

Contractor’s MSR (Monthly, PDF)

6.1.3 Meeting Support (FFP)

The contractor shall host, prepare the meeting agenda and briefing materials, conduct, and be an active participant in meetings to include Weekly PKI Status meetings, Weekly PKE status meetings, and an informal daily 30 minute call to support PKI engineering activities. The contractor shall produce minutes for all meetings including synopses of technical discussions, and lists of open/closed action items.

Deliverables:

Briefing materials (Weekly, various formats) Meeting Minutes (Within seven days after meeting, PDF)

6.2 Combination of TMS and CSP (CPFF)

The contractor shall analyze the existing CSP and TMS hardware and software architecture and develop a Combination Plan that meets the existing technical and functional requirements while striving for maximum economies of scale through the combination of the systems.

The contractor shall develop a new Database Design Description in accordance with DID DI- IPSC-81437A based on the Combination Plan that details the proposed hardware and software configurations.

Once the new design is approved by the Government, the contractor shall decommission the old CSP and TMS equipment that will not be used in the combined system and return it to the Government. The contractor shall purchase new servers to support the combined system to be placed in existing Government owned labs.

Once the new design is approved by the Government, the contractor shall develop and document CRs needed to modify the new and existing software baselines and hardware configurations to support the combined system.

The contractor shall develop System Integration Tests for the combined system in accordance with DID DI-IPSC-41438A to be delivered to the Government according to the IMS.

The contractor shall configure the new and existing network appliances, software, and systems to host the combined system.

The contractor shall execute the System Integration Tests, document the results and deliver a test report to the Government in accordance with DID DI-IPSC81440A within 15 days after test execution.

The contractor shall provide documentation to support the IA accreditation to include the STIG checklists and CR documentation for DoD PKI ATO.

The contractor shall support the transition of the combined CSP and TMS system from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provide system design documents and user manuals.

Deliverables:

Combined Database Design Documentation (Once according to IMS, MS Word) Combined System Integration Tests (Once according to IMS, Contractor Format) Combined Software Test Report (15 days after test execution, MS Word) List of new CRs with all attachments (Once according to IMS, MS Word) Combined User Documentation (Once, MS Word) STIG Checklist (Once according to IMS, STIG Checklist Viewer format)

6.3 Develop issuance interface for SIPR REL DMZ delegated identity (CPFF) The contractor shall analyze SIPR REL DMZ delegated identity infrastructure and develop a Database Design Description in accordance with DID DI-IPSC-81437A based on the Combination Plan that details the proposed hardware and software configurations. This infrastructure is a new development activity for DoD PKI. The delegated identity infrastructure issues a delegated identity credential to the SIPR REL DMZ proxy. The contractor shall design and implement the interface between the proxy and DoD PKI Certificate Authorities (CAs) on the PKI infrastructure.

Once the new design is approved by the Government, the contractor shall develop and document CRs needed to modify the new and existing software baselines and hardware configurations to support the SIPR REL DMZ capability.

The contractor shall develop System Integration Tests for the SIPR REL DMZ capability in accordance with DID DI-IPSC-41438A to be delivered to the Government according to the IMS.

The contractor shall configure existing network appliances, software, and systems to host the SIPR REL DMZ capability. The contractor shall execute the System Integration Tests, document the results and deliver a test report to the Government in accordance with DID DI- IPSC81440A within 15 days after test execution.

The contractor shall provide documentation to support the IA accreditation to include the STIG checklists and CR documentation for DoD PKI ATO.

The contractor shall support the transition of the SIPR REL DMZ capability from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provide system design documents and user manuals.

SIPR REL DMZ Database Design Documentation (Once according to IMS, MS Word) SIPR REL DMZ System Integration Tests (Once according to IMS, Contractor Format) SIPR REL DMZ Software Test Report (15 days after test execution, MS Word) List of new change requests with all attachments (Once according to IMS, MS Word) SIPR REL DMZ User Documentation (Once, MS Word) STIG Checklist (Once according to IMS, STIG Checklist Viewer format)

6.4 Dogtag Certificate System development (FFP)

6.4.1 Deploy a development repository (FFP)

The contractor shall assist the Government in identifying the Dogtag PKI revisions that provides functionality matching the version of Red Hat Certificate System 8 and 9 in use by DoD PKI at task execution. These revisions will serve as a baseline for the Government’s repository. If an exact revision cannot be identified for CS 8 or CS 9, then the corresponding source Red Hat Package Manager (rpms) available from the Red Hat File Transfer Protocol (FTP) site will be used as a baseline version.

The contractor shall assist the Government in identifying feature differences between the Dogtag repository’s most current commit and the source code baseline. The contractor shall document the differences and categorize them as either security enhancements, bug fixes, or functional enhancements and deliver a report delineating such within 15 days after completion of this effort.

The contractor shall assist the Government in deploying a version control system (VCS) to maintain the source code baseline. The server hardware for the VCS will be provided by the Government. The hosting location of the server hardware will be at the Government’s facility in Ft. Meade, MD.

The VCS shall be Internet accessible and comply with all DoD STIGs for running an Internet accessible VCS. The contractor shall provide the Government a quarterly set of applicable STIG checklists for the VCS and justification for any open findings. The contractor shall track information assurance vulnerability alerts (IAVAs) against the VCS and update to the latest version of VCS provided by the vendor within 10 days after its release by the vendor. The contractor shall implement a web accessible interface, protected by Transport Layer Security (TLS) for the VCS and apply access control methods for web resources. The contractor shall utilize mutually authenticated TLS for authentication and certificate mapping for authorization on the VCS as appropriate.

The VCS shall have a bug tracking mechanism where the Government or contractor can register or review bug reports. The tracking mechanism shall permit various access methods and restrict information based on the authorizations afforded for the access method.

The VCS shall have a feature enhancement tracking mechanism where the Government or contractor can register or review feature enhancement requests. The tracking mechanism shall permit various access methods and restrict information based on the authorizations afforded for the access method.

The VCS shall have a task tracking mechanism for assigning and monitoring contractor or Government resources progress in resolving a bug or a feature. The tracking mechanism shall permit various access methods and restrict information based on the authorizations afforded for the access method.

The contractor shall use the VCS to track all code changes created by the development team.

The contractor shall not create a separate contractor internal VCS for this task.

Deliverables:

Dogtag Feature Report (15 days after task completion, MS Word) STIG Checklists (Quarterly, STIG Checklist Viewer format)

6.4.2 National Information Assurance Partnership (NIAP) validation (FFP) The contractor shall assist the Government in creating the necessary Security Target documentation based on the Protection Profiles applicable to the Certificate System. The Government will identify an authorized NIAP lab that will be conducting the evaluation of the Security Target documentation. If the lab is located outside of the Washington local commuting area, travel will be authorized. The contractor shall provide telephone support to the Government and the NIAP lab to complete evaluation process. During this process, the contractor may be required to supply additional test harnesses to the lab in support of the evaluation. The contractor shall update the Security Target documents to complete the NIAP evaluation and provide a final revision to the government once the certification is received. The contractor shall track lab progress, reporting issues to the Government within 2 business days.

Deliverables:

Initial Security Target documents (Once prior to NIAP testing, Government approved format) Final Security Target documents (Once 7 days after NIAP testing completed, Government approved format)

6.5 Dogtag Certificate System New Development activities (CPFF) The contractor shall identify, track and maintain a list of software defects that were discovered by the contractor or the Government. The defects are expected to fall into two categories:

security vulnerabilities and operational issues. The contractor shall identify if an IAVA, CVE, or government reported security vulnerability impacts an existing system within 24 hours of notification, with all reasonable efforts to complete a patch that corrects the security vulnerability within 5 business days. The contractor shall complete operational issue patches within 10 business days. The Government will prioritize the operational issue patches to be completed.

Patches for security vulnerabilities have priority over patches for operational issues. The Government anticipates that there could be as many as three vulnerabilities or patches to be completed each month. The contractor shall record all open and completed software defects and document the results in the IPR Report.

The contractor shall use industry best practices to create source code comments in a format extractible by Doxygen to develop Applicate Programmable Interface (API) documents, user manuals, and security evaluation documents as required by the development schedule. For example, different types of comments may be related to method invocation, TODO activities marked in the source tree, and specific cryptographic operations, constants, or configurations.

The contractor shall implement new capabilities through development activities for the following categories – 1) developing new support for other data source providers, 2) developing new support for smartcards that conform to the current Global Platform version at task execution, 3) implementing support for new cryptographic algorithms or PKI standards, 4) developing new support for emerging web technologies, and 5) new development to support future server operating systems, such as RHEL 8, that the CS product would need to migrate to.It is expected that there will be a total of 1 enhancement per quarter from any of the above categories.

The contractor shall develop a suite of regression test cases or procedures for the existing and updated software baseline and deliver a ZIP file within 10 days of the start of testing, containing the source tree of generated tests. The tests shall include code unit tests (i.e. Junit) and functional tests (i.e. JMeter) for library and application interfaces. The contractor shall execute the regression test cases, record the results, and deliver the results within 15 days after the completion of the testing.

Deliverables:

IPR Report (Monthly, PPT Slides or PDF document) API documents (After each major enhancement, Doxygen generated document) User Manuals (After each major enhancement, Doxygen generated document) Security Evaluation documents (After each major enhancement, Doxygen generated document) Regression Test Cases/Procedures (within 10 days after the start of testing, ZIP file containing all source tree files) Regression Test Report (15 days after completion of testing, MS Word)

6.6 Support Security enhancements (FFP)

The contractor shall reconfigure the rules and settings for the Web Application Firewall (WAF) to protect against new threats and to support CA deployments. The goal of this task is to reach a set of application protocol whitelists which constrain client traffic to the permissible set of client input. The protections are supplied using an Apache Hyper Text Transfer Protocol Daemon (HTTPD) instance and mod_security. The contractor shall provide an initial User Guide detailing the start and stop procedures for the WAF, and update the procedures annually. The contractor shall provide documentation to support the IA accreditation to include the STIG checklists and CR documentation for DoD PKI ATO.

The goal for user restriction is to use SELinux targeted policy as a technical control and enforce separation of duties as defined in DoD PKI policy. The contractor shall modify the text and configuration target files for SELinux to constrain permissions for users and processes on PKI systems. The contractor shall perform the initial effort to isolate user groups to restrict users to only the necessary portions of the file systems and system resources to perform their duties. The contractor shall perform a follow up effort to constrain processes to only the necessary portions of the file systems and system resources for correct functionality. Annually, the contractor shall update the SELinux target files to account for any changes that were made to DoD PKI Policy.

After the completion of each effort, the contractor shall deliver the SELinux target file documentation.

WAF User Guide (Annually, MS Word) WAF STIG Checklist (After SELinux targeted policy development, STIG Checklist Viewer format) SELinux target file documentation (Initial then Annually, MS Word)

6.7 Review and patch the Red Hat Certificate System source code for defects (FFP) The contractor shall review the Red Hat Certificate System 8 and 9 source code, as released officially by Red Hat and as available from the Dogtag open source project, for defects related to functionality and security. The contractor shall provide a report with a summary of components and files reviewed along with the issues identified and proposed patches.

Deliverables:

Code Review Report (After each official Red Hat Certificate System release, MS Word)

6.8 Notification of issuance events to users (CPFF)

The contractor shall analyze the existing DoD PKI Infrastructure and develop a new Database Design Description capability in accordance with DID DI-IPSC-81437A that will notify PKI subscribers and Registration Authorities (RAs) of issuance events. For PKI subscribers, notification occurs using available contact data already registered with DoD PKI or obtained from DoD Enterprise Global Address List servers. The capability will provide the subscriber with notifications for all credentials issued asserting the subscribers name, with date and time of issuance and responsible issuer. For RAs, notification occurs on a monthly basis of all certificates issued during the month by the identified RA.

Once the new design is approved by the Government, the contractor shall develop and document CRs needed to modify the new and existing software baselines and hardware configurations to support the combined system.

The contractor shall develop System Integration Tests for the combined system in accordance with DID DI-IPSC-41438A to be delivered to the Government according to the IMS.

The contractor shall configure the new and existing network appliances, software, and systems to initiate the capability on the DoD PKI Infrastructure.

The contractor shall execute the System Integration Tests, document the results and deliver a test report to the Government in accordance with DID DI-IPSC81440A within 15 days after test execution.

The contractor shall support the transition of the PKI subscribers and RA notification capability from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provides system design documents and user manuals.

Deliverables:

Notification Database Design Documentation (Once according to IMS, MS Word) Notification System Integration Tests (Once according to IMS, Contractor Format) Notification Software Test Report (15 days after test execution, MS Word) List of new change requests with all attachments (Once according to IMS, MS Word) Notification User Documentation (Once, MS Word) STIG Checklist (Once according to IMS, STIG Checklist Viewer format)

6.9 Research and Deploy an Alternate Certificate Management products (CPFF) The contractor shall conduct an Analysis of Alternatives for Certificate Management products available from commercial off the shelf (COTS) vendors as identified by the Government. The contractor shall include the vendor incorporation information, hardware and software requirements, standards supported by the product (e.g. Simple Certificate Enrollment Protocol, PKCS10, Global Platform etc.) and certifications obtained by the product (e.g. NIAP Common Criteria status, Federal Information Processing Standard (FIPS) validation), supported Hardware Security Modules and internal data storage techniques and requirements. The contractor shall map each product’s functionality back toward existing DoD PKI functions and identify gaps in capability or insufficient integration potential.

The contractor shall develop a deployment strategy for up to one alternate Certificate Management product. The deployment strategy shall identify integration requirements and also a regression test plan to verify successful integration. The Government will be responsible for procuring the alternate Certificate Management product.

The contractor shall execute the previously developed deployment strategy. The contractor shall supply all necessary integration solutions documented in accordance with DoD PKI configuration management practices. The solution set is shall contain software updates to existing DoD PKI systems, updated network configurations, and Red Hat Enterprise Linux kernel virtual machine configurations.

Analysis of Alternatives Report (Once according to IMS, MS Word) Deployment Strategy (Once according to IMS, MS Word)

6.10 Mobile Device Derived Credential Issuance Support (CPFF) The contractor shall assist in researching upcoming mobile Operation System (OS) updates and their effect to existing DoD PKI derived credential issuance systems. The anticipated mobile operating environments are: Windows 10, Apple iOS, Samsung Knox, Blackberry, and Google Android. The mobile device capabilities vary from well documented Application Programming Interfaces (APIs) for accessing cryptographic providers and key stores to low level programming. The DoD PKI infrastructure updates require extensive knowledge of Python TurboGears, Apache, mod_nss, mod_wsgi, mod_tact, and mod_security.

The contractor shall analyze upcoming changes to mobile OS and provide a report on the impact to the existing DoD PKI infrastructure along with a planned resolution for each issue identified.

The contractor shall develop CRs for the affected DoD PKI infrastructure hardware and software to resolve each issue that was identified.

The contractor shall develop enhancements to DoD PKIs derived credential issuance system.

The expected enhancements are to the web user interface (UI) workflow, updates to account for changes in Apple’s Over The Air (OTA), and updates to account for updates to Mobile Device Manager protocols.

Deliverables:

Mobile Analysis and Recommendation Report (After each OS update announcement, MS Word) List of new change requests with all attachments (Once according to IMS, MS Word)

6.11 Procure Hardware and Software (FFP)

6.11.1 Purchasing Support (FFP)

The contractor shall procure hardware and/or software as necessary to support implementations, testing and pilots of the DoD PKI PMO. The contractor shall procure the necessary equipment for the deployment of the new Root and Subordinate CAs in the development lab, Operations and Maintenance (O&M) lab, and the operational Root subordinate CA operational sites. The contractor shall work with the Contracting Officer Representative (COR) to define a Bill of Materials (BOM) for needed hardware and/or software. Once the COR has provided concurrence with the BOM, the contractor shall submit the purchase request for COR approval.

After receiving COR approval, the contractor shall procure the needed hardware and/or software.

The contractor shall coordinate delivery of the needed hardware and/or software with the COR.

The contractor may not have to perform all or any of these steps as determined by the COR. In some cases, the contractor shall procure equipment for delivery directly to another organization.

The contractor shall track all open orders and report status in the monthly IPR report.

BOM (For each purchase request, Original Equipment Manufacturer (OEM) provided format) Invoices for Purchased Equipment/Services (For each purchase request, OEM provided format) Quotes or Sole Source Statement (For each purchase request, OEM provided format) Order Status in IPR Report (Monthly, MS Excel or PDF)

6.11.2 Inventory Management (FFP)

The contractor shall create and maintain records of all Government property accountable to the contract, including Government-furnished and contractor-acquired property. The records shall contain the following information and be provided in the IPR report:

(1) The name, part number and description, National Stock Number (if needed for additional item identification tracking and/or disposition)

(2) Quantity received (or fabricated), issued, and balance-on-hand.

(3) Unit acquisition cost.

(4) Unique-item identifier or equivalent (if available and necessary for individual item tracking).

(5) Unit of measure.

(6) Accountable contract number or equivalent code designation.

(7) Location.

(8) Disposition.

(9) Posting reference and date of transaction.

Equipment Inventory List in IPR Report (Monthly, MS Excel or PDF)

6.12 CSP design and implementation (CPFF)

The National Security System (NSS) PKI CSP Concept of Operations (CONOPS) identifies the requirements for capabilities to be implemented in order to meet the NSS PKI Member Governing Board Objectives listed below. The PMO anticipates implementation of the CSP can be achieved by implementing enhanced capabilities building upon the NSS DOD PKI capabilities as a foundational capability. Current COTS products currently in use can be implemented with custom configurations combined with limited Government of the shelf (GOTS) equipment to meet the currently defined requirements. The contractor shall create comprehensive documentation outlining recommended architectural and system changes required for NSS DoD PKI to incrementally move the existing implementation to meet requirements specified by the NSS PKI CSP CONOPS and are further defined in the subsections below.

The purpose of NSS PKI CSP is to support the issuance of certificates and Tokens to support the transition of network access based on username/password to PKI based authentication utilizing Smart Card technologies. The NSS PKI CSP is intended to provide federal agencies the full spectrum of affiliates with accounts on United States (US) Secret level networks.

The current priorities of the CSP Governance Board Objectives are as follows:

1. Encryption Certificate Key Recovery (on-card recovery)

2. Encryption Certificate Key Recovery (on-card auto recovery)

3. Role Based Certificates

4. Encryption Certificate Key Recovery (software auto recovery)

5. Multiple Card Domain Support

6. Group Based Certificates

7. Emergency Support - Command & Control

8. Insider Threat

9. Bulk Certificate Revocation and Token Termination

10. API Exposure

11. Security Assessment

12. Code Signing Certificates

13. SIPRNet Test Lab

6.12.1 NSS PKI CSP Design (CPFF)

The contractor shall analyze the existing CSP hardware and software architecture and develop new requirements to meet the CSP Governance Board Objectives and provide a list of the new requirements to the Government for approval.

The contractor shall update the existing CSP Design Documents with the specific hardware and software configuration changes that will be needed to meet the CSP Governance Board Objectives.

Once the new design is approved by the Government, the contractor shall develop and document CRs needed to modify the existing software baselines and hardware configurations.

The contractor shall update System Integration Tests that fully test the new requirements in accordance with DID DI-IPSC-41438A to be delivered to the Government according to the IMS.

The contractor shall configure the existing network appliances, software, and systems to host the CSP capability.

The contractor shall execute the System Integration Tests, document the results and deliver a test report to the Government in accordance with DID DI-IPSC81440A within 15 days after test execution.

The contractor shall support the transition of the CSP system from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provide system design documents and user manuals.

Updated CSP Database Design Documentation (Once according to IMS, MS Word) CSP System Integration Tests (Once according to IMS, Contractor Format) CSP Software Test Report (15 days after test execution, MS Word) List of new change requests with all attachments (Once according to IMS, MS Word)

CSP User Documentation (Once, MS Word) STIG Checklist (Once according to IMS, STIG Checklist Viewer format)

6.12.2 NSS PKI CSP Implementation (CPFF)

Implementation of the CSP design will account for sustainment, operations, and restoration requirements as part of the implementation build utilizing bare metal build procedures developed and validated independently throughout the DoD PKI lab environments.

The contractor shall implement and deploy the planned NSS PKI CSP infrastructure utilizing the hardware and software designed in the previous task and document any changes identified during the implementation phase. The contractor shall upgrade pre-existing systems, as designated by the Government, to the current and supported version to meet the CSP requirements.

The contractor shall provide email and telephone support during the installation of CSP into both the JITC and Production laboratories. The contractor shall support the CSP in the DISA O&M Lab by developing and executing CRs.

The contractor shall gather the certification and accreditation (C&A) artifacts required for the Enterprise Mission Assurance Support Services (eMass) packet to support the ATO process for the CSP.

The contractor shall support the transition of the CSP from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provide system design documents and user manuals.

Deliverables:

C&A and eMASS packet (Prior to system deployment, various formats)

6.12.3 NSS PKI CSP Program Support (Optional) (CPFF)

The contractor shall support the Government in program management activities for the CSP program. These activities include attending the Governance Board (GB) and Configuration Control Board (CCB) meetings. For GB meetings, the contractor shall support the Government in the preparation and presentation of any GB CSP programmatic material. This material typically includes the status of the CSP program for requirements, schedule, help desk tickets, and funding. For CCB meetings, the contractor shall support the Government in the preparation and presentation of any CCB CSP material. This material includes CCB agenda and development or system design slides. The contractor shall also record any DISA CSP team actions assigned at the GB or CCB meetings, as well as record notes for all meetings.

Deliverables:

Program status slides for the GB meeting (Weekly, slides) Program system design and status slides for the CCB meeting (Weekly, slides) Notes from GB or CCB meeting (Within 7 days after meetings, PDF) Schedule material detailing CSP program task execution (Monthly, MS Project)

CSP Program Requirement documentation (After each major requirement revision, slides or

PDF)

6.13 Development Lab Support (FFP)

The contractor shall host a development lab environment located within the National Capital Region to support the execution of the contract. The contractor shall provide enough space to host up to 16 racks with the maximum height not to exceed standard rack elevations of 48Us.

The development lab environment should have the necessary power and cooling to support up to 16 HP DL 580s, 20 HP DL 380s, 16 4500X Cisco Switches, 6 5585 Cisco Firewalls, 2 F5 Big IP appliances, 12 Dell R720s, 6 Thales 6000+ HSMs, 2 Cisco 5555 Firewalls, 8 Cisco Switches, and 6 management personal computer workstations. The contractor shall have the ability to support an additional 16 racks of similar equipment for redesign or technical refresh efforts.

The lab shall be accessible to the Government for inventory purposes, to monitor or review technical tasks under this contract during normal business hours 0800-1700EST. The contractor shall ensure that the lab is remotely accessible to support external testing of systems. The contractor shall provide an inventory of the equipment located within the development lab every quarter.

Deliverables:

List of systems in the development lab (Quarterly, PDF or Excel)

6.14 WBBR Reengineering (Optional) (FFP)

The contractor shall analyze the WBBR architecture, including all source code files, and identify deficiencies and new enhancements to meet future capabilities as deployed by the DoD PKI PMO, and deliver an Analysis Report to the Government.

The contractor shall develop a new Database Design Description in accordance with DID DI- IPSC-81437A that will maintain current capability and address obsolescence concerns. The Database Design Description will contain the proposed hardware and software configurations.

Once the design is approved by the Government, the contractor shall develop and document CRs needed to modify the software and hardware configurations of the DoD PKI Infrastructure and WBBR to support the capability and deliver a report to the Government according to the IMS.

The contractor shall develop System Integration Tests for the WBBR system in accordance with DID DI-IPSC-41438A to be delivered to the Government according to the IMS. The contractor shall configure existing network appliances, software, and systems to host the reengineered WBBR system. The contractor shall execute the System Integration Tests, document the results and deliver a test report to the Government in accordance with DID DI-IPSC81440A within 15 days after test execution.

The contractor shall support the transition of the reengineered WBBR system from development to operational sustainment for up to 60 days to correct any errors identified during the transition and provide system design documents and user manuals.

Deliverables:

WBBR Analysis Report (Once according to IMS, MS Word) WBBR Database Design Documentation (Once according to IMS, MS Word) WBBR System Integration Tests (Once according to IMS, Contractor Format) WBBR Software Test Report (15 days after test execution, MS Word) List of new change requests with all attachments (Once according to IMS, MS Word) WBBR User Documentation (Once, MS Word) STIG Checklist (Once according to IMS, STIG Checklist Viewer format)

6.15 PKE Engineering Support (CPFF) (Optional)

The PKE team has a suite of existing testing and administrator support tools written in a variety of languages. The current support tools are updated monthly, and there are about 30 updates that occur a year across all of the tools. Purebred may receive more frequent updates due to the mobile platforms it supports. The list of support tools are:

- MailCryptkey

- CertAdmin

- CRLAutoCache

- Keyed Bulk Revoker (KeBlR)

- InstallRoot (Windows and Mobile Versions)

- certLoader Scripts

- MiniCRLFetch

- Federal Bridge Certification Authority (FBCA) Cross Certificate Removal Tool

- Trust Anchor Constraints Tool (TACT)

- PKI Copy and Paste (PCP)

- PKI Interoperability Test Tool (PITT)

- Purebred

6.15.1 Maintenance of Existing Custom Software (CPFF)

The contractor shall support the following programming languages at a minimum: C++, C#, Java, VB.NET and Python. The contractor shall also have hands-on experience with Windows PowerShell, Linux and UNIX shell scripting.

The contractor shall update the source code for previously developed PKE tools to incorporate additional capabilities that result from the deployment of new CA certificates/trust anchors, changes in PKI policies, and support of new standards.

The contractor shall maintain and version control all previously developed PKE tools' source code in the Government-approved enterprise code management tool, which is currently the subversion of either Software Forge or Project Forge. The contractor shall trace all changes or updates to the source code and other artifacts to requirements or defects. The contractor shall ensure that the Government has access to current and historical versions of the software baseline.

The contractor shall leverage best practices in revision control to efficiently manage trunks, branches, merges, and Tags on code submitted in the code management system.

The contractor shall update and maintain the PKE Administration Guides, Application User Guides, and other documentation and artifacts previously developed for existing PKE products.

The contractor shall update and maintain documentation and artifacts required for Risk Management Framework (RMF) activities using the approved processes. The contractor shall provide personnel to support the collection, creation and maintenance of artifacts for vendor components for Government RMF. Where possible, the contractor shall coordinate with the Government and other DoD entities to collect and augment existing Certification artifacts for re-use. The contractor shall upload and maintain C&A artifacts in the approved Government portals.

The contractor shall clearly communicate the level of effort required to update and test the software with project schedules and test plans. The contractor shall perform regression testing prior to acceptance of the software.

To ensure that the software will be or has been developed using secure coding practices in a manner that minimizes security flaws within the software, the contractor shall follow the National Institute of Standards and Technology (NIST) 800-53, Recommended Security Controls for Federal Information Systems and the DISA ID Directorate guidance. Prior to the execution of a software development work request the contractor shall provide the Government a copy of the contractor‘s secure coding best practices policy. The contractor shall deliver the PKE Application Source Code to the Government with all files contained in a ZIP file. Upon delivery of the software source code to DISA ID31, the contractor shall certify to the Government that the contractor complied with the Policy in the performance of its obligations under the delivery order.

Deliverables:

PKE Application Source Code (After each update, All source code files contained in ZIP file) PKE Application Administration Guide Updates (After each update, MS Word) PKE Application User Guide Updates (After each update, MS Word) PKE Application Testing Documentation Updates (After each update, Contractor Format) Contractors Secure Coding Best Practices Policy (Once, Contractor Format)

6.15.2 Evaluation and Integration of COTS Software and Hardware (CPFF) The contractor shall evaluate emerging commercial technologies at the direction of the Government for interoperability with the DoD PKI. This requires at least 5 years of technological knowledge of PKI fundamentals and the DoD PKI Program. DoD PKE directly supports the evolution of the DoD PKI. As the DoD PKI PMO incorporates new PKI capabilities to meet Capability Development Document (CDD) milestones, the contractor shall re-evaluate existing COTS software and hardware solutions for compatible functionality with these new features.

Known capabilities include:

Migrating to stronger cryptographic algorithms (i.e. SHA-256, ECC) Supporting non-person entity certificates Derived Credentials Compliance with FIPS 201 PKI implementation on SIPRNet and NIPRNet PK Enabled wireless mobile devices Cryptographic Smartcard Login PK Enabled Single Sign-on (SSO) solutions Secure remote access capabilities PK…