Attachment_BuildingTechnologiesTechnicalReferenceGuide.pdf

Building Technologies Technical Reference

Guide

Version 1.2

September 29, 2016

Version History / Change Record Revision Chapter Change

Revision

1.1

1 TIC

1 Formal Security Evaluation

1 Security Evaluation Criteria

1 Devices Risk Assessments

1 Scanned Device List

1 Client Software (Non-Standard Software)

1 Non-standard software on GSA servers

1 GSA IT Security Scanning Process

1 Building Systems Network (BSN)

2 BACnet

3 Cabling Installation Options

3 Overview of Data Circuit Installation

4 Responsibilities respective to server and application support

4 Server Installation Guidelines

4 Methods for Remotely Accessing a PBS Technical Operations Server

4 System Documentation and Monitoring

4 Backup Solutions

4 Planned/Unplanned Outages and Maintenance

6 Reporting an BMC Issue

6 BMC support system workflow

7 PACS (new chapter)

Revision

1.2

1 Introduction

1 Scanning Process

1 What is BSN?

1 No external/commercial network connections allowed

1 Incident Response and Disaster Recovery

2 Issues with daisy chaining switches

4 Solution Architecture and Requirements Analysis

4 Server Standards

4 Application Installation and Maintenance Guidelines

4 Server Access

4 System Documentation and Monitoring

4 How to request Remote Desktop User Access

4 How to request Administrator Access

4 Copying Files to a Server on the BSN

5 New SOW format and language

6 Reporting an BMC Issue

6 PBS Technical Operations Team

6 BMC Outage Process

6 BMC Admin, RDP, and Reboot Process

6 SFTP (Secure File Transfer Protocol) Request Process

6 SMTP Email Server Information

7 Physical Access Controls Systems (new chapter)

8 Best Practices (new chapter)

Approvals

Introduction

The nation's buildings are increasingly relying on building control systems with embedded communications technology and many enabled via the Internet. While, the advent of Internet of Thing (IoT) allows ease of use, remote access and data integration, it can also be easy targets for hackers and people with malicious intent. Attackers can exploit these systems to gain unauthorized access to facilities; be used as an entry point to the traditional informational technology (IT) systems and data; 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 include courthouses, laboratories, regional office buildings, many of which are part of the nation's critical infrastructure. These facilities contain building and access control systems such as heating, ventilation, and air conditioning; electronic card readers;

and closed-circuit camera systems that are increasingly being automated and connected to other information systems or networks and the Internet. As these systems are becoming more connected, so are their vulnerability to potential cyber-attacks.

As we have learned in recent highly visible cybersecurity incidents at Office of Personnel Management (OPM), Target, Home Depot, Sony and Veterans Affairs, hacking is a growing trend. GSA does not want to be the next target to prove the external threats are real enough to raise concerns.

Cyber incidents can compromise Personally Identifiable Information (PII) and cause outages related to power, network, or other issues that can not only cause major damage to security infrastructure of a building, it can also have a long term repelling effect that can go on for many years.

Building a platform focused on security with disaster recovery in mind, will limit these type of incidents, protecting the infrastructure; including the building systems, which can be caused by internal or external sources.

While physical and cyber security of our buildings is a high priority, GSA also understands there needs to be balance between continuity of operations and vigilance for security. Therefore, as with any business decision, GSA IT and Office of Facilities Management (OFM) will be taking a risk-based decision approach that evaluates exposure, building level, type of vulnerability and actual physical impact/ likelihood, of threat.

The Building Technologies Technical Reference Guide was created to protect and enhance the GSA IT posture, and in response to repeated requests for information and formalized guidance related to the technical integration of building monitoring and control (BMC) systems to the GSA network and within its GSA’s information technology (IT) environment. BMC systems include, but are not limited to building technologies such as advanced metering systems (AMS), building automation systems, 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 and agency specific policies and security standards as any other Federal IT system. It is the intent of this document to not only inform on those policies and standards, but to establish a consistent approach for how these technologies will be implemented and supported within GSA.

This guide was initiated and published by the Public Buildings Information Technology Services PB-ITS, within GSA IT and developed and reviewed with extensive participation with Office of Mission Assurance, multiple offices of PBS including Facilities Management, Design and Construction, as well as with participants from the Regions. The organization and oversight for this guide was led by a Core Team of senior management from multiple divisions of PBS and included leadership from several GSA 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 from central office and the regions.

The Building Technologies Technical Reference Guide is consistent with existing Federal and GSA specific IT policies and is partnered with the Building Monitoring and Control System Technology Policy, which was issued jointly by PB-ITS, Facilities Management and Design & Construction divisions. For guidance on Smart Building implementations and industry best practices, please refer to the GSA Smart Buildings Program Guide and the GSA Smart Building Implementation Guide.

This guide is a “living document” and will be updated as necessary to accommodate improvements to processes, evolved best practices, and any new or updated policies or standards relevant to the implementation of building monitoring and control systems. Users of this guide are encouraged to provide feedback that will lead to improvement in future versions.

https://insite.gsa.gov/portal/content/651562 https://insite.gsa.gov/portal/content/651562 https://insite.gsa.gov/portal/content/685362 https://insite.gsa.gov/portal/content/685362 https://insite.gsa.gov/portal/content/685362

Table of Contents

Version History / Change Record

Approvals

Introduction

Chapter 1:

Policy/Standards & IT Security

1.0 Overview

1.1 Roles and Responsibilities, BMC Systems

1.2 Trusted Internet Connection (TIC)

1.3 Requirements for Network Connection

1.3.1 Government Furnished Equipment

1.3.2 Server Security Assessment

1.3.3 Device Security Assessment

1.4 Non-Standard Software Review Process

1.4.1 EARC Evaluation of Non-standard Software

1.4.2 Non-standard software on GSA workstations

1.4.3 Non-standard software on GSA servers

1.5 Security Assessment and Evaluation Process for BMC Systems Devices

1.6 GSA Network Access to Perform Duties

1.6.1 HSPD-12 Credentialing and Systems Privileges

1.7 Building Systems Network (BSN)

1.7.1 What is the Building Systems Network (BSN)?

1.7.2 Why is the BSN Necessary?

1.7.3 Who is Responsible for the Creation and Management of the BSN?

1.7.4 BSN Implementation

1.7.5 What Changes Can Be Expected Once the BSN ACL is Applied

1.7.6 Will the BSN Be Implemented the Same Way for Every Site?

1.7.7 BSN Building Consoles

1.7.8 Using Citrix and Building Console Workstations

1.7.9 Steps to Integrate Sites on to the BSN from the ENT Domain

1.8 Incident Response and Disaster Recovery

1.8.1 Incident Response

1.8.2 Disaster Recovery

Appendix A: Contact Information

Appendix B: Listing of Reference Policies

Appendix C: Security for GSA Building Automation Systems

Appendix D: Top Ten Most Common Vulnerabilities in BMC Systems Scans

Chapter 2

Network Infrastructure

2.0 Overview

2.1 Roles and Responsibilities

2.1.1 PB-ITS Building and Energy Systems Technical Project Manager

2.1.2 GSA-IT’s Network Operations (NetOps) Team

2.2 Standards for Interoperability

2.3 Network Topology

2.3.1 Network Design Requirements: Submitting a Network Design Diagram to PB-ITS and NetOps

2.3.2 Sample Network Design Diagrams

2.4 Hardware Standards & Policy

2.4.1 Requesting Switches and Routers

2.4.2 Configuration and Connection of the Switches and the Routers

2.5 Acceptance of Non-Standard Hardware

2.6 Implementing BACnet

2.6.1 What Is BACnet?

2.6.2 How Does BACnet Make Use of IP Networks?

2.6.3 Key Definitions (BACnet)

2.6.4 Considerations and Rule Sets for Implementing BACnet on the GSA Network

Appendix E

Contact Information

Chapter 3

Cabling, Data Circuit Installation and Upgrade

3.0 Overview

3.1 Applicable Standards for Cabling Infrastructure

3.2 Minimum Requirement for Ethernet Cabling

3.3 Attenuation Limit

3.4 How are GSA-IT’s Cabling Standards Enforced?

3.5 Cabling Installation Options

3.5.1 Cabling for New Infrastructure

3.5.2 Cabling Infrastructure for Existing or Migrating Systems

3.6 General Architecture

3.7 Cable Installation and Support

3.8 Cabling Roles and Responsibilities

3.9 Overview of Data Circuit Installation

3.9.1 Process for Data Circuit Requests & Sites Visits

3.9.2 Important Considerations in the Circuit Installation Process

3.9.3 Circuit Installation Roles & Responsibilities

Appendix F: Contact Information

Appendix G: Listing of Reference Policies

Chapter 4:

BMC Systems Workstations, Application Server Provisioning, Installation and Support

4.0 Overview

4.1 About the Technical Operations Team

4.2 BMC Server and Workstations

4.3 Solution Architecture and Requirements Analysis

4.4 Server Standards

4.4.1 Server Virtualization

4.4.2 Server Specifications

4.4.3 Server Security Hardening

4.5 Application Installation and Maintenance Guidelines

4.5.1 Responsibilities respective to server and application support only:

4.5.2 Application Installation Guidelines for Vendors

4.5.3 Dedicated Server Support During Installation

4.6 Server Access

4.6.1 Windows Server Access Requirements

4.6.2 How to request Remote Desktop User Access

4.6.3 How to request Administrator Access

4.6.4 Copying Files to a Server on the BSN

4.6.5 Methods for Remotely Accessing a PBS Technical Operations Server

4.7 System Documentation and Monitoring

4.7.1 Monitoring

4.7.2 Backup Solutions

4.7.3 Patching

4.8 Communications

4.8.1 Planned Outages and Maintenance

4.8.2 Unplanned outages and Maintenance

4.8.3 Group Notifications

4.9 Roles and responsibilities

Chapter 5

IT Requirements in Scopes of Work (SOWs) for Building Controls Procurements

5.0 Overview

5.1 Instructions

5.1.1 Use of Document

5.1.2 Small Projects

5.1.3 New Construction (Design and Construction)

5.2 Scope of Work Language (to be inserted in BAS SOW)

Chapter 6

Technical Support for Building Monitoring and Control and Energy Management Systems

6.0 Overview

6.1 Reporting a BMC Issue

6.1.1 Call or Submit an Email to Technical Operations Team

6.1.2 Call the Helpdesk hotline

6.1.3 Submit an IT Helpdesk ticket online with Service Now

6.1.4 Describing a BMC/BAS/EMS issue

6.2 Support Process

6.2.1 Help Desk Ticket Initiation

6.2.2 Managing and Troubleshooting Open Tickets

6.2.3 Resolving Open Tickets – Roles and Responsibilities

6.2.4 Closing Tickets

6.2.5 BMC Outage Process

6.2.6 BMC Admin, RDP, and Reboot Process

6.2.7 SFTP (Secure File Transfer Protocol) Request Process

6.2.8 SMTP Email Server Information

Chapter 7:

Physical Access Control System (PACS)

7.1 Overview

7.2 Support

7.2.1 Local Support

7.2.2 Technical Operations Team

7.3 Roles and Responsibilities

7.3.1 Building and Energy (B&E) System Team

7.3.2 Network Operations Division (NetOps)

7.3.3 Office of Mission Assurance (OMA)

7.4 Network Architecture and Integration

7.4.1 Security Overview

7.5 PACS Process Flows

7.6 Support Tickets

Chapter 8

Best Practices for BMC Systems Project Implementations

8.0 Overview

8.1 Why Go Virtual?

Glossary

Chapter 1:

Policy/Standards & 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 Building Monitoring and Control (BMC) devices/systems. It documents the comprehensive system requirements related to approved software, standard hardware, network connectivity, user access and security clearances. Additionally, policies and procedures contained herein will guide PBS projects in preparing for assessment and authorization activities required for ALL GSA information systems.

Current policies for assessment and authorization of systems and devices on Public Building networks are based on NIST SP 800-53 rev3. (please note: GSA IT is in transition to using FIPS 200 NIST standard to implement a tailored baseline of NIST SP 800-53 R4, using NIST SP 800- 82 to assist in tailoring to address BMC system). GSA IT is currently in the planning and development stages of a Security A&A boundary for the Building Systems Network (BSN) and the BMC systems that fall under that. Additionally, the GSA IT Security team has issued guidance and procedure documents on the assessment process that detail required steps for security assessments, roles and responsibilities and SLAs/time frames for evaluations. These reference documents can be found on InSite

1.1 Roles and Responsibilities, BMC Systems

The roles and responsibilities of GSA-IT are explained in the following sections:

● GSA IT-Network Operations (NetOps), 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 GSA Wide Area Network (WAN). NetOps is the sole provider for any and all IP addresses for devices associated with its network. NetOps is also responsible for managing the Building Systems Network (BSN) and management of the Access Control List (ACL). Please note:

the controllers/devices are the responsibility of the vendor.

● GSA IT Technical Operations (TechOps), is responsible for all PBS servers on GSA

WAN/LAN, including IT Server Systems in the Regional Offices, PBS Property Management Centers, and GSA buildings, as well as regionally-based IT systems. This includes server hardware, UPS, Operating Systems, databases, server/application services monitoring, data/system backups and restores.

https://insite.gsa.gov/portal/category/520178 https://insite.gsa.gov/portal/category/520178

● The GSA IT Security team performs vulnerability assessments on Building Monitoring and Control Components to meet GSA, PBS, and FISMA flaw identification and continuous monitoring requirements. GSA IT Security performs periodic scans of BMC servers as part of compliance validation. Separate hardware/firmware assessments are performed once on devices designated as Building Monitoring and Control components, reporting on the proper configuration of the device on any GSA network, as well as any residual risks associated with use of the device within GSA. The results of the security assessments provide an executive level view for the security posture of each device connected to the GSA network using an IP address and how the identified vulnerabilities can potentially affect other devices/components on the network. Also responsible for facilitating aspects of Authorization control including: authoring the A&A documents, performing 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.

● Regional project teams (which may include BAS specialists, Contracting Officers, Project Managers, Property Managers…) are responsible for ensuring that any BMC IT system contracted, purchased, owned and/or operated in the Regions adheres 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 PB-ITS Building and Energy Systems team early in the implementation process (prior to contract 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 Tech Ops in a timely manner in order to ensure monitoring and backup routines are established. Please see chapter 4 for links to required documents.

● Vendor/contractor is responsible for adherence to GSA IT policies, ensuring BMC devices and applications are secure, completing documentation related to the security and support of their application and devices, and for providing maintenance/support of their devices and software.

1.2 Trusted Internet Connection (TIC)

GSA security policy 2100.1J states:

All network devices that are either owned, managed, maintain a connection 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 GSA to provide the following security functions for any devices connected to GSA networks:

● Monitoring, incident response, vulnerability 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: No external/commercial network connections (4G, DSL, or Cable) are allowed in GSA buildings for managing or monitoring of buildings systems. Such connections will be removed upon discovery.

1.3 Requirements for Network Connection

1.3.1 Government Furnished Equipment

Government furnished (GFE) is defined as “equipment that is owned by the government and delivered to, or made available to a contractor” (FAR Part 45) and computer hardware must be used in all cases for PBS IT systems. This applies to all networking infrastructure, servers and workstations provided for Building Managers, associated with Building Monitoring and Control. Vendor provided computer hardware is not allowed to connect to 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 can be removed without warning.

Network equipment- includes any equipment that has IP routing and switching functionality.

Computer hardware- includes, but is not limited to servers, PCs, laptops and their peripherals (monitors, mice and keyboards). As buildings are integrated with the GSA network, GSA IT will make every effort to provide one desktop and/or one laptop to newly integrated (to the GSA network) sites for the purposes of giving building management staff access to their building monitoring and control system application interfaces. Please note: availability of hardware is dependent on the availability of budgeted funds dedicated for this purpose, which may or may not be renewed on an annual basis. Existing GSA workstation refreshes will still be coordinated through regional GSA-IT manager’s office.

No hardware (workstations, servers, switches) will be provided unless an approved network diagram is submitted. Please see chapter 2 details about network diagram requirements and submittal.

1.3.2 Server Security Assessment

GSA IT Security currently performs Operating System (OS) scan of the BMC Systems servers. Critical and high vulnerabilities need to be addressed within 30 days. While some of the vulnerabilities are mitigated via routine monthly patching done on the serves by GSA IT, other vulnerabilities, such as multiple version of JAVA, require assistance from property management staff and O&M, responsible for the server. GSA IT Security will also be performing scans of the BMC Systems applications, in the coming months.

Application-related security vulnerabilities will also require vendor engagement in order to be mitigated in a timely manner.

1.3.3 Device Security Assessment

All IP addressable devices, appliances or servers that will communicate over the GSA network must be scanned by GSA-IT Security. Before any hardware, software or IT device/system is connected to its network, a security risk assessment of selected management, operational, and technical security controls is performed, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. A security assessment report is produced by GSA IT Security once the device has been assessed, which will be provided to the PBS stakeholders and the vendor. The assessment report will allow GSA to understand and accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals, based on the implementation of an agreed-upon set of security controls. The contractor/vendor must therefore be held responsible for mitigating all security risks identified. Vulnerabilities must be mitigated within the appropriate timeframe as described in the Security Assessment Report mitigation plan along with milestones and timelines for remediation for consideration of GSA-IT in order to connect to the GSA network. GSA IT only needs to scan a certain model device once and not for each project. Once the device has completely gone through the remediation process and has a remediation/hardening plan in place, all other projects can use that report to configure the named device accordingly.

Please see Appendix D for “Top Ten Most Common Vulnerabilities in BMC Systems Scans”

Security Evaluation Criteria -The GSA IT Security team performs security control reviews utilizing a systematic, repeatable approach, which is utilized to uniformly evaluate any device, application or general support system.

o The security team reviews basic documentation, performs vulnerability scans, evaluates all items received, and provides feedback to the PBS Requesting Official throughout the review process. Upon completion of the security review the security team is able to determine the extent to which the security controls associated with the device/application (information system) are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the established security requirements.

o The security team works closely with the vendor/manufacturer or the designated device POC, to addresses the security vulnerabilities by reducing or eliminating them as appropriate.

o Upon successful completion of the security review, GSA will have the information needed to determine the risk to agency operations, agency assets, or individuals— and thus, will be able to render an appropriate security decision for the information system.

o GSA IT Security assesses the risk this family of devices poses to the GSA network.

Through vulnerability scanning and reviewing available documentation, the Security team provides a holistic security assessment describing the security posture of such devices. At the discretion of the GSA IT Security’s office, Device scanning will be performed either in the Central Office testing lab, in Washington DC, or in instances where shipping a device is not practicable, on-site via GSA Site Remote Scanning will be performed.

o The GSA IT Security team performs a security evaluation then provides a Security

Assessment Report (SAR) to the appropriate Point(s) of Contact and/or device stakeholders.

o Contact the GSA-IT Security Team BMC.IT.Security@gsa.gov to request the

Scanning Request Form and other information you may need.

Encryption The Federal Information Processing Standard (FIPS) 140-2 (see Appendix B) is a U.S.

government computer security standard used to accredit cryptographic modules, which is necessary in order to to maintain the confidentiality and integrity of the information system.

Once a system has been designed and deployed using FIPS compliant technologies it must be operated following documented procedures to ensure keys are created, stored, retired, revoked and otherwise managed in a consistent and secure manner. All file/data transfers inbound to or outbound from the device or software must be encrypted using FIPS 140-2 compliant protocols, all transfers require user authentication, and the authentication credentials must be encrypted during transmission. Lastly, Control and Monitoring of device operations are to be treated as File Transfer functionality

Wireless All wireless solutions must adhere to the "2100.2B CIO P GSA Wireless Local Area Network (LAN) Security" guide, which mostly covers 802.11 solutions. Additionally, other mailto:BMC.IT.Security@gsa.gov https://en.wikipedia.org/wiki/United_States https://en.wikipedia.org/wiki/Government_of_the_United_States https://en.wikipedia.org/wiki/Computer_security https://en.wikipedia.org/wiki/Standardization https://en.wikipedia.org/wiki/Cryptography 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.

SFTP (Secure File Transfer Protocol) Data Transmission GSA IT has a standard process and a dedicated SFTP for data transmissions. Please see chapter 4 for more details.

Scanned Device List All vendor-provided hardware/controllers and application software must be assessed by GSA IT Security. As items get evaluated by the GSA-IT Security team and receive favorable concurrence by the IT Security Team, they will be added to the Scanned Device List. PBS associates can find the current scanned list at the link above. 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. Please note: this is not to be confused with Government Furnished Equipment (GFE) which is defined in section 1.3.1.

1.4 Non-Standard Software Review Process

Non-standard software is referred to applications that cannot be readily downloaded from the GSA Software Delivery agent, referred to as “DSM”. All non-standard software, that has not yet been assessed by GSA IT, will need to go through the evaluation process.

GSA IT performs an assessment of the non-standard, which focuses on ensuring software (workstation or server) are currently supported, are generally secure and free of vulnerabilities

The following is an excerpt from CIO 2160.1D GSA IT Standards Policy v8 , which has been tailored for BMC systems applications use:

● GSA Order CIO 2160.1D requires GSA’s technology architecture to be based on approved technologies contained in the GSA IT Standards Profile. As such, the GSA Chief Information Officer (CIO) has aligned the IT standards management process with the Agency IT Governance process. The purpose of this is to promote principles of security, performance, innovation, interoperability, efficiency, resource sharing, and sustainability.

● Information technologies can only be used in GSA’s IT environment when approved by GSA IT after it has been reviewed against all relevant IT standards.

● Before being considered as an IT standard, the requested IT must meet GSA’s security and legal requirements using formal review processes.

● The GSA Standard Desktop Image, agency-wide Blanket Purchase Agreements, and other operational lists of technologies must align with the GSA IT Standards. Information technologies require a GSA- approved ―terms of service‖ agreement for use in GSA.

● GSA program managers and contracting officials are responsible for including language requiring a determination of compliance to the GSA IT Standards in appropriate goods and services acquisition documents. Information Technologies acquired through any means – including but not limited to formal contract vehicles, credit cards, or open-source

– must comply with the GSA IT Standards. IT services that are externally provided, such as by third parties, must be interoperable with the GSA IT Standards.

● Only those Information Technologies listed as a GSA IT standard or fitting within the scope of a conditional-use approval are authorized for use; those not listed or not fitting within the scope of conditional use are subject to removal.

https://insite.gsa.gov/portal/content/655974 https://insite.gsa.gov/portal/content/655974 https://gsa.my.salesforce.com/06930000002OvWb https://gsa.my.salesforce.com/06930000002OvWb

1.4.1 EARC Evaluation of Non-standard Software

The software evaluation process consists of legal and IT Security evaluation. The Enterprise Architecture Committee, (please note: the letter “R” does not stand for a word, it was placed in the abbreviation to distinguish it from another group called EAC) takes input from both legal and IT and makes a final decision on whether that software is approved for wider use at GSA. The EARC has representation from GSA IT Building and Energy Systems Team. During the review process, the software requester (you) may be contacted with additional business questions when needed. Typical questions include:

"how many people will use the software", "What is the cost and is it recurring", and "whether any already approved alternatives were considered".

The software review process is kicked off by a catalogue request on ServiceNow. Please be sure to keep your Building and Energy Systems Technical Project Manager included in the process so that they can ensure it goes through the appropriate reviews. Here’s a link which shows how to submit a software request.

For a software to be added to the "GSA IT Standards Profile" it has to reviewed and approved by Legal, Security and EARC. Please note: this is not an Approved Products

List. This only lists the software that has gone through the review process and has been approved for use in the GSA environment. Once software has been permitted for use, the requester will be notified and it will be added to the GSA IT Standards Profile. The overall duration of the above process can take anywhere between ~2-6 weeks.

Legal Review of the End-User License Agreement (EULA) The End-User License Agreement (EULA) needs to be made available to GSA IT Building and Energy Systems Team before contract is signed for evaluation and acceptance. A soft copy of the embedded EULA needs to be emailed to the Building and Energy Systems team. The B&E Systems Team will then submit the EULA to be approved by the Office of General Counsel (OGC). The OGC reviews terms of service and determines whether or not any of the terms need to be modified or eliminated before the government can agree. Please see EULA fail chart and details in Chapter 5.

Security and Testing of Non-Standard Software o The software must adhere to the United States Government Configuration Baseline (USGCB) and be able to operate under a user context (i.e. does not need local admin rights to run).

o GSA IT will test the client software to ensure it integrates properly with the standard GSA image. Upon testing of the software by GSA IT, any requested changes to the software for compliance or compatibility reasons, must be made prior to acceptance.

o The length of this review process is dependent on the changes required in the EULA and changes (if any) to the software prior to installation.

o Projects need to ensure that only approved software is installed at their building which will ensure that it will work with the GSA image and pass security assessment. Local Support’s ability to address client software issues on BSN Consoles (See BSN Section 1.7 below) will be limited and can almost never be provided remotely.

https://gsa.service-now.com/GSA_Self-Service/software.do https://insite.gsa.gov/portal/content/686474 https://ea.gsa.gov/EAWEB/#!/itstandards

Figure 1-1: Nonstandard software Approval Process

1.4.2 Non-standard software on GSA workstations

If there is a need to install a non-standard software on a GSA workstation, discuss the application need with your Building and Energy Systems Technical Project Manager. If the software has not yet gone through the EARC evaluation process, then it will need to be completed before the software is installed. If software has been previously approved, then the request for install can be initiated through a catalog request on ServiceNow: Service Catalog > Equipment Requests > Software Requests >Software.

1.4.3 Non-standard software on GSA servers

The software approval process also applied to BMC server applications. The only difference is that servers are hardened before they are deployed and made available to the project.

1.5 Security Assessment and Evaluation Process for BMC Systems Devices Information technology systems which will be placed in GSA buildings are required to be evaluated against GSA IT policy compliance requirements.

Systems unable to compensate to new issues discovered by the assessment process, risk suspension of their Authorization to Operate in the Federal Government. Please note: GSA IT highly recommends that contracts for products and services should include warranties https://insite.gsa.gov/portal/category/539218 https://gsa.service-now.com/ https://gsa.service-now.com/catalog_home.do?v=1&sysparm_catalog=e0d08b13c3330100c8b837659bba8fb4&sysparm_catalog_view=catalog_Service_Catalog https://gsa.service-now.com/catalog_home.do?v=1&sysparm_catalog=e0d08b13c3330100c8b837659bba8fb4&sysparm_catalog_view=catalog_Service_Catalog https://gsa.service-now.com/com.glideapp.servicecatalog_category_view.do?v=1&sysparm_parent=9f371232f8087000ce3de67bda527132&sysparm_no_checkout=false&sysparm_ck=d235d3986f3e0e00ca0c5d412e3ee4ba3e3a29a15ab94c6b624a4a124dc5aaf6c1a55971&sysparm_catalog=e0d08b13c3330100c8b837659bba8fb4&sysparm_catalog_view=catalog_Service_Catalog https://gsa.service-now.com/com.glideapp.servicecatalog_category_view.do?v=1&sysparm_parent=b628125b7cec0100a6e757fe35f45fb8&sysparm_no_checkout=false&sysparm_ck=d235d3986f3e0e00ca0c5d412e3ee4ba3e3a29a15ab94c6b624a4a124dc5aaf6c1a55971&sysparm_catalog=e0d08b13c3330100c8b837659bba8fb4&sysparm_catalog_view=catalog_Service_Catalog and support, therefore vendor would be responsible for any maintenance and support of their devices and language to this effect should be included in the contract.

1.5.1 GSA IT Security Scanning Process

In order to be used in a production environment, a scan must be complete, and vulnerabilities either remediated or have an Acceptance of Risk (AOR) by GSA IT’s Authorizing Authority. Please note: scans are authenticated and have a process in place to securely pass authentication data.

There are two methods to get scans completed:

In IT Security test lab or;

On-site via GSA Site Remote Scanning.

IT Security Test Lab Scan In order to request a scan, the Scan Request Form located on Google Site must be completed, before the device is shipped to GSA IT Security to be scanned. The site is available to anyone with access to the GSA network. To access the scan request form, click the “Assessment Request Form” link. Scan request forms must be complete in order to be approved, and all relevant documentation (installation manual, configuration management plan, hardening guide) for the device should be supplied along with the form. At the end of the Scan Request, there is a link that instructs you to attach files to a shared Google folder.

Please be sure to include the exact device name (as it appears in the scan form) to associate the documents with the scan request form.

The device should be sent to the GSA IT 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 IT Security team is not permitted to work with any electrical wiring, and any device that cannot immediately be plugged into a 110V wall plug will be delayed (either returned for proper configuration, or on hold until someone can come to the lab and configure appropriately).

NOTE: Any configuration required by IT Security or lack of documentation may result in delaying the security evaluation process. If you have any questions regarding this process feel free to contact BMC.IT.Security@gsa.gov

The device should be shipped to the following address:

ATTN: Bernard Ellsworth U.S. General Services Administration GSA IT Security 1800 F Street NW, Seat (1475B) Washington, DC 20405-0001

For more details on the assessment process, please visit InSite.

GSA Site Remote Scan As with test lab scan, a Scan Request Form must be completed, in order to request a remote scan. Any relevant documentation should be submitted along with the form.

Project manager, the building manager or the regional GSA-IT manager must coordinate with the Network Operations (NetOps) team to ensure that a secure VLAN segment has been set up and identify the port to plug device(s) in for remote scanning by GSA IT Security team.

Coordination must be established between the site and the GSA IT Security team to provide the required testing and evaluation of any new device.

If you have any questions regarding this process feel free to contact https://insite.gsa.gov/portal/content/655934 mailto:BMC.IT.Security@gsa.gov mailto:BMC.IT.Security@gsa.gov https://insite.gsa.gov/portal/content/655934

BMC.IT.Security@gsa.gov NOTE: Test lab scans are always preferred over a remote scan, due to the additional logistical hurdles involved in coordinating remote scans.

Manual Assessment and Evaluation Manual assessment of devices include , ensuring the device is:

● Properly configured- services and configurations should be as it will be installed at the field site.

● Properly constructed - fully assembled device as we do not complete any wiring of connections or have power supplies .

● Properly documented- documentation such as device Installation manual, configuration Management Plan and Hardening Guide are sent or emailed to GSA IT before device is scanned.

If any of these items are missing, GSA IT will return the device without scanning it.

1.5.2 Security Assessment Report

Upon completion of the security review, a Security Assessment Report (SAR) is provided.

The SAR includes the assessment results identifying potential security vulnerabilities.

Vulnerabilities are categorized into risk levels (High, Moderate, or Low). The GSA IT Security team provides recommendations for correcting or mitigating the identified issues.

The result of each scan will be provided as part of the final assessment report. The SAR is sent to the vendor, regional Point of Contact (POC) and any other stakeholder authorized to view the report. The GSA IT Security Team then updates the Device Evaluations status page on InSite (GSA’s intranet) once a device which has been evaluated, with non-sensitive information.

1.5.3 Issues Identified During Security Evaluation

Issues identified from a security review must to be addressed by the vendor or appropriate service provider. The GSA IT Security team will provide guidance.

Vulnerabilities should be mitigated by fixing the identified weakness or, if not possible to mitigate, the device/system owner must request that the Authorizing Official (AO) accept the risk the device/system would impose on the GSA network. Each vulnerability (High, Moderate or Low) must be mitigated Per GSA security policy, CIO P 2100.1. all High and Critical risk findings should be mitigated in 30 days and Moderate risk findings in 90 days.

If remediation process goes beyond this time limit, then an Acceptance of Risk needs to be completed by the project and signed by the Authorizing Authority.

1.5.4 Post-Scan Follow Up

Once the SAR is sent, the IT Security team, in coordination with GSA IT and project POCs, will schedule a conference call to follow up with the vendor and/or designated POC to develop a plan of action to address the security findings. The vendor and/or POC is responsible for remediating vulnerabilities. If there are no fixes to resolve the vulnerabilities, or if the vendor fails to engage with GSA IT (within six months of assessment), then the device will be deemed as “non-remediated”. Such devices are not acceptable on the GSA network. If a fix becomes available or if the vendor re-engages with GSA IT, for a non-remediated device, then it will need to go through the assessment process again.

Roles and Responsibilities

Building and Energy System Team’s PM – Communicates scanning requirements to the project team. Also coordinated scan kick off meeting between project team, vendor and GSA IT Security. This meeting is a chance for IT Security to understand a little more about the device and discuss process and expectations.

Regional POC - This is the main POC of the project that will using the device in question. The POC must ensure Scan Request form is filled, proper documentation is included and device is properly configured and sent to IT Security. They will also be championing vendor engagement throughout the evaluation and remediation process.

GSA IT Security- performs scan and communicates vulnerabilities to the stakeholders:

o Ensures Scan Request Form is complete and accurate for devices scanned in IT Security Test lab and inform project team members of status or discrepancies.

o For devices scanned at GSA site, ensures connectivity and account access to device once Regional POC confirms device is ready.

Inform project team members of status or issues and work with regional GSA-IT or NetOps team to resolve.

o Scan device upon successful connectivity and access.

o Writes and send report to Vendor and Region POC (CC rest of

Project Team) upon completed scans.

o Follows up with Vendor and Region POC in order to review and implement remediation strategies

Vendor o Provides POC to GSA IT Security o Provides device documentation to IT Security o Provides IT Security shipment tracking number (if device is sent) o Remediates device - engages with GSA IT and provides remediation documentation and strategies until GSA IT deems devices “remediated”.

1.5.5 Building Technology Device Scanning and Vulnerability Remediation Process

Notification of Receipt and Acceptance for Induction - The GSA IT Security Team will evaluate the device, documentation, scan request form, and any other required item to determine if it has what is necessary to perform a scan on the device. The device will then be inducted into the scanning process and proceed to the next defined step; or it will be rejected for scanning until the required items are provided.

In those cases, the Acceptance for the induction phase will begin again

Induction and Scanning – The GSA IT Security team will initiate and complete all required scans of the device.

Creation and Distribution of the Security Assessment Report (SAR) – The GSA IT Security team will take the results of the scans and write a SAR. The SAR will clearly detail the specific security vulnerabilities associated with the device, and identify the level of risk associated with them. The SAR is considered sensitive and will be provided encrypted to the PBS Project Manager and the vendor/manufacturer point of contact associated with the integration and use of that device. A password for that report can be received by placing a call to the GSA IT Security team.

Scheduling and Conducting a Review of the SAR with Stakeholders – The GSA-

IT Building and Energy Systems project manager, in coordination GSA IT Security will attempt to schedule a conference call with the PBS Project Manager and the appropriate vendor/manufacturer points of contact to kick off the review process and work with the project team and vendor/manufacturer to frame an agenda for the remediation of the vulnerabilities and/or risk associated with the scanned device. The remediation process is largely the responsibility of the vendor/manufacturer and the PBS project manager. The GSA IT Security Team will provide guidance and assessment during the remediation process.

Response from the Vendor/Manufacturer – We are recommending that the vendor/manufacturer provide a response back to the GSA IT Security team and their PBS Project Manager, which details how they plan address each of the identified vulnerabilities and/or their associated risks, as well as a timetable for when that plan will be executed

GSA IT Security Follow-Up Response – The GSA-IT Security team will review and provide feedback to the vendor/manufacturer regarding their aforementioned response to the SAR and remediation work plan.

Successful Remediation of Identified Vulnerabilities - The successful remediation of the vulnerabilities and their associated risks, which may be required for that device to be given approval to operate on the GSA network will be largely driven by the vendor’s/manufacturer’s initiative and effort. The GSA IT Security team is committed to prompt responses to the vendor’s/manufacturer’s inquiries and attempts to satisfy our Agency’s IT Security policies.

1.6 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 needs to be met in order for access to be granted.

1.6.1 HSPD-12 Credentialing and Systems Privileges

On August of 2004, President George W. Bush signed the Homeland Security Presidential Directive-12 (HSPD-12) which is a mandated a Policy a 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 and contractors or personnel who require routine or regularly scheduled access to federally controlled facilities and information technology (IT) systems.

Please visit http://www.gsa.gov/portal/category/26432 for details on how to initiate the credentialing process.

ENT domain credential and VPN access require HSPD-12 clearance. Please note:

Regional Project Teams need to ensure Vendor personnel maintain their ENT accounts and keep them active, in order to be able to provide technical support going forward. This includes timely completion of all tasks required to keep an ENT account active, such as annual IT Security Training courses.

The mandatory minimum security clearance level for access to any GSA IT system is the preliminary adjudication of the National Agency Check with Written Inquiries (NACI);

http://www.gsa.gov/portal/category/26432 however, the actual final clearance level needed is dependent on the security level of the data or systems being accessed by the individual. If the completed clearance process does not result in final favorable adjudication, previously granted provisional access will be revoked. The process to obtain this clearance can be found at insite.gsa.gov, Information Technology/Access Card Implementation/Policy and Guidance Resources. Personnel Security management is the responsibility of the requesting official.(Please see Appendix B for more information.)

Please note: per OMB mandate M-06-16 and GSA order CIO P 2181.1 , “those individuals whose duties require a higher degree of trust, such as IT system administrators, those who handle financial transactions, or those who deal with PII, and other sensitive information (e.g., building drawings, etc.), will continue to require investigations associated with higher levels of trust such as the Minimum Background Investigation (MBI) or the Limited Background Investigation (LBI).” This means individuals who will need administrative access to BMC servers will need to have an MBI clearance.

Lastly, per GSA order 2100.1J, “authentication schemes for Moderate and High Impact systems must utilize multi-factor authentication using two or more types of identity credentials (e.g. passwords, SAML 2.0 biometrics, tokens, smart cards, one time passwords) as approved by the Authorizing Official and in accordance with the security requirements”. This means in order to gain elevated access to BMC systems, once MBI adjudication is completed, individuals will need to get a Shortname Account (SNA) and a token. Request for SNA and token can be submitted by the sponsor on ServiceNow > Service Catalog > Account Services > New Account or Access Requests >GSA Short Name Account

1.7 Building Systems Network (BSN)

As this chapter describes, there are Federal and GSA specific IT security policies and standards that apply to the purchase and/or use of any IT-related product or service. Any piece of hardware or software that does not meet these standards is thereby introducing a certain amount risk through the ownership and/or use of that system or component.

Particularly those devices that are enabled for IP-based network communication are treated with the most caution, as they have the ability to impact and be impacted by other IP-based systems, which are the most prevalent types of systems associated with GSA’s IT environment.