Industry Prevention

Well first off, you can’t have it all.

So, you need to consider whether the methods you deploy also automate crime, this can usually be done from the selling points

  1. So Intuitive Anyone can do it
  2. Your phones can work from any location or device
  3. You can access the VoIP provisioning portal away from your site, to forward calls if you cannot get into the office

So the automating crime requirements from this are

  1. Intuitive means ANYONE can do it, even if they have malicious intent
  2. There is no geographical limitation in utilising our services
  3. There are no access restrictions based on location

So, you don’t white list IP addresses, you don’t restrict access to the service, and you make it easy.

Which means you now need to consider some

Industry Prevention

At a high level

  1. Alarm Monitoring systems need to be in place for at risk features and configuration
  2. IF an at risk account has its password reset, this also needs to notify other individuals in the group.
  3. A user of the same level cannot administer another user of the same level, it must always come from the level above.
  4. You need to cluster at risk features for an activation process in the first instance

So often you find that a Group Level User (above the extensions level) can create other group level users, can administer those users and more importantly can utilise at risk services without anyone else knowing that these have been put in place.

So, if I were to gain access to one of your customers emails, this would by proxy likely give me access to their VoIP provisioning account, from there, I can freely do whatever I like for that level and below.

Cluster At risk features

So in order to apply at risk features or manipulate them at an enterprise or group level, this should be an on/off setting that can only be manipulated by the reseller/service provider (on the assumption that these are secure accounts), this would be used differently for different services

When this is turned on, an email should generate to certain individuals in the VoIP service provider so that they can carry out due diligence checks.

It is unlikely that consumers use these services, so

On/Off function should control

  • Call Recording – Allowing the service to be provisioned for the first time (say group level)
  • Call Listen/Call Barge/ Silent Call Barge – Allowing the service to be provisioned for the first time (say group level)
  • Call Notify – Allowing the service to be provisioned for the first time (say group level)
  • Calling Plans – Visible access to the service from Group/Enterprise levels and below
  • Call Redirect services – Allowing the service to be provisioned for the first time (say group level)
  • CoS (Class of Service) – Visible access to the service from Group/Enterprise levels and below

In addition, not previously mentioned but still merit additional consideration

  • Device/Extension Twinning
  • UC applications

So, most of these are not needed by the vast majority of consumers, but they are likely just available to them to either purchase or to apply if part of a purchased licence, this is not an acceptable approach.

Calling plans and CoS would be configured on customers, but it is very unlikely that they need to see these themselves, so they shouldn’t be visible to everyone.

As a VoIP service provider, you must assume that your agents and re-sellers accounts are not secure by design, as it would rely on unknown quantities, so if they are manipulating these services, you should be made aware.

Alarm Monitoring systems need to be in place for at risk features and configuration

Service Provider level

The first time any of these services are manipulated for a customer group, this should notify the VoIP service provider (a few people or a shared inbox), it takes a few seconds for you to then contact the customer via an alternative method (like a mobile number) to make sure this is them.

You can have a pop up on screen letting them know you will contact them so it is not unexpected, that would also be a deterrent for the person about to commit fraud.

Customer level

Anytime one of these features is applied to a group or extension for the first time, this should notify at least 2 email addresses at the customer level, these email addresses should not be configurable at the customer levels (i.e. if the customer level can amend, and I access at the customer level, I amend these and then I make my changes)

IF an at risk account has its password reset, this also needs to notify other individuals in the group & A user of the same level cannot administer another user of the same level, it must always come from the level above.

  1. Extension users should not be able to reset passwords, but rather need to talk to their group administrator (NORMAL IT PROCESS)
  2. Group users should contact enterprise users
  3. Enterprise users are debatable, is it safer for them to reset it themselves or is it safer for them to talk to an Agent/reseller for a password reset?

In any case, email notifications should be sent to certain users (always to yourself) if your password is reset, then a line manager as well.

A group user should not be able to administer another group user etc.

Why the extra effort, what is in it for you?

These are all selling points, simple to implement, makes you seem a better class than your competitors.

There is nothing here that is complicated, it is all simple, low risk changes, because you operate on the following assumptions

  1. We do everything we need to to protect our consumers
  2. But just in case, we assume our consumers are unprotected, so we have an alarm monitoring system in place.

Same reason why we have locks and bolts in our homes, but then you have an alarm monitoring system on the assumption that if someone really wants to get in, they will anyway.

Anything else?

Yes, but without going into too much detail

  1. If you are a company that develops a user friendly portal for VoIP provisioning, say you have an OSS/BSS front end, that say provisions into a Broadworks VoIP Exchange, at what level can you visibly see the Broadworks user IDs and Passwords?
  2. How are these communicated back to the, for example, Broadworks application by your OSS/BSS front end?
  3. How are these stored in the application?

There is another route in, one that is often not monitored particularly well, being the VoIP exchange GUI.

I can’t really give you more than that without breaking the rules for publishing the articles, ‘it cannot be a training guide for cyber criminals’

So far we haven’t broken that rule for one simple reason in the new VoIP world

Our system are so intuitive anyone can do it

Because that is true for VoIP, and anyone can set up the system, interpret the bills, add the required features, it doesn’t matter if I am the customer or someone posing at them, according to the VoIP industry, this is easy to do.

We summarise on the next page

Previous PageNext Page

Back to How I Would Commit Cyber Crime