How Wazuh file integrity monitoring catches unauthorized change
A security or compliance team needs to know when system binaries, configuration files or sensitive registry keys change outside approved work. Wazuh file integrity monitoring is the part of the Wazuh stack that answers that question. The Wazuh agent on each endpoint watches the paths and registry keys you define, sends change events to the Wazuh server, and the server stores and presents them through the Wazuh dashboard. These components run in infrastructure you control, so the change records stay within your own cloud accounts, data centers or air-gapped network. This section explains that chain, the points where it tends to fail, and what your team should confirm before treating its output as evidence.
The detection path has three stages, and each one needs an owner. The agent performs the monitoring on the endpoint, so its configuration decides which files, directories and Windows registry keys are watched and which attributes are compared. The Wazuh server receives those events, applies decoders and rules to classify them, and forwards the results for storage. The Wazuh indexer keeps the alerts, and the dashboard reads them from there. Wazuh agents run on Linux, Windows and macOS among other platforms, so one design can cover a mixed fleet, but the monitored locations differ by operating system. Confirm the exact monitoring options, scan behavior and attribute list for your agent version in the Wazuh documentation for the 4.14 line before you write them into your standard.
The hard part usually comes after the first configuration. Scope tends to grow as application owners ask for more directories, and every addition adds events that someone must review. Some paths change constantly for legitimate reasons, such as logs, caches, temporary files and package updates that rewrite binaries during patch windows. Baselines also need care. A Linux configuration file, a Windows system directory and a macOS application bundle each have different ownership, update mechanics and normal change rates, so one template rarely fits all. Decide early who approves changes to the monitored scope, who maintains exclusions, and how a baseline change after a patch is recorded so that it can be told apart from tampering.
An alert that a file changed helps with triage, but audit evidence has to meet a higher bar. Evidence needs a documented scope, a record of which monitored items changed and when, a link between each change and an approved change record, and proof that the records were kept intact and retained for the period your framework requires. Wazuh supplies the event data and prebuilt dashboard views for frameworks including PCI DSS, GDPR, HIPAA and NIST 800-53. Whether those views satisfy a specific control is an assessment question for your auditor, and the same applies to how you retain the underlying data. Ask your assessor early which artifacts they expect to see.
Do not treat detection as guaranteed. Wazuh file integrity monitoring reports changes to the locations it is configured to watch, but it does not promise that every unauthorized change will be caught, particularly on paths outside the defined scope or on hosts where agents are offline. Before go-live, run controlled test changes on a non-production host. As an illustrative example, edit a monitored configuration file and change a value in a monitored registry key, then confirm that each change appears in the dashboard with the expected context. Record the results, the monitored scope and the approved change process. That record is what your team can show alongside the configuration when someone asks how the control works.
Which Wazuh components file integrity monitoring depends on
File integrity monitoring in Wazuh depends on four components that work in sequence. Agents on endpoints detect file and registry changes, the server decodes and evaluates them, the indexer stores the resulting alerts, and the dashboard presents them to analysts. The server also delivers monitored paths to each agent, so scope decisions are made centrally.
Wazuh agents on each endpoint
The agent is the only Wazuh component that watches files on the endpoint itself. It compares monitored files and directories against a recorded baseline and reports creations, modifications and deletions. On Windows, the same agent also watches registry keys. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so confirm that every host operating system and version in scope is supported before you define paths for it. Check agent version compatibility with the server before rollout.
Wazuh server decodes and applies rules
The server receives events from agents and processes them in two steps. Decoders parse raw events into fields, and rules decide which of those events matter and at what severity. For file integrity monitoring, this is where a file change becomes an alert. Custom decoders and rules determine whether a change to a critical file is escalated or treated as routine, so test them against sample changes in your version before relying on them for evidence. The server can also run as a cluster to scale horizontally as agent count grows.
Wazuh indexer stores alerts
The indexer is a full-text search and analytics engine that stores the alerts the server produces. Its retention settings decide how long file change history stays searchable, which matters when auditors ask for evidence across a period. Storage grows with event volume, so frequent changes in noisy paths consume disk and slow investigation as well as analyst time. Confirm retention requirements with your compliance owner before you size the indexer, because those requirements drive how much history it must hold.
Wazuh dashboard for review
The dashboard is the web interface where analysts browse file integrity alerts, filter them by agent and path, and investigate changes. It includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. Those views show how alerts map to framework requirements, but they do not replace your own control scope. Confirm which views match your obligations and document how you use them. Access to the dashboard should follow your identity model, so review how users authenticate and which roles can view or change alert handling.
Remote agent configuration from the server
The server manages agent configuration remotely, and that is how monitored paths, exclusions and scan settings reach endpoints. Changes to file integrity scope are made once on the server and pushed to the agents that belong to the affected group. Confirm how agent groups target different server roles and which settings take effect without an agent restart. Test scope changes on a small group first, because an incorrect path list reaches every agent in that group at the same time.
Agentless devices without endpoint monitoring
Wazuh also monitors some devices without an agent, such as firewalls, through syslog collection and periodic API probing. These sources do not provide endpoint file integrity monitoring, because the agent is the component that watches files on a host. If a device in scope cannot run an agent, record that gap in your monitoring design and plan compensating log-based controls. Confirm the supported device types and collection methods in the Wazuh documentation for your version before you commit to coverage.
Which paths, registry keys and alert levels to watch
This table compares the main scoping decisions for Wazuh file integrity monitoring: how broadly to watch paths, when to scan, whether to include Windows registry keys and which changes should raise alerts. Read each row for when the option fits and what it costs in alert volume, agent load and review time. The main takeaway is that narrow, named scope with grouped alerting usually gives the cleanest compliance evidence, and broader scope should be added only where a control or threat model requires it.
| Decision | When it fits | Operational cost |
|---|---|---|
| Whole directories versus named critical files | Use whole directories for trees where any unexpected change matters, such as system binary or configuration locations. Use named files for a short list of security-relevant settings. | Directory-wide monitoring multiplies alerts from routine package updates and log rotation. Named files keep review focused but need upkeep when paths change. |
| Real-time versus scheduled scanning | Choose real-time for high-value locations where delay in detection is a concern. Choose scheduled scans for large trees and for paths that change in predictable batches. | Real-time monitoring adds ongoing agent CPU and I/O load on busy hosts. Scheduled scans concentrate load into windows but can miss short-lived changes between runs. |
| Windows registry keys versus file paths only | Include registry keys on Windows endpoints where the control or threat model covers autoruns, service settings or security policy keys. Limit to file paths where Windows is out of scope or registry changes are not in the requirement. | Registry monitoring adds a separate set of keys to maintain and can produce frequent changes from applications. Expect more tuning time on Windows fleets than on file-only Linux scope. |
| Alerting on every change versus selected groups | Alert on every change only for a small, high-value scope with a named owner who reviews each event. Use selected groups or alert levels for broader scope so reviewers see the changes that matter first. | Alerting on every change produces the highest review workload and risks alert fatigue. Grouped alerting needs upfront rule design and periodic review as systems change. |
| Scope documented against control requirements | Use a written scope that maps each monitored path or key to the control or risk it supports. This suits audits where an assessor asks why a location is or is not monitored. | Documenting scope takes analyst time up front and must be revisited after major changes. Skipping it often leads to unexplained exclusions during assessment. |
| Exclusions for expected churn | Exclude paths such as temporary or cache directories that change constantly without security meaning, after confirming the exclusion with the system owner. | Each exclusion reduces noise but creates a blind spot that must be recorded and reviewed. Overly broad exclusions are a common cause of missed changes. |
| Confirm before going live | Confirm the exact configuration syntax, scan frequency options and supported registry settings for your agent version in the Wazuh 4.14 documentation before setting values. | Settings chosen from memory or older releases can fail silently or behave differently, which adds test time. Ask the implementation partner to test each setting on a representative host. |
How to configure file integrity monitoring step by step
This sequence moves from a healthy Wazuh 4.14 deployment to file integrity monitoring that covers every in-scope endpoint. Each step ends with a check you can verify in the dashboard, so the team can see that the configuration reached the intended hosts before the rollout widens.
Confirm Wazuh 4.14 components and agent enrollment
Start by checking that the Wazuh indexer, Wazuh server and Wazuh dashboard are running the 4.14 line and are healthy after any recent patch. Then confirm that every target endpoint has an agent that is enrolled, connected and reporting to the server. The step is done when each in-scope agent shows as active in the dashboard and the server logs show no repeated enrollment or connection errors. Problems with enrollment make later FIM results hard to trust, so hold configuration work until this check passes. Confirm the health check commands and enrollment steps for your platform in the Wazuh 4.14 documentation.
Inventory critical files and registry keys by platform
Work with system owners to list the files, directories and, on Windows, registry keys that matter for your controls and threat model. Group the list by operating system, because Linux paths, Windows registry locations and macOS paths follow different conventions. Record the owner and the reason for each entry, and include configuration that changes rarely, such as authentication settings, privileged tooling and application configuration. The step is done when security and operations have both reviewed a written inventory for each platform, with paths written exactly as the agents will see them. Confirm the path syntax and monitoring options for each platform in the Wazuh 4.14 documentation before you write any configuration.
Define agent groups for each endpoint class
Create agent groups that match the classes in your inventory, such as web servers, database hosts, domain controllers and workstations. Each group should hold endpoints that share an operating system and a similar set of critical paths, so one configuration fits every member. Write a short rule that states who decides group membership and how new hosts are placed. The step is done when every enrolled agent in scope belongs to exactly one intended group and the dashboard shows the membership you documented. Agents with no group, or with overlapping groups, are a common source of confusing FIM results later, so check membership before going further.
Apply the FIM configuration centrally
Write the file integrity monitoring settings in the shared configuration for each agent group on the Wazuh server, so that member endpoints receive them automatically. Set the monitored directories and files for each group, the scan frequency, and any real-time monitoring options your platform supports. Keep change reporting on for sensitive files only, since storing content diffs for everything adds load. The step is done when the server shows the new configuration for each group and each pilot agent marks the configuration as synced after its next check-in. Confirm the exact directive names and syntax against the Wazuh 4.14 documentation for each operating system.
Establish baselines and test changes on a pilot
Choose a small pilot group that includes a representative host for each operating system and endpoint class. Allow the agents to complete their initial baseline scan, then make a controlled change to a known test file inside a monitored directory on each host. The step is done when every pilot agent reports a baseline and each test change appears in the dashboard with the correct agent name, path and event type. If a change does not appear, check the agent group, the synced configuration and the agent logs before changing any rule. Keep the test steps in a written runbook so the same checks can be repeated for later groups.
Tune noise and confirm evidence on the pilot
Review the pilot alerts over a review window that the security and operations teams agree on in advance. Identify expected churn, such as log rotation, package caches and temporary directories, and exclude it using the ignore settings documented for your version. Adjust alert levels where needed, and record each exclusion with its owner and reason. The step is done when the pilot alert volume is reviewed, every exclusion has a recorded reason, and a sample of alerts can be traced to a changed file and to an approved or investigated change. Exclusions should be reviewed regularly, because excluding too much can hide the changes you need to see.
Widen the rollout one group at a time
Apply the tuned configuration to the next agent group, repeat the baseline and test-change checks, and then continue group by group. Watch endpoint resource use and indexer load after each group, and keep a copy of the previous group configuration so you can roll back quickly if needed. The step is done when every in-scope group reports a baseline and its test alert appears in the dashboard, and the compliance or evidence view contains the expected FIM alerts for each group. Record the final group membership, configuration versions and exclusions so the setup can be reproduced after upgrades.
Why FIM floods alerts and how to tune the noise out
Most file integrity monitoring floods come from paths that were never meant to be integrity-checked as static content. In a Wazuh deployment, the agent's syscheck module watches the directories and Windows registry keys listed in its configuration, and every change it sees becomes an alert that flows through the Wazuh server into the indexer and dashboard. The first step in tuning is to recognize the usual sources of noise: application log files and temporary directories that change constantly, package updates that rewrite system binaries on a schedule, antivirus and backup agents that touch files as part of their normal work, and registry values that update on every boot. Treat these as expected behavior to be managed, not as incidents to be read one by one. The tuning method starts with classification. For each watched path, record what kind of change is expected: none (binaries and configuration that should only change through change control), scheduled (package managers and patch windows), or continuous (logs, caches, spool directories, and paths owned by security tools). Then act on each class. Continuous paths should be excluded from the main syscheck directives or moved into a separate monitored set with its own rule handling, so they do not compete with high-value alerts. Scheduled changes can be routed by agent group, so that a patch window on one group produces change events that a reviewer expects, while the same change on a server group that should be frozen still raises an alert. Agent groups in the Wazuh server let you apply different syscheck settings to different roles without maintaining separate agent builds. Review alert levels in the dashboard after each change. Filter the file integrity events by agent group and by rule, then check which rules fire most often and whether their alert levels match the risk of the change. A rule that fires thousands of times a day for expected activity usually needs either an exclusion or a lower level, and the decision should be made against the actual event stream rather than from memory of the original configuration. Confirm the exact syscheck options and rule IDs against the Wazuh documentation for the 4.14 line before editing them, because option names and defaults can change between releases. Every exclusion carries a trade-off. Excluding a path reduces noise, but it also removes that path from the evidence record, so a later investigation or auditor question about it may find nothing. Before excluding anything, decide whether the path could hold data an investigator or assessor would expect to see, and whether a narrower filter (for example, excluding a specific file pattern while keeping the directory) would achieve the same result. Each exclusion should have a written reason, a named owner who can justify it, and a review date. Keep these records alongside the agent configuration, since they become part of the control narrative when you later map FIM coverage to compliance requirements. Before going live with a tuned configuration, ask the owner of each high-churn exclusion to confirm that the excluded path holds no data they would need to prove integrity for. Then run the tuned configuration in a test agent group long enough to cover a patch cycle and a backup window, and check that the events you expected still appear. This check is inexpensive compared with discovering a gap during an incident or an assessment, and it gives you a documented basis for the exclusions you kept.
What drives FIM effort and cost on a self-hosted rollout
This table lists the factors that change how much work a Wazuh file integrity monitoring rollout takes, how each one moves effort, and what you can do to keep it contained. Read the one-time and recurring columns together, since most of the ongoing cost comes from review and rule upkeep rather than from the initial setup. The main takeaway is that agreeing scope, path templates and exclusions before rollout does more to control cost than any single technical choice.
| Driver | How it changes effort or cost | How to keep it down |
|---|---|---|
| Number and mix of endpoints | Linux, Windows, macOS and other agent platforms each need their own path sets, syntax and testing. Each platform adds packaging, enrollment and validation work, and the self-hosted software itself carries no license fee. | Group endpoints by operating system and role, then reuse agent groups so one centrally managed configuration covers many hosts. |
| Number of distinct critical path sets | Every distinct set of files, directories and Windows registry keys needs an owner, a justification and a test. Effort grows with the number of roles and applications, not only with host count. | Start from standard path templates per platform and role, and add application-specific paths only where an owner has signed off. |
| Compliance scope and evidence requirements | Mapping monitored paths to a framework such as PCI DSS or NIST 800-53 requires documented rationale, retained alerts and proof of review. Each framework you claim adds mapping and evidence work. | Confirm with your assessor which controls require file integrity evidence before design, and limit the framework list to those controls. |
| Integration with change tickets or SIEM rules | Linking FIM alerts to change tickets or custom rules requires matching each alert to an approved change. Integration design, testing and maintenance are recurring work when ticket workflows change. | Agree the ticket fields and alert fields to match before build, and keep correlation logic in a small, documented rule set. |
| Number of environments (production, staging, development) | Each environment needs its own agent configuration, exclusions and test runs. Drift between environments creates noise and rework during audits. | Keep one shared baseline template and apply environment-specific differences as documented overrides. |
| Quality of the existing baseline | A clean, known-good reference for critical files reduces tuning. Without one, the first scans produce large volumes of expected change alerts that must be reviewed and suppressed by hand. | Capture a verified baseline during a controlled window before enabling alerting, and record who approved it. |
| Exclusion rules agreed before rollout | Late exclusion requests during the pilot extend tuning cycles and can hide real changes if approved without review. | Agree exclusion criteria and an approver in writing before the pilot, and review exclusions on a fixed schedule. |
| One-time work: design, pilot and tuning | Scope definition, path template design, agent group setup, pilot runs and alert tuning happen once per rollout, though new platforms or frameworks reopen parts of it. | Ask any quote to itemize these phases separately so you can see which work is fixed and which is open-ended. |
| Recurring work: review, rule upkeep and upgrades | Alert review, periodic path reviews, rule updates after Wazuh upgrades and testing on each patch release continue after go-live. Wazuh has shipped 4.14 patch releases roughly every one to two months, according to its release notes, so upgrade testing is a standing cost. | Budget for a fixed review cadence, keep custom rules under version control and ask any support plan to state what upgrade testing it covers. |
How FIM changes across single node, clustered and air-gapped deployments
A single-node, all-in-one Wazuh deployment runs the indexer, server and dashboard on one host, so FIM configuration is managed in one place. The server distributes agent configuration to every enrolled endpoint, and the paths you monitor are usually defined in the shared configuration for an agent group. Because there is no second server to keep in step, a change made on the server reaches agents on the next configuration sync. This is the simplest context in which to test FIM rules, but the same host stores alerts and performs analysis, so FIM event volume competes with dashboard and search performance.
- Staging: Draft new monitored paths and exclusions on a small lab group before moving them to production groups.
- Groups: Keep separate agent groups for servers, workstations and sensitive hosts so each receives only the paths it needs.
- Load: Watch indexer disk and memory after enabling recursive monitoring on large directory trees.
- Rollback: Keep the previous group configuration so a noisy rule can be reverted without waiting for a rebuild.
Confirm the sync interval and the reload behavior for your agent version in the 4.14 documentation before you schedule a change window.
The Wazuh server can run as a cluster for horizontal scaling, and it manages agent configuration and upgrades remotely. In a clustered design, agents connect to worker nodes while a master node coordinates shared state, including the group configuration that holds FIM settings. The FIM policy itself does not change because of clustering, but the delivery path does. A worker that is unreachable or lagging can leave some agents running an older monitoring policy, which matters when an auditor asks whether a path was monitored on a given date.
- Source of truth: Edit group configuration only through the central management path so every worker distributes the same version.
- Connections: After each change, check agents on each worker node, since an agent enrolled to a degraded node may apply new FIM settings late.
- Event flow: FIM alerts from all workers converge in the indexer, so size shards and disk for the combined FIM volume, not one node's share.
- Evidence: Record the configuration version applied to sample agents from each worker for the change record.
Ask your implementation partner or the vendor to confirm how 4.14 handles group configuration distribution when a worker node fails.
The Wazuh offline installation guide covers systems without internet connectivity. In an air-gapped deployment, every package, rule update and reference dataset must arrive through a controlled transfer, and the server cannot fetch group content or updates on its own. For FIM, this shifts the work from the console to the transfer process. Vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform, so the software inventory that agents collect is correlated against data you imported yourself.
- Transfer: Build a documented process for moving packages and rule sets across the boundary, with checksums checked on both sides.
- Groups: Create and manage agent groups on the local server, with no dependency on external sources for group changes.
- Approval: Record who approved each import and which version it contained, so the change history can be reproduced.
- Verify: Confirm that a test file change produces an alert in the dashboard with outbound connections blocked, and that time sync uses an internal source.
Confirm which offline repository content applies to your 4.14 build in the offline installation guide before you set the transfer schedule.
Wazuh documents Docker and Kubernetes as deployment options for its server components. Endpoint agents still run on hosts, though, so FIM on containerized workloads raises a separate question: whether the host agent can see the files that matter inside containers and mounted volumes. Container filesystems are usually ephemeral, so a redeploy can reset what the agent sees as a baseline. Plan the FIM scope around persistent volumes and host paths rather than the container image layers.
- Server components: Run the indexer, server and dashboard with persistent volumes for indexer data, so alert history survives a redeploy.
- Agents: Install agents on the cluster host nodes and decide which mounted paths should be monitored from the host side.
- Baselines: Test how FIM reports a redeployed workload, since new container layers can look like mass changes.
- Configuration: Deliver group configuration through your normal Kubernetes change process, after checking how the agent reads it.
Confirm support for agents on containerized workloads against the 4.14 documentation before committing, and run a redeploy test on a non-production cluster first.
Protecting the FIM baseline and evidence from tampering
File integrity monitoring is only as trustworthy as the controls around it. The baseline, the agent configuration, the people who view alerts and the stored evidence all need to resist tampering, or an attacker can hide changes from the very system meant to detect them.
Restricting agent group configuration changes
FIM scope, ignore rules and alert behavior are pushed to endpoints through agent groups managed on the Wazuh server. Limit who can edit those group files and who can assign agents to groups, and keep changes under version control with peer review. An attacker who can narrow the monitored paths or add an exclusion can blind the agent without touching the files they want to hide. Check the change history against the monitored directories for each group.
Protecting dashboard and API accounts
Accounts that view, search or export FIM alerts can reveal what has changed and where, and API tokens can alter server settings. Separate read-only analyst roles from administrators, remove default credentials, and require strong authentication for administrative access. Review who holds export rights and log their activity. Confirm which roles can change agent configuration through the API before go-live.
Controlling agent enrollment
An unauthorized host that enrolls with the server can receive the agent configuration, including monitored paths, and can submit forged reports. Restrict enrollment to approved credentials, require enrollment only from known build or provisioning pipelines, and review newly registered agents against your asset inventory. Confirm how enrollment passwords are issued, rotated and revoked in your version of the platform.
Detecting agent disconnection
A root or administrator on an endpoint can stop or alter the agent, after which changes on that host go unreported. Alert when an agent stops reporting within an expected window, and treat unexpected disconnections on high-value systems as potential incidents. Pair this with checks on agent version and configuration drift. Tune the timeout so routine maintenance does not flood analysts with false alarms.
Securing indexer storage for FIM alerts
The Wazuh indexer stores FIM alerts as evidence, so its indices need access control that matches the sensitivity of the data. Restrict direct index access to the service accounts that need it, and limit administrative rights on the indexer nodes. Define retention rules that meet your evidence obligations without deleting records early. Ask your team to confirm how index-level permissions and snapshots are configured for your version.
Keeping alert evidence complete
Evidence is only useful if its gaps are visible. Verify that FIM alerts from each monitored host reach the indexer, and watch for sudden drops in event volume that could indicate suppression. Record who changed rules, decoders or ignore lists and when. Periodically compare alert counts against the expected baseline of changes. This check turns silent loss into a reviewable finding.
How to prove FIM detects change and fails safely
Proving that Wazuh file integrity monitoring works means testing two things: that a change to a monitored item produces an alert with the right details, and that a broken monitoring pipeline shows up as a gap instead of silence. Both should be run on a pilot endpoint before the monitored scope is trusted for compliance evidence. Agree the test plan in writing with the team that owns the endpoints, and keep the plan under change control so it can be repeated after upgrades.
For detection, make controlled changes to a test file, a test directory and, on Windows, a test registry key that the FIM configuration covers. Run the same set on each OS class in scope, such as Linux, Windows and macOS, because the monitored paths and attributes differ by platform. For each change, record the time you made it, then confirm in the Wazuh dashboard that the alert names the expected path, the expected agent and a timestamp that matches your record within the tolerance you set. Check that the clock on the endpoint and the server is synchronized, or the timing check will fail for reasons unrelated to FIM.
Exclusions need the same scrutiny as detection. Write each excluded path into the test plan, change files inside it and confirm no alert appears. Then change a file in a neighboring path that the exclusion does not cover and confirm that alert does appear, so you know the exclusion is narrow. Each exclusion should also appear in the change record with its owner, the reason it exists and the review date. An exclusion that nobody can explain is a finding in its own right during an assessment.
Failure testing covers the agent and the back end. Stop the Wazuh agent on the pilot endpoint and confirm that the disconnection appears in the agent status view within the window your monitoring standard allows. For the server and indexer, simulate an outage in a non-production setting, then confirm with the vendor documentation how the agent handles events raised during the outage and whether they are replayed or lost. Whatever the behavior, the test passes only if the gap is visible in the dashboard or in a health alert, so an auditor can see when evidence was not collected.
The test records are themselves evidence. Keep a log for each test with the test identifier, the change made, the time, the expected result, the observed result, the tester and the reviewer. Export the matching alerts and screenshots of the agent status view, and store them with the plan version they were run against. Rerun the full set after each Wazuh upgrade and after any change to FIM rules or exclusions. Auditors assess the controls and the evidence independently, so the aim is a repeatable record that shows what was tested, what happened and what was done about any gap.
What to monitor, back up, upgrade and document after go-live
This table lists the recurring work after a Wazuh file integrity monitoring rollout, with what to check and the record each activity should leave behind. Read each row as a routine that an assessor or incident responder may ask you to show. The main takeaway is that FIM evidence is only as credible as the exclusion decisions, retention settings and retest records behind it.
| Activity | What to do | Evidence to keep |
|---|---|---|
| Agent connection status | Check that enrolled agents are reporting on schedule and investigate agents that go silent, since unmonitored hosts produce no FIM events. | Dated status reviews with the agents flagged and the action taken for each |
| FIM alert volume trends | Track syscheck alert counts per host and per monitored path over time. Sudden spikes often point to noisy paths, a new deployment or a real change that needs review. | Trend reports with notes on any spike and its root cause |
| Exclusion list review | Review exclusions on a fixed schedule and after major application or OS changes. Remove any exclusion that no longer has a valid reason. | Exclusion register showing each entry, its owner, its reason and the last review date |
| Agent group and server configuration backup | Back up agent group files, the shared configuration and server settings before each change, and store copies outside the Wazuh hosts. | Versioned configuration backups linked to change tickets |
| Indexer data retention | Set indexed alert retention to the period required by the compliance frameworks you map to. Confirm that period with your assessor or framework owner before setting it. | Written retention policy and index lifecycle settings matching that policy |
| Upgrades across the 4.14 line | Upgrade indexer, server, dashboard and agents in the order set out in the Wazuh upgrades and support topic. Watch the 4.14 patch releases in the Wazuh release notes. | Upgrade plan, rollback steps and a record of each component's version before and after |
| FIM retest after changes | After every upgrade or configuration change, make controlled test changes in each monitored path and confirm the alert appears in the dashboard. | Test scripts, expected and actual results, and the date and tester for each run |
| Monitored path and alert review records | Keep the monitored path inventory current. Record who reviewed FIM alerts, what was triaged and how each alert was resolved. | Path inventory with owners and reasons, plus signed alert review logs |
How much work is Wazuh file integrity monitoring and what do we need to provide?
What drives the effort for setting up Wazuh file integrity monitoring?
Effort depends mostly on how many systems you monitor, how many paths and registry keys they include, and how well those paths are defined. The main drivers are the number of endpoints and operating systems, the number of directories and Windows registry keys to watch, how many owners must approve each list, and how much tuning the alert noise requires. Scope that includes compliance evidence adds mapping and review time. Hosts that change constantly, such as CI runners and container hosts, usually need more tuning than stable application servers. The Wazuh documentation describes the file integrity configuration options, so confirm which options apply to each operating system before estimating. A quote should separate setup work from tuning and evidence work, because those scale differently.
How long does a Wazuh file integrity monitoring rollout usually take?
The duration depends on scope and on how ready your inputs are, and no single timeline fits every environment. A typical sequence runs through scoping, a pilot on a small set of representative hosts, tuning the path lists and alert rules, then a staged rollout and evidence capture. The slowest step is often not the technical install but getting asset owners to agree on which paths matter and how changes are approved. If owners respond slowly, the schedule slips regardless of engineering speed. Ask for milestones in the written scope that are tied to inputs from your side and to change windows you control. Use your own host count, change frequency and approval cycle to judge the range, and check Wazuh release timing in the release notes before you start, since the 4.14 line receives frequent patch releases.
What does our internal team need to provide before the work starts?
Plan for four groups of inputs before work begins. First, named asset owners who can approve which systems and paths are in scope. Second, path and registry key lists for each system class, with the reason each item matters, such as configuration files, authentication files or executables. Third, your change process: how approved changes are recorded, the windows they occur in, and who reviews alerts that match a change. Fourth, access: administrative rights on endpoints for agent installation and configuration, and access to the Wazuh server, indexer, dashboard and API in the environment you control. Also provide a non-production host group for testing. Missing any of these usually shows up first as schedule delay.
Can one capable internal engineer set up Wazuh file integrity monitoring alone?
Yes, for a small and well-defined scope, if that engineer already runs Wazuh and administers both Linux and Windows endpoints. The harder part is time and breadth, not the agent installation. Registry monitoring on Windows, path design across several operating systems, alert tuning and mapping output to compliance controls each need attention. One person often cannot run a pilot, tune alerts and roll out to production while also handling ongoing operations. Check three things: whether anyone has run file integrity monitoring before, whether the pilot can get change approval, and whether review cycles are blocked on the calendar. If any answer is no, a fixed-scope engagement can cover the parts that take longest to learn, while your engineer keeps ownership of the platform.
What should a fixed-scope quote for this work include?
A useful quote states what is in scope and what is not, so both sides can check the work at the end. Expect it to list the operating systems and endpoint groups covered, the monitored path and registry key inventory or the method used to build it, and the configuration and rule changes to be delivered. It should name deliverables such as a tuning report, a runbook and evidence notes, and set acceptance criteria tied to a pilot group. It should state assumptions about your inputs, such as access, owner availability and change windows, and list exclusions, such as indexer sizing or other Wazuh modules. It should also explain how scope changes are handled and what support follows go-live. Fixed-scope work is agreed in writing before it starts, and the quote follows from that written scope.
What happens after go-live with file integrity monitoring alerts?
After go-live, the work shifts from building to running. Someone must own alert triage, decide which changes are expected, and review which paths generate noise each month or each release cycle. Wazuh ships 4.14 patch releases roughly every one to two months, so upgrades and retesting of custom rules become recurring tasks, and the release notes should be checked before each one. Compliance evidence also needs periodic export and a record of approved changes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and those can cover these tasks if you want an outside team to carry them. Agree in writing who handles triage, who approves path changes and how upgrades are tested before they reach production.
Which factors make file integrity monitoring noisy and costly to tune?
Noise usually comes from paths that change for normal reasons: package updates, log rotation, container layers, caches and temporary files. Each source adds alerts that operators learn to ignore, which weakens the monitoring. Tuning means excluding those locations or lowering alert levels only after you document the reason, and keeping high-value paths such as authentication files, system binaries and security policy at full sensitivity. Windows registry keys follow the same logic. Check tuning by comparing alert volume and the share of alerts linked to approved changes before and after each adjustment, starting with a pilot group. Ask the team to show how each exclusion was justified, because auditors will review that record.
How DeployOpen scopes, builds and hands over Wazuh file integrity monitoring
DeployOpen plans, implements, documents and supports Wazuh file integrity monitoring inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer once monitoring is live.
How we scope
- Inventory the critical files, directories and Windows registry keys your compliance and security owners need monitored.
- Confirm which Linux, Windows and macOS endpoints will run the Wazuh agent and how they enroll.
- Record the deployment model, including whether the Wazuh server and indexer run in your network without internet access.
- Agree in writing which noise-reduction and exclusion rules are in scope and who approves them.
How we build
- Configure syscheck monitoring on agents using agent groups so each server role gets its own monitored paths.
- Tune ignore rules and alert levels in steps, testing each change against realistic change activity on a non-production group first.
- Test that file creation, modification, deletion and permission changes produce the alerts you specified.
- Map resulting alerts to the compliance views your team relies on, and confirm the evidence fields with your assessor.
How we hand over
- Deliver a written configuration record covering monitored paths, exclusions, agent group assignments and alert thresholds.
- Provide test cases and results showing which changes were detected and which were intentionally suppressed.
- Document how to add a path, change an exclusion and roll the configuration out through agent groups.
- Walk your operations and security staff through daily alert triage and the change approval process.
How we support
- Review new alert sources and false positives on an agreed schedule after go-live.
- Retest file integrity rules after Wazuh 4.14 patch upgrades, since agent and server changes can affect detection.
- Update monitored paths and exclusions when your applications, servers or compliance scope change.
- Offer ongoing support and continuous testing as a retainer, with scope agreed in writing.
