Data Masking

A persistent, non-reversible technique that transforms sensitive data at rest in a database or log store. A production audit log containing a real Social Security Number (123-45-6789) is permanently replaced with a fictitious but structurally valid value (987-65-4321) in a sanitized copy.

• Irreversible: The original value cannot be derived from the masked output.
• Use Case: Creating realistic, non-sensitive development and QA environments from production audit data.
• Key Distinction: Operates on a copy of the data, leaving the original source untouched.

A real-time, streaming obfuscation technique that intercepts queries and masks sensitive fields on the fly without altering the underlying stored data. When an auditor queries a log for user emails, the system returns j***@domain.com instead of the full address.

• Role-Based: Masking rules are applied based on the user's privileges; a privileged admin sees the full data, while an analyst sees a mask.
• No Data Duplication: Eliminates the need to maintain separate sanitized copies of massive log datasets.
• Latency-Sensitive: Requires high-performance proxy layers to avoid introducing query delays in real-time SIEM dashboards.

A reversible pseudonymization method that swaps a sensitive data element for a non-sensitive surrogate value, or token, using a cryptographically secure lookup table. The value [email protected] is consistently replaced with tok_A7X2B across all log entries.

• Referential Integrity: The same input always maps to the same token, preserving relationships needed for user and entity behavior analytics (UEBA).
• Re-identification: The original value can be recovered only by authorized systems with access to the secure token vault.
• Compliance: Satisfies data residency requirements by ensuring the token vault can be kept in a separate, highly restricted jurisdiction.

An encryption algorithm that transforms data into a ciphertext that retains the exact format and length of the original plaintext. A 16-digit credit card number (4111-1111-1111-1111) is encrypted into another 16-digit number (8291-5412-3319-2045).

• Schema Integrity: Allows encrypted data to be stored in existing database columns without modifying schemas or validation rules.
• Algorithmic Basis: Relies on standards like AES-FF1 mode, ensuring strong, provable security.
• Key Management: The security of the entire system depends on rigorous lifecycle management of the encryption keys, often enforced by a Hardware Security Module (HSM).

A privacy model that generalizes and suppresses attributes within a dataset to ensure that each record is indistinguishable from at least k-1 other records. If k=5, an attacker querying the audit log for a specific IP address and browser type will always find at least 5 matching records.

• Attack Prevention: Designed to thwart linkage attacks, where an adversary cross-references anonymized data with external datasets to re-identify individuals.
• Generalization: Specific ages like 34 are replaced with a range (30-40), and precise timestamps are truncated to the hour.
• Trade-off: Higher k values increase privacy but reduce the analytical utility and granularity of the log data for anomaly detection.

A mathematical framework that injects calibrated statistical noise into the results of queries against an audit log. When an analyst asks for the count of users who accessed a specific model, the system returns a result like 1,423 ± 15 instead of the exact number.

• Plausible Deniability: The presence or absence of any single individual's record in the log cannot be definitively confirmed, providing a provable privacy guarantee.
• Epsilon (ε) Budget: Privacy loss is controlled by a parameter ε; a lower epsilon means stronger privacy but noisier, less accurate query results.
• Composability: The total privacy loss accumulates across multiple queries, requiring a privacy budget manager to track and limit total disclosure over time.