Developer Roll Up: November 2022

It has been a huge month here at LimaCharlie. The team continues to grow alongside our capabilities. We have just added a dedicated Sensor engineer and are planning some very exciting things that will be coming soon to an endpoint near you. In case you missed it, we recently hosted a roundtable conversation with key people behind several open-source cybersecurity projects. It was a great discussion full of valuable knowledge for anybody thinking about starting their own open-source project.

LimaCharlie is joining forces with a growing number of cybersecurity companies under the banner of Cybersecurity Cares to raise money to help fight hunger.

The initiative kicked off on November 29th and is running through to December 16th. It is not too late to get involved. You can learn more and sign your company up on the website: cybersecurity-cares.com

Join the list of companies trying to give something back.

Replay Billing Estimates

Changes in Replay that are effective right now:

• The returned data from Replay now has a new value, n_billed which is specifically for the exact number you will be billed on. The n_evals is now strictly representing the number of rule evaluations you made.

• You can now send a is_dry_run: true value to the Replay API/Service. When you enable that, your request will not be actually run, instead the service will return you (through the n_billed metric) exactly what is the worst-case scenario for your request. Worst-case means that your full rule (all its operators) run on every single event from the sensors you're targeting during the target time period. It's not perfect, but a good start and will scale nicely with some of the optimizations we have in mind to make this even more efficient, which will result in directly smaller bills on your part.

New example of a dry-run:

{

  "stats": {

    "n_proc": 563671,

    "n_shard": 0,

    "n_eval": 563671,

    "n_batch_access": 0,

    "n_billed": 1127342

  },

  "results": [],

  "did_match": false,

  "is_dry_run": true

}

The latest version of the CLI (Python SDK) supports it through --dry-run like:

$ limacharlie replay --entire-org --last-seconds 86400 --dry-run --rule-name tracer

The dry-run feature is not yet available in the webapp, but that is coming. (edited) 

Static EDR Cloud Endpoint

This is to let you know we've finally moved to a simple static cloud IP footprint for EDR.

You will see that the relevant per-geo domain where EDR connects to in the LC cloud (like XXXXXXX.lc.limacharlie.io) has now moved from multiple A records to a single one.

Don't worry, if you were already setting up firewall exceptions for the IPs previous under that domain, you don't need to change anything because the now-unique IP is one of the ones that used to be there.

The difference is that we can now officially guarantee that these IPs are the unique and static footprint of the LimaCharlie Cloud for EDR. Makes your life simpler.

Let us know if you have any questions.

New DISCONNECTED Event

You will start seeing a new event, DISCONNECTED flowing from EDR sensors.

It represents a sensor disconnecting from the cloud. Note that this does not necessarily indicate a problem as sensors frequently reconnect to the cloud. This event can be used for external online/offline signaling.

New _event_id field in WEL Events

You will now see a new _event_id field under the System component of  real-time WEL events from EDR.

This synthetic field is there to enable easier rule writing on top of the events. It will always contain the EventID of the WEL event. This field avoids you having to specify multiple EventID field location (since it varies in WEL Microsoft format).

Replay Pricing Change

As we make progress narrowing down the best pricing possible for Replay, we have reduced and changed how Replay is priced:

• The cost per "unit" remains the same at $0.01 per 25,000.

• The unit itself is now much simplified: the unit is now only the number of events processed. It no longer uses the concept of "eval" that was related to the rule complexity.

This means that if you want to run a Replay job over 100,000 events from a sensor, the cost will be $0.04.

Keep in mind that Replay also now has a "dry-run" mode that enables you to get a worst-case estimate of the cost of running a given query.

Sigma Service Change

We are getting closer to enabling most of the Sigma public rules through our Sigma Service (it currently focuses on Windows).

In an effort to make the transition painless (not spam you with unexpected alerts), we're introducing a few changes to how the Sigma Service is working:

• As it is right now, when subscribing an org to Sigma for the first time, all Sigma rules will be installed and enabled.

• When new Sigma rules are added to the open source community, they will be created in the orgs, but they will not be enabled by default. This behavior can be changed by sending the default_enable_rules action to the Sigma Service through the Service Requests section.

• You can monitor changes to the Sigma rules available in LimaCharlie using the  RSS feed provided by Github here: https://github.com/refractionPOINT/sigma-limacharlie/commits/rules.atom

• A new option is available with the Sigma Service through the Service Requests section to apply a Suppression Rule (https://doc.limacharlie.io/docs/documentation/b43d922abb409-reference-actions#suppression) to all Sigma Service Detections. It is enabled by sending the set_sensor_suppression action to the Service with a suppression_time value like 1h which represents the suppression period. These rules are applied per-sensor (not globally) and per-rule.

As usual, your feedback is very welcome and we look forward to pushing more functionality through Sigma and other managed rules from various sources. If you have any questions, join our Slack community or our weekly Office Hours held every Friday at 9:00AM PT.