[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Object Level Markings
Dave,
A few things.... In most situations, IMHO, content will be delivered in atomic units. The STIX Bundle will probably not be used in most TAXII sessions. You will request content and you will be delivered those objects one at a time.. You will then parse those objects and discover reference that you will then need to dereference on the TAXII server... AKA TAXII 2.0 will be a RESTful design.
Now with that said, we may add an HTTP header flag that would allow you to tell the TAXII server to automatically de-reference all of the content and send it all to you. But the TAXII server may not honor that. So there is no way to guarantee that you will get all of the content in the same JSON object.
Stepping back a bit, it sounds like you are asking for a simple summary string in addition to the marking-definition reference... Is that correct? Meaning you would have something like:
{ "type": "indicator", "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235", ... "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"], "object_marking_notes": "NATO Secret" ... }
So the main definition and details would still be in the marking-definition, but you would have a simple helper string value? Or am I misunderstanding what you are asking for?
Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com>
Sent: Tuesday, June 14, 2016 10:51 AM To: Jason Keirstead Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object Level Markings Jason,
Yes, if we were sending that kind of information it would be insane.
There's three items of information associated with the access control decision:
* The Label, which in your example was "NATO SECRET". In NATO's preferred syntax, that's actually a shortish bit of XML, usually around half a kilobyte.
* The Clearance, which a guard would typically have as a constant value, and an endpoint would handle via LDAP lookups, etc.
* The Policy, which actually defines the rules, and again, for NATO, would be XML - but much larger. NATO's policy is 86k, for instance.
The part I'm suggesting needs to be kept with the data is only the first of these, the label. An example label, in NATO's ADatP-4774 format, is here:
https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-17-1.nato
That repository also has (MIT-licensed) code that'll produce a display marking from it (in this case "NATO UNCLASSIFIED Releasable to ISAF, KFOR, RESOLUTE SUPPORT"), which it does from the policy information file, which is similar to that available here
in Open XML SPIF format:
We won't be sending around the policy - we expect anything that needs that to have it already. Similarly, clearances make no sense to send around at all - they'd be selected and evaluated locally in every case.
But typical specifications for this require that the label metadata is "bound" with the data, for example in X.841 §6.1.3, or ADatP-4778.
I'm proposing that in order to side-step the need for cryptographic binding at the object level, we must at minimum keep the label metadata within the same bundle, and rely on the TLS channel to provide hop-by-hop integrity, and claiming we're doing X.841§6.1.3.1.
That's really the minimum I think I can get past an accreditor.
Does this help clarify a little?
Dave.
On 14 June 2016 at 16:55, Jason Keirstead
<Jason.Keirstead@ca.ibm.com> wrote:
Dave Cridland
Participate | Collaborate | Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]