Log4j脆弱性を受けてサプライチェーンのリスクに対応

The Log4j software flaw is expected to wreak havoc on the internet for months and years to come. Patching it has become an arms race for enterprises and government agencies. Success will depend on network visibility, patching speed, and workflows.

Log4j is a logging utility. It is used by nearly every cloud service and enterprise network in the world to gain access to servers. It is just the latest software supply chain vulnerability (like the one that turned up in the massive SolarWinds attack) now plaguing our digital lives.

But the truth about these supply chain vulnerabilities is this: They can—and should—be policed before they can cause damage.

[Read also: What is Log4j and how do I protect my organization?]

Nick Selby, former chief security officer at blockchain services firm Paxos, isn’t interested in unnecessary chances when it comes to software supply chain security. That’s why he’s worried about the way many organizations now protect themselves.

“We’re trying to secure modern environments much the same way we did 20 years ago, and it’s fueling a complete misunderstanding of the attack surface,” warns Selby. “It’s something the industry needs to change–and quickly,” he adds.

Most of that misunderstanding is due to a lack of visibility into the security risks of third-party software, cloud software services, and open-source software. “Third-party risk from supply chain or software vulnerabilities within third-party software components continues to be a huge element of externally caused breaches,” Sandy Carielli, a principal analyst at Forrester Research, warned during the company’s recent Security & Risk Forum 2021. “Organizations probably have more third parties in their ecosystem than ever before,” she added.

Control all network IT assets in minutes with automated client management.

Attacks on software supply chains have boomed during the pandemic era. Just this past summer, Atlassian’s agile-project management and software bug-tracking tool contained a “one-click” attack that allowed a hacker to get into the agile planning system or their code repository—making it possible to inject exploits into an unsuspecting user’s codebase. As Forrester security analyst Chris Condo said at that company’s security and risk forum: “You wouldn’t know that someone had logged in and changed your software. These are the kinds of issues that are occurring daily.”

Supply chain attacks (not all of which are made public) are likely to have increased fourfold in 2021 over 2020, according to the European Union Agency for Cybersecurity (ENISA). In 66% of such attacks, ENISA notes, the attackers first targeted the supplier’s codebase to further their attacks to the ultimate target.

With attackers increasingly focusing on supply chain–style attacks, organizations must understand how to better protect themselves. Consider this the first step in any risk based vulnerability management.

Shift tactics to meet shifting attacks

Supply chain attacks are increasing because they can reach large organizations that haven’t changed the way they mitigate business technology and third-party risks in decades. “Companies haven’t kept up with how the modern enterprise buys, builds, and manages technology,” says Selby, co-host of the Tech Debt Burndown podcast, who recently left Paxos to join cybersecurity research and consulting firm Trail of Bits. “We are still running third-party due diligence based on spreadsheets that were written in the ’90s by accountants.”

Organizations probably have more third parties in their ecosystem than ever before.

Those tactics worked at a time when the main security risk from third-party breaches was the disclosure of proprietary data or the loss of services. But they don’t fare well when it comes to third-party risks aimed at a direct incursion meant to hobble or lock down your organization with ransomware. A risk-based vulnerability management strategy must take that into account.

Here’s how supply chain hacks work. Rather than targeting organizations directly, cybercriminals and nation-state hackers target software makers and software services providers. They inject attack code into software that is then used by other organizations. These attackers specifically target vulnerable software development pipelines and insecure cloud configurations, or they exploit software update processes.

Following the devastating SolarWinds hack, federal officials have sought to help agencies and private-sector organizations better manage software supply chain risks. In 2021 年 5 月, President Biden issued an Executive Order on Improving the Nation’s Cybersecurity, which requires vendors that provide software to the federal government to include a software bill of materials (SBOM) for everything in their products.

[Read also: What the Biden executive order means for tech executives]

An SBOM is like a recipe of the components and dependencies within a software application or package, including proprietary and open-source code.

“The executive order takes some unprecedented action,” Alla Valente, senior research analyst at Forrester, told the company’s security and risk forum audience. While it is not a cure-all or a replacement for good cyber hygiene practices, the order has accelerated supply chain security efforts.

Allan Friedman agrees. An SBOM advocate at the Cybersecurity and Infrastructure Security Agency (CISA), Friedman told a recent SecurityWeek CISO panel on supply chain security transparency, “One of the things that I’m fond of is better analysis and surveillance of the supply chain.”

Create a speed bump

Vetting third-party cloud and software providers starts with understanding their security maturity. Before Selby will engage with a software vendor, he begins with a simple, straightforward test meant to weed out those with immature security programs. “At Paxos, we had a 10-question questionnaire as our preliminary assessment, and it is extremely important. We have implemented this as our speed bump, not as our final security or compliance assessment,” he says.

If [your security chief is] the VP of engineering, then you don’t have a security program.

The preliminary questions include: “Do you have printed and written security policies and procedures? Can I see them? Tell me about your training regimen. Do you have a named executive whose sole responsibility is information security? “If yes, and it’s the VP of engineering,” says Selby, “then you don’t have a security program. I want to hear, ‘Yes, I have a chief security officer, a chief information security officer, a director of information security’—somebody who is on the hook and accountable for delivering security.”

An essential part of any software security assessment should also include third-party code reviews. Selby advises organizations looking at supply chain software to focus on understanding the vendor’s software development and its engineering team’s secure coding practices. “Are you doing secure coding training, and what do you do?”Selby asks. “Tell us about your training regime.”

Passing a security screening doesn’t mean the vendor will get the contract. But it does mean they’ve cleared the most rudimentary and crucial testing bar. “We at least know that we have confidence that they’re going to pass our compliance, security, and legal tests,” says Selby. “And that’s exactly what I think organizations should be doing, getting security involved early in the new vendor onboarding processes. Unfortunately, companies still don’t involve security until the very end.”

Open source is free, not free of risk

Proper supply chain security also requires discovering and understanding what on-premises and cloud software services and software are running in the network environment. “That’s a more complex challenge than it may seem at first,” says Selby.

It’s made even more challenging by the use of open-source components. “As organizations use open source to create applications, or use it within commercially available software, which contains as much as 90% open-source code itself, they’re introducing a scary amount of third-party risk into their environment,” Valente told the security and risk forum.

Commercially available software contains as much as 90% open-source code, introducing a scary amount of third-party risk.

Managing open-source software risks requires security teams to closely examine the software’s code. That doesn’t mean just checking for known vulnerabilities and believing there’s an all-clear if all patches are up-to-date. “Most of the time, that’s what happens” in a security team review, says Selby. “They check for CVEs [common vulnerability and exposures] for the open-source project, and if there aren’t any critical vulnerabilities, they will deem it OK. That’s nuts.”

Instead, security teams must look at all of the components and the software dependencies within an open-source project, and understand how the various components have been assessed and tested for security vulnerabilities. “Open source means that the source is open for you to use it and assess it and improve it,” says Selby. “Open source doesn’t mean take-it-or-leave-it.”

Software supply chain security in action

While President Biden’s executive order calls for new requirements on federal agencies to improve their security programs—such as implementing zero trust, improving cloud security strategies, and implementing SBOMs—the National Institute of Standards and Technology (NIST) is working to make those tools a reality.

Stop using the same spreadsheets that procurement weasels have used since the ’90s.

During a recent workshop, NIST reviewed updates to its special publication, SP 800-218. Released in 2021 年 9 月, it details a core set of high-level secure software development practices that organizations can integrate into their software development life cycles. The final SBOM usage guidelines are to be published in 2022 年 2 月.

Meanwhile, the National Telecommunications and Information Administration (NTIA) recently defined the minimum elements required in SBOMs. These should include the name of the software maker, software versioning data, unique ways to identify software components, a catalogue of dependencies between components, and a record of who created the SBOM and when they created it. NTIA has recognized three open standards to sharing SBOM information: SPDX, CycloneDX, and SWID.

Analysts say each of the three standards differs. While SWID is designed to track software licensing and commercial entitlements, SPDX covers licensing, software components, security information, and other metadata. At the same time, the CycloneDX standard is geared toward software security.

“CycloneDX is specifically designed to handle a range of cybersecurity use cases that go well beyond the minimum required fields that NTIA published,” Steve Springett said at the recent SecurityWeek CISO panel. Springett is chair of CycloneDX SBOM Standard, a working group of the Open Web Application Security Project (OWASP), the online community that produces free articles, methodologies, documentation, tools, and technologies for web application security.

[Read also: Is your agency prepared for software end of life?]

As standards continue to evolve, organizations looking to become more effective at secure software development will have to make do with what’s available. These processes are not easily put in place, and the tools to help are constantly evolving. Still, it’s essential for organizations to get started on securing their software supply chain. “Companies should be looking at how to leverage their existing software, whether it is a GRC [platform] or a third-party risk platform,” Valente told the forum audience.

While software supply chain security starts with close vetting of the security processes and secure software development life cycle, cybercriminals and nation-states will continue to launch attacks against service providers and then use those as launchpads to attack customers. Those customers that have the best general security practices in place will be more successful at maintaining security in their organizations.

[Read also: New survey—cyber professionals lack visibility and speed for effective threat management]

That entails understanding the software running within your organization and keeping it patched and up-to-date, maintaining good configuration management, and having effective monitoring and incident response capabilities.

As for Selby, he says one of the most important things organizations can do now is move as quickly as possible from the old ways of managing third-party software and supply chain risks.

“Stop using the same spreadsheets that procurement weasels have used since the ’90s,” he says. “It’s time to change these questions to focus on how these organizations manage risk to their environment.”