All 14 articles in this series are now available in our free 62 page eBook ‘Understanding IP Broadcast Production Networks’ – download it HERE.

All articles are also available individually:

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, and we can 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 production switchers and cameras will have an Ethernet port running protocols to support at least UDP (User Datagram Protocol) to transmit a packet using the fire and forget policy, once the packet has left the camera or sound console, there is no guarantee that it will get to its destination.

Transmission Control Protocol (TCP) expands on UDP by adding congestion and flow control, and error checking. Many 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.

Most 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 console.

Configuring a camera, production switcher or sound console 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 console 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 production switcher, 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 camera operators, 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 camera operator 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 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 packets will be spending all 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 that easily moves 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 must 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 multi-million dollar 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 reduce the risk of 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.

Versions of ITIL have found their way into broadcast systems in recent years, especially in playout where service companies provide transmission to many different broadcasters with many channels. The potential to take one broadcaster off air due to the actions on another broadcasters’ system must 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 console, then IP ghosting occurs. The routers don’t know whether to send the return packets to the camera or sound console, address resolution protocol (ARP) will be thrashing to ascertain the MAC address and either the camera or sound console will randomly respond causing unnecessary network congestion.

Network design consideration must be applied to the security of media being transferred. If a film is being played out to transmission, then there are potential copyright infringements that must 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 blockbusters 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. And audit systems will need to be in place so broadcasters can see who is accessing the media and why.

The traditional approach to ring-fencing a network infrastructure has served facilities well, but the advances in cybersecurity has seen the development of a new type of security measure, that is, Zero Trust security. Whereas perimeter-type security systems assumed a user was friendly once they had successfully passed the user credential checks, Zero Trust does not make this assumption and instead relies of verification of every user access throughout the whole network infrastructure workflow.

Zero Trust may seem onerous as it implies that users must log into every device they need to operate, but this is not necessarily the case. By using verifiable context and user control, media assets and processes can be reliably protected. However, Zero Trust is not just an add-on to a network but instead embraces a whole security ecosystem that must be implemented from the start of the network infrastructure design.