A behavioral-baseline approach to catching attacks that have never been seen before — because they were never going to match a signature in the first place.
Signature-based detection has one unavoidable structural weakness: it can only recognize what it has already been taught to recognize. A signature is, definitionally, a description of a known pattern — a hash, a byte sequence, a known-bad IP, a rule written after someone else was already compromised by that exact technique. Zero-day attacks are called that precisely because no signature exists yet. By the time one does, the window it was meant to close has usually already been used.
This isn't a criticism of signature-based tools — they remain effective against known, cataloged threats, and there's no reason to discard that layer. The problem is relying on signatures alone for the threats that matter most: the ones nobody has seen before, executed by an attacker who specifically knows that novel techniques don't trip known-pattern matching.
The alternative isn't a smarter signature. It's not needing one — detecting the attack because it deviates from how this specific environment normally behaves, regardless of whether the technique has a name yet.
Applicare's security detection is built on the same IntelliSense engine used across the platform for operational anomaly detection: three layers working together — log and event correlation, statistical anomaly detection against behavioral baselines, and threat intelligence enrichment — to surface suspicious activity that a static rule set would miss entirely.
The behavioral-baseline layer is the one that matters for zero-day detection specifically, because it doesn't ask "does this match a known-bad pattern." It asks "does this deviate from how this entity — this user, this host, this service account — normally behaves." A zero-day exploit still has to do something on the wire and on the host: open a connection, escalate a privilege, spawn a process, move data. Those actions register as behavior, and behavior can be baselined even when the specific technique producing it has never been cataloged.
We're deliberately specific about what "statistical anomaly detection" means here, because the term gets used loosely across the industry to mean anything from a genuine model to a marketing label. In Applicare's IntelliSense engine, a baseline for a given entity-metric pair is built from that entity's own rolling history — a continuously updated mean and standard deviation for the signal in question (connection rate, authentication frequency, process-spawn rate, outbound data volume, and similar security-relevant signals, in addition to the operational metrics IntelliSense baselines elsewhere on the platform).
A new observation is scored against that rolling baseline using a z-score — how many standard deviations the current value sits from the entity's own recent normal. When that deviation crosses a threshold tuned per entity, IntelliSense flags it. There is no proprietary model making an unexplainable judgment call: the math is a standard, well-understood statistical technique, applied per entity rather than globally, which is what makes it both accurate and auditable. If an analyst asks "why did this fire," the honest answer is a specific number of standard deviations from a specific baseline, not a black box.
Worth being precise about
This is rolling-statistics anomaly detection — mean, standard deviation, and z-score thresholds computed continuously per entity — not a trained machine learning model. We describe it this way deliberately: it's a simpler, more explainable technique than "AI-powered threat detection" marketing usually implies, and its simplicity is part of why it's auditable.
An aggregate baseline — one model of "normal login rate" across an entire organization — washes out exactly the signal a zero-day attack produces. A single compromised service account authenticating at 3am is invisible against the aggregate, because thousands of other accounts are also authenticating at various times and the average absorbs the outlier.
A per-entity baseline doesn't have that blind spot. IntelliSense builds a separate behavioral model for every entity — every user, every host, every service account, every workload — learning that specific entity's own pattern of normal. The same 3am authentication that's invisible in an aggregate view is a clear multi-sigma deviation against that one account's own history, because that account has never authenticated at 3am before.
| Detection layer | Catches known threats | Catches novel (zero-day) threats | False positive rate |
|---|---|---|---|
| Signature / rule matching | Yes | No — by definition | Low, but blind to novel attacks |
| Aggregate anomaly detection | Partial | Partial — outliers get averaged out | Medium (30–50%) |
| IntelliSense per-entity baselines | Yes (via correlation layer) | Yes — deviation-based, not pattern-based | Low (under 6%, per-entity) |
One of the clearer illustrations of this approach comes directly from customer feedback rather than a synthetic demo. A security engineer at a retail customer described IntelliSense flagging a credential-stuffing pattern before any of their existing SIEM rules caught it — not because IntelliSense had a rule for credential stuffing specifically, but because the authentication attempt volume against a set of accounts deviated sharply from each account's own established baseline.
“I'll be honest, ‘AI anomaly detection’ usually just means more noise. But IntelliSense flagged a credential-stuffing pattern before any of our SIEM rules would've caught it. That one got my attention.” — Security engineer, retail, quoted on our customers page.
That's the mechanism this paper has been describing in the abstract, observed in production: no signature for "credential stuffing against these specific accounts" existed, because the attack pattern was specific to that environment. The deviation from per-entity baseline was enough on its own.
In the interest of not overselling a real and useful technique: behavioral baseline detection is not a replacement for every other security control, and we don't position it as one. It won't catch an attack that produces no observable behavioral deviation at the layer being monitored. It benefits from a reasonable baselining period — a brand-new entity with no history is harder to score confidently than one with weeks of established pattern. And it works best as one layer among several, which is exactly how IntelliSense is architected: correlation and log analysis plus statistical anomaly detection plus threat intelligence, not statistical detection alone.
We're also not claiming this is a form of predictive AI that "knows" an attack is coming. It's a statistical technique that flags deviation from an entity's own history, reliably and explainably. That's a meaningfully different — and more honest — claim than the industry's typical framing, and it's the one we stand behind.
Applicare's SIEM capability is designed to sit on top of the log sources and detections you already have, not replace them wholesale. Behavioral baselines add the layer that pure signature and correlation rules structurally can't provide: detection of the thing nobody has written a rule for yet. Analytics and correlation catch what's already known. Threat intelligence enrichment adds context once something is flagged. Statistical anomaly detection against per-entity baselines is what closes the gap signatures leave open by design.
The practical result, consistent with what IntelliSense delivers on the operational side of the platform, is fewer false positives and a detection layer that doesn't need to be told in advance what to look for.