DoS LTL .pdf

DOS Less-than-Lethal Defensive System Requirements Matrix

Req # Requirement Description

General System Requirements

G1 Shall comply with prohibitions on using hardware, software, and services from named countries and manufacturers. (Ref FAR 4.2 and 4.21).

G2 Shall be manufactured or substantially transformed in the United States or a Trade Agreements Act (TAA)-designated country. (Ref

FAR 52.225-5).

G3 Shall be compatible with 100 VAC - 250 VAC – 50 Hz/60 Hz input power (objective), 12/24 VDC (threshold) or PoE (threshold).

G4

Shall be electromagnetic compatibility (EMC)-compliant IAW CFR47, Part 15 Class A, (FCC requirements for radiated and conducted emissions) or equivalent U.S.-recognized international standard.

G5 Shall be UL-approved for electrical safety per IEC 62368.

G6 Shall not be Cloud based.

G7 Shall not be Wi-Fi based.

G8 Shall not be Bluetooth (or similar technology) based.

G9 Shall not be Near-field communication (NFC) based.

G10 Shall not require an outward facing internet connection for programming, operation or updates.

G11 Shall be commercial-off-the-shelf (COTS) (objective), modified COTS (threshold), or custom using a majority of COTS components (threshold).

G12 Shall be able to continuously operate in deterrent mode for 8 hours (objective), 2 hours (threshold).

G13 Shall be capable of escalating the deterrent response.

DOS Less-than-Lethal Defensive System Requirements Matrix

Req # Requirement Description

General System Requirements

G14 Shall be capable of performing a walk test of the system without dismantling or reconfiguring any edge devices.

G15

Shall not require the OEM to perform the installation, initialization, or commissioning of the system. System shall be configured in a manner that allows OEM trained DOS staff to perform all installation, initialization, and commissioning tasks.

G16

Shall not require the OEM to perform preventive or corrective maintenance of the system. Shall be able to be serviced and repaired by DOS technicians, trained by the train-the-technician requirement (see VS7).

Deterrent Component Requirements

DC1 Deterrent method shall be of a less-than-lethal design.

DC2

Shall be operational through a temperature range of -40 °C to +60 °C (-40 °F to 140 °F) at up to 95% humidity above freezing temperatures.

DC3

Shall be able to operate in sheltered but indirectly wet environments.

DC4

The deterrent components shall present a low visual impact that can easily blend with surrounding surfaces.

DC5

The deterrent components shall be able to be installed in both indoor and outdoor environments.

DC6

Shall be capable of being mounted to building or perimeter surfaces, not personnel-carried or vehicle-mounted.

DC7

Shall not use chloroacetophenone (CN), o-chlorobenzylidenemalononitrile (CS), or dibenzoxazepine (CR)

Deterrent Component Requirements

DC8 Shall not use bullets, canisters, or similar projectiles of any kind.

DC9

Outlying and intermediate components of the system shall have auxiliary dry contacts that allow for activation of third-party devices.

Control Console Requirements

(If a control console is proposed.)

[Note: some requirements only applicable to a digitally controlled console]

CC1

Shall occupy a 19” wide rack panel with no more than 6 RU (10.5 in.) of rack height. The rear of the rack space may be used for components supporting the control console.

CC2

Shall be operational through a temperature range of -0 °C to +60 °C (32 °F to 140 °F) at up to 95% humidity at above freezing temperatures in an indoor environment.

CC3 Shall not be of a desktop or stand-alone rack design.

CC4

If the control console uses a digital display, it shall be a touch screen (objective) or a screen with pushbuttons (threshold) and be mountable within the rack. A pull-out, or tilt-up display is not permissible.

CC5

Shall include a system “Power On” indicator. Indicator may be a digital display that is energized and in stand-by mode.

CC6

Shall not require a keyboard or mouse for activation/deactivation.

The use of a keyboard and mouse shall be limited to initial setup and local administrator level system configuration changes.

CC7

Shall have a mechanical (objective) or electronic (threshold) safeguard that prevents inadvertent activation of the system and that functions within the control console hierarchy. An electronic safeguard shall not employ any additional device such as a pass-card, physical key, electronic fob, phone verification, or similar.

Control Console Requirements

(If a control console is proposed.)

[Note: some requirements only applicable to a digitally controlled console]

CC8

Shall have a mechanical (objective) or electronic (threshold) emergency disable that will cease all system operations, that will return all prior operational selections to nominal, and that functions within the control console hierarchy.

CC9

Shall have deterrent selection control labels that are user definable.

CC10

Shall have the capability to display zone status (not selected, selected) and when it has lost communication.

CC11

Shall have the capability to allow a one button selection/deselection of all zones.

CC12

Shall allow for a hierarchy in which one control console acts as the primary over all other control consoles and any remaining control consoles that have different lower priorities in the hierarchical structure.

CC13

Shall allow for a higher priority control console to select and lock/unlock lower priority control consoles.

CC14

Shall be capable of being installed remotely from the outlying deterrent components.

Incident Reporting Target Requirements

(If an Internet Protocol [IP]-based system is proposed)

IR1

Shall log the following events: activation, deactivation, zone enable, zone disable, system error, deterrent level, local console login, local console logout, and local console changes.

Incident Reporting Target Requirements

(If an Internet Protocol [IP]-based system is proposed)

IR2

Shall log, at a minimum, the following information for activation log entries: system date/time, type of log entry, command originator, source, system deterrence level, zone, auxiliary contact status.

IR3

Shall log, at a minimum, the following information for deactivation log entries: system date/time, type of log entry, command originator, zone, auxiliary contact status.

IR4

Shall log, at a minimum, the following information for system error log entries: system date/time, error device, error type, affected zones.

IR5

Shall log, at a minimum, the following information for local console change: system date/time, change originator, type of change, parameter changed, parameter old value, parameter new value.

Security/Information Assurance Requirements

(If an IP-based system is proposed)

SIA1

Shall support Microsoft Active Directory authentication for IP-based components.

SIA2

Shall support role-based access that will allow the capability for customized roles. TDB will supply a role-based matrix based on permissions.

SIA3

Shall allow configuration of the Active Directory server parameters to be modified from the local console and the web-enables client.

SIA4

Shall support the use of a fully qualified domain name as the authentication provider.

SIA5

Shall not have local user password expiration, that is, the password will not expire.

Security/Information Assurance Requirements

(If an IP-based system is proposed)

SIA6

Shall provide the ability to lock out access to the system either locally or remotely. The lock-out time should be based on lock-out duration and failed login attempts, variables set by the administrator.

SIA7

Must support encrypted and password-protected administrator login to the system using Hypertext Transfer Protocol Secure (HTTPS) in a browser.

SIA8

Shall support an administrator-assigned user passcode which allows quick access by the daily user to the functional controls of the system.

SIA9 Shall be able to accept and use customer-assigned certificate.

SIA10

Management system shall operate on current operating systems, e.g., Windows 10/11, Red Hat Enterprise Linx (RHEL).

SIA11

Shall use approved Department of State (DOS) single sign-on for authentication, e.g., Public Key Infrastructure (PKI).

SIA12

The local administrator password complexity shall support at least 12 alphanumeric characters and special characters.

SIA13

Shall have the ability to turn off non-secure protocols and settings.

SIA14

All networked system components must be hardened and able to withstand a network scan of software / firmware / operating system.

The system shall stay operational and not degrade during the network scan when exposed to a minimum of five concurrent network connection requests simultaneously from scanning tools such as Nessus Tenable and Nexpose.

System Operation Target Requirements

SO1

Shall provide a user interface that evidences ease-of-use and minimizes the potential for operator error.

Note: This requirement applies to both IP- and non-IP-based systems.

SO2

Shall, at a minimum, provide the capability to perform access audits to cover both remote and local access. The access audits will log detailed information for log on and log off actions.

SO3 Shall log events to local non-volatile storage.

SO4 Shall rotate log files at least monthly.

SO5 Shall maintain the most recent 12 months of log files.

SO6 Shall support a syslog capability.

SO7 Shall support an automated syslog forwarding capability.

SO8 Shall make the log files exportable at the local control console.

SO9 Shall make the log files exportable from a web-enabled client.

SO10 Shall have machine-readable log format.

SO11

Shall make the system log files viewable to the local control console.

SO12

Shall provide a capability to remotely access the system from a web-enabled client.

SO13

Shall allow the network settings to be configurable via the local console as well as through a web-enabled client.

SO14

Shall allow edge devices to support user-configurable static

IP addresses.

SO15

Shall support remote monitoring via Simple Network Management Protocol (SNMP) version 3 at a minimum, with the assumption that if it functions at version 3, then version 2 is supported.

System Operation Target Requirements

SO16

Shall provide a Management Information Base (MIB) file for integration with an SNMP host.

SO17

Shall provide, on the local console and on the web-enabled client, a control which will create a configuration backup file and allow restoration.

SO18

Shall solicit user confirmation during system restoration before fields that could render the system unusable are restored, e.g., network configuration, authentication, and network time protocol (NTP) server addresses.

SO19

Shall provide a Hypertext Markup Language (HTML) 5 or equivalent web-interface client for remote network access to the local control console features. This web client will support major browsers such as Edge, Firefox, Chrome, etc.

SO20

Shall use a secure communications protocol (HTTPS, Transport Layer Security [TLS] 1.2 at a minimum, Advanced Encryption Standard [AES] encryption, etc.).

SO21

Shall, using the NTP protocol, synchronize its system date/time to the date/time provided by the NTP server.

SO22

Shall allow configuration of the NTP server address to be modified from the local console and the web-enabled client.

SO23

Shall have a verification process to ensure that all commands received by the system components are received and properly executed.

SO24 Networked components shall support IPv4 and IPv6.

Vendor Support Requirements

VS1

The warranty period shall be a minimum 1-year from the date of installation by DS/ST (objective) or the date of delivery to DS/ST (threshold).

Vendor Support Requirements

VS2

Shall provide replacement parts and labor for the duration of the product’s warranty.

VS3

Shall provide customer technical support during product’s warranty period, and for a minimum period of five years from the time of last manufacture.

VS4

Shall provide backup copies of all software and firmware needed to restore the system, to include system interface and tools necessary for updates.

VS5

Shall grant internal distribution rights for all necessary manuals and technical documentation.

VS6

Shall provide "train-the-trainer" support to allow Government instructors to develop instructional materials and training for the user community.

VS7

Shall provide "train-the-technician" support to allow Government technicians to become certified in servicing the equipment under warranty and once deployed worldwide.

VS8 Shall provide Application Program Interface (API) documentation for all IP-based components.

VS9 Shall provide Representational State Transfer (REST) APIs to allow integration with other 3rd party applications.

VS10

Shall provide the capability for the DOS to remotely deploy software, and firmware updates to the control console component as well as the edge devices.

Vendor Support Information Request

VSI1

Shall indicate the minimum frequency of planned software updates for any operating system (OS).

VSI2

Shall indicate the minimum frequency of planned software updates for the client application.

Vendor Support Information Request

VSI3

Shall indicate the minimum frequency of planned application software updates.

VSI4

Shall indicate the minimum frequency of planned firmware updates.

VSI5 Shall indicate how product end-of-life will be handled.