[Rule Tuning] Update Azure / M365 Rule Names and File Paths

[terrancedejesus]

Pull Request

Issue link(s):

• [Rule Tuning] Update Azure / M365 Rule Names and File Paths #5164

Summary - What I changed

Standardizes rule names for Azure and M365 based on guidelines established in the related issue. Only file names, rule names and investigation guide headers were adjusted. For a comprehensive list of all Azure and M365 rules, please see the related issue.

How To Test

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

• Detailed description of the suggested changes.
• Provide example JSON data or screenshots.
• Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
• Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
• Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
• Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
• Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
• Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
• Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
• Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
• Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
• Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

• updated_date matches the date of tuning PR merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive. Review to ensure the original intent of the rule is maintained.

Testing and Validation

• Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
• Ensure that the tuned rule has a low false positive rate.

[terrancedejesus]

Note: Not merging until we coordinate internally.

[imays11]

nice work! Since you're normalizing naming conventions. Your brute force rules alternated between Brute Force "Attempt" and Brute Force "Attempted". I suggested Attempted because it seems to align more with the past tense nature of the rest of the rule names. But this is definitely a nit suggestion. Everything looks good!

[imays11]

Suggested change

	name = "M365 Identity User Brute Force Attempt"
	name = "M365 Identity User Brute Force Attempted"

[imays11]

Suggested change

	### Investigating M365 Identity User Brute Force Attempt
	### Investigating M365 Identity User Brute Force Attempted

[imays11]

Suggested change

	name = "Entra ID Sign-in Brute Force Attempt (Microsoft 365)"
	name = "Entra ID Sign-in Brute Force Attempted (Microsoft 365)"

[imays11]

Suggested change

	### Investigating Entra ID Sign-in Brute Force Attempt (Microsoft 365)
	### Investigating Entra ID Sign-in Brute Force Attempted (Microsoft 365)