Based on http://stixproject.github.io/documentation/concepts/data-markings/,
here's what we have now:
<STIXPackage>
<stix:Handling>
<marking:Marking>
<marking:Controlled_Structure>//node() | //@*</marking:Controlled_Structure>
</marking:Marking>
</stix:Handling>
<more stuff that's marked...maybe?></more stuff>
</STIXPackage>
And to select anything non-trivial, I have to consult the XSD spellbook for things like "../../../descendant-or-self::node()
| ../../../descendant-or-self::node()/@*"
As a fan of KISS and DRY, here's what I want:
<STIXPackage TLP="green">
<Indicator TLP="amber">
<Email>
<Recipient="" TLP="red">
<Subject>Buy my $tock$</Subject>
<Body>Please please click here</Body>
</Email>
</Indicator>
</STIXPackage>
But even then as a Python developer, I don't really want to mess with XML. I'd be happiest with something like this:
email = Indicator(TLP="amber")
email.recipient = Recipient( "", TLP="red")
email.subject = "Buy my $tock$"
package = STIXPackage(TLP="green")
package.add_indicator(email)
JSA
From: <> on behalf of Barnum, Sean D. <>
Sent: Monday, November 9, 2015 3:03 PM
To: Aharon Chernin; Jordan, Bret
Cc:
Subject: Re: [cti-stix] Focusing our active discussions a little
One quick comment on the Xpath items below:
It should be noted that Xpath is NOT part of the STIX data model or language specifications.
Xpath would likely be specified within the XML Binding specification as the XML-centric approach to the Controlled_Structure field.
The actual language specifications define Controlled_Structure as:
"The Controlled_Structure property specifies the full explicit set of STIX structured elements to which the marking is to be applied. The controlled structure MUST explicitly select
all structured elements that the marking applies to; selecting a parent structured element may not imply that the marking also applies to its children. Specific syntax for how the set of STIX structured elements will be specified is dependent on the
particular syntactic implementation (XML, JSON, etc.) of the STIX language and MUST be explicitly specified in a separate binding specification for that syntactic implementation (e.g. a STIX XML Binding Specification). For example, a STIX XML Binding Specification
could specify XPath 1.0 as an appropriate choice for the syntax of the Controlled_Structure property."
One the point of "Find a new home for Information Source, outside of Handling/Marking”, this would likely be addressed by
Issue #233 dealing with abstracting Source to a separate object. This would allow Sources to be specified and then all sorts of content from that source to simply reference it
using an appropriate Relationship rather than defining it inline.
Abstract Source to top-level construct rather than embedded only within other constructs · Issue #233 · STIXProject/schemas
This would like involve abstracting InformationSource data to a top-level construct and leveraged where appropriate. Below is from Byron Collie: We are not leaving Source as a technical attribute ...
Read
more...
sean
From: Aharon Chernin <>
Date: Monday, November 9, 2015 at 1:44 PM
To: "Jordan, Bret" <>, "Barnum, Sean D." <>
Cc: "" <>
Subject: Re: [cti-stix] Focusing our active discussions a little
I agree with Sean that we need to get Sightings and Relationships nailed down. However, I need to get this off my chest before I forget.
Soltra Marking Proposal for Discussion:
Issues (I will have Terry add these to the Issue tracker):
XPath in Controlled_Structure does not work well for non-XML implementations of STIX
STIX_Package level handling does not work well when you remove the objects from the STIX_Package (ie. Object reuse)
Marking that is more granular than object level is difficult to implement (ie. 50% of this object is TLP White, 50% of this same object is TLP red).
Solution for Discussion.
Remove Handling/Marking from STIX_Package Header
Remove the concept of XPath Controlled_Structure
Find a new home for Information Source, outside of Handling/Marking
Create Simple Marking, TLP, and TOU marking as either attributes to each object or as elements within each object
Aharon
--
Aharon Chernin
CTO
SOLTRA |
An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 |
www.soltra.com
From: <> on behalf of "Jordan, Bret" <>
Date: Monday, November 9, 2015 at 12:48 PM
To: "Sean D. Barnum" <>
Cc: "" <>
Subject: Re: [cti-stix] Focusing our active discussions a little
We seem to have a lot of momentum right now on Data Marking. It would be a shame to lose that. Might I suggest that we take the next 10 days and try and drive Data Markings to consensus?
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 Nov 9, 2015, at 08:51, Barnum, Sean D. <> wrote:
All,
I wanted to thank everyone for a lot of the great conversation that has been occurring over the last couple of weeks.
That is the good news.
On the not as good news front we haven’t really been able to drive to consensus on any specific concrete proposals yet.
I think that while these various conversations are great and seem to have some good exchange we are currently trying to keep up with and contribute to around 1/2 dozen issue topics rather than the two that we agreed to focus on. I have already
heard from some parties that this level of diverse activity is difficult to keep up with in a well thought out way. I think this dilution is likely part (though certainly not all) of the reason we are still talking about things on some of these issues rather
than having driven towards consensus solutions. I would also hate to have a situation where there is so much active conversation on so many different topics that people not working on this full time with enough cycles to keep up with everything are forced
to choose only specific topics to be involved in and simply do not follow or contribute on others based on time.
May I suggest that we attempt to refocus on 1-2 issue topics, drive them to ground and then move to the others?
The two topics that we had agreed to be discussing are sightings and relationships. I think we have had some good discussion on sightings and if we can focus there without distraction for a bit we can hopefully drive to some consensus. If there
is community desire to have the second active topic be one of these other issues being discussed (data marking application approach, data marking structure, ID format, request/response, etc.) rather than relationships please let us know and we can select one
of these other topics and focus there.
Once again, thank you for your active contributions.
sean
