Expanding Access and Balancing Security
March 29, 2010
We implemented a simple "DMZ" at our broadcast sites in early 2009 to help improve direct access to broadband solutions and minimize impact to our business network circuits. The overall project was completed quickly and resolved several immediate needs for some of our sites. This implementation was actually a significant milestone for us because we have always relied on a closed and restricted wide-area network deployment that provided strict control and management of external access.
Our new model, essentially allowing remote sites to have their own local, dedicated access to the Internet, provides much higher bandwidth and speed capacities, and helps to reduce load and demand on our existing business circuits.
This change, however, required a complete rethinking of our security philosophy. Our original model provided for access to the Internet via two sources located at our headquarters in Richmond, Va. All traffic from remote sites was routed through Virginia, either through dedicated business circuits, or via broadband circuits that were configured as a virtual private network (VPN) and tunneled back to Richmond. This provided us a strong security model and limited the amount of oversight and management required.
TAKING A FRESH LOOK
The initial model has worked very well for years. But changes in local needs, volume of larger video transfers and general changes in how we acquire and share content forced our hand into taking a fresh look at our enterprise topology.
A major issue we have to deal with is support, oversight and management of these new access points at our 18 television stations. This is a significant challenge as resources are already stressed. The initial DMZ model developed last year provided our initial steps toward a secure and managed environment.
At this point, we are in the midst of adding more functionality that will further expand the capabilities of the DMZ.
We have always managed Internet access and traffic from our headquarters, using adequate firewalls and logging servers to protect our environment. Our new plan will include upgrades to existing hardware at our stations that will provide better control of traffic routing through the local DMZ's and the ability to limit and restrict access. We intend to deploy logging servers at each broadcast site that will record access and monitor traffic, and push that information to our security center in Virginia. The centralized reporting will provide a manageable solution to ensure the security of our network with existing personnel. This change in models represents a major increase to the number of our external access points and we believe we have devised a safe and secure solution.
Our sites are excited about the changes and the benefits this will provide them. Sites will now be able to ingest video and larger files much faster using direct broadband capabilities. Because we don't permit use of Skype on our business network (primarily due to its peer-to-peer capabilities), we can safely use this tool on the DMZ, providing stations with a way to receive live reports from the field, in a safe, managed and secure environment.
MAKING IT WORK
More and more providers of content—including news, graphics, programming and spots—are moving to Internet-based delivery. The resources and pricing offered by a broadband solution are very appealing. Costs and speeds are far more attractive than traditional, dedicated circuits.
One consideration we're working through is providing optimal configuration for the variety of content providers. In many cases, we're dealing with video transfer and by their nature these can result in extremely large file sizes. Data compression is becoming more appealing and important when dealing with large files to reduce bandwidth demands, speed transfers and minimize congestion. There are some outstanding compression tools available, both hardware- and software-based, and prices are becoming more reasonable. In an effort to optimize traffic to best suit their product, vendors are making adjustments within their delivery model configurations. One good example deals with Maximum Transmission Units (MTU) that allow you to "build" an optimal packet for delivery.
MTU's provide a great way to gain efficiencies when dealing with large file transfers, however they can also present some challenges. Setting MTU's between two sites on a closed network is a piece of cake. It's easy to set up and control. Add multiple delivery models to this same network and you may find a variety of MTU needs. This can get complex and require additional administration. Mix in quality of service settings, among others… and things continue to get cloudy.
A FINE BALANCE
With Internet-based delivery, the challenge is further increased. You can certainly establish MTU settings within your own environment (on your routers, for example) but you can't control MTU settings on hops throughout the Internet. This presents an opportunity for multiple MTU settings being established for a transfer—the vendor's internal application settings (which may be adjustable, or not), configurations with your hardware, and the unknown of how your traffic will route and hop around the Internet.
Multiple MTU adjustments within a single delivery stream can drastically impair performance by requiring on-the-fly recalculation of packets.
Having several MTU "requirements" from multiple providers can result in further complications that will require your close attention to a balance that works best for your environment. We all want the fastest delivery, but balance is imperative to ensure a fair share of attention for all needs.
I know our stations are not alone in this endeavor. The requirement to provide increased and inexpensive access is likely to escalate further. Our challenge is to provide a solution that solves these needs, but balances security and doesn't negatively impact our strained resources. Our first full implementations will begin in the coming weeks, and I'll keep you posted on the progress. Count on IT!
Michael J. Sutton is director of IT at Media General Broadcast Group in Richmond, Va. He can be reached via e-mail at firstname.lastname@example.org.