A study of the Cloud Security Alliance Cloud Controls Matrix and Zoom
Graham Thompson · Wednesday, April 22nd, 2020
The Zoom videoconferencing product has generated quite a bit of buzz as a result of both a dramatic increase in usage as well as many questions surrounding security.
I figured that looking at the publicly available security issues that have made the news with the Cloud Security Alliance (CSA) assessment tools would be an interesting “real-life” exercise for those trying to understand what these tools are and how they can be used by a company looking at adopting cloud services.
If you are unfamiliar with the Cloud Security Alliance’s Cloud Controls Matrix (CCM), the Consensus Assessment Initiative Questionnaire (CAIQ) and the Security Trust Assurance Risk (STAR) Registry, here’s a quick breakdown of the three subjects:
CCM: A list of over 130 controls spread across 16 domains that can be used to perform risk assessment of Cloud Service Providers (CSP) and internal usage of cloud services. Like all control specification documents (NIST 800-53, ITSG-33, ISO 27002, etc), the wording is pretty much a word salad. That’s where the CAIQ comes in…
CAIQ: A list of fairly direct questions that can be asked to determine how a CSP (or internal) meets a control specification. I’ll be using select CAIQ questions in this paper.
STAR Registry: The STAR registry is a website hosted by the Cloud Security Alliance. At the time of writing, it contains two major types of entries: level 1 entries that are completed by a provider themselves, and level 2 entries that have a certification (ISO 27001) or attestation (SOC2) associated with the vendor’s entry.
You can download the CCM and CAIQ documents from the Cloud Security Alliance website free of charge. You can access the STAR registry at www.cloudsecurityalliance.org/star
The Zoom CAIQ entry is dated January 23rd 2017. This isn’t great, but at least it’s a start. My goal in writing this is to be able to see how the CAIQ can be an excellent start to assessing risk associate with cloud service providers, but isn’t a silver bullet to ensure your company is performing due diligence from a security perspective.
Note: Although I’m numbering the entries, please don’t assume these are listed in an order of criticality.
Zoom Issue 1: Weak Encryption Used
Discussion: The Citizen Lab in Toronto discovered that Zoom uses AES-128 for encryption of live meetings and not AES-256. I highly recommend you check out the excellent writeup supplied. You can find that deep-dive technical discussion here. (https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/).
Now this is where things get a bit interesting. Zoom makes multiple entries in their CAIQ regarding encryption. The entries mostly point to two areas: Per meeting encryption keys being generated (along with TLS) and recorded video keys. The Citizen Lab research is solely focused on the per meeting (session) keys. What I find interesting is that Zoom’s CAIQ entries openly state that Zoom uses S3 to store recorded meetings. These recordings are stored at rest using encryption via Amazon’s “one click” Server Side Encryption (SSE). This means that Amazon owns the encryption keys. In law, you must produce what you can produce. By law, Amazon has to give U.S. authorities access to data under proper warrants being provided by enforcement agencies.
The following entries in the CAIQ questions and answers highlight what Zoom states for their encryption capabilities:
CAIQ DSI-03.1: “Do you provide open encryption methodologies (3.4ES, AES, etc.) to tenants in order for them to protect their data if it is required to move through public networks (e.g., the Internet)”?
Zoom Response: “Zoom supports AES-256 encryption. Data in transit is protected using TLS.”
Takeaway: Ok. Cool. Generic answer, but it gets better later, so whatever.
CAIQ DSI-03.2: “Do you utilize open encryption methodologies any time your infrastructure components need to communicate with each other via public networks (e.g., Internet-based replication of data from one environment to another)”?
Zoom Response: “When accessing Zoom’s web services over the internet, communications is always over TLS/SSL.” (SIC)
Takeaway: TLS is good. So nice they said it twice. Move on.
CAIQ EKM-02.1: “Do you have a capability to allow creation of unique encryption keys per tenant”?
Zoom Response: “Zoom meeting has a unique key that is generated by the meeting servers per meeting session.”
Takeaway: Your meeting encryption is suspect. Here are the issues. First, it appears these per-session keys are of the “roll your own” type that are dependent on a fairly weak AES-128 ECB mode encryption scheme. This just isn’t appropriate for highly sensitive organizations. Secondly (and IMO more importantly), these keys are reported to be created and stored in China according to Citizen Lab research. This is a major issue that I’ll cover later in the final conclusion section.
CAIQ EKM-02.2: “Do you have a capability to manage encryption keys on behalf of tenants”?
Zoom Response: “For each meeting, Zoom server automatically generate a one time use key.” (SIC)
Takeaway: Who in your organization would question where this key is generated? More realistically, is this a “big deal” to your company? I get it if you work for Government, but I think a tire manufacturer in Maine wouldn’t care if a sales meeting could be viewed by a foreign national. TL;DR: Know yourself and know your enemy.
CAIQ EKM-03.1: “Do you encrypt tenant data at rest (on disk/storage) within your environment”?
Zoom Response: “Customer account information are encrypted. If Cloud Recordings feature is used, meeting recordings are store in Zoom’s Amazon Web Service (AWS) cloud in standard MP4 format and are protected at rest using Amazon Server Side Encryption.” (SIC)
Takeaway: Here is where Zoom openly states they use AWS to store recorded meetings. This is also where they state that Amazon owns and manages the encryption keys used to store recorded meetings. What does this mean? If they can access data, they must supply any recorded meetings to U.S. Agencies.
CAIQ EKM-03.2: “Do you leverage encryption to protect data and virtual machine images during transport across and between networks and hypervisor instances”?
Zoom Response: “Zoom leverage TLS for encryption over public connection. Internally, it is not encrypted.”
Takeaway: I’m taking a flyer here and saying that since Amazon AWS introduced TLS between instances on the fly, this isn’t a big deal.
CAIQ EKM-03.3: “Do you support tenant-generated encryption keys or permit tenants to encrypt data to an identity without access to a public key certificate (e.g., identity-based encryption)”?
Zoom Response: No.
Takeaway: Making this available can address most, if not all, concerns regarding encryption, or confidentiality of Zoom recordings.
CAIQ EKM-03.4: “Do you have documentation establishing and defining your encryption management policies, procedures and guidelines”?
Zoom Response: “Data is store on Amazon Web Services S3 and is protected at rest using Amazon’s Server Side Encryption.” (SIC)
Takeaway: Zoom engineers clicked a button and met compliance.
CAIQ EKM-04.2: “Are your encryption keys maintained by the cloud consumer or a trusted key management provider”?
Zoom Response: “Zoom manages all meeting encryption key. Key are randomly generated per meeting session.”
Takeaway: Note how they don’t say how secure the generation process is, the encryption level, or where it’s performed. Citizen Lab showed how the sessions are encrypted, but then again, they showed the issues in the supply chain.
CAIQ EKM-04.3: “Do you store encryption keys in the cloud”?
Zoom Response: “Zoom temporarily stores the encryption key within our production environment for the duration of the meeting.”
Takeaway: Again, they talk about the live meeting encryption key, not the recorded meeting encryption scheme.
Zoom Issue 2: Jurisdictions
Discussion: Citizen Lab research points to these one-time meeting encryption keys being created in and distributed from China. This was for a Zoom session that included two nodes, one in the USA and the other in Canada. This is not listed in the Zoom CAIQ at all.
CAIQ DSI-02.2: “Can you ensure that data does not migrate beyond a defined geographical residency?”
Zoom Response: “Zoom services can be access from anywhere with an internet connection, however, data is stored only in AWS U.S regions.”
Takeaway: I’m going to give Zoom credit and assume this means recorded meetings are stored in the U.S.A. Funny how this sets up a scenario where they could be forced to give live meeting access to Chinese authorities and access to recorded sessions to American authorities.
Zoom issue 3: Numerous application security issues
Discussion: I’m going to lump all the application issues (applistructure) in one big group. This includes their integration (and subsequent shock (!)) with Facebook API integration. This section though does point to a pretty big weakness with the CCM, the CAIQ, and vendor-supplied STAR entries. These products cannot be used for detailed application security findings. For example, Citizen Lab only discovered the issues they reported on after performing detailed Wireshark analysis.
CAIQ AIS-01.4: “Do you verify that all of your software suppliers adhere to industry standards for Systems/Software Development Lifecycle (SDLC) security”?
Zoom Response: “Yes, we do not embed third party software but open source software are verified to conform to our security standard as part of SDLC.” (SIC)
Takeaway: Well, they embedded a Facebook SDK in their IOS app, so I’m not too sure about this statement of theirs. That said, it’s important to note the CSA tools don’t really look
Final Takeway
As you can see, Zoom’s STAR registry level 1 CAIQ addresses risk and security related information, but is mostly useful at a high-level risk management level. It can be very useful to determine if a vendor is worthy of deeper inspection from a security perspective. We also know the CAIQ doesn’t go very deeply into application security itself (nor do I believe that was ever the intent). The most troubling aspect about this CAIQ is a complete absence of any reference to China being an integral part of the application. As has been discovered by researchers and SEC filings, Although Zoom is an American company, it appears the application is actually created and maintained by 700 developers who are located in China.
As for China being identified as a major issue, you have to understand that Chinese Government has laws in place that grant Government access to any and all data stored in any system located in China. They can perform penetration testing at any time and/or have “guys with guns” enter a datacenter to ensure the timely and effective collection of data. We know the application is maintained by Chinese companies, the meeting servers create the session keys, and these keys are delivered from a Chinese IP address (again, consult the Citizen Lab report for their findings). All these findings imply the “production environment” is China and not the U.S.A as implied by their CAIQ entry.
Where does this leave you? As with every other cloud service, the corporate adoption of Zoom depends on your risk profile. Are you working for a Five Eyes Government department and are concerned about using Zoom based on keygen processes being located in China? You should be. This is why you see all these news articles regarding Zoom security. Are you a restaurant in Burlington, Vermont using Zoom to share the nightly special with employees before their shift? You likely don’t, and shouldn’t really care. I do believe however this case study shows the need for additional security assessments on top of a risk review using vendor-supplied attestations.
Further Information
Interested in learning more about cloud assessments? Our training and group training offerings include:
Official Certificate of Cloud Security Knowledge (CCSK) Foundation
Official Certificate of Cloud Security Knowledge (CCSK) Plus
Official Certified Cloud Security Professional (CCSP)
Cloud Security Bootcamp (CCSK Plus and Cloud Audit and Compliance)
Loading ...
