Kaseya began the technical work for deployment of the company's servers that support the software-as-a-service VSA product, configuring an additional layer of security to the SaaS infrastructure.
The added security layer will change the underlying IP address of the VSA servers, which will be transparent for almost all customers, but will require an update to any IP whitelist for firewalls that included the Kaseya VSA server, the latest update on the Kaseya website noted. The new IP addresses can be found here.
Click here for the latest updates on the Kaseya cyberattack.
No SaaS VSA services were restored as of 7:30 p.m. ET; the enhanced security measures "are currently being implemented and verified for proper operation," the update stated. "Once operational, we will then publish the VSA availability timeline." The company will update the support web page hourly.
The decision to bring down SaaS servers as a precautionary measure while the company evaluated the full nature of the ransomware attacks is one that many security researchers laud as a responsible maneuver, even if inconvenient for a segment of customers and partners.
“In retrospect the attack may have prioritized on-premises hardware, but in the thick of the emergency with damage reports still rolling in, I would have taken the SaaS servers offline, too,” said Hitesh Sheth, president and CEO of Vectra. “We’re paying a stiff price for complacent overreliance on endpoint defense. Let’s not second-guess a decisive move to protect Kaseya customers that was the opposite of complacency.”
A patch for on-premises customers of the Kaseya VSA product that was the source of a widespread ransomware attack last Friday is now expected 24 hours (or less) from the restoration of SaaS services.
“We are focused on shrinking this timeframe to the minimal possible – but if there are any issues found during the spin-up of SaaS, we want to fix them before bringing our on-premises customers up,” the company said.
A decision to take down SaaS servers, even temporarily, can be disruptive for the customer community. Kaseya did not provide specifics on the communications with partners and customers about that decision, though it did note plans to provide what it described as a "customer-ready statement" for partners to distribute after the SaaS servers were restored.
"Kaseya taking their SaaS VSA servers offline was a prudent choice,” said Rick Holland, vice president strategy and CISO at Digital Shadows. Holland said there’s a natural “fog of war” in the early stages of incident response when the security team does not have a full picture of the intrusion.
“It’s better to be safe than sorry, and at the time, the risks of a potentially broader intrusion must have outweighed the implications of taking the service offline for a few days,” Holland added.
Oliver Tavakoli, chief technology officer at Vectra, said Kaseya appears to have followed a coherent incident response plan to get the overall VSA infrastructure back up and running. The cascade of updates makes sense, with software updates flowing from Kaseya SaaS to on-prem VSA servers to agents, which are then pushed to affected MSPs’ customers.
“Once a hardened version of the SaaS service is up and running, the on-prem VSA servers will be provided with additional protections (24x7 SOC coverage and a CDN-delivered WAF),” Tavakoli said. “Then the process of opening up uncompromised VSA servers to patches from Kaseya’s SaaS begins, while compromised VSA servers will need to be re-installed and subscriber data must be restored from backups before the patches can flow."
Separate to the Kaseya attack, tech distributor Synnex Corp. confirmed Tuesday evening "a few instances where outside actors have attempted to gain access, through SYNNEX, to customer applications within the Microsoft cloud environment." The company said the actions could potentially be in connection with the recent cybersecurity attacks of managed service providers, or MSPs, though the company is quick to note it does not utilize Kaseya products.
