Card Recon and Enterprise Recon are able to remediate sensitive data. This article explains the various options available and answers some common questions.
The current releases of our software have the ability to censor PAN data (credit card data) in place in a limited number of common file formats, including text files, CSV, and Microsoft Office documents.
This functionality is only available for text matches. OCR and audio matches cannot be masked.
The process works as follows:
- We check to ensure that the PAN we have found is unchanged since the time of the last scan.
- Assuming that it is unchanged, we apply masking according to PCI standards.
As an example, the number 5105105105105100 would be modified to read 510510XXXXXX5100.
Masking for other types of data match can be configured; for further details on this please open a new support case.
The quarantine option will move selected files containing matches to a different directory of choice. We recommend that the target directory is secure and encrypted.
The delete option overwrites the selected file with random data. We perform a three pass overwrite, replacing every bit value with "1", "0" and then finally with "Pseudo-random data".
Please note that we cannot guarantee compliance with specific erasure standards, as our software does not have access to the underlying hardware. For example, ER2 could be performing the Delete Remediation on a virtual machine with snapshot support, which ER2 would not have access to scan or modify, or a volume with copy-on-write (CoW) enabled, or a Write-Once, Read Many (WORM) volume where modification would not be permitted.
The encrypt option archives selected files into an AES protected ZIP archive (using AES-128 bit encryption). The password for this archive should be entered at the time the option is chosen.
*It is important to note the password is not stored within Enterprise Recon, and therefore should be stored independently in a secure manner (such as a password vault).
Remediation of Databases
Ground Labs' products do not support direct remediation within databases. In our experience there are very few DBAs or application owners who would be willing to grant write access to tables in production databases to a third party application. There is a significant risk that an inadvertent remediation could cause a system outage – rendering such a feature too dangerous for practical use.
Our reporting system returns the precise row and column where a match is found in order to aid manual remediation.
In the example above, the match "406041######2825" was found in columns "STREET_ADDRESS_1" and "STREET_ADDRESS2". These columns directly correlate to the columns in your schema table.
Remediation of Email
Email remediation is limited to the ability to delete emails containing matches. It is not possible for us to support data masking or encryption. The reason for this is that email servers do not allow rewriting of email content in place.
This option behaves in exactly the same way as deleting emails through your email client (for example Microsoft Outlook and Gmail). All contents of the email are deleted, including any attachments.
Please note that this option does NOT apply to "offline" email backups/archives/database files.
Remediation of free disk space and shadow copies
Remediation of shadow volumes are not supported.
Remediation (masking) of files within archives
Masking on archive file types such as ZIP, TAR, GZIP, is supported from version 2.0.21 onwards.
However, for GZIP and ZIP, please be warned that the process is memory intensive. We recommend that you have free RAM equivalent to the (compressed) size of the file you are trying to mask within the archive. For example, masking a 10GB text file compressed to 1GB may require up to 1GB of RAM.
All information in this article is accurate and true as of the last edited date.