Summary

The BqlThreat component empowers NProtex nProtex users to create custom "threats" for nProtex reports utilizing Niagara's built-in BQL query functionality. These threats alert based on a comparison on the number of results returned by the user-provided BQL statement.

BqlThreats automatically sync to subordinate stations and only need to be created on the WebSupervisor.   This sync occurs automatically when a report is being generated.

• Enabled: sets whether to include this threat when generating reports
• Override Global: this setting for subordinate devices is used to set custom options (Severity, Bql, Comparison, Count) which will override the matching threat on the server
• Severity: determines the color coding for the alert as well as whether or not it's filtered by a severity filter (i.e. filtering out everything below below "Major" would eliminate our BQL Threat from the report results if it were set to "Minor")
• Bql: the bql statement, expected to return an integer value using one of the BQL functions: COUNT, MIN, MAX, SUM, AVG (see examples)
• Comparison: type of comparison to make against the Count
• Count: integer to compare the result of the Bql against
• Description: this is the description that will appear in the report for this particular Threat

Setup

1. Open the nProtex module Niagara Palette
   
2. Drag BqlThreat component from the palette and drop it underneath the Threats folder inside of the NProtex service (NProtexService/Report/Threats)
   
3. Set a name you would like to give this BQL Threat, we recommend something short but easy to understand at a glance like "FOX protocol is enabled"
4. Provide a BQL query which returns an integer value (using COUNT, MIN, MAX, SUM, AVG built-in BQL functions, see examples)\\

Example BqlThreats

Anchor
Simple Count Simple Count

Simple Count

BQL: station:|slot:/|bql:select COUNT(*) from baja:User

Comparison: Greater Than

Count: 15

Description: Maximum allowed users is 15

Why? Old user accounts are one of the most used attack vectors. Having a large number of user accounts can sometimes reflect a lack of maintenance.

Anchor
Detecting existence Detecting existence

Detecting the Existence of a Component Type

BQL: station:|slot:/bql:select COUNT(*) from program:Program

Comparison: Greater Than

Count: 0

Description: Program objects are not allowed.

Why? Most program objects are not signed, and are one-off objects to solve a temporary problem. This opts to alert us in the event that one exists on the station. While program objects usually require super user permissions to be added/edited, this restriction can be lifted. Since Program Objects can request their own permissions - it's nice to be aware that they exist.

Anchor
Detecting a Property Detecting a Property

Detecting a Property Setting on a Component

BQL: station:|slot:/|bql:select COUNT(*) from fox:FoxService where foxsOnly=false

Comparison: Greater Than

Count: 0

Description: FOXS Only is disabled

Why? If FOXS is not enabled, regular fox connections (not over TLS) are permitted. See the Niagara 4 Hardening guide.

Anchor
Checking Device Status Checking Device Status

Checking Device Status

BQL: station:|slot:/|bql:select COUNT(*) from driver:Device where status.isDown = true or status.isFault = true or status.isAlarm = true

Comparison: Greater Than

Count: 0

Description: Device not OK

Why? Connectivity is important, using this BqlThreat you could monitor all devices (or narrow it down by the type - where driver:Device is the type, bacnet:BacnetProxyExt could only look at BacnetProxyExt components that are having issues).

Source: Niagara Community (requires a Niagara login)