This topic explains how ESA treats sensitive data, such as usernames or IP address, that it receives from Security Analytics core. The Data Privacy Officer (DPO) role can identify meta keys that contain sensitive data and should display obfuscated data. ESA will not display or store sensitive meta. Consequently, ESA will not pass sensitive data to Incident Management.
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 Security Analytics Data Privacy Management Guide.
This topic explains the following:
- How ESA treats sensitive data it receives from Security Analytics core
- How to prevent sensitive data leaks in an Advanced EPL rule
How ESA Treats Sensitive Data from Security Analytics Core
When ESA receives sensitive data from Security Analytics core, 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 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.
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.