Mitel PBX‎ > ‎

Credit Card Fraud (express messenger in a hospitality setting)

It has long been established that if you allow unattended transfers to guest rooms, it will only be a matter of time until the property receives complaints of credit card fraud.  Malicious callers will impersonate hotel staff saying there's a problem with the bill and they need to reenter the credit card information.  This is one reason why it is a common brand standard that house phones not be able to dial guest rooms directly.  It's also a terrible idea to allow VM to access guest rooms without requiring an attended transfer; there are two common attack vectors.  1) Whether or not the auto-attendant announces the ability to dial guest rooms directly, malicious callers will attack auto-attendants by trying to dial guest room extensions, which are easily guessable.  2) Another attack vector is to call a property late at night and request to speak to a manager.  It is a reasonable assumption that the manager will have gone home for the evening.  Once the malicious caller gets to the manager's voicemail box, they will attack the system by trying to transfer to guest room extensions.

In innovations voicemail systems, it is very easy to prevent these attack vectors.  With Mitel Express Messenger (and embedded as well), it is much more difficult.  That's what this article covers.

On 200 ICP platforms, Form 49 offers a feature called "Auto Attendant XFER Restrictions."  This might sound like an easy feature to prevent guests from suffering fraud, but it's not.  This feature only applies to trunking.  Further, consider properties that don't have clear separation of dialplan.  I can think of a lot of properties that use 7xxx for guest rooms, and also use 7xxx for administrative extensions.  So even if this feature prevented inside transfers, you wouldn't be able to put '7' in this field because it'd cause collateral damage.  Anyway, here's what docs says about this option:
AUTO ATT XFER RESTRICTIONS: A programmable field used to prevent callers from accessing system trunks via the Auto Attendant. Access is prevented by programming the system to deny transfers when the leading digit dialed matches the first digit of a trunk group access code. Up to 10 digits can be entered. Separate each digit with a comma.

So let's understand what we need to accomplish.
  1. Prevent VM from allowing transfers to guest rooms without preventing other transfers.
  2. Allow guest rooms to call VM.
  3. Allow embedded recorded announcement devices to reach guest rooms so wakeups can go through.
  4. Allow VM MWI ports to reach guest rooms so the message indicators can be updated.
We can accomplish this using tenant restrictions.  

First let's define our tenants.  The examples provided need not be a guideline.  When creating these restrictions, you want to take a look at where things are already and use tenanting in whatever way makes the most sense and requires the least amount of provisioning.  Using tenant 1 for trunking usually makes sense because tenant 1 is the default tenant and re-provisioning the console and trunks can take a bit of juggling in a live system.
  1. Tenant 1 will be used for trunking.  All trunks will be provisioned in this tenant.  Optionally the console can be in this tenant.
  2. Tenant 2 for house phones and any other phone that won't have coverage provisioned in form 19.  So We'll also use Tenant 2 for our RAD and MWI voicemail ports.
  3. Tenant 3 for administrative extensions.
  4. Tenant 4 for VoiceMail ports.
  5. Tenant 5 for guest room extensions.

The first thing to do is set up Form 19 so that when you move stations into their new tenant, they'll work properly right away.  This is particularly important in case someone happens to pick up the station and dial 0 while you're working on re-provisioning the system.

The next most important thing is to provision Form 6.  You need asterisks across row 3 (and row 1 if the console is in tenant 1).  This way, whenever any station in tenant 3 (or tenant 1) changes the night service mode, it'll also update the other tenants.  Now take a moment to remember that when the system boots, it comes up to night1 mode.  So if Form 6 had never been provisioned, we next need to ask a front desk agent to toggle the system to night1 service and then back to day service (or whatever service mode they normally operate in).  This will bring all our tenants into the same service mode.

Next comes the hard part: re-provisioning all the guest room extensions to their new tenant.  You'll probably run into some locked or busy ports.  I like to just make note of them, continue on, and try them again later.

With the rooms re-provisioned, you can proceed to re-provisioning the admin and house extensions.

So now everything is done except for the voicemail ports.  Before re-provisioning them, we need to understand a couple things.
  1. Every EMEM port should always be provisioned.  It doesn't matter what the extension is, but it matters that every port have an extension.  EMEM can crash if all the ports aren't provisioned.
  2. Y0u need to know how many EMEM ports are active on the system.  The number of active ports is determined by the system option type (business 1, business 2, hospitality, etc) and the number of DSP resources available.  Docs provides a chart to explain this, but you can quickly ascertain the number of available ports by (from the maintenance terminal) going to reports -> show -> status -> voicemail.  The number of ports that gets listed tells you how many ports are active.
  3. Embedded Recorded Announcement Device ports should be provisioned in the middle of the active EMEM ports.  If you have 8 active ports, the eRAD ports should be 4 and 5 (I like to have at least two to better accommodate simultaneous call volume).  If you have 18 EMEM ports, I'd assign ports 8-11 as eRADs.
    BECAUSE eRAD ports need access to guest rooms, they must not be in the restricted tenant.  Following our example, that means they'd be in Tenant 2.  NOT Tenant 4.
  4. Message Waiting Indicator ports.  The last active port will be used for sending MWI updates.  If you have 18 EMEM ports, port 18 will send MWI updates.  If the last port is not available to send the MWI update, the next-to-last port will be used instead.  If both the last ports are busy, the third to last will be used.  And so on.  This means that based on the size of the system, you'll want to reserve 1 or more ports for sending MWI updates.
    LIKE eRAD ports, MWI ports also need access to guest rooms; they must not be in the restricted tenant.  Following our example, that means they'd be in Tenant 2.  NOT Tenant 4.
That's it!  Provision all the remaining active voicemail ports in the restricted tenant (tenant 4 according to our example).

There's just one last thing.  Go to Form 5.  Following the tenanting example provided above, in row 4 you must disallow access on column 5.  This will say any station in Tenant 4 will not be able to connect to any station in Tenant 5.

That's it!  Now if you call VoiceMail and try to transfer to a station, voicemail will attempt to perform the transfer, but will be blocked by the tenant restriction.  The station will not ring, and eventually VM will return an error saying the transfer could not be completed.  There is no cleaner way to prevent credit fraud in the Mitel 200 platform using Express Messenger.