GuardMode 2024.2
Catalogic SoftwareKnowledge BaseMySupport
  • Welcome to GuardMode!
  • Intro
  • Installation
    • System requirements
    • Installing GuardMode Agent on Windows
      • Updating GuardMode Agent on Windows
    • Installing GuardMode Agent on Linux
      • Using GuardMode Agent as a Container
    • Uninstalling GuardMode Agent on Windows
    • Uninstalling GuardMode Agent on Linux
    • Configuring GuardMode Agent for SAMBA setup
    • Uninstalling GuardMode Agent on SAMBA setup
  • Agent Configuration
    • General Settings
    • Excluded Paths Configuration
    • Adding malware detection rules
      • Honeypot and Decoy Files
      • Write Operations Threshold
      • Detecting File Renaming with Abnormal File Extensions
      • Special Files Monitoring
    • Security Incident Detection
    • SMB Monitoring (Linux Only)
    • Event Reports
      • Configuring Event Reports
      • Excluding Paths From Event Reports
      • Tagging Agent
    • NFS Share Monitoring
    • Altering Audit Rules
    • Configuring DPX for Automatic Blocklist Updates
    • Using TLS
    • Configuring YARA-X
  • Using GuardMode Agent Command Line
  • REST API Documentation
  • On-demand Scanning
  • Logging
  • FAQ
  • Found an issue?
Powered by GitBook
On this page
  • Security incidents
  • Configuring incident detection
  • Accessing incident details
  1. Agent Configuration

Security Incident Detection

PreviousSpecial Files MonitoringNextSMB Monitoring (Linux Only)

Last updated 8 months ago

Tip. This feature is only available on GuardMode 2023.1 or higher.

Security Incident Detection is a feature designed to track suspicious file activities, aiding in the Guided Recovery process.

Security incidents

Note. YARA analysis enhances security incident detection by identifying potentially malicious files based on custom-defined patterns. For details, see .

When an alert from a detection strategy is triggered for a user without an open incident, a new Security Incident is created. This incident actively tracks all events related to the files affected by the user's actions. It includes not only the user's suspicious activities, such as encryption, deletion, and renaming, but also those actions performed by other users on the same files. For instance, if user A's behavior leads to an incident involving the encryption of a file F, and then user B renames this file to F1, the tracking of the file F1 continues under the same incident.

An incident is automatically closed when there's no further suspicious activity associated with the tracked files for a predefined period, which can be set in the configuration. The incident also closes if the only activities detected are file renaming.

Configuring incident detection

Configuring Security Incidents is accessible through the Agent’s REST API (accessible from http://localhost:5000/swagger).

To enable or disable Security Incident Detection, you need to change the incidentDetection flag in the endpoint. By default, in version 2023.1, this functionality is enabled. You can also modify the inactivityPeriod, which is the time (1 minute by default) required to pass without any suspicious behavior for an incident to close:

{
  "queryingDelay": "string",
  "savingDelay": "string",
  "incidentDetection": {
    "enabled": true,
    "inactivityPeriod": "string"
  }
}

Accessing incident details

Security Incidents API can be utilized to diagnose the root cause of an incident. By using the GET /security-incidents request, you can list all incidents to find ones related to a certain user or time.

For more detailed information, use GET /security-incidents/:id/events and GET /security-incidents/:id/files requests to see the types of events that caused the incident and the details of the files affected during its duration. The latter offers comprehensive information about the lost files, including their names before the incident, the time of the first modification, and the type of modification.

The GET /security-incidents/modification-types request lists all possible modification types, allowing for a thorough analysis of the incident, including the actions of other users who modified the involved files.

Configuring YARA