Beyond EDR: Securing Your SaaS Attack Surface with LimaCharlie Adapters

The endpoint-centric defense industry has spent a decade perfecting telemetry from a place attackers increasingly avoid. Most of the breaches that have mattered recently never landed on a laptop. They moved through SaaS applications and cloud identities, where a stolen token or a forgotten login path is worth more than any malware. Ken Westin, a Solutions Engineer at LimaCharlie who has spent years inside Splunk, Elastic, and a string of EDR, XDR, and SIM vendors, framed this session around that mismatch. The industry keeps measuring coverage in a place that no longer holds the action, and the tools built to win those measurements were never designed to watch where the action went.

The blind spot is structural, not accidental

Westin opened with a diagram that went viral on LinkedIn, a map of the modern security stack assembled by the Software Analyst Cyber Research group. His point was not that the chart is busy. It is that every logo on it is a separate integration, a separate license, a separate pricing model, and a separate negotiation, and a meaningful share of it ends up as shelfware: bought, paid for, never fully deployed because nobody had the resources to stand it up. Sprawl is the visible symptom. The deeper problem is what the industry chose to measure.

MITRE ATT&CK, and the EDR evaluations built on top of it, carry an endpoint bias. Vendors fight over who scored 100 percent, or 110 percent, on the endpoint matrix while the most damaging intrusions of recent years barely touched an endpoint at all. Westin pointed instead to the SaaS attack matrix from Push Security, which aligns tactics and techniques for SaaS applications the way ATT&CK does for endpoints, and recommended it as the place to start deciding what to watch. The recommendation came with a caveat that turns out to be the heart of the talk. SaaS telemetry is not cookie-cutter. What matters in one tenant is noise in another, so the only reliable way to know what a detection should catch is to generate the logs yourself, including through adversary emulation, and read what actually comes out.

Two techniques carry the argument. Ghost logins happen when an older single-factor path stays enabled after MFA is added, the class of misconfiguration involved in the Snowflake-related compromises, where Westin was careful to note the fault lay with customer configuration rather than the platform. Stolen API tokens are the more durable threat. An attacker finds a key left in a GitHub repository or a Google Doc, and if that token carries superuser privileges it survives a password reset and even account deletion. The common pattern is to steal a token, create a new user, escalate that user, and keep minting tokens indefinitely. Endpoint telemetry sees none of this. The signal lives in the SaaS audit log, which is exactly the source most stacks treat as too expensive or too peripheral to ingest.

Detection follows ingestion, and ingestion is the constraint

This is where Westin's framing of LimaCharlie as a security operations platform rather than an EDR earns its weight. He used the box-of-Legos analogy: EDR agents, SIM-style log handling, and cloud and SaaS telemetry assembled to fit an environment rather than bought as siloed products, priced on usage (sensors deployed, data ingested) instead of a locked long-term contract. Two properties do the real work for a provider. The platform sits on a security data lake with a full year of searchable retention regardless of how data arrives, and it is multi-tenant by design rather than retrofitted from an on-prem architecture, so tenants are genuinely separated and everything in the UI is reachable through the API.

The retention economics are not a footnote. They are why the SaaS coverage is reachable at all. High-volume sources like CloudTrail are the ones teams quietly drop from legacy SIMs because ingesting and searching them is too costly. The same logic pulls Windows Defender data into LimaCharlie, where retention runs cheaper than Microsoft's own tooling and the data stays searchable and detectable, including aggregation rules layered on top. Once the cost of holding a log for a year stops being prohibitive, ingesting Slack, GitHub, HubSpot, Zendesk, and Okta becomes a default rather than a budget decision. Several of those SaaS adapters are recent additions, built because customers asked for visibility into the tools already in their arsenal.

What the demo actually proves

The live portion was deliberately undramatic, and that is the argument. Onboarding 1Password meant creating an installation key, naming the adapter, and pasting an API token from the 1Password admin console, with the standing reminder never to park that token in a repository. Data appeared immediately in a per-sensor timeline. From there Westin surfaced user-creation events and wrote a detection and response rule that reports a new user and passes the actor's name through. The rule extends in a single line of logic: because he is the only 1Password administrator, anyone else creating an account raises the severity. Okta repeated the pattern against activity his own adversary-emulation runs had generated, surfacing access-token creation, admin logins, and MFA deactivation, each becoming a straightforward rule. Custom, webhook, and JSON sources arrive the same way.

The lesson for an MSSP or MDR is not that LimaCharlie can collect 1Password logs. It is that the gap between "we should watch SaaS" and "we are watching SaaS, with tuned detections, across every tenant" is mostly a question of ingestion cost and tenant architecture, both of which the platform is built to absorb. Endpoint-only coverage is a position your clients will eventually feel, because the adversaries already moved. The providers who close the gap will be the ones who can afford to ingest the identity and SaaS telemetry, retain it long enough to investigate, and write the handful of environment-specific rules that turn an audit log into an alert. The demo's real claim is that none of that requires another tool, another license, or another negotiation. It requires an API token and the decision to look where the attacks actually are.