Tl;DR - If you just want to try the connector, install instructions are here.
When we talk to customers about Spyderbat, one of the common questions we get is “can I leverage my existing detections?”. The answer of course is “yes” - Spyderbat can leverage and enhance existing detection investments that teams have made, feed those into Spyderbat via our APIs, and map them to Spyderbat’s causal graph of activity within and between Cloud workloads and containers.
This provides a few key benefits:
Providing operators and analysts with the full story for detections, including the casual activity that led to a Falco detection and the activities that followed it.
Third-party detections can contribute to (and initiate) “Spydertraces”, ongoing traces of infrastructure activity automatically created both within and across containers and Cloud workloads, that are continuously scored to help teams significantly separate signal from noise.
Drive automated workflows to SIEM/SOAR, and automated response actions via Spyderbat analytics.
The Spyderbat Falco Connector is a great example of one of these integrations. Falco is a popular open source project for Cloud Native runtime security with a rules engine and a set default rules (e.g. shell in a container, file write to sensitive directories etc..)
To demonstrate the connector in action, we set up Falco (and Falco Sidekick) to forward the Falco events to the Spyderbat API - and ran an example attack scenario - a read only Redis container exploit.
Here you can see the (default) Falco alerts on the left and the full Sydertrace for the attack on the right:
The Falco events have been fed into Spyderbat and combined with Spyderbat’s own detections, and the resulting automatically generated Spydertrace of activity. Looking at the trace, we get the full context and sequence of the attack, starting all the way from the initial connection into the Redis container, through payload execution in a complete connected sequence. This also includes tying network activity to process activity (e.g. we can see the retrieval of the Github package here as well)
Since Spyderbat is always monitoring and creating this map of activity inside and between Cloud and container workloads (by default for the previous 90 days) - we can also analyze traces of activity that go between containers and instances, and that span long periods of time. This provides the picture and story of what’s happening within your Cloud Native environment, without having to “join the dots” by looking through a wealth of atomic detections and logs.