6973GH_19_R_00106_SIR_Phase_I_Attachment_1_SOW.pdf

Statement of Work

FAALC RVSS CENTRALIZED NOC/SOC/CC

For Official Use Only (FOUO)

Federal Aviation Administration U.S. Customs and Border Protection

Remote Video Surveillance System (RVSS)

Centralized

Network Operations Center (NOC)

Security Operations Center (SOC) and

24/7 Call Center (CC)

Published: February 1, 2019

Support Agency:

Federal Aviation Administration (FAA) FAA Logistics Center 6500 S. MacArthur Blvd Oklahoma City, OK 73069

Distribution Statement: Distribution authorized to the U.S. Customs and Border Protection Agency and Federal Aviation Administration Logistics Center and their Contractors. This document contains non-technical data for administrative use. Requests for this document must be referred to FAALC.

FAALC/CBP P a g e | i

FAALC/CBP P a g e | ii

Table of Contents

1.0 Background

2.0 Objectives

3.0 Statement of Work (SOW)

4.0 Program Requirements

4.2.6.2.1 Test Plan

4.2.6.2.2 Test Procedures

4.2.6.2.3 Test Readiness Review

4.2.6.2.4 Quick Look and Final Test Reports

FAALC/CBP P a g e | iii

5.0 Deliverables

6.0 Background Investigation

7.0 Travel

8.0 Government Furnished Equipment (GFE)

9.0 Work Site

Acronyms

Acronyms

List of Figures

Figure 1 – USBP Stations in the Detroit, Buffalo, and Swanton Sectors

Figure 2 – Tucson and Yuma Sectors

Figure 3 – CBP/USBP Stations in the Laredo and Rio Grande Valley Sectors

Figure 4 – CBP Stations in the San Diego Sector

Figure 5 – Future RVSS-Centralized Production NOC/SOC/CC High-Level Network Architecture

Figure 6 – Future RVSS Test NOC/SOC Environment High-Level Network Architecture

List of Tables

Table 1 – NOC/SOC/CC Roles and Responsibilities

Table 2 – Priority Definition and Examples

Table 3 – Priority Responsibilities

Table 4 – Policy Documents

Table 5 – Security Document Requirements for the NOC/SOC/CC System

Table 6 – Verification Methods

Table 7 – CDRLs

FAALC/CBP P a g e | 4

1.0 Background

The Department of Homeland Security (DHS) has comprehensive multi-year plans to secure America’s borders. The Federal Aviation Administration Logistics Center (FAALC) has been designated by the U.S.

Customs and Border Protection (CBP) as the Servicing Agency and independent Government entity with primary inventory control point activity responsibility (with depot-level authority) throughout the life-cycle of many of CBP's border security programs. The FAALC will provide engineering, technical, and logistics services to support CBP in the areas of Integrated Logistics Support (ILS), management consulting, primary inventory control point, provisioning, and repair of CBP equipment.

The FAALC has been requested by the U.S. Border Patrol, Program Management Office Directorate (PMOD), to establish a Remote Video Surveillance System (RVSS) Centralized Network Operations Center/Security Operations Center (NOC/SOC) and 24 hours per day / 7 days per week Call Center (CC) for a number of deployed CBP RVSS and relocatable towers.

These RVSS deployments include: Northern Border Remote Video Surveillance System (NB-RVSS), Maritime Detection Project (MDP), California Coastal Surveillance (CCS), Arizona, and relocatable sites along the Rio Grande Valley (RGV). The NB-RVSS includes the Buffalo Sector and Detroit Sector, and currently, there are plans to include the Swanton Sector. The MDP has locations at Lake Erie and Lake St. Clair; however, this capability will be implemented near-term at Lake Champlain, NY. The CCS focuses on relocatable technologies.

The Southwestern Border (SWB) includes: Yuma and Tucson Sectors in Arizona and a Relocatable Pilot Program in Laredo Sector and Rio Grande Valley (RGV) Sector in Texas.

The centralized NOC/SOC will provide a single point of contact, a CC, that users and operators can use to report, document, track, and resolve system problems.

The United States Border Patrol (USBP) PMOD RVSS program management is responsible for the execution of the Portfolio of RVSS programs, which includes the RVSS Upgrade Program, NB-RVSS Program, MDP, CCS and relocatable pilots. The PMOD is responsible for the successful implementation of a Centralized NOC/SOC/CC capability for the RVSS Portfolio programs.

The priority is to incorporate the NB-RVSS and MDP sites into the RVSS Centralized NOC/SOC/CC, followed by the SWB sites. However, the NOC/SOC/CC capability must be scalable to accommodate the implementation of many other Areas of Responsibility (AOR) and emerging technologies in the future as they come on line.

The RVSS consists of three subsystems: sensor subsystem, communication subsystem, and the Command and Control (C2) subsystem. RVSS sensors are a collection of video and support equipment mounted on fixed or relocatable infrastructure along the US border. These sensors can include Electro- Optical and Infrared (EO/IR) video cameras, a laser illuminator, and other support equipment depending upon the specific site (e.g., spotlight, loud hailer).

The RVSS sensors transmit the surveillance video to the C2 center via a communications subsystem where the video is available for monitoring, storing, and archiving by USBP.

At this time, there are two distinct and different technology implementations for RVSS: one for the NB AORs and another for the AORs in Arizona and relocatable RVSS sites. Additional AORs are anticipated, but not yet defined.

FAALC/CBP P a g e | 5

There will be additional different technology implementations for the relocatable coastal deployments.

However, from a NOC/SOC/CC monitoring perspective, all implementations use Internet Protocol (IP) based devices with varying support for Simple Network Management Protocol (SNMP).

1.1 NB-RVSS AORs and MDP Sites

The three NB-RVSS AORs, as shown in Figure 1, consist of three CBP sectors: Swanton, Buffalo, and Detroit. Each sector has its own C2 with varying number of RVSS that communicate with the C2. The Video Management System (VMS) and sensor control system at Buffalo and Detroit is currently Qognify and Boeing’s Visual Security Operations Console (VSOC) respectively, however there is a planned transition to Sensor Management System / Joint Perimeter Surveillance Command and Control System (SMS/JPSC2) supported by Space and Naval Warfare Systems Command (SPAWAR).

Swanton will be on SMS/JPSC2.

The microwave backhaul in the communication subsystem is Harris Corporation equipment. The RVSS at the Swanton sector is currently in the planning phase, while the RVSS Buffalo and Detroit deployments have long been established and baselined. The current NOC/SOC/CC provider for Buffalo and Detroit RVSS sites does have a network connection into the respective C2s. The network connection is Secure Border Initiative Network (SBInet), which is an extranet into DHS controlled by DHS OneNet. DHS OneNet is a Multiprotocol Label Switching (MPLS) encrypted network.

The NB-RVSS sites are comprised of two camera sets with long range EO/IR cameras. Each camera set is controlled by a Pan/Tilt Unit (PTU) that provides 360º horizontal coverage and 180º vertical coverage. The four cameras (per RVSS site) provide standard definition video at 30 fps to the C2 using a microwave and/or fiber-optic connection.

In addition to the NB-RVSS sites, MDP is a technology demonstration project to determine if Commercial-off-the-Shelf (COTS) radar and one set of long range cameras (EO/IR) will meet USBP requirements for detecting Surface Targets of Interest (SToI) during day and night operations while providing a common display of SToI data in near real time to a C2 system at Sector Headquarters (HQs).

The Area of Interest (AOI) in USBP Buffalo Sector is the eastern end of Lake Erie. The AOI in USBP Detroit Sector are Lake Saint Clair and the western end of Lake Erie. The requirement exists to expand MDP to all of Lake Erie and Lake Ontario.

The MDP system uses the same camera suite (one set) as NB-RVSS. MDP Buffalo sites are equipped with the Kelvin Hughes SBS-900-2 SharpEye X-Band radar. Radar Distribution Unit, Master PC-RP and SSR radar processor. The Detroit Gull Island site is equipped with the Vista Research, Inc (VRI) MRP- F50 consists of the VRI Maritime Radar Processor (MRP), VRI Radar Control Unit (RCU) integrated into a Furuno FAR-2157 (50kW) Scanner Unit (RSB-106);. The Swanton Derringer site consists of the Furuno FAR-2127 marine radar, Accipter Radar Remote Controller (RRC), Digital Radar Processor (DRP) and a Radar Data Manager (RDM). Buffalo MDP sites also have additional sensors to detect intrusion, fire, flooding, and temperature variance in the shelter using the EnviroMux sensor system.

All sites are connected to grid power and have either a battery backup system or are connected to a backup generator. Cameras, routers, switches, power systems, and microwaves are monitored and resettable by the existing NOC/SOC.

FAALC/CBP P a g e | 6

Figure 1 – USBP Stations in the Detroit, Buffalo, and Swanton Sectors

1.1.1 Buffalo Sector

The Buffalo sector consists of the following:

1) A C2 facility with six operator workstations (four NB-RVSS and two MDP) in Grand Island, NY are displayed on an Extron video wall

2) Five RVSS towers (location names BUN-001, BUN-005, BUN-006, BUN-008, BUN-010)

3) Two microwave relay towers (locations Headquarters (HQ), BUN-035)

4) Three MDP towers (locations BUN-011 and BUN-013, BUN-012 under construction)

5) Buffalo Police Department Radar site (MDP network router only, pending integration with

MDP)

6) Four RVSS legacy towers (future)

7) Planned MDP site (location DTM-016) on Lake Erie

1.1.2 Detroit Sector

The Detroit sector consists of the following:

1) A C2 facility with seven operator workstations in the Northern Border Coordination Center (NBCC) at Selfridge Air National Guard Base, MI displayed on an Activu video wall

2) One planned operator workstation at Detroit Station

3) One planned operator workstation at Marysville Station

4) 13 RVSS towers (locations DTM-002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 013B, 014, and 015)

5) One MDP site (Vista radar at Gull Island collocated with DTM-011)

6) A planned MDP site (location DTM-016) (future)

FAALC/CBP P a g e | 7

1.1.3 Swanton Sector

The Swanton sector consists of the following:

1) A C2 facility at HQ with one operator workstation (under construction)

2) One operator workstation at Ogdensburg Border Patrol Station (under construction)

3) Up to four RVSS towers (future)

4) MDP Deringer site (transition in process)

5) Two DHS Science and Technology (S&T) Slash monitoring sites (transition in process)

1.2 Arizona AORs

CBP implemented a comprehensive multi-year plan to acquire, field, test, and sustain layered technical capabilities to achieve improved situational awareness along the U.S. border. As a part of the assignment, USBP has deployed an upgrade of the existing RVSS in Arizona (Yuma and Tucson Sectors), as shown in Figure 2. This project is identified as the RVSS Upgrade (RVSS-U) Program.

The five Arizona AORs are at Nogales, Naco, Douglas, Yuma, and Papago Farms Forward Operating Base (FOB) at Ajo. Each AOR has its own C2 with varying number of RVSS that communicate with the C2. The VMS and sensor control system is PureActiv by PureTech Systems. The microwave backhaul in the communication subsystem is DragonWave equipment.

All five AORs have been established and in varying states of being baselined. The current NOC/SOC/CC provider for five AORs is a localized NOC/SOC implementation (i.e., there is not a DHS OneNet network connection.) The current NOC/SOC provider has a localized NOC/SOC implementation per AOR that consists of a NOC workstation and a SOC workstation with a division of NOC/SOC responsibilities. There is a centralized Customer Care Center (CCC) that covers all the RVSS-U deployment AORs.

Figure 2 – Tucson and Yuma Sectors

FAALC/CBP P a g e | 8

1.2.1 Yuma Sector

The Yuma sector consists of the following:

1) A C2 facility at the Yuma station with 19 sensor and one relay RVSS towers (locations YUS- 0026, 0023, 0573, 0571, 0535, 0019, 0018, 0022, 0021, 0020, 0014, 0533, 0011, 0010, 0012, 0013, 0577, 0575, 0539, and 0543)

1.2.2 Tucson Sector

The Tucson sector consists of the following:

1) A C2 facility at the Ajo station with one RVSS tower (location AJO-005)

2) A C2 facility at the Douglas station with 12 RVSS towers (locations DGL-0003, 0004, 0005, 0006, 0007, 0008, 0009, 0010, 0012, 0014, 0557, and 0565)

3) A C2 facility at the Naco station with 18 sensor RVSS towers (locations NCO-0003, 0004, 0005, 0006, 0008, 0008, 0009, 0010, 0011, 0012, 0013, 0014, 0015, 0016, 0017, 0525, 0529, and 0567)

4) A C2 facility at the Nogales station with 16 sensor and one relay RVSS towers (locations NGL-0006, 0007, 0008, 0009, 0010, 0011, 0014, 0012, 0013, 0015, 0016, 0017, 0505, 0507, 0509, 0511, and 0555)

1.3 Relocatable Tower Pilot AORs

The relocatable towers have recently been deployed. The two pilot deployments are using relocatable towers at USBP stations at RGV Sector (McAllen, TX and Weslaco, TX) and Laredo Sector (Laredo, TX), as shown in Figure 3. The total number of relocatable towers will grow significantly and are planned to be deployed throughout RGV and Laredo Sectors. The RVSS-U technology in the RGV, as well as the VMS and sensor control system will be the same as the Arizona AORs. The current NOC/SOC provider has a localized NOC/SOC implementation per AOR that consists of a NOC workstation and a SOC workstation with a division of NOC/SOC responsibilities (i.e., there is not a DHS OneNet network connection.) There is a centralized CCC between the AORs.

FAALC/CBP P a g e | 9

Figure 3 – CBP/USBP Stations in the Laredo and Rio Grande Valley Sectors

1.3.1 Laredo Sector

The Laredo Sector contains the following:

1) A C2 in Laredo West, TX with five sensor and two relay towers

1.3.2 Rio Grande Valley Sector

The Rio Grande Valley sector contains the following:

1) A C2 in McAllen, TX with five sensor and two relay towers

2) A C2 in Rio Grande City, TX with at least 5 towers

3) A C2 Weslaco, TX with at least 3 towers

1.4 California Coastal AORs

In the CCS project, there is an initial planned deployment of several Relocatable Surveillance Systems-Maritime (RSS-M) in the San Diego Sector, as shown in Figure 4.

The CCS project is a technology demonstration to determine the performance and effectiveness of an integrated, land based RSS-M against a quickly evolving maritime threat, and to explore various aspects of technology in meeting the requirement.

The specific area of interest for this demonstration is the California Coastal Region.

The objective of this technology demonstration is to assess the capabilities (e.g. effective range, detection performance, camera performance, and multimodal communications) of today’s technologies, in the varied and challenging topography of the California Coastal Region.

Rather than deploy fixed surveillance towers, this technology demonstration is meant to assess the ability to relocate systems to respond to shifting threats.

The demonstration will deploy up to ten RSS-Ms, to be distributed among the available sites and relocated as needed. The CCS will be deployed along the California coast in USBP San Diego Sector.

The CCS RSS-M towers are currently in development for use in San Diego Sector along the California coast line; with an estimated deployment in 2019.

The CCS system will employ relocatable towers, which will be connected to the DHS OneNet using long-term evolution (LTE) cellular, satellite communications, and/or direct internet connections.

Alternative energy will be used to power the towers for 30 days of continuous operations when not connected to grid power (i.e., solar, generator, etc.).

A fixed long range surveillance radar will also be installed on San Clemente Island, CA and connected via fiber-optic service. Cameras, routers, switches, power systems, and communications systems will be monitored and resettable by the NOC/SOC.

RSS-M is envisioned to be equipped with a global positioning satellite (GPS) location monitoring system.

FAALC/CBP P a g e | 10

Figure 4 – CBP Stations in the San Diego Sector

1.4.1 San Diego Sector

The San Diego sector consists of the following:

1) Data center at the Air and Marine Operation Center (AMOC) in Riverside, CA

2) Up to three operator workstations at the United States Coast Guard (USCG) Joint Harbor Operation Center (JHOC) in the San Diego C2 facility

3) Three operator workstations at the Maritime Command Center (MCC) in the Long Beach C2 facility

4) Up to four CCS relocatable sensor systems

5) One long range radar site at San Clemente Island, CA

2.0 Objectives

The overall objective of this requirement is the replacement of the existing NOC/SOC/CC capability for the existing and planned RVSS sites with a Contractor Owned and Contractor Operated (COCO) facility that will be provided by the selected Contractor delivering a cost savings to CBP, increased visibility, and improved metrics reporting.

The RVSS Centralized NOC/SOC/CC is an effort to consolidate various RVSS NOC/SOC and CCC capabilities into one centralized location.

It is envisioned that this effort will eventually provide a single NOC/SOC/CC for all RVSS locations. The initial effort will address the NB-RVSS, MDP, Arizona RVSS, CCS, and relocatable RVSS sites. However, additional sites may be identified and eventually brought into this acquisition.

FAALC/CBP P a g e | 11

The solution will include the supplied and staffed centralized NOC/SOC/CC, operating 24 hours per day, 7 days per week, 365 days per year (24x7x365) and monitoring USBP border security surveillance systems in order to maintain system mission readiness and Operational Availability (Ao).

The Contractor supplied fully managed NOC/SOC/CC solution should be networked to the RVSS sites via DHS OneNet.

Contractor supplied NOC/SOC/CC should be highly scalable, for a phased deployment across the NB- RVSS, MDP, Arizona RVSS-U sites, Laredo and RGV AORs, and potentially additional existing RVSS legacy sites, as well as planned additional RVSS and relocatable deployments along the southern California coastline.

The scalability of the solution should include the possibility of expanding the NOC/SOC/CC support to additional USBP programs and deployed security systems. There will be separate Contract Line Item Numbers (CLINs) per AOR.

The NOC/SOC/CC will deliver Information Technology (IT) management and security services to the RVSS system. All functions of the NOC/SOC/CC will be oriented towards maintaining and securing the systems, the network, and the overall IT infrastructure.

The NOC/SOC/CC will perform a wide variety of functions for CBP’s border security systems, including monitoring, diagnosing incidents, resolving incidents up to and including a Tier 2 (reference §3.4.1) capacity, and managing alerts.

The NOC/SOC/CC will capture data used to calculate availability and performance metrics regarding all aspects of provided services. The NOC/SOC/CC will be required to monitor network attached border security systems and scan all systems for vulnerabilities so that CBP can maintain a consistent security posture across the AOR.

In addition, the NOC/SOC/CC will be an essential stakeholder in all system enhancements and the deployment of modernizations and innovations in border security technology.

The CC will provide Tier 1 and Tier 2 support (reference §3.4.1) and coordinate with NOC/SOC and CBP Field Service Representatives (FSR) to resolve and document incidents. The NOC/SOC/CC will also work with FSRs to resolve incidents that are detected by the NOC/SOC/CC monitoring system.

When necessary, the NOC/SOC/CC will need to work with the CBP designated In-Service Management Authority/Software Support Authority (ISMA/SSA) that supports the RVSS deployments.

A separate stand-alone test NOC/SOC instance will also need to connect to an existing and future RVSS test beds (which will be maintained by the ISMA/SSA) over a secure commercial Internet Service Provider (ISP) network connection (i.e., this will not be on DHS OneNet).

The test NOC/SOC instance must replicate the production NOC/SOC instance to the extent needed to support testing of security patches and Contractor software updates.

3.0 Statement of Work (SOW)

The Contractor must furnish all professional, technical and support labor, materials, supplies, management services, data, facilities, and transportation required to perform all requirements set forth within this SOW.

Work considered inherently governmental will not be assigned to the Contractor.

FAALC/CBP P a g e | 12

The Contractor must perform the services identified in this SOW with minimal assistance from Government personnel. Work will include, but not be limited to, the following:

Establish and maintain a COCO NOC/SOC/CC, staffed at appropriate levels

Monitor the RVSS stations and relocatable towers to ensure their availability, integrity, and confidentiality commensurate with associated risk

Interface with CBP personnel and systems to track and resolve incidents

Perform DHS/Federal Information Security Management Act (FISMA) required operational management, reviews, analysis, and reporting

3.1 Roles and Responsibilities

The NOC/SOC/CC roles and responsibilities are described in Table 1.

The NOC provides a 24x7x365 management capability for monitoring the health and status of CBP RVSS and for performing maintenance actions. The NOC provides system monitoring, health and status reporting, and security services for all CBP deployed RVSS.

The SOC provides a 24x7x365 security management capability for monitoring system conformance to DHS Security policy. Security monitoring includes monitoring and analysis of network traffic, intrusion detection through the inclusion of Intrusion Detection Systems (IDS), and security event incident response logging.

Additionally, it includes conducting and tracking security events, composing and distributing security alert notifications, and preemptive measures such as centralized logging, virus protection, and system hardening.

The CC provides a single point of contact that users and operators can use to report, document, track, and resolve system problems and account issues.

The CC also handles system change requests to the system as well as to personal accounts and associated access privileges.

The CC will use the Government provided trouble ticket system (currently Maximo but transitioning to BOSEC) in order to track, respond to, and report on user-reported issues.

The scope of this SOW also requires that the Contractor assist with the transition support from the current NOC/SOC/CC provider to the Contractor’s solution (as described in section 4.1.6).

FAALC/CBP P a g e | 13

Table 1 – NOC/SOC/CC Roles and Responsibilities

Roles and Responsibilities NOC SOC CC

Receives calls / opens trouble tickets X

Lead Tier I troubleshooting via CC Knowledge Base X

Lead Tier 2 troubleshooting and maintaining of Desktop Instructions (DIs) X X

Updates incident tickets for root cause analysis and corrective action(s) X X X

Escalate / communicate issues as defined by policies and escalation procedures X X X

Close incident tickets X

Administer user system access and permission X

Respond to password reset requests during normal business hours X

Support requests from local operations supervisor X

Manage and perform incremental and full backups X

Perform triage, solving straightforward network problems utilizing appropriate tools

X

Perform triage, solving straightforward system problems utilizing appropriate tools X

Resolution of false positives and nuisance alarms via event management tool(s) X X

Monitor network configuration and status X

Monitor system configuration and status including servers, operating systems, and software applications

X

Administer and monitor system availability and performance Tools X

Document and further escalate issues as needed X

Maintain system configuration (product/operational baseline) X X

Test patches and configuration changes (Hardware (HW) and Software (SW) updates) in a separate test environment

X X

Implement security patches and configuration changes (HW and SW updates) X

Implement non-security software updates to network hardware X

Creates shift logs X X

Logs incidents and requests X

Monitors events and alarms related to network operational status X

Monitors events and alarms related to system security posture X

Security incident response and reporting X

Performs forensic investigation for security events/incidents X

FAALC/CBP P a g e | 14

3.2 High-Level Network Architecture

3.2.1 Future Network Connections for the Production NOC/SOC/CC Environment

Figure 5 – Future RVSS-Centralized Production NOC/SOC/CC High-Level Network Architecture

Figure 5 provides a future, desired end-state high-level network architecture for the Contractor’s centralized networked production NOC/SOC/CC environment (or instance) and it depicts the network connections between the production NOC/SOC/CC environment and the RVSS C2 sites.

All the hardware supporting the DHS OneNet network connections, including any Customer Edge (CE) routers at the Contractor site, will be Government Furnished Equipment (GFE). This is expected to be a Cisco ISR 4451 router.

The Government will provide access and establish the DHS OneNet network connections.

The Contractor is responsible for providing secure space to house DHS OneNet equipment and connecting Contractor equipment to the DHS OneNet network connections.

The area in Figure 5 labeled “Centralized NOC/SOC/CC” provides network and security services including user management, vulnerability monitoring and remediation, system availability reporting, health and status reporting, bandwidth analysis, and issue troubleshooting.

The “DHS and CBP Internal Resources” provides internal CBP system assets including email, shared drives, and internal facing websites.

FAALC/CBP P a g e | 15

The DHS Public Key Infrastructure (PKI) Certificate Revocation List (CRL) uniform resource locator (URL) “DHS PKI CRL Server/URL” is the web address used to conduct Personal Identification Verification (PIV) card authentication requests.

In Figure 5, the Point-to-Point dedicated circuit connection (Red Line) are the RVSSU/NB-RVSS AOR Local Area Networks. These sites communicate with the centralized NOC/SOC/CC through a Point-to-Point connection.

The connection is used to send network and security status data to the centralized NOC/SOC/CC including high-definition streaming video at 30 frames per second which is required for system troubleshooting and display issues.

At times this information can be mission critical affecting the USBP Agent safety and well-being.

The DHS OneNet Connection (Blue Line) is the Centralized NOC/SOC/CC network connection to DHS and CBP Internal Resources using a DHS OneNet connection.

This connection is used to transfer Sensitive but Unclassified For Official Use Only (FOUO) and Law Enforcement Sensitive (LES) data, send CBP email including monthly system scan data transmission to Office of Information Technology (OIT), and access DHS internal servers and websites.

Within the DHS and CBP Internal Resources lies the PKI CRL Server which authenticates user workstations at both the AORs and Centralized NOC/SOC/CC. For authentication from RVSS Local Area Network (LAN) sites, the request is routed from the AOR via the Point-to-Point connection to the Centralized NOC/SOC then to the PKI CRL server to via the DHS OneNet Connection to complete the request.

3.2.2 Future Network Connections for the Test NOC/SOC Environment

Test environments will be air gapped from DHS OneNet connections. To test the deployment of pushing patches and software upgrades to the AORs, there is a requirement to first conduct these activities in a test environment. To facilitate this requirement, a network connection is required between the Contractor’s test NOC/SOC environment and the various RVSS test beds.

Figure 6 provides a future, desired end-state high-level network architecture for the Contractor’s test NOC/SOC environment (or instance) and it depicts the network connections required between the test NOC/SOC environment and the various RVSS test beds.

The Contractor is responsible for the maintenance and staffing of the test NOC/SOC environment while the ISMA/SSA will be responsible for the maintenance and staffing of the RVSS test beds.

These network circuits will not be on DHS OneNet due to the fact that the test bed environments do not go through the CBP Authority to Operate (ATO) process, which is a requirement for DHS OneNet. Instead, they will be networked via a commercial ISP.

All the hardware supporting the network connections, including any CE routers at the Contractor site, will be GFE.

The Government is responsible for establishing commercial ISP network connections, with involvement from the Contractor in achieving connectivity.

FAALC/CBP P a g e | 16

Figure 6 – Future RVSS Test NOC/SOC Environment High-Level Network Architecture

3.3 Configuration and Asset Management

The Contractor will be responsible for their own Configuration Management (CM) and associated CM processes and procedures (e.g., maintaining the Functional, Allocated, and Product baselines (PBL) of the Contractors NOC/SOC systems) as well as executing the five traditional capabilities of CM which are as follows:

1) Planning

2) Configuration Identification

3) Configuration Change Management

4) Configuration Status Accounting (CSA)

5) Configuration Verification and Audit

The Government uses MIL-HDBK-61A (Military CM Handbook) for CM guidance and recommends that the Contractor use the same or GEIA-HB-649 (and associated EIA-649-B standard).

FAALC/CBP P a g e | 17

3.3.1 Configuration Change Management

The definition of major and minor changes can be found in MIL-HDBK-61A Table 6.2. The definition of a Class 1 and Class 2 changes can be found in EIA-649-B Table 4.

For changes to the Contractor’s configuration documentation in an Allocated or PBLs that meets the criteria for major changes (Class I) the Contractor must notify the Government. The form of notification from the Contractor to the Government of a major change (Class I) is left to the discretion of the Contractor.

For changes to the Contractor’s configuration documentation in the Allocated or PBLs that meets the criteria for minor changes (Class II), the changes are adjudicated by the Contractor with Government concurrence to the change classification.

The Contractor’s PBL must be described in a Version Description Document (VDD), a Network Description Document (NDD), and a System Description Document (SDD), see CDRLs 10-12 respectively. The Contractor’s must also provide a baseline Technical Data Package (TDP), see CDRL 19, to support a Physical Configuration Audit (PCA).

For any major (Class I) and minor (Class II) changes to the Contractor’s PBLs that effect these delivered documents, the Contractor will generate a document revision and re-deliver to the Government.

The Contractor must submit to the Government a Request for Variance (RFV) for a proposed departure from functional or non-functional requirements as specified in the RVSS Centralized NOC/SOC/CC Functional Requirements Document (FRD), Document Control Number (DCN)

ENT15-NOCSOC-00-000001.

3.4 NOC/SOC/CC Standard Operating Procedures

The Contractor must create a NOC/SOC/CC Standard Operating Procedures (SOP) in accordance with (IAW) the associated Contract Data Requirements List (CDRL) / Data Item Description (DID).

The troubleshooting DI for the NB AORs as well as for the SWB AORs will be initially supplied to the Contractor, however the Contractor must maintain these documents. The Contractor must develop and deliver the DI for the California Coastal AOR.

The CC service desk must be staffed 24x7x365.

The RVSS owner will inform the NOC/SOC/CC and Integrated Logistics Center (ILS) / sustainment Preventative Maintenance (PM) of all planned system outages (full and partial) at least five days prior to an outage commencement. The RVSS owner will inform the NOC/SOC/CC and ILS/sustainment PM of all unplanned system outages (full and partial) within one hour of an outage commencement.

3.4.1 NOC/SOC/CC Support / Troubleshooting

All incident resolutions must be entered in Integrated Logistics Support System (ILSS) Maximo and is tracked for the purposes of reporting Ao. Incidents will be assigned a Priority 1 – 3.

See Tables 3 and 4 for Priority Definition and Examples and Priority Responsibilities.

Priority 1 is a failure of the system’s primary function and/or any safety related issue. Priority 1 failures are all counted as system failures/downtime in the Ao calculation.

FAALC/CBP P a g e | 18

Priority 2 is a partial failure or degradation of primary system functions that impact primary functionality but mission operations are achievable with alternative methods. Priority 2 failures may escalate to a Priority 1.

Priority 2 failures do not affect the Ao unless they induce a Priority 1 failure. For instance, if the Priority 2 corrective action requires a repair activity that takes the system down then a child ticket is created as a Priority 1 to account for the downtime.

Priority 3 failures cause minimal degradation to the system operations. Priority 3 failures do not affect the Ao.

The CC provides Tier 1 support. The CC will receive the initial contact from system users and will create a service request in the designated tool (e.g. ILSS Maximo).

Tier 1 support is also preemptive/triage and the CC takes direct action to resolve system and network issue within standard operating procedures.

If the issue is resolved, CC will update the service request with details of the reported incident and the resolution.

If the incident is not resolved, the CC will create a work order in in ILSS Maximo which will escalate the incident to Tier 2 support.

The NOC/SOC/CC and supporting organizations such as FSR and ISMA are Tier 2 support and tasked to resolve the incident and update the work order.

FSR and ISMA support is governed by their Service Level Agreements (SLAs).

Tier 2 is responsible for requesting Tier 3 support (system Contractor support) through ILSS Maximo, if they need Contractor assistance to resolve the issue.

Resolution by Tier 2, or above must be reported to Tier 1 for ticket closure.

FAALC/CBP P a g e | 19

Table 2 – Priority Definition and Examples

Priority Definition Example

P1

Failure of system's primary functions and/or any safety related issues

Counted as system failures/downtime in Ao calculations

Any failure of a mission critical sensor or PTU (day or infrared cameras)

Failure of a communications package impacting the ability of the user to receive sensor data, or cause a degradation of sensor controls

Failure of a Ethernet data acquisition (DAQ), VMS, data collection system (DCS), assess control system (ACS), safety critical real-time systems (SCS), or any system degradation that inhibits users from achieving mission operations

Loss of multiple C2 user workstations; no less than 75% of user workstations must be operational at any given time in each AOR

Failure of the SOC workstation or security functions

Loss of operational use of more than one Secondary Display Monitor per Secondary Display Server. Exceptions may include AORs with only 6 or less monitors (e.g. Ajo Papago Farms) where loss of one display would be considered a P1 failure

Any condition preventing a C2 user from logging into or using a workstation

P2

Partial failure or degradation of primary system functions that impact primary functionality; mission operations achievable with alternative methods

Any failure that does not immediately cause loss of sensor data to the operator

Is not counted as system failures/downtime in the Ao calculations unless a child ticket is created to account for P1 time

Loss of a generator as a sensor tower that has backup power system available and functioning

Loss of a single screen at an individual Human Machine Interface (HMI) workstation with the two other screens still being available

Loss of a laser illuminator

P3

Failure causes minimal degradation to system operations

Issue results in degraded operations of minor functionality or where a workaround is available to enable operations to continue

Is not counted as system failures/downtime in the Ao calculations

Loss of a single Secondary Display Monitor

Loss of a joy stick capability

FAALC/CBP P a g e | 20

Table 3 – Priority Responsibilities

Priority Responsibilities

CC NOC/SOC

P1

Incident ticket creation Lead Tier I troubleshooting Incident updates for root cause analysis or corrective actions

Escalation to NOC/SOC or FSR, as required

Incident ticket closure Weekday:

Within 12 hours of

Incident ticket creation Evening/Weekend/Holiday:

Within 12 hours of

Incident ticket creation

Initial identification of problem if alarm triggered through event management tool

Contact with CC for ticket creation Lead Tier II troubleshooting, as required Resolution of false positives and nuisance alarms via event management tool Resolution and closure of the ticket, if not escalate to Tier III

Weekday:

Within 12 hours of Incident ticket creation

Evening/Weekend/Holiday:

Within 12 hours of Incident ticket creation

P2

Incident ticket creation Lead Tier I troubleshooting Incident updates for root cause analysis or corrective actions

Escalation to NOC/SOC or FSR, as required

Incident ticket closure Weekday:

Within 24 hours of

Incident ticket creation Evening/Weekend/Holiday:

Within 24 hours of

Incident ticket creation

Initial identification of problem if alarm triggered through event management tool

Contact with CC for ticket creation Lead Tier II troubleshooting, as required Resolution of false positives and nuisance alarms via event

Within 24 hours of Incident ticket creation

Within 24 hours of Incident ticket creation

P3

Incident ticket creation Lead Tier I troubleshooting Incident updates for root cause analysis or corrective actions

Escalation to NOC/SOC or FSR, as required

Incident ticket closure Weekday:

Within 48 hours of

Incident ticket creation Evening/Weekend/Holiday:

Within 48 hours of

Incident ticket creation

Initial identification of problem if alarm triggered through event management tool

Contact with CC for ticket creation Lead Tier II troubleshooting, as required Resolution of false positives and nuisance alarms via event

Within 48 hours of Incident ticket creation

Within 48 hours of Incident ticket creation

FAALC/CBP P a g e | 21

4.0 Program Requirements

4.1 Program Management Requirements

The Contractor must be responsible for the execution and management of the requirements identified within the SOW.

4.1.1 Project Management Plan

The Contractor must produce a Project Management Plan (PMP) plan for each major initiative being supported (e.g., for each AOR). The plan will include a project management sheet identifying related tasks, critical path, transition-in plan and proposed start and completion timeframes.

The Contractor must get approval from the CO before starting the work. The Contractor must also provide an Integrated Master Schedule (IMS) identifying tasks, durations, start and finish dates, predecessors and successors, and ownership.

4.1.2 Monthly Program Management Report

The Contractor must submit a monthly Program Management Report (PMR). The report will be submitted to the COR, or to the appointed FAA Project Manager. The reports highlight the work performance and related activities accomplished during the month to and the planned/expected activities for the following month.

The report must also include any exceptions or deviations from the planned activities as well as the following:

Activity summary

Major milestones

Open Action Items

Program risks and response/actions to be taken to reduce/eliminate risks

Schedule performance to IMS with variance analysis and impact

Status of baseline changes

Non-conformance and resolutions

4.1.3 Automated Reports

The Contractor must provide, as requested, a series of automated reports that have been generated via the tracking systems. These reports include CC reports, NOC/SOC alarms and defect reports, NOC/SOC Activity Report, executive dashboard and associated metrics, and other project reports which can be extracted from the implemented tracking systems.

4.1.4 Basic Monthly Financial Report

The Contractor must provide a basic monthly financial report (i.e., CDRL 006).

4.1.5 Annual Program Review

The Contractor must host an annual program review at the Contractor’s facility.

FAALC/CBP P a g e | 22

4.1.6 Transition Out Plan

Near the conclusion of the contract, the Contractor must deliver a draft Centralized NOC/SOC/CC Services Transition Out Plan stating the plan to transfer Contractor support services to Government support organization for each AOR (see associated CDRL / DID). The Centralized NOC/SOC/CC Services Transition Out Plan must cover all initial AORs and subsequent AORs as the options are exercised.

The transition plan must reflect a strategy for a seamless transition from the Contractor to the Government and continue to sustain the deployed systems at the optimal operational availability for each AOR.

A joint Contractor and Government meeting must be conducted within fifteen (15) days after each AOR transition is exercised. A Centralized NOC/SOC/CC Services Transition Out Plan must be submitted to the Government NLT thirty (30) calendar days from the conclusion of the meeting for review and approval.

4.2 Service Requirements

4.2.1 Policy Requirements

The NOC/SOC/CC must comply with the following documents (see Table 4).

Table 4 – Policy Documents

# Policy Documents

National Institute of Standards and Technology (NIST) standard 800-53 Security and Privacy Controls for Federal Information Systems and Organizations current version

System Reporting Form Standards for Security Categorization of Federal Information Processing Standards (FIPS 199)

3 DHS Standard 4300 A Sensitive Systems Policy current version

4 DHS Directive (MD 11042.1) FOUO Information" dated January 6, 2005

CBP Security Policy and Procedures Handbook (HB1400-005D), Current version, Volume IV, Chapter 13, FOUO Information

DHS Information Security Policy, identified in MD4300.1, (IT) Systems Security Program and 4300A Sensitive Systems Handbook, current version

7 Section 508 of the Rehabilitation Act: http://www.section508.gov/

8 Code of Federal Regulations (CFR): http://www.gpoaccess.gov/cfr/index.html

9 DHS IT Security Policies (NIST) SP 800-47

10 DHS Information Security Performance Plan (current version)

11 CBP Technical Reference Model (current version)

12 DHS Security Operations Concept of Operation (current version)

13 Federal Risk and Authorization Management Program (FEDRAMP)

14 Federal Information Security Management Act (FISMA)

15 ANSI/ISO/ASQ Q10007 – Quality Management Systems – Guidelines for Configuration Management

FAALC/CBP P a g e | 23

# Policy Documents

16 National Institute of Standards and Technology (NIST) 800-137 Information Security

National Institute of Standards and Technology (NIST) 800-37 Guide for Applying the Risk Management (RM) Framework to Federal Information Systems

18 CBP Directive Operational Materiel Cost Wise Readiness (CWR) Policy and Oversight

19 DOD Reliability, Availability, Maintainability, and Cost Rationale Report Manual

4.2.2 Security Document Requirements

For new users to either the RVSS or the NOC/SOC/CC systems, the user must submit a CBP OA Computer Access Authorization Request (CAAR) form and a DHS CBP Rules of Behavior (RoB) form to the CBP Informational System Security Officer (ISSO) for approval via email. Both forms can be signed digitally using Adobe.

The CBP ISSO will then work with the NOC/SOC/CC operators once approval has been given to obtain the user credentials.

The Contractor must provide their DD-254 (Security Requirements) to the Government prior to accessing or processing production information.

Table 5 contains security document requirements that the Contractor must complete for the NOC/SOC/CC system prior to connection to DHS OneNet.

Table 5 – Security Document Requirements for the NOC/SOC/CC System

Security Requirement Document Comment

System Security Plan (SSP) Contractor Support as required

Security Requirements Traceability Matrix Contractor Support as required

Contingency Plan Contractor Support as required

Contingency Plan Test Contractor Support as required

Input to USBP’s Security Risk Assessment System Contractor support as required

Security Test and Evaluation Plan Contractor Support as required

Security Test and Evaluation Checklist Contractor support as required

Provide any unique Memorandum of Understanding (MOU's)/Memorandum of Agreement (MOA’s)/Interconnection Security Agreement (ISA's)

Contractor support as required

Security Test and Evaluation Network/System Scans using scanning tools compliant with current DHS policy. Currently those tools are NESSUS, Webinspect, and AppDetective

Contractor support as required

Plan of Action & Milestones (POA&Ms) for any identified weaknesses Contractor support is required

Vulnerability Scan Findings/POA&M Remediation Plans Contractor support is required

Security Incident Report Contractor support and interaction is required

FAALC/CBP P a g e | 24

4.2.3 DHS and CBP Enterprise Requirements

The Contractor must support the Government while its solution is incorporated into the DHS and CBP Enterprise Architecture (EA), and the DHS and CBP Technical Reference Model (TRM).

Where feasible, the Contractor must use DHS/CBP approved products, standards, services, and profiles as reflected by the hardware software, application, and infrastructure components of the DHS/CBP TRM/standards profile. The DHS/CBP TRM/standards profile will be updated as technology insertions are accomplished.

The Contractor must support the Government to add all items, currently not in the TRM, into the updated TRM. The Government may decide to provide as GFE/GFI software products that are in the Contractor’s system, and which are in the TRM.

CDRLs for the Version Description Document (VDD), Network Description Document (NDD), and System Description Document (SDD) are used to assess the hardware and software Configuration Items (CIs) against the TRM and the DHS and CBP enterprise requirements.

4.2.4 Requirement Traceability Matrix (RTM) for Functional and Non-Functional Requirements

The RTM for the functional and non-functional requirements are contained in an associated document titled Requirements Traceability Matrix (RTM), Remote Video Surveillance System (RVSS) Centralized Network Operations Center / Security Operations Center (NOC/SOC) and 24/7 Call Center Program, Document Control Number (DCN) USBP-PMO-NOCSOC-00-000001 (current version).

For additional context of the functional and non-functional requirements contained in the RTM, refer to the Functional Requirements Document, Remote Video Surveillance System (RVSS) Centralized Network Operations Center / Security Operations Center (NOC/SOC) and 24/7 Call Center Program, DCN ENT15-NOCSOC-00-000001.

4.2.5 Vulnerability Scans and Remediation Process Requirements

The Contractor must perform monthly scan and associated vulnerability reports on the RVSS network/system devices using scanning tools compliant with current DHS policy. Currently those tools are Nessus, WebInspect, and AppDetective. The Contractor must send the scan files and associated vulnerability reports to the CBP OA Information System Security Officer (ISSO).

The Contractor must perform monthly scans and associated vulnerability reports on the NOC/SOC production environment(s) using scanning tools compliant with current DHS policy.

Currently those tools are NESSUS, WebInspect, and AppDetective. The Contractor must send the scan and associated vulnerability reports files to the CBP OA ISSO.

Once the ISSO reviews the scan files, the Nessus scan files are sent to the CBP OIT Vulnerability Assessment Team (VAT) for review and processing into the Continuum system.

Once the VAT team processes the files and corrects the anomalies, the scan files are sent to DHS for review, processing, and creating the FISMA reports and score cards. The FISMA reports and score cards are utilized to identify system deficiencies that need to addressed.

The CBP OA ISSO retrieves the vulnerability reports from the Continuum system. The vulnerability reports are utilized to identify, document, and create a Plan of Action and Milestones (POA&M) to mitigate any identified findings.

FAALC/CBP P a g e | 25

The Contractor must work with the ISSO and ISMA/SSA to generate remediation plans and create patch files in the test bed environments.

Once the ISMA/SSA successfully tests the patch files, the files are provided to the NOC/SOC for implementation. Patches will be transported from the test environment to the production using CC, Iron Key, or other secure means.

4.2.6 System Design and Requirements Verification

4.2.6.1 System Design

The Contractor must provide a SDD, VDD, and NDD, of the production NOC/SOC environment.

In addition, the Contractor must provide a NOC device monitoring document, per AOR, describing the devices being monitored and their configurations and characteristics (e.g., Simple Network Management Protocol (SNMP) polls and traps, Internet Control Message Protocol (ICMP), etc.). The format of the NOC device monitoring document is the discretion of the Contractor.

4.2.6.2 Requirements Verification

The Contractor must verify all RVSS Centralized NOC/SOC/CC functional requirements using one of the following methodologies (Inspection, Demonstration, Test, or Analysis) identified in the RTM.

The RTM identifies the desired verification method of each requirement. Verification method types used to validate requirements are described in Table 6.

Table 6 – Verification Methods

Method Description

Inspection The visual inspection of equipment and evaluation of drawings/specifications and other pertinent design data and processes that are used to verify conformance with characteristics such as physical, material, part and product marking and workmanship.

Demonstration The performance of operations at the system/sub-system level where visual observations are the primary means of verification that the system meets requirements.

Test

An activity designed to provide data on the functional features and performance characteristics of equipment operations in an operational environment under fully controlled and traceable…