Achieving Cloud Compliance in the Age of CMMC, CUI, and DFARS 7012: How secure are your cloud vendors?
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.
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?
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
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.
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.
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?
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).
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.
What about clouds that don’t store, process, transmit CUI?
At this time (July 2021), we are lacking scope guidance for CMMC. But 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, 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 our clients to get surprised during a government audit, my company, Kieri Solutions considers 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.
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?
First, I want to point out this fact: The CMMC is not currently in effect, meaning it isn’t required for any DoD contract yet. (as of July 8, 2021)
The DFARS 252.204-7012 rule is where FedRAMP and NIST SP 800-171 are described.
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.
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.
- 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.
- 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.
- 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!
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.