Satisnet Ltd, Basepoint Innovation Centre, 110 Butterfield Great Marlings, Luton, Bedfordshire, LU2 8DL
+44 (0) 1582 434320

Data Obfuscation in QRadar

Data Obfuscation in QRadar

Data Obfuscation in QRadar


Obfuscation was introduced in release 7.2.6 as a means of encrypting payload data fields both on the database and within the GUI. The most obvious candidates for obfuscation are personal data or credit card numbers but any normalised field can be encrypted.

When obfuscation is enabled QRadar masks the incoming event data as it is received. Obfuscation cannot be applied retrospectively so data received prior to enabling obfuscation will remain in clear text form. This also applies to offenses and assets so to avoid data being visible they should be removed and in the case of assets, re-created.

It must be remembered that QRadar will not perform de-encryption so if user names are encrypted, any actions based upon user name will no longer work as expected. This is especially true within a rule set.


In the Admin tab, under data sources, is an icon “Data Obfuscation Management” which when clicked will display a panel listing existing profiles. From here, clicking Add will display a pop-up allowing a new profile to be created. The most important element is the generation of an obfuscation keystore. This must be downloaded and retained in a safe location. This key is used to de-crypt all data obfuscated under this profile.

The next step is to add expressions to the profile, each one designed to target a specific field within the payload. Highlight the profile and click “View Content” from the resulting pop-up, clicking “Add” allows for a new expression to be defined. The important point here is the decision to use “Field Based” or “RegEx” to identify the data to be encrypted. Two points must be considered. If the field is used in multiple payloads, user name for example, using the “Field Based” option will result in all instances of user name being encrypted. The second point is that any RegEx should be thoroughly tested before enablement to ensure accuracy. Using a custom property is a useful way of ensuring that just the required field is targeted.


Once the profile is finished, that is all expressions have been added and enabled, then the profile itself should be enabled which will then be automatically locked. The keystore entry is now needed to un-lock the profile and disable the obfuscation.

Just remember, if you obfuscate a field that you are value-testing, the test will fail once the obfuscation profile is enabled.