MSPs TRUST their technicians with the virtual keys to an end user’s castle. But people, as they say, aren’t always who they seem to be, and that sometimes proves disastrous.
Take the case of an MSP that hired a technician who was perfect on paper.
“He knew a lot about tech, cloud, really about everything,’’ recalls James Carroll, co-founder and principal of Hacket Cyber, a penetration testing firm that was brought in by the MSP to help vet the candidate, who had a lot of experience in cryptography, bitcoin, and emerging tech trends and “nailed” the questions Carroll asked him.
Once hired, that employee went from junior to senior technician in less than a year. However, it was eventually discovered that the employee was running a bitcoin mining software program on customers’ machines and in the cloud—and getting kickbacks to process transactions.
The MSP terminated the employee and recouped its costs through the courts, but there were other, reputational damages that could not be rectified monetarily, Carroll says.
Another example of a rogue employee is someone who thought he was “the smartest guy on the team and let everyone know it,” but his hubris exacerbated a ransomware attack, recalls Lawrence Cruciana, president of Corporate Information Technologies, an IT and cybersecurity provider in Charlotte, N.C., that was subsequently brought in to assess and harden the MSP’s infrastructure.
When the MSP’s SMB customer was hit with ransomware, the employee, an engineer, thought he could stop it from happening. Meanwhile, the customer had cyber insurance and the MSP “had a protocol they had at least discussed” to get both their insurance company and the customer’s insurance company involved if a ransomware incident ever happened, Cruciana explains.
Instead, the engineer “used the customer service email provided in the ransom note … and from his work email address, sent the hackers an email that said more or less, ‘You’re picking on the wrong people. We’re a reputable MSP with some of the best tools,’ and named them,’’ Cruciana says, adding that he “cringed” when he read the email.
The engineer was let go for disobeying the MSP’s rules of engagement, he says. “It almost crosses the line to an insider threat.”
The lessons learned?
Application whitelisting would have prevented the bitcoin mining software from being installed, Carroll says.
Cruciana suggests following best practices by separating duties and limiting access rights, along with having clearly written policies and robust audit logging that is centrally maintained with trigger-based alarms built in.
Carroll agrees documentation is critical along with a solid employee onboarding process that includes background and reference checks.
ESTHER SHEIN is a longtime freelance tech and business writer and editor.