This week the US government, as well as many enterprises, were hit by a cyberattack, dubbed Solorigate, via the SUNBURST backdoor. Fireeye (also a victim of the attack) has done a great analysis of how the attack works, and we recommend reading it.
But we’ll focus on a couple of takeaways instead of the precise details of how it worked. What we can learn from it in order to improve our cybersecurity posture.
We have to do thorough security monitoring of our environments
No matter how evasive a malicious actor is, they still do anomalous things that are detectable. In the Fireeye analysis, there are multiple detection opportunities. A well-configured SIEM should be able to catch at least some of those – landspeed violations (using the same account from too distant IPs over a short period of time), “single system authenticating to multiple systems with multiple accounts”, “SMB sessions that show access to legitimate directories and follow a delete-create-execute-delete-create pattern”. Probably there are other anomalous and therefore detectable activities as well.
This lets us once again iterate the truism that no matter how great a product you’ve purchased, it’s only as good as its configuration, which is in part a function of how easy it is to configure and use. (That’s why one of our main goals is to make SIEM simpler, so that “datasheet features” are actually useful in practice, alerting and preventing attacks like Solorigate).
Our organization can be collateral damage
In this case, anyone using a particular product can be a victim even though they are not the reason for the attack. That’s why our security strategies can’t assume a lack of interest from malicious actors and management teams can’t afford to cut budgets with the mantra “why would nobody want to hack us?”. Sadly, the answer is: “because they can”.
We can’t afford to trust anything
That’s the logic behind the zero-trust model, which unfortunately has turned more into a marketing slogan than real security practice. And it goes beyond just the network perimeter – we can’t afford to trust even the most reputable vendors, we can’t afford to trust our employees, we can’t trust any outbound traffic. (What happened to SolarWinds can happen to any popular vendor, with the right amount of time and motivation from a nation-state actor)
This doesn’t mean we should automatically block everything, or that we should decompile each binary and look for hidden malicious payloads, but the SUNBURST would not have worked if outbound requests were allowed just to trusted SolarWinds IPs and/or domains. Now, they can be compromised as well, of course, which is why we should utilize real-time threat intelligence and possibly even block all outbound traffic for certain components. For example, our products at LogSentinel don’t need to “call home” for anything, because we are aware that this introduces security risks (we do check for updates and for license info, but that’s entirely optional). Calling home should be a well defined, strictly timed, properly configured and thoroughly monitored process, not something that “just happens”.
We need security at every level
The root cause of this issue seems to be that malicious actors have somehow infiltrated a software vendor (SolarWinds) and either injected code into their release pipeline or compromised signing keys and FTP credentials (or both). That allowed them to ship the malware in a perfectly legit form – signed by a trusted vendor, as part of a normal plugin.
This emphasizes that we need security at every level – at our source code repositories (for both vendors and companies that procure custom software), at our build tools and continuous integration environments, at our release process, at our key management, as our vendor assessment, at our 3rd party software monitoring, and at our whole infrastructure. A mistake at any stage can lead to severe incidents, even if the rest of the process is “mostly okay”.
Alert fatigue and lack of threat sharing can cost a lot
As stated above, even though highly evasive, this attack is detectable. And it probably has been detected somewhere. But the world learned about it when it was too late. There are many possible reasons for that, but two of them are “alert fatigue” and lack of threat sharing. Even if some SIEM or IPS/IDS out there detected the malicious activity, the alert may have been buried deep down with other ignored alerts, because the security team is overworked and overburdened. “Oh, yet another authentication anomaly, probably nothing serious, again” is something that has likely happened. There is no silver bullet for that problem – we should tweak and refine our rules and machine learning models and let security teams automate as much as possible.
The other possible issue is the lack of threat sharing. Even if the proverbial alert was handled in one or several organizations, and accounts were disabled, ports blocked and domains denied, the rest of the world didn’t learn about it. Standards like TAXII should be used for both pushing and pulling threat intelligence information (LogSentinel SIEM supports both) so that we collectively can be warned. That’s rarely a technical, but rather an organizational issue – who do we share threat intel with and how. This point is speculative – maybe the attack was so good, that no SIEM and IDS caught it. Which would be even worse, unfortunately.
In the days to come, we’ll probably learn more details and be able to draw even more conclusions. After each major security incident, there’s some dread that “nothing is secure and nothing can be sufficiently secured”, yet on the next day things are just “business as usual”. But we have to look back and improve – our processes, our tools and sometimes, our mindsets.
If you’re interested to learn how LogSentinel SIEM can help you improve your information security posture, just book a demo today:
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
