LC101: Simplifying enterprise deployment

Most security tooling treats deployment as a packaging problem. You get an installer, you push it everywhere, and you sort out what each machine is later. Matt from LimaCharlie spends most of this fourth LC101 session arguing that this order is backwards. The hard part of putting sensors on hundreds or thousands of endpoints is not the installer format. It is the decision you make before you push a single agent: how you intend to address these systems for the rest of their operational lives. Get that right and the packaging is almost an afterthought. Get it wrong and you pay for it in friction on every action you ever take against the fleet.

The expensive mistake happens before deployment, not during it

The session opens not on an installer but on installation keys, and Matt is deliberate about why he lingers there for the first ten to fifteen minutes. An installation key controls which bucket a sensor checks into when it comes online, and any tags applied at the key level travel with every sensor enrolled through it. So he stages keys ahead of time for Windows servers, Windows workstations, Linux servers, Linux workstations, Mac systems, and more, layering tags like lab, server, workstation, and VM so that a fleet can be sliced and cross-referenced from the moment a sensor first reports in.

The temptation he warns against is the catch-all key. You can push everything through a single key, he allows, and then sort systems out afterward by IP address, hostname, or the services they happen to be running. The problem is that those attributes are exactly the things that change, and every action you take against a subset then forces you to rebuild the same filter from scratch. His example is geographic: give California and Texas the same key, then try to apply crown jewel or compromise tags during an incident, and suddenly every operation has to reason about where a machine sits before it can do anything. Declaring the system's identity at install time collapses that recurring cost into a one-time decision. For a provider running many customer environments, the catch-all key is not a shortcut. It is a tax billed on every future query.

Why the structure pays its largest dividend in detection logic

The reason this is more than housekeeping becomes clear when Matt connects key-level tagging to detection and response. A domain controller, a general-purpose server, and a user workstation should not run the same rules, because what counts as normal differs on each. A server, unless it is a jump box or bastion, should not show heavy user interaction; a workstation should not be running services. When systems carry their role as a tag from enrollment, a single rule can branch on it. His illustration is a rule that fires on a running web server, IIS, Apache, or Tomcat, and then reacts based on whether the host is tagged server or workstation, because a web server on a user's laptop is suspicious in a way it is not on a server.

This is where the argument lands hardest for the session's intended audience. Because the branching logic lives at the tag level rather than being wired to specific hosts, the same detection and response rule lifts cleanly into every customer environment a provider runs. Reverse the design, one key plus host-level filtering at rule time, and that rule is welded to a single tenant. You have written more code and lost all of it the moment you onboard the next customer. The structural choice at the key level is what turns one piece of detection content into reusable coverage across an entire book of business.

Make the agent a fixed building block, then let the platform move

Once the keys are right, packaging reduces to a single principle: produce a stable building block and stop touching it. On Windows that block is an MSI. LimaCharlie ships 32-bit and 64-bit EXE and MSI installers, but the bare EXE is low-key in Matt's words. It never registers with the Windows installer manager, so it does not appear in the control panel, and the installation key has to be handed over separately on every install, which invites copy-paste errors and key tampering as the file gets passed around. The fix he walks through is wrapping the EXE into a custom MSI with a third-party tool, exemsi, bundling the installation key directly inside the package. Along the way he sets the security and user context so the sensor runs with system privileges, creates a new upgrade code so it can be cleanly uninstalled later, and notes that the same wrapping step can strip the LimaCharlie name from the package, a real advantage in an incident where you would rather an adversary not recognize the tooling on a host they already own.

The payoff is a cache of self-contained, role-named installers, a server MSI, a workstation MSI, a laptop MSI, each carrying its own key, ready to hand to any deployment tool. And because Group Policy, PowerShell, SCCM, and Intune all consume MSIs, that one artifact slots into whatever the customer already runs.

The part that resolves the session's deepest worry is what happens next. Operators reasonably fear that every new agent release means rebuilding all those installers. It does not. Matt deliberately leaves an out-of-date sensor visible to make the point: a slightly stale installer still delivers full telemetry, and the version is managed independently of the package. You can pin behavior at the fleet level with an LC:stable or LC:latest tag on the installation key, or push an upgrade from the web app or an API call, transparently and in the background, with the spinning wheel being about as much interaction as it demands. This is the piece that matters when a tool like Intune wants to own versioning. You deploy the MSI once and let the platform handle updates, rather than redeploying on every release or stacking a heavy version-control layer on top of one you already have.

The same philosophy carries to Linux and Mac, even though neither offers the clean bundling of an MSI. LimaCharlie publishes 32-bit and 64-bit Linux binaries, Debian packages, and Alpine and ARM builds, plus Docker images, all at static download paths, so the recommended pattern is a curl or wget script that pulls the binary into temp and installs it with the chosen key as a persistent init.d or systemd service you can fork to taste. (Note that apt-get and aptitude will not pull these, precisely because the key must be supplied; you push the binary directly.) Mac follows the same shape at small scale but tightens at enterprise scale around Apple's permission model, where LimaCharlie supplies an MDM configuration profile granting full disk access, the network content filter, and system extension rights, plus a sample plist for silent install, all pushed through something like Jamf Pro.

Strip away the operating-system tours and the session makes one argument. Deployment at scale is not really about installers. It is about deciding, before anything ships, how you will address your fleet for years, then reducing the agent itself to a fixed, boring building block the platform keeps current on its own. For an MSSP or MDR, that is the difference between onboarding a new client by reaching for an existing asset and writing reusable detection content once, versus rebuilding filters, rules, and installers tenant by tenant.