Security Think Tank: Supply chain security demands systematic approach

As organisations have increased their own cyber security over the past five to 10 years, there has been an increase in indirect attacks via the supply chain. At the same time, there has also been an increase in ransomware, and the emergence of targeted ransomware linked with data theft and extortion.

This is, to some extent, because small to medium-sized enterprises (SMEs) in the supply chain are seen as an easier way into the enterprise than a direct attack. However, sophisticated supply chain attacks through larger companies have also been seen.

The increase in ransomware is a real threat, particularly where there is a single-source supplier. Ransomware has become more sophisticated, sometimes infecting backups as well as operational technology (OT), so companies may be unable to produce and deliver their products for three months or more after an attack.

It is essential, therefore, that we can have confidence in the security of the companies in our supply chains to detect and respond to an attack and recover quickly afterwards. 

As we move more to digital contracts and integration with suppliers, so the opportunity to mount an attack through the supply chain grows, first by compromising the supplier and then by entering the customer’s organisation through a purchasing portal or other shared service. We also need to be aware of compromised hardware or software that may be intended for our own internal systems, or integration into products or solutions for our own customers.

An example from some years ago was an attack on a company that created a website development tool used by several other companies to develop websites for their customers. As a result, the attack on the tool developer impacted many website developers and placed backdoors in even more of their customers’ websites. 

The risk from the supply chain will vary from organisation to organisation and supplier to supplier, so the first step is a risk assessment of the supply chain and the impact that may have. There are three main areas to consider: intrusion from a supplier or service provider into your systems; an attack placing malware in a supplier’s product; or a ransomware attack on a single-source supplier making that product unavailable. This means ensuring suppliers are protecting themselves and that your systems are protected from your suppliers. 

When ensuring that suppliers are properly addressing their own cyber security, it is important not to be prescriptive or provide advice about the measures they should take, because if they follow your advice and, subsequently, you suffer a supply chain attack through that supplier, they could not be held responsible.

The approach, therefore, should be to require that their systems are certified to standards such as ISO 27001 or Cyber Essentials Plus.  Suppliers should also be regularly audited and, ideally, they should carry out regular security testing of their systems. There is a lot of good guidance available on this, in particular from the National Cyber Security Centre (NCSC).

Suppliers may also have access to their customers’ systems. This may be limited to technical requirements through purchasing systems and direct submission of bids, or they may be providing maintenance services for production equipment, or security monitoring services. In any case, they will have access to equipment operating within their customers’ IT and/or OT systems. Here, the important considerations are to:

• Limit access to only a reduced number of the suppliers’ staff.
• Allow only virtual private network (VPN) access from the suppliers’ systems using two-factor authentication.
• Restrict their access to only those systems and resources they need to access to satisfy the contractual requirements.
• Limit privileges to the minimum necessary to complete the task.

In the case of hardware and software that is to be used in your own IT systems, or integrated into the products and services you provide, some additional requirements need to be considered for suppliers, and possibly for testing of products received from them. The main areas are around the security of the development and final software build environment.

The first step is the use of a software code configuration tool, configured to limit who can check-in code and create builds. However, the most vulnerable point in the process is the build of the final application, because malicious changes here cannot easily be detected.

A separate build environment with limited access to build personnel, and ideally isolated from direct internet access, should therefore be used. All code should be signed during the build process and the signatures checked on execution. While this must be the case with Windows, it is not always the case with embedded and some other applications. All software updates and patches should also be signed to prevent substitution in transit.

When integrating software, or software updates received from a supplier, into a system, it would typically be verified on a systems testbed before being loaded onto the operational system. On particularly critical systems, one could consider the use of different signatures for untested software and the final operational software, effectively reapplying the signature using a different “quality assurance” signing certificate after system test. This would ensure that untested software could not be used on the operational system.

All in all, this is not a simple process, particularly for large organisations with deep and broad supply chains, but it is a risk that needs addressing. Measures need to be systematic and assessed so as to minimise the complexity and cost to the business. Nor will it always be technical. Mitigating a ransomware attack on a single-source supplier may be done by holding several months’ stock of their product, or diversifying the supply chain to include a second source. It is, however, something that all organisations must consider and take control of.