PCI-DSS v4.0.1
PCI-DSS v4.0.1 control mapping — LinuxGuard agent and console capabilities aligned to Requirements 2, 6, 7, 8, 10, and 11 with Satisfies / Supports / Out of scope tiers.
Note: This page maps LinuxGuard against PCI-DSS v4.0.1 (effective 2024-06-01). Last verified against the framework on 2026-05-31. Canonical framework document: PCI Security Standards Council — PCI-DSS v4.0.1. For the vocabulary contract used here, see Audit & Comply.
Scope
This page maps LinuxGuard's agent and console capabilities against PCI-DSS v4.0.1. The mapping is scoped to controls in audit logging, file integrity monitoring, configuration management, identity and access tracking, and behavioral monitoring on Linux systems within the Cardholder Data Environment (CDE). Controls in cardholder data environment scope definition, network segmentation, application-layer authentication, key management, anti-malware, encryption-in-transit, physical access, and information security policy administration are out of scope for this product and are listed in the mapping table as Out of scope rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor.
Customers remain responsible for defining CDE boundaries (PCI-DSS scope), implementing and validating network segmentation, completing the annual self-assessment questionnaire or Report on Compliance, and engaging a Qualified Security Assessor (QSA) where required by their merchant level or service provider tier.
Shared responsibility
LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor.
The shared-responsibility framing for PCI-DSS v4.0.1:
LinuxGuard responsibility. Produce continuous audit log generation, file-integrity monitoring telemetry, configuration baselines and drift detection, eBPF-based behavioral monitoring, and identity intelligence for Linux systems in the CDE. Maintain the framework version pin and per-control evidence pointers.
Customer responsibility. Define CDE scope, implement network segmentation between CDE and out-of-scope networks, administer cardholder data flows, operate application-layer authentication and authorization, manage cryptographic keys, deploy anti-malware on in-scope systems, validate quarterly vulnerability scans (ASV scans for external-facing systems), and engage a Qualified Security Assessor (QSA) where the merchant level or service provider tier requires.
Out-of-scope domains for this framework. Network segmentation enforcement, key management, encryption-in-transit, anti-malware, physical access controls, information security policy administration, and the contractual and training elements of Requirement 12.
Control mapping
The Tier column uses one of three labels and only those three: Satisfies, Supports, Out of scope. The Evidence column points to a row of the canonical Evidence Location table or to a specific console page. See Audit & Comply for the three-tier vocabulary contract.
Req 2.2
Configuration standards for all system components — secure configuration baseline maintenance
Supports
Console Compliance Expansion → framework → control detail; Config Drift events
LinuxGuard surfaces drift against SSH config, SSHD config, account, group, sudo aliases, sudo defaults, and sudo rules baselines. Customer responsible for defining the baseline content itself and for hardening application-layer configuration.
Req 6.4.3
Inventory of payment page scripts and configuration management — change detection
Supports
Console Zero Trust Enforcement → Config Drift; Agent log (raw events)
Drift detection surfaces unauthorized changes to monitored configuration files. Customer responsible for the application-layer script inventory (payment pages) outside LinuxGuard's monitored file set.
Req 7.1
Define and document access control policy by business need to know
Supports
Console Audit pillar → Authorizations audit; Console Compliance Expansion → control detail
SUDO rule baselines, authorization audit, and account/group inventory provide evidence of access posture. Customer responsible for defining the access control policy and for application-layer role enforcement.
Req 7.2
Establish role-based access control model for system components
Supports
Console Audit pillar → Authorizations audit
LinuxGuard observes and audits OS-level access (sudo rules, group membership, SSH access). Customer responsible for the role model definition and for application-layer authorization.
Req 8.2
Strong authentication — unique user identification
Supports
Agent log (raw events) with loginUID attribute; Console Identity Intelligence
loginUID capture survives sudo/su escalation for non-repudiation. Customer responsible for the IAM platform, account provisioning workflow, password policy, and MFA enforcement.
Req 8.3.1
All access to system components is authenticated using multi-factor authentication
Supports
Agent log (raw events); Console Identity Intelligence
LinuxGuard captures authentication events including method (password, publickey, keyboard-interactive). Customer responsible for MFA enforcement at the IdP or PAM layer.
Req 10.2.1
Audit logs are enabled and active for all system components
Satisfies
Agent log (raw events) at /var/log/linuxguard/agent.log; Support bundle
The LinuxGuard agent generates structured audit logs continuously on every enrolled Linux host in the CDE. Log rotation defaults: 50 MB per file, 14-day retention, 5 backups, gzip compression. See Log Management.
Req 10.2.1.1
Audit logs capture all individual user access to system components
Satisfies
Agent log (raw events) with auth.event attribute and loginUID field
eBPF-based authentication event capture records every login (success and failure) with user, source IP, method, and timestamp.
Req 10.2.1.2
Audit logs capture all actions taken by any individual with administrative access
Satisfies
Agent log (raw events); Console Audit pillar → SUDO execution audit
SUDO execution audit and process attribution with loginUID survive privilege escalation for non-repudiation.
Req 10.2.1.4
Audit logs capture invalid logical access attempts
Satisfies
Agent log (raw events); Console Identity Intelligence → Brute Force Detection
Authentication failure events captured at kernel level via eBPF auth probes; brute force pattern detection surfaces in the console.
Req 10.2.1.7
Audit logs capture creation and deletion of system-level objects
Supports
Console Zero Trust Enforcement → Config Drift; Agent log (raw events)
Drift detection across accounts and groups surfaces creation and deletion of system-level identity objects. Customer responsible for application-layer object lifecycle logging.
Req 10.3.1
Audit logs are protected from unauthorized modification
Supports
Agent log on disk with logrotate integration
LinuxGuard writes to /var/log/linuxguard/agent.log with standard UNIX permissions; logrotate close+reopen via SIGHUP. Customer responsible for forwarding logs to write-once-read-many (WORM) storage or central log management for tamper resistance.
Req 10.4
Audit log review — daily review of security events
Supports
Console Compliance Expansion → History; Console Audit pillar
Console surfaces drift events, signals, and authorization audit for daily review workflow. Customer responsible for assigning the review process and documenting reviewer sign-off.
Req 10.5.1
Retain audit log history for at least 12 months with the most recent 3 months immediately available
Supports
Agent log rotation; Console Compliance Expansion → History
Default agent retention is 14 days locally; customers ship to central log management for the 12-month / 3-month retention requirement. See Log Management § Central Log Collection Patterns.
Req 10.7
Failures of critical security control systems are detected, alerted, and addressed promptly
Supports
Console Notifications; Agent probe status
Agent health, eBPF probe status, and connectivity errors are visible via the probe command and console. Customer responsible for the alerting routing and incident response workflow.
Req 11.5.1
Change-detection mechanism is deployed to alert personnel to unauthorized modification of critical files
Satisfies
Agent log (raw events); Console Zero Trust Enforcement → Config Drift
File monitoring with eBPF tracks writes to sudoers, sshd_config, passwd, shadow, authorized_keys, and operator-configured paths. Drift events feed the console. See Security Architecture.
Req 11.5.2
Change-detection mechanism alerts on modifications, additions, and deletions of critical system files
Satisfies
Agent log (raw events); Console Zero Trust Enforcement → Config Drift
eBPF Configuration File Write Detection and file baseline drift events surface modify, add, and delete operations on monitored paths.
Req 11.6.1
Change- and tamper-detection mechanism for payment page header and script changes
Out of scope
n/a
Payment page tamper detection is an application-layer / browser-side concern not addressed by LinuxGuard.
Req 1
Install and maintain network security controls
Out of scope
n/a
Network segmentation and firewall rule management are not addressed by LinuxGuard.
Req 3
Protect stored account data
Out of scope
n/a
Cardholder data storage protection, key management, and tokenization are not addressed by LinuxGuard.
Req 4
Protect cardholder data with strong cryptography during transmission
Out of scope
n/a
Encryption-in-transit for cardholder data is not addressed by LinuxGuard.
Req 5
Protect all systems and networks from malicious software
Out of scope
n/a
Anti-malware deployment and signature management are not addressed by LinuxGuard.
Req 9
Restrict physical access to cardholder data
Out of scope
n/a
Physical access controls are not addressed by LinuxGuard.
Req 12
Support information security with organizational policies and programs
Out of scope
n/a
Information security policy administration, security awareness training, incident response program management, and third-party risk management are organizational responsibilities not addressed by LinuxGuard.
Important: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim.
How to share with auditor
Three export paths are available, depending on the QSA's evidence preference:
Console Compliance Expansion reports. Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per Compliance Expansion. Each report includes the framework version (PCI-DSS v4.0.1), last-verified date, per-control coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification.
Support bundles for host-level evidence.
support-bundle collecton each host in the CDE produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see Support Bundles. Bundles are useful when the QSA wants raw host-level telemetry rather than a console-rendered report.Console CSV / JSON export per control. Compliance Expansion → PCI-DSS v4.0.1 → control detail → Evidence tab exports per-control evidence in machine-readable form for QSAs who want to ingest evidence into their own GRC tooling.
Security Note: Support bundles include the raw
agent.logand rotated segments. Attribute-key redaction (api_key / *_token / *_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally — particularly relevant for CDE evidence where hostnames and process command-line arguments may correlate to systems handling cardholder data. See Support Bundles for the per-file redaction status table.
Cross-references
Audit & Comply — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template.
Compliance Expansion — console pillar; canonical Evidence Location pointer set.
Audit — authorizations and SUDO execution audit feeding compliance evidence.
Support Bundles — per-file redaction status table; pre-share PII warning.
Log Management — log retention and rotation relevant to the 12-month audit-period retention requirement (Req 10.5.1).
Glossary — framework acronyms and compliance vocabulary definitions.
Last reviewed: 2026-05-31 against PCI-DSS v4.0.1 published 2024-06-01.
Last updated
Was this helpful?