LimaCharlie Enterprise (LCE) is a specialized backend for the Open Source LimaCharlie (LC) endpoint sensor focusing on enterprise features, stability and performance.
The LC sensor is an Open Source cross platform endpoint sensor developed in C. Its source is available https://github.com/refractionpoint/limacharlie. It provides all the basic types of events needed for Flight Data Recorder (FDR) type functionality like Processes, Network Connections, Domain Name requests etc. It also supports some more advanced features like intelligent local caching of events for in depth Incident Response (IR) as well as some forensic features like dumping memory.
Sensors can be described through AgentIDs
The LCE backend runs on a Linux based appliance running Cassandra for storage and Beach for compute. These appliances are designed to scale a deployment by supporting clustering of their storage and compute.
The Control Plane is a REST interface allowing you to manage multiple LC Backends using a single interface. The Control Plane is documented using Swagger and uses JWT for authentication. By default the Control Plane is accessible at
- Swagger-based REST API documentation:
- Basic Web UI on top of REST:
- REST API root:
The Modules are the binary payloads loaded by the LC sensor that provides the core of its capabilities. This component is easily upgradable. For change management reasons it is not automatically updated to the most recent version, but doing so is a simple REST call to the Control Plane.
Installer Keys are keys used to install a sensor. By specifying a key at install time the sensor knows where to connect as well as the cryptographic keys specific to your installation. Installer Keys can also associate specific Tags the first time a sensor is installed.
Sensors can have Tags associated with them. Tags are applied either based on an Installer Key, or dynamically via Detection & Response Rules.
Sensor can be configured using Profiles. The Profiles define which Collectors (major functionality categories) are enabled and disabled. Some Collectors can use additional data (like lists of file extensions). The Exfil Collector also controls exactly which events are sent in realtime to the backend verssus which ones are only cached locally until requested.
Profiles are applied by specifing a AgentId mask (which includes an Organization Id, Installer Id, Sensor Id, Platform and Architecture) along with a specific Tag (optional).
Detection & Response Rules
The Detection & Response Rules are an automation engine. The Detection component is a rule that either matches an event or not. If the Detection component matches, the Response component of the rule is actioned. This can be used to automatically investigate, mitigate or apply Tags.
Since LimaCharlie Enterprise doesn’t store data itself, it needs to relay the data somewhere for longer term storage and analysis. Where that data is sent depends on which Outputs are activated. You can have as many Output modules active, so you can send it to two different syslog destinations using the Syslog Output module and then send it two some cold storage over an Scp Output module.
Output is also split between two categories: “event” and “detect”. Event will be a stream containing the all raw data from
all the sensors, so it tends to be a large amount of data. Detect is a stream of detections generated through the
function of the Detection & Response rules. This means you can send your bulk “event” data to a cheap cold storage and
send all the important “detect” data to a Splunk instance or a Slack channel (using the Slack Output).