You can’t apply security in just one place and be done with it.
I have been working with IP technology for a long time. I can't tell you the exact year of my first exposure, but it was sometime between 1985 and 1987. I was working at Northern Telecom as a software developer and was tasked with adding a TCP/IP stack to a version of Unix that ran on a Motorola 68010 processor. I sent away for a set of manuals from the Department of Defense (yes, they invented the protocol suite) and eight months and thousands of lines of C-code later, I had something up and running.
As proud as I was of that accomplishment, the work I did back then would be completely unacceptable today. Don't get me wrong; my stack worked very well, and I was able to subsequently add network services such as File Transfer Protocol and Network File System on top of it. The problem wasn't my code. The problem was that I didn't do one thing in terms of security. Anyone with a network analyzer could see every bit and byte that was sent between applications and servers.
Of course, what did we know about hackers and computer viruses back then? The term virus wasn't even coined until 1983 and although the Internet existed, its use was miniscule. The packets sent and received by my software ran on very isolated networks. Quite often, the network was little more than a coaxial cable between two servers.
Everything has changed since those carefree, innocent days. The Internet is everywhere, and everything from refrigerators to wristwatches use it. Hackers are extremely sophisticated, and there are no vulnerabilities that will not be exploited. My unsecure software of yesteryear wouldn't last ten microseconds in today's dangerous world.
The Many Levels of Security
Think about a house and the many places where security measures can be applied. Leaving a porch light on at night can drive away would-be thieves. Alarm systems alert you when a break-in has occurred. Motion detectors inside the house sense improper movement.
IP security is no different. You can't apply security in just one place and be done with it. Like that house, security must be applied on the outside (porch light), ingress and egress points (alarm system), and within (motion detector). Not doing so leads to points of failure that will be found and compromised.
Let's See Some Identification
At the root of most security technologies are certificates. You encounter them when you surf the Web and they are just as vital to any communications solution.
Everyone is familiar with a passport. Passports contain the owner's picture, signature, gender, and a holographic image. The newest forms contain biometric information encapsulated in a microchip that has been embedded into the passport's cover or one of its pages.
Think of a certificate as a digital passport that is used to prove that an IP service is what it claims to be. Imagine navigating to your bank's webpage to check your account balance. A certificate is used to prove to your Web browser that you have accessed the correct site and not a malicious site impersonating your bank.
Certificates in the communications world work the same way. They allow one service to prove to another service that it's the real deal. You find them used by SBCs, voice mail systems, conference bridges, and any number of other IP services. The same way your Web browser needs to be sure it is accessing valid, authenticated Web servers, communications services need to be sure of who they are talking to.
There are two basic types of certificates – public and self-signed.
Public certificates are issued by recognized Certificate Authorities such as VeriSign or DigiCert. There is a cost for these certificates, but the level of trust is universal. These are the kinds of certificates that your bank will purchase and install on their Web servers.
Private certificates are created and issued by a company's internal Certificate Authority and are only trusted within that company. That doesn't necessarily make them unsecure, but the level of trust doesn't extend outside an enterprise's network. You might use them between a session manager and an SBC, but a bank would never use one on its public website.
Like a passport, it's nearly impossible to forge a certificate. If you encounter a public certificate, you can rest assured that it hasn't been spoofed or tampered with.
It's all Greek to Me
The next level of communications security is encryption. In the world of communications, security-minded enterprises encrypt both signaling and media.
Just like my TCP/IP stack of days gone by, SIP started out its life on unencrypted protocols. The first work I did with SIP was all on User Datagram Protocol, which offers no protection to either the sender or receiver of SIP messages. My development work soon moved to TCP, but that was just as bad as UDP when it came to security.
Thankfully, most SIP implementations are now built on something called Transport Layer Security. TLS encrypts all SIP signaling making it impossible for someone to "sniff" the network and gather the metadata of your communications traffic (who called who, etc.).
Smart enterprises encrypt both signaling and media. Media encryption is known as secure real-time transport protocol (SRTP) and offers the same level of protection as TLS. If you don't have the keys to decrypt SRTP, it looks and sounds like gobbledygook.
Newer technologies such as WebRTC realized from the get-go that security is absolutely essential. Like SIP, WebRTC encrypts media with SRTP, but instead of TLS, it uses something called datagram transport layer security (DTLS) to secure its signaling messages. Users of WebRTC services can sleep at night knowing that their conversations are private.
A Secure Network Edge
Like my house example, one of the best ways to ensure security is to keep the bad guys on the outside while allowing the good guys to come and go as they please. In communications, a session border controller performs the job of an alarm system. It sits on the network edge (or border) and guards against malicious attacks, malformed packets, and a number of other dangers that threaten your enterprise.
An SBC can also be used as a way to hide the details about your system (think Romulan Cloaking Device). Hackers use information about communications vendors and software releases to exploit known weaknesses. Creating a shroud of mystery around your implementation may be enough to drive hackers away from you and towards easier, less protected targets.
When I design a communications system, I do whatever it takes to identify and eliminate single points of failure in hardware and software. The same goes for security. A break in the chain or a weak link is almost as bad as having no security whatsoever. 2015 is not 1985, and only the most foolish enterprise would cut corners when it comes to locking down one of their most valuable assets – their typed or spoken conversations.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Hear more from Andrew at Enterprise Connect Orlando 2015, March 16-19, at the session, Interoperability: Has Anything Actually Worked? Register with code NJSPEAKER to get $300 off Entire Event or Tue – Thu pass.
Follow Andrew Prokop on Twitter and LinkedIn!
Andrew Prokop on LinkedIn