CIS, NIST, ISO 27001, SOC2, PCI-DSS, HIPAA & GDPR

Learning Objectives

Understand key compliance frameworks and when each applies
Implement technical controls that satisfy multiple frameworks
Map security controls to compliance requirements
Prepare for SOC2 Type II audits as a DevOps engineer

What is this? (Beginner On-Ramp)

Compliance frameworks (like SOC 2, HIPAA, or PCI-DSS) are standardized security checklists enforced by auditors. They prove to customers and governments that a company is following strict security and privacy laws, often requiring specific technical controls like audit logs.

45.1 Compliance Framework Overview

    Compliance Framework Map
    ─────────────────────────

    WHO REQUIRES IT?
    ──────────────────────────────────────────────────────────────
    CIS Benchmarks:      Self-imposed; gold standard for hardening
    NIST CSF:            US Federal, critical infra, widely adopted
    NIST SP 800-53:      US Federal agencies (FedRAMP)
    ISO 27001:           International; required by many enterprises
    SOC2 Type II:        SaaS companies; required by enterprise customers
    PCI-DSS:             Anyone processing credit card payments
    HIPAA:               US healthcare, PHI (Protected Health Info)
    GDPR:                EU data protection; any company with EU users

    OVERLAPPING CONTROLS (satisfy all at once):
    ──────────────────────────────────────────
    Access control (RBAC, MFA, least privilege)
    Encryption at rest and in transit
    Audit logging and monitoring
    Vulnerability management (patching, scanning)
    Incident response plan
    Business continuity / disaster recovery

45.2 CIS Benchmarks

CIS (Center for Internet Security) Benchmarks provide hardening guides for every OS and platform.

# ── CIS Linux Benchmark Key Controls ──────────────────────

# 1. Filesystem Hardening
# /etc/fstab noexec/nosuid/nodev on appropriate mounts
grep "noexec\|nosuid\|nodev" /etc/fstab

# 2. Service Reduction (disable what you don't need)
systemctl disable avahi-daemon cups rpcbind
systemctl mask avahi-daemon cups rpcbind

# 3. SSH Hardening (CIS 5.2.x)
grep -E "PermitRootLogin|PasswordAuthentication|MaxAuthTries|Protocol" /etc/ssh/sshd_config

# 4. Password Policy (CIS 5.4.x)
grep PASS_MAX_DAYS /etc/login.defs   # Should be 365
grep PASS_MIN_DAYS /etc/login.defs   # Should be 7
grep PASS_WARN_AGE /etc/login.defs   # Should be 7

# 5. Auditing (CIS 4.1.x)
systemctl is-active auditd
auditctl -l | head -20

# ── Run CIS Benchmark Assessment ──────────────────────────
# OpenSCAP (built into RHEL/CentOS)
oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis \
    --report /tmp/cis-report.html \
    /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Lynis (cross-distro)
apt install lynis
lynis audit system
# Generates: /var/log/lynis.log, /var/log/lynis-report.dat
# Hardening index: 0-100

45.3 NIST Cybersecurity Framework

    NIST CSF Core Functions
    ────────────────────────

    IDENTIFY:
    Asset inventory, risk assessment, governance
    • What assets do we have?
    • What data do we collect and process?
    • What are the risks?

    PROTECT:
    Implement safeguards
    • Access control (MFA, RBAC)
    • Encryption (data at rest, in transit)
    • Security awareness training
    • Secure configuration (CIS benchmarks)
    • Patching / vulnerability management

    DETECT:
    Anomaly detection, monitoring
    • SIEM / log aggregation
    • IDS/IPS
    • File integrity monitoring (AIDE)
    • Vulnerability scanning

    RESPOND:
    Incident response plan
    • Defined response team (CSIRT)
    • Playbooks for common incidents
    • Communication plan
    • Evidence preservation

    RECOVER:
    Recovery planning
    • Business continuity plan
    • Backup and DR testing
    • Post-incident improvement

    NIST CSF Maps to:
    ISO 27001 ✓, SOC2 ✓, FedRAMP ✓, HIPAA ✓
    → Implementing CSF often satisfies core controls of others

45.4 SOC2 Type II

SOC2 is audited by a CPA firm against the Trust Services Criteria (TSC). Type II covers a 6-12 month period.

    SOC2 Trust Services Criteria
    ──────────────────────────────

    Security (CC): Required for all SOC2
    ─────────────────────────────────────
    CC1: Control environment (policies, procedures)
    CC2: Communication and information
    CC3: Risk assessment
    CC4: Monitoring (SIEM, alerts, reviews)
    CC5: Control activities (technical controls)
    CC6: Logical and physical access (MFA, RBAC, SSO)
    CC7: System operations (change management, incidents)
    CC8: Change management (deployment process)
    CC9: Risk mitigation (DR, backup)

    Availability (A): Uptime/performance commitments
    Processing Integrity (PI): Complete, accurate processing
    Confidentiality (C): Protect confidential information
    Privacy (P): Personal information collection/use

    What Auditors Actually Look For:
    ──────────────────────────────────
    ✓ Documented policies (written, approved, reviewed annually)
    ✓ Evidence controls work (logs, screenshots, pull request history)
    ✓ Access reviews (quarterly) — inactive accounts removed
    ✓ Vulnerability management (scan weekly, patch within SLA)
    ✓ Incident response (every incident has a ticket)
    ✓ Background checks for employees
    ✓ Security training completion
    ✓ Change management (all changes via PR + review)
    ✓ Encryption (all data encrypted at rest + in transit)
    ✓ MFA required for all systems

# SOC2 Technical Evidence Automation

# Evidence 1: Access reviews (export all IAM users + last login)
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d > iam-report.csv

# Evidence 2: MFA enforcement
aws iam list-users | jq '.Users[].UserName' | while read user; do
    mfa=$(aws iam list-mfa-devices --user-name $user | jq '.MFADevices | length')
    echo "$user: MFA_devices=$mfa"
done

# Evidence 3: Encryption at rest (S3 buckets)
aws s3api list-buckets | jq -r '.Buckets[].Name' | while read bucket; do
    enc=$(aws s3api get-bucket-encryption --bucket $bucket 2>/dev/null || echo "NONE")
    echo "$bucket: $enc"
done

# Evidence 4: Audit trail completeness
# Verify CloudTrail is enabled and logs are in S3
aws cloudtrail describe-trails | jq '.trailList[] | {name, S3BucketName, IsLogging}'

45.5 PCI-DSS

    PCI-DSS Requirements (v4.0)
    ────────────────────────────

    1. Install and maintain network security controls
       → Firewall/network segmentation around cardholder data environment (CDE)

    2. Apply secure configurations to all system components
       → CIS benchmarks, no default passwords, disable unused services

    3. Protect stored account data
       → No plain-text PANs stored, use tokenization, strong encryption

    4. Protect cardholder data with strong cryptography during transmission
       → TLS 1.2+ for all payment data, no weak cipher suites

    5. Protect all systems from malicious software
       → Antivirus/EDR, regular scanning

    6. Develop and maintain secure systems and software
       → SAST/DAST, patching within SLAs, WAF for web-facing systems

    7. Restrict access to system components and cardholder data
       → Need-to-know, role-based access

    8. Identify users and authenticate access
       → Unique user IDs, MFA required for remote access and admin

    9. Restrict physical access to cardholder data
       → Datacenter physical controls

    10. Log and monitor all access to system components and cardholder data
        → Centralized logging, 12-month retention, 3-month online

    11. Test security of systems and networks regularly
        → Quarterly vulnerability scans, annual penetration test

    12. Support information security with organizational policies
        → Security policy, risk assessment, incident response plan

    Key DevOps Controls:
    ──────────────────────
    ✓ Network segmentation (CDE in isolated VPC/namespace)
    ✓ Tokenization (never store raw card numbers — use Stripe token)
    ✓ TLS 1.2+ everywhere in payment flows
    ✓ Logging with 12-month retention
    ✓ Automated vulnerability scanning in CI/CD
    ✓ File Integrity Monitoring (AIDE, Tripwire) on CDE systems

    GDPR Technical Requirements
    ────────────────────────────

    Article 25: Privacy by Design
    → Build privacy in from the start, not bolted on
    → Data minimization: collect only what you need

    Article 32: Security of Processing
    → Appropriate technical measures for the risk:
      • Encryption of personal data (at rest + in transit)
      • Ongoing confidentiality, integrity, availability
      • Ability to restore after incident
      • Regular testing (penetration testing, security review)

    Article 33/34: Breach Notification
    → Report to supervisory authority within 72 hours
    → DevOps implication: Alert pipeline must include PII breach detection
    → SIEM rule: Alert on bulk export of user data

    Article 17: Right to Erasure ("Right to be Forgotten")
    → Technical capability to delete all data for a user
    → Complication: Backups — GDPR allows keeping in backup if encrypted
    → Solution: Separate user data from logs, use surrogate keys

    Article 20: Data Portability
    → Export user data in machine-readable format (JSON/CSV)
    → Build export API

    Practical DevOps Controls:
    ───────────────────────────
    ✓ Data classification: tag resources with data sensitivity
    ✓ No EU personal data in US-based logs (data residency)
    ✓ Log anonymization: hash IPs, truncate email in logs
    ✓ Encryption: all PII encrypted at rest (per-user keys for erasure)
    ✓ Access logging: who accessed what personal data, when
    ✓ Retention policies: auto-delete logs containing PII after 90 days

45.7 Interview Questions

Q1: What is SOC2 Type II and why do enterprises require it from SaaS vendors?

Answer: SOC2 (Service Organization Control 2) is a security audit standard by AICPA. Type II covers a 6-12 month observation period — an auditor reviews your actual operations, not just your stated policies. It validates the Trust Services Criteria (TSC), especially Security. Enterprises require SOC2 because: (1) Third-party validation: Instead of each customer running their own security assessment, one SOC2 audit covers all. (2) Contractual obligation: Enterprise procurement/legal requires proof of security controls. (3) Insurance: Reduces enterprise’s risk in using SaaS — if a breach occurs, SOC2 shows due diligence. As a DevOps engineer, SOC2 means: all production changes via pull requests, quarterly access reviews, MFA everywhere, centralized logging, documented incident response.

Q2: How do you handle GDPR’s “Right to Be Forgotten” technically in a system with backups?

Answer: The right to erasure requires deleting all personal data about a user when they request it. The complication is backups — you can’t easily restore a backup and delete one user. Technical approaches: (1) Crypto-shredding: Encrypt each user’s data with a user-specific key. To “delete” the user, delete their encryption key — all their data in backups is now cryptographically inaccessible. (2) Data separation: Store personal data in a separate database with shorter retention, separate from behavioral/log data. (3) Pseudonymization: Replace direct identifiers (email, name) with a surrogate ID in logs and analytics — delete the mapping table to de-identify. (4) Documented backup policy: GDPR allows keeping personal data in encrypted backups if you document that you will not restore it for that user’s data.

45.8 Summary

Framework	Who Needs It	Key Focus
CIS Benchmarks	All	System hardening
NIST CSF	US Federal, enterprises	Risk framework
SOC2 Type II	SaaS vendors	Customer trust
PCI-DSS	Payment processors	Card data protection
HIPAA	US healthcare	PHI protection
GDPR	EU user data	Privacy rights
ISO 27001	Enterprises	ISMS certification

Next Chapter: Chapter 46: Live Kernel Patching, Kexec & Crash Dumps

Prerequisites

Chapter 14 (Security Fundamentals), Chapter 19 (Auditd).

Deep Dive: File Integrity Monitoring (FIM)

Compliance frameworks (like PCI-DSS) mandate that you know exactly when critical system files are modified. File Integrity Monitoring (FIM) solves this.

How it Works (AIDE)

Advanced Intrusion Detection Environment (AIDE) creates a baseline database of file hashes (SHA-512, etc.), permissions, and metadata for specified directories (like /etc and /bin).

# 1. Initialize the baseline (Run this on a clean, known-good state)
aide --init

# 2. Move the database to the active location
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# 3. Run a check (often done via daily cron)
aide --check

If an attacker modifies /etc/passwd or replaces the ls binary with a rootkit, the hash will change, and AIDE will flag it in the next scan.

Production Note: The baseline database MUST be stored securely. If an attacker compromises the server, they could alter a file and simply run aide --init to create a new baseline. Real production environments ship FIM alerts to a central SIEM immediately and store baselines on read-only media or remote servers.

Advantages & Disadvantages

Advantages: Opens doors to enterprise/government contracts, forces baseline security hygiene. Disadvantages: Compliance does not equal security; generates massive amounts of paperwork.

Common Mistakes

Treating compliance as a one-time checklist instead of a continuous process.
Implementing security controls only on the production environment and ignoring CI/CD or staging.
Assuming compliance equals security (you can be compliant but insecure).

Troubleshooting

Symptom	Cause	Diagnosis	Fix
Audit fails on file integrity monitoring	AIDE/Tripwire not configured or database not updated	`Check AIDE logs`	Initialize the AIDE database, set up a cron job, and update it after legitimate changes
Audit fails on log retention	Logs rotated and deleted too early	`Check logrotate conf and SIEM retention policies`	Ensure logs are shipped to immutable storage (like AWS S3 Object Lock) for required retention period

Hands-on Lab

Objective: Check system compliance against CIS benchmarks.

# 1. Run a mock compliance scan using OpenSCAP (if installed)
# oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

# 2. Check password expiration settings (Common compliance requirement)
grep PASS_MAX_DAYS /etc/login.defs

Exercises

Set up AIDE (Advanced Intrusion Detection Environment) on a test system, create the initial database, modify a tracked file, and run a check to detect the change.
Draft a data classification policy classifying Public, Internal, Confidential, and Restricted data.

Revision Notes

SOC 2 focuses on Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy).
PCI-DSS requires strict network segmentation (CDE) for cardholder data.
GDPR mandates data minimization, right to erasure, and strict consent management.
FIM (File Integrity Monitoring) is a common technical requirement across many frameworks.