Atomic vs. Abstract CybOX Objects

[c-x]

To my understanding, the only way to describe a MAC Address in CybOX is by using an AddressObject with the field category set to “mac”. This cover the definition of a MAC address, but it doesn’t tell me the format of the MAC address itself (is the separator a hyphen? a semicolon? none? dots?, are the characters grouped by 2 or 4? what’s the constructor associated with the first 3 bytes of the Mac? etc).

By extension, to update an atomic indicator over time seems easier than updating complex types like the AddressObject is today. For example, if we extend the AddressObject type for a full coverage of MAC Addresses, we probably have greater chances of side effects in the existing products, rather than if we were using a dedicated atomic object.

[ikiril01]

Completely agree. One of the main benefits of atomic Objects is that we can much more effectively constrain and therefore validate the data that is captured in the Object, which benefits both producers and consumers.

[packet-rat]

[+1] for Atomic MAC addresses, would also suggest we adopt a standards based default format (with ability to override by passing a different representation through regX,etc if absolutely required by anyone who can't agree on form),

One follow-on: we should probably accommodate Vendor Ethernet Prefixes. I've experienced same as actionable intelligence with some nasty APT adversaries operating at Layer 1/2 of Ethernet...rare but perhaps just cause we aren't looking 😁

Patrick Maroney (609)841-5104

On Aug 5, 2015, at 5:27 PM, Ivan Kirillov notifications@github.com wrote:

Completely agree. One of the main benefits of atomic Objects is that we can much more effectively constrain and therefore validate the data that is captured in the Object, which benefits both producers and consumers.

— Reply to this email directly or view it on GitHub.

[ikiril01]

@packet-rat agreed, I think we'll have to settle on a default format for all Atomic Objects, if we go down this road. I think specifying the Vendor that a MAC Address prefix belongs to is an interesting idea - I think we'd probably want a separate field for this?

[ikiril01]

Some possibilities for new Atomic Objects (i.e. not including those that already exist, such as the Domain Name and Port):

• IPv4 Address [1]
• IPv6 Address [1]
• MAC Address [1]
• Email Address [1]
• ATM Address [1]
• URL [2]
• Hash

[1] In conjunction with the deprecation of the existing Address Object. [2] In conjunction with modification and potential deprecation of the existing URI Object.

[johnwunder]

:+1:

[MarkDavidson]

:+1:

[JasonKeirstead]

:+1: