(Apoorva) - Proposal of a generic way of communicating risk to different parties
Sub could be user, device tennant.
was a topic to put in RISC vs CAEP…Keep in in CAEP.
Is this going to be generic or specific.
(Stan) - What is going to measure this risk event or define the criteria for it to happen?
(Apoorva) - Different companies or systems factor in "risk" and is very subjective
(Stan) - There might be confusion in this case with the subjectivity and different levels or risk. If bucketed under this event there can be discrepancies between vendors and "relative risk".
(Stan) - We should consider this Risk event to be more agnostic between vendors. When to act vs when not to.
How would the vendors accept it.
(Apoorva) - getting to a common ground might be subjective.
using "admin_reason" could be a way to be more discreet about the subjectivity. But the goal was to be subjective / abstract to cover use cases.
this is very similar to "claims changed event" in CAEP
(Stan) - Tx sends event of what happened and here it is sent to the Rx.
The name is going be confusing with RISC spec as it has "risk" in it. Ensure that it is clear in the name between the RISC spec and event name in the CAEP Spec. Suggestion is for a better name to avoid confusion.
(Sean) - Used internally by some companies, but has a lot of value and was proposed in the latest 2 caep events
(Shayne) - Risk of what? what is the Risk
(Apoorva) - Subjectivity is key but coming up with the enums will be difficult
(Shayne) - Do we want risk of "x" events?
(Stan) - be more specific
(Shayne) - Do we want events for each type of risk vs parsing from a text string in "admin_reason". If it is general..something has happened might be more precise
(Steve) - This convo might lead to an enumerated type or a risk registry.
(Sean) - Wait for the registry the risk were too big to enumerate
(Apoorva) - We need a container to communicate
If you think an enum would work…that could work
Adding one event per type may not scale (opinion)
(Shayne) - Differentiation of metadata per event per type might matter. Downloading something with a virus versus cred was pwned.
(Stan) - Metadata is a way that could help, from the POV of the Rx. The Rx will need context of the metadata/dictionary and a common dictionary.
To help the implementers we could create 3 or 4 events.
(Apoorva) - What is important to Steve vs Jen vs Harry might differ
(Stan) - Lets see if we can get to those 3 events for the implemented
(Apoorva) - There could be risk events that would be hard to enumerate… 15+
(Stan) - Start with the most common to tackle?
(Apoorva) - Defining just another event might flood the network.
(Stan) - There might be too many feeds and types of risk that are sent that you risk a signal to noise ratio being too high. The Tx might need to use the common taxonomy to put the data in the feed.
(Shayne) - This might be a new profile of events. Might be a generic risk event but not specific and expand the specifics as we need to.
(Apoorva) - Moving to dictionaries versus profiles (as indicated in Issue 200)
Confusion for new implementers on which one to use. How do we avoid the confusion in the future?
(Raj) - This seems like a stop gap until the JSON Registry is up and running.
(Apoorva) - This is a need that we see, Okta, and there is a demand for it
(Shayne) - What risks are you communicating?
(Apoorva) - Every provider has different types of Risk and the bigger spectrum.
(Shayne) - You have a list of IP's in the data here. He complained about it in the session established event and will do so here. Maybe introduce a new subject type
(Sean) - Previous context versus current…is that your intent?
(Apoorva) - Same guidelines as claims changed event.
(Shayne) - Device, Tenant and User Risk. How would you interpret the risk based on the subjects identified?
(Apoorva) - Means to feed data that is abnormal and reactivate infrastructure
(Shayne) - The subject is used to identify the risk, ok.
(Apoorva) - It can be a mixture of both
(Stan) - We should keep account level subjects risk to the RISC Spec, not CAEP
(Stan) - Some vendors can have high low medium without sending any data (so minimal to no metadata)
(Apoorva) - Should not have to restrict anything as the profiles might become moot with a dictionary/schema
-When we are accepting the events the "reason_admin" it should/would be implemented as mandatory.
(Shayne) - Isn't "reason_admin" optional? We all think so…Shayne is checking and it is called out as optional in the CAEP Profile.
Where are we at with the RISC Spec?
(Stan) - Where are we at with it to get to the next draft?
(Shayne) - They might go together
(Stan) - We have not worked on the RISC spec for a while and we maybe should?
At least consisency.
(Shayne) - Is there anything to review for the 2 new specs? Dont think there is.
(Stan) - Agrees.
(Sean) - We need the schema/dictionary sooner rather than later
(Stan) - agrees
(Apoorva) - agrees
(Shayne) -agrees. Rather have schema/dictionary vs final review
Action Items
(Shayne) - Compile changes from ID2 to ID3 security analyses
(Apoorva via Shayne) - Add a new subject type in the SSF Spec. Apoorva is working on the Issue
(TBD) - Double check the RISC spec for consistency with CAEP (syntax)
(Jenn and Sean) - See about plausibility for review of the JSON Schema and applicability for the 2 profiles
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe