Information System Security Capabilities
Security Built into the Machine
Software security controls get most of the attention, but they all sit on top of hardware. If the hardware is compromised — if memory can be read by unauthorized processes, if the boot sequence can be tampered with, if a single disk failure takes the whole system offline — no amount of software will save you. This module covers the hardware and firmware security capabilities that form the foundation of a trustworthy system.
Hardware security is the trust anchor. Software can be patched, reconfigured, or replaced. But if the underlying hardware cannot be trusted, nothing built on top of it is trustworthy either.
This module covers CISSP exam objective 3.4: understand information system security capabilities. The exam expects you to know what each capability protects and when an architect would specify it — not how to configure it at the command line.
Memory Protection
Memory protection prevents one process from accessing another process’s memory space. Without it, any running program could read passwords from your browser, inject code into your operating system, or modify data belonging to other applications.
Key Mechanisms
- Process isolation — Each process runs in its own memory space. The operating system enforces boundaries so Process A cannot read or write Process B’s memory.
- Hardware segmentation — The CPU enforces memory boundaries at the hardware level. Even if the operating system has a bug, the hardware prevents cross-boundary access.
- Address Space Layout Randomization (ASLR) — Randomizes where programs and libraries load in memory, making it harder for attackers to predict target addresses for exploitation.
- Data Execution Prevention (DEP) / No-Execute (NX) — Marks certain memory regions as non-executable. Data stored in those regions cannot be run as code, preventing many buffer overflow exploits.
- Memory encryption — Some modern processors encrypt data in RAM, protecting against physical memory attacks (cold boot attacks, DMA attacks via external ports).
Memory protection is the technical enforcement of process isolation. The exam connects it to the concept of security domains — separate execution environments where different security policies apply.
Virtualization Security
Virtualization allows multiple operating systems to run on a single physical machine. The hypervisor (or virtual machine monitor) manages this separation. Security in virtualized environments depends on the hypervisor maintaining isolation between virtual machines.
Hypervisor Types
- Type 1 (bare-metal) — Runs directly on the hardware with no underlying operating system. Examples: VMware ESXi, Microsoft Hyper-V, Xen. Preferred for production environments because the smaller attack surface offers better isolation.
- Type 2 (hosted) — Runs on top of a host operating system. Examples: VMware Workstation, VirtualBox. The host OS adds an additional attack surface. Used primarily for development and testing.
Virtualization Security Concerns
- VM escape — An attacker breaks out of a virtual machine and gains access to the hypervisor or other VMs. This is the most serious virtualization threat because it breaks the fundamental isolation boundary.
- VM sprawl — Uncontrolled creation of virtual machines leads to unpatched, unmonitored, and forgotten VMs that become attack targets.
- Hypervisor compromise — If the hypervisor is compromised, every VM it manages is compromised. The hypervisor is the single most critical component in a virtualized environment.
- Inter-VM traffic — Traffic between VMs on the same host may bypass physical network security controls. Virtual switches and network monitoring must account for east-west traffic.
For the exam: Type 1 hypervisors are preferred for security because they have a smaller attack surface. VM escape is the highest-severity threat. VM sprawl is a governance problem, not a technical one.
Trusted Platform Module (TPM)
A TPM is a dedicated security chip on the motherboard that provides hardware-based cryptographic functions. It stores cryptographic keys, certificates, and measurements in a way that software alone cannot tamper with.
TPM capabilities:
- Secure key storage — Cryptographic keys are generated and stored inside the TPM. They never leave the chip in plaintext.
- Platform integrity measurement — The TPM records measurements (hashes) of boot components during startup. These measurements create a chain of trust that can detect if any boot component has been tampered with.
- Disk encryption binding — BitLocker and similar technologies use the TPM to seal encryption keys to the platform state. If the boot configuration changes (indicating tampering), the TPM will not release the encryption key.
- Remote attestation — The TPM can prove to a remote party that the platform is in a known, trusted state. This is used in enterprise environments to verify device health before granting access.
The TPM is a passive component — it does not enforce policy by itself. It provides measurements and cryptographic services that other systems (BIOS, OS, disk encryption) use to make trust decisions.
Secure Boot and UEFI Security
The boot process is the most vulnerable phase of system operation. Before the operating system loads, there are no OS-level security controls in place. An attacker who compromises the boot sequence controls everything that loads afterward.
BIOS vs. UEFI
- BIOS (Basic Input/Output System) — The legacy firmware interface. BIOS has limited security capabilities and no built-in mechanism to verify the integrity of what it loads.
- UEFI (Unified Extensible Firmware Interface) — The modern replacement for BIOS. UEFI supports Secure Boot, larger disk support, faster boot times, and a more capable firmware environment.
Secure Boot
Secure Boot is a UEFI feature that verifies the digital signature of every component loaded during startup: the firmware, the bootloader, the kernel, and the drivers. If any component fails signature verification, the boot process halts.
The chain works like this:
- UEFI firmware verifies the bootloader’s signature against trusted keys stored in the firmware
- The bootloader verifies the OS kernel’s signature
- The kernel verifies driver signatures before loading them
This creates a chain of trust from firmware to operating system. A rootkit that modifies the bootloader would fail signature verification and be blocked before it could execute.
Exam connection: Secure Boot + TPM together provide a hardware-rooted chain of trust. The TPM measures each boot stage; Secure Boot verifies each stage. Together, they detect and prevent boot-level tampering.
Hardware Security Modules (HSM)
An HSM is a dedicated, tamper-resistant hardware device designed to manage cryptographic keys and perform cryptographic operations. Unlike a TPM (which is a chip on the motherboard), an HSM is typically a standalone device or a PCIe card purpose-built for high-volume cryptographic processing.
HSM use cases:
- Certificate Authority key protection — The root CA’s private key is stored in an HSM, never exposed to software
- Payment processing — PIN verification, transaction signing, and key management for payment card operations
- Database encryption key management — Storing and managing the master keys that protect data encryption keys
- Code signing — The private key used to sign software releases is protected in an HSM
HSM vs. TPM
- TPM — Built into the motherboard, limited processing power, designed for platform integrity and binding keys to a specific machine
- HSM — Standalone or add-in device, high-performance cryptographic processing, designed for enterprise key management and high-volume operations
The exam tests whether you can match the right technology to the scenario. If the question involves protecting a platform’s boot integrity, TPM is the answer. If the question involves protecting a CA’s root key or processing thousands of cryptographic operations per second, HSM is the answer.
Fault Tolerance and Failover
Fault tolerance is the ability of a system to continue operating when a component fails. Failover is the process of automatically switching to a redundant system when the primary system fails. Both protect availability.
RAID (Redundant Array of Independent Disks)
RAID provides disk fault tolerance by distributing data across multiple drives:
- RAID 0 (striping) — Data is split across disks for performance. No redundancy. If one disk fails, all data is lost. This is NOT fault tolerant.
- RAID 1 (mirroring) — Data is duplicated on two disks. If one fails, the other has a complete copy. Simple but uses 50% of total capacity for redundancy.
- RAID 5 (striping with parity) — Data and parity information are distributed across three or more disks. Can tolerate one disk failure. Minimum three disks required.
- RAID 6 (striping with double parity) — Like RAID 5 but with two parity blocks. Can tolerate two simultaneous disk failures. Minimum four disks required.
- RAID 10 (1+0) — Combines mirroring and striping. Mirrors pairs of disks, then stripes across the mirrored pairs. Provides both performance and redundancy.
The exam tests two things about RAID: which levels provide fault tolerance (not RAID 0) and how many simultaneous failures each level can survive.
System-Level Failover
- Active-passive (hot standby) — A standby system waits idle until the primary fails, then takes over. Provides redundancy but the standby resources are unused during normal operation.
- Active-active (load sharing) — Multiple systems share the workload simultaneously. If one fails, the others absorb its load. More efficient resource usage but more complex to configure.
- Clustering — Multiple servers act as a single logical system. If one node fails, the cluster redistributes work to surviving nodes. Used for databases, application servers, and other critical services.
Pattern Recognition
Information system security capability questions on the CISSP follow these structures:
- Technology matching — A scenario describes a security requirement (protect boot integrity, store CA keys, survive disk failure). You match the requirement to the correct technology (Secure Boot + TPM, HSM, RAID level).
- Threat identification — A scenario describes an attack or failure. You identify which security capability would prevent it. Boot-level malware points to Secure Boot. Memory exploitation points to DEP/ASLR. VM attacks point to hypervisor security.
- Architecture decisions — You are selecting components for a new system. The question tests whether you understand what each component provides and when it is appropriate.
- Availability vs. security — A scenario involves a trade-off between uptime and protection. RAID and failover are availability controls. TPM and HSM are security controls. The question may ask which addresses the stated concern.
Trap Patterns
Watch for these wrong answers:
- “RAID replaces backups” — RAID protects against disk failure. It does not protect against accidental deletion, ransomware, or corruption. Both RAID and backups serve different purposes and are both needed.
- “RAID 0 provides redundancy” — RAID 0 provides performance through striping but zero fault tolerance. If any disk in a RAID 0 array fails, all data is lost.
- Confusing TPM and HSM — TPM is a motherboard chip for platform integrity and key binding. HSM is a dedicated device for enterprise key management and high-performance cryptography. Different tools for different jobs.
- “Secure Boot prevents all malware” — Secure Boot prevents boot-level tampering (rootkits, bootkits). It does not prevent application-level malware that runs after the OS loads.
- “Type 2 hypervisors are as secure as Type 1” — Type 2 hypervisors run on a host OS, adding attack surface. Type 1 runs directly on hardware with a smaller footprint. For security-sensitive environments, Type 1 is preferred.
Scenario Practice
Question 1
An organization operates a certificate authority that issues digital certificates for all internal and partner-facing services. The CA’s root private key must be protected so that it is never exposed to software, cannot be extracted even by administrators, and survives hardware failures through key backup.
Which technology should protect the root CA key?
A. TPM on the CA server
B. Software-based key store with strong encryption
C. Hardware Security Module (HSM) with key backup to a second HSM
D. Encrypted USB drive stored in a physical safe
Answer & reasoning
Correct: C
An HSM is purpose-built for protecting high-value cryptographic keys. The root CA key never leaves the HSM in plaintext, the tamper-resistant design prevents extraction even by insiders with physical access, and enterprise HSMs support key backup to secondary HSMs for disaster recovery. A TPM (A) is designed for platform integrity, not enterprise key management. Software key stores (B) expose keys to the operating system. A USB drive (D) is portable and lacks the tamper resistance and access controls of an HSM.
Question 2
A security team discovers that malware has modified the bootloader on several workstations. The modified bootloader loads before the operating system and intercepts authentication credentials. The workstations have UEFI firmware but Secure Boot is disabled.
What control would have prevented this attack?
A. Full disk encryption using software-based key management
B. Enabling Secure Boot to verify bootloader signatures before execution
C. Installing an intrusion detection system on each workstation
D. Deploying RAID 1 to maintain a clean copy of the bootloader
Answer & reasoning
Correct: B
Secure Boot verifies the digital signature of the bootloader before allowing it to execute. A modified bootloader without a valid signature would fail verification and be blocked. The attack specifically targets the boot sequence — which is the exact threat Secure Boot addresses. Disk encryption (A) protects data at rest but does not prevent bootloader modification. IDS (C) detects after the fact, not prevents. RAID (D) provides disk redundancy, not integrity verification of boot components.
Question 3
A database server stores financial transaction records that the organization classifies as critical. The server uses a single 4 TB hard drive. Management asks the security architect to recommend a storage configuration that can survive a single disk failure without data loss while balancing cost and performance.
Which RAID level should the architect recommend?
A. RAID 0 — striping across two drives for maximum performance
B. RAID 1 — mirroring to a second drive for a complete duplicate
C. RAID 5 — striping with parity across three or more drives
D. RAID 6 — striping with double parity for two-failure tolerance
Answer & reasoning
Correct: C
The requirement is surviving a single disk failure while balancing cost and performance. RAID 5 provides single-disk fault tolerance through parity data distributed across three or more drives, with better storage efficiency than RAID 1 (which loses 50% of capacity to mirroring). RAID 0 (A) has no fault tolerance. RAID 6 (D) survives two failures, which exceeds the stated requirement and costs more. RAID 5 is the balanced choice for single-failure tolerance with reasonable cost and performance.
Key Takeaway
Information system security capabilities are the hardware foundation that software controls depend on. For the exam, remember three categories and their flagship technologies:
- Trust establishment — TPM (platform integrity), Secure Boot (boot chain verification), HSM (key protection)
- Isolation — Memory protection (process separation), virtualization (VM isolation via hypervisor)
- Availability — RAID (disk fault tolerance), failover (system-level redundancy)
Match the technology to the risk. Boot tampering needs Secure Boot. Key protection needs HSM. Disk failure needs RAID. VM isolation needs a Type 1 hypervisor. The exam tests your ability to select the right tool, not your ability to configure it.