Hi Agustin,
Apologies for the delay. I spoke with our amazing PD team and they provided this information...
Yes, Imperva SecureSphere DAM provides capabilities to mask sensitive data in the audit logs that are forwarded to a SIEM.
This is not a direct "mask SIEM log" switch. Instead, data masking is configured at the Database Service level. When you enable masking at this level, the data is masked in alerts, violations, and the audit data itself. The logs forwarded to your SIEM are built from this audit data, so the masking is applied before the log is ever sent.
The masking can be configured to either redact the data (do not display value) or mask it using patterns (e.g., replacing with asterisks) based on sensitive data dictionaries.
Here is the step-by-step procedure to configure data masking for your audit logs.
Step 1: Configure Data Masking on the Database Service
This procedure defines what data to mask and how to mask it at the source.
1. Navigate to the Main workspace.
2. Go to Setup > Sites.
3. In the Sites Tree pane on the left, expand your Site and Server Group, and select the specific Database Service for which you want to mask data.
4. In the details pane for that service, click the Operation tab.
5. Expand the Data Masking pane .
6. You will see two primary sections. To mask data in SIEM logs, you must configure Requests (Alerts, Violations and DB Audit) :
○ This section controls masking for raw queries and bind variables that are recorded in the audit log.
7. You can also configure DB Audit Responses if your audit policies collect database responses and you need those masked as well .
8. For the desired section, choose the Masking Method :
○ No Masking: (Default) No data will be masked.
○ Do Not Display Value: This will completely redact the sensitive data from the logs.
○ Apply Sensitive Data Dictionaries: This will mask data (e.g., xxxx-xxxx-xxxx-1234) based on patterns you have defined in your Sensitive Data Dictionaries.
9. You can apply this masking method granularly :
○ All Columns: Applies the method to all data.
○ All Sensitive Columns: Applies the method only to columns found in tables defined in a "Sensitive Table Group".
○ Specific Table Groups / Specific Tables and Columns: Allows you to define specific tables or columns to which the masking method will apply.
Step 2: Verify Your Audit Policy and SIEM Action Set
For the masking to apply, you must be auditing the data and forwarding it to your SIEM. The masking you configured in Step 1 is applied to the data collected by the following policies.
1. Verify Audit Policy:
○ Navigate to Main > Policies > Audit.
○ Select the audit policy that is capturing the sensitive data (e.g., "Default Rule - All Events").
○ Ensure this policy is applied to the Database Service you configured in Step 1.
2. Verify SIEM/Syslog Action Set:
○ An audit policy sends data to a SIEM using an Action Set defined in the External Logger tab of the policy .
○ This Action Set (e.g., "SIEM Audit Interface") typically uses an Action Interface of type "Gateway Syslog" (e.g., Log audit events to System Log (Gateway syslog)) .
○ The Message field of this Action Interface uses Placeholders (like ${Event.struct.query.parsedQuery} or ${Event.struct.rawData.rawData}) to build the log message .
○ When you enable data masking on the Database Service (Step 1), SecureSphere masks the sensitive data before it populates these placeholders.
Step 3: (If Necessary) Configure Sensitive Data Dictionaries
If you chose the "Apply Sensitive Data Dictionaries" masking method, you must ensure those dictionaries are configured.
1. Navigate to Main > Setup > Global Objects.
2. From the Scope Selection dropdown, select Sensitive Data Dictionary Groups .
3. Here you can create or edit dictionaries to define the specific patterns (like credit card numbers or social security numbers) that you want the masking engine to find and mask .
Summary of Logic
To mask data forwarded to a SIEM, you must configure masking at the Database Service level (Main > Setup > Sites > [Your Service] > Operation > Data Masking). This ensures the data is masked in the audit log itself. The SIEM-forwarding action set then uses this already-masked audit data to build the syslog message, ensuring sensitive data is not sent in clear text .
Warning: Personal Information Masking (GUI)
There is a separate, distinct feature named Personal Information Masking (configured in dam.properties ) that masks data within the SecureSphere GUI for certain roles . This feature does not control the masking of data being sent to external SIEMs via syslog action interfaces. You must use the Data Masking Options on the Database Service as described above to redact data from SIEM logs.
------------------------------
Sarah Lamont
Digital Community Manager
------------------------------
Original Message:
Sent: 10-26-2025 13:07
From: Agustin Cudiamat
Subject: Does Imperva DAM provide a capability for data masking or redaction of sensitive data within the audit/security logs that are forwarded to a SIEM?
Hi All,
Firstly, I can confirm that the DAM data masking is correctly configured and working: sensitive data is not readable in local alerts, reports, and the GUI.
Secondly, I have configured an Action Set in Imperva DAM to forward audit/security logs to our SIEM, including the 'Parsed Query' parameter in the CEF message.
During testing, when a user executed an ALTER USER command, it was correctly flagged as a custom violation and sent to the SIEM. However, in the SIEM log's 'Parsed Query' column, the user's password remains visible/unmasked (e.g., alter user sys identified by password).
What is the recommended method to ensure that sensitive data, such as the password field within the 'Parsed Query', is masked or redacted before the audit logs are forwarded to the SIEM?
#DatabaseActivityMonitoring #DAM #DataMasking
#DatabaseActivityMonitoring
------------------------------
Agustin Cudiamat
Field Engineer
Singapore
------------------------------