Last Friday, the National Security Agency released a guide aimed mainly towards U.S. Government employees and military service members are working from home, but is also ideal for business professionals on Selecting and Safely Using Collaboration Services for Telework.
This cybersecurity guidance contains a snapshot of current, commercially-available collaboration tools available for use, along with a list of security criteria to consider when selecting which capability to leverage. In addition, the guidance contains a high-level security assessment of how each capability measures up against the defined security criteria, which can be used to more quickly identify the risks and features associated with each tool.
Criteria to Consider When Selecting a Collaboration Service
The criteria below identify risks and features to consider when choosing collaboration services to support your mission. All criteria should be strongly considered but may not be fully supported based on your own operating environment and constraints. The criteria are intended to align with related USG guidance to include NIST SP 800-171r2 – Protecting Controlled Unclassified Information in Non-Federal Systems and Organizations (Feb 2020) and NIST SP 800-46r2 Guide to Enterprise Telework, Remote Access and BYOD Security (Apr 2016).
1. Does the service implement end-to-end encryption?
End-to-end (E2E) encryption means that content (text, voice, video, data, etc.) is encrypted all the way from sender to recipient(s) without being intelligible to servers or other services along the way. Some apps further support encryption while data is at rest, both on endpoints (e.g. your mobile device or workstation) and while residing on remote storage (e.g. servers, cloud storage). Only the originator of the message and the intended recipients should be able to see the unencrypted content. Strong end-to-end encryption is dependent on keys being distributed carefully. Some services such as large-scale group video chat are not designed with end-to-end encryption for performance reasons.
2. Are strong, well-known, testable encryption standards used?
Even in the absence of end-to-end encryption, NSA recommends the use of strong encryption standards, preferably NIST-approved algorithms and current IETF secure protocol standards. Many collaboration services protect data-in-transit between clients and servers via the Transport Layer Security (TLS) version 1.2 (or later) secure protocol, which is commonly used for sensitive but unclassified information. The use of published protocol standards, such as TLS and DTLSSRTP, is preferred. If the product vendor has created its own encryption scheme or protocol, it should undergo an independent evaluation by an accredited lab. This includes not just cryptographic protocols, but also key generation.
3. Is multi-factor authentication (MFA) used to validate users’ identities?
Without MFA, weak or stolen passwords can be used to access legitimate users’ accounts and possibly impersonate them during the use of the collaboration service. Multi-factor authentication requires that a second form of identification (code, token, out-of-band challenge, etc.) be provided to allow access to an existing account.
4. Can users see and control who connects to collaboration sessions?
The collaboration service should allow organizers to limit access to collaboration sessions to only those who are invited. This can be implemented through such features as session login passwords or waiting rooms, but preferably would support reasonably strong authentication. Users should also be able to see when participants join through unencrypted/unauthenticated means such as telephone calls.
6. Do users have the ability to securely delete data from the service and its repositories as needed?
While no services are likely to support full secure overwrite/deletion capabilities, users should be given the opportunity to delete content (e.g. shared files, chat sessions, saved video sessions) and permanently remove accounts that are no longer used.
7. Has the collaboration service’s source code been shared publicly (e.g. open-source)?
Open-source development can provide accountability that code is written to secure programming best practices and isn’t likely to introduce vulnerabilities or weaknesses that could put users and data at risk.
8. Has the service and/or app been reviewed or certified for use by a security-focused nationally recognized or government body?
NSA recommends that cloud services (which collaboration apps rely on) be evaluated under the Office of Management and Budget (OMB) FEDRAMP program. NSA also recommends that collaboration apps be evaluated by independent testing labs under the National Information Assurance Partnership (NIAP) against the Application Software Protection Profile (PP) . NSA has worked with the DHS S&T Mobile Security R&D Program to develop excellent semi-automatable testing criteria for app vetting based on the application PP . These criteria include tests of how apps interact with platform resources, how they defend themselves from exploitation, the crypto libraries they use, what permissions they request, and many others.
9. Is the service developed and/or hosted under the jurisdiction of a government with laws that could jeopardize USG official use?
Since it is well documented that some countries require that communications be provided to law enforcement and intelligence services, it may not be wise for certain USG missions to be performed on services hosted or developed under certain foreign legal jurisdictions. Users should be aware that the country of origin where products were developed is not always public knowledge. This criterion was not assessed in the table on page 5.