Azure AD Identity Protection (part 3 of 3)

By Ashwin Venugopal -

 




To read part 1, please click here
To read part 2, please click here





Plan Your Investigation

Azure Identity Protection dashboard provides access to the following:
  1. Reports like Users flagged for risk, Risk events, and Vulnerabilities.
  2. Settings like the configuration of your Security Policies, Notifications, and Multi-factor Authentication registration.

It is the starting point to review the activities, logs, and other relevant information regarding a risk event which helps you to determine if remediation or mitigation steps are necessary and understand how the identity was compromised and used. 

Mitigation Sign-in Risk Events

Mitigation is termed as an action to restrict the ability of an attacker to exploit a compromised identity or device without restoring the identity or device to a safe state. If you want to mitigate the risky sign-ins automatically, then, you have to configure sign-in risk security policies that will allow to block risky sign ins or perform multi-factor authentication. All these actions will help you to prevent an attacker from exploiting a stolen identity to cause damage, providing some time to secure the identity.

Mitigation Best Practices

The following practices are recommended to follow while setting a policy:

  1. Exclude users who do not/cannot have multi-factor authentication.
  2. Exclude users in locales where enabling the policy is not practical like locales with no access to a helpdesk.
  3. Exclude users who are likely to generate a lot of false-positives like developers and security analysts.
  4. Use a High threshold during initial policy roll out, or if you must minimize challenges seen by end-users.
  5. Use a Low threshold if your organization requires greater security which introduces additional user sign-in challenges but increased security.   

However, it is recommended for the most organizations to configure rule for a Medium threshold to strike balance between usability and security. 

The sign-in risk policy is:

  1. Applied to all browser traffic and sign-ins using modern authentication. 
  2. Not applied to applications using older security protocols by disabling the WS-Trust endpoint at the federated IDP, like ADFS.  

User Risk

The user risk level is calculated using the following inputs:
  1. Active risk events impacting the user.
  2. Risk level of these events.
  3. Whether any remediation actions have been taken. 

The user risk levels can be used to create conditional access policies that can block risky users from signing in or force them to securely change their password. 

Closing Risk Events Manually

You can change the status of a risk event with the help of the following actions:

  • Resolve- Resolved events will set the risk event's status to Closed and the risk event will no longer contribute to user risk. If you believe the risk event should be considered closed, mark the event as Resolved.

  • Mark as false-positive- If you investigate and find that a risk event is mistakenly flagged as a risk, you can mark it as False-positive which will help the machine learning algorithms to improve the classification of similar events in the future. After that the status of false-positive will change to Closed and they will no longer contribute to user risk.

  • Ignore-  If you want a risk event to be removed from the active list without applying any remediation action, then, you can just mark it as Ignore and the event will be Closed i.e. the event will not contribute to any user risk. This option can only be used under unusual circumstances. 

  • Reactivate- The manually closed risk events can be reactivated by simply setting the event status back to Active. These events will contribute to the user risk level calculation, however, the risk events closed through remediation cannot be reactivated. 

Azure Identity Protection Notifications

Two types of automated notification emails are sent to help you manage user risk and risk events:
  1. Users at risk detected email
  2. Weekly digest email

If an account is detected to be at risk, then AIP will generate an email alert with Users at risk detected as the email subject which also include a link to the User flagged for risk report. It is recommended to immediately investigate the users at risk. 











To read part 1, please click here
To read part 2, please click here










Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more