Aegis / Pinnacle Insurance - Detect Roadmap Review

Of course, absolutely — okay so, I've got the agenda pulled up, we wanted to walk through some of the Detect roadmap items, and I know you had some specific feature requests you wanted to put on the table today.

Sure, sure, yeah we can definitely touch on that — I know the Comply v2 launch just happened last week actually, so there might be some relevant stuff there.

So the primary thing — and I've been saying this for a couple of quarters now — is that we really need more granular alerting thresholds by entity type.

Right, can you walk me through specifically what you mean by entity type in your context?

But right now in Detect, when we're setting alert thresholds, it's basically a one-size-fits-all situation, and that creates a ton of noise on the low-risk endpoints and then potentially under-alerts on the high-value systems.

-1Describes one-size-fits-all thresholds creating noise and under-alerting on high-value systems. · product capability

Understood, and I don't want to get too far ahead without checking — are we talking about thresholds on the behavioral side, like anomaly detection thresholds, or also on the signature-based rules?

Both, but honestly the behavioral side is where it's most painful because the baselines are being calculated across everything and they just don't reflect the actual behavior patterns of, say, a claims adjuster versus a network admin.

-1Says behavioral side is most painful because baselines don't reflect actual patterns. · product capability

Got it, okay — so what you'd really want is the ability to define entity groups and then have separate baseline models trained per group, essentially.

Exactly, yes, that's exactly it — and ideally you'd be able to map those groups to your own org hierarchy, not just some generic taxonomy.

Okay, I'm noting all of this down — and I do want to be upfront with you, Sandra, that the entity grouping with custom baselines is something our product team has been scoping, it's not GA yet, it was targeted for Q3 in the roadmap I have, but I want to get you connected with our product team directly so they have this context.

That's the current target, yeah — but I want to be careful not to commit to that because roadmaps shift, as you know.

The second thing, um, this is a little more sensitive to bring up but I think it needs to be on the table — the outage in March.

So we were dark for, what, six hours — and look, I understand things happen, infrastructure fails, I've been in this industry long enough to know that, but for us specifically, that's six hours where we had no visibility into threats across our environment, and given our regulatory obligations that's not a small thing.

-1Highlights six-hour outage as a regulatory concern. · service reliability

No, absolutely not, and I want to acknowledge that directly — that outage was a significant failure on our part, it was a cascading failure in the event ingestion pipeline, single point of failure that we should have architected around, and we did not.

And the fix — we've implemented redundant processing nodes and a circuit breaker pattern so that if one node in the pipeline degrades, it doesn't take everything down with it, and that's been live since mid-March.

Okay, so my follow-up question on that is — and this goes to the feature request angle — is there any way for customers to have visibility into the health of the Detect pipeline itself, like a status indicator within the product?

Yeah because we only found out about the outage because someone on my team noticed the alert volume had dropped to zero and then went and checked the status page — that's not a great discovery mechanism.

-1Notes alert volume dropping to zero is not a good discovery mechanism. · product capability

No, I completely agree, and that's — I'll be honest, that's a gap in the product experience, and I'm going to log that as a formal feature request, in-product pipeline health status with proactive alerting if ingestion drops below a threshold.

Understood, and I think that's a very reasonable ask — I'm going to make sure that goes to the right product team with your name on it so they have the customer context.

First one is expanded SIEM integration — we're adding native connectors for a couple of the major SIEM platforms in Q2, which I know you're running LogVault, so that should reduce the time from event to alert in your existing workflow.

That would actually be helpful, yeah — right now the LogVault integration is a little manual, we're doing some custom scripting to get the data in there.

+1Welcomes native LogVault integration as helpful versus manual scripting. · product capability

Yeah so that should get a lot cleaner — I'll send you the details on that after this call, it's a Q2 item so should be coming up relatively soon.

Second one is — we're building out a threat intelligence correlation layer, so essentially Detect will be able to cross-reference events against external threat intel feeds in near real-time, which should improve the signal-to-noise ratio on the alerts that are actually meaningful.

That's interesting — what feeds are you pulling from?

The initial launch is going to include a few of the major ones — I don't want to get into specifics that I haven't confirmed with the product team, so let me get you the accurate list rather than guess.

We're subscribed to FS-ISAC feeds and I'd want to see that included, that's probably the most relevant for our threat landscape.

Yeah just quickly — we're coming up on a SOC 2 Type II renewal and honestly the reporting process last time was pretty painful, lots of manual exports and spreadsheet work.

-1Describes SOC 2 report process as painful with manual exports and spreadsheets. · compliance reporting

So this is actually really timely because Comply v2 launched last week — April 7 — and one of the headline features is on-demand SOC 2 reporting, so you can generate the report without the manual export process, it pulls directly from the data in the platform.

Okay, that's — yeah that could actually save us a lot of pain, when can we see that in action?

+1Says on-demand SOC 2 reporting could save a lot of pain. · compliance reporting

I can set up a demo for your team, I'm thinking we loop in your compliance lead too — would that be the right person to have in the room?

So from my side — I'm logging two formal feature requests: entity grouping with custom behavioral baselines, and in-product pipeline health status with proactive degradation alerts.

Correct, yes.

I'm also going to send you the confirmed list of threat intel feeds for the correlation layer, including whether FS-ISAC is on the roadmap, and the details on the LogVault native connector timeline.

That all sounds right.

And then I'll set up the Comply v2 demo with you and Marcus — I'm thinking we can probably do that within the next two weeks?

Two weeks works, yeah — try to avoid the last week of April if you can, I think we've got some internal stuff happening.

No problem, I'll aim for the week of the 20th — I'll send a calendar invite.

Perfect, that works — and Rachel, I do appreciate you actually listening on the feature requests, sometimes these calls feel like they go into a black hole so.

+1Appreciates Rachel listening, contrasting with calls that go into a black hole. · support experience

I hear you, and I want to make sure that doesn't happen here — I'll keep you posted on what traction these get with the product team, even if the answer is not yet, I'll tell you.

Sounds good — thanks Sandra, I'll have everything in your inbox by end of week.