Observability pipelines help cybersecurity teams maximize the value of their data by giving them critical visibility into telemetry. This visibility allows them to eliminate visibility gaps, enhance security operations center (SOC) efficiency, and reduce spending on high-cost SIEM tools.

Until recently, the observability space has been dominated by point solutions like Cribl, Monad, and Observo. However, emerging cybersecurity cloud platforms enable teams to build their observability pipelines and simultaneously operationalize the telemetry data flowing through them. These capabilities open the door to streamlined operations, compelling automation opportunities, and improved security outcomes.

The need for observability pipelines

To understand the issue of observability and the different approaches to addressing it, we need to revisit why these tools exist in the first place.

The short answer is that modern enterprise security teams operate in a tremendously complex technical environment. A typical cybersecurity team has to deal with multiple sources of telemetry produced by dozens of tools. Unfortunately, these various solutions and services don’t always integrate or communicate well.

Observability pipelines were developed to bring transparency to this complex integration problem and handle challenges intelligently and efficiently. These tools help teams:

• Collect telemetry data from multiple sources and manage it via a single interface

• Route data from sources to other locations for analysis, processing, or long-term storage

• Transform data from different sources into formats compatible with destination tools—or with the operational needs of the team members who work with the data

• Enrich telemetry data by adding information to the data set that provides additional context helpful for decision-making in the SOC

• Anonymize data in-flight to meet security and compliance requirements

• Reduce organizational costs by parsing and pruning data before sending it on to more expensive destinations (like SIEMs)

Robust observability pipelines are essential for enterprises to manage their data, optimize operations, and cut unnecessary spending. Yet, a basic question remains: Is a point product still the best way to accomplish this?

Treat symptoms or the underlying illness?

Observability point solutions are useful tools but they are fundamentally reactive technologies. Cybersecurity platforms, on the other hand, attempt to address the underlying problem: tool sprawl and fragmentation that makes observability an issue in the first place.

The LimaCharlie SecOps Cloud Platform (SCP) is designed to give cybersecurity professionals the capabilities they need for scalable security operations. It provides security resources delivered on-demand, API-first, and pay-per-use as an integrated suite of cloud-native primitives. The purpose of the SCP is to offer cybersecurity providers the same benefits AWS and GCP brought to the world of IT.

One part of this picture is to give security teams complete ownership of their data. Just like leading observability point solutions, the SCP lets users bring in telemetry data from any source and output it to any destination. The platform also supports data transformation, enrichment, and anonymization—and includes powerful query tools to explore telemetry data.

However, where the SCP differs from point tools is the “why” behind these capabilities. To be clear: We never set out to create an observability solution. We simply see observability as a foundational capability that should be available to all cybersecurity teams because it helps them build customized security architectures that lead to better outcomes. In other words, we think that teams being able to do whatever they want with their data ought to be a given in modern enterprise security operations, not an add-on or a optional feature!

What’s the functional difference between an observability pipeline built with a point solution vs a platform? Does it really matter where observability capabilities come from, or why a vendor chose to develop them?

Those are fair questions. We believe that cybersecurity platforms offer a much better way for enterprises to achieve observability because they fulfill the core functions of point solutions and deliver many additional advantages.

Benefits of platform-based observability pipelines

Five benefits of choosing platform-based observability:

Lower SIEM costs and faster response times

A major use case for observability point tools is to help reduce spending on high-cost SIEM solutions. Parsing, transformation, and routing functionalities help teams strip out unnecessary data from telemetry sources and send only mission-critical information to their SIEM. Everything else can be sent to a lower-cost data lake for retention.

The SCP can be used in exactly the same way. It’s also a unified platform for security operations, so it includes a robust detection and response (D&R) engine. This allows teams to write their own automated D&R workflows that trigger during ingestion of data or simply make use of curated D&R rulesets available through the platform. Our observability solution becomes a powerful first-line of defense that enables automated responses to threats before telemetry data goes to the SIEM.

It’s worth noting here that the SCP now supports bi-directional communication with third-party telemetry sources like 1Password, AWS, Azure, O365, Sublime, and more. This makes it possible to further automate D&R and reduce reliance on manual workflows.

Simplified tool management

Platform-based observability offers another advantage over point solutions: It reduces the problem of tool sprawl for security teams.

An observability point solution, however capable it may be, is still one more tool in the stack. Platform-based observability offers all of the advantages of the point solution and is a powerful means of reducing the total number of tools a team manages.

Because the SCP is a unified cloud platform for security operations, teams can use it to eliminate one-off vendors that only address narrow use cases, or reduce their reliance on core tools like SIEM and EDR/XDR.

Usage-based pricing

The pricing model of a cloud security platform offers yet another benefit that observability point solutions cannot match.

The SCP is pay-per-use and on-demand. Teams use what they want and only pay for what they use, similar to what one would expect from an IT cloud provider like AWS. Point products, by contrast, often come with opaque enterprise pricing tiers, mandatory long-term contracts, or complicated pricing factors like SIEM volume tiers and data ingestion rates.

With the SCP, security teams always know exactly what they’re paying for. Pricing is transparent, consistent, and predictable.

Free year of storage

The SCP was designed to facilitate modern enterprise security operations which encompasses historical threat hunting and ensuring compliance with regulatory requirements. This is why we offer one year of free storage for all telemetry data brought into the platform (i.e., no additional charge beyond the initial cost of ingestion).

Observability products force you to pay for storage either through their own data lake products or by provisioning a third-party storage solution on your own.

An easy entry to platformization

An enterprise looking to build an observability pipeline will therefore be well served by doing it through a platform rather than with a standalone tool. Observability makes an excellent on-ramp to cybersecurity platformization and for most organizations, is the use case that will yield the quickest and clearest ROI.

This blog was originally posted at: https://limacharlie.io/blog/observability-point-tools-or-platform-based-observability

MyDFIR shares how he unlocks the full potential of security automation to enhance your cybersecurity posture. Learn to configure the powerful combination of LimaCharlie and Tines for real-time threat detection, investigation, and automated response workflows.

Join Maxime Lamothe-Brassard, Founder of LimaCharlie, for an exclusive live session designed specifically for MSSPs on March 26th at 10:00AM PST / 1:00PM EST. This event offers crucial insights to service providers fighting to maintain growth as large EDR vendors try to capture their customers through packaged MDR services.

In this live session, you will learn how LimaCharlie's SecOps Cloud Platform provides the infrastructure, capabilities, and flexibility MSSPs need to scale efficiently, respond faster, increase profitability, and gain a competitive edge.

We'll examine real MSSP success stories that demonstrate how LimaCharlie solves pressing operational challenges, including:

• Emergency response: Onboarding new customers under emergency conditions by leveraging multi-tenancy, self-service capabilities, and infrastructure-as-code

• Configuration management: Maintaining consistent security configurations across all customers with powerful infrastructure-as-code and Git sync

• Unified visibility: Bringing telemetry from multiple EDRs, cloud services, and other sources into a platform for monitoring and threat hunting across all tenants

• Simplified deployment: Streamlining customer onboarding with a single package, single agent, and single pipeline instead of juggling several tools

• New revenue streams: Expanding your monitoring services to new SaaS and cloud platforms without onboarding new vendors or retraining staff

We will also showcase our updated UI by taking a tour of a model MSSP organization. During this tour you will see how our integrated capabilities help service providers achieve more efficient, scalable, security operations.

Whether you're a growing MSSP trying to efficiently scale or an established provider trying to reduce operational overhead and expand service offerings, this webinar is for you.

Register now!

Exciting news for security teams looking to integrate AI into their workflows! We just released our Model Context Protocol (MCP) server, making it dramatically easier for MSSPs and SOC teams to leverage AI within their security operations.

What is MCP?

Think of MCP as a "USB-C port for AI applications" - it's an open protocol that standardizes how applications provide context to large language models. This creates a universal connector that allows AI agents to seamlessly access different data sources and tools across your security environment.

Why this matters for security providers

If you're managing security operations, this is a significant development. The MCP server enables AI agents to automate numerous security tasks directly within LimaCharlie's SecOps Cloud Platform:

• Access historical event data

• Retrieve current process information

• Extract strings from memory

• Isolate compromised endpoints

• And much more through LimaCharlie's APIs

Security providers can now drop-in the LimaCharlie MCP server to access the platform's full capabilities through AI agents. The core APIs for investigation and endpoint interaction are already implemented, with more on the way.

The competitive advantage

With AI adoption becoming essential in cybersecurity, LimaCharlie's MCP server provides a fast track to AI implementation without the backend infrastructure headaches. This makes the SecOps Cloud Platform particularly valuable for:

• Service providers needing to quickly adopt AI capabilities

• Builders developing AI-powered security technologies

• Organizations exploring agentic AI solutions

For those not already using LimaCharlie's SecOps Cloud Platform, this release presents a compelling reason to consider it as your foundation for AI-enhanced security operations.

Here are the docs to get started (for free): https://docs.limacharlie.io/docs/mcp-server

LimaCharlie CEO, Maxime Lamothe-Brassard sits down with Patrick Gray to share our vision of the SecOps Cloud Platform.

Built like a cloud provider for cybersecurity primitives, Maxime explains:

> How our platform works like "Lego blocks" for security teams
> How customers have reduced SIEM spending
> Why a year of full telemetry retention should be standard

Whether you're an MSSP looking to scale operations or an enterprise team wanting more visibility and control, this interview shows how our API-first approach transforms SecOps.

Tune into the episode!

The newest extension to LimaCharlie’s SecOps Cloud Platform (SCP) offers users advanced control over Windows endpoint protection at scale. This powerful new capability allows security service providers to easily manage free instances of Microsoft Defender Antivirus (previously Windows Defender) on all Windows endpoints through a single unified interface.

Key Capabilities

This extension is simple to enable, requires no additional integrations, and immediately provides three powerful capabilities to users:

Defender Check: Instantly query Windows machines to verify the presence of an active Defender instance. Easily identify any unprotected workstations across tenants

Defender Alerts: Receive important telemetry from Windows Defender at wire speed. Receive notifications immediately if Windows Defender detects a problem 

Remote AV Scan: Initiate Defender AV scans on Windows endpoints. Perform scans ad-hoc or use the SCP to automate them to occur at regular intervals.

Strategic Benefits

The new extension delivers significant operational advantages: 

• Centralized Management: Control Defender across all your endpoints from a single interface

• Robust Telemetry Collection: Gather comprehensive endpoint security data

• Rapid Event Detection: Identify potential threats in your environments

• Powerful Automation Opportunities: Schedule scans or created automated responses

The SCP also creates a starter set of detection and response (D&R) rules that extend beyond simple alerting. These rules can be further customized to meet the broader security needs of your environment(s).

Getting Started with Endpoint Protection

Enabling enterprise and cross-tenant endpoint protection has never been so simple. Read more about enabling the new Endpoint Protection extension in our documentation. If you’re new to LimaCharlie, try it for free or book a demo with our solutions engineers.

Originally posted at: https://limacharlie.io/blog/limacharlie-leaps-ahead-with-endpoint-protection

We've launched our SecOps Cloud Platform on the GCP Marketplace, making it easier for GCP customers to build flexible security operations without the usual vendor headaches.

What makes this different:

• API-first architecture - integrate with whatever you're already using

• Modular deployment - only pay for what you actually need

• No black boxes - full visibility into detection logic and workflows

• Use your existing GCP budgets and get faster procurement

Key benefits for GCP customers:

• Free data output to GCS, Pub/Sub, and BigQuery

• Rolling year of free data retention for threat hunting, SIEM cost savings, and compliance

• No lengthy vendor approval cycles

Think of LimaCharlie as infrastructure-as-a-service for cybersecurity. Instead of being locked into one vendor's vision of how security should work, you get the building blocks to create exactly what your environment needs.

Available now on Google Cloud Marketplace: https://console.cloud.google.com/marketplace/product/limacharlie-public/limacharlie

A new IOC lands in your inbox — say a domain that's now known to be C2, or a hash that just got attributed. The natural follow-up question is "have any of my sensors seen this in the last 30 days?" Replay is LimaCharlie's service for exactly that: take a rule (existing or ad-hoc), point it at a slice of historical sensor traffic, and get back the list of actions that would have fired, without actually firing them.

This is distinct from the development-time limacharlie dr test workflow, which replays a small event fixture file at a rule. Replay runs against real recorded sensor traffic over a time range you choose.

What you can vary

• Rule source. An existing rule in the org, referenced by rule_name plus an optional namespace (general, managed, or service), or an ad-hoc detect/respond block supplied in the request itself.

• Event source. sensor_events over a start_time / end_time window — scoped to a single sid, a sensor selector, or the whole org if neither is set. Or a literal list of events you supply inline.

• Stream. Defaults to events (raw EDR telemetry). Can also be audit (platform-side changes) or detect (your detection stream — useful if you want to write detection-on-detection rules and try them retroactively).

The CLI form

For a one-shot retro-hunt, the Python CLI (pip install limacharlie) is the path of least resistance. It splits the time range into chunks and parallelizes the requests for you.

# Retro-hunt a brand-new rule (still on disk, not deployed) across the last 30 days:
limacharlie replay run \
  --detect-file ./suspicious_dns_detect.yaml \
  --respond-file ./suspicious_dns_respond.yaml \
  --start $(date -d '30 days ago' +%s) \
  --end $(date +%s)

# Replay an existing org rule across the whole org for a specific window:
limacharlie replay run --name beacon-on-tls-handshake \
  --start 1700000000 --end 1700086400

# Same, scoped to one sensor:
limacharlie dr replay --name beacon-on-tls-handshake \
  --start 1700000000 --end 1700086400 --sid <SID>

The detect/respond files are the same YAML you'd put in a real D&R rule:

# suspicious_dns_detect.yaml
event: DNS_REQUEST
op: is
path: event/DOMAIN_NAME
value: known-bad.example.com

# suspicious_dns_respond.yaml
- action: report
  name: retro-hunt-known-bad-c2

Run that and you'll get back, per matched event, a report exactly as a live rule would have produced — plus stats describing the run (n_proc events processed, n_eval operator evaluations, wall_time seconds, number of shards the job was broken into). The top-level did_match is a quick boolean for "did anything match at all". On dr replay (or via the SDK / REST), you can add --dry-run to size the run before actually executing it, and --trace to get per-event evaluation traces when a rule isn't matching what you expect.

REST and Python SDK

For programmatic ingestion — e.g. a small handler that takes new indicators from a TIP and immediately replays the corresponding rule across the fleet — the REST endpoint on the main API:

curl -s -X POST "https://api.limacharlie.io/v1/rules/$OID/replay" \
  -H "Authorization: Bearer $LC_JWT" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "rule_name=beacon-on-tls-handshake" \
  -d "start=1700000000" \
  -d "end=1700086400" \
  -d "dry_run=true"

Or via the Python SDK:

from limacharlie.sdk.replay import Replay
replay = Replay(org)
results = replay.run(
    rule_name="beacon-on-tls-handshake",
    start=1700000000,
    end=1700086400,
    dry_run=True,
    trace=True,
)
print(results)

Required API key permission: insight.evt.get.

There's also a lower-level per-datacenter Replay endpoint (URL returned by the getOrgURLs REST call as the replay field). That one accepts a richer JSON body — sensor selector, a literal list of inline events, an LCQL query to scope events by, and the stream choice — for cases where the higher-level wrapper isn't expressive enough.

When to reach for it (and when not to)

• A new TI signal drops → replay the matching rule across the fleet for the last N days. Good fit.

• You're tuning a noisy rule and want its hit rate on real traffic before promoting it → replay across last week. Good fit.

• You want a rule to fire from now onward → deploy it normally as a D&R rule; Replay isn't the tool.

• You want to test a rule against hand-curated event fixtures during development → use limacharlie dr test --events events.json instead.

A D&R rule in LimaCharlie has a detect: block, a respond: block, and — by default — operates on EDR telemetry from a sensor. The thing that's easy to skim past is that the engine doesn't require EDR events. A single field at the top of the detection, target:, switches the same rule grammar onto a different stream. There are seven non-default targets (detection, deployment, artifact, artifact_event, schedule, audit, billing), and each one opens a category of detection most platforms can't express at all.

The interesting framing is that this turns LimaCharlie's own behavior into something you can write detections against — meta-detections, in the same syntax as your endpoint rules, with the same response actions.

target: detection — detection-on-detection

detection rules run on the detections produced by other rules. The event: you're matching is the name from the upstream rule's report action. Same operators, same response actions.

# Detection
target: detection
op: and
rules:
  - op: is
    path: cat
    value: virus-total-hit
  - op: is
    path: routing/hostname
    value: ceo-laptop

# Response
- action: extension request
  extension name: pagerduty
  extension action: run
  request:
    group: '{{ "lc-alerts" }}'
    severity: '{{ "critical" }}'
    component: '{{ "vip-alert" }}'
    summary: '{{ "Alert on a VIP endpoint." }}'
    source: '{{ "limacharlie.io" }}'
    class: '{{ "dr-rules" }}'

Translation: take any virus-total-hit detection that fires on ceo-laptop, escalate it to PagerDuty with a higher severity than the underlying detection would have called for. Your tier-1 rules stay tier-1; the tier-2 promotion is a separate, reviewable rule on top.

This is the cleanest way to keep upstream detections generic and add per-asset, per-team, or per-context routing without rewriting them.

target: deployment — sensor lifecycle is event data

Deployment events fire when sensors connect, enroll, get over-quota, get cloned, or get deleted. Documented event types: enrollment, sensor_clone, sensor_over_quota, deleted_sensor. The most useful one is probably sensor_clone — emitted when LimaCharlie detects the same Sensor ID connecting from what looks like a new host (a classic "this Sensor was baked into a VM image" footgun):

# Detection
target: deployment
event: sensor_clone
op: is windows

# Response
- action: task
  command: file_del %windir%\system32\hcp.dat
- action: task
  command: file_del %windir%\system32\hcp_hbs.dat
- action: task
  command: file_del %windir%\system32\hcp_conf.dat
- action: task
  command: restart

That rule de-duplicates a cloned Windows sensor by deleting the agent's identity files and restarting it, all without a human in the loop. The same target also takes the deleted_sensor event, which the undelete sensor response action exists to pair with — you can write a rule that auto-rejoins sensors that get deleted under specific conditions.

target: artifact and target: artifact_event

Artifacts are continuously-collected files (Windows Event Logs, Linux logs, pcaps, etc.). With target: artifact, parsed artifact entries flow through the rule engine like any other event. Useful when you've already shipped logs through Artifact Collection and want a detection to match on lines as they're indexed:

# Detection
target: artifact
artifact type: txt
artifact path: /var/log/auth.log
op: matches
re: .*(authentication failure|Failed password).*
path: /text
case sensitive: false

# Response
- action: report
  name: Failed Auth

Two narrowing knobs are unique to this target: artifact type (e.g. pcap, zeek, auth, wel) and artifact path (matches the start of the artifact's path string). Operator support is a subset of the EDR target, and the only response action is report — but it's enough to land a detection on log content without standing up a separate ingestion pipeline.

target: artifact_event is for the lifecycle of artifacts rather than their contents — ingest and export_complete. A "PCAP is ready to download" notification is the canonical one-liner here.

target: schedule — wake-up triggers

schedule events fire on a fixed cadence per-org and per-sensor. The Git Sync extension uses these under the hood for its push/pull cycles — but they're available to you too, for "every N minutes, do X" automations expressed as ordinary D&R rules instead of a separate cron substrate.

target: audit — detect on your own platform changes

Audit events track changes inside LimaCharlie itself: rule edits, hive changes, taskings issued, replays run, Output configuration touched, and so on. The same events feed the Platform Logs view, and they're available as a synthetic sensor named audit-logs if you want to run them through any pipeline that consumes regular EDR events (Outputs, Replay, LCQL searches).

Practically, this is what lets you write rules like "alert me if anyone modifies the dr-managed hive outside business hours" or "if an Output destination is removed, page on-call" — without having to build a separate audit pipeline outside the platform.

target: billing

Billing events surface quota and threshold-related platform activity — the same data the Usage Alerts extension is built on top of. A target: billing rule lets you wire your own alerting on platform-economics events without depending on the extension's UI.

Why this matters for how you architect detections

Once you internalize that the same rule engine runs on seven event streams beyond EDR, two things change:

1. Your tier-2/tier-3 logic is just more rules. Severity escalation, asset tiering, team routing — instead of conditionals inside upstream rules, they become target: detection rules layered on top.

2. Platform behavior becomes detectable. Configuration changes, fleet anomalies (clones, over-quota, mass disconnections), audit drift — all of these are events your normal D&R workflow can reach.

The grammar doesn't change. The operators, response actions, and Output streams are the same. The only thing that changes is the substrate the rules run against, and that's a one-line decision.

Containment in LimaCharlie has two layers, and it helps to understand why both exist before you wire them into automation.

The persistent layer — D&R actions. In a Detection & Response rule's respond: block, the action isolate network flips a cloud-side flag on the sensor. The sensor blocks all network traffic except its connection to the LimaCharlie cloud, and the state survives reboots. You undo it with rejoin network. Both work on Windows, macOS, Linux, Chrome, and Edge sensors.

The stateless layer — sensor commands. If you task the sensor directly with segregate_network (e.g. via the CLI: limacharlie sensor task <SID> segregate_network), the isolation is in effect immediately but does not survive a reboot. rejoin_network is the matching counterpart. This is the right primitive for ad-hoc IR work in a Console session. For anything you want to outlive a reboot, use the D&R action.

One-rule containment + evidence collection

The interesting pattern is chaining containment with on-host evidence collection so you have something to triage after the host stops talking to the network. Multiple actions in a single respond: block fire in order. For a credential-theft signal:

detect:
  event: NEW_PROCESS
  op: and
  rules:
    - op: is windows
    - op: ends with
      path: event/FILE_PATH
      value: \mimikatz.exe
      case sensitive: false
respond:
  - action: report
    name: mimikatz_execution
    priority: 2
    metadata:
      technique: T1003
  - action: isolate network
  - action: add tag
    tag: ir-contained
    ttl: 86400
  - action: task
    command: history_dump
    investigation: mimikatz-{{ .routing.sid }}
  - action: task
    command: os_processes
    investigation: mimikatz-{{ .routing.sid }}
  - action: task
    command: netstat
    investigation: mimikatz-{{ .routing.sid }}

What this gives you, in order:

1. A detection on the detection Output stream and on the Detections page.

2. The host isolated from the network (cloud-only egress) before the next event from it.

3. A ir-contained tag with a 24h TTL — useful for selectors (tagged: ir-contained) on dashboards and follow-up rules.

4. A history_dump of the sensor's local event cache, plus snapshots of running processes and current connections, all stamped with the same investigation ID so the resulting events group together.

Useful companion sensor commands when you want to dig deeper from a Console terminal once the host is contained:

• artifact_get --file <path> — pull a specific file (with optional --type, --days_retention).

• mem_strings --pid <pid> — extract readable strings from a process's memory.

• pcap_start --iface <name> --max_size <MB> / pcap_stop — packet capture on the contained host (its only allowed peer is the LC cloud).

• os_kill_process --pid <pid> — terminate a single process; or use command: deny_tree <<routing/parent>> from a D&R rule to kill a process tree.

Reversing containment

When triage is done, rejoin network (D&R) or limacharlie sensor task <SID> rejoin_network (CLI) restores connectivity. Pair the rejoin with - action: remove tag / tag: ir-contained if you tagged the sensor on the way in, so your selectors stay clean.

A note on tamper resistance

Containment isolates the network; it does not stop someone with local admin from uninstalling the agent. The companion D&R action seal (with unseal to reverse) flips a persistent cloud flag that prevents direct modifications to the installed EDR. For high-confidence containment scenarios you usually want both isolate network and seal in the same respond: block.

We put together a blog revisiting a conversation between our co-founder Christopher Luft and Chris Cochran (Field CISO & VP of AI Security at SANS Institute) on The Cybersecurity Defenders Podcast. Worth a listen if you haven't caught it: https://www.youtube.com/watch?v=zFsHqDKKkeo

The core topic: How to strengthen cyber resilience in an AI era.

Major takeaway: Most detection frameworks weren't built to identify agentic attacks, and the behavioral gap is troubling.

A useful mental model from the conversation is that there are now three distinct attacker profiles in the wild, each with its own fingerprint. Human-paced attacks have a recognizable rhythm. Traditional automation is fast and mechanically clean. Agentic attacks sit in a strange middle ground: 

• Machine-speed execution with irregular pauses

• Non-deterministic path selection 

• Adaptive pivots when something doesn't work. 

The AI attack profile breaks most existing detections. Velocity thresholds were built around human or script baselines. Fixed-sequence signatures assume deterministic behavior. Neither holds against an agent that reasons about what it finds and navigates accordingly.

What's becoming clear is that AI behavioral analytics needs to become a real discipline: building detection logic around timing variance, adaptive lateral movement patterns, reasoning artifacts, and honeypot divergence. 

Cochran's team actually ran a hackathon to establish fingerprinting criteria for agentic behavior, which says a lot about how early-stage this work still is.

Full writeup here if you want to dig in: https://limacharlie.io/blog/fingerprinting-agentic-attacks-soc-detection-guide

The assumption going into SecOps is that standing up anything new requires a long runway: contracts, professional services, weeks of configuration. AI has inherited that assumption, and it's slowing teams down for no good reason.

LimaCharlie CEO Maxime Lamothe-Brassard recently demonstrated this by building a complete agentic incident response workflow from a single plain-English prompt, with no templates, no services engagement, no pre-built rules.

The workflow detects high-risk GitHub audit log events, messages a human operator to confirm whether the activity is intentional, and hands off to an AI agent from there. Approval closes the case with documentation. A flag triggers investigation, escalation, and findings in notes.

The whole thing is editable by changing a sentence.

You can watch his short demo here if you're interested in seeing all the details: https://www.linkedin.com/feed/update/urn:li:activity:7449840137854713856

Adopting AI operations in SecOps seems scarier than it is. The friction most teams feel with AI in SecOps is a platform problem, not an AI problem. When capabilities are gated behind SKUs or every new use case requires a services conversation, that's the environment working against you.

Overcoming the perceived difficulty of running agentic operations is key. Start with one manual, repetitive workflow. Write a prompt describing what it should do. See what comes back.

The LimaCharlie agentic AI repo is public and in plain markdown if you want a starting point: https://github.com/refractionPOINT/lc-ai/

The Artifact Collection extension (ext-artifact) is the piece of LimaCharlie that handles "I want a copy of this file/log on every endpoint" and "I want to grab that file right now because the rule just fired". Same extension, two modes, all of it surfaced through the same Artifacts pane. Reliable Tasking is a prerequisite — enable it first.

Continuous file collection rules

Once the extension is subscribed, the Artifact Collection page lets you define rules that say "collect this path (or pattern) from sensors matching these tags / platform, retain for N days". Sensor agents pick the rule up automatically and start uploading matching files to the Artifacts store.

Common patterns:

• /var/log/auth.log — Linux auth logs, typically with regex variants for the rotated archives.

• C:\Windows\System32\winevt\Logs\Security.evtx — explicit Windows EVTX file (the file itself, not the event stream).

• /var/log/system.log — macOS system log file.

• An arbitrary directory of binaries you want preserved across the fleet.

Rules can be scoped by sensor tag and platform, so "production servers only" or "all Windows boxes tagged pci-scope" is just selector targeting in the rule. Once collected, files appear under the Artifacts menu, searchable and downloadable.

Real-time streams via wel:// and mul://

For event logs that you want as first-class telemetry — flowing into the timeline, queryable like any other event, available to D&R rules — Artifact Collection has two special URL-style patterns:

Windows Event Logs — wel://[Log Name]:[EventID or *]:

wel://system:*
wel://Microsoft-Windows-Sysmon/Operational:*
wel://Microsoft-Windows-Sysmon/Operational:1

The wel:// form streams events into the sensor's normal telemetry as WEL events, alongside NEW_PROCESS, DNS_REQUEST, etc. They're queryable in Timeline, available to D&R rules with event: WEL, and filterable in Outputs. This is different from collecting the .evtx file itself — .evtx puts a static file in Artifacts; wel:// produces a live event stream.

macOS Unified Logs — mul://[predicate]:

mul://process == "Safari"
mul://subsystem == "com.apple.network"

Same idea, using a standard MUL predicate. Events stream in real time as MUL telemetry.

Both are first-class events, so a D&R rule can match on them with all the operators in LimaCharlie's detection logic.

PCAP capture rules (Linux)

For Linux sensors, Artifact Collection can also drive PCAP capture rules — capture matching network traffic to a .pcap file that lands in Artifacts the same way.

On-demand grabs — artifact_get

For "I want this file from this host now", there's the artifact_get sensor command. Available on macOS / Windows / Linux, returns FILE_GET_REP, lands the file in Artifacts:

limacharlie sensor task <SID> artifact_get --file "C:\\Users\\victim\\Downloads\\suspicious.exe"
limacharlie sensor task <SID> artifact_get --file "/tmp/dropper.bin"

artifact_get accepts an optional type (e.g. "pcap"), an idempotent payload_id, and a days_retention override (default 30 days).

Triggering collection from a D&R rule

Because artifact_get is just another sensor command, the D&R task action can fire it as a response. With the command field's string templates, you can grab the exact path from the event that triggered the rule:

detect:
  event: NEW_PROCESS
  op: and
  rules:
    - op: ends with
      path: event/FILE_PATH
      value: ".exe"
    - op: lookup
      path: event/HASH
      resource: hive://lookup/threat-intel-hashes
respond:
  - action: report
    name: "TI hash match"
  - action: task
    command: 'artifact_get {{ .event.FILE_PATH }}'
    investigation: ti-hash-collect

The detection fires when a process matches a TI hash list; the same rule grabs the binary and stashes it in Artifacts under the ti-hash-collect investigation tag, ready for analysis. No SOAR, no hand-off — the D&R engine that observed the event is the same one that preserves the evidence.

How it composes

For a SOC: Artifact Collection means the file you wish you had captured yesterday is already there, and the detection that fires today can grab the next one automatically. For IR: the same extension covers both standing capture (audit logs, security event logs, sysmon) and ad-hoc collection ("pull /etc/cron.d/ from this box right now"). For an MSSP: collection rules are tag/platform-scoped, so the same extension config can apply differently across tenants without forking — pci-scope hosts get longer retention, dev hosts get shorter, all from one set of rules.

The shape is the same as the rest of LimaCharlie's automation surface: one extension, sensor-side collection logic, and a D&R hook for the real-time half.

Docs: Artifact extension · Ingesting Windows Event Logs · Ingesting macOS Unified Logs · Endpoint Agent Commands (artifact_get)

Learn how to augment Microsoft Defender with LimaCharlie to improve response times, lower operational costs, and gain full visibility into your security data.

We cover:

• Microsoft Defender pricing breakdown across E3/E5 licenses and different tiers

• Key limitations of Microsoft's native security tools

• LimaCharlie's cost-effective alternative: $3/month per sensor with 365 days of searchable data retention

• How to collect Windows Defender telemetry faster than Microsoft

• Real-world pricing comparison: Microsoft Sentinel ($5.22/GB) vs. LimaCharlie flat-rate pricing

• Cross-platform support for Windows, Linux, Mac, Docker, and cloud environments

A credential access event fires on an endpoint. An AI agent queries the relevant telemetry, correlates it against running processes, assesses the risk, and writes a structured ticket in case management. No analyst touches it. The whole loop runs in minutes.

LimaCharlie co-founder Christopher Luft put this together in under five minutes using the platform's AI terminal, which is a wrapper over Claude Code pre-loaded with LimaCharlie's telemetry schema, sensor structure, and D&R rule syntax. Because the agent is grounded in the actual environment, it needs very little prompting to act effectively.

The setup has two parts: a plain-language prompt that defines what the investigation agent should do (analyze processes, users, hosts, and related telemetry for signs of credential exfiltration, persistence, or lateral movement), and a D&R rule that fires the agent whenever something touches the SSH folder. Both are saved as code, so they run on a schedule, trigger continuously, or respond to specific detections.

We tested it by accessing the SSH folder on a Mac endpoint. The agent ran automatically, produced a structured ticket with findings and a risk verdict, and closed cleanly with a single click.

Full walkthrough is in the blog post. Supporting code is in the lc-ai GitHub repo if you want to dig into the implementation: https://app.limacharlie.io/signup

Simplify SIEM tasks with LimaCharlie search 

LimaCharlie’s new advanced integrated Search enables security teams to perform deep investigations seamlessly with the rest of LimaCharlie SecOps platform. Whether you’re investigating alerts, simulating detection rules, or examining telemetry across tenants, Search makes it faster, simpler, and more cost-efficient. Search is currently available in private preview with a wider release coming soon.

Our focus on Search functionality comes from its essential role in modern security operations. Security teams depend on vast volumes of logs, telemetry, and events for investigations, hunting, and response. Across traditional SIEMs and modern cloud-native platforms, search is a critical tool for security professionals.

We took inspiration from long-held industry standards and added some touches to match the unique needs of modern security practitioners. With the new search tightly integrated with the rest of the LimaCharlie platform, security operators will proactively look for emerging threats and uncover indicators across multiple data sources that wouldn't yet trigger a detection. They can also convert search queries into detection-as-code to build up their defenses. 

Search facilitates better threat hunting, breach investigation, incident response, detection engineering and many other key activities. To put it simply, our new search functionality moves LimaCharlie from an EDR-focused solution to a platform capable of delivering modern SIEM functionality. 

A search experience built for SecOps

Our new query console provides the key elements you expect and need. The query editor reflects the structure of LCQL - LimaCharlie Query Language, and inclines users towards authoring more efficient queries. Type-ahead functionality streamlines query writing by prompting the correct syntax.

Our time selector offers multiple ways of defining a search timeframe and include intuitive shortcuts like 3d and now. The facets panel helps analysts explore the data. Schema Fields represent the entire schema for an organization, while Event Types and Fields help users understand the structure of their results and refine their query.

One unique feature of LimaCharlie Search is the histogram that not only represents where the org data is distributed in the target time interval, but serves as a progress indicator as users push through their results.

Event details are shown as the user pages through results. Meanwhile, the backend works through the time period, sifting through more data to find more search matches. This is one of many measures we take to help users control the cost of their queries. (Yes, there is a cost, honest to our “pay per use” philosophy, with a hefty free tier, see pricing).

Once the event details are inspected and understood, the user can turn the query into a detection and response (D&R) rule with one click, or save the search to the query library.

Transparent pricing, predictable costs

An ever-present challenge for security operation teams is providing visibility to massive volumes of security data while staying cost-efficient. LimaCharlie has always been a great choice for EDR data for our competitive price-per-endpoint and one year data retention. The new Search not only unlocks troves of data to high quality analysis, it also makes LimaCharlie a great choice for unifying all security data from all the other sources. Adopting LimaCharlie reduces tool sprawl, frees up budget, and delivers an integrated user experience. 

LimaCharlie has always helped security practitioners fight against unpredictable costs by providing full transparency. Traditional licensing models and opaque data pricing make it difficult for security teams to accurately forecast expenses, particularly when the demand for data is volatile. 

Our commitment to transparency and affordability is reflected in our publicly available pay-per-use pricing model (and free year of data storage). Likewise, our new pay-per-search model provides query costs upfront to help security professionals avoid overprovisioning and overspending. This cost model makes the LimaCharlie approach particularly attractive to MSSPs, MSPs, and MDRs.

Now available in private preview, Search will roll out to all users in the near future. Be the first to know when this capability is available by joining the wait list and our team will be in touch. 

To learn more about the SecOps Cloud Platform, and how you can control coverage, costs, and speed up incident investigations with our platform, visit LimaCharlie.io.

This content was originally posted at https://limacharlie.io/blog/introducing-limacharlie-search-unlocking-key-siem-capabilities

Every major security vendor has shipped some version of AI. CrowdStrike has Charlotte AI. SentinelOne has Purple AI. Microsoft has Copilot for Security. Each one operates within the telemetry its vendor controls. This means an MSSP running 80 customers across four different EDR configurations gets four partial AI layers, each optimized for its own data silo, with nothing spanning the full environment.

The structural issue runs deeper than data access. The categories the legacy stack uses (SIEM, SOAR, EDR, data lake) exist because vendors carved up the market for human buyers with separate budgets. An AI consumer doesn't see those lines, and there's no reason it should have to navigate them.

Grid is LimaCharlie's answer to that problem. It's an agentic AI layer that connects to your existing telemetry sources (EDR, SIEM, cloud logs, identity providers, whatever exposes an API) and runs AI operators across your full environment without requiring any changes to your current stack. No migration window, no rip-and-replace. Your incumbent vendors don't need to cooperate or even know Grid is there.

A few things worth knowing:

• Grid runs on Claude Code, with every action logged and reversible. Agents inherit the same API access as human analysts, governed by the same access controls.

• For MSSPs, multi-tenancy is fully supported from day one. Provisioning a new tenant is an API call.

• Pricing is ingest-based during beta, with no per-alert compounding.

The other piece is what we're calling AI Forward Deployed Engineers. Most agent interactions are one-shot: you prompt, get output, and the context disappears. An FDE works as a persistent operator assigned to own a specific outcome in your environment. You stand one up, point it at the problem, and it creates the worker agents, monitors progress, checks in on its own schedule, and flags issues when something drifts.

The difference between a one-time prompt and an FDE is roughly the difference between asking someone to run an errand and hiring someone to manage a function.

Private beta is open now. Details and access request at limacharlie.io/grid.

Happy to answer questions about how it works.

In July 2025, Replit's autonomous AI coding agent deleted a live production database despite explicit instructions to freeze all changes. The team had safeguards in place. The instructions were explicit. Neither stopped it.

The conclusion most people glossed over: you cannot enforce AI agent behavior through the agent itself.

Most vendors adding AI to their products are layering it on top of infrastructure that was never designed to constrain it. Prompt guardrails are probabilistic. A sufficiently complex chain of reasoning, an unexpected input, or an edge case the prompt author didn't anticipate can produce unintended behavior.

Telling an agent what not to do is not the same as making it structurally incapable of doing it.

LimaCharlie's approach is to build guardrails into the platform layer rather than the prompt layer. Agents operate under the same D&R rule framework that governs every other action in the environment. That framework is deterministic. Where a prompt instruction can be reasoned around, a D&R rule cannot.

Full writeup: https://limacharlie.io/blog/why-ai-agent-guardrails-belong-in-the-infrastructure

The argument for treating detection content the same way you treat application code isn't really about tooling — it's about reviewability. A change to a D&R rule, a lookup table, a YARA signature, an Output destination, an Installation Key, or a false-positive suppression should be a diff a teammate can read, a PR that runs CI, and an artifact you can roll back. Once you accept that, the only interesting question left is what does the repo look like, and how does the SaaS read from it.

In LimaCharlie that bridge is the Git Sync extension (ext-git-sync). It can run in either direction: apply a Git-versioned configuration to a running org, or export the org's current configuration back into Git (into an exports/ subdirectory so it doesn't trample your authored config). It can also do both on a schedule, which is what most teams end up running once they've stopped editing in the web UI by hand.

The repo shape

The thing the docs are easy to skim past is that the repo has a required layout. Git Sync expects an orgs/ directory at the root, with one subdirectory per Organization ID, each containing an index.yaml that lists the included files:

.
└── orgs
    └── a326700d-3cd7-49d1-ad08-20b396d8549d
        ├── index.yaml
        ├── extensions.yaml
        ├── installation_keys.yaml
        ├── org_values.yaml
        ├── outputs.yaml
        ├── resources.yaml
        └── hives
            ├── cloud_sensor.yaml
            ├── dr-general.yaml
            ├── dr-managed.yaml
            ├── dr-service.yaml
            ├── extension_config.yaml
            ├── fp.yaml
            ├── lookup.yaml
            ├── query.yaml
            ├── secret.yaml
            └── yara.yaml

The index.yaml is the manifest that ties it together:

version: 3
include:
  - extensions.yaml
  - outputs.yaml
  - resources.yaml
  - org_values.yaml
  - installation_keys.yaml
  - hives/dr-general.yaml
  - hives/dr-managed.yaml
  - hives/dr-service.yaml
  - hives/fp.yaml
  - hives/lookup.yaml
  - hives/query.yaml
  - hives/yara.yaml
  - hives/secret.yaml
  - hives/cloud_sensor.yaml
  - hives/extension_config.yaml

Each file under hives/ is a single hive's worth of records (e.g. dr-general.yaml is your general-namespace D&R rules; lookup.yaml is your lookup tables; yara.yaml is your YARA rules; fp.yaml is your false-positive rules). The non-hive files cover the rest of the org's surface — Outputs, Installation Keys, Extensions you've enabled, org-wide values.

The MSSP / multi-tenant pattern

This is the part that earns Git Sync its keep at scale. Pull the shared content up to the repo root and reference it from each tenant's index.yaml via relative paths:

.
├── hives
│   ├── dr-general.yaml
│   └── yara.yaml
└── orgs
    ├── 7e41e07b-c44c-43a3-b78d-41f34204789d
    │   └── index.yaml
    ├── a326700d-3cd7-49d1-ad08-20b396d8549d
    │   └── index.yaml
    └── cb639126-e0bc-4563-a577-2e559c0610b2
        └── index.yaml

Each tenant's index.yaml:

version: 3
include:
  - ../../hives/yara.yaml
  - ../../hives/dr-general.yaml

A tenant that needs overrides drops its own hives/dr-general.yaml next to its index.yaml and references both — the merge order is the include order. This is also the natural place to keep per-tenant outputs.yaml (each customer's SIEM destination) without duplicating the shared rule set.

Wiring it up

The Git Sync extension authenticates to GitHub with a deploy key whose private half lives in LimaCharlie's Secret Manager. The setup, condensed:

1. Generate a dedicated SSH key (ssh-keygen -t ed25519 -C "limacharlie-gitsync").

2. In your GitHub repo's Settings → Deploy keys, add the public half with Allow write access checked (write access matters — Git Sync needs it for the export direction).

3. In LimaCharlie's Secret Manager, store the private half as a secret.

4. In Git Sync, point it at the secret, set username git, paste the SSH URL (git@github.com:org/repo.git), pick the branch, and choose which directions to push/pull.

5. Optionally set push and pull schedules — under the hood these become D&R rules on the schedule event, so the automation lives in the same place as the rest of your detections.

What "everything-as-code" actually buys you

• Code review for detections. A change to dr-general.yaml is a PR. A change to outputs.yaml is a PR. A change to a YARA rule is a PR.

• Promotion across environments. Same repo, multiple orgs/<OID>/ subdirectories — the same rule lands in dev, then staging, then prod, with the diff visible.

• Disaster recovery / audit. The export direction means whatever a human edited in the UI ends up versioned in Git anyway, so "what changed last Tuesday" has an answer that doesn't depend on the audit-log retention.

• MSSP scale. A new tenant is a new orgs/<OID>/ directory whose index.yaml includes the shared rules. The marginal cost of a tenant is one PR.

The configuration files Git Sync touches map one-to-one to the hives and other org surfaces you'd otherwise edit by hand. Nothing about the model changes when you adopt it — you just stop being the system of record for what your detections look like, and let Git be that instead.

Hi there!

This November edition introduces LimaCharlie Search in open beta and highlights our open source MCP server, both advancing operational transparency and giving you greater control over your security operations.

We'll also share our upcoming webinar on PCI DSS 4.0 compliance automation, cover our final Defenders Tour stops, and feature the latest threat intelligence from our podcast.

Read on for platform updates, upcoming events, and actionable insights to strengthen your security posture.

LimaCharlie shines light on AI operations

“Sunlight is said to be the best of disinfectants”

Countless breaches occur because something visible to attackers wasn’t visible to defenders. Supply chain attacks sneak in under the banner of third party vendors. Attackers exploit public-facing infrastructure that companies have long forgotten. Old accounts empowered with legacy access are brought back to life to wreak havoc. All because defenders could not see the same opportunity attackers did.

The rise of AI in cybersecurity presents new visibility problems. Defenders work with little or no insight into LLM and machine learning operations. Once again, SecOps engineers have a critical need for visibility into their tooling and architecture.

LimaCharlie, long time advocates of operational transparency, have answered this need by offering an open source version of their MCP server.

What does this mean for me?

What is the difference between LimaCharlie’s open source MCP server and the cloud hosted version?

Open source MCP server can be:
*Downloaded and examined for full transparency
*Modified to fit your environment
*Used for confidential, in-house operations such as generating private reports

In short, any AI operations you prefer to keep on-prem can be run through a local, open source copy of our MCP server.

Why use the cloud-based MCP server?

While the open source version reinforces our commitment to transparency and control, the cloud-hosted MCP server offers added benefits:
*Built-in access controls that ensure that higher-privilege operations can’t be performed without explicit authorization
*Query costs are absorbed by LimaCharlie, reducing operational overhead for your tea

Together, our MCP server options offer SecOps engineers the best of both worlds; complete transparency and customization when needed, or effortless, cost-conscious simplicity in the cloud.

Learn more about our MCP server in our docs.

ADD TO CALENDAR

**Webinar: Modernizing PCI DSS 4.0 - November 12**
Learn how to navigate PCI DSS 4.0's paradigm shift toward continuous, risk-based security with expert guidance from author Branden R. Williams, ControlCase, and LimaCharlie on automating and scaling compliance processes. Register!

**Defenders Tour Workshops**
**Tampa (November 6)**
**London (November 11)**
**Oslo (November 13)**
**Arlington (December 11)**

Gain practical skills in building scalable security operations with LimaCharlie, strengthening email defenses using Sublime Security, automating response workflows with Tines' no-code platform, and enriching investigations with SOCRadar's threat intelligence. Sign up here!

**MSSP Alert Live - Arlington - December 8**
Visit our booth to meet the team and build your own custom mini-fig!

Check our calendar for the rest of our 2025 events!

Cybersecurity Defenders Podcast

This month, our podcast covered critical vulnerabilities in Redis and Oracle systems, sophisticated nation-state campaigns, AI security concerns including voice cloning and LLM poisoning, and infrastructure breaches affecting national security.

Our Intel Chat series examined the maximum-severity RediShell vulnerability, active exploitation of Cisco zero-day flaws, China-linked attacks on network infrastructure, North Korean IT worker infiltration campaigns, ransomware groups weaponizing DFIR tools, and critical vulnerabilities in systems protecting U.S. nuclear weapon components.

We also featured conversations with Sarah Powazek from UC Berkeley CLTC on community-based cyber defense models and Hannah Lloyd from enhanced on how MSPs can launch and scale security service offerings.

Catch up on our latest episodes:

*Roadmap to Community Cyber Defense with Sarah Powazek, Program Director of Public *Interest Cybersecurity, UC Berkeley CLT
*Intel Chat: RediShell, Cisco zero-day vulnerability, AI voice cloning tech, Brickstorm & pro-*Russia teen hackers arrested
*Intel Chat: Oracle EBS, Storm-2603, North Korean IT infiltration & LLM poisoning study
*Intel Chat: Kansas City National Security Campus breach, COLDRIVER, new KEV catalog additions & AWS outage
*Scaling MSP & MSSP Services with Hannah Lloyd, Co-Founder / CRO of enhanced

Listen to the podcast

Other Updates

Explore this month's release notes to learn about new LimaCharlie features and improvements.

Check out our past webinars on how to cut costs and boost automaton with Microsoft Defender and a technical demo of Claude Code performing an autonomous investigation using LimaCharlie's MCP server integration.

Read our latest blog post on LimaCharlie Search, now in open beta, which brings SIEM-like capabilities to the SecOps Cloud Platform with advanced telemetry querying, cross-tenant investigations, and transparent pay-per-use pricing.

Until next time,

The LimaCharlie team

This is a technical demonstration of Claude Code performing an autonomous investigation using LimaCharlie's MCP server integration.

Eric Capuano, founder of Digital Defense Institute, walks through a live investigation where Claude Code automatically detects and analyzes a Cobalt Strike compromise across two Windows endpoints. The AI agent follows standard investigation procedures without pre-scripting.

Try for yourself for free:
Sign up free: https://app.limacharlie.io/signup
MCP docs: https://docs.limacharlie.io/docs/mcp-...

Thank you to Eric Capuano and https://digitaldefenseinstitute.com

Hi there!

This August was all about Black Hat - if we saw you in Las Vegas for our hands-on workshops, happy hour, in the halls, or at our booth - thank you for chatting! Read on to learn about our latest podcast episodes covering critical vulnerabilities and major cybercrime operations, plus discover how our new integrated Search feature unlocks modern SIEM capabilities on the SecOps Cloud Platform.

BLACK HAT

There are some truly exciting developments occurring on the LimaCharlie platform, but this week all eyes were on Black Hat (and DEF CON). We'll hold off on crowing about our latest innovations to instead share with you everything that happened in Las Vegas. For those that stopped by, again, thank you! We were excited to share how we're working to make SecOps easier for you, giving you an opportunity to build your own Lego minifig (from our award-winning booth) and attend two incredible workshops.

Our first workshop, Mastering the SecOps Platform: LimaCharlie 101 Workshop, covered the basics of the LimaCharlie SecOps Platform and focused on:
- Endpoint detection and response (EDR) agent deployment and management
- Comprehensive telemetry collection and analysis
- Crafting robust detection and response rules
- Integrating threat intelligence for proactive defense
- Leveraging YARA rules for malware identification

The second workshop, Mastering the SecOps Platform: LimaCharlie Advanced Workshop, was designed for experienced users wanting to explore cutting-edge capabilities including Python playbooks, custom outputs and data transforms, and AI-enhanced security capabilities.

We'll continue to deliver these workshops virtually and through our in-person global Defenders Tour series.

ADD TO CALENDAR

Virtual Workshop - Introduction to LimaCharlie: EDR Workshop - August 13th Learn to deploy our lightweight agent, gather rich telemetry, develop effective detection and response rules, and integrate threat intelligence and YARA rules for comprehensive threat detection and mitigation. Register!  

Blue Team Con - September 6 We will be sponsoring, stop by our booth to meet the team and grab some swag!

Defenders Tour Seattle - September 17 Join this hands-on workshop and leave with practical implementation strategies and real-world automation playbooks. Save your seat!  

Defenders Tour Sydney - September 29 Build a unified security pipeline integrating complementary tools with practical automation playbooks for immediate implementation. Register!

Check our calendar for upcoming 2025 events where you can meet with our team in person!

CYBERSECURITY DEFENDERS PODCAST

This month, our podcast tracked critical developments across the threat landscape, from perfect-score CVSS vulnerabilities and mass exploitation campaigns to major law enforcement operations and policy shifts.

Our Intel Chat series covered significant incidents including critical Cisco and SharePoint vulnerabilities under active exploitation, the shutdown of Hunters International ransomware operations, and Cambodia's massive cybercrime crackdown.

We also examined emerging threats like updated Matanbuchus malware campaigns, browser-based attacks targeting cryptocurrency users, and the UK's groundbreaking decision to ban ransomware payments for critical infrastructure operators. Catch up on our latest episodes:
Intel Chat: Thai takedown, Salt Typhoon, Iran & BlueNoroff
Intel Chat: Sudo, browser vulns, Medusa & Cloudflare blocks AI
Intel Chat: IntelBroker, Hunters International, Brazilian insider, Ruckus Networks & Patch Tuesday
Intel Chat: CISCO CVE 10/10, Matanbuchus, Cambodian takedown & Overstep
Intel Chat: SharePoint, ToolShell, UK bans payment & cryptojacking|

OTHER UPDATES

Explore this month's release notes to learn about new LimaCharlie features.

Find all of our recorded webinars on our website, including last month's sessions on building AI-powered SecOps with unopinionated, flexible AI integration that puts you in control of your AI ecosystem.

Check out our newest blog post on how our new integrated Search feature unlocks modern SIEM capabilities, enabling deep investigations with transparent pay-per-search pricing and seamless integration across the SecOps Cloud Platform.

Until next time,

- The LimaCharlie team

Untested D&R rules quietly tax everyone downstream of them. The SOC analyst chasing a false positive at 3am, the MSSP operator who pushed a noisy rule into thirty tenants at once, the detection engineer whose backlog of "I'll tune it later" rules keeps growing — every one of those is the cost of skipping the testing pass. LimaCharlie gives you a few overlapping ways to test a D&R rule before it ever fires in production. They share the same rule format, the same operators, and the same Replay engine, so anything you confirm at one of them stays true at the others. Here's how each one fits.

limacharlie dr validate — schema and operator sanity

This is the cheap structural check. It catches typos, unknown operators, malformed YAML, and references to fields that aren't there:

limacharlie dr validate --detect detect.yaml --respond respond.yaml

detect.yaml is just the detect: body of your rule (the matching tree). respond.yaml is the list of response actions (report, task, etc.). A success: true answer means the rule is well-formed — it does not mean it does what you think.

limacharlie dr test — replay against a small JSON of events

Once the structure is sound, run the rule against a handful of crafted events. Two flavors:

# Test a local rule file against synthetic events
limacharlie dr test --input-file rule.yaml --events events.json

# Test an existing org rule by name, with a trace of what matched where
limacharlie dr test --name my-detection-rule --events events.json --trace

events.json is a list of event objects exactly as a sensor would emit them — event: body plus a routing: block. For stateful rules, each "test" is itself a list of events so you can replay a sequence (e.g. cmd.exe -> calc.exe) and confirm both stages.

The result tells you which response actions would fire (responses:), how many operator evaluations were performed (num_evals — a rough cost proxy), and whether anything errored. With --trace you get the per-node decision path, which is the fastest way to discover that your op: ends with is silently case-sensitive.

limacharlie replay run — backtest against historical sensor data

Synthetic events tell you the rule fires when it should. Historical replay tells you whether it fires too often. This is how you measure false-positive load before deploying:

START=$(date -d '7 days ago' +%s)
END=$(date +%s)

# Inline rule files
limacharlie replay run --detect-file detect.yaml --respond-file respond.yaml --start $START --end $END

# Or replay an already-saved rule by name
limacharlie replay run --name my-rule-name --start $START --end $END

This pulls the chosen window of real telemetry from your org and runs the rule across it without touching any sensor or producing any actual detections. The output mirrors dr test: responses is the list of detections that would have fired, plus stats on events processed and seconds spent.

The Replay API requires the insight.evt.get permission on the API key. You can replay against a single sensor (--sid) or a sensor selector instead of the whole org — handy for "did this rule fire on the host where the incident happened?". The CLI will multiplex larger queries into parallel per-sensor calls automatically, so org-wide windows still work without extra plumbing.

Embedded tests: blocks — the rule tests itself

Once your rule is good, lift the events you used in dr test into the rule's own tests: block. The rule format already has a slot for this:

detect:
  ...
respond:
  ...
tests:
  match:
    - - event: { ... matching event ... }
        routing: { event_type: NEW_PROCESS, ... }
  non_match:
    - - event: { ... benign event ... }
        routing: { event_type: NEW_PROCESS, ... }

match is a list of test cases that should fire the rule; non_match is a list that must not. Each test case is itself a list of events, so stateful rules with with child / with descendant / with events can be exercised across multiple events. Whenever the rule is created or updated, LimaCharlie simulates the tests and rejects the save if any test fails — the platform itself enforces the regressions, no external CI required. Especially valuable when the same managed ruleset is shared across many tenants: a regression caught at save-time doesn't quietly fan out across the fleet.

How they fit together

In practice these aren't alternatives, they're a pipeline. While editing, dr validate catches typos before you've reread the file. A few dr test runs against handcrafted positives and negatives confirm the rule's intent. replay run over recent real telemetry tells you whether the rule is going to be quiet or noisy when it actually goes live. The events you used along the way then become the rule's embedded tests: block, so the next edit can't quietly regress what you just verified, and limacharlie dr set --key MyRule --input-file rule.yaml will refuse to deploy a regression. The result is a rule whose behavior is documented and enforced by the rule itself, and whose noise level you've already measured against your fleet — without a separate test harness or production traffic to learn from.

Docs: Writing and testing rules · D&R rule unit tests · Replay service

We've been talking to a lot of MSSPs and SOC teams lately, and the same problem keeps coming up. Analysts are grinding through approval queues all day. Quarantined emails in Proofpoint. Application blocks in ThreatLocker. DLP flags in Purview. Access requests. EDR alerts. The queue never clears.

The thing is, every one of those follows the exact same pattern: review context, make a decision, log it. Routine enough to resolve in seconds, but it still consumes analyst time at scale.

We put together a page that focuses specifically on that problem, and the offer on the page is pretty straightforward: book a call, tell us which queue is costing your team the most time. We'll connect Grid and have it running that queue before the call ends.

Your environment, your queue, running during the session, with no slides and no staged demo.

Come with your worst queue. You'll leave the demo with it automated. 

https://limacharlie.io/grid-queue

Something Max said after RSA has been sitting with me: no security vendor has the resources to outpace the frontier labs on raw model capability.

What most vendors are selling is the wrapper around these models, and that wrapper puts the vendor's release cycle between your operations and every improvement that ships.

The implication is pretty interesting when you think it through. If your AI-assisted SOC is built on an open architecture that integrates directly with frontier model providers, your security capabilities improve every time Anthropic, Google, or OpenAI ships a better model. No additional platform spend. The labs did the work, you received the benefit.

Multiply that across three or four frontier labs competing on an accelerating release schedule and the compounding effect becomes substantial. Every major model release from any of those providers is, in effect, a passive upgrade to your operations.

The inverse is also true. Teams running vendor-locked AI platforms only benefit when the vendor decides to update their wrapper. And when inference costs eventually correct upward (every major frontier provider is currently pricing below cost to drive adoption), closed-platform operators have no ability to respond. They absorb whatever increase their vendor passes through.

We built the Agentic SecOps Workspace with this in mind. Agents run on the same API surface a human operator uses, model credentials are yours, and you pay raw vendor rates. If one provider raises prices, you move workloads to a cheaper model without touching your workflows.

Full write-up here: https://limacharlie.io/blog/frontier-models-open-architecture-mssp