Application configurations

Application configurations define how individual detection and integration components behave within Kaseya MDR. They control application‑specific behavior, such as ingestion behavior, tuning, exclusions, and reporting presentation.

These settings are managed by administrators and can impact alerts, investigations, and response workflows across the platform. Only users with appropriate administrative permissions can modify them.

Typically, application configurations are reviewed after initial onboarding and adjusted over time as part of tuning, noise reduction, or environment‑specific customization. Because they directly influence how activity is detected and reported, changes should be made carefully and reviewed periodically.

While application configurations affect how data is evaluated and presented, they do not determine whether an alert triggers or whether response actions are executed.

In Kaseya MDR, application configurations are managed from Settings > Application Configurations.

Common questions this article answers include:

  • What are application configurations in Kaseya MDR?

  • How do application configurations differ from detection logic or response behavior?

  • When should application configurations be adjusted versus left at default settings?

  • How do global defaults and organization overrides apply to application configurations?

  • Which application configuration areas affect visibility, tuning, or ingestion?

This article builds on the global default + organization override model described in Global defaults and organization overrides.

What application configurations do

Application configurations define baseline behavior for how specific applications ingest, evaluate, or present telemetry once it reaches Kaseya MDR.

They are used to:

  • Influence how telemetry is evaluated or contextualized for a specific application

  • Apply exclusions or sensitivity adjustments where supported

  • Customize behavior for a specific organization using overrides

Application configurations do not:

  • Replace detection rules

  • Execute response actions

  • Override SOC authorization or investigation workflows

Application configurations affect configuration behavior, not SOC‑managed detection logic or response execution.

Not all application configurations are meant to be adjusted immediately. Some are used primarily for tuning after baseline behavior is observed, while others are configured during onboarding to enable data ingestion.

In general:

  • Ingestion‑related configurations are reviewed during onboarding when a data source is first introduced.

  • Detection‑specific configurations are adjusted later, after baseline behavior is observed and tuning is required.

  • Exclusions and sensitivity changes should be applied incrementally and reviewed periodically.

Because application configurations can impact visibility, changes should be made deliberately and documented internally.

Application configurations at a glance

The table below summarizes the application-level configuration areas available under Settings > Application Configurations, what each area influences, and when it is typically adjusted.

Application What it controls When to configure Common use case Caution
Advanced Breach Detection Detection tuning for activity mapped to MITRE ATT&CK tactics and techniques on the local device During tuning, after baseline behavior is observed Reducing noise from known processes or command‑line activity while maintaining visibility into advanced attack techniques Exclusions reduce detection coverage
Datto Ransomware Detection Ransomware‑ related detection behavior, including exclusions and reporting sensitivity After initial onboarding, during environment‑specific tuning Reducing noise from known processes while maintaining ransomware visibility Exclusions reduce detection scope
Crypto Mining Detection Detection behavior for known or suspected crypto‑mining activity During tuning when legitimate workloads resemble mining behavior Excluding approved domains or IPs Over‑exclusion can hide malicious activity
Suspicious Tools Exclusions for tools or utilities that may otherwise be flagged as suspicious When approved tools generate alerts Reducing alerts from known operational utilities Path‑based exclusions reduce visibility
Suspicious Network Services Evaluation of network service activity, including exclusions and custom service definitions When legitimate services are flagged Defining known services or excluding expected network behavior Network‑level exclusions should be used sparingly
Firewall Log Analyzer Ingestion, filtering, and forwarding of firewall and network device logs During onboarding of firewall or network devices Managing firewall syslog ingestion and filtering Misconfiguration can impact log volume
Defender Manager Microsoft Defender protection, scanning, threat handling, and exclusions During endpoint security posture review Aligning Defender behavior with organizational security policies Changes directly affect endpoint protection

Accessing application configurations

Application configurations are managed from the Settings area.

To access application configurations, follow these steps:

  1. From the side navigation menu, click >Settings>.

  2. Select the Application Configurations tab.

The Application Configurations page is organized into two scopes:

  • Global defaults, which apply to all organizations unless an override exists

  • Organization overrides, which allow application behavior to be customized for a specific organization

Changes made anywhere within an application configuration panel are applied when you select Save.

If you navigate away from the page without saving, your changes are not applied. Saving applies changes at the current scope (global default or organization override).

Understanding global defaults and organization overrides

By default, application configurations are defined at the global level. These defaults apply to all organizations unless an override exists.

You can create organization overrides to customize application behavior for a specific organization. When an override exists:

  • The organization no longer inherits the global default for that application

  • Application behavior is determined by the organization‑specific configuration

For detailed information, see Global defaults and organization overrides.

Application‑specific configurations

Each application listed under Application Configurations exposes its own configuration options. The available settings vary by application and reflect the nature of the data being ingested or evaluated.

Advanced Breach Detection is an agent‑based detection application designed to identify activity mapped to MITRE ATT&CK tactics, techniques, and procedures (TTPs) on the local device. This application evaluates attacker techniques associated with device and network compromise, such as Discovery, Persistence, Defense Evasion, Execution, Credential Access, Privilege Escalation, and Lateral Movement.

This application focuses on detection, not investigation or response execution. How detections are interpreted, escalated, or acted upon depends on broader investigation, SOC review, and response configuration.

Configuration options

When accessed from Settings > Application Configurations, Advanced Breach Detection exposes tuning options that allow administrators to adjust how this detection operates in their environment.

The following options are available in the configuration panel when you select Advanced Breach Detection:

  • Enabled CLI commands: Specifies command‑line patterns that are considered during detection analysis. These commands are evaluated as part of breach‑related detection logic.

  • Report low confidence results: When enabled, lower‑confidence detection results are included in reporting and alerting. Disabling this option may reduce noise but can also reduce visibility into early or ambiguous activity.

  • Excluded parent processes: Specifies parent processes whose activity should be excluded from Advanced Breach Detection analysis. This option is commonly used to reduce false positives for trusted system processes or well‑understood administrative workflows.

  • Excluded registry values: Specifies registry values that should be excluded from detection analysis when evaluating breach‑related behavior.

IMPORTANT  Exclusions reduce detection scope. Add exclusions only when the behavior is well understood and expected, and document the reason for each exclusion.

Datto Ransomware Detection is a response‑oriented application configuration that controls how Kaseya MDR responds when ransomware activity is detected on an endpoint. These settings govern actions such as device isolation and process termination and should be reviewed carefully due to their operational impact.

For details on available settings and their effects, see Configuring Datto Ransomware Detection.

The Crypto Mining Detection configuration controls how known or suspected crypto‑mining activity is identified.

  • Enabled miner domains: Defines domains associated with known mining activity that should be monitored

  • Excluded miner domains: Specifies domains that should be excluded from mining detection

  • Excluded IP addresses: Specifies IP addresses that should be excluded from mining detection

These options are commonly used to tune detection behavior in environments where legitimate activity may resemble mining patterns.

The Suspicious Tools configuration allows administrators to define exclusions for tools or utilities that may otherwise be flagged as suspicious.

  • Excluded paths: Specifies file system paths that should be excluded from suspicious‑tool detection.

This configuration is typically used to reduce false positives for legitimate administrative or operational tools.

The Suspicious Network Services configuration controls how Kaseya MDR evaluates network service activity and allows administrators to define exclusions or custom network definitions to account for expected or known behavior.

This configuration is typically used to reduce false positives related to legitimate internal services or known network patterns.

Excluded networks tab

Use the Excluded networks tab to define network‑level exclusions.

  • Excluded IP addresses: Specifies IP addresses that should be excluded from suspicious network service detection. Commonly used to exclude known internal systems, trusted infrastructure, or expected service endpoints

  • Excluded parent processes: Specifies parent processes whose network activity should be excluded from detection. Typically used when known applications or services legitimately open network connections that would otherwise appear suspicious

IMPORTANT  Exclusions reduce detection coverage. Add exclusions only when the activity is well understood and expected.

Custom networks tab

Use the Custom networks tab to define specific network services that should be treated as expected or known.

Custom networks are defined by protocol, port, and traffic direction, allowing Kaseya MDR to recognize legitimate services running in your environment.

Adding a custom network

To define a custom network service:

  1. Select + New network.

  2. Configure the following fields:

    • Port: The network port used by the service

    • Protocol: The network protocol (for example, TCP or UDP)

    • Traffic direction: Specifies whether the traffic is Inbound, Outbound, or Both

    • Service Name: A short name to identify the service (up to 100 characters)

    • Description: An optional description providing additional context (up to 255 characters)

  3. Select Add network.

Custom networks appear in the list once added and can be reviewed or removed as needed.

Changes made to Suspicious Network Services configuration are applied when you click Save. If you leave the configuration without saving, your changes are not applied.

Best practices for Suspicious Network Services

  • Start with default settings and observe alert behavior before adding exclusions.

  • Use Excluded IP addresses and Excluded parent processes sparingly.

  • Prefer Custom networks when you want to explicitly document and allow known services.

  • Document why each exclusion or custom network was added.

  • Review configurations periodically as network architecture changes.

The Firewall Log Analyzer configuration controls how firewall and network device logs are ingested, stored, filtered, and forwarded into Kaseya MDR using syslog. For detailed information, see Configuring Firewall log ingestion.

The Defender Manager configuration controls Microsoft Defender protection, scanning, threat handling, and exclusions applied to managed endpoints.

Because these settings directly affect endpoint security posture, they should be configured carefully. For detailed configuration options and best practices, see Defender Manager.

Best practices

  • Start with global defaults and adjust only when necessary

  • Make changes incrementally and review their impact before making additional adjustments

  • Use organization overrides only when an organization requires behavior different from the global standard

  • Document why exclusions or advanced settings are configured

  • Review application configurations periodically, especially after onboarding new organizations or data sources

Related articles

  • Global defaults and organization‑level behavior: Explains how global defaults and organization overrides determine which application configurations apply across organizations, and why behavior may differ between environments

  • Power Filters and allowlisting logic: Describes how to manage surfaced visibility and investigation focus without changing application behavior, detection logic, or data ingestion.

  • Advanced agent settings and organization overrides: Covers how agent‑level behavior (resource usage, logging, and diagnostics) is governed separately from application configurations, using the same global default and override model

  • Configuring SOC settings: Explains how SOC communication preferences, authorization boundaries, and organization‑specific context are defined, and how they differ from application‑level configuration