September 30th, 2022
Developer Roll Up: September 2022
The team at LimaCharlie has been heads down working on making some big improvements to the platform. This month we have been doing a lot of work to make the function of imported rules more visible. At LimaCharlie, we believe cybersecurity needs to be transparent; the exact set of malicious activity and behavior you’re protected from should be known and you should be able to test and prove this.
On October 20th @ 10:00 AM PT / 1:00 PM ET, we are pulling together several cybersecurity founders to talk about their experiences, lessons they have learned, and things they wished they had known when starting out.
You can register to attend the webinar here: Register for the webinar
3rd Party D&R Rules in Infrastructure as Code
As you may know, we've been making progress in exposing additional information about external rule sets like Sigma and Soteria in order to provide extra transparency.
We'd like to share the upcoming steps that will go further in that direction:
Starting in the next few days, you will see those external rules starting to get reported through the Infrastructure as Code functionality. These rules will be in the "service" namespace which should get automatically ignored by "push" and "fetch" using Infrastructure as Code. So there should be nothing to be done, but if you monitor the content of the configuration of your Orgs, you may see the new rules pop in.
The next step will occur mainly in the web app. Once rolled out, the web app will default to displaying and managing D&R rules through a new interface called "Hive". This new way of managing rules will provide some new features and greater flexibility in managing them without losing any of the current features. The rule content will not change, just how they are pushed and pulled. The "legacy" APIs are and will remain in effect for a long time so there should be no rush to port your CI/CD pipelines.
Once step 1 is done, we will be providing you with more information on the new features Hive brings and how to leverage them.
Announcing ‘Advanced Filters’ capability
To make it easier for LimaCharlie users to drill down into their detection & response coverage and sensor deployments, we have added a new ‘Advanced Filters’ feature.
You can filter sensors based on the following criteria:
hostname (contains, omits, is, is not)
is_isolated (true, false)
is_kernel_available (true, false)
sid (contains, omits, is, is not)
You can filter detection & response rules based on the following criteria:
name (contains, omits, is, is not)
author (contains, omits, is, is not)
updatedBy (contains, omits, is, is not)
enabled (true, false)
tags (contains, is)
Note that filters are not case sensitive.
In the future, we plan to expand this functionality to other parts of the product such as detections.
Extended Platform & Template Strings
Sensor information now includes its Extended Platform allowing you to see that, for example, "this is a Defender endpoint, but it's a Windows machine". Or, "that this is a Carbon Black sensor, but it's a Windows machine". This will show up in the UI in the sensor list as well as sensor details.
Template Strings in LimaCharlie now support two new "functions" ( anon and token) to perform tokenization or anonymization of specific fields: https://doc.limacharlie.io/docs/documentation/279f9b83be51b-template-strings-and-transforms#template-strings
More visibility into security coverage & replay of Sigma/Soteria rules
Users can now click on individual rules from Sigma and Soteria rulesets; they can see the content of all Sigma rules, as well as enable/disable individual rules from both rulesets.
All rules from Sigma and Soteria can now also be replayed against historical traffic enabling even more granular retroactive threat hunting capabilities.
Users have the ability to add and remove tags from any rule (including managed rulesets) making it easy to categorize detection & response rules and manage them at scale.
Announcing the ability to define suppression as a part of D&R rules
LimaCharlie has added the ability to define suppression as a part of detection and response rules. This enables users to specify the maximum number of times a select action will trigger within a defined period. When that threshold is reached, LimaCharlie will suppress the action (that action will no longer take place).
For example, if the same event occurs on the same machine (or on different machines within the same tenant) again and again, you can suppress the duplicate alert for the user-specified time. Or, you can say “generate a LimaCharlie detection every time X happens but only send a PagerDuty alert once per hour”.
See what else is new in our release notes: https://limacharlie.io/release-notes