Feature

A streaming headache for IT bosses

The long summer of sport draws to a close, and corporate networks draw a breath of relief as multiple streams of video cease to drain available bandwidth from the business.

How was it for you? Did the voices from on high make the big statement "stop all streaming media"? What was your response?

The problem is that the use of streaming media is only going to increase. At the moment, for most organisations there is a straightforward solution - if it is streaming, it needs to be stopped, as there is no business use for streaming media.

However, corporations will increasingly find valid uses for streaming media. This will complicate the situation, as we find that basic tools can be used for both "real" and non-allowed functions.

So what can you do to stop unwarranted use of media streams on your network?

Surely it is easy? Block the ports at the firewall.

Staff are using peer-to-peer clients with floating ports? That's OK. There is a plan B. Identify the video streams by packet inspection and kill them.

If plan B causes the company's IP-based video conferencing system to stop working, you can move to plan C: label the corporate video using multi-protocol labelling switching (MPLS) at source, and then kill anything that does not have the correct label.

If the network does not support this, and only your wide area network provider can manage that, move to plan D

The situation gets worse for the IT director when management gets in on the act, demanding, "Stop all this streaming media, but make sure I can still get it." Now we have to let the content through the firewall and then try to deal with it. If only there was something that could be done at an individual level.

How about whitelisting applications at users' desktops? IT security professionals are well used to blacklists - stopping known illegal operations from occurring. Whitelists offer a slightly different approach, by only letting known approved operations occur.

SecureWave's Sanctuary product allows you to lock down individual desktops so that only registered applications can be run. This will stop anything along the lines of Mediaplayer from running, and it will certainly kill any dodgy downloaded peer-to-peer application.

The powers that be can still watch their summer of sport, as they can be registered as having the need for the requisite application. Everyone else finds that they do not have the application, and even if they try to install it, it will not run.

The trouble with this approach comes when people need Mediaplayer for a legitimate corporate purpose, such as watching the chief executive's latest guff on how downsizing is right for the organisation, while he takes another 50% bonus rise.

Overall, it looks like this is the familiar onion approach - you will need to look at the various layers of a system to ensure that you can stop the bad and allow the good.

However, one final plan, plan E, takes a different approach - allowing people to stream media.

This need not necessarily kill the network - using proxy servers and real-time caching can create a set-up where, instead of multiple streams of the same content clogging up the Wan and the main corporate backbone, single streams can be used to populate proxy caches closer to main points of use. It still hits the network, but at least it is controllable.

If nothing else works, next time, bung a television in the corner of the office, give the remote control to the senior person in the department and watch the arguments. In any case, if you are in the UK, make sure you have a television licence.

Clive Longbottom is service director at analyst firm Quocirca





Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in August 2006

 

COMMENTS powered by Disqus  //  Commenting policy