[Rule Tuning] Multi-Factor Authentication Disabled for User

[terrancedejesus]

Pull Request

Issue link(s):

• [Rule Tuning] Multi-Factor Authentication Disabled for User #5005

Summary - What I changed

Tunes rule to include missing operation for user-initiated MFA disablement. Please see issue for more details.

How To Test

Query can be used in TRADE stack.

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.

[imays11]

Suggested change

	event.dataset: "azure.auditlogs" and
	azure.auditlogs.operation_name: "Disable Strong Authentication" or
	azure.auditlogs.operation_name: "User deleted security info" and azure.auditlogs.properties.additional_details.key: "AuthenticationMethod" and
	event.outcome: (Success or success)
	event.dataset: "azure.auditlogs" and
	azure.auditlogs.operation_name: "Disable Strong Authentication" or
	(azure.auditlogs.operation_name: "User deleted security info" and azure.auditlogs.properties.additional_details.key: "AuthenticationMethod") and
	event.outcome: (Success or success)

I'm adding the parenthesis for clarity because initially I thought you were looking for ("Disable Strong Auth" OR "User deleted security info") AND azure.auditlogs.properties.additional_details.key: "AuthenticationMethod"

But when I put both versions of parenthesis into the stack the one I've suggested here captures events for both these azure.auditlogs.operation_name, where as the one I initially thought would have excluded one. This is expected correct?

[terrancedejesus]

Parenthesis causes a KQL query optimization failure which is why none are included. The reason you see one result with your parenthesis is because AuthenticationMethod is not a data point when operation is Disable Strong Authentication.

[Samirbous]

@terrancedejesus event.outcome: (Success or success) is not evaluated for azure.auditlogs.operation_name: "Disable Strong Authentication" so it may match also on failure ?

[imays11]

For consistency across the rulesets could you add the datasource to the beginning of the name? Across the Azure ruleset I've seen a mix of "Microsoft Entra ID" and "Azure Entra" used, not sure which is appropriate here.

Suggested change

	name = "Multi-Factor Authentication Disabled for User"
	name = "Microsoft Entra ID Multi-Factor Authentication Disabled for User"

[imays11]

Suggested change

	### Investigating Multi-Factor Authentication Disabled for User
	### Investigating Microsoft Entra ID Multi-Factor Authentication Disabled for User

[terrancedejesus]

There is no standard practice on this. May be a good idea to determine what is ideal moving forward. Always including names of the data source overlaps with the purpose of the rule tags, related integrations and target indices. Whatever we agree on, we should then open a PR to standardize it. If we standardize including integrations, then that would effect Elastic Defend rules and we would be putting Elastic Defend on every rule.

[imays11]

why the change to low?

[terrancedejesus]

• MFA disabled does not immediately indicate malicious behavior
• MFA being disabled, while not extremely noisy, is more likely a benign TP
• Expecting a steady volume of benign TPs over time that we will not be able to tune but rather use the alerts and correlation when triaging

[Samirbous]

@terrancedejesus I would recommend to instead bump it to high, it's a low noise and very susp behavior, unless the added condition "User deleted security info" is expected to be noisier, if that's the case keep it as medium, observe telem and downgrade/bump-up severity. low is a bit risky for such events. OR convert the rule to newterm by
azure.auditlogs.properties.initiated_by.app.servicePrincipalName with riks set to high ?

[Samirbous]

@terrancedejesus event.outcome: (Success or success) is not evaluated for azure.auditlogs.operation_name: "Disable Strong Authentication" so it may match also on failure ?

[Samirbous]

@terrancedejesus I would recommend to instead bump it to high, it's a low noise and very susp behavior, unless the added condition "User deleted security info" is expected to be noisier, if that's the case keep it as medium, observe telem and downgrade/bump-up severity. low is a bit risky for such events. OR convert the rule to newterm by
azure.auditlogs.properties.initiated_by.app.servicePrincipalName with riks set to high ?