Data states and protection methods

Sub-domain 2.6 of the 2024 outline asks you to determine data security controls, starting with the states data can be in: at rest, in transit and in use. Each state faces different threats and calls for different protections. This lesson covers the three states, then the main protection methods that apply across them: encryption, hashing, tokenization, masking, and anonymization and pseudonymization. Choosing among these is one of the most common practical decisions in asset security, and the exam often asks which method best fits a scenario.

Data at rest

Data at rest is stored on media: disks in servers and laptops, databases, file shares, cloud storage, backup tapes, removable drives and mobile devices. The main threats are theft or loss of the media, unauthorized access by people or processes with access to the storage, and improper disposal. Controls include access control on the storage, encryption, physical security, and secure sanitization at the end of life.

Encryption at rest comes in several layers. Full-disk encryption, such as BitLocker on Windows, FileVault on macOS or self-encrypting drives, protects a device that is lost or stolen while switched off, but provides no protection once the device is running and unlocked. Volume or file-system encryption protects particular storage areas. Database encryption, including transparent data encryption, protects database files and backups. Application-level or field-level encryption protects particular values, such as a national identifier, so that even database administrators and anyone who copies the database cannot read them without the application's keys. The closer encryption sits to the data, the more threats it addresses, but the more complex key management and application changes become.

Data in transit

Data in transit is moving across a network: between a browser and a website, between application services, between data centres, across a wireless network or over a virtual private network. The main threats are interception (eavesdropping), modification and impersonation of either end. Controls include strong encryption with authentication of the endpoints. Transport Layer Security (TLS) 1.2 and 1.3 protect most application traffic; IPsec and modern VPNs protect network-level links; SSH protects administrative sessions; and secure file transfer protocols protect bulk transfers. Older protocols such as SSL, TLS 1.0 and 1.1, plain FTP and Telnet should be disabled. Mutual TLS, where both client and server present certificates, is increasingly used between services inside a zero trust architecture, so that traffic inside the data centre is protected as carefully as traffic across the internet.

Data in use

Data in use is being processed: loaded in memory, displayed on a screen or held in a processor's registers. It is the hardest state to protect, because most processing requires plaintext. Threats include malware that reads memory, privileged users who can inspect running processes, screen capture, and side-channel attacks. Traditional controls include strong endpoint security, least privilege, session controls such as watermarking and blocking screenshots for sensitive applications, and keeping sensitive processing on hardened, monitored systems.

Newer technologies aim to protect data even while it is processed. Confidential computing uses hardware-based trusted execution environments, such as secure enclaves, that keep data encrypted in memory and isolate it from the operating system, the hypervisor and the cloud provider's administrators. Homomorphic encryption allows certain computations on encrypted data without decrypting it, though it remains slow for most uses. Secure multi-party computation lets several parties compute a joint result without revealing their inputs to each other. These are useful to know for the exam at a conceptual level: they extend protection to the one state that conventional encryption leaves exposed.

Encryption and key management

Encryption is only as strong as its key management. Keys must be generated securely, stored separately from the data they protect, rotated on a schedule, backed up so data is not lost, and destroyed when no longer needed. Hardware security modules (HSMs) and cloud key management services store keys in tamper-resistant hardware and log their use. In cloud services, customers can choose provider-managed keys, customer-managed keys held in the provider's key service, or keys held entirely outside the provider, sometimes called hold your own key, which gives the customer more control at the cost of more responsibility. Domain 3 covers cryptography in depth; for asset security, the key points are that keys are themselves restricted assets, and that destroying keys can be a form of data destruction, as lesson 8 explains for crypto-erase.

Hashing

A cryptographic hash function turns any input into a fixed-length digest, such that the same input always gives the same digest, a small change gives a completely different digest, and it is infeasible to find the input from the digest or two inputs with the same digest. Hashes protect integrity: comparing the hash of a file with a known-good value shows whether it has changed. SHA-256 and the SHA-3 family are current choices; MD5 and SHA-1 are broken for security purposes. Hashing is not encryption: there is no key and no way to reverse it. Passwords are stored as salted hashes using slow, purpose-built algorithms such as Argon2, scrypt, bcrypt or PBKDF2, so that a stolen password database does not reveal the passwords. Simple unsalted hashes of low-entropy data such as phone numbers or postal codes are not a privacy protection, because an attacker can hash every possible value and compare.

Tokenization

Tokenization replaces a sensitive value with a random substitute, a token, that has no mathematical relationship to the original. The mapping between tokens and real values is kept in a secure token vault, or derived using vaultless techniques that still require a protected secret. Systems that only need to refer to the value, such as order history or customer service screens, store the token; only the few systems that genuinely need the real value can call the vault to detokenize. Tokenization is widely used for payment card numbers because it can remove most systems from the scope of the Payment Card Industry Data Security Standard (PCI DSS), now at version 4.0.1, which greatly reduces compliance effort and breach impact.

Encryption and tokenization are often compared. Encryption transforms the value with an algorithm and key, so anyone with the key can decrypt any encrypted value, and the ciphertext's format usually differs from the original unless format-preserving encryption is used. Tokenization substitutes values through a lookup, so stealing tokens without access to the vault reveals nothing, and tokens can easily keep the original format, such as a 16-digit number with the last four digits preserved for display.

Masking

Data masking hides some or all of a value. Static masking creates a permanently altered copy, for example a test database in which names, addresses and account numbers are replaced with realistic but fictitious values, so developers and testers can work without seeing real data. Dynamic masking leaves the stored value intact but changes what particular users see, for example showing only the last four digits of an account number to call centre agents while the fraud team sees the full value. Good masking preserves the format and relationships the application needs, such as valid-looking postal codes and consistent customer identifiers across tables, without exposing real people. Synthetic data, generated to have the statistical properties of real data without containing real records, is an increasingly common alternative for testing and machine learning.

Pseudonymization and anonymization

Pseudonymization replaces direct identifiers, such as names or account numbers, with pseudonyms, while keeping the information needed to re-link records held separately under strict control. A research data set in which each patient is labelled with a study code, while the key linking codes to patients is held by a separate team, is pseudonymized. Pseudonymized data is still personal information under the GDPR and most Canadian and US privacy laws, because re-identification is possible, but it reduces risk and is recognized as a safeguard.

Anonymization goes further: it transforms data so that individuals can no longer be identified, by anyone, using reasonably available means. Properly anonymized data falls outside many privacy laws. But true anonymization is hard. Removing names is not enough: combinations of quasi-identifiers such as postal code, date of birth and sex can single out most people, and rich data sets such as location traces or purchase histories can be re-identified by linking with other sources. Techniques such as generalization (reporting age bands instead of birth dates), suppression of rare values, k-anonymity (ensuring each record matches at least k others on its quasi-identifiers) and differential privacy (adding calibrated noise to results) reduce the risk. Quebec's Law 25, for example, allows anonymized information to be kept after its purpose is fulfilled only if anonymization is irreversible and done according to generally accepted best practices set by regulation.

Thinking like a manager

Exam scenarios usually point to the right method through what must be preserved. If authorized systems must recover the original value, choose encryption or tokenization; if most systems never need the real value, tokenization reduces scope. If only integrity matters, choose hashing. If people should see less than the whole value, choose dynamic masking. If non-production work needs realistic data, choose static masking or synthetic data. If data must leave the scope of privacy law, true anonymization is required, and the manager's job is to be sceptical of claims that removing names is enough.