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: Reviewing External-Reference


Rich has highly valuable deep knowledge regarding STIX 1.X
(the inconsistent, but available, thing that was a 
"Good plan X violently executed now is better than a perfect plan executed next week." - Ref. George S. Patton)

Examples are so obvious and numerous that I'm a bit chocked we would have to list them again...

The REFERENCE class of the XORCISM API/Language can highlight some
https://github.com/athiasjerome/XORCISM/blob/master/SOURCES/XORCISMModel/REFERENCE.cs

Regarding properties, you could reduce/optimize the ones of the XORCISM REFERENCE table (class/table; subject/object) (i.e. if you don't want the books of CWEs...)

CREATE TABLE [REFERENCE](
[ReferenceID] [int] IDENTITY(1,1) NOT NULL,
[ReferenceGUID] [nvarchar](500) NULL,
[ReferenceSourceID] [nvarchar](50) NULL,
[Source] [nvarchar](50) NULL,
[SourceTrustLevelID] [int] NULL,
[SourceTrustReasonID] [int] NULL,
[ReferenceTitle] [nvarchar](max) NULL,
[ReferenceDescription] [nvarchar](max) NULL,
[Type] [nvarchar](50) NULL,
[ReferenceCategoryID] [int] NULL,
[ReferenceURL] [nvarchar](max) NULL,
[ReferenceFilePath] [nvarchar](500) NULL,
[lang] [nvarchar](10) NULL,
[LocaleID] [int] NULL,
[notes] [nvarchar](max) NULL,
[ReferenceVersion] [nvarchar](50) NULL,
[VocabularyID] [int] NULL,
[CreatedDate] [datetimeoffset](7) NULL,
[CreationObjectID] [int] NULL,
[timestamp] [datetimeoffset](7) NULL,
[ValidFromDate] [datetimeoffset](7) NULL,
[ValidUntilDate] [datetimeoffset](7) NULL,
[ValidityID] [int] NULL,
[LastCheckedDate] [datetimeoffset](7) NULL,
[ConfidenceLevelID] [int] NULL,
[ConfidenceReasonID] [int] NULL,
[TrustLevelID] [int] NULL,
[TrustReasonID] [int] NULL,
[isEncrypted] [bit] NULL,
[Reference_Publication] [nvarchar](250) NULL,
[Reference_Edition] [nvarchar](100) NULL,
[Reference_PubDate] [nvarchar](50) NULL,
[Reference_Publisher] [nvarchar](100) NULL,
[ReferenceISBN] [nvarchar](50) NULL,
[Reference_Date] [nvarchar](50) NULL


PS: not having Incident would be, excuse my french, ridiculous



2016-06-15 16:37 GMT+03:00 Piazza, Rich <rpiazza@mitre.org>:

Hi Bret,

 

If we were just supporting external_ids, I would probably agree with you – but we are supporting external references also (URLs).  Before this proposal was made, external_reference was a full-fledged TLO, which any other TLO could have a relationship with – so this enables us to handle that use case.

 

BTW, in the examples I included several uses which were not Attack Pattern related:  Incident referring to a JIRA or VERIS external id, Report referring to a PDF report (I know Incident isn’t in MVP – yet J ).

 

                Rich

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Wednesday, June 15, 2016 6:39 AM
To: Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org


Subject: Re: [cti-stix] Re: Reviewing External-Reference

 

That is fine...  But can we get an explanation of how it would be used or how it would make sense for all TLOs not just a subset of the TLOs?  The only one I have heard an example for is Attack Pattern and that is so you can link against a CAPEC ID.  

 

How would this be used for each of the following:

 

Campaign

Course of Action

Identity

Indicator

Malware

Marking Definition

Observation

Relationship

Report

Sighting

Threat Actor

 

I think it will be a huge stretch to justify it for Relationship, Marking Definition and maybe even Report if not also some of the others.

 

 

Bret

 

 

 

 


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Tuesday, June 14, 2016 6:32 PM
To: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: Reviewing External-Reference

 

I come at this from the opposite perspective I think. Back in STIX 1.2, we had this field in two places: Indicator and Incident. In Indicator it was called Alternative_IDs and in Incident it was called External_IDs. At that time we had an issue to add it to Observable (now Observation) as well: https://github.com/CybOXProject/schemas/issues/386. Lastly, based on those usages and the intent to use it on Vulnerability and Attack Pattern, we added a ticket to just make it consistent across all objects: https://github.com/STIXProject/schemas/issues/358. We discussed it back in February as part of the core object properties discussion (http://markmail.org/message/4jqzqj4mdoqygbk2?q=external+reference+list:org%2Eoasis-open%2Elists%2Ecti+date:201602+&page=1#query:external%20reference%20list%3Aorg.oasis-open.lists.cti%20date%3A201602%20+page:1+mid:zfwhga2ayoosjblh+state:results) and decided at that point to add it. It was discussed in the context of the Report and Sighting object at that point (on both the CTI list and the CTI STIX list).

This would serve the same purpose as Alternative_ID on Incident and External_ID on Incident. (suggested by someone who wanted to remain anonymous)

 

 

Later on, we altered course a bit and rather than having it as a property on all TLOs we added “External Reference” as a separate TLO and said we would use relationships for this concept and so it was removed. Now that we’re moving back to having it as properties, in my opinion we should just move it back to what we discussed previously and add it across all TLOs. It’s more consistent that way and is a change based on actual experience with an inconsistent approach in STIX 1.2.

 

So, long story long, I think we should add it across all TLOs.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, June 14, 2016 at 6:51 PM
To: Rich Piazza <rpiazza@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Reviewing External-Reference

 

I would prefer that we only add things to the Common TLO Properties section once we know that it is in fact needed on every TLO.  I do not want to just artificially add things to TLOs that may never need them.

 

So lets use the external-reference type for Attack Pattern and see if anything else needs it in the future.  My guess is that only a small handful of things will actually end up needing it.  

 

Bret

 

 


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Piazza, Rich <rpiazza@mitre.org>
Sent: Tuesday, June 14, 2016 10:35 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Reviewing External-Reference

 

When reviewing the External Reference type (https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.cez46v5quobo ), please consider the usages of it.

 

In the original proposal, as discussed on a previous working call, it was suggested that external_references be added as a Common TLO field. 

However, the Common TLO section’s status was already “Consensus”, so your humble editors didn’t want to change that text without discussion.

 

An alternative is to only include it for particular TLOs.  It originally was discussed by John Wunder as a way to support external_ids like CAPEC.  Therefore, it would be make sense for it to be a field of Attack Pattern, for instance.  However, it was broadened to include URLs, so it was thought that all TLOs might need this concept.  So……

 

…as we finalize External References, we must also approve how it is used.  The choices are:

 

·         external_references is a Common TLO field

·         external_references is a field on a TLO if there is an explicit use case for it (e.g., Attack Pattern).

 

 




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