Introduction

Scammers try to use some SMS sender names to impersonate companies or organisations. For example they may pretend to be courier companies, banks, or HMRC. To combat this, the mobile phone operators maintain a list of protected sender IDs/names and use it to ensure those names can only be used by the services/organisations/companies they refer to. They call this 'Trusted Brands'.

We have our our own list of protected sender names, containing both government and non-government sender names. The non-government sender names are populated from the 'Trusted Brands' list like so:

1. we parse 'Trusted Brands' list (that we get in the form of spreadsheet) to extract only the non-governmental sender names
2. we put those in a database table that we put extra protections around

How to update the db table with new protected sender names

Daniel of MMG will send us an excel spreadsheet once a quarter. Once he does, we then follow these steps:

1. upload it to Google Drive and save it to GOV.UK Notify/Operations Team/Protected Sender IDs
2. export and download this as a CSV
3. use the 'process_sender_names.py' script in the notification-api repo to parse the CSV and generate a SQL INSERT statement

cat $CSV_DOWNLOADED_FROM_BT | python process_sender_names.py

Check the list to make sure there are no sender names used by government. We want to only extract non-government sender names. If there are government sender names in our resulting list, this would indicate a breaking change between the script and the data.

If you are happy with the list, wrap it in BEGIN and COMMIT commands and run the INSERT in preview, staging and production, using write access. It should be idempotent, meaning that it can be run multiple times without erroring.

This assumes that the list is always increasing, which might not always be true. It is left as an exercise for the reader to figure out what to do if the list shrinks.

Protections

We prevent our services from setting their sender id to one in our protected sender names database table when they try to change it in the admin app, as part of validation. We also raise a Zendesk ticket to show we suspect that there might be malicious activity on their account.