All 14 articles in this series are now available in our free eBook ‘Understanding IP Production Networks - 2026 Edition’ – download it HERE.

All articles are also available individually:

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 or fiber port running protocols to support 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 variable and indeterminate delay and is of little use for real time streaming in broadcast production facilities.

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.

Configuration

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 available. At this point, as far as a hacker is concerned, there is no difference between a PC and a camera or 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.

Attacks

With no processes in place, malicious or disgruntled employees could determine 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 multimillion-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 sidechain 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 – 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. 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.

Other Problems

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. If 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 movie 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.

Zero Trust Security

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 philosophy, 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.

If a hacker was to gain access to a specific service within a zone type network, then cross device access is relatively easy as the user account they have hijacked, or other access method they’ve exploited, doesn’t get verified in the zone again (until they leave it), hence they can move around large parts of the network with little or no detection. Granular access helps overcome this and further enhances Zero Trust as it restricts users from full network access. Services do not get full subnet visibility, and applications cannot communicate laterally unless configured to do so.

Smaller segmentation through granular controls and policies can apply at the level of individual workloads, containers or actual flows and IP streams, instead of VLANs and subnets. This means that attackers cannot easily obtain access from one server or service to the next as their access must be verified when moving between services.

Increasing granular access to decisions beyond identity is also based on location, time, behavior and workload enabling further improvements of security using request authorization, real-time monitoring and access, so that dynamic enforcement can be applied if the risk landscape changes.

All this extra data enhances auditing and visibility through the greater accuracy and the depth of logs created by granular access. A complete forensic audit of who accessed what, when and how, can be easily built so that threat detection and compliance can be significantly enhanced. As access control can be logged to individual flows and identities, the security system no longer relies on firewalls or trusted internal zones, thus significantly improving network and device security.

Zero Trust isn’t a specific system or component. Instead, it’s a design philosophy and work-in-progress that must be included at the very beginning of the facility design and diligently enforced for the life of the network.