The SolarWinds “Sunburst” supply chain attack is challenging security teams across the world. From a Vendor Risk Management perspective, it is already a time of soul searching, learning and improvement.
We expect the situation to continue to develop over the coming days, weeks and months. However, this is where C2 Cyber has got to in its thinking so far:
Attackers inserted their malicious code into a Solarwinds Orion network management product software update way back in March 2020. Customers that implemented the update gave the attackers access to their networks. They used this to steal credentials to gain access to more data and largely do as they please. Key targets were US Government departments, but any Orion users will have been at risk. FireEye is so far the other best publicised victim.
What do we know?
- It was a complex attack – The attackers are believed to have poisoned SolarWinds source code so that all customers got infected when they updated the software. This is not a trivial thing to do, as most modern software development has strong technical and procedural controls to prevent this happening. How did the attackers circumvent Solarwinds software update code signing? Or did SolarWinds drop the ball around their source code commit procedure? Similar attacks in the past have gained access to the target environment using a Remote Access Trojan and then found ways to access the credentials of authorized users. This means they could modify the code as though they were an authorised developer. Fireye has declared that the trojanized component is digitally signed and contains a backdoor that communicates with third-party servers controlled by the attackers.
- It was very stealthy - The adversaries used highly developed technical measures. A two-week dormancy phase, steganography, minimising malware use, all helped to masquerade as legitimate activity. This would suggest that the aim was to covertly steal and use credentials rather than disrupt. The backdoor delivered a stealthy malware dropper that does not leave traces on the disk. Luckily, Fireye went public when its red team tools were compromised. Otherwise, the Bad Actors could still be quietly working away within systems across the world.
What lessons can we already learn?
This supply chain attack emphasises the critical importance of supply chain risk management. But this was a highly sophisticated, targeted attack. It would be naïve to claim that using our service would have prevented your business being affected.
Luckily, the attack was clearly focussed, both from the perspective of the targets they were going after and the proxy through which they chose to attack. The prevalence of the Orion software means that the protagonists could have run amok through many other organisations if they chose to do so. In reality, the damage that has been done in terms of stolen information may never be known.
But just because you don’t believe you are a target of Foreign Intelligence Services does not mean that you won’t be attacked in the same way in six months' time. The aftermath of the NotPetya virus in 2017, and even Stuxnet in 2010, showed how quickly resources, tools and techniques that start off being the province of nation state actors move into the broader world of organised crime within months. The success of this exploit suggests we will see many more examples. And even if none of your direct vendors uses the affected system, one of their critical third parties may.
The real lesson from these types of attack is that vendor risk management needs to be a holistic practice. Digital transformation has brought with it an exponentially complex supply chain risk – it is hard not to be inundated by third parties who all protect their networks in different ways and characterise their risks according to their own perspectives. Working with critical vendors so that you both have a common view of the risks is key. Collaborating and sharing concerns, intelligence, and observations can be a catalyst for action with a mutual purpose.
The real solution must be a long term, continuous, standardised VRM programme based on self-assessment, external monitoring, technology-led questionnaires, threat feed monitoring, and ever more collaboration between customer and supplier.