LC101: Extending the LimaCharlie platform

Most security tooling forces a choice early. You either centralize everything in one platform and accept its workflow, or you scatter data across the tools your team already knows and pay the integration tax. The third installment of LimaCharlie's LC101 series, hosted by Matt, is really an argument that this is a false choice. Once telemetry is flowing into a single organization, the interesting work is not keeping it there. It is deciding, deliberately, what leaves and what more you can do with a sensor that is already in place.

Matt states the premise plainly when he turns to add-ons. You already have an endpoint agent deployed, you already have visibility in the environment, so why stand up another agent or another piece of infrastructure to do the next thing. That single idea, reuse the reach you already paid for, runs underneath both halves of the session and is what makes it useful to anyone running security as a service across many client environments.

Centralize the data, then decide what leaves

LimaCharlie's outputs are the mechanism for moving data out of the platform, and Matt frames the decision as a choice of stream before a choice of destination. The events stream is the full firehose of sensor telemetry, and he is blunt about it: the most verbose option there is, not worth shipping unless you are using another system purely for retention, and even that is a weak case given the sensors already include a year of retention at the endpoint cost. The detections stream is far more honed, carrying only what the detection and response engine actually fired. Deployment and audit logs are the two platform-internal streams, useful for watching sensors check in and for tracking who changed what inside an organization, a control that matters once a large number of people touch the same instances. Artifacts cover files pulled on a schedule rather than streamed continuously.

The stream Matt singles out as the real lever is the tailored stream, the quietest of the set, populated only by output actions you declare inside detection and response rules. This is where the centralize-then-export argument gets concrete. Because you control exactly what lands in it, you can wrap priorities into the titles, route high-priority detections straight to a Slack channel, a ticketing system, or an email for immediate attention, and let lower-priority detections fall into a standard queue. The triage decision happens in the rules, upstream, rather than downstream in whatever tool is catching the data.

Where the data goes is almost secondary, because the destination list is long: all the major cloud providers, plus Datadog, an Elastic-specific option, Splunk, syslog, the older SMTP, SFTP and SCP protocols, and Slack. Matt is candid that some of the marketing-friendly integrations, Tines and Torque among them, are really a webhook output with a shorthand wrapped around it to make configuration easier. When nothing fits, a webhook or its bulk variant sends data almost anywhere, and an S3 bucket is the reliable last resort. The honesty is the point. The platform is not pretending every integration is a deep native one.

Shipping a slice instead of the whole stream

The most useful pattern Matt describes is also the one with the clearest economics. Rather than treating LimaCharlie as a stop on the way to a SIEM, treat it as the system of record and ship only a slice elsewhere. He points to customers exporting five or ten percent of their data to an Elastic instance and using it as a focused analyst console while LimaCharlie holds the retention. Sending data into Splunk, he notes, is a way to cut down on Splunk costs and Splunk retention while still landing the data in a workflow an analysis team already runs. For a provider pricing a service, that gap between full firehose and curated slice is margin.

The advanced options on every output are where that trimming happens before data ever leaves the platform. Transform templates reshape the payload, sample rates let you test ingestion on the receiving side, and tags scope an output to specific sensors, Windows workstations only, for instance. You can include or exclude event types, which leads to Matt's split-stream suggestion. If you are shipping a thousand detections a day and ninety percent of a stream is DNS requests, send everything except DNS to one hook and DNS-only to another so analysts are not digging through low-value noise to find what matters. Nothing is lost by trimming, because the retention stays inside LimaCharlie. He returns to that reassurance repeatedly, and it is what makes aggressive filtering safe rather than reckless.

Turning one sensor into a forensics and testing platform

The second half of the session extends the same reuse logic from data to capability. The add-on marketplace splits into enrichment and services. On the enrichment side, API integrations like VirusTotal and geolocation can both enrich an event and feed a detection, flagging a hash VirusTotal calls bad or adding country context to an IP. Lookups hold lists of atomic values a rule can check against, and Matt's example is sharp: the JumpSec list of IP addresses that have targeted RDP servers, updated hourly, paired with a simple rule that matches it against 4624 authentication events with logon type 10. Lookups can be public or private, and the private case is the multi-tenant payoff. A provider can keep its own list of known-bad indicators drawn from its own investigations and apply one flexible rule across every client organization rather than hard-coding hashes per tenant.

Services push the idea furthest, because they borrow the installed sensor to do work that would normally demand separate tooling, sometimes by pushing a single binary for a specific task while the EDR visibility stays in place. Dumper pulls memory or the MFT and can be wired into a rule, so a Cobalt Strike alert captures memory the moment it trips. YARA scanning is included free but off until enabled, and a scanner can point at a shared rule repository applied across organizations. Velociraptor is the one Matt lingers on. LimaCharlie pulls the vanilla executable, runs it, and collects the result without ever leaving a persistent server behind, so an analyst can pull parsed prefetch or shim cache from one host or, by tag, from a thousand at once during an incident, across Windows, macOS, and Linux. Atomic Red Team, built by Red Canary, closes the loop by firing tests mapped to MITRE ATT&CK so you can confirm a detection actually works or measure existing coverage against the techniques named in a fresh threat report. That last move, Matt notes, is also how you answer the executive who read an article and wants to know whether you are protected.

Strip away the menu of integrations and the session makes one coherent case. The value of a deployed sensor is not the telemetry it streams, it is the reach it gives you. Centralizing data in one place is only the starting position. The leverage comes from exporting precisely what your workflows need and nothing more, and from using the presence you already have on every endpoint to do forensics, enrichment, and control testing without standing up a single additional piece of infrastructure per client.