Yup, it’s just the number, along with some data that you can glean from the RIR [1]. The primary impetus for having it as a separate Object was for cases where you may want to share information about malicious AS’s without additional context. If we feel
that this isn’t a likelihood (or useful), I’m fine with excluding it and implementing it as a number in the Network Connection.
Regards,
Ivan
What would be in the AS object?
AS is a number with a defined enum, why do we need an object to communicate a number? Should STIX copy data from APNIC and RIPE...., why would we...
Sent from IBM Verse
Kirillov, Ivan A. --- Re: [cti-cybox] CybOX Object Selection ---
Going through the “green-field” list again (BTW Rich Piazza added a column highlighting the relative complexity of each Object via its number of UML classes/enums), I think it might be reasonable to also include the following objects:
* AS - well understood and likely to be used in the updated Network Connection Object (source/destination ASN). * x509 Certificate - well understood and supported via the x509 to CybOX utility [1]
[1] https://github.com/CybOXProject/x509-to-cybox
Regards, Ivan
On 2/3/16, 8:19 AM, "Kirillov, Ivan A." <ikirillov@mitre.org> wrote:
>I think that makes great sense, Trey. > >On the point release front, we’d love any input to help us plan out this roadmap - which objects/object classes would you like to see us address first? I know that Terry is keen on the web forum post object/credential dump object, as an example. > >Oh, and if we do envision using these Object subsets/classes as a means for producers/consumers to declare their particular facet of CybOX support, it seems like this is a topic for the interoperability SC. > >Regards, >Ivan > > > > >On 2/3/16, 4:31 AM, "Trey Darley" <cti-cybox@lists.oasis-open.org on behalf of trey@soltra.com> wrote: > >>On 02.02.2016 13:44:00, Jason Keirstead wrote: >>> ". Maybe what we really need is a “malware analysis” subset, a “digital >>> forensics” subset, etc." >>> >>> Yep that is what I am saying I suppose. >>> >>> Cybox Base >>> Cybox Network >>> Cybox Digital Forensics >>> Cybox Malware >>> >>> That way a product can more easily specify what they support. And, >>> people looking for products can more easily align expectations. >>> >> >>Hey, Jason - >> >>This is precisely the approach Ivan and I intend to pursue in point >>releases to 3.0. The idea for 3.0 is, let's get the core CybOX >>abstract type definitions right and refactor the set of core MVP >>Observable types selected. Then, say, for 3.1, we as a community >>decide to prioritize the digital forensics domain. So we'll pull >>together a constituency of subject matter experts to guide the >>creation / refactoring of additional Observable types focused on >>digital forensics use cases. >> >>In parallel to the ongoing 3.0 effort, I'd like to see us: >> >>0) Assemble a list of use case categories a la: >> >> * network >> * digital forensics >> * malware analysis >> * mobile >> * virtualization >> * ... >> >>1) Prioritize that list to produce a point release roadmap. >> >>2) Work to identify subject matter experts to guide those discussions, >> reach out, get them on board, and execute the timeline. >> >>Thoughts? >> >>-- >>Cheers, >>Trey >>-- >>Trey Darley >>Senior Security Engineer >>4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 >>Soltra | An FS-ISAC & DTCC Company >>www.soltra.com >>-- >>"For all resources, whatever it is, you need more." --RFC 1925
|