Recommended Alerts
Overview
Once Britive audit events flow into your SIEM (see SIEM overview), the next step is turning them into detections. This guide is a starter catalog of alerts worth configuring, organized by category. Each alert lists the Britive event types that drive it, why it matters, and a suggested trigger.
The event types referenced here are the actual event.eventType values Britive emits — use them as the primary filter field in your correlation rules.
The examples below were derived from a real Britive tenant audit export. All tenant-specific values — usernames, IP addresses, application names, transaction IDs — are intentionally excluded. Build your rules on event types and patterns, not on any single actor or resource.
Audit Event Schema
Every Britive audit record carries these fields. Map them in your SIEM parser before writing rules.
| Field | Use in detections |
|---|---|
timestamp | Time window / rate logic |
actor.type | User, ServiceIdentity, System User, SharedKey — pivot human vs. machine |
actor.username, actor.display_name | Per-identity correlation (treat as sensitive) |
client.ipAddress, client.device, client.browser, client.platform | Geo / impossible-travel / new-device logic |
event.eventType, event.displayName | Primary rule filter |
event.additionalInfo | Event-specific context |
target.applicationName, target.environmentName | Scope alerts to sensitive apps/envs |
result.success (true/false) | Failure-rate and denial detections |
result.message | Reason text (e.g. step-up required, invalid credentials) |
Severity Model
| Severity | Meaning |
|---|---|
| 🔴 High | Likely compromise, privilege abuse, or destructive config change — page on-call |
| 🟠 Medium | Suspicious or policy-relevant — review same day |
| 🟡 Low | Informational / baseline for hunting and trend dashboards |
Authentication & MFA
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Repeated login failures (credential stuffing / brute force) | authentication.login with result.success=false | ≥ 5 failures per actor.username or client.ipAddress in 10 min | 🟠 Medium |
| Successful login after repeated failures | authentication.login failures followed by authentication.login / authentication.login.sso success, same actor | Success within 15 min of a failure burst | 🔴 High |
| MFA factor locked | mfa.totp.factor.locked | Any occurrence | 🟠 Medium |
| Admin removed an MFA registration | mfa.registration.admin.deleted | Any occurrence — possible MFA-reset social engineering | 🟠 Medium |
| Forced password update / forgot-password validation failures | authentication.login.password.force.update, authentication.login.forgot.password.validation (success=false) | Spike per actor | 🟡 Low |
| Login from new IP / geo for an actor | authentication.login, authentication.login.sso, cli.authentication.login | First-seen client.ipAddress or country for that actor.username | 🟠 Medium |
| CLI login spike | cli.authentication.login | Anomalous volume per identity vs. 30-day baseline | 🟡 Low |
result.message values like “Invalid username or password” and “Step up authentication required” are reliable signals — parse them, but alert on the event type + success flag, not free-text alone (messages can change between releases).
Privileged Access — Checkout / Checkin
Profile (access.*) and resource (resource.*) checkouts are the core of just-in-time access. Watch volume, failures, and off-hours patterns.
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Checkout request denied / step-up required | access.checkout.request, resource.checkout.request (success=false) | Repeated denials per actor (e.g. ≥ 5 / 15 min) | 🟠 Medium |
| Off-hours privileged checkout | access.checkout, resource.checkout | Successful checkout outside business hours / maintenance window | 🟠 Medium |
| Checkout of a high-value profile or environment | access.checkout, resource.checkout | target.applicationName / target.environmentName in a crown-jewel watchlist | 🔴 High |
| Checkout volume anomaly | access.checkout, resource.checkout | Per-actor count > N× 30-day baseline | 🟠 Medium |
| Repeated checkin failures (access not revoked) | access.checkin, resource.checkin (success=false) | Any sustained failures — JIT access may persist beyond intent | 🔴 High |
| Excessive access extensions | access.extend | ≥ 3 extensions on one session, or extensions concentrated on one actor | 🟡 Low |
| Admin profile checkin | admin.access.checkin, admin.resource.checkin.request | Any — admin-level sessions warrant tracking | 🟠 Medium |
| Approval withdrawn or repeatedly failing | approval.update (success=false), profile.access.approval | Failed/withdrawn approvals clustering on one approver or requester | 🟡 Low |
Secrets
Secret reads are high-signal — they expose credential material.
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Bulk secret reads (possible exfiltration) | secret.read | ≥ N reads per actor in a short window, or many distinct secrets read by one actor | 🔴 High |
| Secret file download | secret.read (displayName “Download secret file”) | Any download of secret files; alert on volume | 🟠 Medium |
| Secret read failures | secret.read (success=false) | Spike — probing for unauthorized secrets | 🟠 Medium |
| Secret deleted | secret.delete | Any — confirm change ticket | 🟠 Medium |
| Secret rotation failed | secret.rotate.failed | Any failure — rotation gap leaves stale credentials | 🟠 Medium |
| Secret created / updated | secret.create, secret.update | Track for change correlation | 🟡 Low |
Policy & Configuration Changes
Changes to who-can-access-what. Destructive ones are high severity.
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Policy deleted | policy.delete | Any — especially bursts (bulk teardown) | 🔴 High |
| Policy created or updated | policy.create, policy.update | Any change to access policy; correlate to a change request | 🟠 Medium |
| Profile (PAP) permission grants | pap.permissions.add, pap.update.scope, resource.profile.permission.add | New permission/scope added to a profile | 🟠 Medium |
| Identity added to a profile | pap.identities.add, pap.tag.add | New principal granted profile access | 🟠 Medium |
| Profile deleted | pap.delete, resource.profile.delete | Any — loss of access control object | 🟠 Medium |
| Resource permission changed/removed | resource.permission.update, resource.permission.delete, resource.profile.permission.remove | Bursts or off-hours edits | 🟠 Medium |
| Managed permission changes | managed.permission.create, managed.permission.delete | Any | 🟡 Low |
| Application or environment property change | application.update.properties, environment.update.properties, environments.disable, environments.delete | Disable/delete of an environment | 🔴 High |
| Broker pool / response template / resource-type changes | broker.pool.create, response.template.*, resource-type.create/update/delete | Track infrastructure-level edits | 🟡 Low |
Identity & Tag Lifecycle
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| User created / deleted / disabled | user.create, user.delete, user.disable | Bulk user deletion, or off-hours creation | 🟠 Medium |
| Tag membership change | tag.add.identity, tag.remove.identity | Membership change on a privileged tag (watchlist) | 🟠 Medium |
| Tag created / deleted | tag.create, tag.delete | Deletion of a privileged tag | 🟠 Medium |
| Identity provider changed | identity.provider.create, identity.provider.delete | Any — IdP changes affect the whole trust chain | 🔴 High |
| SCIM attribute mapping change | user.attribute.scim.mapping.add, scim.token.create | Any | 🟡 Low |
Service Identities & API Tokens
Non-human identities and tokens are common abuse paths — actor.type of ServiceIdentity or SharedKey deserves its own dashboards.
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Service identity created or updated | service.identity.create, service.identity.update, service.identity.access.update | Any creation or privilege change | 🟠 Medium |
| Service identity deleted | service.identity.delete | Any | 🟡 Low |
| API token created | api.token.create | Any — new long-lived credential; correlate to owner | 🟠 Medium |
| API token revoked | api.token.revoke | Track; spike may indicate incident response or token churn | 🟡 Low |
| Service identity activity anomaly | any access.* / resource.* / secret.read where actor.type = ServiceIdentity | Checkout/secret access outside the SI’s normal pattern or hours | 🟠 Medium |
| Shared key usage | any event where actor.type = SharedKey | Baseline and alert on unexpected use | 🟠 Medium |
Scans & Operational Health
Mostly low-severity, but useful for hunting and to catch monitoring blind spots.
| Alert | Event types | Trigger | Severity |
|---|---|---|---|
| Scan failures / timeouts | environment.scan (success=false), resource.scan.timed_out | Sustained failures — stale entitlement data | 🟡 Low |
| Account mapping changes | environment.accounts.users.mapping, environment.accounts.users.unmapping | Bulk unmapping (access loss) or unexpected mapping | 🟡 Low |
| Scan settings changed | resource.scan.settings.update | Any | 🟡 Low |
Implementation Tips
Normalize the event type field
Map event.eventType to a single indexed field. All rules above key off it — consistent parsing is the foundation.
Build watchlists, not hardcoded values
Maintain lookup lists for crown-jewel target.applicationName / target.environmentName, privileged tags, and business hours. Reference the lists in rules so you never embed a specific tenant value in detection logic.
Pair failure spikes with the follow-on success
The highest-value detections chain a failure burst to a later success by the same actor.username (e.g. brute force → login, denied checkout → step-up → checkout). Use your SIEM’s sequence/correlation primitive, not two independent rules.
Baseline per identity
Volume alerts (checkouts, secret reads, CLI logins) need a per-actor baseline. Compute a rolling 30-day mean and alert on multiples, separating User from ServiceIdentity.
Keep actor and target values out of rule definitions
Treat usernames, IPs, and resource names as data, not config. This keeps detections portable across tenants and avoids leaking sensitive identifiers into rule exports.
Next Steps
- SIEM integration overview — getting events into your SIEM
- ITSM & Incident Management — gate access on tickets and escalation policies