Atomic Runbook: Search User Login Activity in Chronicle#
ID: RB-ATOM-USER-002
Version: 1.0
Last_Updated: 2025-05-30
Purpose: To perform a detailed search for user login events (successful and failed) associated with a specific username in Chronicle SIEM using search_security_events
.
Parent_Runbook(s)/Protocol(s): rules-bank/indicator_handling_protocols.md#user-indicator
, rb_user_lookup_entity_chronicle.md
Trigger: When detailed login activity for a user is required, often after an initial entity lookup or if suspicious account behavior is suspected.
Inputs Required#
username
: string - The username to search for (e.g.,jdoe
,admin@example.com
).hours_back
(optional): integer - How many hours of historical data. Defaults to 72 (3 days).max_events
(optional): integer - Max event records. Defaults to 100.login_outcome_filter
(optional): string - Filter by login outcome [“Successful”, “Failed”, “Any”]. Defaults to “Any”.
Execution Steps#
Tool Selection:
Primary_Tool_MCP_Server:
secops-mcp
Primary_Tool_Name:
search_security_events
Query Construction (for
text
parameter):Base query: “Login events for user ‘{username}’”
Outcome filter:
If
login_outcome_filter
is “Successful”: Append “where outcome is ‘SUCCESSFUL_LOGIN’ or ‘ALLOW’” (UDMsecurity_result.action
can beALLOW
for successful logins).If
login_outcome_filter
is “Failed”: Append “where outcome is ‘FAILED_LOGIN’ or ‘BLOCK’” (UDMsecurity_result.action
can beBLOCK
for failed logins).
Append time window: “… in the last {hours_back} hours”
Example: “Login events for user ‘jdoe’ where outcome is ‘FAILED_LOGIN’ in the last 24 hours”
Parameter Mapping:
Map constructed query to
text
.Map
hours_back
,max_events
.
Execute Tool: Call
search_security_events
.AI Agent Note: UDM event types for logins can be
USER_LOGIN
or sometimesUSER_UNCATEGORIZED
with specific outcome details. The natural language query should handle this.
Data Transformation/Extraction:
Focus on
events.events
. Extractmetadata.event_timestamp
,principal.user.userid
,principal.hostname
(source of login),target.hostname
(target system),src.ip
,security_result.action
,security_result.description
.
Outputs Expected#
login_events
: list - List of UDM login event records.translated_udm_query
: string.total_events_matched
: integer.source_ips_logins
: list - Uniquesrc.ip
from login events.target_systems_logins
: list - Uniquetarget.hostname
from login events.output_status
: string - [“Success”, “NoEventsFound”, “Failure”]output_message
: string (if Failure).
Decision Logic / Next Steps (If Applicable)#
IF
output_status
is “Success”:Log key findings (e.g., number of successful/failed logins, unique source IPs, target systems).
Analyze for patterns: Logins from unusual geolocations/IPs (correlate source IPs with GTI), impossible travel, brute-force attempts (many fails then a success), logins to unexpected systems.
If suspicious patterns found, escalate or proceed to other runbooks (e.g., IP investigation for source IPs, process activity search for the user on target systems).
IF
output_status
is “NoEventsFound”:Log “No {login_outcome_filter} login events found for user {username} in Chronicle for the last {hours_back} hours.”
ELSE (
output_status
is “Failure”):Log error:
output_message
.Escalate: “Failed to search login events for user {username} in Chronicle.”
AI Agent Execution Notes#
The term for
security_result.action
(e.g.ALLOW
,BLOCK
) can vary by log source, so natural language queries are generally better here than trying to construct a precise UDM filter for outcome unless the exact UDM values are known for the target log sources.Correlate
source_ips_logins
withrb_ip_get_gti_report.md
if suspicious.
Metrics Collection Points#
Log execution time.
Log
output_status
, number oflogin_events
returned.(Reference
rules-bank/ai_performance_logging_requirements.md
)
References#
rules-bank/mcp_tool_best_practices.md
rules-bank/indicator_handling_protocols.md
(future User section)rules-bank/analytical_query_patterns.md
rules-bank/ai_performance_logging_requirements.md