Summary

The BqlThreat component empowers 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.

Regarding BQL

Previous knowledge of the Baja Query Language (BQL) - its use - or the advanced options is valuable here but not required. Check out our examples for a quick-start, head over to the Niagara Community to ask other users or email techsupport@activelogix.com if you have an advanced use-case that you need assistance with.

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, Override Global, and Severity: these options are shared by all Threats, see the Threats doc for more info
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

Open the nProtex module Niagara Palette
Drag BqlThreat component from the palette and drop it underneath the Threats folder inside of the NProtex service (NProtexService/Report/Threats)
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"
Provide a BQL query which returns an integer value (using COUNT, MIN, MAX, SUM, AVG built-in BQL functions, see examples)\\

This BQL queries must return a numeric value for the comparison to function appropriately.

Example BqlThreats

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.

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.

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.

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)

You'll notice this just provides a count of the number of devices that are down and does not tell you which devices are down.