In the last article we looked at why we need security in a broadcast network. In this article we continue the theme of looking at a network from a broadcast engineers’ point of view so they can better communicate with the IT department, and look at how IT engineers implement network security.
Humans are Weakest Link
IP networks can be attacked at any time without warning. This could be from a malicious hacker wishing to exploit money from their victim, a bored enthusiast who wants to prove a point, or a political activist who wants to disrupt the activities of the company they have a grievance with.
In any security system humans are the weakest link. They inadvertently open links in emails which launch virus’s, download music and films from bit-torrents and even open illegal web sites.
Broadcast Engineers and Malicious Hacks
These security breaches are problematic for the IT network and infrastructure but they have not traditionally affected the broadcast equipment. As camera’s, vision mixers, sound desks and other IP enabled kit regularly run FTP, TCP and SSH protocols, it’s easy for attackers to gain access to the broadcast kit too.
Broadcast engineers need to seriously consider the effects of malicious hacks and attacks on their broadcast infrastructure and two strategies are available to us; prevention and detection.
Thousands of Protocols
Firewalls provide the best form of prevention from malicious hacks and are devices that sit in-line on the gateway to a network and monitor all of the incoming and outgoing IP packets deciding to pass, reject or drop them, all in real time under the control of the network administrator.
Firewall can be used to block hostile attacks from SSH and Telnet, but allow video and audio streams
There are thousands of protocols in the TCP suite ranging from HTTP web access to more obscure protocols such as “quote of the day”. Each protocol can increase network traffic and is a potential for a network attack.
Software Developer Armies
Open source code provides great opportunities to develop our knowledge and build better products, one of the downsides is malicious hackers also have access to the source code and they can use this to find vulnerabilities in the design and exploit them for their own needs. As vulnerabilities become evident they are quickly fixed by the community of developers and republished.
An army of software developers will peer review the code and soon let the authors know if there is still a problem and suggest ways to fix it. This is the single most important aspect of open source software and has led to improvements in the IT and broadcast industries.
This loop continues and as a software service matures the number of vulnerabilities it is subject to decreases over time making the code more secure and resilient.
Propriety code suffers the same problems but we have to rely on believing the vendors when they tell us the vulnerability has been fixed. The software patch cannot be peer reviewed as we do not have access to the source code.
Through their rule tables firewalls restrict protocol access from the outside world and work on three levels; stateless, stateful and application.
In its simplest form stateless firewalls look at the source and destination addresses of IP packets travelling to and from the network without reference to any higher protocols. If we have a vision mixer with IP addresses 10.10.0.20 and 10.10.0.21, then we could add these to the firewall rules table to drop any packets with these as the source addresses leaving the network, and block any inbound network traffic with these addresses as destinations, resulting in the vision mixer not being able to communicate with the outside world, and the outside world will not see the vision mixer.
Stateful firewalls look at the higher level data flows and connection states. TCP is a connection based protocol and the source device must request a logical connection to the destination device. If an engineer wants to configure a camera using HTTP their browser will first request a TCP connection to the camera and a stateful firewall can detect this and log the event for later analysis.
Application configurations monitor at a service level for inbound and outbound traffic. Telnet is a utility based on TCP to allow command line access to a device such as a camera or vision mixer. Once the credential stage is passed then an engineer can gain access to any part of the device especially if they have administrator access. SSH is an encrypted version of Telnet providing a secure method of access to the camera and in the wrong hands both of these can be devastating for a broadcast infrastructure.
The big problem with IT security is that the attacker may be anywhere in the world meaning they don’t have to have breached front door security of the television station. Without firewalls we don’t know if a network is being attacked or has been attacked. It’s possible that a malicious hacker might be monitoring and learning a network waiting for an opportune moment to launch their attack.
Taking this argument to the extreme we could put a firewall on every device on a network. This is impractical due to cost, administrative overhead and network delays. A compromise has to be struck to determine where is best to install firewalls and a network may have many situated throughout the estate.
In a broadcast design we have the added challenge of keeping network jitter and delays low to allow error free distribution of real time video and audio. Firewalls, routers and switchers will inevitably cause varying amounts of packet delay and jitter. Even choosing the type of firewall can change delays, a stateful configuration is much slower than a stateless one.
Generally speaking each studio, client playout system or pool of edit suites should have its own firewall and subnet. If one studio is compromised, then the firewall can be used to block the effect on the rest of the network.
In the past, broadcast engineers have been used to pulling U-links and patch cords to isolate broadcast systems. In the IT world we don’t have this luxury as resilient networks will automatically route to other links when cables are removed, and removing an Ethernet cable in a studio network could also stop access for the PC’s, vision mixers, sound desks or cameras.
You might also like...
Today’s broadcast engineers face a unique challenge, one that is likely unfamiliar to these professionals. The challenge is to design, build and operate IP-centric solutions for video and audio content.
Broadcasting used to be simple. It required one TV station sending one signal to multiple viewers. Everyone received the same imagery at the same time. That was easy.
Are you an IT engineer having trouble figuring out why the phones, computers and printer systems work but the networked video doesn’t? Or maybe you have 10-15 years of experience with video production equipment but really don’t understand why…
As broadcasters migrate to IP, the spotlight is focusing more and more on IT infrastructure. Quietly in the background, IT has been making unprecedented progress in infrastructure design to deliver low latency high-speed networks, and new highly adaptable business models,…
In principle, IP systems for broadcasting should not differ from those for IT. However, as we have seen in the previous nineteen articles in this series, reliably distributing video and audio is highly reliant on accurate timing. In this article,…