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] FW: [cti] Location - precision, altitude, and administrative area


I think the question that we as a TC need to answer is do we want to encumber the implementation of our open and freely-available work with the necessity of purchasing other standards from other organizations? My sense, at least to date, is that our answer is no. But this is a conversation we should have as a TC.

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, July 28, 2017 at 11:08 AM
To: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

I’ve been looking in to this. I’ve asked Chet if there’s an ISO liaison to OASIS that I can work through or, if not, I’ll just reach out to ISO directly. In talking to Chet, OASIS’s perspective is that we’re free to reference ISO standards and it’s up to the organizations implementing our specifications to legally obtain and use the referenced specifications.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
Date: Friday, July 28, 2017 at 9:56 AM
To: John Wunder <jwunder@mitre.org>, "Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

Hi John,

 

On (1), Is OASIS looking into those lawyer type questions with ISO?

 

-Marlon

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Friday, July 28, 2017 8:52 AM
To: Masuoka, Ryusuke; Allan Thomson; Sarah Kelley; Terry MacDonald
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

Hi Ryu,

 

Thanks for the comments.

 

(1): We’re all in agreement that we should use ISO 3166-1 for country code. It’s in super common use across industry. We’re still not settled on the use of ISO-3166-2 for administrative area. It’s not in as much common use and, because it’s an ISO specification, we have the concern about whether it requires organizations buy the specification to implement it. I know most of the values are on Wikipedia, but is ISO OK with vendors using the values from Wikipedia without buying the specification? Are those values up to date given the amount of churn (at least in some countries) in administrative areas? I’d like to be able to use it, I’m just not sure we have a good answer to those questions yet.

 

(2): Yes, absolutely those values can be in other languages. Your example is correct, you’d add the “lang” attribute and that would denote that the human-oriented strings in the object are in Japanese.

 

John

 

From: "Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com>
Date: Friday, July 28, 2017 at 3:07 AM
To: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

Hi, John, All,

 

(1) As for country and administrative_area,

can we make it MUST (at least Should) to use the following?

 

ISO 3166-1 alpha-2 for country

  https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

ISO 3166-2 for administrative_area

  https://en.wikipedia.org/wiki/ISO_3166-2

 

  So it would be

  {

  country: US,

  administrative_area: US-MD,

  city: Annapolis Junction,

  street_address: 300 Sentinel Drive, Suites 500 & 600

}

 

(2) Is it okay to use a language other than English describing the address?

 

  If so, then my office address would be (lang: option is now optional,

so it may be without lang: field.)

 

  {

  lang: ja,

  country: JP,

  administrative_area: JP-13,

  city: 千代田区,

  street_address: 虎ノ門 2-10-1 虎ノ門ツインビルディング東棟 18

  }

 

  FYI, JP-13 is for Tokyo.

  https://en.wikipedia.org/wiki/ISO_3166-2:JP

 

Regards,

 

Ryu

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Friday, July 28, 2017 2:38 AM
To: Allan Thomson; Sarah Kelley; Terry MacDonald
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

So putting floor in the street_address field should be supported now, just like any other part of the street address. We should probably clarify this in examples.

 

As an example, MITRE’s located on floors 5-6 in our national business part site, by saying suite 500 and 600. Given our current location approach that would be:

 

{

  “country”: “us”,

  “administrative_area”: “Maryland”,

  “city”: “Annapolis Junction”,

  “street_address”: “300 Sentinel Drive

                                      Suites 500 & 600”

}

 

Obviously the newline would be encoded. If you had a location where they just wanted to say floor you could do that too, like “Floor 16”.

 

The reason I don’t think we should add AGL/MSL altitude is the usual one…IMO we should only add fields when there’s a use case for them that’s in common use across many organizations/tools.

 

John

 

 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, July 27, 2017 at 1:29 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

Hi Sarah – As shared in response to John’s email I would be fine if we support floor at a minimum. But there location systems that handle altitude also.

 

Is there a reason I’m missing why we don’t allow both as options?

 

Allan Thomson

CTO

+1-408-331-6646

LookingGlass Cyber Solutions

 

From: Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Thursday, July 27, 2017 at 10:27 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

So, my question to you Allan would be this. If the primary purpose of adding the altitude field would be so that you could represent a specific floor of a building, then:

  1. Why would you not just include the floor in the actual street address?
  2. How would someone translate “fifth floor” into Altitude = 60 ft?

 

I’m not saying that if people need this field we shouldn’t do it. My biggest problem with altitude is that the only use case I’ve heard is building floor, which is like more accurately represented by just saying “123 Main Street, Fifth Floor, Rm #12” than it is by saying “Altitude = 60 ft”.

 

Is there a use case I’m missing here? I’d willing to expand my knowledge.

 

Thanks,

 

Sarah Kelley

Senior Cyber Threat Analyst

Multi-State Information Sharing and Analysis Center (MS-ISAC)                   

31 Tech Valley Drive

East Greenbush, NY 12061

 

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722

 

                  

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, July 27, 2017 at 1:15 PM
To: "terry.macdonald@cosive.com" <terry.macdonald@cosive.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "John A. Wunder" <jwunder@mitre.org>
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 






All – Whether you agree or disagree with the number of organizations interested in altitude representation in location there are use cases that it helps solve.

 

As stated previously, any large city with skyscrapers (NY, London, Signapore….etc) or enterprise (Fortune 500) that have many different floors and typically multi-tenant environments, then being able to determine location of related intelligence associated with a particular floor is a valid use case.

 

I don’t think organizations that don’t care about this use case should necessarily make decisions to exclude the ability for the standard to support altitude.

 

Is there really a big impact to the velocity of STIX2.1 location efforts by not having altitude as an option?

 

I suggest there’s minimal impact to *allowing* altitude as an option in the location object if a provider wants to include it as an option property.

 

Allan Thomson

CTO

+1-408-331-6646

LookingGlass Cyber Solutions

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, July 26, 2017 at 10:27 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

I agree with Sarah. I believe that altitude is only useful to a very small group, and the 80/20 rule will apply in this case.

 

Cheers

Terry MacDonald

Cosive

 

On 25/07/2017 7:44 AM, "Sarah Kelley" <Sarah.Kelley@cisecurity.org> wrote:

  1. My thoughts are that altitude should be deferred to a future release when we have more defined use cases (I don’t really see how it’s necessary at the moment).
  2. Since the ISO standards cost money, my preference would be to not use them unless the information is also available elsewhere for free.

 

 

Sarah Kelley

Senior Cyber Threat Analyst

Multi-State Information Sharing and Analysis Center (MS-ISAC)                   

31 Tech Valley Drive

East Greenbush, NY 12061

 

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722

 

                  

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 3:28 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

 

Sorry, I should have sent this to cti-stix, as this is really a conversation specifically about STIX.

 

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 3:27 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Location - precision, altitude, and administrative area

 

All,

 

Now that the discussion on location precision has subsided, it seems like the closest thing we have to consensus is that the precision field should be optional and, if it’s not present, the precision is unspecified (i.e. no default). A consuming tool can then provide its own defaults and treat it how it thinks best. I realize this isn’t what everyone wanted, but it did seem like the most common either first or second-best option.

 

We do have two other questions to resolve:

 

1. Are there any use cases for an altitude property?

Altitude has been suggested once but we discussed it on a working call and there didn’t seem to be anything clear. Given that you can currently represent an address (including floor/etc) and lat/lng, are there any use cases that require an altitude specifically?

 

2. Should we use ISO-3166-2 for administrative area?

This was suggested on a TC call…we currently have said we’ll use ISO-3166-1 for country code, but 3166 also includes a set of values for administrative area (state, province, etc.). For example, an ISO 3166-1 alpha-2 country code is “us”, while an ISO 3166-2 area code would be “US-NY”.

 

There are some pros and cons to doing ISO-3166-2. The pros are obviously that it’s an international standard and provides a good set of values to use. That said, it isn’t in as much common use as ISO-3166-1 (country codes) is and so people will need to figure out how to find and use it.

 

 

My points of view on these:

 

  1. I can’t think of any use cases for altitude…address provides the best way to describe people on a certain floor/room in a building.
  2. We shouldn’t use ISO-3166-2 for administrative area, it’s not commonly used enough and I don’t think the value of having defined properties for that field outweighs the downside of people doing it wrong or having to figure out what it is.

 

John

 


.....

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .

 


.....




This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .



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