“Education is the most powerful weapon which you can use to change the world.”
– Nelson Mandela
I recently came across a report from Omdia entitled, “SIP Trunking & eSBC Strategies North American Enterprise Survey – 2020.” It was a fascinating document filled with illuminating data on how enterprises are jettisoning their ISDN trunks and replacing them with SIP equivalents. As someone who has witnessed the sometimes snail’s pace adoption of SIP trunks over the past 20 years, I was thrilled to see that 67% of the respondents have already eliminated their ISDN trunks.
The report goes on to state that that 67% will reach 89% by the year 2022. While 89% is still below what I would like to see, it appears that we’ve crossed the chasm and SIP has become mainstream, and dare I say it, expected.
Changes
We embrace change because of the benefits, but all change has the potential of bringing disruption, risk, and retooling. It’s that last point that I plan on addressing today — the retooling of business practices that come with a SIP migration. Specifically, I want to discuss those tools related to security.
While ISDN does not lack its own set of security concerns, they are significantly different from those that come with SIP. However, that doesn’t make ISDN the safer choice. In fact, there are a number of security measures that can be applied to SIP that are not possible with ISDN. For example, SIP communication can be encrypted. That isn’t possible with ISDN. Anyone with physical access to an ISDN connection can listen to every word spoken on those shiny copper wires. With encrypted SIP, the risk of eavesdropping can be completely eliminated.
Holistic Security
When you contemplate security, it’s essential to view it holistically. Simply put, this means you must be concerned with all attack surfaces. For SIP, this includes all the physical, software, network, and human interfaces that are associated with SIP communication. Additionally, it’s important to examine where all these attack surfaces interconnect and work together. These handoff points can often be the most vulnerable strike zones for hackers.
Central to any SIP security approach is the Session Border Controller (SBC). Simply put, an SBC sits between an enterprise’s private network and the public Internet. Its primary purpose is to monitor, evaluate, modify, and route all SIP traffic that enters and leaves the enterprise. This includes SIP trunks for traditional carrier-like connections, to the “SIP line” functionality used to support SIP endpoints. A properly configured and maintain SBC can recognize, report, and stop malicious activity before it has the opportunity to do significant harm.
It has been my experience that most successful attacks could have been stopped by an SBC, but the enterprise failed to properly secure their SIP traffic, didn’t pay attention to what their SBC was trying to tell them, or both. SBC logs are a valuable tool to finding and stopping SIP attacks, but all too often they are ignored.
I have often heard people say, “My carrier has an SBC. Why do I need one?” My response is simple. “You may live in a gated community, but you still lock your doors.” In other words, you can’t let security be someone else’s concern. It’s important that other entities are doing everything they can to create a secure network, but that is never an excuse to be lax in your methodologies.
Beyond the SBC
Beyond the SBC, session management can provide another line of defense. Here, security can be applied outside a particular ingress or egress point. You can almost think of session management as the umbrella that protects and manages disparate SIP entities as a whole. For instance, SIP rate limiting can be set and applied to all traffic that flows through every one of an enterprise’s SBCs. The same can be said for authentication standards assigned to SIP methods. Here, session management can decide that all INVITE methods are challenged with a “407 Proxy Authentication Required” response.
SIP security responsibilities also extend to managing endpoints and SIP enabled applications. Here, we can apply policies that determine encryption, supported devices, and allowed media types. For example, an enterprise might decide to reject any endpoint that doesn’t encrypt its SIP signaling with TLS and/or media with SRTP. The allowed types of encryption can also be enforced. It might also determine that only a certain endpoint of a particular vintage is allowed to send or receive telephone calls. All other devices can be blacklisted as security threats.
There are also the physical concerns. This can be as simple as ensuring that access to the servers and network devices that house and enable SIP services is tightly controlled. While we typically think of security in terms of software and network traffic, who can physically touch and possibly disable or change a SIP component should not be ignored.
Lastly, there is the human factors that effect SIP security. This typically is dealt with by training users to recognize and not fall prey to voice phishing. While this is not unique to SIP users, SIP technology in general has allowed hackers to accelerate their attacks. Thanks to cloud SIP platforms, scammers can attack faster and with a much broader reach.
Mischief Managed
As was clearly revealed in the Omdia report, SIP usage is on the rise. While this brings tremendous opportunities for process improvement, cost savings, and digital migration, it carries the risks of toll fraud, information loss, and business disruption. Thankfully, there are tools and methodologies to enable the former while mitigating the latter. These need to be understood and carefully cared for and tended, though. That all begins with thinking and acting holistically.