Manage Device Access (part 1)

By Ashwin Venugopal -

 


To read part 2, please click here





Plan for Device Compliance

Device Compliance policies can define the rules and settings required to be configured on a device so that it can be considered compliant allowing you to monitor device compliance status as well as individual devices that are configured in an expected way. However, the device must be enrolled to Intune before applying for compliance policy which will help the device to be automatically added to a device group so that its compliance status can be automatically reported to Intune and shown in the portal.

Some of the commonly used device compliance settings are:

  1. Required password to access devices
  2. Local data encryption 
  3. Whether the device is jail-broken or rooted
  4. Minimum OS version required 
  5. Maximum OS version allowed
  6. Required the device to be at, or under the Mobile Threat Defense level

If you want to implement device compliance policies, you must satisfy the following prerequisites:

  • It must be licensed for Azure AD Premium P1 or Azure AD Premium P2 and Intune. Both of them are part of Microsoft 365 or Enterprise Mobility + Security, but they can also be obtained separately.

  • Its devices must run one of the given supported platforms- Android, Android Enterprise, iOS, macOS, Windows Phone 8.1, Windows 8.1 and later, Windows 10.

  • Its devices must be enrolled in Intune to be eligible for compliance management.  

Following are the two types of non-compliant actions:

  • Notify end users through email-  Everything in an email notification can be customized like recipients, subject, message body along with the company logo as well as contact information  before sending it to the end user. Intune includes details about the noncompliant device in the email notification. 

  • Mark device noncompliant- You can either specify the number of days immediately after which the device can be flagged as noncompliant or you can simply grant the user a grace period in which he or she can update the device to make it compliant. However, if the device is still not compliant after the specified number of days, then, it will be marked as noncompliant.  

Device compliance policies can be used as follows:

  • With conditional access- The devices that comply with the policy rules, can be allowed access to the email and other company resources, but if it doesn't, then they aren't allowed any access to the company resources. 

  • Without conditional access- The device compliance policies can also be used without any conditional access providing restrictions free access to the company resources. 

If compliance policies are used independently, then, the targeted devices are evaluated and reported with their compliance status. However, the compliance status can also be reported regardless of any primary user or enrollment by device enrollment manager.

Configure Conditional Users & Groups

A built-in Mobile Device Management (MDM) agent automatically begins to sync the device details to Intune after the device's successful enrollment to it which includes information like:
  1. Name of device
  2. Operating system
  3. Total and free storage space
  4. Enrolled date
  5. Encrypted
  6. Compliance

The information can be easily viewed on the Intune blade in the Azure portal or while generating reports. 

The user and device groups can be created with the help of static as well as dynamic membership in Azure AD. A group can be created in azure AD with dynamic membership by specifying a rule to determine membership based on user or device properties. If all the attributes of a user or device changes, Azure AD evaluates all dynamic groups in a directory to check if the change would trigger any group adds or removes. If a user or device satisfies a rule on a group, then, they are added as the member of that group and vice versa. 

A group membership rule can automatically populate a group with users or devices which is a binary expression resulting in a true or false outcome. The three parts of a simple group membership rule are as follows:

  • Specifies the object attribute; for example, you can use user.department to reference the Department attribute of a user object, or device.displayName to reference the displayName attribute of a device object. 

  • Can be one of many supported operators, like as Equals (-eq), Starts With (-startsWith), Contains (-contains), or Match (-match). 

  • The value against which you want to evaluate the property by using the operator. 











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

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...
Read more