Enterprise-scale SecOps: Naming conventions
Continuing on a journey started in early 2023. How to deploy a well-architected security toolkit in Azure? This time we look at resource naming conventions in Azure and Microsoft Sentinel.
Introduction
In this article I am continuing to explore some ideas related to Microsoft Sentinel architecture design. Previously in this series I’ve written one article about ‘security landing zones’:
While Microsoft Learn offers valuable resources on fundamental architectural design elements like Workspace design, and there exist comprehensive best practice white papers such as 'Microsoft Sentinel Deployment Best Practices,' certain nuances often remain unexplored.
This series aims to bridge that gap by uncovering less frequently discussed architectural patterns and design choices, particularly those proven crucial in larger Sentinel deployments with my clients.
This time we will look at naming conventions. This includes the naming of Sentinel-related Azure resources, and also artefacts inside Microsoft Sentinel such as Analytics Rules.
Azure
In general Azure Cloud Adoption Framework (CAF) has a decent document for defining your naming convention and known abbreviations for resources.
The naming convention documentation has examples for many resource types, but not for all resources we use with Sentinel.
One important thing in that document is the notion of Subscription purpose and workload Environment:
These reflect to parts of Azure resource naming. As I’ve said in my earlier article, I tend to define both of these as sec to separate the security toolkit from standard production or non-production workloads.
If the organisation has a true testing or development environment for the SecOps toolkit itself, then I might decide on prod and dev for the Environment identifiers for Sentinel-related Azure resources too.
Another key thing noted in this document is to decide if you want to include instance count as part of the naming or not:
I know this is often skipped for the resources I talk about here, as for example it is quite rare that there would ever be a second Log Analytics workspace in the same Resource Group.
However, I don’t see the Instance number as a problem, and often just use them anyway. It can be thought of as a kind of insurance, if some re-design and re-deployment next to the original resources needs to be done later.
Subscription and Resource Groups
These both are included in the CAF naming convention document, with the following conventions:
Subscription:
<business unit>-<subscription purpose>-<###>
Resource Group:
rg-<app or service name>-<subscription purpose>-<###>
My assumption here, is that Sentinel (and the entire “SecOps toolkit”) resides in it’s own Subscription and the related “business unit” is the entire organisation.
If for some reason Sentinel is in a shared subscription, then best practice is to store everything inside a single Resource Group and this part of this article does not apply so much.
This convention results in the following set of names for core Sentinel related resources that span multiple Resource Groups:
Subscription:
companyx-sec-001
Log Analytics RG:
rg-logs-sec-001
Playbook RG:
rg-automation-sec-001
Storage Account RG:
rg-storage-sec-001
Key Vault RG:
rg-secrets-sec-001
Data Collection RG:
rg-datacollection-sec-001
This list also shows you how I place different key SecOps resources so that they span multiple Resource Groups.
Log Analytics workspace
This is simple as there is usually only one LAW in the scope we are talking about, and the naming convention I use is this:
law-<organisation>-<subscription purpose>-<###>
As a result, we end up with a LAW named law-companyx-sec-001 by default.
Logic Apps
Logic Apps in the Azure SecOps context can mean either “Sentinel playbooks” which are triggered from Sentinel or Logic Apps that are triggered by something outside of Sentinel, such as a Webhook or a recurring run schedule inside the Logic App.
The naming convention needs to support both cases.
For Logic Apps I use the following convention:
la-<source>-<target>-<action>-<env>-<###>
Some examples of results from this convention are below, these would be “Isolate device entity in Defender for Endpoint” and “Scheduled fetching of incidents from a third party API to Sentinel:
la-Sentinel-MDE-IsolateDevice-sec-001
la-ProductY-Sentinel-GetIncidents-sec-001
Storage Accounts
Storage Accounts are actually found as an example in the CAF document:
st<project, app or service><###>
The name has to be under 24 characters, which pushes us to be a bit creative here.
Example for a Storage Account containing Watchlist data:
stcompxsecwatchlist001
Note that the naming scope for Storage Accounts is Global, so it needs to be globally unique and having some sort of full or abbreviated name for the organisation is likely useful. Storage accounts also only allow lowercase letters and numbers in the name.
Key Vaults
For Key Vaults that store secrets, usually used by automation Playbooks, I have the following convention:
kv-<organisation>-<app or service>-<env>-<###>
A practical example of this might be a KV to store MISP platform secrets:
kv-companyx-misp-sec-001
Note that best practice is to separate Key Vaults per application, so I don’t recommend creating one big “secops vault” to store all the secrets needed in automation.
Key Vaults are also Global, so you need to have globally unique names, and the limit is 24 characters. Thus the need to include organisation identifier, or you might end up being unable to use a name due to it being taken already. If the standard organisation name is long, I would probably consider either having a shorter version for Key Vaults, like we did for Storage Accounts (or to skip the instance numbering).
Data Collection Rules
Data Collection Rules (DCRs) are a critical part of integration engineering in Sentinel.
My naming convention for these is the following:
dcr-<source>-<target>-<content identifier>-<env>-<###>
A practical example of this might be a DCR to ingest firewall logs via Logstash:
dcr-logstash-sentinel-fortigate-sec-001
Microsoft Sentinel
Analytics Rules
Naming Analytics Rules (threat detections) can actually a surprisingly large topic if the organisation is diligent with detection engineering. I’ve written one earlier article that briefly discusses this topic.
For a large environment where I assume the amount of detections will be big, I might use the SPEED framework, which has the following naming convention for SIEM rules:
<USE CASE CATEGORY>-<USE CASE>-<#> - <SIEM RULE NAME> On <INFRASTRUCTURE VECTOR>
As a result you will build a detection knowledge base and get rule names like this:
If the team and coverage is smaller, I might push for a simplified version where we just list certain categories like this:
APP (application log based detections)
IAM (identity threat detections)
AWS (AWS detections based on CloudTrail data, GuardDuty or other services)
Then let the team name the rules how they want, as long as they use category and rule instance number identifiers. The resulting naming convention looks like this:
<category>-<###> - rule description
As a result you would end up with Analytics Rule names such as:
IAM-001 - Break Glass Account usage
AZURE-004 - Resource Lock deleted
Other Sentinel content
At least the following artefacts inside Sentinel require the user to specify custom names:
Automation Rules
Watchlists
Workbooks
Hunts
Repositories
Workspace manager Groups
Saved Queries and Functions
For all of these my most usual experience is that the naming convention can be summed up with the Oxford English Dictionary entry for the word “concise”:
giving a lot of information clearly and in a few words; brief but comprehensive
I would not be opposed to using a specific convention for Automation Rules. Maybe even for Workbooks if a lot of custom workbooks are built and some kind of categorisation seems necessary.
Conclusion
Feel free to share your thoughts in the comments on whether you'd appreciate a more tangible resource regarding this topic.
I'm considering creating a condensed table or spreadsheet version, which could be hosted on GitHub. Your feedback would be valuable in shaping the direction of this!