All,
Trey and I are pleased to say that the CybOX specifications have been tweaked and updated (we have LOTS of examples now) for review. There are still a few open questions, as documented below. Besides those questions, we encourage you to look through the text for consistency, accuracy, and general sensibility. Monday morning Trey and I will send out a plan and working session schedule for resolving these questions and putting the final touches on the specs.
· CybOX Core: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit
o Q: Should we support/document extension hierarchies even though they’re not currently used? If so, is there another way to achieve the desired effect without defining a hierarchy of extensions?
o Q: How should encoding metadata be captured, if at all? Our current methodology doesn’t account for list and dictionary types, only basic fields of type string.
· CybOX Network Objects: https://docs.google.com/document/d/1oPAHN6nitdVF60RuDlajq0VuN6S_p_RP3ZE48yOBBfQ/edit#heading=h.ewxs2sk1slva
o Q: For the Network Connection Object, should Network Flow be a type instead of an extension, since theoretically every network connection involves transmission of bytes/packets?
· CybOX Host-based Objects: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.ewxs2sk1slva
o Q: Should we always be consistent in how we represent file paths, i.e. using the same delimiter/string list methodology as in the File Path Type?
· CybOX Patterning: https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit#heading=h.t32x0azc539r
Thanks again to everyone who has helped out with these specs these past few weeks – this has been a huge undertaking, and we couldn’t have done it without you.
Regards,
Ivan and Trey
Dave Cridland
Participate | Collaborate | Innovate