LimaCharlie's usage-based billing enables incident responders to offer pre-deployments to their customers at almost zero cost. That is, they can deploy across an organization's entire fleet and lay dormant in ‘sleeper mode’ at a cost of just US$0.02 per endpoint per month. With agents deployed ahead of an incident, responders can offer competitive SLAs.
To get started with the sleeper deployment, first, evaluate if this is something that would be suitable for your use case. The below articles can help:
Contact us at answers@limacharlie.io for more information or book a quick call with the engineering team to discuss your use case. Here are the metrics used for pure usage-based billing.
Connected Time | Events Processed | Events Retained |
$0.02 per 30 days | $0.67 per 100,000 events | $0.17 per 100,000 events |
Below is a sample setup process when you want to deploy the LC sensor in sleeper mode.
Once you are confident you would like to move forward, the LimaCharlie team will enable usage-based billing for you after you provide a written request. Please note LimaCharlie customers don't have the ability to switch to or from the pure usage-based billing themselves. All requests have to be processed & actioned by the LimaCharlie support team; the average processing time is 3 days.
To deploy the LimaCharlie sensor in the sleeper mode, you first need to create an organization that is set up on Pure Usage billing mode, then configure event collection. You can apply this template to your organization via infrastructure as code. After this template is applied, the LimaCharlie sensor by default will only collect the following events across Linux, Windows, macOS, Chrome OS: CONNECTED and SYNC.
Manually apply the tag
liveto any endpoints that you wish to actively see data for (note that per-event pricing comes into effect here).When then the
livetag is applied, the sensor will start collecting all events as per this template.
The above describes a sample implementation; you are free to leverage the usage-based billing in any way that solves your problem best.
To eliminate any impact LC sensor deployed in a sleeper mode can have on performance, users can utilize tagging functionality.
Switching to dormant mode does not change the binary on disk, however, the code running in memory does change. Whether putting an org into dormant mode or changing sensor versions, the binary on disk remains as-is.
The changes to dormant mode go into effect without the need for a reboot. In dormant mode, activities such as read other process’ memory (e.g. YARA) will stop.