Security context, alerts and history holds in your tenant

Security context

Each protocol Audit record written while serving a request keeps its context: the browser and operating system as short names such as Chrome on Windows, the country Cloudflare reported, a network digest, and for sign-ins the public session ID and the method used; a sign-in through an identity provider names the provider instead of a method. The network digest is a keyed hash of the caller's network (an IPv4 address, or an IPv6 /64) that is the same for the same network within your tenant and different in every other tenant. Neither the address nor the user agent text is stored. A wrong password for an existing account names that account as the record's subject, never its actor, because whoever typed the address has not proved who they are. Open a record in Audit, source Protocol activity, to see its context. Under More filters, Subject narrows Protocol activity to one person by user ID, or by email if you may also read users, and Session ID to one browser session by its public ID or its first 8 characters. Action narrows it to one protocol action, such as Request OAuth token, From and Through to whole UTC days, and the search box to one exact request ID, the value a response's X-Request-ID header carries and Logs show, so a detection query can run here. A record's details offer Show this subject's activity and Show this session's activity. Reading one person's activity this way is recorded in Audit with that person as its subject.

Choose how many days context is kept, from 1 to 30, under Security context on the Alerts page. After that the record stays and its context is cleared, except for records under a legal hold. A Beyond the Login account's sign-ins on the Beyond the Login site are recorded with the same context in its home org.

This was not me

On their Security page, each person sees where they are signed in. This was not me signs that browser out and records the report, which the not_me rule raises as an alert for your administrators. The Beyond the Login site offers the same for Beyond the Login accounts.

Detection rules

Rules run on each record as it is written, so no sign-in path can skip them. Each sign-in rule raises at most one alert an hour for the same user, network or application; the two access rules raise one alert for each request.

• Sign-in from a new browser and from a new network (low): a successful sign-in whose browser and system, or network, the user has not signed in from in the context still kept. A first sign-in is never new.
• Sign-ins from two countries too close together (high): two successful sign-ins from different countries within a number of hours you choose, 1 to 24.
• Password guesses across many accounts from one network (high): wrong passwords for at least the number of accounts you choose, 3 to 100, from one network within an hour. Guesses for addresses with no account each count once.
• Many failed sign-ins across the tenant (medium): at least the number of wrong passwords you choose, 5 to 10000, in an hour.
• A code or refresh token was used again (high): an authorization code or refresh token replay at the token endpoint.
• A user reported activity that was not them (high), and a sign-in approval was denied or answered with the wrong number (medium), from push approvals.
• Someone took emergency access (high): a person used a catalog item's emergency access, which gives the access at once without approval. Every emergency raises its own alert, as it happens.
• Access marked high sensitivity was given through a request (medium): a request or just-in-time activation for a catalog item of high sensitivity was fulfilled, after its approvals. Access an administrator gives directly is not alerted; it is in Audit under the administrator's name.

Turn each rule on or off and set its threshold on the Alerts page. Each raised alert is also a protocol Audit record, security.alert.

The Alerts page

Alerts lists alerts by status, newest first, with the user, a short detail, the network digest's first characters and the request ID to search in Audit. Acknowledge, resolve or reopen each one. A user's email address is shown only to readers who may also read the user directory; others see the user ID. Alerts are kept for 30 days. At most 1000 can be open: beyond that new alerts are not raised, and the page says how many were not.

Alert email

A digest of new alerts at or above the severity you choose goes at most every 15 minutes to everyone who can read alerts: tenant users with a confirmed email address, and Beyond the Login accounts that manage the tenant, at the address on their Beyond the Login account. It goes to at most 20 people, people who live in the tenant first. It says how many alerts are new, never who or what they concern. Each digest is recorded in protocol Audit as security.notify, with how many messages were sent.

Export

Below the Audit and Logs viewers, Export downloads the selected source as CSV or JSON: User directory, OAuth management or Protocol activity from Audit, or Protocol summaries from Logs, up to 5000 records from up to 31 days, filtered by outcome. Records hold the same fields the viewer shows. CSV cells that a spreadsheet would run as a formula start with an apostrophe. Tenant management lifecycle history and request logs are kept outside your tenant's store and are not exported here.

Legal holds

On the Audit page, Legal holds keeps the Audit records of a past period, for everyone or one user, beyond the usual 30 days, for up to 365 days or until you release it. Held records keep their security context. Releasing a hold returns its records to their normal expiry, unless another active hold covers them. While a hold is active, the tenant cannot be reset: release the hold first. Up to 10 holds can be active.

Permissions, Audit and limits

Reading alerts needs tenant.alerts.read; acknowledging them and changing rules, email and context retention needs tenant.alerts.manage. Exporting needs tenant.audit.export or tenant.logs.export as well as the matching read permission. Holds need tenant.history.hold. Tenant Admin holds all of them, and custom roles can include any. Each read, change, export and hold is recorded in management Audit. Your tenant can export 30 times an hour. All limits appear in your tenant's usage view. The BTL organization has the same Alerts page, export and holds under BTL Admin.