More data privacy laws -- like those tabbed across this section -- in the US, Europe, and other international jurisdictions are passing and being enforced. CISOs and data governance teams responsible for safeguarding data at risk must also prove they located and protected that data in the right places, and in the right ways.
Data Loss Prevention (DLP) systems and data masking software can discover and de-identify Personally Identifiable Information (PII). How well do they document their search results, and actual masking procedures? How easy is it to locate and modify specific protections if something needs to be redone, or done differently? How can the risk of re-identification based on quasi-identifying data be measured and mitigated?
For detection control, there are extensive search logs and dashboard reports available from the data profiling and sensitive data discovery modules including with all IRI data masking software. For example, there are both scan-specific text reports and visualizations like these:
For masking operations, all data protections are specified in self-documenting, human-readable job scripts, mapping diagrams, or configuration files, or audit logs produced for IRI FieldShield, IRI DarkShield and IRI CellShield EE (which are all also included in the IRI Voracity data management platform.)
In the case of FieldShield, the audit trail contains each job script, which shows the protection technique(s) applied to each field in each table or file processed. Source-to-target mapping diagrams show the same changes quickly with orange connectors and the visual representations of the jobs are handy images to share.
That XML audit log also contains other job metadata, like the:
- protection library function(s) used
- encryption keys or de-ID codes
- input and output tables or files
- user who ran the job
- job start and end times
- number of records processed
To facilitate data breach prevention, you can review your jobs to validate a developer’s protections of output fields prior to execution.
For example, masking the SSN field in a payroll feed is a matter of connecting to your sources (or existing jobs) and clicking through a new job wizard or modifying existing parameters in a dialog or script. Some of the functions you can apply (ad hoc or as a rule), are:
- encryption and decryption
- anonymization via pseudonymization
- data masking
- de-identification and re-identification
- field redaction
As a compliance officer, you can see the protection(s) in each self-documenting job script or diagram. Once approved, the job can be saved or run on any local or remote server running the IRIdata masking executable.
After execution, the job script can be isolated or shared, and modified or protected using EGit for example, for reliable re-use in production. In FieldShield, a re-ID risk scoring module is also supplied to statistically measure the likelihood of a data set being linked to an individual based on the unmasked quasi-identifying (demographic) attributes in their record. Further anonymization techniques like blurring and bucketing to generalize that data to lower the re-ID risk but preserve the data's utility for research and marketing purposes are included (see HIPAA and FERPA tabs above).
The proxy-based dynamic data masking system optionally available with FieldShield is front-ended in a web application called SQL#. All database activity intercepted through the associated JDBC SQL Trail driver is recorded in an active logging environment, and exportable.
In the case of IRI DarkShield, an even more elaborate dashboard is provided to show data found vs. data masked: