Types of Alerts
The following table explains the types of alerts.
| Alert Name | Description | Logic |
|---|---|---|
|
Login on weekend |
User login during a weekend |
Trigger an alert if a user logs in on Sunday or Saturday. Filter out users who are active on two or more consecutive weekends. |
|
User performed an activity from an abnormal location |
User performed an activity from a location where they are not normally found |
Based on the session IP, compare the session location to the user's previous locations (at least 10 days of baseline required) and alert if the location is new. Ignores IPs with unknown locations. |
|
Irregular session |
The user sessions started before or after the user's usual activity time, determined by the user timeline |
Baseline data is collected for at least 14 days of activities. Based on this baseline, determine the user's usual start time and end time, as one standard deviation from start and end time. Each session occurring outside of those thresholds triggers an alert. |
| Suspicious user agent | Detects if the user's agent is either downgraded or new to this user | Based on the baseline of the user (requires at least 10 days), the system checks if the user's agent is downgraded. For example, the user is using Chrome 135, and suddenly switched to chrome 133; or, if the user-agent platform is new. For example, a change from Chrome to Safari. |
|
Abnormal spike in secrets view |
The user viewed secrets more than five times their normal activities |
Determine whether the baseline of at least 14 days of platform usage exists for the user. If the baseline exists, calculate a baseline of activities, for secret view.
Trigger an alert if the user's secrets views exceed five times the number of average activities. |
| Abnormal spike in session lunches | The lunched session count is more than five times their normal activities |
Determine whether the baseline of at least 14 days of platform usage exists for the user. If the baseline exists, calculate a baseline of activities, for session lunches. Trigger an alert if the user's number of lunched sessions exceed five times the number of average activities. |
| Abnormal spike in file transfer |
Determine whether the baseline of at least 14 days of platform usage exists for the user. If the baseline exists, calculate a baseline of activities, for file transfers during sessions. Trigger an alert if the user's file transfers counts exceed five times the number of average activities. |
|
| Abnormal spike in platform administrative action |
Determine whether the baseline of at least 14 days of platform usage exists for the user. If the baseline exists, calculate a baseline of activities, designated as platform administrative. Trigger an alert if the users’ platform administrative actions exceed five times the number of average activities. |
|
| Abnormal spike in Secret Server cloud administrative actions |
Determine whether the baseline of at least 14 days of platform usage exists for the user. If the baseline exists, calculate a baseline of activities, designated as SSC administrative. Trigger an alert if the users’ SSC actions exceed five times the number of average activities. |
|
| Access to crown jewel secrets | Detect if user accessed a secret designated as crown jewel. This rule will trigger every time a user accesses a secret that was defined as a crown jewel for your organization. To define crown jewel secrets, see Configuring Alert Settings. | |
| Suspicious platform action | Rule that tracks if a user performed actions on the platform that are considered suspicious |
Alert if any of the following actions performed by a user:
|
| User-Rare Secret Access | Detects if user used a secret that they rarely use | Per each secret accessed by a user, checks if that secret was used less than 5% of all users usage in platform. If yes, this triggers an alert. |
| Rare Secret Access in Tenant | Detects if a user accessed a secret reraly used in secret server | Per each secret accessed by a user, checks if that secret was rarely used in the tenants (less than 5% of all usage). If yes, this triggers an alert. |
|
Rapid brute force attempt |
Consecutive attempts were made to brute force an account |
Excessive login attempts were made from the same account within an hour. You can configure the minimum number of attempts. |
| Stealthy MFA bombing attempt | Multiple failed logins detected over a period of attempt, suggesting a stealthy brute force attempt |
Detect any of these events:
|
|
Account under MFA bombing attack |
Detects repeated MFA bombing attempts to access an account that requires MFA authentication |
Detected if there are multiple failed MFA bombing attempts detected on the same user account in a short period of time. Default is 1 hour, but can be configured with Alerts settings. See Configuring Alert Settings. |
| Stealthy brute force attempt | Detected multiple failed MFA bombing attempts over a period of time | Detects if multiple failed MFA attempts where made to the user accounts, looking for failed attempts over a period of 7 days, and must match a count of at least 7 failed attempts. Both values are configurable in the alerts configuration. See Configuring Alert Settings. |
| Atypical travel | Detects atypical travel instances of the user |
Detect an atypical travel instance if:
|
| Inactive user performed an action | Triggered if a dormant account for at least 90 days performed an activity |
Per each non enabled account, we search for actions that occurred after a period of 90 days or more of inactivity, meaning in this time period, the system did not record any activity for the user. |
| Suspicious login attempt to disabled accounts | Triggered if a login attempt was made into a disabled account | Triggered if a login attempt was made, per each disabled user in the platform. |
