3.4 Information System Security Capabilities
3.4 Information System Security Capabilities
Information systems contain security capabilities at several layers - hardware, firmware, operating system, platform and application.
These capabilities provide the mechanisms that allow security architectures and controls to actually enforce protection.
Isolate
Prevent processes and users from interfering with protected memory and execution.
MEMORY PROTECTIONEstablish Trust
Use hardware-backed capabilities to protect keys and verify platform integrity.
TPM & ROOTS OF TRUSTProtect Data
Apply cryptographic capabilities to information stored and transmitted by the system.
ENCRYPTIONThe Big Idea
Security architecture defines what protection is required.
System security capabilities provide the mechanisms that help enforce those requirements.
A capability describes what a system is technically capable of doing.
The architect still needs to decide whether, where and how that capability should be used to satisfy security requirements.
Security Capabilities Exist at Multiple Layers
An application can be securely coded while still depending on a compromised operating system, firmware layer or hardware platform.
🧠 Memory Protection Prevent one process from accessing memory belonging to another
Modern operating systems execute many applications at the same time.
Those applications may process:
Without memory protection, one process could potentially inspect or overwrite memory belonging to another process.
Process Isolation
Each process can be given its own logical address space.
The operating system and processor cooperate to prevent one process from directly accessing memory that belongs to another process unless access has been explicitly permitted.
Your browser is running alongside a password manager.
The browser should not be able to simply read arbitrary memory belonging to the password manager.
Process isolation helps enforce that boundary.Compromising one process should not automatically provide unrestricted access to every other process on the system.
📍 Virtual Memory & Address Spaces Processes receive controlled views of memory
Applications normally operate using virtual memory addresses rather than directly managing every physical memory location.
The operating system and processor map those logical addresses to physical memory.
Process A may believe it owns memory location:
0x1000
Process B may also use a virtual address:
0x1000
But the operating system can map those addresses to completely different physical memory locations.
It also contributes to process isolation and controlled memory access.
👑 Processor Privilege Levels Not all code should have equal authority
Modern processors provide different privilege levels so ordinary applications do not receive unrestricted access to critical system resources.
Highly privileged execution used by the operating-system kernel and other trusted components.
Restricted execution used by normal applications.
A normal text editor should not be allowed to directly:
- reconfigure processor memory protection;
- overwrite the operating-system kernel;
- arbitrarily access another process's memory;
- directly control protected hardware resources.
If every application executed with the highest processor privilege, compromise of any application could potentially compromise the entire system.
Privilege Levels
More privilege = greater potential impact
🚧 Memory Execution Protections Make memory exploitation more difficult
DEP / NX
Data Execution Prevention, often supported by processor NX - No Execute functionality, allows memory regions to be marked as non-executable.
This makes it harder for an attacker to place malicious instructions into a data area and execute them directly.
Memory used for application data is marked:
READ / WRITE - NOT EXECUTE
Injecting malicious machine instructions into that area does not automatically make those instructions executable.
ASLR
Address Space Layout Randomization makes important memory locations less predictable.
Locations such as executable code, libraries and other memory regions can be placed at varying addresses when processes start.
Some exploits depend on knowing where useful code or data exists in memory.
ASLR makes those addresses less predictable.
DEP attempts to restrict where code can execute.
ASLR makes useful memory locations harder to predict.
They make exploitation more difficult, but vulnerabilities can still exist and attackers may develop techniques that bypass individual protections.
🧩 Memory Safety Prevent unsafe access within applications
Memory protection prevents one process from arbitrarily accessing another process's memory.
Memory safety addresses whether a program itself accesses memory correctly.
Protects boundaries between processes and privilege domains.
Helps prevent software from reading or writing memory outside valid boundaries.
An application allocates a buffer for 20 characters.
It attempts to write 500 characters into that buffer.
That is a software memory-safety problem.
Safe programming techniques, compiler protections, operating-system protections and processor capabilities can all contribute to reducing memory exploitation.
🔐 Trusted Platform Module - TPM Hardware-backed trust and cryptographic protection
A Trusted Platform Module is a security component designed to provide hardware-backed cryptographic and platform-security capabilities.
TPM functionality can support:
It can protect cryptographic material and record measurements that help determine how the platform started.
Hardware-Backed Key Protection
Cryptographic keys can be generated or protected in ways that make exporting the secret key material more difficult.
A disk-encryption system protects its encryption key using the TPM.
Copying the encrypted disk into another computer does not automatically provide the attacker with the protected TPM-held secret.
A TPM is commonly used to protect keys and platform state.
Bulk encryption of large amounts of data is usually performed by other cryptographic mechanisms using keys that may be protected by the TPM.
📏 Platform Measurements Record evidence about how a system started
Components involved in booting a system can be cryptographically measured.
Those measurements can be recorded using TPM facilities and later used as evidence of the system's boot state.
Platform Configuration Registers - PCRs
TPMs provide Platform Configuration Registers that can be used to hold cryptographic measurements associated with platform state.
Rather than simply overwriting measurements, TPM operations can build a history of measurements into PCR values.
Think of them as cryptographic evidence about platform state rather than storage for complete firmware or operating-system images.
🥾 Secure Boot Prevent untrusted boot components from executing
Secure Boot uses cryptographic verification to determine whether boot components are trusted before allowing them to execute.
An attacker modifies the system's bootloader.
Its cryptographic validation no longer satisfies the expected trust policy.
Secure Boot can prevent the modified component from loading.
Secure Boot
Secure Boot = Verify then Execute
📊 Measured Boot Measure components so platform state can be evaluated
Measured Boot records measurements of components involved in the boot process.
Those measurements can later be evaluated to determine whether the system started in an expected state.
It is conceptually different from Secure Boot, which attempts to prevent untrusted components from executing.
Secure Boot vs Measured Boot
| Secure Boot | Measured Boot | |
|---|---|---|
| Main purpose | Prevent unauthorised boot components from executing. | Record evidence about components that participate in the boot process. |
| Main action | Verify and enforce. | Measure and record. |
| Question | Should this component be allowed to execute? | What did this system boot with? |
| Result | Trusted component proceeds; untrusted component may be blocked. | Measurements provide evidence for later evaluation. |
Boot Memory Aid
Secure = Enforce · Measured = Evidence
🌱 Roots of Trust Trust must begin somewhere
A system cannot establish trust by asking every component to verify itself.
Trusted computing architectures therefore require a small set of components or functions that are trusted to perform critical security operations correctly.
These foundational components are commonly described as roots of trust.
Trust can be extended from a trusted starting point by verifying subsequent components before they are relied upon.
If the foundational trust mechanism is compromised, later validation may no longer provide meaningful assurance.
📜 Attestation Provide evidence about platform state
Attestation allows a system to provide evidence about aspects of its platform state to another party.
TPM-backed measurements can contribute to this process.
Before allowing a laptop to access a sensitive service, an organisation may want evidence that the device booted using an expected trusted configuration.
Platform measurements can contribute to that trust decision.
Attestation does not mean:
"This device can never be compromised."
It provides evidence that can be evaluated as part of a security decision.
🔒 Encryption & Decryption Capabilities Protect information against unauthorised disclosure
Encryption transforms readable information into a protected form using cryptographic algorithms and key material.
Decryption reverses that process for an authorised party possessing the required key material.
Encryption makes information unintelligible to parties that do not possess the required cryptographic key material.
The deeper cryptographic algorithms, PKI concepts and key-management architecture are covered in:
3.6 Cryptographic Solutions & PKI
Encryption Across Data States
Data at Rest
Information stored on disks, databases, backups or other media.
STOREDData in Transit
Information moving between systems or locations.
MOVINGData in Use
Information actively being processed.
PROCESSINGCustomer data may be:
encrypted on a database disk - at rest;
encrypted using TLS while travelling to an application - in transit;
decrypted while the application performs a calculation - in use.
A database encrypted on disk may still expose plaintext when an authorised application decrypts records for processing.
💾 Full-Disk & Volume Encryption Protect stored information when media is lost or stolen
Storage encryption can protect information when a disk, laptop or other storage device is removed from its normal trusted environment.
An employee loses a powered-off corporate laptop.
Properly implemented full-disk encryption can significantly reduce the attacker's ability to read information directly from the drive.
Once an authorised user unlocks the system, applications may access decrypted data normally.
Malware executing in that authorised environment may therefore present a different risk.
Disk Encryption
🗝️ Key Protection Encryption is only as trustworthy as its key management
An information system may provide excellent cryptographic algorithms, but those capabilities can be undermined if keys are poorly protected.
Backup files are strongly encrypted.
The encryption key is stored:
unencrypted beside the backup files.
Anyone obtaining both can decrypt the information.
Systems may use hardware-backed mechanisms such as:
Good cryptography depends on trustworthy key generation, storage, access, rotation and destruction.
🏦 Hardware Security Module - HSM Dedicated protection for high-value cryptographic operations
A Hardware Security Module is a specialised security device designed to protect cryptographic keys and perform cryptographic operations within a controlled hardware environment.
A bank operates an internal Certificate Authority.
The CA's private signing key is extremely sensitive.
Rather than storing the private key as an ordinary file, the organisation may use an HSM so signing operations occur within protected hardware.
TPM vs HSM
| TPM | HSM | |
|---|---|---|
| Typical scope | Individual computing platform or device. | Dedicated cryptographic infrastructure. |
| Common use | Device trust, platform measurements and protected device keys. | High-value organisational keys and cryptographic operations. |
| Example | Protect laptop disk-encryption key. | Protect Certificate Authority signing key. |
| Architecture role | Platform trust anchor. | Dedicated cryptographic trust component. |
TPM vs HSM
TPM = Platform · HSM = Cryptographic Infrastructure
🔒 Trusted Execution Environments Create additional isolation for sensitive processing
Trusted Execution Environment technologies attempt to provide an isolated execution area for sensitive code and data.
Depending on the architecture, they may help protect particular workloads even from other highly privileged software on the same system.
A sensitive cryptographic operation executes inside a protected enclave.
Other normal applications on the machine should not be able to directly inspect the protected memory used by that operation.
Trusted execution mechanisms create another security boundary around particularly sensitive execution.
The architecture, implementation, interfaces and underlying hardware can still contain vulnerabilities.
📦 Virtualisation Isolation Separate multiple systems on shared hardware
Virtualisation allows multiple isolated virtual systems to operate on shared physical hardware.
A hypervisor helps create and enforce boundaries between those virtual machines.
One physical server hosts:
Each virtual machine can be given isolated virtual memory, processors, storage and network interfaces.
If the isolation layer is compromised, the separation between guest systems may be undermined.
Architecture vulnerabilities associated with virtualisation are covered further in:
3.5 Architecture & Technology Vulnerabilities
⚙️ Firmware Security Capabilities Protect the layer underneath the operating system
Firmware operates at a fundamental level of the computing platform.
Compromise of firmware can be particularly serious because malicious code may execute before the operating system and can undermine higher-level protections.
Verify firmware updates before installation.
Restrict unauthorised modification of firmware.
Identify unauthorised firmware changes.
Restore trusted firmware following corruption or attack.
Firmware resilience is not only about preventing modification.
Architectures should also consider detecting compromise and securely recovering from it.
⚡ Cryptographic Acceleration Hardware can assist cryptographic processing
Some processors and specialised hardware provide capabilities designed to accelerate cryptographic operations.
This can make strong cryptographic protection practical for workloads processing large volumes of information.
A high-volume service performs millions of encrypted communications.
Hardware cryptographic acceleration can reduce the computational overhead associated with supported cryptographic operations.
Fast cryptography does not compensate for weak algorithms, exposed keys or poor key management.
How the Capabilities Work Together
Securing a Corporate Laptop
Consider how multiple information-system capabilities can work together on an enterprise laptop.
Protects hardware-backed cryptographic key material and platform measurements.
Helps prevent unauthorised boot components from executing.
Records evidence about components involved in the boot sequence.
Protects stored information if the laptop is lost or stolen.
Helps isolate user applications and system processes.
Restricts execution from memory areas intended only for data.
Makes useful memory locations less predictable to attackers.
Prevents ordinary applications from automatically receiving unrestricted system privilege.
The laptop becomes more resilient because several capabilities protect different stages of system operation.
Protecting a Certificate Authority
An organisation operates a highly sensitive internal Certificate Authority.
Protecting the CA key is not simply an application-level problem.
The trustworthiness of the underlying platform also matters.
🎓 CISSP Scenarios Identify the relevant information-system capability
A compromised browser attempts to read arbitrary memory belonging to a password manager running on the same workstation.
Which capability should help prevent this?
Memory protection / process isolation.
A normal user application attempts to directly modify protected operating-system kernel memory.
Which capability is MOST relevant?
Processor privilege levels and user/kernel separation.
An attacker places machine code into an area of memory intended only to contain data.
Which capability can mark that memory as non-executable?
DEP / NX.
An exploit depends on a system library always loading at the same predictable memory address.
Which capability attempts to disrupt this assumption?
ASLR.
An organisation wants encryption keys to be bound to a corporate laptop and protected using a hardware-backed security component.
Which capability is MOST appropriate?
TPM.
An attacker replaces a legitimate operating-system bootloader with a modified version.
Which capability is intended to prevent an untrusted bootloader from being executed?
Secure Boot.
A security service needs evidence showing which components participated in a workstation's boot process.
Which capability is MOST relevant?
Measured Boot.
A bank needs to protect the highly sensitive private signing key of its Certificate Authority.
Which capability is MOST appropriate?
Hardware Security Module - HSM.
A stolen powered-off corporate laptop contains confidential customer information.
Which capability MOST directly protects the stored information?
Full-disk or storage encryption.
A system needs to provide evidence to a remote service that it booted into an expected trusted state.
Which concept is MOST relevant?
Attestation.
Sensitive code should execute within an additional isolated environment that protects its memory from normal applications.
Which capability is MOST relevant?
Trusted Execution Environment.
Four virtual machines operate on one physical system while being isolated from each other's virtual memory and resources.
Which component is primarily responsible for maintaining this virtualisation boundary?
The hypervisor.
Recognise the Capability from the Requirement
Process Separation
One process should not read another process's memory.
Memory ProtectionPrivilege Boundary
Applications should not execute with kernel authority.
User / Kernel ModesNo Execution from Data
Prevent instructions executing from data-only memory regions.
DEP / NXUnpredictable Memory
Randomise where code and libraries are loaded.
ASLRDevice Trust
Hardware-backed keys and platform measurements.
TPMStop Modified Bootloader
Validate before boot execution.
Secure BootRecord Boot State
Measure boot components.
Measured BootEvidence of Platform State
Prove or demonstrate measured state.
AttestationProtect Device Keys
Device-level hardware-backed trust.
TPMProtect Enterprise Crypto Keys
Dedicated cryptographic hardware.
HSMProtect Stored Data
Lost or stolen storage device.
Encryption at RestIsolate Sensitive Execution
Additional protected execution boundary.
TEE⚠️ Common CISSP Mistakes Similar capabilities solve different problems
Memory protection controls access between processes and privilege domains.
Encryption protects the confidentiality of information using cryptography.
Memory protection isolates processes.
Memory safety concerns whether code accesses memory correctly within its own execution context.
Secure Boot: verify and enforce.
Measured Boot: measure and record.
A TPM commonly provides a device-level trust anchor.
An HSM is dedicated cryptographic infrastructure designed to protect high-value keys and operations.
A TPM can protect cryptographic keys and provide platform-security capabilities.
It is not simply a general-purpose replacement for bulk encryption.
Once an authorised system has decrypted the information for use, other security controls are still required.
ASLR can make exploitation more difficult.
It does not remove the underlying software vulnerability.
DEP restricts execution from particular memory regions.
Attackers may still exploit vulnerabilities using other techniques.
Attestation provides evidence about a measured system state.
It does not prove that compromise can never occur afterwards.
Isolation depends on the trustworthiness of the hypervisor and surrounding architecture.
Quick Comparison
| If the requirement is... | Think... |
|---|---|
| Separate one process from another | Memory Protection |
| Restrict ordinary applications from kernel privileges | Privilege Modes |
| Prevent execution from a data-only memory region | DEP / NX |
| Make memory addresses unpredictable | ASLR |
| Hardware-backed device key protection | TPM |
| Prevent unauthorised boot code | Secure Boot |
| Record evidence about boot components | Measured Boot |
| Provide evidence about platform state | Attestation |
| Protect a highly sensitive organisational private key | HSM |
| Protect a stolen powered-off disk | Encryption at Rest |
| Protect communications over an untrusted network | Encryption in Transit |
| Isolate sensitive code while executing | Trusted Execution Environment |
| Isolate multiple virtual machines | Hypervisor |
| Protect low-level platform software | Firmware Protection |
Information System Capability Memory Aid
Isolate · Verify · Measure · Protect
Trusted Platform Memory Aid
Trust → Verify → Measure → Record → Attest
Key Takeaways
Information-system security capabilities exist across hardware, firmware, operating-system, platform and application layers.
Memory protection helps isolate processes and prevents unrestricted access to memory belonging to other processes.
Processor privilege levels separate ordinary application execution from highly privileged operating-system functions.
DEP / NX can mark memory regions as non-executable, making some forms of memory exploitation more difficult.
ASLR makes important memory locations less predictable to attackers.
Memory protection and memory safety are related but different concepts.
A TPM provides hardware-backed platform-security capabilities including key protection and platform measurements.
Platform Configuration Registers can hold cryptographic measurements associated with system state.
Secure Boot verifies boot components and can prevent unauthorised components from executing.
Measured Boot records measurements of boot components so platform state can later be evaluated.
Secure Boot = enforce. Measured Boot = evidence.
Roots of trust provide the trustworthy foundation from which further trust can be established.
Attestation provides evidence about system or platform state for evaluation by another party.
Encryption protects information confidentiality, but protection must be considered separately for data at rest, in transit and in use.
Cryptographic protection depends on appropriate protection of cryptographic keys.
A TPM is commonly associated with an individual computing platform while an HSM provides dedicated protection for high-value cryptographic keys and operations.
Trusted Execution Environments can provide additional isolation for sensitive code and data while they are being processed.
Virtualisation provides isolation between guest systems, but the hypervisor itself becomes a security-critical component.
No single capability creates a secure system. Security comes from combining complementary capabilities within a well-designed architecture.
📚 Sources & Further Reading Platform and information-system security references
- ISC2 - CISSP Certification Exam Outline
View the CISSP Exam Outline - Trusted Computing Group - TPM 2.0 Library Specification
View the TPM specification - NIST SP 800-193 - Platform Firmware Resiliency Guidelines
View NIST platform firmware guidance - NIST SP 800-147B - BIOS Protection Guidelines for Servers
View NIST BIOS protection guidance - Microsoft - Trusted Platform Module Technology Overview
View TPM technology guidance - Microsoft - Secure the Windows Boot Process
View Secure Boot and Measured Boot guidance