We offer more fraud mitigation tools than any other carrier. We give data away freely which is used by others in their own products and networks. Finally, we go out of our way to educate and inform, in the hope of helping the industry thwart this threat and, quite frankly, to give our customers a better chance of avoiding a business-busting attack. Our business could be quite literally ten times the size if we took the reactive token-gesture approach of some of our competitors but that conflicts with our values. We’ve nevertheless doubled in size again in the last twelve months, hopefully with customers that’ll be with us for the long-term, because you like what we do.
From that position I have in the past got somewhat grumpy with those unable to help themselves and this was the premise for a talk I gave with ITSPA alongside the Convergence Summit South. I only had two 10 minute slots (part 1 and 2 slides) so couldn’t give the “full talk” and instead discussed the last year – why we’d written our VoIP Fraud Analysis, some of the people I’d met along the way, and moreover the lessons learned. I was deliberately a little bit confrontational, saying ITSPs were walking around with a “mug me” sticker on their forehead and suggesting that from the experience of many many talks over the last year, they’d leave the room and do nothing, but goading them to prove me wrong. I’ve said the same in blog posts over the last year too, the old adage of being able to lead a horse to water but being unable to make it drink, continuing to prove true. One competitor in the room made copious amounts of notes so some of the features we offer may make it into their platform to some degree at some point – they’ll be years after we implemented them and not as good, I’m confident – but when we reject traffic for a hacked customer who then overflows it to them (and they complete it) there is little point us rejecting it in the first place!
Against that background we’ve had two really interesting support tickets that I wanted to discuss. The first, was from a long-standing customer who quite regularly receives blacklist alerts which are standard and enforced across every account. These alert to calls we reject heading for known bad numbers, both those from our various feeds and critically the “test numbers” we identified in VoIP Fraud Analysis that are used to prove a compromise sometimes long before a visible attack. This particular customer has these alerts sent by SMS as well as to his engineering team and is one we have reached out to manually in days gone by before they were sent automatically. We know this has proved valuable and is appreciated. However, some weekends ago the customer concerned exhausted his credit limit with calls to Cuba. He promptly opened a support ticket along the lines of “I’ve been hacked and you didn’t tell me”, to which we replied in a more polite form of “You haven’t configured any settings – it isn’t magic. The reconnaissance for this attack could have been weeks ago and you’d probably have had blacklist alerts then.” Said customer still has no limits configured on his account.
By complete contrast, a newer customer had a zero-cost hack today. Unlike longer-standing customers who tend to have a single IP-authenticated trunk with us, this customer has trunks configured Simwood-side for each end user. That immediately makes the default blacklist alerts more useful as they uniquely identify the trunk with the issue and enable it to be disabled without affecting the overall account. It also means each trunk gets a set of default limits which apply some of our more advanced features out the box. Ironically, this customer hadn’t configured any limits himself either and the basis of his support ticket was confusion over why we were blocking his calls! One of his end user installations was compromised and within the space of 15 minutes we rejected nearly 16,000 calls from them before the trunk was disabled altogether manually. Initially the default limit of 1 call to known hotspot countries per 12 hours kicked in once the second call to a problem area had been detected. It is pure luck that the first call to a problem country some hours before didn’t answer, but the result is that this intrusion cost our customer absolutely nothing. He quite rightly did not overflow the calls we had rejected to another carrier, he quite rightly used trunks per end-user and whilst he hadn’t specifically configured any settings for that customer, the defaults did their job.
The relevant settings only have default values configured when using trunks, and are only a subset of the features that can be applied at both account and trunk level. These settings have always been available in our API but are now easier than ever with our new portal. Whilst I can appreciate the satisfaction in making me grumpy, and I feel the release in insulting a room full of people, we’d all be much better off if customers configured the features available to them! Non-customers: our message to you is either beat up your carrier to copy them faster or move your traffic to Simwood! You can sign up for an account instantly online and have the benefit of these today.
Now, what are you going to do?
