Prerequisites
- User role with security.view permission for viewing forecasts, recommendations, baselines, deviations, exfiltration alerts, efficiency stats, and the security dashboard
- User role with security.manage permission for acknowledging/resolving forecasts, accepting/dismissing recommendations, managing baselines, whitelisting processes, investigating/resolving exfiltration alerts, and triggering manual engine runs
- Hosts must be online and reporting metrics (S.M.A.R.T., thermal, CPU, memory, disk) for forecasting and resource analysis
- Hosts must be reporting process lists for process baseline learning and enforcement
- Network flow collection must be enabled on agents for exfiltration detection
Hardware forecasting
The hardware forecasting engine analyzes S.M.A.R.T., thermal, and memory metrics over a 14-day window to predict hardware failures before they happen.
Viewing forecasts
- Navigate to Security > Hardware Forecasts.
- Filter by severity, status, component (disk, CPU, memory), host, or organization.
- Click a forecast to see details: failure probability, predicted failure date, trend direction, confidence, evidence metrics, and recommendation.
Forecast fields
ComponentHardware component type: disk, CPU, or memory.
SeveritySeverity based on failure probability thresholds. Info forecasts (less than 0.1 probability) are filtered out.
Failure ProbabilityEstimated probability of failure (0.0 to 1.0).
Predicted Failure DateExtrapolated date when failure is expected, based on trend analysis.
Evidence MetricsThe raw metric data points that drove the prediction.
RecommendationSuggested action (e.g., "Replace disk", "Clean fan assembly", "Add memory").
Forecast lifecycle
| Status | Description | Action |
|---|---|---|
active | Forecast is current and requires attention. | Acknowledge or resolve. |
acknowledged | Operator has seen and is tracking the issue. | Resolve when addressed. |
resolved | Issue has been addressed (e.g., disk replaced). Terminal state. | — |
Running the engine manually
- Click Run Analysis to trigger a manual forecast run.
- The engine analyzes all hosts with relevant metrics from the last 14 days.
- Results appear as new or updated forecasts.
The engine also runs automatically daily at 02:00 UTC.
Resource recommendations
The resource analysis engine evaluates CPU, memory, and disk utilization data over a 30-day window to generate right-sizing recommendations.
Viewing recommendations
- Navigate to Security > Resource Recommendations.
- Filter by resource type (CPU, Memory, Disk), recommendation (Downsize, Upsize, Optimal), status, host, or organization.
- Click a recommendation to see details.
Recommendation fields
Resource TypeResource being analyzed: CPU, Memory, or Disk.
RecommendationAction: Downsize (over-provisioned), Upsize (under-provisioned), or Optimal (correctly sized).
Current AllocationCurrent resource allocation value.
Utilization StatsAverage, peak, and p95 utilization percentages over the analysis window.
Recommended ValueSuggested allocation based on utilization patterns.
Estimated SavingsEstimated cost savings if the recommendation is implemented.
ReasoningText explanation of why this recommendation was generated.
Actions
- Accept: Acknowledge the recommendation for action. Click the Accept button on the recommendation detail view.
- Dismiss: Hide the recommendation. It will NOT be regenerated until the dismissed record is removed. Click the Dismiss button on the recommendation detail view.
The resource analysis engine runs automatically daily at 03:00 UTC, or manually by clicking Run Analysis on the Resource Recommendations page.
Minimum data requirement.
At least 100 data points are needed per resource type (approximately 4 days at 5-minute intervals). Hosts with insufficient data show "insufficient_data" status.
Process baselines
Process baselines learn the normal set of running processes on a host and flag anomalies during enforcement.
Creating a baseline
- Navigate to Security > Process Baselines.
- Click Create Baseline.
- Select a host and organization.
- Configure detection options:
Alert on New ProcessesEnable to flag any process not in the learned whitelist (default: on).Alert on LOTL BinariesEnable to flag known Living off the Land binaries (default: on).
- Click Save.
- The baseline starts in learning mode -- it absorbs processes from the next 10 host-info submissions.
- After 10 samples, it automatically switches to enforcement mode.
Learning mode vs enforcement mode
| Mode | Behavior | Duration |
|---|---|---|
| Learning | Merges incoming processes by (name, path) into the whitelist. No deviations generated. | 10 host-info submissions with process data. |
| Enforcement | Compares current processes against whitelist. Unknown processes generate deviations. | Indefinite until reset or deleted. |
Managing baselines
- Update settings: Toggle alert flags, active status, or manually switch learning/enforcement mode.
- Reset: Clear all learned processes and restart learning mode from scratch. Click Reset on the baseline detail view.
- Delete: Remove the baseline and all associated deviations.
LOTL binary detection
Living off the Land (LOTL) detection flags when known system utilities are used in potentially suspicious ways. The detection catalog covers 20 specific binaries commonly abused by attackers.
How it works
- During enforcement mode, each process not in the whitelist is checked against the LOTL catalog for the host's OS.
- If "Alert on LOTL Binaries" is enabled and the process name matches a catalog entry, a deviation is created with type "LOTL Binary" and the LOTL category from the catalog.
- If the process does not match the LOTL catalog and "Alert on New Processes" is enabled, it creates a deviation with type "New Process" and severity Medium.
Responding to deviations
- Navigate to Security > Process Deviations.
- Filter by severity, status, deviation type (New Process or LOTL Binary), host, or baseline.
- Review each deviation: process name, path, user, PID, command line, LOTL category (if applicable).
- Choose an action:
- Acknowledge: Mark as seen.
- Whitelist: Add the process to the baseline whitelist so it will not be flagged again. Updates the baseline's process list.
- False Positive: Mark as a detection error.
- Resolve: Mark as handled.
Network exfiltration detection
The exfiltration detector runs every 30 minutes, analyzing network flow data to identify potential data exfiltration. It uses four detection strategies:
| Alert type | Trigger condition | Default severity |
|---|---|---|
| Large Outbound | More than 100 MB transferred to a single destination in 30 minutes. | High |
| Unknown Destination | More than 50 connections to an unresolved external IP (non-RFC1918). | Medium |
| Tunneling Port | Unexpected process using ports 22, 53, 443, 8080, or 8443. | Medium |
| Receive-Only Outbound | Server-type host (typically receive-only) suddenly sending outbound traffic. | Critical |
Investigating alerts
- Navigate to Security > Exfiltration Alerts.
- Filter by alert type, severity, status, host, or organization.
- Review each alert: destination IP/port, bytes transferred, connection count, process name, time window.
- Investigate: Set status to "investigating" (only from "open" status).
- Resolve: Close as "confirmed" (real threat) or "false_positive".
Deduplication.
Each strategy checks for existing alerts within a 60-minute window to avoid duplicate alerts for the same ongoing activity.
Exfiltration alert triage
Follow this process for each exfiltration alert:
- Review the alert details: Check the destination IP, port, process name, and bytes transferred.
- Set to investigating: Click Investigate to claim the alert.
- Correlate with context: Check if the destination is a known service (backup target, CDN, cloud provider). Check if the process is expected (backup agent, update service).
- Resolve: If legitimate traffic, resolve as "False Positive". If a real threat, resolve as "Confirmed" and take appropriate incident response action.
Cannot investigate non-open alerts.
The "investigate" action is only available from the "open" status. Alerts that are already investigating or resolved cannot be set back to investigating.
Efficiency metrics
Efficiency metrics measure how quickly and effectively your team responds to alerts and remediations.
- Navigate to Security > Efficiency Stats.
- Set the period (default 30 days, max 365).
MTTAMean Time to Acknowledge: average minutes from alert trigger to acknowledgment.
MTTRMean Time to Resolve: average minutes from alert trigger to resolution.
Auto-Resolution RatePercentage of alerts resolved automatically (metric returned to normal without human intervention).
Toil Hours SavedEstimated hours saved by auto-resolution (30 minutes per auto-resolved alert).
Remediation Success RatePercentage of completed remediation executions with outcome "fixed".
Null values.
MTTA and MTTR return null if no alerts were acknowledged or resolved in the selected period. Extend the time range to get data.
Security dashboard
The security dashboard aggregates all security posture data into a single view.
- Navigate to Security > Dashboard.
Dashboard panels
Forecast summaryActive hardware forecasts grouped by severity (critical, high, medium, low).
Recommendation summaryActive resource recommendations grouped by type (downsize, upsize, optimal).
Baseline summaryTotal baselines, count in learning vs. enforcing, total open deviations.
Exfiltration summaryOpen and investigating exfiltration alerts grouped by alert type.
Permissions reference
| Action | Permission |
|---|---|
| View forecasts, recommendations, baselines, deviations, exfiltration alerts | security.view |
| View efficiency stats and security dashboard | security.view |
| Acknowledge/resolve forecasts | security.manage |
| Accept/dismiss recommendations | security.manage |
| Create/update/delete/reset baselines | security.manage |
| Acknowledge/whitelist/false-positive/resolve deviations | security.manage |
| Investigate/resolve exfiltration alerts | security.manage |
| Trigger forecasting/resource analysis engines manually | security.manage |
Navigation reference
| Feature | Location |
|---|---|
| Hardware Forecasts | Security > Hardware Forecasts |
| Resource Recommendations | Security > Resource Recommendations |
| Process Baselines & Deviations | Security > Process Baselines / Process Deviations |
| Exfiltration Alerts | Security > Exfiltration Alerts |
| Efficiency Metrics | Security > Efficiency Stats |
| Security Dashboard | Security > Dashboard |
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| No hardware forecasts generated | Hosts not reporting S.M.A.R.T., thermal, or memory metrics | Verify agents are collecting hardware health, thermal, and memory metrics. |
| Forecasts all show "info" severity | Metrics within normal thresholds | Expected behavior. Info forecasts with less than 0.1 probability are filtered out. |
| Forecasts not updating | Engine not running or no recent metrics | Check system health for the hardware forecasting heartbeat. Engine runs at 02:00 UTC daily. Trigger manually from the Forecasts page. |
| Recommendations show "insufficient_data" | Fewer than 100 data points in 30 days | Agent needs to report metrics for at least ~4 days at 5-min intervals. |
| Dismissed recommendation reappears | Should not happen | Dismissed records are skipped by the upsert engine. Check if someone deleted and re-created it. |
| Baseline stuck in learning mode | Fewer than 10 host-info submissions with process data | Host must send process data 10 times. Or manually switch to enforcement mode from the baseline detail view. |
| Baseline not detecting new processes | "Alert on New Processes" is disabled, or process already whitelisted | Check baseline settings. Check if the process was previously whitelisted. |
| LOTL binary not flagged | "Alert on LOTL Binaries" is disabled, or binary not in catalog | Verify the setting. The catalog covers 20 specific binaries. Others are treated as new process deviations. |
| No exfiltration alerts | Agents not collecting flow data | Verify agent flow collection is enabled (connection sampling must be turned on). |
| Exfiltration alert for legitimate traffic | False positive | Resolve as "false_positive". Thresholds are currently hardcoded. |
| Efficiency stats show null for MTTA/MTTR | No acknowledged/resolved alerts in period | Extend the time period to capture more data. |
| Security dashboard shows 0 everywhere | No active forecasts/recommendations/baselines/alerts | Run engines manually and verify hosts have metric data. |