Redundant rule templates about MFA Rejection/Deny

[roniegh]

There are two redundant rule templates for basically the same thing. Please merge them or at least add a deprecation warning to the legacy one.

• https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Microsoft%20Entra%20ID/Analytic%20Rules/ExplicitMFADeny.yaml

• https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Microsoft%20Entra%20ID/Analytic%20Rules/MFARejectedbyUser.yaml

[v-sudkharat]

Hi @roniegh, Thanks for flagging this issue, we will investigate this issue and get back to you with some updates by 03-05-2024. Thanks!

[v-sudkharat]

Hey @roniegh, Thanks for highlighting the templates. As per the use case description of both templates, they can be used as MFA denies/rejected. but the "MFA Rejected by User" rule is more enhanced to identifying potentially compromised accounts by considering user behavior and risk factors as compared to "Explicit MFA Deny". Sharing doc for more detail's info and reference:-
https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-failed-unusual-sign-ins
So, closing this issue. If you still need support for this issue, feel free to re-open it any time. Thank you for your co-operation.

[roniegh]

Hey @roniegh, Thanks for highlighting the templates. As per the use case description of both templates, they can be used as MFA denies/rejected. but the "MFA Rejected by User" rule is more enhanced to identifying potentially compromised accounts by considering user behavior and risk factors as compared to "Explicit MFA Deny". Sharing doc for more detail's info and reference:- https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-failed-unusual-sign-ins So, closing this issue. If you still need support for this issue, feel free to re-open it any time. Thank you for your co-operation.

@v-sudkharat I didn't find anything on the aforementioned doc in regards to diferences between the redundant rules. The only reference I see is a link to a past version of the MFARejectedbyUser rule.

Both rules query the same table SigninLogs with virtually the same where clause. While the MFARejectedbyUser rule returns more information, the ExplicitMFADeny rule also queries the AADNonInteractiveUserSignInLogs table.

Also, as you can see by @shainw post in #3516 (comment) the MFARejectedbyUser rule was added without checking if such a rule already existed.

Could you please explain what you mean by "MFA Rejected by User rule is more enhanced to identifying potentially compromised accounts by considering user behavior and risk factors as compared to Explicit MFA Deny" ?

Please reopen this issue.

[v-sudkharat]

@roniegh, Sure, Happy to reopen this case and share info with you.
Agreed to your comment, both the tables are using same table name and also having same target, but it is having the difference in connector id's they are using. Like "MFA Rejected by User" rule uses BehaviorAnalytics connector, which allows for a more comprehensive analysis by considering behavioral patterns and risk factors associated with user activities. And Explicit MFA Deny uses the MicrosoftThreatProtection one. So completely removing the rule will may affect to other customer if they have configured it with the different sources. Regarding to the deprecation of old one, let us check with @shainw, if they have any plan for it.

Thanks!

[roniegh]

@roniegh, Sure, Happy to reopen this case and share info with you. Agreed to your comment, both the tables are using same table name and also having same target, but it is having the difference in connector id's they are using. Like "MFA Rejected by User" rule uses BehaviorAnalytics connector, which allows for a more comprehensive analysis by considering behavioral patterns and risk factors associated with user activities. And Explicit MFA Deny uses the MicrosoftThreatProtection one. So completely removing the rule will may affect to other customer if they have configured it with the different sources. Regarding to the deprecation of old one, let us check with @shainw, if they have any plan for it.

Thanks!

@v-sudkharat Could you please explain how MFARejectedbyUser's current code is doing the "more comprehensive analysis by considering behavioral patterns and risk factors associated with user activities" ?

[v-sudkharat]

@roniegh, Sure, Happy to reopen this case and share info with you. Agreed to your comment, both the tables are using same table name and also having same target, but it is having the difference in connector id's they are using. Like "MFA Rejected by User" rule uses BehaviorAnalytics connector, which allows for a more comprehensive analysis by considering behavioral patterns and risk factors associated with user activities. And Explicit MFA Deny uses the MicrosoftThreatProtection one. So completely removing the rule will may affect to other customer if they have configured it with the different sources. Regarding to the deprecation of old one, let us check with @shainw, if they have any plan for it.

Thanks!

Sure. Adding to it, as it is having logs from BehaviorAnalytics. These logs provide insights into various aspects of behavior, such as failed attempts, activity insights and investigation priorities associated with IP addresses. Which is into below query -

By incorporating these additional logs, the rule can analyze behavioral patterns and risk factors associated with user activities more comprehensively.
In addition, we reached out with the respective team to check on Deprecation/merge rule. Thanks!

[shainw]

@ashwin-patil - please have a look at this.