Minimize Your Software Attack Surface

Minimizing Your Software Attack Surface

It’s staggering that the average security breach lasts 228 days before detection. For more than seven months, bad actors who illicitly access systems can live off the land while looking for tools, passwords, files, secrets, executables, and other vulnerabilities. They cover their tracks by replicating communication and traffic patterns that look completely normal on a victim’s network.

To put this into perspective, let’s say someone got into your company’s infrastructure on January 1, 2022. You and the team were celebrating the new year while someone surreptitiously found a way in. If you fit the average trend, you won’t even realize you were compromised until August 16, when you may be enjoying a late summer holiday.

Bad actors gain access and survive for so long partially because systems are complex with numerous components so  IT and product teams don’t fully understand their own infrastructure or workloads. They often use existing inspection tools left in workloads to go deeper into infrastructure and move laterally towards their targets.

These are tough challenges to address!

Let’s talk about how organizations have historically protected their infrastructure, which was mainly around network attack surface management. How cloud changes that, how software is now built, and how we are now at a point at which new tactics must be employed to minimize the software attack surface.

The Attack Surface Includes the Software

The term “attack surface” has traditionally been defined by network, cyber security, and IT teams who protected the network perimeter but now the software layer needs to included in that description. An attack surface is the totality of all points that can be exploited to get into your system. It includes many facets of computer infrastructure, like the network perimeter, AND all the software behind it.

Any hold someone can find to get into your system constitutes the attack surface. Traditionally, the “attack surface” has been focused on the network. Firewalls, intrusion detection, and other devices are often employed to manage the network attack surface. But the reality is: software itself poses a huge surface.

Bad actors employ known and unknown vulnerabilities (zero day exploits) to compromise and exploit a system. These vulnerabilities are well beyond the network, which is why it’s so important to understand what components are running in your infrastructure when talking about the software attack surface. It’s no longer enough to manage and minimize the network attack surface. If the network is breached, which is much easier to do post the data center generation, the next line of defense needs to be at the software layer.

Security teams obviously have an understanding of this problem, but they don’t know there’s so much risk sitting in their infrastructure. Security experts are so focused on compliance, threat detection, and pen testing that they don’t have bandwidth to change processes, educate teams, and provide effective tooling.

Understanding Complexity in the Software Attack Surface

Modern software workloads are so sophisticated and rapidly changing build to build, they are ephemeral so spin up and down, so they are extremely challenging to fully understand without dedicated runtime tools. Developers are writing and assembling code by pulling together open source software (OSS) components with potentially significant attack surfaces. They’re also gaining incredible speed by using high-quality open source software components to develop software.

When an OSS package is widely popular, like Log4j, and it's used in millions of places, there’s a really large “blast radius” for a major vulnerability in that once compromised the vulnerability can allow a deep exploit quickly  and control of the host can be lost in a few keystrokes. On the other hand, bespoke code is expensive and creates risk only for the enterprise that develops and deploys it so its harder to gain visibility into. Software teams and enterprises have rightly decided the benefits of OSS components far outweigh the security risk.

Building an app with OSS components inevitably uses more code than is absolutely necessary. Developers already know this all too well, but the job of securing and minimizing this excess is tedious and riddled with unknown unknowns and hours of effort noodling through their code.

Challenges of Optimizing the Software Attack Surface

Few approaches exist to manage the software attack surface through runtime observability capabilities, but the issue is getting it granularly accurate to act on. One approach is to have privileged agents running on machines to monitor and react to unexpected behavior. Then there’s the classic approach of having security teams build constraints and policies into the SDLC, which often leads to contention between security and product teams.

Another approach is to rigorously build compact, self-contained workloads with small base OS images across every build and deployment. This is extremely expensive because its time consuming and requires a high level of maturity and advanced engineering talent.

Companies like Palo Alto Networks, Coinbase, and Google have developed sophisticated practices of managing extra code with minimal (aka “distroless”) images, CI/CD automation, and compiled binaries in languages like C, Java, Go, or Rust but this is rare for most enterprises and cost prohibitive for startups.

Regardless of approach, you may still be left with these questions:

• How do you gain visibility about a workloads complete runtime profile, especially in ephemeral workloads getting spun up and down dynamically?
• How do you profile and understand what is the correct behavior versus what is anomalous across a large number of instances?
• How do you hire and maintain teams with this level of rigor across an ever-changing technological landscape where speed is often prioritized over testing and security?
  

We believe it’s much cleaner to simply understand what you need and remove the excess code you don’t use. Developers are great at what they do and better software is getting delivered to customers faster than ever. Google, Amazon, Netflix, and Etsy have built incredible development practices that deploy changes to millions of users several times a day. And they’re fantastic at quickly delivering business value.

Why stop or slow this progress with complex management processes? Why deliver less business value when there are solutions available today that plug into today’s methodologies? Why “shift left” and give developers more work to do? 

The better question is: Why not use the technologies you want to use but then optimize your software attack surface just before it’s deployed?

Software Attack Surface Optimization Done Right

Software attack surface optimization gives you less software to manage, meaning you have less stuff to manage. Less software weight. Fewer vulnerabilities, packages, alerts, licences, and friction points. Once you have less, then you can move quicker—at the speed of devops.

The optimization concept and process is simple:

• Dev teams build what they need using the technologies tha allow them to move quickly
• Their code is instrumented through a stub
• This stub is observed to get a profile of what is actually being used
• Everything unnecessary is removed form the workload
• Only the code that’s needed to run then gets deployed
  

RapidFort is the only software attack surface optimization solution available today. It audits your infrastructure and workloads, gives you an optimized software bill of materials (RBOM), and presents optimization options for you to manage your software attack surface. With just a few clicks, you can dramatically reduce your workload sizes by between 60% and 90% (language depending, and keep yourself protected even from zero-day attacks).

In fact, we are making our Scanner available for free so you can see exactly what you’d get with RapidFort.