Add Locations to SuccessThenFail_DiffIP_SameUserandApp.yaml

[tduarte14]

Added Success and Failed Locations
Fixed SuccessIPBlock to also consider IPV6

Required items, please complete

Change(s):

• Added Success and Failed Locations
• Fixed SuccessIPBlock to consider IPv6

Reason for Change(s):

• Locations are very useful for whitelisting known activity
• IPv6 are now more used than before, so it makes sense to have that into account

Version Updated:

• Yes

Testing Completed:

• Yes

Checked that the validations are passing and have addressed any issues that are present:

• Yes

[v-prasadboke]

Hello @tduarte14, Thank you for raising this PR. We will examine this PR and update you about the same before 05 September, 2023.

[v-prasadboke]

Hello @tduarte14, The description is crossing 255 character. Try to reduce it below the count.

"Detects a user’s successful and failed logins to an Azure App from different IPs within 10 mins. This could mean password guessing by an attacker. The query also uses UEBA logs for more context."

Please check if the above descriptions suits.

And also can you please share the results/ running screenshots of the detection, as we dont have the sample data to test it.

Thanks.

[tduarte14]

Hello @tduarte14, The description is crossing 255 character. Try to reduce it below the count.

"Detects a user’s successful and failed logins to an Azure App from different IPs within 10 mins. This could mean password guessing by an attacker. The query also uses UEBA logs for more context."

Please check if the above descriptions suits.

And also can you please share the results/ running screenshots of the detection, as we dont have the sample data to test it.

Thanks.

Hi,

I haven't changed the description, just added the location fields and fixed the IPBlock to consider IPv6.

As for the results, this was never requested and I tested in many different environments, however cannot share them as they are in customer environments, so due to privacy, I cannot share it.

[v-prasadboke]

Hello @tduarte14, As per new guidelines. Description of Hunting query and Analytic rule should be below 255 characters.
That's the reason I asked you to shorten the description.

So for Detection can you share sample data to test the content,
Thanks.

[v-prasadboke]

Hello @tduarte14, Hope you are doing well. Can you please respond to the above requested changes.

[v-prasadboke]

Hello @tduarte14, It's been a while we haven't heard from you. Please respond to the above mentioned changes & data.
Thanks.

[v-prasadboke]

Hello @tduarte14, Please respond to the above comments.

[tduarte14]

Apologies, but had no time these days to get back here.
Changes were now made.

I continue saying this, it's not my responsibility to change the description, it wasn't I that did that, it was done on the previous commit by someone when they added the UEBA sources, where description was "increased" in size.

I also fixed a problem of that commit where the person removed the line that contained the declaration of Name and UPNSuffix which are necessary for Entities match.

I cannot provide data for testing as it's customer data and I cannot share it as may understand for privacy concerns. Unless you want a big problem for Microsoft by requesting that.

The changes I made were heavily tested (more than the last commit that broke the query and nobody noticed that).

Thank you

[v-prasadboke]

Hello @tduarte14, Thank you for responding. That should be enough as you heavily affirm on testing and working on the analytic rule. As to maintain integrity, you are unable to share sample data then its ok. I'll just check for what the KQL validation is failing

[tduarte14]

Hi Prasad, I noticed a bad copy paste on the last commit, so it was fixed and it's running checks again.
I enabled Azure DevOps to allow some checks that weren't going through (that's probably what you were talking about).

[tduarte14]

Thanks everyone!