Ten years ago, a foundational security company RSA, was hacked. They were foundational because they were the leader in two-factor authentication tokens. At the time, these tokens were physical devices that generated a new code every sixty seconds, similar to the soft tokens you have hopefully have now. In both cases, these tokens utilize a “seed” value to generate the codes every minute. In 2011, these seeds were stolen compromising every single RSA token globally.

Ten years later, the full story of what happened is now available because NDA’s from those involved have expired. The full and fascinating story is available in July’s issue of Wired magazine.

More recent supply chain attacks include the Solarwinds attack, and more recently the Kaseya attack, that affected over 1500 managed service providers and their customers. The news is still unraveling.

Supply chain attacks are nothing new as you can see, but they have tremendous downstream impact. Easier to target one company that could lead to hundreds or thousands of others, than to try to get to each one individually.

I’d like to take a moment to highlight some lesser known, but common, attacks:

• Chrome extension alteration

• Open source code alteration

• Typosquatting of open source repositories

I’ve talked about chrome extension security before, so don’t need to reiterate here.

Many of us think that because something is open source, that it’s secure and that someone has taken the time to review additional code. While the hypothesis can be true, in reality it pans out a little different. At the end of the day you may have some code maintained by one person, who’s already got a day job and is spread thin as it is. They may not have the time to review every PR and nuance.

It’s really up to the community to review the code, but then you have the age-old psychological conundrum called Diffusion Of Responsibility, where everyone thinks the other person will stand up to do the hard work.

Preventing/Minimizing Supply Chain Attacks

These attacks will continue forever. Here are some tips to better equip yourself:

• Add signatures and verifications at every step of your code chain. There are a bunch of startups now in the space trying to solve this problem.

• Review the authors of your upstream source repos, use well known and maintained resources.

• Question the security of your 3rd party CI/CD plugins. Although doing so may not prevent an attack, it may help sway your opinion in the event there is a more secure competitor.

• Limit the software that can be installed in your environment, whether it’s on your employee machines, 3rd party plugins, or etc.

• Monitor your environment. I can't stress this enough. Here are some things to log.

• Have an incident response plan and policy. This will come in handy and help you react calmly should a 3rd party you use be affected.

Take care,

Ayman