VPNLYR Audit Evidence Package

Purpose

Audit evidence for the VPNLYR (Layered Remote Access) controls that are called out in the Cirius Group HIPAA and SOC2 compliance programs. This document maps each control to its implementation, its monitoring agent, and where reviewers can find primary evidence.

Related documents:

• compliance/three-layer-access-architecture.md — the three-layer (network / identity / device) model this document extends
• compliance/hipaa-controls.md — top-level HIPAA control mapping
• architecture/two-firewall-architecture.md — the two-firewall design
• architecture/network-topology.md — IP ranges and routes
• runbooks/firewall-rule-reference.md — firewall rule governance

This document is specifically about access security controls for remote users. Server-side, workload, encryption, and PHI-storage controls are covered in the other compliance docs.

---

Framework Mapping

Framework	Control	What VPNLYR provides
HIPAA §164.312(a)(1)	Access control — unique user ID	Entra ID + on-prem AD; no shared logins; break-glass is the only shared credential and generates a CRITICAL incident on use
HIPAA §164.312(a)(2)(i)	Emergency access procedure	Break-glass GP path for CEO/CTO; documented in architecture/two-firewall-architecture.md Flow 2
HIPAA §164.312(a)(2)(iii)	Automatic logoff	Twingate session timeout and GP idle disconnect; enforced per device per Intune compliance profile
HIPAA §164.312(b)	Audit controls	Palo Alto traffic logs + GP authentication logs + Twingate session logs → LAW central → 6-year S3 WORM archive
HIPAA §164.312(c)(1)	Integrity controls	Cortex XDR behavioral FIM + WildFire file inspection on egress
HIPAA §164.312(d)	Person or entity authentication	Entra ID MFA (phishing-resistant FIDO2), Intune compliant device, Twingate device identity, GP certificate + MFA — four independent identity anchors
HIPAA §164.312(e)(1)	Transmission security	TLS to GP portal and gateway; Twingate tunnel to cloud relay; IPSec BGP to AWS
SOC2 CC6.1	Logical access controls	Twingate ZTNA + Entra CA + Intune compliance. Three-layer access with MFA enforced at layer 2
SOC2 CC6.2	Authorization	Entra group membership controls; gp-vpn-users limited to CEO/CTO; group membership reviewed quarterly
SOC2 CC6.6	Boundary protection	Two-firewall architecture — PublicFW + PrivateFW in series. Either alone cannot expose PHI
SOC2 CC6.7	Data in transit	TLS 1.2+ enforced on all remote access paths
SOC2 CC7.2	System monitoring	17-agent security monitoring system, Arctic Wolf MDR, Cortex XDR, Palo Alto DNS Security, WildFire
HITRUST 01.a	Access control policy	Documented in three-layer-access-architecture.md
HITRUST 01.b	User registration	Entra lifecycle, Intune enrollment, Twingate resource mapping

---

Control Evidence

Control A — MFA Enforcement on All Remote Access

• Description: Every remote session to PHI requires phishing-resistant MFA (FIDO2 or certificate-based) before PHI network reachability.
• Implementation:
  • Entra ID conditional access policy CA-RemoteAccess-CompliantDeviceFIDO2 — enforces FIDO2 token or platform authenticator on remote sign-ins.
  • Twingate SAML IdP = Entra ID; Twingate cannot issue a session without Entra authentication succeeding first.
  • GP portal authentication uses SAML to Entra (for CEO/CTO) and enforces the same CA policy.
• Evidence locations:
  • Entra CA policy definition in the PROD tenant: Security → Conditional Access → CA-RemoteAccess-CompliantDeviceFIDO2.
  • Entra sign-in logs (SigninLogs in LAW) — filter AuthenticationRequirement == 'multiFactorAuthentication'.
  • Twingate admin portal → Policy → Authentication.
• Framework: HIPAA §164.312(d), SOC2 CC6.1.

Control B — Twingate Zero-Trust Primary Path

• Description: Twingate replaces traditional VPN for all non-CEO/CTO staff. There is no inbound public port on PHI networks.
• Implementation:
  • Two Twingate connectors in DMZ (HA pair) — see runbooks/twingate-connector-ips.md for the operational governance.
  • Connectors initiate outbound tunnels; no inbound public port.
  • Per-resource policy — user sees only resources their Entra group grants them.
• Evidence locations:
  • twingate_agent.py (bedrock-hub/agents/twingate_agent.py) — alerts on connector offline.
  • Twingate admin portal logs.
  • PublicFW policy outbound-dmz-to-twingate (see runbooks/firewall-rule-reference.md).
• Framework: SOC2 CC6.1, CC6.6.

Control C — GlobalProtect Restricted to CEO/CTO

• Description: GP exists as a break-glass / out-of-band remote path and is limited to two named users (CEO and CTO).
• Implementation:
  • Entra security group gp-vpn-users — membership: CEO, CTO only.
  • PrivateFW gp-gateway-landing rule references this group.
  • GP client requires Intune compliance at sign-on.
  • All GP sessions still traverse PrivateFW east-west policy. Getting onto the GP tunnel does not grant blanket network access.
• Evidence locations:
  • Entra group membership audit (quarterly PIM access review).
  • GP authentication logs in LAW (PaloAltoNetworks_CL).
  • Firewall rule hit counter on gp-gateway-landing in Panorama.
• Framework: HIPAA §164.312(a)(2)(i), SOC2 CC6.2.

Control D — Palo Alto DNS Security

• Description: DNS requests from internal networks are inspected by Palo Alto DNS Security; malicious and newly-registered domains are blocked inline.
• Implementation:
  • DNS Security license active on both azure-prod-firewall and (when live) PrivateFW.
  • Security profile group applied to all outbound internet rules.
  • DNS sinkhole for positive matches forwards logs to LAW and to the kill-chain exfiltration agent for corroboration.
• Evidence locations:
  • Palo Alto threat logs (category: dns), LAW ingested.
  • SecOps findings from prod-palo-audit.py — checks the DNS Security profile is applied to security policy.
  • security/palo-alto-overview.md and security/panorama-operations.md.
• Framework: HIPAA §164.312(c)(1), SOC2 CC7.2.

Control E — Cortex XDR on All Managed Endpoints

• Description: Cortex XDR endpoint protection runs on every Windows VM and every Intune-managed device that can reach PHI.
• Implementation:
  • Agent deployed via Intune and via VM baseline image.
  • CMDB reconciliation (scripts/cmdb-upsert-cortex.py) verifies coverage; gaps become SecOps findings.
  • EDR silence agent fires HIGH if Cortex reports zero findings while other agents are elevated.
• Evidence locations:
  • Cortex XDR console — agent inventory.
  • SecOps findings from scripts/cortex-audit.py.
  • security/edr-cortex-xdr.md.
• Framework: HIPAA §164.312(c)(1), SOC2 CC7.2, HITRUST 10.l.

Control F — WildFire Malware Verdict Integration

• Description: Palo Alto WildFire verdicts on files seen in internet egress (and email attachments where integrated) are ingested into SecOps as findings. MALICIOUS verdicts produce HIGH severity findings; GRAYWARE verdicts produce MEDIUM.
• Implementation:
  • agents/network/wildfire_agent.py in ops-automation — polls WildFire API, posts findings to /api/ingest/findings.
  • Runs on the wildfire-daily.yml GitHub Actions workflow (daily cadence, 24-hour window).
  • Output artifact picked up by prod-security-dashboard.yml to appear in the monthly PROD security dashboard email.
• Evidence locations:
  • GitHub Actions run history for wildfire-daily.yml.
  • SecOps findings filtered source=WILDFIRE.
  • Artifact downloads for historical verdict logs.
• Framework: HIPAA §164.308(a)(5) (security awareness/training — malicious software), SOC2 CC7.2.

Control G — Two Firewalls in Series (Boundary Protection)

• Description: PublicFW and PrivateFW provide two independent policy-enforcement points between the internet and PHI. Either firewall dropping a flow is sufficient to prevent unauthorized access.
• Implementation:
  • architecture/two-firewall-architecture.md — design and traffic flows.
  • architecture/network-topology.md — IP ranges and route design.
  • UDRs force spoke-to-spoke through PrivateFW — completed in the VPNLYR UDR work item.
• Evidence locations:
  • azure-infra/networking/udr_*.tf — UDR Terraform.
  • azure-prod-firewall backup XML in Azure Blob — policy snapshot.
  • PrivateFW backup XML once live.
  • prod-palo-audit.py results for both devices.
• Framework: SOC2 CC6.6, HIPAA §164.308(a)(4) (information access management).

Control H — Break-Glass Auditability

• Description: Break-glass sign-ins bypass Twingate but not MFA or logging, and always generate an immediate CRITICAL incident.
• Implementation:
  • Break-glass accounts enumerated in CLAUDE.md (ciriusgroup, ciriusdde, dr.ciriusgroup.internal, plus AWS root, plus Palo Alto local admins).
  • API-level suppression block for these accounts in SecOps /api/incidents.
  • CRITICAL severity with Telegram notification on any sign-in or config-change event.
• Evidence locations:
  • SecOps DB — break-glass rule table.
  • SigninLogs filtered on break-glass UPN pattern.
  • Retrospective annual review of break-glass usage.
• Framework: HIPAA §164.312(a)(2)(i), SOC2 CC6.1.

---

Evidence Handling

• All evidence referenced here is retained for a minimum of 6 years in the SIEM-independent archive (blob + S3 WORM).
• Quarterly pulls of evidence for the compliance program are handled by the weekly HIPAA audit workflow (.github/workflows/weekly-hipaa-audit.yml in ops-automation) and its monthly consolidated dashboard.
• New evidence types (e.g., the WildFire feed, once live) are added to this document in the same PR that introduces the control.

Review Cadence

• This document is reviewed at least quarterly alongside the VPNLYR epic progress review.
• The doc-staleness agent flags this file as MEDIUM at 90 days and HIGH at 180 days — the audit evidence cannot be allowed to go stale.