DISC InfoSec blogVendor Security Assessment 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)

Aug 28 2022

Why You Need a Third-Party Risk Management (TPRM) Program

Category: Vendor Assessment — DISC @ 9:56 am

Why You Need a Third-Party Risk Management (TPRM) Program

What entity, or sector doesn’t engage with a third party in some way, shape or form? Not many. The reality is that outsourcing, contracting and subcontracting happen all the time and is the norm as businesses continue to embrace the core/context mindset and division of labor. The more you outsource, the more you need to have a robust third-party risk management process (TPRM), also known as vendor risk management, plan in place.

Risk management is not new, but the current iteration of TPRM logic typically focuses on three parts:

Risk assessment and analysis
Risk evaluation and
Risk treatment.

I had the pleasure of chatting with David Medrano, director of third-party risk management at Morgan Franklin, who shared his insight on the importance of TPRM and vendor oversight. Medrano explained that many enterprise entities may have over 1,000 separate third-party engagements and, therefore, must have a methodology to measure the risk each of those presents.

Medrano said that while many entities know their contractors, they may lack visibility into the contractor’s contractor; thus, a daisy chain of outsourced work may be taking place which places data at an unknown level of risk as the third party shares it with a fourth party and so on. The most important thing an organization can do, in this case, is to categorize vendors in the planning/strategy phase. Suggested risk buckets may include critical vendors, physical vendors and technology vendors.

“Bucket them according to how and what they do and how their third-party actions present a risk to you,” Medrano said. The risk from the coffee vendor, for instance, is not the same as the risk provided by an MSSP. He advised caution with regard to allowing more risk to be accepted than the vendor’s worth or value to the enterprise.

Medrano also advised keeping the methodology used uniform, as that can help manage risk while also showing customers, regulators and compliance entities that the company has a methodology in place to measure and address risk and explains the company’s thought processes with regard to its actions.

TPRM Tools

Ironically, there are a plethora of vendors (yes, third parties) who are prepared to provide you with tools to create your TPRM program, there are also standardized methodologies available from the U.S. government. For example, the National Institute of Standards and Technology (NIST) has created a TPRM framework to help companies create a consistent and uniform TPRM plan which is adaptable to their unique needs. The NIST framework can help you:

Prepare – Essential activities to prepare the organization to manage security and privacy risks
Categorize – Categorize the system and information processed, stored and transmitted based on an impact analysis
Select – Select the set of NIST SP 800-53 controls to protect the system based on risk assessment(s)
Implement – Implement the controls and document how controls are deployed
Assess – Determine if the controls are in place, operating as intended and producing the desired results
Authorize – Senior official makes a risk-based decision to authorize the system (to operate)
Monitor – Continuously monitor control implementation and risks to the system

In sum, every business unit should be using a TPRM system, regardless of if their engagement with third-party vendors is centralized or decentralized. Additionally, uniformity in the assessment is of paramount importance, Medrano said.

Third-Party Risk Management: Driving Enterprise Value

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

IT Vendor RISK Management Toolkit

Tags: Third Party Risk, Third Party Threat Hunting, Third-party risk management, TPRM, 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.