At Black Hat: Security threats and how to defend against them
How risky is the online world? You could count the ways — and it would probably take you a while.
But that’s why they do what they do at security conferences, in exhaustive detail. Black Hat USA 2021 in Las Vegas last week covered the online threat landscape in more than 90 different ways, from hacking to social engineering, supply chain attacks, and plenty more.
But conference sessions also went into detail about mitigating those threats, and one of the primary ways to do that is by building better software. While nothing can eliminate online threats entirely, secure software can keep organizations from becoming what most experts describe as “low-hanging fruit” for criminal hackers.
And two security experts from Synopsys were among those bringing that message. (Disclosure: I write for Synopsys.)
For Tim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, the focus was on supply chains — also the topic of the opening keynote from Matt Tait, COO of mobile security startup Corellium.
Supply chains have been around for as long as people have done business, but in modern society, even at just the physical level, they are both sophisticated and complex. And that sophistication and complexity increases by orders of magnitude within the digital world, where the supply chain of software components can multiply exponentially through a web of “dependencies.”
That generates enormous risk — vulnerabilities in online supply chains can easily have material consequences. Perhaps the most catastrophic of this year was the attack on Texas-based network management vendor SolarWinds, which supplied an update to one of its software programs called Orion to tens of thousands of customers.
That update had been corrupted by hackers, so when customers dutifully installed it, obeying the mantra to “keep your software up-to-date,” they installed malware. The number of victims compromised was estimated at 100 companies and about a dozen government agencies — far fewer than the estimated 18,000 that downloaded the update — but the damage was still massive.
The victims even included the Cybersecurity and Infrastructure Security Agency, the part of the Department of Homeland Security responsible for protecting federal computer networks from cyberattacks.
A web of connections
Mackey, in a presentation titled “Software Supply Chain 101 — What Is It? Why Is It Hard to Track? What Are Some of the Common Challenges and Risks?” said the major reasons supply chains pose such a risk to organizations is because of their complexity and how difficult it can be to track the connections among suppliers.
Indeed, the “chain” image is apt. As the cliché puts it, a chain is only as strong as its weakest link. Which means if an organization doesn’t keep track of every link in its software supply chain, as well as vetting the security of those components, it doesn’t matter how secure its on-premises systems and networks are.
One example Mackey gave was a hypothetical app that would interact with the business chat platform Slack, and also communicate with Instagram “with a few other libraries along for the ride,” he said. “Those libraries come from suppliers — they’re called dependencies, and there are eight of them in my app.”
Within just one of those dependencies, he noted, are 15 other dependencies. And within one of those are 30 more. Ultimately, he said, “when you walk the entire dependency chain, you end up with 133 unique components with a dependency depth of eight levels. That’s a lot for someone to determine if it’s secure, if it’s correct, and what functional aspects are associated with it.”
Mackey said it’s typical for software developers to focus just on the first level of dependencies and “trust that the rest are doing the right thing.” But that trust can lead to a host of problems, he said, because not all software is tested equally, especially given that the majority of the components in software projects today are open source.
So it’s crucial for organizations to know and to vet what they’re using — especially if they’re not paying for it.
Open source software is attractive because it’s free and can be modified to suit the needs of an organization. But the security of open source projects is also subject to the interest, skills and size of the community supporting them, which can range from excellent to nearly nonexistent. And finding out about it isn’t as simple as contacting customer support. “There is no vendor known as open source,” Mackey said.
He cited the most recent annual Open Source Security and Risk Analysis report by Synopsys, which found an average of 528 components per commercial code base. The report also noted that an average of 48 new software vulnerabilities were identified per day in 2020 and that 75% of organizations take longer than a week to resolve high-severity vulnerabilities.
“Are you prepared to manage 500-plus components per app?” he asked.
It’s important, he stressed, for organizations building apps to make sure that they are using the right components, which means knowing the origin, key contributors, and the level of support they have. It’s risky simply to use packages or libraries without that knowledge. “You can’t tell if something is secure unless you look inside the container,” he said.
Patch, patch, patch
It’s also crucial to install patches and updates for vulnerabilities as soon as they are available, because hackers know about them as well, and will try to exploit those who fail to patch.
Mackey went into considerable technical detail about how to vet software components correctly, but said the bottom line is that “awareness is key to improvement. You can’t patch what you don’t know you have, so plan your patch strategy before using code, not after.”
His checklist for reviewing supply chain components includes:
- What is the origin?
- Why was this component chosen relative to other options?
- How are updates to the component communicated and then applied?
- Is the component cached in an internal repository?
- What security reviews were done prior to approval?
- What security reviews were done on updates prior to adoption?
- What critical capabilities are in the component?
Meera Rao, senior director (DevOps Solutions) with the Synopsys Software Integrity Group, focused on a relatively new weapon in the battle not only against hackers but also in helping to resolve the decades-long conflict between better security and the speed of software development.
That weapon is Intelligent Orchestration, an automated tool that lets organizations manage software testing according to their own priorities. And it addresses the escalating pressure on developers to build and deploy applications faster and faster, to the point where if the choice is between speed and security, speed wins.
In a presentation titled “Building Security in DevOps With Intelligent Orchestration,” Rao noted that “some firms deploy to production as frequently as every five minutes, a velocity that security teams have struggled to match.”
She said developers have complained for years that bringing security testing tools into the development pipeline slows it down. The complaints she hears, she said, are that “all these scans, they run all the time whether they’re needed or not. You overload our developers with vulnerabilities when you run either manual or automated tests. And there is no continuous feedback to the developers at the right time.”
Meanwhile, security team leaders complained that it was difficult to impose security policies across all applications because they all carried different levels of risk depending on their functions, the types of data they process, and whether they are open to the internet.
Benefits for both
That’s a significant laundry list. And Rao said it’s one that Intelligent Orchestration can address — to the benefit of both teams.
Intelligent Orchestration is a pipeline that runs parallel to the development pipeline and automatically enforces security policies. The attraction is that not only does it keep up with the speed of development, it also lets the organization define what those policies are.
The result? “Orchestrated” security testing, which means doing the right test at the right time and only reporting vulnerabilities that the development team cares about. No longer are developers overwhelmed with so many notices about trivial defects that they start ignoring all of them.
“It knows, based on the policies that you define and on the risk profiles that you define, when to run the right tests or when to skip the tests. Or when to run manual versus automated tests,” Rao said.
Organizations can assign a “risk score” to applications and then have Intelligent oOrchestration automatically enforce testing policies based on the score. So a high-risk app can get in-depth testing while a low-risk one can get much more cursory attention.
Bottom line: “Application security doesn’t have to come at the cost of velocity,” Rao said. “You define the rules and Intelligent Orchestration does the rest.”