PWS_PKI Sustainment_14Jul26_SSA.docx

PERFORMANCE WORK STATEMENT (PWS)

1. Contracting Officer’s Representative (COR).

a. Primary COR. See DITCO Additional Text G1 – Points of Contact

b. Alternate COR. See DITCO Additional Text G1 – Points of Contact

c. Alternate COR. See DITCO Additional Text G1 – Points of Contact

d. Property Administrator. See DITCO Additional Text G1 – Points of Contact

2. Task Order Title. Public Key Infrastructure (PKI) Sustainment

3. Background. The Department of Defense (DoD) PKI Portfolio is 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.

As PKI capabilities have expanded and become more ubiquitous, requirements for its security benefits and systems enhancements have increased to better meet the reliability and availability requirements of the DoD community.

4. Objectives. The objective of this Task Order (TO) is to provide sustainment and sustainment-engineering support of the existing PKI platform, and continued program management and sustainment support. This will include operational monitoring and reporting support, multi-tiered support, training support, and system integration/deployment support.

5. Scope. The scope of this TO includes the operations and sustainment of existing PKI Government Off the Shelf (GOTS) code; requirement analysis and definition; procurement; IA analysis; Risk Management Framework (RMF) support; integration of Commercial Off the Shelf (COTS) products and services; quality assurance/system evaluation; developmental testing; installation support; documentation; operational reporting and monitoring; and system performance analysis to improve and expand DISA PKI system on Defense Information Systems Agency (DISA) utilized networks to include Non-Secure Internet Protocol Router Network (NIPRNET) and Secret Internet Protocol Router Network (SIPRNET). These sustainment activities shall remain in effect and fully supported until the PKI infrastructure is upgraded, modernized, or otherwise tech-refreshed, ensuring uninterrupted mission capabilities throughout the transition to new or enhanced platforms. The contractor shall perform as an integrated team member with other vendors, other Government contractors, and Government organizations in providing services under this PWS.

In order to meet Presidential EO 13587 Acquisition Category (ACAT) Information Assurance Management (IAM), and DoD Chief Information Officer/DISA directed enhancements, the main sub-components to include: Non-Classified Internet Protocol Router Network (NIPRNet) PKI, Common Service Provider, Token Management System, Global Directory Services, Non-Person Entity, NIPRNet Enterprise Alternate Token System, Robust Certificate Validation System, External Certificate Authority, Purebred, and Public Trust.

The NIPRNet and Secret Internet Protocol Router Network (SIPRNet) PKI deployments have varying Certificate Authority (CA) lifecycles and requires frequent deployments to ensure operational capability to meet requirements, or example Web Content Filtering (WCF), Hardware certificates, Software Certs, mobile device certs (PureBred), Non-Person Entity, Code Signing.

Common Service Provider (CSP):

The Committee on National Security Systems (CNSS) recognized that it was not cost-effective for each Federal Agency to establish and operate a separate PKI. As a result, CNSS Policy No. 25 created a CSP, which would operate the National Security System (NSS) PKI and provide certificate management services for Participating Agencies (PAs). The CNSS Directive #506 establishes the requirement for all federal agencies to implement the NSS-PKI to promote interoperability and secure information sharing and to use PKI to provide strong authentication on Secret level networks. The DoD PKI Program Management Office (PMO), using previous NIPRNet and SIPRNet PKI experience, responded and built an NSS PKI infrastructure for the DoD. The DoD is currently issuing SIPRNet hardware tokens from this infrastructure to personnel in the PAs.

The DoD PKI PMO, under the guidance of the CNSS and primary management of DISA, has been working with the CNSS PKI Member Governing Body to incorporate the capabilities needed by the CSP into the NSS PKI. The CSP began issuing certificates on hardware tokens in June 2013. DISA manages the certificate life cycle for PAs.

Token Management System (TMS):

The SIPRNet TMS allows SIPRNet users to generate credentials and store them on a hardware token. The SIPRNet TMS consists of Red Hat 8.1 Certificate Server (CS) software packages and the Red Hat Directory Server 8.1 software packages. The SIPRNet TMS consists of the following new components: Certificate Manager, Token Key Service (TKS), Token Processing System (TPS), Registration Portal, Data Recovery Manager and Directory Server.

Non-Person Entity (NPE):

The NPE system provides certificates to devices (e.g., workstations, mobile devices, web servers, network equipment) from a trusted CA on both the NIPRNet and SIPRNet. Certificates for NPEs will increase security by enhancing the identity and authentication of devices to DoD networks. NPE also provides Secure Socket Layer (SSL) certificates for encryption purposes to enhance data authenticity.

The NPE system is one of the DoD PKI Certificate and Token Issuance systems within the DoD PKI. Its primary mission is to issue certificates for devices and services on the NIPRNet and SIPRNet. In order to accomplish this mission, the NPE system also provides services that support user registration and management, compromise management, and reporting.

NIPRNet Enterprise Alternate Token System (NEATS):

NEATS provides confidentiality, integrity, authentication, and non-repudiation services by providing a centralized token management system for NIPRNet medium assurance certificates on NEATS tokens, known as Alternate Tokens, for use cases to include groups, roles, code signing and individuals not authorized to receive a CAC. NEATS will issue, revoke, suspend, provide key recovery, and provide token issuance and inventory management of each Alternate Tokens received into the system and until removed from the system permanently. NEATS improves security by leveraging PKI credentials for authentication and it strengthens accountability across the NIPRNet by tracking access to these PKI credentials. NEATS uses the Authoritative Data Repository as the authoritative data source and the CAC infrastructure to register users and issue tokens.

Robust Certificate Validation System (RCVS):

The RCVS is the DoD PKI's Online Certificate Status Protocol (OCSP) responder infrastructure. OCSP is a mechanism for determining the revocation status of X.509 certificates. OCSP, as defined by Request for Comments 2560 and 5019, uses a request-response paradigm in which an OCSP client submits a certificate status request to an OCSP responder and the responder, in turn, returns an OCSP response indicating whether the certificate status is good, revoked or unknown. DoD OCSP responses are generated from data contained within DoD PKI certificate revocation lists (CRLs); however, since an OCSP response contains status for only one or a small number of certificates, it is a much lighter-weight way to obtain certificate status than downloading a full CRL.

Purebred:

Purebred is a key management server and set of apps for mobile devices. It aims to facilitate separating key management from device management so that key management maintains its affinity with the PKI and is consistent across the DoD enterprise, and device management can vary with each operational scenario.

DISA PKI Engineering Purebred was developed to provide a secure, scalable method of distributing software certificates for DoD PKI subscribers’ use on commercial mobile devices. The system first establishes trust in device certificates used to encrypt configuration data bound for a device and then permits a subscriber to demonstrate possession and usage of their CAC to generate two new derived credentials and recover existing email encryption keys.

SIPR Purebred:

SIPR Purebred is a capability that has the ability to authenticate to services using DoD PKI certificates/credentials from SIPR mobile devices without relying on the smart card form factor.

This capability allows authentication to enterprise services or digitally sign and encrypt documents or emails used on SIPR mobile devices. Users of SIPR mobile devices are able to authenticate to PKI enabled services without the use of a smart card form factor.

SIPR PUREBRED is in line with the Classified (CSfC) Mobile Access Capability Package (MACP) v2.5 It has the ability to perform Sign and encrypt email and perform secure web browsing without the continuous need for a smart card reader and user Common Access Card (CAC).

Purebred supports key issuance and recovery for all DOD CAC holders under DOD PKI through a supervised initial device enrollment implemented by a Purebred agent. It supports the issuance of DOD credentials to Yubikey USB security tokens. It’s enrollment capabilities uses Over-the-Air Key Management Extension (OTA KME).

Gray CA:

The Enterprise Gray PKI is sustained at two DISA Sites and supports current and future Commercial Solutions for Classified (CSfC) requirements. The “Gray Network”, is a physically and logically separate network between an unclassified “Black Network” and a classified “Red Network” that requires separate gray PKI management of DoD certificates.

External Certificate Authority (ECA):

The DoD has established the ECA program to support the issuance of DoD-approved certificates to industry partners and other external entities and organizations. The ECA program provides the mechanism for these entities to securely communicate with the DoD and authenticate to DoD Information Systems.

The DoD PKI PMO has designated the ECA External Liaison Officer as the single point of contact to receive and coordinate all communications between the ECA community, DoD programs, and the DoD PKI PMO.

Global Directory Service (GDS):

GDS provides a DoD-wide directory service for the DoD PKI Program on both the NIPRNet and SIPRNet. GDS is the DoD PKI Program’s primary distribution point for the DoD PKI public email encryption certificates used for secure messaging and for CRLs used in validating DoD PKI certificates. The GDS architecture consists of Red Hat Linux servers, Government off-the-shelf (GOTS) MetaDirectory Java tools, a master directory with replicated directories built on the Red Hat Directory Service product, and a PKI-enabled white pages web query service using Apache/Tomcat web server applications. The custom MetaDirectory Java tools automatically pull and compile DoD PKI public information from the DoD PKI CAs and trusted ECAs. The GDS directory hosts the name, e-mail address, public key encryption certificates (for encryption of message traffic), and the unique identifier of each person who has been issued a DoD PKI certificate. The GDS has double redundant system architecture. GDS is hosted in two independent Defense Enterprise Computing Centers (DECC) that are globally load balanced with Domain Naming Service round robin technology. Also, at each DECC the GDS web and directory servers are load balanced locally behind F5 Networks application routers. GDS serves as DoD primary distribution point for DoD PKI CRLs. The figure below depicts the GDS data sources and consumers.

The DoD is transforming to network-centric operations. This includes:

1. Building and maintaining a network that people depend on and trust;

1. Populating the network with new dynamic sources of information; and

1. Denying the enemy comparable advantages and exploiting their weaknesses.

Network-centric operations are defined as military operations enabled by “networking the force.” This is accomplished through distributed collaboration processes designed to ensure that all pertinent available information is shared and that all appropriate assets can be brought to bear by commanders in order to employ dominant maneuver, precision engagement, full-dimensional protection, and focused logistics.

Vital to success of this modernization effort is establishing a secure means of moving and sharing a variety of information resources – data, voice, and imaging – to support strategic, operational and administrative functions in both peacetime and periods of national crisis. Critical to effective information assurance (IA) and sharing is the implementation of identity management capabilities and other security services. Enterprise-level identity management is a key component of secure information sharing in a network-centric environment, and a key part of enterprise-level identity management is enterprise-level directory services.

Public Trust:

The purpose of the effort is build Issuing CAs signed by General Services Administration Root CAs instead of DoD Root CAs, that issue SSL/Transport Layer Security certificates to .gov and .mil websites, and publish the results to publicly available certificate transparency logs.

The subcomponents listed above are included in the PKI infrastructure. Following references to PKI includes subcomponents. As the PKI requirements expand, grow, mature or require new capabilities, current programs may evolve, combine or be replaced by new capabilities.

The Government may require surge support during the base or any option period, and surge modification will be within the scope of the TO and provide increased support for the defined task areas of this PWS. Surge support over the life of the TO will not exceed 10% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to Federal Acquisition Regulation (FAR) 52.217-8.

6. Performance Requirements.

6.1 Task 1 – Task Order Management.

6.1.1 Subtask 1 - Task Order Management.

The contractor shall provide a Task Order Management Plan (TOMP) and control process to ensure management visibility and effective coordination from TO startup through the cost-effective delivery of high-quality services, contract transition and closeout, and shall adhere to all DoD, DISA, and other customer directives. The TOMP shall include all elements and processes to be used for successful execution of this task order to include Transition-In, Startup, Schedule Management, Subcontractor Management, Quality Control, Financial Control, Issue Escalation, Risk Management, Transition-Out, and Closeout. The draft TOMP, submitted with the proposal, shall be updated and resubmitted 14 calendar days after TO award (transition period).

6.1.2 Subtask 2 - Monthly Status Report (MSR).

The contractor shall submit an MSR that addresses adherence to the Best Management Practices, based on the Information Technology Infrastructure Library (ITIL) Framework. The MSR shall describe tasks, progress, quality, risks, customer feedback, any potential problems, accomplishments, and issues from the reporting period of the MSR for each of the exercised task areas against the Integrated Master Schedule (IMS). At a minimum, this data shall include:

· A brief description of activities and deliverables performed during the reporting month by Task Area. This description shall include problem definition and recommendations for program resolution. Particular attention shall be given to risk management and cyber security activities.

· Rolling 90-Day Action plan

· 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.

· Identification of key personnel and personnel reassignments including personnel added or removed from the TOs and all subtasks supported.

· The contractor shall provide an updated Government Furnished Equipment (GFE) list

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

· Cost-reimbursement estimates, quotes, sole source statements, and the status of ordering/invoicing. Evaluation of contract line-item numbers (CLIN) of ceilings, obligations, and projected demand.

· Self-assessment of performance with respect to the PWS Acceptable Quality Levels (AQL).

· 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 aligned to Labor Category and Prime vs Sub-contractor (when applicable).

· The contractor shall proactively identify and prioritize risks and alternative Courses of Action (COAs) sufficiently in advance to permit Government intervention and action before a risk becomes an issue, as well as identify best practices and lessons learned.

· Process improvement recommendations – this can be related to the specific projects or just overall business improvements

· Registration Authority (RA)/Local Registration Authority (LRA)/Key Recovery Agent (KRA)/ Robust Certification Validation Service (RAO) Services summary

· Help Desk Metrics

6.1.3 Subtask 3 - Monthly Contract Status Meeting (CSM).

The contractor shall hold monthly task order status meetings. The contractor shall conduct each CSM with a coordinated agenda, briefing materials, document minutes of the CSMs 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. CSMs shall provide for interchanges between the Government Staff (to include PKI Portfolio staff, the Contracting Officer (KO), the COR, and the contractor. The CSMs shall provide a forum to address performance, technical, and programmatic topics of the TO.

6.1.4 Subtask 4 - Integrated Master Schedule (IMS).

The contractor shall develop a single IMS to include each exercised task area that contains all the technical and functional activities required to complete the tasking and deliver the first IMS within 14 calendar days of task order award and updated each week thereafter to reflect the execution and completion of scheduled events. Specifically, this should also capture PKI milestones including but not limited to certificate expirations and software license expirations.

The contractor shall deliver an IMS with at least three levels of definition sufficient to allow for tracking the completion of scheduled events, duration, and inter-relationships between events. The IMS will be baselined, through deliverable acceptance, within the first 30 days of award and changes cannot be made to baselines without concurrence from the TO COR (or alternate COR) in conjunction with other PKI Program Management Leads. Any anticipated changes to the IMS shall be communicated within 24 hours of the identification of the change. This notification shall include identified impact factors and potential recovery mechanisms.

The contractor shall attend and be able to talk to the full IMS scope in a weekly IMS meeting to include risks to the schedule, recommended adjustments to the schedule as well as any external factors that have occurred that impacted the schedule. The contractor shall provide meeting minutes from these meetings to include line changes, impact of change, and Government acceptance date of the change.

6.1.5 Subtask 5 - Purchasing Support.

The contractor shall procure hardware and/or software as necessary to support implementations, testing, and pilots of the PKI Portfolio. The contractor shall procure the necessary equipment for the deployment of the new root and subordinate Certificate Authorities (CA) in the development lab, Operations and Maintenance (O&M) lab, and the operational root subordinate CA operational sites. The contractor shall work with the 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. Purchase requests shall include quotes or sole source statements (as required) and included in the MSR.

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 MSR.

6.1.6 Subtask 6 - Recurring Meeting Support and Participation.

The Contractor shall be required to attend recurring meetings in support of the PKI Portfolio. These meetings will fall into two categories: participant and meeting support. Currently the PKI Portfolio has four to six (4-6) weekly recurring meetings that will need participation. Additionally, there are two to three (2-3) monthly meetings and two to three (2-3) quarterly meetings that are also expected to be supported.

When participating in meetings, the contractor is expected to act in a professional manor while providing meeting notes/minutes for all meetings. When the task order is providing meeting support, the contractor shall prepare the meeting agenda, briefing materials, coordinate participants and venue (in person or virtual) prior to the meeting and provide minutes with action item tracking after the meetings.

6.1.6.1 DoD PKI Certificate Policy Management Working Group (CPMWG).

The contractor shall support the DoD PKI Certificate Policy Management Working Group (CPMWG) by providing support to the DISA PKI Program Management Office (PMO) voting member on policy changes presented at the CPMWG. Moreover, the contractor shall coordinate, and document all proposed updates to any Certificate Policy (CP) and/or Certificate Practice Statement (CPS) and/or Registration Practice Statement (RPS) through the CPMWG if the DISA PKI Program Management Office (PMO) is the originating entity of the proposed policy change. The contractor shall attend the monthly CPMWG meetings.

6.1.6.2 Configuration Change Board (CCB).

The Configuration Change Board (CCB) is a weekly meeting (one hour per week) where all upcoming changes to the PKI environment are discussed and made known to Government, stakeholders, and Combatant Command Support Agency (CCSA) within the PKI community. The contractor shall support the CCB chair during the weekly CCB Sync meeting to ensure all ongoing efforts are coordinated with the labs and production sites ahead of time and maintain, open, and close Change Requests (CRs) in support of the Operations Manager. The contractor shall gather, prepare, and distribute all necessary documentation to include the CR Deployment Plan, which is a comprehensive list of CRs scheduled for implementation that week, prior to the CCB meeting, The contractor shall distribute CCB meeting notes with an approved CR deployment list once the meeting concludes, and support any follow-on CCB correspondence from the PKI community.

6.1.6.3 Technical Interchange Meeting (TIM).

Technical Interchange Meetings (TIMs) take place so that customers, operators, stakeholders, and other PKI PMO staff can learn about the core mission of the DoD PKI and discuss upcoming development activities in support of that mission. TIMs will be held quarterly for the DoD PKI community lasting two - three hours. The contractor shall produce minutes including synopses of attendees, technical discussions, and lists of open/closed action items. Topics presented and discussed at the TIM will be focused on current challenges facing the DoD PKI community or forthcoming capabilities within DoD PKI. The contractor shall coordinate the date, place, and agenda for the TIM as directed by Government.

6.1.7 Subtask 7 – Transition-In Tasking.

The contractor shall prepare, provide, and execute a phase-in transition plan that describes management controls, techniques, and procedures to ensure all required personnel are available at their designated on or off-site location, ready to perform, 15 calendar days after the Period of Performance (PoP) start date. The onboarding period shall be day one (1) through day 14 of the PoP. Onboarding tasks include contractor submission of Visit Authorization Letters (VALs), COR processing of VALs, and CAC applications. Contractors should make every effort to schedule CAC appointments within this 14 day onboarding period. Personnel for the first 14 calendar days of the transition period shall be limited to what the offeror requires to facilitate the phase in transition plan. At a minimum, the plan shall include executable milestones and actions for each day of the Transition-In period that ensure all staffing is available to support the PWS. The plan shall detail how the offeror will maintain daily oversight of their staff. The plan shall identify procedures and corporate policies that support the attrition and sustainment of a qualified workforce. The total transition-in period is two months.

6.1.8 Subtask 8 -Transition-Out Tasking (Optional).

The Transition-Out Plan task shall facilitate the accomplishment of a seamless transition from the incumbent to an incoming contractor/Government personnel at the expiration of the TO. The contractor shall cooperate to facilitate an orderly changeover to the follow-on service provider. The contractor shall provide a Transition-Out Plan 120 days prior to expiration of the TO. The contractor shall identify how it will coordinate with the incoming contractor and/or Government personnel to transfer knowledge regarding the following:

· Provide familiarization training and documentation to any follow-on service provider.

· Transition of service operations outlined in the PWS to any follow-on service provider. The plan shall address the transfer of system configuration, load balancing configurations and processes, and other network infrastructure supporting documentation. The plan shall address the orderly transition of responsibility between service providers while ensuring continuity of operations (COOP).

· Inventories and locations of all documentation (program management documents, technical drawings, configuration data [including warranty and maintenance] implementation plans, and COOP). The plan shall address current retention schemes and access for follow-on service provider.

· Provide a status of all ongoing technical initiatives and support a smooth transition of all tasks to follow-on service provider.

· Transition milestones and communications. The plan shall address the milestones required to successfully transition the effort to a follow-on service provider. The plan shall also include a reporting plan to address milestone progress updates.

· The contractor shall conduct a joint inventory with Government personnel of all Government furnished property (GFP). The contractor shall deliver to the Government COR a final inventory of all GFP no later than (NLT) 90 business days before the end of TO performance.

Access to SIPRNet will be required to review SECRET level information in support of completing Task 6.1.

Deliverables (Task 6.1):

*Standard Distribution: One (1) copy of the transmittal letter without the deliverable to the Contracting Officer; One (1) copy of the transmittal letter with the deliverable to the Primary COR.

6.3 Task 3 - PKI Portfolio Sustainment.

6.3.1 Subtask 1 – Out-of-Band Management.

The contractor shall maintain the DoD PKI Out of Band Management Networks point to point for remote management of the PKI Portfolio Systems and Capabilities as well as for Active Monitoring of the Health of the PKI and Robust Certification Validation Service (RCVS) resources located at the Hosting and Compute Center (HACC)-Mechanicsburg, HACC-Oklahoma, JITC AZ and DISA Ft. Meade.

The Network consists of National Security Agency (NSA) Certified Type 1 Encryption Devices. Currently this requirement is using a 10 G KG175D TACLANES.

The contractor shall enhance, manage, and sustain the out of band network for PKI and RCVS.

6.3.2 Subtask 2 - Enhanced Monitoring.

The contractor shall utilize a Government approved suite to monitor application and network performance of the DoD PKI network and system. Current monitoring tools include, but not limited to: Network Performance Monitor, Application Performance Monitor, Server Performance Monitor, Net Flow Traffic Analyzer, IP Address Mapping, Syslog Server, Network Configuration Manager, User Device Tracker, Network Topology Mapper and Log Analyzer.

· Monitoring Platform uses Windows Server and Structured Query Language (SQL) Server.

· A Host Based Security System (HBSS) ePolicy Orchestrator (ePO) shall be managed and sustained to support these Window devices.

The contractor shall manage and sustain a Windows Domain to support the PKI Monitoring - implementation. This will include:

· Sustaining of the virtualization architecture consisting of two Hewlett Packard (HP) physical host servers at each site with VMware ESXi hypervisors and vSphere management software

· Sustain the Windows domain of the PKI Architecture which requires multiple domain controller servers and Windows domain administration functions (Active Directory Operational Unit (OU) configuration and management, security groups, group purchasing organizations (GPOs), replication, etc.)

· Installation, operations, updating, and maintenance of multiple Windows servers and Windows Software - including Windows Server 2016, MS SQL, ePO, and Windows Server Update Service (WSUS).

The contactor shall provide weekly monitoring reports in support of this subtask.

Access to SIPRNet will be required to review SECRET level information in support of completing Task 6.3.

Deliverables (Task 6.3):

*Standard Distribution: One (1) copy of the transmittal letter without the deliverable to the Contracting Officer; One (1) copy of the transmittal letter with the deliverable to the Primary COR.

6.4 Task 4 - Tiers I, II, and III Support (Optional).

The contractor shall provide Tier I, Tier II and Tier III services, and a supporting knowledge management environment. This Tier I, II, and III support is applicable to the internal PKI enclave only, which includes Government labs and operational sites only. This Tier I, II, and III support services does not include support to external PKI customers. The contractor shall provide on-site support at DISA HQ, Ft. Meade MD in response to email requests Monday through Friday, excluding Federal Holidays. Onsite support will be required only during normal business hours (typically between 0630 and 1800). On-call support will be required after normal business hours. The contractor shall provide an initial response within 30 minutes of receiving a request for support. The PKI Support team shall be able to research and elevate questions to Tier III personnel and the Government when circumstances require it. Responses shall meet the quality expectations of the Government. The number and type of requests shall be reported in the MSR.

· Typically manages around 50 -100 tickets per week with 5-10 issues per week requiring escalation for additional technical engagement and analysis across the task order team and Government.

· Serve as the programs Lead Tier II/III liaison to facilitate tracking and resolution of issues and correcting degradation with respective HACC, developer, and program office staff

6.4.1 Subtask 1 - Tier I Support.

The contractor shall provide Tier I support to the DoD and Federal Agency Communities in the form of technical consultation, security analysis and configuration support for the acceptance and use of DoD PKI certificates and existing DoD approved PKI certificates within DoD networks and information systems. The DoD Community is defined as the CCSA. Support may be required either for ongoing operations or for planned implementations. This can range from a basic support question such as “how to send an encrypted email” all the way up to a request for on-site support for a DoD Enterprise Program to assist with designing the security architecture to accept and validate External Certification Authority (ECA), DoD PKI, and DoD-approved PKI certificates. PKI Operational Enablement escalation path to Tier II & Tier III.

The contractor shall provide a document consolidating Frequently Asked Questions (FAQ) and to be posted on cyber.mil and other locations as directed by the Government.

6.4.2 Subtask 2 - Tier II Support.

The contractor shall establish and operate a PKI Tier II help desk to resolve issues elevated from Tier I. The contractor shall investigate elevated issues by confirming the validity of the problem and seeking known solutions related to these more complex issues. The contractor shall collect information such as the name of the program or application that has failed or any database related details (e.g., table, view, or package name) or application programming interface (API) names. This information shall be readily available to Tier III if the issue is further escalated to that level. The contractor shall manage all support tickets assigned to Knowledge Management (KM).

6.4.3 Subtask 3 - Tier III Support.

The contractor shall provide Tier III technical support to HACC Operators for all infrastructure issues regarding the PKI Portfolio. The contractor shall also provide on-call support to resolve PKI Portfolio Tier III issues.

The contractor Tier III support shall be available at any time, to assist in resolving infrastructure issues with PKI technologies. The contractor shall create, document, test, and install shell scripts, and/or DISA approved programs/applications that will provide automation of duties to manage the system most effectively in accordance with the Configuration Management (CM) process.

The contractor shall provide the COR and PKI Portfolio an email notification of any issues including degradation, outage, or any factor that impacts operational status of the PKI Portfolio. Notification format shall include a problem description, time and date of issue, and discovery, impact, and troubleshooting measures. The notification shall also indicate whether the issue is a recurring problem or a new issue. The contractor shall provide the COR and PKI Portfolio an after-action report (AAR) when issues including degradation, outage, or any factor that impacts operational status of the PKI Portfolio occur. The AAR shall include all details that pertain to the event to include time and date of issue start and resolution, systems and users impacted, and issue resolution time/date. These items shall be delivered in an overarching Issue Tracker which includes operational status reports, Issue notifications, Issue Resolutions, authorized service interruptions, After Action Reports, Continuous monitoring issue logs, and audit log reviews.

Access to SIPRNet will be required to review SECRET level information in support of completing Task 6.4.

Deliverables (Task 6.4):

*Standard Distribution: One (1) copy of the transmittal letter without the deliverable to the Contracting Officer; One (1) copy of the transmittal letter with the deliverable to the Primary COR.

6.5 Task 5 - PKI Portfolio Program Support.

6.5.2 Subtask 2 – Onsite Infrastructure Support.

The contractor shall provide Operations Management onsite support at Ft. Meade, Maryland, Oklahoma City, Oklahoma, and Mechanicsburg, Pennsylvania for Operations with deployment, integration, and operation of PKI Portfolio capabilities. Contractor support shall:

· Ensure baseline configuration is maintained to site deployed PKI systems

· Implement approved CRs released by CCB in CR/RTS or approved by the PKI Portfolio

· Ensure all changes that are made to site deployed PKI Portfolio’s systems are recorded and implemented via RTS (https://remedy.dodpke.us/) or approved by the Operations section of the PMO

· Provide information and guidance to HACC staff about CP/CPS compliance

· Immediately notify PKI Portfolio Operations of any outage and/or degradation of operating status for PKI systems

· Support system and application troubleshooting, tuning, management, implementation, operations, and decommissioning

· Provide the PMO requested reports to include logistical, operational, and process reporting

· Compile aggregated daily check reports and provided daily operational status checks to validate operational availability reports to PKI Portfolio

· Provide implementation and integration support for deployment of new capability, tracking Service Request Form from submission to project deployment completion

· Serve as TO representative for dissemination of operational tasks

· Work to analyze PKI Portfolio Systems monitoring and logging architectures to identify deficiencies and propose enhancement in the form of CRs and Implementation Plans. In the follow-on option years, part of this analysis will lead to development of a “Continuous-Use” Monitoring capability to provide web-based status and trend information to PKI Portfolio customers on system and sub-system uptime and usage.

· Engage with Information System Security Officer (ISSO) to review weekly audit log discrepancies and work with the nominated site staff and PKI Portfolio to develop Plan of Action & Milestones (POAM) for mitigation or resolution

· Track site certificate validity (issued internal/external certificates and Delegated Trust Model (DTM) certificates) and ensure rekey/update activities occur to ensure no service interruption.

· Validate Certificate Revocation Lists (CRL’s) are updating per applicable PKI CPS.

· Monitor all services and offerings of the PKI environment through deployed application tools. E.g., Nagios.

· Generate, update, and disseminate SOP/ TTP through specified platform.

· On-site personnel shall schedule and implement JITC-released CRs according to authorized maintenance windows for PKI. The contractor shall schedule all updates outside of peak operating hours and implement on no more than one node at a time to avoid capability degradation.

· Support additional PKI Portfolio requirements as the PKI program evolves.

DISA Hosting and Compute Center (HACC) Support.

The contractor shall maintain onsite support at specified PKI enclave locations that will assist HACC Operators with operations of all PKI Portfolio systems. The onsite support shall have expertise with Red hat Enterprise Linux, Red Hat Directory Server, Red Hat Certificate System, Red Hat Directory Services, directory Access Control Lists, Directory synchronization tools, PKI, network communication, encryption to include Hardware Security Module (HSM), Extensible Markup Language, Java code development, X.500 directories, Hypertext Transfer Protocol (HTTP), HTTP Secure, Lightweight Directory Access Protocol, Active Directory, Cisco IOS, F5 BigIP Local Traffic Management (LTM)/Global Traffic Management (GTM) iRules, fundamental troubleshooting skills, enterprise level directory administration tools, and other closely related Directory services technologies.

The contractor shall support CR generation for the current operational systems at the HACCs to ensure the PKI operates 24 hours per day, seven (7) days per week (24/7) and meets operational availability parameters. PKI operational availability is defined as the time that the PKI is prepared to respond to requests to register subscribers; generate new, renewed, or re-keyed certificates; process revocation requests; generate CRLs; provide certificate status checking; and respond to key recovery requests. The contractor shall also track, facilitate, and work to resolve any trouble tickets opened by the program team on vendor’s products and/or code developed, including testing bug fixes provided by the vendor, providing feedback to the vendor, engaging appropriate stakeholders in troubleshooting sessions and providing resolutions to the customers. The contractor shall track and facilitate any trouble tickets opened by the DISA Global Service Desk in support of the PKI program including getting feedback from the customers, engaging appropriate stakeholders in troubleshooting sessions and providing resolution to the customers. The contractor shall provide weekly status of the resolution of those trouble tickets to the COR in a format that supports the configuration management process and shall be documented in the Management Plan. The contractor shall ensure that all changes to the system comply with the CPS where applicable. Specific areas considered within the realm of this review to include the following:

· Data Distribution Service Processes and Interfaces

· Directory and Data Storage Components

· Customer Usage and NetOps End-to-End Monitoring

· HACC Site-to-Site Data Integrity, Parity, and replication

· Delegated Trust Model updates

· Key/Rekey actions

· Certificate renewals

· Enclave monitoring tools

· Assured Compliance Assessment Solution (ACAS)

· HBSS

· Satellite

· Puppet

· Ansible

· Red Hat Identity Manager (IdM)

6.5.3 Subtask 3 – Support.

The contractor shall ensure certificate(s), DTM, F5 DS account passwords and CRL’s have not expired on PKI Portfolio systems on a frequent basis. For CRL’s, the contractor shall ensure the CRLs are updated and posted in accordance with the CP/CPS. The contractor shall provide Operating System (OS) and Validation Authority updates as released.

6.5.4 Subtask 4 – Registration Authority (RA) Support.

The contractor shall provide on-site PKI support as directed by the Government to assist in technical advice, security analysis, configuration support and certificate issuance, suspension, revocation, and other duties outlined in the CPS/RPS.

The contractor shall administer, maintain, sustain, and update RPS/CPS compliant RA workstation on NIPRNet, SIPRNet, GIPRNet or other DISA approved Networks at DISA Headquarters (HQs). The contractor shall be responsible for identifying escalated privileged individuals within the team that will serve the additional duties of RA, Local Registration Authority (LRA), and Key Recovery Agent (KRA) on NIPRNet and RA, LRA, KRA, and Registration Authority Officer (RAO) on SIPRNet and other future networks based on PKI Requirements. A list of the newly added officers shall be delivered monthly. The contractor shall train escalated privilege individuals IAW the PKI program policy guidance and be responsible for the following:

· Maintain qualifications that meet the CPS requirements

· Support tickets from customers in procedures required to be followed when obtaining digital certificates from the organization CA

· Provide Subject Matter Expert (SME) support, as necessary, to ensure the organization is functioning effectively

· Conduct annual review of combatant commands, services, and agencies (CC/S/A) and Participating Agencies (PAs) provisioned RA/LRA/KRA/RAOs and coordinate changes

· Support and coordinate additions of newly trained RA/LRA/KRA/RAOs with approved nomination letters

· Conduct daily checks of deployed PKI capability and provide daily status update to PKI PMO

With PKI PMO concurrence, the contractor shall support RA/KRA/LRA/RAO services if a suitable DoD and Federal community component escalated privilege user is not available. This support is infrequent but shall be made available as an option of last resort to the DoD and Federal Community. All efforts shall be made to handle all requests by the appropriate DoD or Federal Registration Authority office.

All RA, KRA, LRA and RAO activities shall be included in the MSR.

6.5.5 Subtask 5 – PKI Portfolio Lab Sustainment.

The contractor shall maintain the PKI Labs at Ft. Meade, Maryland. The contractor shall maintain the PKI Labs from on-site and will only access remotely during contingency operations (e.g. pandemic, building closures, etc). The labs will consist of GFE purchased by the Government. The contractor shall ensure that the systems are up to date with current versions and patches. The contractor shall have access to the Remedy (https://remedy.dodpke.us/) asset management systems or record that provides configuration management for the Development, Test and Staging Laboratories. The contractor shall be responsible for providing status updates to Remedy (https://remedy.dodpke.us/) asset management of record systems for the PKI Labs. The contractor shall be responsible for providing a monthly report of patching activity within the MSR. The contractor shall supply all compliance data to the DISA PKI Information Systems Security Manager (ISSM).

6.5.6 Subtask 6 – Support Security Enhancements.

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 (Security Technical Implementation Guide (STIG) checklists and CR documentation for DoD PKI Authority to Operate (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.

6.5.7 Subtask 7– Review and Patch the RedHat Certificate System Source Code for Defects.

The contractor shall review the Red Hat Certificate System 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.

6.5.8 Subtask 8 – Maintenance of Existing Custom Software.

The contractor shall support the following programming languages at a minimum: Objective-C, 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 GOTS software to include PKE tools to incorporate additional capabilities that result from the deployment of new CA certificates/trust anchors, changes in PKI policies, and…