Tag: Security

Security Requirements for Microsoft Partners and Their Customers

bp1

1. Introduction: The Microsoft AI Cloud Partner Program serves as a framework to empower organizations through various benefits and incentives.1 Within this program, security stands as a fundamental pillar, critical for safeguarding the integrity of both the partner’s operational environment and the environments of their customers.1 This report aims to provide a comprehensive analysis of the specific security requirements that Microsoft partners must adhere to, drawing upon recent updates and guidelines. Furthermore, it will address the user’s inquiry regarding the necessity of achieving a Secure Score of 70 for both the partner and their customers.

The increasing sophistication of cyber threats necessitates a strong emphasis on security within the partner ecosystem. Microsoft’s partner network plays a vital role in delivering cloud services, making the security posture of each partner a crucial factor in maintaining the trust and security of the broader ecosystem. A vulnerability in a partner’s infrastructure could potentially expose numerous customers to risks. Therefore, Microsoft is proactively establishing security standards to mitigate these potential threats and ensure a secure environment for all stakeholders. The introduction of new benefits packages alongside these security requirements indicates a strategic alignment by Microsoft, where partners who demonstrate robust security practices are more likely to access enhanced resources and opportunities within the program. This interconnected approach incentivizes partners to prioritize security as a core aspect of their participation in the Microsoft AI Cloud Partner Program.

2. Mandatory Security Requirements for Microsoft Partners: Microsoft mandates several fundamental security obligations for partners participating in its programs. These requirements are designed to protect both the partners themselves and their customers from a range of cyber threats.

A primary mandatory security requirement is the enforcement of Multi-Factor Authentication (MFA) for all user accounts associated with a partner’s tenant.3 This obligation extends to partners involved in the Cloud Solution Provider (CSP) program, as well as Advisors and Control Panel Vendors.3 Partners must ensure that MFA is active whenever users sign in to Microsoft commercial cloud services, conduct transactions within the CSP program through Partner Center, or interact with relevant APIs.4 Microsoft provides its own MFA solution through Microsoft Entra security defaults, which is available at no additional cost.3 It is important to note that non-Microsoft MFA solutions are not taken into account when calculating the Partner Center security score.5 Failure to comply with these MFA requirements can result in the partner losing access to their customer tenants.4 The strong emphasis on MFA as a non-negotiable requirement underscores its critical role in preventing unauthorized access to sensitive environments. Passwords alone are often insufficient in today’s threat landscape, and MFA adds a crucial layer of defense by requiring users to provide multiple forms of verification, thereby significantly reducing the likelihood of account compromise. Microsoft’s firm stance on MFA reflects the widespread prevalence of credential theft in cyberattacks.

Another key mandatory requirement is the adoption of the Secure Application Model for partners who integrate with Partner Center APIs.3 This framework is essential for all app and user authentication models used in such integrations.3 By mandating this model, Microsoft aims to enhance the security of partner infrastructure and safeguard customer data from potential security risks.4 This shift towards the Secure Application Model for API integrations signifies a move towards more secure and less privileged access methods, ultimately reducing the potential attack surface. Traditional API access methods might involve storing credentials, which can introduce vulnerabilities. The Secure Application Model likely leverages modern authentication protocols like OAuth 2.0 and the principle of least privilege, ensuring that applications only possess the necessary permissions to perform their intended functions.

Beyond these core requirements, Microsoft also advises partners to embrace the principles of Zero Trust security.4 Furthermore, the removal of inactive Delegated Admin Privileges (DAP) is strongly recommended, as DAP is in the process of being deprecated and replaced by the more secure Granular Delegated Admin Privileges (GDAP).4 The recommendation to transition to GDAP and eliminate inactive DAP highlights Microsoft’s commitment to bolstering security through finer-grained access controls. DAP provides broad administrative rights to partner tenants over customer tenants, meaning that if a partner account with DAP is compromised, an attacker could potentially gain extensive control over the customer’s Microsoft 365 environment. GDAP, on the other hand, allows for the assignment of more specific roles with limited permissions, thereby mitigating this significant risk.

3. Understanding the Partner Center Security Score: To help partners assess and improve their security posture, Microsoft provides the Partner Center security score.5 This metric is designed to give partners a clear understanding of their tenant’s security level.5 It is accessible to direct-bill partners and indirect providers participating in the CSP, Value Added Reseller, or Advisor programs.5 The Partner Center security score ranges from 0 to 100 and reflects the tenant’s security based on adherence to specific security requirements established by Microsoft.5

The calculation of the Partner Center security score is based on the security scores assigned to individual security requirements.5 Each security requirement has a maximum possible score, ranging from 0 to 20 points, determined by its relative importance.5 Currently, a security requirement is considered either fully met, in which case it earns the maximum possible score, or not met, resulting in a score of 0 for that specific requirement.5 The overall Partner Center security score is calculated using the following formula: (Sum of individual security requirement scores) / (sum of individual security requirement max scores) * 100.5 This formula provides a weighted average of the partner’s compliance with the mandatory security measures.

There are several specific security requirements that contribute to the Partner Center security score, each with a defined maximum score 5:

  • Enable MFA: This requirement focuses on ensuring that multifactor authentication is enabled for all administrative roles within the partner’s tenant. Achieving this earns a maximum of 20 points. To be considered complete, every administrative user must be covered by MFA through security defaults, Conditional Access, or per-user MFA, and each admin user needs to have set up additional verification factors.5
  • Response to alerts is 24 hours or less on average: This requirement encourages partners to promptly address security alerts. Partners must triage and respond to alerts within 24 hours of their appearance in Partner Center, with an ideal goal of responding within one hour. Meeting this requirement contributes 10 points to the overall score. The average response time is calculated based on the activity of the last 30 days.5
  • Provide a security contact: This requirement emphasizes the importance of having a designated point of contact for security-related issues. Partners need to provide an email address, phone number, and the name of an individual or group responsible for responding to security incidents. Compliance with this requirement results in 20 points.5
  • All Azure subscriptions have a spending budget: This requirement applies specifically to partners operating under the new commerce experience. By setting up a spending budget for all their customers’ Azure subscriptions, partners can earn 10 points. Partners who are still on the traditional experience do not receive any points for this particular requirement.5
  • Users with administrative roles in the customer tenants must use MFA: This requirement extends the MFA mandate to the administrative roles within the partner’s customer tenants. Ensuring that MFA is enabled for these roles earns 20 points.5

It is important to reiterate that non-Microsoft MFA solutions are not supported for the “Enable MFA” requirement within the Partner Center security score framework and are therefore not factored into the score calculation.5 Partners can monitor and manage their security settings and view their current Partner Center security score through the Security requirements dashboard available in Partner Center.5 Furthermore, the partner security score API can be utilized to programmatically retrieve the score and gain insights into the security posture of their customers.6 The Partner Center security score is specifically tailored to the Microsoft ecosystem and the partner’s role within it. The requirements are designed to address common vulnerabilities and ensure partners are adhering to Microsoft’s security best practices for managing their own and their customers’ cloud environments. The weighting of different security requirements, such as the high scores assigned to MFA for both partner and customer administrators, clearly indicates Microsoft’s priorities in securing the partner channel by preventing unauthorized access with elevated privileges. The inclusion of the Azure spending budget requirement for new commerce partners suggests a connection between security and financial management, potentially aimed at preventing resource abuse or unauthorized consumption through proactive oversight.

To provide a clear overview of the Partner Center security score components, the following table summarizes the specific requirements and their corresponding maximum scores:

Security Requirement Maximum Score Description
Enable MFA 20 points Requires multifactor authentication (MFA) to be enabled for administrative roles within the partner’s tenant.
Response to alerts is 24 hours or less on average 10 points Requires partners to triage and respond to security alerts appearing in Partner Center within 24 hours, with a goal of responding within one hour.
Provide a security contact 20 points Requires partners to provide an email address, phone number, and name of an individual or group responsible for responding to security incidents.
All Azure subscriptions have a spending budget 10 points Applies to partners on the new commerce experience and requires them to set up a spending budget for all their customers’ Azure subscriptions. Partners on the traditional experience do not receive points for this requirement.
Users with administrative roles in the customer tenants must use MFA 20 points Requires MFA to be enabled for all users holding administrative roles within the partner’s customer tenants.

4. The Solutions Partner for Security Designation and Partner Capability Score: The Microsoft AI Cloud Partner Program offers various designations to recognize partners with specific expertise. One such designation is the Solutions Partner for Security, which distinguishes partners who possess the necessary skills to protect customers from increasingly sophisticated cyberattacks across diverse environments, including remote, hybrid, and cloud infrastructures.2 To achieve this designation, partners are required to meet certain qualification criteria based on their partner capability score for security.8

The partner capability score is a composite score derived from a partner’s performance, skilling, and customer success, using data already recorded within Partner Center.8 To attain the Solutions Partner for Security designation, a partner must achieve a minimum score of 70 points, with at least one point in each of the following four key metrics 8:

  • Performance – Net customer adds
  • Skilling – Intermediate certifications
  • Customer success – Usage growth
  • Customer success – Deployments

Microsoft offers two distinct pathways for partners to pursue this designation: the Enterprise path and the Small and Medium Business (SMB) path, each with its own specific criteria.8 Microsoft evaluates partners on both paths and ultimately selects the highest score achieved from either path at the solution area level to determine qualification.8 This flexibility allows partners to leverage their strengths and focus on the path that best aligns with their business strategy and customer base.

The partner capability score for security is comprised of four metrics organized into three categories 8:

  • Performance (Maximum 20 points): This category assesses a partner’s ability to expand their customer base by leveraging Microsoft Security products and services. The primary metric is Net customer adds for both Microsoft 365 and Azure Security workloads. The calculation methods and eligibility criteria for net customer adds differ between the Enterprise and SMB tracks, taking into account factors like Azure Consumed Revenue (ACR) and the number of paid licenses for specific Microsoft 365 workloads.8
  • Skilling (Maximum points vary based on track): This category measures the security-related skills acquired by a partner organization through the number of certified individuals. The key metric is Intermediate certifications. Both the Enterprise and SMB tracks have mandatory prerequisites, requiring individuals to complete the Azure Security Engineer Associate and Microsoft Security Operations Analyst certifications. Additional points are awarded for completing advanced certifications such as Microsoft Cybersecurity Architect expert, Microsoft Identity and Access Administrator, or Microsoft Information Protection Administrator. The specific requirements and point allocations for these certifications vary between the Enterprise and SMB tracks.8
  • Customer Success: This category evaluates a partner’s effectiveness in driving the adoption and growth of Microsoft security solutions among their customers. It consists of two metrics:
  • Deployments (Maximum 20 points): This metric awards points based on the growth in the number of customer deployments of eligible Azure and Microsoft 365 security workloads. Similar to the Performance category, the calculation methods and eligible workloads differ between the Enterprise and SMB tracks.8
  • Usage growth (Maximum 20 points): This metric focuses on the growth in the usage of security workloads by a partner’s customers, measured by Security Azure consumed revenue (ACR) and the growth in the number of Microsoft 365 protected users. Again, the thresholds and calculation methods vary between the Enterprise and SMB tracks.8

The partner capability score for security is one of six solution areas within the broader Microsoft AI Cloud Partner Program.9 Achieving the Solutions Partner for Security designation comes with various benefits, including access to go-to-market services, technical advisory hours, technical support incidents, and exclusive product benefits tailored for security.2 The requirement of a minimum partner capability score of 70 points is specifically for attaining the Solutions Partner for Security designation and is not a general mandatory security requirement for all partners. The multi-faceted nature of the partner capability score, encompassing performance, skilling, and customer success, underscores Microsoft’s emphasis on a holistic approach to security expertise. To achieve this designation, partners must demonstrate not only that their staff possess the necessary security skills but also that they are actively acquiring new security customers and driving the adoption and usage of Microsoft security solutions among their existing customers. The existence of separate Enterprise and SMB tracks acknowledges the diverse business models within the partner ecosystem and provides achievable paths for different types of partners to demonstrate their security capabilities.

To further clarify the metrics for achieving the Solutions Partner for Security designation, the following table provides a summary of the requirements for both the Enterprise and SMB tracks:

Category Metric Enterprise Track Details SMB Track Details
Performance Net customer adds Each net new customer contributes two points, up to a maximum of 20 points from ten customers. Each net new customer contributes four points, up to a maximum of 20 points from five customers.
Skilling Intermediate certifications
Step 1 (Required): At least two people must complete the Azure Security Engineer Associate certification (0 points).
Step 2 (Required): At least two people must complete the Microsoft Security Operations Analyst certification (0 points).
Step 3: Each certified individual completing one of the advanced certifications adds 6.67 points.
Step 1 (Required): At least one person must complete the Azure Security Engineer Associate certification (4 points).
Step 2 (Required): At least one person must complete the Microsoft Security Operations Analyst certification (4 points).
Step 3: Each certified individual completing one of the advanced certifications adds 8 points.
Customer Success Deployments Each net new customer contributes 3.3 points, up to a maximum of 20 points from six deployments. Each net new customer contributes 3.3 points, up to a maximum of 20 points from six deployments.
Customer Success Usage growth Every Security Azure consumed revenue (ACR) growth of USD 1,250 earns one point (maximum 20 points). Every Microsoft 365 protected users growth of 125 earns one point (maximum 20 points). Every Security Azure consumed revenue (ACR) growth of USD 750 earns one point (maximum 20 points). Every Microsoft 365 protected users growth of 50 earns one point (maximum 20 points).

5. Security Considerations for Customer Tenants: Ensuring the security of customer tenants is a critical aspect of the Microsoft partner program. While partners are primarily responsible for their own security, they also play a crucial role in safeguarding the environments of their customers.

One specific requirement that directly links partner security to customer security is the mandate for MFA for administrative roles within customer tenants.5 This requirement carries a significant weight of 20 points in the Partner Center security score calculation for the partner.5 This high weighting underscores the importance Microsoft places on securing privileged access within customer environments. Furthermore, the Partner Center provides partners with insights into customer MFA adoption statistics, allowing them to monitor and encourage the enablement of MFA across their customer base.5 This visibility empowers partners to identify potential security gaps and proactively engage with their customers to promote this essential security measure.

Microsoft emphasizes that partners have a vital role in protecting customer trust by implementing all necessary security measures.4 The partner security score API also enables partners to gain insights into their customers’ overall security posture.7 While the provided information highlights the importance of customer MFA and offers tools for partners to monitor it, there is no explicit mention of a specific security score requirement for customer tenants that partners must meet.6 However, the strong emphasis on MFA for customer administrators and the availability of customer security insights within the Partner Center framework indicate that Microsoft expects partners to have a clear understanding of their customers’ security practices and to take proactive steps to improve them. Although partners are not directly penalized based on a customer’s overall Microsoft Secure Score, their own Partner Center security score is directly affected by the enablement of MFA for administrative roles within their customer tenants. This creates a strong incentive for partners to actively promote and facilitate the adoption of MFA among their customers’ administrators, reflecting a shared responsibility for security within the Microsoft ecosystem.

6. Microsoft Secure Score vs. Partner Center Security Score: It is important to distinguish between the Microsoft Secure Score, which is a broad measure of an organization’s overall security posture, and the Partner Center security score, which is specifically designed for Microsoft partners.

The Microsoft Secure Score is a measurement of an organization’s security health across Microsoft 365, Microsoft Entra ID, and other Microsoft services.11 A higher score indicates that more of the recommended security actions have been implemented.11 This score helps organizations to understand their current security state, identify areas for improvement, and compare their posture against industry benchmarks.11 Points are awarded for configuring recommended security features, performing security-related tasks, or mitigating risks through non-Microsoft solutions.11 Security defaults within Microsoft Entra ID contribute to the Microsoft Secure Score.11 While a target of 80% or higher is generally considered a good Microsoft Secure Score, this can vary depending on the organization’s size and industry.12 The Microsoft Secure Score can be accessed through the Microsoft Defender portal.11

Conversely, the Partner Center security score is specific to Microsoft partners participating in the CSP, Value Added Reseller, or Advisor programs.5 Its primary focus is on the security posture of the partner’s tenant and, to a certain extent, their customers’ tenants, particularly concerning MFA for administrative roles, within the context of the partner program.5 This score is calculated based on specific mandatory security requirements established by Microsoft for its partners.5 The Partner Center security score ranges from 0 to 100 5 and can be monitored and managed through the Security requirements dashboard in Partner Center.5 The partner security score API provides a quantifiable measure of a partner’s security performance and also offers insights into the security posture of their customers.6 The Microsoft Secure Score serves as a comprehensive security assessment tool for any organization using Microsoft products, whereas the Partner Center security score is a specific set of requirements and a scoring mechanism tailored by Microsoft for its partners within the partner program framework. While achieving a high Microsoft Secure Score is generally indicative of strong security practices, maintaining a high Partner Center security score is crucial for partners to ensure compliance with program requirements and potentially access certain benefits or maintain their partner status.

7. Addressing the Secure Score of 70 Requirement: The user specifically asked whether a Secure Score of 70 would be required for both the partner and their customers based on the provided blog post. The analysis of the research snippets reveals important distinctions regarding the use of the number 70 in relation to security within the Microsoft partner program.

The research indicates that a score of 70 is relevant in the context of the Solutions Partner for Security designation. To attain this specific designation, a partner needs to achieve a minimum partner capability score of 70 for the security solution area.8 It is crucial to understand that this partner capability score is based on a combination of performance metrics (net customer adds), skilling (intermediate certifications), and customer success metrics (usage growth and deployments), and it is distinct from the Partner Center security score.8

The provided snippets do not explicitly state a requirement for partners to maintain a Partner Center security score of exactly 70. The Partner Center security score is designed to measure a partner’s adherence to specific mandatory security requirements set by Microsoft. The general principle is to aim for the highest possible score by ensuring that all these mandatory requirements are fully met.5 There is no indication that a score of 70 is a specific threshold that partners must reach for this particular metric.

Similarly, the research snippets do not specify a mandatory Microsoft Secure Score of 70 for customer tenants that partners are obligated to ensure. While Microsoft encourages partners to promote security best practices among their customers, such as the implementation of MFA for administrative roles, there is no mention of a specific Microsoft Secure Score target for customers within the defined partner program requirements.6 The user’s query might stem from a general understanding that a security score around 70-80 is often considered a reasonable benchmark for overall security posture. However, it is essential to differentiate between the various scoring mechanisms within the Microsoft ecosystem and the specific context in which they are used. The Partner Center security score is about meeting specific mandated requirements for partners, while the partner capability score of 70 is related to achieving a particular Solutions Partner designation. Therefore, partners should primarily focus on meeting all the mandatory security requirements that contribute to the Partner Center security score to ensure compliance with the partner program, rather than focusing on an arbitrary score of 70 for this metric or for their customers’ overall Microsoft Secure Score.

8. Recommendations for Microsoft Partners: To effectively navigate the security requirements of the Microsoft AI Cloud Partner Program and enhance the security posture of both their own organizations and their customers, partners should consider the following recommendations:

  • Prioritize Enabling Multi-Factor Authentication (MFA): Ensure that MFA is enforced for all user accounts, both administrative and standard, within the partner tenant. This can be achieved using Microsoft Entra security defaults or other compatible MFA methods. Additionally, actively encourage and assist customers in enabling MFA for all their users, with a particular focus on administrative roles. Leverage the customer MFA statistics available in Partner Center to identify any gaps in adoption.3
  • Adopt the Secure Application Model: If your organization integrates with Partner Center APIs, it is crucial to ensure that all applications adhere to the Secure Application Model framework for authentication and authorization. This will help protect both your infrastructure and your customers’ data.3
  • Maintain Responsiveness to Security Alerts: Establish clear and efficient processes for monitoring and responding to security alerts that appear within Partner Center. Aim for a response time within 24 hours, with an ideal target of one hour, to maximize your Partner Center security score and mitigate potential risks.5
  • Provide and Maintain a Security Contact: Ensure that the designated security contact information (including name, email address, and phone number) within Partner Center is accurate and kept up-to-date. This ensures that Microsoft can effectively communicate with your organization in the event of any security-related issues.5
  • Set Azure Spending Budgets for Customers (New Commerce): For partners who are operating under the new commerce experience, it is important to configure spending budgets for all customer Azure subscriptions. This action contributes to your Partner Center security score and can also help in managing and monitoring resource consumption.5
  • Aim for the Solutions Partner for Security Designation: If your organization has security as a core area of expertise, consider working towards achieving the Solutions Partner for Security designation. This involves focusing on improving your performance metrics (net customer adds), skilling levels (relevant certifications), and customer success in deploying and driving the usage of security-related workloads.8
  • Regularly Review the Security Requirements Dashboard: Make it a practice to regularly utilize the Security requirements dashboard within Partner Center to monitor your current security score and identify any areas where improvements can be made to meet the mandatory requirements.5
  • Leverage the Partner Security Score API: Explore the potential of using the partner security score API to gain deeper insights into both your organization’s and your customers’ security posture. This proactive approach can help in identifying and addressing potential risks before they escalate.6
  • Transition to Granular Delegated Admin Privileges (GDAP): If your organization is still using Delegated Admin Privileges (DAP), plan and execute a migration to Granular Delegated Admin Privileges (GDAP). GDAP offers enhanced security by providing more granular and least-privileged access to customer tenants, reducing the potential impact of compromised partner accounts.4

These recommendations highlight the importance of a multi-layered approach to security, encompassing technical implementations like MFA and secure application models, operational procedures for alert management, and strategic goals such as achieving the Solutions Partner designation. Microsoft provides partners with both the requirements and the necessary tools, such as the Partner Center dashboard and API, to effectively manage and continuously improve their security posture, demonstrating a strong commitment to security within the partner program.

9. Conclusion: In summary, Microsoft partners are required to adhere to several mandatory security measures to ensure the safety and integrity of their own operations and the environments of their customers. These include the critical step of enforcing Multi-Factor Authentication (MFA) on their partner tenants and adopting the Secure Application Model when integrating with Partner Center APIs. The Partner Center security score serves as a key indicator of a partner’s compliance with these specific security requirements.

Achieving a partner capability score of at least 70 is a specific requirement for attaining the Solutions Partner for Security designation, which recognizes expertise in this critical area. This score is based on a holistic evaluation of a partner’s performance, skilling, and success in delivering security solutions. While promoting the adoption of MFA for administrative roles within customer tenants is a crucial responsibility for partners and directly impacts their Partner Center security score, the research does not indicate an explicit requirement for a specific Microsoft Secure Score target for customers.

Therefore, based on the analysis of the provided research snippets, a Partner Center security score of 70 is not explicitly mandated as a general requirement. Furthermore, a Microsoft Secure Score of 70 is not a defined requirement for customers within the context of the partner program requirements discussed. Instead, partners should prioritize meeting all the mandatory security requirements outlined by Microsoft to achieve the highest possible Partner Center security score. Simultaneously, they should actively work to improve the security posture of their customer tenants by promoting and facilitating the adoption of security best practices, particularly the implementation of Multi-Factor Authentication.

Works cited
  1. New benefits packages for the Microsoft AI Cloud Partner Program, accessed on May 9, 2025, https://www.microsoft.com/en-us/americas-partner-one/News/new-benefits-packages-for-the-microsoft-ai-cloud-partner-program
  2. Counter cyber threats as a Solutions Partner for Security, accessed on May 9, 2025, https://partner.microsoft.com/de-de/blog/article/counter-cyber-threats-as-a-solutions-partner-for-security
  3. Partner security requirements FAQ – Partner Center | Microsoft Learn, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/security/partner-security-requirements-faq
  4. Partner security requirements – Partner Center | Microsoft Learn, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/security/partner-security-requirements
  5. Security requirements dashboard for Partner Center – Learn Microsoft, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/security/security-requirements
  6. What is the Security workspace? – Partner Center | Microsoft Learn, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/security/overview
  7. Use the partner security score API in Microsoft Graph (preview), accessed on May 9, 2025, https://learn.microsoft.com/en-us/graph/api/resources/partner-security-score-api-overview?view=graph-rest-beta
  8. Solutions Partner for Security – Partner Center | Microsoft Learn, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/membership/solutions-partner-security
  9. Solutions Partner program Partner Capability Score – Partner Center | Microsoft Learn, accessed on May 9, 2025, https://learn.microsoft.com/en-us/partner-center/membership/partner-capability-score
  10. Specialization – Microsoft Partner Network, accessed on May 9, 2025, https://partner.microsoft.com/en-us/partnership/specialization
  11. Microsoft Secure Score – Microsoft Defender XDR, accessed on May 9, 2025, https://learn.microsoft.com/en-us/defender-xdr/microsoft-secure-score
  12. Microsoft Secure Score – A Complete Overview – AdminDroid Blog, accessed on May 9, 2025, https://blog.admindroid.com/boost-up-your-security-posture-with-microsoft-secure-score/

Benefits of using KQL to improve the security

Screenshot 2025-05-08 091712

What is KQL?

KQL is a powerful, read-only query language designed to explore data and discover patterns. It’s used across various Microsoft services, most notably for our discussion:

  1. Microsoft Sentinel: A cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) solution.

  2. Microsoft 365 Defender: An XDR (Extended Detection and Response) platform that provides integrated threat protection, detection, and response across endpoints, identities, email, and cloud apps. Its “Advanced Hunting” feature uses KQL.

Essentially, KQL allows you to “talk” to the vast amounts of security log data generated by your M365 services.

Benefits of Using KQL to Improve M365 Tenant Security:

  1. Proactive Threat Hunting:

    • Beyond Built-in Detections: While Microsoft provides many out-of-the-box detections, KQL allows you to hunt for specific, emerging threats, anomalous behaviors, or indicators of compromise (IOCs) that might not trigger a standard alert.

    • Hypothesis-Driven Investigation: You can form a hypothesis (e.g., “Are there any unusual external email forwarding rules set up?”) and use KQL to validate it against your logs.

  2. Deep Incident Investigation & Root Cause Analysis:

    • Contextual Understanding: When an alert fires, KQL lets you dive deep into the raw logs (Azure AD sign-ins, Exchange mail flow, SharePoint activity, Defender alerts, etc.) to understand the full scope, timeline, and impact of an incident.

    • Connecting the Dots: You can join data from different sources (e.g., correlate a suspicious sign-in with subsequent file access or email activity) to build a complete picture.

  3. Custom Detection Rule Creation:

    • Tailored Alerts: If you identify a pattern of malicious activity specific to your environment or a new threat vector, you can write KQL queries and turn them into custom analytic rules in Microsoft Sentinel or custom detection rules in M365 Defender. This automates the detection of future occurrences.

    • Reduced False Positives: By crafting precise KQL queries, you can fine-tune detection logic to minimize false positives and focus on genuine threats.

  4. Enhanced Visibility & Reporting:

    • Custom Dashboards & Workbooks: KQL queries can power custom dashboards and workbooks in Sentinel, providing tailored views of your security posture, trends, and key metrics (e.g., risky sign-ins by location, malware detections over time).

    • Compliance & Auditing: Extract specific data needed for compliance reporting or internal audits, such as administrator activity logs or access to sensitive data.

  5. Understanding Your Environment:

    • Baseline Activity: Use KQL to understand normal patterns of behavior in your tenant. This makes it easier to spot deviations that could indicate a security issue.

    • Configuration Audits: Query configurations (e.g., MFA status, conditional access policies, sharing settings) to ensure they align with security best practices.

  6. Speed and Scalability:

    • KQL is optimized for querying massive datasets very quickly, which is essential when dealing with the volume of telemetry generated by M365 services.

How to Get Started Using KQL for M365 Security:

  1. Access the Right Portals:

    • Microsoft 365 Defender Portal (security.microsoft.com):
      • Navigate to Hunting > Advanced Hunting. This is where you’ll query data from Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Azure AD Identity Protection.
    • Microsoft Sentinel (via Azure Portal portal.azure.com):
      • Navigate to your Log Analytics Workspace connected to Sentinel, then select Logs. This is where you’ll query data ingested into Sentinel, which can include M365 logs, Azure activity, third-party logs, etc.

  2. Ensure Data Ingestion (Prerequisite):

    • For Microsoft 365 Defender Advanced Hunting: Most data from the Defender suite is automatically available.

    • For Microsoft Sentinel: You need to set up Data Connectors for the M365 services you want to query (e.g., Azure Active Directory, Office 365, Microsoft Defender for Cloud Apps).

  3. Learn Basic KQL Syntax:

    • KQL queries are a sequence of data transformation steps piped (|) together.

    • TableName: Start by specifying the table you want to query (e.g., SigninLogs, EmailEvents, DeviceEvents).

      • In Advanced Hunting, the schema is usually pre-loaded on the left.

      • In Sentinel (Logs), you can see available tables in the schema pane.
    • | where Condition: Filters rows based on a condition (e.g., | where ResultType == "50126" for failed logins due to MFA).

    • | project Column1, Column2: Selects specific columns.

    • | summarize Aggregation by GroupingColumn: Aggregates data (e.g., | summarize count() by UserPrincipalName).

    • | top N by Column [desc/asc]: Shows the top N results.

    • | extend NewColumn = Calculation: Creates a new column.

    • | join kind=inner (OtherTable) on CommonColumn: Combines rows from two tables.

    • Time Range: Use the time picker in the UI or specify in the query (e.g., | where TimeGenerated > ago(1d)).

  4. Explore Schemas and Tables:

    • In both Advanced Hunting and Sentinel Logs, there’s a schema explorer. Familiarize yourself with the available tables and their columns. Common tables include:

      • M365 Defender: IdentityLogonEvents, EmailEvents, UrlClickEvents, DeviceProcessEvents, CloudAppEvents.

      • Sentinel (often from Azure AD): SigninLogs, AuditLogs, OfficeActivity, SecurityAlert.

  5. Start with Simple Queries and Build Up:

    • Example: See the last 10 sign-ins. 
      SigninLogs // Or IdentityLogonEvents in M365 Defender
| top 10 by TimeGenerated desc
    • Example: Count failed sign-ins by user in the last day. 
      SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != 0 and ResultType != 50140 // Filter for various failure codes, 0 and 50140 are common success/interrupts
| summarize FailureCount = count() by UserPrincipalName
| top 10 by FailureCount desc

  6. Use IntelliSense and Built-in Help:

    • The query editors in both portals have IntelliSense to help you with table names, column names, and operators.

    • Look for example queries or templates provided by Microsoft.

  7. Leverage Microsoft’s Learning Resources:

    • Microsoft Learn KQL Path: Search for “KQL” on Microsoft Learn. There are excellent modules.

    • Microsoft Sentinel Documentation: Full of KQL examples for security scenarios.

    • Microsoft 365 Defender Advanced Hunting Documentation: Similar to Sentinel docs but focused on Defender data.

    • GitHub Repositories: Microsoft and the community share many KQL queries for Sentinel and M365 Defender on GitHub.

  8. Practice, Practice, Practice:

    • Take an existing alert and try to find the related raw logs.

    • Think of a security question (e.g., “Has anyone downloaded an unusual number of files from SharePoint recently?”) and try to answer it with KQL.

Example KQL Queries for M365 Security:

  • Suspicious Sign-in Locations (Sentinel – SigninLogs):

    SigninLogs
| where TimeGenerated > ago(7d)
| where Location != "YourExpectedCountry" // Be more specific with IPs or city if possible
| summarize count() by UserPrincipalName, Location, IPAddress
| sort by count_ desc

  • New Email Inbox Forwarding Rule (M365 Defender – CloudAppEvents):

    CloudAppEvents
| where TimeGenerated > ago(1d)
| where Application == "Microsoft Exchange Online"
| where ActionType == "New-InboxRule"
| where RawEventData has "ForwardTo" or RawEventData has "RedirectTo"
| project Timestamp, AccountObjectId, UserAgent, RawEventData

  • Potentially Malicious File Downloads by a User (M365 Defender – CloudAppEvents for SharePoint/OneDrive):

    CloudAppEvents
| where TimeGenerated > ago(1d)
| where ActionType == "FileDownloaded"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive for Business")
// Optional: add filters for specific file types if known (e.g., | where FileName endswith ".exe" or FileName endswith ".ps1")
| summarize FilesDownloaded = dcount(FileName), TotalSize = sum(tolong(RawEventData.FileSize)) by Actor = UserPrincipalName, bin(TimeGenerated, 1h)
| where FilesDownloaded > 10 // Example threshold

Key Takeaway:

KQL is an indispensable skill for modern security operations in the Microsoft ecosystem. It empowers you to move from reactive alert chasing to proactive threat hunting and deep investigation, significantly improving your M365 tenant’s security posture. Start simple, leverage the available resources, and gradually build your expertise.

How effective is enabling Windows Attack Surface Reduction in preventing a Windows device from Malware?

image

Enabling Windows Attack Surface Reduction (ASR) rules is **highly effective** in preventing a Windows device from many common types of malware and attack techniques. It’s a crucial component of a defense-in-depth strategy.

However, it’s not a silver bullet and its effectiveness depends on several factors.

Here’s a breakdown of its effectiveness:

How ASR Works and Why It’s Effective:

  1. Targets Common Attack Vectors: ASR rules are specifically designed to block behaviors commonly used by malware to infect machines and execute malicious code. This includes:

    • Office Application Abuse: Blocking Office apps from creating executable content, injecting into other processes, creating child processes, or running macros deemed malicious.

    • Script-Based Attacks: Blocking obfuscated scripts (JavaScript, VBScript, PowerShell), or scripts that download/run payloads.

    • Email-Based Threats: Blocking executable content from email clients and webmail.

    • Exploitation Techniques: Preventing credential stealing (e.g., from LSASS), process hollowing, or unsigned/untrusted executables from running from USB drives.

    • Ransomware Behaviors: Some rules can help mitigate common ransomware tactics.

  2. Pre-Execution and Early-Execution Prevention: Many ASR rules intervene before malware fully executes or early in its execution chain, stopping the attack before significant damage occurs. This is more proactive than relying solely on detection of already-running malware.

  3. Reduces Reliance on Signatures: While traditional AV relies heavily on signatures for known malware, ASR focuses on behaviors. This makes it more effective against new or polymorphic malware that might not have a signature yet.

  4. Complements Antivirus: ASR works alongside Microsoft Defender Antivirus (or other AV solutions) and Endpoint Detection and Response (EDR) solutions like Microsoft Defender for Endpoint. It adds an extra layer of proactive defense.

Factors Influencing Effectiveness:

  1. Which Rules Are Enabled: There are many ASR rules. Not all may be suitable for every environment. Enabling more relevant rules increases protection. Some key high-impact rules include:

    • Block Office applications from creating child processes.

    • Block Adobe Reader from creating child processes.

    • Block execution of potentially obfuscated scripts.

    • Block credential stealing from the Windows local security authority subsystem (lsass.exe).

    • Block executable content from email client and webmail.

  2. Mode of Operation (Audit vs. Block):

    • Audit Mode: Logs what would have been blocked. Essential for testing and identifying potential legitimate application conflicts (false positives) before enabling block mode. Provides visibility but no active prevention.

    • Block Mode: Actively prevents the flagged behaviors. This is where the true preventative power lies.

  3. Exclusions: Properly configured exclusions are necessary for legitimate applications that might otherwise trigger ASR rules. Overly broad exclusions can reduce effectiveness.

  4. Configuration and Management: Consistent deployment and management (e.g., via Group Policy, Intune, MEMCM) ensure all devices are protected.

  5. Attacker Sophistication: While ASR stops many common TTPs (Tactics, Techniques, and Procedures), highly sophisticated attackers might find novel ways to bypass specific rules or use techniques not covered by ASR.

  6. Keeping Systems Updated: Microsoft continually updates ASR rules and the underlying Defender platform to address new threats and improve detection logic.

Limitations:

  • False Positives: The primary challenge. Some legitimate applications, especially older or custom-developed ones, might exhibit behaviors that trigger ASR rules. Thorough testing in audit mode is crucial.

  • Not a Complete Solution: ASR doesn’t cover every conceivable attack vector. It won’t stop zero-day exploits against unpatched vulnerabilities if the exploit doesn’t trigger a specific ASR rule behavior.

  • User Experience: If not carefully tuned, blocking legitimate actions can frustrate users.

Conclusion:

Enabling Windows Attack Surface Reduction rules is a very effective proactive measure to significantly reduce the likelihood of malware infection from common attack vectors. It raises the bar for attackers, forcing them to use less common or more sophisticated techniques.

For maximum effectiveness:

  • Start in Audit Mode: Understand the impact on your environment.

  • Gradually Enable Rules in Block Mode: Prioritize rules that block high-risk behaviors with low potential for false positives first.

  • Monitor and Tune: Continuously review ASR logs and adjust exclusions as needed.

  • Use in Conjunction with Other Security Layers: ASR should be part of a comprehensive security strategy that includes antivirus, EDR, firewalls, patching, and user education.

When implemented thoughtfully, ASR is a powerful, built-in tool that provides a substantial boost to Windows endpoint security.

Enforce device compliance and app protection policies on BYOD with M365 Business premium

image

M365 Business Premium is well-suited for this because it includes key components like:

  • Microsoft Intune (Part of Microsoft Endpoint Manager): For Mobile Device Management (MDM) and Mobile Application Management (MAM).

  • Azure Active Directory (Azure AD) Premium P1: Provides Conditional Access policies, which are crucial for enforcement.

  • Information Protection Features: For data security.

Here’s a step-by-step approach, focusing on the least intrusive but effective methods for BYOD:

Core Strategy: Prioritize App Protection Policies (MAM) without Full Device Enrollment (MDM)

This is often the preferred approach for BYOD because it protects corporate data within specific apps without taking full control over the user’s personal device. It respects user privacy while securing business information.

Steps:

  1. Configure App Protection Policies (APP / MAM Policies):

    • Go to the Microsoft Endpoint Manager admin center: (endpoint.microsoft.com)

    • Navigate: Apps > App protection policies.

    • Create Policy: Click “+ Create policy” and select the platform (iOS/iPadOS or Android).

    • Basics: Give the policy a descriptive name (e.g., “BYOD App Protection – Android”).

    • Apps:
      • Target policy to: Select “All Public Apps” or “Selected Apps”. For BYOD, often start with core Microsoft apps (Outlook, Teams, OneDrive, Edge, Office apps). You can add other MAM-enabled apps later.

      • Important: This policy only applies to apps that support Intune App Protection.
    • Data Protection: This is the core. Configure settings like:

      • Prevent backup: Block backing up work data to personal cloud storage (iCloud/Google Cloud).

      • Restrict cut, copy, paste: Control data movement between managed (work) apps and unmanaged (personal) apps. Often set to “Policy managed apps”.

      • Encryption: Ensure app data is encrypted. (Usually enabled by default).

      • Screen capture: Block screen capture for Android (iOS requires device management).

      • Save copies of org data: Prevent saving work files to local/personal storage. Allow saving only to managed locations like OneDrive for Business or SharePoint.

      • Receive data from other apps: Control if managed apps can receive data from unmanaged apps.

      • Open data in Org documents: Control which apps can open work documents.
    • Access Requirements: Define how users access the protected apps:

      • PIN for access: Require a separate PIN (or biometrics) to open the work apps. Configure PIN complexity and timeout.

      • Work or school account credentials for access: Force re-authentication after a period of inactivity.
    • Conditional Launch: Set conditions that must be met for the app to launch (e.g., block rooted/jailbroken devices, minimum OS version, app version).

    • Assignments:
      • Target: Assign the policy to specific Azure AD user groups containing your BYOD users. Do not assign to device groups for MAM-without-enrollment.
    • Review + Create: Finalize and create the policy.

  2. Configure Conditional Access Policies in Azure AD:

    • This is how you enforce the use of protected apps and check device state (even without full enrollment).

    • Go to the Microsoft Endpoint Manager admin center or Azure AD portal: (portal.azure.com)

    • Navigate: Endpoint Security > Conditional Access (in MEM) or Azure Active Directory > Security > Conditional Access (in Azure Portal).

    • Create New Policy:
      • Name: Give it a clear name (e.g., “CA – Require App Protection for Mobile Access”).

      • Assignments > Users and groups: Target the same user groups as your App Protection Policy.

      • Assignments > Cloud apps or actions: Select the specific M365 services you want to protect (e.g., Exchange Online, SharePoint Online, Teams). Start with “Office 365” (which covers multiple services).

      • Assignments > Conditions > Device platforms: Configure this policy to apply only to iOS and Android.

      • Assignments > Conditions > Client apps: Configure this to apply to “Mobile apps and desktop clients” > “Modern authentication clients” > Select “Mobile apps”.

      • Access Controls > Grant:
        • Select “Grant access”.

        • Choose “Require app protection policy”.

        • Optional but Recommended: Also choose “Require approved client app”. This ensures users are using MAM-capable apps (like Outlook Mobile instead of native mail clients).

        • For “Multiple controls”: Select “Require all the selected controls”.
      • Enable policy: Set to “On”.

      • Create: Save the policy.

User Experience with this Approach:

  1. The user installs a managed app (e.g., Outlook) from the public app store.

  2. They sign in with their work (Azure AD) account.

  3. Conditional Access checks if access is allowed. The policy requires an app protection policy.

  4. The user is prompted that their organization protects data in the app. They may be prompted to install the Microsoft Authenticator (on Android) or the Company Portal app (on iOS/Android). Crucially, they do NOT need to fully enroll their device via the Company Portal. The Company Portal app simply needs to be present to receive and report the APP status.

  5. The App Protection Policy settings are applied to the app (e.g., PIN required, copy/paste restrictions).

  6. The user can now securely access work data within that managed app. Their personal apps and data remain untouched and unmanaged.

Alternative/Additional Strategy: Device Compliance (Requires Enrollment – MDM)

If you need stronger device-level controls (e.g., enforcing screen lock complexity on the device itself, checking for device encryption, ensuring minimum OS), you need users to enroll their devices into Intune (MDM). This is more intrusive for BYOD and users might resist.

Steps (If Choosing Enrollment):

  1. Configure Enrollment Restrictions: (MEM Admin Center > Devices > Enroll devices > Enrollment device platform restrictions) Ensure personal iOS/Android devices are allowed to enroll if you intend to support this.

  2. Create Device Compliance Policies: (MEM Admin Center > Devices > Compliance policies)

    • Create separate policies for iOS and Android.

    • Configure settings like: Minimum/Maximum OS Version, Require PIN/Password, Require Encryption, Device Threat Level (if using Defender for Endpoint), Block rooted/jailbroken devices.

    • Assign these policies to user groups.
  3. Modify/Create Conditional Access Policies:
    • Instead of (or in addition to) “Require app protection policy,” add the grant control “Require device to be marked as compliant”.

    • You can combine these: Require a compliant device AND require app protection policy for maximum security on enrolled BYOD devices.

User Experience with Enrollment:

  1. User installs the Company Portal app.

  2. User signs in and follows the prompts to enroll their device. This grants Intune management capabilities over the device.

  3. Intune checks the device against the assigned Compliance Policy.

  4. If compliant, the device is marked as such in Azure AD.

  5. Conditional Access policies check for this compliance status before granting access to corporate resources.

  6. App Protection Policies can still be applied for layered data security within apps, even on enrolled devices.

Summary & Recommendation:

  • For BYOD, start with App Protection Policies (MAM) without enrollment, enforced by Conditional Access requiring App Protection and Approved Client Apps. This provides strong data security within work apps with minimal impact on the user’s personal device.

  • Use Device Compliance Policies (MDM) requiring enrollment only if you have specific, strong requirements for device-level settings and your users consent to this level of management on their personal devices.

  • Always communicate clearly with users about what is being managed and why, especially with BYOD.

  • Test thoroughly with pilot groups before rolling out broadly.

By leveraging App Protection Policies and Conditional Access, Microsoft 365 Business Premium offers a powerful and flexible way to secure corporate data on BYOD smartphones while respecting user privacy.

Starting point for implementing Intune security policies

image

This plan focuses on establishing foundational security controls across your diverse devices, leveraging the integrated features of M365 BP.

Core Concepts:

  • Microsoft Intune: Your cloud-based Mobile Device Management (MDM) and Mobile Application Management (MAM) solution.

  • Azure Active Directory (Azure AD): Your identity provider. User accounts and groups live here. It’s tightly integrated with Intune.

  • Configuration Profiles: These define settings and restrictions pushed to managed devices (MDM).

  • Application Protection Policies (APP / MAM): These protect organizational data within specific apps, useful for both corporate and personally owned (BYOD) devices, without requiring full device enrollment.

  • Compliance Policies: Define rules devices must meet to be considered “compliant” (e.g., have encryption enabled, be updated).

  • Conditional Access (CA): The powerhouse feature (included in M365 BP via Azure AD Premium P1 features) that uses signals (like user, location, device compliance) to enforce organizational policies (like requiring MFA or blocking access from non-compliant devices).

Assumptions:

  • You have Microsoft 365 Business Premium licenses assigned to all 20 users.

  • You have Global Administrator access to your Microsoft 365 tenant.

  • Your users are licensed and exist in Azure AD.

Step-by-Step Implementation Plan:

Phase 1: Preparation & Foundational Setup

  1. Access the Endpoint Manager Admin Center:

  2. Set MDM Authority to Intune:

    • Navigate to Tenant administration > Tenant status.

    • Verify that the Mobile device management authority is set to Microsoft Intune. If it’s something else (like Office 365 MDM or Configuration Manager), you’ll need to change it. This is usually a one-time setting for new tenants. Be careful if you have existing MDM.

  3. Configure Enrollment Settings (Enable Platforms):

    • You need to explicitly allow each device platform to enroll.

    • Windows: Go to Devices > Enroll devices > Windows enrollment > Automatic Enrollment.

      • Set MDM user scope to All (or a specific Pilot Group first).

      • Set MAM user scope to All (or Pilot Group). This enables MAM without full enrollment for BYOD Windows.
      • Recommendation: Also configure DNS CNAME records (enterpriseenrollment and enterpriseregistration) pointing to Microsoft’s services to simplify Windows enrollment. Search Microsoft Docs for “Configure DNS for Intune Windows enrollment”.
    • Apple (iOS/iPadOS & macOS): Go to Devices > Enroll devices > Apple enrollment.

      • You must create an Apple Push Notification service (APNs) certificate. Follow the Apple MDM Push certificate link and instructions carefully. This certificate needs renewal annually. Set reminders!

      • For macOS enrollment methods, initially, users can enroll via the Company Portal app.

      • For iOS/iPadOS enrollment methods, users can enroll via the Company Portal app.

      • (Advanced/Recommended for corporate devices later: Consider Apple Business Manager integration for supervised enrollment).
    • Android: Go to Devices > Enroll devices > Android enrollment.

      • Click Managed Google Play and connect your Intune tenant to your organization’s Managed Google Play account. Follow the instructions. This is required for most Android management scenarios.

      • Decide on enrollment profiles. For a mix of BYOD and potentially corporate devices, enabling Android Enterprise: Personally-owned devices with work profile is the most common starting point for BYOD. This creates a secure container for work apps/data separate from personal data.

  4. Create User Groups:

    • Go to the Azure AD portal (https://aad.portal.azure.com/) or via M365 Admin Center (Groups > Active groups).

    • Create at least one group, e.g., “All Company Employees”. Assign all 20 users to this group. This makes targeting policies much easier. You might create pilot groups later for testing.

Phase 2: Basic Security Policies (Configuration Profiles)

Start with essential security settings for each platform. Target these profiles to your “All Company Employees” group (or a pilot group first).

  • How to Create: In Endpoint Manager (https://endpoint.microsoft.com/), go to Devices > Configuration profiles > Create profile. Select the Platform, then choose a Profile type (use Settings catalog where possible for granularity, or Templates for common scenarios).

  1. Windows Security Policies:

    • Platform: Windows 10 and later
    • Profile Type: Settings catalog
    • Key Settings to Configure (Search within Settings catalog):
      • BitLocker: Require device encryption, configure recovery key storage. (Crucial!)

      • Password: Set minimum length, complexity, history.

      • Windows Defender (Microsoft Defender Antivirus): Ensure real-time monitoring, cloud protection, daily scans are enabled. (M365 BP includes Defender for Business features here).

      • Windows Update for Business: Create Update Rings to manage patch deployment (e.g., install deadlines, deferral periods).

      • Firewall: Ensure Microsoft Defender Firewall is enabled for relevant profiles (Domain, Private, Public).

  2. macOS Security Policies:

    • Platform: macOS
    • Profile Type: Settings catalog (preferred) or Templates (e.g., Device Restrictions)

    • Key Settings:
      • Passcode: Set minimum length, complexity, auto-lock time.

      • Encryption (FileVault): Require FileVault disk encryption, configure recovery key escrow. (Crucial!)

      • Software Update Policy: Configure how updates are handled.

      • Security & Privacy: Enforce Gatekeeper (allow apps from App Store and identified developers), ensure Firewall is enabled.

  3. iOS/iPadOS Security Policies:

    • Platform: iOS/iPadOS
    • Profile Type: Settings catalog (preferred) or Templates (e.g., Device Restrictions)

    • Key Settings:
      • Passcode: Require passcode, set minimum length, complexity (e.g., alphanumeric), maximum grace period for device lock, max failed attempts before wipe (optional but strong).

      • Device Restrictions: Consider disabling simple passcodes, maybe block untrusted TLS certificates, configure AirDrop settings. Start minimally.

  4. Android Enterprise (Work Profile) Security Policies:

    • Platform: Android Enterprise
    • Profile Type: Personally-owned work profile > Device restrictions
    • Key Settings:
      • Work profile settings: Require a separate Work Profile Password (complexity, length).

      • Device password: Require a device screen lock (can be less strict than work profile if desired, but still recommended).

      • Security: Ensure work profile data is encrypted (usually default), block screen capture within the work profile, potentially restrict data sharing between personal/work profiles.

Phase 3: Protect App Data (Application Protection Policies – MAM)

This is vital for BYOD scenarios and adds a layer of security even on enrolled devices.

  • How to Create: In Endpoint Manager, go to Apps > App protection policies > Create policy. Select the platform (iOS/iPadOS, Android, Windows).

  1. Create Policies for iOS/iPadOS and Android:

    • Target these policies to your “All Company Employees” group.

    • Apps: Select All Microsoft apps or target specific core apps initially (Outlook, OneDrive, Teams, Edge, Word, Excel, PowerPoint).

    • Data Protection Settings:
      • Prevent Save As to local/personal storage.

      • Restrict Cut, copy, and paste between policy-managed apps and unmanaged/personal apps (Allow within policy apps).

      • Block opening work data in unmanaged apps.

      • Encrypt work app data.
    • Access Requirements:
      • Require PIN for access (separate from device passcode). Set complexity, length, timeout. Allow Biometrics (Face ID/Touch ID/Fingerprint) as an alternative to PIN.
    • Conditional Launch:
      • Set conditions like minimum OS version, block jailbroken/rooted devices.

  2. (Optional but Recommended) Create Policy for Windows:

    • This protects data on Windows devices without full MDM enrollment (useful if some Windows PCs are personal).

    • Target the policy to the user group.

    • Select target apps (e.g., Edge).

    • Configure similar data protection settings (prevent save-as, restrict copy/paste).

    • Note: Windows MAM has fewer features than mobile MAM.

Phase 4: Enforce Health and Access (Compliance & Conditional Access)

This ties everything together.

  1. Create Device Compliance Policies:

    • How to Create: In Endpoint Manager, go to Devices > Compliance policies > Create policy. Select Platform.

    • Key Settings (Align with Configuration Profiles):
      • Windows: Require BitLocker, Require Secure Boot, Require Antivirus, Require Firewall, Set Min/Max OS Version, Require Password.

      • macOS: Require System Integrity Protection, Require Firewall, Require Password, Require FileVault, Set Min/Max OS Version.

      • iOS/iPadOS: Require Passcode, Require device encryption (implicit with passcode), Min/Max OS Version, Block Jailbroken devices.

      • Android Enterprise (Work Profile): Require Device Lock, Require Encryption, Min/Max OS Version, Block Rooted devices, Require Google Play Protect checks.
    • Actions for Non-Compliance: Start with Mark device noncompliant (immediately). You can add Send email to end user after a few days.

    • Assignment: Assign these policies to your “All Company Employees” group.

  2. Configure Foundational Conditional Access Policies:

    • How to Configure: In Endpoint Manager, go to Devices > Conditional Access > Create new policy. (This actually takes you to the Azure AD CA portal).

    • Policy 1: Require MFA for All Users:
      • Name: CA001: Require MFA for All Users
      • Assignments: Users and groups > Include All users. Exclude 1-2 emergency access/”break-glass” accounts (highly recommended).

      • Cloud apps or actions: Include All cloud apps.

      • Conditions: Define any trusted locations (like your office IP) where MFA might be skipped if necessary (use with caution).

      • Access controls: Grant > Grant access > Check Require multi-factor authentication. Require all the selected controls.

      • Enable policy: On (or Report-only initially to test impact).
    • Policy 2: Require Compliant Devices for Cloud App Access:
      • Name: CA002: Require Compliant Device for Access
      • Assignments: Users and groups > Include All users. Exclude break-glass accounts.

      • Cloud apps or actions: Include All cloud apps.

      • Conditions: Device platforms > Configure > Include All platforms. Client apps > Configure > Include Browser, Mobile apps and desktop clients.

      • Access controls: Grant > Grant access > Check Require device to be marked as compliant. Require all the selected controls.

      • Enable policy: Report-only first, then On.
    • Policy 3: Require Approved App / App Protection Policy for Mobile Access:
      • Name: CA003: Require Protected Apps on Mobile
      • Assignments: Users and groups > Include All users. Exclude break-glass accounts.

      • Cloud apps or actions: Include Office 365 (or specific apps like Exchange Online, SharePoint Online).

      • Conditions: Device platforms > Configure > Include Android, iOS. Client apps > Configure > Include Mobile apps and desktop clients.

      • Access controls: Grant > Check Require approved client app AND Require app protection policy. Select Require one of the selected controls (allows flexibility if one isn’t applicable).

      • Enable policy: Report-only first, then On.

Phase 5: User Enrollment, Communication & Monitoring

  1. Communicate with Users:

    • Explain why these changes are being made (security, data protection).

    • Provide simple instructions on how to enroll their devices (e.g., install Company Portal app from the app store and sign in).

    • Explain what they should expect (e.g., prompts for PINs, work profile creation on Android).

    • Offer support for the transition.

  2. Guide Users Through Enrollment:

    • Have users install the “Intune Company Portal” app on their iOS, Android, and macOS devices and sign in with their M365 credentials. Follow the prompts.

    • For Windows devices that are not already Azure AD Joined: Guide users through Settings > Accounts > Access work or school > Connect, entering their M365 email and following prompts to join Azure AD and enroll in Intune (if Automatic Enrollment is configured).

  3. Monitor Enrollment and Compliance:

    • In Endpoint Manager, check Devices > Overview for enrollment status and compliance overview.

    • Check specific device compliance under Devices > Compliance policies.

    • Review Conditional Access sign-in logs in Azure AD (Monitoring > Sign-in logs) to see policy impacts.

Important Considerations:

  • Start Simple & Iterate: Don’t try to implement everything at once. Start with foundational policies and build complexity as needed.

  • Test Thoroughly: Use pilot groups before rolling out to everyone. Use “Report-only” mode for Conditional Access policies initially.

  • BYOD vs. Corporate: Be clear about expectations for personal devices (Work Profile on Android, MAM policies) vs. company-owned devices (potentially fully managed).

  • User Experience: Balance security with usability. Overly restrictive policies can hinder productivity.

  • Documentation: Keep track of the policies you create and why.

  • Annual APNs Renewal: Don’t forget this! If it expires, you can’t manage Apple devices.

This step-by-step guide provides a solid starting point leveraging the security features within Microsoft 365 Business Premium. Remember to consult Microsoft’s official documentation for detailed configuration options as you proceed.

The Evolving Landscape of IT Security: Is a Multi-Vendor Approach Still the Gold Standard for Risk Reduction?

Screenshot 2025-05-01 145421

The long-held adage that relying on multiple vendors for IT security services is the best way to reduce risk is facing increasing scrutiny in today’s complex threat landscape. While the principle of not putting all your eggs in one basket still holds some weight, the practicalities and potential drawbacks of managing a diverse array of security solutions have led many organizations to reconsider this traditional approach.

Historically, the multi-vendor strategy offered distinct advantages. It allowed organizations to select “best-of-breed” solutions for specific security needs, leveraging specialized expertise from different providers. This could lead to a more robust defense in individual areas like firewalls, endpoint protection, or threat intelligence. Additionally, a multi-vendor approach could provide geographic coverage and adaptability, allowing businesses to tailor security solutions to different locations and evolving requirements.1 It was also seen as a way to avoid vendor lock-in and maintain negotiation leverage.2

However, the modern cybersecurity environment presents significant challenges that can undermine the effectiveness of a fragmented security infrastructure. Managing multiple vendor relationships, contracts, and disparate technologies can lead to considerable operational overhead, increased complexity, and potential security gaps due to a lack of seamless integration between solutions.3 This “tool sprawl” can strain limited IT resources, make it difficult to achieve comprehensive visibility across the network, and slow down threat detection and response efforts.4 Furthermore, inconsistencies in security policies and the accumulation of technical debt can increase overall risk rather than reduce it.

In response to these challenges, a strong trend towards cybersecurity vendor consolidation has emerged. Organizations are increasingly looking to streamline their security stacks by partnering with fewer vendors who can offer integrated platforms or a broader portfolio of security services.5 This approach aims to simplify management, reduce costs, improve interoperability, and enhance overall security posture through better correlation of threat intelligence and centralized control.6 Gartner, for instance, has highlighted vendor consolidation as a key trend, with a significant percentage of organizations actively pursuing it to improve security and operational efficiency.7

Alternative strategies gaining traction include leveraging managed security service providers (MSSPs) who can deliver integrated, multi-vendor solutions as a single service. This allows organizations to benefit from best-of-breed technologies without the burden of managing each vendor individually. The focus is shifting from simply having multiple vendors to having a cohesive and well-managed security ecosystem, regardless of the number of underlying providers.

While the idea of diversifying to avoid a single point of failure remains theoretically sound, the practical difficulties of managing a complex multi-vendor environment can introduce new forms of risk, such as misconfiguration, alert fatigue, and delayed incident response.8

Therefore, the adage that you need to have your IT security services provided by multiple vendors to reduce risk is no longer universally valid. While a carefully selected and integrated multi-vendor strategy can still be effective for some organizations, particularly those with very specific and advanced security needs, the prevailing trend and expert opinion lean towards consolidation and integrated platforms for improved manageability, visibility, and overall risk reduction in the face of increasingly sophisticated threats and operational complexities. The focus has shifted from the sheer number of vendors to the effectiveness of the integrated security program.

Minimum Viable Configuration for Microsoft Sentinel

mvc-sent

What is the the Minimum Viable Configuration (MVC) for Microsoft Sentinel aimed at protecting a small business (SMB), the setup steps, and the estimated costs.

Understanding the Goal of an MVC for Sentinel in an SMB Context

The goal isn’t to catch every sophisticated nation-state attack, but to provide fundamental visibility and detection for common threats targeting SMBs, such as:

  1. Compromised Credentials: Detecting suspicious sign-ins, impossible travel, etc.

  2. Malware/Ransomware: Leveraging endpoint protection alerts.

  3. Phishing & Email Threats: Monitoring Office 365 activity.

  4. Basic Cloud Misconfigurations/Anomalies: Using built-in cloud security alerts.

The MVC focuses on leveraging the security signals already generated by the Microsoft ecosystem (assuming the SMB uses Microsoft 365 and Azure AD).

Minimum Viable Configuration (MVC) Components

  1. Azure Subscription: The foundation for all Azure services.

  2. Log Analytics Workspace: The data repository where Sentinel stores and analyzes logs. Configured for Pay-As-You-Go pricing initially.

  3. Microsoft Sentinel Instance: Enabled on top of the Log Analytics Workspace.

  4. Core Data Connectors (Focus on Free/Included Tiers First):
    • Azure Active Directory (Entra ID):
      • Sign-in Logs (Requires Azure AD P1 or P2 license) – Crucial for credential compromise detection.
      • Audit Logs (Free) – Tracks admin activity.

      • Azure AD Identity Protection Alerts (Requires Azure AD P2 license) – High-fidelity alerts for risky users/sign-ins. If P2 isn’t available, rely more heavily on Sign-in log analytics.
    • Microsoft 365 Defender (Recommended if licensed): This single connector can ingest alerts from:

      • Microsoft Defender for Endpoint (if using MDE Plan 1/2 or Defender for Business)

      • Microsoft Defender for Office 365 (if using Plan 1/2)

      • Microsoft Defender for Identity (less common in pure SMB cloud setups)

      • Microsoft Defender for Cloud Apps

      • Benefit: Ingesting Alerts via this connector is often free.
    • Office 365 (Alternative/Supplement to M365 Defender):
      • Exchange Online & SharePoint Online audit logs (Standard Audit is generally free to ingest). Essential for tracking file access, mail rule changes, etc.
    • Azure Activity Log (Free): Tracks subscription-level events (creating VMs, changing settings). Important for basic Azure infrastructure security hygiene.
  5. Essential Analytics Rules (Start with Templates):
    • Enable built-in Microsoft Security templates related to the connected data sources. Focus on:

      • Suspicious Azure AD Sign-in activity (Impossible travel, unfamiliar locations, logins from known malicious IPs).

      • Anomalous Office 365 activity (e.g., mass file downloads/deletions, suspicious inbox rule creation).

      • Alerts forwarded from Microsoft Defender products (e.g., Malware detected, phishing email reported).

      • Basic Azure activity anomalies (e.g., unusual resource creation/deletion).
  6. Incident Management: Rely on the built-in Sentinel Incident queue for manual review and investigation.

What’s NOT in this MVC (to keep it minimal):

  • Third-Party Data: No logs from non-Microsoft firewalls, servers, or applications initially.

  • Advanced Analytics: No custom rules, machine learning models (beyond built-in ones), or complex threat intelligence feeds initially.

  • SOAR/Automation: No automated response playbooks initially. Response is manual review and action.

  • Extensive Workbooks/Dashboards: Rely on default views.

  • Long Data Retention: Stick to the default or included retention (often 90 days free with Sentinel).

Setup Steps

  • Prerequisites:

    • An Azure Subscription.

    • Appropriate Permissions: Contributor or Owner on the Azure subscription/resource group; Global Administrator or Security Administrator role in Azure AD/Microsoft 365 to authorize connectors.

    • Relevant Licenses: Microsoft 365 Business Premium (includes Defender for Business, Azure AD P1), M365 E3/E5, or standalone licenses (Azure AD P1/P2, Defender plans) are highly recommended for the data sources.

  • Step 1: Create a Log Analytics Workspace

    1. Log in to the Azure portal (portal.azure.com).

    2. Search for “Log Analytics workspaces” and click “Create”.

    3. Choose your Subscription and Resource Group (create a new one if needed, e.g., RG-Security).

    4. Provide a Name (e.g., LAW-CompanyName-Security).

    5. Select a Region (choose one geographically close or with specific compliance needs).

    6. Select the Pricing Tier: Start with Pay-as-you-go.

    7. Review and Create.

  • Step 2: Enable Microsoft Sentinel

    1. Search for “Microsoft Sentinel” in the Azure portal and select it.

    2. Click “Add” or “Create”.

    3. Select the Log Analytics Workspace you just created.

    4. Click “Add Microsoft Sentinel”. Deployment takes a few minutes.

  • Step 3: Configure Data Connectors

    1. Once Sentinel is deployed, navigate to your Sentinel workspace.

    2. Go to Configuration -> Data connectors.

    3. Find and configure the following connectors (prioritize based on your licenses):

      • Azure Active Directory: Connect Sign-in logs and Audit logs. Requires authorization. If you have Azure AD P2, also connect Azure AD Identity Protection.

      • Microsoft 365 Defender: If you have relevant Defender licenses, connect this. It streamlines alert ingestion. Requires authorization. Configure it to sync alerts. This is often the most cost-effective way to get Defender alerts.
      • Office 365: If not using the M365 Defender connector for O365 data, or if you want raw logs beyond alerts, connect this. Select Exchange and SharePoint. Requires authorization.

      • Azure Activity: Connect this. It’s straightforward and free.
    4. For each connector, open its page, click “Open connector page”, and follow the specific prerequisites and configuration steps (usually involves ticking boxes and granting permissions).

  • Step 4: Enable Analytics Rules

    1. In Sentinel, go to Configuration -> Analytics.

    2. Go to the Rule templates tab.

    3. Filter by Data Sources (e.g., Azure Active Directory, Office 365, Microsoft 365 Defender).

    4. Look for rules tagged Microsoft Security. These are often high-quality and maintained by Microsoft.

    5. Select relevant templates (e.g., “Sign-ins from IPs that attempt sign-ins to disabled accounts”, “Malware detection by Microsoft Defender Antivirus”, “Suspicious inbox manipulation rule”, “Impossible travel activity”).

    6. For each chosen template, click “Create rule”.

    7. Review the rule logic (you can accept defaults for MVC). Ensure it’s set to Enabled.

    8. Configure Automated response later; leave it empty for MVC.

    9. Create the rule. Start with 5-15 key rules covering identity, endpoint, and email threats.

  • Step 5: Monitor Incidents

    1. Regularly (daily is recommended) check the Threat management -> Incidents blade in Sentinel.

    2. Review new incidents, assign them, investigate the alerts and entities involved, and close them with appropriate classifications.

Expected Monthly Costs

This is highly variable, but let’s break it down:

  1. Log Analytics Ingestion:

    • Free Tier: Many security alerts ingested via the Microsoft 365 Defender connector and Azure Activity logs are free. Office 365 standard audit logs are also often free.

    • Paid Data: The primary cost driver will be paid data sources ingested. Azure AD Sign-in logs are a common paid source. The volume depends heavily on user count and activity.

    • Estimate: For a small business (e.g., 10-50 active users), ingesting only essential paid logs like Azure AD Sign-ins might result in 0.5 GB to 5 GB per month (this is a rough estimate). Some sources estimate ~1GB/month per 100 users for just sign-in logs, but activity varies hugely.

    • Cost: Log Analytics Pay-As-You-Go ingestion is roughly $2.76 per GB (price varies slightly by region, check current Azure pricing).

  2. Sentinel Analysis Cost (Pay-As-You-Go):

    • Sentinel charges for analyzing the data ingested into Log Analytics. The PAYG rate is often similar to the Log Analytics ingestion rate, around $2.46 per GB (check current pricing).

    • Important: Data sources that are free to ingest into Log Analytics (like M365 Defender alerts, Azure Activity) are typically also free to analyze in Sentinel. You only pay Sentinel analysis costs on the paid data ingested into Log Analytics.

  3. Log Analytics Retention:

    • The first 90 days of data retention are typically included free with Sentinel enabled.

    • Storing data beyond 90 days incurs a small storage cost (e.g., ~$0.12 per GB per month). For an MVC, sticking to 90 days is recommended.

Cost Summary Estimate for MVC:

  • Scenario 1: Strict MVC using mostly FREE alert sources: If you rely heavily on the free ingestion from the M365 Defender connector (for endpoint/email alerts), Azure Activity, and standard Office 365 audit logs, and don’t ingest Azure AD Sign-in logs (or have very low volume), your direct Sentinel/Log Analytics costs could be very low, potentially $0 – $20 per month.

  • Scenario 2: MVC including Azure AD Sign-in Logs: If you add Azure AD Sign-in logs (highly recommended for security), assuming 1-5 GB/month ingestion:

    • Log Analytics Ingestion: 1-5 GB * ~$2.76/GB = $2.76 – $13.80

    • Sentinel Analysis: 1-5 GB * ~$2.46/GB = $2.46 – $12.30

    • Total Estimated Direct Cost: Roughly $5 – $30 per month.

Crucial Caveats on Cost:

  • Licensing Costs: This estimate does not include the cost of Microsoft 365 licenses (e.g., Business Premium, E3, E5) or standalone Azure AD P1/P2 licenses required to generate the security signals in the first place. These are often the larger part of the overall security spend.

  • Data Volume Variance: Actual data volume can vary significantly based on user activity, configured logging levels, and enabled features.

  • Pricing Changes: Azure pricing can change. Always refer to the official Azure pricing calculator for the most current information.

  • Commitment Tiers: If data volume grows significantly (e.g., consistently over 100 GB/day, which is unlikely for this SMB MVC), Commitment Tiers for Sentinel and Log Analytics offer discounts but require upfront commitment.

In conclusion, a minimum viable Sentinel setup focusing on free alert ingestion and essential paid logs like Azure AD Sign-ins can be quite affordable for an SMB, likely falling in the $5 – $30 per month range for direct Azure consumption costs, plus the necessary Microsoft 365/Azure AD licensing costs. Remember that someone needs the time and basic knowledge to monitor the incidents generated.

Best ways to monitor and audit permissions across a SharePoint environment in Microsoft 365

image

What are the best ways to monitor and audit permissions across a SharePoint environment in Microsoft 365. There isn’t one single “magic button,” but rather a combination of tools and practices that form the most effective approach.

The “best” way depends on your specific needs (scale, complexity, budget, compliance requirements), but generally involves a multi-layered strategy:

1. Leveraging Built-in Microsoft 365 Tools:

  • Microsoft Purview Compliance Portal (Audit Log):

    • What it does: Records actions related to permissions and sharing. This includes granting access, changing permissions, creating sharing links, accepting/revoking sharing invitations, adding/removing users from groups, etc.

    • Pros: Centralized logging across M365 services (not just SharePoint). Captures who did what, when. Essential for forensic auditing and tracking changes over time. Can set up alerts for specific activities.

    • Cons: Reports events, not the current state of permissions easily. Can generate a large volume of data, requiring effective filtering and analysis. Default retention might be limited (90 days for E3, 1 year for E5/add-ons, up to 10 years with specific licenses). Doesn’t give you a simple snapshot of “who has access to Site X right now“.

    • Best for: Auditing changes to permissions, investigating specific incidents, monitoring for policy violations (e.g., excessive external sharing).

  • SharePoint Site Permissions & Advanced Permissions:

    • What it does: The standard SharePoint interface (Site Settings > Site Permissions and Advanced permission settings) allows site owners and administrators to view current permissions on a specific site, list, or library. The “Check Permissions” feature is useful for specific users/groups.

    • Pros: Direct view of current permissions for a specific location. No extra tools needed. Good for spot checks by site owners or admins.

    • Cons: Entirely manual, site-by-site. Not feasible for auditing across the entire tenant. Doesn’t scale. Doesn’t show how permissions were granted (direct vs. group) easily in aggregate. Doesn’t provide historical data.

  • Site Usage Reports (Sharing Links):

    • What it does: Found under Site Settings > Site Usage, this includes reports on externally shared files and sharing links (Anyone, Specific People).

    • Pros: Quick overview of sharing activity for a specific site, particularly external sharing links.

    • Cons: Limited scope (focuses on sharing links, not inherited or direct permissions). Site-by-site basis.

  • PowerShell (SharePoint Online Management Shell / PnP PowerShell):

    • What it does: Allows administrators to scriptmatically query and report on permissions across multiple sites, lists, libraries, and even items (though item-level reporting can be slow). PnP PowerShell is often preferred for its richer feature set.

    • Pros: Highly flexible and powerful. Can automate the generation of comprehensive current state permission reports across the tenant. Can export data to CSV for analysis. Can identify broken inheritance, unique permissions, group memberships, etc. Free (part of M365).

    • Cons: Requires scripting knowledge. Can be slow to run across very large environments, especially if checking item-level permissions. Scripts need to be developed and maintained. Requires appropriate administrative privileges.

    • Best for: Periodic, deep audits of the current permission state across the environment. Generating custom reports. Automating permission inventory.

  • Azure AD Access Reviews (Requires Azure AD Premium P2):

    • What it does: Automates the review process where group owners or designated reviewers must attest to whether users still need access via Microsoft 365 Groups or Security Groups that grant access to SharePoint sites (often via the Owners, Members, Visitors groups).

    • Pros: Proactive governance. Engages business users/owners in the review process. Reduces permission creep over time. Creates an audit trail of reviews.

    • Cons: Requires Azure AD P2 license. Primarily focuses on group memberships, not direct permissions or SharePoint groups (though M365 groups are the modern standard). Requires setup and configuration.

    • Best for: Implementing regular, automated reviews of group-based access to ensure continued need.

2. Third-Party Tools:

  • What they do: Numerous vendors offer specialized SharePoint/Microsoft 365 administration, governance, and auditing tools (e.g., ShareGate, AvePoint, Quest, SysKit, CoreView, etc.).

  • Pros: Often provide user-friendly dashboards and pre-built reports for permissions auditing. Can simplify complex reporting tasks compared to PowerShell. May offer advanced features like alerting, automated remediation workflows, comparison reporting (permissions changes over time), and broader M365 governance capabilities. Can often combine state reporting and change auditing.

  • Cons: Cost (licensing fees). Can have their own learning curve. Reliance on a vendor for updates and support. Need to grant the tool potentially high privileges.

  • Best for: Organizations needing comprehensive, user-friendly reporting and management without extensive PowerShell expertise, or those requiring advanced features and workflows not available natively. Often essential for large, complex environments or those with stringent compliance needs.

Recommended Strategy (The “Best Way”):

For most organizations, the most effective approach is a combination:

  1. Configure & Monitor the Purview Audit Log: Ensure auditing is enabled and understand how to search/filter logs. Set up alerts for critical permission changes or sharing events (e.g., creation of “Anyone” links if disallowed, granting owner permissions). This covers ongoing change monitoring.

  2. Perform Regular Audits using PowerShell or a Third-Party Tool: Schedule periodic (e.g., quarterly, semi-annually) comprehensive audits to capture the current state of permissions across all relevant sites. Focus on:

    • Sites with broken inheritance.

    • Direct user permissions (should be minimized).

    • Membership of Owners groups.

    • External sharing status.

    • Usage of SharePoint Groups vs M365/Security Groups.
  3. Implement Azure AD Access Reviews (if licensed): Use this for regular recertification of access granted via M365 and Security groups, especially for sensitive sites.

  4. Establish Clear Governance Policies: Define who can share, what can be shared externally, how permissions should be managed (use groups!), and the responsibilities of Site Owners.

  5. Train Site Owners: Ensure they understand the principle of least privilege and how to manage permissions correctly within their sites using M365 groups primarily.

  6. Use Built-in UI for Spot Checks: Empower admins and site owners to use the standard SharePoint UI for quick checks on individual sites as needed.

By combining proactive monitoring (Purview), periodic deep audits (PowerShell/Third-Party), automated reviews (Access Reviews), and clear governance, you create a robust system for managing and auditing SharePoint permissions effectively.