“Kelly was a seaman, and his life on the water followed a strict routine, which meant observing all the safety rules that had been written in the blood of less careful men."
- Tom Clancy
We have all fallen prey to a false sense of security. Whether it’s being laid off from a job that we were positive was safe or having a house robbed after installing an alarm system and security cameras, life teaches us that absolute safety is impossible, and reasonable safety requires constant vigilance. It’s never a one-and-done affair. Instead, safety is a never-ending series of enhancements, refinements, and most importantly, careful monitoring.
What is true in our personal lives is also true in business practices. Securing corporate assets requires a dedication to a job that can never be called complete. Installing a security device or implementing a service and never touching it again is nearly as bad as doing nothing at all.
Sadly, the one-and-done attitude is far too prevalent when it comes to
securing SIP. Enterprises finally understand that a session border controller (SBC) is an essential component in their SIP architecture, but all too often, they don’t do much with it once it’s up and running. Like data security, though, communications security is constantly evolving. Just like updating virus definitions on your McAfee and Norton virus checkers, SBCs require constant care and feeding to ensure they are properly protecting an enterprise’s communication traffic and resources.
Taking Steps
I hate making blanket statements, but I feel comfortable in saying that if you were to look at your SBC logs, there is a 100% chance that someone (or more than one someone) is trying to hack you – probably right now. You will see registration attempts that sweep through your extension list (e.g., 1000, 1001, 1002, etc.) as well as pick a particular extension and try various passwords hoping to find the right one. Without protection, a 4-digit telephone password can be hacked in seconds. Longer passwords take more time, but if nothing is done to stop the hackers, they will eventually succeed.
Preventing these brute force attacks is nearly impossible, but taking steps to thwart hackers from getting into your system are not. Something as simple as temporarily locking an extension after a set number of failed registration attempts can increase the time-to-hack from seconds to years. Hackers will move on to easier targets if they find themselves wasting their time.
Beyond invalid registration attempts, an SBC log will shine a light on many more irregularities. These include SIP user-agent types not supported by the enterprise, IP addresses from very questionable locations, malformed SIP packets, DoS and DDoS attacks, unsupported Codecs, Call Walking, and unencrypted media or SIP signaling. Knowing the methodologies hackers are employing is vital to stopping their attacks.
Unfortunately, SBC logs are only as good as what the SBC vendor puts in them. You can’t see messages that weren’t logged. Also, while every SBC I am familiar with allows an administrator to set log levels to control how much is captured, the highest, most complete log levels create enormous files that make finding problems more complicated. Keep in mind that higher levels may negatively impact performance. Most vendors advise that they be used sparingly.
While log files are an essential part of problem discovery, they aren’t nearly enough. To go deeper, an enterprise may need some form of penetration test that exercises an SBC’s security settings in order to find and repair weaknesses. This test may take the form of an on-premise tool or be cloud-based. I prefer cloud-based because that is how the hacker is going to attack. Cloud services can also scale up and down to suit an enterprise’s needs and architecture. A large enterprise will often have SBCs from different vendors in many geographies and the cloud offers that best coverage.
While communications attacks that come from the outside-in get the most attention, attacks from the inside-out can be just as devastating. Therefore, penetration testing needs to be applied to both the ingress and egress paths of an SBC.
Beyond testing your SBC by trying to break it, it’s extremely important to perform regular configuration audits. Hackers love coming upon an SBC that hasn’t been properly configured. I will venture to say that the most damaging and expensive SIP hacks were due to an SBC that had the ability to stop the attack but was not setup to do so.
Configuration audits examine every configuration item on its own and in relationship with the others. This is essential because a well-maintained SBC will be regularly changed and it’s not always easy for the technician to know how changes in one area affect another. Additionally, enterprises often deploy multiple SBCs, and it’s critical to validate that their configurations are in-sync.
Bots to the Rescue
I am a big believer in bots for customer experience, but they also play a role in security. Unlike a virtual agent bot that impersonates a human being, an SBC security bot orchestrates a collection of software tools that are automatically applied to a running service. The results of these checks are then analyzed by an AI engine that looks for anomalies, inconsistencies, and configuration errors. These bots can be launched ad hoc or be scheduled.
Bots also play a role in SBC log analysis. What might be difficult for a human to find, a well-trained bot can quickly identify. The bot can also suggest remediation for discovered problems.
Mischief Managed
Telecom fraud amounted to around $28 billion in 2018, according to
the Communications Fraud Control Association (CFCA). It’s the responsibility of every IT department to ensure that they are not contributing to those losses. In addition to lost money, communication hacks disrupt business and may cause consumers to shop elsewhere.
Properly maintained and cared for, an SBC is a key component in perimeter security. Ignored, it’s almost as bad as not having one at all. Don’t let a false sense of security be your downfall.
