Powerful Detection Response Capabilities w/ Bi-directionality

The security industry has spent a very long time getting very good at one half of its job. Detections have gotten sharper, telemetry richer, and the time to spot something malicious keeps falling. The response half never kept pace. An alert fires at machine speed and then waits for a human to pick up a playbook and work it by hand. Matt from LimaCharlie spent this session making a single argument about that gap: the reason response stays slow is not that analysts are slow, it is that most of the systems feeding your SOC can only be read, never commanded. Fix the shape of the data flow and you fix the speed of the response.

Read-only telemetry is what makes response manual

The session draws a clean line between two kinds of telemetry, and the distinction does more work than it first appears. Bi-directional telemetry, which in LimaCharlie has always meant the EDR sensor, both ships data and accepts commands. You can task the sensor, run scripts, pull files, and deploy software over a secure channel, which matters because reaching a system any other way, ad hoc scripts or out-of-band access, stomps on the very forensic artifacts you are trying to preserve. Unidirectional telemetry only flows inward. You forward AWS logs, Google Cloud, Okta, 1Password, or a third-party EDR's alerts into one place and then work the data after it lands.

Matt's point is that the unidirectional model quietly shaped how security teams operate. When every source is read-only, your processes get built around reading: a single pane of glass, queries, detections written against logs you cannot act on. The workflow that follows is the one everyone knows. Detect at wire speed, then either hand off to a separate SOAR platform or go manual. As he puts it, if you detect at machine speed but respond at human speed, you have not gained the efficiency of time, the adversary has. Bi-directionality is his answer: make any source you can build connectivity for into a source you can also issue commands against, from inside the same detection and response rule. He is careful to say this does not mean rewriting telemetry. It means issuing a command based on activity that already happened.

The leverage is in the response side, not the detection

LimaCharlie already separates detection from response, so operators write their own logic on both sides rather than living with a single "if detected, quarantine" checkbox. Bi-directionality extends the response half without touching the detection half, and the examples Matt walks through are deliberately ordinary so the mechanism stands out.

A suspicious login to an Office 365 tenant from a non-approved geolocation used to terminate as an alert for a human to chase. The same rule now calls the Office 365 CLI and locks the account, pulling the username straight out of the detection with template strings and transforms. The interesting part is not the lock, it is what the decoupling buys: the detection stays generic while the response branches on who got hit. A C-suite account can trigger an immediate lock plus a call tree, a least-privileged mailbox or a no-login mailing list account can route to the email admins as a likely misconfiguration rather than a breach. One rule, many graded outcomes.

The Word-spawns-PowerShell case pushes further into why this matters. Almost always phishing, and the obvious move is to kill the process tree, which Matt says he would do without hesitation. But the better question is where the file came from, and answering it means talking to two platforms at once: quarantine the host or kill the process on the endpoint, whether that endpoint runs LimaCharlie EDR or a Defender agent reporting in, while simultaneously handing the file hash to an email security tool like Sublime to see if the same attachment reached other inboxes. That is the real shape of the capability. Take parameters from a detection on one platform and feed them to another, so a single alert becomes containment plus the opening of an investigation.

Why this lands for a provider running many tenants

The deeper move is encoding the incident response playbook itself as rules. Matt frames it as a refusal of single-button security: severity has to depend on context, because a domain controller, an external-facing web server, and an intern's hoteling workstation each deserve a different response tree. Bi-directionality lets you write that branching instead of collapsing everything into "if critical, quarantine, else notify." Humans then handle only the steps that need judgment, like reasoning about how a file actually arrived, the intuition a machine does not have. He estimates this can take thirty to fifty percent off an analyst's workload, though the figure he keeps returning to is not headcount but time recovered per incident.

For an MSSP or MDR, two design details turn this from a neat demo into something operationally serious. First, every source with a CLI or API becomes both monitored and commandable, which collapses tool sprawl and the need for a separate SOAR layer replicated across tenants. The capability ships as the Cloud CLI extension, enabled from the marketplace in seconds, with sample detection and response rules for each integration. At recording time that covered 1Password, AWS, Azure, DigitalOcean, GitHub, Google Cloud, Microsoft 365, Okta, StrongDM, Sublime, and Tailscale, with more in the works. Credentials live in LimaCharlie's secrets Hive rather than as plaintext in a rule, so automated commands never leak secrets into event data, which is not a nicety when you are running these flows across dozens of client environments.

Second, every extension creates its own adapter that records the commands issued and the responses returned in the timeline, and those adapter events are themselves observable. That is what makes the whole thing compound. A command that enumerates VMs can feed its output into a follow-on rule, a quarantine result and an email-search result can be split into separate queues for different levels of human review, and a Sublime query that finds ten matching messages can hand those back to the email provider to delete. Matt calls this bi-directionality on bi-directionality, and it is where the argument finally closes. Once any source can both speak and be commanded, the question stops being which tool sent the alert and becomes what the next ten steps of the playbook are, and how many of them a machine can take before a human ever needs to look.