In cybersecurity, nation states, cyber criminals, hacktivists, and rogue employees are the usual suspects. They fit nicely into categories like external attackers or insider threats.
But what about our essential suppliers, partners, and service providers?
We rely on them, sometimes inviting them in to help manage our networks and internal systems. It’s easy to overlook them as possible pathways for cyberattacks. But the shocking cyberattack discovered in December shined a bright light on supply chain vulnerabilities.
Table of Contents
Trust can be exploited
As the Cybersecurity and Infrastructure Security Agency (CISA) continues investigating, they reported on January 6 that “one of the initial access vectors for this activity is a supply chain compromise.”
In short, attackers breached a popular network product, one that organizations around the globe trust to manage and monitor their infrastructure. They abused its update system to disguise and deliver malicious code, impacting thousands of customers including high-value US government agencies.
Not new, but easily overlooked
MITRE is well aware of supply chain risks, and they’re not alone.
Back in 2018, they updated the Enterprise ATT&CK Matrix with Trusted Relationship (T1199) and Supply Chain Compromise (T1195) to increase awareness of these adversary techniques. The latter, Supply Chain Compromise (T1195), focuses on the manipulation of products before customers receive them. It also covers software development environments and product update/distribution mechanisms. Sounds a bit like the December cyberattack, no?
The latter, Trusted Relationship (T1199), is relevant in that attack too. MITRE defines it like this: “Adversaries may breach or otherwise leverage organizations who have access to intended victims. Access through trusted third party relationship exploits an existing connection that may not be protected or receives less scrutiny than standard mechanisms of gaining access to a network.” With so much on cyber defenders’ plates, scrutinizing a product update system isn’t likely to be top-of-mind.
There are still a lot of unknowns with this attack, but the security lesson is clear: Trusted relationships must be built on zero trust. Whether it’s our own employees, suppliers, partners, or service providers… we simply can’t trust anyone.
Segmentation is zero trust magic
In this blog series, the Magic of Mitigations, we’ve highlighted Mitigations as MITRE’s recommendations against attacker behavior.
For the Trusted Relationship (T1199) technique, MITRE recommends Network Segmentation (M1030) as one of just two mitigations. The other is User Account Control (M1052), a Windows configuration step that helps stop adversaries from gaining elevated process access. There’s certainly magic in both, but let’s focus on the first.
Network segmentation is a simple concept where the network carries only authorized traffic. People and devices can reach only the systems they need, when they need then, and that they’re explicitly permitted to access.
Its magic is zero trust, least privilege access that can contain a cyber breach, stopping the spread of malware and infections. Logical segmentation can prevent unauthorized communication between, say, an infected network management system and the attacker’s command-and-control infrastructure — without relying on costly, legacy approaches like internal firewalls, VLANs, air gaps, or dedicated admin networks.
Beyond mitigating Trusted Relationship exploits, MITRE says segmentation defends against all of these adversary techniques too:
- Account Manipulation (T1098)
- Create Account (T1136)
- Data from Configuration Repository (T1602)
- Data Manipulation (T1565)
- Domain Trust Recovery (T1482)
- Exfiltration Over Alternative Protocol (T1048)
- Exploit Public-Facing Application (T1190)
- Exploitation of Remote Services (T1210)
- Man-in-the-Middle (T1557)
- Network Service Scanning (T1046)
- Non-Application Layer Protocol (T1095)
- Non-Standard Port (T1571)
- Remote Service Session Hijacking (T1563)
- Remote Services: Remote Desktop Protocol (T1021)
- Service Stop (T1489)
- Software Deployment Tools (T1072)
What other security approach addresses so many threat vectors?
The magic needs a little magic
Okay, network segmentation needs a sprinkle of pixie dust first.
It relies on a policy tightrope: Too loose, and your organization remains at risk. Too tight, and you might break something and disrupt service. For critical infrastructure sectors, where uptime is job one, that’s a no-no.
Until recently, a lot of work went into finding the right balance. First, you’d have to monitor network activity over a long period, baseline it, determine what’s normal and what isn’t, what’s authorized and what isn’t. Then you’d define segmentation policies, translating them into a product interface — and watch to make sure it’s doing what you wanted.
After that, you’re still not done. You’re continually adjusting them to support new deployments, system retirements, and countless other changes on the network. It can be a never-ending cycle of monitor, manage, reconfigure, repeat.
The pixie dust and the magic
At Cisco, we’ve been doing network segmentation for a long time. And no, I’m not talking about VLANs. I’m talking about our magic of modern, scalable, manageable segmentation. Our pixie dust is automation.
We provide deep visibility to see and classify everything on the network. We analyze network activity to suggest segmentation policies based on your traffic and devices. We know micro-segmentation and granular control over applications and workloads. We make policy enforcement simple and consistent, so that you can act quickly and with confidence. And the best part? Our solutions integrate to work together as a team, using threat intelligence to adjust policy quickly and contain new threats.
Learn more
Check out our detailed whitepaper that maps all of our solutions to ATT&CK Enterprise, posted to our Cyber Frameworks page. And do you want to learn more about ATT&CK, including their latest ATT&CK v8 updates? Watch our SANS webinar and get up to speed today.
Share:
Leave a Reply