Variable rules per application
Inherit Guard's defaults or set monitor-specific alert and block thresholds, correlation windows and block duration when an application behaves differently.
Bring your own authentication evidence
Custom Monitors: extend Scantide Guard to your own applications
Not every application deserves a hard-coded collector. Guard Custom Monitors let administrators teach Guard how a trusted event channel or log file represents authentication failures, successful logins and source IP evidence.
Built-in Guard collectors are simply preinstalled and preconfigured monitors. Custom Monitors are the mechanism that lets the same Guard detection, alerting, trusted-source learning and blocking model work with applications outside the built-in list.
Windows Event channel monitors
Supported as part of the Guard monitoring, policy or enforcement workflow.
Single log file or rolling-directory patterns
Supported as part of the Guard monitoring, policy or enforcement workflow.
Recognition and IP extraction expressions
Supported as part of the Guard monitoring, policy or enforcement workflow.
Username extraction where available
Supported as part of the Guard monitoring, policy or enforcement workflow.
Failed and successful authentication classification
Supported as part of the Guard monitoring, policy or enforcement workflow.
Successful-login evidence for trusted-host learning
Supported as part of the Guard monitoring, policy or enforcement workflow.
Capabilities
What this Guard workflow covers
- Windows Event channel monitors
- Single log file or rolling-directory patterns
- Recognition and IP extraction expressions
- Username extraction where available
- Failed and successful authentication classification
- Successful-login evidence for trusted-host learning
- Per-monitor alert and block overrides
- Display-name based event and email reporting
- Portable/community monitor package model
Designed around observable server evidence
Scantide Guard does not need to attack, exploit or brute-force a service to decide that repeated hostile activity deserves action. Collectors observe evidence already generated by the server, normalize it into a common event model, then apply explicit thresholds, allowlists, exceptions and enforcement policy.
The result is intended to be understandable by an administrator: which source IP was seen, which collector reported it, which rule or threshold was reached, what action Guard took, and when a temporary block is due to expire.
Standalone when you need it. Centralized when you grow.
A single Guard can protect its own server with local policy and local firewall enforcement. Organizations with multiple systems can add Scantide Guard Datacenter for shared policy, fleet visibility, licensing and coordinated reputation services.
Frequently asked questions
Can Guard watch rotating logs?
Yes. Custom monitors can target a directory and filename pattern, with optional recursive handling where appropriate.
Can successful logins be used?
Yes. A custom monitor can classify successful authentication evidence so Guard can use it for trusted-host or safe-list learning rather than blocking.
Can each application have different thresholds?
Yes. The design supports per-monitor overrides so applications with different authentication behavior do not have to share one global threshold.
See Scantide Guard in context
Read the current Guard documentation, deployment notes and product status, then choose the Windows, Linux or Datacenter path that fits your environment.
Same policy model as built-in collectors
A Custom Monitor is not a second-class collector.
Custom Monitors use the same operational concepts as Guard's standard collectors: enablement, health, activity statistics, inherited or overridden policy, notification routing and management provenance.
Notify the right owner
Use global recipients, add application-specific recipients, or replace the normal recipient list for that monitor. Blocking events can still escalate to server/security administrators.
Operational visibility
Monitor cards surface enabled state, triggers or recent activity, last source/activity, block context, policy source, notification state and catalogue provenance where available.
Blocking an attack is one thing. Knowing when not to block is another.
Guard does more than count failures. Supported built-in collectors and Custom Monitors can also classify successful authentication. That lets Guard learn which source addresses are repeatedly associated with legitimate administration and use that evidence to reduce unnecessary blocking.
Successful-login learning
When a trusted authentication source reports a successful login, Guard can use that evidence to learn or reinforce the source as a known administrative origin instead of treating every future failure from that address as hostile.
Reset-on-success behavior
A successful login can reset or contextualize the active failure counter for the same source where the monitor supports it, helping distinguish mistyped credentials from a sustained brute-force attack.
Works with Custom Monitors
Custom Monitors can classify both failed and successful authentication, so trusted-source learning is not limited to RDP or other built-in collectors. Applications with usable login evidence can participate in the same model.
Explainable trust
Learned trust should remain visible and auditable: administrators can see why a source became trusted and distinguish learned entries from manually configured allow lists.
Safer than blind whitelisting
The goal is not to permanently trust any IP that happens to log in once. Trust decisions are tied to supported authentication evidence and Guard policy so administrators retain control.
Useful across managed estates
Combined with Datacenter, successful-login intelligence can help reduce friction for known management sources while keeping attack blocking and repeat-offender handling active across the fleet.
Smarter protection
Blocking an attack is one thing. Knowing when not to block is another.
Scantide Guard can use successful authentication evidence from supported built-in collectors and Custom Monitors to recognize trusted administration sources, reset or contextualize active failure history where appropriate, and reduce unnecessary blocking without weakening the deterministic protection model.
Learn from successful logins
Trusted authentication evidence can help Guard distinguish legitimate administration from repeated hostile attempts.
Reduce false-positive blocking
Successful authentication can reset or contextualize active failure counters where supported, helping avoid blocking known legitimate sources after simple mistakes.
Not limited to built-in collectors
Custom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.