Re: [cti-cybox] CybOX 3.0: Address Object Refactoring

["Wunder, John A." <jwunder@mitre.org>]

Yeah I’m really not sure. I expect whatever we’re using to create the model (UML, RDF) should allow for a “choice” type construct, meaning you wouldn’t need the parent class. I know XML Schema and JSON Schema do this, not sure about whether RDF/JSON-LD do (or, if they do it, how they do it).

It seems to me like even if we don’t use JSON-LD we’ll need a field like “type” to indicate which type of object you’re using. Otherwise the consumers would need to infer it from the set of fields (assuming that’s even possible, which it might not be). For example, on a STIX indicator:

{
  “title”: “Indicator”,
  “pattern”: {
    “operator”: “OR”,
    “objects”: [
      {
        “ip_address”: “1.2.3.4/32”
      }
    ]
  }
]

(vs)

{
  “title”: “Indicator”,
  “pattern”: {
    “operator”: “OR”,
    “objects”: [
      {
        “type”: “ipv4-addr"
        “ip_address”: “1.2.3.4/32”
      }
    ]
  }
]

Obviously in some places where objects are used within other objects it will be deterministic, but that won’t be universal.

John

> On Nov 2, 2015, at 10:28 AM, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:
> 
> Yeah, that’s a good point - making a field optional has the potential for bifurcation of CybOX content, which is one of the issues we’re trying to address with CybOX 3.0! I also think that having a mandatory “version” or “type" field isn’t a terrible thing, so I’m preferential towards option 2 as well. 
> 
> 
> The JSON-LD aspect of this is interesting; I think if we do go down that road, than the specificity of the “@type” field would be useful. However, not sure what this means for the JSON schema/serialized data model, especially for fields where either an IPv4 or IPv6 address is permitted - is it possible to specify an OR between an “ipv4-addr-object” and “ipv6-addr-object”, or would we still need some sort of higher level “ip-addr-object” abstraction?
> 
> Regards,
> Ivan
> 
> 
> 
> 
> On 11/2/15, 10:21 AM, "cti-cybox@lists.oasis-open.org on behalf of John Anderson" <cti-cybox@lists.oasis-open.org on behalf of janderson@soltra.com> wrote:
> 
>> +1 for using a "type" rather than "version" field. "Version" is widely used for other purposes, and what we're really identifying is a type anyway.
>> 
>> And, I kinda like using the JSON-LD "@type", too, if only because it leads us one step closer to "@context", which is really the killer feature of JSON-LD.
>> JSA
>> 
>> ________________________________________
>> From: cti-cybox@lists.oasis-open.org <cti-cybox@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
>> Sent: Monday, November 2, 2015 10:17 AM
>> To: cti-cybox@lists.oasis-open.org
>> Subject: Re: [cti-cybox] CybOX 3.0: Address Object Refactoring
>> 
>> I prefer option 2, with the version field required. I don’t really see it as being more complicated to construct and parse…yes, it’s an extra field, but you can always count on the IP address being in the same field. I don’t have to do an existence check for an ipv4_address key and an ipv6_address key in order to parse it, I just always check the ip_address field for the address and the version field for the version.
>> 
>> I don’t really like the version field ever being optional. I just don’t see a strong enough use case to want to omit it…it’ll bifurcate the ecosystem (can consumers assume it will be there for an unknown producer?) for a gain of a few bytes here and there. If we’re at that point, we can consider a binary protocol that will compress away that field anyway.
>> 
>> Will this be impacted by whatever mechanism we use to identify which type of object we’re describing? Will we have that mechanism?
>> 
>> E.g., if we use a “@type” field (from JSON-LD, kind of like xsi:type) you would have:
>> 
>> {
>> “@type”: “ipv4-addr-object”
>> “ip_address”: “1.2.3.4/32”
>> }
>> 
>> In that case, the version isn’t necessary because it’s encoded in the name of the object. But I’m not sure how we’re planning to have that work in CybOX 3.0 or the eventual serialization.
>> 
>> John
>> 
>>> On Nov 2, 2015, at 10:00 AM, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:
>>> 
>>> Trey is correct - my main point regarding the MITRE python libraries is that they are the de-facto CTI implementation used today, like it or not. If we want to reasonably maintain them going forward, I think it’s in our best interest to have their focus be on the deserialization/serialization of the language data structures, and leave other capabilities (e.g., validation) for others to focus on.
>>> 
>>> Anyhow, I think we’re diverging a bit from the main topic at hand, on the capture of IP addresses in CybOX.
>>> 
>>> I think there are currently three views on how best to do this:
>>> 
>>> Option 1: hybrid
>>> 
>>> {
>>> "ipv4_address" : "192.168.1.1/32"
>>> }
>>> 
>>> 
>>> + Simple (IP version encoded in field name)
>>> - Ontologically awkward (the IP Address Object is composed of the IPv4/IPv6 Address Objects, instead of those Objects being an extension of the IP Address Object)
>>> 
>>> Option 2: base + derived types
>>> 
>>> {
>>> "ip_address" : "192.168.1.1/32",
>>> "version" : "ipv4"
>>> }
>>> 
>>> + Ontologically correct (the IPv4/IPv6 Address extend from the IP Address Object)
>>> - More complicated to construct/parse (requires handling of the extra “version” field)
>>> 
>>> Option 3: single IP address type
>>> 
>>> {
>>> "ip_address" : "192.168.1.1/32",
>>> }
>>> 
>>> + Simple (one type, no separate IPv4/IPv6 constructs)
>>> 
>>> - Requires consumer to identify version
>>> 
>>> As you can see, each has its benefits and drawbacks. However, I do think Option 3 is less suitable than the rest because there are places in the data model (Objects) where we want to explicitly constrain fields to specific IP address versions.
>>> 
>>> As an alternative, I’m wondering if it would make sense to have a variant of Option 2 the “version” field optional on the broader IP Address Object, and required on the IPv4 Address and IPv6 Address Objects. That way, producers/consumers interested in sharing any type of IP Address don’t need to be encumbered with an additional field, while we still get the semantic accuracy we need in some of the Objects:
>>> 
>>> {
>>> "ip_address" : "192.168.1.1/32",
>>> }
>>> 
>>> 
>>> (a notional example from the Network Packet Object)
>>> {
>>> “src_ipv4_addr" : {"ip_address" : "192.168.1.1/32”, “version” : “ipv4”},
>>> }
>>> 
>>> Any thoughts on this?
>>> 
>>> Regards,
>>> Ivan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 10/30/15, 6:00 AM, "Trey Darley" <trey@soltra.com> wrote:
>>> 
>>>> On 29.10.2015 21:44:03, Jordan, Bret wrote:
>>>>> Validation needs to happen at the consumer side, as you can never
>>>>> guarantee that it has happened at the producer side. To complicate
>>>>> matters the producer may make best effort to validate it, but the
>>>>> data may get messed up in transit, either intentionally or
>>>>> unintentionally.
>>>>> 
>>>> 
>>>> Agreed, that's basically just a paraphrase of what I stated in my
>>>> previous mail. :-)
>>>> 
>>>>> 
>>>>> Further people talk about the python-cybox libraries as if they were
>>>>> some sort of canonized gospel. If we succeed and get across the
>>>>> chasm, we need to realize that our little baby will be spoken in
>>>>> just about every programming language there is. So we can not rely
>>>>> on the fact that some thing is or is not in the python libraries.
>>>>> 
>>>> 
>>>> I'm very much aware of the fact that Python is not universal.
>>>> Personally, I code in several languages, Python amongst them. To
>>>> debate the merits of programming languages is like debating emacs
>>>> versus vi; to wit, pointless discussion.
>>>> 
>>>> It is a fact that Python is one of the dominant languages used in
>>>> infosec and is widely grokked within the wider developer community.
>>>> The MITRE reference implementations could have been written in any
>>>> other language. Python wasn't the only choice but it definitely was a
>>>> *good* choice. (I'm looking at you, Haskell!)
>>>> 
>>>> I would argue vehemently that we would *not* be where we are today in
>>>> terms of standards uptake if the MITRE reference implementations did
>>>> not exist.
>>>> 
>>>> Say I'm a new vendor just entering the space. I can leverage the
>>>> reference implementations to run a quick PoC. Then, as I'm writing my
>>>> own {Ruby, PHP, C++, OCaml, Rust...} libraries, I can leverage the
>>>> reference implementations to sanity-check the interoperability of my
>>>> own implementation.
>>>> 
>>>> QED, I think we should maintain them going forward.
>>>> 
>>>> The fact that I was discussing how validation ought to work in a
>>>> future revision of the MITRE reference implementations was not in any
>>>> way intended to privilege Python nor to convey a bias against
>>>> implementers working in other programming languages.
>>>> 
>>>>> 
>>>>> This is also why the statements about not needing to worry about
>>>>> serialization "as it is taken care of in a library" are false.
>>>>> 
>>>> 
>>>> By 'serialization' are you referring to data validation? The crux of
>>>> my argument was that it is *clearly* in the best interest of all
>>>> producers and consumers to perform validation. The mention of MITRE's
>>>> reference implementation was a sidebar, in no way intended to
>>>> undermine the criticality of validation.
>>>> 
>>>> I just don't think it makes any more sense to carve into the OASIS CTI
>>>> standards "You must perform validation" than it makes sense to
>>>> promulgate a law saying, "You must treat people respectfully."
>>>> Producers and consumers will perform data validation for the same
>>>> reason that treating others respectfully has become the societal norm:
>>>> because it is ultimately in all our best interest to do so.
>>>> 
>>>> --
>>>> 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
>>>> --
>>>> "It is always possible to add another level of indirection." --RFC 1925
>> 
>> 
>> ---------------------------------------------------------------------
>> 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 
>>