Skip to content

Blog

Differences between B2B Direct Connect and B2B Collaboration in Microsoft Entra

Microsoft Entra offers two ways to collaborate with external users: B2B Direct Connect and B2B Collaboration. Both features allow organizations to share resources with external users while maintaining control over access and security. However, they differ in functionality, access, and integration. Here is a comparison between B2B Direct Connect and B2B Collaboration:

Feature B2B Direct Connect B2B Collaboration
Definition Mutual trust relationship between two Microsoft Entra organizations Invite external users to access resources using their own credentials
Functionality Seamless collaboration using origin credentials and shared channels in Teams External users receive an invitation and access resources after authentication
Applications Shared channels in Microsoft Teams Wide range of applications and services within the Microsoft ecosystem
Access Single sign-on (SSO) with origin credentials Authentication each time resources are accessed, unless direct federation is set up
Integration Deep and continuous integration between two organizations Flexible way to invite and manage external users

I hope this helps!

Microsoft Defender for Storage

Microsoft Defender for Storage is part of the Microsoft Defender for Cloud suite of security solutions.

Introduction

Microsoft Defender for Storage is a cloud-native security solution that provides advanced threat protection for your Azure Storage accounts.

Microsoft Defender for Storage provides comprehensive security by analyzing the data plane and control plane telemetry generated by Azure Blob Storage, Azure Files, and Azure Data Lake Storage services. It uses advanced threat detection capabilities powered by Microsoft Threat Intelligence, Microsoft Defender Antivirus, and Sensitive Data Discovery to help you discover and mitigate potential threats.

Defender for Storage includes:

  • Activity Monitoring
  • Sensitive data threat detection (new plan only)
  • Malware Scanning (new plan only)

How it works

Microsoft Defender for Storage uses advanced threat detection capabilities powered by Microsoft Threat Intelligence, Microsoft Defender Antivirus, and Sensitive Data Discovery to help you discover and mitigate potential threats.

Activity Monitoring

Activity Monitoring provides insights into the operations performed on your storage accounts. It helps you understand the access patterns and operations performed on your storage accounts, and provides insights into the data plane and control plane activities.

Sensitive data threat detection

Sensitive data threat detection helps you discover and protect sensitive data stored in your storage accounts. It uses advanced machine learning models to detect sensitive data patterns and provides recommendations to help you protect your sensitive data.

Malware Scanning

Malware Scanning helps you detect and mitigate malware threats in your storage accounts. It uses advanced threat detection capabilities powered by Microsoft Defender Antivirus to scan your storage accounts for malware threats and provides recommendations to help you mitigate these threats.

Pricing

The pricing for Microsoft Defender for Storage is as follows:

Resource Type Resource Price
Storage Microsoft Defender for Storage €9 per storage account/month6
Storage Malware Scanning (add-on to Defender for Storage) €0.135/GB of data scanned

For more information about pricing, see the Microsoft Defender for Cloud pricing.

Conclusion

Microsoft Defender for Storage is a cloud-native security solution that provides advanced threat protection for your Azure Storage accounts. It uses advanced threat detection capabilities powered by Microsoft Threat Intelligence, Microsoft Defender Antivirus, and Sensitive Data Discovery to help you discover and mitigate potential threats.

For more information about Microsoft Defender for Storage, see the Overview of Microsoft Defender for Storage

Security Score System

The Common Vulnerability Scoring System (CVSS) is a framework for scoring the severity of security vulnerabilities. It provides a standardized method for assessing the impact of vulnerabilities and helps organizations prioritize their response to security threats. In this article, we will discuss the CVSS and how it can be used to calculate the severity of security vulnerabilities.

What is CVSS?

The Common Vulnerability Scoring System (CVSS) is an open framework for scoring the severity of security vulnerabilities. It was developed by the Forum of Incident Response and Security Teams (FIRST) to provide a standardized method for assessing the impact of vulnerabilities. CVSS assigns a numerical score to vulnerabilities based on their characteristics, such as the impact on confidentiality, integrity, and availability, and the complexity of the attack vector.

CVSS is widely used by security researchers, vendors, and organizations to prioritize their response to security threats. It helps organizations understand the severity of vulnerabilities and allocate resources to address the most critical issues first.

How is CVSS calculated?

In CVSS Version 4.0, vulnerabilities are scored on a scale of 0.0 to 10.0, with 10.0 being the most severe. The CVSS score is calculated based on several metrics groups, including:

  • Base Metric: The Base metric group represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments. It is composed of two sets of metrics: the Exploitability metrics and the Impact metrics.

  • Threat metric group: The Threat metric group reflects the characteristics of a vulnerability related to threat that may change over time but not necessarily across user environments.

  • Environmental metric group: The Environmental metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment.

  • The Supplementary metric group: The Supplemental metric group includes metrics that provide context as well as describe and measure additional extrinsic attributes of a vulnerability.

CVSS Version 4.0 Metrics

Base Metrics

The Base metric group includes the following metrics:

  • Exploitability Metrics: These metrics describe the characteristics of the vulnerability that affect how easy it is to exploit. They include the Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), and User Interaction (UI).
  • Vulnerable System Impact Metrics: These metrics describe the impact on the system if the vulnerability is exploited. They include the Confidentiality(VC), Integrity (VI), and Availability (VA) impacts.
  • Subsequent System Impact Metrics: These metrics describe the impact on the system if the vulnerability is exploited. They include the Confidentiality(SC), Integrity (II), and Availability (SA) impacts.
Exploitability Metrics
  • Attack Vector (AV): This metric describes the context where vulnerability is exploited. It can be either Local (L), Adjacent Network (A), Network (N), or Physical (P).
  • Attack Complexity (AC): This metric describes the complexity of the attack required to exploit the vulnerability. It can be either Low (L), High (H).
  • Privileges Required (PR): This metric describes the level of privileges required to exploit the vulnerability. It can be either None (N), Low (L), or High (H).
  • User Interaction (UI): This metric describes whether user interaction is required to exploit the vulnerability. It can be either None (N), Required (R).
Vulnerable System Impact Metrics
  • Confidentiality Impact (VC): This metric measures the impact on the confidentiality of the information managed by the vulnerable system due to a successful exploit of the vulnerability. It can be either Low (L), High (H), or None (N).

  • Integrity Impact (VI): This metric measures the impact on the integrity of the information managed by the vulnerable system due to a successful exploit of the vulnerability. It can be either Low (L), High (H), or None (N).

  • Availability Impact (VA): This metric measures the impact on the availability of the services of the vulnerable system due to a successful exploit of the vulnerability. It can be either Low (L), High (H), or None (N).

Subsequent System Impact Metrics
  • Confidentiality Impact (SC): This metric measures the impact to the confidentiality of the information managed by the Subsequent System due to a successful exploit of the vulnerability. It can be either Low (L), High (H), or None (N).

References

markmap

markmap is a visualisation tool that allows you to create mindmaps from markdown files. It is based on the mermaid library and can be used to create a visual representation of a markdown file.

Installation in mkdocs

To install markmap in mkdocs, you need install the plugin using pip:

pip install mkdocs-markmap

Then, you need to add the following lines to your mkdocs.yml file:

plugins:
  - markmap

Usage

To use markmap, you need to add the following code block to your markdown file:

```markmap  
# Root

## Branch 1

* Branchlet 1a
* Branchlet 1b

## Branch 2

* Branchlet 2a
* Branchlet 2b
```

And this will generate the following mindmap:

alt text

That is for the future, because in my mkdocs not work as expected:

# Root

## Branch 1

* Branchlet 1a
* Branchlet 1b

## Branch 2

* Branchlet 2a
* Branchlet 2b

Visual Studio Code Extension

There is also a Visual Studio Code extension that allows you to create mindmaps from markdown files. You can install it from the Visual Studio Code marketplace.

    Name: Markdown Preview Markmap Support
    Id: phoihos.markdown-markmap
    Description: Visualize Markdown as Mindmap (A.K.A Markmap) to VS Code's built-in markdown preview
    Version: 1.4.6
    Publisher: phoihos
    VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=phoihos.markdown-markmap
VS Marketplace Link

Conclusion

I don't like too much this plugin because it not work as expected in my mkdocs but it's a good tool for documentation.

References

When to use service principals

In Azure, there are two ways to authenticate your applications and services: service principals and managed identities.

Basically, don't use service principals if you can use managed identities. Managed identities are a more secure way to authenticate your applications and services in Azure. However, there are some scenarios where you need to use service principals instead of managed identities. Here are some scenarios where you should use service principals:

flowchart TD
    A[When to use service principals] --> B{Is your application or service running on-premises?}
    B --> |Yes| C{Is Azure Arc supported?}
    C --> |Yes| D[Use Managed Identity]
    C --> |No| E[Use Service Principal]
    B --> |No| F{Do the resources or applications support managed identities?}
    F --> |No| G[Use Service Principal]
    F --> |Yes| H[Use Managed Identity]

Conclusion

In conclusion, you should use managed identities whenever possible. However, if your application or service is running on-premises or if the resources or applications do not support managed identities, you should use service principals instead.

Microsoft Entra Conditional Access

In this post, I will show you how to configure Conditional Access in Microsoft Entra.

What is Conditional Access?

Conditional Access is a feature of Microsoft Entra that allows you to control access to your organization's resources based on specific conditions. With Conditional Access, you can enforce policies that require users to meet certain criteria before they can access resources, such as multi-factor authentication, device compliance, or location-based restrictions.

You have three main components in Conditional Access:

  • Signals: These are the conditions that trigger a policy. Signals can include user sign-in, device state, location, and more.
  • Decisions: These are the actions that are taken when a policy is triggered. Decisions can include requiring multi-factor authentication, blocking access, or granting access with conditions.
  • Enforcement: This is the mechanism that enforces the policy. Enforcement can be done at the application level, the network level, or the device level.

Really, all the Conditional Access policies are based on the following flow:

  1. Assignments: Define who and where the policy applies to.
  2. Access Controls: Define what to do when the the who and where are met.

For that reason, we can define the followin phases:

  • Phase 1: Collect session details
  • Assignments: Define who and where the policy applies to.

    • users: users and groups selected and excluded
    • Target resources: Control access base on Cloud apps, actions, and authentication context.
    • Cloud apps: Include and exclude. Many of the existing Microsoft cloud applications are included in the list of applications that can be targeted by Conditional Access policies: Office 365, Windows Azure Service Management API, Microsoft Admin Portals and Others
    • User actions: Tasks that a user performs: Register security information and Register or join devices
    • Global Secure Access: Targeting members in your tenant with Global Secure Access (GSA) as a resource,enable administrators to define and control how traffic is routed through Microsoft Entra Internet Access and Microsoft Entra Private Access.
    • Authentication context: With this option you can define a authentication context for the policy, for example, you can define that the policy is applied only when the user is accessing to Higly Confidential information. You can create labels with ID c1 to c99 and tag your information with these labels. Not all apps support authentication contexts, you can check the official documentation to see which apps support it.
    • Network: Include and Exclude. Control user access based on their network location or physical location.
      • Any network or location: This option allows you to apply the policy to all network locations.
      • All trusted locations: This option allows you to apply the policy to all trusted locations.
      • All Compliant Network locations: This option allows you to apply the policy to all compliant network locations.
      • Selected network or location: This option allows you to apply the policy to selected network locations: Countries(GPS),Countries(IP) and IP ranges.
    • Conditions: Control access based in signals from conditions.
      • User risk: Control access based on the user risk level calculated by Microsoft Entra Identity Protection. User risk represents the probability that a given identity or account is compromised, for example: Published credentials in Dark Web.
      • Sign-in risk: Control access based on the sign-in risk level calculated by Microsoft Entra Identity Protection. Sign-in risk represents the probability that a given authentication request wasn't made by the identity owner. For example, sign-in from a new location or new device.
      • Insider risk: Control access for users who are assigned specific risk levels from Adaptive Protection, a Microsoft Purview Insider Risk Management feature. Insider risk represents the probability that a given user is engaged in risky data-related activities.
      • Device Platform: Include and Exclude. Control access based on the platform of the device used to sign in.
      • Client apps: Include and Exclude. Control access based on the client apps used to sign in.
      • Filters for devices: Include and Exclude. Control access based on configured filters to apply policy to specific devices
      • Authentication flows: Control access based on the authentication flow used to sign in:
      • Device code flow: Device code flow is a method of authentication that allows users to sign in to a device using a code displayed on the device. This flow is used for devices that don't have a browser or can't use a browser to sign in.
      • Authentication transfer: Authentication transfer is a new flow that offers a seamless way to transfer authenticated state from one device to another.
  • Phase 2: Enforcement

  • Access controls: Define what to do when the the who and where are met.
    • Grant: Control access enforcement to block or grant access.
    • Block: Block access to the resource.
    • Grant: Grant access to the resource. You can also define the following options:
      • Require multi-factor authentication: Require users to perform multi-factor authentication.
      • Require authentication strength: Require a combination of authentication methods to access the resource.
      • Require device to be marked as compliant: Require the device to be marked as compliant by Microsoft Entra Intune.
      • Require Hybrid Azure AD joined device: Require the device to be Hybrid Azure AD joined.
      • Require approved client app: Require the use of an approved client app.
      • Require app protection policy: Require that an Intune app protection policy is present on the client app before access is available to the selected applications
      • Require password change: Require the user to change their password.
    • For multiple controls, you can define the following options:
      • Require all the selected controls: Require all the selected controls to be met.
      • Require one of the selected controls: Require one of the selected controls to be met.
  • Session: Control access based on session controls to enable limited experiences within specific cloud applications.
    • Use app enforced restrictions: Enforce app restrictions to control access based on the app's own restrictions. When selected, the cloud app uses the device information to provide users with a limited or full experience. Limited when the device isn't managed or compliant and full when the device is managed and compliant.
    • Use Conditional Access App Control: Enforce real-time monitoring and control of user sessions. Conditional Access App Control enables user app access and sessions to be monitored and controlled in real time based on access and session policies. Access and session policies are used within the Defender for Cloud Apps portal to refine filters and set actions to take.
    • Sign-in frequency: Enforce sign-in frequency to control how often users are prompted to sign in. Sign-in frequency setting works with apps that implement OAUTH2 or OIDC protocols according to the standards.
    • Persistent browser session: Enforce persistent browser session to control users can remain signed in after closing and reopening their browser window.
    • Customize continuous access evaluation: Enable custom continuous access evaluation to revoke access tokens based on critical events and policy evaluation in real time.Continuous Access Evaluation (CAE) allows access tokens to be revoked based on critical events and policy evaluation in real time rather than relying on token expiration based on lifetime.

Example of Conditional Access policy configuration:

  1. Block access to all users from all locations except for a specific group of users from a specific location:
  2. Assignments:
    • users:
    • Include:All users
    • Exclude: Group_of_excluded_users
    • Target resources:
    • Cloud apps: All cloud apps
    • Network: All trusted locations
  3. Access controls:
    • Grant: Block

Mindmaps of the Conditional Access policies flow:

# Conditional Access Policy
## Phase 1: Collect session details
### Assignments
#### users
##### Include
###### None
###### All users
###### Select users and groups
##### Exclude
###### Guest or external users
###### Directory roles
###### Users and groups
#### Target resources
##### Cloud apps
###### Include
 - None
 - All cloud apps
 - Select apps
###### Exclude
  - Edit Filter
  - Select excluded cloud apps
##### User actions
  - Register security information
  - Register or join devices
##### Global Secure Access
  - Microsoft 365 traffic
  - Internet traffic
  - Private traffic
##### Authentication context
##### Network
###### Any network or location
###### All trusted locations
###### All Compliant Network locations
###### Selected network or location
#### Conditions
##### User risk
##### Sign-in risk
##### Insider risk
##### Device Platform
##### Client apps
##### Filters for devices
##### Authentication flows
###### Device code flow
###### Authentication transfer
## Phase 2: Enforcement
### Access controls
#### Grant
##### Block
##### Grant
###### Require multi-factor authentication
###### Require authentication strength
###### Require device to be marked as compliant
###### Require Hybrid Azure AD joined device
###### Require approved client app
###### Require app protection policy
###### Require password change
##### For multiple controls
###### Require all the selected controls
###### Require one of the selected controls
#### Session
##### Use app enforced restrictions
##### Use Conditional Access App Control
##### Sign-in frequency
##### Persistent browser session
##### Customize continuous access evaluation
mindmap
    root((Conditional Access Policy))
      (Phase 1: Collect session details)
        (Assignments)        
          [users]
            {{Include}}
              None
              All users
              Select users and groups
            {{Exclude}}
              Guest or external users
              Directory roles
              Users and groups
          [Target resources]
            {{Cloud apps}}
              Include
                None
                All cloud apps
                Select apps
              Exclude
                Edit Filter
                Select excluded cloud apps
            {{User actions}}
              Register security information
              Register or join devices
            {{Global Secure Access}}
              Microsoft 365 traffic
              Internet traffic
              Private traffic
            {{Authentication context}}
            {{Network}}
              Any network or location
              All trusted locations
              All Compliant Network locations
              Selected network or location
          [Conditions]
            {{User risk}}
            {{Sign-in risk}}
            {{Insider risk}}
            {{Device Platform}}
            {{Client apps}}
            {{Filters for devices}}
            {{Authentication flows}}
              Device code flow
              Authentication transfer
      (Phase 2: Enforcement)
        (Access controls)
          [Grant]
            {{Block}}
            {{Grant}}
              Require multi-factor authentication
              Require authentication strength
              Require device to be marked as compliant
              Require Hybrid Azure AD joined device
              Require approved client app
              Require app protection policy
              Require password change
            {{For multiple controls}}
              Require all the selected controls
              Require one of the selected controls
          [Session]
            {{Use app enforced restrictions}}
            {{Use Conditional Access App Control}}
            {{Sign-in frequency}}
            {{Persistent browser session}}
            {{Customize continuous access evaluation}}

Resources

Data threat modeling in Azure storage accounts

Info

I apologize in advance if this is a crazy idea and there is some mistake!! I am just trying to learn and share knowledge.

Azure Storage Account is a service that provides scalable, secure, and reliable storage for data. It is used to store data such as blobs, files, tables, and queues. However, it is important to ensure that the data stored in Azure Storage Account is secure and protected from security threats. In this article, we will discuss how to perform data threat modeling in Azure storage accounts.

What is data threat modeling?

Data threat modeling is a process of identifying and analyzing potential threats to data security. It helps organizations understand the risks to their data and develop strategies to mitigate those risks. Data threat modeling involves the following steps:

  1. Identify assets: Identify the data assets stored in Azure storage accounts, such as blobs, files, tables, and queues.
  2. Identify threats: Identify potential threats to the data assets, such as unauthorized access, data breaches, data leakage, malware, phishing attacks, insider threats, and data loss.
  3. Assess risks: Assess the risks associated with each threat, such as the likelihood of the threat occurring and the impact of the threat on the data assets.
  4. Develop mitigation strategies: Develop strategies to mitigate the risks, such as implementing security controls, access controls, encryption, monitoring, and auditing.

By performing data threat modeling, organizations can identify and address security vulnerabilities in Azure storage accounts and protect their data from security threats.

Identify assets in Azure storage accounts

Azure storage accounts can store various types of data assets, including:

  • Blobs: Binary large objects (blobs) are used to store unstructured data, such as images, videos, and documents.
  • Files: Files are used to store structured data, such as text files, configuration files, and log files.
  • Tables: Tables are used to store structured data in a tabular format, such as customer information, product information, and transaction data.
  • Queues: Queues are used to store messages for communication between applications, such as task messages, notification messages, and status messages.
  • Disks: Disks are used to store virtual machine disks, such as operating system disks and data disks.

Identifying the data assets stored in Azure storage accounts is the first step in data threat modeling. It helps organizations understand the types of data stored in Azure storage accounts and the potential risks to those data assets.

Identify threats to data in Azure storage accounts

There are several threats to data stored in Azure storage accounts, including:

  • Unauthorized access: Unauthorized users gaining access to Azure storage accounts and stealing data.
  • Data breaches: Data breaches can expose sensitive data stored in Azure storage accounts.
  • Data leakage: Data leakage can occur due to misconfigured access controls or insecure data transfer protocols.
  • Data loss: Data loss can occur due to accidental deletion, corruption, or hardware failure.
  • Ransomware: Ransomware can encrypt data stored in Azure storage accounts and demand a ransom for decryption.
  • DDoS attacks: DDoS attacks can disrupt access to data stored in Azure storage accounts.
  • Phishing attacks: Phishing attacks can trick users into providing their login credentials, which can be used to access and steal data.
  • Malware: Malware can be used to steal data from Azure storage accounts and transfer it to external servers.
  • Insider threats: Employees or contractors with access to sensitive data may intentionally or unintentionally exfiltrate data.
  • Data exfiltration: Unauthorized transfer of data from Azure storage accounts to external servers.

For example, the flow of data exfiltration in Azure storage accounts can be summarized as follows:

sequenceDiagram
    participant User
    participant Azure Storage Account
    participant External Server

    User->>Azure Storage Account: Upload data
    Azure Storage Account->>External Server: Unauthorized transfer of data

In this flow, the user uploads data to the Azure Storage Account, and the data is then transferred to an external server without authorization. This unauthorized transfer of data is known as data exfiltration.

Assess risks to data in Azure storage accounts

Assessing the risks associated with threats to data in Azure storage accounts is an important step in data threat modeling. Risks can be assessed based on the likelihood of the threat occurring and the impact of the threat on the data assets. Risks can be categorized as low, medium, or high based on the likelihood and impact of the threat.

For example, the risk of unauthorized access to Azure storage accounts may be categorized as high if the likelihood of unauthorized access is high and the impact of unauthorized access on the data assets is high. Similarly, the risk of data leakage may be categorized as medium if the likelihood of data leakage is medium and the impact of data leakage on the data assets is medium.

By assessing risks to data in Azure storage accounts, organizations can prioritize security measures and develop strategies to mitigate the risks.

For example, the risk of data exfiltration in Azure storage accounts can be assessed as follows:

pie
    title Data Exfiltration Risk Assessment
    "Unauthorized Access" : 30
    "Data Breaches" : 20
    "Data Leakage" : 15
    "Malware" : 10
    "Phishing Attacks" : 10
    "Insider Threats" : 15

Develop mitigation strategies for data in Azure storage accounts

Developing mitigation strategies is an essential step in data threat modeling. Mitigation strategies help organizations protect their data assets from security threats and reduce the risks associated with those threats. Mitigation strategies could include the following:

  1. Implement access controls: Implement access controls to restrict access to Azure storage accounts based on user roles and permissions.
  2. Encrypt data: Encrypt data stored in Azure storage accounts to protect it from unauthorized access.
  3. Monitor and audit access: Monitor and audit access to Azure storage accounts to detect unauthorized access and data exfiltration.
  4. Implement security controls: Implement security controls, such as firewalls, network security groups, and intrusion detection systems, to protect data in Azure storage accounts.
  5. Use secure transfer protocols: Use secure transfer protocols, such as HTTPS, to transfer data to and from Azure storage accounts.
  6. Implement multi-factor authentication: Implement multi-factor authentication to protect user accounts from unauthorized access.
  7. Train employees: Train employees on data security best practices to prevent data exfiltration and other security threats.
  8. Backup data: Backup data stored in Azure storage accounts to prevent data loss due to accidental deletion or corruption.
  9. Update software: Keep software and applications up to date to protect data stored in Azure storage accounts from security vulnerabilities.
  10. Implement data loss prevention (DLP) policies: Implement DLP policies to prevent data leakage and unauthorized transfer of data from Azure storage accounts.

As it is not an easy task, Microsoft provides us with tools for this, in the case of using a security framework we can always use the MCSB (Microsoft Cloud Security Baseline) which is a set of guidelines and best practices for securing Azure services, including Azure storage accounts. The MCSB provides recommendations for securing Azure storage accounts, such as enabling encryption, implementing access controls, monitoring access, and auditing activities:

Control Domain ASB Control ID ASB Control Title Responsibility Feature Name
Asset Management AM-2 Use only approved services Customer Azure Policy Support
Backup and recovery BR-1 Ensure regular automated backups Customer Azure Backup
Backup and recovery BR-1 Ensure regular automated backups Customer Service Native Backup Capability
Data Protection DP-1 Discover, classify, and label sensitive data Customer Sensitive Data Discovery and Classification
Data Protection DP-2 Monitor anomalies and threats targeting sensitive data Customer Data Leakage/Loss Prevention
Data Protection DP-3 Encrypt sensitive data in transit Microsoft Data in Transit Encryption
Data Protection DP-4 Enable data at rest encryption by default Microsoft Data at Rest Encryption Using Platform Keys
Data Protection DP-5 Use customer-managed key option in data at rest encryption when required Customer Data at Rest Encryption Using CMK
Data Protection DP-6 Use a secure key management process Customer Key Management in Azure Key Vault
Identity Management IM-1 Use centralized identity and authentication system Microsoft Azure AD Authentication Required for Data Plane Access
Identity Management IM-1 Use centralized identity and authentication system Customer Local Authentication Methods for Data Plane Access
Identity Management IM-3 Manage application identities securely and automatically Customer Managed Identities
Identity Management IM-3 Manage application identities securely and automatically Customer Service Principals
Identity Management IM-7 Restrict resource access based on conditions Customer Conditional Access for Data Plane
Identity Management IM-8 Restrict the exposure of credential and secrets Customer Service Credential and Secrets Support Integration and Storage in Azure Key Vault
Logging and threat detection LT-1 Enable threat detection capabilities Customer Microsoft Defender for Service / Product Offering
Logging and threat detection LT-4 Enable network logging for security investigation Customer Azure Resource Logs
Network Security NS-2 Secure cloud services with network controls Customer Disable Public Network Access
Network Security NS-2 Secure cloud services with network controls Customer Azure Private Link
Privileged Access PA-7 Follow just enough administration(least privilege) principle Customer Azure RBAC for Data Plane
Privileged Access PA-8 Choose approval process for third-party support Customer Customer Lockbox

And part of MCSB can be complemented with Azure Well Architected Framework, which provides guidance on best practices for designing and implementing secure, scalable, and reliable cloud solutions. The Well Architected Framework includes security best practices for Azure storage accounts, such as implementing security controls, access controls, encryption, monitoring, and auditing:

  1. Enable Azure Defender for all your storage accounts: Azure Defender for Storage provides advanced threat protection for Azure storage accounts. It helps detect and respond to security threats in real-time.
  2. Turn on soft delete for blob data: Soft delete helps protect your blob data from accidental deletion. It allows you to recover deleted data within a specified retention period.
  3. Use Microsoft Entitlement Management to authorize access to blob data: Microsoft Entitlement Management provides fine-grained access control for Azure storage accounts. It allows you to define and enforce access policies based on user roles and permissions.
  4. Consider the principle of least privilege: When assigning permissions to a Microsoft Entitlement security principal through Azure RBAC, follow the principle of least privilege. Only grant the minimum permissions required to perform the necessary tasks.
  5. Use managed identities to access blob and queue data: Managed identities provide a secure way to access Azure storage accounts without storing credentials in your code.
  6. Use blob versioning or immutable blobs: Blob versioning and immutable blobs help protect your business-critical data from accidental deletion or modification.
  7. Restrict default internet access for storage accounts: Limit default internet access to Azure storage accounts to prevent unauthorized access.
  8. Enable firewall rules: Use firewall rules to restrict network access to Azure storage accounts. Only allow trusted IP addresses to access the storage account.
  9. Limit network access to specific networks: Limit network access to specific networks or IP ranges to prevent unauthorized access.
  10. Allow trusted Microsoft services to access the storage account: Allow only trusted Microsoft services to access the storage account to prevent unauthorized access.
  11. Enable the Secure transfer required option: Enable the Secure transfer required option on all your storage accounts to enforce secure connections.
  12. Limit shared access signature (SAS) tokens to HTTPS connections only: Limit shared access signature (SAS) tokens to HTTPS connections only to prevent unauthorized access.
  13. Avoid using Shared Key authorization: Avoid using Shared Key authorization to access storage accounts. Use Azure AD or SAS tokens instead.
  14. Regenerate your account keys periodically: Regenerate your account keys periodically to prevent unauthorized access.
  15. Create a revocation plan for SAS tokens: Create a revocation plan and have it in place for any SAS tokens that you issue to clients. This will help you revoke access to the storage account if necessary.
  16. Use near-term expiration times on SAS tokens: Use near-term expiration times on impromptu SAS, service SAS, or account SAS to limit the exposure of the token.

Mixed strategies for data protection in Azure storage accounts

Diagram of the mixed strategies for data protection in Azure storage accounts:

graph LR
    A[Asset Management] -->B(AM-2)
    B --> C[Use only approved services]
    C --> D[Azure Policy] 
    E[Backup and recovery] -->F(BR-1)
    F --> G[Ensure regular automated backups]
    G --> H[Azure Backup]
    G --> I[Service Native Backup Capability]
    I --> I1["Azure Storage Account Configuration"]
    I1 --> I11["Turn on soft delete for blob data"]
    I1 --> I12["Use blob versioning or immutable blobs"]
graph LR
    J[Data Protection] -->K(DP-1)
    K --> L[Discover, classify, and label sensitive data]    
    L --> M[Sensitive Data Discovery and Classification]
    M --> M1["Microsoft Pureview"]       
    J --> N(DP-2)
    N --> O[Monitor anomalies and threats targeting sensitive data]
    O --> P[Data Leakage/Loss Prevention]
    P --> P1["Microsoft Defender for Storage"]
    J --> Q(DP-3)
    Q --> R[Encrypt sensitive data in transit]
    R --> S[Data in Transit Encryption]
    S --> S1["Azure Storage Account Configuration"]
    S1 --> S2["Enforce minimum TLS version"]
    J --> T(DP-4)
    T --> U[Enable data at rest encryption by default]
    U --> V[Data at Rest Encryption Using Platform Keys]
    V --> WW["Azure Storage Account Configuration"]    
    J --> W(DP-5)
    W --> X[Use customer-managed key option in data at rest encryption when required]
    X --> Y[Data at Rest Encryption Using CMK]
    Y --> WW["Azure Storage Account Configuration"]    
    J --> Z(DP-6)
    Z --> AA[Use a secure key management process]
    AA --> AB[Key Management in Azure Key Vault]
    AB --> AC["DEPRECATED"]
graph LR  
    AC[Identity Management] -->AD(IM-1)
    AD --> AE[Use centralized identity and authentication system]
    AE --> AE1["Microsoft Entra ID"]
    AE --> AF[Microsoft Entra ID Authentication Required for Data Plane Access]
    AF --> AF1["Azure Storage Account Configuration"]
    AF1 --> AF2["Disable Allow Shared Key authorization"]
    AD --> AG[Local Authentication Methods for Data Plane Access]
    AG --> AG1["Azure Storage Account Configuration"]
    AG1 --> AG2["Don't use SFTP if you don't need it"]
    AC --> AH(IM-3)
    AH --> AI[Manage application identities securely and automatically]
    AI --> AJ[Managed Identities]
    AI --> AK[Service Principals]
    AK --> AK1["Rotate or regenerate service principal credentials"]
    AC --> AL(IM-7)
    AL --> AM[Restrict resource access based on conditions]
    AM --> AN[Microsoft Entra Conditional Access for Data Plane]
    AC --> AO(IM-8)
    AO --> AP[Restrict the exposure of credential and secrets]    
    AP --> AQ[Service Credential and Secrets Support Integration and Storage in Azure Key Vault]    
    AQ --> AK1
    click AK1 "https://github.com/Azure-Samples/KeyVault-Rotation-StorageAccountKey-PowerShell" "Open this in a new tab" _blank

graph LR
AR[Logging and threat detection] -->AS(LT-1)
    AS --> AT[Enable threat detection capabilities]
    AT --> AU[Microsoft Defender for Service / Product Offering]
    AU --> AU1["Microsoft Defender for Storage"]
    AR --> AV(LT-4)
    AV --> AW[Enable network logging for security investigation]
    AW --> AX[Azure Resource Logs]
    AX --> AX1["Azure Monitor"]
    AX --> AX2["Azure Activity Log"]
    click AU1 "https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-storage-introduction" "Open this in a new tab" _blank
graph LR
    AY[Network Security] -->AZ(NS-2)
    AZ --> BA[Secure cloud services with network controls]
    BA --> BB["Azure Storage Account Configuration"]
    BB --> BB1[Disable Public Network Access]
    BB --> BB2[Allow trusted Microsoft services to access the storage account]
    BA --> BC[Azure Private Link]
    BC --> BC1["Azure Private Endpoint"]
    BA --> BD[Azure Network]
    BD --> BD1["Azure Service Endpoint"]
    BA --> BE["Network Security Perimeter"]

graph LR
    BD[Privileged Access] -->BE(PA-7)
    BE --> BF["Follow just enough administration(least privilege) principle"]
    BF --> BG[Azure RBAC for Data Plane]
    BG --> BG1["Azure RBAC"]
    BG1 --> BG2["Azure RBAC Roles"]
    BD --> BH(PA-8)
    BH --> BI[Choose approval process for third-party support]
    BI --> BJ[Customer Lockbox]
click BG2 "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/storage" "Open this in a new tab" _blank

Example of mixed strategies for data protection in Azure storage accounts

The following example illustrates how to implement mixed strategies for data protection in Azure storage accounts:

Conclusion

In conclusion, data threat modeling is an important process for identifying and addressing security vulnerabilities in Azure storage accounts. By identifying assets, threats, risks, and developing mitigation strategies, organizations can protect their data from security threats and ensure the security and integrity of their data assets. By following best practices and implementing security measures, organizations can prevent and detect data threats in Azure storage accounts and protect their data from security threats.

References

Tagging best practices in Azure

In this post, I will show you some best practices for tagging resources in Azure.

What are tags?

Tags are key-value pairs that you can assign to your Azure resources to organize and manage them more effectively. Tags allow you to categorize resources in different ways, such as by environment, owner, or cost center, and to apply policies and automation based on these categories.

If you don't know anything about tags, you can read the official documentation to learn more about them.

Why use tags?

There are several reasons to use tags:

  • Organization: Tags allow you to organize your resources in a way that makes sense for your organization. You can use tags to group resources by environment, project, or department, making it easier to manage and monitor them.

  • Cost management: Tags allow you to track and manage costs more effectively. You can use tags to identify resources that are part of a specific project or department, and to allocate costs accordingly.

  • Automation: Tags allow you to automate tasks based on resource categories. You can use tags to apply policies, trigger alerts, or enforce naming conventions, making it easier to manage your resources at scale.

Best practices for tagging resources in Azure

Here are some best practices for tagging resources in Azure:

  • Use consistent naming conventions: Define a set of standard tags that you will use across all your resources. This will make it easier to search for and manage resources, and to apply policies and automation consistently.

  • Apply tags at resource creation: Apply tags to resources when you create them, rather than adding them later. This will ensure that all resources are tagged correctly from the start, and will help you avoid missing or incorrect tags.

  • Use tags to track costs: Use tags to track costs by project, department, or environment. This will help you allocate costs more effectively, and will make it easier to identify resources that are not being used or are costing more than expected.

  • Define tags by hierarchy: Define tags in a hierarchy that makes sense for your organization, from more general at level subscription to more specific at resource group level.

  • Use inherited tags: Use inherited tags to apply tags to resources automatically based on their parent resources. This will help you ensure that all resources are tagged consistently, and will reduce the risk of missing or incorrect tags. Exist Azure Policy to enforce inherited tags for example, you can check all in Assign policy definitions for tag compliance

  • Don't use tags for policy filtering: If you use Azure Policy, it's highly recommended not to use tag filtering in your policy rules when the policy relates to security setting, when you use tags to filter, resources without tag appear Compliance. Azure Policy exemptions or Azure Policy exclusions are recommended.

  • Don't use tags for replace naming convention gaps: Tags are not a replacement for naming conventions. Use tags to categorize resources, and use naming conventions to identify resources uniquely.

  • Use tags for automation: Use tags to trigger automation tasks, such as scaling, backup, or monitoring. You can use tags to define policies that enforce specific actions based on resource categories.

  • Don't go crazy adding tags: Don't add too many tags to your resources. Keep it simple and use tags that are meaningful and useful. Too many tags can make it difficult to manage. You can begin with a small set of tags and expand as needed, for example: Minimum Suggested Tags

  • Not all Azure services support tags: Keep in mind that not all Azure services support tags. You can check in the Tag support for Azure resources to see which services support tags.

Conclusion

By using tags, you can organize and manage your resources more effectively, track and manage costs more efficiently, and automate tasks based on resource categories. I hope this post has given you a good introduction to tagging best practices in Azure and how you can use tags to optimize your cloud environment.

Restrict managed disks from being imported or exported

In this post, I will show you how to restrict managed disks from being imported or exported in Azure.

What are managed disks?

Azure Managed Disks are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines. Managed Disks are designed for high availability and durability, and they provide a simple and scalable way to manage your storage.

If you don't know anything about Azue Managed Disks, grab a cup of coffee( it will take you a while), you can read the official documentation to learn more about them.

Why restrict managed disks from being imported or exported?

There are several reasons to restrict managed disks from being imported or exported:

  • Security: By restricting managed disks from being imported or exported, you can reduce the risk of unauthorized access to your data.
  • Compliance: By restricting managed disks from being imported or exported, you can help ensure that your organization complies with data protection regulations.

How to restrict managed disks from being imported or exported

At deployment time

An example with azcli:

Create a managed disk with public network access disabled
## Create a managed disk with public network access disabled
az disk create --resource-group myResourceGroup --name myDisk --size-gb 128 --location eastus --sku Standard_LRS --no-wait --public-network-access disabled 
Create a managed disk with public network access disabled and private endpoint enabled

Follow Azure CLI - Restrict import/export access for managed disks with Private Links

At Scale

If you want to restrict managed disks from being imported or exported, you can use Azure Policy to enforce this restriction. Azure Policy is a service in Azure that you can use to create, assign, and manage policies that enforce rules and effects over your resources. By using Azure Policy, you can ensure that your resources comply with your organization's standards and service-level agreements.

To restrict managed disks from being imported or exported using Azure Policy, you can use or create a policy definition that specifies the conditions under which managed disks can be imported or exported. You can then assign this policy definition to a scope, such as a management group, subscription, or resource group, to enforce the restriction across your resources.

In this case we have a Built-in policy definition that restricts managed disks from being imported or exported Configure disk access resources with private endpoints

Conclusion

In this post, I showed you how to restrict managed disks from being imported or exported in Azure. By restricting managed disks from being imported or exported, you can reduce the risk of unauthorized access to your data and help ensure that your organization complies with data protection regulations.

Curiosly, restrict managed disks from being imported or exported, it's not a compliance check in the Microsoft cloud security benchmark but it's a good practice to follow.

Microsoft Entra ID Privileged Identity Management

In this post, I will show you how to use Microsoft Entra ID Privileged Identity Management (PIM) to manage and monitor access to privileged roles in your organization.

What is Microsoft Entra ID Privileged Identity Management?

Microsoft Entra ID Privileged Identity Management (PIM) is a service that helps you manage, control, and monitor access within your organization. It provides just-in-time privileged access to Azure AD and Azure resources, along with access reviews and monitoring capabilities.

Reasons to Use Microsoft Entra ID PIM

There are several reasons to use Microsoft Entra ID PIM:

  • Security: Microsoft Entra ID PIM helps you reduce the risk of unauthorized access to privileged roles.
  • Compliance: Microsoft Entra ID PIM helps you meet compliance requirements by providing access reviews and monitoring capabilities.
  • Efficiency: Microsoft Entra ID PIM provides just-in-time access to privileged roles, reducing the risk of unauthorized access.
  • Monitoring: Microsoft Entra ID PIM provides monitoring and alerts that help you detect and respond to suspicious activities.
  • Traceability: Microsoft Entra ID PIM provides an audit trail of all access requests and approvals, helping you track who has access to privileged roles.

Maybe you can't use Microsoft Entra ID PIM to log all changess that the users do in the system, but you can use Actor Change for that.

Key Features of Microsoft Entra ID PIM

Microsoft Entra ID PIM offers several key features that help you manage and monitor access to privileged roles:

  • Provide just-in-time privileged access to Microsoft Entra ID and Azure resources.
  • Assign time-bound access to resources using start and end dates.
  • Require approval to activate privileged roles.
  • Enforce multifactor authentication to activate any role.
  • Use justification to understand why users activate.
  • Get notifications when users activate privileged roles.
  • Conduct access reviews to ensure users still need roles.
  • Download audit history for internal or external audit.
  • Prevent removal of the last active Global Administrator and Privileged Role Administrator role assignments.

How to Use Microsoft Entra ID PIM

We can manage three types of "things" in Microsoft Entra ID PIM:

  • Microsoft Entra roles. Microsoft Entra roles are also referred to as directory roles. They include built-in and custom roles to manage Microsoft Entra ID and other Microsoft 365 online services.
  • PIM for Groups. To set up just-in-time access to the member and owner role of a Microsoft Entra security group. PIM for Groups provides an alternative way to set up PIM for Microsoft Entra roles and Azure roles. It also allows you to set up PIM for other permissions across Microsoft online services like Intune, Azure Key Vaults, and Microsoft Entra ID Protection.
  • Azure roles. Azure's role-based access control roles that grant access to management groups, subscriptions, resource groups, and resources.

Microsoft Entra ID roles

Note

If you want to use groups, you need create eligible groups, for now the maximum number of eligible groups is 500.

In the Microsoft Entra ID portal, you can manage Microsoft Entra ID roles by selecting the "Roles" tab. Here you can see all the roles that are available to you, as well as the roles that you have activated.

You can made the following actions:

  • Assign: Create assignments for Microsoft Entra ID roles, update existing assignments to ensure that users have just-in-time access to privileged roles.
  • Activate: Activate your eligible assignments to get just-in-time access to privileged roles.
  • Approve: List, approve, or deny activation requests for Microsoft Entra ID roles.
  • Audit: View and export a history of all assignments and activations done in PIM so you can identify attacks and stay compliant.

Ok, let's see how to assign a role to a group.

In the "Roles" tab, click on the role that you want to assign.

In Role settings, edit the settings for the role, modify Activation, Assignment, and Notification settings and then click "Update. These are the default settings:

Activation

Setting State
Activation maximum duration (hours) 8 hour(s)
On activation, require None
Require justification on activation Yes
Require ticket information on activation No
Require approval to activate No
Approvers None

Assignment

Setting State
Allow permanent eligible assignment Yes
Expire eligible assignments after -
Allow permanent active assignment Yes
Expire active assignments after -
Require Azure Multi-Factor Authentication on active assignment No
Require justification on active assignment Yes

Send notifications when members are assigned as eligible to this role:

Type Default recipients Additional recipients Critical emails only
Role assignment alert Admin None False
Notification to the assigned user (assignee) Assignee None False
Request to approve a role assignment renewal/extension Approver None False

Send notifications when members are assigned as active to this role:

Type Default recipients Additional recipients Critical emails only
Role assignment alert Admin None False
Notification to the assigned user (assignee) Assignee None False
Request to approve a role assignment renewal/extension Approver None False

Send notifications when eligible members activate this role:

Type Default recipients Additional recipients Critical emails only
Role activation alert Admin None False
Notification to activated user (requestor) Requestor None False
Request to approve an activation Approver None False

In the "Assignments" tab, click on "Add assignments". In Membership, select the scope type: Application, Device, Directory, Group, Service Principal or User (It's dependes of each role) and select the identity related that you want to assign the role to. We are going to select Directory and a eligible group, and then click "Next".

Info

App registrations are supported in PIM for Microsoft Entra ID roles but only in active assignments.

In the "Settings" tab, you can set the Assigment type: Eligible or I need to do something to activate and Active or I don't need to do nothing to activate my role. You can configure too if you want that the duration of the assignment is permanent or if you want to expire the assignment after a certain period of time. Once you're done, click "Assign".

You can set the activation settings, assignment settings, and notification settings for the assignment. Once you're done, click "Assign".

PIM for Groups

In the Microsoft Entra ID portal, you can manage PIM for Groups by selecting the "Groups" tab.

First you need to discover the groups that you want to manage. In the "Groups" tab, click on "Discover groups". In the "Discover groups" pane, you can search for groups by name. Once you've found the group you want to manage, click on "Add to PIM".

Info

You must be an owner of the group or have Microsoft Entra role that allows to discover and manage group in PIM.

Now, in the "Groups" tab, you can see all the groups that you have discovered.

In the "Groups" tab, click on the group that you want to manage. You can made the following actions under manage:

  • Assign: Create assignments for the member and owner role of the group, update existing assignments to ensure that users have just-in-time access to privileged roles.
  • Activate: Activate your eligible assignments to get just-in-time access to privileged roles.
  • Approve: List, approve, or deny activation requests for the member and owner role of the group.
  • Audit: View and export a history of all assignments and activations done in PIM so you can identify attacks and stay compliant.

Ok, let's see how to assign a role to a group.

In the "Groups" tab, click on the group that you want to assign a role to.

In Role settings, edit the settings for the role, modify Activation, Assignment, and Notification settings for members or users, these settings are the same that we saw in the Microsoft Entra ID roles section.

In the "Assignments" tab, click on "Add assignments". In Select role, select the scope type: Member or Owner and in Select members select the identity related that you want to assign the role to or groupm, if you select a group, you doesn't need a eligible group, and then click "Next".

In the "Settings" tab, you can set the Assigment type: Eligible or I need to do something to activate and Active or I don't need to do nothing to activate my role. You can configure too if you want that the duration of the assignment is permanent or if you want to expire the assignment after a certain period of time. Once you're done, click "Assign".

Info

App registrations are supported in PIM for Groups but only in active assignments. I think that this is very useful for IaC for example because you can assign a role to a service principal and you can activate the role when you need it.

Example of a sequence diagram of the activation process for a group:

sequenceDiagram
    participant User
    participant PIM
    participant Approver
    participant MFA
    participant Group

    User->>PIM: Logs in
    User->>PIM: Navigates to PIM and selects "My roles"
    User->>PIM: Selects eligible group
    User->>PIM: Requests activation
    PIM->>MFA: Requests multi-factor authentication
    MFA-->>User: MFA request
    User->>MFA: Provides MFA credentials
    MFA-->>PIM: MFA confirmation
    PIM->>User: Requests justification
    User->>PIM: Provides justification
    PIM->>Approver: Sends approval request
    Approver-->>PIM: Approval
    PIM-->>User: Activation confirmation
    PIM->>Group: Activates temporary membership
    Group-->>PIM: Activation confirmation
    PIM-->>User: Access granted

Azure roles

In the Microsoft Entra ID portal, you can manage Azure roles by selecting the "Azure resources" tab. Here you can see all the Azure roles that are available to you by scope, as well as the roles that you have activated.

First you need to select the Azure resource that you want to manage: Management groups, Subscriptions, Resource groups or Resources and follow Manage Resource.

Once here, same as the other sections, you can made the following actions for this scope:

  • Assign: Create assignments for the member and owner role of the group, update existing assignments to ensure that users have just-in-time access to privileged roles.
  • Activate: Activate your eligible assignments to get just-in-time access to privileged roles.
  • Approve: List, approve, or deny activation requests for the member and owner role of the group.
  • Audit: View and export a history of all assignments and activations done in PIM so you can identify attacks and stay compliant.

Ok, let's see how to assign a role to a identity in a scope.

Info

We already have a scope selected

In the "Assignments" tab, click on "Add assignments". In Select role, select the role that you want to assign and in Select members select the identity related that you want to assign the role to or group, if you select a group, you doesn't need a eligible group, and then click "Next".

In the "Settings" tab, you can set the Assigment type: Eligible or I need to do something to activate and Active or I don't need to do nothing to activate my role. You can configure too if you want that the duration of the assignment is permanent or if you want to expire the assignment after a certain period of time. Once you're done, click "Assign".

Info

App registrations are supported in PIM for Azure roles but only in active assignments. I think that this is very useful for IaC for example because you can assign a role to a service principal and you can activate the role when you need it.

Don't forget review settings for the role, modify Activation, Assignment, and Notification settings for members or users, these settings are the same that we saw in the Microsoft Entra ID roles section.

Conclusion

Microsoft Entra ID Privileged Identity Management (PIM) is a powerful service that helps you manage and monitor access to privileged roles in your organization. By using Microsoft Entra ID PIM, you can reduce the risk of unauthorized access, meet compliance requirements, and improve the efficiency of your organization. I hope this post has helped you understand how to use Microsoft Entra ID PIM and how it can benefit your organization.

If you want to play with Microsoft Enter ID PIM, you can use a test on a new tenant or the current one if you haven't used it before.