The SolarWinds Supply-Chain Compromise has affected us all, whether we’re SolarWinds customers or not.
Why? It’s simple.
Technology is the foundation of every organization’s services—we all rely on it fully to deliver and protect those services. Today, the Security industry as a whole is on edge, knowing our entire system of trust can be compromised by a simple update.
With alert fatigue already plaguing the industry, this all leads to a question…
What if there was a way to monitor service accounts and activities from trusted applications without the resulting alert fatigue?
There has to be something vendors can do to better inform customers of the changes—and potential threats—that can come from a software update.
Life after SunBURST requires the Security industry to refocus our defense-in-depth strategy.
We must place less trust in our protective technologies, and at the same time, sharpen our detection capabilities.
The idea here is not to diminish budgetary allocations for protections, like next-gen AV’s, Firewalls, etc. Rather, it’s to use the raw non-alert data collected from these technologies. In doing so, you strengthen the extra defense-in-depth layer of detection within your organization.
Of course, it’s not always this simple.
Many organizations lack the resources to effectively implement a threat detection development lifecycle, critical to produce new detections from the raw data. Additionally, they struggle with the alert fatigue that creeps up thanks to the extra detections.
You can read examples of efforts you can take to effectively develop threat detections in an earlier series, Content Conundrums for the SOC.
The grim reality? As detections are built and Security Operations Centers become even more inundated with alerts to triage, they start ramping up regressive tuning practices, including safe-listing. Lots of safe-listing.
And herein lies a massive, missed opportunity:
What would have happened if teams detected SunBURST when it made its grand entrance into SolarWinds implementations? What if we had a detection at the front-end...not just a reaction to an avoidable breach?
Can you guess what the most safe-listed objects are within a SOC?
If you said service accounts and activities from trusted applications, you’re right. Especially those trusted applications that constantly perform activities on multiple machines within an infrastructure...trusted applications like SolarWinds.
This means even organizations that had detection capabilities in place to potentially detect the compromised SolarWinds update...didn’t. So, what happened? They either disregarded the alerts or never received them to begin with as the threat got filtered out before the alert was even triggered.
Assuming your organization does remove these accounts and activities from your safelists, how can you handle the alert fatigue that comes with it?
In SolarWinds Supply Chain Compromise — Is it possible to detect?, the author describes how Anvilogic helps organizations detect the next Supply-Chain Compromise, using:
- Ready-to-deploy detections
- A codeless scenario builder
- A unique detection framework
It all helps SOCs be more prepared to combat the ever-changing threat landscape.
Many of the findings from the SolarWinds compromise post-analysis details are detections that organizations can easily implement but tend not to as a direct result of the noise they can generate, including task scheduler creation, DGA calls, WMI executions, and system enumerations.
These kinds of alerts are individually noisy by nature but tying them together and looking for sequences among them would have easily alerted a SOC of SolarWinds’ change of behavior after a recent upgrade.
But wait…isn’t it normal for a technology application to behave and perform functions abnormal to the previous version? Isn’t this the nature of an upgrade?
There’s the rub...the next dilemma which lies outside of prevention and detection.
Vendors tend to be diligent about providing release notes for new features and bug fixes, but no technology vendor publishes potential behavior changes in their technology, especially from a security perspective.
Knowing whether SolarWinds should have been communicating to avsvmcloud.com—a seemingly legitimate looking outbound call—would have been valuable information for organizations that intentionally ignored their detections with the idea that “SolarWinds just had an update,” and, “This is just a new thing it does.”
If vendors would begin to publish new behaviors from their products through normal communication channels...behaviors that customers should expect...we can all be better prepared to defend ourselves when the next Supply-Chain Compromise occurs.
Transparency is key.
Open communication between vendor and customer must adapt, just as the defense constantly adapts to the threat.
The SolarWinds Supply-Chain Compromise has affected us all, whether we’re SolarWinds customers or not. I say, that shouldn’t be.
To learn more about Anvilogic, visit Anvilogic.com. And, to see what I mean by all of this in more granular detail, request a demo.
About the Author
Kevin Gonzalez is currently the Director of Security at Anvilogic where he is responsible for the threat detection lifecycle and corporate security.
Prior to Anvilogic, Kevin led cyber security operations, engineering, and architectural practices at Lennar Corporation and Cubic Corporation while consulting for several organizations to help build security analytic programs and architect security solutions.
Kevin is from Miami, Florida. He holds a master’s degree from Florida International University in Management Information Systems along with several cybersecurity certifications.
.svg)
