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?

This article is authored by Amira Armond, the president of Kieri Solutions, a cyber-security provider in Maryland, USA.

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 3 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 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.

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

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 cloud vendor that processes, stores, or transmits their Controlled Unclassified Information (CUI).

Before I dive into DFARS security requirements, let’s get on the same page about clouds and vendors and whether DFARS 252.204-7012 applies to a specific cloud.

Is ______ a cloud?

Formal definitions of clouds are ridiculously complex. For the purposes of this article, if you are using information technology residing on a network infrastructure that your company doesn’t own, it is 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, 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 and DFARS / CMMC

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 $6/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.

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 often counts as CUI)
  • 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.

I have heard from several sources that the new version of DFARS 252.204-7012 (expected to be released in December 2020) has strict language about organizations that provide support services to contractors.

Third Party Providers (TPPs) and DFARS –

Must meet CMMC requirements if they receive, store, generate, and/or transmit CUI / FCI. Expected to participate during audits of their clients.

Major Service Providers MSPs / Major Security Service Providers MSSPs and DFARS –

Must meet security requirements and have an SLA with the CMMC organization

This informative DoD audit report found a third party provider as a failure point (among other contractor issues).

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.

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


What does DFARS 252.204-7012 say about clouds?

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. In my opinion, cloud-based management and identity solutions (smart firewall, monitoring, antivirus, directory services, mobile device management), which have privileged access to devices with CUI, also fall into this category.

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, which was just released a few days ago, 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.

Does the DFARS apply to “Less obvious clouds” – those that manage software agents installed on CUI devices?

When my company Kieri Solutions assists clients with CMMC preparation, we consider any system with management access to a CUI system to be in scope. This is more difficult than ignoring those systems, but we believe it is better to account for all factors rather than being surprised on the day of the audit.

So if you have CUI stored on a Windows File Server, I’d consider the following systems “in scope”: Active Directory domain controllers, Antivirus server, Patch Management server, vulnerability scanner. Each of these systems typically has root privileges and unrestricted network access to the file server.

Those examples were on-premises. What happens if a cloud vendor is performing these functions?

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 or not.

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

What does the CMMC say about clouds?

First, I want to point out this fact: The CMMC is not currently in effect, nor is it described in the DFARS yet. CMMC is expected to be added as a requirement to DFARS 252.204-7012 by February 2021, which would make it an official requirement for contracts going forward.

The DFARS 252.204-7012 rule is where cloud requirements and FedRAMP are described. The CMMC is oriented toward your internal networks.

So at this point, there is no CMMC requirement specific to cloud use or FedRAMP. But the DFARS is more authoritative than the CMMC, so don’t ignore it.

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.

You can assume 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.

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 delay your version. 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 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!

V. Amira Armond (CISSP, CISA, PMP, MBA) is a computer systems architect, cyber-security consultant, and owner of Kieri Solutions LLC. She specializes in CMMC preparation and DFARS 252.204-7012 compliance, and designing secure and resilient enterprise systems for private sector and the DoD. 

Leave a Reply

Your email address will not be published. Required fields are marked *