In our ongoing migration to Trend Micro Vision One for EDR and XDR, a common operational hurdle has emerged: the necessary interaction between our Remote Monitoring and Management (RMM) tools and endpoint agents often triggers alerts. While Vision One's detection capabilities are a core strength, we must create precise exceptions to prevent these legitimate administrative tools from being flagged as malicious, which would otherwise generate significant noise for the SOC.
This guide outlines a structured, audit-friendly approach to creating a whitelist, focusing on the principle of least privilege and clear audit trails. We'll move beyond simple hash-based exclusions and build a more robust rule set.
### Foundational Concepts: Understanding Exclusion Types
First, it's critical to understand the different scopes of exclusions available within Vision One, as defined in the Workload Security policy:
* **Global Scan Exclusion**: Applies to all managed computers. Use this sparingly and only for universally trusted, corporate-mandated paths.
* **Trusted Process for Real-Time Scan**: Prevents the scanning of specified processes and their file operations. This is often the most applicable for RMM tool components.
* **Trusted Process for On-Demand Scan**: Similar, but only for scheduled or manual scans.
* **File Hash Exclusion**: Excludes a specific file hash from detection. Useful for static, signed binaries but can be bypassed if the file is updated.
### Recommended Strategy: A Layered Approach
For a typical RMM agent, I recommend a combination of the following, ordered from most to least secure:
1. **Path-Based Exclusion for Installation Directories**: Whitelist the known, standardized installation path(s) for your RMM agent (e.g., `C:Program FilesYourRMM*`). This is the broadest but most manageable rule.
2. **Trusted Process for Real-Time Scan**: Identify the core, persistent processes of your RMM. Use their full image paths.
3. **File Hash Exclusion for Key Signed Binaries**: For critical, infrequently updated, and digitally signed components, consider adding a hash-based exclusion as a final layer of precision.
### Step-by-Step Implementation via Vision One APIs
For automation and Infrastructure as Code (e.g., Terraform), or simply for consistency across large environments, using the Vision One APIs is preferable. Below is a conceptual example of creating a Trusted Process rule via the API.
First, you need to authenticate and obtain a bearer token. Then, you can `POST` to the appropriate endpoint. The following JSON payload example whitelists a hypothetical RMM agent's main service and updater.
```json
POST /v3.0/trustedProcesses
Authorization: Bearer
Content-Type: application/json
{
"processes": [
{
"path": "C:\Program Files\RMM Corp\Agent\rmm-service.exe",
"description": "Primary RMM Agent Service - Corp Standard",
"platform": "windows"
},
{
"path": "C:\Program Files\RMM Corp\Agent\updater.exe",
"description": "RMM Agent Updater - v2.1.3",
"platform": "windows"
}
]
}
```
### Critical Pitfalls and Compliance Notes
* **Over-broad Paths**: Avoid using high-level paths like `C:` or `C:Windows`. Always drill down to the most specific directory possible.
* **Lack of Documentation**: Each exclusion **must** have a clear `description` field citing the business justification (e.g., "IT-OPs-RMM-01: Datto RMM Core Service").
* **Change Control**: Any modification to these whitelists should follow your standard change management process. The API call itself can be version-controlled in a Git repository.
* **Regular Review**: Schedule quarterly reviews of all exclusions to validate their ongoing necessity and to ensure they haven't been co-opted by malicious activity.
By implementing whitelists in this manner, we maintain the security integrity of Vision One while eliminating alert fatigue for our legitimate administrative tooling. The key is precision, documentation, and treating the exclusion list itself as a critical security artifact.