Microsoft Compliance Manager's scope is not limited to tracking customer-managed controls only. Compliance Manager provides a comprehensive solution that helps organizations manage their compliance requirements by tracking both customer-managed controls and Microsoft-managed controls. It offers a range of assessments, including those for various regulatory standards and compliance frameworks, and provides actionable insights and recommendations to help improve compliance.

Why the other answer is wrong:

A. Yes: This is incorrect because Compliance Manager covers more than just customer-managed controls. It also includes controls that are managed by Microsoft, offering a holistic view of compliance status.

Example:

Happy Hogan can use Compliance Manager to track the implementation of compliance controls across Parker Industries. This includes controls managed by Parker Industries' IT team (customer-managed) and controls managed by Microsoft as part of their cloud services (Microsoft-managed). Compliance Manager provides a unified dashboard to monitor compliance across various standards, such as GDPR, HIPAA, and ISO 27001, and helps ensure that both sets of controls are effectively implemented and maintained.

Microsoft Cloud App Security can use conditional access policies to control sessions in real time.

Microsoft Cloud App Security

Moving to the cloud increases flexibility for employees and IT alike. However, it also introduces new challenges and complexities for keeping your organization secure. To get the full benefit of cloud apps and services, an IT team must find the right balance of supporting access while maintaining control to protect critical data.

Microsoft Cloud App Security is a Cloud Access Security Broker (CASB) that supports various deployment modes including log collection, API connectors, and reverse proxy. It provides rich visibility, control over data travel, and sophisticated analytics to identify and combat cyberthreats across all your Microsoft and third-party cloud services.

Microsoft Cloud App Security natively integrates with leading Microsoft solutions and is designed with security professionals in mind. It provides simple deployment, centralized management, and innovative automation capabilities.

What is a CASB?

Moving to the cloud increases flexibility for employees and IT teams. However, it also introduces new challenges and complexities for keeping your organization secure. To get the full benefit of cloud apps and services, an IT team must find the right balance of supporting access while protecting critical data.

This is where a Cloud App Security Broker steps in to address the balance, adding safeguards to your organization's use of cloud services by enforcing your enterprise security policies. As the name suggests, CASBs act as a gatekeeper to broker access in real time between your enterprise users and cloud resources they use, wherever your users are located and regardless of the device they are using.

CASBs do this by discovering and providing visibility into Shadow IT and app use, monitoring user activities for anomalous behaviours, controlling access to your resources, providing the ability to classify and prevent sensitive information leak, protecting against malicious actors, and assessing the compliance of cloud services.

CASBs address security gaps in an organization's use of cloud services by providing granular visibility into and control over user activities and sensitive data. CASB coverage scope applies broadly across SaaS, PaaS, and IaaS. For SaaS coverage, CASBs commonly work with the most popular content collaboration platforms (CCP), CRM systems, HR systems, Enterprise resource planning (ERP) solutions, service desks, office productivity suites, and enterprise social networking sites. For IaaS and PaaS coverage, several CASBs govern the API-based usage of popular cloud service providers (CSP) and extend visibility and governance to applications running in these clouds.

Why do I need a CASB?

You need a CASB to better understand your overall cloud posture across SaaS apps and cloud services and, as such, Shadow IT discovery and app governance are key use cases. Additionally, an organization is responsible for managing and securing its cloud platform including IAM, VMs and their compute resources, data and storage, network resources, and more. Therefore, if you are an organization that uses, or is considering using, cloud apps to your portfolio of network services, you most likely need a CASB to address the additional, unique challenges of regulating and securing your environment. For example, there are many ways for malicious actors to leverage cloud apps to get into your enterprise network and exfiltrate sensitive business data.

As an organization, you need to protect your users and confidential data from the different methods employed by malicious actors. In general, CASBs should help you do this by providing a wide array of capabilities that protect your environment across the following pillars:

• Visibility: detect all cloud services; assign each a risk ranking; identify all users and third-party apps able to log in

• Data security: identify and control sensitive information (DLP); respond to classification labels on content

• Threat protection: offer adaptive access control (AAC); provide user and entity behaviour analysis (UEBA); mitigate malware

• Compliance: supply reports and dashboards to demonstrate cloud governance; assist efforts to conform to data residency and regulatory compliance requirements

The Cloud App Security framework

• Discover and control the use of Shadow IT: Identify the cloud apps, IaaS, and PaaS services used by your organization. Investigate usage patterns, assess the risk levels and business readiness of more than 16,000 SaaS apps against more than 80 risks. Start managing them to ensure security and compliance.

• Protect your sensitive information anywhere in the cloud: Understand, classify, and protect the exposure of sensitive information at rest. Leverage out-of-the box policies and automated processes to apply controls in real-time across all your cloud apps.

• Protect against cyberthreats and anomalies: Detect unusual behaviour across cloud apps to identify ransomware, compromised users or rogue applications, analyze high-risk usage and remediate automatically to limit the risk to your organization.

• Assess the compliance of your cloud apps: Assess if your cloud apps meet relevant compliance requirements including regulatory compliance and industry standards. Prevent data leaks to non-compliant apps, and limit access to regulated data.

Architecture

Cloud App Security integrates visibility with your cloud by:

• Using Cloud Discovery to map and identify your cloud environment and the cloud apps your organization is using.

• Sanctioning and unsanctioning apps in your cloud.

• Using easy-to-deploy app connectors that take advantage of provider APIs, for visibility and governance of apps that you connect to.

• Using Conditional Access App Control protection to get real-time visibility and control over access and activities within your cloud apps.

• Helping you have continuous control by setting, and then continually fine-tuning, policies.

https://docs.microsoft.com/en-us/cloud-app-security/what-is-cloud-app-security

The Data Security pillar is responsible for identifying and controlling sensitive information. This involves classifying and protecting data based on its sensitivity, ensuring that data is encrypted, and applying policies to control access and sharing of sensitive information.

Why the other answers are wrong:

B. Compliance: This pillar ensures that cloud usage adheres to relevant laws, regulations, and policies but is not specifically focused on identifying and controlling sensitive information.

C. Visibility to detect all cloud services: This pillar is about gaining visibility into all cloud services being used within the organization but does not deal with identifying or controlling sensitive information.

D. Threat protection: This pillar focuses on protecting against threats like malware and unauthorized access but does not specifically address the identification and control of sensitive information.

Example:

Bruce can explain to Oswald that the Data Security pillar of the Cloud App Security framework enables the Iceberg Lounge to classify their sensitive customer data, such as VIP client lists and transaction records. This pillar helps ensure that only authorized personnel can access this information, thereby protecting it from potential breaches or unauthorized sharing.

Azure AD manages various types of identities, including users, devices, service principals, and managed identities. However, "service applications" is not a recognized identity type managed by Azure AD. Service principals are the identities created for applications to access Azure resources, which might be the source of confusion.

Why the other answers are correct:

A. Service principals: These are identities created for applications, services, and automation tools to access specific Azure resources.

C. Devices: Azure AD can register and manage devices to ensure secure access and compliance.

D. Users: User identities are managed by Azure AD for authentication and access control.

E. Managed identities: These are identities automatically managed by Azure AD for applications running on Azure, which eliminates the need for developers to manage credentials.

Example:

Melinda and Phil can use Azure AD to manage user identities for their employees, ensuring secure access to corporate resources. They can also use service principals for applications that need to interact with Azure services and managed identities to simplify identity management for their deployed applications. However, "service applications" is not a term used to describe an identity type in Azure AD.

Active Directory stores information about members of the domain, including devices and users, verifies their credentials, and defines their access rights.

Describe the concept of directory services and active directory

In the context of a computer network, a directory is a hierarchical structure that stores information about objects on the network. A directory service stores directory data and makes it available to network users, administrators, services, and applications.

Active Directory (AD) is a set of directory services developed by Microsoft as part of Windows 2000 for on-premises domain-based networks. The best-known service of this kind is Active Directory Domain Services (AD DS). It stores information about members of the domain, including devices and users, verifies their credentials, and defines their access rights. A server running AD DS is a domain controller (DC).

AD DS is a central component in organizations with on-premises IT infrastructure. AD DS gives organizations the ability to manage multiple on-premises infrastructure components and systems using a single identity per user. AD DS doesn't, however, natively support mobile devices, SaaS applications, or line of business apps that require modern authentication methods.

The growth of cloud services, SaaS applications, and personal devices being used at work, has resulted in the need for modern authentication, and an evolution of Active Directory-based identity solutions.

Azure Active Directory is the next evolution of identity and access management solutions. It provides organizations with an Identity as a Service (IDaaS) solution for all their apps across cloud and on-premises. In this course, we'll focus on Azure AD, Microsoft’s cloud-based identity provider.

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview

Azure AD identity types

Azure AD manages different types of identities: users, service principals, managed identities, and devices.

User

A user identity is a representation of something that's managed by Azure AD. Employees and guests are represented as users in Azure AD. If you have several users with the same access needs, you can create a group. You use groups to give access permissions to all members of the group, instead of having to assign access rights individually.

Azure AD business-to-business (B2B) collaboration, a feature within External Identities, includes the capability to add guest users. With B2B collaboration, an organization can securely share applications and services with guest users from another organization.

Interactive guide

In the following interactive guide, you'll add a new user to Azure Active Directory.

https://edxinteractivepage.blob.core.windows.net/edxpages/Security%20fundamentals/LP02M02%20-%20Create%20a%20New%20User%20in%20Azure%20Active%20Directory/index.html

Service principal

A service principal is a security identity used by applications or services to access specific Azure resources. You can think of it as an identity for an application.

For an application to delegate its identity and access functions to Azure AD, the application must first be registered with Azure AD. The process of registering creates a globally unique app object that's stored in your home tenant or directory. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal defines what the app does in the tenant, such as who accesses the app, and what resources the app can access.

Managed identity

A managed identity is automatically managed in Azure AD. Managed identities are typically used to manage the credentials for authenticating a cloud application with an Azure service.

There are several benefits to using managed identities, including:

• Application developers can authenticate to services that support managed identities for Azure resources. For a complete list of services, refer to Azure Services that support managed identities.

• Any Azure service that supports Azure AD authentication can use managed identities to authenticate to another Azure service; for example, accessing Azure Key Vault.

• Managed identities can be used without any extra cost.

There are two types of managed identities: system-assigned and user-assigned.

System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD that's tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.

User-assigned. You may also create a managed identity as a standalone Azure resource. A user-assigned managed identity is assigned to one or more instances of an Azure service. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. With user-assigned managed identities, the identity is managed separately from the resources that use it.

The following table summarizes the differences between system-assigned and user-assigned managed identities:

Device

A device is a piece of hardware, such as mobile devices, laptops, servers, or printer. Device identities can be set up in different ways in Azure AD, to determine properties such as who owns the device. Managing devices in Azure AD allows an organization to protect its assets by using tools such as Microsoft Intune to ensure standards for security and compliance. Azure AD also enables single sign-on to devices, apps, and services from anywhere through these devices.

There are multiple options for getting devices into Azure AD:

• Azure AD registered devices can be Windows 10, iOS, Android, or macOS devices. Devices that are Azure AD registered are typically owned personally, rather than by the organization. They're signed in with a personal Microsoft account or another local account.

• Azure AD joined devices exist only in the cloud. Azure AD joined devices are owned by an organization and signed in with their account. Users sign in to their devices with their Azure AD or synced Active Directory work or school accounts. You can configure Azure AD joined devices for all Windows 10 devices (except Windows 10 Home).

• Hybrid Azure AD joined devices can be Windows 7, 8.1, or 10, or Windows Server 2008, or newer. Devices that are hybrid Azure AD joined are owned by an organization and signed in with an Active Directory Domain Services account belonging to that organization. They exist in the cloud and on-premises.

IT admins can use tools like Microsoft Intune, a mobile device management (MDM) solution, to manage devices.

https://docs.microsoft.com/en-us/mem/intune/fundamentals/what-is-intu

Yes - Leaked Credentials indicates that the user's valid credentials have been leaked.

Risk levels

Identity Protection categorizes risk into three tiers: low, medium, and high. When configuring custom Identity protection policies, you can also configure it to trigger upon No risk level. No Risk means there's no active indication that the user's identity has been compromised.

While Microsoft doesn't provide specific details about how risk is calculated, we'll say that each level brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user.

Password hash synchronization

Risk detections like leaked credentials require the presence of password hashes for detection to occur. For more information about password hash synchronization, see the article, Implement password hash synchronization with Azure AD Connect sync.

Leaked credentials

Microsoft finds leaked credentials in various places, including:

• Public paste sites such as pastebin.com and paste.ca where bad actors typically post such material. This location is most bad actors' first stop on their hunt to find stolen credentials.

• Law enforcement agencies.

• Other groups at Microsoft doing dark web research.

https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks

Connectivity via Azure Bastion will work across peered virtual networks (VNets) even if the VNets are deployed in different subscriptions. Azure Bastion provides secure and seamless RDP and SSH connectivity to virtual machines in the peered VNets as long as the VNets are correctly peered and configured, and network security groups (NSGs) allow the necessary traffic.

Why the other answer is wrong:

B. No: This is incorrect because Azure Bastion is designed to work across peered VNets, regardless of whether they are in the same or different subscriptions, as long as the peering is properly set up.

Example:

If Café Rivoli deploys Bastion hosts in different VNets that are peered, and these VNets belong to different subscriptions, they can still use Azure Bastion to connect securely to virtual machines within those VNets. The peering configuration ensures that the network traffic can flow between the VNets, allowing Bastion to provide the required connectivity.

Conditional Access is implemented using policies that enforce organizational rules.

Conditional access and its benefits

Conditional Access is a feature of Azure AD that provides an extra layer of security before allowing authenticated users to access data or other assets. Conditional Access is implemented through policies that are created and managed in Azure AD. A Conditional Access policy analyses signals including user, location, device, application, and risk to automate decisions for authorizing access to resources (apps and data).

A Conditional Access policy might state that if a user belongs to a certain group, then they're required to provide multifactor authentication to sign in to an application.

Conditional Access signals

Conditional Access can use the following signals to control the who, what, and where of the policy:

• User or group membership. Policies can be targeted to specific users and groups (including admin roles), giving administrators fine-grained control over access.

• Named location information. Named location information can be created using IP address ranges, and used when making policy decisions. Also, administrators can opt to block or allow traffic from an entire country's IP range.

• Device. Users with devices of specific platforms or marked with a specific state can be used.

• Application. Users attempting to access specific applications can trigger different Conditional Access policies.

• Real-time sign-in risk detection. Signals integration with Azure AD Identity Protection allows Conditional Access policies to identify risky sign-in behaviour. Policies can then force users to perform password changes or multifactor authentication to reduce their risk level or be blocked from access until an administrator takes manual action.

• Cloud apps or actions. Cloud apps or actions can include or exclude cloud applications or user actions that will be subject to the policy.

• User risk. For customers with access to Identity Protection, user risk can be evaluated as part of a Conditional Access policy. User risk represents the probability that a given identity or account is compromised. User risk can be configured for high, medium, or low probability.

Access controls

When the Conditional Access policy has been applied, an informed decision is reached on whether to grant access, block access, or require extra verification. Common decisions are:

• Block access

• Grant access

• Require one or more conditions to be met before granting access:

• Require multifactor authentication.

• Require device to be marked as compliant.

• Require hybrid Azure AD joined device.

• Require approved client app.

• Require app protection policy.

• Require password change.

• Control user access based on session controls to enable limited experiences within specific cloud applications. As an example, Conditional Access App Control uses signals from Microsoft Cloud App Security (MCAS) to block, download, cut, copy and print sensitive documents, or to require labelling of sensitive files. Other session controls include sign-in frequency and application enforced restrictions that, for selected applications, use the device information to provide users with a limited or full experience, depending on the device state.

Conditional Access policies can be targeted to members of specific groups or guests. For example, you can create a policy to exclude all guest accounts from accessing sensitive resources. Conditional Access is a feature of paid Azure AD editions.

Interactive guide

In this interactive guide, you'll create a Conditional Access policy for a group of users.

https://edxinteractivepage.blob.core.windows.net/edxpages/Security%20fundamentals/LP02M04%20-%20Create%20a%20Conditional%20Access%20Policy/index.html

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/plan-conditional-access

No - “Shared Responsibility” is not a key privacy principle in Microsoft.

Microsoft’s products and services run on trust. Microsoft focuses on six key privacy principles when making decisions about data. Privacy is about making meaningful choices for how and why data is collected and used. It's about ensuring that you have the information you need to make the choices that are right for you, across all Microsoft products and services.

The six privacy principles are:

• Control: Putting you, the customer, in control of your privacy with easy-to-use tools and clear choices.

• Transparency: Being transparent about data collection and use so that everyone can make informed decisions.

• Security: Protecting the data that's entrusted to Microsoft by using strong security and encryption.

• Strong legal protections: Respecting local privacy laws and fighting for legal protection of privacy as a fundamental human right.

• No content-based targeting: Not using email, chat, files, or other personal content to target advertising.

• Benefits to you: When Microsoft does collect data, it's used to benefit you, the customer, and to make your experiences better.

These principles form Microsoft’s privacy foundation, and they shape the way that products and services are designed.

https://privacy.microsoft.com/en-us/privacy