Infrastructure as Code

Most security tooling treats configuration as a private act. You log in, you click, you tune, and the result lives inside the console as state nobody else can read. That works until you are running more than a handful of tenants, at which point the console stops being a tool and becomes a liability. The argument running underneath this LimaCharlie session is that the configuration of a security environment should be a file you own, not a state you visit, and that the gap between those two things is mostly a question of access.

LimaCharlie has long supported Infrastructure as Code, the idea that a tenant (what the platform calls an org or organization) can be represented in full as a single YAML file. That file captures everything: detection and response rules, the outputs and forwarders that route data, network policies for net endpoints, and the integrations tied to the org's lifecycle. The benefit is not novelty. It is that a file can be read, diffed, and versioned offline, which makes change auditable in a way a console never will be. As the session puts it, you stop clicking twenty million times and start managing intent.

The real change is who can reach it

For a long time, that power came with a tax. To work with IaC in LimaCharlie you needed the command line interface, which quietly narrowed the audience to the people willing to install and learn it. The substance of this session is that the tax is gone. The same capability now lives in a managed service with a simplified REST API, enabled by default on every new org, and it surfaces as an Infrastructure Config view in the console. Older orgs add it from the marketplace and the menu appears.

This sounds like a packaging detail and is actually the whole point. When configuration management required the CLI, IaC was a discipline practiced by the few engineers on a team who had set it up. Move it behind a web view and a REST endpoint and it becomes something the rest of the team can use, share, and reason about. The session leans on the most mundane example to make the case: open the view and it fetches the tenant's current config automatically, so you can copy it out as a backup, or paste it into a fresh org and clone an entire tenant. Standing up a staging environment that mirrors production goes from a project to a paste.

Additive by default, with force when you mean it

What makes the web view safe to hand to a wider audience is a deliberate choice about blast radius. The underlying service behaves exactly like the old CLI, including a force mode that applies an exact config and deletes everything not in it, which is how you make production match your repo precisely. But the web view does not default to that. Pasting a config there is additive: it layers onto the tenant rather than replacing it. You can experiment without wiping out the detection rules already in place.

That distinction matters more than it first appears for a provider. Force mode is the right tool when your repo is the source of truth and you want drift eliminated. Additive mode is the right tool when an analyst is trying something on a live customer environment and a mistake should not be catastrophic. Keeping both, but defaulting to the gentler one in the interface most people will touch, is a sensible read of how teams actually behave under pressure.

Templates turn patterns into building blocks

The other half of the accessibility argument is that you should not have to author config from scratch. LimaCharlie maintains a public templates repository (github.com/refractionPOINT/templates), a curated set of configurations you can apply directly, and it is open to contributions by pull request. Some are whole-organization starting points, including basic coverage with VirusTotal. A Microsoft Defender template installs the Windows Event Log rules and the artifact rule needed to surface Defender detections through LimaCharlie in real time. Another collects full packet captures across endpoints, retains them for 60 days, and pipes them through Zeek in the cloud with the resulting logs kept for a year.

The template that should catch an IR or MDR practice's attention pairs IaC with usage-based billing. The sleeper deployment template turns event collection off by default, so a broadly deployed sensor costs next to nothing while idle, and collects in real time only from endpoints carrying a live tag. The lifecycle becomes a tag operation: pre-deploy the EDR across a thousand machines, add live to the host when a call comes in, remove it to stop paying. That is the LimaCharlie lego blocks philosophy expressed as a single applyable file, which is exactly what a template is for. Complex automation usually requires several pieces wired together correctly, and a template lets you adopt the pattern without re-architecting it.

For automation beyond the console, the same service answers on the REST API at api.limacharlie.io, where it exposes more than the web view does. Instead of inlining a config, you can hand it an ARL, an authenticated resource locator that bundles a pointer to a set of resources with the credentials to reach them. Aim one at a private GitHub repo and the platform fetches the configuration itself. The CLI remains for those who want it, with dry runs that report what a change would do before it does it, and the mssp-demo repository stands as a working reference for managing at scale: composable config files, access control, and GitHub Actions deployment.

Strip away the demos and the session is making a quiet claim about ownership. Configuration you can only reach through a console is something you maintain. Configuration that is a file, a template, or an ARL is something you can back up, clone, review, and ship. For a provider running many customers, that is the difference between repeating work tenant by tenant and applying a decision everywhere at once.