Management

1. Overview

The Management module is the central administrative control plane of Siberson Verikor DLP. While the Policies, Classifications, and Resources modules define what the platform should detect and how it should react, the Management module governs how the platform itself operates — its global behaviour, its endpoint agent posture, the directories it synchronises with, the channels it uses to notify operators, the integrations it streams events into, and the lifecycle by which configuration changes reach production.

Every Siberson Verikor DLP deployment is configured first through the Management module. Subsequent operational tasks — onboarding a new domain, rotating SMTP credentials, adding a SIEM destination, suppressing scans on a set of folders, or deploying a tuned policy package to all endpoints — are also performed here. A correctly-configured Management module ensures consistent enforcement across the estate, predictable agent behaviour, accurate notifications, and a clean separation between configuration authoring and configuration deployment.

This article walks through every page under the Management menu, in the exact order the navigation presents them, and explains the purpose of each screen, the fields it exposes, and the workflow an administrator should follow to maintain it over time.

2. Accessing the Management Module

All Management pages are available under the Management menu in the left-hand navigation of the Siberson Verikor DLP Administration Console. The module presents ten sub-sections in a deliberate order — from global console behaviour through diagnostic and notification channels, to identity sources, endpoint agent posture, scan exclusions, and finally configuration publishing.

1. Sign in to the Siberson Verikor DLP Administration Console with an administrator account.

2. Expand the Management menu in the left-hand navigation panel.

3. Select the sub-section you wish to manage. List-style screens (Mail Recipients, Mail Templates, Directory Settings, Exclusion Configurations, Publish) expose New, Details, Edit, Delete, Display Columns, and Export to Excel controls. Form-style screens (Configurations, Log Configurations, Mail Configurations, Syslog Configurations, Agent Settings) open directly into editable settings.

3. Management Navigation Structure

The Management menu items appear in the left navigation in the following order. The remainder of this article documents each item in the same sequence.

• Configurations — global console and agent behaviour, organised across six tabs.

• Log Configurations — internal Siberson Verikor DLP server logging behaviour for diagnostics and performance.

• Mail Configurations — outbound SMTP server used for system notifications.

• Syslog Configurations — Syslog facility and severity catalogues that drive SIEM integration.

• Mail Recipients — the address book of operational notification recipients.

• Mail Templates — reusable email body templates referenced by alerting workflows.

• Directory Settings — Active Directory and LDAP connections used to synchronise users and computers.

• Agent Settings — endpoint agent protection, disabling, MS Outlook, and printer behaviour.

• Exclusion Configurations — directories, files, and file formats excluded from scanning.

• Publish — staging and deployment of pending configuration changes to the agent fleet.

4. Detailed Sections

4.1 Configurations

The Configurations page consolidates the global behaviour of Siberson Verikor DLP into a single screen with six tabs: General Settings, DLP Configurations, Display Configurations, Integration Settings, Limits, and Security. Settings on this page apply tenant-wide and are evaluated by every endpoint agent and every console session, so changes here have the broadest blast radius in the platform — they should be reviewed carefully before being saved and published.

4.1.1 General Settings

The General Settings tab captures the identity of the deployment, the master directory-synchronisation behaviour, the user-facing language of both the agent and the administration panel, the cadence at which the agent contacts the server, and the threshold at which the console flags out-of-date clients.

Figure 1 – Configurations › General Settings (top): company project information and directory synchronisation in the Siberson Verikor DLP Management module.

‌

The Company Project Informations group records the Company Name, Company Title, and Project Name that appear in console headers, exported reports, and notification email metadata. Directory Settings on this tab control whether directory synchronisation is enabled at all, the LDAP connection version (v1 / v2), and whether paginated reads should be used against very large directories. Language Settings independently control the Agent Language seen on managed endpoints and the Administration Panel Language used in the console — the two can differ, which is helpful when the operations team and the end-user population speak different languages.

Figure 2 – Configurations › General Settings (bottom): agent loop times, web service URL, and panel display thresholds.

‌

Agent Configurations governs how often the Verikor agent service performs its main loop and how often it checks the server for a new agent version. The Web Service Address (Url) is the endpoint that every managed agent contacts; it must be reachable from every endpoint in the agent network. Panel Configurations sets two colour thresholds (in minutes) used by the Client Versions widget to flag agents whose last check-in is approaching staleness (yellow) and is fully stale (red).

4.1.2 DLP Configurations

Figure 3 – Configurations › DLP Configurations: OCR coverage and OCR speed mode controls.

‌

The DLP Configurations tab activates Optical Character Recognition (OCR) inspection for the four content sources where text is most often embedded in image form: standalone images on the endpoint, PDFs on the endpoint, images attached to mail flows, and PDFs attached to mail flows. The OCR Speed Mode dropdown selects the trade-off between throughput and detection depth: Fast Mode favours endpoint performance and is suitable for routine scanning of large estates, while Slow Mode performs more thorough character recognition and is recommended for forensic or post-incident inspection runs.

4.1.3 Display Configurations

Figure 4 – Configurations › Display Configurations: end-user-facing taskbar and context menu behaviour.

‌

Display Configurations governs what end users see on managed endpoints. Active Verikor Information Assistant (Taskbar) determines whether the agent presents a taskbar tray icon at all, and Show Verikor Information Assistant Message controls whether interactive notifications surface on policy events. Windows 10 Style Context Menu, when enabled, integrates classification and policy actions into the modern Windows shell context menu rather than the legacy menu — recommended for any deployment running Windows 10 or later.

4.1.4 Integration Settings

Figure 5 – Configurations › Integration Settings: Syslog and SNMP destinations.

‌

Integration Settings configures the two outbound machine-to-machine integrations available at the platform level: Syslog (for SIEM event forwarding) and SNMP (for network management system trap forwarding). The Syslog group captures the host address, port, Syslog Type (RFC 5424 by default; RFC 3164 also supported), an optional User Activity Syslog Integration toggle, and a Connection Test button that issues a synchronous probe to the configured host. The SNMP group captures host and port for trap forwarding.

4.1.5 Limits

Figure 6 – Configurations › Limits: agent CPU and memory ceilings.

‌

Limits constrains the resource footprint of the Siberson Verikor DLP agent on every endpoint. Max Limit CPU Verikor Agent (Percent) caps the share of CPU the agent process is permitted to consume; Max Limit RAM Verikor Agent caps the working-set memory either as a percentage of installed RAM or as an absolute amount. Both thresholds are enforced by the agent itself — when exceeded, the agent backs off active scanning and resumes when headroom returns.

4.1.6 Security

Figure 7 – Configurations › Security: authentication, lockout, and password policy for the administration panel.

‌

4.2 Log Configurations

Log Configurations controls the diagnostic logging produced by the Siberson Verikor DLP server itself. It is intended for the platform operations team and for support engagements where Siberson is helping to diagnose unusual behaviour. The page is organised into a Log Settings group at the top — covering IP address logging modes — and three tabs below: Developer Logs, Performance Logs, and Service Logs. Each tab can be activated independently and scoped via a rule grid.

Figure 8 – Log Configurations: IP logging modes and Developer Logs tab in the Siberson Verikor DLP Management module.

‌

Log Settings exposes three independent toggles — Internal IP Logging, External IP Logging, and VPN IP Logging — that control whether the corresponding source IP is recorded against each event. Below, each of the three log tabs (Developer / Performance / Service) is enabled by its Is …Log Active checkbox and can be scoped down to specific rules so that diagnostic logging only fires for the conditions actually under investigation. The Rule Pattern field accepts a Boolean expression combining rule numbers (for example, (1 & 2) | (3 | 4)) to express compound activation logic; Validate Pattern checks the syntax before saving.

4.3 Mail Configurations

The Mail Configurations page defines the outbound SMTP server that Siberson Verikor DLP uses to send all system-generated email — operator alerts, scheduled reports, mail-template-driven notifications, and password-related messages. This is a single global configuration; only one SMTP profile is active at any time.

Figure 9 – Mail Configurations: SMTP host, credentials, timeout, and Send Test Mail control.

‌

After saving, use the Send Test Mail button to confirm end-to-end deliverability. The console will surface SMTP errors directly, which is the fastest way to diagnose authentication and TLS issues without having to read the receiving mailbox.

4.4 Syslog Configurations

Syslog Configurations exposes the catalogues that drive RFC 5424-compliant Syslog event forwarding. The page is organised into tabs covering Syslog Configurations, Syslog Facilities, and Syslog Severities. The two catalogue tabs — Facilities and Severities — are documented below; configuration of the Syslog destination itself (host and port) is performed earlier on the Configurations › Integration Settings tab.

4.4.1 Syslog Facilities

Figure 10 – Syslog Configurations › Syslog Facilities: facility catalogue with numeric values and descriptions.

‌

Syslog Facilities lists the standard Syslog facilities available for tagging outbound events. Each facility has a Name (for example, kern, user, authpriv, ftp, ntp, security, console, clock, mail, daemon), a numeric Value (0–23), a Description, and an Active flag. Verikor ships with the full facility catalogue (16 entries) in an active state. Edit a row to override the description, or deactivate a facility to remove it from the picker shown to rule authors.

4.4.2 Syslog Severities

Figure 11 – Syslog Configurations › Syslog Severities: severity catalogue with numeric values and descriptions.

‌

Syslog Severities lists the seven RFC 5424 severities used to weight outbound events: Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Informational (6), and Debug (7). Most organisations leave this catalogue unchanged — it maps cleanly to standard SIEM ingestion pipelines. Customise only when a downstream SIEM expects an unusual mapping or when an in-house severity tier is needed for routing rules.

4.5 Mail Recipients

Mail Recipients is the address book used by every outbound notification produced by Siberson Verikor DLP. Each entry has an E-Mail address, an optional Description, and an Active flag. Defining recipients here, rather than hard-coding addresses into individual rules, ensures that when a SOC distribution list, an on-call rotation, or a compliance officer changes, only one place needs to be updated.

Figure 12 – Mail Recipients: notification address book grid.

‌

Use the inline column filters to confirm that the same recipient is not duplicated across descriptions, and the Active flag to retain a recipient on file (for audit purposes) without continuing to deliver mail to it.

4.6 Mail Templates

Mail Templates defines the reusable email bodies that drive notification workflows. Each template carries a Name, an Active flag, a Description, a Subject, and a Mail Body. Templates are referenced by name from rules and from automated workflows, so the same wording is reused consistently across every event type that should produce identical messaging.

‌

Figure 13 – Mail Templates list view with New, Details, Edit, Delete, Display Columns, and Export to Excel actions.

‌

The list view displays every template in the system along with its Active state and the Created By / Created Date / Modified By / Modified Date metadata. Use the toolbar to create a new template, open an existing template for read-only inspection, edit it, or remove it permanently. Export to Excel is useful for backing up the template library before bulk changes.

Figure 14 – Mail Template editor: Name, Description, Subject, and Mail Body fields.

‌

The editor exposes the four mandatory fields the template engine needs to render an email. Name is a unique identifier referenced from rules; Subject is the rendered subject line; Mail Body is the rendered body. The Active checkbox controls whether the template appears in selection lists; deactivate templates that are pending review without deleting them.

4.7 Directory Settings

Directory Settings registers the Active Directory and LDAP-compatible identity sources from which Siberson Verikor DLP imports users and computers. A single deployment typically has one primary directory plus any secondary sources used for guest, contractor, or service-account populations. Multiple entries can be active at the same time.

‌

Figure 15 – Directory Settings list view: registered directories with Domain Path, Query Filter, Description, and Active flag.

‌

The list view exposes columns for Domain Path, Query Filter, Description, and Active state. Use New to register a new directory, Details to inspect an existing entry, Edit to modify connection details, and Delete to remove an entry that no longer applies. Display Columns lets you tune the visible fields, and Export to Excel produces an offline reference of the configured directories.

Figure 16 – Directory Setting edit form: LDAP connection parameters and Test action.

‌

Use the Test button after entering connection parameters to validate bind, query, and read access without committing the entry. A failed test reports the directory error inline, which is significantly faster than waiting for a scheduled synchronisation run.

4.8 Agent Settings

Agent Settings is where the posture of the Siberson Verikor DLP endpoint agent is governed. The page exposes four tabs that, taken together, control how resistant the agent is to tampering, when it is permitted to be disabled, and how it should treat two of the most sensitive endpoint channels — Microsoft Outlook and printers. All four tabs share a common construction: an enabling toggle at the top, a Rules grid that scopes the behaviour to specific resources, and a Rule Pattern Boolean expression that combines rules.

4.8.1 Protection Settings

Protection Settings is the first tab and is itself organised into two sub-tabs: Agent Uninstall Settings and Agent Stopping Settings. Both sub-tabs control whether — and under what credentials — the local agent can be removed or paused.

Figure 17 – Agent Settings › Protection Settings › Agent Uninstall Settings: tamper-protection mode, admin password, and per-machine password catalogue.

‌

Active Protection UnInstalling enables tamper protection: the agent cannot be uninstalled without the configured admin password. Activate Offline Uninstall extends this to scenarios where the endpoint is not in contact with the server. The Admin Password field stores the master uninstall credential. Below, the Passwords grid catalogues additional per-machine or per-group passwords that scope to specific resources via the Rules definition.

Figure 18 – New Passwords editor for tamper-protection credentials, with Rules grid and Rule Pattern.

‌

The New Passwords editor captures a Password, an optional Description, an Active flag, and a Rules section that scopes the password to specific machines, groups, or time windows. Evaluate All Rules, when enabled, requires every rule in the pattern to match before the password is applied; otherwise, the Boolean Rule Pattern expression governs activation.

4.8.2 Disabled Settings

Figure 19 – Agent Settings › Disabled Settings: scope-bound disabling of agent services.

‌

Disabled Settings allows the agent to be disabled for narrowly-scoped circumstances — for example, a maintenance window, an imaging laboratory, or a specific compatibility test bench. The Disabled Agent Services checkbox enables the feature; the Rules grid below it defines when the disabling takes effect, scoped by Resource Type, Resource, Start Datetime, and End Datetime.

Figure 20 – Disabled Settings rule editor: Rule Name, Field, Expression, Resource scope, and validity window.

‌

The Edit Form opens for both new and existing rule rows and exposes Rule Name, Field (the agent attribute to evaluate), Expression (the comparison operator), Expression Value, Resource Type, Resource, Start Datetime, End Datetime, and the Active flag. Combined with the parent Rule Pattern, this gives a precise way to disable agent activity only where it is genuinely needed and only for as long as it is needed.

4.8.3 MS Outlook Settings

Figure 21 – Agent Settings › MS Outlook Settings: disabling Verikor inspection inside MS Outlook for scoped resources.

‌

MS Outlook Settings carves out scoped exceptions for the Microsoft Outlook channel. Disabled MS Office Outlook, when checked and combined with a matching rule, prevents the agent from inspecting Outlook traffic on the targeted endpoints. The Rules grid below uses the same construction as the Disabled Settings tab — same fields, same Boolean Rule Pattern — and is intended for scenarios where Outlook inspection is incompatible with a particular plug-in or test workflow.

4.8.4 Printer Settings

Figure 22 – Agent Settings › Printer Settings: disabling print-channel inspection for scoped resources.

‌

Printer Settings controls inspection of the print channel. Disabled Printer, combined with a matching rule, suspends print-channel DLP inspection on the targeted endpoints. The same Rules grid construction applies. Use this tab sparingly and only for endpoints that drive specialised printers (label printers, plotters, regulated production lines) where DLP inspection is incompatible.

4.9 Exclusion Configurations

Exclusion Configurations defines the directories, files, and file formats that Siberson Verikor DLP should not scan. Well-tuned exclusions reduce agent CPU consumption, eliminate noisy false positives from system locations, and ensure the platform focuses its scanning budget on user-content paths. The page is organised into three tabs: Excluded Directories, Excluded Files, and Excluded File Formats.

4.9.1 Excluded Directories

Figure 23 – Exclusion Configurations › Excluded Directories: shipped Windows exclusions covering Recycle Bin, AppData, Program Files, ProgramData, Windows, and OneDrive.

‌

Excluded Directories ships pre-populated with the directory paths that should be excluded on a typical Windows endpoint — \$Recycle.Bin, \AppData, \Program Files, \Program Files (x86), \Program Files\WindowsApps\, \ProgramData, \Windows, and OneDrive. Each row carries a Directory Path, an Environment (the operating-system family the path applies to), an Exclude flag, a Description, and an Active state.

Figure 24 – Excluded Directories editor with cross-platform Environment selector (Microsoft Windows, Linux, Apple Mac OS, FreeBSD).

‌

The Edit Form exposes the same fields for create and update, with the Environment dropdown listing Microsoft Windows, Linux, Apple Mac OS, and FreeBSD. This cross-platform Environment binding ensures that a path defined for one operating-system family does not unintentionally exclude a similarly-named but legitimate path on another.

4.9.2 Excluded Files

Figure 25 – Exclusion Configurations › Excluded Files: file-path-level exclusions grid.

‌

Excluded Files captures specific file paths that should be skipped during scanning, regardless of the directory exclusions above. Each row records a File Path, a Description, and an Active flag. Use this tab for narrow, surgical exclusions — for example, a known-large log file in an otherwise-scanned directory, or a vendor-supplied data file that triggers consistent false positives.

4.9.3 Excluded File Formats

‌

Figure 26 – Exclusion Configurations › Excluded File Formats: shipped catalogue (47 formats) of file extensions to skip during scanning.

‌

Excluded File Formats lists the file extensions that the agent should not open or inspect. The shipped catalogue covers 47 formats, biased toward executable and platform formats that do not typically carry user content (.apk, .app, .appicon, .appinfo, .asax, .ascx, .ashx, .asp, .aspx, .bak, .bat, .bin, .cab, .cache, .cgi, and so on). Each format carries a File Format extension, an Only Attachments flag (which limits the exclusion to mail attachments rather than on-disk files), a Description, and an Active state.

‌

Figure 27 – Excluded File Formats editor: File Format, Only Attachments, Active, and Description fields.

‌

The Edit Form is used both for adding new format exclusions and for tuning existing ones. Set Only Attachments when the format is acceptable on disk but should be skipped when arriving as an email attachment, or vice versa.

4.10 Publish

Publish is the last subsection of the Management module and the gate through which configuration changes reach the agent fleet. Configuration edits made elsewhere in the Management module — and indeed throughout Policies, Classifications, and Resources — are staged in the server until they are explicitly published. This deliberate separation prevents partially-applied changes from reaching production and gives administrators a single, auditable point of deployment.

Figure 28 – Publish: staging area listing pending configuration packages with Publish, Config.ini Download, Download Config.data, and Delete actions.

‌

The Publish Configurations grid lists every configuration package that has been staged, ordered by Created Date. Each row carries a checkbox for selection, the user who created the package (Created By), the Created Date, an optional Description, an Active flag, per-row Client and Worker download buttons, and a per-row Delete action. The toolbar at the top exposes four batch actions:

• Publish — promotes the active configuration package to all agents. After this action runs, every agent that contacts the server retrieves the new configuration on its next loop.

• Config.ini Download — downloads a human-readable initialisation file representing the active configuration, useful for archival, version control, or cross-environment promotion.

• Download Config.data (UnPublished) — downloads the staged-but-not-yet-published configuration package, useful for inspection or for transferring the staged state to a parallel test environment.

• Delete — removes the selected staged package(s) without publishing.

5. Recommended Administrative Workflow

The Management subsections are presented in the navigation in roughly the order they should be configured during initial deployment, and revisited during day-to-day operations. The following workflow is the order Siberson recommends for a clean first-time setup and for major configuration revisions.

4. Configurations — set company identity, language, agent loop times, integration targets, resource limits, and console security policy first. These tenant-wide settings shape every subsequent configuration choice.

5. Log Configurations — confirm logging behaviour matches your support and audit requirements; turn on Developer logs only if Siberson support is actively engaged.

6. Mail Configurations — establish a working SMTP profile and validate it with Send Test Mail before any rule that produces email is created.

7. Syslog Configurations — review Syslog Facilities and Severities; align them with your SIEM ingestion mapping.

8. Mail Recipients and Mail Templates — register notification distribution lists and the email bodies that policies and workflows will reference.

9. Directory Settings — connect Active Directory or LDAP, validate with Test, and run a synchronisation. This populates users and computers used by every downstream policy.

10.   Agent Settings — set tamper protection, optional disabling rules, MS Outlook and Printer scoped exclusions, and per-machine uninstall credentials.

11.   Exclusion Configurations — review the shipped exclusions and add any environment-specific Excluded Directories, Files, and File Formats to reduce scanning noise.

12.   Publish — promote the staged configuration to the agent fleet only after the steps above are validated.

6. Best Practices

The following practices keep the Management module healthy across a long-running Siberson Verikor DLP deployment.

• Keep configuration records up to date. Use the Description field on every list-style screen (Mail Recipients, Mail Templates, Directory Settings, Excluded Directories) to record why an entry exists and who owns it.

• Verify configurations before applying. Every screen that connects to an external system (SMTP, Syslog, LDAP) exposes a Test or Connection Test action; use it before saving and before publishing.

• Use clear naming conventions. Directories should be named after the OU they synchronise; mail templates should be named after the rule family they support; exclusion entries should describe the reason for exclusion in their Description.

• Review permissions and assignments regularly. Agent Settings rules, particularly Disabled Settings, accumulate over time. Re-validate them quarterly to confirm the windows are still required.

• Validate changes in a non-production environment when feasible. Use Download Config.data (UnPublished) to ship a staged configuration to a test deployment, validate, then return to the production console to publish.

• Document operational changes. Use the Description field on the Publish package, and keep an internal change log that pairs each Publish action with a ticket reference.

• Prefer deactivation over deletion. Every list screen exposes an Active flag; using it preserves history while removing the entry from the active evaluation path.

• Apply the principle of least privilege. Console accounts that only need to publish should not have configuration-edit rights, and vice versa.

7. Summary

The Management module is the operational backbone of Siberson Verikor DLP. Configurations sets the global behaviour of the platform; Log, Mail, and Syslog Configurations connect it to its diagnostic and notification channels; Mail Recipients and Mail Templates supply the address book and message bodies that drive operational alerting; Directory Settings ties the platform to its identity sources; Agent Settings governs the posture of every endpoint; Exclusion Configurations focuses scanning on user-content paths; and Publish is the deliberate gate through which all of the above reaches production.

Time invested in the Management module — particularly during initial deployment and at every major change window — is recovered many times over in stable agent behaviour, predictable notification, accurate SIEM events, and a clean separation between configuration authoring and configuration deployment. Treat this module as the place where governance happens, not just where settings live.

Last updated: 2026-04-30