Audit Logging Setup for Compliance Requirements

Audit Logging Setup for Compliance Requirements

The problem: when an auditor asks for logs, but they don't exist

PCI DSS requires logging every access to cardholder data. GDPR mandates recording operations with personal data. SOC 2 requires logging all admin actions in production systems. An auditor asks for logs from the past 12 months for a specific user — and it turns out that audit logs either were not kept, were overwritten after 7 days, or are in a format that makes rapid extraction impossible. Non-compliance fines for PCI DSS can reach $500,000 per month, and the average data breach cost is $4.45 million according to IBM Cost of a Data Breach. The average compliance violation cost for HIPAA is $1.5 million per year. Setting up audit logging with WORM takes 3 times less time than building a hash chain and covers 95% of standard requirements. We have solved this for 50+ projects: from startups to banks. We set up audit logging turnkey in 3-7 days, guaranteeing compliance.

Audit logging is a separate subsystem from application logging. Its requirements are different: immutability, guaranteed delivery, long-term storage (up to 7 years), and forensic analysis capability.

What data needs to be logged for PCI DSS?

Minimum set for PCI DSS (Requirement 10):

• All authentication attempts (successful and unsuccessful)
• All actions by users with root/admin privileges
• Access to audit log files
• Use of identification and authentication mechanisms
• Initialization, stopping, and pausing of audit log functions
• Creation and deletion of system objects

Each record must contain: event type, date/time (UTC), source (IP, hostname), user ID, result (success/failure), and identifier of the affected resource.

How to configure auditd on Linux

auditd is the Linux kernel subsystem for auditing. Rules are defined in /etc/audit/rules.d/:

# /etc/audit/rules.d/audit.rules
-D
-b 8192
-f 1
-w /etc/sudoers -p wa -k sudo_changes
-w /etc/sudoers.d/ -p wa -k sudo_changes
-w /bin/su -p x -k su_execution
-w /var/log/auth.log -p wa -k auth_log
-w /var/log/faillog -p wa -k login_failures
-w /etc/passwd -p wa -k user_modification
-w /etc/shadow -p wa -k shadow_modification
-w /etc/group -p wa -k group_modification
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S mount -k mounts
-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -k access_denied
-e 2

Note: The -e 2 parameter makes rules immutable until reboot — neither processes nor root can disable auditing without a system restart. For PCI DSS, this is a mandatory requirement.

Check active rules with auditctl -l, ausearch -k sudo_changes --start today, aureport --auth --start this-month.

Why centralized log collection is critical

Local auditd logs must be sent to a centralized storage immediately — if the local server is compromised, the audit log on it loses evidentiary value. Configure sending via audisp-remote:

# /etc/audisp/plugins.d/au-remote.conf
active = yes
direction = out
path = /sbin/audisp-remote
type = always
args = 192.168.1.100
format = string

# /etc/audisp/audisp-remote.conf on aggregator server
remote_server = 192.168.1.100
port = 60
transport = tcp
queue_file = /var/spool/audit/remote.log
mode = immediate
queue_depth = 10240
fail_action = syslog

Audit logging in Kubernetes: Falco and API Server

For Kubernetes, we use falco as runtime security and audit logging:

# falco.yaml
rules_file:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/k8s_audit_rules.yaml
json_output: true
json_include_output_property: true
outputs:
  rate: 1
  max_burst: 1000
  output:
    - http:
        url: http://falco-sidekick:2801
plugins:
  - name: k8saudit
    library_path: libk8saudit.so
    init_config:
      sslVerify: false
      webhookMaxBatchSize: 200
    open_params: "http://0.0.0.0:9765/k8s-audit"

Kubernetes API server audit policy:

# kube-apiserver audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    users: ["system:admin"]
  - level: Request
    verbs: ["create", "update", "patch", "delete"]

Immutability and integrity: WORM vs hash chain

Audit logs must be protected from modification. Compare approaches:

S3 Object Lock is simpler to set up than a hash chain and provides sufficient protection for most standards. For PCI DSS, WORM is sufficient; for SOC 2, a hash chain may be required.

S3 Object Lock in Compliance mode:

resource "aws_s3_bucket_object_lock_configuration" "audit" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    default_retention {
      mode = "COMPLIANCE"
      years = 7
    }
  }
}

Comparison of standards: audit logging requirements

Typical mistakes in audit logging setup

• Lack of centralized collection: local logs lose evidentiary value when a host is compromised.
• Weak audit rules: for example, not logging execve calls from root.
• Insufficient retention: PCI DSS requires at least 1 year, HIPAA requires 6 years.
• Ignoring Kubernetes: pods are destroyed, taking local logs with them.

What stages are included in turnkey audit logging setup?

1. Audit of current infrastructure and compliance requirements.
2. Development of audit policies (which events, how to store, who has access).
3. Configuration of auditd on Linux servers (including immutable rules).
4. Configuration of Falco and Kubernetes audit policy.
5. Centralized log collection via syslog/S3.
6. Setup of WORM storage or hash chain.
7. Incident investigation documentation (runbook).
8. Team training: how to analyze logs, how to extract data for auditors.
9. Guarantee: logs will not be lost, altered, and will be accessible for the last 7 years.

Why should you trust us with the setup?

7+ years of experience in DevOps and compliance. Over 50 projects on audit logging in banks, fintech, e-commerce. Certified specialists (AWS, Kubernetes, CISSP). Our configurations pass audits on the first attempt in 98% of cases. Contact us — we will evaluate your project and provide a solution in 1-2 days. Order turnkey audit logging setup and avoid fines. Get a consultation for your project.

Setup timeline: from 3 to 7 days depending on scale. Cost is calculated individually. Links: PCI DSS — audit requirements, Falco — runtime security for Kubernetes.