Re: [cti] Preservation of STIX

Re: âIf we could go back in timeââ

 

     Ahhhhhhâthere you go raising âTimestamp Precisionâ again?

 

Please note and emphasize Smiley-Face:

 

  😉

Patrick Maroney

Principal - Cybersecurity

Chief Security Office

Office: 732.615.5287 | Cell: 609.678.5613 |
Email: 


 

 

From:
 <> on behalf of Bret Jordan <>

Date: Friday, April 30, 2021 at 4:07 PM

To: Jason Keirstead <>

Cc:  <>, Marlon Taylor <>

Subject: Re: [cti] Preservation of STIX

This issue has been discussed at length over and over. The consensus of the TC is with the text as it is written. From a level of specificity the versioning rules are general and apply to all of STIX object. However, there is a caveat and
 _additional_ clarification that was given to Custom Properties. That text was well understood, the ramification of it well understood, and what it meant was well understood and debated. This is how standards are written. Broad rules that cover everything and
 when needed specific sometimes other rules are given for very specific purposes. That was the case here. 

 

It is also important to note that there was a very small and very vocal minority of people that disagreed with that decision that was made by the TC ever so long ago. But the majority made a decision and it has been in the document for
 a long time, early early on in STIX 2.0. 

 

There are all kinds of issues in STIX that various people, even myself, do not like. If we could go back in time, I am sure we would change some of them. But that is the nature of consensus and community built things. 

 

Bret

On Apr 30, 2021, at 1:00 PM, Jason Keirstead <> wrote:

 

I need to correct myself before someone jumps all over me...

Please add words inside *** to my reply...

 

 

The spec is very clear on this... if you *** are not the original producer and you *** change the data in the object in any way when you
 retransmit, then you must generate a new ID for it. This includes dropping fields, adding fields, or any other change whatsoever.

 

-

Jason Keirstead

Distinguished Engineer, CTO - IBM Security Threat Management

www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

www.opencybersecurityalliance.org

 

 

 

----- Original message -----

From: "Jason Keirstead" <>

Sent by: <>

To: 

Cc: 

Subject: [EXTERNAL] Re: [cti] Preservation of STIX

Date: Fri, Apr 30, 2021 3:49 PM

 

The spec is very clear on this... if you change the data in the object in any way when you retransmit, then you must generate a new ID for it. This includes dropping fields,
 adding fields, or any other change whatsoever.

 

TIPs and other systems that consume an SDO and then retransmit it later, but with different fields, MUST do so with new object IDs (which start over at version 1) - and ideally,
 a new created_by_ref (in the previous 2.0, interop tests, created_by_ref was required as part of interop)

If a system is simply dropping fields and re-transmitting with the same ID, then they are not compliant with the spec.

 

--

"STIX Objects have a single object creator, the entity that generates the id for
 the object and creates the first version. The object creator MAY (but not necessarily will) be identified in the created_by_ref property
 of the object. Only the object creator is permitted to create new versions of a STIX Object. Producers other than the object creator MUST NOT create new versions of that object. If a producer other than the object creator wishes to create a new version,
 they MUST instead create a new object with a new id. They SHOULD additionally
 create a derived-from Relationship object to relate their new object to the original object that it was derived from."

 

-

Jason Keirstead

Distinguished Engineer, CTO - IBM Security Threat Management

www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

www.opencybersecurityalliance.org

 

 

 

----- Original message -----

From: "Taylor, Marlon" <>

Sent by: <>

To: "" <>

Cc:

Subject: [EXTERNAL] [cti] Preservation of STIX

Date: Mon, Apr 19, 2021 1:40 PM

 

Hi TC,

 

What is the TC stance on the preservation of STIX content?

 

Through engagements with various members of the STIX community it has become apparent that STIX content is handled differently within the community. The difference in STIX handling
 (e.g. dropped fields) results in confusion and lack of trust between systems. This concern has echoed throughout the STIX community, the Interop subcommittee, and now the TC for the purpose of resolution! This is great timing as we can address this for all
 while the specification is in public review prior on the way to becoming an OASIS standard!

 

The table below highlights areas of consideration. The âRow #â column provides an unique identifier of each use case. Iâm we hoping we as a TC can provide a decision on this
 matter and show alignment via the rows below.

 

Row #

Ingest - Keep Original

 

No â the original STIX is a
not accessible  

Yes â the original STIX is accessible 

Process  - Translate to internal Data Model

 

None â no STIX properties are mapped to the data model

Some â some STIX properties are mapped to the data model

All â every STIX property in mapped to the data model

Export â Original

 

No â the original STIX is
not exportable

Yes â the original STIX is exportable

Export â Processed

 

No â the internal data model is
not exportable is STIX

Yes â the internal data model is exportable is STIX

1

No

None

No

No

2

No

None

No

Yes

3

No

None

Yes

No

4

No

None

Yes

Yes

5

No

Some

No

No

6

No

Some

No

Yes

7

No

Some

Yes

No

8

No

Some

Yes

Yes

9

No

All

No

No

10

No

All

No

Yes

11

No

All

Yes

No

12

No

All

Yes

Yes

13

Yes

None

No

No

14

Yes

None

No

Yes

15

Yes

None

Yes

No

16

Yes

None

Yes

Yes

17

Yes

Some

No

No

18

Yes

Some

No

Yes

19

Yes

Some

Yes

No

20

Yes

Some

Yes

Yes

21

Yes

All

No

No

22

Yes

All

No

Yes

23

Yes

All

Yes

No

24

Yes

All

Yes

Yes

 

Addressing the preservation of STIX as a TC will drive a better understanding for all and interoperability.

 

 

Marlon Taylor

<>