[Rule Tuning] Standardize Azure / M365 Rule Contents #5035
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
w0rk3r
reviewed
Sep 2, 2025
| index = ["logs-azure.signinlogs-*"] | ||
| language = "kuery" | ||
| license = "Elastic License v2" | ||
| name = "Microsoft Entra ID SharePoint Access for User Principal via Auth Broker" |
Contributor
There was a problem hiding this comment.
Nice initiative, but what is the reason for dropping this? I think it helps with context, and it is referred by MS always as Microsoft Entra ID, like:
Contributor
Author
There was a problem hiding this comment.
@w0rk3r - Great question. Here are a few reasons I decided to drop the Microsoft string unless absolutely necessary for context.
- Keeping cloud rule names concise. If we enforce putting Microsoft behind every service, the rule names can get long and redundant. Example
User Session Reuse from Microsoft Entra ID to Microsoft Graph in Microsoft Azure - Entra ID is unique in itself and there should be no naming conflicts where context may be missed. However, for example, we should use
Microsoft GraphasGraphalone can be vague. - We don't use
Microsoft Azureeverywhere, simple Azure as we assume subjectively users know what Azure is. IMO we can say the same for Entra ID or M365. - Contextually the full product or service name should be throughout the rule contents itself. We fully say "Microsoft Entra ID", etc. in the description, investigation guides, tags, etc. so it is not missing.
Honestly, if we don't care too much about redundancy or length, I dont have a strong judgment against using the full service/product naming.
Contributor
There was a problem hiding this comment.
Makes perfect sense, I think it is positive ++
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This has been closed due to inactivity. If you feel this is an error, please re-open and include a justifying comment. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
Issue link(s):
Summary - What I changed
Standardizes rule contents and file names for Azure & M365 rules.
How To Test
No queries have been adjusted. However, files have been renamed. Diff may appear to be new rules but are just file name changes.
Checklist
bug,enhancement,schema,maintenance,Rule: New,Rule: Deprecation,Rule: Tuning,Hunt: New, orHunt: Tuningso guidelines can be generatedmeta:rapid-mergelabel if planning to merge within 24 hoursContributor checklist