Video Over IP: Security Considerations and Concerns

Every year, our students in final semester work on a Capstone Project, where they are required to research and implement part of a larger system. This year, we decided to give three students an opportunity to dive deeper into issues associated with video over IP integration. On the research side of the project, they specifically tackled potential of security issues within broadcast facility. Frances, Craig and Danny did an amazing job researching the subject and wrote a white paper that is worth reading for anyone in the industry who will be dealing with video over IP design and implementation in the near future. – Lubos Kuzma, Instructor – School of ICT, Broadcast Systems Technology

 

Video Over IP: Security Considerations and Concerns, a White Paper submitted by Frances Kootnekoff, Craig Young, and Danny Lee, Broadcast Systems Technology, Southern Alberta Institute of Technology

Security Concerns

Businesses today face the growing threat of ‘cyber-attacks’, that is attacks either on or through networking infrastructure. Much like other industries the business side of most broadcast facilities currently use conventional IT methods to secure their systems. Firewalls, isolated internal networks, and the use of secure protocols provide protection against external threats. Despite this network attacks against companies are becoming increasingly common. In November 2019, an undisclosed Canadian insurance company was forced to pay $950,000 CAD to hackers who had used ransomware to hold the company network hostage [1]. This payout was after a week of being locked out of their network. For a broadcaster, being unable to access systems for a week would be unacceptable.

Events in the past few years suggest that broadcasters are increasingly becoming targets for this sort of cyber attack. In 2019, The Weather Channel suffered a malicious attack that resulted in them being unable to air their live morning show for around 90 minutes [2]. Some attacks, such as ransomware attacks, are motivated by the chance of financial gain for the hackers. Broadcasters are good targets for this as they operate in a real-time environment, meaning they can’t afford to have systems offline and therefore are more likely to pay the ransom. Even if broadcasters choose not to pay the ransom, the cost of recovering from such an attack is often immense. A 2017 attack on KQED San Francisco cost the station $475,000 USD to rebuild and secure their network [3], and an attack on Radio One came with a repair cost of $500,000 USD on top of the estimated $800,000 USD in lost advertising revenue [3]. For smaller broadcasters, the cost of being a victim could mean severe financial difficulty.

Perhaps even more concerning than network attacks motivated by financial gain, are attacks perpetrated with the intent to cause harm to a broadcaster. In 2017, French broadcaster TV5Monde suffered an attack that took all 12 of their channels off air for over 18 hours. While addressing the FT Cyber Security Summit in London, the network’s managing director, Yves Bigot, addressed the motivation behind the attack “We are still not certain who ordered the attack or why TV5Monde was targeted, but we do know that it was aimed at destroying the company” [4].

A report by ANSSI, the national cyber-security agency of France, provides sobering details on how hackers were able to access a supposedly secure internal network. Three months prior to the attack, hackers had infiltrated TV5Monde’s network. From there, they were able to identify a server used for camera control, they used this system to create a new user with administrative privileges in the active directory, thus allowing them unchecked access to the rest of the network. Hackers then spent over a month investigating and mapping the network and signal flows, the search terms used by the attackers show that they were most interested in finding and understanding how video streams are managed and broadcast. On the day of the attack, the perpetrators configured multiplexers, ensuring they could not be restarted, before going on to overwrite firmware on multiple switches and routers within the network, as well as taking down encoders related to the transmission of TV5Monde signals [5] – [7].

The TV5Monde incident shows the damage that can be done should an attacker gain access to a broadcaster’s internal network. In this particular case, access was gained through a weak endpoint, the company that provided the camera control software. Third-party vendor security is an issue that an IP based system will be especially vulnerable to. Using IP based infrastructure to route signals means an increasing amount of equipment will be connected to a facilities internal network, creating possible points of penetration from external threats.

Security Concerns for Video over IP Systems

Security will become increasingly important to broadcasters as the shift towards network-based streams occur. These concerns will closely reflect general IT security concerns; however, broadcast facilities have additional vulnerable areas that will need to be addressed, likely through the implementation of industry-wide standards.

Use of Third-Party Equipment

One of these areas is the unavoidable use of third party hardware and software within the internal network. In traditional network systems, there are firmly established guidelines, and equipment manufacturers have established a focus on the security of their product. In contrast manufacturers of broadcast-specific equipment may not the same tradition and focus of security. This is especially likely to be true in the early years of the migration onto IP based systems.

Currently, SMPTE (Society of Motion Pictures and Television Engineers) standards do not cover security for video over IP, leaving individual manufacturers to set and maintain their own best practices. This creates a serious weakness in the integrity of a network in which these devices are deployed.

The TV5Monde attack is a real-world example of just how serious these vulnerabilities are, and the devastating effects of broadcasters not even considering them in the planning of their network security. The ANSSI report gives further insight into this issue describing how attackers initially attempted to gain direct access to the TVMonde5 network but were unable to do so due to the network security implemented by the station on its own networks. Upon realizing this was a “dead-end” they then focused on gaining access through a third-party equipment supplier, and the first penetration into the network came from the Netherlands, where the third-party supplier was based. The report specifically comments on the fact that while TV5Monde thought their network was secure due to their security practices, they were relying on external third-party vendors to maintain security for their devices. Relying on unknown and uncontrollable security practices creates a very serious, exploitable vulnerability in any system.

Standards

SMPTE ST 2110

In November 2017, SMPTE published its SMPTE ST 2110 standard. SMPTE ST 2110: Professional Media Over Managed IP Networks, allows for uncompressed video to be sent over IP, with audio data and ancillary data sent as separate streams. The use of elementary media flows sent separately over IP networks is a step towards the eventual conversion of a broadcast facility to a completely IP based environment.

SMPTE ST 2110 is a multipart standard suite, that as of March 2020 is comprised of the following parts [8]:

SMPTE ST 2110-10 System Timing and Definitions

SMPTE ST 2110-20 Uncompressed Active Video

SMPTE ST 2110-30 PCM Digital Audio

SMPTE ST 2110-31 AES3 Transparent Transport

SMPTE ST 2110-21 Traffic Shaping and Delivery Timing for Video

SMPTE ST 2110-40 Ancillary Data

Source: As listed in [9]

This set of standards defines a system RTP- based essence streams in reference to a common reference clock, and in doing so it lays out the framework for achieving video over IP within a broadcast facility.

A system that enables video within a broadcast facility to be sent over IP must be multilayered. This is because video is continuous, and highly time-sensitive, whereas IP is neither continuous due to its packetized nature, nor time-sensitive to the level that is required for video. This means that for Video over IP to work other standards, in addition to SMPTE 2110, may be required [10]. These include, but are not limited to:

IEEE 1588-2008

PTP – Precision Time Protocol v2

IETF RFC 4566 (SDP)

SDP – Session Description Protocol

IETF RFC 4175

Payload Format for Uncompressed Video

SMPTE 291

Ancillary Data Packet Space and Formatting

AMWA – NMOS

Networked Media Open Specifications

The complexity of a broadcast IP Video Ecosystem along with the required standards is illustrated below:

Fig. 1  IP Video Ecosystem for Production, Post-Production, and Broadcast.

                            Source: Adapted from [11]

SMPTE 2110 has been well received within the industry, with equipment manufacturers listing “SMPTE 2110 compatibility” in specifications sheets of their products.  However, while SMPTE 2110 covers both the physical layer, as well as the transport layer (with ST 2110-21), it does not yet address all other aspects of an IP based media flow system such as device communication, discovery and registration of devices, and security.

 

Why is this a problem

The nature of broadcast equipment means that it is inevitable that a facility will use both hardware and software from a variety of manufacturers. This creates an unavoidable security issue, that if left unaddressed could potentially leave the internal networks of such facilities vulnerable to outside intrusion. An industry-wide standard that addresses best security practices would assist manufacturers in designing equipment that will remain secure when deployed in an IP broadcast network, and thus limit the scenario where access to that network is gained through a vendor’s product.

Standards

A standard, addressing the acceptable security practices of equipment used in a video over IP environment, would provide three primary benefits. It would ensure that all equipment conforming to the standard, uses best-practice security methods, to ensure the integrity of such devices. It would allow broadcast facilities to understand what security is being used by devices connected to their internal and external networks. It would help to guarantee the interoperability of equipment by eliminating the scenario where different manufacturers use non-compatible, or conflicting security methods.

Interoperability

In the current environment, companies are free to create equipment using their protocols and security methods of choice, this means that not all devices are compatible ‘out of the box’. To address this, facilities may use workarounds, potentially opening up the network to further vulnerabilities. This ‘manufacturer’s choice’ issue can be seen when looking at some of the protocols used in equipment that has been specifically designed to transition facilities to video over IP.

Control and Management Protocols

SMPTE ST 2110 provides a standard for the transport layer of a video over IP system. However, the control and management layers of devices used in such a system are undefined. This has left manufacturers with a variety of options regarding the protocols used for functions such as the discovery of devices, and device connection management.

Ongoing Solutions

Creating standards for packet-based professional media systems presents a complex challenge for the industry. Video over IP systems has a multitude of layers, many of which will have security implications and considerations. To address this, various industry bodies are collaborating on creating frameworks to further support the development of standardized Video over IP.

One such group is the Advanced Media Workflows Association (AMWA). Who, in collaboration with various other bodies, have created Networked Media Open Specifications (NMOS), with the goal of providing “a means for straightforward interoperability between products from a wide range of manufacturers, in order that end-users and service providers can build best-of-breed systems.” [12]

NMOS

NMOS, much like SMPTE 2110, is a family of specifications addressing the control and management layer of Video over IP systems. The current status (as of March 2020) of the various NMOS standards can be seen in the following table [13]:

Table I

Current status of NMOS

Id	Name	Status
IS-04	Discovery & Registration	AMWA Specification (Stable)
IS-05	Device Connection Management	AMWA Specification (Stable)
IS-06	Network Control	AMWA Specification
IS-07	Event & Tally	AMWA Specification
IS-08	Audio Channel Mapping	AMWA Specification
IS-09	System	Work In Progress
IS-10	Authorization	Work In Progress
MS-04	ID & Timing Model	Work In Progress
BCP-002-01	Natural Grouping	AMWA Specification
BCP-003-01	API Security: Communications	AMWA Specification
BCP-003-02	API Security: Authorization	Work In Progress

Source: Adapted from [13]

In their development of NMOS, AMWA has specifically addressed security concerns related to APIs, as well as defined standards to mitigate these concerns. Looking at the BCP-003-01 standard, as well as BCP-003-02, highlights some of the serious security weaknesses that could be inherent in equipment that does not choose to follow these best practices.

NMOS Security Practices

Two of the principles followed when building NMOS was the idea of building on widely used and open foundations, and the idea of ‘use’ rather than ‘invent’ [14]. This is a security-conscious philosophy that advocates for the use of protocols and technology that has proven successful elsewhere.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is an established way to communicate over a network. Commonly used to access webpages across the internet, HTTPS uses the Transport Layer Security to encrypt communication protocol. This provides the security trifecta; authentication, privacy, and integrity. Through NMOS BCP-003-01 the usage of HTTPS is mandated in several areas such as API to server communications, ensuring that servers shall respond to HTTPS API requests using a cipher suite as allowed by TLS, and shall ignore any plain HTTP requests received. This ensures that a server is responding to the requests from a legitimate API within a system.  HTTPS is also mandated on the client side, stating that clients must provide the ability to install a root certificate, and then use this to ensure the validity of server certificates. It is also required for a client to stop communication with a server should a handshake between them fail.

The development of NMOS provides an example of how standards that build on known secure ideas can be created for Video over IP. These standards then enable broadcast equipment manufacturers to design products that do not risk compromising the network in which they are deployed.   

General IT Security in Broadcast Equipment

A network is only as strong as its most vulnerable point. Building a secure internal network within a facility and then allowing unsecured devices access to that network is bad practice. It means the network will be perceived as secure when it is not. This is especially true for internal networks within a broadcast facility, as such networks are often thought of as isolated from the wider internet. The idea that a network is “not connected” creates a false sense of security, with potentially serious consequences.

This “laissez-faire” attitude towards good IT security can be seen when looking at broadcast specific equipment and how they use communications concepts such as HTTPS. HTTPS enables equipment to securely communicate within a network. Sending unencrypted communications, whether through HTTP or other protocols such as Telnet or FTP, means that passwords and other sensitive data are sent in cleartext, creating the risk that an unauthorized user can read this data. Broadcast specific equipment also uses web interfaces to allow for configuration, these can also allow remote login or monitoring. If unencrypted communication is used for such interfaces the network can be left exposed. This is especially true if equipment allows for remote login, and manufacturers should be following web application security best practices when building web interfaces for their equipment. If equipment allows remote access without HTTPS authentication, then anyone on the network is able to log in, and potentially configure that equipment, including taking it offline. For a broadcast facility having equipment forced offline can result in dead channels on air. Unauthenticated access to equipment could also, in the most serious cases, allow for a brute force attack to be used to gain the systems root password [15].

In a typical network, the importance of secure communication is obvious, but in a broadcast environment, it can be regarded as less crucial due to the false idea that only authorized users will ever be on the network. The idea that traditional IT security does not apply to equipment within a broadcast network is dangerous. If commonly accepted IT security practices are not followed because it’s believed that external threats cannot gain access to an internal network, then facilities are leaving themselves vulnerable. As seen in the attack on TV5Monde, penetrating a ‘secure’ network is possible, and once inside, the lack of security discipline can allow the intruder access to the entire system, resulting in very serious consequences for a Broadcaster.

A Cybersecurity Vulnerability report by JT-NM confirms that vulnerabilities in broadcast specific equipment are not uncommon. Through testing of 34 companies, the report identified 385 vulnerabilities on the tested devices. Worryingly 6 out of the 34 tested companies had devices exhibiting “highly critical” vulnerabilities.

Grouping the vulnerabilities into categories highlights the risk of not using secure communication protocols such as HTTPS (categories absence of encryption, web interface weakness, and unauthenticated remote access).

Fig. 2  Percentage of occurrence of a vulnerability category as a percentage of the total number of detected vulnerabilities.

Source: [16]

The number of security concerns found during the testing performed by JT-NM highlights the need for vendors to ensure that their devices are truly secure.  With the adoption of video over IP systems, the idea that broadcast facility networks are “isolated” is increasingly untrue. Failing to consider this will result in equipment that leaves Video over IP networks with weak points, leaving them vulnerable to attack.

Broadcast facilities must also be aware of what they are allowing to connect to their internal networks. Designing a secure network to enable Video over IP is not enough if unsecure equipment is then allowed unmetered access to that ‘secure’ network. The attack on TVMonde5 demonstrates that commonly held beliefs such as “broadcasters are not targets”, or that “our network is isolated and therefore safe”, are untrue, and that this false sense of security can create serious problems.

Conclusion

As more broadcast facilities look towards implementing Video over IP, the need to consider security must become a focus of the industry. In current traditional configurations, best of practice security protocols, especially concerning the use of third-party equipment, may not be at the forefront of broadcasters’ minds. Should this false sense of security not change, then Video over IP capable facilities are opening themselves up to the very serious risk of attack. These attacks will cost Broadcasters substantial amounts of money and time, and in the most severe cases, can completely shut down a facility resulting in stations going dark. To mitigate these risks, the industry needs to create strong standards, that layout best practices relating to security, for both vendors and broadcasters. Without these standards in place, the idea that internal networks are isolated and secure creates systems that can be crippled by an external attack. Video over IP brings traditional Broadcast and the wider IT industry closer than they have ever been, and it’s critical that the Broadcast industry considers this when creating secure, reliable Video over IP facilities.

References

[1] R. Flanagan, “Canadian insurance company lost nearly US$1M in ransomware attack,” CTVNews, 30-Jan-2020. [Online]. Available: https://www.ctvnews.ca/sci-tech/canadian-insurance-company-lost-nearly-us-1m-in-ransomware-attack-1.4790490. [Accessed: 24-Feb-2020].

[2]    S. Ferguson and R. Ross, “Today’s Forecast: Cloudy With a Chance of Malware,” Bank Information Security. [Online]. Available: https://www.bankinfosecurity.com/todays-forecast-cloudy-chance-malware-a-12394. [Accessed: 02-Mar-2020].

[3] L. Venta, “Entercom’s Ransomware Attack: What We Know As Of Now,” RadioInsight, 10-Sep-2019. [Online]. Available: https://radioinsight.com/headlines/180430/entercoms-ransomware-attack-what-we-know-as-of-now/. [Accessed: 02-Mar-2020].

[4] W. Ashford, “Cyber attack aimed at destruction, says TV5Monde,” ComputerWeekly.com, 22-Sep-2016. [Online]. Available: https://www.computerweekly.com/news/450304775/Cyber-attack-aimed-at-destruction-says-TV5Monde. [Accessed: 15-Mar-2020].

[5] M. J. Schwartz and R. Ross, “French Officials Detail ‘Fancy Bear’ Hack of TV5Monde,” Bank Information Security. [Online]. Available: https://www.bankinfosecurity.com/french-officials-detail-fancy-bear-hack-tv5monde-a-9983. [Accessed: 05-Mar-2020].

[6] M. Untersinger, “Le piratage de TV5 Monde vu de l’intérieur,” Le Monde.fr, 10-Jun-2017. [Online]. Available: https://www.lemonde.fr/pixels/article/2017/06/10/le-piratage-de-tv5-monde-vu-de-l-interieur_5142046_4408996.html. [Accessed: 05-Mar-2020].

[7] G. Corera, “How France’s TV5 was almost destroyed by ‘Russian hackers’,” BBC News, 10-Oct-2016. [Online]. Available: https://www.bbc.com/news/technology-37590375. [Accessed: 06-Mar-2020].

[8] “SMPTE ST 2110 FAQ,” SMPTE ST 2110 FAQ | Society of Motion Picture & Television Engineers. [Online]. Available: https://www.smpte.org/smpte-st-2110-faq?action. [Accessed: 02-Mar-2020].

[9] OV 2110-0:2018 – SMPTE Overview Document – Professional Media over Managed IP Networks Roadmap for the 2110 Document Suite. SMPTE. Jan 2019. Available: doi:  10.5594/SMPTE.OV2110-0.2018

[10] M. Brennesholtz, “Is Video over IP Ready for NAB and InfoComm?,” DisplayDaily, 22-Jun-2017. [Online]. Available: https://www.displaydaily.com/article/display-daily/is-video-over-ip-ready-for-nab-and-infocomm. [Accessed: 12-Mar-2020].

[11] W. D. Simpson, “A Field Guide to IP Video. A practical reference for STANDARDS found in the wild today,” IP Showcase Real Time Media, 2017

[12] “NMOS,” AMWA. [Online]. Available: https://www.amwa.tv/nmos. [Accessed: 24-Feb-2020].

[13] “Networked Media Open Specifications: Introduction,” nmos. [Online]. Available: https://amwa-tv.github.io/nmos/. [Accessed: 03-Mar-2020].

[14] “NMOS Technical Overview,” nmos. [Online]. Available: https://amwa-tv.github.io/nmos/branches/master/NMOS_Technical_Overview.html. [Accessed: 27-Feb-2020].

[15] A. Kouadio, G. Dierick, and A. M. Santos, JT-NM Cybersecurity Vulnerability Assessment. JT-NM, 2020. Available: https://www.jt-nm.org/documents/security/jt-nm_cybersecurity_final_report_2020_02_26.pdf. [Accessed: 25-Mar-2020].

[16] A. Kouadio, G. Dierick, and A. M. Santos, JT-NM Cybersecurity Vulnerability Assessment. JT-NM, 2020.