Recent cyber attacks targeting the radio industry have directed my attention to security.
We all have engineering networks that run our most critical systems. Are they protected? Just how far should I go to protect them?
I think the answers really depend on the level of risk that is acceptable to you for your network. How well do you sleep at night? I am very paranoid, so I watch just about every aspect of my network, starting with the actual switches and ending with application and web monitoring. I have touched on this in a previous article.
Is this overkill? Probably, but I sleep very well at night because of it.
Let’s take a look at these attacks and what you as the responsible engineer can do about it.
The attacks that hit some Midwest stations recently are the result of poor passwords and lack of firewalling. Any device that is critical to your operation deserves to be protected by a secure password and firewall. We get busy setting up devices that we need to use and then forget about them. This is the worst thing an engineer can do.
Most devices have default passwords that are easily discovered by hackers that are looking for access. That is exactly what happened to the stations recently targeted. All of the devices that were compromised were left with default passwords or passwords that were easily guessed. The devices that were compromised were either not behind a firewall or were not properly secured by a firewall.
We need to be diligent in our implementation of security for our networks. The days of installing devices in a default configuration and forgetting them are over.
Passwords need to fit certain criteria: at least eight characters long with mixed case and symbols, add some numbers too if you want. Anything that creates complexity is good when dealing with secure passwords. I’m not advocating the use of a 50-character randomly generated password, but we need to be a bit more creative and use passwords that are not easily guessed.
An example would be Lock@Load. This is a great password that cannot be easily guessed. It is nine characters long and has mixed characters. Another example would be WnBc45y3ars! This one has almost all the best features of a secure password.
Firewalls are your friend. Most engineers shy away from parking audio devices behind them due to latency issues, but this is really a non-issue in today’s environment.
The latency caused by utilization of a decent firewall is negligible. However, I have seen latency issues with cheap firewall routers from Linksys and Netgear. These consumer routers just do not have the horsepower or the reliability to deal with critical audio streams. If a firewall is to be utilized in a mission-critical environment, spend a few dollars more and get a Cisco, Sonic Wall or similar high quality device.
Another issue with firewalls occurs with opening ports for pass-through.
Most audio devices are web-configurable but use alternate ports for the actual audio streams or data streams. Therefore, you do not need to open the web console port on the firewall. Just open the ports for the data that needs to go over the internet and manage the device from within your engineering network. The devices compromised in the recent attack were behind a firewall but had the web console port open to the internet. Bad idea.
Parking your devices on a dedicated internet access circuit would not have fixed the problems exploited recently. The hacker had access to the device either way and could change the audio feed source. That was the real issue.
The audio feed was redirected, and the device played alternate audio until the engineer unplugged it. In this case, some of the devices were located at transmitter sites, and it took many hours for the engineer to get there and shut it off. Sometimes we cannot easily fix what has been compromised.
Ransomware attacks have also crippled some radio markets recently.
These attacks encrypt all the data on your networks and offer to sell you the unlock key for a price.
Imagine that all of the audio files that your production people use daily and the audio files of the automation systems are suddenly encrypted and unreadable. You would pay almost any price to get them unlocked.
The ransomware virus actually scans your network for shared drives and will encrypt any data that it has access to. Because of this, I keep a backup of my network on an offline NAS storage device. I physically plug in the backup device, make my backup and then unplug it.
Paranoid I know, but effective.
Sometimes, engineering solutions are extreme and manual. The backup method might be a little old school, but that is better than losing everything to a ransomware attack.
Firewalls and passwords will do little to protect your station if you have end users that utilize the internet for work.
I have users who access the internet for show audio files and FTP downloads of shows. They are always clicking on something that causes me grief. This is where the ransomware attacks come into play — they need a user to click on the wrong item to get started.
We are not going to get away from our end users needing internet access on our engineering networks; so I redirect all internet traffic to a proxy server and lock out Port 80 traffic from all other computers. This allows me to filter all web-based traffic that goes through my engineering network.
I also disallow administrator access to any engineering systems. All the users are standard non-admin users. This keeps the user from causing too much damage to the computer itself. Individuals can destroy their own accounts but cannot do anything to kill the machine (usually).
Almost all of the recent infamous ransomware attacks were successful because the machine that was infected allowed standard users admin control.
MAKE IT A PRIORITY
Security is often the last thing we consider for our engineering networks. We get so busy with all of our other duties that we just do not have the time or energy to really give it the attention it needs.
We need to change this attitude. We are under constant attack from all kinds of different sources on the internet.
Engineers need to have security procedures, firewalls and good passwords on their networks. If you have these three things under control, then your network probably won’t get hit with some of these recent types of attacks.
If you don’t, or can’t institute these things, then try to find someone who can help you locally.
Call a local network consultant and get some help before you are the victim of one of these attacks. There are companies dedicated to helping you with security. “White hat hackers” will test your network, try to break in electronically, and assess all the areas where your network has a weakness. The cost for this service varies, but in larger markets it is worth it.
If you do not have the resources to hire a security consultant then take some time and do your own research. Unsurprisingly, there is a lot of information on the ’net that will help you.
Cottingham is a Cisco, Microsoft and CompTIA instructor with 25 years experience in IT and radio engineering. He’s also the chief engineer of KFMK in Austin, Texas.