RDP, Kerberos, SQL Server, IIS/RDWeb, Exchange SMTP, SSH and web collectors are useful because they work without building a parser first. They are not meant to define the outer boundary of Guard.
Applications already produce security evidence
Many line-of-business products record failed login, successful login, username and source address in a file or Windows Event channel. A Custom Monitor lets Guard turn that existing evidence into normalized security events.
The path is part of the monitor
A useful monitor package can include a suggested log path because that information helps another administrator deploy it. On import, Guard should verify whether the suggested location exists and allow the administrator to adjust it.
Policy belongs to the monitor
Different applications retry differently. Custom Monitors can inherit global policy or override thresholds, windows, durations and notification behavior.
Reusable monitors become an ecosystem
Monitor definitions can be shared, reviewed and centrally distributed through Datacenter while preserving provenance and distinguishing verified, organization-managed and locally authored definitions.
Practical depth: examples, failure modes and what to verify
Source note: current Scantide material describes the present platform. Older JufCorp/Red Cloud material is retained as field experience and historical context. Old product names, versions and configuration examples are not presented as current requirements.
Current Scantide detail
Current Scantide source: Scantide Guard for LinuxThe bundled SSH, Apache, Nginx, Tomcat, WildFly and related collectors are intended to give Linux Guard useful coverage immediately. Custom Monitors extend the same detection, alerting and blocking model to other applications that write meaningful authentication or security evidence to files or supported logs.
Current Scantide source: Custom Security Log Monitoring & Automatic IP BlockingBuilt-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.
Current Scantide source: RDP Brute Force Protection for Windows ServerCustom 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.
Current Scantide source: Custom Security Log Monitoring & Automatic IP BlockingCustom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.
Current Scantide source: Scantide Guard for LinuxScantide 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.
Practical review checklist
- The bundled SSH, Apache, Nginx, Tomcat, WildFly and related collectors are intended to give Linux Guard useful coverage immediately.
- Built-in Guard collectors are simply preinstalled and preconfigured monitors.
- Custom Monitors can classify both failed and successful authentication, so trusted-source learning is not limited to RDP or other built-in collectors.
- Custom Monitors can classify both failed and successful authentication, so trusted-source learning can extend to your own applications as well.
- 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.