One of the most significant developments to impact security professionals in the past few years has crept in almost unnoticed. This is the migration of real-time communication (RTC) services from private networks owned and operated by phone companies to public IP networks. RTC services include voice calls, video calls and instant messaging. If we think about it, this change is obvious. A June 2018 article in The Guardian summed it up well: ‘The only person who rings your landline is your mum. And now even mobile calls are passé. How did this happen?’
The impact of this change is greater than simply changing social interaction. It affects both consumers and businesses as it brings a service, which was previously the responsibility of the telecoms manager, firmly into the realm of the IT professional. Most importantly, those communications services which are the lifeblood of businesses are now within the scope of data protection regulations such as GDPR and NIS.
Regulatory requirements
Most IT professionals are familiar with GDPR and related regulations, normally in the context of protecting information in databases and information used by applications such as CRM systems (data-at-rest). However, GDPR applies to all forms of data processing and specifically includes transmission over any RTC application or service (data-in-transit).
Article 4.2 of GDPR specifically includes data-in-transit in its definition: ‘‘processing’ means any operation or set of operations which is performed on personal data ... such as ... disclosure by transmission, dissemination or otherwise making available...’
The European Union Agency for Network and Information Security (ENISA) publishes technical guidelines to assist in meeting regulatory requirements. These guidelines, in their definition of communications networks subject to GDPR, specifically include all forms of fixed and mobile telephony, VoIP services, mobile internet access and WiFi.
GDPR places an obligation on the data processing organisation to ensure that all data processing, including the transmission of information over real-time communication (RTC) networks, is: ‘processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).’
Applying appropriate security measures to RTC applications requires an understanding of the technology used to deliver the service and the threats faced by the protocols and applications used.
Delivery technology
IP based RTC services may be delivered by either proprietary or standardised protocols. The dominant standard protocols are the session initiation protocol (SIP) and the real time transport protocol (RTP); both are needed to deliver audio and video calls. A third protocol, session description protocol (SDP) is used by SIP to set up RTP media sessions. All three protocols are defined in RFC documents published by the IETF, the body managing internet standards. The use of these standards is widespread.
- Many business phone systems, and virtually all new systems are IP based. Vendors such as Avaya, Cisco and Mitel provide IP based systems, built using standardised protocols, for business use.
- Unified Communication (UC) such as Microsoft Teams is growing in popularity and relies on the same standards.
The current trend is for these systems to be deployed in the cloud. To be useful in the business world, these systems must connect to the global phone network, the PSTN. The only option is a SIP trunk - an IP connection to an external service provider. The SIP trunk connection is often the security weak point.
Elevated risk
This is a perfect storm for attackers and fraudsters as a set of services (previously run over semi-private networks owned and operated by the phone company) are now using IP networks, elevating the risk of attack.
If you need evidence, consider the recent news of a WhatsApp security flaw, which allowed a single call to a WhatsApp user to install spyware. The nefarious code enabled all subsequent calls to be monitored. This demonstrates the vulnerability of proprietary consumer apps, but standards-based applications and services also hide vulnerabilities.
One of the factors is that SIP and the related protocols which drive VoIP and UC services are significantly more complex than the protocols used for services such as email and web. This complexity leaves unprotected applications and services open to a wide range of attacks. While some of these attacks operate at the IP network level and are shared with other network applications, many of the potential attacks operate at either the application or content level. Application level attacks are targeted at the SIP protocol, which controls features such as audio or video call setup and termination, plus the transmission of instant messages. Content level attacks are targeted at the audio and video media streams generated during a call.
The standards for both SIP and RTP allow for a choice of lower level transport protocols. These include the use of encrypted transports, but the standard does not mandate the use of encryption. Today, most VoIP deployments use a clear-text connection-less protocol. This leaves calls made over IP networks open to unauthorised monitoring and to a range of other attacks. There is clearly a problem if widely deployed communications services that run over public networks and use transport protocols can be monitored. If those services are used for the transmission of confidential or sensitive information, data-in-transit, then there is an elevated risk of data loss and a compliance violation.
While many UC services now implement encryption for call setup and for media transmission, the protection gained by the use of encryption is limited to communication between users with accounts on that system. The protection ends when external connections are made to the PSTN or to other services. A good example is Microsoft Teams. Teams runs exclusively in the cloud but relies on third party services for PSTN connections. These connections operate at a lower level of security than connections between Teams client and the Teams cloud service.
Other attacks
VoIP and UC systems are potentially vulnerable to a wide range of attacks, only some of which threaten violation of regulatory requirements such as GDPR. Other attacks include a range of sophisticated denial or service attacks, which are not detected with standard countermeasures. Poorly protected VoIP systems and UC systems are also susceptible to fraudulent use. There are numerous examples of these attacks, mostly occurring at night or over a weekend. A single attack can cost the victim in excess of £200,000.
Addressing the problem
VoIP and UC systems are potentially vulnerable to threats at multiple levels. These include:
- IP network level threats, including flooding attacks and distributed DoS attacks. Standard cybersecurity products, including firewalls and intrusion prevention systems (IPS) can provide some limited defence against these attacks.
- Application level threats.These threats operate at the level of the protocols which control communication sessions, for example the session initiation protocol (SIP). Threats at this level include directory harvesting, password recovery, call hijacking and a number of sophisticated DoS attacks. DoS attacks at this level include call termination attacks and attacks which prevent users from receiving incoming calls. Attacks at this level are not detectable by IPS and firewall technologies, as the attacks cannot be distinguished from legitimate protocol requests.
- Content level threats. These threats target the audio and video media streams or an RTC session. Threats including unauthorised call monitoring and replay attacks. A successful attack at this level will almost certainly mean a GDPR compliance violation.
Effective security controls for VoIP and UC systems must provide protection at each of these levels. To be fully effective, there should be feedback between the security controls at each level. So, for example, a threat detected at the application level can be blocked at the network level, or the blocking action can be pushed out to the cloud infrastructure. This requires a security architecture designed specifically to protect VoIP and UC protocols and applications.
