/find@mail

Articles, write-ups, and musings concerning the world of cybersecurity and technology.

Cloud for a Defense Contractor: Hybrid Hosting for CUI

Simulated Case Studies  · 1,493 words · 7 min read · by QiO:~$ ·

Cloud for a Defense Contractor: Hybrid Hosting for CUI

Disclosure: This post uses a fictional company, "XYZ Systems" (XYZ), as a vehicle for exploring a real question: how should a defense contractor that handles Controlled Unclassified Information think about moving to the cloud? The company and its setup are invented for illustration. The regulations and technologies discussed are real. The hypothetical is a way to learn from, not a description of any actual organization.

Moving to the cloud is easy to justify and hard to do safely when the files you hold are controlled by federal regulations. Here's how a defense contractor might split the difference.

The Company and the Constraint

XYZ is a hypothetical U.S. Department of War contractor specializing in GPS and guidance hardware and software for kinetic weapons systems. As a government contractor that handles Controlled Unclassified Information (CUI), it is required to be NIST SP 800-171 compliant and to demonstrate ongoing cybersecurity process maturity under the Cybersecurity Maturity Model Certification (CMMC). With this in mind, when examining cloud models and solutions, it is important to remember that information security is at the forefront of the mission. A cloud implementation that does not provide security and maintain compliance will not support the mission.

Why Consider the Cloud?

Cloud computing offers many benefits but also comes with some risks. For example, a cloud solution allowing a company like XYZ to use a web application that provides document creation and cloud storage could provide a replacement for its current on-premises servers, which are nearing end-of-life. This would also mean data could be accessed remotely with greater ease, and with less risk to the internal network. Such a solution would also shift much of the day-to-day responsibility for data availability to the cloud provider.

As noted, cloud computing comes with some risks. Exposing a cloud-based application to the internet also exposes it to attack. Proper application security, configuration, and authentication methods such as multi-factor authentication will be key to mitigating these risks. Additionally, the data will be at rest on external third-party servers, and it will traverse the internet when accessed. This means XYZ cannot ultimately control the security of the facility, network, or physical servers where its data exists. To mitigate these risks, it will be critical that data is encrypted at rest and in transit.

The Service Models

There are many popular cloud service models available. Infrastructure as a Service (IaaS) would provide the underlying computing, storage, and networking resources (usually virtualized), allowing a company to build out a full cloud system. In this model, the customer handles every software aspect of the cloud servers, including the operating system, applications, networking configuration, and security.

Platform as a Service, or PaaS, is a model where the cloud provider includes both the physical hardware and the operating system or software platform on which applications can be run. In this model, selected cloud applications can be launched and administered without the added task of configuring the base operating system or networking.

Software as a Service, or SaaS, is by far the most popular cloud computing model today. Web-based services like Salesforce, Google Workspace, or QuickBooks Online are excellent examples of this model. When using Software as a Service, the cloud provider is responsible for almost everything. They provide the hardware and infrastructure, the operating system and application software, and they deliver an application that is ready to be used by the customer. Under this model, the customer administers the application and provides security through proper configuration of authentication and access policies.

A Proposed Approach: Cloud Collaboration Plus an On-Premises CUI Enclave

One option for XYZ is a SaaS-style model to replace its general-purpose business suite hosting. Employees currently create documents locally and store them on network drives. Moving to a collaboration platform such as Nextcloud would offer several advantages. The application would provide a single interface for document creation, as well as storage and sharing. It offers rich features and role-based access controls to ensure security. Multi-factor authentication is also available for the web application itself. This would allow employees to work remotely without having to use RDP or a VPN to access the local network.

The obvious question is how to protect CUI, and that is a valid one. For this, a hybrid-cloud setup could be used. In this implementation, XYZ would run a small on-premises instance of Nextcloud on which its encrypted CUI lives. Using a federated cloud and proper DNS configuration (for example, split-horizon DNS and firewall rules so the CUI server is only reachable from inside), access to the CUI paths could be restricted from the remote web application, requiring users to be on premises to interact with that data. This model would allow XYZ to offload the bulk of everyday use to a web application while preserving the availability and confidentiality of CUI for the smaller segment of employees who must access it.

Risks and Controls

The risks of such an implementation are not negligible. The web application itself presents a large attack surface, and administrative configuration errors can make this problem even worse. Multi-factor authentication must be required, as well as strong password requirements and login attempt lockouts to limit brute force attacks. Furthermore, zero trust must be implemented correctly within both the remote and on-premises applications. To ensure these risks are under control, penetration testing by an internal red team and/or third-party contractors will be crucial. This will help ensure the external security of the web application, as well as help validate the zero-trust implementation within the hybrid cloud. A simulated breach of the web application can test whether CUI is reachable on the internal federated server. Beyond this, the hybrid cloud system should undergo regular auditing and risk assessment, and be monitored by the information security team like any other system, including threat hunting.

What a Real Plan Would Also Need

A design like this raises questions that the high-level picture glosses over. These are the ones worth asking first:

  • FedRAMP for anything that touches CUI. Under the DFARS safeguarding clause, an external cloud provider that stores, processes, or transmits covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline, and the contractor must report cyber incidents within 72 hours. That is a big reason this design keeps CUI on premises. But it only works if CUI stays out of the cloud tenant, which takes data classification, marking, and controls that stop someone from uploading a CUI file to the wrong place. If the cloud service also handles authentication for the on-premises server, it may be pulled into scope anyway.
  • "SaaS" may not be the right word. Nextcloud Enterprise is self-hosted software with a support subscription, not a hosted service. If XYZ runs it themselves, the company is back to running IaaS-style infrastructure: patching, hardening, backups, and monitoring are all theirs. A true SaaS version would mean using a hosting provider, and then the FedRAMP question applies to that provider if CUI is involved.
  • "Shifting responsibility" has limits. The provider can take on availability of the platform, but the customer still owns its data, its identities, and its configuration. Most SaaS breaches trace back to those.
  • Encryption must be validated, not just strong. NIST SP 800-171 requirement 3.13.11 calls for FIPS-validated cryptography when protecting the confidentiality of CUI. "We use AES" is not enough; the cryptographic module has to be validated.
  • Mind the version. CMMC Level 2 maps to NIST SP 800-171 Revision 2 (110 requirements), even though Revision 3 has been published. As of this writing the Department has also paused CMMC's second implementation phase while enforcing Rev 2 through self-assessments, so check the current status before planning.

Conclusion

In conclusion, this approach would offer many advantages, like cost savings on equipment and maintenance, ease of remote access, better scalability, and a single federated platform for document creation and storage. Risks can be mitigated through proper configuration of security protocols and networking, while protecting access and availability to CUI. The details above, especially FedRAMP scoping, FIPS-validated encryption, and who really runs the software, are what decide whether it works in practice.

The Takeaway

The smartest part of this design is a simple idea: don't put the crown jewels where you can't control the walls. Splitting everyday collaboration from regulated data lets a company enjoy the cloud's convenience without handing it the most sensitive files. But a good architecture on paper is not a compliant one. The hard work is proving that the boundary holds: that CUI never wanders out, that the encryption is the validated kind, and that someone owns every patch.

Sources

Read next

Field Notes: From Service Version to a Working Exploit