Federal and Government Deployment

This guide is for Information System Security Officers (ISSOs), assessors, and security teams deploying Guardimesh within a FedRAMP High, DoD IL4/IL5, or NIST 800-53-governed authorization boundary. It consolidates FIPS compliance, control mappings, and configuration guidance into a single reference for Assessment and Authorization (A&A) documentation.

---

Deployment Model

Guardimesh's on-premise Enterprise operator deploys the entire platform — scanner, web console, API, database, and signature server — inside your Kubernetes cluster. No data leaves the authorization boundary.

This is a customer-deployed tool, not a FedRAMP-authorized SaaS offering. Guardimesh operates within your ATO, the same way ClamAV, Falco, or GoAlert does. Your assessor evaluates whether the tool satisfies your control implementation, not whether Guardimesh holds a separate authorization.

What Stays In-Cluster

Component	Purpose	External Connectivity
Scanner DaemonSet	Runtime malware scanning on every node	None
Backend API	Scan result ingestion	None
Web Console	Dashboard, configuration, reporting	None (admin access via Ingress or port-forward)
PostgreSQL	Scan result and user data storage	None
Signature Server	ClamAV database distribution	None (signatures loaded via ConfigMap or PVC)

For full air-gap deployment instructions, see Air-Gap Deployment.

---

Why Node-Level Scanning Satisfies SI-3

NIST SP 800-53 SI-3 requires malicious code protection "at system entry and exit points." In a Kubernetes environment, the system entry point is the node where container images are pulled from a registry and instantiated as running processes.

Guardimesh deploys as a DaemonSet — one scanner pod per node — ensuring that every entry point is covered with no gaps. This is architecturally distinct from:

• Registry scanning (e.g., Trivy, Grype) — runs once at push time; cannot detect runtime mutations, fileless payloads, or supply-chain compromise after the image is pulled
• Pipeline scanning — runs at build time; misses everything that happens post-deployment
• Centralized cluster scanners — run on a subset of nodes; create coverage gaps on unscanned nodes

The DaemonSet model ensures that scanning happens on the node where containers enter the cluster's runtime environment — the literal "entry point" in NIST terminology.

---

NIST SP 800-53 Rev. 5 Control Mapping

The table below maps Guardimesh capabilities to specific NIST controls. Use it as a starting point for your System Security Plan (SSP) control implementation statements.

SI — System and Information Integrity

Control	Title	Guardimesh Implementation
SI-3	Malicious Code Protection	ClamAV-based malware scanning on every node via DaemonSet. Scans container writable layers (overlay upperdir), host-mounted directories, and in-memory payloads. Scanning occurs at the system entry point — the node where images are pulled and containers are instantiated.
SI-3(1)	Central Management	Web console provides centralized management of scan policies, signature databases, namespace exclusions, and reporting. Policy changes propagate to all nodes automatically via remote config polling (default: every 5 minutes).
SI-3(2)	Automatic Updates	ClamAV signature databases are updated automatically every 12 hours from the on-cluster signature server. In air-gapped environments, signatures are updated by loading new databases into the ConfigMap or PVC (see Signature Updates).
SI-3(10)	Malicious Code Analysis	Obfuscation scanner sidecar performs ML-based analysis (Random Forest classifier), YARA rule matching, and Shannon entropy measurement to detect packed, encrypted, or deliberately obfuscated binaries that evade signature-based detection.
SI-4	System Monitoring	Continuous monitoring of container writable layers for new file writes via Linux fanotify API. Executable drift detection identifies binaries added after container startup. memfd scanning detects fileless payloads. Deleted binary and shared library scanning identifies processes running from unlinked files.
SI-4(2)	Automated Tools and Mechanisms for Real-Time Analysis	fanotify-based real-time file monitoring intercepts filesystem writes inside containers as they occur — not on a polling interval, but at write time. Findings trigger immediate alerting.
SI-4(4)	Inbound and Outbound Communications Traffic	Scanner monitors container filesystem activity for indicators of compromise. Detection actions can automatically quarantine affected pods via annotation (for NetworkPolicy enforcement) or Kubernetes events (for SIEM ingestion).
SI-4(5)	System-Generated Alerts	Configurable alerting via email, PagerDuty, Slack, Jira, and ServiceNow when threats are detected. Alert metadata includes container ID, pod, namespace, node, image, and matched signatures.
SI-7	Software, Firmware, and Information Integrity	Executable drift detection compares running container contents against the original image layers. Any executable that appears after container startup is flagged as drift — indicating unauthorized modification.
SI-7(1)	Integrity Checks	Scheduled re-scanning mode periodically re-scans all running containers to detect modifications that occurred between active scan events.

SC — System and Communications Protection

Control	Title	Guardimesh Implementation
SC-8	Transmission Confidentiality and Integrity	In on-premise mode, all communication is within the cluster. In SaaS mode, all scanner-to-backend communication uses TLS 1.2+ with FIPS 140-3 approved cipher suites.
SC-13	Cryptographic Protection	All cryptographic operations use Go's FIPS 140-3 certified cryptographic module (CMVP Certificate #5247). Forensic checkpoint archives are encrypted with AES-256-GCM. See FIPS 140-3 below.
SC-28	Protection of Information at Rest	Scan results stored in PostgreSQL (on-premise) with encryption dependent on the storage layer. Forensic checkpoint archives encrypted with AES-256-GCM before writing to disk.

AU — Audit and Accountability

Control	Title	Guardimesh Implementation
AU-2	Event Logging	Every container creation, scan execution, scan result, signature update, and configuration change is logged with timestamps, user identity, and source metadata.
AU-3	Content of Audit Records	Scan result records include: timestamp, container ID, pod name, namespace, node name, cluster ID, image name, image ID, scan duration, matched signatures, and file paths.
AU-6	Audit Record Review, Analysis, and Reporting	Web console provides filtering, searching, and exporting of scan results. Advanced reports include time-series analysis, coverage metrics, and PDF export for audit evidence packages.
AU-11	Audit Record Retention	Configurable retention periods. On-premise deployments control retention via PostgreSQL data management. Default scan result retention is 180 days (Team) or custom (Enterprise).

CM — Configuration Management

Control	Title	Guardimesh Implementation
CM-3	Configuration Change Control	Scan configuration changes are tracked in the web console audit log. The operator reconciles the desired state (GuardimeshScanner CR) against the actual state and applies changes declaratively.
CM-8	System Component Inventory	Scanner reports every running container on every node, including image name, image ID, container runtime, and namespace. This provides a continuously updated inventory of all containerized workloads.

---

NIST SP 800-190 (Container Security Guide)

NIST SP 800-190 provides container-specific security recommendations. Guardimesh addresses the following:

SP 800-190 Section	Recommendation	Guardimesh Implementation
3.1.3	Scan images for vulnerabilities and malware	Runtime ClamAV scanning of container writable layers, plus obfuscation detection
3.3.2	Monitor containers for anomalous behavior	fanotify real-time monitoring, executable drift detection, memfd scanning, deleted binary detection
3.3.4	Use security tools designed for containers	DaemonSet deployment model designed specifically for Kubernetes container scanning
3.4.1	Protect sensitive data in containers	Scanner operates read-only; file contents never leave the node; no secrets, environment variables, or application data are transmitted
4.3.4	Use container-aware runtime security	OverlayFS-aware scanning reads container writable layers directly, understanding the container filesystem structure rather than treating it as opaque

---

FedRAMP High Baseline Applicability

The following FedRAMP High controls are directly addressed by Guardimesh's on-premise deployment:

Control Family	Controls	Coverage Summary
SI (System and Information Integrity)	SI-3, SI-3(1), SI-3(2), SI-3(10), SI-4, SI-4(2), SI-4(4), SI-4(5), SI-7, SI-7(1)	Malware protection at entry points, real-time monitoring, automated updates, integrity checking
SC (System and Communications Protection)	SC-8, SC-13, SC-28	FIPS 140-3 cryptography, TLS 1.2+, encrypted data at rest
AU (Audit and Accountability)	AU-2, AU-3, AU-6, AU-11	Comprehensive audit trail with retention controls
CM (Configuration Management)	CM-3, CM-8	Configuration tracking, container inventory

---

FIPS 140-3 Compliance

All Guardimesh Go binaries embed the FIPS 140-3 certified Go Cryptographic Module (CMVP Certificate #5247). FIPS mode is enabled by default — no additional configuration is required.

Component	FIPS Mechanism
Scanner, Inspector, Puller, Operator	GOFIPS140=v1.0.0 at build time + godebug fips140=on runtime default
ClamAV (Antivirus container)	Built on UBI9 with RHEL 9's FIPS-validated OpenSSL 3.0 provider
TLS	crypto/tls auto-restricts to FIPS-approved cipher suites and TLS 1.2+
Checkpoint encryption	AES-256-GCM via Go's certified FIPS module

Verification

# Check scanner FIPS status
kubectl exec -it <scanner-pod> -c guardimesh-scanner -- \
  curl -s localhost:8086/versionz | jq .fips
# Expected: true

# Check scanner startup logs
kubectl logs <scanner-pod> -c guardimesh-scanner | grep fips140
# Expected: {"level":"INFO","msg":"watcher starting",...,"fips140":true}

Disabling FIPS Mode

For non-FIPS environments (e.g., development clusters), FIPS mode can be disabled per-container:

scanner:
  scanner:
    extraEnv:
      - name: GODEBUG
        value: "fips140=off"

CMVP Certificate

Field	Value
Certificate Number	#5247
Module Name	Go Cryptographic Module
Standard	FIPS 140-3
Algorithms	AES, SHA-2, ECDSA, RSA, HMAC, HKDF, DRBG
Validation URL	csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5247

---

Base Images

All Guardimesh container images are built on Red Hat Universal Base Image 9 (UBI9):

Image	Base	Notes
Scanner	ubi9/ubi-minimal	Go binary + startup scripts
Inspector	ubi9/ubi-minimal	Go binary
Antivirus	ubi9/ubi-minimal	ClamAV compiled from source against system OpenSSL
Puller	ubi9/ubi-minimal	Go binary + ClamAV tools
Operator	ubi9/ubi-minimal	Go binary
Obfuscation Scanner	ubi9/ubi-minimal	Python 3.12 + system OpenSSL FIPS provider

UBI9 images are:

• Freely redistributable
• Supported on RHEL, OpenShift, and any OCI-compliant runtime
• STIG-hardened when running on RHEL 9 nodes with FIPS mode enabled
• Accepted in DoD and IC environments

---

Assessor Guidance

This section provides information commonly requested during A&A assessments.

Control Implementation Statement Template

Use this as a starting point for your SSP. Replace bracketed values with your environment-specific details.

SI-3: Malicious Code Protection

[System Name] employs Guardimesh, a runtime container malware scanning tool deployed as a Kubernetes DaemonSet, to provide malicious code protection at system entry points. The scanner runs on every node in the cluster, scanning each container at the point where container images are pulled from [registry name] and instantiated as running processes.

Scanning uses the ClamAV engine with official, third-party, and custom signature databases. Signatures are updated automatically every 12 hours from an on-cluster signature server with no external connectivity. Real-time file monitoring via the Linux fanotify API detects malware written to container filesystems after initial deployment.

Scan results, including signature matches, file paths, and container metadata, are stored in a PostgreSQL database within the authorization boundary and retained for [retention period]. Alerts are generated via [notification channels] when threats are detected.

Guardimesh uses FIPS 140-3 validated cryptography (CMVP Certificate #5247) for all cryptographic operations. All container images are built on Red Hat UBI9.

Commonly Asked Questions

Q: Does Guardimesh require internet access? A: No. The on-premise Enterprise deployment operates entirely within the cluster. Signature updates are loaded manually (air-gap) or from an in-cluster mirror.

Q: Does any data leave the authorization boundary? A: No. In on-premise mode, all scan results, configuration, and user data remain within the cluster. No telemetry, crash reports, or usage data are sent externally.

Q: What cryptographic module does Guardimesh use? A: Go's native FIPS 140-3 certified cryptographic module (CMVP Certificate #5247). ClamAV uses RHEL 9's FIPS-validated OpenSSL 3.0 provider. FIPS mode is enabled by default.

Q: What base images are used? A: All images are built on Red Hat UBI9 (Universal Base Image 9), which is accepted in DoD and IC environments.

Q: Does the scanner modify containers or application data? A: No. The scanner operates in read-only mode with respect to application workloads. It reads container filesystem layers to scan for malware but never writes, modifies, or deletes application data. Detection actions (pod annotation, event creation, quarantine) modify only Kubernetes API metadata, not container contents.

Q: What privileged access does the scanner require? A: The scanner and inspector containers run as privileged to access host filesystem overlay layers (/host) and read /proc/[pid] for deleted binary detection. No other containers in the pod require privileged access. Required Kubernetes RBAC permissions are documented in Security and Compliance.

Q: Can Guardimesh be STIG-hardened? A: Guardimesh follows STIG principles (minimal base images, no unnecessary services, FIPS cryptography, least-privilege RBAC). A formal STIG checklist is not yet published. Contact support@guardimesh.com for hardening guidance for your specific environment.

---

Recommended Configuration for Federal Environments

apiVersion: enterprise.guardimesh.io/v1alpha1
kind: GuardimeshPlatform
metadata:
  name: guardimesh
  namespace: guardimesh
spec:
  license:
    mode: local
    licenseSecret: guardimesh-license

  scanner:
    enabled: true
    image: your-registry.internal/guardimesh/guardimesh-scanner:latest
    antivirusImage: your-registry.internal/guardimesh/guardimesh-antivirus:latest
    inspectorImage: your-registry.internal/guardimesh/guardimesh-inspector:latest
    pullerImage: your-registry.internal/guardimesh/guardimesh-puller:latest

    # Detection actions for automated response
    detectionActionsEnabled: true
    forensicCheckpointEnabled: true
    checkpointStorageSizeLimit: "20Gi"
    checkpointRetentionDays: 180

    # Signature management (air-gapped)
    signatureStorage:
      mode: internal
      updateInterval: 43200
      internalServer:
        enabled: true
        image: your-registry.internal/guardimesh/storage-access-airgap:latest
        storage: 10Gi
        replicas: 2

    # Scan all workload namespaces
    skipNamespaces: "kube-system,guardimesh,openshift-monitoring"
    skipNamespacePrefixes: "openshift-"

    # Resource limits appropriate for production
    resources:
      requests:
        memory: "1Gi"
        cpu: "500m"
      limits:
        memory: "2Gi"
        cpu: "2000m"
    tolerations:
      - effect: NoSchedule
        operator: Exists

  database:
    managed: true
    storage: 100Gi
    backup:
      enabled: true
      schedule: "0 2 * * *"
      retentionDays: 30

---

Next Steps

• Air-Gap Deployment — Step-by-step air-gapped installation
• Forensic Checkpointing — Container state capture on detection
• Security and Compliance — Data handling, RBAC, and compliance details
• Configuration Reference — Full Helm values and environment variables