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: 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 "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
- 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.