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] [cti-users] MTI Binding


Re: Is anyone actually proposing JSON-LD as the MTI for STIX?

Ok, I will step into it and propose JSON-LD as a MTI based on the following MINIMUM requirements for any exchange format:

1: That all data exchange is described by one or more machine readable schema

2: That all exchange data reference its definition(s) such that every tag used may be deterministically bound to its definition

3: That elements in an exchange document be able to reference elements in other exchange documents

4: That all STIX exchange formats utilize existing standards and not duplicate standard capabilities.

5: That the STIX exchange schema scale in complexity based on requirements (simple things should be simple, complex things possible and reasonable)

 

I would note that current STIX-XML meets all of the above except #3 and perhaps #5. Simple JSON meets none. IMHO JSON-LD meets all. It is not perfect, perfect is not available – it seems a good balance between simplicity and flexibility. I would also emphasize that the above list is minimal, there are other desirable features. I would be surprised if these requirements were not ubiquitous in the group.

 

I would also point out the relative risks. If some are correct and STIX is a closed manual coded system then JSON-LD will have some unused and ignored context sections in the front and we will have wasted some time making the RDF schema. The alternative risk for “simple JSON” is that it will not be possible to have dynamic use of stix data, that data external to stix will be unusable, that data internal to stix will be unavailable to others – that STIX is another “data island” where the sea-change is moving in the opposite direction.

 

-Cory Casanave

 

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Davidson II, Mark S
Sent: Tuesday, October 06, 2015 8:17 AM
To: Jordan, Bret; Cory Casanave; cti-users@lists.oasis-open.org; cti-stix@lists.oasis-open.org
Subject: [cti-users] RE: [cti-stix] [cti-users] MTI Binding

 

I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:

 

1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?

Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion makes it clear that we are considering it

2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size and complexity. What examples would be sufficient?

3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product and I want to add STIX support, won’t developers have to write code?

I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how that actually works (the more concrete the example the better, at least for me).

 

Thank you.

-Mark

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, October 05, 2015 10:23 PM
To: Cory Casanave <cory-c@modeldriven.com>; cti-users@lists.oasis-open.org; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] [cti-users] MTI Binding

 

Cory,

 

Please help me understand....  

 

Say for kicks and giggles I have some structs that looks like this to consume an Indicator in a STIX package

 

type StixMessageType struct {
       Id         string                    `json:"id,omitempty"`
       IdRef      string                    `json:"idref,omitempty"`
       Timestamp  string                    `json:"timestamp,omitempty"`
       Version    string                    `json:"version,omitempty"`
       Indicators []indicator.IndicatorType `json:"indicators,omitempty"`
}

 

type IndicatorType struct {

       Id                        string                         `json:"id,omitempty"`

       IdRef                     string                          `json:"idref,omitempty"`
       Timestamp                 string                         `json:"timestamp,omitempty"`
       Version                      string                               `json:"version,omitempty"`
       Negate                       bool                                 `json:"negate,omitempty"`
       Title                        string                               `json:"title,omitempty"`
       Types                        []string                             `json:"type,omitempty"`
       AlternativeIDs               []string                             `json:"alternative_ids,omitempty"`
       Descriptions                 []common.StructuredTextType          `json:"descriptions,omitempty"`
       ShortDescriptions            []common.StructuredTextType          `json:"short_descriptions,omitempty"`
       ValidTimePositions           []ValidTimeType                      `json:"valid_time_positions,omitempty"`
       Observable                   *observable.ObservableType           `json:"observable,omitempty"`
       CompositeIndicatorExpression *CompositeIndicatorExpressionType    `json:"composite_indicator_expression,omitempty"`
       IndicatedTTP                 []common.RelatedTTPType              `json:"indicated_ttps,omitempty"`
       KillChainPhases              []common.KillChainPhaseReferenceType `json:"kill_chain_phases,omitempty"`
       TestMechanisms               []TestMechanismType                  `json:"test_mechanisms,omitempty"`
       LikelyImpact                 *common.StatementType                `json:"likely_impact,omitempty"`
       SuggestedCOAs                []SuggestedCOAsType                  `json:"suggested_coas,omitempty"`
       Handling                     []common.MarkingSpecificationType    `json:"handling,omitempty"`
       Confidence                   *common.ConfidenceType               `json:"confidence,omitempty"`
       Sightings                    *SightingsType                       `json:"sightings,omitempty"`
       RelatedIndicators            *RelatedIndicatorsType               `json:"related_indicators,omitempty"`
       RelatedCampaigns             *RelatedCampaignReferencesType       `json:"related_campaigns,omitempty"`
       RelatedPackages              []common.RelatedPackageRefType       `json:"related_packages,omitempty"`
       Producer                     *common.InformationSourceType        `json:"producer,omitempty"`
}

And lets say I get an indicator over the wire that looks something like this, built directly from the STIX 1.2 schema.  

 

{
    "stix_package": {
        "id": "example:package-1ad2aab5-1707-4fcc-8fd2-ebae152adeec",
        "indicators": [
            {
                "id": "example:indicator-8571137a-32a2-4934-8077-2129475813af",
                "idref": "companyfoo:indicator-1234-1234-1234-1234",
                "timestamp": "2015-10-05T20:03:23-06:00",
                "version": "1.2.1",
                "title": "Some really neat indicator that we found",
                "type": [
                    "URL Watchlist"
                ],
                "alternative_ids": [
                    "CV-2014-12-12345",
                    "CV-2015-02-54321"
                ],
                "descriptions": [
                    {
                        "id": "example:text-8769b510-9e76-4573-9778-864a51f052ae",
                        "format": "text/plain",
                        "value": "Some long description"
                    }
                ],
                "short_descriptions": [
                    {
                        "id": "example:text-12170f79-62f4-48d9-9a97-d7077f05714f",
                        "format": "text/plain",
                        "value": "Some shorter description"
                    }
                ]
            }
        ]
    }
}

 

We have a version field to say what version of an indicator it is and we know the type because it is in an indicator blob inside a stix_package blob.  

 

How does adding namespace elements make this more clear? 

 

I can easily parse this indicator and do interesting things with it.  I can parse the TTPs that reference it and do things with them.  I understand all of the fields in the indicator package because they are all well documented on the Github site [1] for Indicators.  So I can either dump this data in to a relational database or in to a document database like MongoDB.  

 

Please help me understand why namespaces are required for structured data that is well defined.  Like I said before, I can totally get and fully understand the need for JSON-LD in the open web.  It makes perfect sense when you need this to share say random profile data between two or more entities (twitter, Facebook, youtube, etc).  But we are not transporting random CTI, it will be in STIX.  So alternative_ids are Alternative IDs, and a title is a Title.  I do not see how JSON-LD helps us in anyway other than making a case for RDF over UML/OWL as RDF can work with JSON-LD.  

 

The only value I can see for JSON-LD is if we want to allow overloading.  So I can make my own Indicator format and not adhere to the STIX version of an Indicator.  In that case, yes, I can see the value, but I can also see the madness and chaos that would come from it.  

 

 

 

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

 



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