A new NIST specification promises to help software vendors avoid becoming conduits for advanced cyberattacks on their customers - and Zero Trust is part of the solution.
The Infosec world was on fire again last week, and this time, the focus was on a softphone client from 3CX, a provider of business communications solutions. In a software supply chain attack that’s been linked to North Korea, a malicious payload was included along with a routine and automatic software update. Given that 3CX advertises having over 600,000 clients with 12,000,000 users of their solutions worldwide, this was pretty big news.
But it’s not the first time we’ve seen a supply chain cyber attack - a 2017 attack on the CCleaner that affected over 2.3 million consumers was followed by major attacks on Solarwinds (2020) and Kaseya (2021). In fact, researchers at Comparitech found that over 700 million users worldwide have been affected by supply chain cyber attacks - nearly 10% of the world’s population! These attacks are relatively complex to carry out, but when successful, grant the attackers instant reach and scale.
So whose responsibility is it to prevent the spread of malware through a ransomware attack? Certainly, it can’t be the customer’s responsibility - although they are the ultimate target of a software supply chain attack, a customer has to be able to trust that the tools they buy aren’t booby-trapped.
So this leaves the software vendor. To maintain customer trust, software vendors need to take steps to ensure the entire design process is secured. This includes preventing malware from being injected:
- in upstream or open-source components that are part of the product;
- by hackers directly into source code repositories;
- into supporting packages, such as installation scripts;
- into service dependencies, such as the service which delivers updates
Many companies already have security checks built into their formal release processes, including gates intended to identify and reject malware before it gets into a shipping product. But, as the examples above demonstrate, software supply chain attacks can and do happen.
There is now a NIST standard that vendors can follow to identify and remediate gaps in processes and procedures in their implementation of a Secure Software Development Framework - NIST SP800-218.
There are two sections in NIST SP800-218 that can be particularly difficult for software vendors to implement - because it requires vendors to take steps to secure the development environment - both for code development as well as build and test. This can require significant infrastructure investment and re-engineering.
But there is good news: adopting a Zero Trust mindset can help secure these difficult infrastructure cases while minimizing effort from IT and disruption to the existing development flow.
Let’s take a look at a few examples:
Development Environments
It’s common practice for many software developers to check out code from a repository, develop on a local laptop, and then check code back in when done. While convenient for the developer, this is a real challenge from a security perspective, as developer laptops (and whichever coffee shop or airport WiFi network the developer may be using) are now part of the entire attack surface that needs to be protected. A single compromised developer laptop with access to the code repository can give an attacker the credentials needed to carry out a major supply chain cyber attack.
This is why NIST SP800-218 PO.5.2 calls for vendors to “secure and harden development endpoints (i.e. endpoints for software designers, developers testers, builders, etc.) to perform development-related tasks using a risk-based approach.” Examples of how to achieve this include providing the least functionality required by a developer on that endpoint.
But developers need their laptops for many other functions that are unrelated to the development activity - including communications (email and collaboration software - including softphones like 3CX’s) and web browsing. It’s not clear that a developer laptop can be locked down and restricted to development functions with least privilege.
Here’s where a Zero Trust Architecture (ZTA) comes in. You can create a dedicated virtual machine for code development purposes; developers can use ZTNA to access that virtual machine from wherever they are, and you can use micro-segmentation to allow that VM to check in and check out code. Essentially, the VM is fully-dedicated to the development task, keeping code and access to backend repositories off the user laptop.
This approach has additional benefits - it functions as a powerful data leak prevention system. Since the VM has no access to unauthorized hosts inside or outside the company, source code in the development VM doesn’t leak out. And, with ZTNA controls providing access to external users, you can uniquely identify and authenticate external contractors, enabling the use of unmanaged laptops.
Build and Test Infrastructure
The developed code in the repository has to be built, tested, and prepared for release. This is a critical phase of development, as injecting malware close to release gives the vendor fewer chances to catch it before it goes out the door. Malware could simply be packaged along with the application and shipped - which is exactly what was reported to have happened in the 3CX case.
NIST SP800-218 PO.5.1 requires vendors to “separate and protect each environment involved in software development,” which is a clear call for network segmentation. But it continues in PS.1: “store all forms of code… based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.” Clearly, the network segmentation method must also be identity-aware - something that’s very difficult to do with typical VLAN-based segmentation.
Again, a ZTA helps here by enabling the entire development environment - code repositories, the CI/CD pipeline, and test servers - to be micro-segmented with software-defined network security controls. The micro-segmentation applies to existing resources, making it simple and easy to set up and configure without touching the setup of the build pipelines and test environment. Aware of user, endpoint, and application identity, a Zero Trust micro-segmentation helps protect the development environment even if an attacker has access to the network.
There are a lot of benefits for software vendors to adopt NIST SP800-218 quickly; preventing your products from being exploited to deliver malware to a customer and avoiding the resulting loss of trust and customer confidence is key.
However, the US 2023 National Cybersecurity Strategy highlights the government’s interest in encouraging vendors to adopt secure development practices. Not only is the government planning to require vendors of products it buys to attest to following secure software development practices, it is also planning a game-changing move - the government plans to require vendors to follow NIST SP800-218 in order to avoid claims of liability. Put simply, if you don’t have NIST SP800-218 controls in place, and you ship malware to your customers, then you would be liable for their damages. Talk about a stick for compliance!
Zentera has helped numerous customers lock down their development environments to achieve the protection and controls needed for NIST SP800-218. Our approach is simple, and much easier to implement than completely rearchitecting your development infrastructure. While securing your development environment is important, you shouldn’t spend any more time on it than you have to - that’s where we can help.
Share this article
