Written by: Alex Martirosyan
It’s no surprise that the adoption of teleconferencing services is expanding exponentially. Businesses are adding new services onto their network infrastructure, and typically banned software is being fast-tracked for approval.
Software such as Zoom, MS Teams, Cisco Webex, GoToMeeting, and Slack provide ways to communicate, access, and share internal resources that are on “often out of band” connection. This means that activity and data streams may be outside the organization’s management (i.e. sharing information without being tied to an internal network). This software is used both internally and also to communicate with members outside the organization.
While these services provide remote work capabilities, cybersecurity risks have grown along with them. To continue reaping the benefits of these technologies securely, organizations must align these applications with their risk profiles and ensure they’re safe to use.
But how do you know the chosen solution is appropriate and has been configured through best practice guidance? Authentication, authorization, and encryption are three categories in measuring these types of technologies’ effectiveness. We’ve compiled methods in gauging the security of these technologies, tips on maintaining these applications, and real-life scenarios seen by businesses right now—giving you the heads up on possible attacks you may see in the future.
Authentication occurs in two areas for these services. The first is backend authentication where users are able to access the actual conferencing software. The second is user identity validation. Authentication should be well defined within the application and meet industry standards. It should also remain consistent for all mechanisms, otherwise the weakest link can be leveraged in an attack.
Backend authentication is a similar process to many internal applications such as e-mail or web and desktop applications. The credentials are presented and validated by a server. For on-premise deployments, this can be the internal application’s server or a Domain Controller. However, many of these services have authentication mechanisms in the cloud and may not integrate with existing technologies by default.
Additional checks are needed to ensure authentication mechanisms are following defined policies. Authentication systems work best when they integrate with existing technologies, and managing another set of credentials typically adds more complexity and risk to the organization. Attempt to consolidate authentication to one source, such as Active Directory.
Quick Tips: Backend Authentication Best Practices
- Determine authentication mechanisms in use
- Integrate with Active Directory for Single-Sign On (SSO)
- Enforce Multi-Factor Authentication (Internal and External)
- Disable other forms of authentication such as Facebook, Google, and other credentials not managed within the organization
Attack Example: Skype for Business can be hosted on-premise or Microsoft 365. A common attack vector is to identify the authentication function and perform password attacks externally. A valid credential may provide access to internal resources from the perimeter.
User Identity Validation
Teleconferencing software can also require a password for meetings. Typically, a Personal Identification Number (PIN) and meeting ID are sent out to the invitee. Administrators should ensure that all provisioned meetings have a password enabled, and users should be trained to keep both the meeting ID and password a secret. This secret should be encrypted in transit to whoever is invited to the meeting.
Also, define an appropriate channel by using an existing technology within the organization. For example, email can be used as long as Transport Layer Security (TLS) is negotiated. A meeting should only be allowed to start once the host arrives. When a meeting has started, the host is responsible for monitoring how users are joining. It’s common for users to join through a browser, local application, or a mobile device, and this information should be monitored prior to kicking off the meeting.
Quick Tips: User Identity Validation Best Practices
- Enforce a password for all meeting invites
- Ensure the meeting ID and password are uniquely generated
- Protect the meeting ID and password for the duration of the meeting
- Ensure all guests’ identities are verified
- Monitor and lock the meeting once all users are authenticated
Attack Example:“Zoom Bombing” or war dialing often present issues due to the lack of security configurations.
The goal of authorization is to provide appropriate access for an authenticated user. As with authentication, video and audio conferencing tools allow backend users and end users with certain capabilities for managing meetings. Employees and administrators should be configured following the principle of least privilege. For instance, the ability to add profiles, schedule meetings, and make configuration changes on the application should be governed by those who hold software roles in the company.
From an administration standpoint, the application owner and system administrator should be the only members capable of tweaking configurations and profiles. Other users should have base permissions. Typically, base permissions only allow the user to create meetings and set up a user profile. It’s common for the application to offer role-based access and Lightweight Directory Access Protocol (LDAP) integration. A strong method to mitigate unauthorized changes is to leverage an audit role. Follow the best practice guidance from the user manual to ensure user profiles are created appropriately.
Quick Tips: Authorization Best Practices
- Identify administrators and end users
- Integrate profiles with Active Directory through LDAP
- Configure role-based access following the user guide
Attack Example:An attacker that gains access to an overly privileged account can tweak configurations and change how the software operates.
Meeting controls add another layer of complexity to authorization. For example, a host and end user should have differing privileges on meeting controls, and these controls should be formally defined prior to sending out an invite.
Once a meeting has commenced, users are capable of sharing screens, unmuting users, and sending out documents. Prior to initiating the meeting, some of these settings should be disabled based on the risk profile of the organization, and businesses should determine what to disable by asking questions such as:
- Is it appropriate to be able to send documents, or does this go against any data loss prevention policy?
- Are end users trained in responsibly sharing their screens or videos without leaking data?
System administrators can prevent most meeting controls from being changed by the end users, but some of these controls can be chosen by the host. Ensure the software is well understood by the application owner from both an administrative and end user perspective.
Quick Tips: Administration Best Practices
- Review meeting controls available
- Enforce settings to ensure meetings remain consistent
- Train users on how to run a meeting safely and on data loss prevention policies
- Review best practice guidance from the vendor
Attack Example:A user might share a sensitive document prior to following encryption standards and policies.
All data must be encrypted in transit for video streams, audio streams, and messaging. All major teleconferencing solutions accomplish this by default. Data in transit is encrypted using TLS, following the same protocol that secures modern web browsers on the internet. The protocols and cipher suites the application utilizes for encryption purposes must be validated for appropriateness. This setting can often be tweaked to ensure the strongest encryption protocol and ciphers are negotiated. The encryption here is to safeguard any malicious attacker that tries to “listen in,” which is commonly referred to as a “man-in-the-middle” attack.
Quick Tips: Data Encryption Best Practices
- Validate data and all communication mechanisms are encrypted in transit
- Configure the strongest available encryption protocols and ciphers
- Monitor for changes and new protocols
Attack Example:Voice over Internet Protocol (VoIP) often doesn’t have TLS enforced. An attacker on the same network as the VoIP devices can utilize a sniffer to capture data over the wire. The attacker can then reconstruct the packets and listen to the entire audio stream.
End-to-End Encryption (E2EE)
A common misunderstanding has been centered on end-to-end encryption (E2EE), especially for teleconferencing software. E2EE differs from basic data encryption (like TLS) because it ensures the data is encrypted from the sender to the recipient. Cryptographic keys are distributed securely along with meeting invites to be able to join the meeting.
The difference here is that data cannot be recovered until it’s received. From the TLS example above, data is encrypted from one party to the teleconference server. The server then encrypts the message to the other party. However, the teleconference server is in the middle of negotiating the connections separately. The server can decrypt the original message prior to forwarding it to the other party.
Many teleconferencing systems don’t offer the possibility of configuring E2EE due to complexity and performance issues. E2EE should be considered in scenarios where confidential information may be shared or presented. Although E2EE may not be configurable, all sensitive data must be encrypted at rest if it’s retained for any reason. Prior to configuring E2EE, ensure appropriate risks are identified to mitigate against.
Quick Tips: E2EE Best Practices
- Identify a valid use case for enabling E2EE
- Assess the application and fully determine if E2EE is configurable
- Safeguard and manage cryptographic keys generated
Attack Example:Lack of E2EE allows for third-party vendors to capture data being sent over the internet. If weak privacy policies exist, the vendor may be able to share that data with other third parties.
As with any new high-risk technology, an appropriate analysis should be performed to fully understand the service and its implementation. Review the user manuals to test drive the application and determine if security standards are met. Most teleconferencing vendors offer best practice guidance for securing the software and meetings. If settings haven’t been configured, test them first and inquire with business owners to determine if the change is possible.
Teleconferencing vendors must also be measured to fully trust the service. For instance, does the vendor have a SOC 2 report? Are they regularly audited by independent organizations? Are they mandated by General Data Protection Regulation (GDPR) or other regulatory standards? Do they offer services to meet Health Insurance Portability and Accountability Act (HIPAA) requirements such as Business Associate Agreements? Due to the speed of the adoption of this technology, ensure the typical vendor review procedures are followed.
The key takeaway is to treat this new technology with the same scrutiny as any other critical application. Security can’t be forgone for the cost of simply getting a product to work. Utilize industry standard frameworks and recommendations to select an appropriate technology suited for your business needs.