Add Event family meta schema keyword and Discovery classes #1260
Conversation
Signed-off-by: Paul Agbabian <[email protected]>
…favor of an updated email_activity class. Updated the email object to include domains, files, urls arrays. Updated the email_activity class to add the message_trace_uid ID. Updated the email_activity class to use the references[] for the Trace activity_id instead of the description URL. Updated the email_activity class description to reflect its SMTP protocol and the possible URLs and files attachments. Signed-off-by: Paul Agbabian <[email protected]>
Signed-off-by: Paul Agbabian <[email protected]>
…on to fail!! Signed-off-by: Paul Agbabian <[email protected]>
…ed an at_least_one constraint on all the to and from attributes. Not all email logs have the 'to' and 'from' but must have at least those or 'smtp_to' and 'smtp_from' in the log. Signed-off-by: Paul Agbabian <[email protected]>
Signed-off-by: Paul Agbabian <[email protected]>
…egory. Updated the Discovery classes with their families of Query, Inventory, State. Signed-off-by: Paul Agbabian <[email protected]>
pagbabian-splunk
requested review from
floydtree,
Aniak5,
mikeradka,
zschmerber,
jonrau-at-queryai and
davemcatcisco
as code owners
Signed-off-by: Paul Agbabian <[email protected]>
Signed-off-by: Paul Agbabian <[email protected]>
|
I appreciate that classes in the Discovery category already have one of three suffixes on their name. However, I think the distinction between inventory, state, and query might in some cases be a little arbitrary or artificial. It is heavily dependent on how a given event is used by a product, and this can vary hugely from one product to another. For example, an endpoint product might enumerate running processes on startup and use So I guess in one respect I'm questioning if this change is actually going to help or hinder. For those for whom the chosen family aligns with their intended usage of the events, sure, it will help. But for those who see the foo event as an inventory instead of a state, the pre-determined sub-categorisation into distinct families that don't align with their usage is not helpful. If the community believes there is value to the family concept, I'm wondering if it should be families plural. It seems to me that an event could potentially belong to multiple families. |
pagbabian-splunk
added
metaschema
v1.4.0
|
Maybe we should resolve the root issues @pagbabian-splunk mentions directly rather than adding this family concept? I like the idea of renaming the classes to confirm to a common convention. I lean towards @davemcatcisco comment regarding arbitrary distinctions between query and inventory. It might be better to avoid re-enforcing this artificial distinction? Regarding the class ID's I'm not sure I have an issue with changing those ID values either. It would be a big change but might be worth it for the long term. |
|
We cannot change class IDs without being a breaking change. I'm all for proper naming of course, but there is a fundamental difference between |
|
It seems like this requires further discussion on a weekly call. I will add it to the agenda of the next call as it has been unresolved for a while now. I think all of the comments are valid, however they are over and above the simple enhancement here (i.e. visually collapsing related sets of event classes within a category). It is an artifact of Discovery today, but may also be needed when adding more protocols to Network (e.g. IoT protocols). The issues of state, vs. inventory, vs. query are still valid. If we move to 2.0 we might revisit how these are modeled, and/or we can recast them and deprecate what we have. |
floydtree
added
v1.5.0 or later
and removed
v1.4.0
|
Close for now - we may not need it for Discovery classes, or we might bring it in after the renaming of classes is done. |
Related Issue: #1261
Description of changes:
Added a new meta schema keyword to the framework,
family, so that related classes can be grouped together in the schema browser. In particular, we have many related classes in theDiscoverycategory that make it difficult to see what classes do what. Given they have been created a different times, they sort by their IDs and therefore the related_queryclasses and_infoclasses also don't sort together. Lastly, some of the classes don't conform to consistent suffixes, e.g.inventory_infois reallyDevice Inventory Info. This PR adds the information that will allow the browser to use the value of the keyword, e.g. the family nameQueryorInventory, to collapse the classes under the title matching the family name.Note
The
ocsf-validatorneed to support the newfamilyattribute. PR: ocsf/ocsf-validator#36