The CISO's data problem (and how browser telemetry can help)

The quantification problem nobody talks about

I was recently teaching SANS LDR551, where we cover some of the flawed approaches used in risk measurement and prioritization — for example, presenting ordinal data in a risk matrix as ratio data, implying that the matrix represents quantitative analysis when it’s more of a best guess. We then look at modeling using Loss Exceedance Curves as a more accurate, if much more difficult, approach to quantitative risk assessment.

The only problem is, we rarely have the time or the data to construct such models. Ask a CISO how they measure risk for credential compromise and other account takeover attacks, and the answer will probably include one or more of the following: a risk assessment, a whiteboard, and a room full of smart people making educated guesses about attack frequency and control strength.

That isn't a criticism — for most risk scenarios, expert elicitation is the best (and most convenient) available method. Breach cost data is sparse, threat actor behavior is unpredictable, and internal incident history is (ideally!) a limited sample. Quantitative risk frameworks like FAIR give structure to that uncertainty, but they can't conjure data that just doesn't exist.

The results are usually estimates with wide confidence intervals and loss distributions that appear precise, but are hard to defend to a CFO or a board. Finance leaders have seen Monte Carlo simulations before; the capable ones will challenge the quality of the outputs if they doubt the quality of the inputs. But with the right telemetry, we can get both.

Why the identity attack surface is uniquely measurable

We've written extensively about the shift to identity as a primary attack vector — and the evidence continues to stack up. Credential phishing, device code phishing, ClickFix, adversary-in-the-middle attacks, session hijacking, and SaaS account compromise now account for the majority of breach entry points in most enterprise environments. But the silver lining here is that this shift has created something valuable for risk quantification: a highly observable threat surface.

Identity attacks execute in the browser. They leave traces in authentication flows, login behaviors, OAuth integrations, extension activity, and SaaS access patterns — all of which are captured in real time by the Push extension. Unlike network or endpoint attacks, where the signal is often binary and retroactive, browser-based identity threats generate continuous, high-frequency telemetry that maps directly onto the inputs that drive quantitative risk models.

This telemetry directly informs the hardest inputs in any quantitative risk model. One is Threat Event Frequency (TEF): how often a threat agent acts against an asset in a given period. For identity risks, this can be answered in how many credential phishing attempts reached your users across all delivery channels (social media, email, malvertising, etc.), or how frequently your users authorize malicious or compromised SaaS apps. Browser-level telemetry can answer these questions with observed data rather than industry lookups and general benchmarks. 

The other input to risk modeling that's difficult to express in concrete terms is vulnerability: the probability a threat becomes a loss event or, more specifically, how likely it is that your controls will fail.

This is where browser telemetry gets especially concrete. Analysis of login telemetry across Push-monitored environments shows that 1 in 4 logins are still password-only (not SSO), 2 in 5 are not protected by MFA, and 1 in 5 use a weak, breached, or reused password. Many of these logins occur outside the visibility of a central IdP platform like Microsoft, Google or Okta — the result of downstream ghost logins.

In a FAIR-based model, TEF and vulnerability together determine loss event frequency: the foundational driver of the entire risk calculation. Using telemetry from your own environment as the basis for these calculations makes them far more accurate, and more likely to stand up to scrutiny.

The attack surface is bigger than most models assume

One of the consistent failures in identity risk modeling is the tendency to model risks defenders can see, and leave the rest off the balance sheet. These omissions create a systematic understatement of exposure that browser-based telemetry can offset.

Shadow AI and OAuth sprawl

The Vercel breach in April 2026 was the result of an OAuth connection to a third-party AI SaaS tool a developer connected into the organization's Google Workspace tenant (without admin approval). When the AI vendor was compromised, the attacker leveraged stored OAuth tokens to access downstream accounts, ultimately reaching internal dashboards, API keys, and source code.

Push telemetry across customer environments shows an average of 17 unique AI app integrations per organization in Microsoft and Google alone, most of which security teams would describe as unapproved. These generally don't appear in a conventional risk model that isn't looking for them.

Browser extensions

Analysis of 20,000 unique extensions deployed across Push customer environments found that 46.76% have the permission combinations required for account takeover without user interaction. The extensions carrying these permissions aren't flagged by risk scoring systems because the same permissions are used by ad blockers, password managers, and translation tools (the downside of relying on tools that rely on dubious scoring to assess extensions, but I digress).

What matters for risk quantification isn't the permission set or an arbitrary score assigned by a vendor; it's whether the monitoring exists to detect when a previously-clean extension changes ownership, escalates permissions, or behaves anomalously. Without that monitoring, the exposure is real but unquantified.

ClickFix and non-email delivery channels

ClickFix — where a malicious page silently writes a PowerShell or mshta command into the victim's clipboard and instructs them to paste it — was the most common initial access vector observed by Microsoft in 2025, and CrowdStrike reported a 563% increase in fake CAPTCHA lures (one of the most common ClickFix styles in which the user has to "verify they're human" by running a command on their machine).

What makes this particularly relevant for risk quantification is the delivery channel: 4 in 5 ClickFix payloads intercepted by Push arrive via search engines, not email. A risk model that estimates threat event frequency from email-based phishing telemetry alone is structurally blind to an entire category of attack that has become one of the most prevalent initial access methods in the landscape.

Authorization attacks

Device code phishing and OAuth consent abuse represent a slightly separate category of identity attack that most risk models don't account for because they operate after the authentication flow has already completed — meaning password strength, MFA coverage, and SSO adoption are irrelevant to whether the attack succeeds.

The key lesson for CISOs

A risk model that measures identity vulnerability purely in terms of authentication hygiene at the IdP layer — how many accounts have MFA, how many use SSO — will correctly quantify one dimension of exposure while completely missing another that is growing faster and is structurally immune to the controls being measured.

For a CISO building a risk model, these aren't edge cases. They represent a real attack surface that doesn't show up in models built on conventional network, endpoint, and cloud telemetry. We aren't just talking about better inputs to risk modeling — we're talking about entirely new risk scenarios that aren't being modeled at all, supported by live data.

Browser telemetry makes a CISO's life easier

Browser-based telemetry changes the conversation a CISO can have with a CFO or board. Instead of "industry benchmarks suggest our expected annual loss from account compromise is somewhere in this range," the answer is, "We can see how often these attacks are attempted against our users, and we can measure what percentage of our accounts have the controls in place to stop them," or "We know how many shadow AI apps our users self-provision and share data with each month."

Identity risk is only a piece of the quantification problem. Loss magnitude, regulatory exposure, and reputational impact are still extremely hard to estimate regardless of how good your frequency inputs are.

But the identity attack surface is one of the few areas in security where measurement is genuinely achievable right now, and the gap between what most organizations are modeling and what's actually observable is significant. Shadow SaaS integrations, unapproved AI connections, browser extensions with excessive privileges — these are enumerable risks that don't appear in models built on network, endpoint, and cloud access telemetry alone. 

The lesson for CISOs serious about quantitative risk management is this: the frameworks exist, the talent is available, and the bottleneck is almost always data quality. Browser telemetry is a good example of the kind of high-fidelity, environment-specific measurement that closes that gap.

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required.

Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see. Book a live demo to learn more.