It would be much easier for me to comment on these topics if we had them in a living document and had the non-consensus items identified in some way (e.g., highlighted text). My opinion of certain fields will depend more on the normative text that surrounds
them than the concept of them.
I’ve moved some text from the TWIGs document to the STIX pre-draft document [1] under the heading “Common Object Properties” and attempted to follow my own advice; non-consensus items are highlighted in yellow. I know we talked about doing this on the
wiki, but the wiki makes my brain hurt and scream out for a better way of organizing the information (Does anyone else get the same thing? If it’s just me I’ll go along with the wiki).
Thank you.
-Mark
[1] https://docs.google.com/document/d/1U48DOJzh2qELOEhhVWz_G6hL0Bazx1Y52wpOeR8jaVk/edit#
From: <> on behalf of "Wunder, John A." <>
Date: Wednesday, February 3, 2016 at 9:20 PM
To: "Jordan, Bret" <>, "Piazza, Rich" <>
Cc: "" <>
Subject: Re: [cti] Top-Level Object Properties
So fwiw I like having the identity/source separate from the reference. I do kind of agree that we could merge the url, name, and ID fields though…it’s a distinction that probably doesn’t matter for the vast majority of cases. I could go either way.
From: "Jordan, Bret" <>
Date: Wednesday, February 3, 2016 at 11:51 AM
To: Rich Piazza <>
Cc: "Wunder, John A." <>, "" <>
Subject: Re: [cti] Top-Level Object Properties
It should just be an Array of Strings and then the user can put in what every they want.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 3, 2016, at 09:40, Piazza, Rich <> wrote:
url is optional,
you can use name,
which is also optional – you just have to use one of them
From: [mailto:] On
Behalf Of Jordan, Bret
Sent: Wednesday, February 03, 2016 11:24 AM
To: Wunder, John A. <>
Cc:
Subject: Re: [cti] Top-Level Object Properties
Well then I do not think we have consensus on the external_ids object... I thought this was going to be just an array of string values. Why does it need an "id" and why would we every make data field be a "url".
External_Ids are going to be populated by internal systems or vendor products. These solutions will give a name like "malware foo xyz" for example, this is not a URL.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 3, 2016, at 08:36, Wunder, John A. <> wrote:
The syntax means that those fields are a sub-object nested under the parent. So that would be one of the keys within the objects in the external_ids array.
From: "Jordan, Bret" <>
Date: Wednesday, February 3, 2016 at 10:00 AM
To: "Wunder, John A." <>
Cc: "" <>
Subject: Re: [cti] Top-Level Object Properties
I do not believe we have consensus on all of the items in the consensus section. Namely, what are the "----" field all about?
Example
----id (required)
IDFormat
The external ID itself
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 3, 2016, at 05:53, Wunder, John A. <> wrote:
All,
There’s a new topic to think about! As discussed at the face to face, each top-level object in STIX and CybOX will inherit from a core set of properties…things like ID, etc. We haven’t
quite agreed on what all of those fields are, though.
Take a look at this writeup: https://github.com/STIXProject/specifications/wiki/Active-Issue:-IDable-Construct-Properties.
It has a set of fields that we have general agreement on, a list of fields we haven’t really discussed, and then a couple proposals (from Sean and from the twigs team). Feel free to either add your own proposal to that wiki page or discuss on the mailing lists
and slack. The key question to consider: what fields should be available on *all* top-level objects?
John
PS: The twigs team added our proposal to the writeup on source references. You can see it on the issue page (https://github.com/STIXProject/specifications/wiki/Active-Issue:-Relating-Source)
by scrolling down to Proposal 2. If you want to respond to that one via e-mail, make sure to make a separate thread.
