Getting Ahead of Supply Chain Attacks

The one-year anniversary of the Kaseya attack this month marks an appropriate time to look back at supply chain threats and what has — and has not — changed.

Let’s start with what has changed: more checklists. Oversight across code that’s loaded across customer sites now involves far more paperwork, especially for managed service providers (MSPs). Leadership teams now realize the amount and complexity of code going in and out of their organizations and hope to get more eyes on it. Sadly, much of the new processes involve checking a box, rather than implementing technical cybersecurity steps that could make a difference in threat prevention. But we’ll get to solutions for that in a moment.

What also has changed is the noted sophistication level of adversaries. A willingness to set up an entire replicated network, purchase domains, and persist for months and possibly years represents a significant increase in investment in concerted campaigns. Kaseya reminded us that everyone in the ecosystem is a target. We have always had cyberwarfare. Now we have more heavily funded, more vastly staffed attackers pounding on our supply chains (and everything else).

What has not changed? The idea of using legitimate distribution of code to distribute illegitimate backdoors. As far back as at least 2002, attackers used Trojan-horse techniques to backdoor security tools and email servers. Hackers have always sniffed and surveyed customer and supplier environments to look for the mundane, the routine, the usual. It’s there that they find unguarded corners to slip in malicious code, as humans are lulled into daily routines. Kaseya and especially SolarWinds show more complex, persistent techniques and they are very widely used enterprise apps, yet the supply chain attack idea has been around for decades.

Security techniques have not changed enough, which is why security focus is moving to more response and remediation. This leads to talking about solutions and where we go from here. Pointing to challenges is not meant to be disheartening. It’s meant to be realistic, knowing we’re all in this together.

I suggest three major avenues to explore that can be useful to address the security issues Kaseya made more noticeable.

Change Your Technical Environment

Move away from allowance of third-party actions without associated monitoring, most notably by adopting zero trust. Anyone touching an enterprise resource is untrusted. Period. Vendors, contractors, employees need the same level of multifactor authentication (MFA) and other security treatments.

In addition, monitor third parties more than you would anyone else. They have the privileged accounts. Yet you know far less about when your European automation company partner pushes out code in your environment than when Brian in Seattle releases your product to customers. Super-high alerting on these accounts is warranted to pick up anything suspicious, as early as possible.

On the code creation side, understanding that business still needs to move quickly despite heightened security, it’s okay to keep working on small bursts of code (sprints) and move at a reasonable pace (biweekly releases). Yet know when it’s smarter to pause for a security cross-check rather than push and ignore. Specific tactics could include time-boxing exactly when code may be pushed, from where and by whom. That alone can uncover suspicious code. The OWASP top 10 will identify the easier security issues. But for Kaseya-style attacks, you’ll need to look for who or what is running a command on a server, for example, which is why more defined developer processes and roles can help.

And don’t forget about trusted devices. Know which physical machines have the greatest access rights and consider pairing them with physical presence. The combination of zero trust, MFA, and device trust, together with tactics that keep developers safe, can all be beneficial.

Change Your Legal Safeguards

Rather than checkbox that a vendor filled out a risk questionnaire, revisit your master services agreements (MSAs) with third parties. Clauses such as woeful misconduct, negligence, and unlimited liability are the source of fruitful conversations. These help walk through who can cover what, and where the gaps are, allowing necessary safeguards to occur somewhere (rather than nowhere). Align these agreements with your cybersecurity policy. The worst time to review your MSA is in the deadline-driven moments after an attack is discovered.

Change Your Mentality

Accept that even the most well-funded, advanced security organizations in the world are regularly attacked and breached. It’s not if, it’s when, which means it’s how quickly can you recover. If you have no staff available for recovery, it’s as bad as having no security monitoring in place.

Plan ahead with the mentality you will need people to sift and act and move on attack remediation. This makes it far less painful when you experience the next Kaseya. Vendor response approaches have improved, with customers giving Kaseya positive feedback on their transparency, communication, and sense of urgency in handling the threat discovery. This came after SolarWinds had to struggle through a far more sophisticated and multistage attack. SolarWinds opened a new line of vendor communications and other topics of discussion that later vendors could turn to as precedent.

For a simple starting point on all this, consider choosing one supplier providing the most amount of code updates. Practice the three steps above and hone to your unique environment and business requirements. Once you see gaps in your staff or solutions, take action, whether onboarding security specialists in-house or externally. After all, we’re all in this together.