Open source anti-malware for CIS Control 10

Open source anti-malware for CIS Control 10: the short answer

An enterprise that must meet CIS Control 10 and has not yet chosen tooling should know that open-source platforms can evidence two of its Safeguards well: central management (10.6) and behavior-based anti-malware (10.7). Wazuh, licensed under GPL-2.0, collects endpoint telemetry into a central server, manages agent configuration remotely and runs agents on Linux, Windows and macOS. The open decision is signature-based anti-malware on every asset under Safeguard 10.1. Settle that per operating system before choosing tools. For each candidate, confirm whether its agent performs on-access signature scanning, how signatures update automatically (Safeguard 10.2), and who approves the update source.

Scope depends on your Implementation Group. Safeguard 10.1 applies to every enterprise, so an IG1 enterprise meets its anti-malware baseline with that Safeguard alone. Safeguards 10.6 and 10.7 are assigned to Implementation Group 2 and apply to IG2 and IG3 enterprises. Both sit in the Devices asset class, with 10.6 in the Protect function and 10.7 in the Detect function. These mappings come from CIS Controls v8.1, published on 24 June 2024 and still the current version on cisecurity.org as of October 2026. Confirm the wording against the CIS Critical Security Control 10 page before you write requirements into a contract or a policy.

CIS Controls do not replace any regulatory, compliance or authorization scheme, and CIS says so itself. A bank, clinic or federal contractor still answers to its own rules, and those rules may ask for evidence that Control 10 does not describe. The FTC Safeguards Rule, for example, requires covered financial institutions to monitor and log the activity of authorized users, which is a different obligation from anti-malware deployment. Ask your assessor which framework mappings they will test. The CIS Controls Navigator lists mappings for v8.1, and you should check that the mapping for your framework matches your scope before you design the evidence.

Mapping each Control 10 Safeguard to what the function must do

This table maps the four Control 10 Safeguards in this section to the requirement in plain words, what the function must do, and how Wazuh, Security Onion, Velociraptor or osquery can support it. Read the last column first: open-source tools can evidence configuration, update status and detections, but they do not by themselves prove that a signature-based or behavior-based anti-malware engine is installed and running on every asset.

Safeguard	What the function must do	How to configure it with open-source tools
10.1 Deploy and maintain anti-malware software (all IGs)	Install anti-malware software on every enterprise asset in scope and keep it maintained. Keep an inventory of assets that should have the engine, and record exceptions.	Use Wazuh agent inventory and syslog or agentless collection to list hosts reporting. Use osquery or Velociraptor artifacts to check for installed AV products. Flag hosts that report no engine. Confirm in the vendor documentation which engine and version each platform should run, because Wazuh reports agent and file activity but does not itself confirm an anti-malware product is installed.
10.2 Configure automatic anti-malware signature updates (all IGs)	Keep signatures or detection content current on a schedule the enterprise sets, with update status visible to the function that owns it.	Forward update logs from the endpoint engine to the Wazuh server with decoders and rules that alert on stale definitions. Use osquery to report signature file dates or engine version. For air-gapped hosts, confirm how signature packages reach the enclave. Check the vendor documentation for the update mechanism and its supported log fields.
10.6 Centrally manage anti-malware software (IG2 and IG3)	Manage policy, deployment, health and alerts for anti-malware from a central point rather than host by host.	Use Wazuh server to manage agent configuration and upgrades remotely and to store alerts in the Wazuh indexer, with the dashboard as the central view. Use Security Onion as a central monitoring point for network and host telemetry. Confirm whether the chosen anti-malware product has its own central console and how its alerts reach Wazuh. Central management of the agent does not replace management of the anti-malware engine.
10.7 Use behavior-based anti-malware software (IG2 and IG3)	Detect malicious behavior such as unusual process chains, script misuse or injection, not only known file signatures.	Use Wazuh rules and active response to alert on suspicious process and command activity from agent telemetry. Use Velociraptor hunts and osquery queries to look for behavior patterns across endpoints. Confirm with the behavior engine vendor which behaviors it detects and whether it sends events to Wazuh. Open-source rules and queries add detection but are not a substitute for a behavior-based engine if the Safeguard is to be evidenced as met.

Which open-source tools fit each Safeguard and which need a commercial anti-malware product

Wazuh is the most direct open-source fit for central management under Safeguard 10.6. Its server manages agent configuration and upgrades remotely, and the dashboard gives one place to see agent status, alerts and compliance views. Wazuh is distributed under the GNU General Public License version 2, so the server and agents can be run inside your own environment without a per-endpoint license fee, although support and hosting costs still apply.

Central management (10.6): Agents report to a server you operate, and configuration is pushed from that server rather than set host by host.
Malware and file integrity monitoring: Wazuh can flag suspicious files, rootkit indicators and unexpected changes to monitored paths, which supports detection work under 10.7.
Active response: Scripted responses such as blocking an address or stopping a process can run when a rule fires, but each action needs review and a rollback plan.
Deployment options: Installation options include an OVA, Docker, Kubernetes, Ansible, Puppet and an offline guide for hosts without internet access.
Coverage limits: Wazuh does not block a file on arrival through signature prevention, so it does not by itself satisfy the prevention intent of 10.1 or 10.2.

Before relying on Wazuh for 10.6, confirm with your team which operating systems and versions your fleet runs and whether the agent version you plan to deploy supports them.

Open-source platforms that fit Control 10 and why

No single open-source project replaces a commercial anti-malware engine, so Control 10 is usually met by combining an endpoint agent platform, live query and hunting tools, and network sensors. Each card below states what the tool contributes to Safeguards 10.1, 10.6 and 10.7 and where it stops.

Wazuh for central endpoint management

Wazuh is licensed under GPL-2.0 and its current release line is 4.14. Its four components are the indexer, the server, the dashboard and the agents on endpoints, so one console can show agent status, configuration and alerts across the estate. The server can run as a cluster for scale and push agent configuration and upgrades remotely, which supports central management under Safeguard 10.6. Offline installation covers isolated networks. Check whether its file integrity and malware-related rules meet your signature update and behavior-based detection expectations, because Wazuh alone is not a full anti-malware engine.

Velociraptor for hunting and collection

Velociraptor runs live queries and forensic collections across endpoints, which helps you confirm whether malware is present on hosts that Safeguard 10.7 expects you to watch for suspicious behavior. It is a strong fit for investigating alerts and sweeping the fleet after a detection. It does not stop malware by itself and does not replace a signature or behavior engine on every host. Confirm its license terms, agent resource use on your oldest systems and how it reaches hosts that are offline or segmented before you rely on it for evidence.

osquery for endpoint state

osquery exposes operating system state as SQL tables, such as running processes, listening ports, startup items and installed software. Teams use it to check that protection settings, disk encryption and unexpected persistence mechanisms are present on each device. It reports conditions that point to malware activity but does not block execution. Plan for query load on endpoints, define which tables you need, and confirm how results reach a central store. Security Onion also bundles osquery, so check whether you already have it deployed before adding a second copy.

Falco for container runtime behavior

Falco watches system calls on Linux hosts and container nodes and flags behavior such as unexpected shell launches or privilege escalation. That makes it a useful behavior-based detection layer for Safeguard 10.7 on Kubernetes nodes, where traditional agents often cover the host poorly. It is not a file scanner and does not quarantine files. Confirm which kernel drivers your node operating systems support, who tunes the rule set and how events are forwarded to Wazuh or your SIEM so that alerts are actioned.

Security Onion for sensor-side visibility

Security Onion is licensed under the Elastic License 2.0 and bundles Suricata, Zeek, osquery and the Elastic stack into one platform for monitoring and hunting. For Control 10, its value is correlating endpoint and network signals that show malware communication, such as command-and-control traffic. Read the Elastic License 2.0 terms before you offer it as a managed service, and confirm how much sizing, storage and tuning effort the bundle needs in your environment.

Suricata and Zeek for network-side detection

Suricata is an intrusion detection and prevention engine under GPL-2.0, and Zeek is a network analysis framework under a BSD-style license. Both see traffic that endpoint agents cannot, including downloads, beaconing and lateral movement. They are not anti-malware products and cannot clean a host. Use them to support Control 10 by detecting malware traffic that endpoint tools missed, and confirm sensor placement, encrypted traffic handling and who maintains the rules before you depend on them.

Evidence auditors ask for under Control 10 and which component produces it

This table maps the evidence an assessor typically asks for under Control 10 to the Wazuh component that produces it. Read each row as a question to answer before fieldwork, then confirm the exact measures with the assessor against the CIS Controls Assessment Specification, since the specification defines what to measure but not how. The main takeaway is that agent coverage, policy exports and alert records come from different components, so plan retention and export paths for each one.

Evidence item	Producing component	What to confirm with the auditor
Asset inventory of enterprise devices	Wazuh agents collect inventory; Wazuh server stores it; dashboard exports the list	Which asset sources count as the authoritative inventory and how often it must be reconciled
Agent deployment coverage reports	Wazuh server agent registry; dashboard agent status views	How coverage is calculated, which devices are out of scope and how exceptions are documented
Central configuration and policy exports	Wazuh server manages agent configuration; exports from the dashboard or API	Whether the configuration snapshot must show the effective policy on each endpoint at a point in time
Signature or content update logs	Wazuh server and agent update logs; rule and decoder version records	Which content types count as signatures, and the update frequency and proof of successful application
Detection and alert records for behavior-based rules	Wazuh indexer stores alerts; Wazuh dashboard displays and filters them	Retention period, tamper protection on stored alerts and how rule logic is shown to the assessor
Response action logs	Wazuh server active response records; agent logs on the endpoint	Who authorized each action, how the action is linked to the alert and whether logs are kept separately from the endpoint

What open-source tooling alone does not satisfy

Wazuh, osquery and similar tools cover much of the monitoring and detection work behind Control 10, but several Safeguards depend on an anti-malware engine, vendor content and operating conditions that open-source tooling does not supply on its own. The cards below set out where those gaps usually appear, so you can decide what to build, what to buy and what to document before an assessor asks.

Prevention on every asset

Safeguard 10.1 asks for anti-malware software on all enterprise assets and for it to stay maintained. Wazuh detects malware indicators and file changes, but it is a monitoring platform, so an endpoint with no engine that blocks execution is not covered by it. Check each asset class, including servers, laptops and virtual desktops, against an installed and running engine, and record the exceptions with a reason.

Vendor signature update feeds

Safeguard 10.2 expects signatures to update automatically. Open-source engines can rely on community or vendor rule feeds, but the update source, its licensing terms and the update frequency are your responsibility to verify. Confirm which feed each engine pulls from, how failed updates alert, and how air-gapped sites receive updates by media transfer.

Cloud and SaaS-only endpoints

Managed laptops, SaaS-hosted workloads and browser-based work often run on platforms where you cannot install a custom agent or scan the host. Confirm whether the provider supplies its own anti-malware, whether its logs can reach your central console, and who owns evidence for those assets. Record the provider's control reports as part of the same inventory.

Legacy and unmanaged hosts

Industrial workstations, clinical devices and old Windows or Unix servers may not accept an agent, or the vendor may refuse support for one. For these hosts, log forwarding, file integrity checks and network controls become the compensating layer. Document each host, the compensating control, the review interval and the owner who accepts the residual risk.

Triage staffing for alerts

Behavior-based detection under Safeguard 10.7 produces alerts that someone must review, tune and close. Open-source platforms supply the queue but not the analysts, on-call rota or the tuning effort that keeps false positives manageable. Ask who triages alerts at night and weekends, how quickly suspicious detections are escalated, and how tuning decisions are recorded.

Framework rules beyond CIS

CIS maintains mappings to frameworks including PCI DSS v4.0, ISO/IEC 27001:2022, SOC 2, CMMC v2.0, DORA and NIS2, and the CIS Navigator lists 30 frameworks and versions as of October 2026. Each framework adds its own evidence, retention or review rules, and CIS states that the Controls do not replace any regulatory scheme. Map your Control 10 evidence to each framework's own requirements before you assume one set of logs satisfies all of them.

Questions buyers ask before hiring help for CIS Control 10

What drives the cost of open-source anti-malware for CIS Control 10?

The main drivers are the number and type of endpoints, the server and storage sizing for the chosen platform, the detection content you need, and the staff who run it. Agent deployment across Windows, Linux and macOS, plus any legacy or non-agent devices, adds effort. Detection tuning and alert handling usually cost more over time than the software itself, because open-source tools such as Wazuh carry no per-endpoint license fee under GPL-2.0. Ask any partner for a quote that separates one-time work (architecture, deployment, initial policy and testing) from recurring work (upgrades, tuning, monitoring and support), and that lists who is paid for each item.

How long does it take to get anti-malware coverage in place?

Time to coverage depends on the number of endpoints, how many operating systems and sites are involved, change windows, and whether the network is air-gapped or has restricted access. DeployOpen does not publish fixed durations. A quote follows from the written scope, and that scope should name the agent rollout waves, the management server build, the policy and detection content, and the acceptance tests. Ask for the milestones and the client dependencies that could move them.

What does the client need to provide for an implementation?

Expect to provide an inventory of endpoints and their operating systems, network paths from endpoints to the management server, hosting for the server components, and named owners for change approval and alert response. You also need access to the systems where agents will run, a decision on data retention and where logs are stored, and time from your security team to review detection rules. For internal systems and air-gapped sites, confirm how software packages and vulnerability data will be transferred. The written scope should list these inputs so gaps show up before work starts.

Can our internal team implement CIS Control 10 without a partner?

Many teams with Linux administration and Windows experience can deploy the agents and management server themselves, especially for a small estate. The harder parts are sustained: keeping the platform upgraded, tuning behavior-based rules to reduce false positives, handling alerts at the hours your risk requires, and producing evidence for an assessor. Ask yourself whether you have named people for each task and whether they have time after the initial build. A partner can run the build, hand over documentation and runbooks, or support the team on a retainer.

Does Wazuh alone meet Safeguard 10.2 for automatic signature updates?

Wazuh can receive and manage updates for its own detection content and vulnerability data, but whether it satisfies Safeguard 10.2 depends on what anti-malware engines and signatures you run on each endpoint. Safeguard 10.2 asks for automatic signature updates for anti-malware software, so confirm that each engine, such as ClamAV or a YARA rule set, has a documented update path and an owner who checks that updates landed. Verify the measures in the CIS Controls Assessment Specification for Safeguard 10.2 with your assessor before relying on any single tool.

Do IG1 organizations have to implement Safeguards 10.6 and 10.7?

No. CIS Controls v8.1 places Safeguard 10.6 (central management) and Safeguard 10.7 (behavior-based anti-malware) in Implementation Group 2, so they apply to IG2 and IG3 enterprises but not IG1. IG1 organizations still need Safeguard 10.1 to install and maintain anti-malware on enterprise assets. Confirm your Implementation Group from the CIS Implementation Groups pages before scoping, since many regulated organizations are classified above IG1 by their operating complexity or the sensitivity of their data.

How does CIS Controls accreditation differ from DeployOpen's role?

CIS Controls Accreditation, run with CREST, accredits CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. It is a credential for the organization offering those services. DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your infrastructure and prepares systems and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications, and independent assessors make those determinations. Ask any partner which CIS accreditation they hold, if any, and what the assessor will need from you.

How a Control 10 rollout moves from asset inventory to evidence

The sequence turns an agreed asset scope into deployed, centrally managed anti-malware with tested update and detection content, and ends in an evidence pack an assessor can trace back to each Safeguard. Each step closes with a check that tells the team whether it can move on.

Confirm implementation group and asset scope
The client's security lead and the DeployOpen engagement lead agree which Implementation Group applies, since Safeguards 10.6 and 10.7 apply to IG2 and IG3 but not IG1. They then write down which asset classes and business units are in scope, including any systems that cannot take an agent. The step closes when the scope statement is signed off and lists the Safeguards being claimed.
Inventory devices and classify exceptions
The team builds an inventory of endpoints and servers from directory, configuration management and network sources, then compares it with what the security tooling can see. Each device is tagged by operating system, owner, location and whether it supports an agent, and anything that cannot run one is recorded as an exception with a compensating control. The step closes when the inventory reconciles against the directory and every exception has an owner.
Stand up the management server and content
DeployOpen installs the Wazuh server, indexer and dashboard inside the client's environment, sized for the inventory and retention targets agreed in scope. The team confirms that the management plane can reach its update sources, or that an offline vulnerability repository is in place for isolated networks. The step closes when the console shows healthy components and a test agent reports in.
Deploy agents in controlled waves
Agents are rolled out in small groups, starting with a pilot set that covers each operating system in scope and then moving to production groups. After each wave, the team checks enrollment, agent version, and whether the endpoints appear in the inventory and the dashboard. The step closes when every in-scope device is enrolled or listed as an approved exception, with no unexplained gaps.
Set central configuration and update policy
The team defines agent groups, configuration profiles and upgrade rules from the management server so that policy is set once and applied consistently. Settings cover malware detection, scheduled scanning, and how agents receive detection content and signature or rule updates. The step closes when a sample of endpoints shows the expected group membership and configuration version.
Confirm update and detection content
The team verifies that rule sets and malware detection content update on schedule on both the server and the endpoints, and records where the content comes from. For behavior-based detection under Safeguard 10.7, the team reviews which rules and decoders are active and documents any that are disabled and why. The step closes when a dated update record exists for each content source and the active rule inventory is saved.
Run detection and response tests
DeployOpen and the client's security team run controlled, non-destructive test cases that simulate malware-like behavior on representative endpoints, such as a benign test file or a sample that triggers a known rule. They confirm that the alert reaches the dashboard, is attributed to the right host, and triggers the agreed response. Gaps are logged as findings with owners. The step closes when each test has a recorded result and each failed case has a fix or accepted risk.
Build the evidence pack
The team assembles artifacts that map each Safeguard in scope to the evidence the CIS Controls Assessment Specification describes as measures, such as deployment reports, configuration exports, update logs, test records and the exception register. DeployOpen prepares the pack for the client's own assessor, and does not issue an attestation or certification. The step closes when the client's compliance lead has reviewed the pack and confirmed that every claimed Safeguard has a traceable artifact.

How DeployOpen scopes, delivers and supports Control 10 evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For anti-malware under CIS Control 10, we start from the Safeguards that apply to your Implementation Group and turn them into a written scope, deployed tooling and evidence your assessors can review.

How we scope

Confirm your Implementation Group, since Safeguards 10.6 and 10.7 apply to IG2 and IG3 only
Inventory endpoint types, operating systems and hosts that cannot take an agent
Agree in writing which tools cover malware defense, such as Wazuh, osquery or a dedicated product
Record which Safeguards are in scope, which are excluded and why, and who owns each one

How we build

Deploy Wazuh server, indexer and dashboard in your environment, with the agent rollout staged by asset group
Configure signature and content update paths, including offline update media where networks are isolated
Set up central management, policy baselines and alerting on malware detections and agent health
Test detections against known-benign and safe test samples agreed with your security team before go-live

How we hand over

Provide a mapping from each in-scope Safeguard to the configuration, logs and reports that evidence it
Document the Assessment Specification measures your assessor will check, with the query or report for each
Train operations staff on alert triage, exception handling and maintaining the update cadence
Deliver runbooks, configuration files under version control and a list of open items for your sign-off

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Track new Wazuh releases and plan upgrades in a maintenance window agreed with your change board
Review evidence sets periodically so they stay current through your audit period
Confirm with your auditor which evidence format and retention period they require before we build

Open source anti-malware for CIS Control 10