Mastering the 8 domains of cybersecurity: the definitive CISSP guide

Introduction: the systems engineering perspective on CISSP#

For systems engineers, SREs, and infrastructure architects, cybersecurity is often translated as configuring a firewall, rotating cryptographic keys, or tuning IAM permissions. However, robust enterprise-grade security requires a holistic approach. The CISSP (Certified Information Systems Security Professional) certification, structured by (ISC)², defines this vision through 8 domains that cover everything from high-level risk governance to the minute implementation of cryptography within the secure software development lifecycle (Secure SDLC).

This guide aims to connect the foundational theoretical concepts of CISSP with the day-to-day operational practices of a senior systems administrator, demonstrating real-world applications of commands, modeling, and forensic playbooks.

Operational mapping of the domains#

Below is a summary of the engineering focus and operational vectors for each of the CISSP domains:

1. Security and risk management#

Security governance provides the legal and operational framework for business decision-making. In practical systems engineering, we convert abstract risk concepts into objective controls and active modeling.

The 8 classic principles of cybersecurity#

Governance and security engineering must be guided by solid architectural principles to ensure systems integrity:

1. Least Privilege: Restricting subject access rights to the absolute minimum necessary to perform their duties (e.g., in Linux, avoiding running services as root unless strictly required).
2. Separation of Duties: Splitting sensitive tasks among multiple roles or systems to mitigate the risk of fraud or malicious alterations.
3. Defense in Depth: Implementing multiple security controls in independent layers (e.g., using WAF at the edge, IPS/IDS on the host, encryption at the database, and centralized logs).
4. Security by Design: Ensuring security is a core requirement from the system's design and network architecture phase, rather than bolted on post-implementation.
5. Economy of Mechanism: Designing security controls to be as simple and small as possible. Complex mechanisms increase the attack surface and hinder auditing.
6. Open Design: The principle that a system's security must not rely on the secrecy of its architecture or algorithms (Kerckhoffs's Principle). Control strength must reside purely in the cryptographic key.
7. Least Common Mechanism: Avoiding unnecessary sharing of common paths and resources among multiple users to prevent side-channel exploits and data leakage.
8. Complete Mediation: Enforcing that every access attempt to a resource is intercepted, authenticated, and authorized against active access policies, without shortcuts or cache bypasses (a fundamental pillar of Zero Trust).

The operational risk management lifecycle#

Active threat mitigation and infrastructure hardening follow a continuous, systematic lifecycle consisting of 4 core phases:

1. Identify Threats and Vulnerabilities: The first phase centers on discovering, cataloging, and understanding potential risks threatening system confidentiality, integrity, or availability. In practice, this entails:

• Asset Management: Systematically cataloging servers, endpoints, APIs, containers, credentials, and sensitive data flows.
• Vulnerability Scanning: Periodically running automated tools such as Nessus, OpenVAS, and Trivy to uncover outdated dependencies or software misconfigurations.
• Threat Intelligence Tracking: Integrating real-time feeds to flag emerging 0-day vulnerabilities affecting the operational technology stack.

1. Assess and Prioritize Risks: Once vulnerabilities are listed, their severity and business impacts are analyzed both qualitatively and quantitatively.

• CVSS (Common Vulnerability Scoring System): Leveraging base, temporal, and environmental metric scores to target critical issues first (focusing on scores $\ge 9.0$).
• Financial Impact Calculation: Applying SLE (Single Loss Expectancy) and ALE (Annualized Loss Expectancy) metrics to mathematically justify cybersecurity investments against organizational losses.

1. Implement Security Controls: Enforcing direct safeguards to mitigate, transfer, accept, or avoid identified risks. These controls are split into:

• Technical/Logical Controls: Applied directly via software/hardware (e.g., iptables/firewall rules, LUKS block-level encryption, multi-factor authentication MFA/TOTP, TLS 1.3 tunnels).
• Administrative Controls: Information security policies, standard operating procedures (SOPs), routine security training, and compliance workflows.
• Physical Controls: Tangible barriers shielding hardware assets (e.g., datacenter biometric access controls, security gates, CCTV cameras).

1. Monitor and Review: A secure posture is never static. This step ensures safeguards remain functional and evolve alongside emerging exploitation techniques.

• Log Centralization: Forwarding system and daemon audit logs to unified security monitoring and SIEM systems (e.g., Wazuh/OSSEC).
• Post-Mortem Analysis: Conducting in-depth retrospective reviews after any security anomaly to uncover control gaps and feed details back into the identification phase.

Cybersecurity frameworks#

Frameworks provide standardized methodologies to guide organisations in establishing and maturing their information security governance:

• Establish Policies and Procedures (ISMS): Governed primarily by the international standard ISO/IEC 27001, which sets the blueprint for an Information Security Management System. It details organizational responsibilities, baseline policies, and maps operational controls through its comprehensive "Annex A" containing 93 specific security controls.
• Facilitate Incident Detection and Response (NIST CSF): The NIST Cybersecurity Framework structures resilience through interconnected core functions:
• Govern: Aligning cybersecurity strategy with business risks and regulatory mandates.
• Identify: Defining active assets, security parameters, and data flows.
• Protect: Applying access controls, data encryption, and configuration baselines.
• Detect: Designing real-time auditing and monitoring to surface potential security incidents.
• Respond: Executing containment playbooks to isolate affected systems during an attack.
• Recover: Restoring offline services safely and analyzing residual anomalies.
• Systematically Assess Risks: Benchmarking the active environment against global baselines to objectively evaluate security maturity over time, using frameworks like the CIS Controls (which details 18 domains of actionable defenses).
• Promote Compliance: Aligning infrastructure controls to local privacy laws and vertical industry regulations (such as GDPR or Brazil's LGPD for data protection, and PCI-DSS for credit card transaction safety), shielding the enterprise from liabilities and establishing brand trust.

Threat modeling (STRIDE and SRE)#

One of the core pillars of active risk management is threat modeling prior to infrastructure deployment. The STRIDE model (developed by Microsoft) evaluates the system's data flows to seek 6 classic attack vectors:

• Spoofing (Identity theft/masquerading)
• Tampering (Unauthorized modification of data)
• Repudiation (Inability to prove that an action occurred)
• Information Disclosure (Unintended leak of data)
• Denial of Service (Service exhaustion/interruption)
• Elevation of Privilege (Gaining unauthorized administrative access)

For SREs, modeling is translated into a Data Flow Diagram (DFD) where trust boundaries are explicitly drawn, mapping network connections between external clients, edge APIs, and private databases.

Quantitative risk analysis#

Mathematical risk calculations guide the financial and infrastructure investment in security controls. Classic quantitative analysis relies on the following formulas:

$$\text{SLE} = \text{Asset Value (AV)} \times \text{Exposure Factor (EF)}$$ $$\text{ALE} = \text{SLE} \times \text{Annualized Rate of Occurrence (ARO)}$$

• SLE (Single Loss Expectancy): The projected monetary loss caused by a single security incident.
• AV (Asset Value): The total financial value assigned to the asset. In a professional CISSP risk assessment, the value of a database server (e.g., $500,000) must not be reduced solely to the physical hardware replacement cost. It must mathematically incorporate: the business value of the stored data payloads, engineering and operational costs to recreate the data, corporate productivity loss, legal liabilities and potential lawsuits, regulatory compliance fines (e.g., GDPR/HIPAA), and the direct impact on brand reputation and enterprise market value.
• EF (Exposure Factor): The percentage of loss impact on the asset (e.g., a partial fire destroys 40% of the hardware and data, EF = 0.40).
• ARO (Annualized Rate of Occurrence): The estimated frequency at which the incident occurs per year (e.g., the annual probability of the database failing due to regional power grid instability is once every 5 years, ARO = 0.20).
• ALE (Annualized Loss Expectancy): The projected annual financial loss. In the example above:

$$\text{SLE} = \$500,000 \times 0.40 = \$200,000$$ $$\text{ALE} = \$200,000 \times 0.20 = \$40,000\text{ annually}$$

If a safeguard (such as a redundant backup system with a local generator) costs less than $40,000 per year (TCO - Total Cost of Ownership), the investment is financially justified to reduce the probability/impact of the risk.

Business continuity (BCP) and disaster recovery (DRP)#

Operational resilience is governed by three critical SLA metrics during disasters:

• RPO (Recovery Point Objective): Defines data loss tolerance. Indicates the point in time to which data must be restored (e.g., if the RPO is 4 hours, incremental backups must run at least every 4 hours).
• RTO (Recovery Time Objective): Defines service downtime tolerance. Indicates how quickly the infrastructure must be restored after a disaster.
• MTD (Maximum Tolerable Downtime): The absolute maximum downtime limit the organization can survive before suffering catastrophic, irreversible damage.

2. Asset security#

Protecting resources means understanding the lifecycle of digital and physical assets, controlling the flow and destruction of information in compliance with privacy laws.

Cryptography of assets at REST (LUKS on Linux)#

On physical servers or on-premises storage arrays, disk encryption protects data from physical theft of hardware. On Linux, we implement block-level encryption via the kernel device mapper cryptographic subsystem using LUKS/dm-crypt.

Prerequisites and kernel module verification#

Before initializing device encryption, verify that required kernel modules are active and that the Linux Kernel version is 4.0+ (recommended for full LUKS2 support):

# Check if dm-crypt is enabled in the active kernel configuration
grep CONFIG_DM_CRYPT /boot/config-$(uname -r)

# Verify if the dm-crypt kernel module is currently loaded
lsmod | grep dm_crypt

Block device pre-verification#

Prior to running any destructive operations, audit all active storage blocks to verify device paths:

# List all block devices, partitions, and active mount points
lsblk

# Verify disk partition table structure and dimensions
sudo fdisk -l

# View device signatures, partition details, and UUIDs
blkid

Step-by-step volume encryption:#

# 1. Install necessary cryptsetup utilities
sudo apt-get install cryptsetup -y

# 2. Force load the dm-crypt kernel module if not active
sudo modprobe dm_crypt

# 3. Write random data over the partition to mask physical entropy (optional & destructive)
sudo dd if=/dev/urandom of=/dev/sdb1 bs=4M status=progress

# 4. Format the volume with LUKS encryption (default algorithm AES-XTS-Plain64 with SHA-256)
sudo cryptsetup luksFormat /dev/sdb1

# 5. Map and open the created encrypted partition block
sudo cryptsetup open /dev/sdb1 secure_backup

# 6. Create the Ext4 filesystem on the virtual encrypted block device
sudo mkfs.ext4 /dev/mapper/secure_backup

# 7. Mount the volume to the target directory
sudo mount /dev/mapper/secure_backup /mnt/backups

Data sanitization and destruction#

When physical media reaches the end of its operational lifecycle, basic rm commands or partition formatting do not erase the data, as the logical blocks containing the physical information remain intact. To ensure data cannot be recovered, we apply different levels of sanitization (NIST SP 800-88 r1):

1. Clear (Logical Erasure): Overwriting data with new values.

    # Option A: Cryptographic Erase (instantly destroy decryption keys on dm-crypt)
    sudo cryptsetup erase /dev/sdb

    # Option B: Physical ATA Secure Erase (requires hdparm)
    # Set a temporary access password on the drive controller
    sudo hdparm --user-master u --security-set-pass p /dev/sdb
    # Trigger full physical cell flash sanitization via ATA commands
    sudo hdparm --user-master u --security-erase p /dev/sdb

1. Purge (Declassification): Methods that make data recovery impossible even through advanced forensic lab techniques (e.g., physical demagnetization - degaussing - or cryptographic erasure - Cryptographic Erase - CE, by destroying the master decryption keys).
2. Destroy (Physical Destruction): Physical shredding, incineration, or total chemical disintegration of the silicon/magnetic platter.

3. Security architecture and engineering#

Systems engineering must be rooted in the concept of Security by Design, integrating hardware security and execution isolation boundaries directly into the execution layers.

Access control models#

These conceptual models guide the isolation policies implemented in operating systems:

• Bell-LaPadula: Model focused on Confidentiality. Applies the Simple Security Property ("no read up" - you cannot read data classified above your clearance level) and the $\star$-Property ("no write down" - you cannot write data to a classification level below yours, to prevent accidental leaks).
• Biba: Model focused on Integrity. Applies the opposite rules: the Simple Integrity Axiom ("no read down" - you cannot trust data from a lower integrity level) and the $\star$-Property ("no write up" - you cannot modify data of an integrity level higher than yours).
• Clark-Wilson: Focused on commercial and enterprise data integrity. It prevents authorized users from making unauthorized modifications, ensures both internal and external consistency, and guarantees that modifications are audit-safe. The model relies on key CISSP pillars:
• CDI (Constrained Data Items): Any data item whose integrity is protected by the model (e.g., financial transactions, account balances).
• UDI (Unconstrained Data Items): Any data item outside the integrity model's control (e.g., raw user inputs, unvalidated requests).
• IVP (Integrity Verification Procedures): Audit procedures that run periodically to verify that all CDIs conform to valid integrity baselines.
• TP (Transformation Procedures): Well-formed transactions that move data from UDI to CDI or manipulate CDIs. Users are strictly barred from modifying CDIs directly; they must invoke authenticated TPs. This enforces Separation of Duties (SoD), as the subject triggering a transaction request TP lacks the privilege to execute the matching transaction approval TP.

CPU and hardware level protection#

A classic CPU vulnerability that forced kernel architects to redesign memory mapping was Meltdown (CWE-1037) and Spectre (CWE-1038), side-channel attacks relying on CPU speculative execution. Attackers could read private kernel memory from unprivileged user space processes.

To mitigate Meltdown, the Linux kernel community introduced KPTI (Kernel Page Table Isolation). KPTI ensures that the kernel page tables remain entirely mapped out of user space while normal processes execute, preventing hardware leakages via cache latency timing attacks.

4. Communication and network security#

Secure packet transmission relies on robust encryption tunnels in the transport layer and active edge scanning mitigation.

Network traffic forensic analysis#

During incident response, SREs must inspect network activity at the packet level. Using tcpdump allows analyzing TCP headers in a detailed and forensic manner:

# Capture the first 100 incoming packets containing connection TCP SYN flags
# and that are not directed to the normal HTTPS port (443)
tcpdump -n -c 100 'tcp[tcpflags] & (tcp-syn) != 0 and port not 443' -vvv

In the capture file (PCAP) output, we can track scanning attempts or traffic abuse by inspecting port sequences and packet sizes (MTU).

Secure transport encryption (TLS 1.3)#

During the TLS 1.3 handshake, negotiation is condensed to a single RTT (Round Trip Time), and transport encryption with Perfect Forward Secrecy (PFS) is mandated using Curve algorithms (DHE/ECDHE):

# Secure, hardened Nginx configuration strictly supporting TLS 1.3
server {
    listen 443 ssl http2;
    server_name domain.com;

    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;
    
    # Recommended robust cipher suites
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES-256-GCM-SHA384';
    
    # Enforce HSTS (HTTP Strict Transport Security)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

5. Identity and access management (IAM)#

IAM ensures that the right subject accesses the right object, under the right conditions and time window (Principle of Least Privilege).

Modern authentication and federation (OAuth 2.0 and OIDC)#

Token-based authentication protocols are the industry standard for federated access control on the web:

• OAuth 2.0: A protocol focused purely on Authorization. Emits access tokens (Access Token) following user consent so that client applications can interact with APIs on their behalf.
• OIDC (OpenID Connect): An identity extension layer built on top of OAuth 2.0 focused on Authentication. Introduces the identity token (ID Token) in a JWT (JSON Web Token) format, providing standardized user profile details.

Detecting attacks in active directory (kerberoasting)#

In Active Directory (AD) environments, the Kerberos protocol coordinates domain access. One of the most common design-based attacks on the protocol is Kerberoasting:

1. Any authenticated domain user can request a service ticket (TGS - Ticket Granting Service) for any Service Principal Name (SPN) registered in AD.
2. The Domain Controller (KDC) issues the TGS ticket encrypted using the service account's password hash.
3. The attacker extracts this ticket from their local session memory and cracks it offline using dictionary or brute force attacks (e.g., Hashcat). If the service account has a weak password, the service credentials are leaked.

SRE Mitigation: Use Group Managed Service Accounts (gMSA) and strong service passwords (at least 25+ characters).

Advanced Kerberoasting Detection in AD Logs: Relying solely on auditing Event ID 4769 (TGS Ticket Request) triggers high volumes of false positives, as normal domain activity constantly requests service tickets. To build precise alert definitions in your SIEM, apply the following correlation filters:

• Ticket Encryption Type: Target requests specifying encryption type 0x17 (RC4-HMAC, which is legacy and highly vulnerable to fast offline dictionary attacks) or 0x1/0x3 (DES).
• Service Account Filtering (Non-Machine Accounts): Focus on user accounts configured with SPNs, and explicitly exclude machine accounts (which terminate in $, change passwords automatically, and use secure 120-character keys).
• Request Volume Rate: Configure baseline alarms for automated scanning activity requesting multiple TGS tickets from a single source host within short intervals.

Recommended Wazuh/OSSEC Rule XML:

<rule id="100100" level="10">
  <if_sid>60108</if_sid>
  <field name="EventID">4769</field>
  <field name="TicketEncryptionType">0x17</field>
  <description>Kerberoasting detected: TGS request specifying RC4 encryption</description>
</rule>

6. Security assessment and testing#

Continuously assessing implemented defenses is the only way to validate control effectiveness before real-world attacks occur.

Centralization and forensic monitoring with Wazuh#

A SIEM (Security Information and Event Management) consolidates logs from endpoints into a single correlating console. Using Wazuh/OSSEC, we can monitor suspicious behaviors:

<!-- Custom rules in local_rules.xml to detect incoming SQLi attempts -->
<group name="web,app_security,">
  <rule id="100050" level="10">
    <if_sid>31108</if_sid>
    <regex>(SELECT|UNION|INSERT|DELETE|UPDATE|--|%27|\'|#)</regex>
    <description>Forensic Alert: SQL Injection (SQLi) attempt detected in payload/URL</description>
    <mitigation>Wazuh Active Response temporarily blocks source IP in local firewall</mitigation>
  </rule>
</group>

Forensic investigation in server logs (nginx/waf)#

When investigating HTTP access logs, security engineers must decode anomalous activities embedded inside payloads and header queries.

# Nginx access log showing an SQLi payload trying to bypass a login page
192.0.2.45 - - [15/Jun/2026:01:28:02 -0300] "POST /login.php HTTP/1.1" 200 4522 "https://domain.com/login" "Mozilla/5.0" "user=admin' OR '1'='1' --"

In the log above, the attacker injected ' OR '1'='1' -- inside the user field, nullifying the rest of the database query via the comment operator (--) to force administrative authentication.

7. Security operations#

Security operations isolate the infrastructure layer from advanced persistent threats (APTs), minimizing damage during host infections.

Auditing and tracking syscalls on Linux#

Post-compromise forensic analysis relies on reading system calls (syscalls) executed by suspicious processes. We configure auditd to track system execution on the host.

Unlike standard command utilities, auditctl enforces strict syntax constraints regarding filter operations under the -F flag. Specifically, composite operators like >= or <= are unsupported by the auditd parser, causing it to fail with the -F missing operation for auid error. To bypass this limitation and target standard users (whose UIDs/AUIDs are greater than or equal to 1000), we must use the greater-than (>) operator with the value auid>999.

Additionally, system daemons and background tasks (such as cron jobs or systemd services) run with an unset audit ID (auid=unset or the unsigned 32-bit integer maximum 4294967295, which maps to -1). Since 4294967295 is numerically greater than 999, omitting a cleanup filter would cause system daemons to flood the audit logs. To prevent this noise, we append auid!=4294967295 to filter out automated system processes and monitor solely real logged-in users.

The -k flag defines a custom key tag. In the example below, we designate audit_comandos as our tag. This label embeds a searchable index metadata field directly into the audit daemon log file (/var/log/audit/audit.log). Consequently, SRE teams or SIEM agents (like Wazuh) can instantly isolate occurrences matched by this security rule by running ausearch -k audit_comandos, significantly accelerating forensic triaging during incident response.

Below is the correct, hardened command sequence:

# 1. Add corrected rule to audit executions (execve) of real users (auid > 999) excluding system daemons (auid != -1)
auditctl -a always,exit -F arch=b64 -S execve -F "auid>999" -F "auid!=4294967295" -k audit_comandos

# 2. Read the logs filtered by key in a human-readable format
ausearch -k audit_comandos --format text

If an intruder writes unauthorized keys inside a user's .ssh directory, auditd will pinpoint the execution path, target files, Process ID (PID), and active login credentials.

8. Software development security#

Software security checks reduce human coding errors before the application reaches production environments.

Preventing common web vulnerabilities (OWASP top 10)#

Mitigation of high-frequency vulnerabilities must be integrated into the core software design:

1. SQL Injection (SQLi): Mitigated strictly by utilizing Prepared Statements (Parameterized Queries) or modern ORMs that perform automatic type binding and input escaping.
2. Cross-Site Scripting (XSS): Context-aware output encoding of dynamic values and implementing proper security headers (Content Security Policy - CSP).
3. Cross-Site Request Forgery (CSRF): Enforced by validating unique, cryptographic, single-use anti-CSRF tokens for mutating actions and setting cookie flags with the SameSite=Strict or SameSite=Lax attributes.

Post-hardening validation procedures#

After implementing the security hardening configurations (TLS tuning, auditd rules, Nginx adjustments), always perform operational verification to ensure controls are working correctly without disrupting system services:

# 1. Validate Nginx configuration syntax prior to reload
sudo nginx -t

# 2. Audit SSL/TLS handshakes and active cipher suites remotely
nmap --script ssl-enum-ciphers -p 443 domain.com

# 3. Verify that syscall auditd rules trigger successfully
sudo su -c "whoami"
sudo ausearch -k audit_comandos --start recent

Production takeaways#

The 8 domains of the CISSP certification prove that cybersecurity is not a series of isolated hardware appliances, but an ongoing cycle of risk management. As you bridge corporate strategy and operational implementation, you establish a resilient security posture.

Keep your infrastructure monitored, schedule continuous vulnerability scans, and secure your deployment pipelines.

See also

Cybersecurity cPanel security in production: Imunify360, csf/lfd, and wordfence CLI

Cybersecurity Lintriage: a Bash script for forensic triage and incident response on Linux

WordPress How to Detect and Clean Compromised WordPress Sites: Complete Forensic & Sanitization Guide

This post is licensed under CC BY-NC.