Recent high-profile security incidents, such as the compromises at SolarWinds and CodeCov and the vulnerabilities in Microsoft Exchange Server, have drawn attention to the risks posed by the software we invite into the heart of our networks and often trust implicitly.

The processes and procedures for identifying and mitigating the risks posed by these third-party software systems is known as Cyber Supply Chain Risk Management or C-SCRM.  Whether it is an off-the-shelf software system or a library which is compiled into in-house developed software, understanding the supply chain that delivers the software onto our networks will help security managers to manage the risk.

There are essentially two types of risk associated with third party software: accidental security vulnerabilities that can be leveraged by malicious actors and deliberate software supply chain attacks.

What are Software Supply Chain Attacks?

When a threat actor infiltrates a software vendor’s network (or an open-source code repository) in order to inject malicious code that will later be delivered onto a customer’s network as part of another software product, a software supply chain attack has occurred.

The compromised software may be subverted from the outset, or the compromise may interfere with legitimate patching and update mechanisms to deliver a malicious payload through the trusted update channel.

How to defend against Software Supply Chain Attacks

There are several strategies that can help defend against software supply chain attacks – either by reducing the probability of an attack or spotting an attempted attack quickly and defeating it.

Enhanced Security Due Diligence when picking suppliers

Choosing to work with suppliers who can demonstrate a mature and security minded Software Development Life-Cycle will help prevent malicious actors getting into the supply chain in the first place.  Conducting due diligence before entering into contracts with new suppliers and requiring them to maintain agreed standards of secure behaviour will help protect your network.

Use existing secure development standards to benchmark suppliers, such as the NIST Secure Software Development Framework or the payments centric PA-DSS.

Deploy all software updates under a Change Control system

If left to their own devices, many software products will download and install updates automatically and at their own schedule.  This can be a problem if the update mechanism is subverted by a malicious actor.

Rather than allowing direct updates to be solicited by each device on your network, channel the updates through a central update system that is under your control.  This means updates can be quarantined, validated and tested before they are deployed to production systems at a time of your choosing. For example SCCM or WSUS can be used to manage the deployment of Microsoft Windows updates and related products.

Use file integrity monitoring to detect changes to software

If you are controlling the timing of patch deployment and software upgrades, then any changes to software outside of the expected time window can be detected using File Integrity Monitoring systems.  This will help identify if a malicious actor is pushing updates or installing malware such as a Web Shell on your systems.

Protect and secure the development environment

In many organisations, the production systems and networks are the most secure. Test environments are a little less tightly controlled and the development environment has little or no security controls.  While this may help developers to ‘get on with their job’ it also makes it much easier for a malicious actor who has gained access to the network to interfere with the development systems including injecting their own malicious code into your applications.

Building applications and compiling code is a production level activity and the systems that perform these tasks should be secured accordingly to prevent tampering and subversion of your in-house applications or software delivered to your customers.

Follow supplier guidelines and security baselines

When installing third party software, follow the security recommendations provided by the vendor and revisit these recommendations in case they have changed since your system was first installed.  Vendors will update their security recommendations to reflect changes in the software design and evolving threats and vulnerabilities over time.  It is quite likely that the security best practices you followed seven years ago when the CRM system was first installed have changed since then.

Manage the ingress of software updates

A compromised software update system may pull updates from servers controlled by malicious actors rather than the software vendor.  If possible, use firewall or proxy rules to limit the IP address and URL the software may contact in order to request updates to known and trusted servers of the vendor.

When a new software update is downloaded, check the bill of materials to confirm what has been delivered matches what the vendor said would be changing.  If hash values/checksums are provided for the changed files then actually check them to ensure the files have not been intercepted and changed during transit.

Manage vulnerabilities in well-known products and services

The risks presented by third party software are not limited to supply chain attacks, traditional security vulnerabilities also pose a significant risk – especially for well-known products.

When a vulnerability is disclosed in a well-known product – such as Microsoft Exchange Server – malicious actors start to attempt to exploit the vulnerability within a few days.  Such is the speed with which newly disclosed vulnerabilities are attacked that Google’s Project Zero has recently added a 30 day grace period before disclosing the details of patched vulnerabilities in order to give time for customers to actually get the patches installed before the vulnerability is disclosed and comes under attack.

Users of well-known products and services are advised to actively monitor for the release of security alerts and hot-fixes in order to be able to respond in a timely manner. Waiting for the arrival of the monthly security patch bundle may well be too late for high-profile vulnerabilities – as was seen with the recent Exchange Server ProxyLogon vulnerability.

Helpful resources

Further advice and resources to help you develop your Cyber Supply Chain Risk Management approach:

• Defending against Software Supply Chain Attacks – CISA
• PA-DSS Guidelines for developing secure payment applications
• OWASP Secure Coding Practices
• Microsoft Security Development Lifecycle