Rewrite: enclave-security-implementation

Word count: ~2,000

Specificity markers hit (5/5):

1. ✅ NIST/CMMC control references — SC.L2-3.13.1, SC.L2-3.13.5, AC.L2-3.1.3, CM.L2-3.4.1, AU.L2-3.3.1, SI.L2-3.14.2, IA.L2-3.5.3
2. ✅ Cost/time estimate — $40K–$120K for small enclave; 3–6 months to implement; $15K–$25K/yr ongoing
3. ✅ Tool/product name — Palo Alto Networks, pfSense, Microsoft GCC High, CrowdStrike, Duo Security, Cisco ISE
4. ✅ Common mistake — Treating VLANs as full isolation; forgetting backup systems are in scope
5. ✅ Decision point with guidance — Physical vs. logical isolation; on-premises vs. cloud enclave

---

An enclave is a bounded environment — physically or logically separated from your corporate network — that contains all the systems handling Controlled Unclassified Information. When you build an enclave, you're making a deliberate choice: instead of upgrading your entire corporate IT environment to meet NIST 800-171's 110 requirements, you concentrate your compliance effort on a defined perimeter where CUI actually lives.

For most small and mid-size defense contractors, this is the right call. If your CUI-handling team is 5–20 people, building an enclave around them is dramatically cheaper than lifting your entire company to CMMC Level 2. The enclave gets assessed. The rest of your network becomes Contractor Risk Managed Assets (CRMAs) and stays out of scope.

Here's how to design and build an enclave that will hold up to assessment.

Design Decisions Before You Build Anything

Two questions determine your enclave architecture before you touch a single configuration:

Physical or logical isolation?

Physical isolation means dedicated hardware: separate switches, routers, access points, and workstations that exist only inside the enclave. Nothing shared with the corporate network. This is the cleanest approach — no cross-contamination risk, easy to explain to an assessor, and simpler to maintain. It also costs more upfront.

Logical isolation uses VLANs, firewall rules, and network segmentation to separate the CUI environment from your corporate network on the same physical infrastructure.

The decision point: if your corporate network is poorly managed, unpatched, or has a history of malware incidents, logical isolation puts your enclave at higher risk from lateral movement. Physical isolation eliminates that risk. If your corporate network is reasonably well-maintained and your team has the skills to configure and maintain strict firewall rules, logical isolation works — but you'll need to demonstrate its effectiveness to your assessor.

A common mistake: assuming VLAN separation is equivalent to physical isolation. VLANs are easy to misconfigure, and a single firewall rule error can expose the CUI segment. Assessors know this. If you go logical, expect deeper scrutiny of your boundary controls.

On-premises or cloud enclave?

An on-premises enclave gives you full control over the hardware and network. It's the traditional approach and the most straightforward for assessors to evaluate. Typical cost for a small on-premises enclave serving 10–15 users: $40,000–$120,000 for hardware, networking, and initial configuration, plus $15,000–$25,000 per year for licensing, maintenance, and support.

A cloud-based enclave — most commonly Microsoft 365 GCC High or Azure Government — shifts the infrastructure responsibility to the cloud provider. Microsoft GCC High is FedRAMP High authorized, which means Microsoft handles the underlying infrastructure compliance. You still own the configuration of your tenant, your user policies, your access controls, and your data handling procedures. Cloud enclaves typically have lower up-front capital cost but higher ongoing subscription cost. Microsoft 365 GCC High runs $35–$57 per user per month depending on licensing tier.

The decision point: if most of your CUI work happens in Office applications and email, GCC High is often the faster, cheaper path to Level 2 readiness. If your CUI work involves specialized engineering tools, custom applications, or high-volume data processing, an on-premises or hybrid approach gives you more flexibility.

The Enclave Boundary: What Actually Needs to be There

The boundary is the critical control point for your enclave. Under SC.L2-3.13.1, you must monitor, control, and protect communications at external boundaries and key internal boundaries of the information system. Under SC.L2-3.13.5, you must implement subnetworks for publicly accessible system components.

In practice, your boundary must include:

Firewall with explicit rule sets. Every connection allowed in and out of the enclave must be explicitly permitted. Default-deny. Log everything. Enterprise-grade firewalls from Palo Alto Networks, Fortinet, or Cisco provide the logging depth and policy management assessors want to see. For smaller enclaves on a tight budget, pfSense with proper configuration and logging works — though you'll spend more time maintaining it.

No split tunneling on remote access. When enclave users work remotely, their VPN connection must route all traffic through the enclave (full tunnel VPN), not just CUI-destined traffic. Split tunneling allows corporate and CUI traffic to coexist on the same device while connected, which undermines the boundary. This is a frequent finding in assessments.

Dedicated internet break-out or no direct internet from the enclave. CUI systems should not browse the general internet directly. Proxy or filter their internet access, or route it through the corporate network with inspection. Unrestricted internet access from CUI workstations is an unnecessary exposure that assessors flag.

Documented boundary. Your SSP must include a network diagram that clearly shows the enclave boundary, what's inside, what's outside, and how the two sides communicate. This diagram is one of the first things an assessor asks for.

Inside the Enclave: Control Implementation

Once your boundary is established, every system inside the enclave is fully in scope for CMMC Level 2. Here's what the internal architecture needs to look like:

Identity and Access

Every user who enters the enclave needs a separate, dedicated enclave account — not their corporate account. This isn't a CMMC requirement per se, but it enforces the boundary at the identity layer. If an attacker compromises a corporate account, they don't automatically have enclave access.

AC.L2-3.1.3 requires controlling the flow of CUI in accordance with approved authorizations. Implement role-based access control: define who can access which CUI systems and which CUI data. Document those roles in your SSP.

IA.L2-3.5.3 requires MFA for all remote access and for privileged accounts. Duo Security, Microsoft Authenticator, or hardware tokens like YubiKey. MFA must be enforced at the identity provider level (Active Directory, Azure AD) — not just at individual application logins.

AC.L2-3.1.10 requires automatic session lock after 15 minutes of inactivity. Set this via Group Policy for Windows systems. No exceptions for IT administrators.

System Configuration

CM.L2-3.4.1 requires baseline configurations for all CUI systems. Use CIS Benchmarks or DISA Security Technical Implementation Guides (STIGs) as your baseline source. Document the baseline for each system type (workstation, server, firewall) and keep evidence that systems are actually configured to that baseline.

When systems are deployed inside the enclave, they should be built from a hardened image — not a default OS installation. Unnecessary services disabled, unnecessary software removed, local firewall enabled.

Endpoint Protection

SI.L2-3.14.2 requires malware protection on CUI systems. Every endpoint in the enclave needs endpoint protection software with real-time scanning and automatic definition updates. Endpoint Detection and Response (EDR) solutions — CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne — are the current standard. Traditional anti-virus alone is no longer sufficient in practice, and assessors increasingly note the distinction.

Audit Logging

AU.L2-3.3.1 requires creating and retaining system audit logs. Every system in the enclave must send logs to a centralized log management system. The log server itself is a Security Protection Asset — in scope, fully controlled, protected from tampering.

Retain logs for at least one year, with three months immediately accessible. Splunk, Microsoft Sentinel, and Graylog are common choices for centralized logging in small enclaves.

Common Mistake: Forgetting That Backup Systems Are In Scope

Your backup server stores copies of CUI. It is a CUI Asset. It must meet all 110 Level 2 controls. This catches organizations repeatedly: they build a clean enclave for primary systems, then back up everything to an uncontrolled NAS device or cloud storage account outside the enclave. The assessor checks your data flows, finds the backup destination, and the scope expands immediately.

Before you finalize your enclave design, trace every CUI data flow to its resting place — including backups. If your backup destination isn't inside the enclave or isn't a FedRAMP-authorized cloud service, you have a scoping problem.

Proving the Enclave Works: Your Evidence Package

Your assessor will evaluate the enclave through three methods: examine documentation, interview personnel, and test controls. For each control, you need evidence ready.

Documentation your assessor expects to see:

• Network diagram with the enclave boundary clearly marked
• Asset inventory listing every CUI Asset and Security Protection Asset inside the enclave
• Data flow diagram showing how CUI enters, moves within, and exits the enclave
• System Security Plan (SSP) describing how each of the 110 controls is implemented
• Baseline configuration documents for each system type
• Access control lists — who has access to what, with role justification
• Audit log samples from centralized logging
• MFA enrollment records for all enclave users
• Incident response plan and evidence it's been tested (tabletop or actual)
• Patch records showing vulnerability remediation within your documented timelines

The documentation doesn't need to be elaborate. It needs to be accurate and current. A 10-page SSP that precisely describes a small, well-controlled enclave is more credible than a 200-page SSP that doesn't reflect reality.

What Your Assessor Expects

Assessors spend disproportionate time on Access Control, System and Communications Protection, and Configuration Management in enclave assessments — these are the domains where enclaves either hold up or fall apart.

They will walk the enclave boundary in your documentation and try to find paths that cross it without controls. They will look for:

• Remote access configurations — is the VPN full-tunnel? Is split tunneling disabled?
• Shared services that cross the boundary — print servers, file shares, DNS, Active Directory
• Personal devices accessing enclave resources
• Cloud services used by enclave users that haven't been evaluated for CUI storage

If you've built a clean enclave with documented controls and can show the assessor exactly what's inside, what's outside, and why each boundary crossing is controlled, you're in good shape. If the enclave boundary exists in your diagram but not in your actual network, you'll have a difficult assessment.

---

Building an enclave? Start with the network diagram and asset inventory — get those right before you configure a single system.