Protect your Identities with Azure AD Identity Protection (part 1)

By Ashwin Venugopal -

 


To read part 2 please click here


What is Azure Active Directory Identity Protection?

Identity Protection is a solution built into Azure AD that's designed to protect your identities through a three-part process by helping you to automatically detect, remediate, and investigate the identity-based risks for your organization without hiring expensive security experts. 

What are risks?

Risks can be known as a suspicious activity and actions by the users when they sign in, or when they take actions after signing in. Hence, the risks are categorized into two ways- as user risks and sign-in risks.

User Risk

A user risk is caused when a user's identity or account is compromised and can include:

Risk

Description

Unusual behavior

The account showed unusual activity or the patterns of usage are similar to those patterns that the Microsoft systems and experts have identified as attacks.

Leaked credentials

The user’s credentials could have been leaked. For example the Microsoft might have found a list of the leaked credentials on the dark web, which could affect your user account.  


 Sign-in Risk

In this one, Identity Protection scrutinizes each authentication request to judge whether it was authorized by the owner of the identity. Sign-in risks includes:

Risk

Description

Unfamiliar sign-in properties

Identity Protection remembers and learns a particular user’s sign-in history. For example when a sign-in occurs from a location that’s unusual for the user, a risk detection is triggered.   

Atypical travel

For example, when two or more sign-ins occurs from distant locations in an unrealistically short time period, a risk detection is raised.

Malware-linked IP address

For example, if the IP address where the sign-in originates is known to have been in contact with an active bot server,  risk detection is raised.

Anonymous IP address

For example, a sign-in originates from an anonymous IP address. As these details can be used by the attackers to hide their real IP address or location, a risk detection is raised.

 

Detect risks with Azure AD Identity Protection policies

Risk policies helps your organization to respond more appropriately to identity risk while allowing you to respond to risks rapidly and your company can easily leverage risk policies, as well as avoid hiring external contractors to handle identity-based risks.

Different types of risk policies are available based on the type of identity risk and you can also use a sign-in risk policy or a user risk policy. 

Sign-in risk policy

A sign-in risk policy scrutinizes every sign-in, and gives it a risk score which indicates the probability that the sign-in was attempted by the person whose credentials are used. According to the risk level, you can choose whether to allow access, automatically block, or allow access only after additional requirements are met while also using a form to configure a sign-in risk policy in the Azure portal and specify the settings such as:

  • The users this policy should target.
  • The conditions that must be met, such as how high a score triggers a policy.
  • How you want to respond.

You should confirm that the users are already registered for Azure AD Multi-Factor Authentication before you apply for this policy and after a sign-in risk is identified, the user is asked to take action to remediate the risk as well as also told what triggered the risk, and what they need to provide to resolve the issue.

User risk policy

Here, the Identity Protection automatically learns the user's normal behavioral patterns and then uses this knowledge to calculate the likely risk that the user's identity was compromised which helps the admin to decide whether to allow access, to block it, or  to allow access only after the additional requirements are met. 

You can easily specify the settings like the users this policy should target, the conditions that must be met, and how you'll respond while making sure that the users are already registered for the self-service password reset before you apply this policy and after a user risk is identified, the user is asked to take action to remediate that risk while also knowing what triggered the risk, and what they need to provide to resolve the issue.

 

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 groups of computers, re
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 of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more