Re: [cti-stix] Proposal - Top Level Relationship Object

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

JSON object structures are by their nature extensible. Anyone could add other fields to their marking object at will... this would not break any software parsing the data who did not know or care about those markings being present.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Wunder, John A." ---2015/07/30 04:58:45 PM---I hate to be a downer but I have to point out that this probably won't work for U.S. government mark

From: "Wunder, John A." <jwunder@mitre.org>
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/07/30 04:58 PM
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
Sent by: <cti-stix@lists.oasis-open.org>

---

I hate to be a downer but I have to point out that this probably won't work for U.S. government markings, which are much more complex. Whether that's a show-stopper for the TC I don't know. OTOH USG could internally do something more complicated by replacing the "marking" string with an actual object, it just wouldn't work outside of that enclave.

Some industry groups are also working on more complicated marking structures (FIRST, for example). Might be smart to future-proof by supporting structured markings ahead of time, or just wait until they have something usable before doing that.

I'm kind of ambivalent, simpler is always better but I worry that strings are *too* simple.

John

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Thursday, July 30, 2015 at 3:47 PM
To: Aharon Chernin
Cc: "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object

Perfect, I agree a simple string would be good....  Do we need to provide a helper for those things that are not TLP? Something like: 

{
ID: "12312312321312",
MarkingType: "TLP",
Marking: "Amber",
etc
}


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 Jul 30, 2015, at 12:46, Aharon Chernin <achernin@soltra.com> wrote:

The most common used Marking today is TLP. Today we just use a string to describe the TLP. Below, we just say "Amber".

<marking:Marking_Structure color="AMBER" xsi:type="tlpMarking:TLPMarkingStructureType"/>

The next most used marking is simple marking type, which in the grand scheme of things is just a string.

I could see the creation of an object if there was more context or metadata around marking than just a string

Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com
www.soltra.com




---


From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Thursday, July 30, 2015 1:14 PM
To: Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object

The reason why I like a top level Marking object is, I believe, and PLEASE correct me if my assumptions are wrong, that we could build a small repository of simple markings that will work for say 70% to 80% of the market. Then people just need to use those ID values. They become well known markings and it makes it easier to understand and process.. Then for those groups that need really super elaborate markings, they can do that as well. The other reason for having a top level marking object, is that I think people will end up using them over and over in side of an trust-group or eco-system, or in other parts of a STIX document. If I am wrong, please correct me....


Updated based on John's comments... I think we are getting close to the point of being able to pull this out of email and make it an official proposal in a wiki document... Things outstanding from my view: 1) Start and End times, 2) What does Reliability/Confidence actually look like inside, 3) Marking, 4) Type. Anyone want to take a stab at those?


ID [1]: The ID of the relationship, a simple random GUID
Marking [0..n]: The ID of the marking object that you should reference
Version [1]: The version of the relationship; a simple number to be used with the ID for version control
Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet)
Description [1]: A single simple and short description
Source [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Producer [1]: A simple producer object like what John calls out
Timestamp [1]: A timestamp in UTC stating when the relationship object was created.


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 Jul 30, 2015, at 10:54, Aharon Chernin <achernin@soltra.com> wrote:

ID [1]: The ID of the relationship, a simple random GUID
Marking[1]: The ID of the marking object that you should reference
Version [1]: The version of the relationship; a simple number to be used with the ID for version control
Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet)
Description [1]: A single simple and short description
Source [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Producer [1]: A simple producer object like what John calls out
Timestamp [1]: A timestamp in UTC stating when the relationship object was created.