A unified strategy for Zero Trust network architecture in higher education — enabling academic openness while securing research, administrative, and teaching environments through evidence-based access decisions.
Universities are uniquely difficult to secure. ASU operates thousands of applications across research, academic, and administrative domains with a transient population of 150k+ students (Fall 2024 enrollment: 152,812) plus faculty and staff, BYOD everywhere, and a cultural expectation of openness. Traditional perimeter security fails here because:
- The perimeter doesn't exist. Users access resources from personal devices, off-campus networks, cloud services, and partner institutions. There is no "inside." [1]
- Flat trust gets people breached. A compromised student laptop on a flat network can lateral-move into research data, HR systems, or grant financials. Segmentation without trust signals is just VLANs — it doesn't adapt to risk. [2]
- Compliance is table stakes for funding. Federal research grants (DoD, NIH, NSF) increasingly require demonstrated security maturity. CMMC Level 1 (15 controls per FAR 52.204-21) is the floor; Level 2 (110 controls per NIST SP 800-171) is required for controlled unclassified information (CUI) research contracts. [3]
- Credential theft is the #1 initial access vector. Stolen credentials initiated 22% of all breaches in 2025, the highest of any single vector (Verizon 2025 DBIR). Higher education is the second most phishing-targeted sector globally at 8.62% of all phishing attacks, with the highest click rate of any industry at 5.1% (CampusGuard, EasyDMARC). Certificate-based network auth (AGNI) eliminates password-based WiFi/wired access. Conditional access limits blast radius at the application layer.
- Operational cost of the status quo is unsustainable. Firewall sprawl, VPN capacity issues, manual exception management, and incident response on flat networks consume staff time that should go toward proactive security. Education faces more than 2,500 attacks weekly, up 15% over two years (Microsoft Cyber Signals / Check Point).
Trust-based access means access decisions backed by evidence (identity, device health, network location, behavior) rather than assumptions (you're on the VPN, therefore you're trusted).
From the ASU Network Principles document — the philosophical foundation for this strategy:
The network is a transport utility. Its job is moving packets reliably. Security is the responsibility of each product, application, or service — not the network.
Attribution note: The Network Principles document states Zero Trust was "Originally developed by Google." More precisely: the term was coined by Forrester analyst John Kindervag in 2009; Google's BeyondCorp (2011) was the first large-scale implementation. The five principles listed in the document align with NIST SP 800-207 Zero Trust Architecture.
Zero Trust assertions (aligned with NIST SP 800-207):
- Each service owns its own operational security (confidentiality, integrity, availability)
- The network protects infrastructure availability, not endpoint security
- Never trust one IP address more than another
- Authenticate people, actions, and endpoints dynamically based on data accessed
- Default allow traffic until determined to be an issue
- Assume multiple compromised endpoints exist on the network at all times
- All endpoints must have their own defenses (packet filtering, malware detection, minimal listening processes)
- IoT/embedded devices that can't be hardened must be isolated from general use
Segmentation stance:
- Effectiveness is inversely proportional to use-case diversity within a segment
- Network segmentation is appropriate for regulated data that excludes general use
- Micro-segmentation should be built into deployment workflows for all services
- Default for regulated data enclaves: deny all in/out
- Default for general use: minimal interference
Operations model:
- Device configuration managed by automation (Git-backed, templates + source of truth like Nautobot)
- Direct device access is least-privilege (default read-only)
- Internal open-source model — any engineer can contribute, network engineers peer-review
- Observability data accessible to all engineers
The strategy operates across four layers, each with distinct enforcement points:
graph LR
Identity[Identity Layer] --> Device[Device Layer] --> Network[Network Layer] --> Application[Application Layer]
| Layer | Question | Tools |
|---|---|---|
| Identity | Who are you? | Entra ID, Cloudflare One (WARP), EDNA, Conditional Access |
| Device | Is it managed and healthy? | Arista AGNI, CrowdStrike, Certificate Infrastructure |
| Network | Where does traffic go? | Arista MSS, Palo Alto Firewalls, VRF Segmentation |
| Application | What can you do? | Cloudflare WAF, BastionZero, Per-service controls |
| Tool | Role |
|---|---|
| Cloudflare One (WARP) | Identity-aware proxy; traffic egresses via Cloudflare, replacing VPN for most use cases |
| VPN | Supplements Cloudflare One for legacy/complex environments |
| Cloudflare WAF | DoS and exploit protection for public-facing websites |
| BastionZero | Zero trust infrastructure access (SSH/RDP replacement) — under evaluation |
| Microsoft Entra ID | Conditional access policy enforcement at the IdP layer |
| EDNA | Authoritative identity/group source; manages Cloudflare users/groups via RMI + Terraform |
EDNA integration model:
- Auto-subscription (existing EDNA groups) for broad populations; manual subscription for specialized use cases
- Cloudflare service support in the EDNA Terraform Provider for IaC-based provisioning
- Outstanding: Gateway groups RMI (tunnel access), "any valid ASU user" group feasibility
Split AuthN/AuthZ: Authentication (who are you?) is separated from authorization (what can you access?), enabling composable trust decisions from multiple signals — device posture, identity-aware proxy status, network location, compliance state.
Arista AGNI — replacing Cisco ISE as the NAC solution for wired and wireless access.
- Certificate-based authentication — a stolen password no longer grants network access
- Policy-driven VLAN assignment based on certificate attributes (org unit, device type, management status)
- CMMC Level 2 capable — granular enforcement via device certificate attribute model (MTW proving this)
- Phased rollout: ET-managed → business units on ET platform → business units off-platform → BYOD → ISE retirement
Current state: ~220 active connections on asu-internal (ET dogfood), MTW onboarding in progress, ~14,947 devices in scope for broader rollout.
Certificate infrastructure:
- Certificate Subject CN format:
MTW-SWAP-Private(KE team recommendation) - Issuing CA: ASU Issuing CA03 (rebuilt post-vulnerability)
- GPO scoped to all of UTO; SCCM client certs use fully distinguished names
- Blocker: ADCS connector installation requires terminal server provisioning
CrowdStrike — deployed as EDR; gates BYOD WARP access. Not yet wired into network-layer access decisions.
Arista Multi-Domain Segmentation (MSS):
- Policy-driven Zero Trust zoning across VRFs/VLANs without firewall sprawl
- East-West firewall rules shared with Arista for Border B prototyping (7280 platform)
- POC at CXFEL: 7280 switches connecting BDC to ISTB1 over direct fiber; MSS ZTX appliance on loan; monitoring-only testing phase
- NDR: replacing Gigamon with Arista DCS-7280CR3 (DANZ) for East-West visibility
Palo Alto firewalls:
- Automation project kicked off to align configuration management to DevOps practices
- Ownership under discussion (Network Engineering product, NOC service)
VRF management:
- Isolated VRF for Cloudflare testing account (IM/Skysong)
- VRF audit/consolidation proposed, not started
Connectivity:
- AWS Direct Connect to Cloudflare at Equinix DC2 and CoreSite VA1 (IAD)
- CNI egress + WARP performance issue unresolved — Cloudflare recommends ASU-border egress, conflicting with desired architecture
DNS-layer protection: Proposed switch of asu-guest to Cloudflare malware-blocking resolver (1.1.1.2 / 1.0.0.2).
SOC operations (BLAST):
- Two-analyst sign-off now required for domain blocks (post-backblaze incident)
- AI-assisted block-decision logic under evaluation (Google SecOps)
- Legacy firewall audit: 31 devices with SNMPv3 exposed to internet (contractor equipment)
Per the Network Principles: each service owns its own security. The network provides transport, not application-layer protection. Additional controls:
- Cloudflare WAF for public-facing web applications
- BastionZero for infrastructure access (under evaluation)
- Per-service firewalling (e.g., Appsian for PeopleSoft, AWS security groups per-service)
| Framework | Scope | Status | Reference |
|---|---|---|---|
| CMMC Level 1 (15 controls) | University-wide baseline | Aligned | FAR 52.204-21 |
| CMMC Level 2 (110 controls) | Research environments with CUI (MTW first) | In progress via AGNI device attribute model | NIST SP 800-171 Rev 2 |
| FedRAMP Moderate | Cloudflare services handling controlled data | Quote in progress (Cloudflare/MicroAge) |
| # | Item | Status | Detail |
|---|---|---|---|
| 1 | ASU Network Principles — re-validate/adopt | 🔄 In progress | Chris proposed in #isawg-trustbased (Jul 7). Document is substantive and aligned; needs formal re-adoption with current technology examples. |
| 2 | Trust signal taxonomy and scoring model | ❓ No progress | No owner assigned. Foundational to the conditional access model. |
| 3 | Entra ID conditional access scope | ❓ No progress | May be tracked in Jira/Confluence. |
| 4 | Cloudflare CNI egress + WARP performance | 🔴 Blocked | Jun 25 support call unproductive. Architectural decision needed: Cloudflare egress vs ASU border. |
| 5 | EDNA RMI for Cloudflare Gateway groups | 🔄 Open | Access groups RMI done; Gateway groups outstanding since Mar 2025. |
| 6 | "Any valid ASU user" WARP group feasibility | 🔄 In discussion | No resolution as of May 2025. |
| 7 | PA firewall automation | 🔄 Started, blocked | Ownership dispute unresolved. Jeff Williams not engaged. Lab PA440s being located. |
| 8 | VRF audit/consolidation | 🔄 Proposed | Adrian proposed Jul 14; no formal audit started. |
| 9 | MSS ZTX appliance purchase | 🔄 Pending PO | Quote requested, EVP funds available. |
| 10 | MSS proof of value (CXFEL) | 🔄 Pending | Monitoring-only testing agreed. No formal document. |
| 11 | NDR — Gigamon replacement | ✅ Resolved | Arista DCS-7280CR3 (DANZ). BOM finalized; decommission scoped. |
| 12 | ADCS connector for AGNI certs | 🔄 Blocked | Depends on terminal server build (Torey). Milestone 3 dependency. |
| 13 | AGNI production licensing | 🔄 Pending quote | James Celmer assigned (Jun 22). |
| 14 | FedRAMP Moderate quote | 🔄 Unclear | Quote requested Apr 2025. Unclear if folded into Phase 2. |
AGNI proves device identity and managed status. CrowdStrike is deployed. But runtime health signals (patch level, disk encryption, active threats) do not feed into network access decisions. A compromised-but-managed device still gets full network access.
Trust decisions are point-in-time. No mechanism re-checks trust signals mid-session to step up or revoke access when posture degrades. A device that loses compliance after connecting remains connected.
The Network Principles reference a Data Classification Standard as the driver for segmentation decisions. This standard is not linked or included in current strategy materials. Without it, segmentation decisions are ad-hoc.
EDNA is the authoritative identity source. The Cloudflare Terraform provider enables IaC provisioning. But no unified policy layer spans all enforcement points (Cloudflare, AGNI, MSS, Entra ID). A group membership revocation in EDNA may not propagate to network-layer decisions in real time.
The Network Principles call host-based firewalling "more effective" than network segmentation for mobile devices. No evidence this is enforced or measured today.
The Network Principles reference IPv6 ND for global unicast addresses. Unclear if the current stack (Cloudflare One, AGNI, MSS) fully supports dual-stack operation.
The Network Principles state specific criteria should determine when an endpoint loses Internet access. These criteria are not formally defined. The BLAST/SOC improvements are adjacent but don't constitute a specification.
No centralized access-decision logging or anomaly detection across the combined stack. Required for incident response and compliance evidence. The Gigamon outage demonstrated that silent observability failures go undetected.
As traffic flows shift from ASU border to Cloudflare egress, the SOC needs updated tooling and context to make informed block decisions. The BLAST incident exposed this gap.
- Cloudflare One: which populations move from VPN first? VPN deprecation timeline?
asu-guestretirement is in AGNI milestones 5–9 but has no timeline- Legacy systems that can't participate in certificate auth or conditional access need a defined path
- Resiliency: Cloudflare PHX maintenance raised failover questions not fully resolved