Open appsdesh opened 1 week ago
The members of a Complex Subject are all Simple Subjects. I think what we need is a new Simple Subject instead of a new Complex Subject field.
So a new IPs Simple Subject like
{
"format": "ips",
"ips": ["1.2.3.4", "2001:0000:130F:0000:0000:09C0:876A:130B"]
}
And then we could have a Complex Subject whose user field is that value, like
{
"format": "complex",
"user": {
"format": "ips",
"ips": ["1.2.3.4", "2001:0000:130F:0000:0000:09C0:876A:130B"]
}
}
@FragLegs - I am thinking more of declaring IPs as a first-class complex subject members along with existing user
, device
, session
, application
, tenant
, org_unit
, group
.
With that, the simple subject would be -
{
"format": "opaque",
"ips": ["1.2.3.4", "2001:0000:130F:0000:0000:09C0:876A:130B"]
}
Complex would be -
{
"format": "complex",
"ips": {
"format": "opaque",
"ips": ["1.2.3.4", "2001:0000:130F:0000:0000:09C0:876A:130B"]
}
}
If you are thinking of declaring ips
as a format
then we would need to go via adding it in Security Events Identifiers Formats
I believe, that would need to be done outside SSWG
We have added two Simple Subject formats in the Shared Signals spec already: jwt_id and saml_assertion_id. So this would simply be a third one.
The opaque
format doesn't work quite like you are suggesting above. It takes two fields, format
and id
:
{
"format": "opaque",
"id": <must be a string>
}
not format
and ips
:
{
"format": "opaque",
"ips": <list of strings>
}
As we are seeing the need for communicating IPs in more events, this issue proposes a list of IPs as a new Complex Subject Member member.
The following events have IPs as members
Please refer call notes from 9/10 for more context. cc: @FragLegs @iamseanodentity