The specific tactic of the ransomware gang that targeted Kaseya customers illustrated an unresolved flaw in many managed service provider software distribution models: Relationships anchored in mutual trust, by definition, introduce risk.
And that risk can often go unaddressed.
“They have an issue here, because MSPs are responsible for their customers. And Kaseya provides this service that the MSPs pay for,” said Dede Haas, channel strategist at DHL Services and an expert in MSP models. “There’s a chain of trust that has now been broken.”
So then, where are the failures in vendor and MSP relationships that could introduce risks, and what tactics could help close the gaps? SC Media spoke to supply chain experts to examine the complexities.
A shared responsibility
Between 50 and 60 of Kaseya’s on-premises remote monitoring and management customers, by the company’s count, were breached by a REvil ransomware affiliate on Friday. Well over a thousand customers of managed service providers using Kaseya VSA were infected with ransomware.
“When I saw that, I thought, ‘Oh. That’s not good,” Haas said. “When Kaseya gets hacked, it’s not the MSP's information; it’s their clients' and customers' information as well.”
All of those factors led Kaseya to tell on-prem VSA customers to shutdown, and to take servers that support software-as-a-service offerings offline as a precautionary measure.
On Thursday, company CEO Fred Voccola announced during an online video statement that Kaseya would provide aid to customers who needed it following the attack, in an offering modeled after a financial assistance program the company launched after COVID-19 hit. That would take the form of direct financial assistance to MSPs “who have been crippled by the REvil people, and the new adversaries that we face,” he said.
The company will also be spending millions of dollars, working with third-party consulting companies and its own professional services team, to provide licensed delays of payments.
“It’s very different than the type of relationship that we have with our customers, where we are mission-critical,” he said.
But whether or not Kaseya falls on its sword, as the company seems to be doing, it does not necessarily alleviate the challenges MSPs face from their own customers. Those customers will want assurances their own data has not been compromised, and even once those assurances come, MSPs could find themselves – much like Kaseya is doing now – managing potential damage to relationships and reputation.
“It was strategic to go after MSPs, but opportunistic in terms of which they caught,” said Joshua Marpet, executive director at Guardedrisk. “If you want to find juicy bits, do you go after a company? Maybe. But if they’re involved in M&A, it’s easier to go after the law firm, which typically has worse security. The most successful MSP I ever heard of had 36% profit margin; that’s nothing in the software world. So how much time and effort do they have to hard-configure all of these tools and vendor offerings? I can’t blame the MSPs.”
Distinctive with the MSP model is that a successful attack is typically multi-pronged: Identify a vulnerability in the software, and then target the provider that in theory did not layer on top of the vendor’s tech stack additional security controls to make exploitation more difficult.
In the case of the Kaseya attack, MSPs that were using two-factor authentication “I’m guessing are in a slightly better position,” said JC Herz, cofounder and chief operating officer at Ion Channel, a data platform and service that allows organizations to risk-manage their software supply chain. But even before an attack happens, she added, “vendors should know whether an MSP’s enterprise policy is two-factor authentication. This isn’t about making sure your MSPs are compliant with [the Federal Risk and Authorization Management Program]. These are basic standards that you should know and require. The question with the MSPs is whether it’s possible to get to some verifiable, ongoing level of assurance about their controls.”
“What should be happening now, is for every customer to assume that all their MSPs have been compromised, and to implement compensating controls within their own enterprises to properly segment the data exchange,” she continued.
‘Smart’ communications
That said, while MSPs hold significant responsibility for securing their own infrastructure, most experts tell SC Media that the burden falls upon the vendor to not only ensure the security of the product, but to establish policies and procedures for customers in terms of security standards and also what must be done when a vulnerability is identified. That should include specifics about communications and expectations of the vendor, the MSP and even the end customers.
“It’s just so important to have these mitigation processes and procedures,” Haas added. “The MSPs are more aware than anybody. And this is their frustration. Vendors think partners should be out there taking care of the vendor, but no, vendor – your responsibility is to take care of the partner. Help them be protected.”
“The MSP is the one that is getting screwed the most,” she continued. “There needs to be transparency. And they need to make it simple.”
To achieve that transparency, many experts point to various versions of what you might call "smart" contracts that clearly define requirements, expectations and procedures. Chris Blask, a strategic adviser to Cybeats, and former executive director with Unisys, said it’s an important component of a digital bill of materials – a concept he coined in the last couple of years to mean the list of every component inside any type of product as each moves from one set of hands to another.
“All will have to be able to [do this], at some point in the foreseeable future, not just because there will be a regulation but because a) attackers will evolve to the point where you can't keep your thing running for five minutes, and b) if you don't do it your competitors will do it and then take away all your business,” continued Blask, who advocated specifically for application of "oracles," where contract language is established and chained together in repositories, with specific automated responses that occur when particular conditions are met.
With that approach of real-time communication that includes process automation, “you don’t tend to have opportunities for these issues to slip in because people are talking to one another,” he said. “A lot of this comes down to an organization being mature enough to ask the right questions.”
Reporting from Senior Reporter Joe Uchill contributed to this report.
