I’ve said many times in this blog that I think software supply chain security attacks and ransomware attacks are the two biggest cyber threats in the world today. And in terms of growth rate, the former have it all over the latter. Ransomware is now a fairly mature threat, and while it’s definitely growing, it’s not growing at anywhere near the rate of software supply chain attacks.
In this post, I
pointed out that Sonatype’s annual State of the Software Supply Chain
report in
September said that, in the 12 months starting May 2020, software supply
chain attacks increased from below 2,000 to around 12,000, or 650%. By
contrast, from February 2015 to June 2019, 216 software supply chain attacks
were recorded. So we went from 216 attacks in more than four years to 12,000
attacks in the last 12 months. Wouldn’t just about any CEO be willing to
sacrifice one or two limbs to achieve that rate of growth? And now ENISA, the
EU Agency for Cybersecurity, predicts that there will be four times as many
software supply chain attacks in 2022 as in 2021.
Fortress Information Security, as
you may know, is in the business of supply chain cybersecurity, and they are
quite aware of the importance of software supply chain attacks. That’s why
they’re hosting a webinar on Thursday November 18 from 11 to 12 EST titled “Patch
Poisoning: Critical Infrastructure’s Backdoor”. They’ve put out a white
paper to go with it, titled “Patch
Poisoning: Software Supply Chain Attack Detection and Prevention”, which
does an excellent job of explaining a number of serious attacks that you (and
I) have barely heard of. No developer credentials are required!
“Patch poisoning” – a wonderfully
descriptive term that I’ve never heard before – is a great way of
characterizing software supply chain attacks. They literally poison the
trusting relationship that develops between suppliers and customers of any
product, but especially software. Of course, Exhibit A is the 18,000 SolarWinds
customers who allowed the seven “poisoned” updates of SolarWinds Orion to be automatically
installed on their networks. And why shouldn’t they have done so? They’d
trusted SolarWinds for years, and there was no reason to even consider not
letting these updates install again. After all, the updates wouldn’t even have been
allowed to install if they weren’t digitally signed by SolarWinds…And if you
can’t trust an update signed by your supplier, what can you trust?
Good question. Sign up for the webinar (and read the white paper) to learn the answer.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. Nor
are they shared by the CISA’s Software Component Transparency Initiative, for
which I volunteer as co-leader of the Energy
SBOM Proof of Concept. If you would like
to comment on what you have read here, I would love to hear from you. Please
email me at tom@tomalrich.com.
No comments:
Post a Comment