Meet the Bloggers Twitter BTSecureThinking YouTube Channel Blogroll About BT Looking for more?
BTSecureThinking Resources center

Posts tagged - UCC

Friday, August 13, 2010

Five Common Myths of Unified Communications

By Douglas Drew, Christopher Heinz, Senior Consultants, BT

Information technology is fundamentally about enabling business communications. Yet when business owners consider a technology to facilitate this process, they often face resistance from the information security team.  Open communications and information security are diametrically opposed.

Tremendous power and capability are to be gained with the deployment of a Unified Communications and Collaboration (UCC) solution.  However, a lack of clarity around UCC needs and their security implications can hinder the deployment.  The issues may not be as clear as they would seem on the surface — we’ll call these the “myths” of UCC Security challenges.

Myth #1: We have to open the firewall up too much.

When considering deploying a UCC solution, the conversation often ends at the firewall.  “I will not be able to open 10,000 ports” seems to be a common response, albeit a simplistic analysis.  In an ironic twist, more effective communication between the UCC team and security personnel reveals that those ports are only open to the UCC server.  That permits the deployment of the UCC server within the DMZ and the access controls to limit those open ports to a single server or pair.

Myth #2: Those 10,000 ports are always open.

Those ports are dynamically opened during the call set-up process and are used for the streaming of media.  That means the number and allocation of ports varies during usage, since ports are only open during an active communication session.  Ports are opened on an “as needed” basis, so the claim, “10,000 active listeners,” just isn’t so; reducing available attack vectors dramatically.

Myth #3: UCC communications should be run across a VPN.

Doing so would be redundant.  Current UCC implementations run over SIP-TLS.  That means that the SIP traffic, the actual data stream, is encrypted via TLS.  TLS is an encryption protocol functionally equivalent to SSL, which is a protocol accepted for online banking transactions.  Adding a secondary encryption induces significant overhead, possible degradation of service, for little to no gain in security.

Myth #4: Identifying remote nodes will be a security challenge.

Actually, current UCC architecture best practices deploy/leverage Public Key Infrastructure (PKI) for remote node identity management.  PKI is the cornerstone of most secure encryption methodologies, including https.  By deploying/leveraging a certificate server, remote nodes are validated automatically.

Myth #5: UCC security challenges are complex and there’s no one to help.

BT is here to help with a full suite of complimentary information security solutions.  Service offerings include penetration testing, scheduled remote scanning, etc.  Please contact your local BT account manager for more information.

Have we missed a myth? Please add to our list by posting a comment below.