LC101: Getting started with LimaCharlie

Most security teams have gotten good at the work. Detection engineering, red and blue teams running together, larger and more complex networks: Matt Bromiley, LimaCharlie's Lead Solutions Engineer, opens his inaugural LimaCharlie 101 session by granting all of it. Then he names the thing that has not kept pace. A talented team can still be stuck doing what he calls hidden security, responding to alerts from a stack it does not own, with no real grip on where the telemetry comes from or how the detections fire. The session is billed as a getting-started walkthrough, but the argument running underneath it is that the way you stand the platform up is itself the security decision, and the platform refuses to let you defer it.

Control and visibility are a structural choice, not a slogan

Bromiley repeats two words, control and visibility, often enough that they could pass for marketing. What keeps them honest is that he never lets them float free of a decision the operator has to make. LimaCharlie is vendor-agnostic middleware: it connects sources of telemetry, automates action on what it observes, and forwards data where you want it, without favoring or excluding any EDR vendor or log source. He is deliberate about never naming a preferred vendor and never excluding one. The question he wants operators carrying out of the session is not whether one tool beats another, but how to get the highest-fidelity data into one place to make more informed decisions.

That neutrality is where the value lands for an MSSP or MDR. If the platform takes any telemetry, you can standardize one operational surface across a client base that runs a different toolset in every environment, ingesting third-party EDR alongside native sensors, and keep the analyst experience identical from tenant to tenant. The alternative, a stack you subscribe to rather than operate, is precisely the hidden security Bromiley is arguing against.

He grounds the telemetry point in a simple split. There is EDR-class data, an installed agent reporting real-time system events such as new processes, network connections, and file activity, with parity across Windows, macOS, and Linux plus Chrome OS, Edge, and Docker. And there is everything else, typically logs: cloud provider logs from AWS, Azure, and GCP, appliance logs, third-party application logs, and historical data sets pulled in for an investigation. The practical consequence for a provider is that the same platform runs a full streaming deployment for one client and a narrow, short-lived ingest for another, say a gigabyte of firewall logs spanning the past six months brought in for a six-to-eight-week incident response engagement, without becoming two different products.

The funnel forces you to decide before the sensor checks in

The spine of the session is what Bromiley draws as a funnel: organization at the top, installation keys in the middle, individual sensors at the bottom. Each level is where a different kind of decision lives, and that matters more than any single screen.

An organization is a logical boundary holding everything about one environment, and Bromiley is blunt that on the managed side you create one per customer. Each carries its own name, its own data residency region (he cites the US, EU, UK, Canada, and India), and its own plan, so client data stays geographically and logically separate. He calls out the failure mode by name. If you are supposed to be multi-tenant but you are pouring everything into one pool and sorting it later by hostname convention, that does not hold up. He stands up a fictional Stark Industries organization in the EU region in under ten seconds to show that separation is cheap, and templates and prebuilt configurations turn tenant onboarding into something closer to infrastructure as code.

Installation keys are the next grouping. A key carries a description and tags and yields a sensor key, a Chrome key, and an adapter key from one binary. The tags you set at install time, operating system, dev or prod, geography, workstation type, become how you treat systems differently later. At the bottom of the funnel sits the individual sensor, where per-host actions live, including isolating a single compromised machine from the network.

The funnel is the argument and not just a menu because of the order it imposes. Bromiley contrasts it with the common pattern of installing the agent everywhere and classifying after the fact, which leaves every sensor looking identical until someone cleans it up. His objection is operational: you do not have that much time. Classify up front, and the moment a sensor checks in, a matter of three or four seconds in his demo, it is already acting as the right kind of asset with the right rules running. He treats Linux and Windows as inherently different things that should never inherit the same posture by default, and the funnel is what lets him say so before any telemetry arrives.

Detection becomes a property of the tenant, not the endpoint

The session closes where the structure pays off. Because detection and response rules apply at the organization level, a tenant can carry a working detection posture before a single sensor exists. Bromiley shows an organization already running 702 Sigma rules through the built-in integration, then subscribes the tenant to SnapAttack's Community Edition from the add-ons marketplace in a few clicks, alongside available rule sets from SOC Prime and a managed set from Soteria. The result is an environment with hundreds of rules waiting, so the next sensor, and every sensor after it, is analyzed for malicious activity the instant its telemetry checks in.

For a provider, that inverts the usual onboarding sequence. Detection is no longer something you bolt onto each endpoint after deployment; it is a property the tenant already has, tuned per customer over time. Bromiley flags that the next session will go deep on detection and response rules, which is the right place to stop, because the first session was never really about clicking through setup. It was about the claim that owning the structure is what owning your security looks like, and that the platform will not let a provider skip the decision.