Securing the building blocks of your professional ecosystem
Supply chain attacks were up 78% in 2019. (Symantec) and are now thought to make up 65% of cyber-attacks! This will change over time and so will the attacks, the vectors, the preventions and the reactions. If you’re reading this in 2029 it’s probably safe to suggest this is out of date.
Supply chain attacks are so impactful because of the level of trust between the parties.
Supply chain risk is common knowledge among cybersecurity professionals, however, it often fails to be taken seriously by board members and procurement teams. Third-party supplier risk is seen as a third party supplier problem.
It isn’t feasible to expect a company to reinvent the wheel and provide everything in house. We use services from particular companies because of their specialisms, ie, I’m happy for Yorkshire Tea to supply my hot drinks, but I wouldn’t go to them for medical advice or a car MOT. We have to open up our businesses to third parties. If we didn’t we would have no offices, no operating systems, no coffee, air conditioning, you get the picture. So what exactly is a supply chain attack and what can be done about it? Let’s discuss…
What Is a Supply Chain Attack?
Almost all businesses use third-party software and services in order to operate. Those software and services then become a part of the supply chain of that business. A supply chain attack seeks to damage an organisation by targeting less-secure elements (suppliers) within the supply chain.
Consider your home; in order to function well you have suppliers; gas, water, wifi… your home operates well and you can concentrate on your life because you aren’t generating your own electricity, you are commissioning a supplier to do that for you. That supplier, ie, your electricity supplier, has their own suppliers, those suppliers have THEIR own suppliers and on and on…
A supply chain attack is a direct attack on the suppliers of a given target.
If an attacker’s aim was to stop everyone in a particular area from having access to gas, an option would be to attack a large gas company. But, that company will no doubt be large, have significant resources (money, employees, technical defences) enabling them to defend against attacks particularly well. However, there is another option, an attacker could attack a less protected, smaller, less security-savvy supplier of
theirs (the gas company) to gain a foothold into their trusted ecosystem of that ‘end-goal target’. Better still, if an attacker could compromise a service that was ingrained in a critical business function (software, applications) I’d be in a stronger and healthier position, one which could spread the attack wider and incorporate the entire consumer base of that application.

What Specifically Are Software Supply Chain Attacks?
Attackers target software developers and suppliers of software, compromising the software means any company which instals it also becomes potentially compromised. It’s not only the software, as in the source code which is a target but also processes, updates and plugins that are appetising for attackers. An attacker’s goal is to compromise legitimate software, which can be widespread and impactful in the case of an update or patch.
Memorable examples of supply chain attacks?
Solarwinds
SolarWinds is a large IT and software provider, hackers broke into ‘Orion’, a SolarWinds system, added malicious code and waited for SolarWinds to send out updates to their customers, which they ultimately did, unwittingly infecting their own customers. The code created a backdoor to customers’ IT systems, which hackers then used to launch further malicious activity. Solarwinds are thought to be used by over 30 thousand businesses, needless to say, this is a brilliant example of how and why software suppliers, in particular, are targeted. Thankfully this attack opened some much-needed dialogue about software suppliers and supply chain security.
Target
Target provides us with one of the best examples of supply chain attack dangers. Attackers compromised ‘Fazio Mechanical Services, a supplier of HVAC services (heating, ventilation and air conditioning) to target stores, due to a lack of network segregation in the stores those same attackers were able to access point of sale devices (POS) which enabled them to infect those devices with malware that stole shoppers payment card data from the memory of the devices. This attack resulted in 40million payment card details of target customers being stolen.
Who Instigates Supply Chain Attacks?
Let’s say you have a hospital, certain nurses, pharmacists and doctors with the permissions to access restricted medications, such as morphine have a key to medicine rooms. If the people who work in the coffee shop on the ground floor of that same hospital also were given a key to those rooms but were just expected to not abuse that permission, do you foresee a potential problem with that? What about the porters? Or the canteen staff? Would it be safe to assume that not applying restrictions on ‘roles’, and not physically segmenting compartments could lead to abuse? Of course, it would be sensible to assume that.
What I’m trying to illustrate here is that any opportunist with the know-how can execute an attack against a company should they find that they have the access to do so, so hardening your processes and systems against those opportunists is going to significantly reduce, if not eradicate those opportunists that happen across bugs in code that they can exploit the users of that code through.
However, the most prevalent attackers associated with targeted and often successful supply chain attacks are Organised crime groups and nation state-backed groups. Even so, they will always attempt the easiest routes available first, think of the attack on target (mentioned above) other retail stores of different chain brands were known to be customers of the same HVAC provider, but they were not compromised, the attackers went for the one with the least level of security restrictions in place. The onus is not just on your supplier but on you as a defender of your own data and systems.
How Does an Attacker Move from One Business to Another?
When suppliers become part of the trusted ecosystem of the target company, a threat actor only needs to compromise 1 of many within that ecosystem to gain that initial foothold, maybe not in the ‘end-goal target’ but within that trusted ecosystem of relationships somewhere along that attack chain.
Considering the wide range of attack techniques and vectors, and the fact that they must be relevant to the victim there are too many combinations to list here, however, any threat you can think of generally can be applied from within the comfort of that trusted ecosystem but the effort once accepted is much easier to execute. Let’s take spearphishing as an easy example.
I once was called in to help a manufacturing company that specialised in building custom moulds for factories. The supplier of the metals used to great those moulds became compromised, so when an email came to the finance director account from someone he knew explaining that they owed money for an outstanding invoice he, being overstretched, in a busy environment and with no phishing awareness, issued the payment. A payment of £43,538k, an inconspicuous number, not too big, not too small, definitely in line with the usual invoices he was used to issuing, was sent to a threat actor posing as a contact head engaged via email on a number of occasions in the past.
Had this email been sent by an unknown person, account or had the branding been slightly off that finance director likely wouldn’t have paid it but because it came in from a trusted supplier, with whom they had a trusted relationship it became a harder attack to defend against.
Because the compromised software is distributed by legitimate businesses it is signed and has a legitimate certificate of authenticity, because it is in fact authentic code from a legitimate vendor, it’s just been modified for malicious purposes. The malicious code will run with the same permissions as the application.
Other common ways to migrate from one business to another within a trusted supply chain;
- Software updates and installations
- Remote access
- Escalation of privileges
- Creation of accounts
- Accessing of Shared drives
What Are Some Ways to Avoid Falling Victim to a Supply Chain Attack?

Like the attack methods depend on the systems and services applied to a given environment, the defences depend on present vulnerabilities, attacks themselves and systems and services in place. For businesses wanting to generically defend against supply chain attacks as best as possible, there are a whole host of safeguards to put in place from contractual audits and change control to ACL lists and remote backups. Here are a few honourable mentions.
Use Strong Passwords and Encryption
If a company you use were to be breached, and attackers managed to access your details, being unable to crack your passwords and encryption could protect your most sensitive data.
Be Phishing Email Savvy
Even if a supplier were to send you an email, or text, check that the number and email address is legitimate. Simply google those details or check for misspellings.
If you are asked to make an unexpected payment out of sync for your operating rhythm, consider that the worst-case scenario and call/email the provider directly and ask for clarification.
A sense of urgency is a huge red flag when dealing with phone calls and emails from providers.
Google Alerting:
https://www.google.co.uk/alerts
Create Google alerts to notify you as soon as the news breaks about one of your more sensitive suppliers. Get a head start when things break the news.
Restrict access to internal code repositories and critical build systems.
If your business is to enable other businesses business (tongue twister) through your software, make sure that source code is under lock and key.
Maintain Up-to-date Systems
I get the frustration that the software supply chain attacks mentioned here might have you questioning whether updating systems is truly the safest bet. It is, should an operating system, or software vendor be compromised they are likely the best people to create a patch (security fix) and the quickest to deliver it should the worst happen.
Maintain a well understood and rehearsed incident response process
Should the worst happen, you won’t want roles and responsibilities to be confused, you’ll need to know how to access suppliers, what agreements are in place and what actions you need to take as individuals, as a business, as a supplier, a customer and what your legal obligations are. This is a lot to work out in the heat of the moment.
Operate a Secure Software Development Life Cycle
Making sure code is developed with security in mind, is tested and peer-reviewed will create a strong security-centric development environment, likely the best method of preventing exploitable security flaws in the first place.
Deploy Methods of Detecting Anomalous and Nefarious Activity
Utilising endpoint detection and response on critical endpoints, and Implementing SIEM across cloud and on-prem infrastructure to detect anomalous activity such as lateral movement, new account creation and much more.
Maintain Asset Inventories and an Approved Software Register
Knowing what you have and where you have it is half the battle, during the Log4j global panic attack, IT security teams reported the hardest task was identifying where and if it was present in their environments. Keeping good governance is a huge time saver in the event of a major incident. In addition to this, allowing only authorised applications to run, especially on critical systems is good practice.
Audit and/or query suppliers
Many companies are audited for various reasons, it’s always worth asking if your supplier is compliant with relevant security-related compliance checks, or simply performing your own in the form of a questionnaire and making an informed risk assessment internally, security compliance can in some instances be overkill, and some audits aren’t worth the paper which the certificate is printed on, and that is up to you to decide and to apply some common sense to.
Relationship Management
Commit to instilling cybersecurity in from the moment you begin to foster the relationship, ie, make sure that permissions are kept to a minimum, make sure shared resources, such as drives are restricted to a need to know basis and all best practices for vendor systems are discovered and applied where possible.
Find out more about the th4ts3cur1ty.company and how our services and help your business defend against supply chain attacks by dropping us a message at info@th4ts3cur1ty.company