Debuting default detections! You no longer have to YAML your way through gaining Linux protection. Instead, Capsule8 is shipping our Detection Analytics and Smart Policy detection bundles together to provide the protection you want out-of-the-box, without the configuration hassle (unless you want to create your own policies!). Talk to your sales rep to learn more.
Default detections and alerts are now categorized by detection classes, like “Kernel Backdoors” and “Risky Developer Activity,” so you can more easily understand what was detected in an alert and what detections are available to enable on your hosts
Don’t want the alert, but still want the event record? You can now choose to audit events, rather than alert on them, letting you view what activity transpired without being immediately blasted with a notification
You can now override the default alert message format to customize detailed descriptions. Additionally, our new default detections now display more descriptive messages highlighting the behavior that triggered the alert
Want your alerts without an overflow? We now let you enable basic alert batching on a policy-by-policy basis that can be configured to bundle alerts above a certain threshold during a specific window of time.
You can now store your detection config files on disk, which allows for easier debugging
Grab your backpack, because it’s time to be Fedora the Explorer! That is, we now support Fedora Core, CoreOS, and Linux 5.0 - 5.5 kernels.
Speaking of kernels, we now automatically detect and validate if a host kernel can support running our sensor. If either the detection or validation fails, the sensor will produce a little error message letting you know
Each lost event type is now tracked separately with more detailed metrics, helping you understand what types of events are being dropped. It’ll be hard to get lost in these visibility conditions!
Also in the spirit of visibility, error messaging on missing permissions, capabilities and probes is newly improved
Embracing D.I.E. and making your containers immutable? We’re here to help you on your quest, allowing you to set constraints around containers’ actions after startup
Want to see alerts on a specific system? You can now filter alerts and set policy by Kubernetes namespace and pod, allowing you to see alerts for specific systems.
When investigations buffers get close to full, they’re now flushed to a durable data store. We also made improvements to compaction and scaling to further boost query performance.
Investigations now pulls in audit group IDs, which reflect a bundle of related events from the same host. We’ve also added new detail fields in many investigations tables – the more context, the merrier!
Data from older sensors can now live in harmony with data from newer sensors in investigations data stores, making for an easier sensor upgrade experience
Investigations now records lost data events to create a more complete history of what happened on your systems (specifically when visibility was missing)
Baselining of initial system state should now be much smoother, as we split subscriptions so that baseline-irrelevant data is only subscribed to once detection processing begins.
Various performance improvements, the details of which do not rise to the level of documentation
Notable Bug Fixes
Fixed a bug that occasionally mistakenly described container programs as having a host user or group name
Fixed a bug that incorrectly tracked mount information for some CRI-O and Docker runtimes
Resolved compatibility issues in identifying the correct program name of recent versions of runc
Fixed a compatibility issue with kernels that were compiled with ISRA optimizations enabled
Detox tea shockingly didn’t ease the memory bloating from the event limiter, so we resolved some memory leaks instead
Supervising the supervisor with the supervisor isn’t ideal. So, the supervisor process applying resource limits is no longer included in the resource limiting group.
YARA-related detection no longer throws an error upon encountering symlinks