It takes a village to raise a website...
The world wide web of today is full of platforms that can’t stand alone. Almost all websites need a whole ecosystem to stay up. This ecosystem saves countless hours of effort. But it also allows for accidents like left-pad, where one open-source developer deleted a minor program that turned out to be crucial for much larger systems. Worse things can happen through malice.
Every modern website is “a thrashing leviathan of code and markup written by people so untrustworthy that they’re not even third parties, they’re fifth parties who weren’t even INVITED to the party,” according to Harvard professor James Mickens. His work focuses on “the performance, security, and robustness of large-scale distributed web services.” Performance and robustness have gotten a lot nicer in the seven years since he wrote those words, what with programs like Kubernetes and MapReduce. Security, not so much.
You probably remember the SolarWinds attack from late last year. You may have remembered it because you read this stellar blog post about lessons from the attack. If you didn’t, here’s a recap: SolarWinds sent out software updates that created backdoors in around 18,000 clients’ systems. The attack hit Microsoft hard as well as government agencies like the Treasury, Homeland Security, and (gulp) the National Nuclear Security Administration.
But it could have been even worse. The Orion Platform, the software that carried the vulnerability, was used by around 33,000 clients at the time. What’s Orion for? Well, it makes managing other cloud software easier.
This was what’s called a supply chain attack. By putting a backdoor in a trusted piece of software that many users buy, an attacker can get at the target they really want to hit. It’s expensive and difficult to mount a supply chain attack. Software companies that many people trust are not soft targets. Phishing and the like are vastly more common; prep for those first. But supply chain attacks nevertheless succeed sometimes, more often in recent years.
What Is the Cloud?
The cloud is just someone else’s computer. That’s not a security problem in and of itself. Amazon, Microsoft Azure, and Google are quite good at taking care of their computers. You can usually trust them to keep unauthorized people out of your instances.
But do you trust everyone you authorize? Do you trust everybody the people you authorized authorize?
Most every company online has third-party vendors, contingent staff or contractors, and other people out of house whose activities can create vulnerabilities. Risks range from the dumbest data breaches (someone copy-pastes something to a public page instead of a private one) to Hollywood-esque disasters (hospital ransomware attacks).
These risks are growing more common. One 2018 study found that 61% of US companies had experienced a data breach caused by one of their vendors or third parties, rather than by their own workers.
In 2020, Amazon got hit with such a data breach, when a third-party authorized user accidentally left a database with millions of customer records open for anyone to see.
As companies seek more flexibility, they outsource more and more functions. If you’re using many different third-party vendors, the odds that one of them gets compromised are higher than if you stick to a narrow ecosystem.
How do you prevent supply chain attacks?
“Be more careful which suppliers you trust” is a pat answer. But this is an organizational problem, not a technical problem. Vetting suppliers for good security practices will get you further than trying to audit the software itself.
So how do you do that? A checklist.
- Make a list of your third-party vendors
- Decide which ones have the highest impact on your operations. Pay the closest attention to them.
- Nail down who’s responsible for what
- Contracts and service-level agreements are crucial. You need to be able to hold your vendors responsible. Be clear and explicit about what security practices you require them to follow
- Check up on your vendors
- People get sloppy. Set up audits, annual training requirements, or some other process to increase the odds that your vendors stick to the practices you prescribe.
- Monitor what they’re doing on your network
- User activity monitoring can save you a lot of agony. Being able to watch a vendor’s activity on your network for anomalies is better than trusting them to catch their own slip-ups.
- Have an incident response plan
- Choose team members to be notified and respond in case of suspicious activity. You need to be able to cut off a threat on your end, not just wait for the vendor to fix it.
- And look for a backup solution for what to do if you need to stop using a vendor’s product on short notice.
For more details, I recommend these writeups by Ekran Systems (focused more on the technical fixes) and NETOP (focused more on the organizational fixes).
Article originally published on LinkedIn: READ HERE
