Once I was doing an investigation of a network compromise discovered when an IDS signature tripped, indicating a worm propagation during a new sensor install. As the investigation unfolded, I tried to locate the source IP in the asset database and came up empty. Further investigation and lots of subsequent phone calls identified the box as a PC in a conference room. The PC was tied to a video conferencing system running a default OS installation as well as software collaboration tools such as Microsoft NetMeeting. During the postmortem, I found out that a VTC reseller had provided the PC as part of a bundle and the internal IT guys had never reconfigured or rebuilt it with an approved Windows image. Since the IT guys didn't know it existed, no agents were installed on the box, it wasn't properly patched and it wasn't running any of the standard build's applications or security programs. Apparently the box wasn't put into production as a part of any maintenance window, and no history of the PC was found in the change management system either.

By now, you're probably wondering how this could happen. After all, it's not like you can just plug a PC into the wall jack, configure DHCP and a default route, and get on the network. Or can you? In this particular case, the network architects ran a test network, essentially a non-production playground for building and testing new applications and tools. Apparently, someone configured a couple of cross-connects in the right places to bring this network into the conference room. It probably started as a pilot project or vendor bake-off that slipped right into fulltime use without ever getting redeployed into production. I know what you're thinking. This would never happen on my network. Not on my watch. Not at my company. But I have to tell you that after more than 15 years in IT, I've yet to meet a CTO, CIO or other IT executive who could tell me they knew every device and all the applications running on their networks.

The whole scenario was a case study in what happens when IT and security are cut out of the deployment process for new telepresence applications.

Deploying applications within the IT systems management paradigm is critical to ensuring application performance and security. Yet time and again I've seen visual collaboration systems deployed outside of the best practices and visibility of IT and security, a blunder that can turn into a real executive management nightmare if gone unchecked.

A fundamental lack of cooperation and integrated delivery between the IT, security and telecomm groups dramatically increases security risks when it comes to deploying new technologies like VoIP, telepresence and collaboration. Security is seen as the great roadblock to getting anything into production and is routinely left out of project planning and milestone reviews. Though it's supposed to be all about risk management, not risk avoidance, security all too often becomes a business inhibitor instead of a business enabler and gets cut out of the picture. I predict this will only change when security teams provide true risk mitigation support and view the groups they serve as internal customers.

Convergence is here to stay, and our technology organizations need to reflect the integrated nature of enterprise applications and networks. Silos responsible for telephony, audio/video and IT no longer make practical sense. Telepresence systems should be deployed like any other enterprise application and be subject to company governance and process controls.

About the author: Brent Houlahan, CISSP is a member of the Human Productivity Lab's Board of Advisors, writer and independent consultant who most recently served as the CTO and VP of Operations at NetSec, an MSP acquired by MCI in February of 2005 and as Vice President of Managed Security Services at MCI. E-mail Brent at: Brent.Houlahan [at] HumanProductivityLab [dot] com