States of Data

The Three States Framework

Data exists in one of three operational states at any given moment: at rest (stored on a device), in transit (moving across a network), and in use (being actively processed in memory). Each state creates a different attack surface and requires a different set of security controls. A comprehensive security strategy must address all three states — protecting two while ignoring the third leaves a gap that attackers can and will exploit.

This is not theoretical. The 2013 Target Corporation breach is the canonical exam example: Target encrypted both their stored data (data at rest) and their network traffic (data in transit). Attackers bypassed both by going directly after data in use — credit card numbers loaded into RAM during point-of-sale processing. 110 million credit cards were stolen from the memory of cash register terminals that had correctly implemented encryption for the other two states.

Data at Rest — Stored on Persistent Storage

Data at rest is any information stored on a persistent storage device and not actively traversing a network or being processed. The key characteristic: the data is sitting still. It is on a hard drive, SSD, flash drive, tape, database server, or any other persistent storage medium.

The primary risk for data at rest: physical or logical unauthorized access to the storage device. If an attacker steals a laptop, removes a hard drive, gains unauthorized access to a database server, or obtains a backup tape — the data at rest on those devices becomes exposed. Without encryption, everything on the device is immediately readable.

Encryption options for data at rest:

1. Full Disk Encryption (FDE) / Whole Disk Encryption

Full disk encryption encrypts every sector of the storage device — every file, every directory, the operating system files, everything. When the device is powered off, the entire contents are encrypted ciphertext. When the device powers on, a pre-boot authentication mechanism (password, PIN, smart card, TPM chip) unlocks the encryption and the operating system boots normally.

Common implementations: BitLocker (Windows), FileVault (macOS), LUKS (Linux). The Trusted Platform Module (TPM) chip can hold the encryption keys and enforce hardware-based authentication before releasing them.

Use case: laptops and portable devices — if the device is lost or stolen while powered off, the data is inaccessible without the authentication credential.

Limitation: full disk encryption protects against offline attacks (stolen powered-off device). A logged-in operating system has already decrypted the disk — data at rest encryption does not protect against a live OS-level attack from a logged-in attacker or malware running on the system.

2. Database Encryption

Database encryption encrypts sensitive data stored within a database management system. This can operate at different levels:

• Transparent Data Encryption (TDE): The database engine automatically encrypts data files on disk and decrypts them when queried by authorized users. Protects against someone stealing the database file — they cannot read it without the database engine and key.
• Column-level encryption: Individual sensitive columns (SSN, credit card number, password hash) are encrypted while other columns remain plaintext. Allows more granular control but adds query complexity.
• Application-level encryption: The application encrypts data before inserting it into the database — the database stores ciphertext and never sees the plaintext.

Use case: protecting regulated data (PII, PHI, payment card data) within a database that is accessible to the application but should not be readable if the database files are extracted.

3. File- and Folder-Level Encryption

Rather than encrypting the entire disk or an entire database, file- and folder-level encryption selectively encrypts specific files or directories. Only those selected items are encrypted; other content on the same drive remains unencrypted.

Common implementations: Windows Encrypting File System (EFS), third-party file encryption tools, encrypted archives (ZIP with AES).

Use case: protecting a specific folder of sensitive documents (legal files, HR records, financial spreadsheets) on a shared server where some content is public and some is sensitive.

Access controls for data at rest:

Encryption protects against physical theft and offline attacks, but access controls protect against online unauthorized access — when the system is running and the encryption is already unlocked by the operating system. Access controls answer: "Even though you can log into this system, can you access this specific data?"

• Access Control Lists (ACLs): Per-file and per-folder permission lists that specify which users or groups have read, write, execute, or modify rights. Every major file system (NTFS, ext4, APFS) supports ACL-based permissions.
• Role-Based Access Control (RBAC): Permissions assigned to roles (HR Manager, Database Administrator, Read-Only Auditor) rather than individuals. Users inherit permissions from their assigned roles.
• Group permissions: Users organized into groups; permissions assigned at the group level. An HR group has access to personnel files; the Engineering group does not.

Data in Transit — Moving Across Networks

Data in transit (also called data in motion) is any information actively moving across a network — from one device to another, from a client to a server, from a branch office to headquarters, from a local device to cloud storage. The key characteristic: the data is moving and therefore passing through infrastructure it does not control.

The primary risk for data in transit: interception. As data travels through switches, routers, wireless access points, and internet infrastructure, any device on the path could potentially capture the traffic. Without encryption, a network tap, a compromised router, or a malicious Wi-Fi hotspot can see everything passing through it. This is why unencrypted protocols (HTTP, Telnet, FTP, plain SMTP) are considered security risks — an observer anywhere on the path sees the plaintext data.

Network-based protection for data in transit:

Before considering encryption, organizations deploy network controls that filter what traffic is allowed to traverse the network at all:

• Firewalls: Enforce policies on which traffic is permitted — blocking unauthorized connections before they can reach sensitive systems. A firewall cannot protect the confidentiality of traffic it allows, but it reduces the attack surface by limiting what can communicate with sensitive servers.
• Intrusion Prevention Systems (IPS): Analyze traffic in transit for known attack patterns and anomalous behavior — blocking malicious traffic automatically. An IPS can detect and block data exfiltration attempts, C2 communication, and exploitation attempts in transit.

Transport encryption for data in transit:

Encryption is the primary protection that makes intercepted traffic unreadable to an observer on the network path:

TLS (Transport Layer Security): The protocol that secures HTTPS web traffic, email (SMTP/IMAP/POP3 with TLS), and many other application protocols. TLS creates an encrypted session between two endpoints — a web server and browser, for example. Traffic is encrypted before leaving the client and decrypted only at the intended server. An observer who captures the TLS session sees only ciphertext. TLS operates at the Transport Layer (Layer 4/5) and protects a specific application session.

IPsec (Internet Protocol Security): A suite of protocols that encrypts and authenticates IP communications at the Network Layer (Layer 3). IPsec is the foundation of most VPN technologies. In tunnel mode, the original IP packet is encrypted entirely and wrapped in a new outer header — the network path sees only the outer header; the original source, destination, and content are invisible. A site-to-site VPN using IPsec encrypts all traffic between two networks — not just a specific application session, but all IP communications between those networks.

What Data in Use Means

Data in use is information that is actively being processed by a computer — loaded into RAM, sitting in CPU registers or cache, or being manipulated by an application. The key characteristic: to do anything with data, the CPU must be able to read it. This means data in use is almost always decrypted.

Consider the lifecycle of an encrypted file. At rest on disk, it is stored as ciphertext — unreadable without the encryption key. When a user opens the file, the operating system or application decrypts it into RAM. The CPU processes the plaintext data in memory. When the user saves and closes the file, it is encrypted again before being written back to disk. At every moment when the data is being actively worked with — read, modified, displayed — it exists in plaintext somewhere in the system's memory. That is data in use.

This is not a flaw or a configuration mistake; it is a fundamental requirement of computation. A CPU cannot perform arithmetic on ciphertext; it cannot render encrypted pixels on screen; it cannot execute encrypted instructions. Plaintext must exist in memory for the computer to do anything with it.

Where Data in Use Lives

• System RAM: The primary working memory. When you open a document, browse a website, or run an application, the data is loaded into RAM. RAM is volatile — it loses its contents when power is removed — but while the system is running, everything in RAM is potentially readable by any code with sufficient privilege.
• CPU registers: Small, extremely fast storage locations inside the CPU itself. Data being actively computed on at this instant is in registers. Values move between registers and RAM during program execution.
• CPU cache: Intermediate memory between RAM and registers — faster than RAM but smaller. The CPU caches frequently accessed data here to avoid slower RAM round-trips. Data in cache is also plaintext during active processing.
• Virtual memory / swap space: When RAM is full, the operating system may page memory contents to disk in a swap file. This means data that was "in use" (and therefore decrypted) may be written to disk — potentially bypassing disk-level encryption if the swap file is on an unencrypted partition.

Why Attackers Target Data in Use

Attackers explicitly target data in use because encryption controls for the other two states — while necessary — create a known attack opportunity. If an organization:

• Encrypts all stored data (at rest) — attackers cannot read the disk contents offline
• Encrypts all network traffic (in transit) — attackers cannot read intercepted packets

...then there is one predictable moment when the data must be decrypted and readable: when it is being processed in memory. The attacker who cannot read the disk and cannot read the network traffic pivots to reading RAM instead. The encrypted data they cannot access at rest or in transit must pass through memory in plaintext, making memory the last unencrypted frontier.

Techniques for attacking data in use:

• RAM scraping (memory scraping): Malware that reads another process's memory — the primary technique in the Target breach. If malware gains sufficient privilege on the system, it can iterate through the memory of other processes and extract plaintext data that is temporarily loaded there.
• Cold boot attacks: Physically removing RAM chips immediately after power-off (RAM contents persist briefly at cold temperatures) and reading them with specialized hardware. Targets encryption keys held in RAM.
• DMA attacks: Devices with Direct Memory Access (DMA) capability (Thunderbolt, older FireWire) can read system RAM directly, bypassing OS access controls.
• Hypervisor attacks: In virtualized environments, the hypervisor has access to all guest VM memory — a compromised hypervisor can read all guest RAM.

The Target Corporation Breach — November 2013

The Target breach is the definitive real-world example of a data-in-use attack, and it is explicitly cited in the Security+ exam objectives for this reason. Understanding it in detail is essential for the exam.

What Target had in place:

• Data at rest encryption — stored cardholder data was encrypted on their servers
• Data in transit encryption — credit card data was encrypted as it traversed their network
• PCI DSS compliance — Target was certified as meeting Payment Card Industry standards at the time

How the breach happened:

1. Attackers initially compromised Target's network through a third-party HVAC (heating, ventilation, and air conditioning) contractor who had network access credentials
2. From that initial foothold, attackers moved laterally through Target's network to reach the point-of-sale (POS) systems — the cash register terminals in every store
3. Attackers installed custom malware (later named "BlackPOS" or "Kaptoxa") on the POS terminals — this malware was specifically designed to scrape credit card data from RAM
4. POS terminals process card transactions: the card is swiped, the card number and CVV are loaded into the terminal's RAM in plaintext for processing, the transaction is authorized, and then the data is cleared from memory. During that brief window when the data is in RAM, the malware captured it
5. The captured card data was collected by the malware on the terminals and exfiltrated to attacker-controlled servers
6. Result: approximately 110 million credit and debit card records stolen over several weeks

Why encryption did not help:

The card data was encrypted at rest (on Target's servers) and encrypted in transit (in the payment network). But at the moment of transaction processing — when the POS terminal is doing the work of reading the card and authorizing the transaction — the card data must be decrypted in RAM. That is the mandatory gap. The attacker's malware operated at the exact moment and location where the data had to be plaintext. No amount of encryption at rest or in transit can close the window when the CPU must work with the plaintext.

What would have helped:

• Point-to-point encryption (P2PE): Encrypting card data at the card swipe hardware itself and keeping it encrypted through the entire processing chain until it reaches the payment processor's secure environment — so the POS terminal RAM never holds plaintext card data
• Tokenization: Replacing card numbers with non-sensitive tokens at the card reader, so RAM never holds real card numbers
• Network segmentation: Isolating POS terminals so that lateral movement from the HVAC contractor's access point could not reach them
• Endpoint detection: Security software on POS terminals that could detect unusual process memory access patterns

The Target breach changed how the payment industry thinks about POS security and accelerated adoption of end-to-end encryption and chip cards (EMV), which use dynamic transaction codes that make RAM-scraped card numbers less usable for fraud.

Data Sovereignty — The Country's Laws Follow the Data

Data sovereignty is the principle that data stored within a country's borders is subject to that country's laws — regardless of where the organization that owns the data is headquartered. When data is stored in a country, that country's government has legal authority over it: they can issue court orders for access, they can mandate how it must be protected, they can restrict where it can be transferred, and they can impose penalties for non-compliance.

This principle has profound implications for organizations that operate globally, use cloud providers, or store data in multiple countries:

• A U.S. company that stores data in Germany is subject to German data protection law for that data — not just U.S. law
• A company whose cloud provider stores their data in multiple regions (including countries with mandatory data access for government intelligence agencies) must consider whether that storage arrangement is consistent with their data protection obligations
• Legal proceedings involving the data follow the laws of the country where the data resides — not the laws of the company's home country

GDPR and Data Residency Requirements

The General Data Protection Regulation (GDPR) is the most-tested data sovereignty example on the Security+ exam. GDPR is a European Union regulation — but its reach extends well beyond EU borders.

GDPR's core principle on data storage: Data collected about EU citizens must be handled according to GDPR standards — including where it is stored. GDPR restricts international data transfers: personal data about EU residents cannot be freely transferred to countries outside the EU unless that country has been deemed to provide adequate data protection or appropriate safeguards are in place (Standard Contractual Clauses, Binding Corporate Rules, etc.).

What this means practically:

• A U.S. company with European customers must comply with GDPR for those customers' data
• If that company wants to store European customer data on U.S. servers, they must have appropriate legal mechanisms in place (SCCs, adequacy decisions) — they cannot simply move the data to where it is convenient for them
• If a U.S. court issues an order for data that is stored in the EU, the EU data sovereignty laws apply — the company may be caught between conflicting legal obligations in different jurisdictions

Cloud computing complicates data sovereignty: Cloud providers distribute data across multiple data centers in multiple countries for redundancy and performance. An organization that uses a cloud service may not know exactly which countries their data passes through or where it is stored at any given moment. Cloud contracts increasingly include data residency options — the ability to specify that data must stay within a particular geographic region — precisely because of data sovereignty requirements.

Compliance laws may prohibit moving data out of the country: The exam source explicitly notes this — some jurisdictions not only require data to be stored locally but prohibit it from being transferred or replicated outside the country at all. Russia, China, and several other countries have data localization laws requiring that certain categories of data about their citizens be stored within the country. Organizations operating in these jurisdictions must ensure their data architectures comply, which may mean maintaining dedicated in-country infrastructure.

Geolocation — Location as a Security Control

Geolocation is the process of determining a user's or device's physical location using available technical signals. It is used as a security control to make access decisions based on where someone is, not just who they are.

Geolocation technologies:

• GPS (Global Positioning System): Satellite-based; highly accurate for mobile devices; requires GPS hardware. Most accurate for outdoor locations.
• Wi-Fi positioning (802.11): Identifies the device's location based on which wireless access points are visible and their signal strengths. Works indoors. Can be very precise within a building if access point positions are mapped.
• Mobile provider (cell tower triangulation): Location determined from which cell towers the device can communicate with. Less precise than GPS or Wi-Fi but works anywhere there is cellular coverage.
• IP address geolocation: Maps the user's IP address to a geographic location based on ISP registration data. Less precise than device-based methods — may resolve to a city or region rather than a specific building.

Security applications of geolocation:

1. Country-level access restriction: The most common application — blocking access to data or systems from countries where the organization has no employees or legitimate users. A U.S.-only business might block all login attempts from IP addresses that resolve to foreign countries. This is the streaming media example from the source material: content geo-restriction prevents access from countries without distribution rights.

2. Location-based privilege escalation: Users may receive different access levels depending on where they are. A corporate security policy might allow enhanced administrative access — or access to particularly sensitive data — only from within the physical corporate building (verified via Wi-Fi positioning to the corporate access points). The same user's credentials from outside the building receive standard access. This is the "permit enhanced access when inside the building" control in the exam objectives.

3. Anomaly detection: If a user's credentials are used from New York at 9 AM and then from a foreign country at 9:30 AM — an impossible travel detection — that anomaly can trigger a security alert or require additional authentication factors. Geolocation data combined with authentication timing enables this detection.

4. Data sovereignty enforcement: Geolocation can enforce data residency rules by preventing access to data from outside the authorized geography — or ensuring that data replication does not occur to servers in non-compliant countries.

Geolocation limitations: Geolocation controls can be bypassed by VPNs and proxy servers that change the apparent IP address. GPS and Wi-Fi signals can be spoofed with specialized hardware. IP geolocation databases are often inaccurate for mobile users or users on corporate VPNs that exit in a different city. Organizations should treat geolocation as one factor in an access control decision — not the only factor — and combine it with other authentication mechanisms for sensitive operations.