Internationalizing SIEM Rules

When workstations and services are used in a language other than English, some changes to detection rules are required to ensure consistent coverage

Internationalizing SIEM Rules
Photo by Hanson Lu / Unsplash

I've recently needed to apply a set of Sentinel analytics rules to organizations outside of the UK/USA where workstations and services will be used in a language other than English. This post will explore what changes are or aren't required in this situation.

What doesn't need to change

Let's start with the easy bit! When you install Windows in a language other than English; various aspects of the interface appear in the local language, this includes folder names such as Desktop, Pictures etc. However, if you open up a terminal window and examine the same directories, you'll see the names in English. Windows applies the localization at the user-interface, not the underlying filesystem. All rules that rely on folder paths do not need to be altered.

Additionally, all Microsoft 365/Entra ID/Azure strings such as Operation Names and actions remain in English. Domains such as portal.azure.com will only vary if the organization uses a different Azure Cloud, eg in China https://portal.azure.cn is used

What does need to change

I also have a few rules that rely on names of folders in Outlook, and unlike Windows, these will change to match the local language. (More details)

For example, excluding the calendar folder from certain detections requires translation. I've defined a variable at the top of the rule to make this easy to update in future. If you are reusing the same translations across multiple rules, then you might like to create a function that you can call.

Additionally, any rules which have location strings hardcoded will need to be updated. Moving the list of expected locations into a watchlist makes this easy to update.

Finally, if you are using regex to match part of a string, you may use patterns to match Latin characters (eg [a-zA-Z0-9] or \w+). It's worth noting that this will fail to match characters from other alphabets.

What might need to change

I've found detection of unusual inbox rules to be a particularly valuable indicator of mailbox compromise. Attackers frequently create rules to move or forward emails with specific words in the subject line. All of the real world attacks that I have observed have been against English-speaking organizations, so I don't know if attackers will alter the rules that they create to match other languages. To err on the side of caution, I have created translated copies of these rules which run in parallel to the English versions.

What have I missed?

There are probably other rules which need to be modified for non-English organizations that I haven't covered here, so please let me know if you are aware of any