Much has been reported, blogged and pod-casted about the recent high-profile cyber security events surrounding Solarwinds. However, for many including myself, there has been a sense of foreboding about such an event for some time now, given the state of third party security. The response from the stakeholders indicate that while this event is still unfolding, the scope of the damage is unclear. Given the coverage, it is safe to assume most of us are aware of what exactly went on. However, for the sake of posterity, I will describe the hack one more time as briefly as I can.
One of the software updates for Orion, a network management software, created and distributed by Solarwinds was injected with a malware (Remote Access Trojan – RAT), which enabled hackers to unauthorized access into the roughly 18K Solarwinds customers, which include Fortune 500 and many government agencies.
So how did the hackers managed to inject the malware and upload it to the software update server? Current theory is that Solarwinds’ FTP server password was leaked through public github repository. The password itself was a textbook example of bad passwords (hint: it ended in “123”).
The rest, is unfolding in front of us like a slow moving train wreck.
Given the nature and sprawl of our attack surfaces, it is not very surprising that we are faced with these types of attacks. And if the ease and stealth with which this attack was affected is any indication, there could be more of these in our future. However preventing such issues is a huge challenge for the entire industry today. Detecting such RATs before they are widespread is not trivial. Malware scan would not be possible until this was identified as malware in the first place. Traditional third party security measures, audits would have been ineffective here since they typically only look “outside-in” at the external attack surfaces of the vendors. Would they have been able to uncover the password leak through the public github repo. Not really. Would they have uncovered the weak password in the update server? Highly doubtful. This problem seems squarely out of the scope of the current third party security assessment tools.
So is there a way to prevent these kind of attacks or are we left to react to them? Well there is one thing about this attack that stands out – the compromise of the software update server. Details about how this actually happened have to be confirmed but consider this. The software update / patch servers of your vendors are a huge part of your supply chain. There is increasing automation in software update process both on the delivery and deployment sides. This is both good and bad. Updates and features are delivered faster to your customers but your delivery pipelines need to be secured as well. In this case, the hosting of the software update pipeline should not have been left un-sanitized.
And, while this is the responsibility of the vendor but it could be argued that the customers have a role to play in this as well. If we agree that our vendor’s attack surface becomes a part of ours, then ensuring its security also becomes part of doing business with the vendor. But how could Solarwinds’ customers ensure this? This is where collaboration with vendors becomes an absolute must. Customers and vendors need to acknowledge that we can all benefit by improved cyber hygiene and securing the attack surfaces that we share. This goes well beyond scans of external endpoints and requires sharing of some security configuration, patch level information. This information can be used to monitor the shared attack surface by both the customer and the vendor. If the vendor agrees, this could be done on a continuous basis as well.
The customer benefits by knowing gaps in the vendors attack surface before hand, while the vendor can get his cyber hygiene monitored continuously by his third party (the customer). This could be a win-win approach.
While it is true that this hack was a result of failures at multiple levels and no single solution or idea could address all of those, preventing such attacks in the future should be a priority over simply reacting to them. A more collaborative approach recognizing the true scale of our shared attack surface in these times could be a way forward.