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] Proposal - Top Level Relationship Object


One principle to handle this situation is to require some minimal, interoperable baseline and have a provision for alternatives. So, we can say there is a marking object. You must support TLP (minimum baseline). You can support other stuff. If you are on a restricted enclave, you can let the transport require the more advanced alternative. In HTTP that would be something like require. 

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger

On Jul 30, 2015 1:39 PM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
One things we did in JSON based TAXII is this idea of allowing an object at the space...  So you could have a simple Marking element which we device as TLP, and it is just a string.  But if that does not work for you, then you can drop in an object and build your detail to your hearts content.  You just need to make sure everyone in your group can understand it.


For example, a very rough example at that...  This would allow full future proofing of the design and allow a very basic version for the 80% use case where a simple string is good enough. 

{
	ID : "1234567890",
	Marking : "Green",
	Marking_Detail : {
		foo : "bar",
		foo1 : "bar1",
		etc
	},
	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 14:09, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

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 


<graycol.gif>"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


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