Open c-x opened 9 years ago
I also concur – there are too many overlapping Objects at this point. Some of these we’ve known about and have intended to fix (e.g., the AddressObject and AS Object can both capture AS names), while others were created for specific use cases (e.g., DNS Cache and DNS Query). This will require some analysis by ourselves and the CybOX community, but my hope is that we can eliminate any true redundancies while also retaining the ability to target the use cases that some of the Objects were initially created for.
Suggest we adopt Atomic level DNS Objects to represent standards based types (https://en.wikipedia.org/wiki/List_of_DNS_record_types). Note that RRI Extensions have been used (very successfully) by APT Actors to embed Covert C2 and Exfiltration Channels in DNS Traffic so we need some form of representing these non-normative extensions as well.
I would like to see the AddressObject and HostnameObject merged into one "AddressObject" that can be either an address or a host.
I have seen too many watch lists that contain a mixture of IP addresses and hostnames to be convinced they should be forced to be treated separately. It should be up to the person creating the report, and if you have them in one object, then they can either split them into two indicators, or keep them in one mixed list, depending on the use case.
Jason are you saying we should treat bad-thing.bad-guys.com the same as 1.2.3.4?
Patrick Maroney Cell: (609)841-5104
On Aug 6, 2015, at 10:27 AM, JasonKeirstead notifications@github.com wrote:
I would like to see the AddressObject and HostnameObject merged into one "AddressObject" that can be either an address or a host.
I have seen too many watch lists that contain a mixture of IP addresses and hostnames to be convinced they should be forced to be treated separately. It should be up to the person creating the report, and if you have them in one object, then they can either split them into two indicators, or keep them in one mixed list, depending on the use case.
— Reply to this email directly or view it on GitHub.
@packet-rat Yes, I am saying that an AddressObject should be allowed to contain host names, because for most use cases they are interchangeable and you want to create one piece of "logic" or "description" for the list of data that contains both.
For use cases where they are not interchangeable, it is trivial for the creator of the report to separate them.
As a bonus, doing this would make CybOX more consistent with most modern programming languages, where these objects are for the most part interchangeable .
@JasonKeirstead I understand where you're coming from, but hostnames and IP addresses are semantically different concepts, so merging them into a single abstract Address Object would go against our goal of having unambiguous representations of cyber observables. Also, while they may be functionally the same to consumers of watchlists, this is but one use case we're trying to meet, and there are certainly cases where we need to clearly distinguish between them (e.g. for capturing DNS resolutions).
@ikiril01 Shouldn't it be up to the creator of the report if the data needs to be distinguished or not? if it needs to be distinguished, they will separate it into two lists.
DNS records has it's own set of objects - I am not trying to group hostnames with DNS records, those are different.
+1 with @ikiril01
Having "generic objects" or "meta objects" could maybe answer that. The idea would be to have objects which are composed of atomic objects only. I'm clearly not familiar with the references objects and alike, but it sounds similar to list objects described in ticket #380 .
@JasonKeirstead could you gives us an example or be more specific on the use case to solve please?
@JasonKeirstead I don't think distinguishing such things via lists is an elegant solution, as it adds another meta layer of semantics that producers and consumers potentially have to deal with; it should really be done at the Object level. As far as DNS, one of the fundamental concepts in DNS is the resolution of hostnames to IP addresses. Modeling the resolution as relationship, with your proposal we'd have Address --(resolves to)--> Address
, which in my mind is ambiguous. My thinking is that it would clearer to have well defined atomic Objects, in this case say an IPv4 Address and a Hostname. Thus, we'd have Hostname --(resolves to)--> IPv4 Address
.
Another problem is that we can describe the same information with different objects. If we keep the previous example of the e-mail, to define an email address we can at least choose between an EmailMessageObject or an AddressObject.
This is even more complicated with DNS related objects: HostnameObject, AddressObject, DomainNameObject, DNSCacheObject, DNSQueryObject, DNSRecordObject, etc.