Hi, Marlon, John,
This is my concern expressed at the 2nd session of the CTI TC
July Monthly meeting and I am glad it has been addressed.
The concern is that there is already important semantic information
(like Country and AdministrativeArea in AIS) accumulated and
that such information can still be exchanged using STIX 2.x.
Regards,
Ryu
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Wednesday, July 26, 2017 5:14 AM
To: Taylor, Marlon; 'Terry MacDonald'; Sarah Kelley
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area
Hm, I’m not sure what you mean by what would be used…the idea would be that the administrative_area property, if present,
MUST contain a valid value from ISO 3166-2. The codes themselves are defined by ISO. So it would look like:
{
“type”: “location”,
“country”: “mx”,
“administrative_area”: “MX-COA”
}
The alternative, leaving it free text with some recommendations to not use abbreviations (i.e. as it is now) would be:
{
“type”: “location”,
“country”: “mx”,
“administrative_area”: “Colima”
}
John
From: Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
Date: Tuesday, July 25, 2017 at 4:05 PM
To: 'Terry MacDonald' <terry.macdonald@cosive.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>
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
Just FYI, DHS uses “ISO 3166-2” for AdministrativeArea and “ISO 3166-1 alpha-2” for Country within AIS(https://us-cert.gov/ais).
If we did use ISO 3166-2 what would be used?
-Marlon
From:
cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Terry MacDonald
Sent: Monday, July 24, 2017 4:08 PM
To: Sarah Kelley
Cc: cti-stix@lists.oasis-open.org; John A. Wunder
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area
I agree.
1. We agreed at the start of development of STIX 2.0 that we would only put in features that were useful to a large percentage of the users... The 80/20 rule we've mentioned before.
I believe that altitude is only useful to a very, very small group, and that group hasn't demonstrated altitude is useful to them sufficiently, leading me to the conclusion that we should not include this function.
2. I prefer the use of pre-existing standards where possible, but I'm still not convinced that we need it conjunction with the other ways of defining a location that we currently have.
So at this stage I would say that I'm a no on ISO-3166-2.
Cheers
Terry MacDonald
Cosive
On 25/07/2017 7:44 AM, "Sarah Kelley" <Sarah.Kelley@cisecurity.org> wrote:
-
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).
-
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
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:
-
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.
-
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.
. . . . .