diff --git a/docs/lessons/31_methodology_policy_and_politics/31.8_compliance-_regulations_and_standards.md b/docs/lessons/31_methodology_policy_and_politics/31.8_compliance-_regulations_and_standards.md index ea7c17d..ffdccb2 100644 --- a/docs/lessons/31_methodology_policy_and_politics/31.8_compliance-_regulations_and_standards.md +++ b/docs/lessons/31_methodology_policy_and_politics/31.8_compliance-_regulations_and_standards.md @@ -1,66 +1,427 @@ ## 31.8 Compliance: Regulations and Standards +Compliance is the practice of proving that systems are operated according to +required rules. Those rules might come from law, contracts, customer promises, +industry standards, security policy, or internal risk management. +For a Linux administrator, compliance is not just paperwork. It changes how you +manage accounts, patches, logs, backups, encryption, network exposure, change +records, and incident evidence. A well-run system should be secure enough to +operate and explainable enough to audit. !!! abstract "What you will learn" - - Explain where **31.8 Compliance: Regulations and Standards** fits in day-to-day Linux operations. - - Use current Linux tooling to inspect, change, and verify the relevant system behavior. - - Connect the concept to a real operational scenario: an operations team trying to become predictable without becoming bureaucratic. - -!!! example "Field story" - Imagine an operations team trying to become predictable without becoming bureaucratic. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved. + - Distinguish regulations, standards, policies, controls, and evidence. + - Recognize common compliance frameworks that affect Linux operations. + - Map Linux administration tasks to audit-ready control evidence. + - Use read-only commands to collect useful compliance evidence. + - Avoid common mistakes that make compliant systems difficult to operate. !!! success "Operator principle" - Policies are useful when they make good work easier and risky work harder. + Compliance work is strongest when the system is configured correctly, the + evidence is easy to reproduce, and exceptions are written down before they + become surprises. -## Hands-on practice +## Regulations, standards, and controls -Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise. +These words are often used loosely, but they mean different things. -1. Inspect the current state with a read-only command related to this topic. -2. Save the command and output in a short lab note. -3. Make one reversible change or simulate the change in a sandbox. -4. Re-run the inspection and explain what changed. +**Regulation** is an external legal requirement. Examples include HIPAA for +protected health information in the United States, GDPR for personal data in the +European Union, and SOX for certain financial reporting controls. -## Check your understanding +**Standard** is a defined set of requirements or best practices. Examples include +PCI DSS for payment-card environments, ISO/IEC 27001 for information security +management, SOC 2 trust services criteria, CIS Benchmarks, and NIST guidance. + +**Policy** is the organization's own rule. A company might require MFA for +administrator access, monthly vulnerability remediation, encrypted laptop disks, +or a documented approval before production firewall changes. + +**Control** is the specific safeguard used to satisfy a requirement. "Only +authorized administrators can use sudo" is a control. So is "production logs are +retained for 90 days." + +**Evidence** is proof that the control exists and operated as expected. Evidence +can include command output, screenshots, logs, change tickets, backup reports, +monitoring alerts, access-review records, vulnerability reports, or signed +exception approvals. + +!!! example "A simple chain" + Requirement: production administrator actions must be attributable. + + Control: administrators use individual accounts with sudo logging enabled. + + Evidence: `/etc/sudoers` policy, group membership, sudo logs, and a ticket + showing the most recent access review. + +## Why compliance matters to Linux teams + +Compliance affects operations because Linux hosts often process sensitive data, +run customer-facing services, store logs, provide identity integrations, and +host administrative tooling. + +A Linux operator may be asked to answer questions like: + +- Who can log in to this host? +- Who can become root? +- Is SSH password authentication disabled? +- Are security updates current? +- Are disks or backups encrypted? +- Are system logs retained and shipped off-host? +- Are production changes approved? +- Can we prove when a service was patched? +- Can we restore from backup? +- Is cardholder, health, employee, or customer data stored here? +- Are exceptions documented and time-limited? + +The job is not to memorize every regulation. The job is to operate systems in a +way that produces clear, repeatable answers. + +## Common frameworks you will hear about + +You do not need to be a lawyer or auditor to work around these frameworks, but +you should know the shape of them. + +**PCI DSS** applies to environments that store, process, or transmit payment-card +data. Linux work may involve network segmentation, secure configuration, +vulnerability remediation, access control, logging, file-integrity monitoring, +and evidence collection. + +**HIPAA** applies to protected health information in the United States. Linux +work may involve access controls, audit logs, encryption, backup protection, +incident response, and vendor boundaries. + +**GDPR** focuses on personal data for people in the European Union. Linux work +may involve data location, retention, deletion, access logging, encryption, +breach response, and minimizing unnecessary personal data collection. + +**SOC 2** is an assurance report around trust service criteria such as security, +availability, confidentiality, processing integrity, and privacy. Linux work may +show up through access reviews, change management, incident response, monitoring, +backups, vulnerability management, and vendor controls. + +**ISO/IEC 27001** is an information security management standard. Linux work +usually supports documented risk treatment, asset management, access controls, +operations security, logging, backup, cryptography, supplier controls, and +incident response. + +**CIS Benchmarks** are technical hardening recommendations for operating systems +and software. Linux work may involve SSH hardening, password policy, auditd, +firewall rules, filesystem mount options, package hygiene, service reduction, +and kernel parameters. + +**NIST guidance** is widely used by government and enterprise environments. +Linux work may support identity, logging, asset inventory, vulnerability +management, configuration baselines, incident response, and recovery planning. + +## Linux controls auditors often care about + +Most audits eventually come back to a small set of operational questions. The +exact wording changes, but the themes are stable. + +### Asset inventory + +You cannot protect or audit systems you cannot identify. + +Useful evidence might include: + +```bash +hostnamectl +uname -a +ip addr show +ip route show +lsblk +df -hT +systemctl list-units --type=service --state=running +``` + +Record what the host is, who owns it, what environment it belongs to, what data +classification applies, and what services it runs. + +### Access control + +Auditors often ask who has access and how privileged access is controlled. + +Useful evidence might include: + +```bash +getent passwd +getent group sudo +getent group wheel +sudo -l +lastlog +last -n 20 +``` + +On production systems, prefer named accounts over shared accounts. Keep root SSH +login disabled unless there is a documented, time-limited exception. + +```bash +sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication' +``` + +### Privilege escalation + +Sudo policy should be intentional and reviewable. + +Useful evidence might include: + +```bash +sudo -l +sudo visudo -c +grep -R "^[^#].*ALL" /etc/sudoers /etc/sudoers.d 2>/dev/null +journalctl _COMM=sudo --since "7 days ago" +``` + +Avoid broad permanent rules when a narrow command, group, or break-glass process +would satisfy the need. + +### Patch and vulnerability management + +Compliance usually requires evidence that security updates are tracked and +applied within a defined time window. + +Debian and Ubuntu examples: + +```bash +apt list --upgradable +apt-cache policy openssl +unattended-upgrades --dry-run --debug +``` + +RHEL, Fedora, and compatible systems: + +```bash +dnf check-update +dnf updateinfo list security +rpm -q kernel openssl +``` + +Patch evidence should include the date, system, packages, approval or maintenance +window if required, result, and rollback note. -- What evidence would tell you that this system is healthy? -- What is the riskiest command in this lesson, and how would you make it safer? -- How would you explain section 31.8 to a teammate during an incident handoff? +### Logging and audit trails +Logs are compliance evidence only if they are present, complete enough, protected +from casual tampering, and retained long enough. -Navigating the world of IT is akin to embarking on a great maritime adventure. โš“ On one hand, you enjoy the freedom of exploration and innovation, but on the other, you must respect certain boundaries and laws. These laws, in our context, are the 'Regulations and Standards' that govern IT operations. +Useful evidence might include: -๐Ÿ”Ž **Why is Compliance Important?** +```bash +journalctl --disk-usage +journalctl --since "24 hours ago" -p warning +systemctl status systemd-journald +systemctl status auditd 2>/dev/null || true +auditctl -s 2>/dev/null || true +ls -lh /var/log +``` -In any organization, compliance refers to adhering to legal and ethical standards. These rules are not there just to make life hard for you. They exist to: +If logs must survive host loss, ship them off-host. Local logs alone are weak +evidence after a compromise or disk failure. -- Ensure fair competition ๐Ÿ -- Safeguard consumer rights ๐Ÿ›ก๏ธ -- Protect data and privacy of users ๐Ÿ” -- Maintain the integrity and reputation of businesses ๐Ÿฆ +### Network exposure -Breaking compliance can lead to legal issues, financial penalties, and damage to the company's reputation. Hence, it's paramount for any IT professional to understand and follow these rules. +Network controls show what can reach the host and what the host exposes. -๐Ÿ’ป **Compliance in the Tech World** +Useful evidence might include: -In the tech realm, compliance often involves data protection and privacy, cybersecurity, and ethical handling of technology. Some common regulations and standards that you might encounter in a professional setting include: +```bash +ss -tulpn +ip route show +nft list ruleset 2>/dev/null || true +iptables -S 2>/dev/null || true +firewall-cmd --list-all 2>/dev/null || true +ufw status verbose 2>/dev/null || true +``` -- **GDPR (General Data Protection Regulation)**: It aims to protect user data and privacy in the EU and the transfer of personal data outside the EU. ๐Ÿ’ผ -- **ISO 27001**: An international standard that sets out the specification for an information security management system (ISMS). ๐ŸŒ -- **PCI DSS (Payment Card Industry Data Security Standard)**: A set of security standards designed to ensure that ALL companies that accept, process, store or transmit credit card information maintain a secure environment. ๐Ÿ’ณ -- **HIPAA (Health Insurance Portability and Accountability Act)**: It provides data privacy and security provisions for safeguarding medical information. ๐Ÿฉบ +Evidence should connect open ports to business purpose. An unexplained listening +service is a risk even if it is not actively being abused. -๐Ÿ’ก As an IT professional, it's not always your job to implement these standards directly. However, knowing them helps you understand the underlying principles guiding your organizationโ€™s protocols and procedures. +### Data protection -โš™๏ธ **Aligning With Linux** +Sensitive data controls often involve encryption, backup protection, retention, +and deletion procedures. -When working with Linux, various features help you align with compliance standards: +Useful evidence might include: -- **IPTables and Firewalls**: Linux's firewall system allows for granular control over network traffic, enabling you to establish secure connections. ๐Ÿ‘ฎโ€โ™€๏ธ -- **User Permissions and Access Control**: Linux provides a robust system for controlling who can access what data - a key aspect of many compliance rules. ๐Ÿšช -- **Audit and Syslog**: It's important to monitor actions and changes on your Linux systems. The audit daemon and syslog services provide powerful logging - often a requirement for compliance checks. ๐Ÿ“œ +```bash +lsblk -f +findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS / +cryptsetup status luks-root 2>/dev/null || true +systemctl list-timers '*backup*' '*snapshot*' +``` -Understanding these functions is a crucial part of ensuring that the Linux systems under your purview adhere to the essential regulations and standards. +Do not guess whether a host stores regulated data. Track data classification in +inventory, architecture notes, or service ownership records. + +### Backup and recovery + +Many frameworks care less about whether a backup job exists and more about +whether restore has been tested. + +Useful evidence might include: + +```bash +systemctl list-timers +journalctl -u backup.service --since "7 days ago" 2>/dev/null || true +restic snapshots 2>/dev/null || true +borg list 2>/dev/null || true +``` + +Strong evidence includes a recent restore test, not only a green backup status. + +### Change management + +Compliance frameworks often require production changes to be approved, tested, +implemented, and reviewed. + +A good Linux change record includes: + +- system or service changed +- reason for the change +- risk and rollback plan +- approval if required +- exact commands or automation used +- validation output +- incident or follow-up notes + +The command history on a host is not a change-management system. It is at best a +supporting clue. + +## Evidence quality + +Good compliance evidence is specific, reproducible, and tied to a requirement. + +Weak evidence: + +- "We use secure settings." +- A screenshot without a host name or date. +- A ticket saying "done" with no validation. +- A spreadsheet that no one owns. +- A hardening report that cannot be reproduced. + +Stronger evidence: + +- command output with host, date, and command shown +- a link to the approved change ticket +- the configuration file or automation commit that enforces the control +- monitoring or log evidence showing the control operated +- an exception record with owner, reason, expiration date, and compensating + control + +!!! tip "Keep evidence boring" + Auditors and incident responders both benefit from boring evidence. Use + simple commands, stable reports, and consistent naming. Clever one-off + evidence is hard to trust later. + +## Exceptions + +An exception is a documented, approved departure from a rule. Exceptions are not +failures by themselves. Undocumented exceptions are the problem. + +Every exception should answer: + +- What requirement is not being met? +- Why is the exception needed? +- What system, account, service, or data is affected? +- Who owns the risk? +- What compensating control reduces the risk? +- When does the exception expire? +- What is the plan to remove it? + +For example, if an old application requires a weaker TLS setting, document the +affected service, the business owner, the network restriction around it, the +monitoring in place, and the retirement date. + +## Compliance without bureaucracy + +Bad compliance programs slow work down without reducing risk. Good compliance +programs make safe work easier. + +Useful habits: + +- automate baseline checks where possible +- store infrastructure configuration in version control +- keep production changes tied to tickets +- make standard changes repeatable +- write rollback steps before the change +- keep service ownership records current +- review privileged access on a schedule +- remove unused services and accounts +- test backup restore, not only backup creation +- record exceptions with expiration dates + +The goal is operational discipline, not paperwork theater. + +## Common mistakes + +**Confusing a tool with compliance.** Installing auditd, a scanner, or a SIEM +does not satisfy a requirement by itself. The tool must be configured, monitored, +reviewed, and tied to a control. + +**Treating the baseline as universal.** A CIS benchmark may recommend disabling a +feature that a system legitimately needs. Apply baselines with context and +document exceptions. + +**Collecting evidence after the fact.** If evidence is only created during audit +week, it is easy to miss important detail. Build evidence into normal operations. + +**Using shared administrator accounts.** Shared accounts make attribution hard. +Use named accounts, groups, sudo logs, and break-glass procedures. + +**Leaving stale access in place.** Departed employees, old vendor accounts, and +unused SSH keys are common audit findings and real security risks. + +**Forgetting retention.** Logs and backups are useful only if retained long +enough for the requirement and protected from unauthorized changes. + +**Overpromising.** Do not claim every system is encrypted, fully patched, or +centrally logged unless you have evidence. Compliance language should be precise. + +## Hands-on practice + +Use a disposable VM, container, or lab host. + +1. Create a short compliance evidence note for the host: + + ```bash + { + date -Is + hostnamectl + uname -a + ss -tulpn + getent group sudo 2>/dev/null || getent group wheel + sshd -T 2>/dev/null | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication' + journalctl --disk-usage + } | tee compliance-evidence.txt + ``` + +2. Pick one control statement, such as: + + - "SSH root login is disabled." + - "Only approved administrators can use sudo." + - "System logs are retained locally." + - "Only documented services listen on the network." + +3. Under the control statement, paste the command that proves or disproves it. + +4. Write one finding in plain language: + + - compliant + - non-compliant + - unknown because evidence is missing + - exception required + +5. If a change is needed, write the proposed change, risk, rollback, and + validation command. Do not change a production system without approval. + +## Check your understanding -Remember, navigating the ocean without knowledge of the maritime laws can be risky. Similarly, charting an impeccable IT career requires understanding and respecting these vast seas of regulations and standards. It might seem daunting, but worry notโ€”these laws are your guiding stars, helping you navigate your journey successfully. โญ +- What is the difference between a regulation, a standard, a policy, a control, + and evidence? +- Why is a screenshot weaker than repeatable command output? +- Which Linux controls help prove administrator accountability? +- What evidence would show that a host's network exposure is understood? +- Why is a successful backup job not the same as a successful recovery control? +- What should be recorded when a system cannot meet a hardening baseline? +- How can change-management records reduce audit and incident-response pain?