VoIP security for business

A business discovers a phone bill several times its usual size. Over one weekend, thousands of pounds of calls were placed to international destinations nobody in the company has ever dialled. The calls are real, the carrier delivered them as instructed, and the invoice is legitimate. There is no fraud department to appeal to, because from the carrier's point of view no fraud occurred — the system authenticated correctly and asked for the calls.

That is toll fraud, and it is the dominant threat to business voice systems. It is unglamorous, entirely automated, and it happens because a phone system is one of the few pieces of infrastructure that converts a compromise directly into cash for the attacker without needing to sell anything on.

The security work that matters is therefore not primarily about preventing compromise, which is difficult, but about capping what a compromise can cost, which is straightforward and mostly configuration of equipment already in place.

What is actually attacking a phone system

A SIP service reachable from the internet receives automated scanning continuously. It is worth separating the threats, because they have different objectives and different controls.

The last row is consistently underestimated. Businesses spend effort encrypting calls in transit and then leave months of recordings on a disk with broad access and no encryption. The recordings contain everything the calls contained, at rest, indexed and searchable — which makes the archive a more attractive target than the live traffic.

Capping the loss before preventing the breach

This ordering is deliberate and it is not the usual one. Preventing every compromise is not achievable; making a compromise worth very little is. Four controls do most of that work.

1. 1

   Set outbound dialling permissions per extension

   Most extensions in most businesses need local and national dialling only. Grant international access to the specific extensions with a business reason, and premium-rate access to none unless something genuinely requires it. This is the control that determines whether a compromise costs pounds or thousands.

2. 2

   Apply a spend cap with the carrier

   Most carriers support a credit limit or a spend alert. With one, a successful attack has a ceiling. Without one, it has a weekend. This is a five-minute conversation with the provider and it is the difference between a bad Monday and a serious one.

3. 3

   Restrict destinations at the route level as well

   Blocking destination ranges the business will never legitimately call — satellite, premium and known high-fraud prefixes — removes the profitable targets entirely, regardless of which extension is compromised.

4. 4

   Alert on the pattern, not the total

   International calls outside working hours, a sudden change in call volume, repeated calls to one unfamiliar destination. Toll fraud is normally discovered on an invoice weeks later; these signals surface it within the hour.

The fourth step is worth being specific about. Fraudulent traffic has a distinctive shape — high volume, out of hours, to a narrow set of destinations, from one extension. Any of those alone is unremarkable and the combination is not. A rule watching for it costs nothing and is the difference between a loss measured in hours and one measured in weeks.

Then reduce the chance of compromise

With the loss capped, the controls that reduce the likelihood of a successful attack are conventional and worth applying properly.

• Do not expose SIP to the entire internet where it can be avoided. Restrict by source address to the carrier's published ranges and to known sites, and put remote workers behind the remote access architecture rather than opening registration globally.
• Use strong, unique secrets on every extension. Weak or default extension passwords remain the most exploited weakness in this class of system, and an extension password that matches the extension number is still found in production regularly.
• Rate-limit and ban on repeated authentication failures, so a registration brute force is stopped rather than merely logged. Tools that watch authentication logs and add firewall rules automatically are standard practice here.
• Disable what is not in use. Unused extensions, default accounts, unused trunk contexts and administrative interfaces that nobody needs are all attack surface with no offsetting benefit.
• Keep the platform patched. Voice platforms are software, and the same deferred-maintenance failure that affects everything else affects them, with the added property that a compromise is directly monetisable.
• Separate the voice network from everything else, so that a compromised handset cannot reach servers and a compromised workstation cannot reach the PBX management interface.

The last point connects to segmentation rather than to voice specifically, and it cuts both ways. Handsets are appliances that are rarely patched and often run firmware years old, which makes them a plausible entry point onto a flat network. Keeping them in their own zone protects the rest of the estate from them and protects the phone system from a compromised laptop.

Encryption: what it protects, and what it does not

Securing calls in transit means TLS for the SIP signalling and SRTP for the media. Both are standardised and widely supported, and both are worth enabling where the carrier and the endpoints allow it.

SRTP is defined in RFC 3711, which describes it as a profile of the Real-time Transport Protocol providing confidentiality, message authentication and replay protection to RTP traffic and to the control traffic for RTP. The specification is also clear about its limits: RTP headers remain partially visible, and the security of key management is outside its scope.

Two practical caveats matter more than the cryptographic detail. Encryption protects the leg you control — typically between your platform and your carrier, and between your platform and your endpoints. It says nothing about what happens once the call leaves the carrier for the wider telephone network. And it protects audio while it is moving, which has no bearing on the recording written to disk afterwards. Encryption in transit and encryption at rest are separate decisions and a business that has done the first often believes it has done both.

Recordings are the concentrated risk

If an attacker had to choose between intercepting live calls and taking the recording archive, the archive is the better target by a wide margin. It is complete, it is at rest, it is usually searchable, and it contains whatever customers said aloud — which routinely includes payment details, health information and personal data that would never be typed into a form.

• Store recordings somewhere other than the PBX. A platform that stops working because its disk filled with recordings is a common and entirely avoidable outage, and the separation also lets access control differ between the two.
• Restrict who can listen, and log the access. Retrieval of a recording is an event worth recording in its own right, because the question during an investigation is who listened rather than who could have.
• Encrypt at rest, and decide that separately from transport encryption.
• Set a retention period with automatic deletion, rather than accumulating until something breaks. This is covered in more depth in the retention article.
• Keep payment card details out of the audio path entirely — pause recording around the payment step, or take payment through a mechanism that keeps the digits out of the call. Removing card numbers from an existing archive is far harder than never capturing them.

The last item is the one to design in rather than retrofit. A recording that never contained the card number needs no remediation; an archive that contains thousands of them is a problem with no clean solution.

Caller ID spoofing works in both directions

Caller ID was never designed as an authentication mechanism and should not be used as one. Two distinct problems follow, and only one of them is technical.

Outward-facing, an attacker can present your numbers when calling your customers, which is a reputational and fraud problem largely outside your control. Mitigation is mostly carrier-side, and the frameworks that address it vary by jurisdiction; the practical step available to a business is to ask its carrier what verification they apply and to publish guidance to customers about what the business will never ask for by phone.

Inward-facing is the part fully within your control and the part more often exploited. Any internal process that treats a phone call as proof of identity — releasing information, resetting a credential, approving a payment, changing bank details — is exploitable by anyone who can spoof a number, which is not difficult. The control is procedural rather than technical: no action with financial or access consequences is completed on the basis of an inbound call alone, and a callback to a number held on record is the minimum verification.

Emergency calling is a legal obligation

This sits alongside security because it is the other regulatory dimension of running a phone system, and it is the one most often missed entirely. In the United States, two federal laws apply to multi-line telephone systems, which is what a business PBX is: Kari's Law requires that a user can dial 911 directly without first dialling a trunk access digit, and that the system provides notification when such a call is made; Section 506 of RAY BAUM'S Act requires that a dispatchable location is conveyed with the call.

Remote and home-based extensions make this an architectural problem rather than a configuration setting, because a softphone registering to a distant platform has no inherent location. The call centre article covers the requirements and the remote-agent case in more detail. Businesses operating elsewhere face equivalent obligations under their own regulators rather than none.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A business receives a phone bill roughly six times its normal value. The traffic ran over a weekend, to international destinations, from a single extension belonging to a meeting room.

The extension's secret was the extension number. SIP was reachable from any address because the original commissioning had opened it and nothing had revisited that. Every extension on the platform could dial internationally, because that was the default and no route restrictions had been applied. There was no carrier spend cap, and no alerting on call patterns, so the first indication was the invoice.

The remediation was sequenced by what limits the next loss rather than by what looks thorough. Dial permissions were set per extension the same day, with international access granted to four extensions that had a reason for it. A carrier spend cap was requested. Route-level blocks were applied to premium and high-fraud destination ranges. Alerting was added for out-of-hours international traffic and volume anomalies. Only then were the underlying weaknesses addressed: secrets regenerated across every extension, SIP restricted by source address, automatic banning enabled on repeated authentication failures, and handsets moved to their own network segment.

The carrier declined to waive the charges, which is the normal outcome. The calls were placed by an authenticated system and delivered as requested.

Implementation checklist

• Outbound dialling permissions are set per extension, and international access is granted only where there is a business reason.
• Premium, satellite and known high-fraud destination ranges are blocked at route level.
• A carrier spend cap or credit limit is in place.
• Alerting covers out-of-hours international calls, volume anomalies and repeated calls to unfamiliar destinations.
• SIP is restricted by source address to carrier ranges and known sites rather than open to the internet.
• Every extension has a strong unique secret; none matches the extension number or a shared pattern.
• Repeated authentication failures trigger rate limiting and automatic banning.
• Unused extensions, default accounts and unnecessary administrative interfaces are disabled.
• Handsets sit in their own network segment, isolated from servers and management interfaces.
• TLS and SRTP are enabled where the carrier and endpoints support them.
• Recordings are stored off the PBX, with restricted and logged access, encryption at rest, and a defined retention period.
• Card details are kept out of the audio path rather than removed from recordings afterwards.
• No process completes a financial or access-changing action on the basis of an inbound call alone.
• Emergency calling permits direct dialling without a prefix, provides notification, and carries a dispatchable location including for remote extensions.

Frequently asked questions

Conclusion

Voice security is unusual in that the dominant threat has a direct and immediate financial cost, and unusual again in that the most effective controls are configuration rather than purchase. Dial permissions, a spend cap, route restrictions and pattern alerting will cap almost any realistic loss, and none of them requires new equipment.

The conventional hardening — strong secrets, source restrictions, automatic banning, patching, segmentation — is worth doing and reduces how often the cap is tested. But a business that hardens thoroughly and leaves every extension able to dial anywhere in the world has protected itself against the attempt while leaving the consequence unlimited.