APP.5.4 Unified Communications and Collaboration (UCC)

Description

Introduction

Unified Communications refers to a service that combines various communication services in one application and typically also one soft client. This reduces the proportion of traditional telephony in personal digital communication. The possible communication channels are expanded with additional services such as video, various forms of chat, and presence indicators.

A communication relationship between two or more participants, regardless of the service used, is referred to as a conversation.

The collaboration aspect frequently mentioned in connection with Unified Communications and Collaboration (UCC) goes a step further. While in the past this often referred only to services such as screen sharing and (digital) whiteboarding, UCC services now provide many additional functions. In particular for team collaboration, a number of applications have been established that are often used as cloud services and, in addition to telephony, presence indicators, classic chats, video calls and conferences, also include team chat areas and shared file repositories. Open interfaces are also included, allowing additional applications to be integrated, so that the overall service can become functionally very extensive.

Objective

The objective of this building block is to establish information security as an integral component of the extended communication spectrum of UCC services, to create an awareness of the potential threat landscape of these applications, and to offer approaches to avoiding threats.

Scope and Modeling

The building block APP.5.4 Unified Communications and Collaboration (UCC) must be applied to all IT systems and communication networks as well as applications used to operate UCC services. Since UCC operates over data networks, the requirements of the building blocks NET.1.1 Network Architecture and Design and NET.3.2 Firewall must be observed in addition to this building block.

Since the scope of communication services continues to expand through UCC, there are a particularly large number of overlaps with other building blocks.

This building block addresses the following content:

• the UCC services as well as the interactions and interdependencies of different services
• the (soft) clients provided to use these services and their functional scope
• the associated infrastructure components, insofar as they are not already covered by other building blocks
• topics arising from the (from the user’s perspective) seamless transition between the UCC environment and other applications

The following content is also of relevance and is addressed elsewhere:

• If a dedicated PBX system is used for telephony, the building block NET.4.1 PBX Systems must be applied.
• For Voice over IP (VoIP) as an elementary service in UCC, the building block NET.4.2 VoIP must be applied.
• For the central servers as well as various end devices and clients, the building blocks SYS.1.1 General Server and SYS.2.1 General Client and, where applicable, specific building blocks must be applied.
• For the underlying networks, the building block NET.1.1 Network Architecture and Design must be applied.
• If UCC services are provided from the cloud, the building block OPS.2.2 Cloud Use must be applied.
• To secure file repositories provided within the scope of UCC services, the building blocks APP.3.3 File Server and SYS.1.8 Storage Solutions must in particular be applied.

This building block does not address the following content:

• The email service is generally not part of UCC services. For this, the building block APP.5.3 General Email Client and Server must be applied.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.5.4 Unified Communications and Collaboration (UCC).

Limited Availability of UCC Services

UCC services are often subject to elevated availability requirements, and at the same time the functionality of UCC services depends on other IT systems and applications.

If the data networks used by UCC services are not fully functional, this can impair the availability of UCC services. For example, disruptions in the data network or internet connection can limit communication quality, causing delayed voice intelligibility, video artifacts, or connection drops.

Dependencies between critical IT systems can also hinder the functionality of other services or organizational units. For example, if UCC is absolutely required as a communication platform to restore the network, but the network is needed for UCC services to function, the two systems block each other and cannot be restored.

UCC services are often used as cloud services or operated by a service provider, meaning that disruptions at external networks or the service provider can lead to limited availability of UCC services. The same applies to the authentication service through which users log in to the UCC services. If the authentication service fails, UCC services can often no longer be used.

Inadequate Planning of UCC

If UCC is not planned in the way it is actually intended to be used, this can have effects on the functionality of all UCC services. If UCC components are modified or used more heavily, e.g. by an increased number of users, planning that was originally adequate may become insufficient.

Depending on the deployment type and services used, the demands of UCC components on networks can vary greatly. A UCC component focused on voice communication within the organization’s own network can, for example, have different requirements for internet and WAN connections than a cloud service intended to be used on mobile devices as well. If networks are not planned to accommodate UCC services, the UCC services cannot be used adequately.

Corresponding threats also exist for the end devices to be considered. Video communication and its associated functions in particular can place very high demands on clients. This can be problematic especially with thin clients, since UCC services often run entirely or partially on the end device to optimize communication data flows. Clients with insufficient processing power can, for example, cause dropouts or artifacts in video communication.

Incorrect Configuration of UCC

A large number of functions and services often also means a large number of configuration options. This can lead to misconfigurations.

Users may or must partly configure their UCC clients themselves. Due to the large number of configuration options, this can overwhelm users and cause incorrect configurations. For example, if different headsets are used in the office and in the home office, the configuration may need to be adjusted. Misconfigurations can lead to users not being audible or visible in meetings, or not being able to hear audio themselves. In addition, information can be unintentionally disclosed when room systems are configured to automatically accept incoming communication requests.

Errors can also arise from an insufficient identity and authorization concept when UCC services are configured. Administrators who also modify central routing settings during account setup can thereby cause a serious misconfiguration. This can lead to data loss or UCC service failures.

Misconfigurations from an insufficient identity and authorization concept also include insufficiently restricted permissions for external participants. If these can, for example, gain unauthorized access to conversation content, information can leak or be manipulated.

Unauthorized or Abusive Use of UCC Service Administration Rights

The assigned administration rights allow administrators to potentially make far-reaching changes to the UCC services. If administration rights are used in an unauthorized or abusive manner, this can have wide-ranging consequences. For example, administration rights can be used to make a private area, such as a chat or file repository originally accessible only to a limited group of people, available to all users of the UCC service. This allows sensitive information to be viewed and possibly modified by unauthorized persons.

Furthermore, UCC services may not be available or may only be available in a limited capacity due to intentionally altered routing configurations. For example, if all outgoing calls are blocked by central IT systems, the telephony service can no longer be used.

Disclosure of Sensitive Information

Modern UCC clients have a wide range of functions and are therefore confusing for many users. This promotes operational errors that can lead to information being passed on not in accordance with regulations. If an incorrect contact is accidentally selected, they may unintentionally receive sensitive information via chat. Another scenario involves unintentionally disclosing information during a screen share, for example when the email client is accidentally shared instead of the intended presentation.

Many users are not aware that UCC services store data sent within, for example, private chats in a cloud. This can unknowingly violate the institution’s storage policies. The same applies to files in which conversations have been recorded.

Team areas generally have a defined group of users and corresponding access restrictions; however, many users are not aware that access rights and memberships can be modified subsequently. This allows additional persons to access all previously stored files. In addition, public team areas are frequently created that additional persons can join without explicit permission. This can potentially allow data to be viewed by unauthorized persons. For example, a project team area may consist exclusively of internal users. Participants then upload internal documents because all team members are internal. When external persons are invited to the area later in the project, they can access all previous documents.

Disclosure of Personal Information

UCC services collect data in many places that is also displayed to other users. This can lead to personal information being unintentionally disclosed.

Among other things, user availability can be visible. Timestamps on chat posts, as well as extensive analyses of conversations, activities, or content for individual users can also be part of a UCC component. In some cases, user profiles can even be created by UCC services. Even persons without elevated permissions are often given access to these analyses. This allows them to draw conclusions about working hours and content, as well as the personal relationships of other persons, and to use these, for example, for performance monitoring.

When virtual conferences are used during mobile working, private information can be unintentionally transmitted to conference participants. This includes, for example, persons walking past the camera, personal items in the background of a video transmission, or sounds and voices from the private environment.

Interactions Between UCC Services

UCC services can cause interactions with each other that restrict functionality.

To improve the user experience, various services are often linked in a single user interface. However, this can lead to dependencies between services. For example, if a video conferencing service is integrated into a team collaboration interface, the video service may no longer be usable if the interface fails.

UCC services often use shared resources. This can lead to conflicts that impair functionality. For example, if headsets are used simultaneously by a telephony and a video conferencing application, the headsets can be blocked by one application and then no longer be available for the other.

Some applications have very high resource requirements. If multiple UCC services run simultaneously on an IT system, this can overload the client and cause the IT system to fail or crash. For example, if multiple video conferencing applications run in parallel in the background, the resulting memory load can severely impair the client.

Access to Applications or Resources through Control Sharing

If desktop or screen content is displayed to participants within a conversation, the control can be transferred by the sharer to other users. However, this can result in the sharer losing control over further actions.

Since this function is often available but generally only rarely used, many users are unfamiliar with how to operate it, accept the sharing, and then lose control over their client. For example, users can share control of their mouse without knowing how to end the sharing. As a result, conversation participants may be able to access further applications on the client.

Impersonation of False Identities

The introduction of new UCC services and the new opportunities for external parties to make contact create new avenues for attackers who wish to pose as trustworthy communication partners in order to obtain confidential information.

The complexity of UCC services increases the likelihood of operational errors or unconscious violations of security policies by users. For example, hyperlinks to malicious content can be opened because UCC services are perceived as an internal platform with elevated trustworthiness.

Users are often not aware that they can also be contacted by unknown external parties. This makes them more susceptible to social engineering, for example via a chat or an invitation to a conversation.

Furthermore, attackers can manipulate their displayed names, voice, or appearance. For example, an external person can pose via the ostensibly internal communication platform as a superior to obtain confidential information or documents directly via chat.

Requirements

The following are the specific requirements of the building block APP.5.4 Unified Communications and Collaboration (UCC). The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled with priority for this building block.

APP.5.4.A1 Planning of UCC (B)

A comprehensive and detailed plan MUST be developed for how and for what purpose UCC is to be used. The plan MUST in particular take into account the interactions of UCC services and MUST include at minimum the following aspects:

• Intended purposes of the planned UCC services
• Functional requirements for UCC as a whole and for the individual UCC services
• Requirements for securing UCC
• Definitions of information and data that may be transmitted via UCC
• Analysis of communication and dependencies between UCC services
• Product and service selection based on the defined requirements
• Establishment of organizational rules for using the UCC services

When planning, consideration MUST be given to how UCC is integrated into the institution’s IT infrastructure. In particular, it MUST be examined whether and how the systems of the UCC services are to be separated within the network and which interfaces to other applications in use are necessary.

APP.5.4.A2 Consideration of UCC in Network Planning (B)

Before UCC services are introduced, it MUST be verified whether the network meets the UCC-specific performance parameters. If the performance parameters are not met, it MUST be defined how this is to be handled.

If UCC services are to be used, the following aspects in particular SHOULD be considered within the scope of general network planning:

• Fulfillment of UCC-specific performance parameters such as packet loss, jitter, and latency
• Network capacities (bandwidth) for the defined use of UCC services such as video conferences
• Consideration of Power over Ethernet (PoE) for stationary end devices
• Availability of WLAN for mobile end devices

If the UCC services are expanded, these aspects SHOULD be reviewed again.

APP.5.4.A3 Initial and Regular Testing of UCC Services (B)

Initial tests MUST be performed for the UCC services to verify that the UCC components function without interference with each other and with other UCC services. Tests MUST also be performed with selected users to verify interactions with other applications in particular.

These tests SHOULD be repeated when UCC services are expanded or modified.

In addition, the configuration of UCC services SHOULD be checked at regular intervals for plausibility and conformity with the defined intended purposes.

APP.5.4.A4 Deactivation of Unnecessary Functions and Services (B)

UCC services MUST ONLY be operated with the minimum necessary functional scope. The available functions and services MUST be selected in accordance with the defined intended purposes. Any interactions between the various components of a UCC service that may arise MUST be taken into account. The following services and functions in particular MUST be reviewed for necessity and, where applicable, deactivated or restricted:

• Storage of personal data by UCC components
• Access to and processing of personal data by users and the UCC service
• Usability of functions such as chat, presence status, file repositories, or team areas by external participants
• Sending of data and files to external UCC services

Conversation-related log data MUST ONLY be stored to the minimum necessary extent. Functions and services that access (permanently) stored log data MUST be reviewed for necessity and, where applicable, deactivated.

APP.5.4.A5 Roles and Authorization Concept for UCC (B)

The roles and authorization concept MUST be supplemented with UCC-specific definitions of roles and permissions. Such definitions MUST be made for all internal users as well as for external users. The following aspects MUST be considered:

• Permissions for the targeted use of UCC services in accordance with defined intended purposes
• Permissions for adjusting the configuration of conversations
• Permissions for special functions of UCC services such as recording of conversations and access to file repositories of a UCC service

Furthermore, account permissions MUST also be reduced to the necessary minimum. Services available only to a subset of users MUST NOT be accessible to the remaining users.

In addition, only users with a corresponding authorization SHOULD be able to access data such as recordings or file repositories.

The definitions MUST be recorded, reviewed regularly and on an event-driven basis, and updated.

APP.5.4.A6 Encryption of UCC Data (B)

All communication over insufficiently trusted networks MUST be encrypted using secure methods, insofar as this is supported by the respective UCC component. If encryption is not possible for individual UCC components or individual conversations, the definition of which information may be transmitted via these UCC components MUST be reviewed and, where applicable, adjusted.

In particular, for cross-application communication it MUST be defined for which conversations the media streams, signaling, and what further data such as chat or file transfer must be transmitted in encrypted form.

File repositories containing persistent personal or confidential data MUST be secured using secure encryption mechanisms. Both internal file repositories of the UCC services and external file repositories connected via interfaces MUST be considered.

Users MUST also be informed about the encryption status within conversations.

APP.5.4.A7 Rules for the Secure Use of UCC Services (B)

Conversations conducted using UCC MUST be secured. The following aspects MUST be taken into account:

• Selection of participants according to the content of the conversation
• Additional securing of planned conversations using mechanisms such as PIN or a password
• Assignment of moderation rights to selected users of the inviting institution
• Rules for handling recordings of conversations
• Rules for end devices used by multiple users

Users MUST be informed about functions through which conversations can be secured. Users MUST also be sensitized to how to use UCC services securely, in particular for external chats or video conferences.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

APP.5.4.A8 Use of a Session Border Controller at the Provider Transition (S)

For UCC communication over networks of limited trustworthiness, a Session Border Controller (SBC) SHOULD be used at the network transition or at the transition to the SIP provider, at minimum for voice services. The SBC SHOULD terminate the signaling and media streams as an encryption endpoint. The SBC SHOULD support filter functions for signaling and media streams that additionally secure the respective conversations.

APP.5.4.A9 Secure Configuration of UCC (S)

To configure UCC securely, at minimum the following aspects SHOULD be considered:

• Encryption of signaling and media data also on trusted transmission paths
• Securing of stored data, in particular definitions of access permissions to recordings of conversations
• Restriction of available services to exclusively internal users
• Restriction of the transmission of presence information

Stored data SHOULD be encrypted. Users SHOULD only be able to access stored data after prior authentication.

IT Operations SHOULD specify secure settings to be used when conversations are created. For text-based conversations, malware protection SHOULD be activated.

Implementation SHOULD be recorded, reviewed regularly and on an event-driven basis for compliance with requirements, and adjusted.

APP.5.4.A10 Securing and Restricting Analysis of Content (S)

The nature of any (automatic) analysis of conversation content SHOULD be carefully reviewed in advance and its benefit weighed against the protection needs. It SHOULD be possible to deactivate corresponding functions either entirely or per conversation and to prevent content analysis of the communication. AI functions and the transmission of data to online services SHOULD receive particular attention.

If content is analyzed beyond the purpose of the conversation, the consent of the persons participating in the conversation MUST also be obtained for this.

If persistent data is generated during the analysis of conversations, appropriate protective measures SHOULD be implemented for these.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.

APP.5.4.A11 Ensuring the Availability of Communication Services (H)

The availability of UCC services SHOULD be ensured in particular by the following technical measures:

• Redundant design of central servers and services
• Use of Call Admission Control (CAC) for quality assurance of telephony and video services
• UCC services that function as autonomously as possible

In addition, for cloud-based UCC services, the cloud provider and internet provider SHOULD be connected to the institution’s own network in a fault-tolerant manner.

Furthermore, a SIP provider that provides phone numbers and forms the transition to the public telephone network SHOULD be connected to the institution’s own network in a highly available manner.

Availability SHOULD be monitored via monitoring of UCC services.

APP.5.4.A12 Integration of UCC into Emergency Planning (H)

Based on a business impact analysis, it SHOULD be examined which UCC services are to be considered in emergency planning. In emergency situations, alternative applications SHOULD be provided for individual UCC services. In particular, users SHOULD be guaranteed access to important services such as emergency calls.

A contingency plan for the UCC services SHOULD also be created, addressing the necessary configurations and routing adjustments that are realized via the telephony provider.

The recovery of UCC components and services SHOULD also be defined, taking into account the interactions within the UCC services.

APP.5.4.A13 Secure Administration of SIP Trunks (H)

When administering SIP trunks, a four-eyes principle SHOULD be applied for the following activities:

• Changes to routing configurations
• Changes to parameters used within Call Admission Control
• Changes regarding encryption both toward the institution’s own network and toward the provider network
• Changes to other security-relevant configurations such as local storage of connection data

APP.5.4.A14 End-to-End Encryption (H)

For UCC communication, secure end-to-end encryption SHOULD be used. The end-to-end encryption SHOULD cover both the signaling and the media data of audio and video communication with two or more participants.

For conversations between UCC services from different manufacturers, the transmitted information SHOULD be restricted if end-to-end encryption according to the state of the art is not possible.

APP.5.4.A15 Restriction of AI Functions (H)

The use of AI functions SHOULD be deactivated or reduced to a minimum. If permanent deactivation is not possible or desired, it SHOULD be defined that users of UCC services specifically deactivate AI functions at the beginning of a conversation, if this is possible.

APP.5.4.A16 Use of an SBC at Further Network Transitions (H)

In addition to an SBC at the network transition to the provider, further SBCs SHOULD be used at internal network transitions. In particular, network transitions between network segments with different protection needs SHOULD be considered.

The SBC SHOULD ensure that the encryption mechanisms at the SBC-secured network segment transitions are implemented in conformity with requirements.

APP.5.4.A17 Restriction of the Use of UCC Services (H)

The following aspects SHOULD at minimum be considered to additionally secure the UCC services and the transmitted data:

• Restriction of services according to the protection needs of the transmitted information
• Use of multi-factor authentication for users
• Deactivation of functions for external users
• Deactivation of metadata storage
• Restriction of the visibility of communication-related data for administrators

In addition, further technical and organizational precautions SHOULD be taken to secure conversations beyond the assignment of PINs or passwords.

APP.5.4.A18 Integration of UCC into Security Monitoring (H)

The central UCC components SHOULD be monitored by a security monitoring system. This SHOULD at minimum be implemented for components that act as encryption endpoints, such as Multipoint Control Units, or that are positioned at trust boundaries, such as SBCs.

If a system for centralized detection and automated real-time verification of event messages is used for the institution’s IT, the central UCC components SHOULD be integrated into it.

Additional Information

Good to Know

For the selection of encryption methods and key lengths, the technical guideline “BSI-TR-02102: Cryptographic Methods: Recommendations and Key Lengths” of the BSI should be observed.