Now more than ever, computer networks are a critical component of our facilities, and the security of these networks is paramount. For the next two months, this column will focus on this important topic. This month will look at how to develop a security policy that drives design and builds decisions for secure IT networks. Next month, we'll look more deeply into firewalls, virtual private networks and other technologies that can enhance network security.
What is your security policy?
If you were going to build an edit suite, how would you go about it? You would collect user requirements, develop design documentation, purchase the equipment, install and test the facility, and then hand it over to post production. You would then monitor the suite and fix any issues that come up. When you think about it, to design and build a secure computer network, you follow much the same process. But before you invoke this process, I strongly suggest asking a few questions and then using the answers to develop a security policy. This security policy will drive many fundamental decisions about your network design.
- Do you have an existing corporate IT security policy? I know that many of you struggle with corporate IT support, and this is understandable. Frequently, corporate IT people do not understand the intricacies of video networks. That said, perhaps there are parts of your corporate IT policy that can be adapted to the technical facility. An ideal situation would be to find the person who wrote the policy and ask him or her candid questions about each element in the policy. Treat this as a learning opportunity. At the end of the day, there may not be anything useful in a corporationwide IT policy written for the office environment. On the other hand, there may be some vital information that should be included in a policy for a technical area. Besides, if you work in a corporate environment, it is likely you will need to operate within that corporate IT policy or know how to get exceptions to it when needed.
- Are you going to require user authentication to use computers on the network? Your first inclination might be to say, “Of course!” But take a moment to contemplate this issue. Any security measure comes with a burden. Remember that every time someone logs on to a system, it takes time to validate that log-on request. In an on-air environment, would that log-on time cost you money? Do you already have physical security in place where a log-on requirement would be redundant? On the other hand, is it important to know who is logged on to the system at any given time? Will you use logs and audit trails to research failures or mistakes after the fact? If this is the case, think again about how you see authentication actually being used in the facility. For example, does everyone in your master control area use the log-on name “master” and the same password? If so, is there really a benefit in having the authentication requirement at all?
- Are you going to allow access to the Internet from your media facility network? Are there technical reasons why you will be forced to allow this access? Again, the answer may seem obvious — either yes or no. But carefully consider your answer. If you decide to disallow Internet access, people will be lining up at your door asking for exceptions before the network installation is complete.
- Will you allow automatic updates of software? I believe that you should not permit automatic updates of software in a technical environment. Why? Because automatic updates create instability. That said, many times software updates are released to address security issues, so this is a double-edged sword. On one hand, you want to ensure that systems are patched to the latest level for security reasons. On the other hand, you do not want to have a system auto-update and then quit working. So I believe the best way forward for technical platforms is to disable automatic updating, but make updates part of a regular maintenance plan. Bear in mind that it is wise to thoroughly test updated systems to ensure that they are working properly before returning them to service.
- Will clients be allowed to bring in laptops that they can use to access the media facility network? This is a critical decision. In a master control environment, the answer is likely to be no. In fact, you can use MAC addressing on the routers to keep people from plugging in a rogue computer. However, in a post environment, it is customary for clients to want to bring in their own laptops. These people spend a significant part of their day away from their desks. Not allowing them network access is impractical, especially if these clients are out-of-house. Establish a separate client wireless network in your facility, granting them access to the Internet but prohibiting them from accessing your core technical network.
- How many networks do you anticipate having in the facility, and what will they be used for? While it is nice to talk in theory about a single technical network and a single business network, anyone who has worked in a facility knows that real life is not like that at all. No one may actually know how many networks are in the facility. As you develop the security policy, it can be helpful to have a good idea of how many networks there are and to think about how and where these networks will be joined. Clearly, implementing security at the point where networks join is a key concept and should be addressed in the security policy.
- Will you allow clients to use USB drives or other removable media? Did you hear about the company whose security was hacked by someone who left USB drives scattered in the parking lot? The hacker was clever enough to know that people would pick up the drives and use them, and also was clever enough to infect the USB drives with a virus that allowed the hacker to take control of the computers from outside the company. USB drives are a great convenience, but in a mission-critical environment, it may be best to disable them.
- Are there network protocols that you will specifically not allow on the network for security reasons? Certain protocols such as telnet, FTP and HTTP are inherently insecure. Does it matter to you that someone with a packet sniffer can see what you are sending across the network? If it does, then you may want to insist on using secure versions of these protocols (SSH, SFTP, SHTTP) and to block the transmission of unsecure protocols across the network. But beware: Many manufacturers assume that common protocols will be supported on the network. Certain products may not function if these protocols are blocked. A better approach may be to block these protocols at the firewall.
- Will you employ monitoring and logging on the network for security purposes? If so, what level of monitoring is appropriate? Intrusion protection systems (IPS) can be used to monitor network traffic for behaviors that are typical of a security breach. While IPS is a great tool, it requires configuration and maintenance to be successful. A policy that includes the inspection of all server and router logs on a daily basis is an extremely good idea. Not only will this alert you of security issues, but it will also allow you to see problems as they are developing, frequently before a fault occurs.
- Are you concerned solely about external threats, or are you also protecting the facility from internal threats? This is pretty simple: If you are only considering external security threats, then you have an insecure system. As you develop the policy, consider the impact of internal security threats as well.
- What are the ongoing training, maintenance and administration impacts of decisions you make regarding network security? There are a variety of security systems out there, many of which impose a substantial burden on the organization in terms of ongoing training, maintenance and administration. Be sure to consider the costs of security technologies and policies as well as the benefits when developing the security policy.
Conclusion
I hope that this column gets you thinking about how important a security policy can be as you contemplate the design and construction of a new network. It is imperative to have a security policy. Don't just think about developing a policy; write it down, share it with your colleagues, modify it as you see fit, and then publish it widely within your organization.
Brad Gilmer is president of Gilmer & Associates and executive director of the Advanced Media Workflow Association.
Send questions and comments to: brad.gilmer@penton.com
