The Strict mode under the Detect or Enforce mode is used for stronger threat protection. Enabling Strict mode reduces the level of baseline fingerprint deviation allowed; in other words, it performs stricter comparison between the established baseline and currently-running operational behaviors.
In more dynamic processes where devices and access behaviors are more subject to change, this may generate more events. See Strict Mode - Use Case for information.
To enable Strict mode, set the Operations Behavior Anomaly Detection to Detect or Enforce mode, and then toggle on specifc pillars of protection for guarding separate vulnerability points or simply enable them all for maximum defense.
See below for more details on how the three pillars work in Strict mode.
Script Behaviors: In the Strict mode, the operation process and the monitored process or script must exactly match the approved full operation process stored in the baseline; otherwise, events will be generated or the process will be blocked.
See below as an example of how the Strict mode works for the Script Behaviors.
-
When you select the Learn mode under the Operations Behavior Anomaly Detection, the following full operation process is learned:
-
explorer.exe → cmd.exe → powershell.exe → script.ps1
-
-
When you switch to the Detect or Enforce mode without turning on the Strict Mode, StellarProtect will not block recognized program calls with unidentified script; the following process is allowed:
-
explorer.exe → cmd.exe → powershell.exe → NEWscript.ps1
Note:The NEWscript.ps1 does not count as an unrecognized script in the process when the Strict Mode is turned off.
-
-
When the Strict Mode is turned on, no matter it's under the Detect or Enforce mode, the following process is not allowed:
-
explorer.exe → cmd.exe → powershell.exe → NEWscript.ps1
Note:The NEWscript.ps1 is detected as an unrecognized script that will trigger alerts or be blocked when Strict Mode is enabled.
-
-
In conclusion, when Strict Mode is turned on, only the exact process (the process learned in Step 1) is allowed:
-
explorer.exe → cmd.exe → powershell.exe → script.ps1
-
|
Script Behaviors |
Operations Behavior Anomaly Detection |
||||||
|---|---|---|---|---|---|---|---|
|
Approved Operation |
Monitored Process |
Detect |
Enforce |
Detect |
Enforce |
||
|
Monitored Application |
Script |
Strict mode: OFF |
Strict mode: ON |
||||
|
Process learned and stored in the baseline |
explorer.exe→cmd.exe→ |
powershell.exe→ |
script.ps1 |
Allowed |
|||
|
Operation process changed |
cmd.exe→explorer.exe→ |
powershell.exe→ |
script.ps1 |
Events |
Blocked |
Events |
Blocked |
| Monitored application changed | explorer.exe→cmd.exe→ |
cscript.exe→ |
script.ps1 |
Events |
Blocked |
Events |
Blocked |
|
Script changed |
explorer.exe→cmd.exe→ |
powershell.exe→ |
NEWscript.ps1 |
Allowed |
Events |
Blocked |
|
User Login: In the Strict mode, the user accounts and the login activities must exactly match the approved user accounts stored in the baseline; otherwise, events will be generated.
Application Behavior: In the Strict mode, the application behaviors must exactly match the approved application behaviors stored in the baseline; otherwise, events will be generated.
See Strict Mode - Use Case for the description of how you can use the Strict mode to maximize its effectiveness.