OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Intelworks uses a "type" field and their JSON based STIX is pretty neat.  And when we did JSON based TAXII we also put in a "message_type".  That simple element really made things easier.  

Here is an example of TAXII JSON Poll messages
https://github.com/freetaxii/libtaxii/tree/master/messages/pollMessage



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Nov 2, 2015, at 09:39, Wunder, John A. <jwunder@mitre.org> wrote:

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



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]