We recently had a support ticket which asked what we did to cap losses resulting from fraud. Figuring that everyone followed the continuing drip-feed of features in this area, this is not something we’ve summarised in one place before. So here goes…
Reality check
There are only two types of customers we see:
- Those who have lost money as a result of a compromise or customer compromise.
- Those who are going to lose money as a result of a compromise or customer compromise.
The stakes are huge as the cost to you (and gain to them) is only limited by how long it takes to detect. We operate honeypots which, as the name suggests, exist to be compromised and provide useful data. We once billed calls passed following a successful intrusion to one of them at over £300,000 of call cost in under 24 hours. We blocked the attacker at that time as they were causing excessive logs and we’d got all the data we could use – it would have continued indefinitely.
That honeypot could be your equipment or a customer’s. How would you handle a £300k bill? Moreover, how would you handle a £300k customer debt?
Being big is no defence here. If you’re big you’re a) a higher value target and b) have higher credit limits / balances to burn through. On the contrary, we often find smaller operators are agile and listen!
Guiding principles
We do not want to profit from your (or your customer’s) misfortune.
We try our very best not to pass calls that look like they stem from you or your customer having equipment compromised. Be very clear though, not everyone works this way – just as there are scallywags masquerading as customers or trying to hack your equipment, there are suppliers who take a hands-off approach to your misfortune and enjoy windfall gains as a result. There are others who of course do not know as their processes are so cumbersome and slow or they’re simply reselling and cannot see what is going on under the hood.
We think it is vital to know your wholesale supplier is not only on your side but also working with you, not against you. There’s enough people against you in this industry and we do not want to be one of them.
Caution!
For the reasons we’re about to set out many customers put us first in route. However, if we reject a call because it looks dangerous and you failover the call to a carrier who passes it, we’ve achieved nothing. In fact, if they were second in route because they are more expensive you’d have been better off if we hadn’t blocked it! Whilst putting us first in route is absolutely the right thing to do, you need to ensure your fail-overs are carefully managed or manually activated in the exceptional event of a multi-site outage here.
Measures we take
The following are some of the measures we take to protect you:
- We enforce prepay balances. If your account runs out of credit, we kill calls.
- We block in excess of 7000 known fraudulent numbers from various industry and in-house sources such as our honeypots. If your account passes calls to them, they will not complete and you can expect us to follow up with a support ticket. More often than not, a sudden surge in calls to these numbers indicates compromise with such certainty that we take pro-active action here in disabling your account. That may seem harsh but in these cases your credit will usually be exhausted in minutes anyway and your account disabled, the only difference is you’ll be poorer!
- Our API gives real-time balance and CDR information. As soon as a call is billed it is available in the API and reflected in the balance. Many customers have linked their balance to internal monitoring to raise alerts if it changes too much/quickly.
- Reports of expenditure by destination are also available real-time so you can monitor and alert on expenses to specific areas of the world that concern you in real-time.
- Of course, certain attack vectors rely on a large number of calls left up for a long time and the above would only show finished calls, probably when your credit ran out and we terminated them. As such, we give you the ability to see similar reports for calls in progress! You can view a summary of calls by destination with the accruing cost. This is brilliant to script and trigger alerts on scenarios that may concern you, e.g. more than £5 of calls in progress to destination X = send an e-mail, more than £10 to destination Y = send an SMS, more than £2 of calls in progress at a very quiet time = send a pager. The script and rules are yours to create but we give you the in-progress call data to do it.
- You can blacklist (and whitelist) specific prefixes if your own policy suggests you don’t want to pass calls to them. We will then reject calls attempted to them. This can be configured at either the account or the trunk level.
- On a per call basis you can specify the maximum cost per minute and the maximum connection charge you wish to allow in a SIP header. If our charge would exceed those, we’ll reject the call. You can similarly configure this where you map incoming numbers to PSTN destinations to ensure the calls are profitable.
- On a per account or per trunk basis you can specify rate limits. You specify a limit for non-UK destinations overall as well as calls to a list of countries we consider as ‘known hotspots’. Setting this to x calls per y hours can really take the heat out of a compromise.
- You can use our API to dynamically create and delete trunks (user name and password pairs) linked to your account. In the event of a customer or piece of equipment being compromised, you can delete the trunk out-of-band to contain the damage.
We think the above is more than anyone else in the industry is doing to protect wholesale customers and end-users. There are a few more that we’re working on but if you know of something available elsewhere that we’re not doing, do please let us know.
Why bother?
We sometimes get customers so confident in their own fraud management that they don’t make use of the features we offer, at least until they lose money. Like any security measure it is great having established policies and processes but if they rely on equipment that itself becomes compromised, they’re useless.
A common approach we see is not for customer equipment to be compromised at the SIP level, but instead at the MySQL or <insert well known turnkey PBX product> “control panel” level. Here the attacker can create administrator users, disable fraud checks etc. They can empower themselves to do what they need and cover their tracks.
Having your own processes and checks is diligent and necessary but we also think you need protection outside the control of the equipment being compromised. Our API can (should) be securely accessed separately to your voice equipment and can orchestrate much of the above. You are then empowered to diminish the pain of a compromise and limit damage, even if you cannot get access to your own equipment.
Repeat
To repeat the caution above, it would be very sad for you to implement some of the features above as well as your own but then receive a large surprise bill through because you overflowed to a carrier who didn’t look out for you. We operate multiple sites precisely so customers can rely on us as their only route even though you may want to have a manual standby in-place just-in-case!
