Smbexec passes the hash like


This topic explains how ESA handles sensitive data, such as: B. Usernames or IP addresses obtained from Security Analytics core services. The data privacy officer (DPO) role can identify meta keys that contain sensitive data and should indicate obfuscated data. ESA does not display or store sensitive metadata. As a result, ESA does not pass confidential data on to Incident Management.

Optionally, ESA can add a disguised version of the confidential data to an event. For example, the DPO identifies user_dst as confidential. ESA can add an obfuscated version, such as user_dst_hash, to an event. The obfuscated metadata is not sensitive, so ESA can view and store it in the same way as any other non-sensitive metadata.

For more information on the strategy and benefits of data obfuscation, see the Security Analytics guidelines for data protection management.

This topic explains the following:

  • How ESA handles sensitive data coming from Security Analytics Core
  • How to prevent leaks of confidential data in an extended EPL rule

How ESA handles confidential data from Security Analytics Core

When ESA receives sensitive data from Security Analytics Core, ESA only forwards the obfuscated version of the data. ESA does not store or display sensitive data.

The following functions are affected:

  • Issues: ESA does not forward sensitive data to expenses, including alerts, notifications, and MongoDB storage.
  • Extended EPL Rules: When an EPL statement creates an alias for a sensitive meta key, there is a confidential data leak. This topic illustrates how that happens so you can prevent it.
  • Enhancements: If a sensitive meta key is used in the link condition, a leak of confidential data occurs. This topic illustrates how that happens so you can prevent it.

Extended EPL rule

If an EPL query statement renames a sensitive meta key, the data is not protected.

ESA identifies a confidential meta key by name:

ip_src is the confidential meta key.
ip_src_hash is the non-confidential, obfuscated version.

To support data protection, the confidential meta key must not be renamed in an EPL query. If a sensitive meta key is renamed, the data is no longer protected.

Example: In a rule like select ip_src as ip_alias ... ip_alias contains the confidential data. However, these are not protected because ESA only knows ip_src, but not ip_alias. In this case, the IP addresses would not be obfuscated. Real values ​​would be displayed.

Expansion source

When a sensitive meta key is used in a link condition, sensitive data cannot be displayed.

The extension database, the other part of the association database, has a column that corresponds to the meta sensitive key. This cross-reference refers to actual values, not obfuscated values. As a result, actual values ​​are displayed.

The following example highlights both parts of the link condition.

  • ip_src contains sensitive data.
  • ipv4 is added to the alert and is at risk as a non-sensitive data item

Since the ipv4 value is the same as the ip_src value, ipv4 contains and displays confidential data.