Teams should refresh the index pattern so the dashboard recognizes the new fields and displays them in Security events. Without that step, the telemetry exists but is difficult to use for searches and visual analysis. After refresh, analysts can query the relevant rule IDs and review CPU, memory, disk, and network values directly.
Why This Matters for Security Teams
When Wazuh starts showing new macOS fields as unknown, the issue is usually not missing telemetry. The data may already be flowing, but the dashboard cannot interpret the updated schema until the index pattern is refreshed. That matters because analysts lose searchability, field-level pivots, and the ability to build reliable views of system activity. For security operations, a display problem can quickly become a blind spot in detection, triage, and reporting if it is left unresolved.
This is especially important in environments where endpoint telemetry supports incident response, compliance evidence, or workload baselines. If the dashboard cannot resolve the new fields, teams may underestimate host resource usage or miss patterns in CPU, memory, disk, or network behavior that should be visible during investigation. The control issue is not the macOS agent itself but the analytics layer that sits between ingestion and analyst workflow. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because security monitoring only works when collection, review, and analysis are aligned end to end.
In practice, many security teams discover this only after an investigation stalls because the right fields were ingested but could not be queried cleanly.
How It Works in Practice
The fix is straightforward, but it sits in the right operational sequence. First, confirm that the macOS agent or data source is actually emitting the new fields. Then refresh the index pattern or field mapping in the dashboard layer so the search index understands the updated schema. After that, validate that the fields appear in Security events and can be used in filters, searches, and visualizations.
A practical workflow usually looks like this:
- Verify the underlying events are arriving with the expected rule IDs and host telemetry.
- Refresh the dashboard index pattern so newly added fields are discovered.
- Confirm the fields are searchable and can be added to event tables or panels.
- Test a few analyst queries, including resource metrics such as CPU, memory, disk, and network values.
- Document the change so future field additions follow the same review path.
This matters because field discovery is often treated as a cosmetic step, when it is really part of detection engineering hygiene. If an event field is unknown, it may still exist in storage, but it is not operationally dependable until the analytics layer has been updated. For teams using endpoint telemetry as part of broader monitoring, it is also sensible to align the refresh process with change management and detection validation so new schema elements do not quietly bypass analyst workflows.
For teams that manage many index patterns or heavily customized dashboards, Kibana index pattern guidance can help explain the mechanics of field discovery and refresh behavior. These controls tend to break down when dashboards are cloned across environments without a schema refresh because analysts assume the visual layer is current even though the underlying field set has changed.
Common Variations and Edge Cases
Tighter schema management often increases operational overhead, requiring organisations to balance faster dashboard usability against more deliberate change handling. In small environments, a manual refresh may be enough. In larger deployments, best practice is evolving toward a documented process that ties schema updates to content reviews, saved searches, and analyst validation.
There are a few common edge cases. If the fields still show as unknown after a refresh, the issue may be a mapping mismatch, an ingest pipeline problem, or a version gap between the agent and the dashboard stack. If only some fields appear, the source may have changed its event structure incrementally, which makes partial validation easy to miss. If a team uses custom fields or enrichment, there is no universal standard for naming discipline across all macOS telemetry pipelines, so consistency becomes a local governance decision rather than a platform guarantee.
The key operational distinction is this: unknown fields in the dashboard do not always mean bad collection, but they do mean incomplete usability. Teams should treat the refresh as the first corrective action, then verify the telemetry path if the problem persists. This approach keeps analysts focused on evidence rather than interface friction, and it reduces the chance that a working sensor is mistaken for a broken one. The guidance breaks down in highly customized multi-tenant deployments where index templates, saved objects, and access controls are managed separately across environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Unknown dashboard fields affect continuous monitoring and analyst visibility. |
| MITRE ATT&CK | T1082 | CPU, memory, disk, and network telemetry support system discovery and host assessment. |
Confirm telemetry is visible, searchable, and continuously reviewed after schema changes.
Related resources from NHI Mgmt Group
- How should security teams investigate an EKS privilege escalation after a CloudTrail alert shows new IAM key creation?
- How should security teams use AI in secret scanning without creating new blind spots?
- Should security teams replace PAM with a new identity model?
- How should security teams replace traditional MFA without creating new access friction?
