Randy Woods is technical director for the Central Florida Educational Foundation. He spoke to us for an article in the Radio World eBook “The Internet of Broadcast Things,” available free at radioworld.com/ebooks.
Randy Woods
Radio World: With all the attention to breaches, it must be tempting to just “disconnect everything.” How can media professionals “do it smart” and practice “safe IP”?
Woods: Yes, it’s tempting, but we would get so much less done. From a security standpoint, we need to focus on segmentation and isolation. Depending on what the communications requirements are, this can be accomplished at layer 2 with switches, and VLANs. Another name for this is a demilitarized zone, or DMZ. This isolates traffic, but you still need something to connect that segmented network to the networks that it needs to communicate with, and isolate it from the networks that it doesn’t. Using a router, or routing process, you can apply appropriate access control lists [ACLs] to the router interfaces.
If the necessary communication is limited to a known list of IP addresses or networks, this is an easy and acceptable solution. If the communication is from the internet in general, or the device needs to talk to the internet, then deeper packet inspection is preferable, which require a firewall. If you are using some Cisco routers and switches, they have a built-in firewall option called context based access controls, or CBAC for short. This is a cost-effective firewall, but it has limited bandwidth forwarding capability. Various other dedicated firewall options are of course available.
RW: What kind of questions should engineers and IT managers be asking when working with the growing “Internet of Broadcast Things”?
Woods: The obvious challenge is to keep the bad guys out of these devices. The less considered aspect is for devices that you are granting third-party access to.
For example, we had an emergency alerting device that we allowed the vendor to connect to, to inject proprietary data into our RDS system, which was then picked up on specialty radio receivers. In this type of situation, you have to assume the worst. You have to assume that the vendor, or bad employee, has a malicious intent, and once they have access to their device, that they might use that device to get to other devices on your network. The best option is to put their devices on an above-mentioned DMZ, and to not allow them to connect to anything they do not need to. In my case, they only needed to talk to the RDS encoder, so on their DMZ, I granted no outbound access.
RW: How do firewalls play into this conversation?
Woods: At the internet connection point, firewalls are an absolute minimum requirement. Additional processes such as intrusion detection and/or prevention should also be considered when you are protecting critical data such as personal information from your clients.
RW: How about virtual private networks?
Woods: VPNs come in two general forms: remote access, and point-to-point. Remote access VPNs allow your staff to securely access your private network. A big benefit to using this is that you don’t have to open holes in your firewall to allow remote administration. Too often a broadcast engineer will open up a hole to do VNC or remote desktop access. At that point, your network security is as strong as your password and/or your authentication process. In my opinion, this practice should never be done. You are just asking to be breached.
Point-to-point VPNs are great for remote sites that you can only get internet connectivity to. Again, they keep you from having to punch a hole in the firewall at either site.
This brings up another topic: Remote, shared sites. It is not uncommon for a broadcaster to be leasing access in a shared building. If a point-to-point VPN is used, gaining access to your studio facility is as easy as gaining access to the remote site system, which in many cases is trivial. Make sure you lock down your equipment at these sites. Strong passwords. Locked racks, and secured network ports. On most managed switches, there is a feature called port security. This allows you to lock down the Ethernet ports to specific MAC addresses. If someone gains access to your rack and tries to plug their laptop into your switch, they will not be allowed access.
RW: What is required to provide outside entities, such as alarm companies and security services, access to a transmitter site network while maintaining security of the network?
Woods: Limit their access to a single, static source address. If they cannot provide that, then the answer is no. Then put their devices in a very restrictive DMZ. Only grant access to these devices over the absolutely necessary ports, and never allow them outbound access that they don’t need. If their device needs access to the internet, that is not a problem. Just make sure you explicitly deny access to all network address ranges inside your private network first. Then allow them access to the internet. Tell them to use Google’s DNS servers, 8.8.8.8, and an outside SMTP server if email is necessary.
RW: What are the best secure methods for station personnel, such as engineers, to access Ethernet-enabled or controlled equipment at a transmitter site (e.g. secure port forwarding, VNC, etc.)?
Woods: The best option is via a private connection such as microwave, or maybe Metro Ethernet. If internet access is the only transport, remote access VPN is the next best option. If that is not possible, consider something like TeamViewer. Make sure your password is solid, and that you don’t let it get into the wrong hands.
RW: If a backup ISP service is employed at a site that is otherwise LAN-connected to the studio, how is that securely integrated into the network?
Woods: Just like it would be with a primary internet connection. First start with a managed firewall. If the ISP is only to be used when the LAN connectivity is down, use interior routing protocols to dynamically choose the network’s default route. This is done by prioritizing the default route coming from the backup ISP firewall lower than the priority of the default route coming from the main ISP device. How to do that technically is outside the scope of this discussion, but is very easy to do in a managed network using Cisco or similar devices.
RW: What other questions should we in the industry be asking about this issue?
Woods: Our engineering community needs to learn how to think like nefarious people. I spoke with a naval commander in the cybersecurity division. Somewhere in that conversation, he said to me, “We love people like you. You build nice, neat, clean networks. Once we get in, we can get to anywhere we want.” That was a very offensive statement, but unfortunately, very true. In my past career, I worked to build very robust, high-performing networks and systems. The game has very much changed. We now need to assume that everyone is a criminal, and protect our systems like our reputation depends upon it, because it does.
RW: Anything else we should know?
Woods: Many people assume they have some degree of anonymity because there are so many devices on the internet. They think someone with malicious intent would need to do a lot of detective work to find their site and devices, but it’s really quite easy.
The Shodan.io site is a search engine for the “Internet of Things.” By doing a Shodan search for your station’s call sign [and] Barix or Burk, for example, you can see pages of listings for broadcast devices that are visible on the internet. Information such as IP address, site type, stream mode, connection status and content type is readily available.
You can save yourself a lot of pain by simply changing the default password on these devices to something more robust.
If you’re not convinced that there is a crisis at hand, did you know that there are now exploits for network printers? Yes, printers can have agents installed on them to act as a Trojan horse, or to interrogate the print streams and capture confidential information. I am now planning on building a printer DMZ and isolating those seemingly benign devices as well.
Comment on this or any story. Email[email protected].
