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 deleted file mode 100644 index b69bfb1..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md +++ /dev/null @@ -1,31 +0,0 @@ -# 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 deleted file mode 100644 index a4170d1..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md +++ /dev/null @@ -1,30 +0,0 @@ -# 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 deleted file mode 100644 index 6a5388d..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md +++ /dev/null @@ -1,30 +0,0 @@ -# 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 deleted file mode 100644 index a0c6439..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 8ada825..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 3f1e2ed..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 32ce73a..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md +++ /dev/null @@ -1,30 +0,0 @@ -# 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 deleted file mode 100644 index d05a91c..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index b6a5447..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index bd900cb..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index f0ee218..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index f907897..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index dd2b2fb..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 29dc392..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 231ffee..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index d1f0f84..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index 25b2039..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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 deleted file mode 100644 index e4bf22d..0000000 --- a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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/Deploy/Reference/Policies/Entra-Conditional-Access.md b/docs/SHIELD/Deploy/Reference/Policies/Entra-Conditional-Access.md new file mode 100644 index 0000000..febfad2 --- /dev/null +++ b/docs/SHIELD/Deploy/Reference/Policies/Entra-Conditional-Access.md @@ -0,0 +1,442 @@ +# Entra Conditional Access + +## Enterprise + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +## Privileged + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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 Requirement**: + +- 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"} + +--- + +### 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 Requirement**: + +- 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} + +--- + +### 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"} \ No newline at end of file diff --git a/docs/SHIELD/Prerequisites/Required-Graph-API-Permissions.md b/docs/SHIELD/Prerequisites/Application-Permissions.md similarity index 93% rename from docs/SHIELD/Prerequisites/Required-Graph-API-Permissions.md rename to docs/SHIELD/Prerequisites/Application-Permissions.md index 1a02960..d2c7f91 100644 --- a/docs/SHIELD/Prerequisites/Required-Graph-API-Permissions.md +++ b/docs/SHIELD/Prerequisites/Application-Permissions.md @@ -1,29 +1,29 @@ -# Required Permissions +# Application Permissions + +## Required Permissions The below permissions are necessary for the operation of this web app. -## End User Permissions +## User Permissions -The below permissions are required to be assigned to the user that is doing the installation of SHIELD itself. -The permission(s) are not assigned to the service principal. +### Install SHIELD | Permission Name | What it is used for | |------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `Global Administrator` | To use the SHIELD installer link and install SHIELD into the Azure tenant. For more information, see [Setup Steps/Requirements](Installation/#setup-stepsrequirements). | - ---- +| `Global Administrator` | To use the SHIELD installer link and install SHIELD into the Azure tenant. For more information, see [Overview and Installation Requirements](./Installation.md). | -## SHIELD's Service Principal +### Run SHIELD Discover Scans -Permissions listed below are assigned directly to the service principal that SHIELD uses to orchestrate/audit. +| Permission Name | What it is used for | +|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `Global Administrator` | To run the SHIELD Discover report. | +| `Global Administrator`, `Security Administrator`, & `User Administrator` | To run the SHIELD Discover Report with least permissions
**Note**: All three permissions are required.| -!!! info - A service principal is a non-human user, such as managed identity or app registration. It is highly recommended to use a Managed Identity. -Permissions that can't be self auto granted are automatically granted by SHIELD - Desktop's installer module. +--- !!! note - The permission marked with '✅' are assigned by SHIELD to itself. Permissions marked as '❌' have to be assigned by an admin ahead of time. + Permissions marked with '✅' are assigned by SHIELD to itself. Permissions marked as '❌' have to be assigned by an admin ahead of time. ### Entra ID Role Assignments diff --git a/docs/SHIELD/Prerequisites/Installation.md b/docs/SHIELD/Prerequisites/Installation.md index 9e0f4f9..ee83417 100644 --- a/docs/SHIELD/Prerequisites/Installation.md +++ b/docs/SHIELD/Prerequisites/Installation.md @@ -2,125 +2,77 @@ ## 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. +SHIELD is a self-hosted application deployed in a customer’s Azure App Service tenant. SHIELD collects and processes all necessary data exclusively within the customer’s environment, then returns only abstracted and fully anonymized results back to SHI for reporting. All requirements can be set up by the delivery team or customer prior to engagement. This guide explains how to install the SHIELD - Desktop application and run your first scan. For more information about requirements, pricing, and more, see [Prerequisites](/SHIELD/Prerequisites). !!! 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. - ---- - -## Installation Instructions - -### SHIELD - Desktop's Installer Module - -1. Create new Dedicated Azure Subscription (recommended for isolation). -2. The installer must have: - - `Owner` on the Azure subscription (to deploy resources) - - Global Administrator or Privileged Role Administrator (to grant Microsoft Graph application permissions via admin consent) -3. Run the installer to set up SHIELD automatically using the following link: [https://url.shilab.com/shield-install](https://url.shilab.com/shield-install) - ---- - -## Azure Cost Estimate Associated (as of 4/30/2026): - -| Premium v4 Service Plan | vCPU(s) | RAM | Storage | Pay as you go | 1 year savings plan | 3 year savings plan | 1 year reserved | 3 year reserved | -|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------| -| P0v4 | 1 | 4 GB | 250 GB | **53.29**/month | **$36.771**/month ~ 31% savings | **$24.514**/month ~ 54% savings | **$31.420**/month ~ 41% savings | **$20.251**/month ~ 62% savings | -| P1v4 | 2 | 8 GB | 250 GB | **$106.58**/month | **$73.541**/month ~ 31% savings | **$49.027**/month ~ 54% savings | **$62.919**/month ~ 41% savings | **$40.501**/month ~ 62% savings | - - + 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 and security reviews prior to engagement upon request. Permissions exist for both the user initiating the report and the application itself. Code review is available upon request. --- -### Networking +## Networking Requirements -- Network Endpoints: - - - - - - https://*.azurewebsites.net -- Disable network traffic inspection/unwrapping/decryption - - 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. +For a smooth installation, network traffic inspection must be disabled on the device installing SHIELD. If inspection is enabled, Microsoft will drop the traffic, and SHIELD will not function properly. This includes tools like Palo, Zscaler, or nginx (caching). Traffic inspection must be excluded from network inspection according to Microsoft's terms and conditions. For more information, see [Microsoft Documentation](http://aka.ms/pnc){:target="_blank"}. ---- +If you require assistance, please reach out to your networking team, security team, or the person in charge of information technology at your organization. For more information about traffic inspection, see [Network Traffic Inspection](./Network-Traffic-Inspection). -## 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"} +- Add the following network endpoints to the inspection exclusion list: + - `https://api.shilab.com` + - `https://url.shilab.com` + - `https://*.azurewebsites.net` - *Your specific deployment URL (generated after deployment)* --- -## Data Structure - -### High-level Data Flow Diagram - -SHIELD: Discover does not collect Personally Identifiable Information (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. - -```mermaid -flowchart LR -SHI[SHI] - -subgraph tenant["Customer Tenant"] - serviceConfiguration[Service Configuration Scope Noted to Object ID. Configuration **not** recorded] - tenantConfiguration[Tenant Configuration Observed, such as a Conditional Access policy] - objectIDs[Object IDs in Scope Determined] -end - -serviceConfiguration --> tenantConfiguration -tenantConfiguration --> objectIDs -objectIDs --> serviceConfiguration - -SHI -.Initial Installation.-> tenant -serviceConfiguration-->|Object IDs with associated Scopes reported to Data Gatway, no PII Associated| SHI -``` +## Installation Instructions -### Example Data Structure & Output +!!! info "SHIELD Installation Has Changed" + The **SHIELD - Desktop** application is now the preferred method, for faster and easier installation.

+ **Why?** The desktop application automates most steps, making setup much simpler.

+ **Manual Installation**: If you prefer the manual method, please reach out to an SHI employee for guidance and support -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 +### SHIELD - Desktop's Installer Module -For a complete look at the Data Structure, please refer to the [Data Gateway API Spec](https://specs.shilab.com/){:target="_blank"}. +1. Create a new Azure subscription dedicated to SHIELD (recommended for isolation). +2. You must have: + - **Global Administrator** or **Privileged Role Administrator** (to grant Microsoft Graph application permissions via admin consent). For more information about permissions, see [Application Permissions](./Application-Permissions). + - `Owner` on the Azure subscription (to deploy resources) +3. If you haven't already done so, turn off network traffic inspection on the device installing SHIELD, so there are no interruptions during installation. If you require assistance with this step, please see [Networking Requirements](#networking-requirements) above. +4. Run the installer to set up SHIELD automatically using the following link: [https://url.shilab.com/shield-install](https://url.shilab.com/shield-install) + - **Note**: The download will not work if network traffic inspection is enabled, especially in Microsoft/Azure environments. + +### Install and Deploy SHIELD Discover + + +1. After installation, launch the SHIELD - Desktop application. +2. Log in using the account manager in the top right corner. Be sure to log in with the account that has the necessary `Owner` and `Global Admin` permissions in Azure. These are required to grant the necessary permissions for deployment. +3. After you are successfully logged in, click on the **Installer** module. + - **Note**: An additional tab may open, and another log in may be required. +4. Select the **Azure Subscription** that is dedicated for SHIELD. +5. Select your desired **Azure Region** from the drop-down menu. **West US 3** is recommended, but other regions can be selected depending on company policy. +6. Click on the toggle switch to display **Advanced Options**. +7. For **Operation Mode**, select **Discover** from the drop-down menu. +8. Click on the **Deploy** button for the SHIELD installer to begin the installation process. + - **Note**: An additional tab may open, and another log in may be required. +9. The installer will do the following: + - Download the SHIELD Deploy ZIP file + - Create a SHIELD App Service and managed identity in Azure + - Upload and configure the SHIELD application, including permissions and security settings such as disabling basic auth, enabling encryption, and setting quantum-resistant cryptography. +10. After deployment, verify the following required permissions are granted to the SHIELD managed identity in Azure: + - `Application.ReadWrite.All` + - `AppRoleAssignment.ReadWrite.All` +11. Lastly, assign the Read and Write Everything role to the user who will run SHIELD scans via the "SHIELD End User Login" enterprise app in Entra. + + +### Running the SHIELD Web Instance + + +1. Navigate to your SHIELD web instance in your browser: [https://portal.azure.com/](https://portal.azure.com/){:target="_blank"} +2. Click **Resource groups**. +3. Click **SHIELD**. +4. Click on the App Service that starts with "shield-xxxxxxxxx" (the x's are a random set of lower-case letters and numbers). +5. In the top right corner, click on the **Default domain** link. **Example**: shield-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx.eastus-01.azurewebsites.net +6. Log in to the SHIELD web instance with the account that has the necessary Azure permissions. +7. Click on **Discover Module**. +8. Click **Start Authentication Sync**. Then click **Start Report Collection** to start scanning the tenant environment. +9. During the first scan, SHIELD - Desktop will open and request account credentials multiple times. Log in each time as required. You will also need to accept each set of permissions. +10. Once the scan is complete, reports are available on the SHIELD web instance. + 1. Click **Discover** in the left navigation pane and click **Overview**. \ No newline at end of file diff --git a/docs/SHIELD/Prerequisites/Network-Traffic-Inspection.md b/docs/SHIELD/Prerequisites/Network-Traffic-Inspection.md new file mode 100644 index 0000000..28ecefb --- /dev/null +++ b/docs/SHIELD/Prerequisites/Network-Traffic-Inspection.md @@ -0,0 +1,40 @@ +# Network Traffic Inspection + +Network traffic inspection is the process of monitoring, capturing, and analyzing data packets that flow through a computer network. It is the cornerstone of modern cybersecurity, enabling organizations to detect threats, optimize performance, and maintain compliance. + +!!! note + If you need to disable network traffic inspection for SHIELD, reach out to your networking team, security team, or the person in charge of information technology at your organization. Each organization manages its own inspection tools and policies, and there is no universal method. + + +## Purpose + +Gain visibility into network activity, detect anomalies, enforce security policies, and troubleshoot performance issues. Cloud services such as Microsoft Azure, Google, Amazon, and Apple do not allow network traffic to be inspected, decrypted, or changed. Doing so can cause authentication failures and may be treated as a security risk, like a man-in-the-middle attack. + +- **Example**: Microsoft will drop any traffic that has been inspected or repackaged, preventing applications, such as SHIELD, from functioning properly. + +## How it Works + +- **Data Collection**: Traffic inspection tools intercept and record packets or flows of strategic points in the network. This can be done in the perimeter (edge), within core segments, or in cloud environments. +- **Analysis**: Captured data is analyzed for patterns, threats, and performance bottlenecks. Deep packet inspection (DPI) may be used by tools to examine the contents of packets, or flow monitoring to summarize communication between endpoints. +- **Enforcement**: Based on the analysis, organizations can block malicious traffic, optimize bandwidth, or enforce compliance requirements. + +## Importance + +- **Security**: Detects threats like malware, unauthorized access, and data exfiltration. Helps identify suspicious patterns and block attacks. +- **Performance**: Diagnoses network bottlenecks, latency, and downtime. +- **Compliance**: Supports auditing and regulatory requirements by logging and analyzing network activity. + +## What is Supported + +- Monitoring traffic for performance and security at endpoints you control such as servers and internal segments. +- Using tools for visibility and troubleshooting within your own infrastructure. + +## What is Not Supported + +- Inspecting, decrypting, or altering traffic destined for major cloud providers such as Microsoft, Google, Amazon, and Apple. +- Attempting to inspect traffic to Microsoft domains (e.g., security.microsoft.com, azurewebsites.net, etc.) will result in dropped connections and failed authentication. + +## Types of Inspection + +- **Layer 4 (L4) Inspection** - Examines basic headers (IP addresses, ports, protocol type) for fast, efficient filtering and routing. Limited visibility into content. +- **Layer 7 (L7) Inspection** - Analyzes application-layer content (HTTP headers, cookies, payloads) for deeper security and content-based routing. More granular but resource intensive. diff --git a/docs/SHIELD/Prerequisites/index.md b/docs/SHIELD/Prerequisites/index.md index 453249a..df998c4 100644 --- a/docs/SHIELD/Prerequisites/index.md +++ b/docs/SHIELD/Prerequisites/index.md @@ -2,18 +2,33 @@ Before deploying SHIELD or using Discover, ensure your environment meets all license, configuration, permission, and software requirements. -This page is divided into two parts: +--- + +## Pricing + +### Azure Cost Estimate Associated (as of 7/28/2026): + +| Premium v4 Service Plan | vCPU(s) | RAM | Storage | Pay as you go | 1 year savings plan | 3 year savings plan | 1 year reserved | 3 year reserved | +|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------| +| P0v4 | 1 | 4 GB | 250 GB | **$53.29**/month | **$36.771**/month ~ 31% savings | **$24.514**/month ~ 54% savings | **$31.420**/month ~ 41% savings | **$20.251**/month ~ 62% savings | +| P1v4 | 2 | 8 GB | 250 GB | **$106.58**/month | **$73.541**/month ~ 31% savings | **$49.027**/month ~ 54% savings | **$62.919**/month ~ 41% savings | **$40.501**/month ~ 62% savings | -1. [SHIELD Core Platform Requirements](#shield-core-platform-requirements) -2. [Discover System Requirements](#discover-system-requirements) --- -## SHIELD Core Platform Requirements +## Network Traffic Inspection + + +Network traffic inspection must be turned off on the device where SHIELD is being installed. This ensures the installation process proceeds without interruption and prevents any disruption to the application’s functionality. To disable network traffic inspection, reach out to your networking team, security team, or the person in charge of information technology at your organization. Each organization manages its own inspection tools and policies, and there is no universal method. + + +--- + +### SHIELD Core Platform Requirements SHIELD automates secure deployment and lifecycle management using Microsoft 365 and Azure. It requires specific license levels, identity configurations, and Microsoft Defender components. -### Environment Requirements +#### Environment Requirements - ✅ Deploying user must have **Global Admin Rights** - ✅ Microsoft Defender for Endpoint must be provisioned. See [Defend Usage Guide](../Defend/Usage-Guide/), under **Defender for Endpoint Workspace Creation** @@ -22,7 +37,90 @@ SHIELD automates secure deployment and lifecycle management using Microsoft 365 --- -### Licensing Requirements by Mode +### 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 Personally Identifiable Information (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. + +```mermaid +flowchart LR +SHI[SHI] + +subgraph tenant["Customer Tenant"] + serviceConfiguration[Service Configuration Scope Noted to Object ID. Configuration **not** recorded] + tenantConfiguration[Tenant Configuration Observed, such as a Conditional Access policy] + objectIDs[Object IDs in Scope Determined] +end + +serviceConfiguration --> tenantConfiguration +tenantConfiguration --> objectIDs +objectIDs --> serviceConfiguration + +SHI -.Initial Installation.-> tenant +serviceConfiguration-->|Object IDs with associated Scopes reported to Data Gateway, no PII Associated| SHI +``` + +### Example Data Structure & Output + +SHIELD Discover collects the following data: + +- Tenant ID +- Principal ID that saved the report +- Principal ID that ran the report +- Principal 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 [Data Gateway API Spec](https://specs.shilab.com/){:target="_blank"}. + +--- + +#### Licensing Requirements by Mode SHIELD uses `M3` and `M5` to refer to Microsoft 365 license families, abstracting E3/E5 and similar plans. @@ -34,7 +132,7 @@ SHIELD uses `M3` and `M5` to refer to Microsoft 365 license families, abstractin --- -## Discover System Requirements +### Discover System Requirements Discover is a component of SHIELD that audits licensing configuration, queries Microsoft APIs, and stores analysis in SHI - Data Gateway. The following setup is required. @@ -43,7 +141,7 @@ Discover is a component of SHIELD that audits licensing configuration, queries M --- -### Entra ID Role Permissions +#### Entra ID Role Permissions Discover uses read-only Entra ID roles for configuration queries. These permissions are scoped with the principle of least privilege. diff --git a/docs/SHIELD/Reference/Settings/Configure-Managed-Identity.md b/docs/SHIELD/Reference/Settings/Configure-Managed-Identity.md index 621debc..43c7817 100644 --- a/docs/SHIELD/Reference/Settings/Configure-Managed-Identity.md +++ b/docs/SHIELD/Reference/Settings/Configure-Managed-Identity.md @@ -34,7 +34,7 @@ No fear, PowerShell is here! Check out this PowerShell app: The PowerShell app will graphically list all the managed identities, let you select one, then graphically list all the Graph API permissions you can assign it. Assign the permissions listed here: -[Required Graph API Permissions](../../Prerequisites/Required-Graph-API-Permissions) +[Required Graph API Permissions](../../Prerequisites/Application-Permissions) For more information on how the PowerShell app works, check out this MS Docs article: diff --git a/zensical.toml b/zensical.toml index a852c50..ce01c71 100644 --- a/zensical.toml +++ b/zensical.toml @@ -11,7 +11,8 @@ nav = [ {"Prerequisites" = [ {"Overview" = "SHIELD/Prerequisites/index.md"}, {"Installation" = "SHIELD/Prerequisites/Installation.md"}, - {"Graph API Permissions" = "SHIELD/Prerequisites/Required-Graph-API-Permissions.md"} + {"Application Permissions" = "SHIELD/Prerequisites/Application-Permissions.md"}, + {"Network Traffic Inspection" = "SHIELD/Prerequisites/Network-Traffic-Inspection.md"} ]}, {"Usage Guide" = "SHIELD/Usage-Guide.md"}, {"Deploy" = [ @@ -20,35 +21,8 @@ nav = [ {"Usage Guide" = "SHIELD/Deploy/Usage-Guide.md"}, {"Reference" = [ {"Overview" = "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"} - ]} - ]} - ]} + {"Policies" = [ + {"Entra Conditional Access" = "SHIELD/Deploy/Reference/Policies/Entra-Conditional-Access.md"}, ]}, {"Troubleshooting" = "SHIELD/Deploy/Troubleshooting.md"} ]}