Raising the Bar, Part Three: The Boundary Is Where CORA Gets Serious

CORA doesn’t give credit for having the right architecture. It gives credit for maintaining it correctly, continuously. 

Parts one and two of this series made the case for Insider Risk — why CORA demands more than passive monitoring, why multi-domain visibility matters, and why the evidence portfolio an assessor expects to see has to be built before the assessment is scheduled. 

This blog covers different ground. CORA is not exclusively an Insider Risk audit. It is, at its core, a boundary security assessment. And four Everfox solutions sit precisely at that boundary: Trusted Thin Client (TTC), the Garrison Isolation Appliance (GIA), Cross Domain Solutions (CDS), and Content Disarm and Reconstruction (CDR). All four are squarely within what CORA evaluates, continuously, under a framework that has been tightening since its predecessor first named CDS as an explicit scored risk indicator. 

CORA is asking four questions about every boundary. How do users access other domains? How do they interact with potentially hostile environments? What information must cross between domains? And is that information actually safe to receive? Access. Isolate. Control. Sanitize. Everfox has a specific answer to each. 

The Boundary Is the Audit 

Joint Force Headquarters Department of War Information Network (JFHQ-DODIN) has been explicit. CORA is hyper-focused on securing the boundary. That boundary consists of network perimeter devices, public and Department of War (DoW)-facing assets, and any information system with a direct interface to an external network. The boundary review measures the cyber-hardening risk of systems exposed to the public internet and the risk that malicious activity could propagate to other DoW components if a boundary system is compromised. 

That description is not pointing at something adjacent to Cross Domain Solutions. It is pointing directly at all the categories of them. 

Every CDS, whether it provides access across domains or transfers data between them, is a controlled interface between security environments. Access CDS provides users with controlled access to computing resources in other security domains without transferring data between them. Transfer CDS enables data movement between domains with content filtering applied at the crossing point. Different architectures, different risk profiles, both definitionally within CORA’s boundary review scope. 

DISA publishes Security Technical Implementation Guides (STIGs) for CDS products. CORA can assess any technology for which STIGs exist. Those STIGs exist, which means CDS across both categories is CORA-assessable on any network CORA inspects. Site compliance visits for CDS deployments are conducted during Command Cyber Operational Readiness Inspections, the direct lineage into CORA. The boundary review is, structurally, an audit of exactly the systems CDS comprises. 

Cross Domain Access 

Start with access itself because this is where CORA’s attack surface language is most directly applicable, and where most organizations carry the most unexamined exposure. 

When users need to reach multiple classified networks, the traditional answer is multiple physical workstations: one for NIPR, one for SIPR, one for JWICS. Every additional machine is an additional endpoint that must be enrolled in comply-to-connect under OPORD 8600-25 Pillar 4, STIG-hardened and continuously verified under CORA’s Key Indicators of Risk (KIORs), monitored for anomalous behavior, and kept current on patches. JFHQ-DODIN’s stated purpose for CORA is to reduce the attack surface of cyber terrain. Every unnecessary endpoint is terrain. 

TTC changes the architecture. It grants authorized users access to multiple classification levels from a single device through virtualized remote sessions. The endpoint is read-only, no data from any accessed domain is stored locally, and nothing can be transferred to or from the endpoint itself. One accredited device replaces the stack of workstations that previously represented each network on a user’s desk. 

The CORA connection runs directly through the attack surface reduction mandate. Fewer endpoints means fewer devices requiring STIG hardening, comply-to-connect enrollment, patch currency verification, and anomaly monitoring. The total cyber terrain shrinks. Beyond the infrastructure reduction, TTC enforces access control at the domain boundary. Lt. Gen. Skinner named access control explicitly as one of the risk factors CORA fuses in every assessment and the read-only, no-local-storage architecture directly addresses the insider threat and exfiltration KIORs. A user cannot exfiltrate data from an accessed domain via removable media or local storage because nothing from that session ever resided on the endpoint to begin with. 

TTC is on the NCDSMO Cross Domain Baseline at both TSABI (Top Secret/SCI and Below Interoperability) and SABI (Secret and Below Interoperability) levels and is the widest deployed Access CDS across the DoD, Intelligence Community (IC), and civilian federal government. It operates under ITAR controls, which governs where and how it can be deployed. 

Hardware-Enforced Isolation 

TTC addresses multi-classification access for domestic and ITAR-eligible environments. For coalition operations, partner nation deployments, and environments where ITAR restrictions preclude TTC, GIA provides the same single-device multi-classification access capability without ITAR constraints. 

GIA also extends the Access CDS model to cover a problem TTC does not: browse-down to untrusted and internet-facing environments. A user on a classified network who needs to reach external websites, cloud services, or contractor portals faces a fundamentally different risk profile than a user accessing another classified environment. The public internet is adversary terrain. CORA’s KIOR framework weights initial access as the highest-risk exposure category, and web content is one of the most heavily weaponized initial access vectors in the MITRE ATT&CK framework. 

GIA addresses this through hardware-enforced pixel-stream rendering. Web sessions and remote sessions execute in a hardware-isolated environment; only raw pixel streams reach the user’s display. Keyboard and mouse commands traverse to the remote session, nothing else comes back. No code from the accessed environment executes on the protected endpoint. There is no data path from the session back to the classified network. A compromised website, a weaponized document, a drive-by exploit, none of these have a path to the classified environment because the endpoint never directly interacted with them. The isolation is enforced in hardware before any session content crosses the boundary. 

This maps directly to OPORD 8600-25 Pillar 1 through application control and deny-by-default posture enforced at the hardware level. Pillar 4’s asset visibility and comply-to-connect requirements apply to GIA as a network appliance. GIA can be deployed alongside TTC within the same endpoint architecture, extending hardware-enforced isolation to the same consolidated infrastructure and doing so in environments where TTC’s ITAR constraints would otherwise leave the access problem unsolved. 

Cross Domain Transfer 

Some information must actually move between domains. Access CDS and hardware-enforced isolation are boundary architectures that keep domains separated while giving users what they need. When the mission requires data to cross a classification boundary, transfer controls take over. 

Cross Domain Transfer establishes deliberate, policy-driven pathways where data is inspected, validated, filtered, and moved according to defined rules. Rather than broad connectivity between environments, each crossing is an enforcement point. That applies across classified and unclassified networks, coalition and partner environments, operational and enterprise, and air-gapped networks receiving external data. 

The CORA connection runs through lateral movement KIORs. Once an adversary compromises one environment, Transfer CDS governs the mission-critical pathways connecting it to others ensuring those pathways are enforcement points rather than exploit opportunities. Post-accreditation compliance visits for CDS sites were conducted as Command Cyber Operational Readiness Inspections under the predecessor program. CORA inherits that scope. A Transfer CDS deployment is within CORA’s assessment boundary on day one, and on every assessment day thereafter. 

Content Disarm and Reconstruction 

The transfer pathway can be policy-enforced. The sender can be authorized. The file can still be hostile. 

Traditional boundary security asks whether it can detect a malicious file. CDR changes the question entirely: why should any file be trusted when it crosses a domain boundary? 

CDR deconstructs every file to its structural components, validates each component against the known-good schema for that file type, strips anything that does not conform, and reconstructs a verified copy before the file crosses the boundary. The file that arrives on the high side is not the file that was submitted. It is a verified reconstruction. A zero-day embedded in a document is not something CDR needs to identify — it is eliminated in the reconstruction, because CDR discards everything except what is verifiably conformant to the file type’s legitimate structure. 

The policy basis is explicit. The NCDSMO Raise the Bar (RTB) program, made mandatory by NSM-8 in January 2022 for any CDS connected to a National Security System, requires three independent verification mechanisms per file crossing a domain boundary, the Rule of Three. CDR is the technical mechanism that satisfies that requirement architecturally. 

JFHQ-DODIN leadership has described CORA’s agility in terms of addressing vulnerabilities not yet known to exist and already being exploited. CDR’s transform-not-detect model is built for exactly that environment. OPORD 8600-25 Pillar 2 covers DLP across all three data states: at rest, in transit, and in use. CDR operates at the Transfer CDS point, data in transit at the moment of domain crossing. Among the four OPORD pillars, DLP carries the largest documented gaps across DoW organizations. CDR at the transfer boundary is the most architecturally defensible answer to that gap. 

Don’t just inspect what enters the boundary. Rebuild it. 

“We Have It Deployed” Is Not the End of the Story 

This is the part of the CORA conversation most organizations are not having. 

CORA’s shift from point-in-time inspection to continuous assessment means that deploying Access CDS, hardware-enforced isolation, Transfer CDS, or CDR is the beginning of the compliance story, not the end. The CSIAC documentation is explicit: CDS must be patched regularly, actively maintained, and enhanced to address new threats and component obsolescence. Every CDS deployment must be monitored and defended with an active defensive cyberspace operations capability. 

That requirement is not new. What is new is that CORA enforces it continuously. The old model allowed organizations to prepare for a scheduled inspection and return to a maintenance posture until the next cycle. CORA’s risk-based model means some organizations face assessment multiple times in a year. There is no preparation window. 

Any boundary control misconfigured, unpatched, or operating outside its accreditation boundary is a high-risk indicator under CORA’s KIORs regardless of category. CORA does not give credit for having it. It gives credit for having it correctly maintained and current on the day assessors arrive, which could be any day. 

Ready to Examine What You Have at the Boundary? 

CORA helps identify where your cyber terrain is operationally exposed. Everfox provides the controls that close those gaps: secure access when users need to reach multiple domains, hardware isolation when the destination itself presents risk or ITAR constraints preclude standard Access CDS, controlled transfer when data must move, and content reconstruction when the content itself cannot be trusted. 

If your organization operates cross-domain infrastructure, the CORA conversation about that infrastructure is already overdue. Everfox works with defense and intelligence organizations to assess cross-domain architecture against current CORA requirements, close configuration and maintenance gaps, and build the documentation trail an assessor expects to see. 

The boundary is where CORA gets serious. It is also where Everfox is purpose-built to operate. 

This is part of a continuing series. There’s more to come. 

Everfox provides Cross Domain Solutions, Content Disarm and Reconstruction, the Garrison Isolation Appliance, Trusted Thin Client, and Insider Risk Management capabilities purpose-built for the defense and intelligence communities.