Three-Layer Access Architecture — Audit Evidence Package

Purpose

This document provides audit evidence for the three-layer access control architecture implemented across Cirius Group environments. Each layer is documented with its control mechanism, Terraform implementation reference, and where evidence can be found. This document supports SOC2 CC6.x (Logical and Physical Access Controls), HIPAA §164.312(a) (Technical Safeguards — Access Control), and HITRUST 01.a/01.b requirements.

Architecture Overview

Access to internal resources is enforced through three independent, sequential control layers. An attacker or unauthorized user must bypass all three to gain access.

External User / Device
       │
       ▼
┌──────────────────────────────────────────────────────────┐
│  LAYER 1: NETWORK LAYER — Zero Trust Network Access      │
│  Twingate ZTNA — no network path without authentication  │
│  No VPN split tunneling. No direct inbound internet.     │
└──────────────────────────────────────────────────────────┘
       │ Authenticated session only
       ▼
┌──────────────────────────────────────────────────────────┐
│  LAYER 2: IDENTITY LAYER — Entra ID + MFA               │
│  Conditional Access policies enforce phishing-resistant  │
│  MFA (FIDO2/passkey) for all remote access scenarios    │
└──────────────────────────────────────────────────────────┘
       │ Verified identity only
       ▼
┌──────────────────────────────────────────────────────────┐
│  LAYER 3: DEVICE LAYER — Intune Compliance              │
│  CA policy requires Intune-compliant managed device.    │
│  Cortex XDR endpoint protection on all managed devices. │
└──────────────────────────────────────────────────────────┘
       │ Compliant device only
       ▼
   Internal Resources (PROD / DDE / AWS)

Exceptions:

CEO/CTO have GlobalProtect as an additional remote access pathway. GlobalProtect is also subject to Entra ID conditional access (Layer 2) and Intune compliance (Layer 3).
Break-glass accounts (cirius-breakglass@*) bypass Twingate but are protected by PIM, MFA enforcement, and real-time CRITICAL alerting with no suppression window. Any break-glass sign-in triggers an immediate SecOps incident.

Layer 1: Zero Trust Network Access (Twingate)

Control Description

Twingate replaces traditional VPN with zero-trust network access. Users must authenticate to Twingate before any network path exists to internal resources. There is no open inbound internet port to any internal system — the Twingate connector initiates an outbound tunnel.

Implementation Evidence

Evidence Item	Location / Reference
Twingate connectors deployed in DMZ VNET	`azure-infra/firewall/` — Twingate connector VM resources
No direct inbound internet to private subnets	NSG rules on `snet-identity`, `snet-prod-servers`, `snet-prod-workers` — no 0.0.0.0/0 inbound rules
Twingate SAML integration with Entra ID	Twingate Admin Portal → Authentication → SAML. IdP: Entra ID app registration `twingate-law-ingest` (PROD tenant). Authentication enforces Entra ID MFA before issuing Twingate session
Remote access Conditional Access policy	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-RemoteAccess-CompliantDeviceFIDO2`
Twingate connector monitoring	`bedrock-hub/agents/twingate_agent.py` — monitors connector uptime, alerts CRITICAL if offline >1h
Twingate connector private IPs documented	`azure-infra/firewall/net_vnet.tf` — DMZ subnet allocations

Twingate Architecture

External Device (Twingate client installed)
       │
       │  HTTPS tunnel to Twingate cloud relay
       ▼
Twingate Connector (DMZ VNET)
       │
       │  Private network path — no firewall rule change needed
       ▼
Internal Resource (private subnet)

Monitoring

twingate_agent.py (PROD maintenance job) alerts CRITICAL if any connector has been offline for >1 hour
Twingate access logs ship to LAW via DCR (twingate-law-ingest service account, Data Collection Endpoint)
Failed Twingate authentications visible in Entra ID SignInLogs (SAML auth failures)

Layer 2: Identity Verification (Entra ID + MFA)

Control Description

All remote access scenarios require authentication against Entra ID with phishing-resistant MFA. Conditional Access policies enforce FIDO2 hardware keys or passkeys for remote access. Legacy authentication (Basic Auth, NTLM over internet) is blocked tenant-wide.

Implementation Evidence

Evidence Item	Location / Reference
Remote Access CA policy — FIDO2 required	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-RemoteAccess-CompliantDeviceFIDO2`
Block legacy authentication	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-BlockLegacyAuth`
MFA required for all users	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-RequireMFA-AllUsers`
MFA for privileged admin roles	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-RequireMFA-Admins-AllCloudApps`
Sign-in risk CA policy	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-SignInRisk-MediumHigh-MFA`
Entra authorization policy — guest restrictions	`azure-infra/entra/authorization-policy.tf` — `azuread_authorization_policy.main`
Guest access to M365 groups blocked	`azure-infra/entra/group-settings.tf` — `AllowGuestsToAccessGroups=false`
Maester test results	EIDSCA track B — all authorization policy tests passing

Conditional Access Policies Active (PROD tenant)

Policy	Condition	Action
`CA-RequireMFA-AllUsers`	All users, all cloud apps	Require MFA
`CA-RequireMFA-Admins-AllCloudApps`	Privileged admin roles	Require MFA
`CA-BlockLegacyAuth`	Legacy auth clients	Block
`CA-RemoteAccess-CompliantDeviceFIDO2`	Remote access scenarios	Require FIDO2 + Intune-compliant device
`CA-SignInRisk-MediumHigh-MFA`	Risk ≥ Medium	Require MFA or block
`CA-UserRisk-High-Block`	User risk = High	Block

Authorization Policy Controls

Control	Setting	Maester Test
Users can register applications	Disabled	EIDSCA.AP04
Users can create new tenants	Disabled	MT.1069
Users can create security groups	Disabled	MT.1068
Guest users can invite other guests	Disabled	EIDSCA.AP06 / MT.1055
Guests can access M365 groups	Disabled	EIDSCA.AG01
Guests can be group owners	Disabled	EIDSCA.AG02
Only admins can create M365 groups	Enabled	MT.1073 / CISA.MS.AAD.5.2

Monitoring

Identity agent (bedrock-hub/agents/entra/identity_agent.py) reviews SignInLogs for:
- First-time login from unmanaged device (T1078.003)
- Impossible travel (UBA)
- Sign-in outside of normal hours
- MFA fatigue (multiple MFA prompts in short window)
Break-glass sign-ins trigger CRITICAL with no suppression, no known-good suppression ever
Weekly Maester audit (maester-sprint2-ca.tf controls validated via GitHub Actions)

Layer 3: Device Compliance (Intune + Cortex XDR)

Control Description

Remote access is restricted to Intune-managed, compliant devices. The CA-RemoteAccess-CompliantDeviceFIDO2 policy requires the device to satisfy Intune compliance policies before a session is granted. All managed devices also have Cortex XDR deployed for endpoint detection and response.

Implementation Evidence

Evidence Item	Location / Reference
CA policy requires Intune-compliant device	`azure-infra/entra/maester-sprint2-ca.tf` — `CA-RemoteAccess-CompliantDeviceFIDO2` — `grantControls.operator = AND`, `requireCompliantDevice = true`, `authenticationStrength.id` (FIDO2)
Intune compliance policies	Intune admin center — Windows 10/11 compliance policies: BitLocker required, Defender required, OS update compliance
Cortex XDR on all managed devices	Cortex XDR admin console — All-devices view; `bedrock-hub/agents/cortex_agent.py` monitors agent status
EDR silence escalation	`bedrock-hub/agents/edr_silence_agent.py` — alerts HIGH if Cortex returns 0 findings while other agents are elevated (indicates potential EDR tampering)
Cortex coverage monitoring	`bedrock-hub/agents/operational/arctic_wolf_coverage_agent.py` and `cortex_coverage_agent.py`

Intune Compliance Policy Requirements (Windows)

Requirement	Setting	Enforcement
BitLocker enabled	Required	CA blocks sign-in if not compliant
Microsoft Defender Antivirus	Active	CA blocks sign-in if not compliant
Minimum OS version	Windows 10 21H2+ / Windows 11	CA blocks outdated OS
Firewall enabled	Required	CA blocks sign-in if not compliant
Device is Intune-managed	Implicit	CA `requireCompliantDevice`

Monitoring

Cortex XDR agent: real-time EDR on all managed endpoints
Arctic Wolf MDR: external monitoring with act-first authority, reviews Cortex events
edr_silence_agent.py: detects Cortex silence patterns (0 findings + elevated other agents = HIGH)
vm_status_agent.py: monitors all VMs including managed device registration status
Monthly compliance review: Intune compliance report reviewed for non-compliant device trends

Summary Table

Layer	Control	Mechanism	Evidence Location	Monitoring
1 — Network	ZTNA — no network path without auth	Twingate connectors in DMZ	`azure-infra/firewall/` NSGs + Twingate Admin	`twingate_agent.py` — CRITICAL if offline >1h
2 — Identity	Phishing-resistant MFA (FIDO2)	Entra ID Conditional Access	`azure-infra/entra/maester-sprint2-ca.tf`	`identity_agent.py`, Maester weekly audit
3 — Device	Intune-compliant managed device	Intune + Cortex XDR	Intune admin center, Cortex XDR console	`edr_silence_agent.py`, `cortex_coverage_agent.py`

Compliance Mapping

Framework	Control	Layer	Status
SOC2 CC6.1	Restrict logical access	All three layers	✅ Implemented
SOC2 CC6.2	New access requires authorization	Layer 2 (Entra) + Layer 3 (Intune managed)	✅ Implemented
SOC2 CC6.3	Remove access when no longer required	Layer 1 (Twingate deactivation) + Layer 2 (Entra user disable)	✅ Implemented
SOC2 CC6.6	Protect against threats outside boundaries	Layer 1 (ZTNA, no open inbound)	✅ Implemented
SOC2 CC6.7	Restrict transmission to authorized users	Layer 2 (Entra CA)	✅ Implemented
HIPAA §164.312(a)(1)	Access control	All three layers	✅ Implemented
HIPAA §164.312(d)	Person authentication	Layer 2 (FIDO2 MFA)	✅ Implemented
HITRUST 01.a	Access control policy	All three layers	✅ Implemented
HITRUST 01.b	Access to networks and network services	Layer 1 (ZTNA)	✅ Implemented
CISA.MS.AAD.2.1	MFA for all users	Layer 2	✅ Implemented
CISA.MS.AAD.2.3	Phishing-resistant MFA for admins	Layer 2	✅ Implemented

Audit Procedures

For External Auditors

Twingate connector verification: Request Twingate Admin Portal read access or screenshot of active connector status. Confirm no direct inbound internet access on Azure NSGs for private subnets.
Conditional Access policy review: Entra admin center → Security → Conditional Access. Review all policies listed in Layer 2 table above. Confirm CA-RemoteAccess-CompliantDeviceFIDO2 requires both FIDO2 authentication strength AND Intune-compliant device.
Maester test results: Request latest Maester M365 DSC audit report (generated weekly by GitHub Actions weekly-hipaa-audit.yml). Confirm EIDSCA.AP04/AP06/AP07, MT.1055/1068/1069/1073, EIDSCA.AG01/AG02 are all passing.
Intune compliance verification: Intune admin center → Devices → Compliance → Per-policy compliance report for Windows. Confirm BitLocker, Defender, and OS version requirements are active.
Cortex XDR coverage: Cortex XDR admin console → All Endpoints → confirm all corporate-managed devices show agent status Active.
Monitoring evidence: SecOps platform (secops.bedrockcybersecurity.org) → Incidents → filter by twingate_agent, identity_agent, cortex_agent. Demonstrate active monitoring with recent findings or clean status.

For Internal Review

Run the following to confirm all layers are active:

bash

# Layer 1: Confirm Twingate connector uptime (last 24h)
az monitor log-analytics query \
  --workspace 5d76d1f2-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --analytics-query "Twingate_CL | where TimeGenerated > ago(24h) | summarize count() by connector_name"

# Layer 2: Confirm CA policy state (all policies ON, not report-only)
az ad conditional-access policy list --query "[].{name:displayName, state:state}"

# Layer 3: Confirm Intune compliance % (via Intune admin center)
# Graph API: GET /deviceManagement/deviceCompliancePolicySettingStateSummaries

Three-Layer Access Architecture — Audit Evidence Package ​

Purpose ​

Architecture Overview ​

Layer 1: Zero Trust Network Access (Twingate) ​

Control Description ​

Implementation Evidence ​

Twingate Architecture ​

Monitoring ​

Layer 2: Identity Verification (Entra ID + MFA) ​

Control Description ​

Implementation Evidence ​

Conditional Access Policies Active (PROD tenant) ​

Authorization Policy Controls ​

Monitoring ​

Layer 3: Device Compliance (Intune + Cortex XDR) ​

Control Description ​

Implementation Evidence ​

Intune Compliance Policy Requirements (Windows) ​

Monitoring ​

Summary Table ​

Compliance Mapping ​

Audit Procedures ​

For External Auditors ​

For Internal Review ​

Three-Layer Access Architecture — Audit Evidence Package

Purpose

Architecture Overview

Layer 1: Zero Trust Network Access (Twingate)

Control Description

Implementation Evidence

Twingate Architecture

Monitoring

Layer 2: Identity Verification (Entra ID + MFA)

Control Description

Implementation Evidence

Conditional Access Policies Active (PROD tenant)

Authorization Policy Controls

Monitoring

Layer 3: Device Compliance (Intune + Cortex XDR)

Control Description

Implementation Evidence

Intune Compliance Policy Requirements (Windows)

Monitoring

Summary Table

Compliance Mapping

Audit Procedures

For External Auditors

For Internal Review