New event to represent risk level changes

[appsdesh]

Context

A software vendor may deploy mechanisms to gather and analyze various signals associated with subjects such as users, devices, etc. These signals, which can originate from diverse channels and methods beyond the scope of this event description, are processed to derive an abstracted risk level representing the subject's current threat status.

The risk-level-change event is employed to communicate any modifications in a subject's assessed risk level between trusted entities. This event indicates whether the risk level has increased, decreased, or remained unchanged since the last assessment.

Example Scenarios:

• Device Risk Assessment - A transmitter initially determines a device's risk-free status, assigning a LOW risk level. During a routine health scan, new software is detected. If the vendor assesses this software as legitimate but unauthorized, the risk level may be adjusted from LOW to MEDIUM. Conversely, if the software is identified as malicious and harmful, the risk level may be elevated from LOW to HIGH.
  This event could be used in addition to the device-compliance-change when risk determination may/may not affect compliance policies.
• User Risk Assessment - If multiple failed login attempts are detected, the user's risk level may increase to MEDIUM. Should it be discovered that the user’s password has been compromised, the risk may escalate to HIGH. Conversely, if the user subsequently resets their password and adopts high-assurance authentication methods, the risk level might be reduced.
  This event could complement events like session-revoked. It could also help drive softer remediations by prompting for MFA, quarantining users, etc.
• Tenant Risk Assessment - A tenant is under DDoS or has experienced a similar attack. The vendor wants to share this information with other entities.

Vendors may decide to ingest risks from various sources/providers, add weights to the risks calculated, and make their own policy determinations. The nonprescriptive nature of this event helps communicate the change in posture for the subject and leaves out the actions.

Risk Level Classification:

The transmitter may utilize numeric ranges to categorize risk levels into predefined buckets such as LOW, MEDIUM, or HIGH. This classification helps in standardizing the risk communication and facilitating consistent risk management across different systems.

Event-Specific Claims

1. current_level - REQUIRED, JSON string indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH
2. previous_level - OPTIONAL, JSON string indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.
3. ips - OPTIONAL, The array of IP addresses of the subject as observed by the Transmitter. The value MUST be in the format of an array of strings, each one of which represents the RFC 4001 [RFC4001] string representation of an IP address. (NOTE, this can be different from the one observed by the Receiver for the same user because of network translation)

{
   "iss":"https://idp.example.com/3456789/",
   "jti":"07efd930f0977e4fcc1149a733ce7f78",
   "iat":1615305159,
   "aud":"https://sp.example2.net/caep",
   "events":{
      "https://schemas.openid.net/secevent/caep/event-type/risk-level-change":{
         "subject":{
            "user":{
               "format":"iss_sub",
               "iss":"https://idp.example.com/3456789/",
               "sub":"[email protected]"
            }
         },
         "current_level":"LOW",
         "previous_level":"HIGH",
         "ips":[
            "98.87.234.76"
         ],
         "event_timestamp":1615304991643,
         "reason_admin":{
            "en":"User's password detected in the pwned password dump"
         }
      }
   }
}

Why CAEP event?

• Introducing a new profile will be a slow process
• CAEP has accommodated events that are not directly related to the session eg. device-compliance-change
• Explore machine reachable approach to event definitions #158 proposes all the events to be in the JSON dictionary format, rather than in the spec. In the future, all the CAEP, RISC events could be converted to the JSON dictionaries. A use case could be conceptualized by creating profiles of the events.
• RISC profile is user account centric. This event is generic and could be applied to any subject

[deshmukhrajvardhan]

As it's not an active session-related event but Identity (user, device, etc.) related one, would RISC be a better place to have that event?

[iamseanodentity]

We discussed this previously, @FragLegs and @atultulshi by adding in a risk indicator into session presented / session established CAEP Events and we discussed pulling this out into, possibly, its own event type. Is this the follow up to that discussion? If so, the main take away was what is the risk and how does company A classify it versus company B.

[appsdesh]

This event helps make risk-level communication generic for various subjects, as noted in the examples. The risk aspect is going to be subjective, but it's still very prevalent in the industry. The reason_admin can help provide more guidance on the rationale behind the risk levels.