Hello there, and welcome back! If you’re just now tuning in, I’ve decided to do a collection of blog posts on what I think are going to be major cybersecurity topics this coming year.
In the first blog post, I introduced you to what a supply chain attack is, why it’s such a big deal, and the importance of asset and software inventory management towards countering this threat. This post is a follow-up in which I offer a few more recommendations on what can be done to better defend your organization against supply chain threats.
Auditing and Documenting Privileged Assets and Software
One of the key details that made the SolarWinds backdoor so scary was that this vendor was a trusted third party whose tools and applications are typically deployed in privileged places in a customer’s network. SolarWinds Orion is network monitoring software–that means systems with this software installed often sat in network segments that could access many other portions of the network and had privileged account access to a lot of other systems.
If you’re going to have any hope of mitigating this sort of threat in the future, you need to identify software solutions that have this level of access in your current network. This includes answering questions such as:
- What network monitoring tools does your organization use?
- What EDR or Anti-malware suites do you utilize?
- What software do you utilize to perform patch management?
- What sort of system access do these solutions require (e.g. network service account, local admin, domain admin, etc.)?
- What sort of network access do these solutions require? both to your organization’s assets as well as to the internet?
- What appliances perform network monitoring or core network security functions?
- If you lose trust in any of these solutions currently deployed, what is your backup plan?
Once you are able to answer these questions, document them with your asset management database.
While not explicitly stated here, many enterprise software solutions request that customers make antivirus exclusions so their software can run. Enterprise products requiring exceptions like these is a massive pet peeve of mine. Unfortunately, enterprise software means following their guidance if you want technical support for their products, so be extra mindful of any firewall and EDR exceptions the vendor claims are required for the software to work. Ensure they are documented.
Baselining and Deviations
I’m going to keep this section short and sweet. Knowing what constitutes normal on your network will help not only with troubleshooting, but also with detecting malicious actions. When establishing network baselines, think about some of the following questions:
- Do you know what “normal” looks like in your network?
- Do you know what normal network traffic looks like with your privileged third party hardware and software?
- What IP addresses, domains, protocols, and URLs are used to download software updates over the internet?
- How are systems on the network probed?
Establishing baselines is another one of those easier said than done tasks–like asset management–that makes most professionals want to get drunk and set fire to things. But on the bright side, once it’s done, spotting the deviations, abnormalities, and unusual traffic to new destinations is much easier. Another positive aspect is that threat hunting is all about manually spotting anomalies and trying to determine whether or not they are malicious. Having baseline behaviors defined definitely helps to tune out the noise, and make informed decisions that much faster.
Roll for Initiative (Tabletop Exercises)
The proverbial icing on the cake of this blog post would be getting together with your network and security team and figuring out how you would remediate a supply chain breach of a major vendor. Consider a tabletop scenario where either a vendor with privileged access to your network (like the EDR, network or patch management suite examples mentioned above) or a third party that is considered mission critical to your organization or company has experienced a breach.
Consider the following questions to help lead the exercise:
- What software got backdoored?
- What is the time range of this compromise?
- How do you retroactively hunt through your logs for the indicators associated with the threat? What indicators are available?
- What assets run the affected software version or hardware manufacturer/model?
- What are your containment procedures?
- Has a business continuity plan been developed to ensure continuity of operations?
- What are the recovery plans?
- What other third parties/vendors can you rely on if trust has been completely lost?
Regrettably, I don’t have any silver bullets or fool-proof solutions that can help you prevent or detect supply chain attacks. What I do have, however, are industry best practices that, if properly implemented, may prevent your organization from becoming a victim.
Stay tuned for my next installment of The New Year in Cybersecurity!