diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md new file mode 100644 index 0000000..b69bfb1 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md @@ -0,0 +1,31 @@ +# Compliance + +## Description + +This policy enforces that enterprise-class users must authenticate using a device that meets compliance standards defined in Intune. + +## Why It's Important + +Requiring compliant devices ensures that only endpoints with approved configurations, security controls, and health status can access corporate resources. This policy helps prevent access from unmanaged or misconfigured devices, reducing the risk of data leakage, malware propagation, and unauthorized access. It supports a zero-trust model by validating device posture before granting access. + +## Recommendations + +- **Communicate** the requirement for compliant devices and provide remediation guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** device compliance enforcement and validate Intune reporting. +- **Maintain** a rollback plan for operational resilience. +- **Enforce** the policy broadly after successful validation. + + +## License Requirements + +- Microsoft Entra ID P1 +- Microsoft Intune + +## Learn More + +- [Require device compliance with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md new file mode 100644 index 0000000..a4170d1 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md @@ -0,0 +1,30 @@ +# Location + +## Description + +This policy blocks enterprise identity authentication attempts from specific geographic regions identified as high-risk, based on IP geolocation. + +## Why It's Important + +Certain countries pose elevated cybersecurity threats due to geopolitical instability, regulatory concerns, or known malicious activity. This policy uses a named location filter to prevent sign-ins from these regions, helping to enforce geo-fencing and reduce exposure to unauthorized access attempts. It supports a zero-trust strategy by ensuring authentication only occurs from trusted geographic zones. + +## Recommendations + +- **Communicate** the geo-fencing policy and list of blocked regions. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** location-based access behavior and validate named location filters. +- **Maintain** a rollback plan for access continuity. +- **Enforce** the policy broadly after successful validation. + + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Block access by location](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-by-location){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md new file mode 100644 index 0000000..6a5388d --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md @@ -0,0 +1,30 @@ +# Microsoft Defender for Cloud Applications (MDCA) + +## Description + +This policy integrates Microsoft Defender for Cloud Apps (MDCA) with enterprise identity access to enable real-time monitoring and control over user sessions. + +## Why It's Important + +MDCA provides visibility into user activity and enforces session-level controls across cloud applications. By enabling this integration, the policy allows for conditional access enforcement based on risk signals, user behavior, and compliance status. It helps detect anomalies, prevent data exfiltration, and apply granular access restrictions, strengthening enterprise security posture without disrupting productivity. + +## Recommendations + +- **Communicate** the integration of MDCA and its impact on session monitoring. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** session control behavior and validate MDCA enforcement. +- **Maintain** a rollback plan for operational flexibility. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 +- Microsoft Defender for Cloud Apps + +## Learn More + +- [Conditional Access app control in Microsoft Defender for Cloud Apps](https://learn.microsoft.com/en-us/defender-cloud-apps/proxy-intro-aad){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md new file mode 100644 index 0000000..a0c6439 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md @@ -0,0 +1,29 @@ +# Multi-Factor Authentication (MFA) + +## Description + +This policy enforces multi-factor authentication (MFA) for enterprise identities during sign-in to reduce the risk of identity compromise. + +## Why It's Important + +Passwords alone are insufficient to protect privileged access. This policy ensures that users in key enterprise groups must verify their identity using a second factor, such as a mobile app or hardware token, before accessing any cloud application. By excluding break-glass accounts, it maintains emergency access while enforcing strong authentication for all other users, supporting a zero-trust security model + +## Recommendations + +- **Communicate** the MFA requirement and provide setup guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** MFA enforcement and user experience across platforms. +- **Maintain** a rollback plan for access continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Require multifactor authentication for all users](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md new file mode 100644 index 0000000..8ada825 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md @@ -0,0 +1,29 @@ +# Authentication Methods + +## Description + +This policy enforces a specific set of acceptable authentication methods for Entra ID sign-in, based on authentication strength. Only users in the included groups can authenticate, and only if they use approved authentication methods. + +## Why It's Important + +This policy enforces strong authentication methods for Entra ID sign-ins, ensuring SHIELD limits privileged access to approved, phishing-resistant factors only. + +## Recommendations + +- **Communicate** the enforcement of strong authentication methods and provide setup guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** authentication strength enforcement and validate exclusions. +- **Maintain** a rollback plan for access continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access authentication strengths](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md new file mode 100644 index 0000000..3f1e2ed --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md @@ -0,0 +1,29 @@ +# Block Non-Privileged + +## Description + +This policy prevents non-privileged users from signing in to privileged devices—specifically those designated for sensitive operations. It ensures that only authorized, privileged identities can access high-trust endpoints, reducing the risk of lateral movement, data exposure, or misuse of privileged infrastructure. + +## Why It's Important + +This policy restricts privileged devices to privileged identities only, ensuring SHIELD prevents unauthorized users from accessing sensitive endpoints and reducing the risk of lateral movement. + +## Recommendations + +- **Communicate** the restriction of privileged devices to privileged users only. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** access behavior across user types and validate exclusions. +- **Maintain** a rollback plan for operational flexibility. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"} + +
+ +--- \ No newline at end of file diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md new file mode 100644 index 0000000..32ce73a --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md @@ -0,0 +1,30 @@ +# Compliance + +## Description + +This policy enforces that privileged devices must be compliant with their Intune compliance policies before they can access any cloud applications. + +## Why It's Important + +This policy ensures privileged devices meet Intune compliance requirements before accessing cloud apps, allowing SHIELD to block noncompliant or insecure endpoints from sensitive resources. + +## Recommendations + +- **Communicate** the requirement for compliant devices and provide remediation guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** device compliance enforcement and validate Intune reporting. +- **Maintain** a rollback plan for operational resilience. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 +- Microsoft Intune + +## Learn More + +- [Require device compliance with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md new file mode 100644 index 0000000..d05a91c --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md @@ -0,0 +1,29 @@ +# Disable Conditional Access Resilience Downgrade + +## Description + +This policy prevents Microsoft Entra Conditional Access resilience features from automatically downgrading security requirements during service outages or disruptions. It ensures that privileged identities remain protected even when Microsoft services experience availability issues. Instead of relaxing controls, organizations are expected to use break-glass accounts for emergency access. + +## Why It's Important + +This policy ensures Conditional Access requirements are never weakened during outages, allowing SHIELD to maintain strong protection for privileged identities and rely on break-glass accounts for continuity. + +## Recommendations + +- **Communicate** the removal of resilience fallback and reinforce break-glass access procedures. +- **Stage** the rollout with a pilot group and validate emergency access. +- **Test** behavior during service disruptions and confirm policy enforcement. +- **Maintain** a rollback plan for operational continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access: Resilience defaults](https://learn.microsoft.com/en-us/entra/identity/conditional-access/resilience-defaults){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md new file mode 100644 index 0000000..b6a5447 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md @@ -0,0 +1,29 @@ +# Hardware Enforcement + +## Description + +This policy ensures that only approved and commissioned hardware is allowed to authenticate to Entra ID. It blocks access from any device that does not meet specific manufacturer, model, and custom attribute criteria—enforcing strict control over the physical devices used by privileged identities. + +## Why It's Important + +This policy enforces that only approved hardware can access privileged accounts, allowing SHIELD to block untrusted or rogue devices and maintain strict control over sensitive operations. + +## Recommendations + +- **Communicate** the restriction to approved hardware and provide verification guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** hardware enforcement and validate device attribute filtering. +- **Maintain** a rollback plan for operational flexibility. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md new file mode 100644 index 0000000..bd900cb --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md @@ -0,0 +1,29 @@ +# Join Type + +## Description + +This policy ensures that only devices joined directly to Microsoft Entra ID (formerly Azure AD) are allowed to authenticate privileged identities. It blocks access from hybrid-joined or Bring Your Own Device (BYOD) endpoints, helping prevent unauthorized or unmanaged devices from injecting into privileged workflows. + +## Why It's Important + +This policy restricts privileged access to Entra ID-joined devices only, ensuring SHIELD blocks unmanaged or hybrid endpoints from being used to compromise sensitive workflows. + +## Recommendations + +- **Communicate** the restriction to Entra ID-joined devices and provide transition guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** device join type enforcement and validate exclusions. +- **Maintain** a rollback plan for operational flexibility. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md new file mode 100644 index 0000000..f0ee218 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md @@ -0,0 +1,29 @@ +# Legacy Authentication + +## Description + +This policy blocks the use of legacy authentication protocols—such as Exchange ActiveSync and other non-modern clients—for privileged identities. + +## Why It's Important + +This policy blocks legacy authentication for privileged identities, helping SHIELD prevent attackers from exploiting outdated protocols that bypass modern security controls like MFA. + +## Recommendations + +- **Communicate** the deprecation of legacy authentication and provide transition guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** for legacy protocol usage and validate enforcement. +- **Maintain** a rollback plan for operational continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Block legacy authentication with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md new file mode 100644 index 0000000..f907897 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md @@ -0,0 +1,29 @@ +# Location + +## Description + +This policy blocks privileged identity authentication attempts from a set of problematic world regions, as defined by a named location based on IP geolocation. It helps prevent access from countries associated with elevated cybersecurity risks, geopolitical concerns, or regulatory restrictions. + +## Why It's Important + +This policy blocks privileged access attempts from high-risk or restricted regions, helping SHIELD reduce exposure to malicious activity and comply with geographic access requirements. + +## Recommendations + +- **Communicate** the geo-fencing policy and list of blocked regions. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** location-based access behavior and validate named location filters. +- **Maintain** a rollback plan for access continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Block access by location](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-by-location){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md new file mode 100644 index 0000000..dd2b2fb --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md @@ -0,0 +1,29 @@ +# Multi-Factor Authentication (MFA) + +## Description + +This policy enforces Multi-Factor Authentication (MFA) for privileged users during sign-in to Entra ID. It significantly reduces the risk of identity compromise by requiring a second factor of authentication beyond just a password. + +## Why It's Important + +This policy enforces MFA for privileged users, helping SHIELD prevent account compromise by requiring an additional factor beyond passwords. + +## Recommendations + +- **Communicate** the MFA requirement and provide setup guidance. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** MFA enforcement and user experience across platforms. +- **Maintain** a rollback plan for access continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Require multifactor authentication for all users](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md new file mode 100644 index 0000000..29dc392 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md @@ -0,0 +1,29 @@ +# Operating System Enforcement + +## Description + +This policy ensures that only devices running Windows are allowed to authenticate to Entra ID. It blocks access from all other operating systems, helping enforce a standardized and secure platform for privileged access. + +## Why It's Important + +This policy restricts privileged access to Windows devices only, enabling SHIELD to enforce a standardized platform and reduce risks from unmanaged or unsupported operating systems. + +## Recommendations + +- **Communicate** the change and explain the Windows-only access requirement. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** platform access behavior and validate exclusions. +- **Maintain** a rollback plan for operational continuity. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P1 + +## Learn More + +- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices#common-scenarios){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md new file mode 100644 index 0000000..231ffee --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md @@ -0,0 +1,29 @@ +# Session Persistence + +## Description + +This policy disables persistent browser sessions for privileged users, ensuring that identity revalidation occurs as frequently as possible. It helps reduce the risk of unauthorized access due to session hijacking or stale authentication tokens. + +## Why It's Important + +This policy requires privileged users to reauthenticate frequently, helping SHIELD reduce the risk of session hijacking and misuse of stale tokens. + +## Recommendations + +- **Communicate** the change to users, highlighting the impact on session behavior. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** authentication frequency and user experience. +- **Maintain** a rollback plan to address potential disruptions. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P2 + +## Learn More + +- [Configure adaptive session lifetime policies](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md new file mode 100644 index 0000000..d1f0f84 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md @@ -0,0 +1,29 @@ +# Sign-in Risk + +## Description + +This policy blocks access to Entra ID for users whose sign-in attempts are flagged with any level of risk—low, medium, or high. It’s designed to prevent access from potentially compromised or suspicious sign-in sessions, especially for privileged users. + +## Why It's Important + +This policy blocks risky sign-ins for privileged users, allowing SHIELD to prevent access from potentially compromised sessions and reduce the chance of account takeover. + +## Recommendations + +- **Communicate** the policy change and its impact on risky sign-ins. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** sign-in behavior and risk detection accuracy. +- **Maintain** a rollback plan for quick recovery if needed. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P2 and a standalone license for Microsoft Defender for Cloud Apps + +## Learn More + +- [Require multifactor authentication for elevated sign-in risk](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-risk-based-sign-in){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md new file mode 100644 index 0000000..25b2039 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md @@ -0,0 +1,29 @@ +# Token Binding + +## Description + +This policy is designed to prevent token theft from Microsoft Exchange Online (EXO) and SharePoint Online (SPO) clients by enforcing secure session controls for privileged users. + +## Why It's Important + +This policy protects against token theft by binding access tokens to secure sessions, ensuring attackers cannot reuse stolen tokens to bypass SHIELD identity and access controls. + +## Recommendations + +- **Communicate** the policy change and its impact to affected users. +- **Stage** the rollout by piloting with a small, controlled group. +- **Test** functionality and user experience across supported platforms. +- **Maintain** a rollback plan to quickly respond to any issues. +- **Enforce** the policy broadly once validated and stable. + +## License Requirements + +- P2 License + +## Learn More + +- [Token Protection in Microsoft Entra Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md new file mode 100644 index 0000000..e4bf22d --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md @@ -0,0 +1,29 @@ +# User Risk + +## Description + +This policy blocks access to Entra ID for users who are flagged with any level of user risk—low, medium, or high—as determined by Microsoft Entra ID’s risk detection engine. It’s designed to protect privileged access by preventing authentication from accounts that may be compromised. + +## Why It's Important + +This policy blocks privileged access for accounts flagged with user risk, helping SHIELD prevent compromised identities from authenticating and protecting sensitive operations. + +## Recommendations + +- **Communicate** the policy change and how user risk affects access. +- **Stage** the rollout with a pilot group and exclude critical accounts. +- **Test** risk detection accuracy and user impact. +- **Maintain** a rollback plan for rapid response to issues. +- **Enforce** the policy broadly after successful validation. + +## License Requirements + +- Microsoft Entra ID P2 and a standalone license for Microsoft Defender for Cloud Apps + +## Learn More + +- [User risk detections](https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#user-risk-detections){:target="_blank"} + +
+ +--- diff --git a/docs/SHIELD/Discover/Installation.md b/docs/SHIELD/Discover/Installation.md new file mode 100644 index 0000000..fb2b60a --- /dev/null +++ b/docs/SHIELD/Discover/Installation.md @@ -0,0 +1,110 @@ +# Overview and Installation Requirements + +!!! info "Security Considerations" + While this application requires sensitive permissions to conduct the automated scan, by self-hosting the application, SHI does not represent a supply chain risk or path to compromise a customer environment via the SHIELD platform, as there is no control maintained beyond the initial point of installation. All code being run to conduct the automated discovery is available for code & security reviews prior to engagement upon request. Permissions exist for both the user initiating the report & the application itself. Code review is available upon request. + +## Overview + +This application is a self-hosted application that exists in the customer tenant on an Azure App Service, collecting and processing the requisite data only within the customer tenant before provided abstracted & fully anonymized data results back to SHI for reporting. All requirements can be set up by the delivery team or customer prior to engagement. + +--- + +## Requirements + +- New Azure Subscription +(SHIELD Installer will handle below, not required by customer if using Installer) +- Powershell: + - Latest [v7](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell){:target="_blank"} installed (ideally from the [Microsoft Store](https://www.microsoft.com/store/productId/9MZ1SNWT0N5D?ocid=pdpshare){:target="_blank"}) + - Modules: [Az](https://www.powershellgallery.com/packages/Az){:target="_blank"}, [Microsoft.Graph.Beta](https://www.powershellgallery.com/packages/Microsoft.Graph.Beta){:target="_blank"} + - Scripts: [Grant-MIGraphPermission](https://www.powershellgallery.com/packages/Grant-MIGraphPermission){:target="_blank"} +- Blank Azure App Service (Web App) + - OS: Linux + - Minimum SKU: P0v4 + - Runtime Stack: Node 24 LTS + - Resource Group Name: SHIELD + - Azure Cost Estimate associated (as of 1/8/2025): + +![Azure Cost Estimation Table](assets/images/screenshots/Pricing_Table.png) + +- Permissions + - The User logging in to SHIELD: Discover requires either Global Admin or the following: + - Global Reader + - Security Administrator + - User Administrator + - **The service principal (System Assigned Managed identity is recommended) must be granted**: + - `Owner` for the Azure Subscription assigned to app + - `AppRoleAssignment.ReadWrite.All` + - `Application.ReadWrite.All` + - Additional permissions will be self-assigned by the app to save time and begin data collection, the extent of which can be found [here](https://docs.shilab.com/SHIELD/Prerequisites/Required-Graph-API-Permissions/){:target="_blank"}. +- **Network Inspection excluded for Microsoft Traffic** + - According to [Microsoft Documentation](http://aka.ms/pnc){:target="_blank"}, Traffic Inspection of any kind via a tool like Palo, Zscaler, or nginx (caching) violates Microsoft’s Terms & Conditions (as well as each major cloud provider) as traffic that was decrypted and is heading to Microsoft is indistinguishable from man in the middle attacks. + - As a result, all traffic inspected is promptly dropped by Microsoft. As we rely on Azure Networking for SHIELD to run, this prevents SHIELD from functioning. + - Please validate that **ALL** Microsoft traffic is excluded from any form of Network Inspection: this is a requirement for SHIELD to function, as it is against Microsoft’s terms and conditions. + +--- + +## Data Security + +### SHI Lab Azure Architecture + +- Regulatory compliance standards: [https://servicetrust.microsoft.com/](https://servicetrust.microsoft.com/){:target="_blank"} +- Encryption at rest (mandatory) +- Encryption in transit (mandatory) + - Quantum resistant algorithms only + - Latest TLS version for resource only +- CRUD Audit + - SQL Audit is enabled too +- Access Audit (Mandatory) +- Full micro-segmentation (address/port enforcement for all resources) +- Data-store behind API, no internet access +- SSO Access Only (no cred vaulting workarounds, pure modern SSO, credential-less only) +- MFA for all authentication is mandatory +- Human-free production-only design + - Access to the Production environment is limited to only highly critical incidents. +- Debug access is severely limited +- No Operating Systems + - Pure Serverless + - Always up to date + - No custom execution except for designed workload (no viruses possible) + - No update downtime + - Vulnerability patching done before public announcement of vulnerability + - Self-healing + +### Miscellaneous Considerations + +- No customer data is used in any environment except for production +- Environment is only production only, reducing surface area of attack + - No dev or test environments + - Prod only via ring deployment and feature flags +- All tooling can run locally so that no production access is required for testing, development and debugging +- No on-premise systems, all resources are cloud only including end user compute/systems +- Hardware supply chain is strictly enforced +- Surface devices are only allowed at all levels of end user compute +- Firmware credentials are set to cert auth on all endpoints +- Device source code available for review: [https://microsoft.github.io/mu/](https://microsoft.github.io/mu/){:target="_blank"} + +--- + +## Data Structure + +### High-level Data Flow Diagram + +SHIELD: Discover does not collect PII or similar data – it is only focused on the scope of configurations within the Microsoft security stack, and not on any private employee or customer data. Specifics on what data collected is listed in the next section. +As a self-hosted application, data collected lives in the customer environment until it is anonymized and sent to SHIELD’s database via the Data Gateway. The Data Gateway structure is available to review upon request. + +![SHIELD Discover Module Data Flow](/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg) + +### Example Data Structure & Output + +SHIELD Discover collects the following data: + +- Tenant ID +- Principal ID that saved the report +- Principal ID that ran the report +- Principle Object ID + - Assigned License – The Service Plan IDs of the license(s) that are assigned (direct or indirect) to the specific principal + - Assigned Services – The service configuration assignment determining ‘benefitting’ from a service. This includes the service configuration type if possible (feature, such as ‘Conditional Access,’ a service within the Entra ID license) + - Consumed Services – Usage telemetry retrieved to indicate if the specific principal is consuming/using the service, regardless of license status + + +For a complete look at the Data Structure, please refer to the below block or utilize [SwaggerEditor](https://editor-next.swagger.io/){:target="_blank"} for rendering. \ No newline at end of file diff --git a/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png b/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png new file mode 100644 index 0000000..60e3331 Binary files /dev/null and b/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png differ diff --git a/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg b/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg new file mode 100644 index 0000000..d2eaab8 Binary files /dev/null and b/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg differ diff --git a/docs/SHIELD/Reference/Break-Glass-Overview.md b/docs/SHIELD/Reference/Break-Glass-Overview.md new file mode 100644 index 0000000..30e8127 --- /dev/null +++ b/docs/SHIELD/Reference/Break-Glass-Overview.md @@ -0,0 +1,80 @@ +# Break Glass Accounts + +## Overview + +A break glass account, or [emergency access account](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access){:target="_blank"}, is a highly privileged, unlicensed, emergency access mechanism used to regain access to critical resources that can be used to recover systems. Typically, when standard administrative accounts are unavailable, due to outages, conditional access misconfiguration, Multi-Factor Authentication (MFA) failures, or account lockouts. + +--- + +## Getting Started + +It is strongly recommended to maintain two break glass accounts. One account is designated as the primary and the other as a backup. This provides a fail-safe mechanism should the primary account be inaccessible for any reason. + +- Break glass accounts need to be excluded from all security controls. +- These accounts must retain full functionality at all times. Any restrictions could lead to critical outages and operational disruptions. +- Be sure to test the account login immediately after creation to ensure validity. + +--- + +## Storage Methods + +### Offline Physical Storage + +A break glass packet should be enclosed in a sealed, tamper-evident, waterproof container stored in a physically secured location such as a company safe, safe deposit box, or vault. + +#### Break Glass Packet + +Each break glass packet should include two of the following printed out: + +- Account username and password +- Detailed login instructions including the specific account to access such as "entra.microsoft.com", "portal.azure.com", "admin.microsoft.com". +- Two FIDO2 keys (YubiKeys are recommended); one primary and one backup in case the primary key breaks. Both break glass accounts should be stored on each security key. + - **Note**: Multi-Factor Authentication (MFA) is mandatory, even for emergency access accounts. + - PINs for FIDO2 (Fast IDentity Online 2) pins need to be randomly generated and included on the papers. For more information about FIDO2, see [What is FIDO2?](https://www.microsoft.com/en-us/security/business/security-101/what-is-fido2){:target="_blank"} + - **Note**: You can have multiple FIDO2 credentials stored on a single security key. + +#### Passwords + +- Passwords must be a minimum of 32 characters; 64 characters are recommended, although the longer the password the better. +- The password should not be human generated. It must be completely randomly generated by a credential vaulting solution and set on the account. +- Passwords should be printed using a monospaced typeface, such as Consolas. + - This prevents confusing similar-looking characters such as the numeral zero (0) and the uppercase letter 'O', as well as the numeral one (1), lowercase 'L' (l) and uppercase 'i' (I). Since the passwords are long, it is easy to input the wrong character and not know where you made the mistake. +- Passwords must be changed immediately after every usage session (after emergency is resolved). + +#### Printing + +- Use a Secure Printer + - Print passwords only on a printer that does not store printed materials. + - Most multi-function printers (MFPs) have internal storage that retains print jobs in plain text. + - If using an MFP, remove and securely erase the hard drive after printing. +- Ensure Privacy During Printing + - Confirm that no security cameras are directed toward the printer. + - Cameras can capture printed content, and anyone with access to footage could obtain privileged credentials. + - Ensure that unauthorized personnel are not present during printing. + - Ensure that people are not present with Eidetic (photographic) memory/total recall or are familiar with fast memorization techniques. +- Print and Store Copies + - Print two copies of the packet for each break glass storage location. + - Store the copies inverted relative to each other to minimize the impact of water damage. + - If water damage occurs, it typically affects only part of the packet, allowing reconstruction from unaffected sections. + - If you do not have a secondary location, consider using a safe deposit box. +- Maintain Redundancy + - Keep two complete sets in each location to ensure availability if one set is damaged. + +--- + +## Additional Considerations + +### Auditing + +Break glass accounts should be monitored and audited as much as possible. It is essential to track all activities associated with these accounts, as they operate without restrictions. + +- Break glass accounts should not be excluded from auditing controls. + +### Notifications + +Notifications must be set up inside of the security information and event management (SIEM) solution of your choice to ensure timely alerts. Notifications should include phone calls, emails, and text messages sent to everyone in the chain, especially the person in charge of information technology, such as the Chief Information Officer (CIO), Chief Information Security Officer (CISO), Director of Information Technology (IT), or equivalent. All security personnel must be alerted if there is: + +- Any successful sign-in from a break glass account +- Any password reset or modification + +**Note**: Notifications may take up to 5 minutes after authentication, due to a limitation in log analytics if using Microsoft Sentinel. diff --git a/mkdocs.yml b/mkdocs.yml index a548ae6..e9ce9c8 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -153,7 +153,32 @@ nav: - Overview: SHIELD/Deploy/index.md - Deployment: SHIELD/Deploy/Deployment/index.md - Usage Guide: SHIELD/Deploy/Usage-Guide.md - - Reference: SHIELD/Deploy/Reference/index.md + - Reference: + - Reference: SHIELD/Deploy/Reference/index.md + - Architecture: + - SHIELD: + - Enterprise: + - Conditional Access: + - Compliance: SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md + - Location: SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md + - Microsoft Defender for Cloud Applications (MDCA): SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md + - Multi-Factor Authentication (MFA): SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md + - Privileged: + - Conditional Access: + - Authentication Methods: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md + - Block Non-Privileged: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md + - Compliance: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md + - Disable Conditional Access Resilience Downgrade: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md + - Hardware Enforcement: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md + - Join Type: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md + - Legacy Authentication: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md + - Location: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md + - Multi-Factor Authentication (MFA): SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md + - Operating System Enforcement: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md + - Session Persistence: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md + - Sign-in Risk: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md + - Token Binding: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md + - User Risk: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md - Troubleshooting: SHIELD/Deploy/Troubleshooting.md - Defend: @@ -198,6 +223,7 @@ nav: - Discover: - Overview: SHIELD/Discover/index.md + - Installation: SHIELD/Discover/Installation.md - Deployment: SHIELD/Discover/Deployment/index.md - Usage Guide: SHIELD/Discover/Usage-Guide.md - Plugins: @@ -223,6 +249,7 @@ nav: - Configure Managed Identity: SHIELD/Reference/Settings/Configure-Managed-Identity.md - Debug Mode: SHIELD/Reference/Settings/Debug-Mode.md - Environment Variables: SHIELD/Reference/Settings/Environmental-Variables-Reference.md + - Break Glass: SHIELD/Reference/Break-Glass-Overview.md - Uninstall: SHIELD/Reference/Uninstall.md - Data Gateway: