
Mitigating the Impact from the Kaseya Supply Chain Ransomware Attack
This year’s 4th of July weekend has been anything but relaxing for IT and Security teams. Forget about flipping burgers and think more about turning off servers –– definitely less fun and far from as tasty.
On Friday, word started getting out that the REvil ransomware crew had compromised the update server for the Kaseya VSA remote monitoring and management tool that is widely used by MSPs for administering their clients’ IT infrastructure.
Working through the supply chain, the crew appears to have successfully targeted nearly 40 Kaseya customers, including a number of MSPs. Having compromised those key players, they then went after the MSPs’ customers, hitting hundreds of victims with ransomware –– including pharmacies, groceries, and a railway.
This led to the company advising all of their on-prem customers to turn off their servers lest they be targeted as well.
The attackers appear to have only succeeded in compromising Kaseya’s on-prem product, limiting their scope of potential victims. However, out of caution, Kaseya took their SaaS product offline, essentially shutting down operations for the tens of thousands businesses that depend on the platform for managing their IT systems.
Attackers are Bypassing the Perimeter
Due in part to the long holiday weekend and the scale of Kaseya’s dominance in this market, details about the full extent of the damages from the attack and how it was carried out are still coming in.
But for those of you playing cybersecurity incident bingo at home, this was a combination of ransomware and a supply chain attack (remember the SolarWinds attack?), hitting some of the biggest themes of the year.
This attack highlights how attackers are finding more creative ways of breaching their targets, hijacking trusted vectors like update servers to bypass otherwise strong security measures at the perimeter, finding their way into the soft, gooey center where all that good, valuable data is.
While it may be overly fatalistic to say that breach is a matter of “when and not if” (although a recent IDC survey claims that 98% were breached in the last 18 months), organizations need to do more to prepare for the possibility that a determined group of attackers are going to make it past the high gates of their defenses.
If that does occur, organizations have a responsibility to figure out how they are going to protect their assets and mitigate the amount of damage that an attacker can achieve once inside.
The list of “should dos” and “must dos” is long. But one important element that has to be taken into account is ensuring that the compromise of one user account does not allow the attacker to cause significant damage to the organization.
One of the best ways to ensure that this does not happen is through enforcing a Segregation of Duties.
Defining the Segregation of Duties
They say that absolute power corrupts absolutely. This is a fancy way of saying that you shouldn’t entrust any one person with too much power that would allow them to do too much harm on their own.
In the most extreme of cases, think of how it takes at least two people to turn their keys simultaneously to launch a nuclear-tipped missile.
A more day-to-day example would be where the person who sends out the checks is not the same person who approves the payments. Without that second set of eyes, it is too easy for one person to divert payments to themselves and nobody else would be the wiser.
Most organizations have a Segregation of Duties policy for guarding against malicious insiders. In the best of cases, the policy is far from perfect. More often though, it is simply written down to show regulators that they have a policy but is never actually enforced.
One of the problems that organizations often encounter is that changes over time within the organization can lead to a fraying of these controls. There is also often a lack of awareness about where gaps can occur that may open the organization to unintentional risk.
It is not uncommon for managers to be unaware of the structures that were put in place before their time to ensure that there was a Segregation of Duties.
This can lead to risks if a person suddenly needs to take over another’s responsibility while they are on leave. If the manager is not cognizant of the details of the duties, it can easily create a situation where the Segregation of Duties breaks down and one person ends up with more power than they should.
But these policies can also play an important role for dealing with hackers.
Tips for Avoiding Segregation of Duties Risks
In the context of a breach, we want to limit the ability of an attacker to do too much from having compromised a single account. One of the best ways to deal with this potential for risk is to add more people into the loop to approve or carry out “riskier” actions.
Yes, this means adding more friction into whatever process you are working to protect, so there needs to be a balance between security and functionality. But this is true for most security measures and should factored into any policy decision process.
Here are a few basic tips that organizations should put in place for mitigating these risks.
Protect Your Code Base
Attackers in these supply chain compromises have managed to make significant changes to the code by either creating or corrupting privileged or otherwise sensitive accounts.
However, since the code is still being signed by the vendor, it receives a legit hash and certification. This nullifies most of the standard defensive measures that would otherwise catch malicious code entering the targeted organization.
Make sure that any merger to the main branch of your code requires at least two people to approve. While not a total solution, it makes the hackers have to do additional work to manipulate the code, increasing your chances of catching them in the act.
Make it Harder To Push Out Bad Code
Again, the goal here is to put up roadblocks that make life harder for the hackers.
Even if the attackers manage to make it past your defenses and manage to insert a vulnerability in your product, you have a responsibility to make it difficult for them to push it out to your customers.
Make it a policy that pushing software updates to customers (on-prem or cloud production environments) will require at least two people to get updates out the door.
Ask Your Vendors About Their Segregation of Duties Policies
Your product is only as secure as your vendors.
While nobody is bulletproof, it is up to you to ask the right questions about what kinds of precautions your vendors are taking to protect themselves and their customers.
Be sure to ask about what kind of Segregation of Duties policies and enforcement mechanisms they have in place.
Expect Additional Compliance Requirements Soon
In May, the Biden Administration issued its executive order aimed at improving the nation’s cybersecurity posture. Among the points in the document was the need to put in place measures that would enhance the security of software supply chains.
Like ransomware attacks, hacking crews are likely to continue to target software vendors that supply hundreds and thousands of customers simply because the ROI for these attacks are too good to pass up.
Segregation of Duties is just one of the measures that are likely to receive additional attention in the coming months as the government and industry look for ways to mitigate the impact of supply chain attacks. In the near term, we are likely to see a new set of rules come down that will require that organizations step up their security game and give the malicious actors a hard day at the office.
For more information on how to improve your organization’s security posture, apply SoD in your systems, and lock down access from attackers, contact us today.
The post Mitigating the Impact from the Kaseya Supply Chain Ransomware Attack appeared first on Authomize.
*** This is a Security Bloggers Network syndicated blog from Authomize authored by Gabriel Avner and Gal Diskin. Read the original post at: https://www.authomize.com/blog/mitigating-the-impact-from-the-kaseya-supply-chain-ransomware-attack/