Over the July 4th weekend, a supply-chain ransomware attack infected Kaseya VSA software, targeting managed service providers (MSPs) and spreading across their customers. This was an attack of opportunity; cyber criminal group REvil took advantage of a U.S. federal holiday to mount a zero-day-driven supply chain attack while companies had lower employee headcounts and compromised response readiness.
The attack was also opportunistic in the sense that it targeted MSPs, which sit high-up in the IT supply chain and have the ability to drive exponential spread across smaller and mid-sized businesses. The breach hit around 60 MSPs and spread to up to 1,500 companies, with REvil claiming that it infected over 1 million systems.
Notes on Supply-Chain Attacks
Supply-chain attacks are becoming a more common method of attack for highly advanced criminal activity. They present criminals with the opportunity to access hundreds of customers through each infiltration point, leading to widespread campaign behavior.
In 2019, the largest exploitation of a supply chain risk occurred with the SolarWinds Orion platform compromise, affecting more than 30,000 public and private organizations around the world. Disguised as an update from SolarWinds, the Orion product deployed SolarWinds-signed malware to impersonate users and access files and processes on SolarWinds Orion machines.
In addition to the exponential spread of each attack, ransomware attacks compound on one another: Every time a campaign collects ransom, the cyber criminals responsible are able to fund additional criminal ventures. Perhaps an example of this, the Kaseya attack closely followed a ransomware attack by the same group on a meat processing company last month, which paid the requested ransom.
Impacts and Response
The REvil attack has shaken buyer confidence — and rightfully so. As SaaS and cloud-based models become business standards, companies need to continually assess the security of the services and vendors they use.
At JumpCloud, we take this responsibility extremely seriously. While we were not affected by this attack, we take it as a solemn reminder of our responsibility to protect our customers. We believe security should never be assumed, and our security and development teams’ jobs are never done; rather, we’re constantly working to understand new and emerging threats, identify and rectify vulnerabilities, and plan deeper, wider, and more robust response strategies.
As part of our ongoing security practice, we maintain diligent security controls, collaborate with our partners and customers on their security postures, prioritize third-party risk assessments, and practice in-depth risk assessments and incident response planning, often in coordination with other vendors. To aid in our ongoing efforts to minimize vulnerabilities and bugs in our platform, we also have a Vulnerability Disclosure Policy that allows others to report suspected vulnerabilities to us responsibly.
The REvil attack only emphasizes the importance of our ongoing efforts to strengthen our platform security and development cycles and hone our risk assessment and response strategies. It also underlines our focus on ransomware response planning, table-topping, and industry collaboration.
This attack reminds us to be constantly vigilant, and should prompt companies to check-in on their security environment and policies. The nature of the attack reiterated the fact that the supply chain can be obscure and is often left unexamined; vendors and customers can’t afford to rely on a surface-level assessment of their supply chain.
For security to be thorough and reliable, it needs to include a view of all the links in the IT supply chain and their security, and data needs to be protected at every point in the supply chain, including during transmission from one point to another. This means companies should examine both their internal security practices and the practices of those with whom they work and entrust data. They should collaborate with third parties in their supply chain to ensure secure data transmission and plan coordinated incident response strategies.
Security policies should be unique to each company and their vendor environments; however, the following areas are foundational to strong vendor and customer security:
- Use Multi-factor authentication (MFA) everywhere. MFA should always be turned on wherever possible. While it’s not a sure-fire way to stop every attack, it can thwart many and at least hinder other partially successful ones. For example, MFA can stop or slow lateral movement during an attack, preventing a threat actor from using one infiltration point to gain access to other critical resources.
- Implement deep device visibility and management. The Kaseya attack’s exponential spread to endpoints was a stark reminder to stay on top of device and endpoint management. This should include visibility and controls on everything connecting to your network, from on-prem servers to remote devices and printers.
- Practice vigilance. No matter how sophisticated your SIEM system is, relying solely on alerts and automation is not enough; an attack could involve turning off systems or alerts. Make sure your monitoring process supplements alerts with human checks.
- Check third-party security. Check-in on your vendors’ security policies to ensure they meet your company’s standards. If you contract with an MSP, work with them to understand the resources they use and their security policies to assess your security and risk.
- Follow the principle of least privilege. Use the lowest possible permissions and only grant employees and third-parties access to what they absolutely need.
- Log and audit service accounts regularly. Check to make sure they follow the principle of least privilege and aren’t overprovisioned.
- Practice table-topping exercises. Incident response table-topping should be an IT requirement. It should include ransomware response, crisis management, and deep reviews of the supply chain. Ideally, companies should practice internal exercises as well as collaborative exercises with vendors and partners.
- Compliance is not an excuse to forego security steps. While you may meet SOC 2 compliance requirements, this cannot be an excuse to forego thorough vendor security reviews. Like many vendors, JumpCloud meets SOC 2 requirements and follows the Cloud Security Alliance, but we treat these as starting points rather than finish lines. Compliance should represent a solid foundation to build security practices on.
The prospect of facing a security breach is just about every security team’s nightmare; however, in today’s threat environment where a cyberattack is less a matter of if than when, it’s critical to be prepared.
Ideally, your security policies should block all attacks that come your way. But in the event of a breach, the first thing you will need is inside and outside counsel to help you understand how to move forward, from immediate mitigation steps to how to handle ransom requests. Make sure you know who these entities are for your organization — establish internal roles, responsibilities, and communication channels as part of your incident response plan, and consider partnering with a cybersecurity firm for external guidance.
Maintain close working relationships with customers and providers, and keep a constant eye on their permissions, activity, and security practices. If you ever suspect a breach or notice unusual activity, act quickly and communicate transparently with the parties involved.
- If you suspect you may have been affected by the Kaseya attack, consult the official guidance posted by CISA-FBI.
- For Kaseya’s official statement and technical details about the attack, including identified indicators of compromise (IOCs), read their Incident Overview & Technical Details article.
- For an overview of the attack, read Dataprise’s summary and analysis.
- For IOC lists and details, consult these resources in GitHub
- For ongoing news on the attack, visit Kaseya’s page with time-stamped updates.
To learn how JumpCloud intakes security vulnerability reports, view our Vulnerability Disclosure Policy.