Microsoft Azure Identity Protection Respond Procedures and Action Explaination

 Identity Protection is a tool that allows organizations to accomplish three key tasks:

• Automate the detection and remediation of identity-based risks.
• Investigate risks using data in the portal.
• Export risk detection data to third-party utilities for further analysis.

Automation will help to block three top attacks:

• Breach replay: 
• Password spray: 
• Phishing: 

Identity Protection identifies risks in the following classifications:

RISK DETECTION AND REMEDIATION

Risk detection type	Description
Atypical travel	Sign in from an atypical location based on the user's recent sign-ins.
Anonymous IP address	Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs).
Unfamiliar sign-in properties	Sign in with properties we've not seen recently for the given user.
Malware linked IP address	Sign in from a malware linked IP address.
Leaked Credentials	Indicates that the user's valid credentials have been leaked.
Password spray	Indicates that multiple usernames are being attacked using common passwords in a unified, brute-force manner.
Azure AD threat intelligence	Microsoft's internal and external threat intelligence sources have identified a known attack pattern.

Policy Enable (User Risk and Sign-In Risk Policy)

Investigate

Risky users

With the information provided by the risky users report, administrators can find:

• Which users are at risk, have had risk remediated, or have had risk dismissed?
• Details about detections
• History of all risky sign-ins
• Risk history

Administrators can then choose to take action on these events. Administrators can choose to:

• Reset the user password (Not Security Administrator)
• Confirm user compromise
• Dismiss user risk
• Block user from signing in (Not Security Administrator)
• Investigate further using Azure ATP

Risky sign-ins

The risky sign-ins report contains filterable data for up to the past 30 days (1 month).

With the information provided by the risky sign-ins report, administrators can find:

• Which sign-ins are classified as at risk, confirmed compromised, confirmed safe, dismissed, or remediated.
• Real-time and aggregate risk levels associated with sign-in attempts.
• Detection types triggered
• Conditional Access policies applied
• MFA details
• Device information
• Application information
• Location information

Administrators can then choose to take action on these events. Administrators can choose to:

• Confirm sign-in compromise
• Confirm sign-in safe

Best Practice - Self-Remediation with Risk Policy

By allowing users to self-remediate, with Azure Multi-Factor Authentication (MFA) and self-service password reset (SSPR) in the risk policies, they can unblock themselves when risk is detected. These detections are then considered closed. Users must have previously registered for Azure MFA and SSPR in order to use when risk is detected.

• Enable Azure AD self-service password reset

• Enable Azure Multi-Factor Authentication

• Enable Azure Multi-Factor Authentication registration policy

• Enable sign-in and user risk policies

How to manually remediate risks and unblock users

There is an option to enable automated remediation using risk policies, such as MFA or Change password (SSPR - Self-Service Password Reset) to remediate risks. For some reasons, if MFA and Require Change Password options are not available for your organization, but Risk policy has been enabled to block user's access. Here are some manual process :

1. User blocked by User Risk Policy

Unblocking user due to user risk can be done by either Admin reset password OR dismissing user OR exclude user from policy OR disabling policy (if causing issues for all users

step 1. Since user wont be able to log in o365 related system using blocked AD account , user has to call into helpdesk to request unblock. After unblock, helpdesk will execute a manually password reset and pass password to user by phone. 

   -When a user gets blocked for high risk (block being the control) they are blocked from that authentication flow. Access to all resources that are integrated with Azure AD will be affected. 

   -Windows log on will not be affected by blocked users from Identity Protection because On prem is cached log on not a live authentication with an identity provider. 

Step 2. Security admin contacted by helpdesk will need to investigate and take further action, such as dismiss user risk, which confirms to Azure AD that the user is not compromised. User Risk will be reset to none. All risk on this user and past sign-in will be closed. 

Step 3. User should be able to sign in now. 

Step 3 option: Exclude user from policy or disable policy. 

2. user blocked by Sign-in Risk Policy

Step1. User will not be able to sign in certain o365 apps.          

   -When a user gets blocked for high risk (block being the control) they are blocked from that authentication flow. Access to all resources that are intergrated with Azure AD will be affected. 

   -Windows log on will not be affected by blocked users from Identity Protection because On prem is cached log on not a live authentication with an identity provider. 

Step2. User contact helpdesk by phone or email to report issue and get support

-Only if signing in from a trusted location/device does not allow the user to unblock themselves. Then help would be needed to investigate and exclude user from policy if needed. Investigate then either confirm sign in safe or confirm sign in compromised action should be taken which will feed back to Azure AD.

Step3 Security admin confirm sign-in safe, which will set Risk level to none and reverse its impact on the user risk. 

Step4. User should be able to sign -in again . 

Optional step 3, exclude user from sign-in policy or disable sign-in policy. How long should we wait once add user into exclusion policy or disabled policy?

Other recommendations: When you enable Identity Protection you should start with users in report only mode which allows the machine learning to learn the user behavior like sign in location. Report only mode does not actually enforce the user to perform MFA or block the user if that is the action you have set.  

When you set policies, you can set a policy to block a user with High risk but if you have low or above selected or medium or above selected this is best to allow user the option to perform and pass MFA to show Azure AD the user is not risky then learn that behavior. If you have both policies enabled, one to block high risk and the other to challenge the user with MFA (or password change) for low and above (or med and above) then the block will be the one that enforces the user.

https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies#enable-policies

References

• Remediate Risks and Unblock  Users