Solicitation_PTL_System_A005.docx

Solicitation No. S-AQMMA-12-R-0413 A005 Personnel Tracking Locator Department of State

TABLE OF CONTENTS

iii Section B – SUPPLIES OR SERVICES AND PRICES/COSTS

B.1 SERVICES

The Contractor shall provide the software and services in accordance with Section C, and the attachments.

B.2 TYPE OF CONTRACT

The Government contemplates single award of a stand-alone, hybrid contract resulting from this solicitation. Contract types will be firm-fixed-price for CLINS X001 through X007, CLIN X010 through X015, and labor hour or time-and-materials for CLIN X008 and X009.

B.3 PAYMENT, CEILING, AND WITHHOLDING

The Government will pay the Contractor the unit prices specified in this section. The Government shall impose a deduction from the amount of payment for each instance of unacceptable performance or non-performance in accordance with Attachment 1, Quality Assurance and Surveillance Plan (QASP).

BASE YEAR

1,880

1,880

1,880

1,880

1,880

1,880

OPTIONAL SERVERS

BASE YEAR

OPTIONAL SOFTWARE FUNCTIONALITY

OPTION YEAR 1

1,880

1,880

1,880

1,880

1,880

1,880

OPTION YEAR 1

OPTIONAL SOFTWARE FUNCTIONALITY

OPTION YEAR 2

1,880

1,880

1,880

1,880

1,880

1,880

OPTION YEAR 2

OPTIONAL SOFTWARE FUNCTIONALITY

OPTION YEAR 3

1,880

1,880

1,880

1,880

1,880

1,880

OPTION YEAR 3

OPTIONAL SOFTWARE FUNCTIONALITY

OPTION YEAR 4

1,880

1,880

1,880

1,880

1,880

1,880

OPTION YEAR 4

OPTIONAL SOFTWARE FUNCTIONALITY

SECTION C – STATEMENT OF WORK (SOW)

C.1 INTRODUCTION

The Department of State (DOS), Bureau of Diplomatic Security (DS), Office of Security Technology (ST), Personnel Tracking and Locator (PTL) Section, has a requirement for an enterprise personnel tracking system which can ingest the full spectrum of personnel tracking devices on the market currently and with the ability to ingest future next generation devices at minimal cost to the government for adaptation. The proposed system will replace the current nine year old system that supports PTL operations both domestically and overseas.

C.2 BACKGROUND

DS is responsible for deployment of technical security systems that reduce risk to government personnel and facilities. Specifically, the protection of government personnel traveling from the protected mission facility to their foreign counterpart’s office is of paramount importance in the execution of U.S. foreign policy.

C.3 MISSION

The PTL mission is to provide tracking and monitoring capabilities to USG personnel worldwide in support of foreign policy requirements.

C.4 CONTRACTUAL OVERVIEW

At a minimum the Contractor shall provide three (3) software application packages. The three applications will be installed an utilized in the following capacities: 1) Production Server, 2) Back-up Server, and 3) Test Server (i.e., (Gold Standard) verification, certification and authorization (C&A)).

Note: The term "PTL System" as used hence forth shall refer to the Contractors software application installed and operating on either the Contractors or Government furnished hardware platform.

The PTL System shall employ state-of-the-art hardware and software technologies that provide the capability to monitor and ingest multiple device formats over varied transmission paths (i.e., worldwide cellular SMS messaging and data, and satellite based tracking devices). The PTL System shall aggregate the data collected and distribute it to various front end user systems, and provide a default display capability.

The PTL services shall be based at designated Government locations inside the continental United States.

· Commercial-Off-The-Shelf (COTS) fully redundant turn-key system that satisfies the requirements enumerated below.

· Engineering and technical services to include system installation, operational validation of all system elements that support the PTL Systems operations, and associated data services.

· Operations maintenance, technical support, and sustainment services required to support a 24x7x365/6 DOS activities worldwide. The services shall ensure all software and hardware (optional) are functional and remain up-to-date.

· Contractor shall assume all costs associated with any required licensing or maintenance agreements for the life of the contract.

C.4.1 PTL Server The PTL servers (e.g., Contractor or GFE) are mission-critical enterprise servers and shall provide the I/O throughput, reliability, durability and expansion capabilities required to support the PTL mission. The server possessing an expansion capability shall ensure no degradation of the operating system or processing speed over the life of the contract. The PTL System shall operate 24/7/365 and support the following volume of user and tracking activity.

NOTES:

1 Legacy systems remain in the inventory, but DOS immediate future is to baseline the DOS-issued tracking devices in our tracking program to Iridium-Based NAL-built SHOUTs, SHOUT-NANOs, and 9602-LP devices. These devices transmit messages in the PECOS message structure.

2 Estimated yearly growth is compounded per performance period. Estimate may change based on world events and/or budget constraints. More significant and unpredictable is the number of tracking devices procured and fielded by other federal agencies. Integrating the data from these other, unknown type/number, tracking devices is critical to situational awareness for DOS posts overseas.

3 DOS requires unrestricted global web access for approximately hundreds to thousands of users.

The DOS information security program ensures the security for all systems, networks, and data that support operations. The DOS established a comprehensive Information Security Program (ISP) to ensure the confidentiality, availability and integrity of its information and support systems. The current information security program identifies the relevant laws, regulations, and policies; delineates responsibilities; describes the governance mechanism; and catalogues the elements of the Department’s operational, defense-in-depth cyber security strategy. The DOS Standard Operating Environment (SOE) is a specification for using a standard architecture and applications within a Department information system.

The PTL hardware shall be either on or be capable of being added to the State Department Information Technology Change Control Board (ITCCB) list of approved hardware and software. See Attachment 5.

C.4.2 PTL Software

The PTL software application shall be capable of ingesting data from currently deployed devices, which are PECOS-based, Iridium devices manufactured by NAL Research. The PTL system shall be device agnostic and capable of ingesting multiple other device types, as the government also desires to expand its device portfolio with commercial Iridium devices, Global Star based devices, and cellular devices, among others. Using task orders, the contractor shall integrate devices selected by the government into the PTL system when necessary.

The PTL Systems shall be fully redundant with intra-site hot failover, therefore in the event of a component failure the system shall automatically switch over to its backup component without the need for manual intervention.

The functional requirements enumerated in the paragraphs below are categorizes as either "Mandatory" or "Optional." Mandatory functional requirements are required at the time of contract award, and Optional functional requirements must be incorporated into the PTL application during the performance of the contract. See Attachment 6.

In order to facilitate the DOS Certification and Accreditation (C&A) requirements, any solution proposed shall be able to document approval or accreditation by another entity of the federal Government.

C.5 PERSONNEL TRACKING LOCATOR (PTL) SYSTEMS

The DOS mission portfolio is comprised of a significant number of devices that are currently deployed worldwide. The PTL Systems shall be device agnostic and be capable of ingesting data from the tracking devices currently deployed, as well as new, FIPS-approved-encrypted devices using varied transmission paths. The PTL Systems shall be adaptable to allow for new device types and the integration of other transmission paths as necessary.

In order to leverage the existing DOS infrastructure and approved assets the PTL Systems shall provide compatibility with Oracle Version 11 with Oracle Advanced Security - Transparent Data Encryption (TDE).

The DOS has a requirement for a ready-to-deploy solution that meets the maximum number of functional requirements identified in the subparagraphs below, possesses an existing authorized to operate (ATO) and meets minimum government information assurance standards in accordance with NIST or DIACAP standards .

C.5.1 Web Interface

The PTL Systems shall possess the following capabilities:

C.5.1.1 Facilitate the viewing of live track data, historical track data, emergency messages, track administration functions, user administrative functions, and data export functions through a unified, secured, and web interface.

C.5.1.2 Display live/historical tracks with the following device information for all ingested devices: device ID, alias/call-sign, last reported latitude/longitude, last reported track receive time, and emergency status. If the device provides speed, direction or brevity code then the web interface shall display that information as well.

C.5.1.3 Have the capability to export historical device data in CSV format to files.

C.5.1.4 Be able to create, retrieve, update, or delete brevity codes in the web interface for each tracking device.

C.5.1.5 Record a “receive” timestamp with each received device update

C.5.1.6 Provide secure two-way messaging capability to trackers capable of receiving messages.

C.5.1.7 Provide users the capability to filter live/historical tracks individually or as part of a device group. Each user approved to do so shall be able to filter by device, device name/alias, date/time, or device group.

C.5.1.8 Use role-based access control for all functions and commands available to the government. Users shall be granted only the minimum necessary permissions to perform functions for any given device group. User administration functions shall be granted only to authorized administrators.

C.5.1.9 Provide a means to access all configuration settings through the same unified interface. These shall include all software and program settings except settings of the internal COTS products

C.5.1.10 Provide the capability to authorized administrators to assign a user separate permissions for each nested device group. These permissions include but are not limited to the ability to view or modify devices within the device group.

C.5.1.11 Provide system-wide notifications to all users upon software updates, maintenance cycles, or system-wide configuration changes.

C.5.1.12 Allow users to create nested device groups and to assign or reassign devices under the user’s control to any of the device groups under that user’s control.

C.5.1.13 Show only devices, functions, and configuration settings for which a user has authorization.

C.5.1.14 Allow users to remotely configure all capable trackers for which a user has permissions to modify. This configuration shall include remotely changing the reporting rate of each tracking device.

C.5.1.15 Display an audible/visual emergency warning to the user in the event that a user-viewable device sends an emergency message to the system.

C.5.1.16 Provide an authorized user the ability to configure a Geofence for each user-viewable device. The user shall have the ability to configure whether the Geofence alarms when a device enters the Geofence, exits the Geofence, or both. If configured, when a tracking device enters or exits the Geofence, the PTL System's web interface shall provide an audio and visual warning to those users with the viewing permissions for that device.

C.5.1.17 Allow an authorized user the ability to define and edit multiple Geofences or zones for each user-viewable device (at least 10).

C.5.1.18 Be capable of importing a Geofence from file.

C.5.1.19 In an emergency, allow an authorized user to remotely activate the microphone of audio-capable trackers. The administrator shall have the capability to globally enable or disable this function. Contractor will define safeguards over how this feature will be controlled to ensure access to this feature will be limited to a restricted group of authorized users only, and track implementation of this feature in the audit logs.

C.5.1.20 Provide an authorized user the ability to edit a user-modifiable tracker’s association data, including each tracker’s alias or call-sign.

C.5.1.21 Provide an authorized user the ability to edit emergency contact information for each user-viewable device.

C.5.1.22 In the event of an emergency, the PTL Systems shall send an emergency notification via e-mail to the configured emergency contact(s) associated with that device in the system.

C.5.1.23 Allow authorized users to manually deactivate an audible/visual emergency warning and geo-fence warnings.

C.5.1.24 Provide an authorized user the capability to export live tracking data and emergency messages via unencrypted UDP, unencrypted TCP, and HTTPS protocols to any other IP address and port. An authorized user shall be able to switch between export protocols at any time.

C.5.1.25 Provide a secure built-in web viewer that allows a user to see selected trackers as icons directly in the web application. Viewer shall allow the user to pan and zoom on the map.

C.5.1.26 Provide the user with the capability to disable the built-in viewer when necessary, in order to save bandwidth, or so that the user can use an external viewing application

C.5.1.27 Have the ability to zoom to a specified tracker, resolution less than or equal to 250m for geospatial imagery and street level for street maps.

C.5.1.28 Differentiate trackers within the display so that a user may distinguish between closely-spaced trackers.

C.5.1.29 Have the ability to zoom to a specified tracker, at street-level resolution, meaning streets must be distinctly identifiable, for both geospatial imagery and street maps.

C.5.1.30 Provide an authorized user the ability to configure a Geofence for a user-viewable device by highlighting the area directly on a map.

C.5.1.31 Display the following device information when an icon is selected : device ID, device model, alias/call-sign, last reported latitude/longitude, last reported MGRS, last reported time, and emergency status. If a device provides speed, direction or brevity code then the web interface shall display that information as well.

C.5.2 Operator Display and Presentation

The PTL Systems shall:

C.5.2.1 Serve data to multiple external viewing applications. These applications include but are not limited to Google Earth, ESRI and FalconView. This data will include the following device information: device ID, device model, alias/call-sign, last reported latitude/longitude, last reported MGRS, last reported time, emergency status, and brevity code.

C.5.2.2 If the external viewing application supports the ability to display speed and direction this data also shall be provided to the external viewing application.

C.5.2.3 Provide the capability to integrate layers of geospatial data and overlay the data on a Google Earth Baseline.

C.5.3 System Monitoring

The PTL Systems shall provide security auditing and monitoring services, to include intrusion detection and firewall monitoring.

As deemed necessary by the government, the Contractor shall use network management software, another automated process, or a combination of the two to monitor the connection status and health of the externally-connected networks. These externally-connected networks include but are not limited to VPN's to other systems and incoming device transmission networks such as satellite ground stations.

C.5.4 Special Technical Requirements

The PTL Systems shall meet the following technical requirements:

C.5.4.1 Ingest multiple device formats over varied transmission paths, including but not limited to PECOS, Iridium, Global Star, and various 2G/3G/4G cellular networks via Short Message Service (SMS) and data.

C.5.4.2 Ingest, at a minimum, device ID, position, and elevation data from each tracker, and any brevity code. If the device provides it, the PTL Systems shall also ingest device send time, speed, and direction.

C.5.4.3 Provide the ability to ingest encrypted device data using FIPS-approved encryption algorithms where encryption is supported by the device.

C.5.4.4 Utilize an Application Programming Interface (API) for integration to third-party external viewing applications and systems. This API shall include at a minimum: retrieval of live or historical tracks by ID, Alias, Date, Device Group, or other filters, and retrieval of device metadata and geo-fences.

· The API shall be exposed through secured and encrypted services, be it web services, remote method invocation, or complete exposure of proprietary format to the government.

· All API methods shall be exposed, documented, and provided to the government. All API methods and documentation shall be accessible without requiring proprietary software or a license.

C.5.4.5 Provide the ability to import and export real-time data in the JBFSA format (Versions 1.0, 1.0a, 2.3 and FFT 2.4). The Contractor shall update this capability for forward compatibility as required.

C.5.4.6 The production server shall consist of performance languages, either compiled or JIT-compiled, suitable to an enterprise environment.

C.5.4.7 The PTL shall have the ability to store all tracking data for a minimum of two (2) years.

C.5.4.8 (OPTIONAL) Provide the capability to export live track data and emergency messages in real-time through a one-way guard.

C.6 INSTALLATION AND DEPLOYMENT SERVICES

The Contactor shall be responsible for the installation of the PTL systems in a dedicated Government facility. The Contractor shall provide a comprehensive test plan that will be used to verify the full design functionality and operational readiness of the PTL system once installed. The Contractor shall provide the test plan to the COR for review. Installation shall including the following:

· Pre-configuring and installing software.

· Connecting the PTL systems to the Government provided communication and internet.

· Installing the PTL systems, including web servers, database servers, Open Street/Open Topo map servers, and peripheral equipment.

· Documenting the entire system architecture and Standard Operating Procedures (SOPs). The SOP will serve as a living document outlining daily operations procedures, and coordination with the DS point-of-contact (POC) for emergency events and technical support.

· Performing system testing and verification to ensure the operational readiness of the system and the full function of fail-over mechanisms.

C.6.1 Pre-Deployment Tasks

The Contractor shall participate in pre-deployment planning prior to operations as directed by the Contracting Officer Representative (COR). These activities typically include providing engineering support and technical data. All Contractor specific terminology inherent to the system shall be documented and defined using industry accepted definitions.

The DOS shall perform acceptance testing prior to deployment of the PTL Systems.

C.7 OPERATION, MAINTENANCE AND SUSTAINMENT SERVICES

The Contractor shall provide Tier 1 maintenance support for the three (3) PTL servers and software applications. Tier 1 supports includes responding to questions regarding the PTL application, assisting with user creation, and device management Operations maintenance, technical support, and sustainment services required to support a 24x7x365/6 DOS activities worldwide. The services shall ensure all software and hardware (optional) are functional and remain up-to-date.

When a service call is placed the Contractor shall acknowledge receipt of that call within thirty minutes and be on-site during normal DOS business hours and outside of normal business hours in accordance with the priority levels enumerated in the table below. Normal business hours are defined as 07:30 am to 4:30 pm EST, Monday through Friday including all designated federal holidays. The Contractor shall employ a trouble ticket system for logging, tracking, and retaining the history of all service calls.

The Contractor shall perform the following maintenance tasks in support of the PTL program:

· Monitor and maintain comprehensive awareness of system health and status.

· Performing routine and preventative maintenance of all hardware associated with the PTL system consistent with reasonable commercial practices for systems of its type.

· Update all software and operating system versions, security patches, software upgrades and patches; hardware fixes and upgrades; virus signatures, and other maintenance activities for software components used in the PTL system.

· Adhere to the Contingency Plan (i.e., included in the Quality Control Plan), and the defined response protocols, and systematic procedural checklists for rapidly assessing and resolving problems.

C.7.1 Scheduled System Outages

The Contractor shall provide a written notice to the COR one (1) week in advance of all planned or required system maintenance activities that require a PTL systems outage. The Contractor shall ensure that planned system outages do not conflict with critical DOS activities or are performed during times when there is a traditional high level of user activity. The Contractor shall provide the required Incident Report within 24 hours for schedule outage.

C.7.2 Unscheduled System Outages

In the event of an unplanned outage, or component failure the Contractor. upon arriving on-site, shall immediately ensure that the systems automatically switched over to the redundant backup system and the failure is transparent to the end-users. The Contractor shall then assess the extent and cause for the outage and provide an estimated time to restore the failed system to full operation. The Contractor shall provide the required Incident Report within 15 minutes of unscheduled outage.

C.7.3 Development Cycles and Modernization Updates (Critical Gap)

The Contractor shall provide regular development cycles. These cycles shall include bug-fixes, software/server patches, implementation of future (minor) core requirements, and future (minor) built-in web viewer requirements and shall occur at least every 90 days or sooner if deemed necessary by the COR. Updates shall also include modernization updates as part of the regular development cycles. These modernization updates shall include updating the PTL Systems and built-in web viewer such that it can be viewed properly in DOS-approved web browsers. Updates shall be tested on the Test Server in a test domain prior to updating the Production Server. As part of the update package, Contractor shall provide documentation and technical support 60 days in advance of the anticipated change to meet DOS configuration change management requirements and obtain approval for the change.

C.7.4 System Administration

The Contractor shall provide all database, network, and underlying system administration and configuration services. Daily administration of the system by the government shall be restricted to user management and device administration to include, tracking device management, device communications, and device dissemination for regions of interest.

C.8 ENGINEERING AND TECHNICAL SUPPORT

The Contractor shall assist the DOS in immediately achieving security authorization and certification under NIST 800-37 and 800-53 at the “Medium” level and eventually move the system to the “High” level as required by DOS/IRM.

C.8.1 Software or Architecture Modifications

The PTL Systems consists of COTS products that will act as the server for tracking and locating personnel in regions of interest worldwide. Given that the system consists of COTS products, accredited for other federal agencies, certain modifications to system software and or architecture may be required to finalize DS security standards and information systems accreditations and related C&A testing requirements. The Contractor's support for software and architecture modifications shall be provided through the task order process. See H.9.

C.8.2 Certification and Accreditation (C&A)

The Contractor shall be required to support the DOS C&A process for both the initial PTL systems and for any re-certifications (i.e., entire system or individual elements) resulting from future system updates, upgrades, or modifications.

The PTL Systems shall be capable of immediately obtaining a DOS certification and accreditation (C&A) at a “Medium” level as demonstrated through previous federal certifications and authority to operate. Examples include the Department of Defense DIACAP processes.

The Contractor may be required to assist the DOS in meeting the information assurance requirements at the high level for confidentiality, integrity and availability as defined by the National Institute of Standards and Technology.

The Contractor shall assist in the planning and preparation for the security C&A as part of DOS FIPS 200 and FISMA implementation effort. In coordination with PTL and the DS Chief Technology Officer (CTO), the Contractor shall make changes to ensure that the application can immediately meet security requirements for a ”Medium” system as documented in the National Institute of Standards and Technology, to include but not limited to those specified within NIST Special Publications 800-37 and 800-53. Contractor will coordinate and create any additional security certification and accreditation documentation for the application/solution and assist with any testing requirements.

The Contractor shall provide certification documentation as required above, to meet current NIST requirements for a system categorized as ”medium” for confidentiality, integrity and availability and be prepared to move the system to “High” once directed by the government.

The Contractor shall provide both electronic and hardcopy copies of the documentation that identifies the standards-compliant Application Programming Interface (API) for integration to third-party external viewing applications and systems.

Any modifications in order to meet NIST 800-37 and 800-53 at the “Medium” level shall be identified and submitted for approval to the COR. DS shall not incur costs for complete system redesigns in order to obtain the initial necessary authority to operate tracking system at the system categorization level determined by DOS.

The Contractor shall comply with the following standards in support of this SOW and incorporate them into proposed solution:

a. Comply industry standard quality management practices

b. Comply with AIS Security standards

c. Comply with DOS Standards and Procedures – including all Foreign Affairs Manual (FAM), Department of Defense Acquisition Regulations (DOSARS), and Foreign Affairs Handbook (FAH)

The re-certification support will be an ongoing process to include periodic system updates, upgrades, and modifications that may occur in the life cycle operations of the server. This support includes the following.

· Attending meetings with DS security specialists and those supporting the C&A efforts.

· Identifying protocols that support the C&A efforts.

· Identifying and providing supporting documentation.

· Identifying a security architecture needed to meet C&A requirements for protecting, auditing, and validating safeguards.

The Contractor's support for the new PTL systems C&A and future system re-certifications shall be provided through the task order process. See H.9.

C.8.3 Device Integration

The PTL system shall be device agnostic and capable of ingesting tracking data from multiple device types to expand The DOS tracking device data compatibility portfolio includes commercial interfaces for Iridium devices, Global Star based devices, and cellular devices. The Contractor shall also be free to recommend new devices for integration if the devices use FIPS-approved encryption mechanisms.

The Contractor shall support the PTL systems capability to permit the import of data of future device data into the system using a plug-in architecture. The Contractor shall be required to fully integrate new device data into the PTL system and provide a common operating picture for all deployed devices. The Contractor's support for future device integration shall be provided through the task order process. See Paragraph H.9.

C.9 TRAINING

The Contractor shall provide initial and advanced user training sessions upon twenty-four (24) hour notice from the COR. The sessions shall be conducted for DOS PTL System operators.

C.9.1 Initial User Training

The objective for the initial user training sessions shall be provided to give DOS operators a solid working knowledge and a practical understanding of how to use the PTL Systems interface and functions.