Obfuscate strings in KQL queries

Previously, I wrote about understanding Azure Log Analytics query auditing. I since have had several conversations about what goes into an audit log and what can be protected.

The previous post was about Log Analytics. This post is about Azure Data Explorer and how to protect sensitive strings in your queries. It's effortless and something worth knowing.

ADX Query logs

In Azure Data Explorer (ADX), you can pull up a log of the most recent queries to your cluster like this:

.show queries

You will see a list of the queries, including a defined set of metadata around the query:

You can also show queries from the last few minutes to clean up the log view:

.show queries
| where StartedOn >= ago(5m)

You can then review the most recent logs from the last 5 minutes, as in my example.

If your queries contain sensitive information, for example, Personally Identifiable Information (PII), API keys, user accounts, or any information you wouldn't want to disclose in any plain-text logs, you should consider protecting them.

With KQL, you can easily construct your queries to protect sensitive strings; this way, the audit logs will redact that portion of your protected string but still be a valid audit trail that can serve the use cases we talked about previously.

Protected strings in queries would instead show you this result in the query log:

Let's set the scene. Here are two elementary examples. The first one is querying based on regular unobfuscated strings, and the second example shows how to ensure you protect the input easily.

Without obfuscation:

securityAudits
| where Status  != "Succeeded" 
    and PersonalIdentifier == "no-thanks@zimmergren.net"

With obfuscation:

securityAudits
| where Status  != "Succeeded" 
    and PersonalIdentifier == h"no-thanks@zimmergren.net"

Notably, the only difference is that you append h or H to your string literals to protect them. It's easy as 1-2-3 but can be a game-changer for your security and compliance journey.

Read more:

• Obfuscated string literals in KQL (Microsoft Docs)