Microsoft Defender for Identity
Microsoft Defender for Identity( MDI), previously known as Azure Advanced Threat Protection (Azure ATP), is a security product designed to provide insights, analytics, and alerting for suspicious activities, including lateral movements through pass the hash, Kerberos Golden Ticket, or other attempted exploits. MDI is included as part of EMS E5.
MDI helps security analysts identify, detect, and investigate threats that target organization identities. Specifically, MDI leverages either the on-premises domain controller or ADFS server by collecting Active Directory ( AD) data, network traffic, and Windows events to provide insights into possible suspicious activity. Security analysts can then take this data and monitor the assets, investigate, and respond to any alerts triggered by MDI.
Deployment tip
MDI covers organizations with hybrid identity infrastructure, i.e., where the domain controller remains on-premises. If an organization has a cloud-only identity and you want to learn about protecting Azure AD identities, please see https://learn.microsoft.com/en-us/ azure/active-directory/identity-protection/overview-identity-protection.
The Defender portal provides a dashboard for all Azure AD-synced identities, as shown in Figure 9.13:
Figure 9.13 – MDI dashboard highlighting admins
MDI leverages sensors that can be installed directly onto an organization’s on -premises domain controllers, or, if applicable, ADFS server infrastructure. The MDI sensors not only require installation directly onto supported servers (for example, Windows Server 2008 is no longer supported) but also need to be able to communicate with the MDI service.
In order to successfully deploy MDI, you’ll need to ensure your environment meets all of the networking and name resolution prerequisites.
MDI sensor prerequisites
To learn more about the prerequisites for MDI sensors, see https://learn.microsoft. com/en-us/defender-for-identity/prerequisites. It’s important to take note of the license requirements as well as permissions and supported server operating systems.
Once the sensors are installed on the servers, IT admins can then configure entity tags, detection and automated response exclusions, and email and notification settings. Entity tags are used to identify accounts with higher sensitivity and should be treated as such. Examples can be identities with administrative credentials as well as assets such as Exchange Server.
Once configured, security admins can use the Microsoft 365 Defender portal to investigate assets, alerts, and any lateral movement. We discussed lateral movement before, but to reiterate, it is critical to understand that this is one of the most common tactics attackers may use to inevitably gain access to key targets. Finally, security admins can then take remediation actions on a compromised identity by disabling a user in AD, suspending a user in Azure AD, or resetting a user’s password.
For example, an MDI alert may be triggered by a reconnaissance activity. This means that an attacker will use certain techniques specifically to collect as much information about a network. An example alert is when an attacker uses a dictionary-style attack to try and guess the credentials of user objects that exist within a domain controller.
MDI alerts
Learn more about the different types of alerts MDI provides by visiting this page: https:// learn.microsoft.com/en-us/defender-for-identity/understanding-security-alerts
MDI then also provides best-practice recommendations to help mitigate these types of attacks. In this case, long and complex passwords for all users should be standardized, but adapting the password-less model is ideal.
MDI also contributes to the organization’s Secure Score. Like with the other plans, Secure Score provides recommended actions for identity, as shown in Figure 9.14:
Figure 9.14 – Secure Score recommended actions for identity
Requiring users to have MFA configured is also best practice.
Now that you’ve learned about identity, let’s move on to cloud apps.