CrowdStrike is a Harsh Reminder of the Danger of Third-Party Clients

The world was recently reminded of the downsides of clients and agents. The CrowdStrike incident has highlighted the inherent problems with client-based solutions, of which many in the tech community have long been wary.

Kernel-level access can be particularly problematic when you’re granting it to third-party software. A quick glance at any relevant Hacker News thread reveals widespread frustration and wariness towards client-based solutions: Crowdstrike just happened to be the problem this time, but what about all of the other third-party client installed in our systems?

The answer is: all clients are problematic.

The CrowdStrike Incident

CrowdStrike, a prominent cybersecurity company with an Endpoint Detection and Response (EDR) product, recently pushed an update to its Falcon platform. This update was catastrophic, causing a fatal crash-loop on Windows machines and rendering them inoperable.

For a more detailed summary and write-up, here’s a link to CrowdStrike’s own post-incident review.

Industry Reaction and Break-Glass Procedures

Security professionals were scrambling to manage the fallout from the CrowdStrike update. This included activating break-glass procedures typically reserved for natural disasters. From provisioning new machines to manually recovering data from bricked devices, the response was extensive and urgent.

The incident affected over 8.5 million endpoints, including critical infrastructure from airlines to hospitals to everyday applications like the Starbucks mobile ordering app. The long-term impact is still uncertain, but one thing is clear: every company is now reevaluating their client-based solutions and the level of access these third-party software have in their infrastructure.

This level of disruption to operations will undoubtedly prompt a reevaluation of security practices across the industry. At the very least, the reliance on client-based security solutions is likely to come under intense scrutiny.

The Problem with Client Access

Device identity and posture are crucial for context-aware access, but the method of obtaining this information matters significantly. Relying on a device's self-reported status is inherently risky; when a device is compromised, the first thing malware wants to do is make the device lie about its identity and state. Worse still, identifiers like certificates can be easily stolen or cloned.

To address this problem, CrowdStrike’s Falcon and other EDR solutions are used to register device identities and report their current state. However, the installed clients fundamentally function as third-party software installed on your devices to monitor or even modify your device.

Add Kernel-Level Access for a Bad Time

Kernel (ring0) access allows software to interact directly with the core components of an operating system. This level of access is where the OS and device drivers operate, and it's also where the most severe bugs can occur. A fault at this level can cause entire systems to crash, leading to the kind of widespread outages seen today.

Trusting any software at the kernel level is particularly problematic. Kernel-level software, or ring0, operates at the highest privilege level in a system. If something goes wrong here, the consequences can be catastrophic, as we saw with the CrowdStrike incident.

The Case Against Clients

So where are we now? We have third-party software called clients being installed on devices throughout our system with kernel-level access, giving them the ability to monitor and modify core components of the operating system with unfettered privileges.

If that gives off malware vibes, that’s because it’s exactly what malware wants to do. The only difference is trust.

You’re trusting the third-party vendor to not ship faulty updates or abuse their footprint in your infrastructure. This is why other client-based solutions like Zscaler are being called out in recent days.

There’s a lot more to complain about when it comes to client-based solutions, but they all boil down to these points:

• Clients are cumbersome to maintain and inherently unreliable, unlike clientless solutions which do not run the risk of vulnerabilities from outdated or misconfigured clients.

• Auto-updates risk results like CrowdStrike’s Blue Screen of Death or require the company to task someone to manually test each update before rollout, increasing security gaps while the test is being conducted.

• Closed-source software in your system does not allow for verification, meaning companies cannot verify what the software is truly doing with kernel-level access.

Clients are a holdover from a time when certain functions could only be performed by installing a software on devices. Thankfully, many of these same functions can now be performed with clientless solutions to gain the same benefits without the associated risks.

Going Clientless for Peace of Mind

As a result, many companies have approached Pomerium to explore how Pomerium can insulate them from similar breaches. As a self-hosted reverse proxy, Pomerium is purpose-built for context-aware access without compromise, being the only solution on the market capable of the factors discussed above.

Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result is:

• Easier with clientless access.

• Faster by being tunnel-free and deployed where your apps and services are.

• Safer because every single action is verified before allowed to execute.

• Tailored to your organization’s needs by integrating all data for context-aware access.

Give Pomerium a try today!