Feb 26 2020
06:01 AM
- last edited on
May 24 2021
02:36 PM
by
TechCommunityAP
Feb 26 2020
06:01 AM
- last edited on
May 24 2021
02:36 PM
by
TechCommunityAP
Hi Guys,
First time post so apologies if anything is in correct with the below.
I have an alert being picked up in AAD IP for a Risky Sign-in under the detection type, Unfamiliar Sign-in Properties. Usually i would see the same alert being triggered in MCAS but for what ever reason the alert hasn't been triggered. Has anyone seen anything similar before, or know why it wouldn't flag in MCAS but its does in AAD IP? Had this occur a few times now.
AAD IP triggered this alert at 2/26 7:22AM but in MCAS the first activity from this user was 2/26 7:50AM
May 20 2020 04:39 PM
Solution@MattBurrows In late January 2020, Identity Protection and MCAS started integrating, so my guess is the change in behavior you observed on 2/26/20 may have resulted from the code change from January as described here: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#two-new-identity-prot...
There is not perfect parity between MCAS and Azure Identity Protection. For example, I asked Sarah Handler (MSFT):
Q: "Azure Identity Protection already had impossible travel signal before MCAS sent its signal so are you eliminating redundancy and using MCAS’s engine for that now? If not, How does this seemingly redundant impossible travel signal add any extra value to AIP? Was AIP deficient?"
A: "The signals have very similar names, but detection logic is distinct and they are looking at different things to determine compromise. There may be overlap, but we’ve definitely seen cases where AADIP will see atypical travel and MCAS doesn’t see impossible travel and vice versa. Atypical travel is the AADIP signal and Impossible Travel is the MCAS signals. 2 things have changed in the last year: 1) we previously called the AADIP signal “Impossible travel to atypical locations” and renamed it to “Atypical travel." We integrated with MCAS to consume their Impossible Travel signal, which now shows in our UI and can influence user risk"
https://twitter.com/ITguySoCal/status/1232862860084072448
The Unfamiliar sign-in properties risk type is continuously updated.
There was a big update in August 2019:
And then another update in November 2019:
May 20 2020 04:39 PM
Solution@MattBurrows In late January 2020, Identity Protection and MCAS started integrating, so my guess is the change in behavior you observed on 2/26/20 may have resulted from the code change from January as described here: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#two-new-identity-prot...
There is not perfect parity between MCAS and Azure Identity Protection. For example, I asked Sarah Handler (MSFT):
Q: "Azure Identity Protection already had impossible travel signal before MCAS sent its signal so are you eliminating redundancy and using MCAS’s engine for that now? If not, How does this seemingly redundant impossible travel signal add any extra value to AIP? Was AIP deficient?"
A: "The signals have very similar names, but detection logic is distinct and they are looking at different things to determine compromise. There may be overlap, but we’ve definitely seen cases where AADIP will see atypical travel and MCAS doesn’t see impossible travel and vice versa. Atypical travel is the AADIP signal and Impossible Travel is the MCAS signals. 2 things have changed in the last year: 1) we previously called the AADIP signal “Impossible travel to atypical locations” and renamed it to “Atypical travel." We integrated with MCAS to consume their Impossible Travel signal, which now shows in our UI and can influence user risk"
https://twitter.com/ITguySoCal/status/1232862860084072448
The Unfamiliar sign-in properties risk type is continuously updated.
There was a big update in August 2019:
And then another update in November 2019: