Rule body yaml
AnalysisType: rule
Filename: onelogin_login.py
RuleID: "OneLogin.Login"
DisplayName: "Signal - OneLogin Login"
Enabled: true
CreateAlert: false
LogTypes:
- OneLogin.Events
Tags:
- OneLogin
Severity: Info
Description: A OneLogin user successfully logged in.
Reference: https://resources.onelogin.com/OneLogin_RiskBasedAuthentication-WP-v5.pdf
Tests:
- Name: Successful Login Event
ExpectedResult: true
Log:
{
"event_type_id": "5",
"actor_user_id": 123456,
"actor_user_name": "Bob Cat",
"user_id": 123456,
"user_name": "Bob Cat",
}
- Name: Failed Login Event
ExpectedResult: false
Log:
{
"event_type_id": "6",
"actor_user_id": 123456,
"actor_user_name": "Bob Cat",
"user_id": 123456,
"user_name": "Bob Cat",
}
Detection logic
Condition
event_type_id eq "5"
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
event_type_id | eq |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field |
|---|
user_name |