OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

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


Subject: RE: [cti-stix] [cti-users] MTI Binding


Bret & John,

I would like to think through a proper response to your question, but in the mean time I do have questions:

·         Are the “structs” you define in, I think, GOLANG, the STIX definition of the JSON instance data or part of your program to produce/consume them?

·         If the latter, is there any machine readable schema for STIX relevant to the JSON instance data? Are you considering UML to be such a schema?

·         If JSON is the “MTI” is there still a required XML Schema for STIX and what do you see as its relationship to other exchange formats?

Thanks,

-Cory

 

From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Monday, October 05, 2015 10:23 PM
To: Cory Casanave; 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]