In the last article we looked at how a network can duplicate IP packets to perform efficient audio and video stream distribution using multicasting. 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 IP security.
Security Issues for Cameras
New questions need to be asked of broadcast equipment manufacturers, especially around the subject of internet security.
One of the great advantages of broadcast IP Networks is that we can take advantage of consumer off the self (COTS) routers and IT equipment being able to reduce costs and scale designs easily. One of the disadvantages of using IT COTS is that we are potentially susceptible to the same security issues as the IT world and broadcast engineers must plan for this.
Broadcast IP equipment such as vision mixers and cameras will have an Ethernet port running protocols to support at least UDP to transmit a datagram using the fire and forget policy, once the datagram has left the camera or sound desk there is no guarantee that it will get to its destination.
Transfer control protocol (TCP) expands on UDP by adding flow control and error checking. A number of UDP packets are sent within a window and the receiving kit will send an acknowledge packet to tell the sender to send the next packets. If no acknowledge is received the sender will resend the packets, unfortunately this adds delay and is of little use for real time streaming.
On top of UDP and TCP we have protocols such as file transfer protocol (FTP) and hypertext transfer protocol (HTTP) which send files and webpages to and from servers. These are all potential vulnerabilities for viruses and malicious hacks and we must plan for IT style attacks.
An Engineers Dream
Many computer operating systems, whether commercial, proprietary or open source will have a TCP/IP stack. If a camera outputs video over IP then it at least supports UDP. If you can configure the camera using a web page, then it will almost certainly have TCP. At this point, as far as a hacker is concerned, there is no difference between a PC and a camera, or PC and a sound desk.
Configuring a camera, vision mixer or sound desk over IP is an engineer’s dream. No longer do we have to crawl around the floor trying to find the “config” port, or having to push a button whilst powering the device to put it into maintenance mode. Being able to configure a sound desk using a web page is incredibly powerful for today’s broadcast engineer. However, if a studio engineer can gain access to the config screen of a vision mixer, then there is potential for a malicious hacker to be able to do the same.
IT engineers go to great lengths to protect their passwords with well documented procedures in place to allow only authorized users’ administrator access to servers and routers. Broadcast cameramen, sound engineers and VT operators have traditionally had the luxury of being able to gain access to any menu within their equipment. Great care must now be taken when configuring these devices as a cameraman could easily cause problems for other parts of the network if they inadvertently incorrectly set one of the IP parameters. If the network is not designed properly they could easily take the office telephone system down for example.
With no processes in place malicious or disgruntled employees could gain the IP addresses of broadcast kit and perform external denial of service (DoS) attacks on the studio at a later date. A DoS attack occurs when an external computer bombards a particular device through its IP address with requests for data, this will render the camera unusable as the software that is responsible for sending and receiving IP datagrams will be spending all of its time dealing with the data requests from the DoS computer.
One of the most common vulnerabilities are phishing attacks. When a user opens what appears to be a legitimate email only to find when they click on a link a virus is installed on their computer, easily moving through the rest of the network, including the broadcast kit and any device with a file system on it. Ransomware viruses are installed in this way replicating to the media store to encrypt media files. A ransom has to be paid to the attacker before the files are decrypted so they can be played again.
For these reasons office and broadcast networks must be separated within the network design. Without adequate security measures a multimillion pound media asset library could be rendered worthless in a matter of minutes.
Luckily, the IT department will have thought about and put into place procedures and systems to stop attacks and virus downloads to broadcast equipment and media assets. This assumes the broadcast engineers haven’t built a side-chain of IT kit as they didn’t want to go through the change control processes that ITIL (IT Infrastructure Library) demands. IT engineers are process driven for good reason, that is they need to guarantee uptime and maintain the system without affecting the rest of the business.
Mistakes Result in Catastrophic Failures
Versions of ITIL have found their way into broadcast systems in recent years, especially in playout where service companies provide playout to many different broadcasters with many channels. The potential to take one broadcaster off air due to the actions on another broadcasters’ system has to be understood and avoided.
With its change control processes ITIL will be quite new to many broadcast engineers. However, we must respect the IT procedures as we don’t want to be responsible for taking payroll down on pay day by changing the IP address of a camera. With flexibility comes responsibilities.
Problems in networks are not always created intentionally or maliciously. Quite often a simple mistake can result in catastrophic failure. For example, if an engineer configures an IP address of camera 1 to be the same as the sound desk then IP ghosting occurs. The routers don’t know whether to send the return datagrams to the camera or sound desk, address resolution protocol (ARP) will be constantly run by routers to ascertain the MAC address and either the camera or sound desk will randomly respond causing unnecessary network congestion.
Network design consideration has to be given to the security of the media being transferred. If a film is being played out to transmission, then there are potential copyright infringements that have to be considered. Somebody may be able to download the film and take it home on a portable disk drive, or they may be able to gain access to the edit storage and copy films, potentially gaining access to block busters that have yet to be released.
Big film companies will expect to audit a broadcasters’ networks and be certain that nobody can gain unauthorized access to their material. Audit systems will need to be in place so broadcasters can see who is accessing the media and why.
In the next article we look at the three types of systems used by IT to protect a network; logon credentials, firewalls and intrusion detection and prevention systems.
You might also like...
While the merits of 8K delivery is being debated by broadcasters around the world, some are moving forward with plans to deploy the high resolution quality in creative ways that engage viewers and encourage them to interact with a live…
In the last article in this series, we looked at how PTP V2.1 has improved security. In this part, we investigate how robustness and monitoring is further improved to provide resilient and accurate network timing.
NDI (Network Device Interface) is a free protocol for Video over IP, developed by NewTek. The key word is “free.”
NAB have announced the show scheduled for October 2021 has been cancelled.
Timing accuracy has been a fundamental component of broadcast infrastructures for as long as we’ve transmitted television pictures and sound. The time invariant nature of frame sampling still requires us to provide timing references with sub microsecond accuracy.