Privacy by Design

By design, ActivID Appliance does not output Secret Information. On the other hand, PII data can be present in the:

  • Audit Logs – PII data is stored anonymized (that is, tokenized) in the audit trail. PII data is mapped to replacement token values, and can be converted into ‘clear’ data on demand.

    • Even in the anonymized state, the PII data is searchable.

  • Troubleshooting Logs – in order to protect the PII data, and still be able to share the log files in order to troubleshoot issues, the data is anonymized.

Anonymize Data in the Audit Log

Starting with ActivID Appliance 8.2, the PII data of audit log events is anonymized.

Anonymizing audit data enables exporting the audit events trail without fear of exposing PIIs and other sensitive information that it might contain. For example, once ‘anonymized’, these records can be used to feed a SIEM and detect anomalies that could be symptoms of an attack.

As a reminder, GDPR mandates notifying users of data breaches that include their personal data. This involves the ability to detect such breaches. For this purpose, analyzing the authentication and access records for anomalies can be extremely valuable.

Conversely, before 8.2, audit log PII data was not anonymized. This implies that, as a Data Controller, it is strongly recommended that you do not share audit log archives (.csv files) generated before 8.2 with external systems without consulting your security/legal department, as there might be a risk of breaking GDPR compliance.

Furthermore, you should check with your legal team concerning the status of the audit regarding the Right to be forgotten. It is recommended that you encrypt these files and delete them once they are not required - depending on your business and legal constraints.

Note: After 8.2, the online audit log might contain anonymized and non-anonymized (generated before 8.2) events. To help differentiate, the ActivID Appliance 8.3 database procedures are updated to generate .csv files for the events that are anonymized. These files have the _OBF suffix (for example, ARCHIVE_ONLINEBANK_OBF_DAY_20181205.csv) and are safe to export. The non-anonymized events are exported to files without the OBF suffix and are not safe to export. As such, they are to be treated like other files generated before 8.2.
Note: If required, you can de-anonymize (or re-identify) the user data in an audit archive using the Archive Audit Detokenizer tool available on the ActivID Appliance Companion delivery disk.

Example of a tokenized audit record (data in bold are tokens):

{
"sequencegeneratorpoolname": "DOPA_1",
"sequencegeneratorid": 1,
"sequencenumber": 704,
"timestamp": 1523278057477,
"response": "SUCCESS",
"parameters": "{\"ATC\":\"AT_CUSTPW\",\"USN\":\"null\",\"Action\":\"indirectPrimaryAuthenticateUP\",\"ANS\":\"false\",\"ARP\":\"\"}",
"userid": 6238449424879850520,
"targetuserid": 4530108424857105875,
"status": "RESPONSE_SUCCESS",
"sessionid": "d4be79a1134d8425c20787de805ba228a4ae8fd04eb924953826ae0c68705a5b",
"indirectsessionid": "16d2362f19826b7a87c5ba5dfa088f2ebabd338bdbf674d0d51255a869bb17aa",
"channel": "CH_CSTPORT",
"eventid": "indirectPrimaryAuthenticateUP",
"directextref": "dd68dda4-23d9-4173-9a8b-d8225e42c0c3",
"indirectextref": "a41e998d-2d24-4985-bf45-9029a84ee106",
"authtypecode": "AT_CUSTPW",
"auditsignature": "{HID-IA-4T.AUDIT.1,HMAC-SHA256}.AcbRuOKxHW2ookIUDoFXXGglNnQTr8sxs1wMAympVTw=",
"obfuscated": "T"
}

Anonymize Data in the Troubleshooting Logs

Starting with ActivID Appliance 8.3, the PII data is anonymized in the troubleshooting logs of a generated diagnostic package.

The following data is anonymized in ActivID Appliance log files:

Domain name User id
Device serial number Wallet id
Authentication record id Admin group code/User type code
Admin group name/User type name Credential code
Credential serial number Hostname/IP Address
Asset code Asset name
Asset set code Asset set name
Asset type code Asset type name
SAMLResponse User Attribute Value
User name  

ActivID Appliance anonymizes the PII data by replacing them with their associated replacement values followed by a counter and a sub-counter.

If access to the PII data is required, a substitution file is also generated, allowing to retrieve the exact original value.

Best Practices for Backup and Report Data

As a best practice, it is strongly recommended that you regularly purge your backup and report data files to ensure compliance with GDPR regulations, such as the ‘right to be forgotten’.

While ActivID Appliance effectively deletes users from the database – and does not simply mark them as deleted (ActivID Appliance even provides the ability to clear every token related to a deleted user, in order to remove their tracks from the audit trail if mandated) – you should avoid keeping the backup for long periods of time. If you restore the backup, any users deleted between the moment backup was created and the moment it was restored would need to be deleted again.

This is why it is recommended that you implement a process which performs regular backups, and deletes deprecated backups automatically as soon as possible. The same applies to data extracted using ActivID Appliance Reports views.

Although the user secret information (password, credentials, etc) is encrypted in the database and not present in reporting view data, it is strongly recommend that you encrypt the database backups and report view data in order not to expose the user PII data. The same applies also to any user data that is extracted by external applications using ActivID Appliance APIs.