EDR for Linux Production Systems

Posted by

A guide to specific security considerations for protecting Linux VMs, containers, and bare-metal servers. You should keep them in mind as you work toward making your enterprise Linux more secure.

Understanding Indicators of Attack vs Compromise

Posted by

Understanding Indicators of Attack vs Compromise

It’s the choice between stopping an attack before it gets in or detecting a compromise after it affects your company

There are two main methods of detection in the security marketplace—Indicators of Attack (IoA) and Indicators of Compromise (IoC). The two methods approach detection in vastly different ways. 

In this Quick Read, we’ll cut through the crosstalk to compare and contrast IoAs and IoCs. Plus, we’ll share examples of Capsule8 Protect’s different approach to attack protection. 

How IoCs and IoAs Work

Indicators of Compromise

Systems that work by detecting IoCs are reactive. They look at events in retrospect—essentially flagging problems after they’ve happened. IoCs include specific after-the-fact markings to confirm a compromise to a company’s defenses, including:
  • IP addresses, files, and other markers
  • Specific behavior of known attacks
  • A focus on post-exploitation tooling and command and control
Because of the way they are set up, systems that are based on IoCs, although they show that a threat actor has compromised a system, can also generate high false positives. Moreover, IoCs are reactive because, by their nature, they only spring into action once a compromise has happened, which can leave an operation vulnerable.

Indicators of Attack

Conversely, although they are able to conduct after-the-fact investigations to uncover the markings of a compromise, systems that detect IoAs work in real-time to detect exploits as they happen. Such systems:
  • Detect exploitation techniques
  • Provide real-time visibility across your environment
  • Are agnostic to individual vulnerabilities
  • Work proactively to identify unknown or emerging exploits and attacks
IoA-based detection looks at an attacker’s behavior, regardless of whether the attacker is using a known or unknown attack. An attacker doesn’t need malware to compromise your system, so an IoA-based system is ideal for stopping perpetrators before they penetrate your defenses.

Download this content as a PDF

Linux Monitoring Requirements for IoA Detection

The rapid adoption of Linux-based microservices in enterprises has driven the shift to solutions that detect IoAs. For those in SecOps, a modern IoA detection approach must be:

  • Deployed at the local and host level (i.e., utilizing user space code that gathers telemetry from various sources)
  • Flexible enough to detect generic exploitation techniques 
  • Rolled up to generate high-value alerts at low volume 
  • Lightweight enough to not disrupt production
  • Integrated into the existing build chain

Capsule8 Protect is the only attack protection solution that: 

  • Deploys out-of-the-box sensors  
  • Detects locally and analyzes all exploit data
  • Alerts you only when specific security policies are violated
  • Enforces hard limits to system CPU, disk and memory using a resource limiter and an intelligent load-shedding strategy
  • Is fully extensible with an API-first perspective

See Linux Monitoring and Response in Action

Download our Technical Primer: Demonstration of Detection Capabilities in Capsule8 Protect to learn how we support modern Linux environments without slowing down production.

Protection Without Slowing Production

A system that keeps you safe but doesn’t let you get your work done will produce one of two results: Your company’s productivity will slow to a crawl or your employees will start using workarounds that will leave you even more vulnerable than before.

So it’s critical that the approach you take, whether it’s IoA- or IoC-based, not disrupt production. But even though one part of your company might think things are going well with the chosen protection method, another might encounter disruptions. For example, SecOps might think things are humming along nicely, but that doesn’t necessarily mean Ops will feel the same, especially when you’re dealing with agents and kernel modules.

Capsule8 Solves the Problem in a Different Way

Capsule8 enables IoC and IoA methods but we believe IoA is the superior method for today’s advanced attacks.

So we engineered Capsule8 Protect using the kprobe + perf approach to Linux monitoring. kprobes are subsystems that grant visibility into the kernel via syscalls between specific processes. When used in conjunction with perf, a stabler alternative to kernel modules, you can extract kernel data without performance compromise.

The kprobe + perf approach designed by Capsule8 Protect is a safer way to perform Linux monitoring because it:

  • Doesn’t require a kernel module to deploy
  • Can’t crash the kernel
  • Won’t flood the network
  • Won’t require extra config labor by Ops

Different Approaches to Linux Monitoring

Learn more about this better way to do Linux monitoring in our recent blog post.


Customer needs are at the core of Capsule8 Protect 

  • With Capsule8 Protect in place, security teams can detect active exploits as well as known malware and other security issues.
  • Capsule8 Protect prepares your operation with the right telemetry, so you can respond to exploits, cost- and time-efficiently, as they happen
  • Capsule8 Protect supports the way you work. It’s infrastructure and cloud agnostic, cost tunable, and enables you to meet controls that can help you comply with policies. Plus, it’s low maintenance and is suitable for both SecOps and Ops teams.

The Cloud Native Compliance Playbook: Strategies for the Enterprise

Posted by

The reality for most organizations is that they are somewhere between hybrid cloud and cloud native on their cloud transformation journeys. A major roadblock for this delay is compliance – or more specifically – the way compliance has traditionally been achieved within large enterprises.

Spectre and Meltdown | The Data Science Approach

Posted by

Data science in cybersecurity is rapidly growing. At Capsule8, we in data science work in tandem with the security research team to collaborate on state of the art detection models against the latest threats.

Now in machine learning, we all know that feature engineering is the secret sauce. The advantage for us here, given the strength of our  security research team , is that there is no dearth of interesting features for our models. One particular set of attacks for which Capsule8 released an open source detector the very next day (read our blog on this for more) became our target— Spectre and Meltdown. What if we can come up with a machine learning model that can use the features from the current deterministic detector, thereby providing better detection? Will the accuracy increase significantly ? Can it keep the false positives at an acceptable level ? Is it production worthy ?

So many questions! Well the short answer to all — Yes.

The Essential Guide to Cloud-Native Security

Posted by

Modern detection engineering requires the adoption of engineering principles to security analysis. In a cloud native system, this practice becomes existentially critical — without it, security detection will be untenable.

Docker Security 101: Key Considerations

Posted by

Docker and containers bring true platform independence, agility, and flexibility to running applications. As the industry moves toward microservices, containers, and cloud-native environments, container and Docker security will be taking on an increasingly prominent position in an organization’s security posture.

Preparing for Zero-Day Attacks

Posted by

Are you one of the 42% of organizations that reported an attack on their hybrid environment in the last year? Discover how you can detect and instantly disrupt attacks in the production environment before they take hold.

Why Container Security is Such a Challenge

Posted by

Container Security

Why Container Security is such a Challenge

The Power of Containers

Containers are having a moment. They are revolutionizing the way we do application development, but, as with most new technologies, their adoption in the enterprise is (rightfully) hindered by genuine security concerns. Ultimately, containers can bring huge security benefits not found in traditional infrastructure. But with new technologies come new risks. First of all…

What is a Container?

In one sense, containers are an OS-level virtualization method for running multiple isolated Linux workloads on a host using a single Linux kernel. Effectively, everything outside the kernel is virtualized; applications, runtimes and files in one container can’t see other containers on the same machine, but they share an underlying operating system, which makes them far more lightweight than virtual machines.

Containers have not only allowed companies to pack more onto a single machine, they’ve made it much easier to build portable software that is continuously redeployed. Container images can be easily shipped around, are portable from machine to machine, and start fast. They’ve become a key technology to enable microservices and auto-scaling applications, and are now a staple in many continuous integration/continuous delivery (CI/CD) pipelines.

Microservices break down the process of developing an application into a collection of small services; each service implements business capabilities, runs in its own process, and communicates via HTTP APIs or messaging. Microservices make it so you can have different people working on various parts at the same time, which not only speeds up the development process but also makes it easier to check for errors within individual services.

To manage all of the containers and microservices therein, you also need an orchestration platform, such as Kubernetes or Docker Swarm. These platforms have built-in security, but it’s more around making sure nothing gets out. The issue then becomes: what is going on inside?

Why Intrusion Detection Systems are Ineffective for Linux Production Environments

Organizations are evolving and modernizing their production environments with technologies like cloud, microservices and containers, and are more often mixed with both cloud and on-premises infrastructure and applications. This creates a changing attack surface that conventional security solutions such as IDS simply cannot address.

The Challenge of Container Security

Containers enable things to happen faster, so while this means faster deployments, it also means faster failures. And while containers are great for isolating valuable data, it’s also holding…valuable data. The more you put into a container, the more you have to trust everyone (and everything) that has access to it and that it can access. This creates a situation where you are always one kernel bug or misconfiguration away from everything being affected.

Recent high-profile breaches, like the Equifax breach, prove that isolation is not enough, as bad actors never had to gain more privileges than the hacked web server to get access to all of their customers’ data. That access was already allowed. You are never going to know all the vulnerabilities, or how someone could get in, but you need to know when something inside a container is doing something bad. The challenges of monitoring containers are rooted in the very reasons that they are useful in the first place; they provide more flexibility and reuse of resources.

A survey of 450 IT and information security professionals in North America and Western Europe uncovered some major concerns that are hindering container adoption.

Security concerns and obstacles related specifically to running containers:


We use a separate container security solution as our current server workload security solution does not support/offer the same functionality


There is a lack of mature cybersecurity solutions for containers


An infected container can cross-contaminate other containers


The potential for container sprawl creates loose access controls between containers that could leave our production environment(s) vulnerable

By design, containers come and go at a much faster rate than virtual machines (VMs), and while that’s great for speed, it’s not great for monitoring. When deployed, a container often receives access to resources allocated to it, e.g., an IP address on a software-defined network inside of a VM or a small portion of the filesystem. When finished, these resources are then reallocated to the next container. Traditional security identifiers, such as the IP address assigned to a given container, then become meaningless unless you can cross-reference them with the state of the container runtime and orchestrator. To compound matters even further, containers and container orchestrators are built from software-defined components which only exacerbates their dynamism. If you’re monitoring something that is always changing, how do you know when that one change is bad?

Solving the Container Security Problem

Security appliances have been a crucial tool in protecting the current environments of many enterprises today, but when it comes to containers, security appliances fail. While there are a number of reasons (9 of which we outline here), one of the most significant issues is that inter-container traffic mentioned above. When multiple containers live on the same machine and talk to each other, communication doesn’t go over the network and can never be seen by an appliance—even a virtual appliance. You still don’t have access to what is going on inside.

The solution to container security lies within tooling that is container aware. You need to monitor what is going on, all of it, and somehow not be caught up in a mountain of false positives. By looking real-time into system, network and intra-container data, you achieve the level of visibility needed to know when something bad is happening inside of a container and can respond to it appropriately, such as shutting down or isolating the affected container.

This is the problem we are solving at Capsule8. With the transparency required for real-time protection, monitoring and troubleshooting, we’ve developed the first real-time attack disruption platform purpose-built for the cloud-native world of containers, Linux, and microservices. We bring continuous security to an entire production environment, automating the detection, isolation, and shutdown of attacks in the instant they happen.

Learn more about how we are securing container runtimes.

Download this content as a PDF

Capsule8 Product Overview

Protect your enterprise infrastructure with detection and resilience for Linux systems in any environment.

Nine Reasons Why the Death of the Security Appliance Is Inevitable

Posted by

Most security organizations are used to appliances being the workhorse for their protection needs. Indeed, the major security vendors today tend to have huge appliance businesses, including the old titans (e.g., Symantec and McAfee) and the new titans (e.g., Palo Alto and FireEye). As crucial as security appliances are today, they are eventually going to die out, as the technology landscape continues to evolve. They’ll continue to get less effective, pushing detection to the machines that need protection.   The death of the security appliance is inevitable, and here are the nine reasons why.

Time to Blow Up the SOC?

Posted by

Thirty-seven percent of SOCs faced more than 10,000 alerts per day and more than half of those were false positives, which can easily cost organizations thousands of wasted hour and millions of wasted dollars every year. Realistically, many “true positives” are for events with incredibly low value, such as reconnaissance scans. Most scans don’t turn into an issue, and the ones that do often don’t correlate with any information that can be used to defend against the attack.

The model of gathering as many logs as possible and sending them off to be centrally analyzed is like trying to find needles in haystacks by gathering all the hay you can find in a ten-mile radius. You could make a case for it around completeness and the ability to apply analytics, but in reality it turns out to be a horrible approach.  And when the approach does identify an attack, it tends to be hours or even days after the attack has taken hold. So what’s the alternative?