Power your threat detections with SnapAttack and LimaCharlie

Every vendor with a detection library sells the same comfort: thousands of rules, ready to deploy, trust us that they work. The trouble shows up at two in the morning when a junior analyst catches an alert and cannot tell whether it matters. What Paul Caiazzo and Maxime Lamothe-Brassard kept circling in this session is that a rule you cannot verify is a liability dressed up as coverage, and the fix is not more rules. It is proof that each one fires, proof it will not drown you in noise, and a place to run it that does not lock your data away. SnapAttack and LimaCharlie split that problem cleanly, and the split is the interesting part.

A detection is a bet, so it had better be validated

Caiazzo, SnapAttack's Chief Growth Officer and a former CISO at a large MSSP, frames detection content in stark terms. "You're basically staking your business on the fact that it's going to work," he says, "if it doesn't you miss a threat, you have an incident." That framing changes what a detection repository is for. SnapAttack captures attacks from both sides, the attacker's actions and the victim's telemetry, including the packets, event logs, and process activity left behind, then uses that true positive data to answer two questions before anything ships: will this detection fire, and how noisy will it be. Caiazzo calls the first validation and the second confidence scoring, and together they are the difference between a library and a guess.

The reason this holds up under pressure is that SnapAttack indexes behavior, not indicators. Detections are organized around TTPs rather than IOCs, so a novel way to dump LSASS that leaves similar telemetry still trips the same registry-key logic instead of sliding past a stale hash. When something genuinely new appears, machine learning checks the existing repository for matching coverage, and if nothing fits, a detection builder pulls the malicious telemetry in and lets an analyst click through it. That last point matters more than it sounds. The builder compiles to a fork of Sigma and removes the human error that quietly wrecks detection work, the single quote that should have been a double quote, the broken rule that returns zero results and looks like good news. As Caiazzo notes, a skilled hunter questions a zero; a tired tier-one analyst does not.

The skills gap is really a verification gap

Both founders kept returning to the shortage of senior detection talent, and what is striking is that neither treats it as a hiring problem. Caiazzo's answer is to give a blue team analyst who has never run a pen test the attacker's view directly, and to hand the 2 a.m. analyst a reference set of known-bad telemetry to compare against. The decision to escalate or dismiss stops being a judgment call from experience the analyst does not have, and becomes a comparison against data SnapAttack already verified. That is up-leveling by removing the need for expertise at the moment of pressure, not by waiting for it to accumulate.

Lamothe-Brassard attacks the same gap from the opposite end, by lowering the cost of learning. LimaCharlie's founder, who came up through the intelligence sector in Canada and later worked at Google, Chronicle, and CrowdStrike, describes spinning up a free tenant on a weekend, onboarding your own machines, connecting SnapAttack, and watching hundreds of rules flow in and fire against real data. Using replay, you can take a query and turn it into a detection to see how it behaves. His bias is explicit: he learned by taking things apart and putting them back together, and he wants the on-ramp cheap enough that a junior analyst, or someone not yet an analyst at all, can practice on real telemetry. For a provider staring at the margin math of training the next tier, two complementary on-ramps beat one.

Infrastructure you can interrogate beats coverage you have to trust

The deeper alignment between the two is architectural, and they both reach for the same analogy: AWS. Neither platform tries to be the walled garden that does everything and lets nothing out. Lamothe-Brassard positions LimaCharlie as the layer beneath the SOC, the EDR and XDR capabilities, automation and response, querying, a year of retention, and the pipes that move data wherever it needs to go. He likes when users call it "the bus of their security operations." SnapAttack rides on top of that, streaming validated content into a LimaCharlie tenant as rules you can run immediately.

What the openness buys is the ability to question your own posture instead of trusting it. Incoming SnapAttack rules arrive tagged with MITRE ATT&CK technique and kill chain metadata, so when a technique starts heating up you can query the tenant and ask what coverage exists, what will happen when it fires, and where the gaps are. On the SnapAttack side, the same tagging lets you filter coverage by adversary and ask how well defended you are against a specific actor, then roll it into a threat preparedness score that weighs coverage, technique severity, and detection confidence. Caiazzo's read on that number is blunt and useful: a low score usually means a noisy SOC, and noisy SOCs are risky. For an MSSP whose clients increasingly want proof the security spend is reducing risk over time, a trended, defensible metric is the artifact that conversation needs.

The interoperability is what makes the openness real rather than rhetorical. SnapAttack streams to 35 or more sensors and EDRs and, unusually, maintains its own Sigma back end rather than leaning on community ones, whose field mappings, Caiazzo notes, often do not work as cleanly as you would hope. LimaCharlie normalizes incoming telemetry from Carbon Black, Defender, or CrowdStrike against one event schema while never discarding the original fields, so a detection you write once works across a fleet of mixed-EDR clients. Both price on usage with volume discounts as you scale, transparent on the website, no four calls with salespeople to "algorithmically extract the maximum value," as Lamothe-Brassard put it. For a multi-tenant operator, that is the whole pitch in one line: validated content you can audit, running on infrastructure you can query, across every customer you have, without rebuilding the plumbing each time.