04 Building_Technologies_Technical_Reference_Guide_(BTTRG)_Final_Ver20_June2021.pdf

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-BB96-07630E1521 D6

Building Technologies Technical Reference

Guide

GSA

Version 2.0

REDACTED - FOR EXTERNAL DISTRIBUTION

June 11, 2021

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-BB96-07630E1521D6

Approvals

L'~~~ ,~.

I IS

Associate Chief Information Officer GSA lnfom,ation Technology: Office of Public Buildings lnfonnation Technology Services r-:OocllllgMd bf:

~ 1~~,r Bo Berlas Chief Information Security Officer GSA Information Technology: Office of the Chief Information Security Officer

IAOocu!llgn9d bf:

~~~r Assistant Commissioner Public Buildings Service; Office of Facilities Management

Docullgned by:

.J.NM> ~ i...., ~ m~dei!l>I~rew oung

Assistant Commissioner Public Buildings Service: Office of Design and Construction

~ DocuSlgn9d i.,, ~~Ro rt arter - Associate Administrator Office of Mission Assurance

DocuSlgn Envelope ID: FtC7084C-605t-4EE5-BB96-07630E1521D6

Table of Contents Introduction 7

Chapter 1: Policy/Standards and IT Security 9

1.0 Overview 9

1.1 BMC Systems Roles and Responsibilities 9

1.2 Policies and Requirements for lnteroonnectivity 10

1.2.1 Trusted Internet Connection (TIC) 10

1.2.2 Cellular Connection 11

1.2.3 Govemment Furnished Equipment 11

1.2.4 BMC Device VVhitelisting Process 11

1.3 GSA Network Access to Perform Duties 12

1.3.1 HSPD-12 Credentialing and Systems Privileges 12

1.3.2 Background Investigations 12

1.4 BMC Device and Application Security Assessment Process 12

1.4.1 GSA-IT Security Scanning Process 13

1.4.1.1 Step 1: BMC Pre-Assessment 13

1.4.1.2 Step 2: BMC Device and Supervisory Control Software (SCS) Induction 16

1.4.1.3 Step 3: BMC Assessment 16

1.4.1.4 Step 4: BMC Solution SAR Issuance 18

1.4.1.5 Step 5: BMC Vendor Remediation 18

1.4.1.6 Step 6: BMC Solution Post Assessment 18

1.4.2 Wireless Assessments 19

1.4.3 Encryption 20

1.4.4 Non-Standard Software Review Process (BSN Servers/Consoles) 20

1.5 Building Systems Network (BSN) 20

1.5.1 VVhat is the Building Systems Network (BSN)? 21

1.5.2 BSN Operations and Maintenance Roles and Responsibilities 21

1.5.3 BSN Evolvement and Implementation 22

1.5.3.1 BSN I: ACLs and Dedicated VLANs 22

1.5.3.2 BSN 11: Dynamic Multipoint Virtual Private Network (DMVPN) 22

1.5.3.3. BSN 111: Software-Defined Wide Area Network (SD-WAN) 23

1.5.3.4 BSN IV: Trustsec and Microsegmentation 23

1.5.4 Expected Changes Once the BSN ACL is Applied 24

1.5.5 How to Access Virtual Servers in BSN 25

1'.5.6 BSN Consoles 25

1.5.6.1 How to Obtain a BSN Console 25

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-BB96-07630E1521O6

1.5.6.2 How to Access BSN Consoles 26

1.5.6.3 Installing Software on the Building Console 26

1.5.7 Standard BSN Configurations 26

1.5.8 Using Citrix VOi and BSN Consoles 27

1.5.9 Steps to Integrate Sites onto the BSN from the ENT Domain 27

1.5.9.1 Preparation 27

1.5.9.2 BSN Preparation Meeting/Training 28

1.5.9.3 Citrix VOi Access and Use 28

1.5.9.4 Migration 28

1.6 Incident Response (IR) and Building Recovery (BR) Exercises 28

1.6.1 Incident Response 28

1.6.2 Building Recovery Exercises 28

Chapter2: Network Infrastructure 30

2.0 Overview 30

2.1 Network Roles and Responsibilities 30

2.2 GSA Network and Uptime 31

2.3 Standards for Interoperability 31

2.4 Network Topology 33

2.4.1 Network Design Requirements 33

2.4.2 Sample Network Design Diagrams 34

2.5 Hardware Standards and Policy 35

2.5.1 Requesting a GSA Circuit 36

2.5.2 Requesting Switches and Routers 36

2.5.3 Configuration and Connection of the Switches and the Routers 36

2.5.4 Acceptance of Non-Standard Hardware 36

2.6 BACnet 36

2.6.1 How Does BACnet Make Use of IP Networks? 37

2.6.2 BACnet Key Definitions 37

2.6.3 Implementing BACnet on a Wide Area Network (WAN) 38

2.6.3.1 UDP Port Assignment 39

2.6.3.2 BACnet/Ethemet 39

2.6.3.3 Using a BACnet Broadcast Management Device (BBMD) 39

2.6.3.4 Foreign Device Registration 40

2.6.3.5 BACnet/lP Multicast (B/IP-M) 40

Chapter 3: Cabling and Data Circuit Installation/Upgrade 41

3.0 Overview 41

3.1 Applicable Standards for Cabling Infrastructure 41

3.1.1 Minimum Requirement for Ethernet Cabling 41

DocuSign Envelope ID; F1C7084C-6051-4EE5-BB96-07630E1521D6

3.1.2 Attenuation Limit 41

3.1.3 How are GSA-IT's Cabling Standards Enforced? 41

3.2 Cabling Installation 42

3.2.1 Cabling Installation Roles and Responsibilities 42

3.2.2 General Architecture 42

3.2.3 Cabling Installation Options 42

3.2.4 Cable Installation Support 42

3.3 Data Circuit Installation 42

3.3.1 Data Circuit Installation Roles and Responsibilities 43

3.3.2 Process for Data Circuit Requests and Sites Visits 43

3.3.3 Important Considerations in the Circuit Installation Process 44

Chapter 4: BMC Servers: Standards, Provisioning, Application Installation, Maintenance and Remote Access 45

4.0 Overview 45

4.1 BMC Server Roles and Responsibilities 45

4.2 BMC Server Standards 45

4.2.1 Wny Go Virtual? 45

4.2.2 BMC Server Hardware and Software Specifications 46

4.2.3 BMC Application Requirements 47

4.2.4 Server Security Hardening 47

4.3 BMC Deployment Process 48

4.3.1 Step 1: Submit BMC Server Request Form 48

4.3.2 Step 2: Schedule Server Solutions Meeting with TechOps 48

4.3.3 Step 3: Server Deployment Process 49

4.4 Application Installation and Maintenance Guidelines 49

4.4.1 Installation and Maintenance Roles and Responsibilities 49

4.4.2 Do's and Don'ts for Application Installations 50

4.4.3 Temporary Server Administrator Access Requests and Reboots 50

4.4.4 Approval Authority Table 51

4.4.5 Dedicated Server Support During Installation 51

4.4.6 Copying Files to a Server on the BSN 51

4.4.7 Simple Mail Transfer Protocol (SMTP) Email Server Information 52

4.5 Application Access 52

4.5.1 Methods for Accessing an Application via Web Browser 52

4.5.1.1 How to Request Access to a Web Application 52

4.5.1.2 How to Access a Web Application via Citrix VOi 52

4.5.1.3 How to Access a Web Application via BSN Console 54

4.5.2 Methods for Accessing an Application via RDP to a Server 54

Page4 of 109

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-BB96-D7630E152106

4.5.2.1 How to Request RDP Access to a Server 54

4.5.2.2 How to RDP to a Server via CitrixVDI 54

4.5.2.3 How to RDP to a Server via BSN Consoles 57

4.5.2.4 How to Log Off a Remote Desktop Session on a BMC Server 58

Chapter 5: Technical Support for BMC Systems 59

5.0 Overview 59

5.1 Technical Support Roles and Responsibilities 59

5.2 Server Maintenance and Support 59

5.2.1 Server Monitoring 59

5.2.2 Server Backup Solutions 60

5.2.3 Server Patching 61

5.2.3.1 Planned Maintenance and Outages 61

5.2.3.2 Unplanned Maintenance and Outages 62

5.2.4 Communications for BMC Contacts 63

5.3 BSN Console Maintenance and Support 64

5.3.1 BSN Console Patching 64

5.3.2 BSN Console IT Support 64

5.4 BMC Issues 65

5.4.1 Initial Troubleshooting Steps 65

5.4.2 Different Methods. of Reporting a BMC Issue 66

5.4.2.1 Option 1: Call TechOps 66

5.4.2.2 Option 2: Email TechOps 67

5.4.2.3 Option 3: Call the GSA-IT Service Desk Hotline 67

5.4.2.4 Option 4: Submit a GSA-IT Service Desk Ticket with ServiceNow 67

5.4.2.5 Describing a BMC Issue 68

5.4.3 BMC System Support Workflow 68

5.4.3.1 BMC Application Issue 69

5.4.3.2 Network Issue 69

5.4:3.3 BMC Server Issue 70

5.4.3.4 BSN Console Issue 71

5.4.3.5 Advanced Metering System (AMS) Issue 71

5.4.3.6 Troubleshooting Points of Contact 72

Chapter 6: Advanced Metering System (AMS) 73

6.0 Overview 73

6.1 Advanced Metering System Roles and Responsibilities 73

6.2 AMS Architecture 74

6.3 Standards for Interoperability 75

6.4 New Installations 75

DocuSign Envelope ID: F1C7084C-6051-4EE5-BB96-07630E1521D6

6.5 Support 75

6.5.1 Assistance with Support Form 75

6.5.2 Support Form Questions 76

6.5.3 Post-Support Form Process 77

6.6 Metering Issues 77

6.7 Sample Network Diagram 78

Chapter 7: Physical Access Control System (PACS) 79

7.0 Overview 79

7.1 Physical Access Control Systems Roles and Responsibilities 79

7.2 Security 80

7.3 PACS Architecture and Integration 81

7.4 Project Flow 81

7.5 Support 82

Chapter 8: BMC Procurement: IT Requirements in Scope of Work (SOW) 83

8.0 Overview 83

8.1 Scope of Work Template (BAS Hardware/Software Upgrades) 83

Chapter 9: Best Practices for BMC Systems Project Implementations 91

9.0 Overview 91

9.1 Tips for Running a Successful BMC Project 91

9.2 BMC Checklist for Projects 93

9.2.1 Unitary Controller Configuration: 93

9.2.2 Server/AMS Configuration 94

9.2.3 General Documentation and Deliverables 94

9.2.4 Application Account Administration 94

Appendix _ 96 Appendix A: Contact Information 96 Appendix B: Listing of Reference Policies 96

Appendix C: Change Log 97

DocuSign Envelope ID: F1C7084C-6051-4EES.BB96-07630E1521O6

Introduction The nation's buildings are increasingly relying on Building Monitoring and Control (BMC) systems with embedded communications technology, and many are enabled via the Internet. While the advent of the Internet of Things (loT) allows for ease of use, remote access and data reporting/integration, it can also be easy targets for hackers and those with malicious intent. Attackers can exploit these systems to gain unauthorized access to facilities. These technologies can also be used as an entry point to the traditional infom,ational technology (IT) systems and data which can cause physical destruction of building equipment and expose an organization to significant financial obligations to contain and eradicate malware or recover from a cyber-event. Federal facilities can include courthouses. laboratories and regional office buildings, many ofwhich are part of the nation's critical infrastructure. These facilities contain building control systems (i.e., heating, ventilation and air conditioning) as well as physical access control systems (i.e., electronic card readers and closed-circuit camera systems) that are increasingly being automated and integrated to other information systems or networks and the Internet. As these systems are becoming more integrated, so is their vulnerability to potential cyber-attacks.

As the world has learned from highly visible cybersecurity incidents at many large business organizations and the Office of Personnel.Management (OPM), hacking is a growing trend. The external threats are real enough to raise concems and the GSAdoes notwant to be the next target. Cyber incidents can compromise Personally ldentifrable lnfom,ation (PII) and cause outages related to power, network, or other issues. This will cause major damage to the security infrastructure ofa building and it can also have a long-tem, rippling effect that can go on for many years. Building a platform with emphasis on security and disaster recovery in mind will limit these types of incidents as well as protect the infrastructure, including the building systems, which can be vulnerable to internal orextemal sources.

The Building Technology Services Division (BTSD) was established under GSA-IT as a response to growing cybersecurity concerns related to Building Monitoring Control (BMC) systems. BTSD resides within the Office ofGSA-IT's PBS Public Building IT Services (PB-ITS) and specializes in IT Project Management support for building systems projects that depend on the GSA network or require remote connectivity. This includes new capital projects, system migrations and system upgrade projects. Additionally, BTSD creates standards, procedures, and provides guidance and resources for buildings located across the eleven PBS regions. BTSD is at the forefront of assessing and managing risk posed by hardware and software components of BMC systems and works closely with IT Security to facilitate the assessment process. BTSD also supports network integration activities related to loT technologies. BTSD serves in a cross-functional role, collaborating across multiple groups and organizations including:

• Office of Chief lnfomiation Officer (OCIO)/GSA-IT

• Office of Facilities Management (OFM): Smart Buildings Program, Energy Program Division, GSA Proving Ground (GPG)

• Office of Federal High Performance Buildings

• Office of Mission Assurance (OMA)

• Office of Design Construction (CDC)

The Building Technologies Technical Reference Guidelines (BTTRG) was developed due to a growing demand for fom,alized guidance related to the technical integration of BMC systems to the GSA network and within its GSA's infom,ation technology (IT) environment. BMC systems include, but are not limited to, building technologies such as building automation systems (BAS), advanced metering systems (AMS), lighting control systems, physical access control systems (PACS), renewable energy systems, and digital signage. These systems, while closely related to the scope of facilities management, are IT systems and do collect GSA building data, and as such are subject to the same federal (i.e., the Federal lnfoJTTiation Security Management Act (FISMA)) and agency specific policies and security standards as any other federal IT system. It is the intent of this document to inform on those policies and standards. Additionally, this document establishes a consistent and repeatable approach for how these technologies will be implemented and supported within GSA. The audience for this guide is facility managers, operations and maintenance staff, and potential and/or contracted vendors and integrators.

This guide was initiated and published by the Public Buildings Information Technology Services (PB-ITS) in participation with GSA-IT Security, Office of Mission Assurance (OMA), multiple offices of PBS including Office of Facilities Management (OFM), Office of Design and Construction (ODC), as well as with participants from the regions. Each chapter of this guide covers a functional area and the content for each was developed through working group meetings, which included the participation of stakeholders and subject matter experts.

The BTTRG aligns with existing Federal and GSA specific IT policies and is partnered with the BMC System Technology Policy. For guidance on smart building implementations and industry best practices for building automation systems, please refer to:

Revision History

Version Date

Version 1.0 June 2011

Version 1.1

Version 1.2

February 2014

September 2016

Version 2.0 June 2021

This guide will be updated every few years, as necessary, to accommodate improvements to processes, evolved best practices, and any new or updated policies or standards relevant to the implementation of BMC systems. Users of this guide are encoura ed to rovide feedback that will lead to improvement in future versions by emailing the BTSD at

DocuSlgn Envelope ID: F1C7084C.S051-4EE5-BB96-07630E1521D6

Chapter 1 Policy/Standards and IT Security

1.0 Overview

This chapter details the General Services Administration's (GSA) and Public Building Services' (PBS) standards and Information Technology (IT) security policies with respect to the implementation of BMC devices/systems. It documents the comprehensive system requirements related to approved software, standard hardware, network connectivity, user access, security clearances and Building Systems Network (BSN). Additionally, policies and procedures contained herein will guide PBS projects in preparing for assessment and authorization activities required for building systems projects.

Current policies forassessment and authorization of systems and devices on the Building Systems Network are based on the National Institute ofStandards, and Technology (NIST> Special Publication (SP}, 800-53 rev4, Security and Privacy Controls for Federal Information Systems and Organizations. The Building Systems Network (BSN) servers supporting the building automation systems, and associated devices, have been issued a Federal lnfonnation Security Modernization Act (FISMA) Moderate Authority to Operate (ATO). Additionally, the GSA-IT Security team has issued guidance and procedure documents on the assessment process that detail the required steps for security assessments, roles and re~ along with the SLAs/time frames for evaluation. These reference documents can be found on--

1.1 BMC Systems Roles and Responsibilities

• GSA-IT Network Operations and Management (Network Team): The network team is responsible for the entire IP transport layer to include all routing and switching equipment and access to IP connectivity. They have command responsibility for the GSA Local Area Network (LAN) and GSAWide Area Network (WAN). The Network Team is the sole provider for IP/subnet allocation at the building level as well as management of network devices (switches and routers), on the GSA network. They are also responsible for managing the BSN's connectivity to the rest of the network. Please Note: PBS is responsible for the controllers/devices. GSA-IT provides connectivity up to the switch port, on the network.

• GSA-IT Technical Operations Team (TechOps): TechOps is responsible for all PBS servers on the GSA network, including servers in the Regional Office Buildings (ROB), at the PBS owned field offices and GSA data centers. This includes VMware/virtual server builds, operating systems (OS), databases.

server/application services monitoring, data/system backups and restores. Please Note: See Chapter 4 for more details on TechOps's role in provisioning BMC servers.

• GSA-IT Security Operations Team (SecOps): SecOps is responsible for operating the GSA cybersecurity stack that provides security services to PBS. The security services include, but are not limited to, endpoint protection, perimeter defense, vulnerability scanning, enterprise logging, and analysis. GSA-IT Security performs regular scans of BSN servers as part of compliance validation.

SecOps is also responsible for facilitating aspects of authorization control including authoring the Assessment and Accreditation (A&A) documents, perfonning risk assessments, managing the system compliance over the life of the ATO and managing the Plan of Action and Milestones (POA&M) items specific to the Building Technologies systems.

• GSA-IT Security BMC Device Assessment Team (BMC Lab): The BMC Device Assessment Team performs hardware/finnware/software assessments on devices designated as BMC components. They are also responsible for reporting the proper configuration of the device on any GSA network and any

OocuSlgn Envelope ID: F1C7084C-6051-4EES..BB96-07630E1521 D6 residual risks associated with use of the device within the GSA network. Please Note: See Section

1.4 for more details on the BMC Device and Application Security Assessment Process.

• BSN Information System Security Manager (ISSM) and lnfonnation System Security Officer (ISSO): The BSN ISSM, and ISSO are responsible for facilitating aspects of authorization control including authorizing the A&A documents, performing risk assessments, managing the system compliance over the life of the Authority to Operate (ATO), and managing the POA&M items specific to ~eBSN. .

• Regional PBS Project Teams: This includes Regional Smart Building Team members, BAS specialists, contracting officers, project managers, facility managers, etc. They are responsible for ensuring that any BMC-IT systems contracted, purchased, owned and/or operated in the regions adhere to Policy and Implementation guidance within this document and other applicable GSA guides.

Also, these teams are to articulate any contractual agreement with the information technology vendor who provides products and/or services to PBS, including hardware, software and Service Level Agreements. Additionally, the regions are responsible for contacting the Buildings Technology Services Division (BTSD) prior to the award for applicable contract and Implementation requirements. They are responsible for the installation, configuration, and management of the application software. In addition, they are to complete the Application Documentation Form for TechOps in a timely manner in order to ensure monitoring and backup routines are established. Please Note: See Chapter 4 for links to required documents.

• Vendor/Contractor: Responsible for adherence to GSA-IT policies, ensuring BMC devices and applications are secure, meet Security Assessment Report (SAR) provisions, completing documentation related to the security and support of their application and devices, and for providing maintenance/support of their devices and software. Vendor/contractor must meet all provisions of the latest remediated Security Assessment Report for any software and/or hardware connected to the GSA network or BSN LAN extension.

1.2 Policies and Requirements for Interconnectivity

The following section provides information regarding GSA-IT policies and standards with which PBS-IT systems, vendors, manufacturers and integrators shall comply.

1.2.1 Trusted Internet Connection (TIC)

Trusted Internet Connections (TIC) is a mandate from the Office of Management and Budget (0MB). The purpose is to reduce the number of Internet gateways on the federal government network and to ensure that all extemal connections are routed through a government agency that has been designated as an approved TIC Access Provider. All BSN network traffic must transit through a TIC, which is a network circuit that is managed by GSA-IT.

2100.1L C/0 CHGE 1 GSA Information Technology OD Security Policy states:

"All network devices that are either owned, managed, connected to a GSA facility, and/or handle GSA data shall be strategically positioned behind a GSA firewall to provide analysis/correlation, management structure, and minimize threats presented by external attacks." TIC will allow the GSA to provide the following security functions for any devices connected to the GSA networks:

• Monitoring, incident response, wlnerability assessment, vulnerability management. incident reporting, engineering support, and the enforcement of the agency's specific security policy at the hosted facility.

• Trained, qualified, and cleared staff to support security functions 24x7.

• Limited inbound and outbound connections so that only necessary services are allowed.

• Centralized, secured, and unified management of security events in order to protect the integrity of the U.S. Government data and its infrastructure.

Please Note: At no time should a GSA hosted BMC system(s) be made accessible to the public internet orvia any third-party network connection, referred to as "rogue circuits". All network traffic must transit through a TIC, which Is a network circuit that is managed by GSA-IT. Any use of extemaUcommerclal network connection for managing or monitoring of building systems in any GSA owned, non-delegated, building will not be tolerated. Such connections will be removed upon discovery.

1.2.2 Cellular Connection

GSA prefers all BMC devices be connected to the GSA building systems network. GSA realizes that unde certain circumstances, connecting BMC devices to the building systems network is not feasible, and other network transport technologies may need to be employed. The use of a cellular transport is by exception only, based on a GSA OCISO risk assessment. All cellular transport must be facilitated by a device with the following security capabilities, stateful firewall, audit logging, and VPN. GSA IT security must be provided administrative access to the device facilitating the cellular transport. All BMC devices utilizing cellular transport must successfully complete the GSA BMC Systems Security Assessment Process and undergo annual penetration tests. The GSA OCISO may grant exceptions to the security capabilities based on the results of a GSA OCISO risk assessment.

r

1.2.3 Government Furnished Equipment

Federal Acquisition Regulation fFAR) 45 defines Government Furnished Equipment (GFE) as "equipment that is owned by the government and delivered to or made available to a contractor". As such, GFE hardware must be used to access IT systems. This applies to all networking infrastructure, IP-enabled devices, servers and workstations provided for facility managers, associated with BMC Systems. Vendor provided computer hardware is not allowed to connect to the GSA network and can only be used for pre commissioning purposes (at no point can it access the GSA network). If vendor-provided devices, workstations or servers are discovered, they are subject to removal without warning. Alternatively, Citrix VDI can be used as an alternative to GFE, when applicable. Please Note: See Chapter 4 for details.

• Network Equipment: This includes, but is not limited to, any equipment that provides networking capabilities, i.e., hubs, wireless access points, switches, and routers.

• Computer Hardware: This includes, but is not limited to servers, printers, smart devices, computers, laptops and their peripherals (monitors, mice and keyboards).

As buildingsare integrated with the GSA network, GSA-ITwill make every effort to provide up to two laptops to these sites. The purpose of the laptop is to provide building management staff with access to their BMC system application interfaces.

Please Note: A val/ability ofhardware is dependent on the availability of funding dedicated for this purpose, which may ormay notbe renewed on an annual basis. Existing GSA workstation refreshes will still be coordinated through the regional GSA-IT manager's office. No hardware (workstations, servers, switches, etc.) will be provided unless an approved network diagram Is submitted. See Section 2.4 for details about network diagram requirements andsubmission.

1.2.4 BMC Device Whitelisting Process

Cisco Identity Services Engine (ISE) is a next-generation, identity and access-control policy platform that enables enterprises to enforce compliance, enhance infrastructure security, and streamline their service operations. ISE allows enforcement of security and access policies for endpoint devices connected to GSA's routers and switches. ISE is a mandated security policy to ensure that unauthorized systems are not connected to the network. It is applied to GSA switches which, in tum, block devices that are not recognized as approved devices, including rogue circuits and unmanaged switches.

The GSA rolled out the Mac Address Bypass (MAB) process in June 2017. For a device to be allowed to communicate over the GSA network, its MAC address needs to be whitelisted by GSA-IT. All devices will need to be remediated before they are white listed. Please Note: See Section 1.4 for details on the BMC Device and Application Security Assessment Process. Once the device is reviewed and remediated, the BTSD Technical PM will need support from PBS and the project team to prepare an updated network riser diagram, (which lists all devices, their IP addresses, MAC addresses, and location) to the network team. Once documentation has been updated, the BTSD Technical PM submits a "MAB" or an ISE exception ticket in Service Now, in order to white list the devices.

1.3 GSA Network Access to Perform Duties

This section demonstrates how any GSA employee, contract staff, or vendor personnel can obtain access to GSA-IT systems, which includes all hardware, system software, data, and network access. Each of these requirements must be met for access to be granted. ENT domain credential and VPN access require Homeland Security Presidential Directive-12 (HSPD-12) adjudication. Please Note: To ensure unlntem1pted support from vendor personnel, government sponsors/project PDCs must ensure vendor personnel maintain their ENT accounts and keep them active. This Includes timely completion ofall tasks required to keep an ENT account active, such as annual ITSecurity Training courses, and regularly logging into their email.

1.3.1 HSPD-12 Credentialing and Systems Privileges

In August 2004, President George W. Bush signed the Homeland Security Presidential Directive-12 (HSPD-

12) which is a mandated policy for a common identification standard for Federal employees, and contractors. HSPD-12 requires all Federal executive agencies and departments to conduct personnel investigations, adjudicate results, and issue a Personal Identity Verification (PIV) or Access Card to all Federal employees, contractors, or personnel that require routine or regularly scheduled access to federally controlled facilities, and IT systems. Please visit the site for details on how to initiate the credentialing process.

1.3.2 Background Investigations

The mandatory minimum background investigation level for access to any GSA system is the preliminary adjudication of Tier 1. However, Per GSA C/0 Policy 2100.1 , those individuals whose duties require a higher degree of trust, such as IT system administrators (or administrative access to building systems server, applications and devices), those who handle financial transactions, or those who deal with PII, and other sensitive information (i.e., building drawings, etc.) will require a Tier 2 clearance

All access to GSA information systems must comply with the requirements of GSA Information Security Policy 2100.1L. Non-privileged access to a GSA information system categorized at the FIPS 199 High or Moderate level via a network requires Multi-Factor Authentication (MFA), and privileged access to any GSA information system via a network requires MFA.

1.4 BMC Device and Application Security Assessment Process

Before any IP-addressable hardware, software or ITdevice/system can be connected to the GSA network, GSA-IT will need to assess and approve the solution and all identified vulnerabilities must either have been remediated or have an Acceptance of Risk (AOR) by GSA-IT's Authorizing Authority.

Please Note: Scans an, authenticated and have a process in place to securely pass authentication data. This ensures that the systems which touch the GSA network have the proper controls implemented in accordance with security requirements.

DocuSlgn Envelope 10; F1C7084C-6051-4EE5-BB96-07630E1521D6

A Security Assessment Report (SAR) is produced by GSA-IT Security once the device has been assessed, which is provided to the PBS stakeholders and the vendor. The assessment report allows the GSA to understand and accept the risk to agency operations, agency assets, or individuals, based on the implementation of an agreed upon set of security controls. The contractor/vendor is responsible for mitigating all security risks identified in the SAR. Vulnerabilities must be mitigated within the appropriate timeframe as described in the SAR mitigation plan along with milestones and timelines for remediation for consideration of GSA-IT in order to connect to the GSA network.

GSA-IT Security only needs to assess a certain model of a device the first time it is introduced to the GSA network. Once a device has completed the remediation process and has a remediation/hardening plan in place, all other projects can use that SAR to configure the device accordingly. This procedure is repeated on a three-year (maximum) cycle or until a major version change has been implemented by the manufacturer. A~receive favorable concurrence b the IT Securi Team they will be added to the -----which is the backend for the Please Note: Both links have restricted access within the GSA firewall.

PBS stakeholders can find the most current list of devices that are either being assessed or have been assessed in the past and are approved to be used in either of those links. The list is not to be used either for inclusion or exclusion of listed components and is only provided as a guide to devices that have completed favorable assessments and are deemed as · remediated". Please Note: GSA-IT Security will needto evaluate non-IP wireless devices due to the higher level ofthreat posed by wireless devices.

See Section 1.4.2 for more details. Any device that is not approved or has an expired SAR will risk losing the Authority to Operate (ATO).

More information regarding the assessment process can be found in BAS Security Assessment Process fC/0 IT Security 16-767which is located under IT Security Procedural Guides on GSA-

1.4.1 GSA-IT Security Scanning Process

In order to request a scan, the hardware or software being proposed must be under contract for a current project. Please ~can/pre-assess hardware/software from vendors. To begin the process, an----(ARF) must be completed, before the device is shipped to the BMC Assessment Team . This form is available to anyone with access to the GSA network. An offiine version of the ARF can also be sent to POCs without access to the GSA network. The assessment request forms must be completed, and all relevant documentation (installation manual, configuration management plan, hardening guide) must be submitted and reviewed before Security is ready to receive the device. The ARF includes instructions on how to submit documentation to the BMC Assessment Team. Alternatively, the documentation can be emailed directly to

The BMC security assessment process is broken down into six steps: Pre-assessment, Assessment Induction, BMC Assessment, SAR Issuance, BMC Vendor Remediation, and BMC Post-Assessment.

1.4.1.1 Step 1: BMC Pre-Assessment

The BTSD is responsible for working with BMC Vendors to identify BMC solutions needing assessment.

During this stage, the BTSD will collaborate with the BMC Vendor to coordinate and submit the pre assessment requirements. The requirements include electrical specifications, documentation requirements, technical prerequisites, and submitting the required forms. The BMC Assessment Team is responsible for reviewing documentation and technical specifications to identify compliance with minimum security requirements and accepting or rejecting the BMC solution into the BMC Assessment Lab.

The device should be sent to the BMC lab configured and hardened as it will be installed on the GSA network (unnecessary ports and services closed, etc.). The device should also arrive properly assembled for power. The BMC Assessment Team is not permitted to work with any electrical wiring, and any device that cannot immediately be plugged into a 110V wall outlet will be delayed (either returned for proper configuration, or on hold until someone can come to the lab and configure appropriately).

The following will be needed with each device that is submitted:

• Manufacturer POC.

• All relevant infonnation and documentation must be provided to PBS-IT Security, including:

o Firmware and software versions (these are essential for detennining a security baseline) o Technical specifications (including infonnation on all inbound and outbound communication on the device, required ports and services, etc.)

o User Manual o Installation and Configuration Guide o Operation and Maintenance Guide o Configuration/Hardening Guide o Network diagram detailing network ports, protocols, and services utilized

• The device and software documentation must provide infonnation to the system configuration management plan, explaining:

o How will the device be .configured on the GSA network, and how can this configuration be monitored?

o How will the device be hardened (which ports and services are unnecessary and will be turned off when installed on the GSA network)?

■ All unnecessary ports must be closed

■ All unnecessary services must be disabled o How will the device be upgraded / patched when updates to finnware or software are released?

• All new contracts with building automation system vendors shall include support language to ensure that security requirements I upgrades will be remediated by the vendor ormanufacturer at no additional cost to GSA.

• For wireless technology submissions, include the following infonnation; FCC ID, protocol specification, operational documentation and commissioning guides.

Before shipping the device, make sure the device Is configured with the following:

• The device must have sufficient access controls, including:

o Login screen o Password ~eld on login screen must be masked o Passwords must meet GSA policy strength requirements: passwords must contain a minimum of sixteen (16) characters with uppercase and lowercase letters, symbols, and numbers o Logins must be encrypted

• The device must be capable of managing user access rights:

o Least privilege - nobody should have more rights than needed (i.e., a user with a need for read only/monitoring access should not be able to make changes to the device or the things controlled by the device) o Documentation should state how user access rights are managed (i.e., administrators, general users, etc.)

• The device must be capable of utilizing TLS (SSL is not sufficient) for the encryption of sensitive data and/or login credentials:

o Project POC must state what kind ofdata is being transmitted through these devices (i.e., metering data, energy use data, sensitive data, etc.)

o Have TLS v1 .2 Encryption Enabled only. Disable SSL v1 .0, SSL v2.0, SSL v3.0, TLS v1 .0, and TLS v1 .1 Please Note: TLS v1 .3 will become a requirement in the future. Please confirm the latest policy with the BTSD PM.

o All web-based logins must utilize TLS o Configured HTTPS to be enabled and HTTP disabled o Be configured with FIPS 140 Compliance (if possible)

• Audit and Accountability (instructions for accessing bgs and information detailing what events are audited). The device must be capable of logging the following auditable events:

o Successful and unsuccessful account logon events o Account management events (creation ordeletion of user accounts, change in user privileges, etc.)

o Privilege use events (i.e., administrator functions, changes to or erasure ofsystem logs, etc.)

o System events (i.e., power failures, lost connection to a server, or other availability issues, system time changes, NTP server synchronizations, etc.)

o If the device has a web application, the web application must be capable of logging the following auditable events:

■ All administrator activity

■ Authentication checks (i.e., user logons)

■ Authorization checks (i.e., checks of user privileges or access rights)

■ Permission changes (i.e., change in user privileges)

• The device must be capable of being updated:

o To address code vulnerabilities in the firmware o To improve the software or firmware in general Please Note: Major finnware revisions may require reassessment and reauthorization of the device.

• If the device uses a Microsoft yvindows (except Windows CE) or UNIX/Linux based operating system, DocuSlgn Envelope ID: F1C7084C-6051-4EES-BB96-07630E1521O6 antivirus software must be installed, and a plan must be in place for keeping the software updated

• Disable protocols such as Telnet, SSH, TFTP and FTP

• Disable wireless communications unless previously specified as required (802.11 Wi-Fi, Bluetooth, ZigBee, Z-Wave, UHF/RHF, etc.)

Please Note: Any configuration required by IT Securl delaying the security evaluation process. Contact for any further questions regarding this process. Once ITSecurity is ready to receive the device, they will provide detailed instructions aboutshipment

1.4.1.2 Step 2: BMC Device and Supervisory Control Software (SCS) Induction

The BMC Assessment Team will attempt to power on the BMC Device, access the device, and establish network connectivity. The BMC Assessment Team will make a reasonable attempt to work with the vendor during this process. If, after ten business days, the assessor is unable to access the device or establish network connectivity, the priority will be moved to the bottom of the queue until the issues are corrected. If the device is not corrected within 20 business days, it will be removed from the prioritization sheet and the BMC Assessment team has the right to reject the device and close the assessment ticket. The BMC Smartsheet page will be updated to identify the configuration deficiency and the assessment will be closed.

At this point, the device will be shipped back to the vendor within five business days. The vendor will be notified and provided the shipping tracking number.

An SCS is considered inducted once all the following have been completed:

• A server has been reserved

• An image build has been completed by TechOps

• All installation files are available

• An installation meeting has been scheduled.

During this phase, the BMC Vendor will be utilized to assist the BMC Assessor in properly installing and configuring the SCS. An activation license is required prior to the installation meeting.

1.4.1.3 Step 3: BMC Assessment

The BMC Assessment process utilizes a systematic, repeatable approach to uniformly evaluate every type of system, whether physical access controls, building automation, specific applications, or wireless technology. The assessment process consists of several types of reviews in order to test all aspects of a solution. The sections below provide additional detail on each assessment step. The SLA response time will not start until the device is accepted into the BMC Assessment Lab or the software is successfully installed. The SLA timetable does not include the time to mitigate issues or troubleshoot problems with the BMC vendor. The BMC Smartsheet page will be updated to reflect the status of each assessment item noted below.

Top Ten Most Common Vulnerabilities in BMC Systems Assessments:

• Cross-Site Scripting: This could result in impacts such as a hijacked account information theft.

browser redirection or denial of service.

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-BB96-07630E1521 D6 o Mitigation: Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Implement validation globally using standard ASP.NET Validation controls, or directly in system coding

Insufficient Documentation: Documentation available for the device does not provide administration instructions or complete information on the inbound and outbound communications of the device.

o Mitigation: GSA-IT requires that, uoocumentation must be obtained or created to describe how security mechanisms are implemented and configured within the ITsystem." Obtain documentation sufficient to install, configure, administer, and monitor devices.

Least Privilege: Documentation available for the device does not provide required configuration settings to enforce least privilege compliance.

o Mitigation: Information systems must be configured to the most restrictive mode consistent with operational requirements and in accordance with appropriate procedural guides from NIST and/or the GSA to the greatest extent possible. Implemented configuration settings should be documented and enforced in all subsystems of the information system." Obtain documentation sufficient to securely configure these devices.

Configuration Management: Documentation available for the device does not provide a configuration management plan.

o Mitigation: A system configuration management plan must be developed, implemented, and maintained for every IT system managed by the GSA, to ensure changes are authorized, tracked and validated.

Insufficient Auditing: No evidence is provided that the device is auditing to GSA required level of detail.

o Mitigation: The GSA requires security activity auditing capabilities to be employed on all GSA information systems and that audit logs are in compliance with GSA auditing requirements.

Unencrypted Login Form: An attacker who exploited this design vulnerability would be able to utilize the information to escalate their method of attack, possibly leading to impersonation of a legitimate user, the theft of proprietary data, or execution of adions not intended by the application developers.

o Mitigation: Sensitive areas of web application must have proper encryption protocols in place to prevent login information and other data that could be helpful to an attacker from being intercepted.

Per GSA policy, Web sites (internal and public) with logon functions, must implement TLS encryption with a FIPS 140-3 validated encryption module.

Logins Sent Over Unencrypted Connection: An attacker who exploited this design vulnerability would be able to utilize the information to escalate their method of attack, possibly leading to impersonation of a legitimate user, the theft of proprietary data, or execution of actions not intended by the application developers.

o Mitigation: Sensitive areas of web application must have proper encryption protocols in place to prevent login information and other data that could be helpful to an attacker from being intercepted.

Per GSA policy, Web sites (internal and public) with logon functions, must implement TLS encryption with a FIPS 140-3 validated encryption module.

No Encryption: Sensitive information is transmitted without protedion.

o Mitigation: Sensitive areas of web application must have proper encryption protocols in place to prevent login information and otherdata that could be helpful to an attacker from being intercepted.

Per GSA policy, Web sites (internal and public) with logon functions, must implement TLS

Page 17 of109

DocuSlgn Envelope ID: F1C7084C-6051-4EE5-8B96-07630E1521D6 encryption with a FIPS 140-3 validated encryption module.

• Unnecessary Services: Services were available with no documented need for their use.

o Mitigation: Disable all unnecessary services. Document all necessary services. Unnecessary services provide malicious users additional vectors to perform an attack.

• Unnecessary Ports Open: Insufficient or no documentation available to justify need for use of open ports.

o Mitigation: Unnecessary ports provide malicious users additional vectors to perform an attack. All unnecessary ports must be closed, and proper documentation is required for necessary ports that need to remain open.

1.4.1.4 Step 4: BMC Solution SAR Issuance

Upon completion of the BMC Solution Security Assessmen~ the BMC Assessment Team will document all findings and vulnerabilities in a SAR. The SAR provides a discussion of the security assessments results which details the numerical identifier, finding name, description, associated NIST SP 800-53 controls, any GSA policy reference, and a recommended fix. The SAR will be utilized within the remediation phase to provide vulnerability tracking and responses pertaining to the remediation effort. The SAR will also include the scan reports and the manual assessment checklist that was completed during the assessment process.

Updates to the associated SAR creation and issuance date will be provided by the BMC Assessment Team on the BMC Smartsheet page.

1.4.1.5 Step 5: BMC Vendor Remediation

A BMC solution is required to go through the remediation process if the SAR is issued with open 'critical', 'high', or 'moderate' finding. The SAR remediation phase begins once the SAR is distributed to the BMC vendor and appropriate BMC stakeholders. This is a separate process from the BMC Device Assessment Phase. The GSA-IT Security team will provide guidance for remediation or mitigation of the findings.

Vulnerabilities are to be remediated by fixing the identified vulnerability. If the vulnerability cannot be remediated within an acceptable timeframe, the project POC must request an Acceptance of Risk (AoR) from the Authorizing Official (AO) to accept the risk that the device/system would impose on the GSA network. The .AoR can allow up to 12 months for a vulnerability to be remediated. Per GSA Information Security Policv 2100.1L all vulnerabilities (Critical, High or Medium) must be mitigated. AORs are not common and are approved on a case-by-case basis. If new vulnerabilities are discovered after the system has been remediated and integrated onto the network, the PBS project teams are responsible for ensuring that the proper software maintenance and contracting is in place in order to mitigate the vulnerabilities. Per GSA-IT policy, 'critical' and 'high' risk findings must be mitigated within 30 days, and 'medium' risk findings within 90 days.

It is important to note that the BMC solution SAR is a snapshot in time, whose results lose relevancy over time as new vulnerabilities and exploit techniques are identified. As such, if a BMC vendor cannot respond to the GSAwith actionable remediation of the identified findings within 120 business days (six months) from the issuance of the BMC SAR, the _BMC Assessment team has the right to categorize the BMC solution as non-remediated and close the Smartsheet page. The BMC vendor and BMC stakeholders will be notified of the non-remediation decision and the BMC device will be added to the non•remediated BMC device list on GSA's BTSD's Smartsheet page.

1.4.1.6 Step 6: BMC Solution Post Assessment

Once the remediation decision has been detennined, the BMC assessment project is considered closed. If a BMC component is identified as non-remediated, GSA is prohibited from purchasing any additional components of that model since it is an identified risk to the GSA environment. The BMC Assessment Team

DocuSlgn Envelope ID: F1C7084C-6051◄EE5-BB96-07630E1521D6 will review the implementation of a patch management and continuous monitoring plan during the manual assessment process. ·

It is the responsibility of the PBS Business Line to ensure an Operations and Maintenance (O&M) support contract is in place to support any additional remediation or upgrades to the device. lf the device undergoes changes asa part of the System Development Life Cycle (SDLC) process, oran identified security incident, there may be a need to reassess the device/SCS. This section provides additional guidance for requirements as to when a re-assessment must be completed.

1.4.2 Wireless Assessments

Wireless technologies must have a minimum of AES 128 encrypted level, ideally 256-bit AES encryption.

All wireless solutions must adhere to the "2100.2B CIO P GSAWireless Local Area Network (LAN) Security" guide before they can be connected to the GSA network. This guide mainly covers devices operating

802.11. Additionally, other non 802.11 wireless solutions are required to be scanned, remediated, and the solutions evaluated and approved by GSA-IT Security in advance of any implementation.

Use of compromised or weak wireless technology, such as Zigbee (default configuration without any modification), Z-Wave (default configuration without any modification), Bluetooth less than v4.1, 802.11 Wired Equivalent Privacy/ Wireless Protected Access (WEP/WPA) and low-level frequency without protection, such as Global System for Mobile Communications (GSM) Band and Code Division Multiple Access (CDMA) (3G/4G/L TE/5G).

The requirements…