CrowdStrike Outage- A better way forward for  Operating System implementations

August 12, 2024

CrowdStrike Outage- A better way forward for  Operating System implementations

Adding to the recent coverage of the widespread CrowdStrike and Windows Outage, this piece is our two cents on the incident.

But this blog post isn’t one criticizing CrowdStrike’s motives or implementation. Nor does it talk about how comprehensive pre-production testing is essential to prevent outages like this in the future.

It is about preventing the demonization of innovation in the Operating System, which has already been very low compared to innovation outside the operating system.

This blog aims to educate our readers on a technology that can accelerate innovation in the OS while reaping all related benefits without server crashes:

eBPF to the rescue

Some may think it’s astonishing that the current rate of innovation in the OS is so low. But when we consider the vast amount of resource control that the kernel possesses, it's obvious that any innovation within it would need rigorous testing. 

The kernel must remain stable, secure, and reliant under all circumstances to keep our digital ecosystem functional.

The slightest errors in any kernel updates could cause an entire server to fail causing irreparable financial damage, as seen last month with CrowdStrike.

But what if there was a way to keep innovating at the kernel level without ever risking server crashes?

Well, that’s what is possible with eBPF (extended Berkeley Packet Filter)!

Developers can add additional capabilities to the OS at runtime with eBPF as it allows sandboxed programs to run within the OS. Guaranteeing its safety and stability as the kernel capabilities are changed without changing kernel source code or load kernel modules.

These capabilities only get more useful in the current times as updates become more frequent to ensure protection against evolving threats. 

Updates that are being made live without thorough user-side quality testing cause server shutdowns, creating opportunities for hackers to exploit vulnerabilities. However, testing these updates for too long leaves networks vulnerable to the very issues the updates were meant to address.

Thus deploying eBPF sensors instead of kernel-module-based sensors is one of the few ways to avoid choosing between long regression tests and nil preparedness for zero-day vulnerabilities.

Even if any unsafe code is present within updates, the eBPF verifier finds it and automatically rejects execution. This verification is quite rigorous as Tech Titans and industry leaders have contributed 20,000 lines of code to the project.

eBPF and API Security-A match made in the kernel:

Considering the kernel’s privileged ability to oversee and control the entire system, it is apparent that it is the perfect place to implement security and observability functionality.  

Much is talked about its abilities to provide high-performance networking and load-balancing, application tracing, and insights for performance troubleshooting.

But not much about how well-suited it is for API Visibility as it can collect and analyze real-time data with minimal overhead.

Any API Security initiative would need the DevSecOps team to have full visibility (through inventory and documentation) into their API Ecosystem. Yet this was not possible because of 2 reasons:

  1. Most instrumentation was happening at the application level through Gateway and load balancer integrations, causing only a few external APIs to be visible, which carry less than 20% of the traffic.
  2. Traditional monitoring tools cannot read data as it is encrypted with HTTPS while flowing through the standard Linux network stack.

Since eBPF captures traffic right at the kernel level, it can capture and analyze traffic after decrypting it regardless of its origin giving visibility into east-west and ingress-outgress traffic.

Additionally, it also supports seamless instrumentation in complex containerized environments without needing to be installed separately in individual containers. 

Take your API Visibility to the next level with Levo.ai’s eBPF Sensor: 

The Levo team recognized this gap and pioneered a revolutionary instrumentation method built upon eBPF.

This helps us build the most comprehensive inventory portal for all your applications that contains these APIs across all SDLC environments:

  1. Zombie APIs
  2. Shadow APIs
  3. APIs with sensitive data
  4. Third-party APIs
  5. Internal APIs
  6. External APIs

The same instrumentation helps us automatically build API Documentation in OpenAPI/Swagger format with all needed specifications:

  1. Version details
  2. Method
  3. Endpoint URLs
  4. Parameters
  5. Request and response bodies
  6. Status codes
  7. Error messages
  8. Data formats
  9. Rate limits
  10. Changelogs
  11. Support details

eBPF helps us provide instant and complete visibility to our customers, eliminating quarters' worth of manual labor and error. Helping them reach their Security and compliance goals effortlessly as affirmed by several of our Fintech customers. 

Our innovation on top of eBPF has become such an important security use case that it has now become an industry standard. As not only does it provide full visibility but it does so without consuming a lot of cloud resources, unlike other methods like traffic mirroring. 

Our eBPF Sensor integrates with:

  1. VMWare Tanzu
  2. With Kubernetes as a Daemeon set ensuring it runs on each node of the Kubernetes cluster
  3. AWS API Gateway
  4. On-prem deployment

Have more questions? Check out our demo here or book one through this link. 

elliptical light
  • Runtime Agnostic
  • Cloud Agnostic
  • Programming Language Agnostic

Subscribe for experts insights on application security.

Oops! Something went wrong while submitting the form.