Media content

Key Benefits

FIM Alert Reception & Processing

A single point for receiving file integrity monitoring alerts via webhooks. Webhook clients with unique URLs and authentication (Basic, token, custom header). Alert dashboard with filters; alert card with file data, hashes, and agent. Processing statuses: pending review, under investigation, confirmed incident, false positive, resolved, escalated, ignored. Notes, escalation, risk and impact assessment, actions, follow-up review.

Hash & AI Analysis

Configurations for external APIs to analyze file hashes (MD5, SHA1, SHA256), IPs, URLs, etc.: URL, method, data type, encrypted credentials. Analysis results are stored with a threat level and details. AI-powered alert analysis: threat/risk assessment, confidence, summary, conclusions, and recommendations for decision-making.

Outgoing Webhooks & Auto-Status

Outgoing webhooks: trigger event (new alert, high risk, analysis/AI completion, etc.), filters by client, alert type, level, agent, status. Custom body template (Jinja2), retry on error, sending log. Auto-status rules: based on a match of file, path, or hash and agent, an alert is automatically assigned a processing status and risk assessment.

Clients, Agents & Access

Webhook clients are linked to a company; types: Wazuh, SIEM, monitoring, custom. Agent information (ID, name, IP, platform) is stored for alert context. Limit on stored alerts with automatic deletion of the oldest. Guide with translations. Access by groups and companies; permissions for viewing, editing alerts, adding/deleting clients, and configuring webhooks.

Features & Capabilities

Incoming Webhooks & Clients

  • Webhook clients: unique identifier, name, address, port, protocol (HTTP/HTTPS)
  • Client type: Wazuh, SIEM, monitoring, custom; environment (production, test, etc.)
  • Linked to a company; enable/disable; generate webhook URL for receiving alerts
  • Incoming request authentication: no authentication, Basic, API token, custom header
  • Authentication credentials are stored encrypted

FIM Alerts & Processing

  • Alert list: rule, severity level, event type (added/changed/deleted/read), file, agent, time
  • Alert card: full description, file path and name, MD5/SHA1/SHA256 hashes, size, raw data
  • Processing status: pending, under investigation, confirmed incident, false positive, resolved, escalated, ignored
  • Investigation notes, false positive reason, resolution notes
  • Escalation: level, reason, responsible person; risk and impact assessment; actions and prevention; follow-up review
  • View agent information

Analysis & Outgoing Webhooks

  • Analysis configurations: external API (URL, method, data type — hash, IP, URL, etc.), encrypted credentials
  • Hash analysis results: status, threat level, detection count, details
  • AI analysis: analysis type, risk level, confidence, summary, conclusions, recommendations
  • Outgoing webhooks: URL, method, content type; trigger event (new alert, high risk, analysis completion, etc.)
  • Filters: client, alert type, level, rule, agent, processing status
  • Custom body template (Jinja2); include alert, analysis, and AI data; retry on error; sending log

Auto-Status, Settings & Access

  • Auto-status rules: condition based on file name, path, or hash (MD5/SHA1/SHA256) and agent
  • Automatic assignment of processing status and risk assessment on match; notes; enable/disable rule
  • FIM settings: maximum number of stored alerts; automatic deletion of oldest when exceeded
  • FIM dashboard guide with country-specific translations
  • Access by groups and company list; permissions: view, edit alerts, add/delete clients, configure webhooks

Use Cases

Integration with Wazuh or other FIM

Configure a webhook client for your Wazuh server (or another file integrity monitoring system): specify the client type, address, and optionally authentication. Copy the generated webhook URL and configure the source to send FIM alerts to this URL. Alerts will appear on the dashboard: rule, file, hashes, agent. Process them: change status, add notes, escalate, or mark as false positive.

Investigation and Risk Assessment

In the alert card, review file details and hashes. Run hash analysis through a configured external API (e.g., VirusTotal) — the result with a threat level will be stored. Use AI analysis to get a risk assessment, conclusions, and recommendations. Fill in investigation notes, impact and business impact assessments, actions taken, and preventive measures. Set the processing status and escalate the alert if needed.

Automation and Event Forwarding

Create auto-status rules: based on a match of file path, name, or hash and agent, new alerts will automatically be assigned a status and risk assessment (e.g., "ignored" for known safe paths). Configure outgoing webhooks to forward events to external systems (N8N, SIEM, etc.): select trigger events and filters, specify the URL and optionally a custom body template. View the sending log and retry on error.

Access Segregation by Company

Access to the FIM dashboard and settings is managed by user groups. Each group is assigned a list of companies — users only see alerts from clients linked to those companies. Separate permissions: view dashboard, edit alerts, add/delete webhook clients, configure webhooks. This allows event processing to be separated between departments or companies.

Storage Limits and Guide

In the FIM settings, specify the maximum number of stored alerts. When the limit is exceeded, the oldest records are automatically deleted to prevent unlimited database growth. The FIM dashboard guide has basic content and country-specific translations (optional AI-powered translation) for quick user orientation.

Technical Details

Architecture

SOC/FIM module: receive FIM alerts via HTTP webhooks with a unique URL per client. Webhook clients: identifier, address, type, environment, company; incoming request authentication (Basic, token, custom header) with encrypted credentials. Alert storage: rule, level, event type, file, hashes, agent, client; processing status, notes, escalation, risk assessment. External API configurations for analysis (URL, data type, encrypted credentials); storage of analysis results and AI analysis results. Outgoing webhooks: triggers, filters, Jinja2 template, retry on error, log. Auto-status rules based on file/path/hash and agent conditions. Record limit with automatic deletion. Guide with translations. Data in the project database.

Security

Incoming webhook authentication (Basic, token, custom header); credentials and API keys are stored encrypted. Access to the dashboard and settings is managed by groups and a company list; permission checks when viewing and modifying alerts, clients, and webhooks. CSRF protection for forms; validation of incoming webhook data.

Scalability

Alert list with pagination and filtering; indexes on time, agent, rule, processing status, and risk assessment. Automatic deletion of oldest alerts when the limit is exceeded. Hash and AI analysis depend on external APIs and their rate limits. Outgoing webhooks are executed in the context of event processing; retry on error with a configurable delay.

Customization

Webhook clients: type, environment, company, authentication. Analysis configurations: data type, API URL, credentials. Outgoing webhooks: trigger events, filters (client, alert type, level, rule, agent, status), body template, retry. Auto-status rules: condition (file/path/hash), agent, status, risk assessment. Global setting: maximum number of alerts. Guide with basic content and country-specific translations.

Frequently Asked Questions

What is a webhook client?

A webhook client is a configuration for a source of incoming FIM alerts. Each client has a unique URL to which an external system (e.g., Wazuh) sends alerts about file changes. The client specifies a name, address, type (Wazuh, SIEM, monitoring, custom), environment, and company. Incoming request authentication can be enabled (Basic, API token, or custom header) to only accept requests with known credentials.

What are the alert processing statuses?

An alert can have the following processing statuses: pending review, under investigation, confirmed incident, false positive, resolved, escalated, ignored. The status can be changed manually or automatically by auto-status rules (based on a match of file, path, or hash and agent). Additionally, investigation notes, false positive reason, resolution notes, escalation, and risk assessment can be filled in.

How does hash analysis work?

External API configurations are set up: URL, HTTP method, data type (MD5/SHA1/SHA256 hash, IP, URL, etc.), and credentials (stored encrypted). For an alert, you can run an analysis — the system sends the file hash (or other data) to the external service and stores the result: status, threat level, detection count, etc. This helps assess whether the file is malicious.

What are outgoing webhooks?

An outgoing webhook is a configuration for sending data from SecBoard to an external URL when events occur: new FIM alert, high-risk alert, completion of hash or AI analysis, etc. Filters (client, alert type, level, agent, status) can be set to send only the desired events. Custom body templates (Jinja2), authentication, and retry on error are supported. A sending log is maintained for control.

What are auto-status rules?

An auto-status rule defines a condition: a match on file name, file path, or hash (MD5, SHA1, SHA256) and agent. When a new alert matches an active rule's condition, it is automatically assigned a specified processing status and risk assessment. This is useful for automatically marking known safe changes (e.g., temporary files) as "ignored" or "false positive."

Why are old alerts deleted?

In the FIM settings, a maximum number of stored alerts is defined. When this number is exceeded, the oldest records are automatically deleted. This prevents unlimited database growth under a high volume of events. The limit can be increased according to server capacity and storage needs.

How is access restricted by company?

Access to the FIM dashboard is configured by user groups. Each group is assigned a list of companies — users only see alerts from webhook clients linked to those companies. Separate permissions are set: view dashboard, edit alerts, add/delete webhook clients, configure webhooks. Users without access do not see the FIM dashboard.

Related Modules

Ready to Get Started?

Explore this module and enhance your organization's security posture