I'm currently working on developing insider threat detection rules and would appreciate your insights on implementing a specific use case that involves cumulative risk scoring over time.

1. Current Rule

First, here is my current YARA-L rule. This rule detects successful Microsoft Entra ID (Azure AD) user logins occurring during non-business hours in JST (22:00 JST - 06:00 JST).

rule Sample {
  meta:
    description = "Sample"
    severity = "MEDIUM"

  events:
    $e.metadata.log_type = "AZURE_AD"
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "ALLOW"
    $ts = $e.metadata.event_timestamp.seconds
    // UTC 13:00-20:59 corresponds to JST 22:00-05:59
    timestamp.get_hour($ts) >= 13
    timestamp.get_hour($ts) < 21

  outcome:
    // Currently, a fixed risk score of 50 is assigned when an event is detected.
    $risk_score = 50

  condition:
    $e
}

2. Desired Requirement

I'd like to evolve this rule to implement the following logic for alert generation:

• Detect logins during specific hours: Triggered when a specific user logs in during a particular time slot (e.g., JST 23:00).
  • (While the current rule targets JST 22:00-06:00, we can narrow this down further if needed.)
• Cumulative risk scoring based on repetition:
  • Add 10 risk points for each detected login.
  • This risk score should ideally be accumulated per user over a long period (e.g., days, weeks, or even months).
• Alert based on threshold:
  • An alert should be triggered when a user's accumulated risk score reaches 50 points (i.e., after 5 such logins).

Example Scenario:

• Aug 1, 23:00 JST Login ⇒ Risk Score 10
• Aug 3, 23:10 JST Login ⇒ Risk Score 20
• Aug 12, 23:10 JST Login ⇒ Risk Score 30
• Aug 15, 23:20 JST Login ⇒ Risk Score 40
• Aug 20, 23:10 JST Login ⇒ Risk Score 50 ⇒ Alert Triggered

In a worst-case scenario, if explicit risk score accumulation isn't directly possible, we would still like to know if we can generate alerts based on long-term trends (e.g., "5 or more logins during JST 23:00 within the last 30 days") for a specific user.

3. Questions

Regarding the requirements above, is this achievable within Google SecOps (Chronicle SIEM)?

 If achievable: Any tips on implementation or best practices would be greatly appreciated.

Thank you for your time and assistance. Any guidance would be very helpful.