As an MSP you’re the gatekeeper of your customers greatest assets their data and their computer network. Naturally, you are the target of hackers and bad actors as a primary attack vector. A key attack vector is social engineering via your helpdesk. Bad actors are actively impersonating the identities of customers of MSPs and of an MSP technician calling their customers. The objective is to get the MSP to reset passwords for Active Directory and/or Office 365 accounts or to have an end-user provide their credentials so they can distribute and/or deploy malicious payloads for ransomware that will encrypt the customers corporate data.
Why should I verify the identity of my Customers?
Some MSPs will argue that they know all their customers by first name and know their voice so they don’t need to verify their identities. This may be ok in smaller MSP’s that have a limited customer base, a small number of technicians and limited to no turn-over. However, MSPs are growing, getting quite large and can have many customers. There is a point once you start to hit a mid-size MSP where you just can’t know every one of your customers by first name and you have so many techs that turn-over is inevitable. Hackers and bad actors know this and is where the risks become too great.
Case 1: Customer Impersonation
Hacker calls MSP and pretends they are Tom from the Ajax company saying they got locked out of their computer because they forgot their password. Tom is one of the managers at the Ajax company. The MSP technician answers the call and sees that Tom is employed at the Ajax company. The tech has never met Tom nor spoken to them on the phone before because they just started last week. They go ahead and reset the password for Tom and provide the new password over the phone. They end the call and close the ticket for the issue.
About an hour later the MSP gets another call from someone named Tom at the Ajax company saying they are locked out of their account and other employees mentioned they are receiving emails from Tom asking to transfer money and to click a link to provide access to a file on Sharepoint. The tech asks Tom if they remember calling in earlier and they say they never called. Moments later files on the file server are encrypted and requesting a ransom. The MSP realizes they have been dupped and now scrambles to block access to the network and check that they have backups available to restore.
Case 2: MSP Technician Impersonation
A customer receives a call from a tech at their MSP. They say its Randy from their MSP, Secure IT Services. Randy says they detected an issue on their computer and need their password to login to their computer so they can fix the problem. The customer gives the password over and allows Randy to run a remote session to their computer. Meanwhile Randy is not really Randy. They are a bad actor trying to steal credentials from the MSP customer so they can deploy ransomware.
A few hours later users from the customer start seeing their files encrypted on their file server and call Secure IT to report the issue. They say they received a call from Randy earlier to help one of the user’s but Secure IT says that Randy is actually off today and never called. You know what happens next.
How can I verify the identity of my customers?
Now that we have determined that verifying the identities of our customers is important you may be wondering what process I can implement to mitigate these risks.
Option 1: Call back your customers at their registered work or mobile number listed in your PSA system. Conversely, tell your customers to call back the MSP if they receive a call from a technician.
Pros: Straightforward and secure way to ensure that the customer calling is who they say they are. Similarly, for the customer to call back the MSP if they receive a call.
Cons: Adds time to each support call and can be a hassle to have to hang up a call and call back the end-user on their registered phone. What if you don’t have their cell phone registered for the user and they are working from home. Now you can’t be sure it is really them unless you confirm with someone else from the customers office that the number they called from is legit. Now the end-user is frustrated they can’t get their problem solved and the tech just wasted a bunch of time just verifying their customers identity before they can even start to resolve the problem the customer was calling about.
For the cases where the customer has to call the MSP back its an extra hassle for the customer to do this and increases the support incident time when the MSP has to then wait for a call back assuming the customer has time to do this. This may require some chasing of customers to finally get this all sorted out making the experience negative for both the customer and the technician.
Option 2: Add a centralized point of contact authorized to request password changes or other high-level security requests for each customer.
Pros: Simple and effective way to ensure all support requests are valid. They need to come from a single point of contact and that is easier to ensure all techs know that is the person who should be making all the sensitive requests from the customer.
Cons: A hacker could still impersonate this single point of contact and if you had a new tech who hasn’t talked to this person before they would not be able to recognize them. So now your back to Option 1 of having to call them back before continuing with your request or have the same core issue your trying to solve. Lastly, if only one person can call in for sensitive requests like password resets that one person at the customer is taking a lot of their time each day to deal with these requests and also other end-users are now dependent on this one person to submit all their requests. This becomes a roadblock for the customer.
Option 3: Register a list of security questions and answers that only customer and MSP employees would know
Pros: A low tech way to provide the customer with an option to verify their identity to the MSP. Also, that the MSP knows to ask these questions also verifies their identity.
Cons: The MSP needs to make sure they have distributed these security questions to all the customer employees and needs to remember to ask them. What happens when someone at the customers office gets fired. Now they still know the security questions and answers. Does the MSP need to come up with new security questions and answers each time someone at the customer gets fired and then distribute this to the customer? This can become onerous quite quickly.
What is the cost of Verifying Customer Identities?
Now that we have determined that its important to verify your customers identities and provided some options and procedures to add to your help desk process what impact does this have on the cost to deliver helpdesk services. Its great being secure but as an MSP or large IT department if you’re not making money or your costs are too high you will have bigger problems to deal with.
Here is some information to help you understand the costs associated with add customer identity verification manual procedures to your help desk.
Forester Research illustrates the average cost for technicians in time and resources is $100/hr USD or $25 per 15 mins. Let us assume that adding the customer identity verification process adds an extra 2 mins per support ticket. An average technician according to JitBit can handle approximately 21 support tickets per day. Thus, each technician who handles 21 support tickets per day will now spend an extra 42 mins verifying customer identities. If you had 10 technicians that would be an extra 420 mins per day. Given the cost of $100/hr for the technician that is an increase in $70/day per tech or $700/day per 10 technicians. Assuming your techs are not working overtime to complete the same 21 tickets per day they would be handling less tickets to compensate. Each ticket is taking 2 mins longer thereby affecting their output and requiring you to hire more staff to fill the gap in productivity. As you can see this can become quite costly very fast.
Summary
– Average cost per technician and resources is $100/hr ($25 per 15 mins) according to Forester Research
– How long does it take to perform the additional process to verify your customer identities manually…1 min, 2 mins or more?
– A single tech can handle on average 21 tickets per day.
How can CyberQP help Verify your customer identities?
Send Push Notifications to the end-user
With the CyberQP mobile app a technician can send a request from the web dashboard to verify the end-user’s identity. The end-user can click the option to Approve or Deny the request and the confirmation is immediately sent back to the technician.
Send a one-time random code to the end-user
For end-users that don’t want to install the mobile app a technician can send a one-time random code to the end-user by both SMS and Email. The end-user can confirm the code over the phone to the technician and the technician can mark the requests Approved or Denied on the web dashboard.
Log all customer identity requests
With both the mobile app push notifications and SMS / Email one-time passcodes each request to send and the response is logged in the CyberQP Events menu so you have an audit trail of each customer identity verification request and the result.
Self-Serve Password Reset System
To reduce the number of customer calls and tickets for password resets and account unlocks CyberQP offers the ability for end-users to reset their own passwords and perform account unlocks with their mobile and web apps. They receive notifications via push notifications or SMS for the web app when their passwords will expire soon, when they expire and when they are locked out. They can then take action immediately without ever having to call the help desk thus reducing the number of times required to verify the identities for password reset requests.
PSA Integration – Coming Soon
CyberQP is also working on integrating customer identity verification with Connectwise Manage followed by Datto Autotask. This will allow technicians to verify their customer identities right from the ticket form vs going into another dashboard. Logging all events in internal notes in each ticket allows also for an easier audit trail.
