Re: [cti-users] "Data Marking" syntaxes

["Wunder, John A." <jwunder@mitre.org>]

Three comments, all of which are somewhat tangential to the actual structure you’re outlining (sorry):

1. We should consider referencing markings defined in some standard place in the document rather than having to repeat them each time. If I send 100 indicators, that’s 100 repetitions of a fairly complicated marking structure.

2. I think we need to maintain the current approach of extensibility for those fields. Handling is VERY specific to the sharing organization and what we come up with will either end up being overly broad and difficult to implement (to support many different use cases) or overly narrow and won’t work for everyone (to support just our use cases). I’m all for trying to drive to consensus on a “standard” approach (maybe MTI, maybe default, whatever) but we need to have a way for communities not using that to do something else.

3. I put up some approaches to doing field-level markings on the wiki: https://github.com/STIXProject/specifications/wiki/Idea-Exploration%3A-Data-Markings-Alternatives. It includes our current approach, an approach where the markings are embedded in the fields, an approach where the markings are next to the fields, and Pat’s approach to mark at the package level. Issuing different top level objects (or packages) has a few issues we should work through if we want to suggest that (vs. one of the other approaches, either as core STIX or as an extension capability).

John

On Nov 7, 2015, at 12:48 AM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

Can we start driving this discussion to some sort of solution?  So what about something like the following for a top level Indicator.  Note, all marking/handling would be done at the top object level.  If you had different sub needs, you would issue a different top level object.  Once again, just throwing spaghetti at the wall trying to get anything to stick so we can start moving this discussion forward. 

{

    "type": "indicator",

    "marking": {

        "tlp-color": "white || green || amber || red || black",

        "share": "public || limited || no",

        "jurisdiction": [

            "EU",

            "Safe Harbour"

        ],

        "anonymize": "true || false",

        "details": "some really long detailed text with extra context",

        "handeling": {

            "encrypt-at-rest": "true || false",

            "encrypt-in-transit": "true || false"

}

    }

}

This kind of structure will allow people in niche eco-systems to add proprietary fields at both the marking level and the handling level if they need to without breaking other peoples code.  I added a TLP color of "black" to be the magic decoder ring option for "there is extra stuff in this marking / handling that MUST be adhered to".  

We would still need to come up with some general guidelines for the colors to help people make sense of them.

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