How ESA Handles Sensitive DataHow ESA Handles Sensitive Data
This topic explains how ESA treats sensitive data, such as usernames or IP address, that it receives from Core services. The Data Privacy Officer (DPO) role can identify meta keys that contain sensitive data and should display obfuscated data. ESA does not display or store sensitive meta. Consequently, ESA will not pass sensitive data to NetWitness Respond.
Optionally, ESA can add an obfuscated version of the sensitive data to an event. For example, the DPO identifies user_dst as sensitive. ESA can add an obfuscated version, such as user_dst_hash, to an event. The obfuscated meta is not sensitive, so ESA will display and store it the same way as any other non-sensitive meta.
For more information on the strategy and benefits of obfuscating data, see the Data Privacy Management Guide.
This topic explains the following:
- How ESA treats sensitive data it receives from Core services
- How to prevent sensitive data leaks in an Advanced EPL rule
- How to remove sensitive meta keys from global alerts
How ESA Treats Sensitive Data from Core ServicesHow ESA Treats Sensitive Data from Core Services
When ESA receives sensitive data from Core services, ESA passes on only the obfuscated version of the data. ESA does not store or show sensitive data.
The following features are impacted:
- Outputs – ESA does not forward sensitive data to outputs, which include alerts, notifications, and MongoDB storage.
- Advanced EPL rules – If an EPL statement creates an alias for a sensitive meta key, sensitive data will leak. This topic illustrates how this happens so you can avoid it.
- Enrichments – If a sensitive meta key is used in the join condition, sensitive data will leak. This topic illustrates how this happens so you can avoid it.
Advanced EPL RuleAdvanced EPL Rule
If an EPL query statement renames a sensitive meta key, the data will not be protected.
ESA identifies a sensitive meta key by the name:
- ip_src is the sensitive meta key.
- ip_src_hash is the non-sensitive, obfuscated version.
To support data privacy, the sensitive meta key must not be renamed in an EPL query. If a sensitive meta key is renamed, the data will no longer be protected.
For example, in a rule such as select ip_src as ip_alias..., ip_alias contains the sensitive data but it is not protected because ESA only knows about ip_src, not ip_alias. In this case, IP addresses would not be obfuscated. Real values would be displayed.
Enrichment SourceEnrichment Source
When a sensitive meta key is used in a join condition, sensitive data can be displayed.
The enrichment database, which is the other part of the join condition, has one column that matches the sensitive meta key. This cross reference is to actual values not obscured values. Consequently, actual values are displayed.
In the following example, both parts of the join condition are highlighted.
- ip_src contains sensitive data.
- ipv4 will be added to the alert and exposed as non-sensitive data.
Because the ipv4 value is the same as the ip_src value, ipv4 contains and displays sensitive data.
How to Remove Sensitive Meta Keys Globally from All AlertsHow to Remove Sensitive Meta Keys Globally from All Alerts
11.4 Remove Sensitive Meta Keys from Global Alerts for Data Privacy11.4 Remove Sensitive Meta Keys from Global Alerts for Data Privacy
Note: This procedure applies only to ESA Correlation Rules in NetWitness Platform 11.4 and later versions.
For data privacy reasons, it may be necessary to remove some sensitive meta keys from the alert output globally, regardless of the data source. In the ESA Correlation service, you can set the global-private-fields parameter to remove the meta keys from all alert output.
- Go to
(Admin) > Services, and in the Services view, select an ESA Correlation service and then select
> View > Explore.
- In the Explore view node list for the ESA Correlation service, select correlation > data-privacy.
- In the global-private-fields parameter, add the sensitive meta keys that you want removed from all alerts.
The changes are effective immediately.
For more information on the strategy and benefits of obfuscating data, see the Data Privacy Management Guide.
