Yes, we should flatten flow information. A network connection is really just a flow that has end points and meta data about the content that goes over the flow.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Based on the good arguments everyone here (and those on Slack) has put forth, Trey and I have decided to flatten out the file-system-properties-type into the base set of properties for the File Object. We also have a similar issue under consideration for the Network Connection Object [1], namely should we merge the Network Flow extension into the base set of Network Connection Object properties? Based on the discussion during the last CybOX working session on this topic, there seemed be consensus that this is something we should do. Regards, Ivan Yep... It just does not makes sense for them to be treated as 'less important' properties. Lets just flatten them and make the properties optional. Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." Is a file-system-properties-type ever used anywhere other than as the value of file_system_properties? File-object is the only place it is used in the Host-based Objects document. Is there a reason that it was ever made into a nested type in the first place? I agree that the parent_directory_ref, file_name, file_name_enc, etc. properties should be flattened back into file-object. Yes
Sent from my Commodore 64
Right now in the File Object some of the properties are artificially nested. These properties deal with the file system aspects of a file. The argument is that not all files have these and thus it should be nested.
This IMHO, violates one of our core objectives of flatter is better than nested. I feel it would be better to have these fields be flattened and just made optional.
This is something we do throughout STIX and is part of our holistic design principles.
Bret
Sent from my Commodore 64
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|