APPENDIX A - NIWTP - System_Hardening_Requirements.docx

APPENDIX A

System Hardening Requirements for Contractor Installing Security/Camera System at NIWTP.

To the extent that these hardening controls do not prevent the full functionality of the Security system, the contractor shall configure them and document their presence in the delivered system. Hardening requirements shall be present in the following components:

1. IT Hardware and Software Requirements All hardware and software components that are installed as part of this install will follow these specific guidelines. The contractor will also need to apply these guidelines to any existing hardware and software that will remain as part of the new system install. The delivered system will also have all of the controls, policies and programs in place prior to delivery and acceptance of the system.

1.1 System Hardening

System hardening refers to making changes to the default configuration of a network device and its operating system (OS), software applications and required third-party software to reduce system security vulnerabilities.

Unused services in a host operating system that are left enabled are possible entry points for exploits on the network and are generally not monitored because these services are not used. Only the services used for control systems operation and maintenance shall be enabled to limit possible entry points.

Often, networked devices ship with a variety of services enabled and default operating system programs/utilities pre-installed. These range from system diagnostics to chat programs, several of which have well-known vulnerabilities. Various attacks have been crafted to exploit these services to obtain information leading to compromise the system.

Any program that offers a network service that “listens” on specific addresses for connection requests. On a Transmission Control Protocol (TCP)/Internet Protocol (IP) network, these addresses are a combination of IP address and TCP or User Datagram Protocol (UDP) ports. A recommended hardening activity is simply disabling or removing any services or programs, which are not required for normal system operation, thus removing potential vulnerabilities.

Post-contract award, the Contractor shall provide documentation detailing all applications, utilities, system services, scripts, configuration files, databases, and all other software required and the appropriate configurations, including revisions and/or patch levels for each of the computer systems associated with the control system.

The Contractor shall provide a listing of services required for any computer system running camera applications or required to interface with those applications. The listing shall include all ports and services required for normal operation as well as any other ports and services required for emergency operation. The listing shall also include an explanation or cross reference to justify why each service is necessary for operation. The Contractor shall verify and provide documentation that all services are patched to current status.

The Contractor shall provide, within a pre-negotiated period, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security.

The Contractor shall remove and/or disable all software components that are not required for the operation and maintenance of the camera system. The Contractor shall provide documentation on what is removed and/or disabled. The software to be removed and/or disabled shall include, but not be limited to:

1. Games

1. Device drivers for network devices not delivered

1. Messaging services (e.g. MSN, AOL, Yahoo Instant Messenger)

1. Servers or clients for unused Internet services

1. Software compilers in all user workstations and servers except for development workstations and servers

1. Software compilers for languages that are not used in the control system

1. Unused networking and communications protocols

1. Unused administrative utilities, diagnostics, network management and system management functions

1. Backups of files, databases and programs used only during system development

1. All unused data and configuration files

1. Sample programs and scripts

1. Unused document processing utilities (MS Word, Excel, PowerPoint, Adobe Acrobat, OpenOffice, etc.)

1. Server OS should be MS Server 2012 R2, 64 bit

The contractor shall provide for each networked device or class of device (e.g. server, workstation and switch/router) the following configuration documentation lists:

1. Network services required for the operation of that device. Indicate the service name, protocol (e.g. TCP and UDP) and port range

1. Dependencies on underlying operating system services

1. Dependencies on networked services residing on other network devices

1. All the software configuration parameters required for proper system operation

1. Certified OS, driver and other software versions installed on the device

1. Results found by the vulnerability scans with mitigations affected

1.2 Hardware Configuration

Unnecessary hardware can be physically disabled, removed, or its configuration altered through software. Most networked devices have multiple communication and data storage capabilities. These can be used to introduce vulnerabilities such as viruses, root kits, malware, bots, key-loggers, etc.

Hardware configuration activities may include configuring the network devices to limit access from only specific locations (e.g., IP filtering) or requiring additional verification of user credentials (e.g., password, personal identification number [PIN], crypto key, or token). Local hardening can require similar verification for protecting system Basic Input/Output System (BIOS) configuration parameters, and limiting system access through local media (e.g., disabling/removing USB ports, CD/DVD drives, and other removable media devices). It may be desirable to physically lock devices with accessible drives or ports, such that only the human-machine interface is accessible. System administrators shall be able to re-enable devices if the devices are disabled by software.

1. The Contractor shall disable, through software or physical disconnection, all unneeded communication ports and removable media drives, or provide engineered barriers, and provide documentation of the results.

1. The Contractor shall password protect the BIOS from unauthorized changes unless it is not technically feasible, in which case the Contractor shall document this case and provide mitigation measures.

1. The Contractor shall provide a written list of all disabled or removed USB ports, CD/DVD drives, and other removable media devices.

1. The Contractor shall configure network devices to limit access to/from specific locations, where appropriate, and provide documentation of the configuration.

1. The Contractor shall configure the system to allow the system administrators the ability to re-enable devices if the devices are disabled by software and provide documentation of the configuration.

1. The Contractor shall provide validation and documentation of the disabled or locked physical access and the removed drivers.

1.3 Installing Operating Systems, Applications and Third-Party Software Updates Patches and software updates, including those for anti-virus scanners, are required to reduce attack surface. Most successful cyber-attacks occur in non-patched systems or applications. Most common operating systems ship with a number of well-known vulnerabilities; even a new system is likely to be vulnerable based on the services that are active and because patches are not likely to be current. Therefore, an essential system hardening activity is simply installing the latest versions or updates of any necessary software loaded on a system. Of course, testing and validation of the patches and upgrades are necessary prior to performing the updates on a production system. Scanning is an effective tool to identify vulnerabilities.

1. The Contractor shall employ a patch management and update process as part of the install.

1. Pre-contract award, the Contractor shall provide details on their patch management and update process. Responsibility for installation and update of patches shall be identified.

1. Post-contract award, the Contractor shall provide notification of known vulnerabilities affecting Contractor-supplied or required OS, application, and third-party software within a pre-negotiated period after public disclosure.

1. Post-contract award, the Contractor shall provide notification of patches affecting security within a pre- negotiated period as identified in the patch management process.

1. The Contractor shall apply, test, and validate the appropriate updates and/or workarounds on a baseline reference system before distribution. Mitigation of these vulnerabilities shall occur within a pre-negotiated period.

1. The Contractor shall install and update all tested and validated security patches at the start of the install. The Contractor shall provide documentation that all the updates have been tested and installed.

1. The Contractor shall verify system functionality, at the conclusion of patch updates, and provide documentation of the results.

1. The Contractor shall perform security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase of the results.

1.4 Account Management (Disabling, Removing or Modifying Well-Known or guest Accounts Account management is essential to properly maintain and secure a network. Account management regulates who has access, limits permission to only those required, and mitigates vulnerabilities in default accounts. It also covers password management. With careful account management, default accounts and passwords, which typically exist in systems and pose a substantial risk, can be eliminated or mitigated.

Control of user access can be broken into three major topics:

1. Authentication. Is the ability to verify an identity based on the following attributes: “what you have” (i.e., key, digital certificate, or smart card), “what you know” (i.e., username and password), and “what you are” (i.e., biometric iris, fingerprint scan, or fingerprints), and/or “what you do” (i.e., dynamic biometric handwriting scan or voice recognition).

2. Authorization. Is the ability to control user permissions within the system to include network access.

Authorization capabilities and processes vary widely between products, from none in the case of an “all-or-nothing” access, to a very specific control of user capabilities in more advanced cases.

3. Accounting. The ability to provide an audit trail of activities within the system. Accounting is typically accomplished through logging activities of significance, such as a login, changing passwords, or making significant system changes. Accounting is related to auditing.

Disabling, removing, or modifying well-known or guest accounts and changing default passwords are necessary to reduce system vulnerabilities. Default accounts and passwords are available on many systems and are often publicly available in published materials allowing unauthorized system access. Default, guest, or anonymous accounts are commonly used to gain limited access and potentially useful system privileges. These can be used in turn to escalate privileges and gain unauthorized access to additional information. Hardening activities to address these concerns include disabling, removing, or modifying such accounts or changing default passwords.

1. The Contractor shall recommend which accounts need to be active and those that can be disabled, removed, or modified. The USIBWC shall approve in writing the Contractor’s recommendation.

1. The Contractor shall disable, remove, or modify all the accounts pursuant to the approved recommendation.

1. The Contractor shall verify that procedures include exercising this functionality, examining the log files, and validating the results.

1. The Contractor shall verify that procedures include written validation and documentation of this requirements.

1. The Contractor shall not introduce any new accounts without explicit requirements to do so by the USIBWC or designated authorized individual.

1. The Contractor shall disable or remove all default and guest accounts prior to delivery of the completed system. Once changed, new accounts will not be published except that new account information and passwords will be provided by the Contractor via protected media.

1. The Contractor shall disable, remove, or modify all Contractor-owned accounts or negotiate account ownership with the USIBWC.

1.5 Session Management

Weak session practices and insecure protocols exist on many systems for convenience, backwards compatibility, and on legacy systems. Unauthorized access can be achieved through clear-text accounts and passwords along with weak session security practices.

Many legacy system utilities transport user credentials in clear text, using protocols such as FTP and TELNET—this is not acceptable. Other weak session practices include concurrent session logins, remembered account information between login, auto-filling of fields during logins, and anonymous services such as FTP. In many systems, you are your account, and once the account is compromised, the system has no way of knowing who is actually using the account.

1. The Contractor shall not permit user credentials to be transmitted in clear text.

1. The Contractor shall provide the strongest encryption method commensurate with the technology platform and response time constraints.

1. The Contractor shall not allow multiple concurrent logins to applications to retain login information between sessions, provide any auto-fill functionality during login, or allow anonymous logins.

1. The Contractor shall provide user account-based logout and timeout settings.

1. The Contractor shall verify that procedures include validation and documentation of the requirements.

1. The Contractor shall not introduce any new session algorithms without explicit requirements to do so by the USIBWC or a designated authorized individual.

1. The Contractor shall change encryption keys at reasonable intervals commensurate with need.

1.6 Password/Authentication Policy and Management

Instant availability requirements in systems often result in a weak password policy. Weak passwords introduce vulnerabilities to the control systems network. In addition, sometimes passwords are hard-coded into software to facilitate system internal communications allowing anyone with access to the code/configuration files knowledge of the password(s). Users often select poor or easily-guessed passwords even with the best of intentions. Commonly, an automated “brute force” attack can be used to guess user passwords by using common dictionary terms, sequential password patterns, and other means, often revealing the correct password within minutes. By enforcing password complexity limits, restricting user-login attempts, and locking out accounts after repeated failed attempts, such attacks can be thwarted.

1. The Contractor shall provide a configurable account password management system that allows for selection of password length, frequency of change, setting of required password complexity, number of login attempts, inactive session logout, screen lock by application, and denial of repeated or recycled use of the same password.

1. The Contractor shall not store passwords electronically or in Contractor-supplied hardcopy documentation in clear text unless the media is physically protected.

1. The Contractor shall control configuration interface access to the account management system.

1. The Contractor shall provide a mechanism for rollback of security authentication policies during emergency system recovery or other abnormal operations, where system availability would be negatively impacted by normal security procedures.

1. The Contractor shall verify that procedures include validation and documentation of the password and authentication policy and management.

1. The Contractor shall not introduce changes to password or authentication policy and management without explicit requirements to do so by the USIBWC .

1.7 Account Auditing and Logging

Account auditing and logging allow the Operator to verify that authorized operations have been maintained. Logging is also necessary for forensic analysis and anomaly detection. Logging and auditing of both active and disabled accounts are useful for anomaly and unauthorized access detection. However, cyber attackers commonly modify audit logs to cover activities. Account logging must provide an audit trail of user activity that allows specific actions to be traced to a single user/process, location, and time in a verifiable manner.

Advanced cyber security attackers will modify log files to make forensics activities difficult. Monitoring of log access will detect malicious modifications. Writing log files to read-only media also prevents malicious modification.

1. The Contractor shall provide a system whereby account activity is logged and is auditable both from a management (policy) and operational (account use activity) perspective.

1. The Contractor shall time stamp, encrypt, and control access to audit trails and log files.

1. The Contractor shall ensure audit logging does not adversely impact system performance requirements.

1. The Contractor shall provide read-only media for log creation.

1. The Contractor shall verify that SAT procedures include validation and documentation of the requirements.

1. The Contractor shall record system performance measurements to verify that logging activities do not adversely impact system performance. The Contractor shall provide a configurable account password management system that allows for selection of password length, frequency of change, setting of required password complexity, number of login attempts, inactive session logout, screen lock by application, and denial of repeated or recycled use of the same password.

1. The Contractor shall not store passwords electronically or in Contractor-supplied hardcopy documentation in clear text unless the media is physically protected.

1.8 Malware Detection and Protection

Malware is any unauthorized software. Because many control networks are connected to other networks or updated by media, malware can enter into the network and affect process control and/or communications. Malware consists of many different types of software and may include, but is not limited to, bots, Trojans, worms, viruses, backdoors, and zombies. Malware detection can occur on a host or a network-based device. Updates to malware detection software may adversely impact control system behavior. Malicious code-worms, viruses, and Trojans can propagate through a control system and potentially impact or curtail operations. In most systems, network-based malware detection can occur on the outer perimeter of the process control network. Perimeter malware detection is common for legacy components since the impact on these components vary. Traditional malware detection and removal software usage involves updating the signatures that identify the malware frequently (normally once a day on highly exposed systems) and continuously scanning incoming files for infected data.

Both of these acts of updating to the latest detection signatures and scanning the files may affect system networks, especially those with legacy components. Manual scanning or scanning files for malware on a scheduled basis is known to use up central processing unit (CPU) resources and may impact other process executions on the host. Active scanning is the process of scanning files only when the files are accessed or modified and have been used in control systems. In-memory scans will detect the presence of malware in memory, which may affect performance of the system. Faulty signature files may impact system files requiring the need for quick roll back of the signatures and restoring the suspected files. Quarantining the files provides a mechanism to perform forensics if malicious code is detected.

1. The Contractor shall record system performance measurements that include the system with and without malware detection.

1. The Contractor shall verify all media and equipment are scanned under the most current malware detection versions available prior to onsite transport.

1. The Contractor shall exercise the malware detection system.

1. The Contractor shall document any known or identified backdoor codes.

1. The Contractor shall provide documentation of the malware detection software retest when significant changes are made to determine possible impacts to performance.

1. The Contractor shall retain malware detection application logs for a pre-negotiated period for possible forensics tasks.

1. The Contractor shall update malware detection software as required to be effective for the most recent malware released since these signatures are reactive. As the malware variants change, new, more precise or tuned signatures need to be applied.

1. The Contractor shall configure the delivered system to automatically update signature files used by the installed malware detection software. If the system is not directly connected to the Internet, a manual procedure shall be developed so local USIBWC employees can keep the installed solution up to date.

1.9 Web-based Interfaces

Many systems have Web-based interfaces for performing some tasks. Web-based interfaces to control system components are often poorly designed and configured, making these interfaces vulnerable to exploits. Web applications are often vulnerable to injection attacks of several varieties including command injection, Remote File Include (RFI) and Cross-Site Scripting (XSS). Web applications with a database back-end commonly mishandle Structured Query Language (SQL) statements as well, allowing SQL injection. In addition, the HTTP servers on which these applications are hosted can be vulnerable to buffer overflows or other memory corruption attacks. Another common mistake in Web applications is directory traversal, which allows attackers access to more files than the programmer intended. Web applications in embedded devices are often written in a low-level language like C and are potentially vulnerable to buffer overflows.

1. The Contractor shall provide physical and cyber security features including, but not limited to, authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the system from unauthorized modification or use.

1. The Contractor shall clearly identify the physical and cyber security features and provide the methodologies for maintaining the features including the methods to change settings from The Contractor-configured or manufacturer default conditions.

1. The Contractor shall verify that the addition of security features does not adversely affect connectivity, latency, bandwidth, response time, and throughput.

1. The Contractor shall remove or disable all software components and services that are not required for the operation and maintenance of the devices that run an HTTP server. The Contractor shall provide documentation on what is removed and/or disabled.

1. The Contractor shall provide appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security.

1. The Contractor shall provide documentation of input sanitization for all Web-form inputs including, but not limited to, measures for prevention of command injection, SQL injection, directory traversal, RFI, XSS, and buffer overflow.

1. The Contractor shall follow secure coding practices and reporting for all Web-based interface software. This requirement includes both Web applications and Web servers.

1. The Contractor shall provide user configurable and managed passwords

1. The Contractor shall verify and provide documentation of and changes to physical and cyber security features including, but not limited to, authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the system from unauthorized modification or use.

1. The Contractor shall create a baseline of all communications to and from any device running an HTTP server and configuration including, but not limited to, cyber security features, Web-based interfaces, software, protocols, ports, and services and provide documentation describing any changes.

1. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed.

1. The Contractor shall verify and provide documentation that all unused software and services are removed or disabled.

1. The Contractor shall create a new baseline of all Web-based interfaces and provide documentation explaining any changes to the functionality of each interface.

1. The Contractor shall provide, within a pre-negotiated period, upgrades and patches to the Web applications as security issues are identified to maintain the established level of system security.

1. The Contractor shall validate permissions and security settings on the baseline system before delivery of any upgrades or replacements to maintain the established level of system security.

1. The Contractor shall supply maintenance capabilities for delivered system security features.

1. The Contractor shall document all additions and changes to the remote access equipment during the warranty/maintenance period.

1.10 Wireless Closed-Circuit TV Technology

Wireless closed-circuit TV (WCCTV) is a technology that uses video cameras and wirelessly transmits a visual signal to a specific, limited set of monitors. WCCTV is often used for surveillance in areas that need monitoring. Because of infrastructure, terrain, or immediate need, wired video systems are often inadequate, making wireless video systems a viable option. Because WCCTV devices transmit wirelessly, they are subject to interception, modification, or destruction of the signals, and care should be taken with their configuration and use.

In industrial plants such as the SBIWTP and NIWTP, WCCTV systems may be used to observe parts of a process that are remote from a control room, or where the environment is not comfortable for humans. WCCTV systems are also used for intelligence gathering, in contaminated environments, and for training purposes.

A WCCTV system is less dependent on the environment and infrastructure. It can be installed and moved with less difficulty, giving it an advantage in temporary or short-term applications.

The visual signal may be transmitted using wireless technology in combination with the IP, rather than transmission over traditional analog frequencies. A typical IP video network includes both fixed and pan-tilt-zoom (PTZ) cameras (i.e., either IP cameras or analog cameras attached to IP encoders), network video recorders (NVR) and viewing platforms. The use of video, in combination with data and voice, has a tremendous impact on network design and performance because of bandwidth, latency, and jitter requirements. The bandwidth necessary for the network varies based on the resolution, frames per second (fps) desired and codec used, as well as the motion content of the video.

1. The Contractor shall provide the WCCTV system and associated documentation.

2. Post-contract award, the Contractor shall provide specific protocols and other detailed information required for the WCCTV to communicate with the network, including other wireless equipment that can communicate with the WCCTV.

3. The Contractor shall provide documentation on the range of the WCCTV, power requirements, and the designated frequency of operation for each device.

4. The Contractor shall provide, within a pre-negotiated period, any test data with analysis associated with the mobile radio.

5. The Contractor shall provide the USIBWC procedures that include exercising all functionality and calibration procedures.

6. The Contractor shall document the equipment configuration.

7. The Contractor shall provide configuration specifications for implementing encryption and authentication between the cameras and the network and specifically note all security measures associated with the system.

8. The Contractor shall provide multiple levels of Quality of Service (QoS) that enable customization for specific mission-critical applications.

9. The Contractor shall provide advanced video compression techniques, such as MPEG4 and H.264, which can dramatically reduce the bandwidth requirements for video.

10. The Contractor shall supply current system configuration to the USIBWC to allow traceability and to ensure no extra services are installed.

11. The Contractor shall supply written maintenance guidelines for the device, including a timeline, maintenance equipment required, and as-installed parameters and settings.

12. Prior to install, the Contractor shall provide upgrades and patches to all wireless devices in order to maintain the identified level of system security.

1.11 802.11 Technology The reference, 802.11, refers to a family of specifications developed by IEEE for wireless local area network (WLAN) technology. It specifies a wireless interface between a wireless device and a base station (access point) or between two wireless devices (peer to peer). 802.11 devices operate in the 5 GHz and 2.4 GHz public spectrum bands. Because these transmissions are through the air, these can be intercepted or interfered with by those having the proper equipment.

There is only one current 802.11 standard. It is denoted by IEEE 802.11 followed by the date that it was published. The standard is updated by means of amendments. When a wireless device is referred to as 802.11x, x is an amendment to the original 802.11 standard. As of this date, IEEE 802.11-2007 is the most current 802.11 document available and contains cumulative changes (802.11a,b,d,e,g,h,i,j) from multiple subletter task groups. Care must be exercised when defining the 802.11 standard in procurement documents to be sure of the latest version.

The 802.11 standard, hereafter referred to as 802.11, defines the MAC and physical layers for a LAN with wireless connectivity where the connected devices are within close proximity to each other.

The Basic Service Set is the basic component of an 802.11 wireless LAN. The Basic Service Set consists of a group of stations. The station is the basic component of the WLAN. It is any device that provides the 802.11 protocol (MAC, physical layers, and a connection to the wireless device). The station might be a personal computer, handheld device, or an access point and may be mobile or stationary.

Security is provided by encryption, authentication, and configuration control. The encryption methods used are Wired Equivalent Privacy (WEP), WiFi Protected Access (WPA), or WPA2. WEP can be easily intercepted and decoded. Numerous free software tools exist to aid in such endeavors. Due to these weaknesses, enhanced security was introduced for Wireless Fidelity (WiFi) networks through the WPA protocol. The security of connections using this protocol depends largely on the strength of the usersupplied pass-phrase. Free software and descriptions of how to attack these connections also are available online. Improving upon previous security implementations, the WiFi Alliance released the WPA2 standard, which uses a stronger encryption algorithm.

Despite the availability of strong encryption for user communication, the management frames of IEEE 802.11 messages are not encrypted, leaving the door open for DoS attacks. Several tools are available that can cause users to drop off the network or send messages to hamper the functionality of wireless end points. Such tools include WiFi jammers, designed to block IEEE 802.11 transmissions, and rogue access points, that are set up in hopes of attracting connections then stealing sensitive information or altering communications. Adding to and enabling attacks is the fact that WiFi access points are often set up quickly and without security foresight. This results in the use of weak or no encryption, allowing attackers to impersonate wireless end points in hopes of providing false data. It also may result in users not changing default passwords for device management, allowing attackers to gain full control of the access point as default passwords are common knowledge.

Recently, researchers have considered the possibility of worms that use the aforementioned security weaknesses to propagate on the local network. Such malicious code would rely on two assumptions to propagate. First, in urban settings, numerous WiFi networks exist within close proximity of one another. Second, that victim machines are configured to connect to multiple networks.

1. The Contractor shall provide the WiFi device, meeting the requirements of the required sections of IEEE 802.11, and associated documentation.

2. Post-contract award, the Contractor shall provide specific protocols and other detailed information required for the WiFi device to communicate with the network, including other wireless equipment that can communicate with the Contractor-supplied device.

3. The Contractor shall provide documentation on the range of the WiFi device, power requirements, and the designated frequencies of operation for each device.

4. The Contractor shall allow and recommend alarm settings in accordance to the needs of the system.

5. The Contractor shall define interoperability limits for the WiFi device specifically stating the devices that could be replaced and any associated problems that might be associated with the replacement.

6. The Contractor shall provide, within a pre-negotiated period, any test data with analysis associated with the WiFi device.

7. The WiFi device shall be provided with security devices, such as passwords or security codes, to protect the device from unauthorized modification or use. The Contractor shall clearly identify these security devices and methods to change them from the Contractor-configured or manufacture default conditions.

8. The Contractor shall provide the WiFi device with the standard security measures as specified in the 802.11 standard and support the required level of encryption.

9. The Contractor shall remove or disable all software artifacts that are not required for the operation and maintenance of the device.

10. The Contractor shall provide the USIBWC procedures, which include exercising all functionality and calibration procedures.

11. The Contractor shall document the equipment configuration and specifically note any security measures associated with the system (encryption devices, password protection, etc.).

12. The Contractor shall identify the configuration control options that enable varying of the security level of the device.

13. The Contractor shall demonstrate that cooperative WiFi nodes can distinguish jamming from channel saturation and provide operational alerts.

14. The Contractor shall provide test data with analysis showing that basic attacks such as malformed packet injection, do not cause the WiFi device to crash, hang, or otherwise malfunction.

15. The Contractor shall verify compatibility of the WiFi device with other interfaced devices.

16. Any Contractor-configured or manufacturer default usernames, passwords, or other security codes must be change. The Contractor shall ensure procedures include written validation and documentation of this requirement.

17. The USIBWC shall perform testing to analyze the potential for radio frequency interference, determine adequate wireless LAN coverage, and set configuration parameters properly.

18. The Contractor shall supply current system configuration to the Purchaser to allow traceability and to ensure no extra services are installed.

19. The Contractor shall supply written maintenance guidelines for the device, including a timeline, maintenance equipment required, and as-installed parameters and settings.

20. The Contractor shall provide upgrades and patches to the WiFi device as vulnerabilities are identified in order to maintain the identified level of system security.

21. The Contractor shall configure MAC address filtering to any WiFi camera.

22. The Contractor shall verify that the installed system meets these specified requirements.