Operating-System Hardening

01 Introduction

The previous six lessons presented the security's mechanisms: the principles (Lesson 12.1), the authentication (Lesson 12.2), the authorization (Lesson 12.3), the access control models (Lesson 12.4), the Linux security (Lesson 12.5), and the sandboxing (Lesson 12.6). This lesson presents the hardening: the discipline that turns the mechanisms into a secure's system, and that keeps the system's security as the threats evolve. The hardening's central's observation: the security is a process, not a product. A system is not secure because it has the firewall, the SELinux, or the strong's passwords; it is secure because the configuration is the reviewed, the patches are the applied, the logs are the monitored, and the incidents are the responded to. The hardening is that process's name.

The hardening is the system's security's configuration's and the operation's discipline: the reduction of the attack's surface, the strengthening of the defenses, the monitoring of the security's state, and the response to the security's incidents. The hardening's goal is threefold:

• The attack's surface's reduction. The system should expose the minimum number of the services, the ports, the accounts, the privileges, and the features, so the attacker has the fewer's entry's points and the fewer's exploitable's components.
• The defense's strengthening. The system's mechanisms (the authentication, the authorization, the sandboxing, the monitoring) should be the configured for the maximum's effectiveness: the strong's passwords, the multi-factor's authentication, the least privilege, the mandatory access control, the sandboxing's confinement, the logging's coverage.
• The compromise's detection. The system should record the security-relevant's events (the authentication, the authorization, the file's accesses, the network's connections, the privilege's escalations), and the records should be the monitored for the anomalies, so the compromises and the attacks are the detected and the responded to.

The hardening's practice is iterative and ongoing: the baselines are the applied, the systems are the assessed, the gaps are the remediated, the new's baselines are the selected, and the cycle repeats. The observation is the reason the security's operations (the SecOps) is the security's central's activity: the modern's threat's environment changes (the new's vulnerabilities, the new's attacks, the new's workloads), and the static's configuration cannot keep pace. The hardening is the security's discipline that keeps the system secure as the environment changes.

This lesson presents the hardening. It defines the hardening and its goals. It presents the hardening's methodology (the standards, the benchmarks, the baselines). It presents the attack's surface's reduction (the services, the ports, the packages, the kernel's modules). It presents the identity's and the authentication's hardening. It presents the kernel's hardening (the sysctl's parameters, the ASLR, the kernel's modules' signing), the file systems' hardening (the permissions, the mount's options, the disk's encryption), and the network's hardening (the firewalls, the segmentation). It presents the logging, the monitoring, and the detection (the auditd, the file's integrity's monitoring, the HIDS, the SIEM), the patch management and the vulnerability scanning, and the compliance and the auditing (the CIS, the NIST, the STIG, the PCI-DSS). It presents the security operations (the SecOps, the incident's response, the hardening's lifecycle). It closes with the hardening's design's principles and the unit's synthesis.

02 Learning objectives

This lesson contributes to U12.7 and the unit's synthesis, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

• Operating System Concepts — Chapter 16, Security, Sections 16.6–16.8 (the security's implementation, the auditing, and the assurance), and Chapter 17, Protection. The standard treatment of the security's implementation and the assurance's concerns.
• OSTEP — the Security chapters and the dialogue Summary. OSTEP's treatment of the security's operations and its discussion of the assurance's concerns is the clearest available account, and it is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapter 9, Security, and Chapter 10, Case Study 1: UNIX, Linux, and Android. A complementary treatment that develops the hardening's practices from first principles.
• Bauer, M. — Paranoid Penguin: A Step-by-Step Guide to Building a Secure Linux Server. No Starch Press, 2005. The comprehensive's hardening's reference for the Linux systems.
• Barrett, D., Silverman, R. E., & Byrnes, R. G. — Linux Security Cookbook. O'Reilly, 2003. The practical's hardening's recipes for the Linux systems.
• NIST SP 800-123 — Guide to General Server Security. The National Institute of Standards and Technology's guide to the server's hardening.
• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning. The NIST's guide to the patch's management.
• NIST SP 800-92 — Guide to Computer Security Log Management. The NIST's guide to the logs' management.
• NIST SP 800-137 — Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. The NIST's guide to the continuous's monitoring.
• The CIS Benchmarks — The Center for Internet Security's benchmarks for the operating systems (the Linux, the Windows, the macOS), the applications, and the cloud's platforms. The benchmarks are the hardening's standard's references.
• The DISA STIGs — The Defense Information Systems Agency's Security Technical Implementation Guides. The government's hardening's baselines, with the detailed's configuration's requirements.
• Bejtlich, R. — The Tao of Network Security Monitoring, 2nd ed. Addison-Wesley, 2013. The comprehensive's reference for the network's monitoring and the incident's detection.
• Sanders, C., & Smith, J. — Applied Network Security Monitoring. Syngress, 2014. The practical's guide to the NSM's operations.
• Linux man pages: man 8 sysctl, man 5 sysctl.conf, man 8 systemctl, man 5 systemd.unit, man 5 systemd.exec, man 1 ss, man 8 ufw, man 1 firewall-cmd, man 8 iptables, man 8 nft, man 8 auditctl, man 8 ausearch, man 8 aureport, man 5 auditd.conf, man 1 aide (if available), man 8 aideinit, man 1 tripwire (if available), man 1 rkhunter, man 1 lynis, man 8 oscap, man 1 apt (or man 8 dnf), man 8 unattended-upgrades, man 1 systemd-analyze, man 1 nmap, man 1 openvas (or man 1 nessus), man 1 trivy (if available), man 5 fail2ban, man 1 fail2ban-client, man 1 sudo, man 5 sudoers, man 8 sshd, man 5 sshd_config, man 8 usermod, man 1 chage, man 1 passwd, man 5 login.defs, man 1 cryptsetup, man 5 fstab, man 1 mount, man 8 mount, man 8 tune2fs, man 1 dmesg, man 1 journalctl, man 5 rsyslog.conf, man 8 logrotate, man 8 cron, man 5 crontab, man 8 systemd.timer, man 8 aa-status, man 8 getenforce, man 8 semanage.

04 Core content

4.1 What hardening is

The operating-system hardening is the discipline of configuring, monitoring, and maintaining a system so that its attack surface is the minimum, its defenses are the layered, and its compromises are the detected. The hardening's goals (the introduction's threefold):

• The attack's surface's reduction. The fewer the services, the ports, the accounts, the privileges, and the features, the fewer the attacker's entry's points and the fewer the exploitable's components.
• The defense's strengthening. The stronger the authentication, the authorization, the sandboxing, and the monitoring, the higher the attacker's cost and the smaller the compromise's damage.
• The compromise's detection. The more complete the logging, the better the monitoring, the faster the detection, and the smaller the compromise's duration.

The hardening's central's observation: the security is a process, not a product. The observation has three consequences:

• The hardening is not the configuration's checklist. The checklist (the CIS Benchmark, the STIG, the internal's baseline) is the starting's point, and the checklist's application is the beginning, not the end. The hardening requires the understanding of the system's role, the threats, and the compromises' impacts, and the configuration's choices must reflect the context.
• The hardening is not the one-time's activity. The threats evolve (the new's vulnerabilities, the new's attacks, the new's exploits), the workloads evolve (the new's applications, the new's users, the new's data), and the environments evolve (the new's networks, the new's regulations, the new's compliance's requirements). The hardening's configuration must be the reviewed and the adjusted as the environment changes, and the observation is the reason the hardening is the ongoing process.
• The hardening is not the perfect's security. The hardening reduces the risk (the attack's likelihood, the compromise's impact), but it does not eliminate the risk. The observation is the reason the hardening includes the detection and the response: the assumption is that the compromise will happen, and the design is the detection and the containment. The assume breach's posture (the zero-trust's principle) is the modern's security's standard.

4.2 The hardening's methodology and the security baselines

The hardening's methodology is the structured's approach to the system's security's configuration:

1. The system's inventory and the role's definition. The system's role (the web server, the database, the workstation, the container host), the system's assets (the data, the services, the credentials), and the system's users (the internal, the external, the privileged) are the inventory's and the role's definition's subjects. The inventory is the hardening's foundation: the system's role determines the services, the ports, and the privileges the system needs, and the role's clarity is the configuration's clarity's precondition.
2. The threat's model and the risk's assessment. The threats (the external's attackers, the internal's attackers, the malware, the supply chain, the insiders) and the risks (the impact's estimates: the data's loss, the service's disruption, the reputation's damage) are the threat's model's and the risk's assessment's subjects. The model and the assessment determine the hardening's priorities: the high-risk's components are the most hardened, and the low-risk's components are the acceptable's exposure.
3. The baseline's selection. The security's baseline is the configuration's template that the system's hardening is measured against. The baselines' sources: the CIS Benchmarks (the Center for Internet Security's consensus-based's configurations: the Level 1's for the general use, the Level 2's for the high-security's use), the NIST's guides (the NIST SP 800-53's controls, the NIST SP 800-123's server's guide, the NIST SP 800-171's CUI's guide), the DISA STIGs (the Defense Information Systems Agency's detailed's configurations for the government's systems), the vendor's guides (the Red Hat's, the Ubuntu's, the Microsoft's hardening's guides), and the organizational's baselines (the organization's tailored's configurations that reflect its specific's requirements).
4. The configuration's application. The baseline's configuration is the applied (the services, the ports, the accounts, the privileges, the kernel's parameters, the file systems, the monitoring), and the application is the automated where possible (the Ansible, the Puppet, the Chef, the SaltStack, the cloud-init) so the configuration is the consistent and the reproducible.
5. The configuration's assessment. The configuration is the assessed against the baseline (the oscap's OpenSCAP's scanning, the lynis's audit, the usg's Ubuntu Security Guide, the organization's scripts), and the gaps (the unmet's controls, the drifted's configurations) are the identified.
6. The gaps' remediation. The gaps are the remediated (the configuration's changes, the services' disabling, the patches' application, the accounts' review), and the remediation is the tracked (the tickets, the change's records, the exceptions' documentation).
7. The monitoring and the review. The configuration is the monitored (the file's integrity's monitoring, the auditd's events, the logs' analysis), and the configuration is the reviewed periodically (the baseline's updates, the new's vulnerabilities, the workload's changes, the compliance's requirements). The cycle repeats.

The baselines' comparison:

The baselines' design's observations:

• The baselines are the starting's points, not the ending's points. The baseline's application is the beginning; the system's specific's requirements (the workload, the threats, the compliance) may require the deviations (the exceptions, the additional's controls), and the deviations must be the documented and the reviewed.
• The baselines' levels. The baselines often have the multiple's levels (the CIS's Level 1 and Level 2, the NIST's low, moderate, and high), and the level's selection depends on the system's risk's profile: the higher's level is the more restrictive and the more disruptive, and the observation is the reason the level's selection is the risk's assessment's outcome.
• The baselines' automation. The baselines' application and the assessment are the automated (the oscap's OpenSCAP's profiles, the lynis's audits, the usg's Ubuntu Security Guide, the Ansible's roles), so the configuration is the consistent and the assessment is the repeatable. The automation's design is the hardening's scalability's mechanism.

4.3 The attack surface's reduction

The attack surface's reduction is the hardening's first's principle (the Lesson 12.1's attack surface's discussion). The system's attack surface is the set of the components that an attacker can interact with (the network's services, the local's interfaces, the users' interactions, the supply chain), and the reduction minimizes the components:

The services

The system's running services are the attacker's entry's points, and the hardening's first's step is the services' inventory and the unnecessary's services' disabling. The commands: the systemctl list-units --type=service --state=running (the running's services), the systemctl list-unit-files --state=enabled (the enabled's services), the systemctl disable <service> (the disabling), and the systemctl mask <service> (the preventing's of the service's start, even by the dependencies). The services' review's criteria: the system's role (the web server does not need the print's service), the necessity (the service's function), and the alternatives (the service's replacement with the more secure's mechanism).

The ports

The listening's ports are the network's attacker's entry's points, and the hardening's step is the ports' inventory and the unnecessary's ports' closing. The commands: the ss -tlnp (the TCP's listening's ports with the processes), the ss -tlnup (the TCP and the UDP's ports), the nmap's scan (the ports' scan from the external's perspective), and the firewall's rules (the ufw, the firewalld, the nftables). The ports' review's criteria: the necessity (the service's external's exposure), the binding (the service should bind to the specific's interfaces: the localhost for the management's services, the specific's network's interfaces for the services' functions), and the firewall's rules (the deny's default with the specific's allows).

The packages

The installed's packages are the components that the attacker can exploit (the vulnerabilities, the misconfigurations, the unnecessary's features), and the hardening's step is the packages' inventory and the unnecessary's packages' removal. The commands: the dpkg -l (the Debian's packages), the rpm -qa (the RPM's packages), the dnf history (the DNF's history), the apt autoremove (the unnecessary's dependencies' removal), and the apt purge <package> (the package's removal with the configuration). The packages' review's criteria: the necessity (the package's function), the alternatives (the package's replacement with the more secure's mechanism), and the vulnerabilities (the package's known's vulnerabilities and the patch's availability).

The kernel's modules

The kernel's modules are the kernel's extensions (the drivers, the file systems, the network's protocols), and the unnecessary's modules are the attack's surface's components (the modules' bugs are the kernel's bugs). The hardening's step is the modules' inventory and the unnecessary's modules' blacklisting. The mechanisms: the lsmod (the loaded's modules), the modprobe.d's configuration (the blacklist's directives), the kernel.modules_disabled=1's sysctl (the modules' loading's disabling: the one-way's switch, the systems that do not need the modules should set it after the boot), and the kernel's build's configuration (the unused's modules' exclusion). The observation: the modern's systems' kernels have the hundreds of the modules, and the unnecessary's modules' blacklisting reduces the attack's surface.

The accounts

The system's accounts are the attacker's entry's points (the unnecessary's accounts, the default's accounts, the weak's accounts), and the hardening's step is the accounts' inventory and the unnecessary's accounts' removal or locking. The commands: the cat /etc/passwd (the accounts), the awk -F: '$3 >= 1000 && $3 < 65534 {print $1}' /etc/passwd (the regular's users), the usermod -L <user> (the account's locking), the userdel -r <user> (the account's removal with the home), and the chage -l <user> (the account's aging's information). The accounts' review's criteria: the necessity (the account's function), the privileges (the account's group's memberships and the sudo's rules), the aging (the password's aging's policy), and the inactivity (the unused's accounts' disabling).

The attack surface's reduction's observations:

• The reduction's tension with the functionality. The services' disabling, the packages' removal, and the accounts' locking reduce the functionality (the users' convenience, the features' availability), and the reduction's design must balance the two: the reduction should not break the system's legitimate's functions, and the observation is the reason the reduction is the iterative process (the inventory, the assessment, the disabling, the testing, the adjustment).
• The reduction's automation. The reduction is the automated where possible (the Ansible's playbooks, the Puppet's manifests, the cloud-init's configurations, the golden's images), so the configuration is the consistent across the fleet and the drift is the detected.
• The reduction's documentation. The reduction's decisions (the services' disabled, the packages' removed, the accounts' locked) must be the documented, so the system's function is the understood and the changes are the reviewed. The documentation is the hardening's auditability's foundation.

4.4 The identity's and the authentication's hardening

The identity's and the authentication's hardening strengthens the system's identity's model and its authentication's mechanisms:

• The account's hardening. The accounts' review (the unnecessary's accounts' removal, the default's accounts' locking, the service's accounts' creation with the nologin's shells), the accounts' aging (the chage's policies: the password's minimum and maximum ages, the warning's period, the inactivity's period), the accounts' privilege's review (the group's memberships, the sudo's rules, the capabilities), and the accounts' auditing (the last and the lastlog's reports, the /etc/shadow's review).
• The password's hardening. The strong's passwords (the length over the complexity, the passphrase, the password's managers: the Lesson 12.2's guidance), the password's policies (the pam_pwquality's rules: the minimum's length, the character's classes, the dictionary's check), the password's aging (the chage's policies), the password's storage (the strong's KDFs: the yescrypt's default in the modern's Linux, the bcrypt's, the Argon2id's), and the password's breach's checking (the pam_pwquality's dictcheck and the usercheck directives).
• The SSH's hardening. The key-based's authentication (the PasswordAuthentication no, the PubkeyAuthentication yes, the AuthorizedKeysFile's configuration, the keys' algorithms: the ed25519's, the RSA's 4096 bits, the keys' passphrases), the root's login's disabling (the PermitRootLogin no), the non-standard's port (the Port 2222's change: the security's through the obscurity's limited's benefit), the users' restriction (the AllowUsers's and the AllowGroups's directives), the protocols' restriction (the Protocol 2's only), the ciphers' and the MACs' restriction (the Ciphers's and the MACs's directives with the strong's algorithms only), the sessions' timeout (the ClientAliveInterval's and the ClientAliveCountMax's directives), the X11's forwarding's disabling (the X11Forwarding no), and the verbose's logging (the LogLevel VERBOSE).
• The multi-factor's authentication. The MFA's deployment (the TOTP: the pam_google_authenticator's module, the FIDO2: the U2F's keys, the smart cards: the PIV's), and the MFA's enforcement for the privileged's accesses (the SSH's logins, the sudo's commands, the administrative's interfaces).
• The sudo's hardening. The sudoers's rules' design (the specific's commands, the per-user's and the per-host's specifications), the NOPASSWD's avoidance (the password's requirement for the sensitive's operations), the Defaults's directives (the requiretty's setting, the env_reset, the secure_path, the logfile's and the log_input's settings), the sudo's logging (the /var/log/auth.log's and the journalctl's events), and the sudo's version's updates.
• The PAM's hardening. The PAM's stack's review (the /etc/pam.d/'s files), the pam_faillock's lockout (the failed's attempts' policy: the deny=5, the unlock_time=900), the pam_limits's resource's limits, the pam_unix's options (the sha512's or the yescrypt's hashing, the nullok's absence), and the pam_exec's and the pam_script's additional's controls.

The identity's and the authentication's hardening's observations:

• The hardening's balance. The identity's and the authentication's hardening has the usability's tension (the strong's passwords, the frequent's re-authentications, the MFA's additional's steps), and the observation is the psychological acceptability's principle (Lesson 12.1's principle 8): the mechanism must be the usable, or the users will find the ways around it.
• The hardening's verification. The identity's and the authentication's hardening's state is the verified (the pam_faillock's faillock's command, the chage -l's reports, the passwd -S's status, the SSH's configuration's review), and the verification is the hardening's assessment's component.

4.5 The kernel's hardening

The kernel's hardening strengthens the kernel's security's mechanisms and reduces the kernel's attack surface:

• The sysctl's parameters. The kernel's runtime's security's parameters (the Lesson 12.5's section 4.13's discussion): the network's parameters (the net.ipv4.tcp_syncookies=1, the net.ipv4.conf.all.rp_filter=1, the net.ipv4.conf.all.accept_redirects=0, the net.ipv4.conf.all.accept_source_route=0, the net.ipv4.conf.all.log_martians=1, the net.ipv4.icmp_echo_ignore_broadcasts=1), the kernel's parameters (the kernel.randomize_va_space=2, the kernel.dmesg_restrict=1, the kernel.kptr_restrict=2, the kernel.yama.ptrace_scope=1, the kernel.sysrq=0, the kernel.kexec_load_disabled=1), the file system's parameters (the fs.protected_hardlinks=1, the fs.protected_symlinks=1, the fs.suid_dumpable=0, the fs.protected_fifos=2, the fs.protected_regular=2), and the virtual memory's parameters (the vm.mmap_min_addr=65536).
• The ASLR's enforcement. The kernel.randomize_va_space=2 (the full's randomization: the stack, the heap, the libraries, the mmap's regions), and the observation is the ASLR's effectiveness's requirement: the randomization's entropy's reduction (the container's or the VM's constraints) can weaken the ASLR, and the observation is the reason the modern's systems verify the ASLR's state.
• The kernel's modules' signing. The CONFIG_MODULE_SIG_FORCE=yes's kernel's configuration (the modules' signing's enforcement), the kernel.modules_disabled=1's sysctl (the modules' loading's disabling after the boot), and the observation: the kernel's modules are the kernel's code, and the malicious's module is the full's kernel's compromise. The signing's enforcement and the loading's disabling are the kernel's integrity's mechanisms.
• The kernel's lockdown. The lockdown=confidentiality's or the lockdown=integrity's kernel's command-line's parameter (the kernel's lockdown: the restrictions on the privileged's operations: the /dev/mem's access, the kexec's loading, the iomem's reading, the unsigned's modules' loading), and the observation: the lockdown is the UEFI's Secure Boot's complement (the boot's chain's integrity), and it is the modern's systems' mechanism for the kernel's integrity's enforcement.
• The boot's chain's integrity. The UEFI's Secure Boot (the boot's chain's signature's verification: the firmware, the boot loader, the kernel), the measured's boot (the TPM's measurements: the PCR's values), the IMA (the Integrity Measurement Architecture: the files' measurements, the appraisal, the audit), and the observation: the boot's chain's integrity is the kernel's integrity's foundation, and the modern's systems' designs include the mechanisms.

4.6 The file systems' hardening

The file systems' hardening strengthens the file systems' security's mechanisms and reduces the file systems' attack surface:

• The permissions' review. The world-writable's files' search (the find / -type f -perm -o+w), the setuid's and the setgid's programs' review (the find / -perm -4000 -type f, the find / -perm -2000 -type f), the unowned's files' search (the find / -nouser -o -nogroup), the /tmp's and the /var/tmp's permissions (the sticky's bit's presence), the home's directories' permissions (the 700's or the 750's modes), the /etc/shadow's permissions (the 640's or the 000's modes with the root's ownership), and the sensitive's files' review (the SSH's keys: the 600's mode; the /etc/sudoers: the 440's mode; the /etc/crontab: the 644's mode with the root's ownership).
• The mount's options. The /etc/fstab's mount's options for the security's partitions: the nodev (the device's files' ignoring), the nosuid (the setuid's bits' ignoring), the noexec (the binaries' execution's prevention) for the /tmp, the /var/tmp, the /home, and the /dev/shm; the ro (the read-only's mount) for the /usr and the /boot; the nodev,nosuid for the /boot; and the observation: the mount's options are the per-file-system's restrictions, and they are the layered's defenses (the mode's bits' restrictions are the complements).
• The disk's encryption. The full's disk's encryption (the LUKS: the cryptsetup luksFormat's initialization, the cryptsetup luksOpen's opening, the /etc/crypttab's configuration), the encryption's algorithms (the AES's with the XTS's mode, the aes-xts-plain64), the key's derivation (the Argon2id's or the PBKDF2's), the encrypted's swap (the swap's encryption or the disabling), and the observation: the full's disk's encryption protects the data at rest (the device's theft, the improper's disposal, the physical's access), and it is the modern's systems' standard for the laptops and the portable's devices.
• The file's attributes. The chattr +i's immutable's attribute for the critical's files (the /etc/passwd's, the /etc/shadow's, the /etc/sudoers's, the /etc/ssh/sshd_config's protection), the chattr +a's append-only's attribute for the logs (the /var/log/audit/audit.log's protection), and the observation: the attributes are the additional's protections beyond the mode's bits, and they are the critical's files' defense's depth.
• The files' ACLs. The ACLs' design for the shared's directories (the projects' directories with the default's ACLs), the ACLs' review (the getfacl -R's recursive's listing, the find / -type f -acl's search for the files with the ACLs), and the observation: the ACLs are the finer's granularity's mechanism, and their design must be the documented and the reviewed (the ACLs' sprawl is the management's concern).

4.7 The network's hardening

The network's hardening reduces the system's network's attack surface and strengthens the network's defenses:

• The firewall's rules. The firewall's design (the ufw's simplification, the firewalld's zones, the nftables's rules, the iptables's legacy), the default's policy (the deny's incoming, the allow's outgoing), the specific's allows (the SSH's port, the HTTP's and the HTTPS's ports, the database's port from the application's server only), and the observation: the firewall's default's deny is the Lesson 12.1's fail-safe defaults' principle's application, and the specific's allows are the least privilege's principle's application.
• The network's segmentation. The system's network's placement (the DMZ's public's services, the internal's network's private's services, the management's network's administrative's interfaces), the VLANs' or the subnets' separation, the host's firewall's rules' per-interface's configuration, and the observation: the segmentation is the attacker's lateral's movement's limitation's mechanism, and it is the network's defence's depth's principle's application.
• The services' binding. The services' binding's configuration (the services should bind to the specific's interfaces: the localhost for the management's services, the specific's network's interfaces for the services' functions), the services' bind's directives (the database's bind-address = 127.0.0.1's setting, the web's server's Listen 443's configuration), and the observation: the binding's restriction is the services' exposure's reduction, and the observation is the reason the services' binding is the attack surface's reduction's component.
• The TLS's configuration. The TLS's versions (the TLS 1.2's and the TLS 1.3's only, the SSLv3's and the TLS 1.0's and the TLS 1.1's disabling), the ciphers' suites (the strong's suites only, the forward's secrecy's suites: the ECDHE's), the certificates' management (the valid's certificates, the renewal's automation: the Let's Encrypt's certbot, the acme.sh), the HSTS's deployment (the Strict-Transport-Security's header), and the observation: the TLS's configuration is the network's traffic's confidentiality's and the integrity's mechanism, and its strength depends on the versions and the ciphers.
• The fail2ban's intrusion's prevention. The fail2ban's configuration (the jail.local's jails: the SSH's, the web's, the database's), the bans' rules (the failed's attempts' threshold, the ban's duration), the actions (the firewall's rules' addition, the notification's email), and the observation: the fail2ban is the brute force's prevention's mechanism, and it is the authentication's hardening's complement.

4.8 The logging, monitoring, and detection

The logging, the monitoring, and the detection are the hardening's detection's component (the introduction's third goal). The mechanisms:

The auditd (the kernel's audit's framework)

The Linux's audit's subsystem (the Lesson 12.5's section 4.11's discussion): the kernel's audit's framework generates the security-relevant's events, the auditd's daemon writes them to the /var/log/audit/audit.log, and the tools (ausearch, the aureport) query and report the events. The audit's rules (the /etc/audit/rules.d/'s files): the file's watches (the -w /etc/passwd -p wa -k passwd_changes), the system calls (the -a always,exit -F arch=b64 -S execve -k exec), the authentication's events (the -w /var/log/faillock -p wa -k logins), and the privilege's escalations (the -w /etc/sudoers -p wa -k sudoers_changes).

The file's integrity's monitoring (the FIM)

The file's integrity's monitoring's tools (the AIDE, the Tripwire, the Samhain, the OSSEC's FIM) compute the baseline's database of the files' hashes, the metadata, and the permissions, and the periodic's scans detect the changes. The tools' purpose: the compromise's detection's (the modified's system's binaries, the added's backdoors, the changed's configurations) and the unauthorized's changes' detection (the accidental's mistakes, the malicious's modifications). The observation: the FIM is the compromise's detection's central's mechanism, and its design's subtleties (the baseline's creation, the exclusions's configuration, the scans' schedule, the changes' review) determine its effectiveness.

The HIDS (the host's intrusion's detection's systems)

The HIDS's tools (the OSSEC, the Wazuh, the Samhain, the Tripwire's HIDS, the Suricata's HIDS's mode) monitor the host's events (the logs, the file's changes, the processes, the network's connections, the registry's changes) and detect the suspicious's activities (the brute force's attempts, the privilege's escalations, the malware's indicators, the anomalous's behaviors). The HIDS's design's components: the agents (the host's monitoring's daemons), the managers (the central's analysis's servers), the rules (the detection's logic), and the alerts (the notifications). The observation: the HIDS is the host's monitoring's central's mechanism, and its rules' maintenance (the updates, the tuning) determines its effectiveness.

The SIEM (the security's information's and the event's management)

The SIEM's platforms (the Splunk, the ELK's stack, the Graylog, the Wazuh, the Sumo Logic, the ArcSight) aggregate the logs from the multiple's sources (the systems, the applications, the network's devices, the security's tools), the correlate the events (the multiple's sources' events' association), the analyze the data (the pattern's detection, the anomaly's detection, the threat's intelligence's matching), and the present the results (the dashboards, the alerts, the reports). The observation: the SIEM is the enterprise's monitoring's central's platform, and its design's components (the log's ingestion, the normalization, the correlation's rules, the alerting's workflows) determine its effectiveness.

The logs' management

The logs' management's mechanisms: the logging's levels (the debug, the info, the warning, the error, the critical), the logs' rotation (the logrotate's configuration, the systemd-journald's settings), the logs' retention (the retention's policies: the legal's requirements, the forensics's needs, the storage's capacity), the logs' protection (the permissions, the attributes, the encryption), the logs' remote's delivery (the rsyslog's configuration, the journald's upload, the syslog-ng's destinations), and the logs' integrity (the cryptographic's signing, the append-only's attribute). The observation: the logs are the security's evidence, and their management determines the detection's and the forensics's effectiveness.

The logging's, the monitoring's, and the detection's observations:

• The detection's role in the hardening's process. The detection is the hardening's assume breach's component: the assumption is that the compromise will happen, and the detection's design is the fast's identification and the containment. The observation is the reason the detection's mechanisms are the hardening's equal's components (the prevention's mechanisms): the prevention reduces the likelihood, and the detection reduces the impact.
• The monitoring's coverage. The monitoring's coverage determines the detection's effectiveness: the events' coverage (the authentication, the authorization, the file's accesses, the network's connections, the privilege's escalations), the sources' coverage (the systems, the applications, the network, the security's tools), and the times' coverage (the real-time's monitoring, the periodic's scans, the historical's analysis). The coverage's design is the risk's assessment's outcome.
• The alerts' quality. The alerts' quality determines the response's effectiveness: the alerts' precision (the false positives' rate), the alerts' recall (the false negatives' rate), the alerts' context (the relevant's information: the source, the target, the event's details), and the alerts' routing (the appropriate's team, the appropriate's priority). The alerts' quality is the monitoring's design's central's concern, and the observation is the reason the SIEM's and the HIDS's tuning is the ongoing's activity.

4.9 The patch management and the vulnerability scanning

The patch management and the vulnerability scanning are the hardening's maintenance's component:

• The patch management. The patches' lifecycle: the patch's availability's monitoring (the vendors' advisories, the CVE's databases, the NVD's feeds, the distributions' security's announcements), the patch's evaluation (the severity's assessment, the applicability, the impact), the patch's testing (the non-production's environments, the staging's systems), the patch's deployment (the production's systems, the maintenance's windows, the rollback's plans), and the patch's verification (the versions' checks, the functionality's tests). The tools: the apt's and the unattended-upgrades's (the Debian's and the Ubuntu's), the dnf's and the dnf-automatic's (the Fedora's and the RHEL's), the zypper's (the openSUSE's), the yum-cron's (the older's), and the configuration's management's tools (the Ansible's, the Puppet's, the Chef's).
• The vulnerability scanning. The scanners: the network's scanners (the Nessus, the OpenVAS, the Qualys, the Rapid7's Nexpose), the host's scanners (the Lynis, the OpenSCAP's oscap, the lynis audit system), the container's scanners (the Trivy, the Clair, the Anchore, the Snyk), the application's scanners (the SAST's, the DAST's, the SCA's), and the cloud's scanners (the AWS's Inspector, the Azure's Defender, the GCP's Security Command Center). The scanners' outputs: the vulnerability's list (the CVE's identifiers, the CVSS's scores, the affected's components), the prioritization (the critical's and the high-severity's findings' first), and the remediation's tracking (the tickets, the exceptions, the verification).
• The patch's cadence. The patch's cadence's design: the critical's patches' immediate's application (the actively's exploited's vulnerabilities, the zero-days), the high-severity's patches' rapid's application (the days to the weeks), the moderate's and the low-severity's patches' regular's application (the monthly's cycles), and the exceptions' management (the systems that cannot be patched: the legacy's applications, the embedded's devices, the vendor's constraints). The cadence's design is the risk's assessment's outcome, and the observation is the reason the patch's and the vulnerability's management is the ongoing's activity.

4.10 The compliance and the auditing

The compliance and the auditing are the hardening's verification's component: the frameworks, the standards, and the audits that verify the system's security's state:

• The frameworks and the standards. The NIST Cybersecurity Framework (the five functions: the identify, the protect, the detect, the respond, the recover), the ISO/IEC 27001 (the information's security's management's systems), the CIS Controls (the eighteen's controls: the inventory, the configuration, the access, the vulnerabilities, the monitoring), the PCI-DSS (the payment's card's industry's standard: the twelve's requirements), the HIPAA (the health's information's protection), the GDPR (the European's data's protection), the SOC 2 (the service's organizations' controls), and the FISMA (the federal's information's security's management). The frameworks and the standards provide the controls' catalogues and the auditing's requirements.
• The audits. The audits' types: the internal's audits (the organization's security's team), the external's audits (the third-party's auditors), the compliance's audits (the regulators' inspections), the certification's audits (the ISO 27001's, the SOC 2's), and the penetration's tests (the ethical's hackers' simulated's attacks). The audits' outputs: the findings (the controls' gaps, the vulnerabilities, the misconfigurations), the ratings (the severity's levels, the risk's scores), the remediation's plans (the actions, the owners, the deadlines), and the attestations (the compliance's reports, the certifications).
• The compliance's automation. The compliance's automation's tools: the OpenSCAP (the SCAP's profiles, the automated's assessments), the Lynis (the audit's tool with the recommendations), the InSpec (the Chef's compliance's framework), the Cloud's compliance's tools (the AWS's Config, the Azure's Policy, the GCP's Security Command Center), and the continuous's compliance's platforms (the Vanta, the Drata, the Secureframe). The automation's design is the compliance's scalability's and the consistency's mechanism.

4.11 The security operations (SecOps)

The security operations (the SecOps) is the security's operations's discipline: the ongoing's monitoring, the incident's response, the threat's hunting, and the security's engineering. The SecOps's components:

• The monitoring. The continuous's monitoring (the SIEM's alerts, the HIDS's events, the network's monitoring's data), the triage (the alerts' prioritization, the false positives' filtering), the investigation (the events' correlation, the incident's assessment), and the escalation (the incidents' routing to the response's team).
• The incident's response. The incident's response's lifecycle (the NIST SP 800-61's framework): the preparation (the plans, the playbooks, the tools, the training), the detection and the analysis (the monitoring's and the triage's outputs), the containment (the affected's systems' isolation, the compromise's spread's prevention), the eradication (the threat's removal, the vulnerabilities' remediation), the recovery (the systems' restoration, the services' resumption, the monitoring's enhancement), and the lessons's learned (the post-incident's review, the improvements).
• The threat's hunting. The proactive's search for the threats within the environment (the hypothesis-driven's investigations, the anomalies' analysis, the threat's intelligence's application), the observation: the threat's hunting is the assume breach's posture's proactive's component, and it is the detection's mechanisms' complement.
• The security's engineering. The security's mechanisms' design and the deployment (the authentication's mechanisms, the authorization's models, the sandboxing's configurations, the monitoring's tools), the security's architecture (the zero-trust's designs, the defence in depth, the least privilege), the security's automation (the infrastructure's as the code, the policy's as the code, the detection's as the code), and the security's research (the new's threats, the new's mechanisms, the new's practices).

The SecOps's design's observations:

• The SecOps's integration with the DevOps. The modern's practice (the DevSecOps) integrates the security into the DevOps's lifecycle: the security's requirements in the planning, the security's tests in the development (the SAST, the DAST, the SCA), the security's configurations in the deployment (the infrastructure's as the code, the policy's as the code), and the security's monitoring in the operations (the SIEM's integration, the feedback's loops). The observation is the reason the DevSecOps is the modern's software's development's standard.
• The SecOps's metrics. The SecOps's metrics: the mean time to detect (the MTTD), the mean time to respond (the MTTR), the mean time to remediate (the MTTR's alternative), the vulnerabilities' backlog's size and the aging, the incidents' count and the severity, the patch's compliance's rate, and the alerts' quality (the false positives' rate). The metrics' design is the SecOps's performance's management's foundation.
• The SecOps's maturity. The SecOps's maturity's models: the CMMC's (the Cybersecurity Maturity Model Certification), the C2M2's (the Cybersecurity Capability Maturity Model), the SOC-CMM's, and the NIST's CSF's implementation's tiers. The maturity's assessment is the SecOps's improvement's roadmap's foundation, and the observation is the reason the maturity's models are the modern's security's organizations' frameworks.

4.12 The hardening's design principles

The hardening's design applies the Lesson 12.1's principles, and the specific's applications:

• The least privilege (the principle 6). The users, the services, and the processes have the minimum's privileges: the service's accounts, the capability's minimization, the sudo's rules, the container's dropped's capabilities, the systemd's directives.
• The fail-safe defaults (the principle 2). The defaults are the secure's: the firewall's deny's default, the services' disabled's default, the permissions' restrictive's default, the SELinux's enforcing's default, the systemd's hardening's directives' defaults.
• The complete mediation (the principle 3). The every access is the mediated: the kernel's reference monitor, the LSM's hooks, the auditd's rules, the FIM's monitoring, the network's firewall.
• The economy of mechanism (the principle 1). The mechanisms are the simple and the small: the minimal's services, the minimal's packages, the minimal's kernel's modules, the minimal's PAM's stack, the minimal's sudoers's rules.
• The separation of privilege (the principle 5). The critical's operations require the multiple's conditions: the MFA for the privileged's accesses, the separation of duties for the sensitive's changes, the multiple's approvals for the critical's operations.
• The least common mechanism (the principle 7). The shared's resources are the minimized: the per-user's home's directories, the per-service's accounts, the per-container's namespaces, the per-VM's isolation.
• The psychological acceptability (the principle 8). The mechanisms are the usable: the sensible's defaults, the understandable's configurations, the reasonable's trade-offs, the escape's hatches for the legitimate's needs.
• The open design (the principle 4). The mechanisms are the public and the auditable: the open-source's implementations, the standard's interfaces, the reviewable's configurations, the documented's decisions.

4.13 Common misconceptions

05 Worked example

The following example performs a hardening's assessment of a Linux server, applies the hardening's controls, and evaluates the improvement with the automated's tools.

# The system's information
uname -a
cat /etc/os-release | head -5
hostnamectl

# The running's services
systemctl list-units --type=service --state=running

# The listening's ports
ss -tlnp
sudo ss -tlnup

# The users' accounts
cat /etc/passwd | grep -vE 'nologin|false'
sudo awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3}' /etc/passwd
sudo chage -l $(whoami)

# The setuid and the setgid's programs
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

# The world-writable's files
find / -type f -perm -o+w 2>/dev/null

# The firewall's rules
sudo ufw status 2>/dev/null
sudo firewall-cmd --list-all 2>/dev/null
sudo nft list ruleset 2>/dev/null | head -20

# The SSH's configuration
sudo grep -E 'PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|Port|AllowUsers' /etc/ssh/sshd_config

# The kernel's parameters
sysctl -a 2>/dev/null | grep -E 'net.ipv4.tcp_syncookies|net.ipv4.conf.all.rp_filter|kernel.randomize_va_space|kernel.dmesg_restrict|kernel.kptr_restrict|fs.protected_hardlinks|fs.protected_symlinks'

# The SELinux's or the AppArmor's status
getenforce 2>/dev/null
sudo aa-status 2>/dev/null | head -10

# The audit's subsystem
sudo auditctl -s 2>/dev/null

# The cgroups' state
systemd-cgls 2>/dev/null | head -20

# The services' disabling
sudo systemctl stop cups avahi-daemon rpcbind 2>/dev/null
sudo systemctl disable cups avahi-daemon rpcbind 2>/dev/null
sudo systemctl mask cups avahi-daemon rpcbind 2>/dev/null

# The firewall's configuration
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

# The SSH's hardening
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^#*X11Forwarding.*/X11Forwarding no/' /etc/ssh/sshd_config
sudo sshd -t  # the configuration's syntax's check
sudo systemctl restart sshd

# The kernel's parameters
sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
# The network's hardening
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
# The kernel's hardening
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 1
# The file system's hardening
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0
fs.protected_fifos = 2
fs.protected_regular = 2
# The virtual memory's hardening
vm.mmap_min_addr = 65536
EOF
sudo sysctl --system

# The accounts' hardening
sudo usermod -L games 2>/dev/null
sudo chage -M 90 -m 1 -W 7 -I 30 $(whoami)
sudo passwd -S $(whoami)

# The auditd's rules
sudo tee /etc/audit/rules.d/99-hardening.rules << 'EOF'
# The identity's files
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes
# The SSH's configuration
-w /etc/ssh/sshd_config -p wa -k sshd_config_changes
# The privileged's operations
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
# The kernel's modules
-w /sbin/insmod -p x -k module_load
-w /sbin/rmmod -p x -k module_unload
-w /sbin/modprobe -p x -k module_load
EOF
sudo augenrules --load 2>/dev/null
sudo auditctl -l | head -20

# The SELinux's enforcing's mode
sudo setenforce 1 2>/dev/null
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config 2>/dev/null
getenforce

# The fail2ban's installation
sudo apt install -y fail2ban 2>/dev/null
sudo systemctl enable --now fail2ban 2>/dev/null
sudo fail2ban-client status 2>/dev/null

# The automatic's updates
sudo apt install -y unattended-upgrades 2>/dev/null
sudo dpkg-reconfigure --priority=low unattended-upgrades 2>/dev/null

# The services' verification
systemctl list-units --type=service --state=running

# The ports' verification
ss -tlnp

# The firewall's verification
sudo ufw status verbose

# The SSH's verification
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|x11forwarding'

# The kernel's parameters' verification
sysctl -a 2>/dev/null | grep -E 'net.ipv4.tcp_syncookies|kernel.dmesg_restrict|kernel.kptr_restrict|fs.protected_hardlinks'

# The auditd's verification
sudo auditctl -l | wc -l
sudo auditctl -s

# The SELinux's verification
getenforce

# The fail2ban's verification
sudo fail2ban-client status sshd 2>/dev/null

# The automated's hardening's assessment
sudo apt install -y lynis 2>/dev/null
sudo lynis audit system 2>/dev/null | tail -40

# The Ansible's playbook (the hardening.yml):
---
- name: The Linux server's hardening
  hosts: all
  become: yes
  tasks:
    - name: The unnecessary's services' disabling
      systemd:
        name: "{{ item }}"
        state: stopped
        enabled: no
        masked: yes
      loop:
        - cups
        - avahi-daemon
        - rpcbind

    - name: The firewall's configuration (the ufw)
      ufw:
        state: enabled
        policy: deny
        direction: incoming
      # The specific's allows are the separate's tasks.

    - name: The SSH's hardening
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "{{ item.regexp }}"
        line: "{{ item.line }}"
      loop:
        - { regexp: '^#*PermitRootLogin', line: 'PermitRootLogin no' }
        - { regexp: '^#*PasswordAuthentication', line: 'PasswordAuthentication no' }
        - { regexp: '^#*PubkeyAuthentication', line: 'PubkeyAuthentication yes' }
      notify: restart sshd

    - name: The kernel's parameters
      sysctl:
        name: "{{ item.name }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop:
        - { name: 'kernel.randomize_va_space', value: '2' }
        - { name: 'kernel.dmesg_restrict', value: '1' }
        - { name: 'kernel.kptr_restrict', value: '2' }
        - { name: 'net.ipv4.tcp_syncookies', value: '1' }

    - name: The auditd's rules
      copy:
        src: files/99-hardening.rules
        dest: /etc/audit/rules.d/99-hardening.rules
      notify: reload auditd

  handlers:
    - name: restart sshd
      systemd:
        name: sshd
        state: restarted
    - name: reload auditd
      command: augenrules --load

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• The operating-system hardening is the discipline of configuring, monitoring, and maintaining a system so that its attack surface is the minimum, its defenses are the layered, and its compromises are the detected. Its goals: the attack's surface's reduction, the defense's strengthening, and the compromise's detection. Its central's observations: the security is a process, not a product; the hardening is the ongoing's activity; and the hardening is the risk's reduction, not the security's perfection (the assume breach's posture).
• The hardening's methodology: the inventory and the role's definition, the threat's model and the risk's assessment, the baseline's selection, the configuration's application, the configuration's assessment, the gaps' remediation, and the monitoring and the review. The security baselines: the CIS Benchmarks, the NIST's guides, the DISA STIGs, the vendor's guides, and the organizational's baselines.
• The attack surface's reduction covers the services, the ports, the packages, the kernel's modules, and the accounts. The reduction's criteria: the necessity, the alternatives, the vulnerabilities, the privileges, and the binding. The reduction's tension with the functionality, the automation, and the documentation.
• The identity's and the authentication's hardening covers the accounts, the passwords, the SSH, the MFA, the sudo, and the PAM. The kernel's hardening covers the sysctl's parameters, the ASLR, the kernel's modules' signing, the kernel's lockdown, and the boot's chain's integrity. The file systems' hardening covers the permissions, the mount's options, the disk's encryption, the file's attributes, and the ACLs. The network's hardening covers the firewall's rules, the segmentation, the services' binding, the TLS's configuration, and the fail2ban.
• The logging, the monitoring, and the detection cover the auditd, the file's integrity's monitoring, the HIDS, the SIEM, and the logs' management. The patch management and the vulnerability scanning cover the patch's lifecycle, the patch's cadence, the vulnerability's scanning, and the remediation's tracking. The compliance and the auditing cover the frameworks and the standards (the NIST's CSF, the ISO 27001, the CIS Controls, the PCI-DSS, the HIPAA, the GDPR, the SOC 2, the FISMA), the audits, and the compliance's automation.
• The security operations (SecOps) is the security's operations's discipline: the monitoring, the incident's response (the NIST SP 800-61's lifecycle), the threat's hunting, and the security's engineering. The SecOps's integration with the DevOps (the DevSecOps) is the modern's software's development's standard, and the metrics (the MTTD, the MTTR, the vulnerabilities' backlog) are the performance's management's foundation.
• The hardening's design principles apply the Lesson 12.1's principles: the least privilege, the fail-safe defaults, the complete mediation, the economy of mechanism, the separation of privilege, the least common mechanism, the psychological acceptability, and the open design.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapters 16 and 17.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Security chapters and the Summary dialogue. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapters 9 and 10.
• Bauer, M. Paranoid Penguin: A Step-by-Step Guide to Building a Secure Linux Server. No Starch Press, 2005.
• Barrett, D., Silverman, R. E., & Byrnes, R. G. Linux Security Cookbook. O'Reilly, 2003.
• NIST SP 800-123. Guide to General Server Security. National Institute of Standards and Technology.
• NIST SP 800-40 Rev. 4. Guide to Enterprise Patch Management Planning. National Institute of Standards and Technology.
• NIST SP 800-92. Guide to Computer Security Log Management. National Institute of Standards and Technology.
• NIST SP 800-137. Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. National Institute of Standards and Technology.
• NIST SP 800-61 Rev. 2. Computer Security Incident Handling Guide. National Institute of Standards and Technology.
• The CIS Benchmarks. Center for Internet Security.
• The DISA STIGs. Defense Information Systems Agency.
• Bejtlich, R. The Tao of Network Security Monitoring, 2nd ed. Addison-Wesley, 2013.
• Sanders, C., & Smith, J. Applied Network Security Monitoring. Syngress, 2014.
• Linux man-pages: man 8 sysctl, man 5 sysctl.conf, man 8 systemctl, man 5 systemd.exec, man 1 ss, man 8 ufw, man 8 auditctl, man 8 ausearch, man 8 aureport, man 5 auditd.conf, man 1 systemd-analyze, man 8 sshd, man 5 sshd_config, man 5 sudoers, man 1 lynis, man 8 oscap, man 1 nmap, man 5 fail2ban, man 1 fail2ban-client.