What type of security risks is Azure AD identity protection designed to detect and analyze?
|
Azure AD Identity Protection is one of the security tools available in the Microsoft E5 license. With Azure AD Identity Protection it is possible to protect users based on the Microsoft signals. Azure AD Identity protection is all about risk, detection, and remediation based on the identity level. Microsoft uses threat intelligence to specify risky detection for all users. This blog is about all the parts of Azure AD Identity Protection. Show
What is Azure AD Identity Protection?For several years Azure AD Identity Protection is available with the Azure AD P2 license. Azure AD Identity Protection gives the following key tasks for organizations:
Identity Protection uses the threat intelligence information from AzureAD and all the threat intelligence information from customers worldwide. Based on the analyzed events Microsoft protects users from threats. Two main risk detection components are part of the Azure AD Identity Protection solution:
User RiskA user risk represents the probability that a given identity or account is compromised. The user risk detections are calculated offline using the Microsoft internal and external intelligence feed.
Sign-in RiskA sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. Examples for sign-in risk:
Risk can be calculated in real-time or offline using threat intelligence. More sign-in risk scenarios, later in the blog. RequirementsFor all the functionality functions, an Azure AD Premium P2 license is necessary. Azure AD Premium P2 is needed for all the Identity Protection features. Configure Azure AD Identity ProtectionFor Azure AD Identity Protection, multiple policies should be enabled to use the full capabilities of Identity Protection. Keep in mind that there will be user impact. User-risk policyEnabling this policy will have an impact on the users that are flagged as risky. Always start small with a pilot group and audit first.
Sign-in risk policyEnabling this policy will have an impact on the users that are flagged as risky. Always start small with a pilot group and audit first.
Now the sign-in risk policy and user risk policy are configured. The next part; notifications. NotificationsIt’s advisable to review the risky users and sign in frequently to optimize the impact and detect possible changes for the sign-in risk level. From the Defender for Identity portal, it is possible to configure some notifications based on a risk level.  For configuring the notifications:
Weekly email digest The weekly email digest can help you to review the risky every week and gives also a weekly overview. For configuring the weekly email digest; click notify – Weekly digest Portal overviewOnce opened the Identity Protection page. The portal gives a summary overview of the new risky user detected and sign-in risk detection. Keep in mind, my demo tenant contains limited users and the data is limited in the overview dashboard. ReportUnder reports, we can find advanced reports on risky users, risky sign-ins, and risk detections with all the available information. The report blade is available for the following views:
From the reports view, you have the option to click for more details and some actions. Actions available:
From the risky sign-ins screen it is possible to use a couple of useful filters. For example; detection type(s) and the selected risk level real-time status. From the details info field, you have the option to view the Device info, Risk info, MFA info. Interesting is the Risk info detection type field: In this case, the Tor sign-in is based on the risk detection: Anonymous IP address. Live demoFor this demo, a policy is created and signed in from a tor browser network. Suspicious activity is detected. To verify the sign-in use the verify button from the screen: Sign-in risk with the Sign-in risk policy block access control configured: Continuous Access Evaluation (CAE)Make sure to enable Access Evaluation (CAE) for direct actions. For the CAE part, read the Continuous Acces Evaluation blogpost with all the details included. CAE enabled experience: https://jeffreyappel.nl/wp-content/uploads/2020/10/CAE-enabled.mp4 Good to knowFeedback to the system is possible if the user sign-in is safe. Good to know the difference between confirm safe and dismiss user risk. Selecting confirm safe on a sign-in does not by itself prevent future sign-ins with the same properties from being flagged as risky. The best way to train the system to learn a user’s properties is to use the risky sign-in policy with MFA. When risky sign-ins are prompted for MFA and the user successfully responds to the request, the sign-in can succeed and help to train the system on the legitimate user’s behavior. If you believe the user is not compromised, use Dismiss user risk on the user level instead of using Confirmed safe on the sign-in level. A Dismiss user risk on the user level closes the user risk and all past risky sign-ins and risk detections. Leaked credentials? What is itLeaked credentials are based on multiple places, including the following places. For example the following places are including:
For the leaked credential risk events make sure you have Password Hash synchronization enabled. Sign-in riskFor all the information about the Sign-in risk detection inside the Azure AD identity protection view. Source: Microsoft.com Risk detectionDescriptionAnonymous IP addressReal-timeThis risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN). These IP addresses are typically used by actors who want to hide their login telemetry (IP address, location, device, etc.) for potentially malicious intent.Atypical travelOfflineThis risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. Among several other factors, this machine learning algorithm takes into account the time between the two sign-ins and the time it would have taken for the user to travel from the first location to the second, indicating that a different user is using the same credentials.The algorithm ignores obvious “false positives” contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of the earliest of 14 days or 10 logins, during which it learns a new user’s sign-in behavior. Malware linked IP addressOfflineThis risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server. This detection is determined by correlating IP addresses of the user’s device against IP addresses that were in contact with a bot server while the bot server was active.Unfamiliar sign-in propertiesReal-timeThis risk detection type considers past sign-in history (IP, Latitude / Longitude and ASN) to look for anomalous sign-ins. The system stores information about previous locations used by a user, and considers these “familiar” locations. The risk detection is triggered when the sign-in occurs from a location that’s not already in the list of familiar locations. Newly created users will be in “learning mode” for a period of time in which unfamiliar sign-in properties risk detections will be turned off while our algorithms learn the user’s behavior. The learning mode duration is dynamic and depends on how much time it takes the algorithm to gather enough information about the user’s sign-in patterns. The minimum duration is five days. A user can go back into learning mode after a long period of inactivity. The system also ignores sign-ins from familiar devices, and locations that are geographically close to a familiar location.We also run this detection for basic authentication (or legacy protocols). Because these protocols do not have modern properties such as client ID, there is limited telemetry to reduce false positives. We recommend our customers to move to modern authentication. Admin confirmed user compromisedOfflineThis detection indicates an admin has selected ‘Confirm user compromised’ in the Risky users UI or using riskyUsers API. To see which admin has confirmed this user compromised, check the user’s risk history (via UI or API).Malicious IP addressOfflineThis detection indicates sign-in from a malicious IP address. An IP address is considered malicious based on high failure rates because of invalid credentials received from the IP address or other IP reputation sources.Suspicious inbox manipulation rulesOfflineThis detection is discovered by Microsoft Cloud App Security (MCAS). This detection looks for suspicious email forwarding rules, for example, if a user created an inbox rule that forwards a copy of all emails to an external address.What types of risks are there in Azure AD?Some of the following actions may trigger Azure AD Identity Protection risk detection:. Users with leaked credentials.. Sign-ins from anonymous IP addresses.. Impossible travel to atypical locations.. Sign-ins from infected devices.. Sign-ins from IP addresses with suspicious activity.. Sign-ins from unfamiliar locations.. What are the three types of Azure AD identity protection policies?Users must have previously registered for Azure AD multifactor authentication before triggering the sign-in risk policy.. Block access.. Allow access.. Require multifactor authentication.. What are the 3 main identity types used in Azure AD?Azure AD manages different types of identities:. User. User identity is a representation of something that's Azure AD manages. ... . Service principal. A service principal is a secure identity that enables an application or service to access Azure resources. ... . Managed identity. ... . Device.. What administrators will receive users at risk detection alerts from Azure AD identity protection?Configure users at risk detected alerts
The user risk level that triggers the generation of this email - By default, the risk level is set to “High” risk. The recipients of this email - Users in the Global Administrator, Security Administrator, or Security Reader roles are automatically added to this list.
|
