Malware Protection

Overview

Audience: Operators deploying Spinifex into environments subject to CMMC Level 1 (or organisations that otherwise require host-based malware protection).

Scope: The Spinifex nodes themselves — the Linux hosts running spinifex-daemon, spinifex-awsgw, spinifex-nats, spinifex-predastore, spinifex-viperblock, spinifex-vpcd, spinifex-ui and the OVN control plane. Guest VMs launched on the platform are the responsibility of the workload owner and are out of scope.

CMMC Practices Covered

This guide captures the operator-side controls required to meet three CMMC Level 1 practices that Spinifex itself cannot enforce — they depend on host-based tooling chosen and operated by the deployment team.

Approach

Spinifex does not bundle or mandate a specific anti-malware product. Operators will typically have an existing endpoint security standard (CrowdStrike Falcon, Microsoft Defender for Linux, Wazuh, ClamAV, Sophos, ESET, etc.). This guide:

1. Names the Spinifex components and filesystem paths that must be included in scan and integrity-monitoring coverage (the "designated locations").
2. Specifies update and scan cadence required to meet SI.L1-3.14.4 and SI.L1-3.14.5.
3. Provides reference configurations for open-source stacks (ClamAV for AV, AIDE for file integrity, Wazuh for centralised monitoring) as a known-good baseline. Operators running a commercial EDR should map these locations and cadences into their existing product.

1. Designated Locations (SI.L1-3.14.2 [a])

All Spinifex nodes must include the following in their malware protection scope. Paths assume the production install layout (/etc/spinifex exists); development layouts under $HOME/spinifex are not supported for compliance deployments.

1.1 Executable Binaries

1.2 Configuration and Secrets

1.3 Service Units and Privilege Configuration

1.4 Runtime and Data Locations

Performance exclusions. Viperblock WAL, Predastore chunks, and NATS JetStream files are large, high-churn, block-level storage that contains customer VM data. Real-time on-access AV scanning of these paths is both a significant performance cost and a confused-deputy problem (the daemon, not the operator, is the writer). Cover these paths with periodic scheduled scans (SI.L1-3.14.5 [b]) but exclude them from real-time on-access hooks. Record the exclusion and its justification in the system security plan.

1.5 External File Ingest — Real-time Scan Required (SI.L1-3.14.5 [c])

The following are "files from external sources" within the meaning of 3.14.5 [c] and must be scanned at ingest, before Spinifex consumes them:

Spinifex does not currently invoke an AV scanner on these ingest paths in-process. Until that integration exists, operators must either (a) use an on-access AV hook (ClamAV clamonacc, EDR file-write monitor) that sees Predastore writes, or (b) run a pre-ingest workflow that scans artifacts before they are uploaded to Spinifex.

2. Update Requirements (SI.L1-3.14.4)

Malicious code protection mechanisms must be updated when new releases are available. For signature-based AV this means signature feeds; for EDR products it means agent version pins. Apply to every node.

Evidence: the system security plan must record (a) which product is deployed, (b) how updates are delivered, and (c) a sample of update-success log entries from the last 30 days.

3. Scan Schedule (SI.L1-3.14.5)

3.1 Periodic Scans (objectives [a], [b])

3.2 Real-time Scans (objective [c])

3.3 Logging

All scan runs — scheduled and real-time — must produce a log entry that includes scanner name, version, signature version, target, outcome, and duration. Forward to the same log collection used for Spinifex service logs.

4. Reference Configurations

The configurations below are reference baselines. They are known to meet the CMMC L1 objectives on a standard Debian 12 Spinifex node; they are not the only valid implementation. Operators running a commercial EDR should treat §1 and §3 as the contract and configure their chosen product to match.

4.1 ClamAV (signature-based AV)

Install:

apt-get install -y clamav clamav-daemon clamav-freshclam clamonacc

Signature updates — drop-in /etc/systemd/system/clamav-freshclam.timer.d/spinifex.conf:

[Timer]
OnCalendar=*-*-* 00,04,08,12,16,20:00:00
Persistent=true

Enable and start:

systemctl enable --now clamav-freshclam.timer clamav-daemon.service clamav-clamonacc.service

On-access scanning — /etc/clamav/clamd.conf additions:

OnAccessIncludePath /usr/local/bin
OnAccessIncludePath /usr/lib/x86_64-linux-gnu/nbdkit/plugins
OnAccessIncludePath /etc/spinifex
OnAccessIncludePath /etc/systemd/system
OnAccessPreventionAction clamd-block
OnAccessExcludePath /var/lib/spinifex/viperblock
OnAccessExcludePath /var/lib/spinifex/predastore
OnAccessExcludePath /var/lib/spinifex/nats

Scheduled scans — /etc/systemd/system/spinifex-clamav-scan.service:

[Unit]
Description=Spinifex scheduled AV scan
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/clamdscan --fdpass --multiscan \
    /usr/local/bin /usr/lib/x86_64-linux-gnu/nbdkit/plugins \
    /etc/spinifex /etc/systemd/system \
    /var/lib/spinifex/awsgw /var/lib/spinifex/vpcd \
    /var/lib/spinifex/spinifex /var/log/spinifex
StandardOutput=append:/var/log/spinifex/clamav-scheduled.log
StandardError=append:/var/log/spinifex/clamav-scheduled.log

Paired timer spinifex-clamav-scan.timer:

[Unit]
Description=Daily Spinifex AV scan

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target

For the weekly /var/lib/spinifex/* data scan and the monthly root scan, add two additional timer/service pairs with OnCalendar=weekly / OnCalendar=monthly and the appropriate scan targets.

4.2 AIDE (file integrity monitoring)

Install:

apt-get install -y aide aide-common

Policy — /etc/aide/aide.conf.d/90_spinifex:

# Binaries — any change is suspicious
/usr/local/bin/spx                                f+p+u+g+s+m+c+sha256
# Viperblock NBD plugin — adjust <arch> for the node (see `nbdkit --dump-config`)
/usr/lib/x86_64-linux-gnu/nbdkit/plugins/nbdkit-viperblock-plugin.so  f+p+u+g+s+m+c+sha256

# Config and secrets
/etc/spinifex                                     f+p+u+g+s+m+c+sha256
/etc/systemd/system/spinifex-.*\.service$         f+p+u+g+s+m+c+sha256

# CA trust store
/usr/local/share/ca-certificates/spinifex-ca.crt  f+p+u+g+s+m+c+sha256

# Exclude high-churn runtime data (covered by scheduled AV instead)
!/var/lib/spinifex/viperblock
!/var/lib/spinifex/predastore
!/var/lib/spinifex/nats
!/var/log/spinifex
!/run/spinifex

Baseline:

aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Daily check — a systemd timer invoking aide --check. Non-zero exit must alert. Re-baseline after every Spinifex upgrade (make reinstall, package upgrade, config change) and record the new hash.

4.3 Wazuh (centralised AV + FIM + alerting)

For multi-node clusters, a Wazuh agent on each Spinifex node feeding a central Wazuh manager is the simplest way to discharge 3.14.2 / 3.14.4 / 3.14.5 with consolidated evidence.

Key agent configuration (/var/ossec/etc/ossec.conf fragments):

<syscheck>
  <frequency>43200</frequency>   <!-- 12h FIM baseline -->
  <directories check_all="yes" realtime="yes">/etc/spinifex</directories>
  <directories check_all="yes" realtime="yes">/usr/local/bin</directories>
  <directories check_all="yes" realtime="yes">/etc/systemd/system</directories>
  <ignore>/var/lib/spinifex/viperblock</ignore>
  <ignore>/var/lib/spinifex/predastore</ignore>
  <ignore>/var/lib/spinifex/nats</ignore>
  <ignore>/run/spinifex</ignore>
</syscheck>

<rootcheck>
  <frequency>3600</frequency>
</rootcheck>

Pair with the Wazuh ClamAV integration (or a commercial AV module) for signature-based detection, and use the Wazuh manager's rule engine to alert on signature updates failing (SI.L1-3.14.4 evidence) and on scheduled-scan failures (SI.L1-3.14.5 evidence).

5. Operator Checklist

Use this list to confirm a node meets the three CMMC practices before the node is admitted to a production cluster:

• Host AV product installed, running, and reporting to a central console or log sink.
• Signature update timer/job running; last successful update within the cadence in §2.
• AV and file-integrity policy covers every path in §1.1–§1.4, with documented exclusions for §1.4 high-churn paths.
• External-ingest paths in §1.5 have real-time scanning in place (either at the Predastore write layer or in the operator's upload workflow).
• Daily, weekly, and monthly scheduled scans defined per §3.1 and visible in recent run history.
• Scan and update logs forwarded to the same SIEM / log collector used for Spinifex service logs.
• AIDE (or equivalent FIM) baseline exists; re-baseline step is part of the Spinifex upgrade runbook.
• System security plan documents the deployed product, update mechanism, scan cadence, and exclusions.