Broadcast security
Jun 1, 2008 12:00 PM, BY BRAD GILMER
I spoke with several broadcasters about security for this month's column. Two topics came up repeatedly — firewall technology and password security.
Firewalls give broadcast engineers heartburn for several reasons. First, in a perfect world, engineers would prefer that there not be any connections from their core broadcast networks to the Internet. Second, in many stations, broadcast engineers do not install or administer the firewalls in their installation, yet they depend on these devices to keep their core operations safe.
Fortunately, or unfortunately, it seems that Internet connectivity is here to stay. For a host of reasons, users of systems we design and implement need to connect to the Internet. Given this fact, what is the best way to design broadcast networks so that they are secure but meet end users' needs?
When you connect a network to the Internet through any sort of security device, there is a chance that the device will be compromised. One solution to this problem is to segment your networks. If you have a critical set of computers (e.g. on-air automation systems), put these computers on a separate physical network (your core broadcast network), and keep this network separate from the Internet. In fact, you probably want to keep this network detached from internal networks too. Do you really want a defective network card in an audio workstation in production to trash your on-air network? This is a real-world scenario.
Figure 1 shows how a network can be segmented. In most stations, it is not practical to completely separate the core broadcast network from the rest of the facility. Automation logs, as-run logs and commercial inventory are examples of information that need to be exchanged between the core broadcast network and the business system network. If you must connect the core broadcast network to the business system network, the best practice is to allow connectivity through a single, well-controlled point, usually a firewall.
Firewalls
When talking about firewalls, it is useful to understand what they can do. A firewall can:
- inspect packets to see if it makes sense to allow them into the network (stateful packet inspection);
- block probes of your network in advance of an attack;
- allow an administrator to admit only the traffic types he or she decides are acceptable across the firewall;
- conceal a local computer IP address from an observer on the business system network or the Internet;
- expose a particular port on a specific server behind the firewall through a demilitarized zone (DMZ), without exposing all computers behind the firewall; and
- provide logging so security threats from the Internet can be analyzed.
When specifying a firewall, you may want to get one that uses stateful packet inspection (SPI). SPI firewalls monitor conversations between computers on either side of the firewall. If a packet arrives that is destined for a computer on the other side of the firewall, the firewall checks to see if the packet makes sense in the context of what it knows about previous communications between the two computers.
For example, if the packet contains a request to provide status about a connection with the target computer but there is no history of communications between the source and target, the firewall discards that packet. The status packet makes no sense, but there is no conversation already in progress. This keeps an attacker from launching attacks based on weaknesses in some protocols.
Early firewalls without SPI would filter packet-by-packet, without any awareness of the state of communication between the source and target. As such, the firewall had no way to know whether the incoming packet was part of a legitimate conversation already in progress or not, so it would let malicious packets through.
When configuring a firewall, you should be aware that many default configurations allow common ports used for office applications to cross the firewall unimpeded. This is not a good starting point for a firewall that is going to be used in broadcast applications. Start by closing all ports and applications, and then open them on a case-by-case basis. This may mean more work in the initial configuration, but the firewall will not be passing traffic types that you do not know about. When you close the ports, be sure the system discards the packets without sending an error message back to the source. This is important because some attackers can gain information from the target system by analyzing the error messages that are returned. (You can go to www.grc.com and run Shields Up!, a port scanning program that will report the status of all ports visible from the Internet on your computer.)
A firewall can conceal a workstation on your core broadcast network from prying eyes on the business Internet. This is called network address translation (NAT). In the example shown in Figure 2, the public Internet address of the firewall is 67.243.7.12. Workstations on the core broadcast network all use the 10.0.0 private address space. Someone on the WAN (Internet) side of the firewall would never see a workstation on the core network. The only device visible from the outside Internet is the firewall.
Web clients connect to servers using port 80. In Figure 2, all inbound traffic from the Internet 67.243.7.12 port 80 is permitted to traverse the firewall and is directed to the Web server located inside a DMZ at 192.168.0.1. The firewall can be configured so that only HTTP traffic is permitted into and out of the DMZ. In other words, Web traffic can be permitted to go to the Web server but be prohibited from all other computers on the core broadcast network. In another example, the firewall may allow FTP across a DMZ to an FTP server, but it might not allow any workstations to use FTP.
A word on passwords
For many years, it has been a challenge to ensure that the person accessing a system or network is authorized to do so. One solution is to assign each person a username and password combination. If the person knows the password for a given username, then it is assumed he or she is an authorized user.
This sounds like a great solution, and it is simple to implement, but of course, it has some problems. First, anyone who knows the username and password combination can use it, whether that person is authorized to do so or not. Second, humans often pick passwords that are easy to remember. Thus, many passwords are incredibly easy to guess. Furthermore, passwords that have meaning to humans are almost always contained in dictionaries, and it is a relatively simple thing for an attacker to try every word in a dictionary as a password when attacking a system.
Security experts agree that a better solution is to base security on something you have and something you know. An example of this is pilots who carry an electronic ID card and also know a door access code. Some computer security systems require that the user carry a small electronic device about the size of a USB drive. The device creates a new password every few minutes.
A key solution to the password problem
One solution to the weaknesses of username and password technology is to not use it at all. Many e-mail, secure FTP and file server applications support enhanced authentication, which uses public/private key exchange. A small utility you can run on a computer creates key pairs. When you run the utility, it generates two files — a public key and a private key. You send the public key file to the administrator of the system you wish to log in on. Keep the private key on your local computer, and point the authentication program to that file. When it's time to log-in to the remote system, start the application, and in many cases, it automatically logs you into the system by exchanging information based on the key files. Common authentication systems include RSA and DES.
You can find more information on both of these systems by searching for these terms on your favorite Internet search engine.
Brad Gilmer is president of Gilmer & Associates, executive director of the Advanced Media Workflow Association and executive director of the Video Services Forum.
Send questions and comments to: brad.gilmer@penton.com
| Want to use this article? Click here for options! |  |
