...
| Table of Contents |
|---|
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.
| Info | ||
|---|---|---|
| ||
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.
Setup
To create a custom BqlThreat:
...
- 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)\\
...
| Note |
|---|
This BQL queries must return a numeric value for the comparison to function appropriately. |
...
Example BqlThreats
...
| Anchor | ||||
|---|---|---|---|---|
|
BQL:
...
station:|slot:/|bql:select COUNT(*) from baja:User
Comparison: Greater Than
Count: 15
Description:
...
Program Objects Installed: Detects if any programs are in use.
...
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 | ||||
|---|---|---|---|---|
|
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 | ||||
|---|---|---|---|---|
|
BQL: station:|slot:/|bql:select
...
COUNT(*) from
...
fox:FoxService where foxsOnly=false
Comparison: Greater Than
Count: 0
FOXS Only Disabled: Detects if Foxs Only is enabled (N4 Only)
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 | ||||
|---|---|---|---|---|
|
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)
| Note |
|---|
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. |