CMMC, CUI, and Cloud Vendors – do you need FedRAMP?

Achieving Cloud Compliance in the Age of CMMC, CUI, and DFARS 7012: How secure are your cloud vendors?

Amira Armond is a CMMC Provisional Instructor, Provisional Assessor, CISSP, and CISA. She is the owner and Quality Manager for Kieri Solutions, an authorized C3PAO offering assessments, CMMC preparation services, and the Kieri Compliance Documentation package . Amira Armond is the chief editor for CMMCaudit.org and volunteers with the C3PAO Stakeholder Forum, an industry group striving for consistency of interpretation and successful rollout of the CMMC program.

Disclaimer: This is my best explanation of how I understand the topic (and I’ve done a LOT of research), but this is a free article so I’m not giving you any guarantees or assurances that it is 100% correct. Talk to your cyber security professional, your lawyer, and your DoD contract officer if you want an official opinion.

Client selection of cloud vendors, particularly for CMMC level 2 and above, is a big topic of misunderstanding that many companies struggle with.

Vendors (not just clouds) introduce cybersecurity risk

Cyber-adversaries have been increasingly using the trust between organizations and their vendors to attack networks.

In 2017 (during the first Russo-Ukrainian war) , Ukraine’s most popular accounting and tax filing program “MeDoc” pushed an update which had been sabotaged to include ransomware. An estimated 80% of Ukrainian firms were using this software.

More recently, (February 2020), the FBI issued an alert warning that hackers were attempting to infect supply chain software providers in order to gain access to strategic partners and/or customers, including Industrial Control Systems.

And an update from July 2021 – hundreds of Managed Service Providers were hit with ransomware after they downloaded a malicious update from Kaseya, whose patch server had been compromised by cyber criminals.

OK, we are convinced about vendor risk, but what does that have to do with clouds?

Is ______ a cloud?

NIST defines cloud computing very carefully in NIST SP 800-145. This is an important reference for defense contractors, especially in relation to FedRAMP requirements. However, for the purposes of most of this article, if you are using information technology residing on a network infrastructure that your company doesn’t own or control, we will call it a cloud.

Simple cloud examples

Google Drive – stores and transmits data between your PC and others. The network infrastructure is owned and operated by Google. Clients can manage their subscription via Google’s website.

Quickbooks Online – processes, stores, and transmits data that you enter to the website. The network infrastructure is owned and operated by Intuit. Clients can manage their subscription via the website.

Amazon Web Services – processes, stores, and transmits data that you upload or configure. The network infrastructure is owned and operated by Amazon. Clients can manage their subscription via AWS’s website.

WordPress.com – processes, stores, and transmits data that you enter to your website. The network infrastructure is owned and operated by WordPress.com. Clients can manage their subscription via WordPress’s website.

Less obvious clouds

More and more products and services are adding a cloud component for central management and updates. This means you need to consider them a cloud product because the back-end infrastructure is outside your company. In some cases, the cloud provider can even connect to your purchased devices without your knowledge and have direct access to your corporate network.

Tip: If you need to pay an ongoing subscription fee for access, it is probably a cloud.

Tip: If you can manage your systems using the vendor’s website, it is probably a cloud.

Rapid7 – (leader in vulnerability management). Processes, stores, and transmits data from software agents installed on workstations and servers. When you install the agents on your computers, the agents establish an always-on connection to Rapid7’s network infrastructure for central management. Clients manage their agent settings and subscription via Rapid7’s website.

Datto – (a leading backup provider). Provides physical appliances for on-premises backups. Processes, stores, and transmits data from the physical appliances. The appliances establish connections to Datto’s network infrastructure and can be directly managed by Datto staff. Clients manage their backups and remote-connect to their appliances via Datto’s website.

zScaler – (a leading mobile device security provider). Processes, stores, and transmits data from software agents installed on mobile devices. When you install the agents on your computers, the agents establish a connection to zScaler’s network infrastructure for central management. Clients manage their agent settings and subscription via zScalers’s website.

Many Internet of Things (IoT) devices also count as clouds. If the IoT device can be managed via the vendor’s website or transmits data to the vendor for central management or reporting, it is a cloud.

“Non-cloud” products and vendors

Some products are not considered clouds by most experts, but they still introduce supply chain risk.

The main risk is products that automatically connect to their vendor to download and install updates.

Technically, any time you download a patch, firmware update, or new version of software from a vendor, you are adding supply chain risk. But since the risk of un-patched products is generally way higher than the risk of patching, we still need to patch.

A big example of this are on-premises antivirus products. For optimum protection, your antivirus should be downloading new malware signatures constantly. The risk is if the antivirus program gets a bad update, it could be used to attack your infrastructure. For example, if the antivirus is told that critical Windows files need to be quarantined, many of your servers and desktops could immediately crash.

Third Party Providers

Outsourcing IT operations and security is popular, especially with small and medium businesses, because it is a way to get high quality service at a lower price point. For example, I know of a SOC-as-a-Service company which offers incident management and auditing for $60/endpoint/year. Great value!

These third party services often count as “less obvious clouds”. They are people managing your network using infrastructure that you don’t own. Note that these smaller companies do not qualify as Cloud Service Providers according to the NIST Definition.

Here is the security problem:

• Many of these providers immediately open remote management links to your network (boundary control)
• They install remote management software on your devices (admin rights not controlled by you)
• They have passwords, network diagrams, and vulnerability info for your network (which could be stolen and used against you)
• Since it isn’t your company, their hiring practices, background checks, and internal controls are normally opaque (access management)
• Since they connect to many networks, they could encounter malware on one client then bring it to your network.

Do you trust the cloud?

Each time you install a cloud-managed device or service, you are essentially giving other people admin rights over your data access to your network.

The good news is that most cloud providers are very professional with highly trained staff. They almost certainly have more skilled admins than your company’s IT department.

The bad news is that cloud providers are targeted by very advanced hacking groups. If your cloud provider gets hacked or infiltrated, the criminals could steal your data or even use the trusted connections to your environment to take over your network. For an example, consider the U.S. Government ban on using Kaspersky antivirus because of concerns that the software was being used to steal data on behalf of Russia.

The Cybersecurity and Infrastructure Security Agency (CISA) warned that organizations need to understand the security of their vendors.

What does DFARS 252.204-7012 say about clouds?

First, DFARS 252.204-7012 references “external cloud service provider“. What is a cloud service provider according to the DoD? We have two potential sources of definition.

DFARS 252.239-7010 defines Cloud Computing

The definition of Cloud Computing in DFARS 252.239-7010 (which is referenced by 252.204-7012) states:

““Cloud computing” means a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This includes other commercial terms, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. It also includes commercial offerings for software-as-a-service, infrastructure-as-a-service, and platform-as-a-service.”

https://www.acq.osd.mil/dpap/dars/dfars/html/current/252239.htm#252.239-7010

NIST Special Publication 800-145 also defines Cloud Computing:

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment
models.
Essential Characteristics:
On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of
abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability1 at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.”

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

Those two definitions sound very similar don’t they? I think that this sets a high bar for what it takes to be an “external cloud service provider” according to the federal government and DoD. Just having your Managed Service Provider or a subcontractor host your server in their datacenter is not a cloud service provider according to these sources.

CUI? DFARS requires cloud vendor evaluation

The current Defense Federal Acquisition Regulation Supplement (DFARS) rule 252.204-7012 says that contractors are responsible for verifying security requirements for any external cloud service provider that processes, stores, or transmits their Controlled Unclassified Information (CUI).

If DFARS applies to your company, or you are a cyber-security pro, spend ten minutes and read the actual regulation. It is only three pages long. https://www.acq.osd.mil/dpap/dars/dfars/html/current/252204.htm#252.204-7012

Here is the key paragraph that I’m talking about with this blog:

Does your cloud “Store, Process, or Transmit” CUI?

Here are examples of each:

Store: Backup providers like AWS. File sharing solutions like Box or Microsoft SharePoint.

Transmit: Clouds that manage firewalls or boundaries. Cloud-provided application server front-ends. Email services

Process: There is disagreement among cyber-professionals on this topic. Obvious examples are using virtual desktops in a cloud to perform work, or cloud databases. Security solutions like antivirus cloud vendors could process CUI files if they are uploaded for investigation.

How does FedRAMP reduce risk?

If a cloud vendor achieves any level of FedRAMP, they have cybersecurity well in hand. For all but the most mature Defense Contractors, FedRAMP approved vendors are generally better managed and more secure than internal systems.

Why is FedRAMP Moderate a “maybe” for CUI?

Reference: This webinar from the DAU describes the DFARS requirements for clouds.

It highlights that in addition to FedRAMP moderate, the cloud vendor “Complies with requirements for cyber incident reporting and damage assessment“.

Let’s look at DFARS 252.204-7012 paragraph D again.

See the and ? This is why you need to check with your vendor and ask if they are DFARS compliant. It is possible for some clouds to have FedRAMP Moderate but not be willing to provide access to equipment for forensic analysis (for example). This blog from Microsoft gives an in-depth explanation of why DFARS needs more than just FedRAMP compliance.

Is there a list of DFARS-compliant clouds? Not to my knowledge. Start with verifying they are FedRAMP Moderate+, then ask the vendor specifically about reporting, forensics, etc. Make sure to save that conversation to show your CMMC assessor.

Cybersecurity risks from cloud vendors – Sovereignty and complexity

When you include a cloud vendor in your scope, suddenly potential risk increases hugely.

• How is the cloud vendor managing insider threat among their hundreds or thousands of IT staff?
• How fast is the cloud vendor at patching their firewalls and web applications?
• Does the cloud vendor have privileged staff in a non-US country, where the government could walk into the building with rifles and force the staff to export your CUI?
• Does the cloud vendor have management servers in a non-US country, where the government could take over and use the systems to reach into client networks?
• Cloud vendors are juicy targets for advanced hacking groups. Does the cloud vendor have enough internal cyber-security to protect itself?
• If the cloud vendor is compromised, will they tell their clients or the U.S. Government? Will they allow the U.S. Government to collect forensic evidence from their servers?

These concerns are why the DFARS 252.204-7012 has such high requirements for cloud vendors.

What about clouds that don’t store, process, transmit CUI?

If the older NIST SP 800-171 scope guidance is used, then clouds with management access would be considered “systems that provide security for CUI”, and in-scope for the 800-171 requirements. If we translate that into CMMC “Security Protection Assets”, it mean that clouds that provide security (AKA management functions) need to meet CMMC requirements, but they do NOT need FedRAMP authorization. Only clouds that store process or transmit CUI need FedRAMP.

Because we don’t want to be surprised during an audit, it is safest to plan for any system with management access to a CUI system to be in scope for CMMC requirements until we get authoritative scope guidance from the Department of Defense.

In 2020, I asked Mr. John Ellis, the Quality Assurance Director (Acting) of the DCMA (performing DFARS 252.204-7012 assessments) to clarify whether clouds that have management access to CUI systems are in-scope for FedRAMP moderate. Summary: No, they don’t need FedRAMP unless CUI is moved into the cloud for storage, processing, or transmission.

This is his reply (thank you Mr. Ellis and OSD CIO!):

What does the CMMC say about clouds?

The DFARS 252.204-7012 rule is the only regulation that requires defense contractors to use FedRAMP for anything. CMMC requirements do not specifically include DFARS 252.204-7012 at this time.

CMMC doesn’t give separate requirements for internal networks versus clouds. However, each CMMC requirement does apply to everything in-scope, which would almost certainly include your clouds if they handle CUI or if they provide security for your CUI.

Our clouds meet DFARS and FedRAMP. We are good, right?

Almost there! By choosing a FedRAMP cloud that meets DFARS requirements for CUI, you’ve saved yourself about 90% of the work.

With FedRAMP, you have proof that the cloud facility is secure, the cloud admins are secure, and the cloud host systems are patched and monitored. But you still have a responsibility to secure your account and any customizations you build. Access management still applies, at the very least. If you build a custom virtual server (Infrastructure-as-a-Service), your security responsibilities are almost the same as on-premises servers.

This concept of shared security responsibility is known as the Cloud Responsibility Model or Shared Responsibility Model. Make sure to review your vendor’s page on this topic. AWS. Azure.

A topic that is starting to be explored with CMMC is how to show proof that your cloud provider is performing the requirements in CMMC. With FedRAMP authorized clouds, you should be able to use the FedRAMP certifications as proof. For clouds that don’t have FedRAMP, there is currently no way forward to show proof of compliance with CMMC. You almost need to audit the cloud provider for CMMC first.

Compliant cloud vendors – not easy

Picking cloud vendors that meet your needs and are compliant is challenging.

• Unlike individual controls in NIST SP 800-171 and the CMMC, there is very little supplemental explanation about Paragraph D, even though it is arguably equivalent to the requirement for internal application of NIST SP 800-171.
• There are very few cloud providers that meet FedRAMP Moderate or High. This leads to monopolies or simply no cloud-based solution available at all.
• Compliant clouds charge a premium that is normally 1.5 – 2x higher than their commercial version. Gaining entry to the compliant cloud can take months and typically requires sponsorship.
• Cloud service providers are highly motivated to dismiss the topic or mislead their customers about whether they are compliant.
• Just using a compliant cloud doesn’t mean your company or product is good to go. There is a thing called the Shared Responsibility Model which applies.

Tip: Even if your cloud vendor is listed on the FedRAMP Marketplace, you might still be using a commercial version of their services. Double-check which subscription you are using.

Remote workforce and clouds

In the age of remote work, you have three main options for connecting your workforce and securing their computers.

1. Force everyone to use the corporate VPN. This requires a lot of internet bandwidth, a strong router/firewall, and can add frustrating latency for workers who are far away from the office.
2. Open ports in your firewall to allow access to internal applications without a VPN. Extremely risky from a cybersecurity perspective. May also require increasing your internet bandwidth.
3. Use cloud services to reach your remote workers.

#3 just makes more sense in a lot of cases. You aren’t wrong for wanting to use a cloud, especially if you have remote workers.

How can we reduce risk from “non-cloud” vendors?

When a vendor makes it clear they are a cloud, you should plan to keep your connectivity open so that your infrastructure can reach the cloud. An internet outage, or blocking the connection to the cloud, will result in severely degraded functionality.

BUT, for products that aren’t fully cloud managed, you should be able to reduce vendor risk. This is why FedRAMP isn’t required for all antivirus vendors or update services – because you have the ability to manage security for these “non-cloud” connections.

Undocumented “non-cloud” software connections

Years ago, I spent some time configuring host-based security systems for the Navy. As I was evaluating network connections, I found one of our (approved) software programs was creating an outbound tunnel to a privately-owned data center. This connection wasn’t documented, and might not even have been known to the vendor. There was no option to disable it without uninstalling the software.

Moral of the story:

Even legitimate, “non-cloud” software can introduce vendor risk.

Non-cloud vendors should never force software updates or reach-back to their network. The software should never create undocumented connections out from your network.

Ways to reduce risk from non-cloud vendors

To reduce risk from non-cloud vendors, I recommend the following practices. These take significant manpower so may not be feasible for smaller organizations.

Test for back-door connections

During your testing phase, perform a network analysis (just like the story above) on your products. Understand any default connections they attempt to create. If you disconnect it, does the product continue to work?

Deny-by-default rules really work

Use deny-by-default outbound rules at your firewall to prevent unauthorized communications from your products.

Delay and manually authorize updates

For some vendors, you can choose to user an older version of the product. This is a common practice for secure networks and enterprises – they want to use a version that has been out for a few years so that the bugs have been discovered and patched.

For patching itself, you can add an interim distribution point. For example, Windows updates can either go directly from Microsoft to Windows computers, or the updates can be downloaded to an internal server and distributed from there. By adding a distribution step and using a deny-by-default network firewall between your patch server and production devices, you can prevent an attacker from compromising your systems directly using the patch tunnel.

By slowing down distribution, you can test updates in a protected network or simply wait a few days to see if other companies have trouble, before installing on your enterprise.

App permissions and virtualization controls

Review and reduce “app permissions” and use application virtualization when available. For example, in Android phones, your Solitaire game shouldn’t need any special permissions. If a new (malicious) version was released, it would be prevented from attacking your operating system by a lack of permissions.

Cloud vendors and CMMC = very important

If there is one point that I hope you take with you from this article, it is that you need to evaluate your cloud and vendor relationships as soon as possible.

The importance of vendor security is EQUIVALENT to your internal network security.

Good luck in your CMMC compliance journey!

That’s all I have on this topic. I hope this is helpful to you! Please comment with your thoughts, subscribe to the newsletter, or connect with me on LinkedIn!

Amira Armond is a CMMC Provisional Instructor, Provisional Assessor, CISSP, and CISA. She is the owner and Quality Manager for Kieri Solutions, an authorized C3PAO offering assessments, CMMC preparation services, and the Kieri Compliance Documentation package . Amira Armond is the chief editor for CMMCaudit.org and volunteers with the C3PAO Stakeholder Forum, an industry group striving for consistency of interpretation and successful rollout of the CMMC program.