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

[John Anderson <janderson@soltra.com>]

Ivan,
I think I like where you're going. Could you clarify one question? In your example, you include a "/32" suffix. Doesn't that make the value a CIDR, rather than a single IP Address? If so, then does that require the consumer to parse the value anyway?
JSA

________________________________________
From: Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, November 2, 2015 10:00 AM
To: Trey Darley; Jordan, Bret
Cc: Jerome Athias; John Anderson; Barnum, Sean D.; Wunder, John A.; Davidson II, Mark S; Terry MacDonald; cti-cybox@lists.oasis-open.org
Subject: Re: [cti-cybox] CybOX 3.0: Address Object Refactoring

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