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.

Control ID
Description
Tier
Evidence
Notes

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 collect on 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.log and 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?