Under Attack?
We are a third of the way through 2021, and already we have had several major cybersecurity incident stories breaking. Recently, the focus of the news has been the problems with Microsoft Exchange, and obviously because of the proliferation of on-premise exchange servers, this has rightly taken the spotlight over the last few weeks. However, if we cast our minds back to before Microsoft’s announcement of its urgent Exchange patch, the big news in the Cybersecurity world was the Solarwinds Attack (known by many in the industry as Sunburst). This attack resulted in malicious infiltrations into a range of IT and Cyber Security focused organisations, as well as Departments of Government in the United States and across the globe, and into major multinationals. Breakdowns of the Solarwinds Attack are available from many sources on the web; however, the purpose of this blog is to examine the overall problem of Supply Chain attacks and to highlight some of the precautions that you can take to protect your organisation against this type of attack.
Types of Service Chain Attacks
From its name you may immediately think of your traditional supply chain, however a supply chain attack is an attack on a third party that supports and is connected to your network. For this reason, it is also known as a Third-Party Attack. Often your traditional suppliers will not fall into this category. Instead, this covers the vendors and services that you rely on to operate your business. This includes your IT and systems support companies, the Vendors of the IT solutions that you leverage – such as Microsoft and Cisco – and the external systems that integrate with your network – for instance you have a cloud backup solution? All these need to be considered as part of the service chain for your network.
In general, we can divide Service Chain Attacks into two broad categories:
- Attack on a partner or affiliate company. Often you will see this referred to as “Island Hopping” or “Leapfrogging.” Organisations rely on partners and affiliates to such an extent that it is necessary to provide these partners with quite extensive access into our network. Many of us find enforcing a security policy on our internal network a significant enough challenge, that the need to be a watcher for our partners and affiliates is just too much. With all cyber-attacks, the attacker will usually take the path of least resistance to their target and, where we have implemented a strict cybersecurity defence mechanism, the attacker will look to the organisations that we trust to see if they can be leveraged as a steppingstone. For this reason, it is important that we all consider ourselves potential targets and take the necessary steps to protect ourselves, even if it doesn’t seem obvious to us how a malicious actor may benefit from compromising us.
- Software Service Chain Attacks –These happen when the source code of software that we trust is compromised and malicious elements are included and then distributed as signed patches or updates to that software. While we are all familiar with the problem of buggy patches being released by reputable vendors, we accept that these are caused by routine human error. Usually, if they are likely to cause a significant problem, we become aware of them quickly and can implement remediation. Where this code has been intentionally and maliciously added, our problems amplify exponentially. Malicious code is designed not to be detected so may sit on our networks for an extended period. When it does surface that there was an issue with the code, while we can remove that code, we cannot be sure of the damage that has been done, while the code was active.
The Extent of the Problem
The extent of the problem should not be underestimated. In their commentary on Securing the Supply Chain1 Accenture have estimated that 40% of cyberattacks are sourced in the extended supply chain. The “extended” supply chain is important to assess here too. Although from a number of years ago now, the findings from the 2018 Poneman survey, Data Risk in the Third-Party Ecosystem2 are still relevant today. During the survey, they identified that 23% of their respondents experienced a breach or cyberattack caused by an Nth Party (third party to a third party).
Similarly, when reviewing Software Supply Chain attacks, as well as considering the security controls that reputable vendors need to implement to ensure the integrity of their code base, there is also the impact of open source software on the problem. According to Sonatype, in its 2020 State of the Software Supply Chain3 report, more than 1 in 10 downloads from open source repositories contain vulnerabilities. If we just examine the proliferation and our dependency on Linux, we can start to comprehend the problem. Historically, the thinking about Open Source software is that because of its nature, anyone can look at the code and vulnerabilities will quickly be uncovered. However, in reality we have seen that vulnerabilities in some mainstream open source software, such as Heartbleed, have taken years to come out in the open. We must acknowledge that these vulnerabilities may have been known about in advance and leveraged by malicious agent.
And the problem isn’t limited to off the shelf software either. Where bespoke software is being developed it is quite common for the developer to access open source repositories for elements of the code that they will leverage in the final product. Why re-invent the wheel after all? While some repositories, such as Github, have recognised this problem and have introduced code-scanning to identify vulnerabilities before they are published in the repository, this is still only the first step in resolving this fragment of the problem.
History
While we might think of the Sunburst attack as audacious, it certainly wasn’t the first of its kind, and unfortunately won’t be the last. Just looking back over the last decade, we see the RSA breach back in 2011, where the intended target was Lockheed Martin. This case is interesting in itself as we tend not to think of organizations of the prominence of RSA being the stepping stone into other organisations, but obviously, given its reputation, and its importance in securing other systems, it is also a highly prized target. Then there was the Target breach in 2013, which was rooted in a supply chain attack from a refrigeration contractor. As we advance through the decade and look at the NotPetya attack in 2017, we see an example of a Software Supply Chain attack. In this case the malware was initially loaded into an Accounting Software update, popular in Ukraine.
These are just some of the examples that have arisen in the last few years and there are many more. The important lesson to take from these is that as hard as it is to enforce good security over the direct network that we control, it is exponentially harder to enforce good security practice over the partner companies and vendors that we rely on to keep our businesses running.
Best Practices for Protection against Supply Chain Attacks
So how can we protect ourselves, knowing that the major cybersecurity organisations and governmental departments have fallen victim to these types of attacks? It’s not easy! Certainly the one take-away NOT to take from the Sunburst attack is to scale back any patching programs that are in place. However, it is important to monitor the network and understand what normal looks like, so that you can identify abnormal. Given the complexities of modern networks that can be a challenge, but this is where the introduction of AI into monitoring and detection systems (such as XDR – eXtended Detection and Response) can help.
When managing third parties, it is important to ensure that any access that you provide to them is fully audited and monitored. PAM (Privileged Access Management) solutions can help here too, as well as managing the access that both third parties and users have to your systems, they can also monitor and record the actions of users, and act as a gate to prevent automated malware transferring from third parties onto your network.
The importance of third party risk assessments cannot be understated here either. It is essential that we understand how seriously our partners take cybersecurity. And indeed, it is just as important to know that they undertake the same processes with their third parties.
How Kontex can help
The steps that I have outlined above are only a small subset of the safeguards that we need to implement to protect ourselves. If you would like to discuss how these solutions can be implemented within your environment, or indeed what protections are suitable for your requirements.