Monitoring failed privilege escalations is a basic security hygiene check. Delinea's reporting is decent, but you need to actively alert on this, not just review logs.
Here's a quick setup using their webhooks and a generic HTTP alerting tool (like Splunk, PagerDuty, or even a custom script):
* In your Delinea PAM portal, navigate to Administration -> Notifications.
* Create a new notification for the event `Privileged account elevation failed`.
* Set the action to `Webhook`. Point it to your alerting system's ingestion endpoint.
Key config in the webhook payload mapping:
* Ensure `{EVENT_DETAILS}` and `{ACCOUNT_NAME}` are included.
* Filter noise: set a threshold, like 5 failures in 60 seconds from the same source, at the alerting tool level.
Without this, you're relying on someone manually checking reports. This creates a critical lag.
This is super helpful, thanks for laying out the steps! I'm new to setting up alerts in our PAM system. Quick question about the noise filter: Is that threshold something you'd set up in Delinea itself, or is that done purely in the receiving tool like Splunk? I always get tripped up on where to put the logic 😅
Ask me in a year
That threshold logic absolutely needs to be in the receiving alerting tool, not Delinea. Their notification system is just a dumb firehose, it triggers on every single event. If you try to build aggregation logic there, you'll end up with a convoluted mess of scheduled scripts.
You set the threshold in Splunk, PagerDuty, or whatever you're using for correlation. For example, in a Splunk alert, your search would look for the event, then use `stats count by source_ip` with a `where count > 5` clause over a 60-second window. Trying to make Delinea do stateful counting is the wrong layer of abstraction.
Otherwise, you'll get a page for every fat-fingered password, and your on-call will rightfully revolt.
Oh, right. That makes total sense, thanks for clarifying. The "dumb firehose" description is perfect.
So the PAM system's job is just to send the raw signal, and it's the alerting tool's job to do the smart stuff, like counting. That separation seems cleaner.
Follow-up: does the same principle apply to other events, like "policy violation" alerts? Should all the aggregation and time-window logic live downstream too?
It's done in the receiving tool. Delinea's notifications are stateless, they can't count.
I made the same mistake thinking I could set a threshold in the event rule itself, but it just doesn't work that way. The logic has to be in your analytics or alerting layer.
For Splunk, you'd build the search window and threshold into your alert condition, not the webhook.
Agreed on the critical lag point. One thing to watch: the default `{EVENT_DETAILS}` field can be a bit sparse. We had to create a custom notification template to also pull in the `{SOURCE_ADDRESS}`. Without the source IP in the webhook payload, your downstream tool can't do the `stats count by source_ip` that user1339 mentioned.
Numbers don't lie
Oh that's a really good catch. I hadn't even thought about what was actually *in* the payload fields. So if `{EVENT_DETAILS}` is just text like "login failed," you'd be stuck.
Is creating a custom template for the notification a big hassle in Delinea? Or is it just a matter of picking different variables from a dropdown when you set up the webhook?
The "dumb firehose" analogy is precise. This separation of concerns is architecturally sound, and trying to enforce it in the PAM layer often leads to the exact convoluted script mess you mentioned. A practical extension of your Splunk example would be handling the alert condition reset. You need to ensure your correlated alert doesn't simply fire once and then go stale, but has a clear resolution path, perhaps by tracking that the `count by source_ip` has fallen back below the threshold for a subsequent window. Without that, your alert dashboard becomes a graveyard of old incidents.
—BJ
Exactly. Letting alerts become permanent noise defeats the whole purpose. The real operational gap is that most teams just set a trigger condition and call it a day.
Your Splunk alert needs a proper reset. You don't just look for count > 5. You need a second condition, like count <= 2 for a defined period, to clear the alert state. Otherwise, your alert fires once and then just sits there open forever, useless.
If your alerting system can't handle stateful clear conditions, you're building a dashboard of lies.
— geo
Thanks for the guide, it's a great starting point. The bit about "critical lag" hits home - we've been looking at weekly reports and it feels way too passive.
Quick question: when you point the webhook to your alerting system, is there usually any authentication needed? Or does Delinea just send it out to the endpoint you provide?
Still learning.
It's just HTTP, so you can do whatever the endpoint expects. Usually a simple API key in a header.
But it's Delinea. The webhook config UI is clunky as hell. Don't expect to just paste in a custom Auth header value. You'll probably need to stick the token in the URL as a query param, which is gross.
If you're lucky, their "custom template" feature lets you add headers. If not, you'll be setting up a tiny proxy lambda just to add the header and forward it. Painful, but doable.
Weekly reports for privilege escalation? That's just checking a box for auditors. Useless for ops.
Great starting guide. The bit about "filter noise at the alerting tool level" is absolutely key. It's so tempting to try and make the PAM tool do that logic, but you're right, it's not built for it.
One extra tip: when you map the payload, also check if you can include a unique event ID variable, like `{EVENT_ID}`. Some downstream systems need that to deduplicate events and prevent alert floods from the same trigger.
null
Absolutely, that graveyard of stale alerts is a real problem. Your point about the reset condition is spot on.
Many teams miss that you need to set the "alert resolve" logic with the same care as the "alert fire" logic. In Splunk, that's the `resolve` property in the alert definition. Without it, your dashboard gives a false sense of ongoing compromise.
A small caveat: if you set your reset window too short, you risk the alert flickering on and off during an actual slow, steady attack. It's a balance between clean-up speed and missing a real threat that's just under the threshold at any single snapshot.
Integrate or die
That flickering point is critical. We saw this exact failure mode when we tried to implement alert resolves based on a short sliding window. An attacker who knew our threshold could just pepper us with attempts, staying just under the limit each window, and never trip a persistent alert. Our "smart" reset logic made us blind to a low-and-slow attack.
You need hysteresis, not just a simple reset. The condition to clear should be stricter than the condition to fire. If fire is `count > 5 in 10 minutes`, then the resolve shouldn't be `count <= 5 in 10 minutes`. It should be something like `count <= 2 for 30 minutes`. That dead band in the middle stops the flicker and forces a sustained period of normal activity before the alert clears. Most alert systems let you define these independently, but few teams do it.
Migrate once, test twice.
Hysteresis is such a great term for this. It's the missing piece in a lot of alert discussions.
One nuance is that the "dead band" approach you describe also helps with operational fatigue. If an alert resolves the moment the count dips, and then fires again two minutes later, the ticket noise alone will cause teams to ignore it. Forcing a sustained quiet period before resolution means each alert ticket represents a more meaningful, contained incident.
I've found you need to tune that resolve window based on your team's response time. If it takes you 15 minutes to even look at a ticket, a 30-minute resolve window might be too aggressive.