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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] Re: Location in 2.0


I agree with Bret. My preference is location as a field within an existing SDO.

 

Before supporting the creation of an SDO I ask myself, “is there another standard that does this better? If so, I am going to reference/use/point to that standard instead”. I would have us take a look at other standards before creating a new SDO for location.

 

Also, adding SDOs does not necessarily reduce complexity. In most cases, even when I support the creation of an SDO, I do so while “flinching”.

 

 

Aharon

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Thursday, October 13, 2016 at 5:47 PM
To: "Katz, Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil>, Allan Thomson <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Location in 2.0

 

Personally I feel like we constantly flirt with this line in the sand of making every field in the data model its own object with relationships linking it back.  I also worry about, how do we actually build a location object and what goes in it?  It will not be a simple straight forward debate.  I am guessing that it is about a 3 month debate to get right.  

 

As the email archives can attest, I am generally in favor of a flatter, simpler design.  

 

Bret


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Katz, Gary CTR DC3\DCCI <Gary.Katz.ctr@dc3.mil>
Sent: Thursday, October 13, 2016 3:19:06 PM
To: 'Wunder, John A.'; cti-stix@lists.oasis-open.org
Subject: [cti-stix] RE: Location in 2.0

 

I'm not sure I completely agree with moving location to a separate SDO.  We just got done a meeting where analysts were requesting that location information, such as Geo IP data was attached to the IP and not a separate object.  Now this may be just how we display it rather than how it is held in STIX, but it's something to consider.  (Note: when we are attaching a geolocation to an IP we are including the date at which it resolved)

Either way, the below location information is pretty useful stuff.  Knowing that an intrusion set is associated with nation state A vs. nation state B is fairly important.  Same thing for an identity. 

-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Thursday, October 13, 2016 5:00 PM
To: cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] [cti-stix] Location in 2.0

All,

 

One of the issues that Allan brought up at the last face-to-face is that location information might be better encoded as a separate SDO rather than as fields on the existing SDOs. Given that, how should we address location attributes in 2.0?

 

IMO, given that we want to discuss this in 2.1, for 2.0 we should remove location attributes from STIX (for now). That would keep us from breaking things in a future version and would mean removing the following fields:

 

Identity:

-          Regions

-          Nationalities

 

Intrusion Set:

-          Region

-          Country

 

Any objections to this? It would let us get 2.0 out and then work on location for 2.1.

 

Thanks,

John



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