DISC InfoSec blogsupply chain Archives

Sep 07 2022

Government guide for supply chain security: The good, the bad and the ugly

Category: Information Security,Vendor Assessment — DISC @ 8:11 am

Government guide for supply chain security: The good, the bad and the ugly

ust as developers and security teams were getting ready to take a breather and fire up the BBQ for the holiday weekend, the U.S.’s most prestigious security agencies (NSA, CISA, and ODNI) dropped a 60+ page recommended practice guide, Securing the Software S u pply Chain for Developers.

My first reaction was that it’s great to see these agencies adding to the public discourse in these still heady days where we’re all sorting out software supply chain security best practices. This is an important voice in shaking out the still many requirements, frameworks, and best practices, and kudos to them for sharing some of their hard-fought lessons learned.

But I think it’s also important for developers at large to weigh what makes sense in the most extraordinarily sensitive national security environments, versus what makes sense for the average enterprise developer and security team.

Here’s what stuck out to me as the good, bad, and ugly implications of the report.

The good

There are some excellent, prescriptive recommendations in the report where these agencies are advocating specific frameworks like Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”) and Secure Software Development Framework (SSDF). The report mentions these frameworks 14 and 38 times, respectively, and for developers and security teams that realize they have a software supply chain security problem but don’t know where to start, now they have a clear path to take their first steps.

The upshot of these frameworks is they give developers clear guidance on (1) how to develop secure code, from design issues to organizational structure issues for more secure software; (2) build system integrity (making sure malicious code isn’t being injected in our build systems); and (3) what happens after software is built and how to operate systems security (vulnerability remediation, monitoring, those types of aspects).

I also think the report does an excellent job of emphasizing what software signing buys developers in terms of artifact security, and how by making the investment in signing and verifying at the start of the software development lifecycle, you can save yourself a lot of toil not having to worry about the security of the package managers further down the line.

The bad

The guide suggests that “all development systems must be restricted to development operations only” … and goes on to say “no other activity such as email should be conducted for business nor personal use.”

I can’t see a future where developers are told they can’t do Slack, email and web browsing on their dev machines, and here’s an example where what’s mandatory in air-gapped environments like the NSA don’t really map out to mainstream developer scenarios.

I also find that the SBOM guidance has great points, but also misses concrete threats and mitigation examples. Overall the industry continues to tell everyone to use SBOMs, but doesn’t really explain what to do with them or what the real benefits are. And while I like the guidance to compare SBOMs with software composition analysis (SCA) results, the reality is that today’s vulnerability scanners actually miss a lot of the transitive dependencies that make software supply chains an attractive threat surface in the first place.

The ugly

While open source is mentioned 31 times in the guide, it’s mostly superficial references, with no new recommendations. We all know most source code being used today is open source, and it has unique aspects for security – the report doesn’t pay any care to how to choose which open source projects to use, what to look for when deciding on a new dependency, approaches to scoring systems, or how to tell the security health of an OSS project.

There’s quite a bit of information overload. Half of the document explains what its contents are, and the other half presents a couple of frameworks and the intersections of those frameworks. I think what we’re going to see next is a tidal wave of security vendor product whitewashing, claiming to have the first capabilities conforming to these guidelines – but it’s important to remember that there is no accreditation process, and most of this will simply be marketing bluster.

What’s next

Software supply chain security is pretty unique – you’ve got a whole lot of different types of attacks that can target a lot of different points in the software lifecycle. You can’t just take one piece of security software, turn it on, and get protected from everything.

Guides and recommendations like this that come down from the most sophisticated organizations that have gone through the early paces give a lot of great clues for developers at large, and I hope the NSA/CSA/ODNI will continue to disclose this type of insight … even if it may require some decoding for what applies to more mainstream developer scenarios outside of the Pentagon.

Cyber Security and Supply Chain Management: Risks, Challenges, and Solutions

Tags: supply chain, Vendor Security Assessment

Comments (0)

Jul 14 2022

Vendor Security Assessment

Category: Information Security,Vendor Assessment — DISC @ 8:43 am

Assessing the security of network equipment.

This document provides guidance on how operators should assess the security of vendor’s security processes and vendor equipment and is referenced in the Telecom Security Act Code of Practice.

The purpose of the guidance is to allow operators to objectively assess the cyber risk due to use of the vendor’s equipment. This is performed by gathering objective, repeatable evidence on the security of the vendor’s processes and network equipment.

https://www.ncsc.gov.uk/report/vendor-security-assessment

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

DISC InfoSec

#InfoSecTools and #InfoSectraining

#InfoSecLatestTitles

#InfoSecServices

Ask DISC an InfoSec & compliance related question

Tags: supply chain, Third-party risk management, third-party vendor program, Vendor Security Assessment

Comments (0)

Sep 30 2021

Supply Chain Emerging as Cloud Security Threat

Category: Cloud computing,Cyber Threats — DISC @ 9:20 am

Supply Chain Emerging as Cloud Security Threat

Misconfigurations in software development environments and poor security hygiene in the supply chain can impact cloud infrastructure and offer opportunities for malicious actors to control unwitting victims’ software development processes.

These were the results of a report from Palo Alto Networks’ security specialist Unit 42, which conducted a red team exercise with a large SaaS provider.

Within three days, the company discovered critical software development flaws that could have exposed the organization to an attack similar to those perpetrated against SolarWinds and Kaseya.

If an attacker (like an APT) compromises third-party developers, it’s possible to infiltrate thousands of organizations’ cloud infrastructures, the report warned.

Supply Chain Flaws in the Cloud

Matt Chiodi, CSO of public cloud at Palo Alto Networks, explained that supply chain flaws in the cloud are difficult to detect because of the massive number of building blocks that go into even a basic cloud-native application.

“Our researchers estimated that the typical cloud-native application is built upon hundreds of these packages,” he said. “Let’s call them ‘Legos.’ Each of these Legos that developers plug into their application carries a certain risk and can be a vector to another supply chain attack.”

The report highlights how vulnerabilities and misconfigurations can quickly snowball within the context of the cloud software supply chain, and called for organizations to “shift security left.”

“Shifting security left is about moving security as close to development as possible,” said Chiodi. “Historically, security and development teams have operated independently of each other.” He added that development teams like to move quickly and try new things and security is more often the opposite.

“The concept of ‘shift left’ attempts to not change developer behaviors, but rather equip them with processes and tools that work natively to secure their existing methods of developing software,” Chiodi said. “If security teams can equip development teams with processes and tools that work natively with development tools and measure regularly, they greatly reduce their risks of supply chain insecurity from cloud-native applications. This is a good first step.”

He pointed out the first wave of migrations to the cloud was marked by “lift and shift,” meaning that organizations simply took existing applications as-is and moved them to the cloud.

“When they did this, they could say the applications were running in the cloud, but the applications themselves were not cloud-native,” he said.