Data Masking

Creates a sanitized, persistent copy of a production database by applying masking rules to sensitive columns before the data is cloned to a lower environment.

• Process: A one-time ETL operation that irreversibly alters data at rest.
• Use Case: Populating development, QA, and staging databases where real customer PII is never needed.
• Key Distinction: The original production data remains untouched; only the cloned target is transformed.

Intercepts database queries in real-time and applies masking rules on-the-fly without modifying the underlying stored data.

• Mechanism: A proxy layer rewrites SQL query results based on the user's role and access privileges.
• Use Case: Customer support agents who need to verify identity but should only see the last four digits of a credit card.
• Key Distinction: No data duplication is required, eliminating the storage overhead of static copies.

Replaces a specific input value with the same masked output value every time the algorithm is applied across tables and databases.

• Integrity: Preserves referential integrity by ensuring foreign key relationships remain consistent.
• Technique: Often implemented using HMAC-based keyed hashing or format-preserving encryption.
• Risk Trade-off: While it maintains join functionality, the consistency makes it vulnerable to frequency analysis if the masking key is compromised.

Encrypts data such that the ciphertext retains the exact length and character set of the original plaintext.

• Schema Compatibility: A 16-digit credit card number encrypts to another 16-digit number, requiring no changes to database column constraints.
• Algorithm: Relies on Feistel network constructions (FF1/FF3-1) approved by NIST Special Publication 800-38G.
• Advantage: Allows legacy applications with strict validation rules to process masked data without code refactoring.

The complete removal or blacking out of sensitive fields rather than replacing them with realistic substitutes.

• Types: Full redaction (replacing with 'XXXX'), partial redaction (showing first/last characters), and nullification (returning empty strings).
• Use Case: Legal discovery documents where irrelevant sensitive data must be obscured before sharing with opposing counsel.
• Limitation: Destroys analytical utility; unsuitable for development environments requiring realistic data distributions.

Substitutes sensitive data elements with non-sensitive surrogate 'tokens' while storing the original value in a hardened, external vault.

• Reversibility: Unlike one-way masking, authorized systems can detokenize the surrogate to retrieve the original value via a secure lookup.
• Scope: Commonly applied to payment card data (PCI DSS compliance) where the token retains the last four digits for verification.
• Architecture: Decouples security from the application layer by isolating the sensitive data store entirely.

Replaces sensitive data with realistic, contextually appropriate values drawn from a custom lookup table or dictionary. Unlike nullification, this preserves the semantic meaning and format of the data.

• Mechanism: A lookup table maps authentic names to a pre-generated list of fake but realistic names.
• Example: Replacing all customer surnames in a column with random surnames from a phonebook file.
• Utility: Maintains application functionality and format validation but breaks referential integrity if not applied consistently across tables.

Randomly reorders values within a single column so that the data remains realistic but the logical link between the attribute and the original record is severed. The values are not modified, only their positions.

• Mechanism: The SALARY column values are randomly permuted across all rows.
• Risk: Vulnerable to inference attacks if external data can be used to re-correlate shuffled attributes.
• Best Practice: Shuffle multiple columns independently to prevent cross-column correlation reconstruction.

Replaces sensitive data with a generic placeholder, typically NULL, XXXX, or a fixed character mask. This is the simplest form of masking but completely destroys analytical utility for that attribute.

• Mechanism: A direct string replacement or deletion operation.
• Use Case: Appropriate for columns that are strictly unnecessary in the target environment, such as direct identifiers in a test database.
• Drawback: Can cause application crashes if the target schema enforces NOT NULL constraints.

Randomly reorders characters within a string field to obscure the original readable value while preserving the string length. This is a basic obfuscation technique often used for test data.

• Mechanism: The string JANE DOE might become NJE AODE.
• Limitation: Trivial to reverse for short strings and provides no formal privacy guarantee.
• Application: Commonly used for masking names or alphanumeric IDs where format preservation is not strictly required.

Applies a fixed offset to date values to obscure the actual chronology of events while preserving the relative time intervals between records. This is critical for longitudinal analysis.

• Mechanism: A deterministic algorithm adds or subtracts a random number of days to every date in a column.
• Example: Shifting all DATE_OF_BIRTH values by -300 days to preserve age distribution without revealing actual birthdates.
• Constraint: The offset must be consistent across related tables to maintain temporal referential integrity.

Substitutes sensitive data with a non-sensitive, randomly generated surrogate token that retains no mathematical relationship to the original value. A secure token vault maps the token back to the original data.

• Mechanism: A credit card number 4111-1111-1111-1111 is replaced with TKN-8A3F-29B1.
• Security: Unlike encryption, tokens are not reversible via a mathematical algorithm; recovery requires access to the external vault.
• Utility: Preserves format and data type for application processing without exposing live data.