This article is contributed. See the original author and article here.
Hi all, Zoheb here publishing on behalf of a guest author, Morne Naude. So without further ado…
Hi Everyone,
Morne here again and welcome to the first blog in our series on Azure Active Directory Security where we will be sharing all details on how we helped our SMC customers reduce the attack vector by enabling Identity Protection in Azure.
If you have not read our introductory blog covering the entire background on our SMC Delivery Methodology, please do give it a read now before continuing here.
How Microsoft Mission Critical Team Helped Secure AAD
If an Electron Can Be in Two Places at Once, Why Can’t You …
Well you can’t PERIOD
We refer to this as Atypical travel “Sign in from an atypical location based on the user’s recent sign-ins.“ or Unfamiliar sign-in properties “Sign in with properties we’ve not seen recently for the given user.”
Before we get on to more details on how we helped our SMC customer, here is some background information on Identity Protection & Risky Sign ins which may help you understand the subject better.
What is Azure Active Directory Identity Protection?
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.
Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats.
This is but a few examples of risk types Azure identity protection use in its classifications.
|
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 |
This risk detection indicates that the user’s valid credentials have been leaked |
|
Azure AD threat intelligence |
Microsoft’s internal and external threat intelligence sources have identified a known attack pattern |
Coming back to our customers’ pain areas, we were detecting a high number of Risky Sign ins every day across the organization, we spotted these during the Azure AD Assessments as well as observations from the Risky Sign in logs.
Working with the Mission Critical team gives our customers the ultimate personalized support experience from a designated team that:
- Knows you and knows what your solution means to your enterprise
- Works relentlessly to find every efficiency to help you get ahead and stay ahead
- Advocates for you and helps ensure get you the precise guidance you need.
Knowing the customer well helped us understand the extent of the problem, to work closely with their Identity team and recommend improvements to them.
There were various attack trends observed from Azure AD Connect Health related to Password spray, Breach replay, Phishing etc. on Azure and it was an urgent need of the hour to get into a better security posture.
After speaking with the messaging team, we realized that few of the Risky users had strange Mailbox rules created and were spamming multiple users in the organization (more details to come in one of our following blogs).
If you are interested to read more about Forms Injection Attacks on emails please see: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide
Our customer had no policy/process configured to tackle this issue, they only had Multi Factor Authentication (MFA) in place for Global Admins.
Policies
We suggested to enable User Risk as well as Sign-in Risk policies for users deemed as “high-risk”, below are some details on how it was enabled for our customer.
- Sign-in risk policy
Identity Protection analyses signals from each sign-in, both real-time and offline, and calculates a risk score based on the probability that the sign-in wasn’t performed by the user. Administrators can decide based on this risk score signal to enforce organizational requirements. Administrators can choose to block access, allow access, or allow access but require multi-factor authentication.
We enabled Sign in risk Policy to force “MFA” for all “High Risk” users as per configuration below.
- User risk Policy
Identity Protection can calculate what it believes is normal for a user’s behaviour and use that to base decisions for their risk. User risk is a calculation of probability that an identity has been compromised. Administrators can decide based on this risk score signal to enforce organizational requirements.
Considering the circumstances, we suggested to our customer to implement below User Risk policy, this policy would ensure that if there is any “High Risk” user he will be required to change Password as per configuration below.
So, these two policies ensured all the Risky Sign in users are forced to use MFA and change their passwords.
Notification for Risky users
Our customer has Azure AD P2 licensing, so we could leverage the full set of Identity protection features.
We configured the users at risk email in the Azure portal under Azure Active Directory > Security > Identity Protection > Users at risk detected alerts.
By default, recipients include all Global Admins. Global Admins can also add other Global Admins, Security Admins, Security Readers as recipients.
Optionally you can Add additional emails to receive alert notifications; this feature is a preview and users defined must have the appropriate permissions to view the linked reports in the Azure portal. We included members of the Identity and Security teams as well.
The weekly digest email contains a summary of new risk detections, such as:
- New risky users detected
- New risky sign-ins detected (in real-time)
- Links to the related reports in Identity Protection
This resulted in a drastic reduction in the number of risky users and risky sign-ins. Additionally we helped implement a process of investigation and remediation of these at- risk accounts from the service desk to the internal security department. Currently the business is in the process of including Medium based at-risk accounts into the above policies.
NOTE: The features and guidelines implemented in this case were specific to this customer’s requirements and environment, so this is not a “General” guideline to enable any of the mentioned features.
Hope this helps,
Morne
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments