How does CUI scoping look when determining if a Unified Communications as a Service (UCaaS) solution could be in scope when it's understood that voice communications can’t be “marked” as CUI in the traditional sense?
Answering the Call
Hello? Can you hear me? What’s that? You didn’t consider that UCaaS / VoIP solutions can store, process, and transmit sensitive data too? You’re breaking up! *Static* - OK, I know that was a bit cheesy, but there’s a bit of truth to that scenario. It’s been an all-too-obvious reality for the IntelliGRC team recently. Over the last couple of months, we’ve had the privilege of engaging with UCaaS providers at different IT/MSP/Cybersecurity events and conferences only to realize that, when it comes to cybersecurity compliance, there’s a disconnect (no pun intended).
The aim of this article is not to decry disingenuous doomsday warnings or to assign blame for the current situation. Rather, I’d like to highlight concerns I see for UCaaS providers and customers alike, as well as suggestions for potential remedies for a technology that is often consumed but poorly addressed in the cybersecurity and compliance field.
Dialing in
Ok, let’s define some terms. Most of us who are familiar with CMMC, DoD regulations, FedRAMP, etc. are also familiar with VoIP and the related requirements from NIST SP 800-171 R2. Currently, under 800-171 R2, VoIP technologies must be controlled and monitored in accordance with 3.13.14.
Side Note: Ironically, the Final Public Draft of Revision 3 removes this control entirely because of it being “technology specific” and assumes the other principles littered throughout the publication will address the risks associated with technologies like that.
The question many practitioners ask: “Why concern yourself with VoIP?” begs the conclusion that the powers that be believed, at one point, that the data being discussed (transmitted)over VoIP solutions can also be sensitive, and such technologies should be secured. I tend to agree. Most do. But what about this UCaaS thing that many may have never even heard of? Let's unpack it.
UCaaS stands for “Unified Communications as a Service”. It’s a term that encompasses a third-party (cloud-based) solution that provides its users with communication services over the internet. Yes, this encompasses VoIP technologies but is not limited to voice. We’re also talking about video, instant messaging, voice-to-text transcription, voicemail management, and even collaboration services. The idea is this, “if I can decentralize my comms and collaboration, I’ll save operational overhead and have an efficient, communicative team, and a sustainable workflow.” This intention is common and is the same rationale for using more subscription-based cloud services… ya’ know, all the “(X)aaS offerings” of the world. But this convenient tech comes with risks. In the GRC world, the risk that we are most concerned with, in addition to the technological, operations, and cybersecurity risks, is the risk of non-compliance with an organization’s GRC-related obligations and goals. We know that the risks associated with the transmission of sensitive data are great and we know that the DoD isn’t unconcerned with this risk. So, for our Defense Industrial Base(DIB) client base, we’ve got some perspectives we’d like to share.
Compliance Concerns
Firstly, the same risks and cybersecurity concerns that are associated with VoIP are, we believe, shared with UCaaS since VoIP is one of the fundamental services UCaaS provides. The collaborative and communicative functions that are provided are great but think of all the security implications!
• The VoIP conversations your project manager may have with their point of contact at the prime or the Federal Agency may pertain to FCI/CUI. It may even include specifics about such data.
• Screen-sharing may be a capability that introduces a visual component to the mix and cause there to be visual exposure to sensitive DoD or proprietary data.
• If you screen share, are the people at the meeting authorized to see that data (3.1.1, 3.1.3, 3.1.5, etc.)?
• If you share a PDF file that contains sensitive data (especially CUI), is it encrypted in transit and at rest with FIPS 140-2 validated encryption mechanism through the NIST CMVP program (3.13.8, 3.13.11, etc.)?
• What about transcriptions created from voice-to-text capabilities in these solutions? Meeting recordings?
• Does your organization have additional obligations beyond the NIST SP 800-171 requirements due to handling types of data with such additional requirements such as ITAR/EAR? Would the UCaaS solution have to offer data sovereignty options to ensure only US Persons could access the supporting infrastructure and data and keep the data in the Continental United States (CONUS)?
The concerns go on. Do you see how it’s more than just controlling and monitoring the use of VoIP technologies?
Regarding DFARS
On top of those NIST 800-171 Rev 2 concerns, users also need to think long and hard about the DFARS requirements and the concerns related to the DoD CIO’s disposition towards these types of technologies. We know that, under DFARS 252.204-7012, if contractors intend to use any cloud service offering to store, process, or transmit covered defense information (DoD CUI), they are required to only use solutions that are not only “equivalent” to the FedRAMP Moderate security requirements but are also compliant with the ‘c-g’ requirements of the same DFARS regulation.
Side Note: The concept of FedRAMP Moderate “equivalency” is a bit messy, and its future isn’t looking so hot so you might as well only focus on solutions that are showing up in the Marketplace as FedRAMP Moderate Authorized. This is due to a recent memo from the DoD CIO indicating that the concept of “equivalency” is practically more difficult than a formal ATO/P-ATO process to gain authorization. Another topic for another day.
We sympathize with DIB organizations trying to understand and navigate these issues. We also really want UCaaS providers with a quality product to be successful and to help those DIB clients have internal cohesion and technologies to scale and improve their business and workflows. But we’ve got to be honest about the situation and talk through what must be done to make this work!
Our 2 cents
Let’s keep this simple, shall we? UCaaS can be an awesome service and can serve as a great alternative to other more commonly accepted solutions. However, as we’ve discussed, we must address the security and compliance elephants in the room. Our opinion for UCaaS providers and UCaaS consumers is the following:
FedRAMP (and FIPS) that thang
The DIB and DIB supply chain needs you! Let alone the other contexts under FISMA where FedRAMP is a priority. We’d highly encourage any Cloud Service Providers (including UCaaS providers) that have the potential to store, process, or transmit sensitive data to pursue the following:
• Start doing your homework on the FedRAMP process.
• Start engineering and implementing at least the FedRAMP Moderate Baseline of controls from NIST 800-53.
• Start developing the additional documentation beyond what they’ve always had for their SDLC.
• Ensure that your systems use encryption mechanisms that have a verifiable FIPS 140-2 Validation Certificate.
• If your solution encrypts data with a proprietary encryption module(s), it’s very important, if your solution is going to be used to transmit, process, and/or store CUI, that the module(s) go through the Cryptographic Module Validation Program from NIST and receive a FIPS 140-2 certification.
We understand that this process is a huge undertaking and can incur costs other than just the price, namely that there could be large amounts of technical debt/overhead and that it will inevitably lead to some pretty drastic changes in the culture surrounding the security and IT operations of the provider’s business and systems. It will also include times of intense/uncomfortable scrutiny by a FedRAMP 3PAO. There’s a reason why, when you type “UCaaS” into the FedRAMP Marketplace, only a handful of products show up there.
However, if more UCaaS providers gritted their teeth and answered the call, it could be a very lucrative opportunity for the provider and would enable businesses in the space to have more options to select from.
Choices, choices!
Companies who currently do or desire to utilize UCaaS solutions while also having some of the regulatory obligations mentioned earlier have few options to consider. Up to this point in time, many DIB organizations only thought to themselves: “As long as I control VoIP access and have logs of its usage, I’m good.” But, as we’ve already seen, there’s more to consider now, especially with UCaaS solutions. So, if you’re already using a UCaaS solution or have the intention to acquire one for external/internal comms and collaboration, we’d recommend a few things.
• Firstly, be compliance minded! If you’re a DIB organization that wants to implement a UCaaS solution, make sure that you’ve implemented the NIST SP 800-171 security requirements.
• Make decisions and changes in accordance with the policies and procedures established to support those requirements.
• Make sure you’re organized in the way you do change control. Decisions like this must go through a formal approval process.
You need to make sure that you have clearly defined the approved sources, destinations, authorizations, and enforcement mechanisms to control the flow of CUI in your environment (3.1.3). This will greatly impact the rest of the process. How? I’m so glad you asked! If you define within your CUI flow policies that leadership does not approve the discussion of CUI over internal VoIP calls or sharing CUI data via UCaaS collaborative functions such as file sharing or instant messaging, for example, then the requirements for the UCaaS solution aren’t as stringent. If the UCaaS solution isn’t meant to be utilized for the storage or transmission of sensitive data, then your efforts are more so going to revolve around enforcing those restrictions instead of finding a FedRAMP UCaaS Provider that can also comply with the DFARS 7012 ‘c-g’ requirements.
If you do intend on using a UCaaS provider and expect sensitive data (especially FCI/CUI) to be included in that set of data, then do your research and choose a compliant solution. This means going to the FedRAMP Marketplace to do your shopping. Investigate further and see if they can attest to (if they haven’t already done so publicly) compliance with the other DFARS requirements (‘c-g' that I keep mentioning). This should include an attestation that they would be able to cooperate with investigations in the event of a security incident that the government would need to investigate.
Ensure that, once you do acquire a compliant solution, you update your documentation (i.e. system diagrams, policies/procedures, etc.) to make sure your security program brings it under its purview. Be ready to show 3rd-party assessors(C3PAOs/DIBCAC) the security package for the solution and your acknowledgment of shared responsibility and update your System Security Plan. Again, be compliance-minded as you move forward!
On hold
Up to this point, we’ve talked about things that are commonly affirmed based on publicly available resources such as the DFARS252.204-7012 or the NIST SP 800-171 and 800-171A. However, we also must confess there are some things we’re just not sure of. I’m not sure anyone is at this point. As we’re pretty heavily focused on CMMC and DoD regulatory compliance for the DIB, many of our concerns and questions come when there isn’t much clarity from the DoD or when the DoD says something (whether through memo or regulation, etc.) that leads to even more concerning implications. This is one of those areas. Here’s a list of concepts that will need some level of clarification before we can dogmatically make recommendations:
1. What about data type and distribution limitation markings? We know that the DoD is responsible for marking CUI according to the NARA guidelines unless the contract requires it to be marked by the contractor, subcontractor, or other member of the supply chain. What, then, are we to do about the data that is generated by the UCaaS services such as transcripts or video recordings? Does the DoD expect contractors to come up with a solution for ensuring that such things are marked and have the necessary distribution limitations? How would an organization do this? NIST 800-171 only touches on media containing CUI being marked with the necessary CUI markings and distribution limits in accordance with the NARA guidelines, but this is only for documents, physical labeling, etc., and doesn’t address this scenario where a VoIP meeting recording or transcript contains sensitive information that was discussed during the meeting. Our advice, for now, is to touch base with your Contracting Officer if this is a scenario that affects you.
2. We are still waiting on clarification as to whether CSPs (including UCaaS Solutions) that aren’t being used to interact with FCI/CUI, but, rather, interact with this new concept of Security Protection Data (SPD) are going to be beholden to the FedRAMP requirements. Currently, the CMMC Proposed rule of the 32 CFR doesn’t explicitly require that CSPs that handle SPD have the same FedRAMP-related obligations that CSPs that handle CUI do. Remember, neither does DFARS 252.204-7012. However, we at IntelliGRC are taking a pretty cautious approach to this as the tone set by the CMMC proposed rule when considering that External Service Providers (with the exclusion of Cloud Service Providers) are required to obtain the same level of CMMC certification corresponding to their customer’s contractually required CMMC level if they are going handle customer CUI OR SPD. We think that it’s a reasonable possibility to think that the DoD will conclude it would be inconsistent to not follow through on flowing down the FedRAMP-related requirements to CSPs like what must be done for ESPs(like an MSP/MSSP). This would affect all CSPs including UCaaS and VoIP providers alike. DoD contractors that utilize UCaaS providers may find themselves in a situation where, because the UCaaS provider doesn’t have a FedRAMP moderate ATO/P-ATO, they are forced to look elsewhere for their communication and collaboration capabilities are crucial aspects of the way they work with SPD.
Hanging up
With all the moving parts, we understand this can be a lotto consider for organizations providing these types of services. Maybe you think that it’s not worth the cost and hassle to work towards meeting these requirements, so you’ll just focus on your commercial customer base. Maybe I’m a sentimentalist and have a special place in my heart for the small DIB contractor, but I am pleading with CSPs (including you UCaaS Providers out there) to please consider moving forward with their FedRAMP efforts. It doesn’t seem to be going away and DIB contractors are under so much pressure right now to get their infrastructure up-to-snuff and are incurring incredible costs to do so. I’ve, personally, had conversations with contractors who have decided that they are just not able to move forward with CMMC and DFARS compliance as the value of the contracts they were involved in didn’t have enough of a return on their investment for it to be a wise enough business decision for them. We’ve got to remember that these contractors are, often, small mom-and-pop shops that are simply trying to provide for their families. One of the last things they need is a scarce marketplace of tools that gouge them due to the limited competition in the marketplace. Where there are limited options and competition, the prices naturally increase. It’s a tough spot for sure, but we implore quality service providers to take up the mantle and help the DIB protect our country's interests! We at IntelliGRC are happy to hop on a call and flesh things out further and provide some guidance if this is a call that you’re willing to answer!
.png)
